17-Design Jackson System Development (JSD)

CMPSCI520/620 Design ***DRAFT*** 11/4/04
17-Design Jackson System Development (JSD)

• Readings • Phases
• OOAD Using the UML
• the modeling phase
Copyright  1994-1998 Rational Software, all rights reserved
• Entity/action step
• will post …
• Entity structure step
• Model process step
• the network phase
• connect model processes and functions in a single system
specification diagram (SSD)
• implementation phase
• examine the timing constraints of the system
• consider possible hardware and software for implementing
our system
• design a system implementation diagram (SID)
UNIVERSITY OF MASSACHUSETTS AMHERST • DEPARTMENT OF COMPUTER SCIENCE • CMPSCI 520/620 F ALL 2003 UNIVERSITY OF MASSACHUSETTS AMHERST • DEPARTMENT OF COMPUTER SCIENCE • CMPSCI 520/620 F ALL 2003
Student Loan Example Step 1: Entity/action step

• Functional requirements: • Actions have the following characteristics:
• before getting a loan, there is an evaluation process after which
agreement is always reached • an action takes place at a point in time
• a TE transaction records each step of the evaluation process
• a TA transaction records the overall loan agreement • an action must take place in the real world outside of the
• a student can take any number of loans, but only one can be active
at any time system.
• each loan is initiated by a TI transaction
• the student repays the loan with a series of repayment
• an action is atomic, cannot be divided into subactions.
• each repayment transaction is recorded by a TR transaction • Entities have the following characteristics:
• a loan is terminated by a TT transaction
• two output functions are desired: • an entity performs or suffers actions in time.
• an inquiry function that prints out the loan balance for any student,
• a repayment acknowledgment sent to each student after payment is • an entity must exist in the real world, and not be a
received by the university construct of a system that models the real world
• Non Functional requirements
• to be implemented on a single processor • an entity must be capable of being regarded as an
• inquiries should be processed as soon as they are received individual; and, if there are many entities of the same
• repayment acknowledgments need only be processed at the end of
each day. type, of being uniquely named.
• Note: generates a stream of data over a long-period of time
Rick Adrion 2004 (except where noted) 1

Candidates Actions/Attributes:
• Entities/Description: • evaluate -action of university? (university performs the evaluation); action of
student? (student is evaluated)
• student • attributes: student-id, loan-no, date of evaluation, remarks
• agree - action of university? (university agrees to loan); action of student ?
• system (agrees to loan)
• university • attributes: student-id, loan-no, date of agreement, amount of loan, interest
rate, repayment period)
• loan • make loan - action of university
• student-loan • 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 initiates loan); 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
Focus on: Step 2: Entity structure step

• Entities/Description:
• student
• Actions/Attributes:
• evaluate -action of student; student? (student suffers the
action, is evaluated);
• attributes: student-id, loan-no, date of evaluation, remarks
• agree - action of student
• attributes: student-id, loan-no, date of agreement, amount of loan,
interest rate, repayment period)
• initiate - action of student
• attributes: student-id, date initiated (1) evaluation part
• repay - action of student - zero or more evaluate actions
(2) student agrees to loan
• attributes: student-id, date of repayment, amount of repayment
(3) loan(s) is (are) made
• terminate - action of student - zero or more loans.
• attributes: student-id, date of termination, remarks - loan is a sequence of initiate
action, iteration of repay actions, a
terminate action

Model Process Model Processes

• Primary building block of a JSD design • A model process is a particular view of the system
• contains all actions characterizing a key real-world • various model processes provide different views
process • model process is multiply instantiated for different instances
• Actions are structured into a tree • model processes are often annotated with informal
specifications and notations
• only the leaf nodes of the tree are real-world actions
• same action may appear as part of more than one process
• interior nodes are conceptual
• Model Processes and Data
• interior nodes can be annotated to show choice or • actions on data hang off of model process leaf nodes
iteration
• global data is necessary too
• traversals of this tree constitute the only "legal" • for functions that must combine data from >1 model process
sequences of actions for this process • to assure consistency between model processes
• Model process tree defines a regular expression • to coordinate between different instances of the same model
process
• set of traversals is a regular set
• to coordinate between different models of the same entity
Step 3: Model process step Error handling

