15 JSP/JSD/ & UML - UMass Amherst - JSP/JSD/UML/RUP ©Rick Adrion 2005 (except where noted) 1 UN IV ER STYOOF M ACHU AMHERST• D EPAR TMN OOFCOMPUT ERS CIN •CMPSCI520/620FAL2200055

CMPSCI520/620 - JSP/JSD/UML/RUP

©Rick Adrion 2005 (except where noted) 1

UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005

15 JSP/JSD/ & UML JSP/JSD Readings

http://www.dsisoft.com/jackson_system_development.html http://cisx2.uma.maine.edu/NickTemp/JSP&JSDLec/jsd.html http://www.ferg.org/jsp_and_jsd/

UML Overview OMG Tutorial Series

[cK00] Kobryn Cris, “Lecture 1: Introduction to UML: Structural and Use Case Modeling ObjectModeling with OMG,” UML Tutorial Series

http://www-edlab.cs.umass.edu/cs520/OMG-Tutorials/Tut1IntroToUML.ppt

[OSBB00] Övergaard, Gunnar, Bran Selic, Conrad Bock and Morgan Björkander, “Lecture 2:Behavioral Modeling with UML,” Object Modeling with OMG UML Tutorial Series

http://www-edlab.cs.umass.edu/cs520/OMG-Tutorials/Tut2Behav iorModeling.ppt

[PSWD00] Palmkvist, Karin, Bran Selic, Jos Warmer and Nathan Dykman, “Lecture 3: AdvancedModeling with UML,” Object Modeling with OMG UML Tutorial Series

http://www-edlab.cs.umass.edu/cs520/OMG-Tutorials/Tut3Adv Modeling.ppt

Note: This version of the tutorial series is based on OMG UML Specification v. 1.4, UML RevisionTask Force recommended final draft, OMG doc# ad/01-02-13.

Other [BJR98] The Unified Modeling Language User Guide by Grady Booch, Ivar Jacobson, James

Rumbaugh Addison-Wesley Pub Co; 1st edition (1998) [dB03] Bell, Donald, “UML basics: An introduction to the Unified Modeling Language,” The

Rational Edge, June 2003 http://www-106.ibm.com/dev eloperworks/rational/library /769.html



Announcements




Design MethodsStepwise Refinement

ModularizationInformation hiding

Structured Methods (= Process Methods)

JSP/JSD (= Data Methods)BOOD, Objectory, etc. -> UML/RUP (= O-O Methods)


JSP & JSD

Jackson System DevelopmentEmphasis on high-level conceptual designDevelops collection of coordinated graphicaldepictions of systemStrong hints about how to carry them toimplementation decisionsStrong suggestions about how to go aboutdoing this

Jackson Structured ProgrammingJSD Based on/uses JSP, so let’s look at thatfirst




composite componentssequence -- a sequenceis a composite componentthat has two or more partsoccurring once each, inorder.

selection -- a compositecomponent that consists oftwo or more parts, onlyone of which is selected,once.

iteration a compositecomponent that consists ofone part that repeats zeroor more times


JSP multiplication table example The required output is: 1 2 4 3 6 9 4 8 12 16 ... ... ... ... 10 20 30 40 50 60 70 80 90 1001. Draw system diagram




JSP multiplication table example2. Draw data structures 3. Form program structure

based on the datastructures from theprevious step.


multiplication table example4. List and allocate operations

elementary operations needed toperform the task, and for eachoperation

"How often is it executed?" "In what program component(s)

does it belong?” The operations must be

elementary statements of someprogramming language; e.g.,Pascal.

5. Code program from structurediagram




Difficulties in applying JSP If the file structures do not correspond appropriately it is impossible to

design a correct program structure: this difficulty is called a structure clash interleaving clash

data groups that occur sequentially in one structure correspond functionally togroups that are interleaved in another structure

e.g., the input file of a program may consist of chronologically ordered records ofcalls made at a telephone exchange; the program must produce a printed outputreport of the same calls arranged chronologically within subscriber. The ‘subscribergroups’ that occur successively in the printed report are interleaved in the input file

ordering clash corresponding data item instances are differently ordered in two structures e.g., an input file contains the elements of a matrix in row order, and the required

output file contains the same elements in column order. boundary clash,

