Design Architecture

1
Design - Architecture
CS-300 Fall 2005 Supreeth Venkataraman
2
Outline

• Introduction
• From Requirements to Design
• Iterative Enhancement
• Stepwise Refinement
• The Design and the Test Plan
• The Design Process
• Architectural Design

3
Introduction

• Design is the process of turning the requirements
  into a form ready to be implemented
• Technical expertise of developers come to the
  fore
• Primary creative activity in software development
• How are we going to solve the problem

4
Introduction

• Design IS problem solving
• The requirements phase helps analyze the problem
• The design phase is when a solution is developed
  for the problem
• Coding is merely the implementation of this
  solution.
• Designers must be well versed in what the
  problem is and also in how to solve that
  problem
• Designers begin by visualizing the architecture
  of the system
• Some requirements constrain design. If high speed
  searches are required, a linked list is not a
  viable data structure. Hash tables might be used
  instead

5
From Requirements to Design

• Design is written by engineers for engineers
• From requirements to design
• Become intimately familiar with each requirement
• Derive functions that must be provided for the
  system to work
• Decide upon data structures
• Identify algorithms needed

6
Identify Functionalities

• Common, needed functions
• This is the set of functions that will be
  implemented
• Any statement in the requirements that begins
  with the software will or the software must
  is very likely a function that needs to be
  implemented
• Or for that matter, use-cases lend themselves to
  function identification

7
Identify data structures

• Major data structures
• Examination of the requirements leads to data
  structure decisions
• Permanent data structures
• More thought and care
• Temporary data structures
• Sometimes data structure decisions can be forced
  because the system may get inputs from another
  system

8
Update test plan

• Adding to the test plan in design
• As design decisions are made, ideas about testing
  them come up
• Record these ideas immediately
• When modules are specified and designed, ideas
  about testing arise too
• These are unit tests (verify that the modules do
  what they are supposed to)
• In the design phase, system level functional
  tests can be refined
• We know how to implement the system. Embellish
  the initial test plan with this information.
• Eg The SSN will be stored in a buffer occupying
  a maximum of 11 characters. Suitable test cases
  would be to
• Check with 11 and 13 character strings
• Hyphen positions
• etc

9
At a bare minimum,

• Decomposition into intellectually controllable
  subproblems
• Further decompose into modules
• Specify the modules (what does this module do?)
• Decide how to implement the modules
• Intellectual control
• Decomposes programming parts uniquely in the
  ideal case

10
Problems of Design

• All the problems associated with system
  requirements
• Requirements can change
• The urge to code first, and then design
• Knowing when to stop.

11
Iterative Enhancement

• Identify the core problem and work with it
• i.e what is the essence of the problem?
• Eg What is the core of E-LIB?
• Design and implement the repository mechanism and
  build everything else around this
• First iteration will have a repository capable of
  storing user data, files etc.
• In the second iteration, we design and add update
  and retrieve capabilities, and integrate it with
  the repository
• And so on
• Iteratively enhance the functionalities

12
Iterative Enhancement

• Iterative enhancement is a good design technique,
  but problems exist
• If we get the core wrong (bad design) what
  happens?
• It might be after enhancing the core that
  problems come to light
• Might need to change both the enhancements as
  well as the core
• Mistakes will be more and more expensive to
  correct as we progress (sound familiar?)

13
Stepwise Refinement

• This is essentially decomposition into a
  hierarchy
• Start at the top where you have the entire system
  that has to be solved
• Break this system into a small group of
  subsystems that will solve the system
• Select each subsystem and further break down into
  components until each component is simple enough
  to be solved on its own.
• The leaves of the hierarchy are essentially
  modules.

14
Stepwise Refinement

• When the level of detail is fine enough,
  functional specifications must be written for
  each component
• These must specify the interfaces and
  communication data structures.
• Test cases must be recorded for each component
• Global data structure decisions can be made in
  the beginning itself
• What is the global data structure for E-LIB in
  concept?

15
The Design Process
16
Architectural Design

• The main purpose of this step is to transform the
  requirements into a high-level architecture.
• All requirements must be allocated to subsystems
  and modules.
• Defines an approach for implementation Serves to
  lay down the foundation for detailed design.
• Architectural design effectively is a high-level
  solution that is further refined in detailed
  design.

17
Architectural Design