• a real-time system (but slow-running)
system
• information is collected as it arrives
entity structure diagram from the real-world
abstract student entity describes the structure of realization in the • entity model process is synchronized
in the real world the serial data stream Information system
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 a counter
Use JSP to create a student's process, then an 'E' (evaluate),
program for the process
'A' (agree) or 'I' (initiate) transaction
must be recognized as an error
•a TE transaction records
each step of the evaluation state vector (SV) connection
process
•a TA transaction records the -- one process can examine
overall loan agreement the SV of a 2nd process
•each loan is initiated by a TI
transaction -- the double lines indicate
•each repayment transaction is that an inquiry process,
recorded by a TR transaction
•a loan is terminated by a TT over its life, will examine
transaction
many student processes

Total System Model Model Process Communication

• At the Network Phase, weave Model Processes • Fundamental notion is Data Streams
together incrementally to form the total system • can have multiple data streams arriving at an action in a
specification process
• also add new processes during this phase: e.g., input,
output, user interface, data collection • can model multiple instances entering a data stream or
departing from one
• Goal is to indicate how model processes communicate
with each other, use each other, are connected to user • Two types of data stream communication:
and outside world • asynchronous message passing
• Linkage through two types of communication: • State vector inspection
• Message passing • These communication mechanisms used to model how
• State vector inspection data is passed between processes
• Indicates which data moves between which processes
• and more about synchronization
Message Passing State Vector Inspection

• Data stream carries a message from one process • Modeling mechanism used when one process needs
activity to an activity in another process considerable information about another
• must correlate with output leaf of sending model process • State vector includes
• must correlate with input leaf of receiving model process • values of all internal variables
• Data transfer assumed to be asynchronous • execution text pointer
• less restrictive assumption • Process often needs to control when its state vector can
• no timing constraints are assumed be viewed
• messages are queued in infinitely long queues • process may need exclusive access to its vector
• messages interleaved non-deterministically when • Could be modeled as message passing, but important
multiple streams arrive at same activity to underscore characteristic differences

Network Phase -- the SSD Designing the LBE function w/ JSP

• loan balance inquiry function (LBE) is connected to the Student-1
process by state vector (SV) connection
• The 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--that

tells the payment acknowledgment lister (PAL) function to begin
• The ACK and DT data streams are rough-merged, that is, we don't
know precisely whether a repayment acknowledgment will appear on
today's or tomorrow's daily list.
Implementation Phase The SID

all of the serial data all student processes have an
• Use of inferences encouraged by understandings streams are input to
identical structure; only their
SV are different
gleaned from the network phase the scheduler process --separate the state vectors of
student processes from their
process text (state vector
• Network Phase suggests ideal traversal paths through separation).
--set of SV is the data base of
model processes and their local data our student loan system
• suggests internal implementation of model processes
• studying use of model processes suggests internal
structure of their data
• Communication by data streams and state vector
inspection often suggest real implementations
PAL is inverted with respect to
• But often not both of its inputs, the repayment
acknowledgment data stream
student-1 process is inverted and the daily marker. PAL is
with respect to its data stream, invoked by Student-1 whenever
S. and is called by the Student-1 processes a repayment
scheduler to process a transaction. The scheduler invokes
transaction, and then PAL directly when it receives a DT
suspended and this triggers the daily listing

Design of the scheduler in JSP JSD and JSP

• records from the serial data stream • In JSD, the principles of JSP are extended into the areas of systems
(loan balance inquiries and student analysis, specification, design and implementation
loan transactions) are read and
processed in real-time • In JSP, a simple program describes a sequential process that
• at the end of the day, a daily time communicates by means of sequential data streams; its structure is
marker--perhaps a signal to the determined by the structure of its input and output data stream
system from the operator--is input • In JSD, the real world is modeled as a set of sequential model
processes that communicate with the real world and with each other
by sequential data streams (as well as by a second read-only
communication called state vector connection). The structure of a
model process is determined by the structure of its inputs and
outputs.
• The JSD implementation step embodies the JSP implementation
technique, program inversion, in which a program is transformed
into a procedure
• Other JSP techniques, such as the single read-ahead rule and
• PAL is invoked & processes
payment acknowledgments that backtracking, and principles, such as implementation through
have been previously generated in transformation, are used in JSD
real-time whenever a student
repayment is made and stored in a
buffer
Comments/Evaluation Rational Unified Process

