DOCSLIB.ORG

OMG Unified Modeling Language Specification

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
OMG Unified Modeling Language Specification OMG Unified Modeling Language Specification Version 1.4 September 2001 Copyright © 1997-2001 Computer Associates International Inc. Copyright © 1997-2001 Electronic Data Systems Corporation Copyright © 1997-2001 Hewlett-Packard Company Copyright © 1997-2001 IBM Corporation Copyright © 1997-2001, I-Logix Copyright © 1997-2001 IntelliCorp Copyright © 1997-2001 Microsoft Corporation Copyright © 1997-2001 Object Management Group Copyright © 1997-2001 Oracle Corporation Copyright © 1997-2001 Ptech Inc. Copyright © 1997-2001 Rational Software Corporation Copyright © 1997-2001 Reich Technologies Copyright © 1997-2001 Softeam Copyright © 1997-2001 Taskon A/S Copyright © 1997-2001 Unisys Corporation PATENT The attention of adopters is directed to the possibility that compliance with or adoption of OMG specifications may require use of an invention covered by patent rights. OMG shall not be responsible for identifying patents for which a license may be required by any OMG specification, or for conducting legal inquiries into the legal validity or scope of those patents that are brought to its attention. OMG specifications are prospective and advisory only. Prospective users are responsible for protecting themselves against liability for infringement of patents. NOTICE The information contained in this document is subject to change without notice. The material in this document details an Object Management Group, Inc. specification. This document does not represent a commitment to implement any portion of this specification in any companies' products. GENERAL USE RESTRICTIONS The owners of the copyright in the UML specifications version 1.3 hereby grant you a fully-paid up, non-exclusive, nontransferable, perpetual, worldwide license (without the right to sublicense), to create and distribute software and special purpose specifications which are based upon the UML specifications, and to use, copy, and distribute the UML specifications as provided under the Copyright Act; provided that: (1) both the copyright notice identified above and this permission notice appear on any copies of the UML specifications; (2) the use of the specifications is for informational purposes and will not be copied or posted on any network computer or broadcast in any media and will not be otherwise resold or transferred for commercial purposes; and (3) no modifications are made to the UML specifications themselves. This limited permission automatically terminates without notice if you breach any of these terms or conditions. Upon termination, you will destroy immediately any copies of the specifications in your possession or control. Software developed under the terms of this license may claim compliance or conformance with UML version 1.3 if and only if the software compliance is of a nature fully matching the applicable compliance points as stated in the specifications. Software developed only partially matching the applicable compliance points may claim only that the software was based on the UML specifications, but may not claim compliance or conformance with any particular UML version. In the event that testing suites are implemented by Object Management Group, Inc., software developed using the UML specifications may claim compliance or conformance with the specifications only if the software satisfactorily completes the testing suites. Any unauthorized use of the UML specifications may violate copyright laws, trademark laws, and communications regulations and statutes. DISCLAIMER OF WARRANTY WHILE THE INFORMATION IN THIS PUBLICATION IS BELIEVED TO BE ACCURATE, THE UML SPECIFICATIONS ARE PROVIDED "AS IS" AND MAY CONTAIN ERRORS OR MISPRINTS. THE SPECIFICATIONS ARE PROVIDED FREE OF CHARGE OR AT A NOMINAL COST, AND ACCORDINGLY ARE PROVIDED ON AN "AS IS" BASIS, WITHOUT WARRANTY OF ANY KIND, INCLUDING WITHOUT LIMITATION THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ERRORS CONTAINED HEREIN OR FOR INCIDENTAL OR CONSEQUENTIAL DAMAGES IN CONNECTION WITH THE FURNISHING, PERFORMANCE, OR USE OF THIS MATERIAL, EVEN IF ADVISED OF SUCH DAMAGES. The entire risk as to the quality and performance of software developed using the specifications is borne by you. This disclaimer of warranty constitutes an essential part of this Agreement. RESTRICTED RIGHTS LEGEND Use, duplication or disclosure by the U.S. Government subcontractor is subject to the restrictions set forth in subparagraph (c) (1) (ii) of The Rights in Technical Data and Computer Software Clause at DFARS 252.227-7013 or in subparagraph (c)(1) and (2) of the Commercial Computer Software - Restricted Rights clauses at 48 C.F.R. 52.227-19 or as specified in 48 C.F.R. 227-7202-2 of the DoD F.A.R. Supplement and its successors, or as specified in 48 C.F.R. 12.212 of the Federal Acquisition Regulations and its successors, as applicable. The specification copyright owners are as indicated above and may be contacted through the Object Management Group, 250 First Avenue, Needham, MA 02494, U.S.A. TRADEMARKS OMG OBJECT MANAGEMENT GROUP, CORBA, CORBA ACADEMY, CORBA ACADEMY & DESIGN, THE INFORMATION BROKERAGE, OBJECT REQUEST BROKER, OMG IDL, CORBAFACILITIES, CORBASERVICES, CORBANET, CORBAMED, CORBADOMAINS, GIOP, IIOP, OMA, CORBA THE GEEK, UNIFIED MODELING LANGUAGE, UML, and UML CUBE LOGO are registered trademarks or trademarks of the Object Management Group, Inc. Rational Software is a trademark of Rational Software Corporation. ISSUE REPORTING All OMG specifications are subject to continuous review and improvement. As part of this process we encourage readers to report any ambiguities, inconsistencies, or inaccuracies they may find by completing the Issue Reporting Form at http://www.omg.org/library/issuerpt.htm. Contents Foreword . xix Preface . xxi 1. UML Summary . 1-1 1.1 Overview . 1-1 1.2 Primary Artifacts of the UML . 1-2 1.2.1 UML-defining Artifacts . 1-2 1.2.2 Development Project Artifacts . 1-2 1.3 Motivation to Define the UML . 1-3 1.3.1 Why We Model . 1-3 1.3.2 Industry Trends in Software . 1-3 1.3.3 Prior to Industry Convergence . 1-4 1.4 Goals of the UML . 1-4 1.5 Scope of the UML . 1-6 1.5.1 Outside the Scope of the UML . 1-7 1.5.2 Comparing UML to Other Modeling Languages 1-8 1.5.3 Features of the UML . 1-9 1.6 UML - Past, Present, and Future . 1-11 1.6.1 UML 0.8 - 0.91 . 1-11 1.6.2 UML Partners . 1-12 1.6.3 UML - Present and Future . 1-13 2. UML Semantics . 2-1 Part 1 - Background 2.1 Introduction . 2-2 2.1.1 Purpose and Scope . 2-2 September 2001 OMG-Unified Modeling Language, v1.4 i Contents 2.1.2 Approach . 2-2 2.2 Language Architecture . 2-3 2.2.1 Four-Layer Metamodel Architecture . 2-3 2.2.2 Package Structure . 2-5 2.3 Language Formalism . 2-7 2.3.1 Levels of Formalism . 2-8 2.3.2 Package Specification Structure . 2-9 2.3.3 Use of a Constraint Language . 2-10 2.3.4 Use of Natural Language . 2-10 2.3.5 Naming Conventions and Typography . 2-10 Part 2 - Foundation 2.4 Foundation Package . 2-11 2.5 Core . 2-12 2.5.1 Overview . 2-12 2.5.2 Abstract Syntax . 2-12 2.5.3 Well-Formedness Rules . 2-52 2.5.4 Detailed Semantics . 2-65 2.6 Extension Mechanisms . 2-74 2.6.1 Overview . 2-74 2.6.2 Abstract Syntax . 2-76 2.6.3 Well-Formedness Rules . 2-80 2.6.4 Detailed Semantics . 2-82 2.6.5 Notes . 2-83 2.7 Data Types . 2-85 2.7.1 Overview . 2-85 2.7.2 Abstract Syntax . 2-85 Part 3 - Behavioral Elements 2.8 Behavioral Elements Package . 2-94 2.9 Common Behavior . 2-94 2.9.1 Overview . 2-94 2.9.2 Abstract Syntax . 2-95 2.9.3 Well-Formedness Rules . 2-107 2.9.4 Detailed Semantics . 2-113 2.10 Collaborations . 2-115 2.10.1 Overview . 2-115 2.10.2 Abstract Syntax . 2-117 2.10.3 Well-Formedness Rules . 2-124 2.10.4 Detailed Semantics . 2-129 2.10.5 Notes . 2-134 ii OMG-Unified Modeling Language, v1.4 September 2001 Contents 2.11 Use Cases . 2-134 2.11.1 Overview . 2-134 2.11.2 Abstract Syntax . 2-135 2.11.3 Well-FormednessRules . 2-138 2.11.4 Detailed Semantics . 2-140 2.11.5 Notes . 2-145 2.12 State Machines . 2-145 2.12.1 Overview . 2-145 2.12.2 Abstract Syntax . 2-146 2.12.3 Well-FormednessRules . 2-156 2.12.4 Detailed Semantics . 2-160 2.12.5 Notes . 2-170 2.13 Activity Graphs . 2-175 2.13.1 Overview . 2-175 2.13.2 Abstract Syntax . 2-176 2.13.3 Well-Formedness Rules . 2-181 2.13.4 Detailed Semantics . 2-184 2.13.5 Notes . 2-186 Part 4 - General Mechanisms 2.14 Model Management . 2-187 2.14.1 Overview . 2-187 2.14.2 Abstract Syntax . 2-187 2.14.3 Well-Formedness Rules . 2-192 2.14.4 Semantics . 2-197 2.14.5 Notes . 2-203 3. UML Notation Guide . 3-1 Part 1 - Background 3.1 Introduction . 3-5 Part 2 - Diagram Elements 3.2 Graphs and Their Contents . 3-6 3.3 Drawing Paths . 3-7 3.4 Invisible Hyperlinks and the Role of Tools . 3-7 3.5 Background Information . 3-8 3.5.1 Presentation Options . 3-8 3.6 String . 3-8 3.6.1 Semantics . ..
Load more

