1 / 42

Model Based Methods for Systems Engineering

Model Based Methods for Systems Engineering. Presentation to SC SPIN 24 September 2009 Professor C.E. Dickerson. Vertical Industry Architecture. Horizontal Industry Structure. The Vertical Computer Industry – Circa 1980. The Horizontal Computer Industry – Circa 1996. Sales and distribution.

eron
Télécharger la présentation

Model Based Methods for Systems Engineering

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Model Based Methods for Systems Engineering Presentation to SC SPIN 24 September 2009 Professor C.E. Dickerson

  2. Vertical Industry Architecture Horizontal Industry Structure The Vertical Computer Industry – Circa 1980 The Horizontal Computer Industry – Circa 1996 Sales and distribution Sales and distribution Retail Stores Superstores Dealers Dealers Application software Application software Word Perfect Word Etc. Operating system Operating system UNIX DOS and Windows OS2 MAC Computer Computer Compaq Dell Packard Bell IBM Etc. Chips Chips Intel Architecture Motorola RISCs IBM DEC Wang Sperry Univac Computer Business Architecture* Evolution: 1980 - 2000 Will Systems Engineering undergo these types of changes? *Source: Dr. James C. Stoffel, INCOSE Keynote Address, 12 July 2005: “Systems Engineering-An Imperative for Economic Growth” Dr. Stoffel proprietary material; used with permission.

  3. Agenda • Modeling Languages • UML • SysML • A Quick Look at Systems Engineering • Model Driven Architecture (MDA) • MDA for Systems Engineering

  4. Use case Class Packages Object Sequence Collaboration State Chart Activity Component Deployment Key Types of UML Diagramsfor Modelling Systems This module of the course will focus on the left hand five types of diagrams.

  5. Use Case Diagrams • Show the interactions between a system and the users or other external systems. • The emphasis is on what the system does rather than how it does it. • The viewpoint is that of an external observer. • Use case diagrams should not be confused with scenarios which are examples of interactions but • The collection of scenarios for a use case may suggest a suite of test cases. • Use cases are part of requirements engineering. • Any aspect of system behaviour that provides a measurable result should be captured in a use case. • They should be a means of communication.

  6. Information Management System Create New Account System Administrator Description of Use Case Diagrams Graphical Elements Use cases (Ovals) Actors (Stick figures) Communication (Lines) Boundary (Rectangle)

  7. Class Diagrams • Correspond to system definition by showing its classes, which become system objects, and their relationships. • The emphasis is on what interacts rather than what happens in the interaction. • The viewpoint is internal to the system.

  8. Relationships in Class Diagrams • There are three types of class relationships • Association: a relationship between instances (objects) of two classes, a reference to an object in the form on an attribute • Aggregation: a stronger form of association in which one class owns but may share a collection of objects of another class • Generalization: an inheritance relationship indicating that a class is a type of (i.e. inherits properties from) a superclass • A class integrates attributes and behaviours.

  9. Information Management System Create New Account System Administrator Account AcctEntry 1 * creation date URL a method a method Description of Class Diagram Use Case Graphical Elements Class (Rectangle) Name Attributes Methods Association (Line) Aggregation (Diamond, Line) Generalization (Triangle) Multiplicity (0,1, 1.. n, 1.. *, *) Class Diagram

  10. Abstract Classes • Are partial declarations of a class, omitting behaviour that may be realized in another class • Can be used in generalization to create a generic reusable class that for which all the behaviours cannot be implemented • Were used in the logical modelling of sentences • The graphic may omit attributes and behaviours

  11. Package Diagrams • Are groupings of classes (called packages) that provide structure or organization to the system model • The emphasis is on organization of and dependencies between the packages. • A dependency between two classes is a declaration that one class needs to know about another class in order to use its objects. • The dependency relationship is weaker than association • Packages can be defined on the basis of logical relationships, subject matter, or responsibilities.

  12. Information Management System Create New Account Account Management System Administrator AcctEntry Security Account Credentials IDVerifier Description of Package Use Case Graphical Elements Package ( Tabbed Rectangle) Name Classes Contained Dependency (Dashed Arrow) Hierarchy (Nested; or ::) Package Diagram

  13. entry AcctEntry entry: AcctEntry URL a method Object Diagrams • Objects are instances of Classes • Classes are blueprints for objects. • Notation is similar to classes • Object names are underlined • Colons are used in association with the instantiated class Objects (are) instances of a Class

  14. Sequence Diagrams • Unlike the static views presented by class and object diagrams, interaction diagrams are dynamic views that show how objects collaborate by means of interactions. • A sequence diagram is an interaction diagram that shows • The details of how operations are carried out • What messages are sent and when • The emphasis is on the order of interactions between parts of the system. • It should not be confused with timing.

  15. Use Case Information Management System : Information Management System Create New Account admin: Administrator Request new account System Administrator Select account type Enter author details Reply Description of Sequence Diagrams Graphical Elements Participants* (Rectangles) Time (Dashed line, down) Activation (Thin Rectangles) Events (Annotated Arrow) *These are the parts of the system and often are represented as objects.

  16. Systems Modelling Language (SysML) • What is SysML? • A visual (graphical) modelling language that extends UML • It provides semantics and notation for systems engineering • SysML supports • The specification, analysis, design, verification and validation of systems that include hardware, software, data, parametrics, personnel, procedures, and facilities • Model and data interchange via the XMI and AP233 • SysML is being implemented in tools provided by the major and smaller vendors (IBM, Telelogic, No Magic, Sparx …) • And is part of the OMG UPDM* specification *the UML Profile for the DoDAF and MODAF architecture frameworks

  17. Relation of UML and SysML Source: the OMG SysML Resource Page, 11 February 2008

  18. SysML Diagram Types Source: the OMG SysML Resource Page, 11 February 2008

  19. The Four Pillars of SysML Source: the OMG SysML Resource Page, 11 February 2008

  20. Agenda • Modeling Languages • UML • SysML • A Quick Look at Systems Engineering • Model Driven Architecture (MDA) • MDA for Systems Engineering

  21. Definitions of Systems Engineering • An interdisciplinary approach encompassing the entire technical effort to evolve and verify an Integrated and life-cycle balanced set of system people, product and process solutions that satisfy customer needs. Systems engineering encompasses: • The technical efforts related to the development, manufacturing, verification, deployment, operations, support, disposal of, and user training for, system products and processes; • The definition and management of the system configuration; • The translation of the system definition into work breakdown structures; and • The development of information for management decision making. (EIA/IS-632-1994)

  22. Definitions of Systems Engineering • An interdisciplinary collaborative approach to derive, evolve, and verify a life cycle balanced system solution that satisfies customer expectations and meets public acceptability. (IEEE 1220-1994) • No definition: • ANSI/EIC-632-1998 • IEEE 1220-1998 and IEEE 1220-2005 • ISO/IEC 15288

  23. User requirements, System concept, Validation plan Validation Validate System to User Requirements System Specification an Verification plan Verification Integrate System and Verify to Specification Configuration Item Specification and Verification plan Verification Assemble CIs and Verify to Specification “Built-To” Specification and Verification Procedures Verification Inspect/Test to “Build-To” Specification Integration and Verification Decomposition and Definition Fabricate, Assemble, Code Forsberg and Mooz "v" model. The “V” Model

  24. Agenda • Modeling Languages • UML • SysML • A Quick Look at Systems Engineering • Model Driven Architecture (MDA) • MDA for Systems Engineering

  25. The Promise of the OMG MDA* *OMG MDA Guide V1.0.1, 12th June 2003. • Implementation • Integrate, target new infrastructure by existing designs • Integration • Automate production of data integration bridges • Maintenance • Design becomes available in machine readable form • Testing and simulation • Models can be used to generate code to validate requirements, test infrastructure, simulate behaviour To allow definition of machine readable application and data models which allow long term flexibility of:

  26. OMG Background • OMG (Object Management Group) has been an international, open membership, not-for-profit computer industry consortium since 1989. • OMG’s current standards include: • UML - Unified Modelling Language, a standardised specification language for object modelling • SysML - Systems Modelling Language, a general-purpose graphical modelling language for specifying, analyzing, designing, and verifying complex systems. • MOF – Meta Object Facility, is a standard for model-driven engineering, is the mandatory modelling foundation for MDA. • MDA - Model Driven Architecture, an approach to using models in software development

  27. What is MDA? • A significant paradigm shift in software engineering • A move from Object Management Architecture to Models • A trade marked term from the Object Management Group (OMG), MDA was initiated in late 2000 and has been public since 2001 http://www.omg.org/http://www.omg.org/mda/ • MDA provides an open, vendor neutral approach to the challenge of business and technology change. • Separates business and application logic from underlying platform technology; insulates the core of the application

  28. Level of Effort ($) Region of Cost Savings Program Phase Maintain Test Deploy Requirements Implementation Analysis/Design MDA Cost Savings over Program LifeCodagen Testimonial to OMG Codagen Testimonial on Development Costs for CGI Program: w/o MDA $8.073M with MDA $5.475M Savings $2.598M (32%)

  29. OMG Concept of MDA • MDA is an approach to system development.* • In MDA, model of a system is a description or specification of that system and its environment for some certain purpose. • The MDA approach is model-driven because it provides a means for using models to direct the course of understanding, design, construction, development, operation, maintenance, and modification [of a system]. *In the MDA Guide V1.0.1, the discussion focuses mostly on system software.

  30. MDA Terminology: System Architecture • The architecture* of a system is a specification of the parts and connectors of the system and the rules for the interactions of the parts using the connectors. • The Model-Driven Architecture prescribes certain kinds of models to be used and • How those models may be prepared and • The relationships of the different kind of models • The Model-Driven Architecture specifies three viewpoints on a system. *The definition in the MDA Guide V1.0.1 is based on Shaw and Garland, Software Architecture.

  31. MDA Terminology: View and Viewpoint • A viewpoint on a system is a technique for abstraction using a selected set of • Architectural concepts and structuring rules • To focus on particular concerns within that system. • The term abstraction is used to mean the process of suppressing selected detail to establish a simplified model. • A viewpoint model or view* of a system is a representation of that system from the perspective of a particular viewpoint. *The definition in the MDA Guide V1.0.1 is based on IEEE 1471.

  32. MDA Terminology: Platform, Independence • A platform is a set of subsystems and technologies that provide a coherent set of functionality through interfaces and specified usage patterns*. • Platform independence is a quality that a model may exhibit, where the model is independent of the features of the platform. *The definition in the MDA Guide V1.0.1 goes on to require that any application supported by the program can use [the subsystems and technologies] without concern for the details of how the functionality provided by the platform is implemented .

  33. MDA Terminology: Viewpoints • Computational Independent Viewpoint • Focuses on the environment of the system and requirements for the system • The details of the structure and processing of the system are hidden or as yet undetermined. • Platform Independent Viewpoint • Focuses on the operation of a system while hiding the details necessary for a particular platform. • Shows that part of the complete specification that does not change from one platform to another. • Platform Specific Viewpoint • Combines the platform independent viewpoint with an additional focus on the detail of the use of a specific platform.

  34. MDA Terminology: Views (Models) • Computational Independent Model (CIM) • A view of the system from the computation independent viewpoint. • Does not show details of the structure of the system. • Platform Independent Model (PIM) • A view of the system from the platform independent viewpoint. • Exhibits a specified degree of platform independence so as to be useful for use with a number of different platforms of similar type. • Platform Specific Model (PSM) • A view of the system from the platform specific viewpoint. • Combines the specifications of the PIM with the details that specify how that system uses a particular type of platform.

  35. Terminology: System Specification • Platform Model (PM) • A set of technical concepts, representing the different kinds of parts that make up a platform and the services provided by that platform. • Also specifies requirements on the connection and use of the parts of the platform, and the connections of an application to the platform. • A generic platform model can amount to the specification of a particular architectural style. • Implementation • A specification which provides all the information needed to construct a system and to put in into operation.

  36. Model Transformation • Model transformation is the process of converting one model to another model of the same system. • An MDA mapping provides specifications for transformation of a PIM into a PSM for a particular platform. • The platform model will determine the nature of the mapping. • Model transformation can be thought of as part of the design and development process. *See for example Model Driven Architecture with Executable UML, Raistrick et al..

  37. System Design and Model Transforms • System design relates to • How one parametric model of a system • Is transformed into another model • Model transformation • Is a mapping of parameters that at a minimum should • Preserve relationships between parameters • Matrix representations of relational transforms • Have precise mathematical formulations that act on the • Cells in the square matrix of parametric relationships

  38. Model Transforms in System Design N Q M

  39. Mathematical Notation for Models • The matrix of a model will be designated as M (or other underlined capital letter) • M = {y1, … ym} denotes the parameters of M • R = {(yi , yj ): i, j = 1, …, mR} is a relation on M • The relationship (yi , yj ) in R is denoted yiRyj • A Relational Model Transformation Q is a mapping of • M = {y1, … ym} to N = {x1, … xn} such that • If yiRyj and yjQxk and yjQxl then xkSxl , where • S is the relation on N (induced by Q) • Q maps relationships in M to relationships in N

  40. Agenda • Modeling Languages • UML • SysML • A Quick Look at Systems Engineering • Model Driven Architecture (MDA) • MDA for Systems Engineering

  41. Validation Acceptance Tests Use Cases, Operational Mission Threads CIM: Requirements Analysis, System Concept Definition Verification Integrate System and Test to Specification Model Transformation, Open Sequence Diagrams PIM: System Specification Verification Assemble Components, Test to Specification PSM: Architecture Analysis, Component Specification Package Diagrams, Component Sequence Diagrams Inspect/Test to “Build-To” Specification PM: “Build-To” Specification, Verification Procedures Verification Integration and Test Analysis and Specification Implementation: Procure, Fabricate, Code, Assemble Adapted from Forsberg and Mooz "vee" model. MDA adapted to the systems engineering V

  42. Summary • Systems Engineering is in a time of change • UML and SysML are a strong influence • Model based approaches are emerging • SysML based MBSE is rapidly evolving • Model Driven Architecture offers agility • Model transformation as system design • Advances in model transformation formalism • Adaptation of MDA to Systems Engineering • MDA for Systems Engineering and MBSE are promising approaches for the future

More Related