Software Design Concepts and Principles COP 4331 and EEL4884 OO Processes for Software Development © Dr. David A. Workman School of EE and Computer Science

Software DesignConcepts and Principles

COP 4331 and EEL4884OO Processes for Software Development

© Dr. David A. WorkmanSchool of EE and Computer Science

February 23, 2010

February 23, 2010 COP 4331 (C) Dr. David A. Workman

2

References

• Software Engineering: A Practioner’s Approach, 5th ed.By Roger Pressman, McGraw-Hill, 2004,

ISBN = 0-07-365578-3

• Software DesignBy David Budgen, Addision-Wesley, 2003

ISBN = 0-201-72219-4

• Program Development in JavaBy Barbara Liskov with John Guttag, Addision-Wesley, 2001

ISBN = 0-201-65768-6

• Object-Oriented Software Engineering (using UML and Java)By Tim Lethbridge and Robert Lagani’ere, McGraw-Hill, 2001

ISBN = 0-07-709761-0


3

The Design Process[Belady’81] There are two major phases to any design process:1. Diversification: acquiring a repertoire of alternatives, the raw material of

design: component specifications, component solutions, and knowledge – all contained in catalogs, textbooks, and the mind.

2. Convergence: choosing and combining appropriate elements from the repertoire to meet design objectives, as stated in the requirements document and agreed to by the customer. This phase is a gradual iterative process resulting in the elimination of all but one particular configuration of components necessary to create the final product.

Areas of Concern and Focus:• System architecture design (modularity and organization)• Data structure• Interfaces and their representation• Components and their detail (algorithm design)


4

Design Focus AreasArchitectural Design

An enumeration of all the relevant modules (logical organizational units) and components (processing units), their functionality and data processing responsibilities, their inter-dependencies, connectivity and/or communication relationships with other architectural units. Decomposition criteria: functional or object-oriented are the most common approaches to architectural design.

Data DesignAn enumeration of all relevant information (data) elements that must be handled by

the system together with specifying the relationships that must be defined, created and maintained among these elements. Examples: composition, aggregation, association, specialization, generalization, and multiplicity are relationships used in object-oriented design methods.

Interface Design An interface is defined when two or more architectural units must exchange data

with each other or interact in some way. An interface design must specify the data content exchanged, the direction of flow, timing constraints, interaction protocols, and mechanism for communication (e.g., hardware signal, hardware registers, shared variables, data file, database record or relation, gui).


5

Design Focus Areas

Component and Module DesignThis design specifies the internal data structures and algorithms required

for a given architectural unit to satisfy all its interface, functional, and non-functional requirements within a given operation context.


6

Flow of Design DecisionsSystemConcept

1: Customer and users develop a vague and incomplete notion of what the system should/could do to solve their problem.

SystemBoundary

2. Developer and Client capture and formalize system requirements defining precisely what the system will do, and what it will NOT do.

DataData

DataData

FunctionFunctionFunction

Function

FunctionFunction

Use Case Model

DataData FunctionFunction Data

Data FunctionFunctionDataData FunctionFunction

Analysis Model

Design Model

3: Developer and users definewhat data and functions the system must manipulate – theseare organized into use cases.

4: Developer decomposes system into modules and theirinterface relationships – this isarchitectural design

5: Developer designs the internal structure of modules selecting data structuresand algorithms to realize module requirements.


7

Design Models

Invoice Mgmt

InternalComponent

Module Interface:The features that are “visible” toclient code - only these can be usedto exercise the capabilities of the component/module.

Example. Header files (.h) are used in Cto declare types, constants, and functionprototypes that are needed to access systemobjects such as files. In C++, header filesdeclare namespaces and their classes.

DataControl

DataData

ExternalComponent

IO

UML notation for a“package” – packages can denotesubsystems or any other type of“module” the designer wishes torepresent.

UML notation for a“analysis objects/classes” –

Module Implementation:Detailed design activitiesspecify how a module isorganized internally to provide the capabilitiesoffered via the module interface. Example. Implementationfiles in C (.c) or C++ (.cpp) encapsulate the bodies of functions.


8

Design Principles• A good designer should consider alternative approaches.

– Each alternative should be judged with respect to stated requirements.– Each alternative should be judged with respect to resources required for the

solution and resources available to do the job.– Each alternative should be judged with respect to the design properties that affect

design quality (presented later).• A good design is traceable to the Analysis Model and to Software

Requirements (Use Case Coverage Table & Traceability Matrix)• A good designer will not “re-invent the wheel”

If a good design exists and can be reused from some other source, then do not re-design the solution. Time and money are always in short supply. A good software engineer will always look for a ready-made solution before developing a new one.

• A good design should minimize “intellectual distance” between the software and the real world problem it is designed to solve.

This is one of the most important benefits of the object-oriented approach to design. We will be emphasizing this point throughout the course.


9

Design Principles• The design should exhibit uniformity and integration.

– It should appear as if “one person” developed the entire system. There should be a well-defined set of coherent principles and rationale that guide design decisions throughout the system development. The description of the system uniformly should follow certain defined standards for style, format, and organization everywhere they could apply.

– Interfaces between components should be documented completely and clearly using a consistent style and presentation format.

• The design should be structured to accommodate change.Again, the object-oriented approach tends to yield designs that satisfy this principle.

• A good design should be resilient to errors and handle them “gracefully” when they do occur.

