Object-Oriented Design (OOD) Case Study : Architecture and Detail Design and Software Design Document (SDD) Prepared by Shahliza Abd Halim

Size: px

Start display at page:

Download "Object-Oriented Design (OOD) Case Study : Architecture and Detail Design and Software Design Document (SDD) Prepared by Shahliza Abd Halim"

Moris Manning
5 years ago
Views:

1 Object-Oriented Design (OOD) Case Study : Architecture and Detail Design and Software Design Document (SDD) Prepared by Shahliza Abd Halim

Diagram) Requirement Analysis 1) Functional &

1) System Sequence Diagram 2) Activity Diagram

User Manual Documentation Testing & Deployment

2 Recap on SDLC Phases & Artefacts Domain Business Process Domain Model (Class Diagram) Requirement Analysis 1) Functional & Non-Functional requirement 2) Use Case diagram 1) System Sequence Diagram 2) Activity Diagram SRS Design 1) Class Diagram (refined) 2) Detail Sequence Diagram 3) State Diagram Implementation 1) Application Source Code 2) User Manual Documentation Testing & Deployment 1) Test Cases 2) Prototype Maintenance & Evolution 1) Change Request Form

3 Domain Analysis Domain Model 1) Class Diagram Requirement Requirement Models 1) Functional & Non-Functional requirement 2) Use Case diagram SRS Analysis Analysis Models 1) System Sequence Diagram 2) Activity Diagram Early Design : Architectural Design Architectural Models 1) Package Diagram (Subsystem) Detailed Design Design Models 1) Class Diagram (refined) 2) Sequence Diagram (refined) 3) State Diagram SDD

5 Weather station description (pg.22 Sommerville) To help weather climate change and to improve accuracy of weather forecast in remote areas; which several hundreds weather station are deploy in the identified areas. A weather station is a package of software controlled instruments which collects data, performs some data processing and transmits this data for further processing. The instruments include air and ground thermometers, an anemometer, a wind vane, a barometer and a rain gauge. Data is collected periodically. 5

6 Weather station description (pg.22 Sommerville) When a command is issued to transmit the weather data, the weather station processes and summarises the collected data. The summarised data is transmitted to the mapping computer when a request is received.

7 STAGE : DOMAIN ANALYSIS (BUSINESS ENVIRONMENT & PROCESS)

8 System context for the weather station 8

9 STAGE: REQUIREMENT

10 Weather station User Requirements

11 Weather station use cases uc Use Case Model Report Weather Report Status Weather Operator Data Archiv e Restart Control System Shutdown Reconfigure Power Sav e Remote Control 11

12 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

13 Use case description Report Status scenario System Use case Actors Description Weather station Report Status Weather Operator 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

14 STAGE: ANALYSIS

15 Sequence diagram describing data collection 15

16 STAGE : EARLY DESIGN (ARCHITECTURAL DESIGN)

17 Recap Architectural design : The design process for identifying the sub-systems making up a system and the framework for sub-system control and communication. It involves identifying major system components and their communications. Represents the link between specification and design processes. Link can be explicitly described by having traceability

Recap on Architectural Design Classification Repository Model Client-Server Model System Organisation (Style/Pattern) Layered (Tiers) Model Pipe & Filter Architectural

18 Recap on Architectural Design Classification Repository Model Client-Server Model System Organisation (Style/Pattern) Layered (Tiers) Model Pipe & Filter Architectural Design Control Style Model Model-View- Controller Call-Return Manager Centralised Modular Composition Event-Driven Broadcast Function-Oriented Interrupt- Driven Object-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?

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?

19 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 functional requirements? ( 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) Chapter 6 Architectural design 19

20 Architectural design decision architectural style

21 Layered architecture 4 layers for Weather Station cmp Component Model Data Display Data Display Layer Data Archiv ing Data Archi ving Layer Data Processing Data Processi ng Layer Data collection Data Collection Layer

22 Traceability between user requirements; system requirements and subsystem in model req Traceability Data Display REQ011 - Collecting Weather Data «realize» Report Weather «trace» (from RE01 - CollectWeatherData) REQ012 - Analysis Data «realize» «realize» (from Use Case Model) (from Component Model) (from RE01 - CollectWeatherData) Data Archiv e REQ013 - Transmitting Weather Data (from Use Case Model) «trace» Data Archiv ing (from RE01 - CollectWeatherData) Restart REQ024 - Archives data for the use of other system (from Use Case Model) «trace» (from Component Model) (from RE02 - Manage and Archive Data) Data Processing Shutdown REQ031 - Monitor the the instrument, power and communication hardware (from Use Case Model) (from Component Model) (from RE03 - System Maintenance for the Station) Report Status 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 Use Case Model) Power Sav e (from Use Case Model) Reconfigure Data collection (from Component Model) (from RE03 - System Maintenance for the Station) (from Use Case Model) Remote Control (from Use Case Model) User requirements System requirements Subsystem design

23 Traceability table Requirement Source / 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

24 Traceability Table Requirements IDD Use Case Realization Design Reference REQ11 :Collecting Weather Data REQ12:Analysis Data REQ13:Transmitting Weather Data REQ024:Archive data for the use of other system REQ031:Monitor the instrument, power and communication hardware Report faults to the management system Report Weather Data Archive Restart, Shutdown Report status Data Display; Data Collection Data Archiving Data processing Data Processing....

25 STAGE : DETAILED DESIGN

26 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.

27 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.

28 Weather station subsystems «subsystem» Inter face «subsystem» Data collection CommsController WeatherData WeatherStation Instrument Status «subsystem» Instruments Air thermometer RainGauge Anemometer Ground thermometer Barometer WindVane

29 Class Diagram in Each Subsystems Identify it from the sequence diagram of each use case related to the subsystem «subsystem» Data collection «subsystem» Data display Observer Comms Satellite User User inter interface Map display Weather station Balloon Map Map printer «subsystem» Data processing «subsystem» Data archiving Data checking Data integ ration Map store Data Data storage storage Data store

30 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.

31 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.

32 Weather station object classes

33 State: State Transition Diagram 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

34 Transition notation State-A Event (arguments) [condition] / action State-B i. Event: ii. iii. triggers the transition Something happened to an object Guard condition: Transition only eligible to fire when guard evaluates to true = constraints 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

35 Example: State diagrams for a simple traffic light GreenLight after(25s) YellowLight after(25s) after(30s) RedLight Initial 36

36 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

37 Weather station state diagram Weather Station class Weather Station state diagram

38 Recap on Interface Design

39 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

40 Weather station interfaces

41 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

Recap on SDLC Phases & Artefacts

Prepared by Shahliza Abd Halim Recap on SDLC Phases & Artefacts Domain Analysis @ Business Process Domain Model (Class Diagram) Requirement Analysis 1) Functional & Non-Functional requirement 2) Use Case