Recap on SDLC Phases & Artefacts

Transcription

1 Prepared by Shahliza Abd Halim 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 1

2 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 Detailed Design Architectural Models 1) Package Diagram (Subsystem) Design Models 1) Class Diagram (refined) 2) Sequence Diagram (refined) 3) State Diagram SDD 2

3 WWS descrip>on (pg.180 Sommerville) To help weather climate change and to improve accuracy of weather forecast in remote areas; which several hundreds weather sta>on are deploy in the iden>fied areas. A Wilderness Weather Sta>on (WWS) is a package of sooware 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 WWS descrip>on When a command is issued to transmit the weather data, the weather sta>on processes and summarises the collected data. The summarised data is transmired to the mapping computer when a request is received. 3

4 STAGE : DOMAIN ANALYSIS (BUSINESS ENVIRONMENT & PROCESS) System context for the WWSS 8 4

5 STAGE: REQUIREMENT WWSS User Requirements 5

6 WWSS Use Case Diagram 11 Use case descrip>on Report Status scenario System Use case Actors Descrip>on Weather staqon Report Status Weather Operator 1. The weather operator sends a summary of the weather data that has been collected from the instruments in the collec>on period to the weather informa>on 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 direc>on as sampled at five minute intervals. 12 6

7 STAGE: ANALYSIS Sequence diagram describing data collec>on 14 7

8 STAGE : EARLY DESIGN (ARCHITECTURAL DESIGN) Recap Architectural design : The design process for idenqfying the sub systems making up a system and the framework for sub system control and communicaqon. It involves idenqfying major system components and their communicaqons. Represents the link between specificaqon and design processes. Link can be explicitly described by having traceability 8

9 Recap on Architectural Design Classifica>on Repository Model Client Server Model System Organisa/on (Style/ Pa5ern) Layered (Tiers) Model Pipe & Filter Architectural Design Control Style Model Model View Controller Call Return Manager Centralised Modular Composi/on Event Driven Broadcast Func>on 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? (5 basic styles/parerns: 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. Func>onal oriented/structured) 5. Is there a generic applicaqon architecture that can be used? (Data Transac>on Event Language Processing applica>on) 6. What architectural organiza>on is best for delivering the non funcqonal 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? (SoOware Design Document SDD) 18 9

10 Architectural design decision architectural style Package diagram Shows how the design is organised into logically related groups of objects. In the UML, these are shown using packages an encapsula>on construct. This is a logical model. The actual organisa>on of objects in the system may be different. In this case study, packages is used to logically organised layers, packages in layers and class diagram in each packages. 10

11 Layered architecture 3 layers for WWSS with dependency rela>onships Dependency Rela>onships Guideline to Determine Classes Suitable for Layers and Packages A) From Object Class Iden>fica>on B) From Sequence Diagram <<boundary>>, <<control>> and <<en>ty>> classes 11

12 A) From Object Class Iden>fica>on Use a gramma>cal approach based on a natural language descrip>on of the system (used in OOD method). Objects and arributes are nouns; opera>ons and services are verbs Base the iden>fica>on on tangible things in the applica>on domain. AircraO, roles (mangers, doctors), events (request, response), loca>ons (offices), organiza>ons (UTM, FSKSM). Use a behavioural approach and iden>fy objects based on what par>cipates in what behaviour. Use a scenario based analysis. The objects, arributes and methods in each scenario are iden>fied. Example Object Class Iden>fica>on for WWSS Object class iden>fica>on in the weather sta>on system may be based on the tangible hardware and data in the system: 1. Ground thermometer, Anemometer, Barometer Applica>on domain objects that are hardware objects related to the instruments in the system. 2. Weather staqon The basic interface of the weather sta>on to its environment. It therefore reflects the interac>ons iden>fied in the use case model. 3. Weather data Encapsulates the summarized data from the instruments. 12

13 B) From Sequence Diagram <<boundary>>, <<control>> and <<en>>y>> classes PresentaQon Layer Boundary and control classes is recommended to be in the applica>on layer you can group the classes into a suitable packages i.e based on your use case etc. Business Logic Layer En>ty classes is recommended to be in the business service layer (control class with heavy processing etc is also recommended in this layer You can group the classes into a suitable packages Middleware layer Contains components, subsystems or classes which are used for connec>ng to external system, databases, or hardware. Recommended for libraries you use to connect between database and also your applica>on. Can be any libraries you used i.e java development kit library etc. Layered Architecture Style, Package and Classes for WWSS Packages: i.e Data Display and Data Collec>on Classes in Data Collec>on Package Layer 13

14 STAGE : DETAILED DESIGN CLASS DIAGRAM RELATIONSHIPS, ATTRIBUTES AND OPERATIONS STATE DIAGRAM Guideline for Class Diagram Detail Design A) Determine Class Diagram Rela>onships and Opera>ons using Sequence Diagram B) Determine Classes ARributes and opera>ons from your own understanding 14

15 A) Determine Class Diagram Rela>onships and Opera>ons using Sequence Diagram Rela>onships are iden>fied by examining interac>on diagrams If two objects must talk there must be associa>on rela>onships between the classes Opera>on addstudent(string) is opera>on for Course Class Registra>on Manager Math 101: Course 3: add student(joe) addstudent(string) Class Diagram for Presenta>on Layer 15

16 B) Determine Classes ARributes and opera>ons from your own understanding Classes arributes and opera>ons for Weather Instrument Package Guideline for State Diagram Not every class needs a state diagram OOen: State diagram not very complex except for certain applica>ons i.e. real >me systems State diagrams are ooen used for UI and control objects As an example Weather Sta>on suitable for State Diagram 32 16

17 Weather sta>on state diagram Weather StaQon state diagram Weather StaQon class TRACEBILITY BETWEEN USER REQUIREMENTS, USE CASE AND DESIGN 17

18 Traceability When you build or model a system, you start at a with requirements and lirle detail. Then, you proceed to a lower level of abstrac>on; for example, to a design with more detail. Viewing the system from different levels of abstrac>on can help stakeholders such as project managers, developers, and testers berer understand how the system works. You can trace an element in either a forward or backward direc>on. Backward Traceability between user requirements; use case and Architecture Design for WWSS User requirements Use case Architecture Design 18

19 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 Traceability Table Requirements IDD Use Case RealizaQon Design Reference REQ11 REQ12 REQ13 Retrieve Weather Report Data Collec>on REQ024 Manage Data Archive Data Archiving REQ031 Restart, Shutdown, Powersave, RemoteControl, Reconfigure Instuments Hardware Interface Report status Data Display