Software Engineering 2 Spring 2003 The development process

1
Software Engineering 2Spring 2003The
development process

• Eliezer Kaplansky
• and
• Guy Viener

2
Unified Process for EDUcation (UPEDU)
http//www.upedu.org/upedu/
Rational Software Corporation  
École Polytechnique de Montréal
3
Phases and Iterations
4
The final goal Artifacts

• A document, such as Software Requirements
  Specification
• A model, such as the Use-Case Model or the
  Design Model
• A model element that is, an element within a
  model, such as a class, or a subsystem .

5
Use cases is the BASIC tool for SE
6
Requirements Activity Overview
The roles and activities involved in the
Requirements discipline
7
Requirements Artifact Set
8
Requirements Workflow Detail
9
Structuring the Use-Case Model

• The use-case model can be organized as a
  hierarchy of use-case packages, with "leaves"
  that are actors or use cases.

10
Analysis phase
11
Architectural Blueprints

• Use Case View Use-case diagrams depicting use
  cases, actors, and ordinary design classes
  sequence diagrams depicting design objects and
  their collaboration.
• Logical view Class diagrams, state machines, and
  object diagrams.
• Implementation view Component diagrams .

12
The Use-Case View

• An architecture view called the use-case view is
  the basis for planning the technical contents of
  an iterations.
• The use-case view is refined and considered
  initially in each iteration.

13
Analysis Design Activity Overview
The purposes of Analysis Design are

• To transform the requirements into a design of
  the system-to-be.
• To evolve a robust architecture for the system.
• To adapt the design to match the implementation
  environment.

14
Analysis Design Artifact Set
15
Artifact  Use-Case Realization

• 1. Introduction
• 1.1 Purpose
• 1.2 Scope
• 1.3 Definitions, Acronyms, and Abbreviations
• 1.4 References
• 1.5 Overview
• 2. ltUse-Case Name Onegt
• 2.1 Flow of Events - Design
• 2.2 Interaction Diagrams
• 2.2.1 Sequence Diagrams
• 2.2.2 Collaboration Diagrams
• 2.2.3 Participating objects
• 2.3 Class Diagrams
• 2.4 Derived Requirements

Use-Case Realization
A use-case realization describes how a particular
use case is realized within the design model, in
terms of collaborating objects.
Separating the use-case realization from its use
case allows the use cases to be managed
separately from their realizations.
16
Use-Case Analysis Steps

• Supplement the Use-Case Descriptions
• For each use case realization
• Find Analysis Classes from Use-Case Behavior
• Distribute Behavior to Analysis Classes
• For each resulting analysis class
• Describe Responsibilities
• Describe Attributes and Associations
• Define Attributes
• Establish Associations between Analysis Classes
• Describe Event Dependencies between Analysis
  Classes
• Qualify Analysis Mechanisms
• Evaluate the Results of Use-Case Analysis.

17
The Logical View

• The logical view illustrates the key use-case
  realizations, subsystems, packages and classes
• The logical view is refined and considered
  initially in each iteration.

18
Analysis phase dynamic behavior
19
Design phaseStatic model
20
Use-Case Design Steps

• Describe Interactions Between Design Objects
• Simplify Sequence Diagrams using Subsystems
  (optional)
• Describe Persistence-related Behavior
• Writing Persistent Objects
• Reading Persistent Objects
• Deleting Persistent Objects
• Modeling Transactions
• Handling Error Conditions
• Handling Concurrency Control
• Refine the Flow of Events Description
• Unify Classes and Subsystems
• Evaluate Your Results

21
Design phase dynamic behavior
22
A Use Case Flow of Events

• It can be useful to use the notion of
  precondition and post-condition to clarify how
  the flow of events starts and ends. However, only
  use it if it is perceived as adding value by the
  audience of the use case.

23
Activity  Class Design

• Create Initial Design Classes
• Identify Persistent Classes
• Define Class Visibility
• Define Operations
• Define Methods
• Define States
• Define Attributes
• Define Dependencies
• Define Associations
• Define Generalizations
• Handle Non-Functional Requirements in General
• Evaluate Your Results

24
Implementation  Workflow Activity Overview
25
Implementation Artifact Set
26
Project Documentation

• Documentation, is the very lifeblood within any
  phase of the software lifecycle.

27
(No Transcript)
28
IEEE Project Documentation
SVVP software validation verification plan
Verification validation
SQAP software quality assurance plan
Quality assurance
SCMP software configuration management plan
Configuration
SPMP software project management plan
Project status
Customer-oriented
SRS software requirements specifications
Requirements
Developer-oriented
SDD software design document
Architecture
Design
Detailed design
Source Code
Code
STD software test documentation
Testing
Users manual
Operation
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
29
Information set evolution over the development
phases
30
Documentation management