DOCSLIB.ORG

Will UML 2.0 Be Agile Or Awkward? the UML Sits at an Architectural Crossroad

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Will UML 2.0 Be Agile Or Awkward? the UML Sits at an Architectural Crossroad Cris Kobryn Will UML 2.0 Be Agile or Awkward? The UML sits at an architectural crossroad. Will UML 2.0 resolve the problems of UML 1.x or will it succumb to the dreaded second-language syndrome? he Unified Modeling Lan- methods such as eXtreme Pro- discussion is primarily concerned guage (UML) has been gramming (XP); and the conver- with the UML 2.0 Infrastructure T widely accepted throughout gence of visual modeling with and Superstructure RFPs that the software industry and success- visual programming techniques. together define the requirements fully applied to diverse domains Considering these trends, as well for the modeling language part of ever since it was adopted by the as numerous requests for UML the specification. Object Management Group improvements, it should not be The UML 2.0 major revision (OMG) in 1997. In those four surprising the OMG has decided represents both an excellent years, UML has become the de that UML 1.x is ready for a opportunity and a serious respon- facto standard for specifying soft- major revision. sibility for its language designers. ware architectures that increase in Consequently, the OMG has It is a chance for them to resolve value as we progress from simple issued four RFPs for UML 2.0: the shortcomings of UML 1.x design models to multiview an Infrastructure RFP concerned and make the language more cur- enterprise blueprints. Indeed, it is with restructuring the basic con- rent and precise. At the same becoming difficult to find a soft- structs and improving customiz- time, it charges them with the ware project with more than 10 ability; a Superstructure RFP to responsibility for improving the developers that does not employ improve more advanced con- language without succumbing to UML in some way to specify part structs such as components, scope creep and design-by-com- of the software architecture. activities, and interactions; an mittee compromises. For reasons While the UML has been Object Constraint Language RFP we will discuss, discharging this growing in popularity among concerned with increasing the responsibility for UML 2.0 will software developers, the software precision and expressive power of likely be challenging. methods and practices it supports UML’s constraint language; and a have also been evolving steadily. Diagram Interchange RFP to Issues and Opportunities Some of the relevant changes to address making model diagrams UML 2.0 offers us an opportu- methods and practices include interchangeable between tools nity to solve many of the major the maturation of component [2–5]. The four RFPs imply the issues associated with UML 1.x. architectures and methods; the UML 2.0 specification will likely Some of the problems commonly transition from heavyweight, rig- be decomposed into four separate cited include excessive size, gratu- orous methods such as the Uni- and complementary parts as itous complexity, imprecise PAUL WATSON fied Process to agile, lightweight shown in the figure here. This semantics, non-standard imple- COMMUNICATIONS OF THE ACM January 2002/Vol. 45, No. 1 107 Technical Opinion reduce the UML’s size and com- Planned evolution of OMG UML. plexity. UML designers can learn a 2002 great deal from how the agile, (planned) informal methods (for example, «document» UML 2.0 XP, Feature-Driven Development, and Crystal) are causing their heavyweight, rigorous counterparts (for example, Unified Process) to «document» «document» streamline their techniques and UML 2.0 UML 2.0 Diagram processes. They can also learn how «document» Superstructure «document» Interchange UML 2.0 the Java and HTML/XML design- UML 2.0 OCL Infrastructure ers streamlined C++ and SGML, respectively. Like the Unified Process, the UML needs to prac- tice better parsimony and pragma- «document» Q2 2001 UML 1.4 tism. Perhaps the best place to Editorial revision start reducing UML is by defining without significant a concise and precise language ker- technical changes. nel. (By “kernel” I mean the 20% «document» of the language that is used to 1999 UML 1.3 specify 80% of the common soft- ware problems.) Defining a language kernel will make UML not only easier to «document» UML 1.2 learn, but to implement. The ker- 1998 nel can be used in conjunction with a mature profile mechanism (which includes metaclasses as «document» well as stereotypes) to define the 1997 UML 1.1 more advanced language features (adopted by OMG) such as the 80% of UML 1.x used only 20% of the time. They can mentations, limited customizabil- learn, apply, and implement. also facilitate language customiza- ity, inadequate support for com- After six years of working on the tion by vendors and users, so that ponent-based development, and UML specification and RFPs, I UML can be efficiently tailored inability to interchange model am still amazed at how frequently for different domains (for exam- diagrams. According to OMG’s experts need to consult the UML ple, financial services, health care, policies and procedures, these specifications regarding semantic telecom) and platforms (J2EE, substantive issues can only be and notational minutiae. If Zen .NET). addressed by a major revision to mind is beginner’s mind, then A concise and precise kernel UML. UML mind does not yet grok will likely accelerate the compli- It has long been recognized Zen. ance of UML implementations that UML 1.x is too large and Hopefully, the next major revi- with the specification, something complex, making it unwieldy to sion will allow us to significantly that is long overdue. More than 108 January 2002/Vol. 45, No. 1 COMMUNICATIONS OF THE ACM four years after the adoption of 2.0 will likely need to reduce dreaded syndrome in [1]: UML 1.1, no modeling tool ven- some of the impedance between dor has yet fully implemented it the object paradigm that under- An architect’s first work is apt to or any subsequent UML 1.x lan- lies UML 1.x and the component be spare and clean. ... This second guage specification! We need to paradigm that has evolved from it is the most dangerous system a man remedy this situation with UML and other sources. ever designs ... The general ten- 2.0, and an excellent way to Lastly, UML 2.0 needs to sup- dency is to overdesign the second system, using all the ideas and frills that were cautiously sidetracked on Web resources. the first one. The result, as Ovid Location Description says, is a “big pile.” www.omg.org/uml Contains links to OMG UML resources, such as specifications, articles, and related webs. Although the pathology of www.uml-forum.com Contains links to the UML 2.0 Working Group this syndrome was first diag- and UML Revision Task Force webs, as well as nosed in large, complex software other UML resources. engineering projects, the malady www.telelogic.com/publications/uml_models/ UML Models and Methods column by author also manifests itself in other tech- that addresses timely issues related to UML nology endeavors such as soft- modeling techniques and methods. Includes ware language design. Here, we discussions of latest minor and major revisions. consider a variation of the dis- ease: the second-language syn- begin is by defining a kernel that port complete model inter- drome known to infect various can be efficiently implemented change, including notational programming language design and tested for compliance via the diagrams. Until this is accom- efforts such as those associated XML Metadata Interchange plished it will be impractical to with Ada, C++, and CLOS. (XMI) standard. effectively share models among I am not claiming that UML UML 2.0 must also make the competing modeling tools. 1.x is spare and clean; on the con- component concept a core con- trary, I consider the language struct that evolves throughout the Second-Language unwieldy and complex. (In fact, software life cycle, rather than an Syndrome one could argue UML 1.x suf- afterthought for the implementa- Since we understand most of the fered from second-language syn- tion phase, as it sometimes problems described here reason- drome during its initial appears in UML 1.x. Although ably well, one might think it unification process!) Despite this the recent revisions to UML 1.4 should be relatively straightfor- difference between UML 1.x and make it easier to distinguish ward to solve them with the the “architect’s first work,” I between components (for exam- UML 2.0 revision. However, we expect that second-language syn- ple, EJB Entity Beans, COM need to keep in mind that since drome will still be a serious prob- objects) and the artifacts associ- we are dealing with the second lem for UML 2.0 for two reasons: ated with them (for example, EJB major version of UML we will The requirements for the four JAR files, DLLs), a good deal of likely need to contend with the separate RFPs (contrast this with work remains before UML 2.0 second-system effect, also known one for UML 1.x) are so exten- can fully support component as the “second-system syndrome.” sive and ambiguous it will be dif- architectures and methods. In Frederick Brooks, Jr., first ficult to prevent scope creep, let order to accomplish this, UML described the pathology of this alone reduce features. And the COMMUNICATIONS OF THE ACM January 2002/Vol. 45, No. 1 109 The UML 2.0 major revision represents both an excellent opportunity and a serious responsibility for its language designers. It is a chance for them to resolve the shortcomings of UML 1.x and make the language more current and precise. record number of companies sub- the experiences of others as well mitting to these RFPs will likely as their own (see the table here).
Load more

