design concept in software engineering

8/12/2019 Design Concept in software engineering

1/14

Design Concepts and Principles

Instructor: Dr. Jerry Gao


2/14

Design Concepts and Pr inciples

Jerry Gao, Ph.D. Jan. 1999

- Software design and software engineering

- Design process

- Design pri ncipl es

- Design concepts

- Abstraction, ref inement, modul ari ty

- Software architecture

- Control hierarchy

- Structural partitioning

- Data structur e

- Software procedure

- I nformation hiding

- Effective modular design

- Functi onal dependence, cohesion, coupl ing- Design heur istics for effective modulari ty

- Design model

- Design documentat ion


3/14

Software Design and Software Engineer ing

Design -> The first step in the development phase for any engineered product.

I t serves as the foundati on for al l software engineering and software

maintenance steps that follow.

The goal of a designer is to produce a model (or representati on) of an enti ty

that will later be buil t.

I npu t of software design: Req. analysis models and specif ication doc.

Output of software design: Design models and design specif ication doc.

Design - translates the requirements into a completed design model for a

softwar e product.

- provides the representat ions of software that can be assessed for

quality.

Figure 13.1


4/14

Software Design

A number of design methods can be used to produce software design:

- Data design: transforms the information domain model into data structur es.

- Architecture design: defines the relationship among major structural elements

of the program.

- I nterface design: describes how the software communicates with users.

- Procedure design: transforms structural elements of the program archi tecture

into a procedural description of software components.

The evolut ion of software design:- Modular program construction[DEN73] and top-down refi ning methods[WIR71].

- Structured programming [DAH71, M IL72].

- Translation of data fl ow/data structure in to a design defi ni tion.[JAC75][WAR74].

- Object-ori ented approach [JAC92][GAM95].

Common features of software design methods:

- A mechani sm for translation of an analysis model into a design representat ion

- A notation for representing functional components and their interfaces

- Heur istics for refi nement and parti tioning

- Gui del ines for qual i ty assessment


5/14

Design Process

Software design --> an i terati ve process thr ough which requirements are

translated into a blueprint for constructing the software.

The design is represented at a high level of abstraction. As design iterations

occur, subsequent ref inement leads to design representation at much lower

levels of abstraction.

Design qual i ty is very importan t. Two methods are used to check the qual i ty:

a) formal techni cal reviews, and b) design walk thr oughs

McGlaughlins [McG91] three common features of a good design:

- The design must implement al l of requi rements (expl icit/impli cit)

- The design must be readable and understandable

- The design should provide a complete picture of the software in

the aspects of data, functions, and behaviors.


6/14

Design Qual i ty

To evaluate a software design, a design qual i ty cri teria can be used.

Here is the guidel ine for a good design:

- A design should exh ibit a hierarchi cal organi zation about software

- A design should be modular based on logical par ti tion.

- A design contains both data and procedural abstractions.

- A design should leads to modul es with i ndependent functional features.

- A design should l eads to simpl i f ied interfaces between modules.

- A design should be derived using a r epeatabl e method

Software design process encourages good design th rough the appl ication of

fundamental design principles, systematic methodology, and through reviews.


7/14

Design Pr inciples

David [DAV95] suggests a set of pr inciples for software design:

- The design process should not suffer from tunnel vision.

- The design should be traceable to the analysis model.

- The design should not reinvent the wheel.

- The design should minimize the intellectual distance between the

software and the problem i n the real world.

- The design should exh ibi t uni formity and integration.

- The design should be structured to accommodate change.

- The design should be structured to degrade gently.

- Design is not coding.

- The design shoul d be assessed for qual i ty.

- The design should reviewed to min imize conceptual errors.

Ex ternal qual i ty factors: observed by users.I nternal qual i ty factors: important to engineers


8/14

Design Concepts

- Abstraction:

Each step in the software engineeri ng process is a refi nement in the level of abstraction of

the software solu ti on.

- Data abstractions: a named col l ection of data

- Procedural abstractions:

A named sequence of instructions in a specif i c function

- Control abstractions:

A program control mechanism without specifying internal detai l s.

- Refi nement: Refi nement i s actual l y a process of elaboration.

