Slide 7E.1 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. An Introduction to Object-Oriented Systems Analysis and Design with UML and the Unified Process McGraw-Hill, 2004 Stephen R. Schach

Slide 7E.2 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. CHAPTER 7 — Unit E THE ANALYSIS WORKFLOW II

Slide 7E.3 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Continued from Unit 7D

Slide 7E.4 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Produce a Report Use Case (contd) l Collaboration diagram for second scenario – This time, investments (not mortgages) are involved

Slide 7E.5 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Produce a Report Use Case (contd) l Sequence diagram for second scenario

Slide 7E.6 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Incrementing the Class Diagram l Combined realization class diagram

Slide 7E.7 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Fourth Iteration of the Class Diagram

Slide 7E.8 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. More on Actors l To find the actors, consider every role in which an individual can interact with the information system – Example: Applicants, Borrowers l Actors are not individuals – They are roles played by those individuals l Find all the different roles played by each user – From the list of roles, extract the actors

Slide 7E.9 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. More on Actors (contd) l In the Unified Process – The term worker is used to denote a role played by an individual – In the Unified Process, Applicants and Borrowers are two different workers l In general use – The word worker usually refers to an employee l In this book, the word role is used in place of worker

Slide 7E.10 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. More on Actors (contd) l Within a business context, finding the roles is easy – They are displayed within the use-case business model l To find the actors – Find the subset of the use-case business model that corresponds to the use-case model of the requirements

Slide 7E.11 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. More on Actors (contd) l To find the actors (in more detail): – Construct the use-case business model – Consider only those parts of the business model that correspond to the target information system – The actors in this subset are the actors of the target information system

Slide 7E.12 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. More on Actors (contd) l Example: The use-case diagram of the MSG business model

Slide 7E.13 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. More on Actors (contd) l There are three actors: – MSG Staff Member – Applicants – Borrowers

Slide 7E.14 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. More on Actors (contd) l Now consider the use-case diagram of the requirements

Slide 7E.15 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. More on Actors (contd) l The use-case diagram of the requirements is a subset of the use-case diagram of the business model – The business model incorporates all the activities of the MSG Foundation – The information system to be developed is just a pilot project

Slide 7E.16 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. More on Actors (contd) l There are only two actors in the use-case diagram of the requirements – MSG Staff Member – Borrowers l These two actors are then the actors of the use-case models of the Unified Process for building the MSG information system

Slide 7E.17 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. More on Use Cases l Within a business context, finding use cases is easy l For each role, there will be one or more use cases – Find the actors (see previous slides) – The use cases then follow

Slide 7E.18 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Risk l Major risk – The delivered information system may not meet the client’s needs l In the traditional paradigm – Construct a rapid prototype »A hurriedly thrown together working program that displays the key functionality of the target information system

Slide 7E.19 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Risk l In the Unified Process – The use cases and their scenarios take the place of the rapid prototype l To appreciate the new way, we now examine rapid prototyping in detail

Slide 7E.20 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Rapid Prototyping l How to ensure that the client’s needs are truly met – Going through the specification document line by line with the client is inadequate l Two fanciful situations – Joe and Jane Johnson have a house built on the basis of a written document – Mark Marberry orders a suit on the basis of a written description of its cut and its cloth

Slide 7E.21 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Rapid Prototyping l These situations typify the problem with documents – “I know that this is the information system I asked for, but it’s not what I wanted” l What has gone wrong?

Slide 7E.22 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Rapid Prototyping (contd) l It is hard to imagine how – A house will look from a written document – A suit will look from a written description of its cut and cloth – An information system will behave from a written document l It is easy to imagine how – A house will look from a model of that house – A suit will look from a photograph of another suit with that cut and a piece of the actual cloth from which the suit will be made – An information system will behave from a rapid prototype

Slide 7E.23 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Rapid Prototyping (contd) l A rapid prototype is a working program that exhibits the key behavior of that information system l Example 1: – The target information system is to handle »Accounts payable »Accounts receivable »Warehousing – The rapid prototype »Performs the screen handling for data capture »Prints the reports »But does no database updating or error handling

Slide 7E.24 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Rapid Prototyping (contd) l Example 2: – An information system for managing an apartment complex – The rapid prototype will »Incorporate an input screen that allows the user to enter details of a new tenant »Print an occupancy report for each month – The rapid prototype will not include »Error-checking capabilities »Routines for updating the database »Complex tax computations

Slide 7E.25 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Rapid Prototyping (contd) l A rapid prototype must reflects the functionality that the client sees, such as – Input screens – Reports l A rapid prototype should omit “hidden” aspects, such as – Database updating

Slide 7E.26 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Rapid Prototyping (contd) l The client and users experiment with the prototype to determine whether it indeed meets their needs l The rapid prototype is changed until the client and users are satisfied that it exhibits the desired functionality

Slide 7E.27 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Rapid Prototyping (contd) l The rapid prototype must be “rapid” – It does not matter if the rapid prototype crashes every few minutes l The sole use of the rapid prototype is to make sure that the delivered information system does precisely what the client needs

Slide 7E.28 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Rapid Prototyping (contd) l After the rapid prototype has been approved by the client, it must be thrown away – Making changes to a rapid prototype is terribly expensive – Also, a rapid prototype is (correctly) thrown together without any sort of specification or design document l The Unified Process offers an alternative mechanism for determining the client’s needs

Slide 7E.29 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Scenarios and the Client’s Needs l When using the Unified Process – The client is shown interaction diagrams reflecting the classes that realize the scenarios of the use cases l The client can understand how the target information system will behave just as well from the interaction diagrams and their written flow of events as from a rapid prototype

Slide 7E.30 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Scenarios and the Client’s Needs (contd) l A scenario is a particular execution sequence of the proposed information system l So is each execution of the rapid prototype – The difference is that the rapid prototype is discarded – The use cases are successively refined, with more information added each time

Slide 7E.31 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Scenarios and the Client’s Needs (contd) l There is one area where a rapid prototype is superior to a scenario – The user interface l There is no way that a scenario can describe a screen as well as a rapid prototype can l There is no need to construct a complete rapid prototype – But specimen screens and reports are essential – Screen generators and report generators can assist with this task