csc480 software engineering lecture 8-9 september 20, 2002

CSC480Software Engineering

Lecture 8-9September 20, 2002

CSC480 - Software Engineering 29/20/2002

Topics

Projects 2&3 review Unified Process Analysis: bridging the gap between

requirement and design UML diagrams


UP Phases & Workflows


UP Phases & Milestones


Req’t Workflow – overview

The essential purpose is to aim development toward the right system.

Achieved by describing the requirements well enough so that an agreement can be reached between customer and the system developers.

Requirements must be written in the language of the customer.


Req’t Workflow – participants

Participants should include Customers – domain experts, end users Development team – architects, analyst

The users don’t know what they require Fail to give a whole picture of the system Don’t know what can be implemented Don’t know how efficient the system could be Don’t know how to express req’ts precisely


Requirement Capture

The workflow includes the following steps which are not actually performed separately: List candidate requirements Understand system context

Domain model Use cases

Capture functional requirements Capture nonfunctional requirements


List Candidate Requirements

Gather desired features from stakeholders Name, brief description/definition. A set of planning values:

Status (proposed, approved, validated) Estimated cost of implementation (in terms of resource types,

man-hours) Priority (critical, important, ancillary) Associated level of risk in implementing the feature (critical,

significant, or ordinary) Artifacts Feature list


Understand System Context

Domain modeling Expressing important context concepts as domain

objects, and links to one another Develops a glossary of terms for team communication

Business modeling Describing the business process A superset of domain modeling

Artifacts Business or domain model


Capture Functional Req’ts

Use cases To the user, a use case is a way of using the system A user needs a number of use cases

(G)UI is an adjunct to use cases specifying the way a system looks to users when a

use case is performed Artifacts Use-case model


Capture Nonfunctional Req’ts

Address required system properties in the use cases to which they apply, as special req’ts

Environmental/implementation constraints Performance Platform dependency Maintainability reliability

Artifacts Supplementary requirements


Sample App – ATM transactions

Entityobjects

DBbroker

Presentation

Domainobjects

Controlobjects

Securitymanager

Storage

Serviceobjects

Application Logic

Layers in a typical O-O information system

DB


Feature List & Domain Model

Feature List - see Sample App 2 Need Statement

Domain model

Transaction

Deposit Transfer Withdraw

Account

Entityobjects

Controlobjects


The GUI Objects


Build a Use Case Model Use case model

represents functional requirements

Actors are the environment of the system

Use cases specify the system

Deposit money

Transfer btwaccounts

Withdraw money


Use Case – a definition

A use case specifies a sequence of actions, including variations, that the system can perform and that can yields an observable result of value to a particular actor.


Use Case Specification


Represent Complex Use Case

Some arrowed links may have condition associated with them.


Sample Use Case - Withdraw Money

The sequence of actions for the main path through this use case is The Bank Customer identifies himself/herself The Bank Customer chooses from which account to

withdraw money and specifies how much to withdraw The system deducts the amount from the account and

dispenses the money


Requirement Tracing

A Requirement Traceability Matrix


Analysis – overview

Analyze requirements by refining and structuring them

Essential purposes include Yield a more precise specification of the req’ts Described in developers’ language better for

reasoning about system internals Well-structured for changes and maintenance First-cut of design (yet not so overwhelming)


Analysis Class Diagrams

Boundary objects Objects with which actors will be

interacting

Entity objects Info holders, from domain model outlive use case execution

Control objects Objects that embody application

logic


Analysis Diagram Rules

Actors can talk only to boundary objects Boundary objects can talk only to controllers and

actors Entity objects can only talk to controllers Controllers can talk to both boundary and entity

objects, but not to actors


Use-Case & Analysis Models


Withdraw Money


Analysis Workflow

Architectural analysis Identify packages Identify obvious classes Identify common special requirements

Analyze use cases Identify classes whose objects are used here Distribute the behavior to interacting objects Capture special requirements


Analysis Workflow – continued

Analyze classes Identify and update the responsibilities Identify and update attributes and relationships Capture special requirements on them

Analyze packages Ensure packages are independent Ensure each package fulfill its purpose Describe dependencies


Design Class Diagram


Sequence Diagram


Package Classes into Subsystems


Deploy A Distributed System

csc480 software engineering lecture 8-9 september 20, 2002

Documents