DOCSLIB.ORG

Xuml Summary

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Xuml Summary APPENDIX A xUML Summary Here is a quick reference to the key features of the Executable UML we use in this book. At the time of this writing, the most complete description is available in the book. Executable UML: A Foundation for Model-Driven Architecture by Stephen J. Mellor and Marc J. Balcer (AddisonWesley Professional, 2002). Resources can also be found in the sites mentioned on the Contact Us page in the back of this book. xUML xUML is a subset of UML notation with platform-independent execution semantics. xUML supports object/data-oriented analysis without assuming any sort of object-oriented implementation. All model elements are executable in a platform-independent context. This means that you don’t need anything extra (for example, code inserted somewhere) to run a model. If you have a tool that executes the model rules, you can test a model on the computer. Otherwise, you must apply the rules by hand. Either way, the rules of execution are the same. They are never subject to interpretation! © Leon Starr, Andrew Mangogna and Stephen Mellor 2017 237 L. Starr et al., Models to Code, DOI 10.1007/978-1-4842-2217-1 APPENDIX A ■ XUML SummaRY Domain A domain is a subject matter representing the rules and vocabulary of a real or abstract world. 238 APPENDIX A ■ XUML SummaRY Bridge A bridge is a relationship between two domains: one domain requires a capability that it cannot perform itself from another domain. The domain that requires the capability plays the role of a client. The domain that provides the needed capability plays the role of a service. 239 APPENDIX A ■ XUML SummaRY Domain Chart The set of domains and their connecting bridges necessary to build an entire software system is shown on a domain chart. A domain may be modeled in xUML, partially modeled in xUML, modeled in another language, hand coded, created in existing legacy software, or acquired from a third party. Remember, any domain can be split across many processor/thread/task boundaries, or multiple domains can be put in the same implementation unit. A domain chart is platform independent, so platform- and other technology-specific boundaries are not shown on the domain chart 240 APPENDIX A ■ XUML SummaRY Class A class is a definition of a set of instances such that all members of the set: Have the same characteristics Have the same behavior Are subject to the same rules and policies 241 APPENDIX A ■ XUML SummaRY Attribute An attribute is a characteristic of something that has been abstracted as a class. It follows from the class definition that each instance must have a meaningful value for each of its attributes at all times. At all times: The meaning and use is explained in an associated attribute description. The values that may be assigned to an attribute are constrained by a data type. 242 APPENDIX A ■ XUML SummaRY Data Type A data type is a constraint on the real-world values that may be assigned to an attribute and the operations that may be applied to those values. Examples: Pressure, mpa Count Count can be defined as an integer [0..maxint] Even though it is based on integer, the only supported operations are increment, decrement, and reset. Aircraft tail number This is not defined as string, because many strings would be illegal. A regular expression could be defined to describe legal tail number names. Also, most string operations would not be allowed on such a value. Point A 2D point type could be defined with operations that produce either a Cartesian or polar point, thus encapsulating the internal representation. r, theta = Track.Origin.Polar x, y = Track.Origin.Cartesian Definition of types (type theory) is orthogonal to relational theory used for defining class and association structures and behavior. 243 APPENDIX A ■ XUML SummaRY Identifier An identifier is a constraint on a set of one or more attributes on the same class such that no two instances of a class share the same value. Real-world identifier Invented identifier An identifier can be a real-world identifier such Or it can be an arbitrary value invented for the as Tail Number. Real-world agencies establish purpose of uniqueness. In this case, the modeler this constraint. establishes the constraint. Formalizes a real-world constraint. It is useful in conjunction with referential attributes to formalize relationships and other constraints. Symbol Identifiers are numbered starting at 1 for each class. Each attribute component of an identifier is tagged with {I} or {In}, where {I} means ID 1 and {In} indicates the participating ID number. An identifier attribute may participate in one or more of its class’s identifiers. The greater UML community encourages the implicit assumption of an architecture-supplied handle to manage links among instances. In xUML, we rely on at least one explicit identifier on each class. This ensures that we have a consistent system of relationship references, and it gives us a powerful tool for expressing restrictive constraints on relationships. 244 APPENDIX A ■ XUML SummaRY Association An association is a relationship that holds systematically among instances. 245 APPENDIX A ■ XUML SummaRY Association Class An association class formalizes an association between two other classes. Always use an association class for many-to-many and any conditional-to-conditional or many-to-0..1 association to ensure that a referential attribute always has a non-null value. 246 APPENDIX A ■ XUML SummaRY Generalization/Specialization A set of instances may share properties and rules and at the same time have exceptions. To handle this situation, the set definition established by a class is partitioned into mutually exclusive subsets. At all times: An ATC cannot exist without being On or Off Duty. An On or Off Duty Controller is certainly an ATC. Each real-world object has simultaneous membership in the superclass and subclass sets. Consequently, one object = two connected instances in a generalization. Generalization, in this case, is employed to establish an exclusive OR constraint. 247 APPENDIX A ■ XUML SummaRY Other Activity Types In xUML, activities are primarily state activities. But they are also written in class methods, external entity operations, and domain operations. Class Method There are several reasons to put an activity in a class method rather than in a state. For example, an activity might be triggered from multiple states. Or a class may not have a state model, but still be subject to state-less processing. The model merely states that when a derived attribute is accessed, it provides a correct value according to a platform-independent formula. When and how frequently the value is updated, on the other hand, is platform specific and, hence, not in the model. 248 APPENDIX A ■ XUML SummaRY Domain Operation A domain operation provides a runtime, model-level API to external domains. The activities should do nothing more than validate incoming data, locate relevant model elements, and then issue an appropriate event or invoke a class method. Limitations: Cannot refer to self attributes because there are none. Domain operation in Lubrication domain invoked via bridge from UI domain 249 APPENDIX A ■ XUML SummaRY State Model (Instance Lifeycle) By definition, all instances of a class share the same behavior. This behavior follows a common life cycle that can be formalized with a state model. (There are many other uses of state models in software, but in xUML, we use them exclusively to capture instance life cycles). State Machine Behavior An instance remains in a state of its state machine for events to occur. When one or more events occur, one of them will be consumed according to the event synchronization rules. A consumed event results in one of three responses: Follow a transition (as shown on the state model diagram) The instance follows the transition and immediately begins executing the activity in the destination state (which may be the same state). Ignore the event The event is consumed and exists no longer. Can’t happen The event is not anticipated and constitutes an unrecoverable error in the model. The model execution domain is responsible for handling the error outside the model. 250 APPENDIX A ■ XUML SummaRY Platform Independent Synchronization Rules Events At some time after an event is generated, it is made available to the destination instance or external entity. Events are never lost: every event will be delivered to an instance or external entity to which it is directed. After an event is consumed by an instance, it no longer exists. Multiple events can be pending for a given instance. (For example, events may arrive for an instance while it is executing an activity. Or, multiple events may simply arrive concurrently.) If events are pending for an instance that were generated by different senders, it is indeterminate which event will be consumed first. An event to self is always consumed by the instance that sent it before that instance consumes any other event. If an instance generates multiple events to a target instance, the events will be received in the order generated. Activities An activity takes time, possibly none, to execute. (The actual duration depends on the platform.) Once initiated, an instance’s state activity must complete before another signal can be accepted by the same instance. An activity always runs to completion in xUML. So, if you need the ability to interrupt behavior at the model level, break it down into multiple activities spread across one or more state models. Only one state activity of a given instance can be in execution at any time, because an instance is in only one state at a time. Multiple actions in an activity can execute concurrently.
Load more

