Modelação T15 – Conceptual Modelling Methodologies José Borbinha .

ModelaçãoT15 – Conceptual Modelling

MethodologiesJosé Borbinha

http://untitledarchive.com/post_images/5904_funny-transportation.jpg

2

ProgramT01-T02 – Module 1 - Introduction to Systems ModelingT03-T04 – Module 2 - Conceptual Modeling – Requirement EngineeringT05-T06 – Module 3 - Conceptual Modeling – Domain; Structure ModelingT07-T13 – Module 4 - Conceptual Modeling – BehaviorT14-T15 –Module 5 - Conceptual Modeling – ArchitectureT16-T21 – Module 6 – Ontology

T22 - Module 7 - Conceptual Modeling – Methodologies, Advanced Concepts

T23 – Test 1 – Revision…T24 - Conceptual Modeling – Global Revisions; Exercises, …

3

Systems and systems’ descriptions

(IEEE Std. 1471-2000: IEEE Recommended Practice for Architecture Description of Software-Intensive Systems)

class IEEE1471

Mission

Environment System Architecture

StakeholderArchitecturalDescription

Rationale

Concern Viewpoint View

Library Viewpoint Model

fullfi ls1..*

inhabits

influences has an

has 1..*identifies

1..*

described by1

is important to1..*

has

1..*

is addressed to1..*

used tocover

1..*

identifies1..*

selects1..*

has source

0..1

conforms to

establishes methods for1..*

participates in

1..*

consists of

1..*

provides

organized by

1..*

aggregates

1..*

participates in

4

Between Systems and Models


class IEEE1471

Mission

Environment System Architecture

StakeholderArchitecturalDescription

Rationale

Concern Viewpoint View

Library Viewpoint Model

fullfi ls1..*

inhabits

influences has an

has 1..*identifies

1..*

described by1

is important to1..*

has

1..*

is addressed to1..*

used tocover

1..*

identifies1..*

selects1..*

has source

0..1

conforms to

establishes methods for1..*

participates in

1..*

consists of

1..*

provides

organized by

1..*

aggregates

1..*

participates in

5

Systems and Viewpoints

• System – A collection of components organized to accomplish a specific function or set of functions

• Viewpoint - A specification of the conventions for constructing and using a view. A pattern or template from which to develop individual views by establishing the purposes and audience for a view and the techniques for its creation and analysis


6

Concerned stakeholders

• Model – An abstract representation of a domain.

• Domain – A specific area of interest.• Concern – A domain of interest.• Viewer – A stakeholder.• Stakeholder – An individual, team, or

organization (or classes thereof) with interests in, or concerns relative to, a system.

7

Viewers

(Proper, H. A., Verrijn-Stuart, A. A., Hoppenbrouwers, S. J. B. A. (2005). On Utility-based Selection of Architecture-Modelling Concepts. In Proceedings of the 2nd Asia-Pacific conference on Conceptual Modelling.)

8

View• A view is a representation or description of the entire

system from a single perspective. In contrast to a viewpoint, a view refers to a particular architecture of a system (i.e., an individual system, a product line, a system-of-systems, etc.). A view is primarily composed of models, although it also has additional attributes. The models provide the specific description, or content, of an architecture. For example, a structural view might consist of a set of models of the system structure. The elements of such models might include identifiable system components and their interfaces, and interconnections among those components.


9

Models, Methods and Methodologies

• Models (which are are expressed in specific languages, such as UML, SysML, etc.) are expected to result from the application of specific methods (processes) according to the stipulated by specific methodologies…

Modelação 2010 André Vasconcelos, Artur Caetano , Helena Pinto, José Borbinha

10

Methodology and Method

• Methodology: A body of practices, procedures, and rules used by those who work in a discipline or engage in an inquiry; a set of working methods

http://www.answers.com/topic/methodology

• Method: A means or manner of procedure, especially a regular and systematic way of accomplishing something

http://www.answers.com/topic/method

11

(in other words)

• Methodology: A collection of methods, procedures, and standards that defines an integrated synthesis of engineering approaches to the development of a work product.

• Method: a specific technique suitable for application under specific assumption

12

