DOCSLIB.ORG

Overview Chapter 3 the Unified Process (3.1) the Unified Process

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Overview Chapter 3 the Unified Process (3.1) the Unified Process 1/11/2008 Overview Slide 2.1 Chapter 3 The Unified Process (3.1) Slide 2.2 z Software life-cycle models z Until recently, three of the most successful object- – Theoretical model oriented methodologies were – Iterative and incremental model – Grady Booch’s method – Code-and-fix life-cycle model – Ivar Jacobson’s Objectory – Waterfall (documentation driven model) – Jim Rumbaugh’s Object Modeling Technique (OMT) – Rapid prototyping life-cycle model – Open-source life-cycle model – Agile processes – Synchronize-and-stabilize life-cycle model – Spiral life-cycle model (risk driven) z Unified process z Capability Maturity Models (CMM) CS510 Software Engineering at Purdue CS510 Software Engineering at Purdue 3.2 Iteration and Incrementation within the Object-Oriented Paradigm The Unified Process (contd) Slide 2.3 Slide 2.4 z In 1999, Booch, Jacobson, and Rumbaugh z The Unified Process is a modeling technique published a complete object-oriented analysis and – A model is a set of UML diagrams that represent design methodology that unified their three various aspppects of the software product we want to separate methodologies develop – Original name: Rational Unified Process (RUP) – Next name: Unified Software Development Process z UML stands for unified modeling language (1997 (USDP) by three Amigos) – Name used today: Unified Process (for brevity) – Graphically represent (model) the target software product CS510 Software Engineering at Purdue CS510 Software Engineering at Purdue 1 1/11/2008 Iteration and Incrementation within the Object-Oriented Paradigm (contd) Slide 2.5 3.10 The Phases of the Unified ProcessSlide 2.6 z The object-oriented paradigm is iterative and z The increments are identified as phases incremental in nature – There is no alternative ttoo repeated iteration and incrementation until the UML diagrams are satisfactory CS510 Software Engineering at Purdue CS510 Software Engineering at Purdue Figure 3.1 Requirements Workflow Slide 2.7 Requirements Pyramid Slide 2.8 z From Chapters 1 and 2 of the book “Requirement Management Using IBM Rational RequisitePro” – Online simplified version » http://www.ibm.com/developerworks/rational/library/04/r-3217/ z Definitions – Requirement – a condition or capability to which a system must conform » Capability – the needs of customers » Condition – constraints – Stakeholder – someone who is affected by the system that is being developed » Customer » User – A travel agency website CS510 Software Engineering at Purdue CS510 Software Engineering at Purdue 2 1/11/2008 Requirements Pyramid Slide 2.9 Requirements Pyramid Slide 2.10 z Need z Supplementary requirement – a requirement from a stakeholder – Other requirement (usually nonfunctional) that cannot – Usually 5-15 high level needs be captured in use cases » “Data should be persistent” » “System should use Oracle 9i” z Feature z Test case – a service provided by the system, usually formulated by – A specification of test inputs, execution conditions, and a business analyst; a purpose of a feature is to fulfill a expected output need z Scenario » “System should use a relational database” – A specific sequence of actions; a path through a use z Use cases case; an instance of the use case – a description of system behavior in terms of sequences z Vision statement of actions – Needs and features CS510 Software Engineering at Purdue CS510 Software Engineering at Purdue Traceability Slide 2.11 RequisitePro Slide 2.12 z Everything z A CASE tool z Nothing more – Integrated with z Impact word » Text-based – Management of traceability CS510 Software Engineering at Purdue CS510 Software Engineering at Purdue 3 1/11/2008 Use Cases Slide 2.13 Uses Cases Slide 2.14 z Goals of use cases z Format – To facilitate agreement between developers, customers, – Brief description and users about the syy(stem (contract ) – Flow of events – A basis for use-case realizations » Basic flow – An input for test cases » Alternative flow 1 » Alternative flow 2 – Special requirements – Preconditions – PtPost-conditions – Extension points – Context diagram – Activity diagram CS510 Software Engineering at Purdue CS510 Software Engineering at Purdue Use Cases Slide 2.15 Analysis and Design Workflow (Rational ROSE)Slide 2.16 z Example (the basic flow of the “place an order” z ROSE= Rational Object Oriented Software Engineering use case in an online bookstore project) z Used for object-oriented – B1 User enters web site address in the browser. System displays login page. analysis, modeling, design, and – B2 User enters an email address and a password. System confirms correct login, presents main page, and prompts for a search string. construction. – B3 User enters search string – partial name of a book. System returns all books z A set of visual modeling matching search criteria. components. – B4 User selects a book. System presents detailed information about a book. – B5 User adds the book to a shopping cart. Shopping cart contents is presented to the user. – B6 User selects "proceed to checkout" option. System asks for confirmation of a shipping address . – B7 User confirms shipping address. System presents shipping options. – … z Example (alternative flows) – Unregistered user – … – Invalid credit card CS510 Software Engineering at Purdue CS510 Software Engineering at Purdue 4 1/11/2008 Diagrams in Rational Rose Slide 2.17 Use Case Diagram Slide 2.18 z Structural Diagram z Actor – Class Diagram – Component Diagram – Deployment Diagram z Behavioral Diagram – Use-Case Diagram – Interaction Diagram » Sequential Diagram » Collaboration Diagram – State Diagram – Activity Diagram CS510 Software Engineering at Purdue CS510 Software Engineering at Purdue Activity Diagrams Slide 2.19 Class Diagrams Slide 2.20 CS510 Software Engineering at Purdue CS510 Software Engineering at Purdue 5 1/11/2008 Sequence Diagrams Slide 2.21 Test Workflow Slide 2.22 z From Use Cases to Test Cases (functional testing) – Scenarios Infinite loops – 2 times CS510 Software Engineering at Purdue Explosion – exclude CS510unreasonable Software Engineering atcombination Purdue From Scenarios To Test Cases Slide 2.23 Step 1. Identify Variables Slide 2.24 z Identify variables for each use case step z Example – B2 User enters an email address and a password. System confirms z Identify significantly different options for each correct login, presents main page, and prompts for a search string. variable » Email and password z Combine options to be tested into test cases – B3 User enters search string – partial name of a book. System returns all books matching search criteria. z Assign values to variables » Search string – B4 User selects a book. System presents detailed information about a book. » Book selection …… CS510 Software Engineering at Purdue CS510 Software Engineering at Purdue 6 1/11/2008 Step 2. Identify Options Slide 2.25 Option Examples Slide 2.26 Step Variable Options to be tested z Options are “significantly different” B1 Website Actual URL One more Min Max – Trigger different flow than Very long Invalid (no B2 Email Regular Blank allowed (1 allowed (50 allowed (51 (257 char) @ sign) char) char) » Vaadlid vs . inva adusedslid user ids char) One more – Trigger different error messages Min Max Too short than Very long B2 Password Regular Blank allowed (6 allowed (10 (5 char) allowed (11 (257 char) » “Email too long” vs. “Invalid email address” char) char) char) One more – Trigger different UIs Min Max Search than B3 Regular Blank allowed (1 allowed » Credit card vs. Gift card string allowed char) (300 char) (301 char) – Trigger different business rules First Last B4 Selection » Overnight shipping <6pm and >6pm selection selection Add to Action B5 shopping – Boundary values selection cart Action Proceed to … … B6 selection checkout Confirm the Shipping B7 address on address file Shipping B8 5 days 3 days 2 days Overnight CS510 Software Engineering at Purdue method CS510 Software Engineering at Purdue Step 3. Combine Options Into Test CasesSlide 2.27 Step 3. Combine Options Into Test CasesSlide 2.28 CS510 Software Engineering at Purdue CS510 Software Engineering at Purdue 7 1/11/2008 Step 4. Assign Values to Variables (T1)Slide 2.29 Rational Robot and Test Manager Slide 2.30 Variable or Expected Step number Value Actual result Pass/Fail Comments selection result z Robot www.amazon. B1 Website Logon Screen com – GUI scripts for functional testing jsmith@hotmai B2 Email lcoml.com – Virtual users (VU) sessions for performance testing B2 Password Johnsm Main Screen z Test Manager B3 Search string “Rational” List of books B4 Book selection First selection Book details – Scripts play back. Action Add to B5 Cart contents selection shopping cart Action Proceed to Prompt for B6 selection checkout address Shipping Confirm the Prompt for B7 address address on file shipping Shipping Prompt for B8 5 days method payment Confirm the Payment Prompt for B9 credit card on method confirmation file Action B10 Place an order Order number selection CS510 Software Engineering at Purdue CS510 Software Engineering at Purdue 3.12 Improving the Software Process (OOSE C3)Slide 2.31 What is the CMM (I)?... Slide 2.32 z The fundamental problem with software – The software process is badly managed z Software process improvement initiatives “The CMM is a 5-level model where each – Capability maturity model (CMM) by Software maturity level is “a well-defined evolutionary Engineering Institute (SEI) plateau on the path towards becoming a mature – ISO 9000-series software organisation”.” – ISO/IEC 15504 SEI SEI CMM CS510 Software
Load more

