DOCSLIB.ORG

Uml.Sty, a Package for Writing UML Diagrams in LATEX

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
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.................................. 14 6.4 Namedoptionsconcerningsize . ..... 14 7 Diagram 15 7.1 Example........................................ 15 8 Stretchbox 15 8.1 Name,graphicalNameandreference . ...... 16 9 Classifier 16 10 Compartment 16 10.1Suppression .................................... 16 10.2Name ......................................... 17 11 Compartmentline 17 12 Feature 17 12.0.1 visibility................................... 17 12.0.2 type ...................................... 17 12.0.3 propertyString ............................... 17 13 Method 17 14 Attribute 18 15 Argument 18 16 Class 18 17 Schema 18 17.1Example(Stack) ................................. 20 18 Relation 20 18.1 Appearanceoftheconnector . ..... 22 18.2 Geometryoftheconnector. ..... 22 18.3 Referenceandplacementofnodes. ....... 22 19 AssociationEnd 23 19.1 Placingofthesymbol ............................. 23 20 Label 24 21 Symbol 24 22 Navigability 24 2 23 The different relations 24 23.0.1 Association .................................. 25 23.0.2 Subclass(generalization). ...... 25 23.0.3 Innerclass................................... 25 23.0.4 Instance.................................... 25 23.0.5 Aggregation.................................. 25 23.0.6 Composition ................................. 25 23.0.7 Application .................................. 25 23.1 RelationstoRelations . ..... 26 23.1.1 AssociationClass . 26 23.1.2 ArgumentRelation . 26 24 Package 28 24.1Example........................................ 29 24.2 Connectingpackages . .... 30 25 Colors 30 25.1Colorset....................................... 30 25.2 Usingthecolorsets.............................. .... 31 26 Positions 31 26.1PlaceNode...................................... 31 26.2Coordinates.................................... 32 26.2.1 Coordinatecommands . 32 27 A large example (Abstract Data Structures) 33 28 Typesetting the implementation 38 28.1 Thedocumentationdriverfile . ...... 39 29 Introductory code 39 29.1Identification .................................. 39 29.2 Processingofoptions. ..... 39 29.2.1 debug ..................................... 39 29.2.2 index ..................................... 39 29.2.3 Processingtheoptions . 40 29.3 Usingotherpackages. .... 40 30 General syntax 40 30.1Lengths ........................................ 40 30.2Angles......................................... 40 31 Drawable 40 31.1Namedoptions ................................... 41 31.2Colors ......................................... 41 31.3Thecommand..................................... 41 32 Element 42 3 33 Box 42 33.1Positioning .................................... 42 33.2Boxesintext .................................... 44 33.3 Thevisualappeareance . .... 44 33.4Size .......................................... 45 33.5 Holding together all the named options . ......... 45 33.6Thecommand..................................... 45 34 Diagram 46 34.1Thecommand..................................... 46 35 Stretchbox 47 36 Package 47 37 Classifier 48 38 Class 49 39 Schema 49 40 Compartment 50 40.1Suppression .................................... 50 40.2 Compartmentnames ............................... 51 40.3 Theimplementation . .. .. .. .. .. .. .. .. .. .. .. .. 51 41 Compartmentline 52 42 Feature 52 42.1Attribute ...................................... 53 42.2Method ........................................ 54 42.3Argument ....................................... 54 43 Relation 55 43.1 Nodeconnectionpoints . .... 55 43.2Armgeometry .................................... 55 43.3 Visualappeareance.. .. .. .. .. .. .. .. .. .. .. .. .. .... 56 43.4Themacro....................................... 56 43.5 Aboutthespesificrelations . ...... 57 43.6Association .................................... 58 43.7 Subclass(generalization). ........ 58 43.8Innerclass..................................... 58 43.9Instance....................................... 60 43.10Aggregation................................... 60 43.11Composition................................... 60 43.12Application ................................... 61 43.13ToRelation .................................... 61 43.14AssociationClass and AssociationSchema . ............ 61 4 43.15ArgumentRelation . .... 62 44 AssociationEnd 62 44.1Fraction....................................... 63 44.2Thecommand..................................... 64 44.3Label ......................................... 64 44.4Symbol ........................................ 64 44.5Navigability................................... 65 45 Colors 65 45.1Colorset....................................... 65 45.2Usingcolorsets................................. 66 46 Positions 67 46.1PlaceNode...................................... 67 1 Syntax for all the commands Most of the commands in uml.sty have the syntax \umlhConstructi[hNamed optionsi]hArgumentsi. hConstructi can be Diagram, Class, Method or other things. hNamed optionsi is a comma-separated list of hkeyi=hvaluei pairs. This is implemented by keyval.sty. The entire [hNamed optionsi] part is optional. In this documentation, the = often is replaced with a ­. This is due to an error in the index generation process, which does not accept. hArgumentsi a number of arguments, typically enclosed in brackets ({}). Typical arguments are a name and some interior of a box. 1.1 Lengths Legal lengths are all PSTricks lengths, including TEX lengths. In PSTricks lengths, the unit is optional; if no unit is present, the current PSTricks unit is used. 1.2 Angles We distinguish between angles and rotations. An angle should be a number giving the angle in degrees, by default. You can also change the units used for angles with the PSTricks \degrees[num] command. A rotation also expresses a direction, but can have different syntax forms: An angle i.e. a number An angle preceded by an asterisk This means the angle is to be interpreted absolute (rel- ative to the page) and not to the underling text direction. This is useful when getting a relation label right up, not in the direction of the relation 5 A letter One of letter Short for Equiv. to letter Short for Equiv. to U Up 0 N North *0 L Left 90 W West *90 D Down 180 S South *180 R Right 270 E East *270 When rotating along lines e.g. relations, you can precede an angle or one of ULDR with a colon. This is to orientate the text relative to the line. This is useful when getting a relation along the relation, not right up. 1.3 Node names A node name is a name of a location on the page. Such a name must contain only letters and numbers, and must begin with a letter. Also, the node names should be unique (at least, to the page). Node names are typically placed by means of the reference named option, but could be placed using any PSTricks node command. 1.4 Reference points A reference point is the point in a box which is to be placed. E.g., if the reference point is tl, meaning top left, the top left corner is placed relative to whatever. A reference point can be any of l (left), r (right), t (top), b (bottom) or B (baseline) or reasonable combinations of them. 1.5 Colors This is as in PSTricks. E.g., you can say \red Red gives Red and use the color red as linecolor or fillcolor. See also section 25 on page 30. 1.6 Line styles As in PSTricks, e.g., solid, dashed, dotted or none. 2 uml.sty options 2.1 debug 2.2 index By default, every named uml.sty construct (e.g., each Class and Attribute) makes an en- try in the index of the form hnamei!htypei. This feature can be turned off with the option \umlIndexOn noindex or on with index. The feature can also be turned on with \umlIndexOn and off with \umlIndexOff \umlIndexOff. Tip: It is possible to change the index entry format by changing \umlIndex. \umlIndex should take two arguments: The name and the type. E.g., \renewcommand\umlIndex[2]{\index{#1 (#2)}}. 6 3 Object-oriented approach A When making an uml package for LTEX, it seems natural to do the programming object- A oriented. While LTEX has no direct support for object-oriented programming, it can be simulated
Load more

Recommended publications
  • 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]
  • 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]
  • 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]
  • 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 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.
    [Show full text]
  • Examples of UML Diagrams
    UML Diagrams Examples Examples by Technology or Application Domain Online shopping UML diagrams Ticket vending machine UML diagrams Bank ATM UML diagrams Hospital management UML diagrams Digital imaging and communications in medicine (DICOM) UML diagrams Java technology UML diagrams Application development for Android UML diagrams Software licensing and protection using SafeNet Sentinel HASP security solution Examples by Types of Diagrams Activity diagram examples Class diagram examples Communication diagram examples Component diagram examples Composite structure diagram examples Deployment diagram examples Information flow diagram example Interaction overview diagram examples Object diagram example Package diagram examples Profile diagram examples http://www.uml-diagrams.org/index-examples.html 1/15/17, 1034 AM Page 1 of 33 Sequence diagram examples State machine diagram examples Timing diagram examples Use case diagram examples Use Case Diagrams Business Use Case Diagrams Airport check-in and security screening business model Restaurant business model System Use Case Diagrams Ticket vending machine http://www.uml-diagrams.org/index-examples.html 1/15/17, 1034 AM Page 2 of 33 Bank ATM UML use case diagrams examples Point of Sales (POS) terminal e-Library online public access catalog (OPAC) http://www.uml-diagrams.org/index-examples.html 1/15/17, 1034 AM Page 3 of 33 Online shopping use case diagrams Credit card processing system Website administration http://www.uml-diagrams.org/index-examples.html 1/15/17, 1034 AM Page 4 of 33 Hospital
    [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]
  • Plantuml Language Reference Guide
    Drawing UML with PlantUML Language Reference Guide (Version 5737) PlantUML is an Open Source project that allows to quickly write: • Sequence diagram, • Usecase diagram, • Class diagram, • Activity diagram, • Component diagram, • State diagram, • Object diagram. Diagrams are defined using a simple and intuitive language. 1 SEQUENCE DIAGRAM 1 Sequence Diagram 1.1 Basic examples Every UML description must start by @startuml and must finish by @enduml. 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. Example: @startuml Alice -> Bob: Authentication Request Bob --> Alice: Authentication Response Alice -> Bob: Another authentication Request Alice <-- Bob: another authentication Response @enduml To use asynchronous message, you can use ”->>” or ”<<-”. @startuml Alice -> Bob: synchronous call Alice ->> Bob: asynchronous call @enduml PlantUML : Language Reference Guide, December 11, 2010 (Version 5737) 1 of 96 1.2 Declaring participant 1 SEQUENCE DIAGRAM 1.2 Declaring participant It is possible to change participant order using the participant keyword. It is also possible to use the actor keyword to use a stickman instead of a box for the participant. You can rename a participant using the as keyword. You can also change the background color of actor or participant, using html code or color name. Everything that starts with simple quote ' is a comment. @startuml actor Bob #red ' The only difference between actor and participant is the drawing participant Alice participant "I have a really\nlong name" as L #99FF99 Alice->Bob: Authentication Request Bob->Alice: Authentication Response Bob->L: Log transaction @enduml PlantUML : Language Reference Guide, December 11, 2010 (Version 5737) 2 of 96 1.3 Use non-letters in participants 1 SEQUENCE DIAGRAM 1.3 Use non-letters in participants You can use quotes to define participants.
    [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]
  • Road Weather Information System (RWIS) Evaluation Technology Evaluation Memorandum
    Prepared by: Michigan Department of Transportation Road Weather Information System (RWIS) Evaluation Technology Evaluation Memorandum December 2013 MDOT RWIS Technology Evaluation Memorandum Table of Contents 1.0 Project overview ............................................................................................................................................ 1-1 1.1 Technology Evaluation ............................................................................................................................. 1-1 2.0 Established Weather Resources ................................................................................................................... 2-1 2.1 Environmental Sensor Station .................................................................................................................. 2-1 2.1.1 Standard ESS Instrumentation ............................................................................................................. 2-1 2.1.2 Optional Instrumentation for Standard ESS ......................................................................................... 2-2 2.1.3 Partial ESS Instrumentation ................................................................................................................. 2-2 2.1.4 Mobile ESS Sites ................................................................................................................................. 2-2 2.1.5 Mobile Data Collection ........................................................................................................................
    [Show full text]