DOCSLIB.ORG

Executable and Translatable UML

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Executable and Translatable UML Executable and Translatable UML Stephen J. Mellor Marc J. Balcer Contents What’s the problem? UML Models Executable UML elements Executable UML behavior The Repository Model Compiler Concepts How model compilers work MDA © 2003 Stephen J. Mellor and Marc J. Balcer All Rights Reserved 2 What’s the Problem? Analysts create …print them out… … then the developers “high-level” look at the models application and write the models… production code These models are Coding adds this independent of the “design detail” implementation technology © 2003 Stephen J. Mellor and Marc J. Balcer All Rights Reserved 3 What’s the Problem? But once …we shouldn’t something is in have to manually a machine reinterpret it representation… (“elaborate it”) into another. The analyst’s diagrams Keeping the diagrams The rework introduces don’t have to be complete, in sync with the code development errors and correct, or consistent models is a daunting task. obscures analyst errors © 2003 Stephen J. Mellor and Marc J. Balcer All Rights Reserved 4 What’s the Problem? But once …we shouldn’t something is in Because have to manually a machine elaboration reinterpret it representation… (“elaborate it”) is stupid! into another. The Ant appears courtesy of Leon Starr, Executable UML © 2003 Stephen J. Mellor and Marc J. Balcer All Rights Reserved 5 Executable Models Analysts • create executable models • test those executable models …and compile the models to produce a running system Developers • buy, build, or adapt a model compiler for a software architecture • map model elements to the architecture… © 2003 Stephen J. Mellor and Marc J. Balcer All Rights Reserved 6 Executable Models The analyst’s models must be complete, correct, and consistent— and the models are verifiable. The process always moves forward… …there’s no editing of the translated code, no round-tripping, no reverse-engineering, no getting out of sync. The software deign decisions are formalized in the mappings and translation archetypes © 2003 Stephen J. Mellor and Marc J. Balcer All Rights Reserved 7 Contents What’s the problem? UML Models Executable UML elements Executable UML behavior The Repository Model Compiler Concepts How model compilers work MDA © 2003 Stephen J. Mellor and Marc J. Balcer All Rights Reserved 8 What’s UML? “The Unified Modeling Language is a language for specifying, constructing, visualizing, and documenting artifacts of a software-intensive system” —The UML Summary ® © 2003 Stephen J. Mellor and Marc J. Balcer All Rights Reserved 9 What’s UML? Common notation for OOA / OOD Goal was to eliminate the notation wars One notation for many purposes Very large ® Concept of “profiles” for different uses © 2003 Stephen J. Mellor and Marc J. Balcer All Rights Reserved 10 UML in Practice Describing Modeling Documenting a problem a solution software “Requirements” “Analysis” “Design” © 2003 Stephen J. Mellor and Marc J. Balcer All Rights Reserved 11 UML in Practice Just because these use the same notation (UML) doesn’t mean these are the same problem. The software design does not follow from the model of the The models are more than problem just the observable behavior to the user © 2003 Stephen J. Mellor and Marc J. Balcer All Rights Reserved 12 Notation Semantics doBilling( ) : BillingGroup Customer name : PersonalName Open Account address : MailingAddress phone : TelephoneNumber billGroup( ) customerID : CustomerIDNumber : Timer billingComplete( ) is the responsibility of 1 R1 : BillingRun is responsible for 1..* Suspend Account Account Customer Service Collection Agent number : CardAccountNumber Rep / currentBalance : Money Call Delinquent Customer actualCreditLimit : Money Transaction requestedCreditLimit : Money is processed prepareStatement( ) transactionDate : Date interestRate : Percent on accumulates / netAmount : Money R3 notes : FreeformText open() 1 0..* dueDateReached( ) suspend( ) approve() reinstate( ) Close Account suspend() is current presents 0..* presentation of : Statement : Account reinstate() R12 close() 1 directs billing of 0..* Produce Bills for Group R5 Timer R2 is billed as part of 1 BillingGroup applyPayment( ) groupNumber : BillingGroupNumber is currently billingDay : BillingDayNumber Submit Charge presented to 1 customer as 0..1 appears on receivePayment( ) doBilling() Statement billingComplete() / statementDate : Date : Payment is an actual billing of 1 minimumAmountDue : Money Merchant paymentDueDate : Date R4 is actually billed as prepareStatement() Receive Payment 0..* applyPayment() Billing Clerk BillingRun dueDateReached() : Billing Clerk Issue Credit billingDate : Date noPaymentDue() billGroup() Use Case Diagram allBillsProduced() Class Diagram Collaboration Diagram C1 C2 Open Account prepareStatement( statementDate ) : Payment : Statement : Billing Clerk : Timer C3 Statement Prepared receivePayment( ) applyPayment( ) Pay Bill applyPayment( transaction ) noPaymentDue Component Diagram dueDateReached Paid On Payment No Payment dueDateReached( ) Time Past Due Due ignored Branch applyPayment( transaction ) Close Account HQ Paid Late Branch Activity Diagram State Diagram Sequence Diagram Remote Deployment Diagram Each diagram is well-defined, but how do they fit together? © 2003 Stephen J. Mellor and Marc J. Balcer All Rights Reserved 13 Contents What’s the problem? UML Models Executable UML elements Executable UML behavior The Repository Model Compiler Concepts How model compilers work MDA © 2003 Stephen J. Mellor and Marc J. Balcer All Rights Reserved 14 UML in Practice O u r F oc us Describing Modeling Documenting a problem a solution software “Requirements” “Analysis” “Design” © 2003 Stephen J. Mellor and Marc J. Balcer All Rights Reserved 15 UML Profiles Customer name : PersonalName address : MailingAddress phone : TelephoneNumber customerID : CustomerIDNumber is the responsibility of 1 R1 is responsible for 1..* A profile defines how these Account number : CardAccountNumber / currentBalance : Money actualCreditLimit : Money Transaction requestedCreditLimit : Money is processed transactionDate : Date interestRate : Percent on accumulates / netAmount : Money diagrams represent models R3 notes : FreeformText open() 1 0..* approve() suspend() is current presents 0..* presentation of reinstate() R12 close() 1 directs billing of 0..* R2 R5 is billed as part of 1 BillingGroup groupNumber : BillingGroupNumber is currently billingDay : BillingDayNumber presented to 1 customer as 0..1 appears on doBilling() Statement billingComplete() / statementDate : Date is an actual billing of 1 minimumAmountDue : Money paymentDueDate : Date R4 is actually billed as prepareStatement() 0..* applyPayment() BillingRun dueDateReached() billingDate : Date noPaymentDue() billGroup() allBillsProduced() Information Model (things in the problem and how they are related) prepareStatement( statementDate ) Statement Prepared applyPayment( transaction ) noPaymentDue dueDateReached Paid On Payment No Payment Time Past Due Due applyPayment( transaction ) Paid Late State Model (lifecycle of an instance of a class) © 2003 Stephen J. Mellor and Marc J. Balcer All Rights Reserved 16 UML Profiles Customer doBilling( ) name : PersonalName address : MailingAddress : BillingGroup phone : TelephoneNumber customerID : CustomerIDNumber 1 is the responsibility of billGroup( ) R1 : Timer billingComplete( ) is responsible for 1..* It also defines a set of diagrams Account number : CardAccountNumber : BillingRun / currentBalance : Money actualCreditLimit : Money Transaction requestedCreditLimit : Money is processed transactionDate : Date interestRate : Percent on accumulates / netAmount : Money that are derived from R3 notes : FreeformText open() 1 0..* approve() prepareStatement( ) suspend() is current presents 0..* presentation of reinstate() R12 dueDateReached( ) close() 1 suspend( ) directs billing of 0..* the basic models reinstate( ) : Statement : Account R2 R5 is billed as part of 1 BillingGroup groupNumber : BillingGroupNumber is currently billingDay : BillingDayNumber presented to 1 customer as 0..1 appears on applyPayment( ) doBilling() Statement billingComplete() / statementDate : Date is an actual billing of 1 minimumAmountDue : Money receivePayment( ) paymentDueDate : Date R4 : Payment is actually billed as prepareStatement() 0..* applyPayment() BillingRun dueDateReached() billingDate : Date noPaymentDue() billGroup() : Billing Clerk allBillsProduced() Information Model Object Communication Model (things in the problem (summary of object interactions) and how they are related) prepareStatement( statementDate ) Statement Prepared : Payment : Statement applyPayment( transaction ) noPaymentDue : Billing Clerk : Timer dueDateReached receivePayment( ) Paid On Payment No Payment applyPayment( ) Time Past Due Due applyPayment( transaction ) dueDateReached( ) Paid Late ignored State Model (lifecycle of an instance of a class) Execution Trace (system behavior under one scenario) © 2003 Stephen J. Mellor and Marc J. Balcer All Rights Reserved 17 Classes Customer Class name : PersonalName address : MailingAddress phone : TelephoneNumber abstraction of common characteristics customerID : CustomerIDNumber is the responsibility of 1 and common behavior R1 is responsible for 1..* Account number : CardAccountNumber Attribute / currentBalance : Money actualCreditLimit : Money Transaction requestedCreditLimit : Money is processed transactionDate : Date abstraction of a single interestRate : Percent on accumulates / netAmount : Money R3 notes : FreeformText open() 1
Load more