Recommended publications
  • 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.
    [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]
  • Component Diagrams
    1.COMPONENT DIAGRAMS 2. PACKAGE DIAGRAMS What is a component? – A component is an autonomous unit within a system – UML component diagrams enable to model the high-level software components, and the interfaces to those components – Important for component-based development (CBD) – Component and subsystems can be flexibly REUSED and REPLACED – UML components diagrams are Implementation diagrams i.e., it describe the different elements required for implementing a system Example – When you build a house, you must do more than create blueprints – you've got to turn your floor plans and elevation drawings into real walls, floors, and ceilings made of wood, stone, or metal. – If you are renovating a house, you'll reuse even larger components, such as whole rooms and frameworks. – Same is the case when we develop software…. COMPONENT NOTATION – A component is shown as a rectangle with – A keyword <<component>> – Optionally, in the right hand corner a component icon can be displayed – A component icon is a rectangle with two smaller rectangles jutting out from the left-hand side – This symbol is a visual stereotype – The component name Component types Components in UML could represent – logical components (e.g., business components, process components) – physical components (e.g., EJB components, COM+ and .NET components) Component ELEMENTS – A component can have – Interfaces An interface represents a declaration of a set of operations – Usage dependencies A usage dependency is relationship which one element requires another element for its full
    [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 Diagram Types Architectural Family Component
    UML Diagram Types Dynamic Models Structural Models activity diagrams class diagrams statechart diagrams object diagrams interaction diagrams packages – sequence diagrams Architectural Models – collaboration component diagrams diagrams deployment diagrams use case diagrams Architectural Family Component Diagram: shows the organization and dependencies among a set of components (i.e., software deployment) Deployment Diagram: shows the configuration of run-time processing nodes and the components that live on them (i.e., hardware deployment) Component def’n: physical and replaceable part of a system that conforms to and provides the realization of a set of interfaces physical: bits replaceable: substitutable, conforming to same interfaces part of a system: software partition of a system interfaces: collection of operations to specify service of a class or component Component Convention name – simple name: (e.g. agent) – path name: (e.g. system::dialog) adornments – tagged values symbol – default: rectangle, with two smaller rectangles – iconic representation Components vs. Classes Similarities Differences names physical implementation realize set of vs. logical abstraction interfaces operations reachable relationships only through interfaces vs. attributes and nesting operations directly instances Interface def’n: collection of operations to specify service of a class or component represents seams in systems components realize the interfaces other components access services (dependency) through interfaces Convention short form (dependency) elided form (realization and dependency) fully specified form (expanded interface) Separation of Interface and Component separate what class does from how it interfaces break direct dependency between two components component will function properly as long as it uses given interface permits assembly of systems from binary replaceable parts extension through new services and new interfaces Types of Components Deployment necessary and sufficient to form an executable system e.g.
    [Show full text]
  • 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.
    [Show full text]
  • On UML's Composite Structure Diagram
    On UML's Composite Structure Diagram Ian Oliver, Vesa Luukkala Nokia Research Center Helsinki, Finland fian.oliver,[email protected] Abstract. The composite structure diagram and related notions have been introduced into UML2.0 to supplement already existing artifacts such as classes. However the usage of these constructs by engineers and/or modellers is not always in the spirit of inventors of these con- structs. A number of additional interpretations develop which are not always consistent with the intended usage of the structure nor with the language itself. Understanding these additional usages assists in under- standing areas of ambiguity, extension, inconsistency and the future de- velopment of the language. 1 Introduction The composite structure diagram's and related structures' uses and semantics are well described in [1{3] while the notions of composition are adequately de- scribed in [4, 5]. Its function is to extend the modelling capabilities of the UML beyond that of classes and their relationships and is primarily aimed to assist the modelling of the internal structures of classes with a more well defined notion of decomposition. Similar notions exist in methods such as ROOM [6] (capsules) and languages such as SDL [7] and SysML [8] for example. As tools become more UML compliant and support more UML constructs, en- gineers and/or modellers start to use these additional constructs. The effect of this is that the semantics of these constructs is often learnt through an implicit process based around the name of the construct and what the tool appears to allow; the semantics are often based on the engineer's expectations and per- ceived meaning [9] rather than on the actual, intended semantics.
    [Show full text]
  • 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).
    [Show full text]
  • 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.
    [Show full text]
  • TAGDUR: a Tool for Producing UML Sequence, Deployment, and Component Diagrams Through Reengineering of Legacy Systems
    TAGDUR: A Tool for Producing UML Sequence, Deployment, and Component Diagrams Through Reengineering of Legacy Systems Richard Millham, Jianjun Pu, Hongji Yang De Montfort University, England [email protected] & [email protected] Abstract: A further introduction of TAGDUR, a documents this transformed system through a reengineering tool that first transforms a series of UML diagrams. This paper focuses on procedural legacy system into an object-oriented, TAGDUR’s generation of sequence, deployment, event-driven system and then models and and component diagrams. Keywords: UML (Unified Modeling Language), Reengineering, WSL This paper is a second installment in a series [4] accommodate a multi-tiered, Web-based that introduces TAGDUR (Transformation and platform. In order to accommodate this Automatic Generation of Documentation in remodeled platform, the original sequential- UML through Reengineering). TAGDUR is a driven, procedurally structured legacy system reengineering tool that transforms a legacy must be transformed to an object-oriented, event- system’s outmoded architecture to a more driven system. Object orientation, because it modern one and then represents this transformed encapsulates variables and procedures into system through a series of UML (Unified modules, is well suited to this new Web Modeling Language) diagrams in order to architecture where pieces of software must be overcome a legacy system’s frequent lack of encapsulated into component modules with documentation. The architectural transformation clearly defined interfaces. A transfer to a Web- is from the legacy system’s original based architecture requires a real-time, event- procedurally-structured to an object-oriented, driven response rather than the legacy system’s event-driven architecture.
    [Show full text]
  • Model-Driven Software Development
    ModelModel--DrivenDriven SoftwareSoftware Development:Development: WhatWhat itit cancan andand cannotcannot dodo JonJon WhittleWhittle AssociateAssociate ProfessorProfessor InformationInformation && SoftwareSoftware EngineeringEngineering GeorgeGeorge MasonMason UniversityUniversity http://ise.gmu.edu/~jwhittle OutlineOutline Introduction to Modeling Introduction to OMG’s Model-driven Architecture (MDA): – What is MDA? – Example – MDA supporting technologies: metamodeling, transformations, executable UML – Tool support Introduction to Microsoft’s Software Factories – Domain Modeling – Domain-Specific Languages – The Microsoft-OMG Debate Model-Driven Development (MDD) in the future 2 SystemSystem ModelingModeling WhatWhat isis aa (system)(system) model?model? – “A simplified description of a complex entity or process” [web dictionary] – “A representation of a part of the function, structure and/or behavior of a system” [ORM01] – “A description of (part of) a system written in a well- defined language” [KWB03] KeyKey point:point: – Models are abstractions – Entire history of software engineering has been one of raising levels of abstraction (01s → assembly language → 3GLs → OO → CBD → patterns → middleware → declarative description) 3 WhyWhy Model?Model? ModelsModels cancan bebe usedused in:in: – System development – System analysis – System testing/validation/simulation EachEach requiresrequires abstractionabstraction ofof complexitycomplexity WhyWhy notnot model?model? – Large(r) effort required – Synchronization – Delayed return – Requires
    [Show full text]
  • Textual, Executable, Translatable UML⋆
    Textual, executable, translatable UML? Gergely D´evai, G´abor Ferenc Kov´acs, and Ad´amAncsin´ E¨otv¨osLor´andUniversity, Faculty of Informatics, Budapest, Hungary, fdeva,koguaai,[email protected] Abstract. This paper advocates the application of language embedding for executable UML modeling. In particular, txtUML is presented, a Java API and library to build UML models using Java syntax, then run and debug them by reusing the Java runtime environment and existing de- buggers. Models can be visualized using the Papyrus editor of the Eclipse Modeling Framework and compiled to implementation languages. The paper motivates this solution, gives an overview of the language API, visualization and model compilation. Finally, implementation de- tails involving Java threads, reflection and AspectJ are presented. Keywords: executable modeling, language embedding, UML 1 Introduction Executable modeling aims at models that are completely independent of the ex- ecution platform and implementation language, and can be executed on model- level. This way models can be tested and debugged in early stages of the devel- opment process, long before every piece is in place for building and executing the software on the real target platform. Executable and platform-independent UML modeling changes the landscape of software development tools even more than mainstream modeling: graphical model editors instead of text editors, model compare and merge instead of line based compare and merge, debuggers with graphical animations instead of de- buggers for textual programs, etc. Figure 1 depicts the many different use cases such a toolset is responsible for. Models are usually persisted in a format that is hard or impossible to edit directly, therefore any kind of access to the model is dependent on different features of the modeling toolset.
    [Show full text]