DOCSLIB.ORG

A Model of Bcms Using the Umple Model-Oriented Programming

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
A Model of Bcms Using the Umple Model-Oriented Programming A Model of bCMS Using the Umple Model-Oriented Programming Approach Timothy Lethbridge Electrical Engineering and Computer Science University of Ottawa, K1N 6N5 Canada +1 613 562-5800 x6685 [email protected] ABSTRACT unnecessary and strongly discouraged, since any needed In this paper we present a model developed using the Umple editing can be done in the original source. model-oriented programming technology. We have modeled the • The processes of modeling and programming are also unified: bCMS crisis management system, which has been set as a Programming is seen simply as development at a lower level common modeling challenge for the Comparing Modeling of abstraction, while modeling is seen as development at a Approaches workshop. We demonstrate modeling of the class higher level of abstraction. We will refer to the people who do structure of the system and the state machine used to co-ordinate the modeling/programming task as developers, to be generic the crisis management effort. This model captures some of the • A program developed using model-oriented programming at benefits of model-oriented programming: The model looks like a any level of abstraction can be ‘partial’, resulting in a sketch, program, so it can be extensively documented inline using or incomplete system. However, as long as it is syntactically comments, and easily edited. The textual model is designed to be and semantically correct, even a partial model-oriented highly readable, but if desired can also be viewed and edited as a program can be compiled; an incomplete model would diagram. Mixin and product-line capabilities of Umple are also generate an API, for example. used. • The types of modeling constructs are not limited by the approach. Currently implemented examples include class diagrams, state diagrams, constructs for databases (keys), and General Terms various design patterns. Design, Language • A visualization of the model/program may be available. In such a case, the text and diagrams are views of the same Keywords underlying model/program. Umple, Model-Oriented Programming, UML. • A developer can create a ‘pure’ model that has only modeling constructs. When doing this he or she is modeling textually. 1. INTRODUCTION On the other hand a developer might start with a program in a standard programming language, and convert it to a model, by We present a model of the bCMS system [1] developed using the transforming parts of the code into modeling elements with a Umple model-oriented programming technology. higher level of abstraction. Doing so would typically reduce We start with an overview of what we mean by model-oriented the volume of code substantially (by between 10% and 90% programming and a few facts about Umple and the modeling depending on the case [2]). approach in this paper. The remainder of the paper shows the model. 1.2 Umple: An Example of a Model-Oriented Programming Technology 1.1 Model-Oriented Programming We have been developing Umple [3][4][5] since 2007 as a Model-oriented programming is a modeling approach that has the technology to explore the ideas of model-oriented programming. following properties: Umple has support for UML class diagrams and state machines, plus aspect-orientation and certain design patterns. Various other • Model and code are a unified textual artifact that can be features are under development, particularly extensions for UML version controlled, edited in a text editor, and operated on by component diagrams and real-time profiles. any standard tool that works with text. The textual notation is designed to be as readable by humans as possible, as such Umple supports product lines and feature-driven development in XML, the basis for many textual modeling languages, has two ways: It has a mix-in capability that allows constructing a been avoided. system from different configurations of parts. This capability • Modeling constructs are added as first-class entities and as applies to the base language (e.g. Java) too, so for example parsimoniously as possible to existing programming different Java methods can be mixed in to give a different version languages, such as Java, PHP, C++ etc. of the same class for two different members of a product line. • All modeling constructs result in high-quality generated code Umple also has an implementation of VML (Variability Modeling when compiled, in the same manner as the existing language Language) [6] that can be used to put together different constructs generate bytecode or machine code. So-called configurations of features; it leverages the mixin capability. ‘round trip engineering’ (editing of generated code with Umple has been used to create a wide variety of systems, propagation of changes to the source) is conceptually including the Umple compiler itself. There is an online tool [7] that allows concurrent editing of graphical and textual views of a 2. THE MODEL system. Umple is also used in the classroom [8] and has proved We present the model as several submodels. For the most part we effective at helping students learn UML present the models using Umple source code. We have omitted the parts of the system that would be written in Java, since this 1.3 Modeling Approach exercise is about pure modeling. The model shows names of When using Model-Oriented Programming starting with a set of methods as method calls in state machine actions, but the requirements (as opposed to a legacy system), with the intent of algorithms for doing such things as planning the routes are creating a new system, the following is an extremely brief sketch omitted. of the suggested approach, and the approach used in developing the model presented in this paper. 2.1 Submodel for Routes and Locations • Develop use cases if they are not already present. In order to enable the system to compute routes and assign them • Start by marking up the requirements and use cases, to vehicles, among other capabilities, bCMS needs a minimal identifying the modeling elements such as classes, geographic information system (GIS) capability. We have associations, generalizations and states. This is as described modeled this first. by Lethbridge and Laganière [9]. Figure 1 shows the class diagram. This has been drawn by • In an agile manner, build versions of the model/program using UmpleOnline [7] from the Umple model/code shown Umple, starting with the central core of the system. At each subsequently. iteration, it should be possible to compile the system, and to execute test cases and skeleton front-ends to render it executable (for this paper we compiled the model to partially validate it, but omitted testing, since the volume of material would be too great to present here). For the work presented in this paper, we were given a reasonable set of requirements including sketches of use cases. We converted the pdf file to Word, and then marked up the Word document with different coloured highlighting as we scanned it for modeling constructs. In particular we focused on finding classes, associations, attributes, states, events and generalizations. We also took note of the variants required. We identified logical subsystems and worked on them independently. Then we worked on some variants. If the paper is selected for inclusion in the workshop we will perform additional iterations to improve it. 1.4 Classification of the Approach As required by the call for contributions, we present the categorization of our approach: Classification of the approach as either aspect-oriented, feature-oriented, object-oriented, subject-oriented, or any other paradigm: The approach is fundamentally ‘model-oriented programming’, which is at its base object oriented, but also incorporates feature- oriented and aspect-oriented capabilities. Fig. 1. Class diagram of the Routes and Locations submodel. Statement classifying the approach in terms of its software development phases: The Umple source of this model is as follows. The file itself has been incorporated as an example in the Umple user manual at The model includes a ‘system domain model’ (as defined in [9], http://www.umple.org/RoutesAndLocations.html and with a small amount of added code in state machine transitions. UmpleOnline using the following URL: The approach itself can be used for high-level design, low-level http://try.umple.org?example=RoutesAndLocations. design, implementation and evolution, since the same artifact is used throughout, with additional details added at each step. To understand the syntax or semantics readers are urged to consult the user manual at http://manual.umple.org. Description of what is modeled: // RoutesAndLocations.ump We have focused on modeling the core system, and have // demonstrated how we can model some of the variants as mixins. // Author: Timothy C. Lethbridge Since the approach can be continued until the system is fully implemented, we have left various details incomplete. For namespace routesAndLocations; example we have not modeled the SOAP communication protocol. Umple is being extended to generate code for inter- /* * This file describes reusable model elements component communication. * that are used in the bCMS Crisis Management * System. It is necessary to have a rudimentary * Graphical Information System such as described 1 -> * Turn illegalTurns; * in this submodel as part of bCMS in order to // Impossible turns , e.g. because of barriers, * plan routes and to track where crises are. // turning radius * This file has the necessary classes. 1 -> * Turn impossibleTurns; */ } /* /* * A CityMap contains the precompiled streets and * Turns are used to model illegal turns, e.g. * landmarks * turning left when there is 'no left turn' * This must be read in from the database on * allowed, or 'no U turn' allowed. * system initialization */ */ class Turn { class CityMap { RoadSegment turnFrom; singleton; RoadSegment turnTo; 1 -> * Landmark fireStn; } 1 -> * Landmark policeStn; 1 -> * Landmark otherLm; /* 1 -> * NamedRoad; * A named road might have the name of a street, } * the number of a highway, etc.
Load more

Recommended publications
  • Xtuml: Current and Next State of a Modeling Dialect
    xtUML: Current and Next State of a Modeling Dialect Cortland Starrett [email protected] 2 Outline • Introduc)on • Background • Brief History • Key Players • Current State • Related Modeling Dialects • Next State • Conclusion [email protected] 3 Introduc)on [email protected] 4 Background • Shlaer-Mellor Method (xtUML) – subject maers, separaon of concerns – data, control, processing – BridgePoint • data modeling (Object Oriented Analysis (OOA)) • state machines • ac)on language • interpre)ve execu)on • model compilaon [email protected] 5 History • 1988, 1991 Shlaer-Mellor Method published by Stephen Mellor and Sally Shlaer. • 2002 Executable UML established as Shlaer-Mellor OOA using UML notation. • 2004 Commercial Corporate Proprietary Licensed. • 2013 BridgePoint xtUML Editor goes open source under Apache 2.0. • 2014 all of BridgePoint (including Verifier and model compilers) goes open source under Apache and Creative Commons. • 2015 Papyrus Industry Consortium and xtUML/BridgePoint contribution • 2015 OSS of alternate generator engine (community building) • 2016 Papyrus-xtUML (BridgePoint) Eclipse Foundation governance • 2016 OSS contributions from industry, university and individuals [email protected] 6 Key Players • Saab • UK Crown • Agilent • Ericsson • Fuji-Xerox • Academia [email protected] 7 Current State • body of IP • self-hosng • Papyrus (and Papyrus Industry Consor)um) [email protected] 8 Related Dialects • MASL • Alf • UML-RT [email protected]
    [Show full text]
  • VI. the Unified Modeling Language UML Diagrams
    Conceptual Modeling CSC2507 VI. The Unified Modeling Language Use Case Diagrams Class Diagrams Attributes, Operations and ConstraintsConstraints Generalization and Aggregation Sequence and Collaboration Diagrams State and Activity Diagrams 2004 John Mylopoulos UML -- 1 Conceptual Modeling CSC2507 UML Diagrams I UML was conceived as a language for modeling software. Since this includes requirements, UML supports world modeling (...at least to some extend). I UML offers a variety of diagrammatic notations for modeling static and dynamic aspects of an application. I The list of notations includes use case diagrams, class diagrams, interaction diagrams -- describe sequences of events, package diagrams, activity diagrams, state diagrams, …more... 2004 John Mylopoulos UML -- 2 Conceptual Modeling CSC2507 Use Case Diagrams I A use case [Jacobson92] represents “typical use scenaria” for an object being modeled. I Modeling objects in terms of use cases is consistent with Cognitive Science theories which claim that every object has obvious suggestive uses (or affordances) because of its shape or other properties. For example, Glass is for looking through (...or breaking) Cardboard is for writing on... Radio buttons are for pushing or turning… Icons are for clicking… Door handles are for pulling, bars are for pushing… I Use cases offer a notation for building a coarse-grain, first sketch model of an object, or a process. 2004 John Mylopoulos UML -- 3 Conceptual Modeling CSC2507 Use Cases for a Meeting Scheduling System Initiator Participant
    [Show full text]
  • 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]
  • 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]
  • Unifying Modeling and Programming with ALF
    SOFTENG 2016 : The Second International Conference on Advances and Trends in Software Engineering Unifying Modeling and Programming with ALF Thomas Buchmann and Alexander Rimer University of Bayreuth Chair of Applied Computer Science I Bayreuth, Germany email: fthomas.buchmann, [email protected] Abstract—Model-driven software engineering has become more The Eclipse Modeling Framework (EMF) [5] has been and more popular during the last decade. While modeling the established as an extensible platform for the development of static structure of a software system is almost state-of-the art MDSE applications. It is based on the Ecore meta-model, nowadays, programming is still required to supply behavior, i.e., which is compatible with the Object Management Group method bodies. Unified Modeling Language (UML) class dia- (OMG) Meta Object Facility (MOF) specification [6]. Ideally, grams constitute the standard in structural modeling. Behavioral software engineers operate only on the level of models such modeling, on the other hand, may be achieved graphically with a set of UML diagrams or with textual languages. Unfortunately, that there is no need to inspect or edit the actual source code, not all UML diagrams come with a precisely defined execution which is generated from the models automatically. However, semantics and thus, code generation is hindered. In this paper, an practical experiences have shown that language-specific adap- implementation of the Action Language for Foundational UML tations to the generated source code are frequently necessary. (Alf) standard is presented, which allows for textual modeling In EMF, for instance, only structure is modeled by means of of software systems.
    [Show full text]
  • Plantuml Language Reference Guide (Version 1.2021.2)
    Drawing UML with PlantUML PlantUML Language Reference Guide (Version 1.2021.2) PlantUML is a component that allows to quickly write : • Sequence diagram • Usecase diagram • Class diagram • Object diagram • Activity diagram • Component diagram • Deployment diagram • State diagram • Timing diagram The following non-UML diagrams are also supported: • JSON Data • YAML Data • Network diagram (nwdiag) • Wireframe graphical interface • Archimate diagram • Specification and Description Language (SDL) • Ditaa diagram • Gantt diagram • MindMap diagram • Work Breakdown Structure diagram • Mathematic with AsciiMath or JLaTeXMath notation • Entity Relationship diagram Diagrams are defined using a simple and intuitive language. 1 SEQUENCE DIAGRAM 1 Sequence Diagram 1.1 Basic examples The sequence -> is used to draw a message between two participants. Participants do not have to be explicitly declared. To have a dotted arrow, you use --> It is also possible to use <- and <--. That does not change the drawing, but may improve readability. Note that this is only true for sequence diagrams, rules are different for the other diagrams. @startuml Alice -> Bob: Authentication Request Bob --> Alice: Authentication Response Alice -> Bob: Another authentication Request Alice <-- Bob: Another authentication Response @enduml 1.2 Declaring participant If the keyword participant is used to declare a participant, more control on that participant is possible. The order of declaration will be the (default) order of display. Using these other keywords to declare participants
    [Show full text]
  • Semantic Based Model of Conceptual Work Products for Formal Verification of Complex Interactive Systems
    Semantic based model of Conceptual Work Products for formal verification of complex interactive systems Mohcine Madkour1*, Keith Butler2, Eric Mercer3, Ali Bahrami4, Cui Tao1 1 The University of Texas Health Science Center at Houston, School of Biomedical Informatics, 7000 Fannin St Suite 600, Houston, TX 77030 2 University of Washington, Department of Human Centered Design and Engineering Box 352315, Sieg Hall, Room 208 Seattle, WA 98195 3 Brigham Young University Computer Science Department, 3334 TMCB PO Box 26576 Provo, UT 84602-6576 4 Medico System Inc. 10900 NE 8th Street Suite 900 Bellevue, WA 98004 * Corresponding author, email: [email protected], phone: (+1) 281-652-7118 Abstract - Many clinical workflows depend on interactive computer systems for highly technical, conceptual work 1. Introduction products, such as diagnoses, treatment plans, care Many critical systems require highly complex user interactions coordination, and case management. We describe an and a large number of cognitive tasks. These systems are automatic logic reasoner to verify objective specifications common in clinical health care and also many other industries for these highly technical, but abstract, work products that where the consequences of failure can be very expensive or are essential to care. The conceptual work products risky to human safety. Formal verification through model specifications serve as a fundamental output requirement, checking could reduce or prevent system failures, but several which must be clearly stated, correct and solvable. There is technical obstacles must be solved first. strategic importance for such specifications because, in We focus here on the abstract products of conceptual work turn, they enable system model checking to verify that that are foundational requirements that must be part of machine functions taken with user procedures are actually verification in a modern health care systems.
    [Show full text]
  • Sysml Distilled: a Brief Guide to the Systems Modeling Language
    ptg11539604 Praise for SysML Distilled “In keeping with the outstanding tradition of Addison-Wesley’s techni- cal publications, Lenny Delligatti’s SysML Distilled does not disappoint. Lenny has done a masterful job of capturing the spirit of OMG SysML as a practical, standards-based modeling language to help systems engi- neers address growing system complexity. This book is loaded with matter-of-fact insights, starting with basic MBSE concepts to distin- guishing the subtle differences between use cases and scenarios to illu- mination on namespaces and SysML packages, and even speaks to some of the more esoteric SysML semantics such as token flows.” — Jeff Estefan, Principal Engineer, NASA’s Jet Propulsion Laboratory “The power of a modeling language, such as SysML, is that it facilitates communication not only within systems engineering but across disci- plines and across the development life cycle. Many languages have the ptg11539604 potential to increase communication, but without an effective guide, they can fall short of that objective. In SysML Distilled, Lenny Delligatti combines just the right amount of technology with a common-sense approach to utilizing SysML toward achieving that communication. Having worked in systems and software engineering across many do- mains for the last 30 years, and having taught computer languages, UML, and SysML to many organizations and within the college setting, I find Lenny’s book an invaluable resource. He presents the concepts clearly and provides useful and pragmatic examples to get you off the ground quickly and enables you to be an effective modeler.” — Thomas W. Fargnoli, Lead Member of the Engineering Staff, Lockheed Martin “This book provides an excellent introduction to SysML.
    [Show full text]
  • A Dynamic Analysis Tool for Textually Modeled State Machines Using Umple
    UmpleRun: a Dynamic Analysis Tool for Textually Modeled State Machines using Umple Hamoud Aljamaan, Timothy Lethbridge, Miguel Garzón, Andrew Forward School of Electrical Engineering and Computer Science University of Ottawa Ottawa, Canada [email protected], [email protected], [email protected], [email protected] Lethbridge.book Page 299 Tuesday, November 16, 2004 12:22 PM Abstract— In this paper, we present a tool named UmpleRun 4 demonstrates the tool usage. Subsequent sections walk that allows modelers to run the textually specified state machines through an example of instrumenting our example system and under analysis with an execution scenario to validate the model's performing dynamic analysis. dynamic behavior. In addition, trace specification will output Section 8.2 State diagrams 299 execution traces that contain model construct links. This will permit analysis of behavior at the model level. II. EXAMPLE CAR TRANSMISSION MODEL TO BE EXECUTED In this section, we will present the car transmission model Keywords— UmpleRun; Umple; UML; MOTL; stateNested machine; substates that and will guard be conditions our motivating example through this paper. It will execution trace; analysis Aalso state be diagram used to can explain be nested Umple inside and a state.MOTL The syntax. states of The the innerCar diagram are calledtransmission substates model. was inspired by a similar model in I. INTRODUCTION LethbridgeFigure 8.18 and shows Lagani a stateère’s diagram book [4] of. anThe automatic model consists transmission; of at the top one class with car transmission behavior captured by the state Umple [1,2] is a model-oriented programming language level this has three states: ‘Neutral’, ‘Reverse’ and a driving state, which is not machine shown in Fig.
    [Show full text]
  • The Convergence of Modeling and Programming
    The Convergence of Modeling and Programming: Facilitating the Representation of Attributes and Associations in the Umple Model-Oriented Programming Language by Andrew Forward PhD Thesis Presented to the Faculty of Graduate and Postdoctoral Studies in partial fulfillment of the requirements for the degree Doctor of Philosophy (Computer Science1) Ottawa-Carleton Institute for Computer Science School of Information Technology and Engineering University of Ottawa Ottawa, Ontario, K1N 6N5 Canada © Andrew Forward, 2010 1 The Ph.D. program in Computer Science is a joint program with Carleton University, administered by the Ottawa Carleton Institute for Computer Science Acknowledgements A very special, and well-deserved, thank you to the following: a) Dr. Timothy C. Lethbridge. Tim has been a mentor of mine for several years, first as one of my undergraduate professors, later as my Master’s supervisor. Tim has again helped to shape my approach to software engineering, research and academics during my journey as a PhD candidate. b) The Complexity Reduction in Software Engineering (CRUISE) group and in particular Omar Badreddin and Julie Filion. Our weekly meetings, work with IBM, and the collaboration with the development of Umple were of great help. c) My family and friends. Thank you and much love Ayana; your support during this endeavor was much appreciated despite the occasional teasing about me still being in school. To my mom (and editor) Jayne, my dad Bill, my sister Allison and her husband Dennis. And, to my friends Neil, Roy, Van, Rob, Pat, and Ernesto – your help will be forever recorded in my work. Finally a special note to Ryan Lowe, a fellow Software Engineer that helped to keep my work grounded during our lengthy discussion about software development – I will miss you greatly.
    [Show full text]
  • UML Why Develop a UML Model?
    App Development & Modelling BSc in Applied Computing Produced Eamonn de Leastar ([email protected]) by Department of Computing, Maths & Physics Waterford Institute of Technology http://www.wit.ie http://elearning.wit.ie Introduction to UML Why develop a UML model? • Provide structure for problem solving • Experiment to explore multiple solutions • Furnish abstractions to manage complexity • Decrease development costs • Manage the risk of mistakes #3 The Challenge #4 The Vision #5 Why do we model graphically? " Graphics reveal data.! " Edward Tufte$ The Visual Display of Quantitative Information, 1983$ " 1 bitmap = 1 megaword.! " Anonymous visual modeler #6 Building Blocks of UML " The basic building blocks of UML are:! " model elements (classes, interfaces, components, use cases, etc.)! " relationships (associations, generalization, dependencies, etc.)! " diagrams (class diagrams, use case diagrams, interaction diagrams, etc.)! " Simple building blocks are used to create large, complex structures! " eg elements, bonds and molecules in chemistry! " eg components, connectors and circuit boards in hardware #7 Example : Classifier View #8 Example: Instance View #9 UML Modeling Process " Use Case! " Structural! " Behavioural! " Architectural #10 Use Case Visual Paradigm Help #11 Structural Modeling Visual Paradigm Help #12 Behavioural Modeling Visual Paradigm Help #13 Architectural Modeling Visual Paradigm Help #14 Structural Modeling " Core concepts! " Diagram Types #15 Structural Modeling Core Elements " a view of an system that emphasizes
    [Show full text]
  • State and Activity Diagrams in UML Last Revised December 4, 2018 Objectives: 1
    CPS122 Lecture: State and Activity Diagrams in UML last revised December 4, 2018 Objectives: 1. To show how to create and read State Diagrams 2. To introduce UML Activity Diagrams Materials: 1. Answers to quick check questions from chapter 7 plus chapter 8 a, b, g 2. Demonstration of “Racers” program 3. Handout and Projectable on Web: State diagram for Session 4. Handout: Code for Session class performSession() method 5. Projectable of text figures 7.12, 7.13 6. Handout of Activity diagram for Racers 7. Projectable of text figure 8.10 I. Introduction A.Go over quick check questions chapter 7 + chapter 8 a, b, g only B. We have drawn a distinction between the static aspects of a system and its dynamic aspects. The static aspects of a system have to do with its component parts and how they are related to one another; the dynamic aspects of a system have to do with how the components interact with one another and/or change state internally over time. C. We have been looking at one aspect of the dynamic behavior of a system - the way various objects interact to carry out the various use cases. We have looked at two ways of describing this: 1. Sequence diagrams 2. Communication diagrams D.We now want to look two additional aspects of dynamic behavior !1 1. How an individual object changes state internally over time. a) Example: As part of doing the domain analysis of a traffic light system, it is important to note that individual signals go through a series of states in a prescribed order - modeled by the following state diagram: ! (Note: this is correct for the US but not for all countries in the world!) An important “business rule” that any traffic light system must obey is that the light must be yellow for a certain minimum period of time (related to vehicle speed in the intersection) between displaying green and displaying red.
    [Show full text]