Recommended publications
  • 07 Requirements What About RFP/RFB/Rfis?
    CMPSCI520/620 07 Requirements & UML Intro 07 Requirements SW Requirements Specification • Readings • How do we communicate the Requirements to others? • [cK99] Cris Kobryn, Co-Chair, “Introduction to UML: Structural and Use Case Modeling,” UML Revision Task Force Object Modeling with OMG UML Tutorial • It is common practice to capture them in an SRS Series © 1999-2001 OMG and Contributors: Crossmeta, EDS, IBM, Enea Data, • But an SRS doesn’t need to be a single paper document Hewlett-Packard, IntelliCorp, Kabira Technologies, Klasse Objecten, Rational Software, Telelogic, Unisys http://www.omg.org/technology/uml/uml_tutorial.htm • Purpose • [OSBB99] Gunnar Övergaard, Bran Selic, Conrad Bock and Morgan Björkande, “Behavioral Modeling,” UML Revision Task Force, Object Modeling with OMG UML • Contractual requirements Tutorial Series © 1999-2001 OMG and Contributors: Crossmeta, EDS, IBM, Enea elicitation Data, Hewlett-Packard, IntelliCorp, Kabira Technologies, Klasse Objecten, Rational • Baseline Software, Telelogic, Unisys http://www.omg.org/technology/uml/uml_tutorial.htm • for evaluating subsequent products • [laM01] Maciaszek, L.A. (2001): Requirements Analysis and System Design. • for change control requirements Developing Information Systems with UML, Addison Wesley Copyright © 2000 by analysis Addison Wesley • Audience • [cB04] Bock, Conrad, Advanced Analysis and Design with UML • Users, Purchasers requirements http://www.kabira.com/bock/ specification • [rM02] Miller, Randy, “Practical UML: A hands-on introduction for developers,”
    [Show full text]
  • An Optimal Control Approach for Determiniation of the Heat Loss Coefficient in an Ics Solar Domesticater W Heating System
    University of Central Florida STARS Electronic Theses and Dissertations, 2004-2019 2010 An Optimal Control Approach For Determiniation Of The Heat Loss Coefficient In An Ics Solar Domesticater W Heating System Camilo Gil University of Central Florida Part of the Electrical and Electronics Commons Find similar works at: https://stars.library.ucf.edu/etd University of Central Florida Libraries http://library.ucf.edu This Doctoral Dissertation (Open Access) is brought to you for free and open access by STARS. It has been accepted for inclusion in Electronic Theses and Dissertations, 2004-2019 by an authorized administrator of STARS. For more information, please contact [email protected]. STARS Citation Gil, Camilo, "An Optimal Control Approach For Determiniation Of The Heat Loss Coefficient In An Ics Solar Domestic Water Heating System" (2010). Electronic Theses and Dissertations, 2004-2019. 4297. https://stars.library.ucf.edu/etd/4297 AN OPTIMAL CONTROL APPROACH FOR DETERMINATION OF THE HEAT LOSS COEFFICIENT IN AN ICS SOLAR DOMESTIC WATER HEATING SYSTEM by CAMILO GIL B.S. Pontificia Universidad Javeriana, 2001 M.S. University of New Mexico, 2005 A dissertation submitted in partial fulfillment of the requirements for the degree of Doctor of Philosophy in the Department of Electrical and Computer Engineering in the College of Engineering and Computer Science at the University of Central Florida Orlando, Florida Summer Term 2010 Major Professor: Marwan Simaan ©2010 Camilo Gil ii ABSTRACT Water heating in a typical home in the U.S. accounts for a significant portion (between 14% and 25%) of the total home’s annual energy consumption. The objective of considerably reducing the home’s energy consumption from the utilities calls for the use of onsite renewable energy systems.
    [Show full text]
  • Sysml, the Language of MBSE Paul White
    Welcome to SysML, the Language of MBSE Paul White October 8, 2019 Brief Introduction About Myself • Work Experience • 2015 – Present: KIHOMAC / BAE – Layton, Utah • 2011 – 2015: Astronautics Corporation of America – Milwaukee, Wisconsin • 2001 – 2011: L-3 Communications – Greenville, Texas • 2000 – 2001: Hynix – Eugene, Oregon • 1999 – 2000: Raytheon – Greenville, Texas • Education • 2019: OMG OCSMP Model Builder—Fundamental Certification • 2011: Graduate Certification in Systems Engineering and Architecting – Stevens Institute of Technology • 1999 – 2004: M.S. Computer Science – Texas A&M University at Commerce • 1993 – 1998: B.S. Computer Science – Texas A&M University • INCOSE • Chapters: Wasatch (2015 – Present), Chicagoland (2011 – 2015), North Texas (2007 – 2011) • Conferences: WSRC (2018), GLRCs (2012-2017) • CSEP: (2017 – Present) • 2019 INCOSE Outstanding Service Award • 2019 INCOSE Wasatch -- Most Improved Chapter Award & Gold Circle Award • Utah Engineers Council (UEC) • 2019 & 2018 Engineer of the Year (INCOSE) for Utah Engineers Council (UEC) • Vice Chair • Family • Married 14 years • Three daughters (1, 12, & 10) 2 Introduction 3 Our Topics • Definitions and Expectations • SysML Overview • Basic Features of SysML • Modeling Tools and Techniques • Next Steps 4 What is Model-based Systems Engineering (MBSE)? Model-based systems engineering (MBSE) is “the formalized application of modeling to support system requirements, design, analysis, verification and validation activities beginning in the conceptual design phase and continuing throughout development and later life cycle phases.” -- INCOSE SE Vision 2020 5 What is Model-based Systems Engineering (MBSE)? “Formal systems modeling is standard practice for specifying, analyzing, designing, and verifying systems, and is fully integrated with other engineering models. System models are adapted to the application domain, and include a broad spectrum of models for representing all aspects of systems.
    [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 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 2001: a Standardization Odyssey
    UML 2001: A Standardization Odyssey As the UML reaches the ripe age of four, both its proponents and its critics are scanning the recent changes in the UML 1.3 revision. CRIS KOBRYN In a relatively short period of time the Unified Modeling Language has emerged as the software industry’s dominant modeling language. UML is not only a de facto modeling language standard; it is fast becoming a de jure standard. Nearly two years ago the Object Management Group (OMG) adopted UML as its standard modeling language. As an approved Publicly Available Specification (PAS) submitter to the International Organization for Standardization (ISO), the OMG is proposing the UML specification for international timescales of standards usually conflict with the standardization. It is anticipated that the “fast competitive need to use the latest technology as track” PAS process will complete sometime next early as possible. From a technical perspective, the year, at which time UML will be formally recog- need to achieve consensus encourages “design by nized as an international standard for information committee” processes. In this sort of environment, technology. sound technical tradeoffs are often overridden by The major benefits of international standardiza- inferior political compromises. Too frequently the tion for a specification include wide recognition and resulting specifications become bloated with patches acceptance, which typically enlarge the market for in a manner similar to the way laws become fattened products based on it. However, these benefits often with riders in “pork belly” legislation. demand a high price. Standardization processes are This article explores how the UML is faring in typically formal and protracted, seeking to accom- the international standardization process.
    [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]
  • Previous Work Relating to Campam Themes
    3rd CAMPaM Workshop 2006 Previous Work Relating to CAMPaM Themes Thomas Kuh¨ ne Darmstadt University of Technology, Darmstadt, Germany e-mail: [email protected] 1 Interests zation” and how deep instantiation provides a nice solution, in particular in comparison to powertypes [12]. The following describes a certain subset of my research in- terests only. I have left out anything that has not immediate connection to the central CAMPaM themes. 1.4 Stereotypes I general, I’m interested in looking at the fundamentals of approaches that have a practical application. For instance, In joint work with Colin Atkinson and Brian Henderson-Sellers I do think the main thrust of the model-driven development I have criticized a common unofficial use of stereotypes and idea is heading in the right direction, but here and there a few argued for the need to better support modelers in specify- basics should be sorted out before the whole thing may fly. ing properties for classes, objects, and a combination of the Here are the areas related to CAMPaM themes in which I two [9]. have been making contributions. 1.5 Profiles 1.1 Metamodeling Fundamentals Together with Colin Atkinson I have tried to clarify when and Colin Atkinson and I have suggested a more comprehensive when not to use metamodeling [8], figured out how parallel interpretation of profiles [3]. descriptions hierarchies may be aligned [2], and distinguis- hed two important dimensions of metamodeling (linguistic vs ontological) [6,5]. 1.6 Architecture Stratification In work yet to be published I have distinguished between two kinds of model roles (token vs type models) and forma- Relating to the “multi abstractions” CAMPaM theme, I have lized what “metamodeling” could mean, including a clarifi- recently developed a prototype for handling multiple descrip- cation whether or not it is reasonable to refer to abstract syn- tions of the same system at different abstraction levels [11].
    [Show full text]
  • IRDRMFAO Install Guide
    IRDRMFAO INSTALL GUIDE IBM Rational DOORS Requirements Management Framework Add-on IRDRMFAO Install Guide Release 6.1.0.4 Before using this information, be sure to read the general information under the “Notices” chapter on page 36. This edition applies to VERSION 6.1.0.4, IBM Rational DOORS Requirements Management Framework Add-on and to all subsequent releases and modifications until otherwise indicated in new editions. © Copyright IBM Corporation 2009,2013 US Government Users Restricted Rights—Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. IBM Rational DOORS Requirements Management Framework Add-on - release 6.1.0.4 Table of Contents 1 INTRODUCTION............................................................................................6 2 CHECK THAT YOU MEET THE PREREQUISITES......................................7 3 INSTALL IRDRMFAO....................................................................................8 3.1 Select the language to be used by the installer................................................................................8 3.2 Warning..............................................................................................................................................8 3.3 Accept Licence....................................................................................................................................9 3.4 Choose DOORS version...................................................................................................................10 3.5
    [Show full text]
  • Case No COMP/M.4747 Œ IBM / TELELOGIC REGULATION (EC)
    EN This text is made available for information purposes only. A summary of this decision is published in all Community languages in the Official Journal of the European Union. Case No COMP/M.4747 – IBM / TELELOGIC Only the English text is authentic. REGULATION (EC) No 139/2004 MERGER PROCEDURE Article 8(1) Date: 05/03/2008 Brussels, 05/03/2008 C(2008) 823 final PUBLIC VERSION COMMISSION DECISION of 05/03/2008 declaring a concentration to be compatible with the common market and the EEA Agreement (Case No COMP/M.4747 - IBM/ TELELOGIC) COMMISSION DECISION of 05/03/2008 declaring a concentration to be compatible with the common market and the EEA Agreement (Case No COMP/M.4747 - IBM/ TELELOGIC) (Only the English text is authentic) (Text with EEA relevance) THE COMMISSION OF THE EUROPEAN COMMUNITIES, Having regard to the Treaty establishing the European Community, Having regard to the Agreement on the European Economic Area, and in particular Article 57 thereof, Having regard to Council Regulation (EC) No 139/2004 of 20 January 2004 on the control of concentrations between undertakings1, and in particular Article 8(1) thereof, Having regard to the Commission's decision of 3 October 2007 to initiate proceedings in this case, After consulting the Advisory Committee on Concentrations2, Having regard to the final report of the Hearing Officer in this case3, Whereas: 1 OJ L 24, 29.1.2004, p. 1 2 OJ C ...,...200. , p.... 3 OJ C ...,...200. , p.... 2 I. INTRODUCTION 1. On 29 August 2007, the Commission received a notification of a proposed concentration pursuant to Article 4 and following a referral pursuant to Article 4(5) of Council Regulation (EC) No 139/2004 ("the Merger Regulation") by which the undertaking International Business Machines Corporation ("IBM", USA) acquires within the meaning of Article 3(1)(b) of the Council Regulation control of the whole of the undertaking Telelogic AB ("Telelogic", Sweden) by way of a public bid which was announced on 11 June 2007.
    [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]
  • Real Time UML
    Fr 5 January 22th-26th, 2007, Munich/Germany Real Time UML Bruce Powel Douglass Organized by: Lindlaustr. 2c, 53842 Troisdorf, Tel.: +49 (0)2241 2341-100, Fax.: +49 (0)2241 2341-199 www.oopconference.com RealReal--TimeTime UMLUML Bruce Powel Douglass, PhD Chief Evangelist Telelogic Systems and Software Modeling Division www.telelogic.com/modeling groups.yahoo.com/group/RT-UML 1 Real-Time UML © Telelogic AB Basics of UML • What is UML? – How do we capture requirements using UML? – How do we describe structure using UML? – How do we model communication using UML? – How do we describe behavior using UML? • The “Real-Time UML” Profile • The Harmony Process 2 Real-Time UML © Telelogic AB What is UML? 3 Real-Time UML © Telelogic AB What is UML? • Unified Modeling Language • Comprehensive full life-cycle 3rd Generation modeling language – Standardized in 1997 by the OMG – Created by a consortium of 12 companies from various domains – Telelogic/I-Logix a key contributor to the UML including the definition of behavioral modeling • Incorporates state of the art Software and Systems A&D concepts • Matches the growing complexity of real-time systems – Large scale systems, Networking, Web enabling, Data management • Extensible and configurable • Unprecedented inter-disciplinary market penetration – Used for both software and systems engineering • UML 2.0 is latest version (2.1 in process…) 4 Real-Time UML © Telelogic AB UML supports Key Technologies for Development Iterative Development Real-Time Frameworks Visual Modeling Automated Requirements-
    [Show full text]