• Focus on conceptual design • The Unified Modeling Language (UML) is a language for
• But difficult to build a system this way specifying, visualizing, constructing, and documenting
• Based upon model of real world the artifacts of a software-intensive system
• Careful (and experienced) analysis of the model • A software development process defines Who is doing
generally points suggested implementation tactics, What, When and How in building a software product
though • The Rational Unified Process has four phases:
• Parnas notions of module not perceptible here Inception, Elaboration, Construction and Transition
• Not an iterative refinement approach either • Each phase ends at a major milestone and contains one
or more iterations
• Treatment of data is very much subordinated/secondary
• An iteration is a distinct sequence of activities with an
• Does a good job of suggesting possible parallelism
established plan and evaluation criteria, resulting in an
• Contrasts strongly with Objected Oriented notions (eg. executable release
Booch, UML)
The RUP presentation is adapted from OOAD Using the UML
Copyright 1994-1998 Rational Software, all rights reserved

In RUP: Major Workflows Produce Models The RUP Iterative Model

Phases
Business
supported by Process Workflows Inception Elaboration Construction InTransition
an iteration,
Modeling you walk
Business Model Business Modeling through all
workflows
Requirements
Requirements realized by Analysis & Design
Use-Case
Model Implementation
Analysis & Test
implemented by
Design
Design Deployment
Model
Supporting Workflows
Implementation verified by
Configuration Mgmt
Implementation Management
Model Workflows
group Environment
Preliminary Iter. Iter. Iter. Iter. Iter. Iter. Iter.
Test activities Iteration(s) #1 #2 #n #n+1 #n+2 #m #m+1
logically
Test Iterations
Model
Requirements Workflow Analysis & Design Workflow

Develop Elicit Stakeholder
Vision Architectural
Needs Analysis
Find Actors
and Use Cases
Architectural Describe Describe Review the Architecture
Capture a Structure the Architect Design Concurrency Distribution Architecture Reviewer
Manage Use-Case Model
Dependencies Common Requirements
Vocabulary Reviewer
Detail a Review
Use-Case SubsystemDesign
Specifier Use Case Requirements Use-Case
Analysis
Use-Case Review the
Design Design Design
Designer Reviewer
User-Interface User-Interface Class

User-Interface Modeling Prototyping Design
Designer
Prioritize Database
Architect Use Cases Database Design
Designer

Implementation Workflow Test Workflow
Structure the PlanTest ImplementTest

Evaluate
Architect Implementation Model Test Designer Design Test Test
Execute Integration
Plan System Integrate Integration Test
System Integrator Integration System Tester
Execute System
Plan Subsystem Integrate System Tester Test
Integration Implement Subsystem
Classes
Implementer
Perform
Unit Test Performance
Execute Performance
Test
Tester
Fix a Defect
Design Test Classes

Designer and Packages
Code Reviewer Review Code
Implement Test Components

Implementer and Subsystems
O-O System Development A Minimal Iterative Process

problem
Project0
statement
Getting Started: (do this once)
Requirements
elicitation 1. Capture the major functional and non-functional requirements for
nonfunctional functional use case the system.
interviews requirements model diagram Project1
• Express the functional requirements as use cases, scenarios, or
Requirements
analysis
stories.
class analysis dynamic
statechart
diagram • Capture non-functional requirements in a standard paragraph-style
diagram object model model
sequence
document.
diagram
2. Identify the classes which are part of the domain being modeled.
System design
3. Define the responsibilities and relationships for each class in the
design goals
system design
object model
subsystem
decomposition
domain.
Object design
4. Construct the domain class diagram.
• This diagram and the responsibility definitions lay a foundation for
Project2
class
diagram
object design
model a common vocabulary in the project.
Implementation
5. Capture use case and class definitions in an OO CASE tool (e.g.,
Project3
Rose) only when they have stablilized.
source
Test
code
deliverable
system
adapted from Bruegge/Dutoit O-O SW Engr Copyright 2002. Gary K. Evans. All Rights Reserved. www.evanetics.com

A Minimal Iterative Process A Minimal Iterative Process

