slide 7e.1 copyright © 2004 by the mcgraw-hill companies, inc. all rights reserved. an introduction...

31
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 [email protected]

Post on 22-Dec-2015

212 views

Category:

Documents


0 download

TRANSCRIPT

Slide 7E.1

Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.

An Introduction toObject-Oriented

Systems Analysis and Design with UML and

the Unified Process

McGraw-Hill, 2004

Stephen R. Schach

[email protected]

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)

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)

Sequence diagram for second scenario

Slide 7E.6

Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.

Incrementing the Class Diagram

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

To find the actors, consider every role in which an individual can interact with the information system– Example: Applicants, Borrowers

Actors are not individuals – They are roles played by those individuals

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)

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

In general use– The word worker usually refers to an employee

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)

Within a business context, finding the roles is easy– They are displayed within the use-case business model

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)

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)

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)

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)

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)

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)

There are only two actors in the use-case diagram of the requirements– MSG Staff Member– Borrowers

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

Within a business context, finding use cases is easy

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

Major risk– The delivered information system may not meet the

client’s needs

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

In the Unified Process– The use cases and their scenarios take the place of the

rapid prototype

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

How to ensure that the client’s needs are truly met– Going through the specification document line by line with

the client is inadequate

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

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”

What has gone wrong?

Slide 7E.22

Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.

Rapid Prototyping (contd)

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

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)

A rapid prototype is a working program that exhibits the key behavior of that information system

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)

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)

A rapid prototype must reflects the functionality that the client sees, such as – Input screens– Reports

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)

The client and users experiment with the prototype to determine whether it indeed meets their needs

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)

The rapid prototype must be “rapid” – It does not matter if the rapid prototype crashes every few

minutes

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)

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

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

When using the Unified Process– The client is shown interaction diagrams reflecting the

classes that realize the scenarios of the use cases

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)

A scenario is a particular execution sequence of the proposed information system

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)

There is one area where a rapid prototype is superior to a scenario– The user interface

There is no way that a scenario can describe a screen as well as a rapid prototype can

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