• Architectural design involves
• Breaking down the system into subsystems
• Deciding on communication details
• Deciding an interface for each subsystem
• Deciding global data structures
• Handling exceptional situations
• Traceability is maintained to the requirements
  (traceability mappings/matrices)
• Architecture diagrams and the traceability
  mappings are the blueprints of the system

18
Decomposition

• Breaking down the system into components
• Identify all major subsystems
• Decompose the system into subsystems
• Identify further subsystems and decompose
• Decompose till all modules have been identified.
• Many, many ways of decomposing systems

19
Rules for decomposition

• Subsystems should be independent of each other
• Connectivity should be at a minimum between
  subsystems
• Clearly define the subsystems that handle errors.

20
Example A simple calculator

• We wish to design a simple calculator
• 1. The calculator must be capable of accepting
  user input
• 2. The calculator must be able to compute simple
  arithmetic.
• 3. The calculator must perform
• 3a. Addition
• 3b. Subtraction
• 3c. Multiplication
• 3d. Division
• 4. The calculator must validate all inputs before
  operation and will work on integers.
• 5. A simple error message will be displayed by
  the validating unit if the inputs are erroneous
• 6. The calculator must be able to display
  computed results to the user

21
Functional Decomposition
Calculator
Input
Process
Output
Accept
Validate
Add
Subtract
Multiply
Divide
Display
22
Functional Decomposition

• What about functional decomposition?
• Hierarchical
• Much more presentable
• Abstract off communication details
• Intellectual control can be achieved
• We may not know when to stop
• Additional documentation for communication
  details (at least, more than the temporal version)

23
Temporal Decomposition
Input
Process
Output
Display
Accept
Validate
Add
Subtract
Multiply
Divide
24
Temporal Decomposition

• What is the advantage of using temporal
  decomposition?
• Communication details can be embedded in the
  architecture
• Easy to model architecture into pseudocode
• Disadvantage is that the architectural diagram
  could easily get messy.
• Hard to achieve intellectual control
• What lends itself directly to temporal
  decomposition?
• Sequences of use-cases

25
Alternatives

• The very fact that design can be approached in
  many ways suggests alternatives
• Usually architecture styles are chosen based on
  the type of application, but styles can be
  imposed on the process as well.
• It is wise to investigate many architectural
  alternatives and choose the best one.
• Might turn out to be more costly

26
Hey, what about traceability?

• The architecture diagram is an abstract view of
  the system
• Useful for visualization
• The traceability mappings are derived separately.
• What is the traceability mapping for the block
  labeled calculator ?

27
Traceability Matrices

• Traceability matrices map subsystems and modules
  back to the requirements document.
• Traceability matrices are vital to keep the
  design orderly.
• 3a Addition
• They can be organized by either requirements or
  subsystems
• Assign each requirement to as few subsystems as
  possible. Difficult requirements can be
  decomposed into multiple requirements that can
  then be assigned to only a few subsystems.

28
Communications

• We need to decide how the subsystems will
  communicate
• The medium of communications is through unique
  interfaces for each subsystem.
• How do we determine which subsystems need to
  communicate?
• The traceability matrix comes in very handy here.

29
Traceability matrix for calculator (High-Level)

• 1 Input
• 2 Input, Process
• 3 Input, Process
• 3a Input, add
• 4 Input
• 5 Input, Output
• 6 Output

30
Questions

• Is there any data the process subsystem needs
  from the input subsystem?
• Is there any data the output subsystem needs from
  the input subsystem?
• Is there any data the output subsystem needs from
  the process subsystem?
• Is there any data the input subsystem needs from
  the process and output subsystems?
• Is there any data the process subsystem needs
  from the output subsystem?

31
Which subsystems must communicate?

• Input process ?
• Input output ?
• Process input ?
• Process output ?
• Output input ?
• Output process ?

32
Hmmm there are more subsystems

• The input subsystem is made up of
• Accept
• Validate
• The process subsystem is made up of
• Add
• Subtract
• Multiply
• Divide
• The output subsystem is made up of
• Display
• We need to know which part of the subsystem to
  call!!

33
Traceability Matrix (Detailed)