two structures have corresponding elements occurring in the same order, but theelements are differently grouped in the two structures; the boundaries of the twogroupings are not synchronized.

If an input file can not be parsed by single look ahead it is impossible towrite all the necessary conditions on the program’s iterations andselections: this is a recognition difficulty


Boundary clashes




Report generation example2. Draw data structures

Structuresdon’t match“boundary”

clash

Part_no Name Number In/Out Time02-131 widget 5 out 0815

07-288 gizmo 5 out 0935 02-131 widget 15 in 1005

….07-288 gizmo 5 out 1055

Part_no 02-131 Name widget

Number In/Out Time5 out 0815

15 in 1005 ….


decomposing the program P into two programs,PA and PB as shown below:

Resolution of the structure clash

Program PA consumes the input file of blocks ofrecords and produces an unblocked file oftransactions. Program PB consumes the groupsof unblocked transaction records and producesthe required report.




Resolution of the structure clashdecomposing the program P into two programs,PA and PB as shown below:

program inversion


Significance of Inversionmany situations appearing in their dynamic, piecemeal

executable form can be recast in their underlying serial form asa simple programany resumable program--one that is alternately activated andsuspended--is an example of inversion

what is the underlying seriality of its input and output?can recast the problem in serial form, and design a simpleprogram using JSPcan optimize the design using inversioninversion preserves program correctness--it is an algorithmictransformation--we can be confident about the design of theinverted (resumable) program

inversion allows us to extend the range of JSP to manysituations that at first glance do not appear to be amenable to it




Uses of program inversionInteractive conversational programs

Interrupt handlerImplementation of pipes & filters and hierarchicalnetworks


Recognition DifficultiesA recognition difficulty is present when an input file cannot be unambiguously parsed by single look-aheadsometimes the difficulty can be overcome by lookingahead two or more recordssometimes a more powerful technique is necessary




Sketch

Group

AGroup BGroup0 0

Group

AGroup BGroup?P

AGroup BGroup0!else Q

?A

0!else Q

Assume (posit) Agroup Admit Bgroup

read AGroup unlessdiscover BGroup record-> Quit (throw exception)

read BGroup unlessdiscover AGroup record-> Quit (throw exception)

The component attempt to readAgroup records positsassume you can read Agroup recordsand admits that you (cannot & should)instead read Bgroup records

The attempt to read Agroup records isa call of the subprogram read Agrouprecords which may cause an implicitquit when, in reading, it is discoveredthe record is a BGroup record an implicit quit is an exception thrown

within a subprogram and not handledand so is propagated from thesubprogram to its calling environment

a posit/ admit design must contain asingle posit and at least one admitconnected at the same level

it can contain any number of, implicitor explicit, quits within the admitcomponent at any level


Jackson System Design - Phasesthe modeling phase

Entity/action stepEntity structure stepModel process step

the network phaseconnect model processes and functions in a singlesystem specification diagram (SSD)

implementation phaseexamine the timing constraints of the systemconsider possible hardware and software forimplementing our systemdesign a system implementation diagram (SID)




Student Loan ExampleFunctional requirements:

before getting a loan, there is an evaluation process after whichagreement is always reached a TE transaction records each step of the evaluation process a TA transaction records the overall loan agreement

a student can take any number of loans, but only one can be activeat any time each loan is initiated by a TI transaction

the student repays the loan with a series of repayment each repayment transaction is recorded by a TR transaction

a loan is terminated by a TT transaction two output functions are desired:

an inquiry function that prints out the loan balance for any student, a repayment acknowledgment sent to each student after payment is

received by the universityNon Functional requirements

to be implemented on a single processor inquiries should be processed as soon as they are receivedrepayment acknowledgments need only be processed at the end ofeach day.

Note: generates a stream of data over a long-period of time


Step 1: Entity/action stepActions have the following characteristics:an action takes place at a point in timean action must take place in the real world outside ofthe system.an action is atomic, cannot be divided into subactions.

Entities have the following characteristics:an entity performs or suffers actions in time.an entity must exist in the real world, and not be aconstruct of a system that models the real worldan entity must be capable of being regarded as anindividual; and, if there are many entities of the sametype, of being uniquely named.




Candidates Entities/Description:

student system university loan student-loan

