Download ppt - Design - Architecture CS-300 Fall 2005 Supreeth Venkataraman

Design - Architecture

CS-300 Fall 2005

Supreeth Venkataraman

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


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


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


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


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


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


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


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


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.


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


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?)


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.


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?


The Design Process

RequirementsArchitecture

(identify subsystems and modules)

Specify details of subsystems

Specify and design modules

Code


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.


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”


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


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.


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


Functional DecompositionCalculator

Input Process Output

Accept Validate Add Subtract Multiply Divide Display


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)


Temporal Decomposition

Input

Accept Validate

Process

Add Subtract Multiply Divide

Output

Display


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


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…


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” ?


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.”


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.


Traceability matrix for calculator (High-Level)

[1] Input [2] Input, Process [3] Input, Process [3a] Input, add … [4] Input [5] Input, Output [6] Output


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?


Which subsystems must communicate?

Input – process ? Input – output ? Process – input ? Process – output ? Output – input ? Output – process ?


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!!


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


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?


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


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?”


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.


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?


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


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 module’s components work towards different goals? (multiple goals within a module)

High cohesion implies simpler interfaces.


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


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


Cohesion and CouplingA

B

C

D

E


Cohesion and CouplingA

B

C

D

E



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.



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.


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?


Make decisions about algorithms This entire process we’ve 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


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