DOCSLIB.ORG

Theory and Application the Real-Time UML Standard

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Theory and Application the Real-Time UML Standard TheThe RealRealReal-Time--TimeTime UMLUML Standard:Standard: TheoryTheory andand ApplicationApplication Bran Selic Ben Watson Rational Software Canada Tri-Pacific Software, Inc. [email protected] [email protected] TutorialTutorial ObjectivesObjectives ♦♦ToTo clarifyclarify thethe relationshiprelationship betweenbetween thethe objectobject paradigmparadigm andand realrealreal-time--timetime systemssystems II matchmatch oror mismatch?mismatch? ♦♦DescribeDescribe andand analyzeanalyze UMLUML fromfrom aa realrealreal-time--timetime designer’sdesigner’s perspectiveperspective ♦♦ToTo introduceintroduce thethe “UML“UML ProfileProfile forfor Schedulability,Schedulability, Performance,Performance, andand Time”Time” ♦♦ToTo introduceintroduce anan engineeringengineeringengineering-oriented--orientedoriented designdesign approachapproach forfor realrealreal-time--timetime systemssystems 2 TutorialTutorial OverviewOverview ♦♦RealRealReal-Time--TimeTime SystemsSystems andand thethe ObjectObject ParadigmParadigm ♦♦UMLUML asas aa RealRealReal-Time--TimeTime ModelingModeling LanguageLanguage ♦♦TheThe RealRealReal-Time--TimeTime UMLUML ProfileProfile ♦♦EngineeringEngineeringEngineering-Oriented--OrientedOriented DesignDesign ofof RealRealReal-Time--TimeTime SystemsSystems ♦♦SummarySummary andand ConclusionsConclusions 3 ♦♦RealRealReal-Time--TimeTime SystemsSystems andand thethe ObjectObject ParadigmParadigm II RealRealReal-Time--TimeTime SystemSystem EssentialsEssentials ♦♦UMLUML asas aa RealRealReal-Time--TimeTime ModelingModeling LanguageLanguage ♦♦TheThe RealRealReal-Time--TimeTime UMLUML ProfileProfile ♦♦EngineeringEngineeringEngineering-Oriented--OrientedOriented DesignDesign ofof RealRealReal-Time--TimeTime SystemsSystems ♦♦SummarySummary andand ConclusionsConclusions 4 RealReal--TimeTime SystemSystem ♦♦SystemsSystems thatthat maintainmaintain anan ongoingongoing timelytimely interactioninteraction withwith itsits environmentenvironment environment signal Real-Time source System inputs (state) controlledcontrolled entitiesentities signal •outputs = f (inputs, state) outputs source •coordination inputs 5 UnderUnder thethe HoodHood ♦♦AA persistentpersistent structurestructure thatthat providesprovides aa frameworkframework forfor behaviorbehavior environment ConcurrencyConcurrency conflictconflict signal Real-Time AgentReal-Time source System inputs (state) controlled Agent controlled entitiesentities signal •outputs = f (inputs, state) outputs Agent source •coordination inputs 6 ClassificationsClassifications ofof RTRT SystemsSystems ♦♦BasedBased onon naturenature ofof keykey inputsinputs II timetimetime-driven:--driven:driven: forfor continuouscontinuous (synchronous)(synchronous) inputsinputs II eventeventevent-driven:--driven:driven: forfor discretediscrete (asynchronous)(asynchronous) inputsinputs ♦♦BasedBased onon timetime criticalitycriticality II hardhard RTRT systems:systems: everyevery inputinput mustmust havehave aa timelytimely responseresponse II softsoft RTRT systems:systems: mostmost inputsinputs mustmust havehave timelytimely responseresponse ♦♦BasedBased onon load:load: II static:static: fixedfixed deterministicdeterministic loadload II dynamic:dynamic: variablevariable (non(non(non-deterministic)--deterministic)deterministic) loadload ♦♦ManyMany practicalpractical systemssystems areare combinationscombinations ofof thesethese 7 SampleSample RealReal--TimeTime ApplicationApplication INSTRUCTORINSTRUCTOR STATIONSTATION AIRFRAMEAIRFRAME ATMOSPHEREATMOSPHERE MODELMODEL CONTROL CONTROLCONTROL PILOT SURFACES PILOT SURFACESSURFACES CONTROLS GROUNDGROUND CONTROLS MODELMODEL ENGINESENGINES Which procedure(s) describe this system? 8 ClassicalClassical Approach:Approach: CyclicalCyclical ExecutiveExecutive The miscellaneous procedural slices are executed cyclically based on time resolution A A A B B B A C C B D D A A E B B F A C G B D H 50msec = 50 msec band ENGINESENGINES = 100 msec band (2 parts: A and B) = 200 msec band (4 parts: A, B, C, D) = 400 msec band (8 parts: A, B, C, D, E, F, G, H) The crucially important system structure is almost completely obscured 9 ProblemsProblems withwith thethe TraditionalTraditional SolutionSolution ♦♦TheThe solutionsolution isis adjustedadjusted toto fitfit thethe implementationimplementation technologytechnology (i.e.,(i.e., thethe stepstepstep-at-a-time--atat--aa--timetime programmingprogramming stylestyle ofof proceduralprocedural programming)programming) ratherrather thanthan humanhuman needsneeds ⇒⇒ InIn additionaddition toto thethe inherentinherent complexitycomplexity ofof thethe problemproblem designersdesigners needneed toto contendcontend withwith thethe accidentalaccidental complexitycomplexity ofof thethe implementationimplementation technologytechnology ♦♦OverwhelmingOverwhelming complexitycomplexity isis byby farfar thethe biggestbiggest hurdlehurdle inin mostmost realrealreal-time--timetime softwaresoftware systemssystems reducingreducing complexitycomplexity isis crucialcrucial toto successsuccess 10 ♦♦RealRealReal-Time--TimeTime SystemsSystems andand thethe ObjectObject ParadigmParadigm II RealRealReal-Time--TimeTime SystemSystem EssentialsEssentials II EssentialsEssentials ofof thethe ObjectObject ParadigmParadigm ♦♦UMLUML asas aa RealRealReal-Time--TimeTime ModelingModeling LanguageLanguage ♦♦TheThe RealRealReal-Time--TimeTime UMLUML ProfileProfile ♦♦EngineeringEngineeringEngineering-Oriented--OrientedOriented DesignDesign ofof RealRealReal-Time--TimeTime SystemsSystems ♦♦SummarySummary andand ConclusionsConclusions 11 TheThe EssenceEssence ofof thethe ObjectObject ParadigmParadigm ♦♦CombinesCombines allall thethe variousvarious featuresfeatures ofof aa logicallogical unitunit (procedures(procedures andand data)data) intointo aa singlesingle packagepackage calledcalled anan objectobject ♦♦DefinesDefines aa softwaresoftware systemsystem asas aa structurestructure ofof collaboratingcollaborating objectsobjects AirframeAirframe ControlControl AtmosphereAtmosphere SurfacesSurfaces 12 ObjectsObjects andand RealReal--TimeTime SystemsSystems ♦♦TheThe structurestructure ofof realrealreal-time--timetime systemssystems tendstends toto persistpersist throughthrough timetime becausebecause itit reflectsreflects thethe physicalphysical entitiesentities ofof thethe realreal worldworld ♦♦ThisThis structurestructure isis thethe frameworkframework throughthrough whichwhich (infinitely)(infinitely) manymany differentdifferent behaviorbehavior threadsthreads areare executedexecuted ♦♦Hence,Hence, thethe focusfocus isis onon structurestructure ratherrather thanthan behaviorbehavior ♦♦TheThe structuralstructural focusfocus ofof thethe objectobject paradigmparadigm isis betterbetter suitedsuited toto realrealreal-time--timetime systemssystems thanthan thethe proceduralprocedural paradigmparadigm 13 Yes,Yes, ButBut WhatWhat About...About... ♦♦Performance?Performance? II thethe costcost ofof abstractionabstraction (encapsulation,(encapsulation, automaticautomatic garbagegarbage collection,collection, dynamicdynamic binding,binding, etc.)etc.) ♦♦ModelingModeling realrealreal-time--timetime specificspecific phenomena?phenomena? II timetime andand timingtiming mechanismsmechanisms II resourcesresources (processors,(processors, networks,networks, semaphores,semaphores, etc.)etc.) ♦♦ExploitingExploiting currentcurrent realrealreal-time--timetime systemsystem theory?theory? II ssschedulabilitychedulabilitychedulability analysisanalysis (e.g.,(e.g., rateraterate-monotnic--monotnicmonotnic theory)theory) theory) II performanceperformance analysisanalysis (queueing(queueing theory)theory) 14 PerformancePerformance ofof OOOO TechnologyTechnology ♦♦HardwareHardware isis becomingbecoming everever fasterfaster (((Moore’sMoore’sMoore’s law)law) II previouslypreviously unacceptableunacceptable responseresponse timestimes maymay nownow bebe acceptableacceptable ♦♦OOOO softwaresoftware technologiestechnologies areare becomingbecoming realrealreal-time--timetime awareaware II boundedbounded dynamicdynamic bindingbinding techniquestechniques II tunabletunable automaticautomatic garbagegarbage collectioncollection (bounded(bounded latency)latency) II realrealreal-time--timetime variantsvariants ofof popularpopular OOOO languageslanguages (e.g.,(e.g., EC++,EC++, RTRT Java)Java) 15 ObjectsObjects ♦♦ConceptualConceptual unitsunits withwith I aa uniqueunique identityidentity (dedicated(dedicated memory)memory) I aa publicpublic interfaceinterface I aa hiddenhidden (encapsulated)(encapsulated) implementationimplementation DataData AttributesAttributes Telephone1: void:offHook (); busy : boolean {busy = true; reqDialtone(); offHook() … }; OperationsOperations onHook () ring() 16 ConceptualConceptual ObjectsObjects ♦♦NotNot allall objectsobjects necessarilynecessarily requirerequire aa physicalphysical underpinningunderpinning ♦♦ForFor example,example, thethe “telephone“telephone call”call” objectobject Telephone1Telephone1 Telephone2Telephone2 TelephoneTelephone CallCall Telephone Call Object abortCall () addParty (t:Telephone) reportDuration () The object paradigm allows us to create our own (virtual) reality! 17 ObjectObject BehaviorBehavior ♦♦InIn essence,essence, anan objectobject isis aa serverserver II genericgeneric objectobject lifecycle:lifecycle: InitializeInitialize HandlingHandling dependsdepends ObjectObject onon specificspecific requestrequest typetype andand objectobject statestate WaitWait for for Request InvokesInvokes Request operationsoperations onon other objects other objects void:offHookvoid:offHook
Load more

Recommended publications
  • 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]
  • UML Tutorial: Part 1 -- Class Diagrams
    UML Tutorial: Part 1 -- Class Diagrams. Robert C. Martin My next several columns will be a running tutorial of UML. The 1.0 version of UML was released on the 13th of January, 1997. The 1.1 release should be out before the end of the year. This col- umn will track the progress of UML and present the issues that the three amigos (Grady Booch, Jim Rumbaugh, and Ivar Jacobson) are dealing with. Introduction UML stands for Unified Modeling Language. It represents a unification of the concepts and nota- tions presented by the three amigos in their respective books1. The goal is for UML to become a common language for creating models of object oriented computer software. In its current form UML is comprised of two major components: a Meta-model and a notation. In the future, some form of method or process may also be added to; or associated with, UML. The Meta-model UML is unique in that it has a standard data representation. This representation is called the meta- model. The meta-model is a description of UML in UML. It describes the objects, attributes, and relationships necessary to represent the concepts of UML within a software application. This provides CASE manufacturers with a standard and unambiguous way to represent UML models. Hopefully it will allow for easy transport of UML models between tools. It may also make it easier to write ancillary tools for browsing, summarizing, and modifying UML models. A deeper discussion of the metamodel is beyond the scope of this column. Interested readers can learn more about it by downloading the UML documents from the rational web site2.
    [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]
  • 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]
  • Semantic Based Model of Conceptual Work Products for Formal Verification of Complex Interactive Systems
    Semantic based model of Conceptual Work Products for formal verification of complex interactive systems Mohcine Madkour1*, Keith Butler2, Eric Mercer3, Ali Bahrami4, Cui Tao1 1 The University of Texas Health Science Center at Houston, School of Biomedical Informatics, 7000 Fannin St Suite 600, Houston, TX 77030 2 University of Washington, Department of Human Centered Design and Engineering Box 352315, Sieg Hall, Room 208 Seattle, WA 98195 3 Brigham Young University Computer Science Department, 3334 TMCB PO Box 26576 Provo, UT 84602-6576 4 Medico System Inc. 10900 NE 8th Street Suite 900 Bellevue, WA 98004 * Corresponding author, email: [email protected], phone: (+1) 281-652-7118 Abstract - Many clinical workflows depend on interactive computer systems for highly technical, conceptual work 1. Introduction products, such as diagnoses, treatment plans, care Many critical systems require highly complex user interactions coordination, and case management. We describe an and a large number of cognitive tasks. These systems are automatic logic reasoner to verify objective specifications common in clinical health care and also many other industries for these highly technical, but abstract, work products that where the consequences of failure can be very expensive or are essential to care. The conceptual work products risky to human safety. Formal verification through model specifications serve as a fundamental output requirement, checking could reduce or prevent system failures, but several which must be clearly stated, correct and solvable. There is technical obstacles must be solved first. strategic importance for such specifications because, in We focus here on the abstract products of conceptual work turn, they enable system model checking to verify that that are foundational requirements that must be part of machine functions taken with user procedures are actually verification in a modern health care systems.
    [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 Why Develop a UML Model?
    App Development & Modelling BSc in Applied Computing Produced Eamonn de Leastar ([email protected]) by Department of Computing, Maths & Physics Waterford Institute of Technology http://www.wit.ie http://elearning.wit.ie Introduction to UML Why develop a UML model? • Provide structure for problem solving • Experiment to explore multiple solutions • Furnish abstractions to manage complexity • Decrease development costs • Manage the risk of mistakes #3 The Challenge #4 The Vision #5 Why do we model graphically? " Graphics reveal data.! " Edward Tufte$ The Visual Display of Quantitative Information, 1983$ " 1 bitmap = 1 megaword.! " Anonymous visual modeler #6 Building Blocks of UML " The basic building blocks of UML are:! " model elements (classes, interfaces, components, use cases, etc.)! " relationships (associations, generalization, dependencies, etc.)! " diagrams (class diagrams, use case diagrams, interaction diagrams, etc.)! " Simple building blocks are used to create large, complex structures! " eg elements, bonds and molecules in chemistry! " eg components, connectors and circuit boards in hardware #7 Example : Classifier View #8 Example: Instance View #9 UML Modeling Process " Use Case! " Structural! " Behavioural! " Architectural #10 Use Case Visual Paradigm Help #11 Structural Modeling Visual Paradigm Help #12 Behavioural Modeling Visual Paradigm Help #13 Architectural Modeling Visual Paradigm Help #14 Structural Modeling " Core concepts! " Diagram Types #15 Structural Modeling Core Elements " a view of an system that emphasizes
    [Show full text]
  • Part I Environmental Diagrams
    Adaptive Software Engineering G22.3033-007 Session 3 – Sub-Topic Presentation 1 Use Case Modeling Dr. Jean-Claude Franchitti New York University Computer Science Department Courant Institute of Mathematical Sciences 1 Part I Environmental Diagrams 2 1 What it is • Environmental Diagram Rent Video Video Store Pay Information System Employees Clerk Customer Payroll Clerk 3 What it is • A picture containing all the important players (Actors) • Includes players both inside and outside of the system • Actors are a critical component • External events are a second critical component 4 2 Creating the Diagram • To create an environmental diagram • 1. Identify all the initiating actors • 2. Identify all the related external events associated with each actor 5 Why it is used • A diagram is needed to show the context or scope of the proposed system • At this time actors and external events are the critical components • It is helpful to include all the participants as well 6 3 Creating the Diagram • 3. Identify all the participating Actors • These actors may be inside (internal) or outside (external) to the system 7 Creating the Diagram • Examples of an internal actor – Clerk who enters the purchase into a Point of Sale terminal – Clerk who places paper in the printer – Accountant who audits report 8 4 Creating the Diagram • Examples of an external actor – Accountant who audits report – A credit authorizing service – A DMV check for renting a car 9 Creating the Diagram •4.Draw a cloud • 5. Then draw initiating actors on the left of the cloud • 6. Then draw participating external actors outside the cloud • 7.
    [Show full text]
  • Leveraging Software Development Approaches in Systems Engineering
    Raytheon Leveraging Software Development Approaches in Systems Engineering Rick Steiner Engineering Fellow Raytheon Integrated Defense Systems [email protected] 6 May 2004 Naval Postgraduate School SI4000 Project Seminar Copyright © 2003 Raytheon Company UNPUBLISHED WORK ALL RIGHTS RESERVED 1 We’re going to talk about: Raytheon • Why Software Tools exist, why Systems Engineers should care • Software vs. SE as a discipline – key differences • The importance of requirements – Different requirement/system development approaches – Pros & cons of each, and how they relate to software approaches • How Use Cases relate to Requirements – Hints on how to manage use case development • How Object Oriented Design relates to Functional Analysis – or not! • What graphical languages can help (UML, SysML) • The promise of Model Driven Architecture (MDA) Copyright © 2003 Raytheon Company UNPUBLISHED WORK ALL RIGHTS RESERVED 2 Software Development Crisis Raytheon • In the 1980’s, software development underwent a crisis: – Software was RAPIDLY proliferating – Software was becoming very complex • Software on top of Software (OS, Application) • Software talking to Software (interfaces) – Software development delays were holding up system delivery – Software was becoming very expensive to develop and maintain – Software development effort was becoming very hard to estimate – Software reliability was becoming problematic – Existing techniques were proving inadequate to manage the problem • Reasons: – Economics • Processing hardware (silicon) got cheap –
    [Show full text]
  • During the Early Days of Computing, Computer Systems Were Designed to Fit a Particular Platform and Were Designed to Address T
    TAGDUR: A Tool for Producing UML Diagrams Through Reengineering of Legacy Systems Richard Millham, Hongji Yang De Montfort University, England [email protected] & [email protected] Abstract: Introducing TAGDUR, a reengineering tool that first transforms a procedural legacy system into an object-oriented, event-driven system and then models and documents this transformed system through a series of UML diagrams. Keywords: TAGDUR, Reengineering, Program Transformation, UML In this paper, we introduce TAGDUR (Transformation from a sequential-driven, procedural structured to an and Automatic Generation of Documentation in UML event-driven, component-based architecture requires a through Reengineering). TAGDUR is a reengineering tool transformation of the original system to an object-oriented, designed to address the problems frequently found in event-driven system. Object orientation, because it many legacy systems such as lack of documentation and encapsulates methods and their variables into modules, is the need to transform the present structure to a more well-suited to a multi-tiered Web-based architecture modern architecture. TAGDUR first transforms a where pieces of software must be defined in encapsulated procedurally-structured system to an object-oriented, modules with cleanly-defined interfaces. This particular event-driven architecture. Then TAGDUR generates legacy system is procedural-driven and is batch-oriented; documentation of the structure and behavior of this a move to a Web-based architecture requires a real-time, transformed system through a series of UML (Unified event-driven response rather than a procedural invocation. Modeling Language) diagrams. These diagrams include class, deployment, sequence, and activity diagrams. Object orientation promises other advantages as well.
    [Show full text]
  • 1 Class Diagrams and Entity Relationship Diagrams (ERD) Class Diagrams and Erds Both Model the Structure of a System
    Tutorial Week 7 - Class and Entity-Relationship Diagrams 1 Class Diagrams and Entity Relationship Diagrams (ERD) Class diagrams and ERDs both model the structure of a system. Class diagrams represent the dynamic aspects of a system: both the structural and behavioural features. ERDs, depicting only structural features provide a static view of the system. 2 Class Diagrams 2.1 Elements of a class diagram: 2.1.1 class A class is a general concept (represented as a square box). Class Name A class defines the structural attributes and behavioural characteristics of that concept. Shown as a rectangle labeled with the class name. 2.1.2 association Class 1 Association Class 2 A (semantic) relationship between classes. A line that joins two classes. 2.1.2.1 binary Simple association between two classes. A Person Eats Food solid triangle with the association name indicates the direction in which the association is meant to be read. 2.1.2.2 n-ary Class 1 Class 2 n-ary Association expresses an association n-ary between multiple classes Class 3 2.1.2.3 Aggregation Team Member “has-a” relationship page 1 of 14 Tutorial Week 7 - Class and Entity-Relationship Diagrams 2.1.2.4 Composition Car Engine “is-composed-of” relationship 2.1.2.5 Generalization Car Volvo “is-a-kind-of” relationship 2.1.2.6 Dependency Project The source class depends on (uses) the target class. (not used for requirements analysis) Project Manager Team 2.1.2.7 Realization «datatype» Class supports all operations of target Human Resources class but not all attributes or associations.
    [Show full text]
  • Telelogic AB
    Developing Test Specifications Through a Developing Test Specifications Model-Driven Approach Through Model-Driven Approach Irv Badr Senior Manager of Product Marketing © Telelogic AB Quality Improvement by Users • Major telecommunications handset maker: “Model Driven Development reduced the design errors in our application by 64%. We found 97% of all errors during the Coding and Unit Test phase of our project.” • Major telecommunications infrastructure provider: – 90% of coding errors removed – 30-50% of logical errors removed Telelogic AB 1 The Vision: Agile MDD approach for Test Development Requirements Document Requirements System Capture & (validation) Analysis Testing Accept Increment Integration & Regression Testing Define Increment Unit test Architect & Increment Design Increment Build Increment Development Testing Operational = Feedback trace System Telelogic AB Modeling Driven Development The Basics © Telelogic AB 2 Model-based Testing • Tests should be modeled together with the system architecture and functionality – systems and their tests tie in with the same system requirements – changes to requirements affect both system and tests – systems and tests are made consistent and coherent • Automatically generate the information that is necessary to execute the tests UML System Model Test Model code generation code generation Source code Telelogic AB Existing MDDTesting Framework • When modeling - a standard approach to express tests, which: – works with models at different levels of abstraction – supports source code – can be
    [Show full text]