Embed Size (px)
Citation preview
Object-Oriented Design (OOD) Case Study : Architecture and Detail Design
andSoftware Design Document (SDD)
Prepared by
Shahliza Abd Halim
Recap on SDLC Phases & Artefacts
Domain Analysis @ Business Process
Requirement
Analysis
Design
Implementation
Testing & Deployment
Maintenance & Evolution
Domain Model (Class Diagram)
1) Functional & Non-Functional requirement 2) Use Case diagram
1) System Sequence Diagram 2) Activity Diagram
1) Class Diagram (refined) 2) Detail Sequence Diagram3) State Diagram
1) Application Source Code2) User Manual Documentation
1) Test Cases 2) Prototype
1) Change Request Form
SRS
Domain Analysis
Requirement
Analysis
Early Design : Architectural Design
Detailed Design
Domain Model 1) Class Diagram
Requirement Models 1) Functional & Non-Functional requirement 2) Use Case diagram
Analysis Models1) System Sequence Diagram 2) Activity Diagram
Architectural Models1) Package Diagram (Subsystem)
Design Models1) Class Diagram (refined) 2) Sequence Diagram (refined)3) State Diagram
SRS
SDD
Weather station description (pg.22 Sommerville)
• To help weather climate change and to improve accuracy ofweather forecast in remote areas; which several hundredsweather station are deploy in the identified areas.
• A weather station is a package of software controlledinstruments which collects data, performs some dataprocessing and transmits this data for further processing. Theinstruments include air and ground thermometers, ananemometer, a wind vane, a barometer and a rain gauge.Data is collected periodically.
5
Weather station description (pg.22 Sommerville)
• When a command is issued to transmit the weather data, theweather station processes and summarises the collecteddata. The summarised data is transmitted to the mappingcomputer when a request is received.
STAGE : DOMAIN ANALYSIS (BUSINESS ENVIRONMENT & PROCESS)
System context for the weather station
8
STAGE: REQUIREMENT
Weather station User Requirements
Weather station use cases
11
uc Use Case Model
Weather Operator
Control System
Report Weather
Report Status
Restart
Shutdown
Reconfigure
Power Sav e
Remote Control
Data Archiv e
Use case description—Report weather scenario
System Weather station
Use case Report weather
Actors Weather Operator
Description 1. The weather operator sends a summary of the weather data that has been collected from the instruments in the collection period to the weather information system.2. The data sent to the maximum, minimum, and average ground and air
temperatures; 3. The data sent to the barometer are the maximum, minimum, and average
air pressures; the maximum, minimum, and average wind speeds; the total rainfall; and the wind direction as sampled at five-minute intervals.
12
Use case description—Report Status scenario
System Weather station
Use case Report Status
Actors Weather Operator
Description 1. The weather operator sends a summary of the weather data that has been collected from the instruments in the collection period to the weather information system.2. The data sent to the maximum, minimum, and average ground and air
temperatures; 3. The data sent to the barometer are the maximum, minimum, and average
air pressures; the maximum, minimum, and average wind speeds; the total rainfall; and the wind direction as sampled at five-minute intervals.
13
STAGE: ANALYSIS
Sequence diagram describing data collection
15
STAGE : EARLY DESIGN(ARCHITECTURAL DESIGN)
Recap
• Architectural design :
– The design process for identifying the sub-systemsmaking up a system and the framework for sub-systemcontrol and communication.
• It involves identifying major system components and theircommunications.
• Represents the link between specification and designprocesses.
– Link can be explicitly described by having traceability
Recap on Architectural Design Classification
Architectural Design
System Organisation
(Style/Pattern)
Repository Model
Client-Server Model
Layered (Tiers) Model
Pipe & Filter
Model-View-ControllerControl Style
Model
Centralised
Call-Return
Manager
Event-Driven Broadcast
Interrupt-Driven
Modular Composition
Object-Oriented
Function-Oriented
Architectural design decisions (9 QUESTIONS)
1. What approach will be used to structure the system? (4+1 views)
2. What architectural styles are appropriate? (5 basic styles/patterns: Repository, Client-Server, Layered, Pipe&Filter, MVC)
3. What control strategy should be used? ( Centralised vs. Event-driven)
4. How will the structural components be decomposed into subcomponents? (Object-oriented vs. Functional-oriented/structured)
5. Is there a generic application architecture that can be used? (Data | Transaction | Event | Language Processing application)
6. What architectural organization is best for delivering the non functionalrequirements? ( Performance | Security | Safety | Availability | Maintainability)
7. How will the system be distributed? (visualise in Deployment diagram )
8. How will the architectural design be evaluated? (ATAM method)
9. How should the architecture be documented? (Software Design Document-SDD)
19Chapter 6 Architectural design
Architectural design decision– architectural style
Layered architecture –4 layers for Weather Station
cmp Component Model
Data Display
Data Archiv ing
Data Processing
Data collection
Data Display Layer
Data Archiving Layer
Data Processing Layer
Data Collection Layer
Traceability between user requirements; system requirements and subsystem in model
req Traceability
(from Use Case Model)
Power Sav e
(from Use Case Model)
Reconfigure
(from Use Case Model)
Remote Control
(from Use Case Model)
Report Status
(from Use Case Model)
Report Weather
(from Use Case Model)
Restart
(from Use Case Model)
Shutdown
REQ011 -
Collecting
Weather Data
(from RE01 - CollectWeatherData)
REQ012 -
Analysis Data
(from RE01 - CollectWeatherData)
REQ013 -
Transmitting
Weather Data
(from RE01 - CollectWeatherData)
REQ024 - Archives data for the use of
other system
(from RE02 - Manage and Archive Data)
(from Use Case Model)
Data Archiv e
REQ031 - Monitor the the instrument, power
and communication hardware
(from RE03 - System Maintenance for the Station)
REQ032 - Report Faults to the Management System
(from RE03 - System Maintenance for the Station)
REQ033 - Manage the system power, ensuring the batteries are
charged
(from RE03 - System Maintenance for the Station)
REQ034 - Allow for dynamic reconfiguration where parts
of the software are replaced with new versions
(from RE03 - System Maintenance for the Station)
Data Archiv ing
(from Component Model)
Data Display
(from Component Model)
Data Processing
(from Component Model)
Data collection
(from Component Model)
«realize»
«realize»
«realize»
«trace»
«trace»
«trace»
User requirements System requirements Subsystem design
Traceability table
RequirementSource / ID Use Case Realization Design Reference
Requirement Source / ID
The Unique Requirement ID / System Requirement Statement where the requirement is referenced in the Software Requirement Specification Document
Use case realization Describe which use case related to the user requirements
Design Reference Specify subsystem which can be traced back to the use case
Traceability Table
Requirements IDD Use Case Realization Design Reference
REQ11 :Collecting Weather Data
Report Weather Data Display; Data Collection
REQ12:Analysis Data
REQ13:TransmittingWeather Data
REQ024:Archive data for the use of other system
Data Archive Data Archiving
REQ031:Monitor the instrument, power and communication hardware
Restart , Shutdown Data processing
Report faults to the management system
Report status Data Processing
…. …. …..
STAGE : DETAILED DESIGN
Examples of design models
1. Subsystem models that show logical groupings of objects into coherent subsystems.
2. Sequence models that show the sequence of object interactions.
3. State machine models that show how individual objects change their state in response to events.
4. Other models include use-case models, aggregation models, generalisation models, etc.
Package diagram- Subsystem models
• Shows how the design is organised into logically related groups of objects.
• In the UML, these are shown using packages - an encapsulation construct. This is a logical model. The actual organisation of objects in the system may be different.
Weather station subsystems
« subsystem»Inter face
« subsystem»Data collection
CommsController
WeatherStation
WeatherData
InstrumentStatus
« subsystem»Instruments
Air thermometer
Ground thermometer
RainGauge
Barometer
Anemometer
WindVane
Class Diagram in Each Subsystems
Datastorage
Userinter face
« subsystem»Data collection
« subsystem»Data processing
« subsystem»Data archiving
« subsystem»Data display
Weatherstation
Satellite
Comms
Balloon
Observer
Map store Data store
Datastorage
Map
Userinter face
Mapdisplay
Mapprinter
Datachecking
Datainteg ration
Identify it from the sequence diagram of each use case related to the
subsystem
Object-Class Identification
• Use a grammatical approach based on a natural language description of the system (used in OOD method).
• Base the identification on tangible things in the application domain.
• Use a behavioural approach and identify objects based on what participates in what behaviour.
• Use a scenario-based analysis. The objects, attributes and methods in each scenario are identified.
Weather station object classes
• Object class identification in the weather station system may be based on the tangible hardware and data in the system:
1. Ground thermometer, Anemometer, Barometer
• Application domain objects that are ‘hardware’ objects related to the instruments in the system.
2. Weather station
• The basic interface of the weather station to its environment. It therefore reflects the interactions identified in the use-case model.
3. Weather data
• Encapsulates the summarized data from the instruments.
Weather station object classes
State Transition Diagram
• State:
– a condition during the life of an object when it satisfies some condition, performs some action, or waits for an event
– found by examining the attributes and links defined for the object
– represented as a rectangle with rounded corners
• Transition
– represents a change of the internal condition/state of an object
34
Transition notation
i. Event: triggers the transition
“Something happened to an object”
ii. Guard condition: Transition only eligible to fire when guard evaluates to true =
constraints
iii. Action: May include operation calls, the creation or destruction of another
objects, or the sending of a signal to an object.
“something the object does”
35
State-A State-BEvent (arguments) [condition] / action
Example: State diagrams for a simple traffic light
36
GreenLight
YellowLight
RedLight
after(30s)
after(25s)
after(25s)
Initial
Rules of thumb
• Not every class needs a state diagram
• Often: State diagram not very complex except for certain applications i.e. real-time systems
• State diagrams are often used for UI and control objects
37
Weather station state diagram
Weather Station
class
Weather Station
state diagram
Recap on Interface Design
Recap on Interfaces in OOD concept
• A special class that contains a collection of operations that are used to specify a service of a class.
– Interfaces specify, but not implement behaviour.
40
Weather station interfaces
Weather station interface source code example (how it applied in implementation)
interface WeatherStation {
public void WeatherStation () ;
public void startup () ;
public void startup (Instrument i) ;
public void shutdown () ;
public void shutdown (Instrument i) ;
public void reportWeather ( ) ;
public void test () ;
public void test ( Instrument i ) ;
public void calibrate ( Instrument i) ;
public int getID () ;
} //WeatherStation
