Modelação

1. Modelação T15 – Conceptual Modelling Methodologies José Borbinha http://untitledarchive.com/post_images/5904_funny-transportation.jpg

2. Program T01-T02 – Module 1 - Introduction to Systems Modeling T03-T04 – Module 2 - Conceptual Modeling – Requirement Engineering T05-T06 – Module 3 - Conceptual Modeling – Domain; Structure Modeling T07-T13 – Module 4 - Conceptual Modeling – Behavior T14-T15 –Module 5 - Conceptual Modeling – Architecture T16-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)

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

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 (IEEE Std. 1471-2000: IEEE Recommended Practice for Architecture Description of Software-Intensive Systems)

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. (IEEE Std. 1471-2000: IEEE Recommended Practice for Architecture Description of Software-Intensive Systems)

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. Modelação 2010 André Vasconcelos, Artur Caetano , Helena Pinto, José Borbinha

13. Methodologies and Methodshttp://openlearn.open.ac.uk/mod/resource/view.php?id=257862 • 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. Modelação 2010 André Vasconcelos, Artur Caetano , Helena Pinto, José Borbinha

14. Methodologies and Methodshttp://openlearn.open.ac.uk/mod/resource/view.php?id=257862 • 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. Modelação 2010 André Vasconcelos, Artur Caetano , Helena Pinto, José Borbinha

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-definedproblem to be solved • Scientificapproach 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 Modelação 2010 André Vasconcelos, Artur Caetano , Helena Pinto, José Borbinha

17. Soft systems approaches are relevant at the methodological level

18. “Categoriesof Method”http://www.agiledata.org/essays/differentStrategies.html When the systems is software… • Code and fix… • Serial rigorous… • Iterative rigorous… • Agile… Modelação 2010 André Vasconcelos, Artur Caetano , Helena Pinto, José Borbinha

19. “Categoriesof Method”http://www.agiledata.org/essays/differentStrategies.html • 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.  Modelação 2010 André Vasconcelos, Artur Caetano , Helena Pinto, José Borbinha

20. “Categoriesof Method”http://www.agiledata.org/essays/differentStrategies.html • 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.

21. “Categoriesof Method”http://www.agiledata.org/essays/differentStrategies.html • 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. Modelação 2010 André Vasconcelos, Artur Caetano , Helena Pinto, José Borbinha

22. “Categoriesof Method”http://www.agiledata.org/essays/differentStrategies.html • 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. Modelação 2010 André Vasconcelos, Artur Caetano , Helena Pinto, José Borbinha

23. Methodologies - Basic approaches • Waterfall… • Vee… • Spiral… • … Modelação 2010 André Vasconcelos, Artur Caetano , Helena Pinto, José Borbinha

24. The Waterfall methods

25. The Vee methods

26. SpiralDevelopmentMethods

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

28. CMMI - CapabilityMaturityModelIntegrationhttp://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." Modelação 2010 André Vasconcelos, Artur Caetano , Helena Pinto, José Borbinha

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

30. Examples… Modelação 2010 André Vasconcelos, Artur Caetano , Helena Pinto, José Borbinha

31. From “Survey of Model-Based Systems Engineering (MBSE)” Methodologies http://www.omgsysml.org/MBSE_Methodology_Survey_RevB.pdf When the scope are complex/heterogeneous systems

32. From “Survey of Model-Based Systems Engineering (MBSE)” Methodologies http://www.omgsysml.org/MBSE_Methodology_Survey_RevB.pdf When the scope are (very) complex/heterogeneous systems

33. From “Survey of Model-Based Systems Engineering (MBSE)” Methodologies http://www.omgsysml.org/MBSE_Methodology_Survey_RevB.pdf When the scope are complex/heterogeneous systems

34. From “Survey of Model-Based Systems Engineering (MBSE)” Methodologies http://www.omgsysml.org/MBSE_Methodology_Survey_RevB.pdf When the scope are complex/heterogeneous systems

35. From “Survey of Model-Based Systems Engineering (MBSE)” Methodologies http://www.omgsysml.org/MBSE_Methodology_Survey_RevB.pdf When the scope are complex/heterogeneous systems

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

37. IBM RationalUnifiedProcess (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 Modelação 2010 André Vasconcelos, Artur Caetano , Helena Pinto, José Borbinha

38. IBM RationalUnifiedProcess http://www.ibm.com/developerworks/rational/library/content/RationalEdge/may04/4763_fig2.jpg Modelação 2010 André Vasconcelos, Artur Caetano , Helena Pinto, José Borbinha

39. RUP as an extension of the UML metamodel http://www.ibm.com/developerworks/rational/library/05/323_extrup1/ Modelação 2010 André Vasconcelos, Artur Caetano , Helena Pinto, José Borbinha

40. RUP is a Model-basedprocessengineeringmethodology http://www.ibm.com/developerworks/rational/library/05/323_extrup1/ Modelação 2010 André Vasconcelos, Artur Caetano , Helena Pinto, José Borbinha

41. RUP is a Model-basedprocessengineeringmethodology http://www.ibm.com/developerworks/rational/library/05/323_extrup1/

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…) Modelação 2010 André Vasconcelos, Artur Caetano , Helena Pinto, José Borbinha

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 UMLUse 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. Modelação 2010 André Vasconcelos, Artur Caetano , Helena Pinto, José Borbinha

45. ICONIX

46. Traceabilityin ICONIX Use case Scenarios Use Cases Robustness SequenceDiagrams

47. State of Michigan Systems Engineering Methodology (SEM)http://www.michigan.gov/suite/0,1607,7-245-45409---,00.html When the scope are informationsystemsat a large…

48. State of Michigan Systems Engineering Methodology (SEM) Modelação 2010 André Vasconcelos, Artur Caetano , Helena Pinto, José Borbinha

49. TOGAF - The Open Group Architecture Frameworkhttp://www.opengroup.org/togaf/ When the system is the business and its IT support…

50. TOGAF - ArchitectureDevelopmentMethod (ADM)http://www.opengroup.org/architecture/togaf9-doc/arch/Figures/adm.png