• Design is–the creative process of transforming a

problem into a solution (verb)–the description of the solution (noun)

Design

• Design starts from the requirements and transforms them into a working system.

• Required to satisfy two groups when design is produced– Customer’s need to understand what the system

is to do.– System builders must understand how the system

is to work• For this reason we produce a conceptual

design and a technical design

Conceptual Design Technical

Design

System Designers

See Textbook (SWE –TnP – Shari Lawrence PfLeeger)

pg. 225 for this figure

Conceptual Design

• A conceptual design focuses on the systems functions.

• It describes:– system boundary, (what is within and what is not)– entities, (element involved in activity)– attributes, (characteristics of entity) – relationships (among entities and activities)

• Also, it answers the following questions:– Where will the data come from?– What will happen to the data in the system?– What will the system look like to users?– What is the timing of events?– What will the reports and screens look like?

Conceptual

• A good conceptual design should have the following characteristics:

– written in the customer's language– contains no technical jargon– describes the functions of the system– independent of implementation– linked to the requirements documents

Design

The conceptual design enables the customer to understand what the system will do by explaining the observable external characteristics of the system.

Technical Design• Technical design describes

– hardware configuration, – software needs, – communications interfaces,– input and output of the system, – network architecture – anything else that translates the requirements into

a solution to the customer's problem.• It usually includes at least the following:

– a description of the major hardware components and their functions

– the hierarchy and function of the software components

– the data structures and the data flow

Decomposition and Modularity

• Wasserman suggests that designs are created in one of five ways:

– Modular decomposition– Data-oriented decomposition– Event-oriented decomposition– Outside-in design– Object-oriented design

Modular Decomposition

• This construction is based upon assigningfunctions to components.• The designer begins with a high-level

description of the functions that are to be implemented

• and builds lower-level explanations of how each component will be organized and related to the other components

Data-oriented Decomposition

• This design is based on external data structures.

• The high-level description depicts general data structures,

• and lower-level descriptions provide detail on what data elements will be involved and how they are related.

Event-oriented Decomposition

• This design is based on events that the system must handle and uses information about how events change the system's state.

• The high-level description catalogues the various states

• and the lower-level descriptions describe how state transformations take place.

Outside-in Decomposition

• This black box approach is based on user inputs to the system.

• That is, the high-level description lists all possible inputs a user can make,

• then the lower-level descriptions address what the system does with each input (including what outputs are produced).

Object-oriented Decomposition

• This design identifies classes of objects and their interrelationships.

• At the highest level, each object type is described.

• At lower levels, the object attributes and actions are discussed

• the design explains how objects are related to one another.

Decomposition and Modularity

• Thus a design can be derived by working from system data descriptions, events, user inputs, high-level functional descriptions, or a combination,

• and creating a hierarchy of information with increasing detail.

Decomposition and Modularity

Architecture Styles and Strategies

• Shaw and Garlan, suggest that software architecture is also the first step in producing a software design. They distinguish between three design levels:– Architecture– Code design– Executable design

Architecture

• Architecture associates the system capabilities identified in the requirements specification with the system components that will implement them.

• Components are usually modules and the architecture also describes the interconnections among them.

• In addition, the architecture defines operators that create systems from subsystems.

Code Design

• Code design involves– algorithms – data structures such as numbers, characters,

pointers and control thread. • In turn, there are primitive operators,

including– the language's arithmetic and data manipulation

primitives, and– composition mechanisms such as arrays, files and

procedures.

Executable Design

• Executable design addresses the code design at a lower level of detail still.

• It discusses memory allocation, data formats, bit patterns etc.

Strategies

• It is useful to work from the top down, designing– an architecture, – then the code design and – finally the executable design.

• In reality, designers move back and forth from one level to another, as they understand more about the solution and its implications.

• These iterations mean that the designers must work on each level in small chunks as their understanding and creativity permit.

Characteristics of Good Design

• High quality designs should have the following characteristics that lead to quality products:– Ease of understanding– Ease of implementation– Ease of testing– Ease of modification– Correct translation from requirements specification

• Modifiability is especially important since changes to requirements or changes for fault correction, sometimes result in a design change

Software Design Document – (SDD)

Independence of Components

• Reasons for independence of components:– easier to understand how a component works if

it is not intricately tied to others– easier to modify a independent component– helps to isolate and fix cause of a system failure

which is traced back through the code to the design

Good Design – Coupling / Cohesion

• To recognise and measure the degree of component independence in a design we use two concepts:

– coupling

– cohesion

Coupling• Highly coupled

– there is a great deal of dependence between them.

• Loosely coupled – There is some dependence, but the

interconnections among components are weak

• Uncoupled – components have no interconnections at

all– they are completely independent

Coupling

Types of Coupling

• Content– occurs when on component modifies another– modified component is completely dependent

on modifying one– May occur when one component modifies

internal data item in another component– OR when one component branches into the

middles of another component

Example of Content Coupling

Example of Common Coupling

Types of Coupling

Types of Coupling

Cohesion

• Cohesion refers to the “internal glue”(intra-dependence) with which a component is constructed.

• The more cohesive a component, the more related are the internal parts of the component to each other and to its overall purpose.– In other words, a component is cohesive if all

elements of the component are directed toward and are essential for performing the same task.

Types of cohesion

Coincidental

