UML 2 Toolkit, Penker Has Also Collaborated with Hans- Erik Eriksson on Business Modeling with UML: Business Practices at Work

Total Page:16

File Type:pdf, Size:1020Kb

UML 2 Toolkit, Penker Has Also Collaborated with Hans- Erik Eriksson on Business Modeling with UML: Business Practices at Work UML™ 2 Toolkit Hans-Erik Eriksson Magnus Penker Brian Lyons David Fado UML™ 2 Toolkit UML™ 2 Toolkit Hans-Erik Eriksson Magnus Penker Brian Lyons David Fado Publisher: Joe Wikert Executive Editor: Bob Elliott Development Editor: Kevin Kent Editorial Manager: Kathryn Malm Production Editor: Pamela Hanley Permissions Editors: Carmen Krikorian, Laura Moss Media Development Specialist: Travis Silvers Text Design & Composition: Wiley Composition Services Copyright 2004 by Hans-Erik Eriksson, Magnus Penker, Brian Lyons, and David Fado. All rights reserved. Published by Wiley Publishing, Inc., Indianapolis, Indiana Published simultaneously in Canada No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning, or otherwise, except as permitted under Section 107 or 108 of the 1976 United States Copyright Act, without either the prior written permission of the Publisher, or authorization through payment of the appropriate per-copy fee to the Copyright Clearance Center, Inc., 222 Rose- wood Drive, Danvers, MA 01923, (978) 750-8400, fax (978) 646-8700. Requests to the Pub- lisher for permission should be addressed to the Legal Department, Wiley Publishing, Inc., 10475 Crosspoint Blvd., Indianapolis, IN 46256, (317) 572-3447, fax (317) 572-4447, E-mail: [email protected]. Limit of Liability/Disclaimer of Warranty: While the publisher and author have used their best efforts in preparing this book, they make no representations or warranties with respect to the accuracy or completeness of the contents of this book and specifically disclaim any implied warranties of merchantability or fitness for a particular purpose. No warranty may be created or extended by sales representatives or written sales materials. The advice and strategies contained herein may not be suitable for your situation. You should consult with a professional where appropriate. Neither the publisher nor author shall be liable for any loss of profit or any other commercial damages, including but not limited to special, inci- dental, consequential, or other damages. For general information on our other products and services please contact our Customer Care Department within the United States at (800) 762-2974, outside the United States at (317) 572-3993 or fax (317) 572-4002. Trademarks: Wiley and the Wiley Publishing logo are trademarks or registered trademarks of John Wiley & Sons, Inc. and/or its affiliates. UML is a trademark of Object Management Group, Inc. All other trademarks are the property of their respective owners. Wiley Pub- lishing, Inc., is not associated with any product or vendor mentioned in this book. Wiley also publishes its books in a variety of electronic formats. Some content that appears in print may not be available in electronic books. Library of Congress Cataloging-in-Publication Data: Library of Congress Control Number: 2003015155 ISBN: 0-471-46361-2 Printed in the United States of America 10 9 8 7 6 5 4 3 2 1 Contents OMG Press Books in Print xiv About the OMG xvii 2003 OMG Press Advisory Board xix Preface for the Second Edition xxi About the Authors xxv Acknowledgments xxvii Chapter 1 What Is UML? 1 The Purpose of Modeling 2 Software Development, Methods, and Models 4 The Method Wars 6 Acceptance of UML 8 The Object Management Group 9 Unified Modeling Language Elements 9 Methods and Modeling Languages 10 Object-Oriented Software Development 11 Concepts of Object Orientation 12 Business Engineering 13 Disciplines of System Development 13 Requirements 14 Analysis 14 Design 14 Implementation 15 Test 15 Relevant Changes in UML 2 15 Summary 17 v vi Contents Chapter 2 An Overview of UML 19 Views 21 Use-Case View 22 Logical View 23 Implementation View 23 Process View 23 Deployment View 24 Diagrams 24 Use-Case Diagram 24 Class Diagram 25 Object Diagram 25 State Machines 26 Activity Diagram 28 Interaction Diagrams 29 Sequence Diagram 29 Communication Diagram 30 Interaction Overview Diagram 31 Component Diagram 32 Deployment Diagram 32 Composite Structure Diagram 33 Model Elements 34 General Mechanisms 36 Adornments 36 Comments 37 Specifications 37 Extending UML 38 Stereotypes 39 Tagged Values 40 Constraints 40 Model Driven Architecture with UML 41 Software Development Process and UML 43 Tools 45 Drawing Support 47 Model Repository 47 Navigation 48 Multiuser Support 49 Code Generation 49 Reverse Engineering 50 Integration 50 Interchange of Models 51 Tool Options 52 Relevant Changes in UML 2 53 Summary 55 Chapter 3 Use-Case Modeling 57 Basics of Use Cases 58 Use-Case Diagram 60 System 61 Contents vii Actors 62 Finding Actors 63 Actors in UML 64 Relationships between Actors 65 Use Cases 66 Finding Use Cases 67 Use Cases in UML 67 Relationships between Use Cases 68 Generalization Relationship 68 Extend Relationship 69 Include Relationship 70 Organizing Use Cases 71 Describing Use Cases 74 Assessing Use Cases 76 Testing Use Cases 77 Use Cases and Requirements Management 78 Realizing Use Cases 79 Relevant Changes in UML 2 83 Summary 84 Chapter 4 Classes, Objects, and Their Relationships 87 Classes and Objects 87 Class Diagram 90 Finding Classes 90 Name Compartment 91 Attributes Compartment 92 Java Implementation 95 Operations Compartment 95 Using Primitive Types 99 Relationships 99 Associations 100 Normal Association 100 Object Diagram 103 Recursive Association 103 Java Implementation 104 Roles in an Association 106 Qualified Association 106 Xor Constraint 108 Ordered Association 109 Association Class 109 Ternary Association 110 Aggregation 111 Aggregate 112 Shared Aggregation 112 Composition Aggregation 113 viii Contents Generalization 115 Basic Generalization 116 Advanced Generalization 123 Generalization Set 123 Powertype 125 Dependencies and Abstractions 126 Constraints, Expressions, and Derivations 128 Interfaces and Ports 131 Java Implementation 133 Ports 134 Packages 135 Templates 140 Relevant Changes in UML 2 141 Summary 142 Chapter 5 Dynamic Modeling 145 State Machines 147 States and Transitions 147 Event-Signature 151 Guard-Condition 152 Action-Expression 153 Send-Clause 154 Events 155 Java Implementation 157 Sending Messages Between State Machines 159 Substates 160 Entry, Exit, and Terminate Indicators 161 History Indicator 162 Activity Diagrams 163 Actions and Edges 163 Activity Partitions 166 Objects 168 Signals 169 Pins 170 Business Modeling with Activity Diagrams 171 Interaction Diagrams 173 Sequence Diagrams 174 Generic and Instance Form 174 Concurrent Objects 176 Combined Fragments 176 Interaction Occurrences 179 Creating and Destroying Objects 179 Recursion 180 Interaction Overviews 180 Communication Diagrams 182 Message Labels 183 Using Communication Diagrams 185 Relevant Changes in UML 2 188 Summary 188 Contents ix Chapter 6 Advanced Dynamic Modeling Illustrated by Real-Time Systems 191 What Is a Real-Time System? 191 Attributes of a Real-Time System 192 Types of Real-Time Systems 192 Concepts in UML for Real-Time Systems 193 Active Classes and Active Objects 193 Active Class Implementation 194 Active Object Interactions 194 Communication 195 Events and Triggers 197 Signals 198 Messages 199 Synchronization and Concurrency 200 Synchronization Issues 201 Synchronization Mechanisms 202 Fault Tolerance 203 Implementation in Java 204 UML Time Elements 205 Real-Time Modeling in UML Diagrams 206 Activity Diagrams 207 The Token Flow Model in Activity Diagrams 207 Chocolate Factory: Streaming Input and Output Example 208 Processing Applications: Expansion Regions and Structured Activities 210 Investment Simulation: Interruptible Regions and Storage 213 House Alarm: Static Structure for Dynamic Messages 216 Static Diagrams 216 Detailed Activity Diagram Showing Message Handling 221 Interaction Diagrams 223 Communication Diagrams 223 Basic Sequence Diagram 224 Advanced Sequence Diagrams with Combined Fragments 227 Timing Diagrams 230 Behavioral State Machines 231 Handling Active Classes and Objects 231 State Machine Regions and Concurrency 232 Handling Triggers on Events in Composite States 234 Transitions and Synchronization 235 Complex State Machines and Run-to-Completion Semantics 236 State Machine Redefinition and Reuse 238 Protocol State Machines 239 Advanced Modeling, Design, and Optimization 241 Design Overview 242 Modeling Processes and Threads with Objects 242 Designing Active Classes 243 x Contents Design and the Implementation Environment 244 Approaches to Showing Behavioral Diagrams 244 Performance Optimization 246 Design Optimization 247 Optimization and the Operating System 247 Relevant Changes in UML 2 248 Summary 249 Chapter 7 Representing Architecture 251 Logical Architecture 254 Logical Architecture Structure 254 Components 255 Collaborations 257 Composite Structure Diagrams 258 Patterns in Architecture 258 The Proxy Pattern 261 Modeling Patterns in UML 263 Showing Patterns in Diagrams 266 Patterns and Use Cases 269 Physical Architecture 270 Hardware 270 Software 271 Component Diagram 272 Deployment Diagram 273 Nodes 274 Communication Paths 275 Deployed Artifacts 275 Allocating Artifacts to Nodes 276 Relevant Changes in UML 2 277 Summary 278 Chapter 8 Extending UML 281 Standard Extensions Overview 282 Tagged Values and Properties 283 Standard Tag Value Examples 284 Tag Value from a Profile 285 Defining Your Own Tagged Values 286 Stereotypes 287 Creating a Stereotype 287 Examples of UML Stereotypes 289 Metainformation 289 Dependency Stereotypes 289 Customization with Components 290 Stereotypes Applied to
Recommended publications
  • UML Summary 1
    UML Summary 1 The UML Summary provides an introduction to the UML, discussing its motivation and history. Contents 1.1 Overview 1-3 1.2 Primary Artifacts of the UML 1-3 1.3 Motivation to Define the UML 1-4 1.4 Goals of the UML 1-5 1.5 Scope of the UML 1-7 1.6 UML - Past, Present, and Future 1-11 UML V1.3 alpha R5 March 1999 1-1 1 UML Summary 1-2 UML V1.3 alpha R5 March 1999 1.1 Overview 1UML Summary 1.1 Overview The Unified Modeling Language (UML) is a language for specifying, visualizing, constructing, and documenting the artifacts of software systems, as well as for business modeling and other non-software systems. The UML represents a collection of the best engineering practices that have proven successful in the modeling of large and complex systems. 1.2 Primary Artifacts of the UML What are the primary artifacts of the UML? This can be answered from two different perspectives: the UML definition itself and how it is used to produce project artifacts. 1.2.1 UML-defining Artifacts To aid the understanding of the artifacts that constitute the Unified Modeling Language itself, this document consists of the UML Semantics, UML Notation Guide, and UML Extensions chapters. 1.2.2 Development Project Artifacts The choice of what models and diagrams one creates has a profound influence upon how a problem is attacked and how a corresponding solution is shaped. Abstraction, the focus on relevant details while ignoring others, is a key to learning and communicating.
    [Show full text]
  • EB GUIDE Documentation Version 6.1.0.101778 EB GUIDE Documentation
    EB GUIDE documentation Version 6.1.0.101778 EB GUIDE documentation Elektrobit Automotive GmbH Am Wolfsmantel 46 D-91058 Erlangen GERMANY Phone: +49 9131 7701-0 Fax: +49 9131 7701-6333 http://www.elektrobit.com Legal notice Confidential and proprietary information. ALL RIGHTS RESERVED. No part of this publication may be copied in any form, by photocopy, microfilm, retrieval system, or by any other means now known or hereafter invented without the prior written permission of Elektrobit Automotive GmbH. ProOSEK®, tresos®, and street director® are registered trademarks of Elektrobit Automotive GmbH. All brand names, trademarks and registered trademarks are property of their rightful owners and are used only for description. Copyright 2015, Elektrobit Automotive GmbH. Page 2 of 324 EB GUIDE documentation Table of Contents 1. About this documentation ................................................................................................................ 15 1.1. Target audiences of the user documentation ......................................................................... 15 1.1.1. Modelers .................................................................................................................. 15 1.1.2. System integrators .................................................................................................... 16 1.1.3. Application developers ............................................................................................... 16 1.1.4. Extension developers ...............................................................................................
    [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]
  • UML Profile for Communicating Systems a New UML Profile for the Specification and Description of Internet Communication and Signaling Protocols
    UML Profile for Communicating Systems A New UML Profile for the Specification and Description of Internet Communication and Signaling Protocols Dissertation zur Erlangung des Doktorgrades der Mathematisch-Naturwissenschaftlichen Fakultäten der Georg-August-Universität zu Göttingen vorgelegt von Constantin Werner aus Salzgitter-Bad Göttingen 2006 D7 Referent: Prof. Dr. Dieter Hogrefe Korreferent: Prof. Dr. Jens Grabowski Tag der mündlichen Prüfung: 30.10.2006 ii Abstract This thesis presents a new Unified Modeling Language 2 (UML) profile for communicating systems. It is developed for the unambiguous, executable specification and description of communication and signaling protocols for the Internet. This profile allows to analyze, simulate and validate a communication protocol specification in the UML before its implementation. This profile is driven by the experience and intelligibility of the Specification and Description Language (SDL) for telecommunication protocol engineering. However, as shown in this thesis, SDL is not optimally suited for specifying communication protocols for the Internet due to their diverse nature. Therefore, this profile features new high-level language concepts rendering the specification and description of Internet protocols more intuitively while abstracting from concrete implementation issues. Due to its support of several concrete notations, this profile is designed to work with a number of UML compliant modeling tools. In contrast to other proposals, this profile binds the informal UML semantics with many semantic variation points by defining formal constraints for the profile definition and providing a mapping specification to SDL by the Object Constraint Language. In addition, the profile incorporates extension points to enable mappings to many formal description languages including SDL. To demonstrate the usability of the profile, a case study of a concrete Internet signaling protocol is presented.
    [Show full text]
  • Complete Code Generation from UML State Machine
    Complete Code Generation from UML State Machine Van Cam Pham, Ansgar Radermacher, Sebastien´ Gerard´ and Shuai Li CEA, LIST, Laboratory of Model Driven Engineering for Embedded Systems, P.C. 174, Gif-sur-Yvette, 91191, France Keywords: UML State Machine, Code Generation, Semantics-conformance, Efficiency, Events, C++. Abstract: An event-driven architecture is a useful way to design and implement complex systems. The UML State Machine and its visualizations are a powerful means to the modeling of the logical behavior of such an archi- tecture. In Model Driven Engineering, executable code can be automatically generated from state machines. However, existing generation approaches and tools from UML State Machines are still limited to simple cases, especially when considering concurrency and pseudo states such as history, junction, and event types. This paper provides a pattern and tool for complete and efficient code generation approach from UML State Ma- chine. It extends IF-ELSE-SWITCH constructions of programming languages with concurrency support. The code generated with our approach has been executed with a set of state-machine examples that are part of a test-suite described in the recent OMG standard Precise Semantics Of State Machine. The traced execution results comply with the standard and are a good hint that the execution is semantically correct. The generated code is also efficient: it supports multi-thread-based concurrency, and the (static and dynamic) efficiency of generated code is improved compared to considered approaches. 1 INTRODUCTION Completeness: Existing tools and approaches mainly focus on the sequential aspect while the concurrency The UML State Machine (USM) (Specification and of state machines is limitedly supported.
    [Show full text]
  • Part I Environmental Diagrams
    Adaptive Software Engineering G22.3033-007 Session 3 – Sub-Topic Presentation 1 Use Case Modeling Dr. Jean-Claude Franchitti New York University Computer Science Department Courant Institute of Mathematical Sciences 1 Part I Environmental Diagrams 2 1 What it is • Environmental Diagram Rent Video Video Store Pay Information System Employees Clerk Customer Payroll Clerk 3 What it is • A picture containing all the important players (Actors) • Includes players both inside and outside of the system • Actors are a critical component • External events are a second critical component 4 2 Creating the Diagram • To create an environmental diagram • 1. Identify all the initiating actors • 2. Identify all the related external events associated with each actor 5 Why it is used • A diagram is needed to show the context or scope of the proposed system • At this time actors and external events are the critical components • It is helpful to include all the participants as well 6 3 Creating the Diagram • 3. Identify all the participating Actors • These actors may be inside (internal) or outside (external) to the system 7 Creating the Diagram • Examples of an internal actor – Clerk who enters the purchase into a Point of Sale terminal – Clerk who places paper in the printer – Accountant who audits report 8 4 Creating the Diagram • Examples of an external actor – Accountant who audits report – A credit authorizing service – A DMV check for renting a car 9 Creating the Diagram •4.Draw a cloud • 5. Then draw initiating actors on the left of the cloud • 6. Then draw participating external actors outside the cloud • 7.
    [Show full text]
  • Leveraging Software Development Approaches in Systems Engineering
    Raytheon Leveraging Software Development Approaches in Systems Engineering Rick Steiner Engineering Fellow Raytheon Integrated Defense Systems [email protected] 6 May 2004 Naval Postgraduate School SI4000 Project Seminar Copyright © 2003 Raytheon Company UNPUBLISHED WORK ALL RIGHTS RESERVED 1 We’re going to talk about: Raytheon • Why Software Tools exist, why Systems Engineers should care • Software vs. SE as a discipline – key differences • The importance of requirements – Different requirement/system development approaches – Pros & cons of each, and how they relate to software approaches • How Use Cases relate to Requirements – Hints on how to manage use case development • How Object Oriented Design relates to Functional Analysis – or not! • What graphical languages can help (UML, SysML) • The promise of Model Driven Architecture (MDA) Copyright © 2003 Raytheon Company UNPUBLISHED WORK ALL RIGHTS RESERVED 2 Software Development Crisis Raytheon • In the 1980’s, software development underwent a crisis: – Software was RAPIDLY proliferating – Software was becoming very complex • Software on top of Software (OS, Application) • Software talking to Software (interfaces) – Software development delays were holding up system delivery – Software was becoming very expensive to develop and maintain – Software development effort was becoming very hard to estimate – Software reliability was becoming problematic – Existing techniques were proving inadequate to manage the problem • Reasons: – Economics • Processing hardware (silicon) got cheap –
    [Show full text]
  • Mutating UML State Machine Behavior with Semantic Mutation Operators
    Mutating UML State Machine Behavior with Semantic Mutation Operators Anna Derezinska a and Łukasz Zaremba Institute of Computer Science, Warsaw University of Technology, Nowowiejska 15/19, Warsaw, Poland Keywords: Model-Driven Software Development, State Machine, Code Generation, Mutation Testing, Framework for Executable UML (FXU), C#. Abstract: In Model-Driven Software Development (MDSD), an application can be built using classes and their state machines as source models. The final application can be tested as any source code. In this paper, we discuss a specific approach to mutation testing in which modifications relate to different variants of behavioural features modelled by UML state machines, while testing deals with standard executions of the final application against its test cases. We have proposed several mutation operators aimed at mutating behaviour of UML state machines. The operators take into account event processing, time management, behaviour of complex states with orthogonal regions, and usage of history pseudostates. Different possible semantic interpretations are associated with each operator. The operators have been implemented in the Framework for eXecutable UML (FXU). The framework, that supports code generation from UML classes and state machines and building target C# applications, has been extended to realize mutation testing with use of multiple libraries. The semantic mutation operators have been verified in some MDSD experiments. 1 INTRODUCTION satisfying selected criteria (Jia and Harman, 2011). In a standard mutation testing process, syntactic Model-Driven Software Development (MDSD) can changes, so-called mutations, are injected into a be aimed at production of high quality software in a source code and supposed to be detected by test cases.
    [Show full text]
  • A Formalism for Specifying Model Merging Conflicts Mohammadreza Sharbaf, Bahman Zamani, Gerson Sunyé
    A Formalism for Specifying Model Merging Conflicts Mohammadreza Sharbaf, Bahman Zamani, Gerson Sunyé To cite this version: Mohammadreza Sharbaf, Bahman Zamani, Gerson Sunyé. A Formalism for Specifying Model Merging Conflicts. System Analysis and Modelling (SAM) conference, Oct 2020, Virtual Event, Canada. 10.1145/3419804.3421447. hal-02930770 HAL Id: hal-02930770 https://hal.archives-ouvertes.fr/hal-02930770 Submitted on 4 Sep 2020 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. A Formalism for Specifying Model Merging Conflicts Mohammadreza Sharbaf ∗ Bahman Zamani Gerson Sunyé MDSE Group, University of Isfahan MDSE Group, University of Isfahan LS2N, University of Nantes Isfahan, Iran Isfahan, Iran Nantes, France [email protected] [email protected] [email protected] ABSTRACT sites. Each of the participants focuses on specific aspects of the Verifying the consistency of model merging is an important step to- system and locally modifies only a particular part of the model. wards the support for team collaboration in software modeling and When participants deliver locally modified models, those need to evolution. Since merging conflicts are inevitable, this has triggered be integrated into a common relevant model for continuing the soft- intensive research on conflict management in different domains.
    [Show full text]
  • Activity Diagrams & State Machines
    2IW80 Software specification and architecture Activity diagrams & State machines Alexander Serebrenik This week sources Slides by Site by David Meredith, Kirill Fakhroutdinov Aalborg University, DK GE Healthcare, USA Before we start… True or False? 1. A web server can be an actor in a use case diagram. 2. Guarantee is an action that initiates the use case. 3. Use case “Assign seat” includes the use case “Assign window seat”. 4. Generalization is represented by an arrow with a hollow triangle head. 5. Every use case might involve only one actor. / SET / W&I 24-2-2014 PAGE 2 Before we start… T, unless it is a part of the system True or False? you want to model 1. A web server can be an actor in a use case diagram. Guarantee is a postcondition. An action that initiates the use case is called “trigger”. 2. Guarantee is an action that initiates the use case. 3. Use case “Assign seat” includes the use case “Assign window seat”. 4. Generalization is represented by an arrow with a hollow triangle head. 5. Every use case might involve only one actor. / SET / W&I 24-2-2014 PAGE 3 Before we start… True or False? 1. A web server can be an actor in a use case diagram. 2. GuaranteeNo, the correct is an relationaction that here initiates is extension the use (<<extend>>); case. <<include>> suggests that “Assign window seat” is always called whenever “Assign seat” is executed. 3. Use case “Assign seat” includes the use case “Assign window seat”. 4. Generalization is represented by an arrow with a hollow triangle head.
    [Show full text]
  • Institution-Based Encoding and Verification of Simple UML
    View metadata, citation and similar papers at core.ac.uk brought to you by CORE provided by Cronfa at Swansea University Institution-based Encoding and Verification of Simple UML State Machines in CASL/SPASS Tobias Rosenberger1;2, Saddek Bensalem2, Alexander Knapp3, and Markus Roggenbach1 1 Swansea University, U.K. ft.rosenberger.971978; [email protected] 2 Université Grenoble Alpes, France [email protected] 3 Universität Augsburg, Germany [email protected] Abstract. We present a new approach on how to provide institution-based seman- tics for UML state machines. Rather than capturing UML state machines directly # as an institution, we build up a new logical framework MD into which UML # state machines can be embedded. A theoroidal comorphism maps MD into the Casl institution. This allows for symbolic reasoning on UML state machines. By utilising the heterogeneous toolset HeTS that supports Casl, a broad range of verification tools, including the automatic theorem prover Spass, can be combined in the analysis of a single state machine. 1 Introduction As part of a longstanding line of research [9,10,19,8], we set out on a general programme to bring together multi-view system specification with UML diagrams and heterogeneous specification and verification based on institution theory, giving the different system views both a joint semantics and richer tool support. Institutions, a formal notion of a logic, are a principled way of creating such joint semantics. They make moderate assumptions about the data constituting a logic, give uniform notions of well-behaved translations between logics and, given a graph of such translations, automatically give rise to a joint institution.
    [Show full text]
  • Network Protocol Design and Evaluation
    Network Protocol Design and Evaluation 04 - Protocol Specification, Part I Stefan Rührup University of Freiburg Computer Networks and Telematics Summer 2009 Overview ‣ In the last chapter: • The development process (overview) ‣ In this chapter: • Specification • State machines and modeling languages • UML state charts and sequence diagrams • SDL and MSC (Part II) Network Protocol Design and Evaluation Computer Networks and Telematics Stefan Rührup, Summer 2009 2 University of Freiburg What are we modeling? Transitional Systems Reactive Systems input-output transformation event-driven e.g. scientific computation, compilers e.g. communication protocols, operating systems, control systems correctness criteria: correctness criteria: - termination - non-termination under normal - correctness of input-output conditions transformation - correctness of event-response actions formal models describe event-response sequences, including state information [S. Leue, Design of Reactive Systems, Lecture Notes, 2002] Network Protocol Design and Evaluation Computer Networks and Telematics Stefan Rührup, Summer 2009 3 University of Freiburg Specification with State Machines ‣ A protocol interacts with the environment • triggered by events • responds by performing actions • behaviour depends on the history of past events, i.e. the state event 1 state 1 state 2 action action event 2 ‣ state machines do not model the data flow, but the flow of control Network Protocol Design and Evaluation Computer Networks and Telematics Stefan Rührup, Summer 2009 4 University of
    [Show full text]