Recommended publications
  • 07 Requirements What About RFP/RFB/Rfis?
    CMPSCI520/620 07 Requirements & UML Intro 07 Requirements SW Requirements Specification • Readings • How do we communicate the Requirements to others? • [cK99] Cris Kobryn, Co-Chair, “Introduction to UML: Structural and Use Case Modeling,” UML Revision Task Force Object Modeling with OMG UML Tutorial • It is common practice to capture them in an SRS Series © 1999-2001 OMG and Contributors: Crossmeta, EDS, IBM, Enea Data, • But an SRS doesn’t need to be a single paper document Hewlett-Packard, IntelliCorp, Kabira Technologies, Klasse Objecten, Rational Software, Telelogic, Unisys http://www.omg.org/technology/uml/uml_tutorial.htm • Purpose • [OSBB99] Gunnar Övergaard, Bran Selic, Conrad Bock and Morgan Björkande, “Behavioral Modeling,” UML Revision Task Force, Object Modeling with OMG UML • Contractual requirements Tutorial Series © 1999-2001 OMG and Contributors: Crossmeta, EDS, IBM, Enea elicitation Data, Hewlett-Packard, IntelliCorp, Kabira Technologies, Klasse Objecten, Rational • Baseline Software, Telelogic, Unisys http://www.omg.org/technology/uml/uml_tutorial.htm • for evaluating subsequent products • [laM01] Maciaszek, L.A. (2001): Requirements Analysis and System Design. • for change control requirements Developing Information Systems with UML, Addison Wesley Copyright © 2000 by analysis Addison Wesley • Audience • [cB04] Bock, Conrad, Advanced Analysis and Design with UML • Users, Purchasers requirements http://www.kabira.com/bock/ specification • [rM02] Miller, Randy, “Practical UML: A hands-on introduction for developers,”
    [Show full text]
  • Activity Diagram Inheritance1
    Activity Diagram Inheritance1 Arnd Schnieders, Frank Puhlmann Hasso-Plattner-Institute for IT Systems Engineering at the University of Potsdam {schnieders, puhlmann}@hpi.uni-potsdam.de Abstract This paper outlines the ongoing work on the realization of a flexible inheritance mechanism for Activity Diagrams that assures the maintenance of syntactical correctness for the derived Activity Diagrams. The objective is to support the reuse of process models especially by applying Activity Diagram inheritance as a variability mechanism in the context of product line oriented software development. Keywords: Activity Diagrams, domain engineering, process inheritance, variability mechanism 1. Introduction In industry similar products are frequently developed and produced as product lines. One of the main advantages is a gain of efficiency in development and production since parts, which are common for several product line members, can be reused optimally. This approach has been transferred successfully to software development and is also known by the name domain engineering. Variability mechanisms are thereby important for the effectiveness of domain engineering. A great number of variability mechanisms has already been published [5, 9, 11, 13, 18]. Unfortunately, existing variability mechanisms only refer to the static aspects of a software system’s design while the impact of variability mechanisms on the process view on the system has been strongly neglected. Therefore, the first contribution of this paper is to contribute to closing this gap by making the important variability mechanism inheritance available for process design models in order to derive process model variants. The second contribution of this paper is to show how the defined process inheritance mechanism is realized concretely for UML 2.0 Activity Diagrams.
    [Show full text]
  • 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]
  • OMG Systems Modeling Language (OMG Sysml™) Tutorial 25 June 2007
    OMG Systems Modeling Language (OMG SysML™) Tutorial 25 June 2007 Sanford Friedenthal Alan Moore Rick Steiner (emails included in references at end) Copyright © 2006, 2007 by Object Management Group. Published and used by INCOSE and affiliated societies with permission. Status • Specification status – Adopted by OMG in May ’06 – Finalization Task Force Report in March ’07 – Available Specification v1.0 expected June ‘07 – Revision task force chartered for SysML v1.1 in March ‘07 • This tutorial is based on the OMG SysML adopted specification (ad-06-03-01) and changes proposed by the Finalization Task Force (ptc/07-03-03) • This tutorial, the specifications, papers, and vendor info can be found on the OMG SysML Website at http://www.omgsysml.org/ 7/26/2007 Copyright © 2006,2007 by Object Management Group. 2 Objectives & Intended Audience At the end of this tutorial, you should have an awareness of: • Benefits of model driven approaches for systems engineering • SysML diagrams and language concepts • How to apply SysML as part of a model based SE process • Basic considerations for transitioning to SysML 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 • Software Engineers who want to better understand how to integrate software and system models • Familiarity with UML is not required, but it helps 7/26/2007 Copyright © 2006,2007 by Object Management Group. 3 Topics • Motivation & Background • Diagram Overview and Language Concepts • SysML Modeling as Part of SE Process – Structured Analysis – Distiller Example – OOSEM – Enhanced Security System Example • SysML in a Standards Framework • Transitioning to SysML • Summary 7/26/2007 Copyright © 2006,2007 by Object Management Group.
    [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]
  • PART 3: UML Dynamic Modelling Notations • State Machines/Statecharts • Collaboration Diagrams • Sequence Diagrams • Activity Diagrams
    PART 3: UML Dynamic Modelling Notations • State machines/statecharts • Collaboration diagrams • Sequence diagrams • Activity diagrams. Chapter 19 of the textbook is relevant to this part. 1 State machines • State machines describe dynamic behaviour of objects, show life history of objects over time + object communications. • Used for real-time system design (eg., robotics); GUI design (states represent UI screens/modes). Example shows simple state machine with two states, On and Off and transitions between them. 2 Switch Off swon swoff On Simple state machine 3 State machines Elements of a state machine are: States: Rounded-corner boxes, containing state name. Transitions: Arrows from one state, source of transition, to another, target, labelled with event that causes transition. Default initial state: State of object at start of its life history. Shown as target of transition from initial pseudostate (black filled circle). Termination of state machine can be shown by `bullseye' symbol. 4 State machines UML divides state machines into two kinds: 1. Protocol state machines { describe allowed life histories of objects of a class. Events on transitions are operations of that class, transitions may have pre and post conditions. Transitions cannot have generated actions (although we will allow this). 2. Behaviour state machines { describe operation execution/implementation of object behaviour. Transitions do not have postconditions, but can have actions. State machines describe behaviour of objects of a particular class, or execution processing of an operation. 5 State machines • Class diagrams describe system data, independently of time. • State machines show how system/objects can change over time. • Switch state machine is protocol state machine for objects of Switch class.
    [Show full text]
  • UML Tutorial: Sequence Diagrams
    UML Tutorial: Sequence Diagrams. Robert C. Martin Engineering Notebook Column April, 98 In my last column, I described UML Collaboration diagrams. Collaboration diagrams allow the designer to specify the sequence of messages sent between objects in a collaboration. The style of the diagram emphasizes the relationships between the objects as opposed to the sequence of the messages. In this column we will be discussing UML Sequence diagrams. Sequence diagrams contain the same information as Collaboration diagrams, but emphasize the sequence of the messages instead of the relationships between the objects. The Cellular Phone Revisited Here again is the final collaboration diagram from last column’s Cellular Phone example. (See Figure 1.) 1*:ButtonPressed() :DigitButton Digit:Button 1.1:Digit(code) Adapter 2:ButtonPressed() :SendButton Send:Button :Dialler Adapter 2.1:Send() 1.1.2:EmitTone(code) 2.1.1:Connect(pno) 1.1.1:DisplayDigit(code) 2.1.1.1:InUse() :Cellular display display:Dialler :Speaker Radio :CRDisplay Display Figure 1: Collaboration diagram of Cellular Phone. The Sequence diagram that corresponds to this model is shown in Figure 2. It is pretty easy to see what the diagrams in Figure 2 are telling us, especially when we compare them to Figure 1. Let’s walk through the features. First of all, there are two sequence diagrams present. The first one captures the course of events that takes place when a digit button is pressed. The second captures what happens when the user pushes the ‘send’ button in order to make a call. At the top of each diagram we see the rectangles that represent objects.
    [Show full text]
  • Capabilities Statement
    Capabilities Statement Email: [email protected] Web site: www.modeldriven.com 1 Model Driven Solutions Model Driven Solutions is a leading provider of professional services and products that leverage Services Oriented Architecture (SOA), the Object Management Group’s (OMG) Model Driven Architecture (MDA), Information Sharing, Ontologies and Semantics and W3C’s Semantic Web techniques and standards to federate processes, information, systems and organizations. A current focus is information interoperability and federation with a current emphasis on finance, risk and threats across cyber and physical domains as well as a model-driven approach to NIEM. We assist major organizations in achieving effectiveness and agility in a changing and collaborative world. Founded in 1996, as Data Access Technologies, Inc., its division, Model Driven Solutions, has been a leader in the development of open standards and supporting products that result in SOA based Executable Enterprise Architectures (EEA). Model Driven Solutions’ EEA focus helps drive information systems to quickly and cost effectively address business and defense initiatives. Active in the Object Management Group (OMG), the Organization for the Advancement of Structured Information Standards (OASIS), the Open Group and other standards development organizations, Model Driven Solutions has provided industry leadership that is, today, resulting in significant technological advancements and customer satisfaction. With customers like the General Services Administration (GSA), the U.S. Information Sharing Environment, the US Army, Raytheon, Lockheed Martin, Kaiser Permanente, Unisys and many others, Model Driven Solutions is at the leading edge of today’s software technology advances. General Information Parent Company Name: Data Access Technologies, Inc. (DAT) Virginia Affiliate: Model Driven Solutions, Inc.
    [Show full text]
  • Unifying Modeling and Programming with ALF
    SOFTENG 2016 : The Second International Conference on Advances and Trends in Software Engineering Unifying Modeling and Programming with ALF Thomas Buchmann and Alexander Rimer University of Bayreuth Chair of Applied Computer Science I Bayreuth, Germany email: fthomas.buchmann, [email protected] Abstract—Model-driven software engineering has become more The Eclipse Modeling Framework (EMF) [5] has been and more popular during the last decade. While modeling the established as an extensible platform for the development of static structure of a software system is almost state-of-the art MDSE applications. It is based on the Ecore meta-model, nowadays, programming is still required to supply behavior, i.e., which is compatible with the Object Management Group method bodies. Unified Modeling Language (UML) class dia- (OMG) Meta Object Facility (MOF) specification [6]. Ideally, grams constitute the standard in structural modeling. Behavioral software engineers operate only on the level of models such modeling, on the other hand, may be achieved graphically with a set of UML diagrams or with textual languages. Unfortunately, that there is no need to inspect or edit the actual source code, not all UML diagrams come with a precisely defined execution which is generated from the models automatically. However, semantics and thus, code generation is hindered. In this paper, an practical experiences have shown that language-specific adap- implementation of the Action Language for Foundational UML tations to the generated source code are frequently necessary. (Alf) standard is presented, which allows for textual modeling In EMF, for instance, only structure is modeled by means of of software systems.
    [Show full text]
  • 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
    [Show full text]
  • 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.
    [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]