DOCSLIB.ORG

Introduction to Systems Modeling Languages

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

Fundamentals of Systems Engineering Prof. Olivier L. de Weck, Mark Chodas, Narek Shougarian Session 3 System Modeling Languages 1 Reminder: A1 is due today ! 2 3 Overview Why Systems Modeling Languages? Ontology, Semantics and Syntax OPM – Object Process Methodology SySML – Systems Modeling Language Modelica What does it mean for Systems Engineering of today and tomorrow (MBSE)? 4 Exercise: Describe the “Mr. Sticky” System Work with a partner (5 min) Use your webex notepad/white board I will call on you randomly We will compare across student teams © source unknown. All rights reserved. This content is excluded from our Creative Commons license. For more information, see http://ocw.mit.edu/help/faq-fair-use/. 5 Why Systems Modeling Languages? Means for describing artifacts are traditionally as follows: Natural Language (English, French etc….) Graphical (Sketches and Drawings) These then typically get aggregated in “documents” Examples: Requirements Document, Drawing Package Technical Data Package (TDP) should contain all info needed to build and operate system Advantages of allowing an arbitrary description: Familiarity to creator of description Not-confining, promotes creativity Disadvantages of allowing an arbitrary description: Room for ambiguous interpretations and errors Difficult to update if there are changes Handoffs between SE lifecycle phases are discontinuous Uneven level of abstraction Large volume of information that exceeds human cognitive bandwidth Etc…. 6 System Modeling Languages Past efforts to create System Modeling Languages E.g. Bond Graphs (1960), IDEF (1981), etc… Regardless of the System Modeling Language being developed and used they share the common features: Domain agnostic Ontology https://en.wikipedia.org/wiki/Ontology_engineering Defines the entities that are allowed to exist and be described How these entities can be grouped, related to a hierarchy and subdivided Constrains the universe of concepts that can be represented in the language Semantics https://en.wikipedia.org/wiki/Semantics Describes the meaning of the entities allowed by the ontology Relationship between signifiers (e.g. words, symbols …) and their denotation Syntax https://en.wikipedia.org/wiki/Syntax Set of rules, principles and processes that govern the structure of the language and how correct “sentences” can be synthesized 7 Overview Why Systems Modeling Languages? Ontology, Semantics and Syntax OPM – Object Process Methodology SySML – Systems Modeling Language Modelica What does it mean for Systems Engineering of today and tomorrow (MBSE)? 8 Introduction to OPM In order to rigorously architect and design products need a language to describe functions, form, concepts in a consistent way • UML 2.0 • http://www.omg.org/spec/UML/2.0/ • Mainly used for software architecting • SysML 1.3 • http://www.omgsysml.org/ • Generalization to cyber-physical systems • OPM • Object-Process-Methodology • 2002, Prof. Dov Dori, Technion • ISO Standard 19450 (2015, new !) 9 Motivation for OPM Typical Product Need for a Unified Representations Representation Sketches Show functions Engineering Drawings Show function attributes UML Diagrams Show objects (operands, (Software) system components, consumables …) Show object attributes Show links Object Process Methodology is a generic system modeling language that has Example: Refrigerator been successfully applied to Systems Kenmore 2.5 cu ft Architecting of Complex Products © source unknown. All rights reserved. This content is excluded from our Creative Commons license. For more information, see http://ocw.mit.edu/help/faq-fair-use/. 10 Ontology of Object Process Modeling Object: that which has the potential of stable, unconditional existence for some positive Object duration of time. Objects have State states. Form is the sum of objects Process: the pattern of transformation applied to one or Process more objects. Processes change states. Function emerges from processes All links between objects and processes have precise semantics 11 OPM: Goods and Services Goods are objects Services are processes Products With every product good object, there is an implicit process Service Goods process object which is linked to value With every product Implicit Implicit object process service process, there is always an implicit object Product/systems always come in object-process pairs, and value is always linked to process 12 Structural Links in OPM Standby Power System Structural Links Link Objects to Objects AC Unit Is related to … AC Drive PWB “powers” Tagged link (suppressed process) Reset Switch Outlet Decomposes to, aggregates to Inlet Is characterized by, exhibits Main LVPS Specializes to, generalizes to Main Switch Instantiated to, belongs to the class of Outlet PSW 13 Processing Processes Defined: A process is the pattern of transformation applied to one or more objects Cannot hold or touch a process - it is fleeting AC Power Switching Generally creation, change, or destruction resultee object operand (its states are affected by the process) consumee DC Power A process relies on at least one object in the pre- Generating process set A process transforms at least one object in the pre- process set A process takes place along a time line Interlock Status Detecting A process is associated with a verb Express processes in Gerund form: ____ing 14 Process and its Links main switch A process is associated with a verb and stateless There is a family of 7 types of links from process to object A process can change the states of its operand(s) through input and output links Main Switch Operator Here Person Transporting There Main Switch State Transporting changes a Switching person from here to there on off 15 Summary Object-Process Links Here P changes O (from state A to B). Person Transporting There P affects O (affectee) Person Transporting P yields O (resultee) Emissions Transporting P consumes O (consumee) Energy Transporting P is handled by O (agent) Operator Transporting P requires O (instrument) Vehicle Transporting Enough P occurs if O is in state A Money Purchasing None * * conditional link also shown as c 16 High Level OPM of a Car Government Driver Passengers Cargo Regulations Fuel Location Owner A B Emissions Value Safety Automobile Valuing Price Transporting x(1): FC Powertrain Towing x(2): ED Chassis f(3): TC This view shows all main x(3): WT elements of the car as a Propelling x(4): WB product system: f(4): FE -objects x(5): GC Body f(5): AC - operands x(6): HT Housing - instruments f(1): PV x(7): LT - consumees, Wheels f(2): CV resultees x(8): TW - operator x(9): TD -processes -attributes Design Parts and Internal Functional Variables Assemblies Functions Attributes -x: design variables -f: functional behavior 17 Managing Complexity in OPM OPM has three mechanism for managing system complexity: unfolding/folding is used for refining/abstracting the structural hierarchy of an object; in-zooming/out-zooming exposes/hides the inner details of a process within its frame; state expressing/suppressing exposes/hides the states of an object. zooming out-zooming 18 operand “Level 0” owns Food value-related OPM of derives attribute value Refrigerator Shelf Life from Owner 7 days beneficiary primary value Temperature delivering process product system 21oF Refrigerator Extending primary operating Thermostat process super-system Setting Operating Exterior Air Interior o 21 F Air sets sets Temperature operator Waste Operator Electrical Convecting 70oF Heat Power resultee consumee 19 expansion valve Sub-Functions from Carnot Condensing ExpandingCycle Compressing Evaporating Internal Processes are governed by Physics. © source unknown. All rights reserved. This content is excluded from our Creative Commons license. For more information, see http://ocw.mit.edu/help/faq-fair-use/. 20 Refrigerator: Functional Level -1 (4) Decomposition Level -2 (15) Operating Cooling Powering Expanding Grounding Evaporating Protecting Compressing Supplying Condensing Regulating Absorbing Sensing Supporting Switching Opening Setting Closing Retaining Connecting 21 OPM of Refrigerator Level -1 System Boundary Power Compressor Supply Powering Electrical Power Power Internal on off Operand Thermostat Refrigerant Regulating Condenser Freezer Pressure Door Evaporator Cooling Temp Door Temp Supportin Exterior g Waste Air Heat Cabinet Heat Temp Hinge Value Food Interior Operand Convecting Convecting Air Temp 22 Generic System OPM OPMs of most complex opto-mechanical systems look like this Value-Delivering Outputs Beneficiary Power Processes Operand (Customer) Supporting Processes Specialized Processes Powering Value-generating Connecting Attributes Value-Related Controlling Output Operator Non-Value- Added Outputs Raw Inputs 23 How to generate a System OPM Top-Down Start with the stakeholder(s) (customer in mind) Map value delivery process(es) at Level 0 Get to greater levels of detail in layers This is system/product architecting ! Reduce Ambiguity Focus Creativity Manage Complexity Bottom-Up Decompose form of existing product or design (product dissection): Parts List/BOM Generate an initial product decomposition Assign processes to elements of form Complete initial OPM and iterate This is reverse engineering ! 24 OPCAT Demo OPCAT is a Java-based software to generate OPM Models © Dov Dori. All rights reserved. This content is excluded from our Creative Commons license. For more information, see http://ocw.mit.edu/help/faq-fair-use/.
Recommended publications
  • Filling the Gap Between Business Process Modeling and Behavior Driven Development

    Filling the Gap Between Business Process Modeling and Behavior Driven Development

    Filling the Gap between Business Process Modeling and Behavior Driven Development Rogerio Atem de Carvalho Rodrigo Soares Manhães Fernando Luis de Carvalho e Silva Nucleo de Pesquisa em Sistemas de Informação (NSI), Instituto Federal Fluminense (IFF), Brazil {ratem, rmanhaes, [email protected]} 1. Introduction Behavior Driven Development (NORTH, 2006) is a specification technique that is growing in acceptance in the Agile methods communities. BDD allows to securely verify that all functional requirements were treated properly by source code, by connecting the textual description of these requirements to tests. On the other side, the Enterprise Information Systems (EIS) researchers and practitioners defends the use of Business Process Modeling (BPM) to, before defining any part of the system, perform the modeling of the system's underlying business process. Therefore, it can be stated that, in the case of EIS, functional requirements are obtained by identifying Use Cases from the business process models. The aim of this paper is, in a narrower perspective, to propose the use of Finite State Machines (FSM) to model business process and then connect them to the BDD machinery, thus driving better quality for EIS. In a broader perspective, this article aims to provoke a discussion on the mapping of the various BPM notations, since there isn't a real standard for business process modeling (Moller et al., 2007), to BDD. Firstly a historical perspective of the evolution of previous proposals from which this one emerged will be presented, and then the reasons to change from Model Driven Development (MDD) to BDD will be presented also in a historical perspective.
  • Uml.Sty, a Package for Writing UML Diagrams in LATEX

    Uml.Sty, a Package for Writing UML Diagrams in LATEX

    uml.sty, a package for writing UML diagrams in LATEX Ellef Fange Gjelstad March 17, 2010 Contents 1 Syntax for all the commands 5 1.1 Lengths ........................................ 5 1.2 Angles......................................... 5 1.3 Nodenames...................................... 6 1.4 Referencepoints ................................. 6 1.5 Colors ......................................... 6 1.6 Linestyles...................................... 6 2 uml.sty options 6 2.1 debug ......................................... 6 2.2 index.......................................... 6 3 Object-oriented approach 7 3.1 Colors ......................................... 10 3.2 Positions....................................... 10 4 Drawable 12 4.1 Namedoptions .................................... 12 4.1.1 import..................................... 12 5 Element 12 5.1 Namedoptions .................................... 12 5.1.1 Reference ................................... 12 5.1.2 Stereotype................................... 12 5.1.3 Subof ..................................... 13 5.1.4 ImportedFrom ................................ 13 5.1.5 Comment ................................... 13 6 Box 13 6.1 Namedoptionsconcerninglocation . ....... 13 6.2 Boxesintext ..................................... 14 6.3 Named options concerning visual appearance . ......... 14 6.3.1 grayness.................................... 14 6.3.2 border..................................... 14 1 6.3.3 borderLine .................................. 14 6.3.4 innerBorder.................................
  • Development of an Entity Component System Architecture for Realtime Simulation

    Development of an Entity Component System Architecture for Realtime Simulation

    Fachbereich 4: Informatik Development of an Entity Component System Architecture for Realtime Simulation Bachelorarbeit zur Erlangung des Grades Bachelor of Science (B.Sc.) im Studiengang Computervisualistik vorgelegt von Trevor Hollmann Erstgutachter: Prof. Dr.-Ing. Stefan Müller (Institut für Computervisualistik, AG Computergraphik) Zweitgutachter: Kevin Keul, M.Sc. (Institut für Computervisualistik, AG Computergraphik) Koblenz, im September 2019 Erklärung Ich versichere, dass ich die vorliegende Arbeit selbständig verfasst und keine anderen als die angegebenen Quellen und Hilfsmittel benutzt habe. Ja Nein Mit der Einstellung der Arbeit in die Bibliothek bin ich einverstanden. .................................................................................... (Ort, Datum) (Unterschrift) Abstract The development of a game engine is considered a non-trivial problem. [3] The architecture of such simulation software must be able to manage large amounts of simulation objects in real-time while dealing with “crosscutting concerns” [3, p. 36] between subsystems. The use of object oriented paradigms to model simulation objects in class hierar- chies has been reported as incompatible with constantly changing demands dur- ing game development [2, p. 9], resulting in anti-patterns and eventual, messy re-factoring. [13] Alternative architectures using data oriented paradigms re- volving around object composition and aggregation have been proposed as a result. [13, 9, 1, 11] This thesis describes the development of such an architecture with the explicit goals to be simple, inherently compatible with data oriented design, and to make reasoning about performance characteristics possible. Concepts are for- mally defined to help analyze the problem and evaluate results. A functional implementation of the architecture is presented together with use cases common to simulation software. Zusammenfassung Die Entwicklung einer Spiele-Engine wird als nichttriviales Problem betrach- tet.
  • Component Diagrams in UML

    Component Diagrams in UML

    9. UML Component Diagrams Page 1 of 4 Component Diagrams in UML The previous articles covered two of the three primary areas in which the UML diagrams are categorized (see Article 1)—Static and Dynamic. The remaining two UML diagrams that fall under the category of Implementation are the Component and Deployment diagrams. In this article, we will discuss the Component diagram. Basics The different high-level reusable parts of a system are represented in a Component diagram. A component is one such constituent part of a system. In addition to representing the high-level parts, the Component diagram also captures the inter- relationships between these parts. So, how are component diagrams different from the previous UML diagrams that we have seen? The primary difference is that Component diagrams represent the implementation perspective of a system. Hence, components in a Component diagram reflect grouping of the different design elements of a system, for example, classes of the system. Let us briefly understand what criteria to apply to model a component. First and foremost, a component should be substitutable as is. Secondly, a component must provide an interface to enable other components to interact and use the services provided by the component. So, why would not a design element like an interface suffice? An interface provides only the service but not the implementation. Implementation is normally provided by a class that implements the interface. In complex systems, the physical implementation of a defined service is provided by a group of classes rather than a single class. A component is an easy way to represent the grouping together of such implementation classes.
  • Rational Unified Process - an Overview Uppsala, 2009-02-10

    Rational Unified Process - an Overview Uppsala, 2009-02-10

    Rational Unified Process - an overview Uppsala, 2009-02-10 Mikael Broomé Consultant M.Sc. LTH 10 years in Software Development 4 different RUP implementations Project Manager Mentor for Project Managers Applying more and more of agile mindset and techniques E-Mail: [email protected] 2 1 Agenda Why a process for developing software? What is RUP? What is the “RUP-way” of developing software? How is RUP packaged? Advantages by using RUP? Challenges when using RUP? Relation to other processes? 3 A good project delivers the right solution: satisified Users satisfied Sponsor delivers in time delivers on budget 4 2 Challenges Common challenges in software development projects: Capture the “right” requirements. Requirement changes. Different parts of the system do not fit together. Small changes causes big problems. Low quality and poor performance. Major problems identified late in projects. Lack of communication. Difficult to estimate time and cost. Management of environment, platforms and tools. 5 It’s all about (lack of) communication 6 3 Agenda Why a process for developing software? What is RUP? What is the “RUP-way” of developing software? How is RUP packaged? Advantages by using RUP? Challenges when using RUP? Relation to other processes? 7 What is RUP and UML? RUP is a process for development of software that describes what should be performed (activities) who should do it (roles) what the result should be (artifacts). UML is a notation with defined symbols that is worked out by OMG (Object Management Group) is used to make drawings (for example in software development). 8 4 Agenda Why a process for developing software? What is RUP? What is the “RUP-way” of developing software? How is RUP packaged? Advantages by using RUP? Challenges when using RUP? Relation to other processes? 9 JW2 RUP’s Six Best practices 1.
  • Network Visualization with R Katherine Ognyanova, POLNET 2015 Workshop, Portland OR

    Network Visualization with R Katherine Ognyanova, POLNET 2015 Workshop, Portland OR

    Network visualization with R Katherine Ognyanova, www.kateto.net POLNET 2015 Workshop, Portland OR Contents Introduction: Network Visualization2 Data format, size, and preparation4 DATASET 1: edgelist ......................................4 DATASET 2: matrix .......................................5 Network visualization: first steps with igraph 5 A brief detour I: Colors in R plots8 A brief detour II: Fonts in R plots 11 Back to our main plot line: plotting networks 12 Plotting parameters ........................................ 12 Network Layouts ......................................... 17 Highlighting aspects of the network ............................... 24 Highlighting specific nodes or links ............................... 27 Interactive plotting with tkplot ................................. 29 Other ways to represent a network ............................... 30 Plotting two-mode networks with igraph ............................ 31 Quick example using the network package 35 Interactive and animated network visualizations 37 Interactive D3 Networks in R .................................. 37 Simple Plot Animations in R .................................. 38 Interactive networks with ndtv-d3 ................................ 39 Interactive plots of static networks............................ 39 Network evolution animations............................... 40 1 Introduction: Network Visualization The main concern in designing a network visualization is the purpose it has to serve. What are the structural properties that we want to highlight?
  • Affordit!: a Tool for Authoring Object Component Behavior in Virtual

    Affordit!: a Tool for Authoring Object Component Behavior in Virtual

    AffordIt!: A Tool for Authoring Object Component Behavior in Virtual Reality * † ‡ § Sina Masnadi Andres´ N. Vargas Gonzalez´ Brian Williamson Joseph J. LaViola Jr. Department of Computer Science University of Central Florida (a) (b) (c) (d) Figure 1: These figures show a sequence of steps followed to add a rotation affordance to the door of a washer machine. (a) An object in the scenario (b) Cylinder shape selection wrapping the door. (c) A user sets the amount of rotation the door will be constrained to. (d) An animation generated from the affordance can be visualized. ABSTRACT realistic experiences necessary to a VR scene, but not asset creation In this paper we present AffordIt!, a tool for adding affordances (a situation described in Hughes et al. [17]) which are needed to to the component parts of a virtual object. Following 3D scene build a virtual scene. To alleviate this problem, recent research has been focusing on frameworks to ease users’ authoring process as reconstruction and segmentation procedures, users find themselves with complete virtual objects, but no intrinsic behaviors have been seen in [9, 12, 35]. 3D scene reconstruction [32, 34, 44, 49] provides assigned, forcing them to use unfamiliar Desktop-based 3D editing a suitable solution to the problem. Initially a 3D reconstructed tools. AffordIt! offers an intuitive solution that allows a user to environment will be composed of a continuous mesh which can be segmented via autonomous tools as shown in George et al. [10] and select a region of interest for the mesh cutter tool, assign an intrinsic behavior and view an animation preview of their work.
  • Sysml, the Language of MBSE Paul White

    Sysml, the Language of MBSE Paul White

    Welcome to SysML, the Language of MBSE Paul White October 8, 2019 Brief Introduction About Myself • Work Experience • 2015 – Present: KIHOMAC / BAE – Layton, Utah • 2011 – 2015: Astronautics Corporation of America – Milwaukee, Wisconsin • 2001 – 2011: L-3 Communications – Greenville, Texas • 2000 – 2001: Hynix – Eugene, Oregon • 1999 – 2000: Raytheon – Greenville, Texas • Education • 2019: OMG OCSMP Model Builder—Fundamental Certification • 2011: Graduate Certification in Systems Engineering and Architecting – Stevens Institute of Technology • 1999 – 2004: M.S. Computer Science – Texas A&M University at Commerce • 1993 – 1998: B.S. Computer Science – Texas A&M University • INCOSE • Chapters: Wasatch (2015 – Present), Chicagoland (2011 – 2015), North Texas (2007 – 2011) • Conferences: WSRC (2018), GLRCs (2012-2017) • CSEP: (2017 – Present) • 2019 INCOSE Outstanding Service Award • 2019 INCOSE Wasatch -- Most Improved Chapter Award & Gold Circle Award • Utah Engineers Council (UEC) • 2019 & 2018 Engineer of the Year (INCOSE) for Utah Engineers Council (UEC) • Vice Chair • Family • Married 14 years • Three daughters (1, 12, & 10) 2 Introduction 3 Our Topics • Definitions and Expectations • SysML Overview • Basic Features of SysML • Modeling Tools and Techniques • Next Steps 4 What is Model-based Systems Engineering (MBSE)? Model-based systems engineering (MBSE) is “the formalized application of modeling to support system requirements, design, analysis, verification and validation activities beginning in the conceptual design phase and continuing throughout development and later life cycle phases.” -- INCOSE SE Vision 2020 5 What is Model-based Systems Engineering (MBSE)? “Formal systems modeling is standard practice for specifying, analyzing, designing, and verifying systems, and is fully integrated with other engineering models. System models are adapted to the application domain, and include a broad spectrum of models for representing all aspects of systems.
  • Plantuml Language Reference Guide (Version 1.2021.2)

    Plantuml Language Reference Guide (Version 1.2021.2)

    Drawing UML with PlantUML PlantUML Language Reference Guide (Version 1.2021.2) PlantUML is a component that allows to quickly write : • Sequence diagram • Usecase diagram • Class diagram • Object diagram • Activity diagram • Component diagram • Deployment diagram • State diagram • Timing diagram The following non-UML diagrams are also supported: • JSON Data • YAML Data • Network diagram (nwdiag) • Wireframe graphical interface • Archimate diagram • Specification and Description Language (SDL) • Ditaa diagram • Gantt diagram • MindMap diagram • Work Breakdown Structure diagram • Mathematic with AsciiMath or JLaTeXMath notation • Entity Relationship diagram Diagrams are defined using a simple and intuitive language. 1 SEQUENCE DIAGRAM 1 Sequence Diagram 1.1 Basic examples The sequence -> is used to draw a message between two participants. Participants do not have to be explicitly declared. To have a dotted arrow, you use --> It is also possible to use <- and <--. That does not change the drawing, but may improve readability. Note that this is only true for sequence diagrams, rules are different for the other diagrams. @startuml Alice -> Bob: Authentication Request Bob --> Alice: Authentication Response Alice -> Bob: Another authentication Request Alice <-- Bob: Another authentication Response @enduml 1.2 Declaring participant If the keyword participant is used to declare a participant, more control on that participant is possible. The order of declaration will be the (default) order of display. Using these other keywords to declare participants
  • Sysml Distilled: a Brief Guide to the Systems Modeling Language

    Sysml Distilled: a Brief Guide to the Systems Modeling Language

    ptg11539604 Praise for SysML Distilled “In keeping with the outstanding tradition of Addison-Wesley’s techni- cal publications, Lenny Delligatti’s SysML Distilled does not disappoint. Lenny has done a masterful job of capturing the spirit of OMG SysML as a practical, standards-based modeling language to help systems engi- neers address growing system complexity. This book is loaded with matter-of-fact insights, starting with basic MBSE concepts to distin- guishing the subtle differences between use cases and scenarios to illu- mination on namespaces and SysML packages, and even speaks to some of the more esoteric SysML semantics such as token flows.” — Jeff Estefan, Principal Engineer, NASA’s Jet Propulsion Laboratory “The power of a modeling language, such as SysML, is that it facilitates communication not only within systems engineering but across disci- plines and across the development life cycle. Many languages have the ptg11539604 potential to increase communication, but without an effective guide, they can fall short of that objective. In SysML Distilled, Lenny Delligatti combines just the right amount of technology with a common-sense approach to utilizing SysML toward achieving that communication. Having worked in systems and software engineering across many do- mains for the last 30 years, and having taught computer languages, UML, and SysML to many organizations and within the college setting, I find Lenny’s book an invaluable resource. He presents the concepts clearly and provides useful and pragmatic examples to get you off the ground quickly and enables you to be an effective modeler.” — Thomas W. Fargnoli, Lead Member of the Engineering Staff, Lockheed Martin “This book provides an excellent introduction to SysML.
  • UML 2 Activity and Action Models

    UML 2 Activity and Action Models

    JOURNAL OF OBJECT TECHNOLOGY Online at www.jot.fm. Published by ETH Zurich, Chair of Software Engineering ©JOT, 2003 Vol. 2, No. 4, July-August 2003 UML 2 Activity and Action Models Conrad Bock, National Institute of Standards and Technology This is the first in a series introducing the activity model in the Unified Modeling Language, version 2 (UML 2), and how it integrates with the action model [1]. The series is a companion to the standard, providing additional background, rationale, examples, and introducing concepts in a logical order. This article covers motivation and architecture for the new models, basic aspects of UML 2 activities and actions, and introduces the general notion of behavior in UML 2. 1 BACKGROUND A focus of recent developments in UML has been on procedures and processes. UML 1.5 introduced a model for parameterized procedures defined by control and data flow to complement the existing state and interaction models [2]. For the first time UML supports first-class procedures that can be used as methods on objects or independently of objects, as occurs when modeling, for example, function libraries with popular programming languages. It also facilitates application of UML by modelers who do not use object-orientation (OO) routinely, such as system engineers and enterprise modelers, and provides them a path to incrementally adopt OO as needed [3]. The flexibility to combine OO with functional approaches considerably widens and integrates the potential applications of UML. UML 1.1 UML 1.3 UML 1.5 UML 2.0 1997 1999 2001 2003 Figure 1: UML Timeline UML 1.5 also inherited from earlier versions a form of state machine that was notationally modified to appear as a flow diagram, called the activity diagram.
  • Introduction OMG Systems Modeling Language (OMG Sysml™) and OOSEM Tutorial by Abe Meilich, Ph.D

    Introduction OMG Systems Modeling Language (OMG Sysml™) and OOSEM Tutorial by Abe Meilich, Ph.D

    Introduction OMG Systems Modeling Language (OMG SysML™) and OOSEM Tutorial By Abe Meilich, Ph.D. [email protected] Acknowledged National Defense Industrial Association Original Authors: 9th Annual Systems Engineering Conference Sanford Friedenthal San Diego, CA Alan Moore October 23, 2006 Rick Steiner Copyright © 2006 by Object Management Group. Published and used by INCOSE and affiliated societies with permission. Caveat • These materials have been modified slightly from the original Tutorial given at INCOSE 2006 – Softcopy of Full Tutorial available at : http://www.omgsysml.org/SysML-Tutorial-Baseline-to-INCOSE- 060524-low_res.pdf • This material is based on version 1.0 of the SysML specification (ad-06-03-01) – Adopted by OMG in May ’06 – Going through finalization process • OMG SysML Website – http://www.omgsysml.org/ 11 July 2006 Copyright © 2006 by Object Management Group. 2 Objectives & Intended Audience At the end of this tutorial, you should understand the: • Benefits of model driven approaches to systems engineering • Types of SysML diagrams and their basic constructs • Cross-cutting principles for relating elements across diagrams • Relationship between SysML and other Standards • Introduction to principles of a OO System Engineering Method This course is not intended to make you a systems modeler! You must use the language. Intended Audience: • Practicing Systems Engineers interested in system modeling – Already familiar with system modeling & tools, or – Want to learn about systems modeling • Software Engineers who want to express systems concepts • Familiarity with UML is not required, but it will help 11 July 2006 Copyright © 2006 by Object Management Group. 3 Topics • Motivation & Background • Diagram Overview • SysML Modeling as Part of SE Process • OOSEM – Enhanced Security System Example • SysML in a Standards Framework • Transitioning to SysML • Summary 11 July 2006 Copyright © 2006 by Object Management Group.