Methodologies and Methodshttp://openlearn.open.ac.uk/mod/resource/view.php?id=257862

• A method is used as a given, much like following a recipe in a recipe book whereas a methodology can be adapted by a particular user in a participatory situation. There is a danger in treating methodologies as reified entities – things in the world – rather than as a practice that arises from what is done in a given situation.


13


• A tool is usually something abstract, such as a diagram, used in carrying out a pursuit, effecting a purpose, or facilitating an activity. Technique is concerned with both the skill and ability of doing or achieving something and the manner of its execution, such as drawing a diagram in a prescribed manner. An example of technique in this sense might be drawing a systems map to a specified set of conventions.


14


• An aware systems practitioner, aware of a range of systems distinctions (concepts) and having a toolbox of techniques at their disposal (e.g. drawing a systems map) as well as systems methods designed by others, is able to judge what is appropriate for a given context in terms of managing a process. This depends, of course, to a large extent on the nature of the role the systems practitioner is invited to play, or chooses to play.


15

From “Survey of Model-Based Systems Engineering (MBSE)” Methodologies http://www.omgsysml.org/MBSE_Methodology_Survey_RevB.pdf

16

Hard versus Soft systems

• Hard systems approaches assume:– Well-defined problem to be solved– Scientific approach to problem-solving– An ideal solution is foreseen

• Soft systems approaches assume:– Problems are poorly defined– No objective reality (stakeholders interpret problems

differently)– Human factors are important– Purpose can be to learn and better understand the

system, rather than finding an ideal solution


17

Soft systems approaches are relevant at the methodological level

18

“Categories of Method”http://www.agiledata.org/essays/differentStrategies.html

When the systems is software…– Code and fix…– Serial rigorous…– Iterative rigorous…– Agile…


19


• Code and fix. This approach is also known as “hacking”, “hack and slash”, or “no-process at all”. This approach to development is chaotic and often unplanned, or when it is planned the plan is quickly abandoned. Estimates and schedules, when made at all, are rarely met in practice.


20