Actions/Attributes: evaluate - action of university? (university performs the evaluation); action of student? (student

is evaluated) attributes: student-id, loan-no, date of evaluation, remarks

agree - action of university? (university agrees to loan); action of student ? (agrees to loan) attributes: student-id, loan-no, date of agreement, amount of loan, interest rate, repayment period)

make loan - action of university attributes: student-id, loan-no, date of loan, loan amount, interest rate, repayment period

initiate - action of university? (university initiates loan); action of student? (student initiatesloan); action of loan? (is initiated) attributes: student-id, date initiated

repay - action of loan? (loan is repaid); action of student? (student repays the loan); attributes: student-id, date of repayment, amount of repayment

terminate - action of loan (loan is terminated); attributes: student-id, date of termination, remarks

Entities have the following characteristics:an entity performs or suffers actions in time.an entity must exist in the real world,an entity must be capable of being regarded as an individual; and, if there aremany entities of the same type, of being uniquely named.

Actions have the following characteristics:an action takes place at a point in timean action must take place in the real world outside of the system.an action is atomic, cannot be divided into subactions.


Step 2: Entity structure step

(1) evaluation part- zero or more evaluate actions

(2) student agrees to loan(3) loan(s) is (are) made

- zero or more loans.- loan is a sequence of initiateaction, iteration of repay actions, aterminate action




Step 3: Model process step

abstract student entity in the real world

realization in theInformation system

Use JSP to create aprogram for the process

entity structure diagram describes the structure of

the serial data stream

•a TE transaction recordseach step of the evaluationprocess•a TA transaction records theoverall loan agreement•each loan is initiated by a TItransaction•each repayment transactionis recorded by a TRtransaction•a loan is terminated by a TTtransaction


Error handling a real-time system (but slow-running)

system information is collected as it arrives

from the real-world entity model process is synchronized

with the actions of the real world entity the state vector of a model process's

“program” has a “counter” … and if it“points” to repay component of astudent's process, then an 'E'(evaluate), 'A' (agree) or 'I' (initiate)transaction must be recognized as anerror

counter

state vector (SV) connection -- one process can examine the SV of a 2nd process -- the double lines indicate that an inquiry process, over its life, will examine many student processes




Network Phase -- the SSD loan balance inquiry function (LBE) is connected to the Student-1

process by state vector (SV) connectionThe function to produce the student acknowledgments data stream

(ACK) is embedded in the student-1 process in the repays component

DT is an input signal at the end of the day--a daily time marker--thattells the payment acknowledgment lister (PAL) function to begin

The ACK and DT data streams are rough-merged, that is, we don'tknow precisely whether a repayment acknowledgment will appear ontoday's or tomorrow's daily list.


Designing the LBE function w/ JSP




Implementation PhaseUse of inferences encouraged by understandingsgleaned from the network phase

Network Phase suggests ideal traversal paths throughmodel processes and their local datasuggests internal implementation of model processesstudying use of model processes suggests internalstructure of their data

Communication by data streams and state vectorinspection often suggest real implementationsBut often not


The SIDall of the serial data streams are input to the scheduler process

all student processes have an identical structure; only their SV are different--separate the state vectors ofstudent processes from their process text (state vector separation). --set of SV is the data base of our student loan system

student-1 process is invertedwith respect to its data stream, S. and is called by the scheduler to process a transaction, and then suspended

PAL is inverted with respect to both of its inputs, the repayment acknowledgment data stream and the daily marker. PAL is invoked by Student-1 whenever Student-1 processes a repayment transaction. The scheduler invokes PAL directly when it receives a DT and this triggers the daily listing




Design of the scheduler in JSP records from the serial data stream

(loan balance inquiries and studentloan transactions) are read andprocessed in real-time

at the end of the day, a daily timemarker--perhaps a signal to thesystem from the operator--is input

PAL is invoked & processespayment acknowledgments thathave been previously generated inreal-time whenever a studentrepayment is made and stored in abuffer


JSD and JSP In JSD, the principles of JSP are extended into the areas of

systems analysis, specification, design and implementation In JSP, a simple program describes a sequential process that

communicates by means of sequential data streams; its structure isdetermined by the structure of its input and output data stream

In JSD, the real world is modeled as a set of sequential modelprocesses that communicate with the real world and with eachother by sequential data streams (as well as by a second read-onlycommunication called state vector connection). The structure of amodel process is determined by the structure of its inputs andoutputs.

