DOCSLIB.ORG

UML Overview [1/2]

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
UML Overview [1/2] 2017 Spring CS350 Introduction to Software Engineering UML Overview [1/2] Young-Min Baek1 and Doo-Hwan Bae2 1,2Korea Advanced Institute of Science and Technology (KAIST) Daejeon, Republic of Korea 1 [email protected] 2 [email protected] Software Engineering Lab (SELab), KAIST Outline 1. Modeling a Software System A. What is Modeling? B. Modeling Languages 2. Unified Modeling Language (UML) A. What is UML? B. UML Diagram Taxonomy C. Software Modeling with UML 3. Design Activities with UML A. Development Process B. Types of UML Diagrams • Structural Diagrams • Behavioral Diagrams 2017 Spring. [CS350] Introduction to Software Engineering – UML Overview [1/2] 2/53 Notice TA Office Hour TUE/THU 14:30~17:30 Young-Min Baek, Mingyu Jin Software Engineering Lab, N1 #524 [email protected] [email protected] 3/53 We Want Better Software More reliable, less defects, better performance, higher quality, more familiar/comfortable interface, and so on THEN HOW? Software Engineering 4/53 How to Develop a System? Systematically Thorough analysis of stakeholders & requirements, better process, unambiguous understandings However, High complexity of a large project (A large number of components & a large amount of team work) Linguistic communication between teams or between team members is neither accurate nor reliable 5/53 How to Develop a System? THEN HOW? Model-based/driven Engineering Models are the standard representations and they are accurate and reliable. https://www2.warwick.ac.uk/fac/sci/physics/research/condensedmatt/imr_cdt/studen 6/53 ts/david_goodwin/teaching/modelling/l1_introuml.pdf Modeling a Software System 2017 Spring. [CS350] Introduction to Software Engineering – UML Overview [1/2] 7/53 Modeling a Software System UML: Unified Modeling Language Design Activities with UML Software Development Process Process-People-Technology triad “While process is often described as a leg of the process-people-technology triad, it may also be considered the “glue” that unifies the other Software aspects.” Programmer Architecture/ Design Technique Telelogic Tau Logiscope, Programming Design Implementation Doxygen, etc. Telelogic Tau SDL Suite, Technique Designer IBM Rational Rose RT Process Telelogic Tau Project goal Analysis Test Testing TTCN Suite Requirement Business goal Technique Analysis Process Technique Tester Telelogic Tau Maintenance IBM Rational Analyst Rose Process People Maintenance Technology related Technology Technique People 8/53 Modeling a Software System UML: Unified Modeling Language Design Activities with UML Here, We Focus on... We need Analyst Telelogic Tau G2 Designer We need analysis capabilities design skills Requirement Software Analysis Architecture/ Technique Design Technique Analyst Programmer Analysis Design Telelogic DOORS Software Configuration Eclipse, Jbuilder etc. Requirement Management Elicitation Programming Technique Technique SW Development Process Conceptualization Code Software Requirement Management Process Technology People Maintenance Test 9/53 Modeling a Software System UML: Unified Modeling Language Design Activities with UML For Analysis and Design of Software, We use a ‘MODEL’ to analyze requirements, to design/illustrate software architectures, to represent software behaviors, and so on. 10/53 Modeling a Software System UML: Unified Modeling Language Design Activities with UML Model What is a model? A model is a simplification of reality Reality Modeling Model Requirements models Software system Analysis/design Implementation models 11/53 Modeling a Software System UML: Unified Modeling Language Design Activities with UML Model What is a model? A model is an intended simplification of reality Models (i.e. specifications) describe structures and behaviors of a system they intend to model. Reality Modeling Model Requirements models Software system Analysis/design Implementation models Modeling is a proven and well-accepted engineering technique (e.g., Architectural model of houses and buildings, Mathematical models) 12/53 Modeling a Software System UML: Unified Modeling Language Design Activities with UML Model (in Detail) What is a model? A model is a simplification of reality A model is the abstracted representation of requirements Requirements We have to start here. Reality Modeling Model Requirements models Software system Analysis/design Implementation models If the software system is not yet developed... 13/53 Modeling a Software System UML: Unified Modeling Language Design Activities with UML Example Models in Real World Examples* *http://www.ursalhomes.com/briana-single-house-and-lot-for-sale-cavite/ 14/53 Modeling a Software System UML: Unified Modeling Language Design Activities with UML Example Models in Real World Examples* *http://www.godesignsolutions.com.au/services/architectural_design_drawings 15/53 Modeling a Software System UML: Unified Modeling Language Design Activities with UML Example Models in Real World Examples: Maps as abstractions http://www.cs.toronto.edu/~sme/CSC302/notes/02-03-IntroModeling.pdf 16/53 Modeling a Software System UML: Unified Modeling Language Design Activities with UML Why Do We Use a Model? We model something To easily communicate information between different stakeholders in an unambiguous way 17/53 Modeling a Software System UML: Unified Modeling Language Design Activities with UML Why Do We Use a Model? We model something To deal with problem complexity ABSTRACTION: Ignore detail to see the big picture **Every abstraction involves choice over what is important DECOMPOSITION: Partition a problem into independent pieces PROJECTION: Separate different concerns (views) and describe them separately MODULARIZATION: Choose structures that are stable over time, to localize change 18/53 Modeling a Software System UML: Unified Modeling Language Design Activities with UML Why Do We Use a Model? Waterfall Model for software development* Requirement Design system/software models • To adequately represent/specify stakeholders’ and Specifications system requirements • To systematically implement a software based on the developed models System and Software Design Implementation and Unit Testing Integration and System Testing Operation and Maintenance *http://pehop.com/waterfall-system-development-life-cycle/ 19/53 Modeling a Software System UML: Unified Modeling Language Design Activities with UML Why Do We Use a Model? We model something To specify target-language-independent designs To provide structure for problem solving To provide mechanisms (abstractions, views, filtering, structure) to manage complexity To be able to easily experiment to explore multiple solutions To reveal key design decisions To uncover problems and figure out what questions to ask The exercise of modeling is more important than the model itself. Time spent perfecting the models might be time wasted… 20/53 Modeling a Software System UML: Unified Modeling Language Design Activities with UML Typical Properties of Good Models Correct Every statement is one that the software shall meet Unambiguous It has only one interpretation Unambiguity is the fundamental Complete property of models It includes all the requirements Consistent No subset has conflict 21/53 Modeling a Software System UML: Unified Modeling Language Design Activities with UML Modeling Language (ML) Definition A modeling language is any language with which a model can be described. An ML can be anything that helps you describe your system (e.g., pseudo-code, actual code, pictures, diagrams, or description) An ML contains two elements: Notation is the elements that make up a modeling language Semantics are the descriptions of what the notation means 22/53 Modeling a Software System UML: Unified Modeling Language Design Activities with UML What Can Be an Effective ML? Visual notation like UML can be a solution! 23/53 UML Unified Modeling Language 2017 Spring. [CS350] Introduction to Software Engineering – UML Overview [1/2] 24/53 Modeling a Software System UML: Unified Modeling Language Design Activities with UML History of UML “Method Wars” of object-oriented paradigm in 1990s OOAD, OMT, OOSE, Fusion, OOA/OOD Each of the methods had its own notation, process, and tools They needed to be unified in a refined & easy-to-understand modeling method 25/53 Modeling a Software System UML: Unified Modeling Language Design Activities with UML Unified Modeling Language (UML) Unified Modeling Language Unified End to many similar approaches Standardized by OMG 26/53 Modeling a Software System UML: Unified Modeling Language Design Activities with UML Unified Modeling Language (UML) Unified Modeling Language Unified End to many similar approaches Standardized by OMG Modeling Main (creative) process of software development 27/53 Modeling a Software System UML: Unified Modeling Language Design Activities with UML Unified Modeling Language (UML) Unified Modeling Language Unified End to many similar approaches Standardized by OMG Modeling Main (creative) process of software development Language Provides notation, no method, no process Graphical, collection of different diagram types 28/53 Modeling a Software System UML: Unified Modeling Language Design Activities with UML Unified Modeling Language (UML) Visual modeling language for specifying, constructing and documenting Object-oriented modeling Model/view paradigm Target language independent http://www.uml.org 29/53 Modeling a Software System UML: Unified Modeling Language Design Activities with UML UML 2.0 UML 2.0 leverages
Load more

