Chapter 5 SOFTWARE DESIGN

1
Chapter 5SOFTWARE DESIGN

• Prepared by
• Victor Velez
• Feb 2 2004

2
Introduction

• S.D. is an implementation of allocated
  requirements to computer programs or modules. Can
  be divided into two phases
• Architectural Design
• Determ.the general structure of a system
• Decomposes the system into subsystem
• Specifies interfaces between subsystems
• Detailed Design
• Decomposes the system into modules
• Selec. evalu. and alloc data struct. to impl
• Verifies against the requirements specific.

3
Introduction to Articles

• First paper describes the software engine-ering
  activity of software design.
• Second paper demonstrates several featu-res of
  software engineering as applied to designing
  concurrent and real-time systems
• Third paper Report that design patterns are an
  affective means of capturing and communicating
  soft. desig. experiences
• Fourth paper Define architecture style as
  characterizing a family of systems

4
Introduction to Articles

• Fifth Introduces a discipline that the author
  calls software reliability engineering.
• Sixth Reports that many systems that are deemed
  safety-critical depend on reliability and
  dependability of software
• Seventh Reports without good human-computer
  interfaces,many systems may not be used.

5
Software Design An Introduction

• Author David Budgen
• University of Keele, U.K.

6
The role of software Design

• What exactly is the purpose of design?
• To produce a workable solution to a given
  problem

7
The role of software Design

• The software design process
• Why is it that the task of designing software
  seems to be even more intractable and less well
  understood than others forms of design?
• Complexity of software
• Problem of conformity
• The apparent ease of changeability
• The invisibility of software

8
The role of software Designcont

• The software design processcont
• Where a designer is unfamiliar with the type
  of problem being solved, then should use a
  software design method in
• a procedural manner
• representation part(usual textual in form)
• process part(the procedure to be followed in
  developing the design model)
• set of heuristics(conveying non-procedural
  knowledge, such as quality attributes)

9
The role of software Designcont

• 2. Design qualities
• The qualities(ilities) can be considered to
  describe rather abstract and top-level
  properties of a system, and these are not easily
  assessed from design information alone
• Reliability
• Efficiency
• Maintainability
• usability

10
Describing Designs

• Recording the design model
• The representation form used in softwa-re
  design can be grouped in viewpoints according to
  their purpose
• Behavioral describes the links between
  external events and system activities
• Functional desc. What the syst. Does
• Structural desc. The interdenpenden-cies of
  the components of the system
• Data Modeling desc. Relationships bet-ween
  the data objects used in the syst.

11
Describing Designscont

• Recording the design modelcont
• The previous forms can be used for
• Documenting and exploring the details of the
  design model
• Explaining the designers ideas to others
  (customer, managers, etc)
• Checking for consistency and completeness of
  the design model

12
Describing Designscont

• 2. Design representation forms
• a.Textual descriptions widely used, use
• forms as headings,lists(bullets,number).
  Limitations may be not clear if its form doesn't
  map easily onto lists and tables. Natural
  language is prone to ambiguity, so long and
  complex sequence avoid it.
• b.Diagrammatical desc. Drawing diagra-ms to
  provide abstractions. Properties few
  symbols(circ,arc,lin,box), symbols by
  level(hierarchical structure), simple symbols to
  easy communication of idea

13
Describing Designscont

• c. Mathematical descriptions
• Are ideally suited by the precision that it
  provides but are not necessarily compa-tible with
  the designers need for abstraction.

14
Describing Designscont

• 3. Some examples of design representation
  Diagrammatical notations for the 4 design
  viewpoints
• The statechart models the behavior of
  finite-state machine systems.The hierar-chy of
  states is shown by encapsulating state symbols.
  The state is denoted by a rounded corners box and
  arc(transition)
• Jackson Structure Diagram Describes the
  sequence and ordered structure of an object in
  terms of the three

15
Describing Designscont

• 3. Some examples of design represcont
• The structure Chart represents physical
  entities (subprograms) and the hierar-chy shown
  is one of invocation(transfer of control) rather
  than of abstraction.
• The Entity-Relationship Diagram Is commonly
  used for modeling the details of the
  inter-relationships (symbol dia-mond) that occur
  between data elements in a system.

16
Software Design Practices and Design Methods

• Rationale for software design Methods
• At the present time software design methods
  probably provide the most practical means of
  transferring design knowledge but might be
  inadequate because there are constraints that
  limit their usefulness. Example
• A design method indicates how the design
  model is to be developed but not what to do for a
  given problem.

17
Software Design Practices and Design Methods

• 2. Design strategies
• These are practices of experienced designers
  observed to adapt a strategy adequate to meet the
  needs of the problem

18
Software Design Practices and Design Methodscont

• 2. Design Strategiescont
• Top-Down
• Separating a large problem into smaller ones.
  Disadvant May make important structural
  decisions at early stage.
• Compositional
• Involve entities that can be assembled to
  create a solution model. While earlier stages
  look simple, resultant complex.

19
Design strategies...cont

• Organizational
• Where the needs of the development organization
  and its management structures impose constraints
  upon the design process.
• Template
• Where some general paradigm descri-
  bes a reasonably large domain of pro-