Getting Started: (do this once)
For each iteration: (repeat until done)
6. Identify the major risk factors and prioritize the most 1. Merge the functional flow in the use cases/scenarios with the classes
architecturally significant use cases and scenarios. in the domain class diagram
• It is absolutely imperative that the highest risk items and the most • Produce sequence (and collaboration) diagrams at the analysis level.
architecturally significant functionality be addressed in the early 2. Test and challenge the sequence diagrams on paper, or whiteboard
iterations. You must not pick the “low hanging fruit” and leave the
• Discover additional operations and data to be assigned to classes
risks for later.
• Validate the business process captured in the flow of the sequence
7. Partition the use cases/scenarios across the planned iterations. diagram
8. Develop an Iteration plan describing each “mini-project” to be 3. Develop statechart diagrams for classes with “significant” state
completed in each iteration. • Statechart events, actions, and most activities will become operations
• Describe the goals of each iteration, plus the staffing, the schedule, on the corresponding class
the risks, inputs and deliverables. 4. Enhance sequence diagrams and statechart diagrams with design
• Keep the iterations focused and limited (2-3 weeks per iteration). level content
In each iteration, conduct all of the software activities in the • Identify and add to the class diagram and sequence diagrams any
process: requirements, analysis, design, implementation and test. required support or design classes (e.g. collection classes, GUI and
other technology classes, etc.)
5. Challenge the sequence diagrams on paper/whiteboard, discovering
additional operations and data assigned to classes.
Copyright 2002. Gary K. Evans. All Rights Reserved. www.evanetics.com Copyright 2002. Gary K. Evans. All Rights Reserved. www.evanetics.com
RUP Design - Where to Begin? Architectural Analysis Topics

• Key Architectural Analysis Concepts
Architectural Architectural Describe Describe Review the Architecture • Modeling Conventions
Analysis Design Concurrency Distribution Architecture Reviewer
Architect
• Analysis Mechanisms
• Key System Concepts
• Initial Architectural Layers
Use-Case Subsystem
• Architectural Analysis Checkpoints
Review the
Analysis Design
Use-Case Design Design
Designer Design Reviewer
Class
Design
Database
Design
Database
Designer

“4+1 View” Model Packages

• a general purpose mechanism for organizing elements into groups
• a model element which can contain other model elements
Logical View Implementation View • uses
• organize the model under development
• configuration management
End-user
Analysts/Designers Programmers • can related to one another using a dependency relationship
Functionality
Structure Software management
Use-Case View Dependency relationship
Process View Deployment View ClientPackage SupplierPackage

System integrators System engineering
Performance System topology
Scalability Delivery, installation
Throughput communication • implications
• changes to the Supplier package may affect the Client package
• Client package cannot be reused independently because it depends
on the Supplier package
Example: Modeling Conventions Architectural Mechanisms

• Use Case View • Analysis Mechanisms (conceptual)
• Use Cases will be named with short active phrases such • Design Mechanisms (concrete)
as “Submit Grades” • Implementation Mechanisms (actual)
• Logical View
• A Use Case Realization package will be created that
includes:
• At least one realization per use case traced to the use case
• A “View Of Participating Classes” diagram that shows the
participants in the realization and their relevant relationships
• Classes will be named with noun names matching the
problem domain as much as possible.

Sample Analysis Mechanisms Identify Key Concepts

• Persistency • Define preliminary entity analysis classes
• Communication (IPC and RPC)
• Message routing
• Domain knowledge
• Distribution • Requirements
• Transaction management • Glossary
• Process control and synchronization (resource contention)
• Domain Model, or the Business Model (if exists)
• Information exchange, format conversion
• Security • Define analysis class relationships
• Error detection / handling / reporting • Model analysis classes and relationships on Class
• Redundancy Diagrams
• Legacy Interface
• Include brief description of analysis class
• Map analysis classes to necessary analysis
mechanisms
Analysis classes will evolve
Typical Layering Approach High-Level Organization of the Model

User Interface Layer
Specific
functionality RegistrarInterface StudentInterface ProfessorInterface
(from User Interface) (from User Interface) (from User Interface)
Registration Student Evaluation

(from Business Services) (from Business Services)
Finance System
(from Business Services)
Business Services Layer
Course Catalog
(from Business Objects)
General
functionality
University Artifacts Business Objects Layer
(from Business Objects)

Architectural Analysis So whqat do we do next?

