Design, Models, and Prototypes

1
Design, Models, and Prototypes

• Chapter 7 Chapter 8

2
Why we need a design?

• Soon after human began to build more and more
  complicated software systems, software engineers
  have learned that the following paradigm is false

specification coding (implementations) testin
g
3
The false paradigm

• When the system you want to build is complicated,
  which requires a lot of programmers to teamwork,
  the false paradigm makes your project
• ineffective and inefficient communications among
  teammates
• unfortunately, system is wrong and it is known
  until system is already completed. Trying to
  correct the problem needs great cost
• architecture is a mess, maintenance becomes a
  nightmare

4
continued

• System correctness is uncertain, the system show
  low reliability
• task loading is unfair
• schedule planning is a joke
• a new crew member joined in the middle takes a
  great amount of time in learning the system that
  is under construction. Old birds are withdraw
  from the projects to help the new crew
• new crew, after spending a significant amount
  time, still have no clues about the system, and
  begins to question his talents and ability, then
  starting looking for another job on 104 Bank.

5

• many years ago, software engineers have found
  that we need to add a stage called analysis and
  design after specifications and before coding
  begins.
• Researches and experiences show that more time
  spent on design and analysis, much less time
  spent on coding and debugging

6
Development effort
Analysis
Design
Coding
Implementation
Maintenance
7
? Early detection of errors
Error found Mar 13
Error found Feb 13
Error occurs Jan 13
Work (person-days)
10
20
Time
Work proceeds at (say) 10 person- days per month
10 person-days of work has been done assuming
the error is not there. Now this must be redone.
If error found this late, 20 person-days must be
redone
8
Development effort 2
Analysis
Design
Coding
Implementation
Maintenance
9

• The development effort 2
• seldom believed by programmers who do not have
  adequate software engineering training

10
Real facts and numbers

• Game industry could be one of the big industry
  which face, endure the problem of software
  engineering.
• it is estimated that billions of dollars (US)
  have been wasted into failed game project by
  inexperienced team.
• inexperienced team
• have talents, smart, good at programming
• have good idea
• however, they failed. Since a game project is no
  longer a one-man or two-mans cooperation.
• a typical game project require more than 10
  people (including graphical artists)
• eg., a programming course for graphical artist

11

• Suppose you have one year schedule
• What do you plan to distribute your time?
• make a guess
• specification (? )
• analysis and design (? )
• coding (?)
• testing (?)

12
An experienced project team schedule

• A distribution (see yellow books of game
  programming)

Testing
Coding
Specs, Analysis Design
one year
13
Why we need to spend so much time on analysis and
design

• The answer is
• complexity
• Simply put, if a software project is not
  complicated, you need not spend too much
• time on analysis and design

14
Learn from other discipline

• Software engineers are not the first kind of
  human to face complexity
• In human history, human in other discipline has
  learned to approach a complicated task carefully

15
History

• While dealing with complex entity, other
  engineering has learned not to learn it by
  building it.
• They approach the complexity cautiously
• Building prototypes and models are two major
  approaches for tackling with something we do not
  understand much

16
Prerequisite (1)

• In other engineering fields
• In aircraft manufacturing, engineering build
  model to test air dynamics in a wind tunnel

NASA's cryogenic wind tunnel simulates flight
conditions for scale models--a critical tool in
designing airplanes.
17
Prerequisite (2)

• In E.E., they always simulate their design
• first before manufacturing

VHDL
18
Prerequisite (3)
Software tools/environment for simulation and
verification of hardware design
19
In hardware world

• In order to get the high assurance of their
  hardware design, simulation may take weeks and
  month to get the result

20
In civil engineering

• A significant amount of efforts is invested in
  planning and design
• They have complicated math tools to compute the
  interaction between building components (????)
• They can compute how much concrete or irons
  should be used to support the building
• They finally draw a blueprint and document these
  analysis.

21
Ok..back to the question

• What is a design?
• A design is an artifact that produced
• by the analysis and design
• ??????????
• In software engineering, a design can be
• a design document
• a prototype (a simplified, runnable software)
• a models (architecture model, object-oriented
  models, etc.)
• a design document combined with prototype and
  models

22
How design is used ?