The JSD implementation step embodies the JSP implementationtechnique, program inversion, in which a program is transformedinto a procedure

Other JSP techniques, such as the single read-ahead rule andbacktracking, and principles, such as implementation throughtransformation, are used in JSD




Comments/EvaluationFocus on conceptual design

But difficult to build a system this wayBased upon model of real worldCareful (and experienced) analysis of the modelgenerally points suggested implementation tactics,thoughParnas notions of module not perceptible hereNot an iterative refinement approach either

Treatment of data is very much subordinated/secondaryDoes a good job of suggesting possible parallelismContrasts strongly with Objected Oriented notions (eg.Booch, UML)


O-O System Developmentproblem

statement

Requirementselicitation

Requirementsanalysis

System design

system designobject modeldesign goals subsystem

decomposition

functionalmodel

nonfunctionalrequirements

use casediagram

analysisobject model

classdiagram

dynamicmodel

statechartdiagram

sequencediagram

adapted from Bruegge/Dutoit O-O SW Engr




Use Case Diagram

buy tickets

survey sales

make charges

buysubscription

Box Office

Clerk

Kiosk Credit card service

Supervisor

<<include>><<include>>

structural use case use case

©The Unified Modeling Language User Guide by Grady Booch, Ivar Jacobson, James Rumbaugh Addison-Wesley Pub Co; 1st edition(1998)



statement



System design


decomposition

functionalmodel


use casediagram


classdiagram

dynamicmodel

statechartdiagram

sequencediagram





Copyright © 1997 by Rational Software Corporation

ClassesA class is a collection of objects with common structure,

common behavior, common relationships and commonsemantics

Classes may be found by examining:written requirementsobjects in sequence and collaboration diagrams

A class is drawn as a rectangle with three compartmentsnameattributesoperations

Classes should be named using the vocabulary of the domainNaming standards should be createde.g., all classes are singular nouns starting with a capital letter


Class Modeling Captures system state – the function of the system's

information content at a point in time Class modeling and use case modeling are typically

conducted in parallel A class diagram shows the existence of classes and

their relationships in the logical view of a system; inUML class diagrams elements include Classes and their structure and behavior Association, aggregation, generalization,

dependency, and inheritance relationships Multiplicity and navigation indicators Role names




Design a program for a booking office of an arts center.There are several theatres, people may reserve seatsat any theatre for any future event, and people maysubscribe to a series of events. People need to be ableto discuss seat availability, where seats are located,and how much they cost. When people make a choice,the program should print the price, record the selection,and print out a ticket

Find Classes from requirements

Fuzzy

Customer

Reservation

SubscriptionSeries

Ticket


AttributesThe structure of a class is represented by its attributesAttributes may be found by examining class definitions,the problem requirements, and by applying domainknowledge

More requirementsEach customer offering has a name and phone numberEach show has a nameEach performance has a date and timeTicket has availability

Customer name: Stringphone: String

Show

name: String

Performance date: Datetime: TimeOfDay

Ticket available: Boolean




OperationsThe behavior of a class is represented by its operationsOperations may be found by examining interactiondiagrams



RelationshipsRelationships provide a pathway for communicationbetween objects

Sequence and/or collaboration diagrams are examinedto determine what links between objects need to existto accomplish the behavior -- if two objects need to“talk” there must be a link between them

Three types of relationships are:AssociationAggregationDependency




Relationships

An association is a bi-directional connection betweenclassesAn association is shown as a line connecting the relatedclasses

An aggregation is a stronger form of relationship wherethe relationship is between a whole and its parts

An aggregation is shown as a line connecting the relatedclasses with a diamond next to the class representing thewhole

Customer name: Stringphone: Stringadd (name, phone)

Reservation date: Date

1 *

