Date post: | 14-Jan-2016 |
Category: |
Documents |
Upload: | job-little |
View: | 214 times |
Download: | 1 times |
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
CSC480 - Software Engineering 39/20/2002
UP Phases & Workflows
CSC480 - Software Engineering 49/20/2002
UP Phases & Milestones
CSC480 - Software Engineering 59/20/2002
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.
CSC480 - Software Engineering 69/20/2002
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
CSC480 - Software Engineering 79/20/2002
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
CSC480 - Software Engineering 89/20/2002
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
CSC480 - Software Engineering 99/20/2002
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
CSC480 - Software Engineering 109/20/2002
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
CSC480 - Software Engineering 119/20/2002
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
CSC480 - Software Engineering 129/20/2002
Sample App – ATM transactions
Entityobjects
DBbroker
Presentation
Domainobjects
Controlobjects
Securitymanager
Storage
Serviceobjects
Application Logic
Layers in a typical O-O information system
DB
CSC480 - Software Engineering 139/20/2002
Feature List & Domain Model
Feature List - see Sample App 2 Need Statement
Domain model
Transaction
Deposit Transfer Withdraw
Account
Entityobjects
Controlobjects
CSC480 - Software Engineering 149/20/2002
The GUI Objects
CSC480 - Software Engineering 159/20/2002
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
CSC480 - Software Engineering 169/20/2002
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.
CSC480 - Software Engineering 179/20/2002
Use Case Specification
CSC480 - Software Engineering 189/20/2002
Represent Complex Use Case
Some arrowed links may have condition associated with them.
CSC480 - Software Engineering 199/20/2002
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
CSC480 - Software Engineering 209/20/2002
Requirement Tracing
A Requirement Traceability Matrix
CSC480 - Software Engineering 219/20/2002
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)
CSC480 - Software Engineering 229/20/2002
CSC480 - Software Engineering 239/20/2002
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
CSC480 - Software Engineering 249/20/2002
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
CSC480 - Software Engineering 259/20/2002
Use-Case & Analysis Models
CSC480 - Software Engineering 269/20/2002
Withdraw Money
CSC480 - Software Engineering 279/20/2002
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
CSC480 - Software Engineering 289/20/2002
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
CSC480 - Software Engineering 299/20/2002
Design Class Diagram
CSC480 - Software Engineering 309/20/2002
Sequence Diagram
CSC480 - Software Engineering 319/20/2002
Package Classes into Subsystems
CSC480 - Software Engineering 329/20/2002
Deploy A Distributed System