Recommended publications
  • 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]
  • Handout 4 the Unified Modeling Language with Markup Ed Rosten
    3F6 - Software Engineering and Design Handout 4 The Unified Modeling Language With Markup Ed Rosten Contents 1. Diagram Types 2. Class Diagrams 3. Object Diagrams 4. Sequence Diagrams 5. Communication Diagrams 6. State Diagrams Copies of these notes plus additional materials relating to this course can be found at: http://mi.eng.cam.ac.uk/~er258/teaching. The Unified Modeling Language 1 The Unified Modeling Language • a formal graphical language comprising a set of diagrams for describing software systems. • used for designing, documenting and communicating various views of the software architecture and program behaviour. • these different views of the system can be used at varying scales, presenting the key information and suppressing unim- portant detail as desired. Historical Note UML evolved from three earlier rival approaches independently developed between 1989 and 1994. • Booch method developed by Grady Booch of the Rational Software Corporation. • Object Oriented Software Engineering (OOSE) devel- oped by Ivar Jacobson of Objectory. • Object Modeling Technique (OMT) developed by James Rumbaugh of General Electric. The first complete version of UML (V1.1) was released in 1997 by a consortium which included DEC, HP, IBM, Microsoft, Oracle, and Texas Instruments. The current release is V2.0 which is used in this course. 2 Engineering Part IIA: 3F6 - Software Engineering and Design Diagram Types Structural Diagrams which describe the architecture or lay- out of the system. 1. Class. These describe the software architecture of the sys- tem by specifying what classes are present in the system, and their relationships. 2. Object. These describe a snapshot of the system while it is running and identify what objects are present at a given instant, and their relationships.
    [Show full text]
  • A Comparative Study of Three New OO Methods
    A Comparative Study of Three New OO Methods Michael M Mattsson Department of Computer Science University of Karlskrona/Ronneby S-372 25 Ronneby, Sweden E-mail: [email protected] Abstract In this paper we will compare and contrast some of the newer methods with some of the established methods in the field of object-oriented software engineering. The methods re- viewed are Solution-Based Modelling, Business Object Notation and Object Behaviour Analysis. The new methods offer new solutions and ideas to issues such as object identi- fication from scenarios, traceability supporting techniques, criteria for phase completion and method support for reliability. Although all these contributions, we identified some issues, particular design for dynamic binding, that still have to be taken into account in an object-oriented method. 1. Introduction The past years have seen the emergence of quite a number of different methods for object- oriented development. Although many of them have now been applied and tested on many real-world projects from which experience reports have been published, the software manager is still facing a daunting task when he is to select the best method for his organ- isation. Furthermore, the area is still evolving and new methods continue to appear every year. A major problem is that terminology and style of presentation make the methods look more different than they really are, thereby obscuring the truly differentiating issues. In this paper we will evaluate some recently published object-oriented methods and high- light those features which are truly innovative contributions. The methods which have been studied are [Gol92], [Ner93],[Rub 92].
    [Show full text]
  • Object-Oriented Analysis and Design with Applications / Grady Booch
    OBJECT-ORIENTED ANALYSIS AND DESIGN With applications SECOND EDITION Grady Booch Rational Santa Clara, California ADDISON-WESLEY Preface To Jan My friend, my lover, my wife Sponsoring Editor: Dan Joraanstad Production Editor: Wendy Earl Editorial Assistant: Melissa Standen Cartoonist: Tony Hall Copy Editor: Nicholas Murray Proofreader: Eleanor Renner Brown Cover Designer: Yvo Riezebos Design Design Consultant: David Granville Healy Adobe illustrator is a trademark of Adobe Systems, Inc. Apple, Macintosh, and MacApp are trademarks of Apple Computer, Inc. Booch Components is a trademark of Grady Booch. Eiffel is a trademark of Interactive Software Engineering, Inc. Mathematica is a trademark of Wolfram Research, Inc. Motif is a trademark of Open Software Foundation, Inc. Objective-C is a trademark of Stepstone. Objectworks and Smalltalk-80 are trademarks of ParcPlace Systems. OS/2 is a trademarks of International Business Machines. Pure Software is a trademarks of Pure Software, Inc. Rational and Rational Rose are trademarks of Rational. Simula 67 is a trademark of Simula AS. UNIX is a trademark of AT&T Technologies, Inc. Windows and Word are trademarks of Microsoft Inc. Camera-ready copy for this book was prepared on a Macintosh with Microsoft Word and Adobe Illustrator. All C++ examples were developed using tools from Apple Computer, AT&T, Borland International, Centerline, Pure Software, and Sun Microsystems. The notation and process described in this book is in the public domain, and its use by all is encouraged (but please acknowledge its source). Copyright © 1994 by Addison Wesley Longman, Inc. All rights reserved. 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, or otherwise, without the prior written permission of the publisher.
    [Show full text]
  • UML Approach to Modeling NIEM Exchanges – Overview and Scenario Planning 1
    Technical Brief August 2015 SEARCH The National Consortium for Justice Information and Statistics A Unified Modeling Language Approach to Modeling NIEM Exchanges: Overview and Scenario Planning By Diane Lacy Information Sharing Specialist SEARCH Introduction Purpose This is the first of two Technical Briefs that provide an approach to using the Unified Modeling Language1 (UML) 2.0 to model web services associated with exchanges that are compliant with the National Information Exchange Model (NIEM)2 and the Global Reference Architecture (GRA).3 The intent is to present a “best practice” process to create a UML model that fully conveys the business and technical information needed to define, develop, and deploy exchange services. A NIEM Information Exchange Package Document (IEPD) defines a recurring message in XML and is built to satisfy information exchange business requirements. A GRA Service Specification also describes other required aspects of information exchange implementations, including access controls, security, policy automation, transmission protocol, and others. Both NIEM and GRA are closely associated with Service-Oriented Architecture (SOA), as is UML. UML provides features and techniques to model and assemble components into orchestrated SOA services. This brief provides an overview of UML and discusses features and techniques that modelers can use to support the Scenario Planning phase of IEPD development (Figure 1 shows the six phases in NIEM IEPD life cycle development). The second Technical Brief discusses the UML diagrams that support the Analyze Requirements and Map and Model phases and briefly discusses the service infrastructure environment. 1 http://www.uml.org/ 2 http://reference.niem.gov/ 3 https://it.ojp.gov/initiatives/gra A UML Approach to Modeling NIEM Exchanges – Overview and Scenario Planning 1 Figure 1: NIEM IEPD Life Cycle Development Figure 2 is a process diagram that summarizes the topics covered in the two Technical Briefs.
    [Show full text]
  • CA3203 OOAD Lecture19
    Rumbaugh Methodology Booch Methodology Jacobson Methodology KRISHNENDU GUHA ASSISTANT PROFESSOR (ON CONTRACT) NATIONAL INSTITUTE OF TECHNOLOGY (NIT), JAMSHEDPUR EMAIL: [email protected] Rumbaugh Methodology It was developed around 1991 by Rumbaugh, Blaha, Premerlani, Eddy and Lorensen as a method to develop object-oriented systems and to support object-oriented programming OMT (Object Modeling Technique) describes a method for the analysis, design, and implementation of a system using an object-oriented technique. Class attributes, method, inheritance, and association also can be expressed easily Describing Object Model or the static structure of the system James Rumbaugh Phases of OMT OMT consists of four phases, which can be performed iteratively: Analysis -The results are objects and dynamic and functional models System Design - The result is a structure of the basic architecture of the system. Object Design - This phase produces a design document, consisting of detailed objects and dynamic and functional models Implementation- This activity produces reusable, extendible, and robust code OMT Modeling OMT separates modeling into three different parts: An object model, presented by the object model and the data dictionary. structure of objects in a system. Identity, relationships to other objects, attributes and operations. Object diagram Classes interconnected by association lines Classes- a set of individual objects Association lines- relationship among classes (i.e., objects of one class to objects of another class) A dynamic model, presented by the state diagrams and event flow diagrams. States, transitions, events and actions OMT state transition diagram-network of states and events A functional model, presented by data flow and constraints The Rumbaugh object model is very much like an entity relationship diagram except that there are now behaviors in the diagram and class hierarchies.
    [Show full text]
  • Engineering the Object- Oriented Software Process: OPEN and Mentor
    OPEN-MeNtOR A Technical Overview Engineering the Object- Oriented Software Process: OPEN and MeNtOR Presented by Tony Simons Object Oriented Pty Ltd OPEN Consortium Version 1.0: May, 1996 Slide 1 OPEN-MeNtOR A Technical Overview Overview Where have OO Methods come from? Where are OO Methods going? Beyond Methods......... to a Process Architecture approach to OO development Context & Background to OPEN and MeNtOR? A Brief Tour of OPEN/MeNtOR Fundamentals of OPEN/MeNtOR Software Engineering Process Software Engineering Process Architecture Summary Deploying an OO Process Summary Object Oriented Pty Ltd OPEN Consortium Version 1.0: May, 1996 Slide 2 OPEN-MeNtOR A Technical Overview Where Did It All Begin? 1960s Simula 67 - OO Concepts class object inheritance relationships polymorphism Refined and applied in 1970s with Smalltalk Semantic data modelling Object Oriented Pty Ltd OPEN Consortium Version 1.0: May, 1996 Slide 3 OPEN-MeNtOR A Technical Overview Foundational Concepts Object Oriented Concepts (1960-70s) Object Oriented Pty Ltd OPEN Consortium Version 1.0: May, 1996 Slide 4 OPEN-MeNtOR A Technical Overview What did we do? Limited commercial application mainly R&D labs specialised applications small to medium sized programs Developed program level support material C++/Smalltalk coding standards and guidelines programming language review checklist of what to look for and what not to do OO design tips and hints Methodology = set of programming level standards, tips and hints Object Oriented Pty Ltd OPEN Consortium Version
    [Show full text]
  • Run-To-Completion Step (1)
    Run-to-Completion Step (1) RTC(env, conf ) ≡ ⎡event ← fetch() step ← choose steps(conf, event) if step = ∅∧event ∈ deferred(conf ) then defer(event) fi for transition ∈ step do conf ← handleTransition(env, conf, transition) od if isCall (event) ∧ event ∉ deferred(conf ) then acknowledge(event) fi conf ⎦ Modelling with UML, with semantics 131 Run-to-Completion Step (2) steps(env, conf, event) ≡ ⎡transitions ← enabled(env, conf, event) ⎦ { guard ٧ step | (guard, step) ∈ steps(conf, transitions) ∧ env} steps(conf, transitions) ≡ ⎡steps ← {(true, ∅)} for transition ∈ transitions do for (guard, step) ∈ steps(conf, transitions \{transition}) do if inConflict(conf, transition, step) then if higherPriority(conf, transition, step) then guard ← guard ∧ ¬guard(transition) fi else step ← step ∪ {transition} guard ← guard ∧ guard(transition) fi steps ← steps ∪ {(guard, step)} od od steps⎦ Modelling with UML, with semantics 132 Run-to-Completion Step (3) handleTransition(conf, transition) ≡ ⎡for state ∈ insideOut(exited(transition)) do uncomplete(state) for timer ∈ timers(state) do stopTimer(timer) od execute(exit(state)) conf ← conf \{state} od execute(effect(transition)) for state ∈ outsideIn(entered(transition)) do execute(entry(state)) for timer ∈ timers(state) do startTimer(timer) od conf ← conf ∪ {state} complete(conf, state) od conf ⎦ Modelling with UML, with semantics 133 Semantic variation points • Some semantic variation points have been mentioned before. • delays in event pool • handling of deferred events • entering of composite states without default entry • Which events are prioritized? • completion events only • all internal events (completion, time, change) • Which (additional) timing assumptions? • delays in communication • time for run-to-completion step • zero-time assumption Modelling with UML, with semantics 134 State machine refinement • State machines are behaviors and may thus be refined.
    [Show full text]
  • Modern Object-Oriented Software Development
    MODERN OBJECT-ORIENTED SOFTWARE DEVELOPMENT A.N. Dunlop University of Southampton, SO17 1BJ, England Abstract Object-oriented (OO) programming has been around for a few years and there are many users of OO programming languages. There are, however, few true practitioners of this method. Just as it is possible to use a screwdriver as a ham- mer, programming with an OO language does not imply that the language is being used correctly. The same was true with the onset of structured program- ming languages. The development of these languages did not instantly result in users producing beautifully structured code without use of the infamous “goto”. It was only later that good programming practice or an appropriate methodology was defined for this programming style. OO programming has now reached a similar situation where “good programming practice” can be defined. In this paper we describe the change in emphasis in moving from procedural to OO programming and describe some of the main techniques that are now promoted to ensure the development of good OO programs. 1 FROM PROCEDURAL TO OBJECT-ORIENTED PROGRAMMING Object-oriented programming is the dominant programming paradigm, replacing the “structured”, procedural- based methods of the early 1970’s. Procedural programming is based on developing algorithms and subsequently a suitable data structure [18] for the problem. Object-oriented programming reverses this order putting the emphasis on designing the data structure first, and only then determining the algorithms that operate on the data. This is the more logical order as requirements often change during program development and maintenance, necessitating the development of additional functions.
    [Show full text]
  • A Quick Introduction to UML, the Unified Modeling Language
    UML, the Unified Modeling Language William H. Mitchell (whm) Mitchell Software Engineering (.com) UML, Slide 1 ©2003 by William H. Mitchell What is UML? "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".— OMG UML Specification "UML is a graphical notation for modeling various aspects of software systems." — whm UML, Slide 2 ©2003 by William H. Mitchell Why use UML? Two questions, really: Why use a graphical notation of any sort? Facilitates construction of models that in turn can be used to: Reason about system behavior Present proposed designs to others Document key elements of design for future understanding Which graphical notation should be used? UML has become the de-facto standard for modeling object- oriented systems. UML is extensible and method-independent. UML is not perfect, but it's good enough. UML, Slide 3 ©2003 by William H. Mitchell The Origins of UML Object-oriented programming reached the mainstream of programming in the late 1980's and early 1990's. The rise in popularity of object-oriented programming was accompanied by a profusion of object-oriented analysis and design methods, each with its own graphical notation. Three OOA/D gurus, and their methods, rose to prominence Grady Booch — The Booch Method James Rumbaugh, et al. — Object Modeling Technique Ivar Jacsobson — Objectory In 1994, Booch and Rumbaugh, then both at Rational, started working on a unification of their methods. A first draft of their Unified Method was released in October 1995.
    [Show full text]
  • Unified Modeling Language 11
    Unified Modeling Language 11 Unified Modeling Language Unified Modeling Language ((UML) is a standardized, general-purpose modeling language in the field of software engineering. The Unified Modeling Language includes a set of graphic notation techniques to create visual models of object-oriented software-intensive systems. The Unified Modeling Language was developed by Grady Booch, Ivar Jacobson and James Rumbaugh at Rational Software in the 1990s.[1][1] It was adopted by the Object Management Group (OMG) in 1997, and has been managed by this organisation ever since. In 2000 the Unified Modeling Language was accepted by the International Organization for Standardization (ISO) as industry standard for modeling software-intensive systems. The current version of the UML is 2.4.1 published by the OMG in August of 2011. Overview Unified Modeling Language (UML) combines techniques from data modeling (entity relationship diagrams), business modeling (work flows), object modeling, and component modeling. It can be used with all processes, throughout the software development life cycle, and across different implementation technologies.[2][2] The Unified Modeling Language (UML) offers a standard way to visualize a system's architectural blueprints, including elements such as: •••• aaccttiivviittiieess •••• aaccttoorrss A collage of UML diagrams. •• bubusisinenessss prprococesessesess •• dadatatababasese scschehemamass •• (lo(logigicacal)l) cocompmpononenentsts •• proprogragrammimmingng llanganguaguage se stattatemeementsnts •• reureusabsablele sofsoftwatwarere comcomponponentents.s.[3][3] UML has synthesized the notations of the Booch method, the Object-modeling technique (OMT) and Object-oriented software engineering (OOSE) by fusing them into a single, common and widely usable modeling language.[4][4] UML aims to be a standard modeling language which can model concurrent and distributed systems.
    [Show full text]
  • Review of UML
    1 Review of UML The purpose of this chapter is to set the scene by reviewing the key UML concepts, the main diagram types, and the role of those diagrams within the software development process. If you're quite new to UML this will serve as a practical introduction that will help you make sense of the rest of the book, before you move on to further reading. If you're experienced with UML the chapter will serve as handy revision and you might just find some nuggets of information that have so far eluded you. Either way we'll all be moving on from roughly the same starting point: with the same appreciation of UML notation, with an understanding of relevant software development processes, and with a common bias towards .NET and the Visio for Enterprise Architects tool. The final point is quite important, and the raison d'être for this book. In recent years the body of UML literature has focused mainly on Java development and the use of modeling tools such as Rational Rose. In this book we're applying a .NET development perspective at the same time as demonstrating the so far under-documented Visio modeling tool that comes bundled with the Visual Studio .NET Enterprise Architect. With all this in mind we can now press on with the introduction to – or revision of, depending on your background – the Unified Modeling Language. What is the Unified Modeling Language? When discussing UML, we need to establish one important point right up front. The Unified Modeling Language is a notation; that is a set of diagrams and diagram elements that may be arranged to describe the design of a software system.
    [Show full text]