DOCSLIB.ORG

Real Time UML

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Real Time UML Fr 5 January 22th-26th, 2007, Munich/Germany Real Time UML Bruce Powel Douglass Organized by: Lindlaustr. 2c, 53842 Troisdorf, Tel.: +49 (0)2241 2341-100, Fax.: +49 (0)2241 2341-199 www.oopconference.com RealReal--TimeTime UMLUML Bruce Powel Douglass, PhD Chief Evangelist Telelogic Systems and Software Modeling Division www.telelogic.com/modeling groups.yahoo.com/group/RT-UML 1 Real-Time UML © Telelogic AB Basics of UML • What is UML? – How do we capture requirements using UML? – How do we describe structure using UML? – How do we model communication using UML? – How do we describe behavior using UML? • The “Real-Time UML” Profile • The Harmony Process 2 Real-Time UML © Telelogic AB What is UML? 3 Real-Time UML © Telelogic AB What is UML? • Unified Modeling Language • Comprehensive full life-cycle 3rd Generation modeling language – Standardized in 1997 by the OMG – Created by a consortium of 12 companies from various domains – Telelogic/I-Logix a key contributor to the UML including the definition of behavioral modeling • Incorporates state of the art Software and Systems A&D concepts • Matches the growing complexity of real-time systems – Large scale systems, Networking, Web enabling, Data management • Extensible and configurable • Unprecedented inter-disciplinary market penetration – Used for both software and systems engineering • UML 2.0 is latest version (2.1 in process…) 4 Real-Time UML © Telelogic AB UML supports Key Technologies for Development Iterative Development Real-Time Frameworks Visual Modeling Automated Requirements- Based Testing Model Execution Model-Code Associativity 5 Real-Time UML © Telelogic AB UML 2 Diagrams Structure Activity Class Diagrams Diagrams Diagrams Statechart Diagrams Object Behavioral Diagrams Diagrams Structural Info Flow Diagrams Functional Diagrams Deployment Diagrams Diagrams Interaction Diagrams Use Case Component Diagrams Diagrams Timing Communication Diagrams Diagrams Sequence Diagrams 6 Real-Time UML © Telelogic AB How does UML apply to Real-Time? • Real-Time UML is standard UML – “UML is adequate for real-time systems” Grady Booch 1997 – “Although there have been a number of calls to extend UML for the real-time domain … experience had proven this is not necessary.” Bran Selic, 1999 (Communications of the ACM, Oct 1999) • Real-time and embedded applications – Special concerns about quality of service (QoS) – Special concerns about low-level programming – Special concerns about safety and reliability • Real-Time UML is about applying the UML to meet the specialized concerns of the real-time and embedded domains 7 Real-Time UML © Telelogic AB How do we capture requirements using UML? Use Case Modeling 8 Real-Time UML © Telelogic AB Why Use Case Modeling? • Use Case modeling is all about describing WHAT the system will do, – At a high level – Analysis NOT Design – From the perspective of the USER • Use Cases Scope the System – The developers need to minimally develop the functionality described by the use cases. – Users should not expect more/less/different functionality than is described by the use cases • Use Cases organize requirements • Provide a means to map requirements into interactions of the structural pieces of the system called collaborations • Can be used for project planning 9 Real-Time UML © Telelogic AB Association Basic Use Case Syntax Use Case { optical images 640x480 res at 30 fps} Constraint Actor 10 Real-Time UML © Telelogic AB An Actor ... • Is an object outside the scope of the system of concern that interacts with the system – May be a hardware device – May be a legacy system – May be a human user • May be generalized 11 Real-Time UML © Telelogic AB A Use Case … • Is a named operational capability of a system – Why the user interacts with the system • Returns a result visible to one or more actors • Does not reveal or imply internal structure of the system 12 Real-Time UML © Telelogic AB A Use Case Is Used to • Capture requirements of a system – Functional requirements Functional • What the system does requirements – Quality of Service (QoS) are modeled • How well the system does it: as use cases, – Worst-case execution time sequence diagrams, – Average execution time activity diagrams or – Throughput statecharts – Predictability – Capacity – Safety QoS Requirements are – Reliability modeled as constraints 13 Real-Time UML © Telelogic AB System Use Cases 14 Real-Time UML © Telelogic AB Identifying Use Cases • Answer questions such as: – What are the primary and secondary operational functions of the system? – With what must the system interface? – Why is the system being built? If it is replacing something else, why? • Play each actor in turn and ask – What do I want out of this system? – What do I want to do to this system? • Identify: – Capabilities (use cases) – Other context participants (actors) 15 Real-Time UML © Telelogic AB Use Cases Are Not .. • A functional decomposition model of the system internals – that’s HOW – They do not capture HOW in any way – They do not capture anything the Actor does outside of the System – How do I capture HOW? • Use Object Model Diagrams to capture Static Structure • Use Sequence Diagrams and State Diagrams (or Activity Diagrams) to capture Dynamic Behavior 16 Real-Time UML © Telelogic AB Good Example: Cardionada 17 Real-Time UML © Telelogic AB Bad Example: Cardionada-NADA Wrong Actors Not primary capabilities Assumes a design 18 Real-Time UML © Telelogic AB Things to avoid • Single messages are not use cases! – Use cases represent a large number of different scenarios – Each scenario has many (possibly hundreds) of messages • Low-level interfaces are not use cases – Low-level interfaces are means to realize use cases – LLI’s are subsumed within actual use cases – A use case should map to a reason for the user to interact with the system, not the means by which it occurs 19 Real-Time UML © Telelogic AB Use Cases Lead To Object Discovery • Use cases define requirements – functional –QoS • Use case are detailed – sequence diagrams – text and text annotations – statecharts • Use cases are “black box” • Use cases are realized by collaborations A collaboration is a set of object roles working together to achieve a higher-level function 20 Real-Time UML © Telelogic AB Use Case Relations • Generalization – One use case is a more specialized or refined version of another • «includes» – One use case includes another • «extends» – One use case provides an optional extension of another The point is to capture requirements not functionally decompose the system internals! 21 Real-Time UML © Telelogic AB Detailing Use Cases • By operational example – Use scenarios captured via sequence diagrams • Each scenario capture a specific path through the use case – Partially constructive – Infinite set, so you must select which are interestingly different – Non-technical users can understand scenarios • By specification – Use an informal (e.g. English) and/or formal (e.g. statechart) to represent all possible paths – Fully constructive – Non-technical readers might not understand formal specs 22 Real-Time UML © Telelogic AB Use Case Description • Use Case Description Structure –Name – Purpose • May be written informally (“The purpose of the capability is to…”) – Description • May be written semi-formally (“The system shall…”) • May be a hyperlink to a textual document – Preconditions • What is true prior to the execution of the capability? – Postconditions • What does the system guarantee to be true after the execution of the use case? – Constraints • Additional QoS requirements or other rules for the use case 23 Real-Time UML © Telelogic AB Description Example 24 Real-Time UML © Telelogic AB Information Flow Requirements • As part of analysis, it is common to want to understand information flow and processing required. – Information Flow diagrams (UML 2) show info flows between elements, but no sequence is shown • Similar to de Marco-style DFDs • Can be done for entire system or per use case – Activity diagrams show sequence of information processing within a system • Usually done per use case 25 Real-Time UML © Telelogic AB Information Flow Requirements 26 Real-Time UML © Telelogic AB Relating to Textual Requirements • Use cases and related notations are an alternative to text-based requirements • Restating text-based requirements – When the text requirements are vague – When they need to be validated with the customer – When the risk or cost of incorrect, inaccurate, or inconsistent requirements is high – When there is a high need to perform validation tests against the requirements – When the requirements are complex Traceability is best achieved through the use of traceability tools such as DOORS or Gateway 27 Real-Time UML © Telelogic AB Detailing Use Cases: Scenarios • A typical system has one dozen to a few dozen use case • Each use case typically has a few to several dozen scenarios of interest • Scenarios capture a specific actor-system interaction – protocols of interaction – permitted sequences of message flow – collaboration of structural elements – show typical or exceptional paths through the use case 28 Real-Time UML © Telelogic AB Example Sequence Diagram 29 Real-Time UML © Telelogic AB Detailing Use Cases: Statecharts 30 Real-Time UML © Telelogic AB Detailing Use Cases: Statecharts Alarm on Critical Event 31 Real-Time UML © Telelogic AB How do we describe structure using UML? 32 Real-Time UML © Telelogic AB Objects, Classes and Interfaces • An object is a run-time entity that occupies memory at some specific point in time – Has behavior (methods) – Has data (attributes) • A class is a design-time specification that defines the structure and behavior for a set of objects to be created at run-time. – Specifies behavior implementation (methods) – Specifies data (attributes) • An interface is a design time concept that specifies the messages a class receives (“provided”) or uses (“required”) – Specifies behavior only (operation implementation) – May have virtual attributes (no implementation) – May have a protocol state machine (no actions) 33 Real-Time UML © Telelogic AB What is an Object ? • An object is one of the common building blocks in a UML model.
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]
  • An Optimal Control Approach for Determiniation of the Heat Loss Coefficient in an Ics Solar Domesticater W Heating System
    University of Central Florida STARS Electronic Theses and Dissertations, 2004-2019 2010 An Optimal Control Approach For Determiniation Of The Heat Loss Coefficient In An Ics Solar Domesticater W Heating System Camilo Gil University of Central Florida Part of the Electrical and Electronics Commons Find similar works at: https://stars.library.ucf.edu/etd University of Central Florida Libraries http://library.ucf.edu This Doctoral Dissertation (Open Access) is brought to you for free and open access by STARS. It has been accepted for inclusion in Electronic Theses and Dissertations, 2004-2019 by an authorized administrator of STARS. For more information, please contact [email protected]. STARS Citation Gil, Camilo, "An Optimal Control Approach For Determiniation Of The Heat Loss Coefficient In An Ics Solar Domestic Water Heating System" (2010). Electronic Theses and Dissertations, 2004-2019. 4297. https://stars.library.ucf.edu/etd/4297 AN OPTIMAL CONTROL APPROACH FOR DETERMINATION OF THE HEAT LOSS COEFFICIENT IN AN ICS SOLAR DOMESTIC WATER HEATING SYSTEM by CAMILO GIL B.S. Pontificia Universidad Javeriana, 2001 M.S. University of New Mexico, 2005 A dissertation submitted in partial fulfillment of the requirements for the degree of Doctor of Philosophy in the Department of Electrical and Computer Engineering in the College of Engineering and Computer Science at the University of Central Florida Orlando, Florida Summer Term 2010 Major Professor: Marwan Simaan ©2010 Camilo Gil ii ABSTRACT Water heating in a typical home in the U.S. accounts for a significant portion (between 14% and 25%) of the total home’s annual energy consumption. The objective of considerably reducing the home’s energy consumption from the utilities calls for the use of onsite renewable energy systems.
    [Show full text]
  • Blurred Lines Between Role and Reality: a Phenomenological Study of Acting
    Antioch University AURA - Antioch University Repository and Archive Student & Alumni Scholarship, including Dissertations & Theses Dissertations & Theses 2019 Blurred Lines Between Role and Reality: A Phenomenological Study of Acting Gregory Hyppolyte Brown Follow this and additional works at: https://aura.antioch.edu/etds Part of the Psychology Commons BLURRED LINES BETWEEN ROLE AND REALITY: A PHENOMENOLOGICAL STUDY OF ACTING A Dissertation Presented to the Faculty of Antioch University Santa Barbara In partial fulfillment of the requirements for the the degree of DOCTOR OF PSYCHOLOGY In CLINICAL PSYCHOLOGY by GREGORY HIPPOLYTE BROWN August 2019 This dissertation, by Gregory Hippolyte Brown, has been approved by the committee members signed below who recommend that it be accepted by the faculty of Antioch University Santa Barbara in partial fulfillment of requirements for the degree of DOCTOR OF PSYCHOLOGY Dissertation Committee: _________________________ Brett Kia-Keating, Ed.D. Chairperson __________________________ Sharleen O‘ Brien, Ph.D. Second Faculty __________________________ Thalia R. Goldstein, Ph.D. External Expert ii Copyright © 2019 Gregory Hippolyte Brown iii Abstract When an actor plays a character in a film, they try to connect with the emotions and behavioral patterns of the scripted character. There is an absence of literature regarding how a role influences an actor’s life before, during, and after film production. This study examined how acting roles might influence an actor during times on set shooting a movie or television series as well as their personal life after the filming is finished. Additionally the study considered the psychological impact of embodying a role, and whether or not an actor ever has the feeling that the performed character has independent agency over the actor.
    [Show full text]
  • Writing and Reviewing Use-Case Descriptions
    Bittner/Spence_06.fm Page 145 Tuesday, July 30, 2002 12:04 PM PART II WRITING AND REVIEWING USE-CASE DESCRIPTIONS Part I, Getting Started with Use-Case Modeling, introduced the basic con- cepts of use-case modeling, including defining the basic concepts and understanding how to use these concepts to define the vision, find actors and use cases, and to define the basic concepts the system will use. If we go no further, we have an overview of what the system will do, an under- standing of the stakeholders of the system, and an understanding of the ways the system provides value to those stakeholders. What we do not have, if we stop at this point, is an understanding of exactly what the system does. In short, we lack the details needed to actually develop and test the system. Some people, having only come this far, wonder what use-case model- ing is all about and question its value. If one only comes this far with use- case modeling, we are forced to agree; the real value of use-case modeling comes from the descriptions of the interactions of the actors and the system, and from the descriptions of what the system does in response to the actions of the actors. Surprisingly, and disappointingly, many teams stop after developing little more than simple outlines for their use cases and consider themselves done. These same teams encounter problems because their use cases are vague and lack detail, so they blame the use-case approach for having let them down. The failing in these cases is not with the approach, but with its application.
    [Show full text]
  • Document Title Requirements on Debugging in AUTOSAR
    Requirements on Debugging in AUTOSAR AUTOSAR Release 4.2.2 Document Title Requirements on Debugging in AUTOSAR Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification No 332 Document Classification Auxiliary Document Status Final Part of AUTOSAR Release 4.2.2 Document Change History Release Changed by Change Description 4.2.2 AUTOSAR Marked the document as obsolete Release Management 4.2.1 AUTOSAR Editorial changes Release Management 4.1.2 AUTOSAR Updated reference to RS feature document Release Editorial changes Management 4.1.1 AUTOSAR Updated the format of requirements according Administration to TPS_StandardizationTemplate Updated the chapters 2 and 5 Replaced Complex Device Driver by Complex Driver 3.1.5 AUTOSAR Initial release Administration 1 of 19 Document ID 332: AUTOSAR_SRS_Debugging - AUTOSAR confidential - Requirements on Debugging in AUTOSAR AUTOSAR Release 4.2.2 Disclaimer This specification and the material contained in it, as released by AUTOSAR, is for the purpose of information only. AUTOSAR and the companies that have contributed to it shall not be liable for any use of the specification. The material contained in this specification is protected by copyright and other types of Intellectual Property Rights. The commercial exploitation of the material contained in this specification requires a license to such Intellectual Property Rights. This specification may be utilized or reproduced without any modification, in any form or by any means, for informational purposes only. For any other purpose, no part of the specification may be utilized or reproduced, in any form or by any means, without permission in writing from the publisher. The AUTOSAR specifications have been developed for automotive applications only.
    [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]
  • 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: Part 1 -- Class Diagrams
    UML Tutorial: Part 1 -- Class Diagrams. Robert C. Martin My next several columns will be a running tutorial of UML. The 1.0 version of UML was released on the 13th of January, 1997. The 1.1 release should be out before the end of the year. This col- umn will track the progress of UML and present the issues that the three amigos (Grady Booch, Jim Rumbaugh, and Ivar Jacobson) are dealing with. Introduction UML stands for Unified Modeling Language. It represents a unification of the concepts and nota- tions presented by the three amigos in their respective books1. The goal is for UML to become a common language for creating models of object oriented computer software. In its current form UML is comprised of two major components: a Meta-model and a notation. In the future, some form of method or process may also be added to; or associated with, UML. The Meta-model UML is unique in that it has a standard data representation. This representation is called the meta- model. The meta-model is a description of UML in UML. It describes the objects, attributes, and relationships necessary to represent the concepts of UML within a software application. This provides CASE manufacturers with a standard and unambiguous way to represent UML models. Hopefully it will allow for easy transport of UML models between tools. It may also make it easier to write ancillary tools for browsing, summarizing, and modifying UML models. A deeper discussion of the metamodel is beyond the scope of this column. Interested readers can learn more about it by downloading the UML documents from the rational web site2.
    [Show full text]
  • Justice XML Data Model Technical Overview
    Justice XML Data Model Technical Overview April 2003 WhyWhy JusticeJustice XMLXML DataData ModelModel VersionVersion 3.0?3.0? • Aligned with standards (some were not available to RDD) • Model-based Æ consistent • Requirements-based – data elements, processes, and documents • Object-oriented Æ efficient extension and reuse • Expanded domain (courts, corrections, and juvenile) • Extensions to activity objects/processes • Relationships (to improve exchange information context) • Can evolve/advance with emerging technology (RDF/OWL) • Model provides the basis for an XML component registry that can provide • Searching/browsing components and metadata • Assistance for schema development/generation • Reference/cache XML schemas for validation • Interface (via standard specs) to external XML registries April 2003 DesignDesign PrinciplesPrinciples • Design and synthesize a common set of reusable, extensible data components for a Justice XML Data Dictionary (JXDD) that facilitates standard information exchange in XML. • Generalize JXDD for the justice and public safety communities – do NOT target specific applications. • Provide reference-able schema components primarily for schema developers. • JXDD and schema will evolve and, therefore, facilitate change and extension. • Best extension methods should minimize impact on prior schema and code investments. • Implement and represent domain relationships so they are globally understood. • Technical dependencies in requirements, solutions, and the time constraints of national priorities and demands
    [Show full text]
  • Object Query Language Reference Version: Itop 1.0
    Object Query Language Reference Version: Itop 1.0 Overview OQL aims at defining a subset of the data in a natural language, while hiding the complexity of the data model and benefit of the power of the object model (encapsulation, inheritance). Its syntax sticks to the syntax of SQL, and its grammar is a subset of SQL. As of now, only SELECT statements have been implemented. Such a statement do return objects of the expected class. The result will be used by programmatic means (to develop an API like ITOp). A famous example: the library Starter SELECT Book Do return any book existing in the Database. No need to specify the expected columns as we would do in a SQL SELECT clause: OQL do return plain objects. Join classes together I would like to list all books written by someone whose name starts with `Camus' SELECT Book JOIN Artist ON Book.written_by = Artist.id WHERE Artist.name LIKE 'Camus%' Note that there is no need to specify wether the JOIN is an INNER JOIN, or LEFT JOIN. This is well-known in the data model. The OQL engine will in turn create a SQL queries based on the relevant option, but we do not want to care about it, do we? © Combodo 2010 1 Now, you may consider that the name of the author of a book is of importance. This is the case if should be displayed anytime you will list a set of books, or if it is an important key to search for. Then you have the option to change the data model, and define the name of the author as an external field.
    [Show full text]
  • 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.
    [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]