• General
• Is the package partitioning and layering done in a logically
consistent way? Architectural Architectural Describe Describe Review the Architecture
Analysis Design Concurrency Distribution Architecture Reviewer
Architect
• Have the necessary analysis mechanisms been identified?
• Packages
• Have we provided a comprehensive picture of the services of
the packages in upper-level layers?
• Classes Use-Case
Analysis
Subsystem
Design
Review the
Design Design
Use-Case
• Have the key entity classes and their relationships been Designer Design Reviewer
identified and accurately modeled? Class

• Does the name of each class clearly reflect the role it plays? Design
• Have the entity classes been mapped to the necessary

analysis mechanisms? Database
Design
Database
Designer
Use Case Analysis Overview What is a Use-Case Realization?

Use Case Model Design Model
<<realizes>>
Use Case Use Case Realization

Use-Case Model
Analysis Classes
Supporting Documents
Architecture Document
Glossary
Supplemental Specs
OR Sequence Diagrams Collaboration

Diagrams
Use-Case Realization
Analysis Model Design Model Use Case Realization
Documentation
Class Diagrams

Use Case Analysis Steps University Course Registration System
• Supplement the Descriptions of the Use Case

• For each use case realization
Login
• Find Classes from Use-Case Behavior
Maintain Professor Information
• Distribute Use-Case Behavior to Classes Registrar
View Report Card
• For each resulting analysis class
• Describe Responsibilities Student Maintain Student Information
• Describe Attributes and Associations Register for Courses
• Qualify Analysis Mechanisms

Course Catalog
• Unify Analysis Classes Close Registration Billing System
Select Courses to Teach
Professor
Submit Grades
What is an Analysis Class? The Roles

Collaboration Diagram Boundary Class -- Model
• Early conceptual model interaction between the
• Functional requirements system and its environment Control Class -- Coordinate
• Model problem domain the use case behavior
<<boundary>>
• Likely to change
• Boundary
<<boundary>> • Information used
• Control logic
Customer
<<control>>
Use-case
behavior <<control>>
coordination
System
boundary
System
information <<entity>> Entity Class -- Store and
manage information in the
system
<<entity>>

Example: Entity & Control Classes Describe Responsibilities

•First cut at class operations
• What are responsibilities? •Actions that object can perform
•Knowledge object maintains
Course
(from University Artifacts)
CourseOffering Grade
(from University Artifacts) (from University Artifacts)
• How do we find them? •Non-functional requirements
•Class should have multiple responsibilities
Student Professor Schedule

(from University Artifacts) (from University Artifacts) (from University Artifacts) Responsibility 1
Class Name
RegistrationController CloseRegistrationController MaintainStudentController

(from Registration) (from Registration) (from Registration) Responsibility 2
MaintainProfessorController SelectCoursesToTeachController ReportCardController

(from Registration) (from Registration) (from Student Evaluation)
Responsibility N
SubmitGradesController
(from Student Evaluation)
Class Responsibilities from a Class Responsibilities from a

Collaboration Diagram Sequence Diagram
: Main
Form
: MainForm : Maintain : Registration : CourseCatalog : Schedule
: Student
2: // open schedule form( ) ScheduleForm Controller System
Register for Courses use case
1: // select maintain schedule( ) Register for Courses use case
5: // select 4 primary and 2 alternate offerings( )
: Maintain 1: // select maintain schedule( )
ScheduleForm 2: // open schedule form( )
3: // get course offerings( )

: Student
3: // get course offerings( ) <<boundary>> 4: // get course offerings( ) <<boundary>>
6: // add courses to schedule( ) MaintainScheduleForm 5: // select 4 primary and 2 alternate offerings( ) MaintainScheduleForm
: Registration
: CourseCatalog4: // get course offerings( ) Controller 6: // add courses to schedule( )
// select 4 primary and 2 alternate offerings() // select 4 primary and 2 alternate offerings()
System
// open () 7: // create with offerings( ) // open ()
7: // create with offerings( )
<<boundary>> <<entity>> <<boundary>> <<entity>>

MainForm Schedule MainForm Schedule
:Schedule
// select maintain schedule() // create with offerings() // select maintain schedule() // create with offerings()
<<control>> <<boundary>> <<control>> <<boundary>>

RegistrationController CourseCatalogSystem RegistrationController CourseCatalogSystem
// add courses to schedule() // get course offerings() // add courses to schedule() // get course offerings()

What are Roles? Example: Finding Relationships

