Conceptual Modelling Overview…

1. Modelação Conceptual Modelling Overview… http://www.asktog.com/images/don%27sConceptualModelColor.gif

2. Program Module 1 - Introduction to Systems Modeling Module 2 - Conceptual Modeling – Requirement Engineering Module 3 - Conceptual Modeling – Domain; Structure Modeling Module 4 - Conceptual Modeling – Behavior Module 5 - Conceptual Modeling – Architecture Module 6 – Ontology Module 7 - Conceptual Modeling – Methodologies, Advanced Concepts

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

4. 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)

5. 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)

6. Concerned stakeholders • Viewer– A stakeholder. • Stakeholder – An individual, team, or organization (or classes thereof) with interests in, or concerns relative to, a system. • Concern – A domain of interest. • Domain– A specific area of interest. • Model – An abstract representation of a domain.

7. Models, Methods and Methodologies • Models (which 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…

8. 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

9. Methodologies and Methods • 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. http://openlearn.open.ac.uk/mod/resource/view.php?id=257862

10. 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

11. Soft systems approaches are relevant at the methodological level

12. “Categories of Method” For example, when the systems is logical (software)… • Code and fix… • Serial rigorous… • Iterative rigorous… • Agile… http://www.agiledata.org/essays/differentStrategies.html Modelação 2010 André Vasconcelos, Artur Caetano , Helena Pinto, José Borbinha

13. Methodologies - Basic approaches • Waterfall… • Vee… • Spiral…

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

15. CMMI - CapabilityMaturityModelIntegrationhttp://en.wikipedia.org/wiki/Capability_Maturity_Model_Integration • 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."

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

17. Modelling with UML and SysML

18. UML and SysML

19. SysML – An overview…

20. Requirements Engineering…

21. Requirements and Stakeholders • Requirements • A requirement is a condition or capability to which a system must conform. • A requirement can have an origin from: • A decision or request from a stakeholder • An imposition of a standard, a regulation, etc. • Stakeholders • Anybody involved in the system’s lifecycle (analysis, design, development, maintenance, …) • Anybody else who, directly or indirectly, may impose requirements for the system (business owner, user, …)

22. Context Diagram

23. Requirements Engineering • Requirements engineering is a systematic approach to documenting the requirements of the system. • From “Conceptual Modeling of Information Systems”[Olivé2007]: • “Requirements engineering is the branch of software engineering concerned with the real-world goals for, functions of, and constraints on software systems. It is also concerned with the relationship of these factors to precise specifications of software behavior, and to their evolution over time and across software families”

24. Types of requirements • Functional Requirements (FR) • The specification of a function of the system or its components. • It must refer a behaviour of the system! • Non-Functional Requirements (NFR) • It must refer how the system must behave. • Examples of non-functional requirements: Performance; Scalability; Availability; Reliability; Maintainability; Serviceability; Security; Regulatory; Manageability; Usability; Interoperability In a project, a specific NFR typology depends of the specificities of the nature of the system or sub-system…

25. A General Process for Requirements Engineering • Business objectives • User’s needs • Information about the domain • Information about existing systems • Laws, regulations, standards, … • … Requirements Elicitation Requirements Analysis and Negotiation Requirements Validation Requirements Documenting Requirements Document System’s Specification…

26. A General Process for Requirements Engineering • Business objectives • User’s needs • Information about the domain • Information about existing systems • Laws, regulations, standards, … • … Requirements Elicitation Requirements Analysis and Negotiation Requirements Validation Requirements Documenting Requirements Document Conceptual Modelling System’s Specification…

27. RequirementsElicitation • Requirements elicitation is the process of discovering the requirements for a system by communication with the stakeholders. • This process can employ several techniques: • Questionnaires • Analysis of documents • Interviewing • Joint Application Design workshops • Ethnography • Prototyping • Use Cases • …

28. Good requirements must be (IEEE Std 830): • Correct • Unambiguous • Complete • Consistent • Ranked for importance • Verifiable • Modifiable • Traceable

29. About Requirements Maturity Levels in Organizations or Methodologies (Recalling the CMMI…) • Initial: No process, or chaotic, ad hoc (heroic). • Repeatable: a process exists and is used repeatedly and disciplined (project management) • Defined: the process is defined according to a standard business domain (process institutionalized) • Managed: the process is defined and measurement takes place (quantified) • Optimizing: process management includes deliberate process optimization (process improvement)

30. Requirements in the Enterprise Architect tool… VERY IMPORTANT: Be aware that EA tool supports requirements diagrams as formal SysML Requirements Diagrams or as informal requirements diagrams as extensions to UML

31. Traceability • A fundamental technique in modelling to relate decisions with their origin or implications • Traceability in the Enterprise Architect tool Traceability Diagrams • Relationship Matrix

32. Requirements in SysML Dependency between a requirement and a test case or other model element that can determine whether a system fulfills the requirement. Decomposing a complex requirement into simpler, single requirements… A dependency between a requirement and a model element that fulfills the requirement. To describe how a model element or set of elements can be used to further refine a requirement. A general-purpose relationship between a requirement and any other model element. Dependency between a supplier and a client requirement that specifies that the text of the client requirement is a read-only copy of the text of the supplier requirement. A dependency between two requirements in which a client requirement can be derived from the supplier requirement.

33. Relating requirements with other elements

34. Use Cases …

35. Use Cases • A Use Case represents a set of actions that one or more actors realize in a systems in order to obtain a tangible result. It represents an external view of the system: • Describes what the system does (or part of it) • Doesn’t describe HOW that is realized!!! • A Use Case is usually described by several scenarios (paths): • A scenario is an instance of a use case when it interacts with actors. It represents a concrete sequence of actions that shows the system behavior. • Principal scenario: describes the normal sequence of actions (“happy day scenario”) • Alternative or secondary scenarios: describes a sequence of actions, parallel to the principal, that could happen because of some exception or alternative possible actions

36. «include» and «extend»… «extend» - The base use case can incorporate the behavior in a specific location. The base use case is extended in one or several points, designated by extension points. • «include» - The base use case will incorporate the behavior of the related use case (this avoids rewriting the same sequence of events several times - reusing)

37. Use Case:”template”Example Modelação

38. Object Constraint Language (OCL)

39. Object Constraint Language (OCL) • OCL expressions can be used to specify operations / actions that, tell “what” the system does – but not “how” it is done (that is supposed to be declared by the UML/SysML diagrams themselves…) • OCL is a pure specification language. When an OCL expression is evaluated, it simply returns a value. It cannot change anything in the model. This means that the state of the system will never change because of the evaluation of an OCL expression, even though an OCL expression can be used to specify a state change (e.g., in a post-condition). • OCL expressions can be used in any diagram!!! Modelação

40. Examples of expressions and constraints Account id : Integer saldo: Real = 0 Usual types: Integer, Real, String, Boolean deposit(value : Real) withdraw (value : Real) balance() : Real context Account::withdraw (value : Real) pre: value <= actualValue post: actualValue = actualValue@pre – value context Account::giveActualValue() : Real post: result = actualValue Usual operators: = < > <> <= >= + - * / mod() div() max() min() round() abs() and or xor not implies if_then_else_endif … Modelação

41. Structure

42. System’s Structure and Architecture

43. Packages… A generic mechanism to group modeling elements

44. Structure in UML (1/2)

45. Concepts in UML: Classes • A class is a description of a set of objects that share the same attributes, operations, methods, relationships and semantics. • A class is a description of a set of objects that share the same attributes, operations, methods, relationships and semantics. • A Class can use a set of interfaces to specify collections of operations it provides to its environment. • UML domains are described in class diagrams

47. Structure in SysML

48. Concepts in SysML: Blocks • Blocks are in SysMLmodular units of system description. Each block defines a collection of features to describe a system or other element of interest. These may include both structural and behavioral features, such as properties and operations, to represent the state of the system and behavior that the system may exhibit. • Blocks provide a general-purpose capability to model systems as trees of modular components. The specific kinds of components, the kinds of connections between them, and the way these elements combine to define the total system can all be selected according to the goals of a particular system model. • SysML blocks can be used throughout all phases of system specification and design, and can be applied to many different kinds of systems. These include modeling either the logical or physical decomposition of a system, and the specification of software, hardware, or human elements.

49. bdd – Block Definition Diagram

50. SysML - System’s Structure…