DOCSLIB.ORG

Verification of UML State Diagrams Using a Model Checker

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Verification of UML State Diagrams Using a Model Checker Verification of UML State Diagrams using a Model Checker A Manuscript Submitted to the Department of Computer Science and the Faculty of the University of Wisconsin-La Crosse La Crosse, Wisconsin by Yiwei Zou in Partial Fulfillment of the Requirements for the Degree of Master of Software Engineering August, 2013 Verification of UML State Diagrams using a Model Checker By Yiwei Zou We recommend acceptance of this manuscript in partial fulfillment of this candidates re- quirements for the degree of Master of Software Engineering in Computer Science. The candidate has completed the oral examination requirement of the capstone project for the degree. Dr.Kasi Periyasamy Date Examination Committee Chairperson Dr.Mao Zheng Date Examination Committee Member Dr.Tom Gendreau Date Examination Committee Member ii Abstract Zou, Yiwei, Verification of UML State Diagrams using a Model Checker, Master of Software Engineering, August 2013. (Advisor: Kasi Periyasamy, Ph.D). This manuscript describes the process of verifying the UML state diagrams by using model checker. A UML state diagram describes the behavior of an object which includes a sequence of states that the object visits during its lifetime. Verification of UML state dia- gram is important because if one state diagram is incorrect, the object’s behavior will not be displayed correctly which leads to incorrect coding and eventually may lead to the possible failure of the system. However, it is hard to verify UML state diagram without the aid of other tools. Therefore, model checker is introduced to verify the UML state diagram. Since model checkers use different syntax, one needs to convert state diagrams from UML tools to the syntax used by the model checker. Moerover, model checkers also use temporal logic experssions for verification which need to be added to the information in the state diagram for verification purposes. This manuscript describes the design and implementation of a conversion tool that converts UML state diagrams drawn using Visual Paradigm to the syn- tax used by UPPAAL model checker. The tool was tested with several UML state diagrams. iii Acknowledgements I would like to express my sincere thanks to my project advisor Dr. Kasi Periyasamy for initiating this project and providing his valuable guidance. I would also like to express my appreciation to the Department of Computer Science at the University of Wisconsin-La Crosse for providing the learning materials and computing environment for my project. iv Contents 1 Introduction 1 1.1 UML State Diagram . 1 1.2 Model Checker . 3 2 Current Project 5 2.1 Overview . 5 2.2 UML Tool . 5 2.3 Model Checking Tool . 6 3 Converting Tool 7 3.1 Development Approach . 7 3.2 Convert Function . 9 3.3 User Interface . 12 3.3.1 Main Window . 12 3.3.2 Additional Information Window . 15 4 Verification 17 4.1 Simulator . 17 4.2 Verifier . 20 4.3 Verify Command . 22 4.3.1 Reachability Properties . 22 4.3.2 Safety Properties . 23 4.3.3 Liveness Properties . 24 4.3.4 Deadlock Properties . 26 5 Case Study 26 5.1 Coffee Machine . 26 5.1.1 Convert . 26 5.1.2 Verify . 28 6 Future Work 30 7 Conclusion 32 8 References 33 9 Appendix 34 9.1 CD Player . 34 9.2 Coffee Machine . 35 9.3 Cruise Controller . 36 9.4 ATM Machine . 37 9.5 Traffic Light . 38 v List of Figures 1 A template of a UML state diagram . 2 2 A finite-state system . 4 3 The simulator on a finite-state system . 4 4 The temporal logical formula to verify the finite-state system . 5 5 Overview of the project . 6 6 UPPAAL Sample . 7 7 Visual Paradigm XML file . 10 8 UPPAAL XML file . 10 9 Main Window . 14 10 Additional Information Window . 16 11 Simulator Example . 18 12 Simulator Trace Example . 19 13 Simulator Trace Example . 20 14 Exist Eventually . 23 15 Exist Globally . 24 16 Always Globally . 24 17 Always Eventually . 25 18 Always Leads To . 25 19 Coffee Machine State Machine Diagram . 27 20 Coffee Machine Convert . 28 21 Coffee Machine In UPPAAL . 29 22 Coffee Machine Verify Queries . 29 23 CD Player state diagram . 34 24 CD Player finite-state system . 34 25 Coffee Machine state diagram . 35 26 Coffee Machine finite-state system . 35 27 Cruise Controller state diagram . 36 28 Cruise Controller finite-state system . 36 29 ATM Machine state diagram . 37 30 ATM Machine finite-state system . 37 31 Traffic Light state diagram . 38 32 Traffic Light Left Lane state diagram . 38 33 Traffic Light finite-state system . 39 34 Traffic Light Left Lane finite-state system . 39 vi GLOSSARY UML Unified Modeling Language - A standardized, general-purpose modeling language in the field of software engineering. Temporal Logic Any system of rules and symbolism for representing, and reasoning about, propositions qualified in terms of time. DOM Document Object Model - A cross-platform and language-independent convention for representing and interacting with objects in HTML, XML and XHTML documents. Finite-state System A mathematical model of computation used to design both computer programs and sequential logic circuits. vii 1 Introduction 1.1 UML State Diagram The UML state diagram displays the behavior of an object which specifies the sequence of states the object visits during its lifetime in response to events, together with its responses to those events. [1] The elements a UML state diagram contains are listed below: • State: A state is a condition during the life of an object. When an object is in a particular state, it satisfies some condition, performs some activity, or waits for some external event. • Transition: A transition is a relationship between two states indicating that an object in the first state will, when a specified set of events and conditions are satisfied, perform certain actions and enter the second state. Mostly, a transition has a source state, an event trigger, an action and a target state as components. A UML state diagram is a mixture of graphical and textual representation that precisely captures both the state topology and its actions. It is strongly connected to other UML diagrams since it gives users a more specific view of the behavior of an instance of one particular class in the class digram. However, a UML state diagram is not completely descriptive. Any complex diagram requires a large amount of textual information like the specification of actions and guards. Moreover, the UML state diagram is meant for design purposes and the semantics of application is not easy to observe from the diagram. A sample UML state diagram is shown in figure 1. The diagram displays the behavior of a CD player. There is one vital error in the diagram. There is no transaction from the 1 Figure 1: A template of a UML state diagram state “CDStopped” to the state “CDPlaying” which indicates that there is no way for the CD player to move from stop to play.However, it takes time for users to verify the diagram just by looking at it. Moreover, there could still be hidden error even if the user checks the diagram carefully. This diagram includes only five simple states. The problem would be much more complex if the number of states increases or complex state diagrams are used. Embedding verification techniques in UML may solve the problems. However, UML is meant as a design notation that already has a vast number of design notations. Moreover, design and verification are usually performed separately. Therefore, it is preferable to take UML design diagram as an input to some verifier and then verify the design. 2 1.2 Model Checker In computer science, model checking refers to the following problem: Given a model of a system, exhaustively and automatically check whether this model meets a given spec- ification. Typically, the specification contains several requirements such as the absence of deadlocks and critical states that could cause the system to crash. Model checking, therefore, is a technique that can automatically verify correctness properties of finite-state systems. [2] Model checking technology arguably ranges among the foremost applications of logic to computer science and computer engineering. In the twenty-five years since its invention, model checking has achieved multiple breakthroughs, bridging the gap between theoretical computer science, hardware and software engineering. Today, model checking is exten- sively used in the hardware industry, and has become feasible for verifying many types of software as well. Model checking has been introduced into computer science curricula at universities worldwide, and virtually has become a universal tool for the analysis of sys- tems. [6] The finite-state system of the CD player in the previous section is shown in figure 2. The finite-state system is similar to the UML state diagram. However, it has some additional information for the guards and synchronizations to actually run the finite-state system. Model checkers have two ways to verify the finite-state system. One way is to use a simulator to track the behavior of the object, as shown in figure 3. The other is using a verifier. By typing in the specification as a temporal logical formula, the verifier will ex- hausively go into all reachable states to verify whether the system meets the specification. The example temporal logical formula is shown in figure 4. 3 Both the simulator and verifier will be discussed later in this manuscript. Figure 2: A finite-state system Figure 3: The simulator on a finite-state system 4 Figure 4: The temporal logical formula to verify the finite-state system 2 Current Project 2.1 Overview The UML state diagram is a great way to view the behavior of an object in a complex system.
Load more