• Design can be used as a reference
• Design can be used as a blue print
• Design can be used as the initial version of the
  systems, allowing programmers to build system on
  top of it. (to be the base of evolutionary
• Design can be used to evaluate system properties
  before real system is built
• Design can be used to validate users
  requirements
• Design can be used to avoid risks

23
Prototype (1st kind of artifacts in design)

• a prototype can be tried and tested
• e.g., properties such as UI usability is
  difficult to gather in labs
• a prototype can be used to validate the idea
• e.g., you are aware the danger of writing
  multithreading and networking program. You want
  to try if a certain design can avoid the troubles
  before real coding begins

24
Concept car

• Concept car in automobile manufacturing
• Car manufacture always build prototype to demo
  and evaluate their new ideas.

A concept car or show car is a car prototype made
to showcase a concept, new styling, technology
and more. They are often shown at motor shows to
gauge customer reaction to new and radical
designs which may or may not have a chance of
being produced.
25
The purpose of a concept car

• show case a concept, styling, and technology
• gauge customer reaction to new and radical
  designs
• collect useful data about customers usability

26
Prototyping objectives

• There are two kinds of prototyping
• The objective of evolutionary prototyping is to
  deliver a working system to end-users. The
  development starts with those requirements which
  are best understood.
• The objective of throw-away prototyping is to
  validate or derive the system requirements. The
  prototyping process starts with those
  requirements which are poorly understood

27
Evolutionary prototyping

• Must be used for systems where the specification
  cannot be developed in advance e.g. AI systems
  and user interface systems
• Based on techniques which allow rapid system
  iterations
• Verification is impossible as there is no
  specification. Validation means demonstrating the
  adequacy of the system

28
Evolutionary prototyping

• Specification, design and implementation are
  inter-twined
• The system is developed as a series of increments
  that are delivered to the customer
• Techniques for rapid system development are used
  such as CASE tools and 4GLs
• User interfaces are usually developed using a GUI
  development toolkit

29
Prototyping to an extreme

• If your project proceeds in a way that
  continuously deliver more and more complicated
  prototypes to the users, your process is called
  incremental development
• System is developed and delivered in increments
  after establishing an overall architecture
• Requirements and specifications for each
  increment may be developed
• Users may experiment with delivered increments
  while others are being developed. therefore,
  these serve as a form of prototype system
• Intended to combine some of the advantages of
  prototyping but with a more manageable process
  and better system structure

30
Q What is the advantages of incremental
development using prototyping?

• rapid delivery
• user engagement in the beginning

QWhat kind of applications is suitable for
incremental development?

• for systems where the specification cannot be
  developed in advance e.g. AI systems and user
  interface systems
• Verification is impossible as there is no
  specification. Validation means demonstrating the
  adequacy of the system
• e.g., your boss has an idea of e-??, no body has
  built that kind of system before, and you ask
  each staff in school, no one has clear idea what
  it is.

31
Incremental development process
32
Throw-away prototyping

• The prototype is meant to be thrown-away after
  needed data is collected.
• what kind of data is collected?
• usability (is user happy about the layout?)
• user requirements (is this really what user
  want?)

33
Throw-away prototyping

• User Interfaces prototyping
• fast UI prototyping with VB (visual programming)
  and some dummy code is added
• proceed UI usability test with the prototype
• make the change to the prototype
• rewrite the whole UI with VC

34
Throw-away prototyping
35
Various Software Prototyping Tools
a rapid application prototyping tool for
designing and developing Windows applications.
36

• Visual Basic (a good tool for UI prototyping)

37
Summary

• Prototyping
• build some things executable rapidly to test out
  some ideas and collect feedbacks from customers
  or collect system properties from the prototypes

38
Problems with prototyping !

• A design process may decide to build a
  prototypes but prototypes
• cannot validate non-functional requirements.
  e.g. 1, a network game which is capable of
  serving 10000 users online e.g. 2, Can an
  elevator system open its door while elevator is
  moving?
• e.g.,3 Is a network game secure for hacker?

39

• For many applications, building prototypes is
  equal to build system after all, the line between
  prototyping and constructing a system is blurred.
  
• e.g., the story of ?????Many applications
  simply cannot test out properties on a simplified
  prototype !Prototyping is not possible in the
  development

40
What else for software design?

• Models
• (2nd kind of design artifact)

41

• Again, lets recall the aircraft design
• When you want to try if a design of aircraft show
  good quality in air flow, you build a
• modelin woods, which
  cannot fly to the sky. You wont call it
• prototype

42
Model and Prototypes

• Model is design or the results of design
• prototype is a design or the results of design
• In aircraft manufacturing, because of the
  complexity, the design process includes
• Models
• model for the wind tunnel to test high speed wind
  air dynamics
• models in CAD
• Prototypes
• small model airplane to test landing and weight
  distribution
• real prototype for real test fly but without
  expensive electronic equipments

43
The characteristics of a model

• a model
• is not a executable system
• can be operational or non-operational
• can be used to test out some system properties
• can be used as a blueprint for implementation
• can be

44
What is a software model?

• A software model is
• Abstract descriptions of systems whose
  requirements are being analysed

45
Software Model Examples

• Architecture model
• ..\..\modules\architecture in UML-client.vsd
• Flow Chart

46
Software Model Examples

• Flow Chart

47
Non standard Flow Chart
48
Software Model ExamplesFinite-state models
49
Again - What is a software model?

• A software model is
• Abstract descriptions of systems whose
  requirements are being analysed
• It can be used to guide coding, avoid
  miscommunications, and relieve programmers from
  requirement chaos
• programmers do not need to figure things out from
  a pile of specifications and requirement.
• They can simply follow design for coding.
  Thinking can be greatly reduced. So that coding
  can be speeded up.

50
What is a design document

• ..\..\..\..\ypc-projects-schedule\diva\documents\d
  esign\DIVA Design v0.4.2.doc

51
What a design document consists of?

• Scenarios
• text descriptions
• models (architecture models, object-oriented
  models, etc. )
• Pseudo code and algorithm
• high level data structure
• definition of module, subsystem interfaces.

52
Modeling

• The process to analyze the requirement and
  specification, decide how to approach the
  applications, and then plot the models is called
  modeling (??)
• model can be the major component in a design
  document.

53
essence of models

• since a model is an abstract description of
  systems, in principle, models can be
• text based (pseudo code)
• diagram based (???,???)
• Most modern models are diagram based because a
  picture worthy a thousand words.

54
Classification (Types) of models

• Context Models (static properties)
• Architecture Models
• Behavioral Models (dynamic properties)
• Data Flow Diagram
• State Machine Diagram
• Object Models
• UML diagrams
• Data Models

55
The context of an ATM system
56
Behavioural models

• Behavioural models are used to describe the
  overall behaviour (dynamic behavior) of a system
• Two types of behavioural model are shown here
• Data processing models that show how data is
  processed as it moves through the system
• State machine models that show the systems
  response to events
• Both of these models are required for a
  description of the systems behaviour

57
Data-processing models

• Data flow diagrams are used to model the systems
  data processing
• These show the processing steps as data flows
  through a system
• Intrinsic part of many analysis methods
• Simple and intuitive notation that customers can
  understand
• Show end-to-end processing of data

58
Order processing DFD
59
Data flow diagrams

• DFDs model the system from a functional
  perspective
• Tracking and documenting how the data associated
  with a process is helpful to develop an overall
  understanding of the system
• Data flow diagrams may also be used in showing
  the data exchange between a system and other
  systems in its environment
• DFD models are most suitable for MIS applications

60
CASE toolset DFD
61
State machine models

• These model the behaviour of the system in
  response to external and internal events
• They show the systems responses to stimuli so
  are often used for modelling real-time systems
• State machine models show system states as nodes
  and events as arcs between these nodes. When an
  event occurs, the system moves from one state to
  another
• Statecharts are an integral part of the UML

62
Microwave oven model
63
Statecharts

• Allow the decomposition of a model into
  sub-models (see following slide)
• A brief description of the actions is included
  following the do in each state
• Can be complemented by tables describing the
  states and the stimuli

64
Microwave oven operation
65
Object models

• Natural ways of reflecting the real-world
  entities manipulated by the system
• More abstract entities are more difficult to
  model using this approach
• Object class identification is recognised as a
  difficult process requiring a deep understanding
  of the application domain
• Object classes reflecting domain entities are
  reusable across systems

66
The Unified Modeling Language (UML)

• Devised by the developers of widely used
  object-oriented analysis and design methods
• Has become an effective standard for
  object-oriented modelling

67
An brief introduction of UML

• ????????????????????????????????
• ???????,???????????????
• Use case diagrams
• Class diagrams
• Object diagrams
• Sequence diagrams
• Collaboration diagrams
• Statechart diagrams
• Activity diagrams
• Component diagrams
• Deployment diagrams

68
Use Case Diagram
69
class diagram
70
Sequence diagram
71
Collaboration diagram
72
state chart
73
Activity diagram
74
package and object diagram
75
Component and deployment diagram