Stepwise refinement is a top-down design strategy proposed by Ni kl aus [WI R71].

The archi tecture of a program is developed by successively refi ning l evels of

procedural detai l .

The process of program refi nement i s anal ogous to the process of refi nement

and parti tioning that i s used du ri ng requi rements analysi s. The major di fferencei s in the l evel of implementation detai l, instead of the approach.

Abstraction and refi nement are compl ementary concepts.

Abstraction enabl es a designer to specif y procedure and data w/o detai l s.

Refi nement helps the designer to reveal low-l evel detai ls.


9/14

Design Concept - Modulari ty

The concept of modulari ty has been espoused for almost four decades.

Software is di vi ded in to separately named and addressabl e components, called modules.

Meyer [M EY88] defi nes fi ve cri teri a that enabl e us to eval uate a design method wi th respectto i ts abi l i ty to defi ne an effective modul ar system:

- Modular decomposabil ity:

a design method provides a systemati c mechani sm for decomposing the problem

into sub-problems --> reduce the complexity and achieve the modulari ty

- Modul ar composability:

a design method enabl es existing design components to be assembled into a new

system.

- Modular understandabili ty:

a module can be understood as a standal one un i t it w i l l be easier to bu i l d and

easier to change.

- Modular continui ty:smal l changes to the system requi rements resul t in changes to i ndividual

modul es, rather than system-wide changes.

- Modul ar protection:

an aberrant condi tion occurs wi thin a module and i ts effects are constrai ned

wi thin the module.


10/14

Software Architecture

Software archi tecture is the hi erar chical structure of program components and thei r

interactions.

Shaw and Garl an [SHA95a] descri be a set of properti es of architecture design:

- Structural properti es:

The archi tecture design defines the system components and thei r interactions.

- Extra-functional properti es:

The archi tecture design shoul d address how the design architecture achieves

requi rements for performance, capaci ty, reli abi li ty, adaptabi li ty, securi ty.

- F amil i es of related systems:

The archi tecture design shoul d draw upon repeatabl e pattern s in the design

of fam i li es of simi lar systems.

F igure 13.3.


11/14

Di fferent architectural design methods: (F igure 13.3)

- Structural models: represent archi tecture as an organized coll ection of components.

- F ramework models: increase the level of design abstraction by identi fyi ng repeatable

archi tecture design frameworks (patterns)

- Dynamic models: address the behavi or aspects of the program archi tecture

- Process models: focus on the design of the business or technical process

- F uncti onal models: can be used to represent the functional hierar chy of a system

Software Architecture

Fan-out

Fan-in

Control H ierarchy


12/14


13/14

Ef fective Modular Design

I nformation hiding:

Modul es shoul d be specif ied and designed so that the internal detai l s of

modul es shoul d be invi sible or i naccessi ble to other modules.

Major benefi ts: reduce the change impacts in testi ng and maintenance

Functional i ndependence:

Design modules based on i ndependent functional features

Major benefi ts: effective modular ity

Cohesion: a natu ral extension of the information hiding concept

a module may perform a number of tasks.

A cohesive module performs a singl e task i n a procedure wi th l i ttle interactions wi th others.

Goal : to achi eve hi gh cohesion for modules in a system.

Di ff erent types of cohesion:

- coincidental ly cohesive: a set of tasks related to each other loosely

- l ogical connection among processing elements ---> l ogical ly cohesi ve:

- data shar ing among processing elements --> communication cohesion

-order among processing elements --> procedural cohesion


14/14

Ef fective Modular Design

Coupl ing: (F igure 13.8)

A measure of interconnection among modules in a program structure.

Coupl ing depends on the interface complexi ty between modules.

Goal : to stri ve for lowest possibl e coupl ing among modules.

Good coupl ing ---> reduce or avoid change impact and r i pple effects.

---> reduce the cost i n program changes, testi ng, mai ntenance

Types of coupl ing:

- data coupl ing: parameter passing or data interaction

- control coupl ing: share related control logical (for a control data)

- common coupl ing: common data sharing

- content coupl ing: modul e A use of data or control informationmai ntained in another module.

design concept in software engineering

Documents