• Worst degree of cohesion• Parts of component are

unrelated to one another• These parts placed for

reasons of convenience

Logical• Next higher level of

cohesion, though still not desirable

• Several logically related function or data elements are placed in the same component

• e.g. one component may read all kinds of input regardless of where input is coming from or how it will be used

Temporal

• Component performs several functions in sequence, but functions are related only by time

• e.g. component used to initialise a system or set of variables

Procedural

• Functions must be performed in a certain order

• e.g. data must be entered before they can be checked and manipulated

Communicational

• Associate functions because they operate on or produce the same data set

• e.g. unrelated data fetched together because the fetch can be done with only one disk or tape access

• Destroys modularity and functional independence of design

Sequential

• The output from one part of a component is input to next part of component

• Possible that component will not contain all of processing related to a function

Functional

• Every processing element is essential to performance of a single function, and all elements contained in one component

• Performs only that function for which it is designed

Control Issues

• We have to decide how many components are under the control of a particular component.

• fan-in is the number of components controlling a particular component

• fan-out is the number of components controlled by a component.

Control example

Faults and Failures

• Fault occurs when a human makes a mistake, called an error, in performing some software activity– Inside view of the system seen by developer

• Failure is a departure from the system’s required behaviour– Outside view of problem user sees

Exception Handling

• We design systems defensively, i.e. we take an active role in anticipating failures before they occur.

• Exceptions are situations that are counter to what we really want the system to do.

• Typical exceptions:– failure to provide a service– providing the wrong service or data– corrupting data

Exception Handling

• For each exception we identify, we can handle it in one of three ways:– Retrying: We restore the system to its previous

state and try again to perform the service using perhaps, a different strategy

– Correct: We restore the system to its previous state, correct some aspect of the system, and try to perform the service using the same strategy

– Report: We restore the system to its previous state, report the problem and do not provide the service

Technical Design

Architectures and Some Examples

Architecture styles

• Pipes and filters• Object-oriented design• Implicit invocation• Layering• Repositories

Pipes and filters• Two components:

– Pipe streams of data for input and output– Filter transforms data from input to output

• Filters are independent– Not aware of the existence or functions of the

system’s other filters

Pipes and filters

Pipes and filters

• Advantages– Designers can understand the entire system’s effects on

inputs and output as the composition of filters– Since any two filters can be linked together, the filters

can be reused easily on other systems– System evolution is simple, because new filters can be

added and old filters removed with relative ease– Because of filter independence, designers can simulate

system behaviour and analyse system properties (such as throughput)

– Allow concurrent execution of filters

Pipes and filters

• Disadvantages– Encourage batch processing, which is not good

for handling interactive applications– When two data streams are related, the system

must maintain a correspondence between them– Independence of filters means that some filters

may duplicate preparatory functions that are performed by filters, thereby affecting performance and making code quite complex

Object-Oriented Design

• This design builds components around abstract data types

• It has two important characteristics:– Object must preserve the integrity of the data

representation– Data representation must be hidden from other

objects (encapsulation)

Object-Oriented Design

• Advantages– Encapsulation makes it easy to change the

implementation without greatly disturbing the rest of the system

– Combining object access routines with the data manipulated by them, encourages designers to decompose the underlying problem into a collection of interacting agents

• Disadvantages– One object must know the identity of the other objects

in order for them to interact

Implicit Invocation• This design is event-driven and based on the

notion of broadcasting– Instead of invoking a procedure directly, a component

announces that one or more events have taken place– Other components can associate a procedure with those

events registering a procedure– System invokes all such registered procedures

• Data exchanged must be done through a shared data in a repository

• In general, when a component or system announces an event, it does not know which components will be affected by the event– For this reason there is usually some explicit invocation

as well

Implicit Invocation

• Advantage– Especially useful for reusing design component

from the other systems• Disadvantage

– Lack of assurance that a component will respond to an event

• The dependence on the context and sequence of events makes it very difficult to test the system and check for correctness

Layering

• Layers are hierarchical• Each layer provides services to the one outside it

and acts as a client to the layer inside it– In some systems, each layer has to access some or all of

the other layers– In other systems, a given layer has access only to

adjacent layers

• Design includes the protocols that explain how each pair of layers will interact

Layering

Layering

• Advantages– Each layer can be considered to be an increasing level

of abstraction, and the designers can use the layers to decompose a problem into a sequence of more abstract steps

– Because there are restrictions on which layers interact with other layers, it is relatively easy to add or modify a layer as the need arises.

• Usually such changes affect only the two adjacent layers

Layering

• Disadvantages– Not easy to structure a system in layers, as

multiple layers of abstraction are not always evident when we examine a set of requirements

– Even when a layered design is created, the system performance may suffer from the extra coordination among the layers

Repositories

• Has two types of components– A central data store– A collection of components that operate on it to store,

retrieve, and update information• The challenge in this design, lies in deciding how

the two types of components will interact• Traditional database the transactions, in the form

of an input stream, trigger process execution• Blackboard the central store controls the

triggering of the process

Repositories

Repositories

• Advantage– Its openness as data representation is often

made available to several vendors so that they can build tolls to access the repository

• Disadvantage– Shared data must be in a form acceptable to all

knowledge sources, even if the knowledge sources themselves are radically different

End of Lesson 5 :: Design

Thank you