DOCSLIB.ORG

UML Profile and Metamodel for Voice-Based Applications Specification

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
UML Profile and Metamodel for Voice-Based Applications Specification Date: April 2008 UML Profile and Metamodel for Voice-based Applications Specification Version 1.0 OMG Document Number: formal/2008-04-06 Standard document URL: http://www.omg.org/spec/VOICP/1.0/PDF Associated Files*: http://www.omg.org/spec/VOICP/20070701 http://www.omg.org/spec/VOICP/20070701/voice_metamodel.xml http://www.omg.org/spec/VOICP/20070701/voice_profile.xml * original file: ptc/2007-07-04 Copyright © 2005, Alcatel Copyright © 2005, EURESCOM Copyright © 2005, France Telecom Copyright © 2005, HP Copyright © 2005, IBM Copyright © 2008, Object Management Group, Inc. Copyright © 2005, Softeam Copyright © 2005, Telelogic USE OF SPECIFICATION - TERMS, CONDITIONS & NOTICES The material in this document details an Object Management Group specification in accordance with the terms, conditions and notices set forth below. This document does not represent a commitment to implement any portion of this specification in any company's products. The information contained in this document is subject to change without notice. LICENSES The companies listed above have granted to the Object Management Group, Inc. (OMG) a nonexclusive, royalty-free, paid up, worldwide license to copy and distribute this document and to modify this document and distribute copies of the modified version. Each of the copyright holders listed above has agreed that no person shall be deemed to have infringed the copyright in the included material of any such copyright holder by reason of having used the specification set forth herein or having conformed any computer software to the specification. Subject to all of the terms and conditions below, the owners of the copyright in this specification hereby grant you a fully-paid up, non-exclusive, nontransferable, perpetual, worldwide license (without the right to sublicense), to use this specification to create and distribute software and special purpose specifications that are based upon this specification, and to use, copy, and distribute this specification as provided under the Copyright Act; provided that: (1) both the copyright notice identified above and this permission notice appear on any copies of this specification; (2) the use of the specifications is for informational purposes and will not be copied or posted on any network computer or broadcast in any media and will not be otherwise resold or transferred for commercial purposes; and (3) no modifications are made to this specification. This limited permission automatically terminates without notice if you breach any of these terms or conditions. Upon termination, you will destroy immediately any copies of the specifications in your possession or control. PATENTS The attention of adopters is directed to the possibility that compliance with or adoption of OMG specifications may require use of an invention covered by patent rights. OMG shall not be responsible for identifying patents for which a license may be required by any OMG specification, or for conducting legal inquiries into the legal validity or scope of those patents that are brought to its attention. OMG specifications are prospective and advisory only. Prospective users are responsible for protecting themselves against liability for infringement of patents. GENERAL USE RESTRICTIONS Any unauthorized use of this specification may violate copyright laws, trademark laws, and communications regulations and statutes. This document contains information which is protected by copyright. All Rights Reserved. No part of this work covered by copyright herein may be reproduced or used in any form or by any means--graphic, electronic, or mechanical, including photocopying, recording, taping, or information storage and retrieval systems--without permission of the copyright owner. DISCLAIMER OF WARRANTY WHILE THIS PUBLICATION IS BELIEVED TO BE ACCURATE, IT IS PROVIDED "AS IS" AND MAY CONTAIN ERRORS OR MISPRINTS. THE OBJECT MANAGEMENT GROUP AND THE COMPANIES LISTED ABOVE MAKE NO WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, WITH REGARD TO THIS PUBLICATION, INCLUDING BUT NOT LIMITED TO ANY WARRANTY OF TITLE OR OWNERSHIP, IMPLIED WARRANTY OF MERCHANTABILITY OR WARRANTY OF FITNESS FOR A PARTICULAR PURPOSE OR USE. IN NO EVENT SHALL THE OBJECT MANAGEMENT GROUP OR ANY OF THE COMPANIES LISTED ABOVE BE LIABLE FOR ERRORS CONTAINED HEREIN OR FOR DIRECT, INDIRECT, INCIDENTAL, SPECIAL, CONSEQUENTIAL, RELIANCE OR COVER DAMAGES, INCLUDING LOSS OF PROFITS, REVENUE, DATA OR USE, INCURRED BY ANY USER OR ANY THIRD PARTY IN CONNECTION WITH THE FURNISHING, PERFORMANCE, OR USE OF THIS MATERIAL, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. The entire risk as to the quality and performance of software developed using this specification is borne by you. This disclaimer of warranty constitutes an essential part of the license granted to you to use this specification. RESTRICTED RIGHTS LEGEND Use, duplication or disclosure by the U.S. Government is subject to the restrictions set forth in subparagraph (c) (1) (ii) of The Rights in Technical Data and Computer Software Clause at DFARS 252.227-7013 or in subparagraph (c)(1) and (2) of the Commercial Computer Software - Restricted Rights clauses at 48 C.F.R. 52.227-19 or as specified in 48 C.F.R. 227-7202-2 of the DoD F.A.R. Supplement and its successors, or as specified in 48 C.F.R. 12.212 of the Federal Acquisition Regulations and its successors, as applicable. The specification copyright owners are as indicated above and may be contacted through the Object Management Group, 140 Kendrick Street, Needham, MA 02494, U.S.A. TRADEMARKS MDA®, Model Driven Architecture®, UML®, UML Cube logo®, OMG Logo®, CORBA® and XMI® are registered trademarks of the Object Management Group, Inc., and Object Management Group™, OMG™ , Unified Modeling Language™, Model Driven Architecture Logo™, Model Driven Architecture Diagram™, CORBA logos™, XMI Logo™, CWM™, CWM Logo™, IIOP™ , MOF™ , OMG Interface Definition Language (IDL)™, and OMG Systems Modeling Language (SysML)™ are trademarks of the Object Management Group. All other products or company names mentioned are used for identification purposes only, and may be trademarks of their respective owners. COMPLIANCE The copyright holders listed above acknowledge that the Object Management Group (acting itself or through its designees) is and shall at all times be the sole entity that may authorize developers, suppliers and sellers of computer software to use certification marks, trademarks or other special designations to indicate compliance with these materials. Software developed under the terms of this license may claim compliance or conformance with this specification if and only if the software compliance is of a nature fully matching the applicable compliance points as stated in the specification. Software developed only partially matching the applicable compliance points may claim only that the software was based on this specification, but may not claim compliance or conformance with this specification. In the event that testing suites are implemented or approved by Object Management Group, Inc., software developed using this specification may claim compliance or conformance with the specification only if the software satisfactorily completes the testing suites. OMG’s Issue Reporting Procedure All OMG specifications are subject to continuous review and improvement. As part of this process we encourage readers to report any ambiguities, inconsistencies, or inaccuracies they may find by completing the Issue Reporting Form listed on the main web page http://www.omg.org, under Documents, Report a Bug/Issue (http://www.omg.org/technology/agreement.htm). Table of Contents Preface ................................................................................................v 1 Scope ............................................................................................. 1 2 Conformance .................................................................................. 1 2.1 Conformance Points ................................................................................. 1 2.1.1 Syntax Dimension ............................................................................................ 2 2.1.2 Capability Dimension ....................................................................................... 2 3 Normative References .................................................................... 2 4 Terms and Definitions ..................................................................... 2 5 Symbols .......................................................................................... 2 6 Additional Information ..................................................................... 3 6.1 Changes to Adopted OMG Specifications ................................................ 3 6.2 How to Read this Specification ................................................................ 3 6.3 Acknowledgements ................................................................................. 3 7 Introduction ..................................................................................... 5 7.1 Overview ................................................................................................... 5 8 The Voice Metamodel ..................................................................... 7 8.1 Introduction ............................................................................................... 7 8.2 Voice Service Modeling ............................................................................ 7 8.2.1 Environment ....................................................................................................
Load more

