DOCSLIB.ORG

Introduction OMG Systems Modeling Language (OMG Sysml™) and OOSEM Tutorial by Abe Meilich, Ph.D

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Introduction OMG Systems Modeling Language (OMG Sysml™) and OOSEM Tutorial by Abe Meilich, Ph.D Introduction OMG Systems Modeling Language (OMG SysML™) and OOSEM Tutorial By Abe Meilich, Ph.D. [email protected] Acknowledged National Defense Industrial Association Original Authors: 9th Annual Systems Engineering Conference Sanford Friedenthal San Diego, CA Alan Moore October 23, 2006 Rick Steiner Copyright © 2006 by Object Management Group. Published and used by INCOSE and affiliated societies with permission. Caveat • These materials have been modified slightly from the original Tutorial given at INCOSE 2006 – Softcopy of Full Tutorial available at : http://www.omgsysml.org/SysML-Tutorial-Baseline-to-INCOSE- 060524-low_res.pdf • 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 • Introduction to principles of a OO System Engineering Method 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 • Diagram Overview • SysML Modeling as Part of SE Process • OOSEM – Enhanced Security System Example • SysML in a Standards Framework • Transitioning to SysML • Summary 11 July 2006 Copyright © 2006 by Object Management Group. 4 Background System Modeling Requirements Start Shift Accelerate Brake Control Power Vehicle Input Equations Dynamics Mass Properties ModelStructural Model Safety Model Cost Engine Transmission Transaxle Model Integrated System Model Must Address Multiple Aspects of a System 11 July 2006 Copyright © 2006 by Object Management Group. 6 Model Based Systems Engineering Benefits • Improved communications • Assists in managing complex system development – Separation of concerns – Hierarchical modeling – Facilitates impact analysis of requirements and design changes – Supports incremental development & evolutionary acquisition • Improved design quality – Reduced errors and ambiguity – More complete representation • Early and on-going verification & validation to reduce risk • Other life cycle support (e.g., training) • Enhanced knowledge capture 11 July 2006 Copyright © 2006 by Object Management Group. 7 Modeling at Multiple Levels of the System MCE (CRC) MCE (CRC) AWACS MCE (CRC) LINK 16 LINK 16 AMDPCS FAAD C3I LINK 16 LINK 16 Patriot ICC E-2C AWACS F/A-18 RIVET JOINT MCE F-15C ABMOC Subsystem Voice Comm Operator Interface Power Hardware Power Generation Hardware includes MSE SIAP ACDS (CVN) and Distribution Power Data Processing Power Terminal Power TCIM JTIDS Hardware Operational Models Terminal DDG-51 AEGIS Destroyer Software Power CG EPLRS or SINGARS Force Level Terminal Control System TAOM Power Voice & TADIL-B Data PLGR (GPS) Patriot ICC Power A2C2 Subsystem Power Operator Interface Voice Comm Power Hardware Power Generation Hardware includes and Distribution MSE Power CEC Information Exchange Requirements - Classified SECRET when filled in Data Processing 12 34567891011 Terminal TCIM Sending Receiving Latency: SA/Eng Message FAAD C3I Voice & TADIL-B Data Rationale/UJTL Number Event/Action Information Characterization Critical Format Class Rem ar k s Hardware Power No de No de Support Error Rate Radar measurements to REF: CEC A-spec JTIDS Provide SA/Support OP 5.1.1 Com m Op Info support data fusion composite Host CEP Yes Binary IAW IDD Secret xx secs/xx secs xx % Table 3-3 and AMDPCS Terminal Engagements Software track ing Hos t r e qm ts IFF measurements to support Provide SA/Support OP 5.1.1 Com m Op Info data fusion and composite Host CEP Yes Binary IAW IDD Secret xx secs/xx secs xx % Engagements EPLRS or SINGARS track ing IFF interrogation requests to Terminal Provide SA/Support Respond when Power OP 5.1.1 Com m Op Info support data fusion and Host CEP Yes Binary IAW IDD Secret xx secs/xx secs xx % Engagements requested Force Level Power com posite tracking Provide SA/Support ID Changes to support data Control System OP 5.1.1 Com m Op Info Host CEP Yes Binary IAW IDD Secret xx secs/xx secs xx % PLGR Engagements fusion and composite tracking (GPS) Provide SA/Support Navigation data to support data REF:CEC SRS and Power OP 5.1.1 Com m Op Info Host CEP Yes Binary IAW IDD Secret xx secs/xx secs xx % Engagements fusion and composite tracking Host Nav. spec Engagement Support Requests Provide SA/Support OP 5.1.1 Com m Op Info to support data fusion and Host CEP Yes Binary IAW IDD Secret xx secs/xx secs xx % AEGIS only Engagements com posite tracking Track number management to Provide SA/Support Changes sent OP 5.1.1 Com m Op Info support data fusion and Host-CEP CEP-Host Yes Binary IAW IDD Secret xx secs/xx secs xx % Engagements immediately com posite tracking Composite Track State Update Provide SA/Support REF: CEC IDDs for OP 5.1.1 Com m Op Info to support data fusion and CEP Host Yes Binary IAW IDD Secret xx secs/xx secs xx % Engagements e ach host com posite tracking Associated Measurement REF: CEC A-spec Provide SA/Support OP 5.1.1 Com m Op Info Reports to support data fusion CEP Host Yes Binary IAW IDD Secret xx secs/xx secs xx % Table 3-3. SPY Engagements and com posite track ing only IFF As signments to support Provide SA/Support When assigned OP 5.1.1 Com m Op Info data fusion and composite CEP Host Yes Binary IAW IDD Secret xx secs/xx secs xx % Engagements or changed track ing ID recommendations to Network Plan Provide SA/Support When assigned OP 5.1.1 Com m Op Info support data fusion and CEP Host Yes Binary IAW IDD Secret xx secs/xx secs xx % Engagements or changed CID Criteria com posite tracking REF: CEC A-spec Provide SA/Support Sensor cues to support data OP 5.1.1 Com m Op Info CEP Host Yes Binary IAW IDD Secret xx secs/xx secs xx % Table 3-3. SPY Engagements fusion and composite tracking Network only Network Track Data Receive Network Track Data Track File 11 Correlate Track Correlated Track Files 12 Manage BMDS Track File Data BMDS Track JDN Correlation S/W Network Interface Track Management Module Correlation Module Track File HIC Module Module 13 Request Attempt to Track Data Correlate with Track Data Possible BMDS Track Network BMDS Track File Matches Interface S/W Network Track MSG Track File Request Track Data Send Track System Models Track Mangement S/W Module HIC File Data BMDS Track Data Correlate Tracks BMDS Track Data Correlation Results Session Activated Verify CID, Correlation, and Assoicated Track yes Update Track File Data Data Correlation no / initialize Possible CreateCorrelation New Complete ( Correlation BMDSResults Track ) [ set not null ] / Send Results Idle Network Track File Received ( File Data ) [ number tracks > 0 ] / Input Network Track Correlating TracksMonitor BMDS Track Display Correlation Receiving Network Track File On entry / match state vectorsProcess Data BMDS Track Data Do / corr state vectors Do / corr LPE On entry / receive file data Do / corr PIP Do / store track data Track MSG Data Send BMDS Do / corr RCS On exit / request matching data Track Data to Do / corr CID JDN <TITLE>System Design<TITLE> On exit / corr BMDS Track # Prepared Track MSG corr fail / is new BMDS Track corr success / is corr BMDS Track <META http-equiv="REFRESH" BMDS Track File Request Sent ( Request ) / Pull BMDS Track Files BMDS Track File Data Received ( File Data ) / <!--CSSDATA:966533483--> Correlate Tracks Receiving BMDS Track File Data <SCRIPT src="/virtual/2000/code On entry / receive file data Do / store track data <LINK rel="stylesheet" href="/ <SCRIPT language="javascript" Track Mangement Module HIC /current tracks /associated track data manages 1..* /CID data uses 1..* assign CID () 1..* JDN recommend CID () 1..* retrieve track file data () display track file data () communicates with ABMOC Subsystem 1 Voice Comm Operator Interface Power 0..* Hardware Hardware includes interface for Power Generation <<entity>> MSE 1 1 1 and Distribution Track File Power <<interface>> Correlation Module Track Number Network Interface Module Data Processing Power CID 0..* algorithm Terminal Power TCIM /State Vector buffer capacity /tracks to be correlated JTIDS /Date-Time correlation data Hardware /msg data Terminal received from decorrelation data send track data () receive msg () parse msg () correlate tracks () Power route msg data () decorrelate tracks () Software build msg () retrieve track data () send msg () send track data () EPLRS or SINGARS Force Level Terminal Control System 1 0..* Power Voice & TADIL-B Data correlates PLGR (GPS) <<entity>> <<entity>> Network Track Customer Power BMDS Track Software License owning element Primary Key <<derived>> Primary Key is subject to Client Call A2C2 Subsystem Received Date-Time /associated data owns traces to /history Customer_ID [PK1] Power local track number Serial_Number [PK1] Primary Key Operator Interface Non-Key Attributes Voice Comm Non-Key Attributes Serial_Number [PK1] [FK]Hardware Power Power Generation Component Models Hardware includes receive () create () Customer_Name store () update () Technical_Contact and Distribution MSE destroy () Purchase_Contact update () send () retrieve ()Customer_Address Power createsData Processing consists of Terminal TCIM Voice & TADIL-B Data Hardware Power JTIDS Software Release Terminal Software Primary Key Tech Support System Entry Version_Number [PK1] Primary Key TSS_Entry_Number [PK1] Non-Key Attributes EPLRS or SINGARS Terminal Windows_Version Power TSS_Description Force Level Power Control System PLGR (GPS) Power Status Location is a Primary Key currently has Primary Key Status [PK1] Status [PK1] [FK] 11 July 2006 Copyright © 2006 by Object Management Group.
Load more

