Introduction to Rational Unified Process Chapter 2 Text

Introduction to Rational Unified Process Chapter 2 Text Modified in many cases to support instructional needs. Original developed by Rational Readings: RUP Chap 1, pp 1 -16; Chapters 2 and 3. Unified Software Practices v 5. 0 -D Copyright Ó 1998 Rational Software, all rights reserved 19 1

Objectives: Rational Unified Process We have talked about these in general. Now, for a more formal discussion: w Describe the Unified Modeling Language (UML) w Define what a Software Development Process is w Describe the Rational Unified Process (RUP) w Explain the four phases of the Rational Unified Process and their associated milestones w Define iterations and their relation to phases w Define artifact, worker, and activity (in RUP Workflows) w State the importance of automated tool support Unified Software Practices v 5. 0 -D Copyright Ó 1998 Rational Software, all rights reserved 19 2

The RUP w Software Development is a process of developing a software system from requirements (functional and non-functional). w A software process provides a disciplined approach to assigning tasks and responsibilities to ensure the production of high-quality software within a predictable schedule / budget. w In building a system, a language (like English) is Not Enough w We need a Modeling Language! Some kind of ‘universal notation. ’ Unified Software Practices v 5. 0 -D Copyright Ó 1998 Rational Software, all rights reserved 19 3

So, we need both a Process and a Modeling Language For our first process, we will follow the Rational Unified Process (RUP) or simply UP (Unified Process) We need a modeling langue: We will use the Unified Modeling Language, (UML) For the Process, we need standards for artifacts produced by workers in roles undertaking work items or activities during development For Modeling, we need a language that has a very high value as a common modeling language. So, we are talking about a Process (UP) and a modeling language (UML). Unified Software Practices v 5. 0 -D Copyright Ó 1998 Rational Software, all rights reserved 19 4

What Is the UML? w The Unified Modeling Language (UML) is a language for • • Specifying Visualizing Constructing Documenting the artifacts of a software-intensive system Important to note that UML does not dictate an OO approach – but greatly supports it! Note: UML is a ‘notation. ’ It is not a process. Unified Software Practices v 5. 0 -D Copyright Ó 1998 Rational Software, all rights reserved 19 5

The UML Provides Standardized Diagrams (Views) Use-Case Activity Diagrams State Class Diagrams Use-Case Diagrams Scenario Sequence Diagrams Models Scenario Collaboration Diagrams Deployment Diagrams State Object Diagrams State Diagrams Component Diagrams • In building visual models, many different diagrams are needed to represent different views of the system. (different views to different stakeholders). • Use Case Diagrams (ahead) – illustrate user interactions with the application. • Activity Diagrams illustrate the flow of events in a Use Case (all scenarios). • Class diagrams represent logical structure, while • Interaction Diagrams illustrate behavior (show objects collaborate via message passing to provide features (responsibilities) of the objects. . • Other diagrams are used to illustrate other viewpoints; e. g. State Diagrams, Unified Software Practices v 5. 0 -D Copyright Ó 1998 Rational Software, all rights reserved 19 6

A Sample UML Diagram: Use-Case Diagram Use Case Diagrams are used to show the existence of Use Cases and their relationships both to other Use Cases and to Actors. A University Course Registration System Boundary Register for Courses Student An Actor is something/one external to the system that interfaces with the system and receives ‘value, ’ from it, such as a user or client. Professor Select Courses to Teach A Use Cases model dialogue (interchange) between actors and system. A Use Case is initiated by an Actor to invoke functionality – like Register for Courses Course Catalog Maintain Professor Information Maintain Student Information Registrar Close Registration Arrow indicates direction of initiation of Billing System the interaction. A Use Case/ Use Case Narrative/ Specification is a complete, meaningful flow of events! Unified Software Practices v 5. 0 -D Copyright Ó 1998 Rational Software, all rights reserved 19 7

A Sample UML Class Diagram A University Course Registration System <> Maintain. Schedule. Form <> Main. Form // select maintain schedule() 1 0. . 1 + // open() + // select four primary and two alternate offerings() 1 1 <> Course. Catalog. System 1 <> Registration. Controller 0. . * // get course offerings() Classes – different kinds (here, boundary, control, entity classes) Note: multiplicity; association; arrow types // add courses to schedule() // get course offerings () Be sure to understand notation…. . multiplicity; aggregation; stereotypes… MUCH MORE ABOUT THESE CLASSES LATER! Unified Software Practices v 5. 0 -D Copyright Ó 1998 Rational Software, all rights reserved 19 8 0. . 1 1 <> Schedule // create with offerings()

UML Diagrams Are Key Artifacts Produced Have seen this slide before too. Use-Case Diagram Class Diagram State Diagram Use-Case 1 Actor A Actor B Use-Case 2 Domain Expert <> Customer name addr receive() withdraw() fetch() send() Use-Case 3 Deployment Diagram Class Repository Document. List File. Manager Package Diagram User Interface Definition Collaboration Diagram Document Graphic. File Component Diagram File. List Forward Engineering(Code Generation) and Reverse Engineering Source Code edit, compile, debug, link Sequence Diagram Executable System Unified Software Practices v 5. 0 -D Copyright Ó 1998 Rational Software, all rights reserved 19 9

What Is a Process? A process defines Who is doing What, When and How to reach a certain goal. In software engineering the goal is to build a software product or to enhance an existing one New or changed requirements Software Engineering Process New or changed system We will use the UP - a generic process that uses UML as a modeling language. The UP can be used for any kind of software system (information system, scientific or engineering-oriented system, etc. ) Unified Software Practices v 5. 0 -D Copyright Ó 1998 Rational Software, all rights reserved 19 10

RUP is Use-Case Driven An actor is someone or This is a Use Case Diagram. Contains UML something outside the symbols for Use Cases and for Actors. Also shows system that interacts with the relationships between an actor and the use cases. Customer the system An actor receives VALUE from the system. A MUST. Example: ATM, transfer funds withdraw money…. Check Balance Withdraw Money Use-Cases for a Cash Machine A collective set of Use Cases is said to constitute The Use Case Model and represent all the possible ways of using the system. (end-user view; functionality!!!) Use Case is thus a model of system’s intended functions. Use Cases can serve as a contract between customer and developer, and are said to capture total functionality. Unified Software Practices v 5. 0 -D Copyright Ó 1998 Rational Software, all rights reserved 19 11 A Use-Case (narrative or Use specification) is a sequence of actions a system performs yielding an observable result of value to a particular actor Models functionality

Use-Case Specifications Include a Flow of Events Example flow of events for the “Withdraw Money” Use-Case. (Example narrative is quite general…. ) 1. The Use-Case begins when the customer inserts a cash card. The system reads and validates information on the card. 2. The system prompts for the PIN. The customer enters the pin. The system validates the PIN. Note the interchange. 3. The system asks which operation the customer wishes This text is to perform. The customer selects “Cash withdrawal. ” typical in a 4. The system requests the amount. The customer Use Case narrative enters the amount. (Interchanges 5. The system requests the account type. The customer may/may not selects checking or savings. be numbered’) 6. The system communicates with the ATM network. . . 19 REMEMBER: 1) The RUP is a use-case driven, Unified Software Practices v 5. 0 -D Copyright Ó 1998 Rational Software, all rights reserved 12