Recommended publications
  • Open Research Online UML in Practice Oro.Open.Ac.Uk
    Open Research Online The Open University’s repository of research publications and other research outputs UML in practice Conference Item How to cite: Petre, Marian (2013). UML in practice. In: 35th International Conference on Software Engineering (ICSE 2013), 18-26 May 2013, San Francisco, CA, USA (forthcoming), pp. 722–731. For guidance on citations see FAQs. c 2013 IEEE Version: Accepted Manuscript Link(s) to article on publisher’s website: http://2013.icse-conferences.org/ Copyright and Moral Rights for the articles on this site are retained by the individual authors and/or other copy- right owners. For more information on Open Research Online’s data policy on reuse of materials please consult the policies page. oro.open.ac.uk UML in Practice Marian Petre Centre for Research in Computing The Open University Milton Keynes, UK [email protected] Abstract—UML has been described by some as “the lingua UML “with rigor” (as he later expressed to the informant). In franca of software engineering”. Evidence from industry does contrast, the informant concluded that probably 45 of the 47 not necessarily support such endorsements. How exactly is UML were like him: “selective borrowers” … “who use some of the being used in industry – if it is? This paper presents a corpus of principles sometimes”. The IBM speaker and the informant interviews with 50 professional software engineers in 50 had very different models of what ‘using UML’ means in companies and identifies 5 patterns of UML use. practice, with different implications. Index Terms—UML, software development, software design, Budgen et al.
    [Show full text]
  • Tool Use in Software Modelling Education
    Tool use in software modelling education Seiko Akayama1, Birgit Demuth3, Timothy C. Lethbridge4, Marion Scholz2, Perdita Stevens5, and Dave R. Stikkolorum6 1 Kyushu University, Japan 2 Vienna University of Technology, Austria 3 Technische Universit¨atDresden, Germany 4 University of Ottawa Canada 5 University of Edinburgh Scotland 6 Leiden University The Netherlands Abstract. An important decision that must be taken by anyone design- ing a course involving (object oriented software) modelling is what tool support, if any, to use. Options include picking an industrial strength modelling tool, using a tool specifically designed for educational use, or eschewing tool use altogether in favour of pencil and paper. The best an- swer will depend on many factors, including the prior experience of the students (and staff), the length and organisation of the course, and the learning objectives. Moreover, decisions on tools have an impact on other aspects of course design. In this informal paper, the result of discussion at the MODELS Educators' Symposium 2013, we survey previous work on this question, discuss our own experience, and draw out some key issues that someone designing a new course involving modelling must consider. 1 Introduction Teaching object oriented design and modelling in a university is important not only because these are important skills that students will need if they pursue careers in software development, but also because this area is a key interface be- tween research and teaching. This double motivation { we might say, vocational and intellectual { for teaching design and modelling is itself a source of challenge for educators. We experience a tension between the desire to train students in the skills they will need after university, and the desire to have them reflect on the nature of design and modelling and the ways in which these activities could be improved with the help of cutting edge research.
    [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]
  • Using Telelogic DOORS and Microsoft Visio to Model and Visualize
    Using DOORS & Visio to Model and Visualize Complex Business Processes Bob Sherman - [email protected] [email protected] Using Telelogic DOORS and Microsoft Visio to Model and Visualize Complex Business Processes - v1.0 © 2005 Galactic Solutions Group LLC – Authors: Bob Sherman ([email protected]), [email protected] 1 © Telelogic AB Agenda • The Unmet Need • The Solution – Strategy: Business Driven Application Lifecycle – Tactics: Business Modeling via DOORS & VISIO – Tactics: DOORS/VISIO Integration • Case Study Results Using Telelogic DOORS and Microsoft Visio to Model and Visualize Complex Business Processes - v1.0 © 2005 Galactic Solutions Group LLC – Authors: Bob Sherman ([email protected]), [email protected] 2 © Telelogic AB Chronic IT Project Problems Top IT Project Problems • User/Stakeholder Engagement Outages • Unclear Objectives • Incomplete or Changing Requirements *Standish Group Chaos Studies Using Telelogic DOORS and Microsoft Visio to Model and Visualize Complex Business Processes - v1.0 © 2005 Galactic Solutions Group LLC – Authors: Bob Sherman ([email protected]), [email protected] 3 © Telelogic AB Chronic IT Project Problems Rework • 35-65% of project budget *Standish Group spent on rework. • ~50% of rework is due to requirements errors * IEEE & University of Southern California Using Telelogic DOORS and Microsoft Visio to Model and Visualize Complex Business Processes - v1.0 © 2005 Galactic Solutions Group LLC – Authors:
    [Show full text]
  • Using Telelogic DOORS and Microsoft Visio to Model and Visualize Complex Business Processes
    Using Telelogic DOORS and Microsoft Visio to Model and Visualize Complex Business Processes “The Business Driven Application Lifecycle” Bob Sherman Procter & Gamble Pharmaceuticals [email protected] Michael Sutherland Galactic Solutions Group, LLC [email protected] Prepared for the Telelogic 2005 User Group Conference, Americas & Asia/Pacific http://www.telelogic.com/news/usergroup/us2005/index.cfm 24 October 2005 Abstract: The fact that most Information Technology (IT) projects fail as a result of requirements management problems is common knowledge. What is not commonly recognized is that the widely haled “use case” and Object Oriented Analysis and Design (OOAD) phenomenon have resulted in little (if any) abatement of IT project failures. In fact, ten years after the advent of these methods, every major IT industry research group remains aligned on the fact that these projects are still failing at an alarming rate (less than a 30% success rate). Ironically, the popularity of use case and OOAD (e.g. UML) methods may be doing more harm than good by diverting our attention away from addressing the real root cause of IT project failures (when you have a new hammer, everything looks like a nail). This paper asserts that, the real root cause of IT project failures centers around the failure to map requirements to an accurate, precise, comprehensive, optimized business model. This argument will be supported by a using a brief recap of the history of use case and OOAD methods to identify differences between the problems these methods were intended to address and the challenges of today’s IT projects.
    [Show full text]
  • Executing UML Models
    Executing UML Models Miguel Pinto Luz1, Alberto Rodrigues da Silva1 1Instituto Superior Técnico Av. Rovisco Pais 1049-001 Lisboa – Portugal {miguelluz, alberto.silva}@acm.org Abstract. Software development evolution is a history of permanent seeks for raising the abstraction level to new limits overcoming new frontiers. Executable UML (xUML) comes this way as the expectation to achieve the next level in abstraction, offering the capability of deploying a xUML model in a variety of software environments and platforms without any changes. This paper comes as a first expedition inside xUML, exploring the main aspects of its specification including the action languages support and the fundamental MDA compliance. In this paper is presented a future new xUML tool called XIS-xModels that gives Microsoft Visio new capabilities of running and debugging xUML models. This paper is an outline of the capabilities and main features of the future application. Keywords: UML, executable UML, Model Debugging, Action Language. 1. Introduction In a dictionary we find that an engineer is a person who uses scientific knowledge to solve practical problems, planning and directing, but an information technology engineer is someone that spends is time on implementing lines of code, instead of being focus on planning and projecting. Processes, meetings, models, documents, or even code are superfluous artifacts for organizations: all they need is well design and fast implemented working system, that moves them towards a new software development paradigm, based on high level executable models. According this new paradigm it should be possible to reduce development time and costs, and to bring new product quality warranties, only reachable by executing, debugging and testing early design stages (models).
    [Show full text]
  • Early Verification and Validation in Model-Based Design
    ® ® Early Verification and Validation in Model-Based Design Amory Wakefield Technical Marketing The MathWorks © 2008 TheMathWorks, Inc. ® ® Introductions I spend most of my time: A. Creating specifications and requirements (systems and software) B. Implementation based on specification and requirements created by somebody else (generating, writing, deploying, debugging code) C. Both D. None of the above 2 ® ® Address the Entire Development Process RequirementsRequirements Design System V&V Requirements Validation Environment Robustness Testing Modeling Standards Checking Physical Components Component V&V Algorithms Design Verification Model Testing G e H t e Coverage and Test Generation G a a n e nd r e n - e r Property Proving e n a ra t te e e G Code Verification Digital Embedded Code Correctness Electronics Software Processor-In-The Loop Testing VHDL, Verilog C, C++ FPGA ASIC MCU DSP Integration Testing Software Integration Testing Integration Hardware-in-the-Loop Testing Hardware Connectivity Implement 3 ® ® Methods for Verification and Validation Traceability Requirements to model and code Model to code Modeling and Coding Standards Modeling standards checking Coding standards checking Testing Model testing in simulation Processor-in-the-loop Proving Proving design properties Proving code correctness 4 ® ® Increasing Confidence in Your Designs Confidence Traceability Modeling and Coding Model and Code Proving Design Standards Checking Testing Properties and Code Correctness Verification Method 5 ® ® Traceability System V&V Comp. V&V Integration Functional Requirements Design Environment Physical Components Tracing RequirementsÙModel Simulink Verification and Validation Algorithms H G e Tracing ModelÙSource Code G an t e e d a n ne - r e ra e r t n a e t Real-Time Workshop Embedded Coder e e G Digital Embedded Electronics Software Tracing RequirementsÙSource Code VHDL, Verilog C, C++ Simulink Verification and Validation FPGA ASIC MCU DSP Integration Implement 6 ® ® Tracing RequirementsÙModel System V&V Comp.
    [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]
  • Challenges and Opportunity of UML Diagram for Software Project Development As a Complete Modeling Tool
    IOSR Journal of Mobile Computing & Application (IOSR-JMCA) e- ISSN: 2394-0050, P-ISSN: 2394-0042.Volume 7, Issue 3 (May - June 2020), PP 46-48 www.iosrjournals.org Challenges and Opportunity of UML Diagram for Software Project development as a complete Modeling Tool Ketema Kifle Gebretsadik1 Debre Markos University, School of Computing, Institute of Technology, Debre Markos, Ethiopia Abstract: UML(Unified Modeling Language) is a most useful method of visualization and documenting software systems design.UML uses object oriented design concepts and it is independent of specific programming language. Unified Modeling Language is a popular technique for documenting and modeling system. The UML uses set of symbols to represent graphically the various components and relationships within the system and UML can be used for business processing modeling and requirements modeling, it mainly is used to support object oriented system analysis and to develop the object models. Many articles describe UML features, but only very few of them discuss its downside in software design. This article discusses the downside of UML as a complete modeling tool for software design. Some of the disadvantages of UML areno specification for modeling of user interfaces, business rule specification a group exists for this within theObject Management Group(OMG), so we should see something in UML and Poor for distributed systems are no way to formally specify serialization and object persistence.Even though UML have many advantages it has also their owndownside for software design. Keyword: UML, Challenge of UML, Software design, UML diagrams ----------------------------------------------------------------------------------------------------------------------------- ---------- Date of Submission: 22-05-2020 Date of Acceptance: 09-06-2020 ----------------------------------------------------------------------------------------------------------------------------- ---------- I.
    [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]
  • Introduction to OMG's Unified Modeling Language (UML) a Little
    07.02.2006 Introduction to OMG's Unified Modeling Language (UML) Dominic Hillenbrand CES - Chair for Embedded Systems (Prof. Dr. Jörg Henkel) Department of Computer Science University of Karlsruhe Chair for Embedded Systems Universität Karlsruhe (TH) <your Name> WS 2005-06 Software Engineering for Embedded Systems A Little History Late 1960s: ¾ Emergence of OO programming languages (Simula-67 language) ¾ Appearance of first OOA&D methodologies 1980s and early 1990s: ¾ Smalltalk (1972) ¾ Many competing general development methods and modelling languages (over 50) Alan Curtis Kay ¾ The “methods wars” „The best way to predict the Excursion: Structured Analysis & future is to Design together with structured invent it." programming preceded the OO- paradigm! Chair for Embedded Systems Universität Karlsruhe (TH) Dominic Hillenbrand WS 2005-06 1 07.02.2006 Software Engineering for Embedded Systems How things got started The Three Amigos and their three prominent key methods (mid 1990s): ¾ Grady Booch (Booch ’93 “OO Analysis and Design) ¾ Rumbaugh (Object Modelling Technique) ¾ Ivar Jacobson (OO Software Engineering) Chair for Embedded Systems Universität Karlsruhe (TH) Dominic Hillenbrand WS 2005-06 Software Engineering for Embedded Systems More Background 1995: Rumbaugh, Booch and Jacobson join forces in Rational: ¾ Develop the (Rational) Unified Process ¾ Develop the Unified Modelling Language (UML) Object Management Group (OMG): ¾ not-for-profit consortium ¾ produces and maintains computer industry specifications ¾ flagship specification is the multi- platform Model Driven Architecture (MDA) Chair for Embedded Systems Universität Karlsruhe (TH) Dominic Hillenbrand WS 2005-06 2 07.02.2006 Software Engineering for Embedded Systems What is UML? UML is a language –semantics& syntax ¾ Not a methodology! (like RUP; Waterfall & Spiral-Model) UML can be used to ¾ specify ¾ visualize ¾ document software artifacts Built upon fundamental OO concepts “industry’s best” engineering practices 13 types of diagrams Usually textual specifications in automobile industry.
    [Show full text]
  • Fakulta Informatiky UML Modeling Tools for Blind People Bakalářská
    Masarykova univerzita Fakulta informatiky UML modeling tools for blind people Bakalářská práce Lukáš Tyrychtr 2017 MASARYKOVA UNIVERZITA Fakulta informatiky ZADÁNÍ BAKALÁŘSKÉ PRÁCE Student: Lukáš Tyrychtr Program: Aplikovaná informatika Obor: Aplikovaná informatika Specializace: Bez specializace Garant oboru: prof. RNDr. Jiří Barnat, Ph.D. Vedoucí práce: Mgr. Dalibor Toth Katedra: Katedra počítačových systémů a komunikací Název práce: Nástroje pro UML modelování pro nevidomé Název práce anglicky: UML modeling tools for blind people Zadání: The thesis will focus on software engineering modeling tools for blind people, mainly at com•monly used models -UML and ERD (Plant UML, bachelor thesis of Bc. Mikulášek -Models of Structured Analysis for Blind Persons -2009). Student will evaluate identified tools and he will also try to contact another similar centers which cooperate in this domain (e.g. Karlsruhe Institute of Technology, Tsukuba University of Technology). The thesis will also contain Plant UML tool outputs evaluation in three categories -students of Software engineering at Faculty of Informatics, MU, Brno; lecturers of the same course; person without UML knowledge (e.g. customer) The thesis will contain short summary (2 standardized pages) of results in English (in case it will not be written in English). Literatura: ARLOW, Jim a Ila NEUSTADT. UML a unifikovaný proces vývoje aplikací : průvodce ana­lýzou a návrhem objektově orientovaného softwaru. Brno: Computer Press, 2003. xiii, 387. ISBN 807226947X. FOWLER, Martin a Kendall SCOTT. UML distilled : a brief guide to the standard object mode•ling language. 2nd ed. Boston: Addison-Wesley, 2000. xix, 186 s. ISBN 0-201-65783-X. Zadání bylo schváleno prostřednictvím IS MU. Prohlašuji, že tato práce je mým původním autorským dílem, které jsem vypracoval(a) samostatně.
    [Show full text]