Recommended publications
  • Uml.Sty, a Package for Writing UML Diagrams in LATEX
    uml.sty, a package for writing UML diagrams in LATEX Ellef Fange Gjelstad March 17, 2010 Contents 1 Syntax for all the commands 5 1.1 Lengths ........................................ 5 1.2 Angles......................................... 5 1.3 Nodenames...................................... 6 1.4 Referencepoints ................................. 6 1.5 Colors ......................................... 6 1.6 Linestyles...................................... 6 2 uml.sty options 6 2.1 debug ......................................... 6 2.2 index.......................................... 6 3 Object-oriented approach 7 3.1 Colors ......................................... 10 3.2 Positions....................................... 10 4 Drawable 12 4.1 Namedoptions .................................... 12 4.1.1 import..................................... 12 5 Element 12 5.1 Namedoptions .................................... 12 5.1.1 Reference ................................... 12 5.1.2 Stereotype................................... 12 5.1.3 Subof ..................................... 13 5.1.4 ImportedFrom ................................ 13 5.1.5 Comment ................................... 13 6 Box 13 6.1 Namedoptionsconcerninglocation . ....... 13 6.2 Boxesintext ..................................... 14 6.3 Named options concerning visual appearance . ......... 14 6.3.1 grayness.................................... 14 6.3.2 border..................................... 14 1 6.3.3 borderLine .................................. 14 6.3.4 innerBorder.................................
    [Show full text]
  • Rational Unified Process - an Overview Uppsala, 2009-02-10
    Rational Unified Process - an overview Uppsala, 2009-02-10 Mikael Broomé Consultant M.Sc. LTH 10 years in Software Development 4 different RUP implementations Project Manager Mentor for Project Managers Applying more and more of agile mindset and techniques E-Mail: [email protected] 2 1 Agenda Why a process for developing software? What is RUP? What is the “RUP-way” of developing software? How is RUP packaged? Advantages by using RUP? Challenges when using RUP? Relation to other processes? 3 A good project delivers the right solution: satisified Users satisfied Sponsor delivers in time delivers on budget 4 2 Challenges Common challenges in software development projects: Capture the “right” requirements. Requirement changes. Different parts of the system do not fit together. Small changes causes big problems. Low quality and poor performance. Major problems identified late in projects. Lack of communication. Difficult to estimate time and cost. Management of environment, platforms and tools. 5 It’s all about (lack of) communication 6 3 Agenda Why a process for developing software? What is RUP? What is the “RUP-way” of developing software? How is RUP packaged? Advantages by using RUP? Challenges when using RUP? Relation to other processes? 7 What is RUP and UML? RUP is a process for development of software that describes what should be performed (activities) who should do it (roles) what the result should be (artifacts). UML is a notation with defined symbols that is worked out by OMG (Object Management Group) is used to make drawings (for example in software development). 8 4 Agenda Why a process for developing software? What is RUP? What is the “RUP-way” of developing software? How is RUP packaged? Advantages by using RUP? Challenges when using RUP? Relation to other processes? 9 JW2 RUP’s Six Best practices 1.
    [Show full text]
  • Network Visualization with R Katherine Ognyanova, POLNET 2015 Workshop, Portland OR
    Network visualization with R Katherine Ognyanova, www.kateto.net POLNET 2015 Workshop, Portland OR Contents Introduction: Network Visualization2 Data format, size, and preparation4 DATASET 1: edgelist ......................................4 DATASET 2: matrix .......................................5 Network visualization: first steps with igraph 5 A brief detour I: Colors in R plots8 A brief detour II: Fonts in R plots 11 Back to our main plot line: plotting networks 12 Plotting parameters ........................................ 12 Network Layouts ......................................... 17 Highlighting aspects of the network ............................... 24 Highlighting specific nodes or links ............................... 27 Interactive plotting with tkplot ................................. 29 Other ways to represent a network ............................... 30 Plotting two-mode networks with igraph ............................ 31 Quick example using the network package 35 Interactive and animated network visualizations 37 Interactive D3 Networks in R .................................. 37 Simple Plot Animations in R .................................. 38 Interactive networks with ndtv-d3 ................................ 39 Interactive plots of static networks............................ 39 Network evolution animations............................... 40 1 Introduction: Network Visualization The main concern in designing a network visualization is the purpose it has to serve. What are the structural properties that we want to highlight?
    [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]
  • UML 2 Activity and Action Models
    JOURNAL OF OBJECT TECHNOLOGY Online at www.jot.fm. Published by ETH Zurich, Chair of Software Engineering ©JOT, 2003 Vol. 2, No. 4, July-August 2003 UML 2 Activity and Action Models Conrad Bock, National Institute of Standards and Technology This is the first in a series introducing the activity model in the Unified Modeling Language, version 2 (UML 2), and how it integrates with the action model [1]. The series is a companion to the standard, providing additional background, rationale, examples, and introducing concepts in a logical order. This article covers motivation and architecture for the new models, basic aspects of UML 2 activities and actions, and introduces the general notion of behavior in UML 2. 1 BACKGROUND A focus of recent developments in UML has been on procedures and processes. UML 1.5 introduced a model for parameterized procedures defined by control and data flow to complement the existing state and interaction models [2]. For the first time UML supports first-class procedures that can be used as methods on objects or independently of objects, as occurs when modeling, for example, function libraries with popular programming languages. It also facilitates application of UML by modelers who do not use object-orientation (OO) routinely, such as system engineers and enterprise modelers, and provides them a path to incrementally adopt OO as needed [3]. The flexibility to combine OO with functional approaches considerably widens and integrates the potential applications of UML. UML 1.1 UML 1.3 UML 1.5 UML 2.0 1997 1999 2001 2003 Figure 1: UML Timeline UML 1.5 also inherited from earlier versions a form of state machine that was notationally modified to appear as a flow diagram, called the activity diagram.
    [Show full text]
  • Introduction to Systems Modeling Languages
    Fundamentals of Systems Engineering Prof. Olivier L. de Weck, Mark Chodas, Narek Shougarian Session 3 System Modeling Languages 1 Reminder: A1 is due today ! 2 3 Overview Why Systems Modeling Languages? Ontology, Semantics and Syntax OPM – Object Process Methodology SySML – Systems Modeling Language Modelica What does it mean for Systems Engineering of today and tomorrow (MBSE)? 4 Exercise: Describe the “Mr. Sticky” System Work with a partner (5 min) Use your webex notepad/white board I will call on you randomly We will compare across student teams © source unknown. All rights reserved. This content is excluded from our Creative Commons license. For more information, see http://ocw.mit.edu/help/faq-fair-use/. 5 Why Systems Modeling Languages? Means for describing artifacts are traditionally as follows: Natural Language (English, French etc….) Graphical (Sketches and Drawings) These then typically get aggregated in “documents” Examples: Requirements Document, Drawing Package Technical Data Package (TDP) should contain all info needed to build and operate system Advantages of allowing an arbitrary description: Familiarity to creator of description Not-confining, promotes creativity Disadvantages of allowing an arbitrary description: Room for ambiguous interpretations and errors Difficult to update if there are changes Handoffs between SE lifecycle phases are discontinuous Uneven level of abstraction Large volume of information that exceeds human cognitive bandwidth Etc…. 6 System Modeling Languages Past efforts
    [Show full text]
  • Generating Executable Capability Models for Requirements Validation
    2046 JOURNAL OF SOFTWARE, VOL. 7, NO. 9, SEPTEMBER 2012 Generating Executable Capability Models for Requirements Validation Weizhong Zhang Institute of Command Automation, PLA University of Science & Technology, Nanjing, China. Email: [email protected] Zhixue Wang1, Wen Zhao1, 2, Yingying Yang1, Xin Xin3 1. Institute of Command Automation, PLA University of Science & Technology, Nanjing, China. 2. Army Reserve Duty No.47 Infantry Division of Liaoning, Siping, China 3. Xi’an Communication Institute of PLA, Xi’an, China. Email: {wzxcx, chip_ai , flyto2016, zwjz1029}@163.com Abstract--Executable modeling allows the models to be models. The normal UML models are not executable executed and treated as prototypes to determine the because they describe the dynamic behavior of models behaviors of a system. In this paper, we propose an with natural language, and hence cannot be directly used approach for formalizing requirement models and to verify and validate the system behaviors in stage of generating executable models from them. Application analysis and design. activity diagrams (AADs), which are used to represent dynamic behaviors of systems in capability requirements The popularly applied methods include Petri Net [6] models, are firstly formalized and saved as XML documents. [7], executable UML (xUML) [8] [9] etc. But when the Then, on the basis of these models, a mapping algorithm of Petri Net applied, the requirements models built with translating AADs into instances of executable models for UML have to be transformed into those of Petri Net, and simulation is proposed. A case study is finally given to some part of model information might be lost during the demonstrate the applicability of the method.
    [Show full text]
  • Working with Deployment Diagram
    UNIVERSITY OF ENGINEERING AND TECHNOLOGY, TAXILA FACULTY OF TELECOMMUNICATION AND INFORMATION ENGINEERING SOFTWARE ENGINEERING DEPARTMENT Lab # 09 Working with Deployment Diagram You’ll learn in this Lab: What a deployment diagram is Applying deployment diagrams Deployment diagrams in the big picture of the UML A solid blueprint for setting up the hardware is essential to system design. The UML provides you with symbols for creating a clear picture of how the final hardware setup should look, along with the items that reside on the hardware What is a Deployment Diagram? A deployment diagram shows how artifacts are deployed on system hardware, and how the pieces of hardware connect to one another. The main hardware item is a node, a generic name for a computing resource. A deployment diagram in the Unified Modeling Language models the physical deployment of artifacts on nodes. To describe a web site, for example, a deployment diagram would show what hardware components ("nodes") exist (e.g., a web server, an application server, and a database server), what software components ("artifacts") run on each node (e.g., web application, database), and how the different pieces are connected (e.g. JDBC, REST, RMI). In UML 2.0 a cube represents a node (as was the case in UML 1.x). You supply a name for the node, and you can add the keyword «Device», although it's usually not necessary. Software Design and Architecture 4th Semester-SE UET Taxila Figure1. Representing a node in the UML A Node is either a hardware or software element. It is shown as a three-dimensional box shape, as shown below.
    [Show full text]
  • UML Components
    UML Components John Daniels Syntropy Limited [email protected] © Syntropy Limited 2001 All rights reserved Agenda • Aspects of a component • A process for component specification • Implications for the UML email:[email protected] Syntropy Limited Aspects of a component email:[email protected] Syntropy Limited UML Unified Modeling Language • The UML is a standardised language for describing the structure and behaviour of things • UML emerged from the world of object- oriented programming • UML has a set of notations, mostly graphical • There are tools that support some parts of the UML email:[email protected] Syntropy Limited Aspects of an Object ! Specification unit 1..* Interface ! Implementation unit * realization Class 0..1 Class Implementation source 1 1 instance * Object ! Execution unit email:[email protected] Syntropy Limited Components in context ObjectObject Evolving PrinciplesPrinciples developed within adopted by adopted by 1989- 1967- RMI 1995- Smalltalk EJB DistributedDistributed Object-orientedObject-oriented ObjectObject ComponentsComponents Programming DCOM Programming TechnologyTechnology C++ Java CORBA COM+/.NET Only interoperable Typically language neutral. A way of packaging within the language. Multiple address spaces. object implementations Single address space Non-integrated services to ease their use. Integrated services email:[email protected] Syntropy Limited Component standard features • Component Model: – defined set of services that support the software – set of rules that must be obeyed in order
    [Show full text]
  • The IBM Rational Unified Process for System Z
    Front cover The IBM Rational Unified Process for System z RUP for System z includes a succinct end-to-end process for z practitioners RUP for System z includes many examples of various deliverables RUP for System z is available as an RMC/RUP plug-in Cécile Péraire Mike Edwards Angelo Fernandes Enrico Mancin Kathy Carroll ibm.com/redbooks International Technical Support Organization The IBM Rational Unified Process for System z July 2007 SG24-7362-00 Note: Before using this information and the product it supports, read the information in “Notices” on page vii. First Edition (July 2007) This edition applies to the IBM Rational Method Composer Version 7.1 © Copyright International Business Machines Corporation 2007. All rights reserved. Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. Contents Notices . vii Trademarks . viii Preface . ix The team that wrote this IBM Redbooks publication . .x Become a published author . xii Comments welcome. xii Part 1. Introduction to the IBM Rational Unified Process for System z. 1 Chapter 1. Introduction. 3 1.1 Purpose. 4 1.2 Audience . 4 1.3 Rationale . 4 1.4 Scope . 5 1.5 Overview . 5 Part 2. The IBM Rational Unified Process for System z for Beginners . 9 Chapter 2. Introduction to the IBM Rational Unified Process and its extension to Service-Oriented Architecture. 11 2.1 Overview . 12 2.2 Introduction to RUP. 13 2.2.1 The heart of RUP . 13 2.2.2 The IBM Rational Method Composer (RMC) platform . 13 2.3 Key principles for successful software development.
    [Show full text]
  • Deployment Diagrams Deployment Diagrams
    DEPLOYMENT DIAGRAMS DEPLOYMENT DIAGRAMS • Deployment diagrams are used to visualize the topology of the physical components of a system. • The purpose of deployment diagrams can be described as: • Visualize hardware topology of a system. • Describe the hardware components used to deploy software components. • Describe runtime processing nodes. Definitions • Deployment diagram is a structure diagram which shows architecture of the system as deployment (distribution) of software artifacts to deployment targets. • Artifacts represent concrete elements in the physical world that are the result of a development process. Examples of artifacts are executable files, libraries, archives, database schemas, configuration files, etc. • Deployment target is usually represented by a node which is either hardware device or some software execution environment. Nodes could be connected through communication paths to create networked systems of arbitrary complexity. UML deployment diagram nodes and edges • Node/deployment target • Artifact • Manifests • Deployment specification • Deploy Node • Node is a deployment target which represents computational resource upon which artifacts may be deployed for execution. • Node is shown as a perspective, 3-dimensional view of a cube. • Node is specialized by: Device Execution environment Hierarchical Node Artifact • An artifact is a classifier that represents some physical entity, a piece of information that is used or is produced by a software development process. • Some real life examples of UML artifacts are: 1. text document 2. source file 3. script 4. binary executable file 5. archive file 6. database table Device Node • A device is a node which represents a physical computational resource with processing capability upon which artifacts may be deployed for execution. • A device is rendered as a node (perspective, 3-dimensional view of a cube) annotated with keyword «device».
    [Show full text]
  • The Tikz-UML Package
    The TikZ-UML package Nicolas Kielbasiewicz March 29, 2016 Contents 1 Preamble 3 1.1 Dependencies...........................................4 1.1.1 Required packages....................................4 1.2 Installation............................................5 2 Class diagrams 6 2.1 Packages, classes, attributes and operations..........................6 2.1.1 To define a package...................................6 2.1.2 To define a class.....................................6 2.2 To define a relation between classes...............................8 2.2.1 General command....................................8 2.2.2 To define the geometry of a relation.......................... 10 2.2.3 To adjust the geometry of a relation.......................... 11 2.2.4 To define informations about attributes of a relation................. 12 2.2.5 To place information about attributes of a relation.................. 13 2.2.6 To adjust the alignment of information about attributes of a relation........ 13 2.2.7 To define and place the stereotype of a relation.................... 13 2.2.8 To modify the anchor points of a relation....................... 14 2.2.9 To define a recursive relation.............................. 14 2.2.10 Name of auto-built points of a relation......................... 15 2.2.11 To draw an intersection point between relations.................... 16 2.2.12 Advanced styling of a relation.............................. 16 2.2.13 N-ary associations.................................... 17 2.3 Comments / constraints note.................................
    [Show full text]