• blems.

20
Features of some Software Design Methods

• Jackson Structured Programming.
• It aims at a very tightly constrained do-main
  of application, hence more pres-criptive in its
  process part, and more useful for localized
  design tasks.
• Structured Systems Analysis and Structured
  Design.
• It is like a top-down approach to design. It
  consists of an analysis(data-flow dia-gram) and
  a design(structural model) component.
  Disadvant has a large and relatively disjoint
  transformation step.

21
Features of some Software Design Methodscont

• Jackson System Development
• Encourages the designer to create a de- sign
  model around the behavior of pro- blems
  entities. These entities gradually will be
  elements of the solution.
• Object-Oriented Design
• Seeks to make extensive use of diagrammatical
  forms, and especially of variations upon the
  Entity-Relationship Diagram.Encourage to make
  decisions about structure at a much earlier
  stage

22
Design Methods for Concurrent and Real-Time
Systems

• Author Hassan Gomaa, 1993
• Department of Information and Software Systems
  Engineering.
• George Mason University
• Fairfax, Virginia

23
Introduction

• This paper discusses and compares the concepts
  used by software design methods for developing of
  concurrent and real-time systems. It is because
  nowadays many consumer products are microcomputer
  based and either software controlled at lower
  cost.
• Starts by describing three key design concepts
  concurrency, modularity and finite state
  machines. Then compares five software design
  methods for concurrent and real-time systems

24
Design Concepts for Concurrent and Real-Time
Systems

• Concurrent Tasks
• System concurrency is obtained by having
  multiple tasks that execute in parallel. From
  time to time, the tasks must com-municate and
  synchronize their operatio-ns with each other.
  Criteria for task stru-cturing have been
  developed to guide a software designer in
  decomposing a real-time system into concurrent
  tasks. The T.S.C. were described in the DARTS,
  later redefined for ADARTS, CODARTS method

25
Design Concepts for Concurrent and Real-Time
Systems

• Modularity
• provides a means of composing a softwa-re
  system into smaller (modules). The principle is
  that each module should hide a design decision
  that is considered likely to change. It means
  that the information hiding modules are
  modifiable and under-standable and hence
  maintainable there-fore have a greater potential
  for reuse than most procedural modules.

26
Design Concepts for Concurrent and Real-Time
Systems

• Finite State Machines
• A finite state machine may be used for modeling
  the behavioral aspects of a real -time system.
  Their actions depend on their inputs and on what
  previously happ-ened in the system, hence the
  system may transition to the same or to a
  differ-ent state. An Output event may be
  optio-nally generated. State transition diagram
  or S.T Tables are used to define it. F.S.M are
  used by several real-time design methods
  including DARTS

27
Survey of Software Design Methods for Concurrent
and Real-Time Systems

• Important objectives for a design method
  concurrent and Real-Time System
• the capability of structuring a system into
  
• concurrent tasks.
• the development of modifiable and reusa-
• ble software using hiding information.
• definition of the behavioral aspects of a
• realtime system using finite state machine
• ability to analyze the design performance
• to determine if it match with requirements

28
1. Real-Time Structured Analysis and Design
(RTSAD)

• develop the system context diagram. It shows
  all inputs and outputs of the system.
• A data flow/control flow decomposition is
  performed which is how the system is structured.
  A data dictionary is develope
• Develop the specification using RTSA integrating
  the state transition diagrams with data flow
  diagram through the use of control
  transformations.
• Allocate transformations to processors

29
1. Real-Time Structured Analysis and Designcont..

• into modules using structured design which uses
  the modularity criteria and Transform and
  Transaction Analysis (design strategies)

30
2. Design Approach for Real-Time Systems (Darts)

• It addresses a key limitation of RTSAD that of
  not adequately addressing task structuring. DARTS
  uses a set of tasks structuring criteria for
  identifying the concurrent tasks in the system
  defining the communication and synchronization
  interfaces between tasks.
• 4. Use structuring criteria to structure the
  system into concurrent tasks identifying the
  concurrent nature of the transform-ations within
  the system

31
2. Design Approach for Real-Time Systems
(Darts)cont

• Thus, a transformation is grouped with other
  transformation into a task. A task architecture
  diagram is drawn showing the tasks identified.
• 5.Interfaces are defined by analyzing the
  previous data/control flow interfaces
• 6.Using the Structure Design method, each task is
  structured into modules

32
Jackson System Development (JSD)

• The design should model reality first before
  considering the functions of the system (real
  world simulator). The func-tions are then added
  to this simulation.
• Phases
• Modeling the real world is identified and
  defined in terms of events
• Network communication and function between tasks
  are defined
• Implementation specifications can be mapped to
  concurrent designs.

33
NRL Method

• To manage the complexity of handling large
  numbers of modules, NRL method organizes
  information hiding modules into a
  tree-structured, information hiding module
  hierarchy and documents them in a module guide

34
Object-Oriented Design

• It is also based on the concept of information
  hiding. An object is an information hiding module
  that has state and is characterized by the
  operations it provides for other objects and the
  operations it uses. The author later extended his
  version of OOD to include classes and inheritance

35

• THANK YOU