Recommended publications
  • Communication Diagram.Pdf
    TU2943: Information Engineering Methodology Lab Notes, 2009-2010, Faculty of Technology and Information Science, Universiti Kebangsaan Malaysia LAB 5: Interaction Diagram - UML Communication Diagram OBJECTIVES To understand the role of dynamic models in requirement analysis by reading and constructing UML Communication Diagram. INTRODUCTION Communication Diagram (a.k.a. Collaboration Diagram) Communication Diagram provides another way to model a scenario. Essentially is a part of Interaction Diagram (just like Sequence Diagram). Each object is represented by an object icon, and links are used to indicate communication paths on which messages are transmitted. Messages presented in the same way as those in sequence diagram. Formerly known as Collaboration Diagram in UML 1.x specification. Communication Diagram represents a combination of information taken from Use Case, Class and Sequence Diagrams describing both the static structure and dynamic behavior of the system. Comparing and Contrasting: Collaboration and Sequence Both diagrams show the same information: Objects/classes Messages Sequence Conditional Repetition Messages to self Sequence Diagram and Communication Diagram are two views of the same scenario. Collaboration diagrams emphasize who-is-talking-to-who. But the time-ordering of the messages who gets obscured. Sequence diagrams emphasize time-ordering. But the who-is-talking-to-who gets obscured. Use the diagram that you are most comfortable with. Structure and Notation of Communication Diagram Objects are named <an object name>:< its class> . Nor Samsiah Binti Sani 1 TU2943: Information Engineering Methodology Lab Notes, 2009-2010, Faculty of Technology and Information Science, Universiti Kebangsaan Malaysia Either <an object name> or <a class name> can be removed. Collaborations / communications are shown by lines between objects.
    [Show full text]
  • Guidelines for UML Or Sysml Modelling Within an Enterprise Architecture
    Guidelines for UML or SysML modelling within an enterprise architecture Mälardalen University Academy of Innovation, Design and Technology Author: Charlie Höglund Email: [email protected] Bachelor of Science in Computer Science/Basic level, 15hp Date: 2017-06-08 Examiner: Jan Carlson Supervisor: Daniel Sundmark Company supervisor: Fredric Andréasson (Volvo Construction Equipment) Abstract Enterprise Architectures (EA) are used to describe an enterprise’s structure in a standardized way. An Enterprise Architecture also provides decision-support when choosing a direction or making changes at different levels of an enterprise, such as the business architecture or technology architecture level. This can involve decisions such as: What kind of enterprise should this be, what kind of technologies should be used for new system developments etcetera. Therefore, using the Unified Modelling Language (UML) or Systems Modelling Language (SysML) together with standardized guidelines that help you decide what to do before, during, and after modelling could be important for producing correct and useful system models, which later on will be used to develop actual systems. At the moment, standardized guidelines of this kind do not really exist. However, there are a lot of information about why you should use UML or SysML, what kinds of UML or SysML diagrams that exist, or what notations to follow when creating a specific UML or SysML diagram. In this thesis, the objective has been to research about the usefulness and creation of standardized guidelines for UML or SysML modelling in an Enterprise Architecture (i.e. mainly intended for the automotive industry domain). For this reason, the two research questions: “how can you create useful standardized guidelines for UML or SysML modelling?” and “what do useful standardized guidelines for UML or SysML modelling look like?” were chosen.
    [Show full text]
  • OMG Systems Modeling Language (OMG Sysml™) Tutorial 25 June 2007
    OMG Systems Modeling Language (OMG SysML™) Tutorial 25 June 2007 Sanford Friedenthal Alan Moore Rick Steiner (emails included in references at end) Copyright © 2006, 2007 by Object Management Group. Published and used by INCOSE and affiliated societies with permission. Status • Specification status – Adopted by OMG in May ’06 – Finalization Task Force Report in March ’07 – Available Specification v1.0 expected June ‘07 – Revision task force chartered for SysML v1.1 in March ‘07 • This tutorial is based on the OMG SysML adopted specification (ad-06-03-01) and changes proposed by the Finalization Task Force (ptc/07-03-03) • This tutorial, the specifications, papers, and vendor info can be found on the OMG SysML Website at http://www.omgsysml.org/ 7/26/2007 Copyright © 2006,2007 by Object Management Group. 2 Objectives & Intended Audience At the end of this tutorial, you should have an awareness of: • Benefits of model driven approaches for systems engineering • SysML diagrams and language concepts • How to apply SysML as part of a model based SE process • Basic considerations for transitioning to SysML This course is not intended to make you a systems modeler! You must use the language. Intended Audience: • Practicing Systems Engineers interested in system modeling • Software Engineers who want to better understand how to integrate software and system models • Familiarity with UML is not required, but it helps 7/26/2007 Copyright © 2006,2007 by Object Management Group. 3 Topics • Motivation & Background • Diagram Overview and Language Concepts • SysML Modeling as Part of SE Process – Structured Analysis – Distiller Example – OOSEM – Enhanced Security System Example • SysML in a Standards Framework • Transitioning to SysML • Summary 7/26/2007 Copyright © 2006,2007 by Object Management Group.
    [Show full text]
  • 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]
  • Unified Modeling Language 2.0 Part 1 - Introduction
    UML 2.0 – Tutorial (v4) 1 Unified Modeling Language 2.0 Part 1 - Introduction Prof. Dr. Harald Störrle Dr. Alexander Knapp University of Innsbruck University of Munich mgm technology partners (c) 2005-2006, Dr. H. Störrle, Dr. A. Knapp UML 2.0 – Tutorial (v4) 2 1 - Introduction History and Predecessors • The UML is the “lingua franca” of software engineering. • It subsumes, integrates and consolidates most predecessors. • Through the network effect, UML has a much broader spread and much better support (tools, books, trainings etc.) than other notations. • The transition from UML 1.x to UML 2.0 has – resolved a great number of issues; – introduced many new concepts and notations (often feebly defined); – overhauled and improved the internal structure completely. • While UML 2.0 still has many problems, current version (“the standard”) it is much better than what we ever had formal/05-07-04 of August ‘05 before. (c) 2005-2006, Dr. H. Störrle, Dr. A. Knapp UML 2.0 – Tutorial (v4) 3 1 - Introduction Usage Scenarios • UML has not been designed for specific, limited usages. • There is currently no consensus on the role of the UML: – Some see UML only as tool for sketching class diagrams representing Java programs. – Some believe that UML is “the prototype of the next generation of programming languages”. • UML is a really a system of languages (“notations”, “diagram types”) each of which may be used in a number of different situations. • UML is applicable for a multitude of purposes, during all phases of the software lifecycle, and for all sizes of systems - to varying degrees.
    [Show full text]
  • AP42 Section: Reference
    AP42 Section: 13.2.1 Reference: 8 Title: Paved Road Particulate Emissions, C. Cowherd, Jr., and P. J. Englehart, EPA-600/7-84-077, U. S. Environmental Protection Agency, Cincinnati, OH, July 1984. United Slates EPA-600 17- 84-077 Environmental Protection Agency July 1984 PAVED ROADS eEPA Research and Ap-42 Section 11.2.51\ Reference Number Development 4 iI J PAVED ROAD PARTICULATE EMISSIONS Source Category Report Prepared for Office of Air Quality Planning and Standards Prepared by Industrial Environmental Research Laboratory Research Triangle Park NC 2771 1 RESEARCH REPORTING SERIES Research reports of the Office of Research and Development, US. Environmental Protection Agency, have been grouped into nine series. These nine broad cate- gories were established to facilitate further development and application of en- vironmental technology. Elimination of traditional grouping was consciously planned to foster technology transfer and a maximum interface in related fields. The nine series are: 1. Environmental Health Effects Research 2. Environmental Protection Technology 3. Ecological Research 4. Environmental Monitoring .. 5. Socioeconomic Environmental Studies 6. Scientific and Technical Assessment Reports (STAR) 7. Interagency Energy-Environment Research and Development 8. “Special” Reports 9. Miscellaneous Reports This report has been assigned to the INTERAGENCY ENERGY-ENVIRONMENT RESEARCH AND DEVELOPMENT series. Reports in this series result from the effort funded under the 17-agency Federal Energy/Environment Research and Development Program. These studies relate to EPA’s mission to protect the public health and welfare from adverse effects of pollutants associated with energy sys- tems. The goal of the Program is to assure the rapid development of domestic energy supplies in an environmentally-compatible manner by providing the nec- essary environmental data and control technology.
    [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]
  • APECS: Polychrony Based End-To-End Embedded System Design and Code Synthesis
    APECS: Polychrony based End-to-End Embedded System Design and Code Synthesis Matthew E. Anderson Dissertation submitted to the faculty of the Virginia Polytechnic Institute and State University in partial fulfillment of the requirements for the degree of Doctor of Philosophy in Computer Engineering Sandeep K. Shukla, Chair Lamine Mili Alireza Haghighat Chao Wang Yi Deng April 3, 2015 Blacksburg, Virginia Keywords: AADL, CPS, Model-based code synthesis, correct-by-construction code synthesis, Polychrony, code generators, OSATE, Ocarina Copyright 2015, Matthew E. Anderson APECS: Polychrony based End-to-End Embedded System Design and Code Synthesis Matthew E. Anderson (ABSTRACT) The development of high integrity embedded systems remains an arduous and error-prone task, despite the efforts by researchers in inventing tools and techniques for design automa- tion. Much of the problem arises from the fact that the semantics of the modeling languages for the various tools, are often distinct, and the semantics gaps are often filled manually through the engineer's understanding of one model or an abstraction. This provides an op- portunity for bugs to creep in, other than standardising software engineering errors germane to such complex system engineering. Since embedded systems applications such as avionics, automotive, or industrial automation are safety critical, it is very important to invent tools, and methodologies for safe and reliable system design. Much of the tools, and techniques deal with either the design of embedded platforms (hardware, networking, firmware etc), and software stack separately. The problem of the semantic gap between these two, as well as between models of computation used to capture semantics must be solved in order to design safer embedded systems.
    [Show full text]
  • OMG Systems Modeling Language (OMG Sysml™) Tutorial
    OMG Systems Modeling Language (OMG SysML™) Tutorial 11 July 2006 Sanford Friedenthal Alan Moore Rick Steiner Copyright © 2006 by Object Management Group. Published and used by INCOSE and affiliated societies with permission. Caveat • This material is based on version 1.0 of the SysML specification (ad-06-03-01) – Adopted by OMG in May ’06 – Going through finalization process • OMG SysML Website – http://www.omgsysml.org/ 11 July 2006 Copyright © 2006 by Object Management Group. 2 Objectives & Intended Audience At the end of this tutorial, you should understand the: • Benefits of model driven approaches to systems engineering • Types of SysML diagrams and their basic constructs • Cross-cutting principles for relating elements across diagrams • Relationship between SysML and other Standards • High-level process for transitioning to SysML This course is not intended to make you a systems modeler! You must use the language. Intended Audience: • Practicing Systems Engineers interested in system modeling – Already familiar with system modeling & tools, or – Want to learn about systems modeling • Software Engineers who want to express systems concepts • Familiarity with UML is not required, but it will help 11 July 2006 Copyright © 2006 by Object Management Group. 3 Topics • Motivation & Background (30) • Diagram Overview (135) • SysML Modeling as Part of SE Process (120) – Structured Analysis – Distiller Example – OOSEM – Enhanced Security System Example • SysML in a Standards Framework (20) • Transitioning to SysML (10) • Summary (15) 11 July 2006 Copyright © 2006 by Object Management Group. 4 Motivation & Background SE Practices for Describing Systems Future Past • Specifications • Interface requirements • System design • Analysis & Trade-off • Test plans Moving from Document centric to Model centric 11 July 2006 Copyright © 2006 by Object Management Group.
    [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]
  • Systems Engineering with Sysml/UML Morgan Kaufmann OMG Press
    Systems Engineering with SysML/UML Morgan Kaufmann OMG Press Morgan Kaufmann Publishers and the Object Management Group™ (OMG) have joined forces to publish a line of books addressing business and technical topics related to OMG’s large suite of software standards. OMG is an international, open membership, not-for-profi t computer industry consortium that was founded in 1989. The OMG creates standards for software used in government and corporate environments to enable interoperability and to forge common development environments that encourage the adoption and evolution of new technology. OMG members and its board of directors consist of representatives from a majority of the organizations that shape enterprise and Internet computing today. OMG’s modeling standards, including the Unifi ed Modeling Language™ (UML®) and Model Driven Architecture® (MDA), enable powerful visual design, execution and maintenance of software, and other processes—for example, IT Systems Modeling and Business Process Management. The middleware standards and profi les of the Object Management Group are based on the Common Object Request Broker Architecture® (CORBA) and support a wide variety of industries. More information about OMG can be found at http://www.omg.org/. Related Morgan Kaufmann OMG Press Titles UML 2 Certifi cation Guide: Fundamental and Intermediate Exams Tim Weilkiens and Bernd Oestereich Real-Life MDA: Solving Business Problems with Model Driven Architecture Michael Guttman and John Parodi Architecture Driven Modernization: A Series of Industry Case Studies Bill Ulrich Systems Engineering with SysML/UML Modeling, Analysis, Design Tim Weilkiens Acquisitions Editor: Tiffany Gasbarrini Publisher: Denise E. M. Penrose Publishing Services Manager: George Morrison Project Manager: Mónica González de Mendoza Assistant Editor: Matt Cater Production Assistant: Lianne Hong Cover Design: Dennis Schaefer Cover Image: © Masterfile (Royalty-Free Division) Morgan Kaufmann Publishers is an imprint of Eslsevier.
    [Show full text]
  • UML Cheatsheet
    UML Cheatsheet Class Diagram Elements dependency multiplicity association Package::AbstractClass -Attribute : Type 1 -ClassAttribute : Type Parent Child parent child* +Operation(Arg:Type):Type #AbstractOperation * role Association generalization Class visibility 0..1 info <<interface>> Note ChildInfo SubClass Interface realizes qualified association dependency T 1 Interface ParameterizedClass Value key Implementor Operation(Arg: T) Operation2(): T Sequence Diagram Elements Object : Class Object2 object creation call(obj) new incoming message Object3 selfCall callback interaction frame return object destruction loop / alt / opt delete frame type {constraint} callUnderConstraint {alternative} callUnderAlternative (cc) 2006 Lou Franco - Some Rights Reserved - Attribution-NonCommercial-ShareAlike 2.5 (cc) 2006 Lou Franco - Some Rights Reserved - Attribution-NonCommercial-ShareAlike 2.5 http://creativecommons.org/licenses/by-nc-sa/2.5/ http://creativecommons.org/licenses/by-nc-sa/2.5/ Package Diagram Elements dependency Data View Model SQLServer Oracle Object Diagram Elements John : Child name = "John" parent: Parent Mary : Child name = "Mary" Use Case Diagram Elements system boundary actor 1 Library checkout 1 Membership <<include>> Common return start : Date Role Use Case Use Case renewal : Date * LendRecord Role Lendable due : Date <<include>> id 1 returned : Boolean newArrival : Boolean * LendRecord(lendable, member, date) calcDueDate(member): Date isDue() : Boolean Use Case Use Case renew(Date) * Role Book CD 1 Role * Member DVD (cc) 2006
    [Show full text]