Recommended publications
  • Xtuml: Current and Next State of a Modeling Dialect
    xtUML: Current and Next State of a Modeling Dialect Cortland Starrett [email protected] 2 Outline • Introduc)on • Background • Brief History • Key Players • Current State • Related Modeling Dialects • Next State • Conclusion [email protected] 3 Introduc)on [email protected] 4 Background • Shlaer-Mellor Method (xtUML) – subject maers, separaon of concerns – data, control, processing – BridgePoint • data modeling (Object Oriented Analysis (OOA)) • state machines • ac)on language • interpre)ve execu)on • model compilaon [email protected] 5 History • 1988, 1991 Shlaer-Mellor Method published by Stephen Mellor and Sally Shlaer. • 2002 Executable UML established as Shlaer-Mellor OOA using UML notation. • 2004 Commercial Corporate Proprietary Licensed. • 2013 BridgePoint xtUML Editor goes open source under Apache 2.0. • 2014 all of BridgePoint (including Verifier and model compilers) goes open source under Apache and Creative Commons. • 2015 Papyrus Industry Consortium and xtUML/BridgePoint contribution • 2015 OSS of alternate generator engine (community building) • 2016 Papyrus-xtUML (BridgePoint) Eclipse Foundation governance • 2016 OSS contributions from industry, university and individuals [email protected] 6 Key Players • Saab • UK Crown • Agilent • Ericsson • Fuji-Xerox • Academia [email protected] 7 Current State • body of IP • self-hosng • Papyrus (and Papyrus Industry Consor)um) [email protected] 8 Related Dialects • MASL • Alf • UML-RT [email protected]
    [Show full text]
  • VI. the Unified Modeling Language UML Diagrams
    Conceptual Modeling CSC2507 VI. The Unified Modeling Language Use Case Diagrams Class Diagrams Attributes, Operations and ConstraintsConstraints Generalization and Aggregation Sequence and Collaboration Diagrams State and Activity Diagrams 2004 John Mylopoulos UML -- 1 Conceptual Modeling CSC2507 UML Diagrams I UML was conceived as a language for modeling software. Since this includes requirements, UML supports world modeling (...at least to some extend). I UML offers a variety of diagrammatic notations for modeling static and dynamic aspects of an application. I The list of notations includes use case diagrams, class diagrams, interaction diagrams -- describe sequences of events, package diagrams, activity diagrams, state diagrams, …more... 2004 John Mylopoulos UML -- 2 Conceptual Modeling CSC2507 Use Case Diagrams I A use case [Jacobson92] represents “typical use scenaria” for an object being modeled. I Modeling objects in terms of use cases is consistent with Cognitive Science theories which claim that every object has obvious suggestive uses (or affordances) because of its shape or other properties. For example, Glass is for looking through (...or breaking) Cardboard is for writing on... Radio buttons are for pushing or turning… Icons are for clicking… Door handles are for pulling, bars are for pushing… I Use cases offer a notation for building a coarse-grain, first sketch model of an object, or a process. 2004 John Mylopoulos UML -- 3 Conceptual Modeling CSC2507 Use Cases for a Meeting Scheduling System Initiator Participant
    [Show full text]
  • A Dynamic Analysis Tool for Textually Modeled State Machines Using Umple
    UmpleRun: a Dynamic Analysis Tool for Textually Modeled State Machines using Umple Hamoud Aljamaan, Timothy Lethbridge, Miguel Garzón, Andrew Forward School of Electrical Engineering and Computer Science University of Ottawa Ottawa, Canada [email protected], [email protected], [email protected], [email protected] Lethbridge.book Page 299 Tuesday, November 16, 2004 12:22 PM Abstract— In this paper, we present a tool named UmpleRun 4 demonstrates the tool usage. Subsequent sections walk that allows modelers to run the textually specified state machines through an example of instrumenting our example system and under analysis with an execution scenario to validate the model's performing dynamic analysis. dynamic behavior. In addition, trace specification will output Section 8.2 State diagrams 299 execution traces that contain model construct links. This will permit analysis of behavior at the model level. II. EXAMPLE CAR TRANSMISSION MODEL TO BE EXECUTED In this section, we will present the car transmission model Keywords— UmpleRun; Umple; UML; MOTL; stateNested machine; substates that and will guard be conditions our motivating example through this paper. It will execution trace; analysis Aalso state be diagram used to can explain be nested Umple inside and a state.MOTL The syntax. states of The the innerCar diagram are calledtransmission substates model. was inspired by a similar model in I. INTRODUCTION LethbridgeFigure 8.18 and shows Lagani a stateère’s diagram book [4] of. anThe automatic model consists transmission; of at the top one class with car transmission behavior captured by the state Umple [1,2] is a model-oriented programming language level this has three states: ‘Neutral’, ‘Reverse’ and a driving state, which is not machine shown in Fig.
    [Show full text]
  • State and Activity Diagrams in UML Last Revised December 4, 2018 Objectives: 1
    CPS122 Lecture: State and Activity Diagrams in UML last revised December 4, 2018 Objectives: 1. To show how to create and read State Diagrams 2. To introduce UML Activity Diagrams Materials: 1. Answers to quick check questions from chapter 7 plus chapter 8 a, b, g 2. Demonstration of “Racers” program 3. Handout and Projectable on Web: State diagram for Session 4. Handout: Code for Session class performSession() method 5. Projectable of text figures 7.12, 7.13 6. Handout of Activity diagram for Racers 7. Projectable of text figure 8.10 I. Introduction A.Go over quick check questions chapter 7 + chapter 8 a, b, g only B. We have drawn a distinction between the static aspects of a system and its dynamic aspects. The static aspects of a system have to do with its component parts and how they are related to one another; the dynamic aspects of a system have to do with how the components interact with one another and/or change state internally over time. C. We have been looking at one aspect of the dynamic behavior of a system - the way various objects interact to carry out the various use cases. We have looked at two ways of describing this: 1. Sequence diagrams 2. Communication diagrams D.We now want to look two additional aspects of dynamic behavior !1 1. How an individual object changes state internally over time. a) Example: As part of doing the domain analysis of a traffic light system, it is important to note that individual signals go through a series of states in a prescribed order - modeled by the following state diagram: ! (Note: this is correct for the US but not for all countries in the world!) An important “business rule” that any traffic light system must obey is that the light must be yellow for a certain minimum period of time (related to vehicle speed in the intersection) between displaying green and displaying red.
    [Show full text]
  • Part I Environmental Diagrams
    Adaptive Software Engineering G22.3033-007 Session 3 – Sub-Topic Presentation 1 Use Case Modeling Dr. Jean-Claude Franchitti New York University Computer Science Department Courant Institute of Mathematical Sciences 1 Part I Environmental Diagrams 2 1 What it is • Environmental Diagram Rent Video Video Store Pay Information System Employees Clerk Customer Payroll Clerk 3 What it is • A picture containing all the important players (Actors) • Includes players both inside and outside of the system • Actors are a critical component • External events are a second critical component 4 2 Creating the Diagram • To create an environmental diagram • 1. Identify all the initiating actors • 2. Identify all the related external events associated with each actor 5 Why it is used • A diagram is needed to show the context or scope of the proposed system • At this time actors and external events are the critical components • It is helpful to include all the participants as well 6 3 Creating the Diagram • 3. Identify all the participating Actors • These actors may be inside (internal) or outside (external) to the system 7 Creating the Diagram • Examples of an internal actor – Clerk who enters the purchase into a Point of Sale terminal – Clerk who places paper in the printer – Accountant who audits report 8 4 Creating the Diagram • Examples of an external actor – Accountant who audits report – A credit authorizing service – A DMV check for renting a car 9 Creating the Diagram •4.Draw a cloud • 5. Then draw initiating actors on the left of the cloud • 6. Then draw participating external actors outside the cloud • 7.
    [Show full text]
  • Mastering the Unified Modeling Language -- State Transition Diagrams
    Mastering the Unified Modeling Language -- State Transition Diagrams -- © Josef Schiefer, IBM Watson Outline nested state diagrams States & Transitions Combinatorial Explosion concurrent state machines Solution: Statecharts Statecharts messages ... UML State Diagrams 12/7/2000 - v2 states Stubbed Transitions transitions Synchronization events Concurrency vs. Orthogonality Diagram Elements UML State Machines actions History Indicator guards Sending Messages conditions Compound Transitions UML State Machines 1 Introduction to State Diagrams Interaction diagrams are very good for communication – between clients and designers – between designers and other designers – between designers and implementors But they are not part of the constructive core – Constructive core means that part from which an actual implementation could be generated The constructive core of the UML is – class diagrams (for the static part) – state diagrams (for the dynamic part) State diagrams can bescribe very complex dynamic behavior UML State Machines Elements of State Diagrams The basic elements of state diagrams are – states – the state in which the object finds itself at any moment – transitions – take the object from one state to another – events – cause the transition from one state to another – actions – take place as a result of a transition In the UML, many other extensions have been added, such as: – generalization/Inheritance among events (i.e. a mouse click and keyboard input as subclasses of user interface events) – hierarchical diagrams for managing complexity (from StateCharts) – guards – conditions on transitions State Diagrams should only be used for objects with significant dynamic behavior UML State Machines 2 Types of Events ChangeEvent (i.e.: when(x>y)) – A change event models an event that occurs when an explicit boolean expression becomes true as a result of a change in value of one or more attributes or associations.
    [Show full text]
  • Activity Diagram in UML
    6. UML Activity Diagrams Page 1 of 5 Activity Diagram in UML In the previous article, we learned about State diagrams, the notations to be used in State diagrams, their significance, and how to build a State diagram for a specific scenario in our Courseware Management system. In this article, we will cover the next dynamic diagram—the Activity diagram. By the end of this article, you will know what an Activity diagram is, what its elements are, and you will be able to create Activity diagrams for your system. Basics The easiest way to visualize an Activity diagram is to think of a flowchart of a code. The flowchart is used to depict the business logic flow and the events that cause decisions and actions in the code to take place. Activity diagrams represent the business and operational workflows of a system. An Activity diagram is a dynamic diagram that shows the activity and the event that causes the object to be in the particular state. So, what is the importance of an Activity diagram, as opposed to a State diagram? A State diagram shows the different states an object is in during the lifecycle of its existence in the system, and the transitions in the states of the objects. These transitions depict the activities causing these transitions, shown by arrows. An Activity diagram talks more about these transitions and activities causing the changes in the object states. Defining an Activity diagram Let us take a look at the building blocks of an Activity diagram. Elements of an Activity diagram An Activity diagram consists of the following behavioral elements: Element and its description Symbol Initial Activity: This shows the starting point or first activity of the flow.
    [Show full text]
  • Capstone Software Engineering Students Can Develop a High-Quality Complex System: a Case Study with Umple
    Proceedings 2019 Canadian Engineering Education Association (CEEA-ACEG19) Conference CAPSTONE SOFTWARE ENGINEERING STUDENTS CAN DEVELOP A HIGH-QUALITY COMPLEX SYSTEM: A CASE STUDY WITH UMPLE Timothy C. Lethbridge University of Ottawa [email protected] Abstract – Umple is an open-source programming UmpLe can be run OnLine, in EcLipse, in VisuaL Studio technology developed almost entirely by students, the Code and in severaL other tooLs. It can aLso be used in a majority of whom were working on it as their capstone classic manner as a command-line tool. project through a program called UCOSP. We describe UmpLe is targeted for educators who teach modeling our development process for Umple that has provided a [3][4], for students, and for open source developers who rich educational experience for the students, while at the want to buiLd systems that require low coding effort. The same time continually improving Umple’s quality. We core idea is that the high-level abstractions reduce the also describe features of Umple that have been designed amount of boiLerplate (repetitive) code that needs to be to facilitate its use in teaching software engineering. written, whiLe at the same time enabLing deveLopers and students to think at a higher level and to visualize their Keywords: Capstone project, open source, software code. UmpLe is a textuaL Language, but its high-level engineering, colLaboration, modeL-driven development abstractions can also be rendered and edited as graphs. UmpLe’s online user manual [5], if printed, amounts to 1. INTRODUCTION 300 pages. The OpenHub code analysis system [6] points out that 102 people have contributed a miLLion Lines of We describe our approach that has enabled successive code to UmpLe and suggests they have spent 286 person- groups of students to engineer and evolve a complex, years of effort on it based on its apparent complexity.
    [Show full text]
  • UML UML (Unified Modeling Language)
    CS189A/172 UML UML (Unified Modeling Language) • Combines several visual specification techniques – use case diagrams, component diagrams, package diagrams, deployment diagrams, class diagrams, sequence diagrams, collaboration diagrams, state diagrams, activity diagrams • Based on object oriented principles and concepts – encapsulation, abstraction – classes, objects • Semi-formal – Precise syntax but no formal semantics – There are efforts in formalizing UML semantics • There are tools which support UML – Can be used for developing UML models and analyzing them Examples for UML Tool Support • IBM’s Rational Rose is a software development tool based on UML. It has code generation capability, configuration management etc. – http://www-01.ibm.com/software/awdtools/developer/rose/ • Microsoft Visio has support for UML shapes and can be used for basic UML diagram drawing. • ArgoUML is an open source tool for developing UML models – http://argouml.tigris.org/ • USE is an open source tool which supports UML class diagrams and Object Constraint Language – http://www.db.informatik.uni-bremen.de/projects/USE/ • yUML is an easy to use tool for drawing UML diagrams. Supports class, activity and use-case diagrams – http://yuml.me/ UML References • There are lots of books on UML. The ones I used are: – “UML Distilled,” Martin Fowler • The examples I use in this lecture are from this book – “Using UML,” Perdita Stevens – “UML Explained,” Kendall Scott – “UML User Guide,” Grady Booch, James Rumbaugh, Ivar Jacobson • The Object Management Group (OMG,
    [Show full text]
  • Important Java Programming Concepts
    Appendix A Important Java Programming Concepts This appendix provides a brief orientation through the concepts of object-oriented programming in Java that are critical for understanding the material in this book and that are not specifically introduced as part of the main content. It is not intended as a general Java programming primer, but rather as a refresher and orientation through the features of the language that play a major role in the design of software in Java. If necessary, this overview should be complemented by an introductory book on Java programming, or on the relevant sections in the Java Tutorial [10]. A.1 Variables and Types Variables store values. In Java, variables are typed and the type of the variable must be declared before the name of the variable. Java distinguishes between two major categories of types: primitive types and reference types. Primitive types are used to represent numbers and Boolean values. Variables of a primitive type store the actual data that represents the value. When the content of a variable of a primitive type is assigned to another variable, a copy of the data stored in the initial variable is created and stored in the destination variable. For example: int original = 10; int copy = original; In this case variable original of the primitive type int (short for “integer”) is assigned the integer literal value 10. In the second assignment, a copy of the value 10 is used to initialize the new variable copy. Reference types represent more complex arrangements of data as defined by classes (see Section A.2).
    [Show full text]
  • Systems, Views and Models of UML∗
    Systems, Views and Models of UML∗ Ruth Breu, Radu Grosu, Franz Huber, Bernhard Rumpe, Wolfgang Schwerin email: {breur,grosu,huberf,rumpe,schwerin} @informatik.tu-muenchen.de Technische Universit¨atM¨unchen Arcisstr. 21 D-80290 M¨unchen, Germany Abstract In this paper we show by using the example of UML, how a soft- ware engineering method can benefit from an integrative mathemat- ical foundation. The mathematical foundation is given by a mathe- matical system model. This model provides the basis both for inte- grating the various description techniques of UML and for implement- ing methodical support. After describing the basic concepts of the system model, we give a short overview of the UML description tech- niques. Then we show how they fit into the system model framework and sketch an approach to structure the UML development process such that it provides methodological guidance for developers. 1 Introduction – Why Formalization? “The nice thing about graphical description techniques is that everyone un- derstands them, the bad thing, however, is that everyone understands them in a different way.” This often heard quote captures a main property of mod- eling techniques using semi-formal, mostly graphical notations, beginning with the early structured modeling techniques and prevalent until today’s object-oriented methods. The diagrammatic notations used here seem easily comprehensible for everyone dealing with software development. Experience ∗ This paper originates from the SysLab project, which is supported by the DFG under the Leibnizprogramme and by Siemens-Nixdorf. [BGH+98b] R. Breu, R. Grosu, F. Huber, B. Rumpe, W. Schwerin. Systems, Views and Models of UML.
    [Show full text]
  • OMG Systems Modeling Language (OMG Sysml™) Tutorial
    OMG Systems Modeling Language (OMG SysML™) Tutorial Based on the INCOSE tutorial available on the web http://www.uml-sysml.org/documentation/sysml-tutorial-incose-2.2mo and the book “SysML for Systems Engineers” SysML as an OMG standard • Specification status Adopted by OMG in May ’06 • Current Specification v1.2 released in June 2010 • The INCOSE tutorial is based on the OMG SysML specification v 1.0 (2007-09-01) • The tutorial, the specifications, papers, and info on tools can be found on the OMG SysML Website at http://www.omg.org/spec/SysML/ • The examples are based on the Topcased modeling tool (open source and Eclipse-based, available at www.topcased.org) Motivation, Objectives and Audience • At the end of this tutorial, you should have an understanding of: – Motivation of model-based systems engineering approach – SysML diagrams and language concepts – How to apply SysML as part of a model-based SE process – The course must be supplemented by modeling practice. • Intended Audience: – Practicing Systems Engineers interested in system modeling – Software Engineers who want to better understand how to integrate software and system models – Familiarity with UML is not required, but it helps What is Systems Engineering • Systems Engineering is a discipline that concentrates on the design and application of the whole (system) as distinct from the parts. It involves looking at the problem in its entirety, taking into account all the facets and all the variables. ( Federal Aviation Agency FAA-USA, Systems Engineering Manual, Definition by Simon Ramo, 2006 ) • Systems Engineering is an iterative process of top-down synthesis, development and operation of a real-world system that satisfies, in a near-optimal manner, the full range of requirements for the system.
    [Show full text]