• MaintainScheduleForm does not
• The “face” that a class plays in the association make any sense outside of the
context of a particular use <<boundary>>
<<boundary>>
MaintainScheduleForm
session. MainForm
• Only one
MaintainScheduleForm can be 1 0..1
// select maintain schedule() + // open()
active at any one time, or none
may be active + // select 4 primary and 2 alternate offerings()
1
Instructor Department head : Main
legacy system.
Form 1
CourseOffering Professor Department 2: // open schedule form( )
<<boundary>>
1 0..*
<<control>>
CourseCatalogSystem RegistrationController
1: // select maintain schedule( )
// get course offerings() // add courses to schedule()
5: // select 4 primary and 2 alternate offerings( )
: Maintain // get course offerings ()
ScheduleForm 0..1
: Student
• one controller for each Schedule
Pre-requisites 3: // get course offerings( ) being created (e.g., each Student
1
6: // add courses to schedule( )
registration session). <<entity>>
: Registration • only one CourseCatalogSystem Schedule
: CourseCatalog4: // get course offerings( ) Controller instance for possibly many
System MaintainScheduleForms // create with offerings()
• serializes access
Course 7: // create with offerings( )• Many MaintainScheduleForms
can be active at one time (for
different sessions/students).
:Schedule
View of Participating Classes (VOPC) diagram.

17-Design Jackson System Development (JSD)

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

17-Design Jackson System Development (JSD)

Uploaded by

Copyright:

Available Formats

CMPSCI520/620 Design ***DRAFT*** 11/4/04

17-Design Jackson System Development (JSD)

Student Loan Example Step 1: Entity/action step

Rick Adrion 2004 (except where noted) 1

Focus on: Step 2: Entity structure step

Rick Adrion 2004 (except where noted) 2

Model Process Model Processes

Step 3: Model process step Error handling

Rick Adrion 2004 (except where noted) 3

Total System Model Model Process Communication

Message Passing State Vector Inspection

Rick Adrion 2004 (except where noted) 4

Network Phase -- the SSD Designing the LBE function w/ JSP

• DT is an input signal at the end of the day--a daily time marker--that

Implementation Phase The SID

Rick Adrion 2004 (except where noted) 5

Design of the scheduler in JSP JSD and JSP

Comments/Evaluation Rational Unified Process

Rick Adrion 2004 (except where noted) 6

In RUP: Major Workflows Produce Models The RUP Iterative Model

Requirements Workflow Analysis & Design Workflow

User-Interface User-Interface Class

Rick Adrion 2004 (except where noted) 7

Implementation Workflow Test Workflow

Structure the PlanTest ImplementTest

Design Test Classes

Code Reviewer Review Code

Implement Test Components

O-O System Development A Minimal Iterative Process

Rick Adrion 2004 (except where noted) 8

A Minimal Iterative Process A Minimal Iterative Process

RUP Design - Where to Begin? Architectural Analysis Topics

Rick Adrion 2004 (except where noted) 9

“4+1 View” Model Packages

Process View Deployment View ClientPackage SupplierPackage

Example: Modeling Conventions Architectural Mechanisms

Rick Adrion 2004 (except where noted) 10

Sample Analysis Mechanisms Identify Key Concepts

Typical Layering Approach High-Level Organization of the Model

Registration Student Evaluation

Rick Adrion 2004 (except where noted) 11

Architectural Analysis So whqat do we do next?

identified and accurately modeled? Class

• Have the entity classes been mapped to the necessary

Use Case Analysis Overview What is a Use-Case Realization?

Use Case Use Case Realization

OR Sequence Diagrams Collaboration

Rick Adrion 2004 (except where noted) 12

Use Case Analysis Steps University Course Registration System

• Supplement the Descriptions of the Use Case

• Describe Attributes and Associations Register for Courses

• Qualify Analysis Mechanisms

What is an Analysis Class? The Roles

Rick Adrion 2004 (except where noted) 13

Example: Entity & Control Classes Describe Responsibilities

Student Professor Schedule

RegistrationController CloseRegistrationController MaintainStudentController

MaintainProfessorController SelectCoursesToTeachController ReportCardController

Class Responsibilities from a Class Responsibilities from a

3: // get course offerings( )

7: // create with offerings( )

<<boundary>> <<entity>> <<boundary>> <<entity>>

<<control>> <<boundary>> <<control>> <<boundary>>

CMPSCI520/620 Design DRAFT 11/4/04