DOCSLIB.ORG

Introduction to UML 2.0

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Introduction to UML 2.0 ® IBM Software Group Introduction to UML 2.0 Terry Quatrani UML Evangelist © 2005 IBM Corporation IBM Software Group Session Objectives ! After completing this session, you should be able to: !Identify the different UML diagrams !Describe the purpose of each diagram !State where diagrams can be used 2 IBM Software Group Agenda ! The Importance of Modeling ! The Unified Modeling Language ! Model-Driven Architecture ! UML Diagrams ! Extending the UML 3 IBM Software Group Agenda ! The Importance of Modeling ! The Unified Modeling Language ! Model-Driven Architecture ! UML Diagrams ! Extending the UML 4 IBM Software Group The Importance of Modeling 5 IBM Software Group Why do we model? ! To manage complexity ! To detect errors and omissions early in the lifecycle ! To communicate with stakeholders ! To understand requirements ! To drive implementation ! To understand the impact of change ! To ensure that resources are deployed efficiently 6 IBM Software Group Agenda ! The Importance of Modeling ! The Unified Modeling Language ! Model-Driven Architecture ! UML Diagrams ! Extending the UML 7 IBM Software Group The Unified Modeling Language ! The UML is the standard language for visualizing, specifying, constructing, and documenting the artifacts of a software- intensive system 8 IBM Software Group UML: The LanguageBlobs of with Software writing in their Development hair And small adornments in the air And has-relations everywhere Adopted majorI've looked revision at clouds (2004) that way. UML 2.0 But now I've purged them from my GradySun Current minor Eliminatedrevision 2001 every one UML 1.5 So many things I would have done To drive the clouds away. Minor revision 1999 UML 1.3 Public I've looked at clouds from both sides now OMG Acceptance,Both in Nov and 1997 out, and still somehow Feedback Final submissionIt's to clouds' OMG, Sept delusions 1997 I appall JimUML 1.1 I really can't stand clouds at all… UML partners Balls for multiplicity UML 1.0 Black and white for clarity And data flows arranged in trees Web - June 1996 Were part of OMT. UML 0.9 But now I've had to let themIvar go OOPSLA 95We'll do it differently, you knowUnified Method 0.8 'Cause Grady said, they've got to go We can't use OMT. Other methods OOSE Booch method OMT 9 IBM Software Group Approach to Evolving UML 2.0 ! Evolutionary rather than revolutionary ! Improved precision of the infrastructure ! Small number of new features ! New feature selection criteria !Required for supporting large industrial-scale applications !Non-intrusive on UML 1.x users (and tool builders) ! Backward compatibility with 1.x 10 IBM Software Group Formal RFP Requirements ! Infrastructure – UML internals !More precise conceptual base for better MDA support !MOF-UML alignment ! Superstructure – User-level features !New capabilities for large-scale software systems !Consolidation of existing features ! OCL – Constraint language !Full conceptual alignment with UML ! Diagram interchange standard !For exchanging graphic information (model diagrams) 11 IBM Software Group Infrastructure Requirements ! Precise MOF alignment !Fully shared “common core” metamodel ! Refine the semantic foundations of UML (the UML metamodel) !Improve precision !Harmonize conceptual foundations and eliminate semantic overlaps !Provide clearer and more complete definition of instance semantics (static and dynamic) 12 IBM Software Group OCL Requirements ! Define an OCL metamodel and align it with the UML metamodel !OCL navigates through class and object diagrams ⇒ must share a common definition of Class, Association, Multiplicity, etc. ! New modeling features available to general UML users !Beyond constraints !General-purpose query language 13 IBM Software Group Diagram Interchange Requirements ! Ability to exchange graphical information between tools !Currently only non-graphical information is preserved during model interchange !Diagrams and contents (size and relative position of diagram elements, etc.) 14 IBM Software Group Superstructure Requirements (1 of 2) ! More direct support for architectural modeling !Based on existing architectural description languages (UML-RT, ACME, SDL, etc.) !Reusable interaction specifications (UML-RT protocols) ! Behavior harmonization !Generalized notion of behavior and causality !Support choice of formalisms for specifying behavior ! Hierarchical interactions modeling ! Better support for component-based development ! More sophisticated activity graph modeling !To better support business process modeling 15 IBM Software Group Superstructure Requirements (2 of 2) ! New statechart capabilities !Better modularity ! Clarification of semantics for key relationship types !Association, generalization, realization, etc. ! Remove unused and ill-defined modeling concepts ! Clearer mapping of notation to metamodel ! Backward compatibility !Support 1.x style of usage !New features only if required 16 IBM Software Group Language Architecture MultipleMultiple levelslevels ofof compliance ! A core language + a set of optional “language units” compliance ! Some language units have multiple “levels” LevelLevel 33 State Structured Activities Interactions Detailed Flows Machines Classes and Actions Components LevelLevel 22 MOF Profiles OCL LevelLevel 11 BasicBasic UMLUML (Classes, Basic behavior, Internal structure, Use cases…) UML Infrastructure 17 IBM Software Group The UML 2.0 Specification ! Can be downloaded from http://www.omg.org/cgi-bin/doc?ptc/2004-10-02 18 IBM Software Group Agenda ! The Importance of Modeling ! The Unified Modeling Language ! Model-Driven Architecture ! UML Diagrams ! Extending the UML 19 IBM Software Group Model-Driven Architecture (MDA) ! An OMG initiative to support model-driven development through a series of open standards (1) ABSTRACTION (2) AUTOMATION MDA (3)(3) OPENOPEN STANDARDSSTANDARDS •• ModelingModeling languageslanguages •• InterchangeInterchange facilitiesfacilities •• ModelModel transformationstransformations •• SoftwareSoftware processesprocesses •• etc.etc. 20 IBM Software Group ! Set of modeling languages for specific purposes The Languages of MDA UML “bootstrap” GeneralGeneral RealReal-Time-Time StandardStandard UMLUML profileprofile General-purpose MetaObjectMetaObject modeling language EAI profile FacilityFacility (MOF)(MOF) EAIEAI profileprofile MOFMOF CommonCommon “core” Warehouse “core”“core” Warehouse Software MetamodelMetamodel (CWM)(CWM) Software processprocess profileprofile A modeling language For exchanging for defining modeling information about languages business and data etc.etc. etc.etc. 21 IBM Software Group MOF (Metamodel) Example ! Uses (mostly) class diagram concepts to define ! Language concepts ! Relationships betweenElement concepts 0..1 /owner * /ownedElement Relationship Element Comment * 1..* DirectedRelationship /source 1..* /target 1..* 22 IBM Software Group Agenda ! The Importance of Modeling ! The Unified Modeling Language ! Model-Driven Architecture ! UML Diagrams ! Extending the UML 23 IBM Software Group Meta-models and Notations 24 IBM Software Group Metamodel Description of Objects Na me d E l e me n t ObjectObject Element (from Ownerships) (from Namespaces) owningInstance owningSlot InstanceSpecification Va l ueS pe ci fic at i on {subsets owner} sl o t * {subsets owner} value Slot (from Expressions) {ordered, 1 {subsets 0..1 * ownedElement} subsets ownedElement} StructuralFeature definingFeature (from StructuralFeatures) 1 classifier Classifier 1..* (from Classifiers) instance 1 ValueSpecification (from Expressions) ObjectObject IdentifierIdentifier InstanceValue 25 IBM Software Group Metamodel Structure StructureStructure-Behavior-Behavior DependencyDependency SharedShared BehaviorBehavior SemanticsSemantics DifferentDifferent BehaviorBehavior FormalismsFormalisms 26 IBM Software Group Diagram Elements ! Each diagram has a frame, a content area and a heading ! The frame is a rectangle and is used to denote a border <kind> <name> <parameters> !Frame is optional ! The heading is a string contained in a name tag which is a rectangle with cut off corners in the upper left hand corner of the frame !Format [<kind>] [<name>] [<parameters>] !<kind> can be activity, class, component, interaction, package, state machine, use case 27 IBM Software Group Frame Example Package P Class 1 Class 2 28 IBM Software Group UML 2.0 Diagrams UseUse InteractionInteraction CaseCase DiagramsDiagrams DiagramsDiagrams ActivityActivity ClassClass DiagramsDiagrams DiagramsDiagrams Deployment CompositeComposite Deployment Structure DiagramsDiagrams Structure DiagramsDiagrams ComponentComponent StateState DiagramsDiagrams MachineMachine DiagramsDiagrams 29 IBM Software Group UML 2.0 Diagrams UseUse InteractionInteraction CaseCase DiagramsDiagrams DiagramsDiagrams ActivityActivity ClassClass DiagramsDiagrams DiagramsDiagrams Deployment CompositeComposite Deployment Structure DiagramsDiagrams Structure DiagramsDiagrams ComponentComponent StateState DiagramsDiagrams MachineMachine DiagramsDiagrams 30 IBM Software Group Activities ! Significantly enriched in UML 2.0 (relative to UML 1.x activities) !More flexible semantics for greater modeling power (e.g., rich concurrency model based on Petri Nets) !Many new features ! Major influences for UML 2.0 activity semantics !Business Process Execution Language for Web Services (BPEL4WS) – a de facto standard supported by key industry players (Microsoft, IBM, etc.) !Functional modeling from the systems engineering community (INCOSE) 31 IBM Software Group Activity Diagram ! Activity diagrams show flow of
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]
  • UML Summary 1
    UML Summary 1 The UML Summary provides an introduction to the UML, discussing its motivation and history. Contents 1.1 Overview 1-3 1.2 Primary Artifacts of the UML 1-3 1.3 Motivation to Define the UML 1-4 1.4 Goals of the UML 1-5 1.5 Scope of the UML 1-7 1.6 UML - Past, Present, and Future 1-11 UML V1.3 alpha R5 March 1999 1-1 1 UML Summary 1-2 UML V1.3 alpha R5 March 1999 1.1 Overview 1UML Summary 1.1 Overview The Unified Modeling Language (UML) is a language for specifying, visualizing, constructing, and documenting the artifacts of software systems, as well as for business modeling and other non-software systems. The UML represents a collection of the best engineering practices that have proven successful in the modeling of large and complex systems. 1.2 Primary Artifacts of the UML What are the primary artifacts of the UML? This can be answered from two different perspectives: the UML definition itself and how it is used to produce project artifacts. 1.2.1 UML-defining Artifacts To aid the understanding of the artifacts that constitute the Unified Modeling Language itself, this document consists of the UML Semantics, UML Notation Guide, and UML Extensions chapters. 1.2.2 Development Project Artifacts The choice of what models and diagrams one creates has a profound influence upon how a problem is attacked and how a corresponding solution is shaped. Abstraction, the focus on relevant details while ignoring others, is a key to learning and communicating.
    [Show full text]
  • 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]
  • UML 2 Toolkit, Penker Has Also Collaborated with Hans- Erik Eriksson on Business Modeling with UML: Business Practices at Work
    UML™ 2 Toolkit Hans-Erik Eriksson Magnus Penker Brian Lyons David Fado UML™ 2 Toolkit UML™ 2 Toolkit Hans-Erik Eriksson Magnus Penker Brian Lyons David Fado Publisher: Joe Wikert Executive Editor: Bob Elliott Development Editor: Kevin Kent Editorial Manager: Kathryn Malm Production Editor: Pamela Hanley Permissions Editors: Carmen Krikorian, Laura Moss Media Development Specialist: Travis Silvers Text Design & Composition: Wiley Composition Services Copyright 2004 by Hans-Erik Eriksson, Magnus Penker, Brian Lyons, and David Fado. All rights reserved. Published by Wiley Publishing, Inc., Indianapolis, Indiana Published simultaneously in Canada No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning, or otherwise, except as permitted under Section 107 or 108 of the 1976 United States Copyright Act, without either the prior written permission of the Publisher, or authorization through payment of the appropriate per-copy fee to the Copyright Clearance Center, Inc., 222 Rose- wood Drive, Danvers, MA 01923, (978) 750-8400, fax (978) 646-8700. Requests to the Pub- lisher for permission should be addressed to the Legal Department, Wiley Publishing, Inc., 10475 Crosspoint Blvd., Indianapolis, IN 46256, (317) 572-3447, fax (317) 572-4447, E-mail: [email protected]. Limit of Liability/Disclaimer of Warranty: While the publisher and author have used their best efforts in preparing this book, they make no representations or warranties with respect to the accuracy or completeness of the contents of this book and specifically disclaim any implied warranties of merchantability or fitness for a particular purpose.
    [Show full text]
  • PML, an Object Oriented Process Modelling Language
    PML, an Object Oriented Process Modeling Language Prof. Dr.-Ing. Reiner Anderl 1, and Dipl.-Ing. Jochen Raßler 2 1 Prof. Dr.-Ing. Reiner Anderl, Germany, [email protected] 2 Dipl.-Ing. Jochen Raßler, Germany, [email protected] Abstract: Processes are very important for the success within many business fields. They define the proper application of methods, technologies, tools and company structures in order to reach business goals. Important processes to be defined are manufacturing processes or product development processes for example to guarantee the company’s success. Over the last decades many process modeling languages have been developed to cover the needs of process modeling. Those modeling languages have several limitations, mainly they are still procedural and didn’t follow the paradigm change to object oriented modeling and thus often lead to process models, which are difficult to maintain. In previous papers we have introduced PML, Process Modeling Language, and shown it’s usage in process modeling. PML is derived from UML and hence fully object oriented and uses modern modeling techniques. It is based on process class diagrams that describe methods and resources for process modeling. In this paper the modeling language is described in more detail and new language elements will be introduced to develop the language to a generic usable process modeling language. Keywords: process modeling language, PML, UML 1. Introduction As the tendency of enterprises to collaborate growths steadily, industry faces new challenges managing business processes, product development processes, manufacturing processes and much more. Furthermore, discipline spanning product development processes are increasing, e.
    [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]
  • 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]
  • 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]
  • Overview Chapter 3 the Unified Process (3.1) the Unified Process
    1/11/2008 Overview Slide 2.1 Chapter 3 The Unified Process (3.1) Slide 2.2 z Software life-cycle models z Until recently, three of the most successful object- – Theoretical model oriented methodologies were – Iterative and incremental model – Grady Booch’s method – Code-and-fix life-cycle model – Ivar Jacobson’s Objectory – Waterfall (documentation driven model) – Jim Rumbaugh’s Object Modeling Technique (OMT) – Rapid prototyping life-cycle model – Open-source life-cycle model – Agile processes – Synchronize-and-stabilize life-cycle model – Spiral life-cycle model (risk driven) z Unified process z Capability Maturity Models (CMM) CS510 Software Engineering at Purdue CS510 Software Engineering at Purdue 3.2 Iteration and Incrementation within the Object-Oriented Paradigm The Unified Process (contd) Slide 2.3 Slide 2.4 z In 1999, Booch, Jacobson, and Rumbaugh z The Unified Process is a modeling technique published a complete object-oriented analysis and – A model is a set of UML diagrams that represent design methodology that unified their three various aspppects of the software product we want to separate methodologies develop – Original name: Rational Unified Process (RUP) – Next name: Unified Software Development Process z UML stands for unified modeling language (1997 (USDP) by three Amigos) – Name used today: Unified Process (for brevity) – Graphically represent (model) the target software product CS510 Software Engineering at Purdue CS510 Software Engineering at Purdue 1 1/11/2008 Iteration and Incrementation within the Object-Oriented
    [Show full text]
  • UML Profile for Communicating Systems a New UML Profile for the Specification and Description of Internet Communication and Signaling Protocols
    UML Profile for Communicating Systems A New UML Profile for the Specification and Description of Internet Communication and Signaling Protocols Dissertation zur Erlangung des Doktorgrades der Mathematisch-Naturwissenschaftlichen Fakultäten der Georg-August-Universität zu Göttingen vorgelegt von Constantin Werner aus Salzgitter-Bad Göttingen 2006 D7 Referent: Prof. Dr. Dieter Hogrefe Korreferent: Prof. Dr. Jens Grabowski Tag der mündlichen Prüfung: 30.10.2006 ii Abstract This thesis presents a new Unified Modeling Language 2 (UML) profile for communicating systems. It is developed for the unambiguous, executable specification and description of communication and signaling protocols for the Internet. This profile allows to analyze, simulate and validate a communication protocol specification in the UML before its implementation. This profile is driven by the experience and intelligibility of the Specification and Description Language (SDL) for telecommunication protocol engineering. However, as shown in this thesis, SDL is not optimally suited for specifying communication protocols for the Internet due to their diverse nature. Therefore, this profile features new high-level language concepts rendering the specification and description of Internet protocols more intuitively while abstracting from concrete implementation issues. Due to its support of several concrete notations, this profile is designed to work with a number of UML compliant modeling tools. In contrast to other proposals, this profile binds the informal UML semantics with many semantic variation points by defining formal constraints for the profile definition and providing a mapping specification to SDL by the Object Constraint Language. In addition, the profile incorporates extension points to enable mappings to many formal description languages including SDL. To demonstrate the usability of the profile, a case study of a concrete Internet signaling protocol is presented.
    [Show full text]
  • 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]