Towards C# Application Development Using UML State Machines – a Case Study
Total Page:16
File Type:pdf, Size:1020Kb
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] -
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 -
Capabilities Statement
Capabilities Statement Email: [email protected] Web site: www.modeldriven.com 1 Model Driven Solutions Model Driven Solutions is a leading provider of professional services and products that leverage Services Oriented Architecture (SOA), the Object Management Group’s (OMG) Model Driven Architecture (MDA), Information Sharing, Ontologies and Semantics and W3C’s Semantic Web techniques and standards to federate processes, information, systems and organizations. A current focus is information interoperability and federation with a current emphasis on finance, risk and threats across cyber and physical domains as well as a model-driven approach to NIEM. We assist major organizations in achieving effectiveness and agility in a changing and collaborative world. Founded in 1996, as Data Access Technologies, Inc., its division, Model Driven Solutions, has been a leader in the development of open standards and supporting products that result in SOA based Executable Enterprise Architectures (EEA). Model Driven Solutions’ EEA focus helps drive information systems to quickly and cost effectively address business and defense initiatives. Active in the Object Management Group (OMG), the Organization for the Advancement of Structured Information Standards (OASIS), the Open Group and other standards development organizations, Model Driven Solutions has provided industry leadership that is, today, resulting in significant technological advancements and customer satisfaction. With customers like the General Services Administration (GSA), the U.S. Information Sharing Environment, the US Army, Raytheon, Lockheed Martin, Kaiser Permanente, Unisys and many others, Model Driven Solutions is at the leading edge of today’s software technology advances. General Information Parent Company Name: Data Access Technologies, Inc. (DAT) Virginia Affiliate: Model Driven Solutions, Inc. -
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. -
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. -
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. -
Executable UML: a Foundation for Model Driven Architecture
01-Introduction.fm Page 1 Wednesday, April 17, 2002 4:33 PM 1 Introduction Organizations want systems. They don’t want processes, meetings, mod- els, documents, or even code.1 They want systems that work—as quickly as possible, as cheaply as possible, and as easy to change as possible. Organizations don’t want long software development lead-times and high costs; they just want to reduce systems development hassles to the abso- lute minimum. But systems development is a complicated business. It demands distilla- tion of overlapping and contradictory requirements; invention of good abstractions from those requirements; fabrication of an efficient, cost- effective implementation; and clever solutions to isolated coding and abstraction problems. And we need to manage all this work to a successful conclusion, all at the lowest possible cost in time and money. None of this is new. Over thirty years ago, the U.S. Department of Defense warned of a “software crisis” and predicted that to meet the burgeoning need for software by the end of the century, everyone in the country would have to become a programmer. In many ways this prediction has come true, as anyone who has checked on the progress of a flight or made a stock trade using the Internet can tell you. Nowadays, we all write our own 1 Robert Block began his book The Politics of Projects[1] in a similar manner. 1 01-Introduction.fm Page 2 Wednesday, April 17, 2002 4:33 PM 2 INTRODUCTION programs by filling in forms—at the level of abstraction of the application, not the software. -
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. -
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. -
Executing UML Models
Executing UML Models Miguel Pinto Luz1, Alberto Rodrigues da Silva1 1Instituto Superior Técnico Av. Rovisco Pais 1049-001 Lisboa – Portugal {miguelluz, alberto.silva}@acm.org Abstract. Software development evolution is a history of permanent seeks for raising the abstraction level to new limits overcoming new frontiers. Executable UML (xUML) comes this way as the expectation to achieve the next level in abstraction, offering the capability of deploying a xUML model in a variety of software environments and platforms without any changes. This paper comes as a first expedition inside xUML, exploring the main aspects of its specification including the action languages support and the fundamental MDA compliance. In this paper is presented a future new xUML tool called XIS-xModels that gives Microsoft Visio new capabilities of running and debugging xUML models. This paper is an outline of the capabilities and main features of the future application. Keywords: UML, executable UML, Model Debugging, Action Language. 1. Introduction In a dictionary we find that an engineer is a person who uses scientific knowledge to solve practical problems, planning and directing, but an information technology engineer is someone that spends is time on implementing lines of code, instead of being focus on planning and projecting. Processes, meetings, models, documents, or even code are superfluous artifacts for organizations: all they need is well design and fast implemented working system, that moves them towards a new software development paradigm, based on high level executable models. According this new paradigm it should be possible to reduce development time and costs, and to bring new product quality warranties, only reachable by executing, debugging and testing early design stages (models). -
Prodeling with the Action Language for Foundational UML
Prodeling with the Action Language for Foundational UML Thomas Buchmann Chair of Applied Computer Science I, University of Bayreuth, Universitatsstrasse¨ 30, 95440 Bayreuth, Germany Keywords: UML, Java, Model-driven Development, Behavioral Modeling, Code Generation. Abstract: Model-driven software development (MDSD) – a software engineering discipline, which gained more and more attention during the last few years – aims at increasing the level of abstraction when developing a soft- ware system. The current state of the art in MDSD allows software engineers to capture the static structure in a model, e.g., by using class diagrams provided by the Unified Modeling Language (UML), and to generate source code from it. However, when it comes to expressing the behavior, i.e., method bodies, the UML offers a set of diagrams, which may be used for this purpose. Unfortunately, not all UML diagrams come with a precisely defined execution semantics and thus, code generation is hindered. Recently, the OMG issued the standard for an Action Language for Foundational UML (Alf), which allows for textual modeling of software system and which provides a precise execution semantics. In this paper, an integrator between an UML-based CASE tool and a tool for Alf is presented, which empowers the modeler to work on the desired level of ab- straction. The static structure may be specified graphically with the help of package or class diagrams, and the behavior may be added using the textual syntax of Alf. This helps to blur the boundaries between modeling and programming. Executable Java code may be generated from the resulting Alf specification. 1 INTRODUCTION days need to manually supply method bodies in the code generated from structural models. -
Verification of UML State Diagrams Using a Model Checker
Verification of UML State Diagrams using a Model Checker A Manuscript Submitted to the Department of Computer Science and the Faculty of the University of Wisconsin-La Crosse La Crosse, Wisconsin by Yiwei Zou in Partial Fulfillment of the Requirements for the Degree of Master of Software Engineering August, 2013 Verification of UML State Diagrams using a Model Checker By Yiwei Zou We recommend acceptance of this manuscript in partial fulfillment of this candidates re- quirements for the degree of Master of Software Engineering in Computer Science. The candidate has completed the oral examination requirement of the capstone project for the degree. Dr.Kasi Periyasamy Date Examination Committee Chairperson Dr.Mao Zheng Date Examination Committee Member Dr.Tom Gendreau Date Examination Committee Member ii Abstract Zou, Yiwei, Verification of UML State Diagrams using a Model Checker, Master of Software Engineering, August 2013. (Advisor: Kasi Periyasamy, Ph.D). This manuscript describes the process of verifying the UML state diagrams by using model checker. A UML state diagram describes the behavior of an object which includes a sequence of states that the object visits during its lifetime. Verification of UML state dia- gram is important because if one state diagram is incorrect, the object’s behavior will not be displayed correctly which leads to incorrect coding and eventually may lead to the possible failure of the system. However, it is hard to verify UML state diagram without the aid of other tools. Therefore, model checker is introduced to verify the UML state diagram. Since model checkers use different syntax, one needs to convert state diagrams from UML tools to the syntax used by the model checker.