Ch:8 Design Concepts S.W Design should have following quality attribute: –Functionality...

Ch:8 Design Concepts

•S.W Design should have following quality attribute:

–Functionality –Usability –Reliability –Performance –Supportability (extensibility, adaptability, serviceability)

Design Concepts Abstraction• At the highest level of abstraction, a solution is stated in

broad terms using the language of the problem domain• At the lower level of abstraction, a more detailed

description of the solution is provided• Procedural abstraction refers to a sequence of

instructions that have a specific and limited function• Data abstraction is a named collection of data that

describes a data object. The data abstraction for any data object would encompass a set of attributes that describes the object

• Eg. Open the Door – process, door is an data object

Architecture• Architecture is the structure or organization of program

components (modules), the manner in which these component interact, and the structure of the data that are used by the components

• A set of properties that should be described as part of an architectural design :– Structural properties : This aspect of the architectural design

representation defines the components of a system and the manner in which those components are packaged and interact with one another

– Extra-functional properties : The architectural design description should address how the design architecture achieves requirements for performance, capacity, reliability, security and other system characteristics.

– Families of related system : The architectural design should draw upon repeatable patterns that are commonly encountered in the design of families of similar systems

• The architectural design should be represented using one or more number of different models.– Structural model:- represents architecture as an

organized collection of components– Framework:- identifies repeatable architectural

design frameworks that are encountered in similar types of applications

– Dynamic:- indicates how structure / system may change as function of external events

– Process:- focuses on the design of the business or technical process that the system must accommodate

– Functional model:- can be used to represent the functional hierarchy of system

• ADL (Architectural Description Language) is developed to represent these models

Pattern

• A design pattern can describes a design structure that solves a particular design problem within a specific situation and accompanied by “forces” that may have impact on the manner in which the pattern is applied and used

Separation Of Concerns• Separation of concerns suggests that any

complex problem can be more easily handled if it is subdivided into pieces that each can be solved and/or optimized independently

• By separating the concerns into smaller, a problem takes less effort and time to solve

• This leads to a divide-and-conquer strategy

Modularity• Software is divided into separately named and

addressable components , called modules ,that are integrated to satisfy problem requirements

• Monolithic software, large program composed of a single module, can not be easily grasped by software engineer

• No of modules increases - cost of effort decreases

• No of modules increases – cost associated with integrating modules also grows

• figure

Information Hiding

• Hiding implies that effective modularity can be achieved by defining a set of independent modules that communicate with one another only that information necessary to achieve software function

• Benefits modification

Functional Independence

• Development of modules with “single-minded” function

• each module addresses a specific subset of requirements and has a simple interface when viewed from other parts of program structure

• easier to develop and easier to maintain

• Independence is assessed using two qualitative criteria : cohesion and coupling

• Cohesion– Modules should carry out a single processing

function– Highly related elements should be in the same

module

• Coupling– Indication of relative interdependence among

modules– One module should have little dependence on

any other module– Loose coupling minimizes the

interdependence between modules

• Low coupling facilitates high cohesion

Refinement• top-down strategy• A program is developed by successively refining

levels of procedural detail• We begin with a statement of the function that is

defined at high level of abstraction• That is , the statement describes functions or

information conceptually but provides no information about internal workings of the function or the internal structure of the data We then elaborate on the original statement, providing more and more details as each successive refinement occurs

Aspects • As requirements analysis occurs, a set of

“concerns” is uncovered• As design begins, requirements are refined into

a modular design representation• An aspect is a representation of crosscutting (i.e.

requirement B can not be satisfied without taking A into account) concerns

• In an ideal context, an aspect is implemented as a separate module

Refactoring • It is the process of changing a s.w system in such a

way that it does not alter the external behavior of the code yet improves its internal structure

• When the s/w is refactored, the existing design is examined for redundancy, unused design elements, inefficient or unnecessary algorithms, poorly constructed or inappropriate data structures or any other failure that can be corrected to yield a better design.

Object-Oriented Design Concepts • OO design concepts such as classes and objects,

inheritance, messages and polymorphism among others.

Design Classes• As the design model evolves, we will

define a set of design classes that refine the analysis classes by providing design details that will enable the classes to be implemented, and implement a software infrastructure that supports the business solution

• Five types of design classes :– User Interface Classes define all abstractions

that are necessary for human-computer interaction

– Business Domain Classes identify the attributes and services (methods) that are required to implement some element of the business domain

– Process Classes implement lower-level business abstraction required to fully manage the business domain classes

– Persistent Classes represent data stores that will persist beyond the execution of the software

– System Classes implement software management and control functions that enable the system to operate and communicate within its computing environment and with outside world

Characteristics of well formed Design Classes

• Complete and sufficient: A design class should be the complete encapsulation of all attributes and methods that can be expected to exist for a class

• Primitiveness: Methods associated with a design class should be focused on accomplishing one service for the class. Once the service has been implemented with a method, a class should not provide another way to accomplish the same thing

• High Cohesion : – A cohesive design class has a small, focused

set of responsibilities and single-mindedly applies attributes and methods to implement those responsibilities.

• Low Coupling : Collaboration should be kept to an acceptable minimum.– Law of Demeter says that a method should

only send messages to methods in neighboring classes. Means: design classes within a subsystem should have only limited knowledge of other classes.

The Design Model

• The design model can be viewed in two different dimensions

• The process dimension indicates the evolution of the design model as design tasks are executed as a part of the software process

• The abstraction dimension represents the level of details as each element of the analysis model is transformed into a design equivalent and then refined iteratively

• Elements Of Design Model– Data Design Elements– Architectural Design Elements– Interface Design elements– Component-Level Design Elements– Deployment-Level Design Elements

Dimensions of the Design Model

Design Model

Analysis Model

Abstraction D

imension

High

Low

Architecture Elements

Interface Elements

Component Level Elements

Deployment Level of Elements

Data Design Elements• Data design creates model of data /

information that is represented at a high level of abstraction (customer / user’s view)

• This data model is then refined into more implementation specific representations that can be processed by the computer-based system

• At the program component level, the design of data structures and the associated algorithms required to manipulate them is essential to the creation of high-quality application

• At application level, the translation of data model into a database is essential to achieving the business objectives of a system

• At the business level – data mining can be implemented

Architectural Design Elements• It can be derived from three sources: (1) information about the application domain for

the s/w to be built (2) specific requirement model element like

DFDs / Analysis classes, their relationship, collaboration.

(3)availabilty of architectural styles and pattern• The architecture design elements is usually

depicted as a set of interconnected subsystems

• Each subsystem may have its own architecture

Interface Design elements• It tells how information flows into and out

of the system and how it is communicated among components

• There are three important elements of interface design:– User Interface– External Interfaces to other systems, devices,

networks or other producers / consumers of information

– Internal Interfaces between various design components

Component-Level Design Elements

• The component-level design fully describes the internal details of each s.w component

• Activity diagram can be used to represent processing logic

• Detailed procedural flow for a component can be represented using either pseudo code or some other diagrammatic form

• Algorithm structure follows the rule established for structured programming.

• Data structures are usually modeled using pseudo code or programming language to be used for implementation

Deployment-Level Design Elements• The deployment-level design elements

describes how software functionality and subsystems will be allocated within the physical computing environment that will support the software

• During design, a UML deployment diagram is developed and then refined

• Figure (8.7)• Each subsystem will be elaborated to indicate

the components that it implements