CourseOfferinglocationopen()addStudent(StudentInfo

CoursenamenumberCreditsopen()addStudent(StudentInfo


Finding RelationshipsRelationships are discovered by examining interactiondiagramsIf two objects must “talk” there must be a pathway forcommunication

Customer

Reservation

Performance





Multiplicity and NavigationMultiplicity defines how many objects participate in arelationshipsMultiplicity is the number of instances of one classrelated to ONE instance of the other classFor each association and aggregation, there are twomultiplicity decisions to make: one for each end of therelationship

Although associations and aggregations are bi-directional by default, it is often desirable to restrictnavigation to one direction

If navigation is restricted, an arrowhead is added toindicate the direction of the navigation



InheritanceInheritance is a relationships between a superclass andits subclasses

There are two ways to find inheritance:GeneralizationSpecialization

Common attributes, operations, and/or relationshipsare shown at the highest applicable level in thehierarchy




Class Diagram

Ticket

sell (c: Customer)exchange ( )

available: Boolean

Customer name: Stringphone: Stringadd (name, phone)

Show Reservation

date: Date

SubscriptionSeries series: Integer

IndividualReservation

name: String

Performance date: Datetime: TimeOfDay

seat: String

1

*

0..10..1

3..6 1

0..1 1

1

1..*

ownerpurchased

show

performancesXor

attributes

static operations

rolenames

generalization

multiplicities

constraint

qualifiers

associationsclassdependencygeneralizationinterfacerealization

structural static class



Class & associations -- notation






statement



System design


decomposition

functionalmodel


use casediagram


classdiagram

dynamicmodel

statechartdiagram

sequencediagram



State Machine View




State Machine Notation


Scott W. Ambler , Copyright 2003 www.agilemodeling.com/

UML 2 Activity Diagramsobject-oriented equivalent of flow charts and data flowdiagrams (DFDs) from structured development

typically used forbusiness process modelingmodeling the logic captured by a single use case orusage scenariomodeling the detailed logic of a business rule

could potentially modelthe internal logic of a complex operationfar better to simply rewrite the operation so that it issimple enough that you don’t require an activity diagram




Activity Diagram

©The Unified Modeling Language User Guide by Grady Booch, Ivar Jacobson,James Rumbaugh Addison-Wesley Pub Co; 1st edition (1998)

dynamic

state machine

activity

interaction

state machine

activity

sequence

collaboration


O-O System DevelopmentRequirements

analysis

System design


decomposition


classdiagram

dynamicmodel

statechartdiagram

sequencediagram


Implementation

Object design

object designmodel

classdiagram

Design Views




Internal Structure Diagram

Interface = port

BoxOffice

sellTicketsseller: TicketSeller

guide:PerformanceGuide

Db:PerformanceDB[*]

1

*

structural design internal structure



Collaboration Diagram

kiosk: Kiosk[*] 1* : BoxOffice terminal: SalesTerminal[*]1 *

TheatreSales

dynamic interaction collaboration ©The Unified Modeling Language User Guide by Grady Booch, Ivar Jacobson, James Rumbaugh Addison-Wesley Pub Co; 1st edition(1998)




Component Definition & Diagram



Deployment views

descriptor instance




The RUP presentation is adapted from OOAD Using the UMLCopyright 1994-1998 Rational Software, all rights reserved

Rational Unified ProcessThe Unified Modeling Language (UML) is a languagefor specifying, visualizing, constructing, anddocumenting the artifacts of a software-intensive system

A software development process defines Who is doingWhat, When and How in building a software product

The Rational Unified Process has four phases:Inception, Elaboration, Construction and Transition

Each phase ends at a major milestone and containsone or more iterations

An iteration is a distinct sequence of activities with anestablished plan and evaluation criteria, resulting in anexecutable release


In RUP: Major Workflows Produce Models

verified by

TestModel

Test

ImplementationModel

Implementation

implemented by

realized by

Analysis &Design

DesignModel

BusinessModeling

Business Model

Requirements

Use-CaseModel

supported by




The RUP Iterative Model

ManagementEnvironment

Business Modeling

ImplementationTest

Analysis & Design

Preliminary Iteration(s)

Iter.#1

PhasesProcess Workflows

Iterations

Supporting Workflows

Iter.#2

Iter.#n

Iter.#n+1

Iter.#n+2

Iter.#m

Iter.#m+1

Deployment

Configuration Mgmt

Requirements

Elaboration TransitionInception Construction

Workflowsgroupactivitieslogically

In aniteration, youwalk throughall workflows


Requirements Workflow

Use-Case Specifier

RequirementsReviewer

User-InterfaceDesigner

Capture a Common

Vocabulary

Find Actors and Use Cases

ReviewRequirements

Structure the Use-Case Model

User-InterfacePrototyping

Detail a Use Case

Elicit Stakeholder Needs

Manage Dependencies

Architect

Prioritize Use Cases

DevelopVision

User-InterfaceModeling




Analysis & Design Workflow

Architect

Designer

ArchitecturalAnalysis

ArchitectureReviewer

Review theDesign

Review theArchitecture

Use-CaseAnalysis

ArchitecturalDesign

DescribeConcurrency

DescribeDistribution

DatabaseDesigner

ClassDesign

SubsystemDesign

Use-Case Design

DatabaseDesign

DesignReviewer


Implementation Workflow

IntegrateSystem

Architect

System Integrator

Implementer

Code Reviewer

Implement Classes

Perform Unit Test

Structure theImplementation Model

IntegrateSubsystem

Review Code

Fix a Defect

Plan System Integration

Plan Subsystem Integration




Test Workflow

Design Test

ImplementTest

Test Designer

Integration Tester

System Tester

Evaluate Test

Execute IntegrationTest

Execute System Test

Designer

Design Test Classes and Packages

Implementer

Implement Test Components and Subsystems

PlanTest

PerformanceTester

Execute Performance Test


Project2

O-O System Development


problemstatement


Requirementsanaly sis

Sy stem design

sy stem designobject modeldesign goals subsy stem

decomposition

f unctionalmodel

nonf unctionalrequirements

use casediagram

analy sisobject model

classdiagram

dy namicmodel

statechartdiagram

sequencediagram

Implementation

sourcecode Test

deliv erablesy stem

Object design

object designmodel

classdiagram

Project0

interviews Project1

Project3



UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005Copyright 2002. Gary K. Evans. All Rights Reserved. www.evanetics.com

A Minimal Iterative ProcessGetting Started: (do this once)1. Capture the major functional and non-functional requirements for

the system. Express the functional requirements as use cases, scenarios, or

stories. Capture non-functional requirements in a standard paragraph-

style document.2. Identify the classes which are part of the domain being modeled.3. Define the responsibilities and relationships for each class in the

domain.4. Construct the domain class diagram.

This diagram and the responsibility definitions lay a foundation fora common vocabulary in the project.

5. Capture use case and class definitions in an OO CASE tool (e.g.,Rose) only when they have stablilized.


Copyright 2002. Gary K. Evans. All Rights Reserved. www.evanetics.com

A Minimal Iterative ProcessGetting Started: (do this once)6. Identify the major risk factors and prioritize the most

architecturally significant use cases and scenarios. It is absolutely imperative that the highest risk items and the most

architecturally significant functionality be addressed in the earlyiterations. You must not pick the “low hanging fruit” and leave therisks for later.

7. Partition the use cases/scenarios across the planned iterations.8. Develop an Iteration plan describing each “mini-project” to be

completed in each iteration. Describe the goals of each iteration, plus the staffing, the

schedule, the risks, inputs and deliverables. Keep the iterations focused and limited (2-3 weeks per iteration).

In each iteration, conduct all of the software activities in theprocess: requirements, analysis, design, implementation and test.




A Minimal Iterative ProcessFor each iteration: (repeat until done)1. Merge the functional flow in the use cases/scenarios with the

classes in the domain class diagram Produce sequence (and collaboration) diagrams at the analysis level.

2. Test and challenge the sequence diagrams on paper, or whiteboard Discover additional operations and data to be assigned to classes Validate the business process captured in the flow of the sequence

diagram3. Develop statechart diagrams for classes with “significant” state

Statechart events, actions, and most activities will become operationson the corresponding class

4. Enhance sequence diagrams and statechart diagrams with designlevel content

Identify and add to the class diagram and sequence diagrams anyrequired support or design classes (e.g. collection classes, GUI andother technology classes, etc.)

5. Challenge the sequence diagrams on paper/whiteboard, discoveringadditional operations and data assigned to classes.

Copyright 2002. Gary K. Evans. All Rights Reserved. www.evanetics.com

Documents

15 JSP/JSD/ & UML - UMass Amherst - JSP/JSD/UML/RUP ©Rick Adrion 2005 (except where noted) 1 UN IV ER STYOOF M ACHU AMHERST• D EPAR TMN OOFCOMPUT ERS CIN •CMPSCI520/620FAL2200055