RUP: First: A Use-Case Driven Proces w Use-Cases are concise, simple, and understandable by a wide range of stakeholders § End users, developers and testers, others all understand functional requirements of the system as captured via stories of interactions between actors (external to application) and application. w Use-Cases ‘drive’ numerous activities in the process: § Creation and validation of the design model § Iteration planning (identifies functionality and risk and more…) § Test case development and procedures of the test model § User interface development and validation § Creation of user documentation § System deployment, and MUCH more. 19 Unified Software Practices v 5. 0 -D Copyright Ó 1998 Rational Software, all rights reserved 13

RUP: Second: An Architecture-Centric Process: w Architecture is a primary focus of the early iterations § Building, validating, and base lining the architecture constitute the primary objectives (but not all) of Elaboration Phase (ahead) w An Architectural Prototype model captures the architecture; serves as the baseline and drives development w Prototype may be found in a Software Architecture Document (SAD) § Platforms; distribution; high-level design models (client/server; pipe/filter…) § Identification of potential items of high risk! Unified Software Practices v 5. 0 -D Copyright Ó 1998 Rational Software, all rights reserved 19 14

The 4+1 Architectural View Logical View Functional Reqmts Deals with design, packages, subsystems, and classes, layers, … Implementation View – deals mostly with programming and organization of the software modules & unit test (More detailed Design and Implements the Design) Logical View Implementation View Functional requirements Analysts/ Designers End-user Functionality Structure Process View System Integrators Performance Scalability, Concurrency, Throughput, Parallelism… Use-Case View Programmers Software management Deployment View System Engineering System topology Delivery, installation Communication A View is a complete description (an abstraction) of a system from a particular viewpoint or perspective – covering particular concerns and omitting others not relevant to this perspective. Different ‘views’ from different ‘stakeholders; different concerns. A Model is a complete representation. Models consist of Views. Unified Software Practices v 5. 0 -D Copyright Ó 1998 Rational Software, all rights reserved 19 15

Benefits of an Architecture-Centric Process w Lets you gain and retain intellectual control over a project, § to manage its complexity, and § to maintain system integrity (Principles of design: divide and conquer; coupling; cohesion, reusability, etc. ) w Provides an effective basis for large-scale reuse w Provides a basis for project management – allocation to teams… w Architectural components fulfill a clear function in the context of a well-defined architecture Unified Software Practices v 5. 0 -D Copyright Ó 1998 Rational Software, all rights reserved 19 16

Benefits of an Architecture-Centric Process - more w Architecture is not just the sum of parts w Consists of small, independent tactical decisions that provide a structure on ‘how to grow’ the system without having the complexity to blow your minds. w Architecture gives us structure for this and rules to guide us. w Often accommodated by the most experienced software designer. w Must ensure all parts follow the architecture agreed upon and that all integration fits properly, and much more. Unified Software Practices v 5. 0 -D Copyright Ó 1998 Rational Software, all rights reserved 19 17

RUP: Third: Iterative Development Process. w Third component: The RUP is a § use-case driven, § architecture-centric, § iterative development process! w To set the stage for further discussion of the ‘iteration, ’ we need more on the structure on the RUP. Unified Software Practices v 5. 0 -D Copyright Ó 1998 Rational Software, all rights reserved 19 18