Iterative System Building: Analyzing, Designing, and Coding with Spiral Model, Lecture notes of Computers and Information technologies

Download Iterative System Building: Analyzing, Designing, and Coding with Spiral Model and more Lecture notes Computers and Information technologies in PDF only on Docsity!

System Building 2

Lecture 16

The Iterative Approach:

Analysis Through Design To Code

The SDLC

Analysis Design Implementation Fault finding A Spiral Model Analysis Analysis Design Design Fault finding Implementation

This appears on

the next slide

A state chart of an Iteration

Designing Implementing Testing Analysing Analysis looks ok Design looks ok Implementation seems ok Testing went ok Analysis Design^ problem problem Implementation problem Start iteration

Two Iterations

Designing Implementing Testing Analysing Designing Implementing Testing Analysing Analysis looks ok Design looks ok Implementation seems ok Analysis problem Design problem Implementation problem Lock Down & Start iteration 2 A ok D ok I ok D Prob A Prob I Prob Lock Down & Start iteration 3

Some aspects of analysis

followed through to design

Following (slide after next) is a slide of a use

case diagram submitted by a student

It is supposed to model the functionality

of a machine

It has some errors

We will remodel it

What are they trying to model?

Belt 1

Belt 3

Machine 1 Belt 2

C

C

C

Component type 1 Component type 2

Assembly

(Component type 3)

W1:Worker

A

powered on/off, speed set by W

Accepts components (C1,C2)

from belts (B1, B2)

producing an assembly (A1)

ejecting onto (B3).

If wrong/too many components

machine halts.

Wrong Functionality of machine 1

1 st Component enters 2nd Component enters stop Switch on assemble eject

«extends»

«extends»

«extends»

M1: Machine

generalisation

Machine is the system that contains the use

cases therefore it is not an actor that uses it

Generally we do not depict multiplicity on use

case diagrams

What interacts with Machine 1?

Belt

Belt

Belt

Component1…

Component2…

Component3..

Assembly1…

Worker

These may be thought

of as external to the

machine sub-system

and therefore actors

interacting with the

machine

What would that look like on a state chart of Machine 1

(from power on to power off)

Analysing Runniing Awaiting Component Can Eject (^) CanAssemble Error Awaiting C Awaiting C PowerOn() H^ Accept(C1) PowerOff() SetSpeed() Accept(C2) Accept(C1) Accept(C2) Halted (^) Halt() Accept(C1) Accept(C2) Assemble(C1,C2):Component B3.add(A1:Component) PowerOff() Halted

What does that tell us about a

class diagram?

Machine

• waitComponent:State
• WaitC1:State
• (^) WaitC2:State
• (^) Error:State
• (^) Halted:State
• (^) CanAssemble:State
• (^) CanEject:State
• (^) Powered:State
• (^) C1:Component
• (^) C2:Component
• (^) B3:Belt
• (^) Speed:int
• (^) A1:Component
• (^) MachiningCost:Number
• Halt()
• (^) Assemble(Component,Component): Component +Accept(Component) +PowerOn() +PowerOff() +SetSpeed() +Simulate()

Component

Belt

-id:ID +add(component)

Worker

-id:ID Assembles► ◄SetsUp -id:ID Supplies► (^1) ◄ Supplies 1 (^2 )

1

Add code (or pseudo code)

Sub Simulate()

select case state

case canAssemble

A1 = new component(C1,C2,Cost)//replaces assembleComponent(C1,C2)…

C1 = null

C2 = null

State = canEject

case canEject

B3.add(A1)

A1 = null

state = awaitingComponent

end select

End sub

WRONG Why?

From State chart

From Sequence diagram

From Sequence diagram

Add more code

Sub Accept(C:Component) if state = awaitingComponent then if C.type = C1Type then C1 = C State = awaitingC else //assumes we can only receive 2 types C2 = C State = awaitingC endif else if state = awaitingC1 and C.type = C1Type then state = canAssemble else if state = awaitingC2 and C.type = C2Type then state = canAssemble else message “error: wrong (or too many) components” state = error endif endif endif End sub

 We now have a better understanding of the problem.  We test (walkthrough/roleplay)  Our diagrams are still inconsistent

A good tool:  (^) could ensure consistency  (^) Automate redrawing

Otherwise we must redraw by hand  Now we start again

Analysis… design… implement… test…