Recommended publications
  • The Essence Initiative
    The Essence Initiative Ivar Jacobson Agenda Specific Problems A Case for Action - Defining a solid theoretical base - Finding a kernel of widely agreed elements Using the Kernel Final Words Being in the software development business Everyone of us knows how to develop our software, but as a community we have no widely accepted common ground A CASE FOR ACTION STATEMENT • Software engineering is gravely hampered today by immature practices. Specific problems include: – The prevalence of fads more typical of fashion industry than of an engineering discipline. – The lack of a sound, widely accepted theoretical basis. – The huge number of methods and method variants, with differences little understood and artificially magnified. – The lack of credible experimental evaluation and validation. – The split between industry practice and academic research. Agenda Specific Problems A Case for Action - Defining a solid theoretical base - Finding a kernel of widely agreed elements Using the Kernel Final Words The SEMAT initiative Software Engineering Method and Theory www.semat.org Founded by the Troika in September 2009: Ivar Jacobson – Bertrand Meyer – Richard Soley What are we going to do about it? The Grand Vision We support a process to refound software engineering based on a solid theory, proven principles and best practices The Next Steps Defining A Kernel of a solid widely agreed theoretical basis elements There are probably more than 100,000 methods Desired solution: Method Architectureincl. for instance SADT, Booch, OMT, RUP, CMMI, XP, Scrum, Lean, Kanban There are around 250 The Kernel includes identified practices incl such elements as for instance use cases, Requirement, use stories, features, Software system, components, Work, Team, Way-of- working, etc.
    [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]
  • Using the UML for Architectural Description?
    Using the UML for Architectural Description? Rich Hilliard Integrated Systems and Internet Solutions, Inc. Concord, MA USA [email protected] Abstract. There is much interest in using the Unified Modeling Lan- guage (UML) for architectural description { those techniques by which architects sketch, capture, model, document and analyze architectural knowledge and decisions about software-intensive systems. IEEE P1471, the Recommended Practice for Architectural Description, represents an emerging consensus for specifying the content of an architectural descrip- tion for a software-intensive system. Like the UML, IEEE P1471 does not prescribe a particular architectural method or life cycle, but may be used within a variety of such processes. In this paper, I provide an overview of IEEE P1471, describe its conceptual framework, and investigate the issues of applying the UML to meet the requirements of IEEE P1471. Keywords: IEEE P1471, architectural description, multiple views, view- points, Unified Modeling Language 1 Introduction The Unified Modeling Language (UML) is rapidly maturing into the de facto standard for modeling of software-intensive systems. Standardized by the Object Management Group (OMG) in November 1997, it is being adopted by many organizations, and being supported by numerous tool vendors. At present, there is much interest in using the UML for architectural descrip- tion: the techniques by which architects sketch, capture, model, document and analyze architectural knowledge and decisions about software-intensive systems. Such techniques enable architects to record what they are doing, modify or ma- nipulate candidate architectures, reuse portions of existing architectures, and communicate architectural information to others. These descriptions may the be used to analyze and reason about the architecture { possibly with automated support.
    [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]
  • UML : Introduction
    UML : introduction Achref El Mouelhi Docteur de l’universite´ d’Aix-Marseille Chercheur en programmation par contrainte (IA) Ingenieur´ en genie´ logiciel [email protected] H & H: Research and Training 1 / 16 UML : introduction Achref El Mouelhi Docteur de l’universite´ d’Aix-Marseille Chercheur en programmation par contrainte (IA) Ingenieur´ en genie´ logiciel [email protected] H & H: Research and Training 2 / 16 UML © Achref EL MOUELHI © Pour construire cette maison Il faut etablir´ un plan avant H & H: Research and Training 3 / 16 UML La realisation´ d’une application peut passer par plusieurs etapes´ Definition´ des besoins Analyse Conception Developpement´ Test Validation© Achref EL MOUELHI © Deploiement´ Maintenance ... H & H: Research and Training 4 / 16 UML Ou` est UML dans tout c¸a ? UML permet de modeliser´ toutes les etapes´ du developpement´ d’une application de l’analyse au deploiement´ (en utilisant plusieurs diagrammes). © Achref EL MOUELHI © H & H: Research and Training 5 / 16 UML UML : Unified Modeling Language Un langage de modelisation´ unifie´ Ce n’est pas un langage de programmation Independant´ de tout langage de programmation (objet ou autre) Un langage base´ sur des notations graphiques Constitues´ de plusieurs graphes (diagrammes) permettant de visualiser© la Achref future application EL MOUELHI de plusieurs angles © differents´ Une norme maintenue par l’OMG (Object Management Group : organisation mondiale cre´ee´ en 1989 pour standardiser le modele` objet) H & H: Research and Training 6 / 16 Exemple
    [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]
  • Formal Specification Methods What Are Formal Methods? Objectives Of
    ICS 221 Winter 2001 Formal Specification Methods What Are Formal Methods? ! Use of formal notations … Formal Specification Methods ! first-order logic, state machines, etc. ! … in software system descriptions … ! system models, constraints, specifications, designs, etc. David S. Rosenblum ! … for a broad range of effects … ICS 221 ! correctness, reliability, safety, security, etc. Winter 2001 ! … and varying levels of use ! guidance, documentation, rigor, mechanisms Formal method = specification language + formal reasoning Objectives of Formal Methods Why Use Formal Methods? ! Verification ! Formal methods have the potential to ! “Are we building the system right?” improve both software quality and development productivity ! Formal consistency between specificand (the thing being specified) and specification ! Circumvent problems in traditional practices ! Promote insight and understanding ! Validation ! Enhance early error detection ! “Are we building the right system?” ! Develop safe, reliable, secure software-intensive ! Testing for satisfaction of ultimate customer intent systems ! Documentation ! Facilitate verifiability of implementation ! Enable powerful analyses ! Communication among stakeholders ! simulation, animation, proof, execution, transformation ! Gain competitive advantage Why Choose Not to Use Desirable Properties of Formal Formal Methods? Specifications ! Emerging technology with unclear payoff ! Unambiguous ! Lack of experience and evidence of success ! Exactly one specificand (set) satisfies it ! Lack of automated
    [Show full text]
  • Unified Modeling Language 2.0 Part 1 - Introduction
    UML 2.0 – Tutorial (v4) 1 Unified Modeling Language 2.0 Part 1 - Introduction Prof. Dr. Harald Störrle Dr. Alexander Knapp University of Innsbruck University of Munich mgm technology partners (c) 2005-2006, Dr. H. Störrle, Dr. A. Knapp UML 2.0 – Tutorial (v4) 2 1 - Introduction History and Predecessors • The UML is the “lingua franca” of software engineering. • It subsumes, integrates and consolidates most predecessors. • Through the network effect, UML has a much broader spread and much better support (tools, books, trainings etc.) than other notations. • The transition from UML 1.x to UML 2.0 has – resolved a great number of issues; – introduced many new concepts and notations (often feebly defined); – overhauled and improved the internal structure completely. • While UML 2.0 still has many problems, current version (“the standard”) it is much better than what we ever had formal/05-07-04 of August ‘05 before. (c) 2005-2006, Dr. H. Störrle, Dr. A. Knapp UML 2.0 – Tutorial (v4) 3 1 - Introduction Usage Scenarios • UML has not been designed for specific, limited usages. • There is currently no consensus on the role of the UML: – Some see UML only as tool for sketching class diagrams representing Java programs. – Some believe that UML is “the prototype of the next generation of programming languages”. • UML is a really a system of languages (“notations”, “diagram types”) each of which may be used in a number of different situations. • UML is applicable for a multitude of purposes, during all phases of the software lifecycle, and for all sizes of systems - to varying degrees.
    [Show full text]
  • Design by Contract: the Lessons of Ariane
    . Editor: Bertrand Meyer, EiffelSoft, 270 Storke Rd., Ste. 7, Goleta, CA 93117; voice (805) 685-6869; [email protected] several hours (at least in earlier versions of Ariane), it was better to let the computa- tion proceed than to stop it and then have Design by to restart it if liftoff was delayed. So the SRI computation continues for 50 seconds after the start of flight mode—well into the flight period. After takeoff, of course, this com- Contract: putation is useless. In the Ariane 5 flight, Object Technology however, it caused an exception, which was not caught and—boom. The exception was due to a floating- point error during a conversion from a 64- The Lessons bit floating-point value, representing the flight’s “horizontal bias,” to a 16-bit signed integer: In other words, the value that was converted was greater than what of Ariane can be represented as a 16-bit signed inte- ger. There was no explicit exception han- dler to catch the exception, so it followed the usual fate of uncaught exceptions and crashed the entire software, hence the onboard computers, hence the mission. This is the kind of trivial error that we Jean-Marc Jézéquel, IRISA/CNRS are all familiar with (raise your hand if you Bertrand Meyer, EiffelSoft have never done anything of this sort), although fortunately the consequences are usually less expensive. How in the world everal contributions to this made up of respected experts from major department have emphasized the European countries, which produced a How in the world could importance of design by contract report in hardly more than a month.
    [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]