• 1 Accept, Validate
• 2 Accept, Validate, add/sub/mul/div
• 3 Accept, Validate, add/sub/mul/div
• 3a Accept, Validate, Addition
• 3b Accept, Validate, Subtraction
• 3c Accept, Validate, Multiply
• 3d Accept, Validate, Divide
• 4 Accept, Validate
• 5 Accept, Validate, Display
• 6 Accept, Validate, add/sub/mul/div, display

34
How do we get the subsystems talking to each
other?

• Specify an interface for each module and
  subsystem
• What data does the add module require, and from
  which module?
• What type of data is needed?
• Specify the interface
• The interface to the add module must have the
  capability to accept two integers.
• What other questions do we need to ask?
• What about the environment?

35
Interfaces

• External Interfaces
• Interfaces to user
• Interfaces to operating system
• Interfaces to hardware etc.
• Internal Interfaces
• Interfaces to subsystems that are part of the
  system
• Eg The borrow subsystem calls the repository

36
Environment

• It is vital that the environment in which the
  product will operate be identified early and
  should be considered during design.
• Software to read temperature sensors
• Assume that lowest temperature that can be read
  in Florida is -10 F, and is hardcoded in the
  design.
• Then somehow, the software is hooked up with
  sensors in Antarctica.
• No matter how low the temperature is, the
  software might happily display -10F
• What if the temperature outside was -150 F, and a
  rescue team was to be dispatched if the
  temperature fell below -100 F?
• Never assume the environment.
• What happened to the Galloping Gertie?

37
Cohesion and Coupling

• Coupling and cohesion describe the interaction
  between subsystems and within subsystems.
• They give us a way to classify modules and
  subsystems based on their interactions.
• In the ideal situation we want to achieve high
  cohesion and low coupling.
• Let us now see what these terms mean exactly.

38
Cohesion

• Cohesion is a measure of the amount of
  interactions within a module.
• Does every component within the module work
  towards the achievement of a common goal?
• Ideally every component within a module must work
  towards a common goal
• What does this mean exactly?

39
Cohesion

• Let us consider the Accept module
• What is the function of the accept module?
• Accept integers from the user
• Accept operators from the user
• We must strive to ensure that all components
  within the accept module work only towards this
  purpose.
• If we can achieve this, then we have high cohesion

40
Cohesion

• Modules with high cohesion lend themselves
  naturally to the concept of re-use.
• All we need to know is the interface of the
  module.
• What happens if the modules components work
  towards different goals? (multiple goals within a
  module)
• High cohesion implies simpler interfaces.

41
Coupling

• Coupling is a measure of interactions amongst
  modules.
• Ideally we would like to minimize the amount of
  interactions between modules.
• More interactions mean that modules are very much
  dependent upon each other.
• Means more complicated interfaces

42
Coupling

• More interactions also means more communication
  overheads.
• Imagine a situation where every module calls
  every other module.
• What if something inside one module has to be
  changed?
• Does it initiate a change within all other
  modules?
• Most likely given the amount of dependency

43
Cohesion and Coupling
44
Cohesion and Coupling
45
Cohesion and Coupling

• High cohesion and weak coupling help build
  modules that can be
• Designed independently
• Coded independently
• Tested independently
• Integrated with few integration errors
• Re-used
• All we need to know about is the interface to the
  modules.

46
Cohesion and Coupling

• Cohesion and coupling are essentially opposites
• High cohesion automatically implies low coupling
  and vice versa
• How to achieve low coupling?
• Minimize shared common data between modules
• Minimize the number of parameters
• Ensure that change in one module does not lead to
  cascading changes in the modules it communicates
  with.

47
Make global data structure decisions

• During architectural design, it is common to make
  decisions about global data structures
• Global data structures usually define the
  back-end of applications
• These data structures are usually permanent, and
  retain state information even after the program
  has terminated.
• So what global data structure decisions would you
  make for E-LIB?

48
Make decisions about algorithms

• This entire process weve been through is itself
  a big algorithm on its own
• We might need to identify specialized algorithms
  to be used by certain modules.
• For example, module A might sort a set of
  integers, and the decision on what sorting
  algorithm needs to be used has to be made in
  architectural design.
• Decisions about algorithms for modules are a task
  for detailed design

49
Detailed Design A sneak peek

• Detailed design involves
• Specifying each module with a functional
  description
• Making decisions about variables, data types
• Representing each module in a form that can be
  easily implemented.
• We will see detailed design in great detail in
  the next class