• Design should be assessed for quality as it is being constructed, not after the fact.

• A design should be reviewed to minimize conceptual errors.Focus on omissions, ambiguity, and inconsistency before worrying about the syntax

of the design model.


10

Design Principles• Design is not coding and coding is not design!

– The level of abstraction in the design model is well above that of the code. A good designer thinks at an abstract level, not in terms of how the code will look.

– Design decisions that are appropriate during coding should only effect the choice of local data and algorithms used to implement a module and its interface – they should not impact the modularity of the system, nor impact their interface design.


11

Design Styles

IncreasinglyObject

Oriented

IncreasinglyFunctionalOriented

Functional-(Monolithic)

Functional+

OO-

OO+

The progression from pure functional decompositionto pure object-oriented decomposition depends on increasing the following properties:• the degree of abstraction (procedural and data)• the degree of data encapsulation• the degree of information hiding• the degree of distributed control• the degree of reusability


12

Functional Decomposition

F1

F2

F3F4

F5

F6

System modules are defined around system functions. Data is passed as parameters and returned as results.Persistent data is shared by defining global storage areas either in memory or on some external medium.Data types are limited to those provided by the implementation language and are typically are primitive.

DataA

DataB

DataC

DataD

DataE

DataA

DataA

DataB

DataD

DataD

DataE

DataE Data

C


13

Object-Oriented Decomposition

A

B

C

E

D

System modules are defined around problem data encapsulated with the operations that are specific to thatdata. All data encapsulated by an object persists beyond the operations that manipulate it. Objects maydefine new types.

Methdf3

Methdf3

Methdf1

Methdf6

Methdf1

Methdf1

Methdf2

Methdf5

Methdf5

Methdf6

Methdf2

Methdf4

Methdf4


14

Design Properties• Abstraction

The frame of mind and set of concepts that permit the designer to reason about the problem and its solution at some level of generalization that disregards irrelevant details – it organizes the problem and its solution into a hierarchy of concepts, entities and their logical relationships.

Problem Domain

Solution Domain

Concept Concept Concept Concept

Concept Concept

Concept Concept

Concept

Concept Concept Concept

Concept

Concept

Concept

Concept

Concept Concept Concept

Concept Concept

Highest Level

Lowest Level

Level 1

2

3

4

5

Requirements

Architecturaldesign

Algorithmdesign

Analysis

Code


15

Design Properties• Abstraction (continued)

Procedural abstraction: assigning a name, perhaps with defined parameters, to awell-defined and reusable computational process or algorithm. This allows the designer to reason in terms of inputs and results of the named computation without having to think about the details of how the computation will be accomplished or implemented.

Example. “Functions in C” and “macros in C” can be used to implement procedural abstractions of design; “methods in Java”.

Data abstraction: assigning a name (new type) to a collection of similar data values and a set of operations for manipulating those values. This allows the designer to treat as one conceptual unit a data structure and the procedural abstractions that manipulate that structure without having to worry about the details of how the data structure and its operations will eventually be implemented.

Example. “Dialog Box” = { frame, title, label, button, text field } + { open, close, insert character, delete character, append character, display field, erase field }.“Classes and Interfaces in Java”


16

Design Properties• Modularity

A “module” is a separately named and addressable software unit that encapsulates and abstracts a set of related software capabilities and features. A module consists of an interface – for access by other modules – and an implementation – that specifies how the capabilities and features are realized in the implementation.

– Modules permit programs to be designed, implemented and tested in an incremental fashion.

– They provide a mechanism for managing software complexity and shortening the “conceptual distance” between the problem and its solution.

– They provide a mechanism for creating layers of reusable software abstractions that build on one another enabling the designer to compose and configure them in different ways to create solutions to a broad family of problems.

– They provide a mechanism for managing and localizing changes to software when new requirements become known or errors are discovered.


17

Design Properties• Data Encapsulation

Organizing and modularizing the program around distinct, program-defined data types or structures; that is, encapsulating a data type or structure by defining a separate module that contains the declarations necessary to define the type or data structure together with all the program operations (functions) that manipulate the type. Data Capsules ought to contain all and only those operations for which knowledge of the representation is necessary to perform their function.

• Information HidingExploiting language mechanisms and encapsulation techniques to hide details about the

representation of data structures and types for the purpose of making it increasingly difficult, if not impossible, for clients of a data type or structure to directly access and manipulate the internal content or composition of that type or structure. A “client” is any program component that has no need to know or directly use the internal representation of a type or structure.

• Distribution of ControlComputation control, like the internal representation of data types and structures, should be

distributed among components to promote maintainability and performance of individual system components, as well as of the system as a whole. This also promotes reusability.


18

Design Properties

• ReusabilityOrganizing the modular design around components that have a high potential for

reuse in other applications. Reusability is generally achieved by designing components that have one or more of the following properties or characteristics:

– Well-defined interface: making public all and only those component features that are necessary for its use.

– Generality: parameterizing the component’s design to broaden to the contexts in which the component will function correctly, without greatly sacrificing other qualities of good design (e.g performance).

– Portability: designing a component to be function correctly on a variety of hardware platforms and operating environments.

– Interoperability: designing a component to interact through a uniform interface with a variety of external programs that may have been written in different languages and may be running in different operational environments.

Documents

Software Design Concepts and Principles COP 4331 and EEL4884 OO Processes for Software Development © Dr. David A. Workman School of EE and Computer Science