• Serial rigorous. Software processes in this category are well defined and often include detailed procedures that developers are expected to follow in a more-or-less serial manner. For example requirements are identified, reviewed, and accepted. The analysis of those requirements is performed, reviewed, and accepted. The design is defined, reviewed, and accepted. And so on. There is room for feedback between phases, although that feedback is provided via a reasonably defined procedure and the changes are then reviewed and accepted as before. Systems are typically delivered on an incremental basis where the releases are on the order of several quarters or years in length. ISO/IEC 12207 is an example of a process which is typically instantiated in a serial and rigorous manner (to be fair, it doesn't have to be instantiated like this but it typically is). This approach is sometimes called a “waterfall process” or a “big design up front (BDUF)” process.

http://www.12207.com/

21


• Iterative rigorous. Software processes in this category are well defined and often include detailed procedures that developers are expected to apply in an iterative manner. For example requirements may be initially defined at a high-level with the detail later identified on an as needed basis. Small portions of your system are fleshed out, with software potentially delivered on an incremental basis following short release cycles often on the order of weeks or months. The Rational Unified Process (RUP) and the Enterprise Unified Process (EUP) are examples of an iterative rigorous process.


http://www.agilemodeling.com/essays/initialRequirementsModeling.htm

http://www.ambysoft.com/unifiedprocess/rupIntroduction.html

http://www.enterpriseunifiedprocess.com/

22


• Agile. Agile is an approach to software development that is people oriented, that enables people to respond effectively to change, and that results in the creation of working systems that meets the needs of its stakeholders. Software processes in this category are defined at a high-level, often presented as a collection of synergistic practices or philosophies. Feature Driven Development (FDD), Agile Unified Process (AUP), and XP are examples of agile software processes.


http://www.agilemodeling.com/essays/fdd.htm

http://www.ambysoft.com/unifiedprocess/agileUP.html

http://www.agilemodeling.com/essays/agileModelingXP.htm

23

Methodologies - Basic approaches

• Waterfall…• Vee…• Spiral…• …


24

The Waterfall methods

25

The Vee methods

26

Spiral Development Methods

27

Measuring Capabilitieshttp://www.sei.cmu.edu/cmmi/

28

CMMI - Capability Maturity Model Integrationhttp://en.wikipedia.org/wiki/Capability_Maturity_Model_Integration

When the system is the organization:• Capability Maturity Model Integration (CMMI) is

a process improvement approach that helps organizations improve their performance. CMMI can be used to guide process improvement across a project, a division, or an entire organization.

• CMMI helps "integrate traditionally separate organizational functions, set process improvement goals and priorities, provide guidance for quality processes, and provide a point of reference for appraising current processes."


29

CMMIhttp://mdob.larc.nasa.gov/hilites/Hl.03/SEPG03.graphic.jpg

30

Examples…


31


When the scope are complex/heterogeneous systems

32


When the scope are (very) complex/heterogeneous systems

33



34



35



36

When the scope is SoftwareFor more details - http://www.agiledata.org/essays/differentStrategies.html

37

IBM Rational Unified Process (RUP)

When the system is logical (software) and complex…• RUP is a risk-driven, use-case-based, and architecture-

centric, iterative software development process. RUP embodies industry-standard management and technical methods and techniques to provide a software engineering process particularly suited to creating and maintaining component-based software system solutions. RUP communicates roles, activities, and artifacts organized by process workflows that guide project teams through software engineering disciplines under the purview of operational business phases and decision making milestones.

http://www.ibm.com/developerworks/rational/library/4763.html


38

IBM Rational Unified Process

http://www.ibm.com/developerworks/rational/library/content/RationalEdge/may04/4763_fig2.jpg


39

RUP as an extension of the UML metamodel

http://www.ibm.com/developerworks/rational/library/05/323_extrup1/


40

RUP is a Model-based process engineering methodology



41

RUP is a Model-based process engineering methodology


42

Rational Software Platform for Systemshttp://www-01.ibm.com/software/rational/solutions/systems/?S_TACT=105AGX23&S_CMP=HP

43

ICONIX – An agile use case driven methodology

• When the system is software (and not too complex…)


44

ICONIX• a software development methodology which predates both the

Rational Unified Process (RUP), Extreme Programming (XP) and Agile software development.

• Like RUP, the ICONIX process is UML Use Case driven but more lightweight than RUP.

• Unlike the XP and Agile approaches, ICONIX provides sufficient requirement and design documentation, but without analysis paralysis.

• The ICONIX Process uses only four UML based diagrams in a four step process that turns use case text into working code.

• A principle distinction of ICONIX is its use of robustness analysis, a method for bridging the gap between analysis and design. Robustness analysis reduces the ambiguity in use case descriptions, by ensuring that they are written in the context of an accompanying domain model. This process makes the use cases much easier to design, test and estimate.


http://en.wikipedia.org/wiki/Rational_Unified_Process

http://en.wikipedia.org/wiki/Extreme_Programming

http://en.wikipedia.org/wiki/Agile_software_development

http://en.wikipedia.org/wiki/Agile_software_development

http://en.wikipedia.org/wiki/Unified_Modeling_Language

http://en.wikipedia.org/wiki/Use_Case

http://iconixprocess.com/iconix-process/analysis-and-preliminary-design/robustness-analysis/

http://en.wikipedia.org/wiki/Domain_model

4545

ICONIX

46

46

Traceability in ICONIX

Use Cases

Use case Scenarios Sequence

DiagramsRobustness

47

State of Michigan Systems Engineering Methodology (SEM)http://www.michigan.gov/suite/0,1607,7-245-45409---,00.html

When the scope are information systems at a large…

48

State of Michigan Systems Engineering Methodology (SEM)


49

TOGAF - The Open Group Architecture Frameworkhttp://www.opengroup.org/togaf/

When the system is the business and its IT support…

50

TOGAF - Architecture Development Method (ADM)http://www.opengroup.org/architecture/togaf9-doc/arch/Figures/adm.png

51

…enough for now!

http://www.ehotdiscussion.com/wp-content/uploads/2009/03/clip-image00111.gif

Modelação T15 – Conceptual Modelling Methodologies José Borbinha .

Documents

Transcript of Modelação T15 – Conceptual Modelling Methodologies José Borbinha .