software

1. ALPHA BREATHING

2. EVOCATION

3. DESIGN CONCEPTS
Badariah Solemon 2010

4. INTRODUCTION
 Design creates a representation or model of the
software
 Software design encompasses the set of principles,
concepts, and practices that lead to the
development of a high-quality system or product.
 Design concepts must be understood before the
mechanics of design practice are applied

5. 1. ABSTRACTION
Procedural abstraction –
 Sequence of instructions that have a specific and limited
function
 Implies the function but specific details are suppressed
 Example – word “open” for a door
Data abstraction –
 Named collection of data that describes a data object.
 Example – open – “door”

6. DATA ABSTRACTION
door
manufacturer
model number
type
swing direction
type
number
Weight
Height
width

7. PROCEDURAL ABSTRACTION
open
details of enter
algorithm

8. 2. ARCHITECTURE
The overall structure of the software and the ways in which that
structure provides conceptual integrity for a system
Structural properties. defines the components of a system (e.g.,
modules, objects, components, etc..) and the manner in which those
components are packaged and interact with one another.
Extra-functional properties. performance, capacity, reliability,
security, adaptability, and other system characteristics.
Families of related systems. Use of repeatable patterns that are
commonly encountered in the design of families of similar systems.
In essence, the design should have the ability to reuse architectural
building blocks.

9. 3. PATTERNS
 A pattern is a named nugget of insight which conveys the
essence of a proven solution to a recurring problem
 A design structure that solves a particular design problem
within a specific context
 It provides a description that enables a designer to determine
whether the pattern is applicable, whether the pattern can be
reused, and whether the pattern can serve as a guide for
developing similar patterns

10. 4. SEPARATION OF CONCERNS
• Concern – feature or behavior that is specified as a part of
requirements model.
• By separating the concerns (dividing) into smaller pieces, they
can be easily managed/optimized or solved with a less effort.

11. 5. MODULARITY
 Separately named and addressable components (i.e., modules)
that are integrated to satisfy requirements (divide and conquer
principle)
 In all instances, you should break the design into many
modules, hoping to make understanding easier and as a
consequence reduce the cost required to build the software

12. 6. INFORMATION HIDING
 The designing of modules so that the algorithms and
local data contained within them are inaccessible to
other modules
 It is advantageous as the inadvertent errors introduced
during modification are less likely to propagate to other
locations within the software

13. 7. FUNCTIONAL INDEPENDENCE
 Modules that have a "single-minded" function and an aversion to excessive
interaction with other modules
 Cohesion- relative functional strength of a module.
 Coupling- relative interdependence among modules.
 High cohesion – a module performs only a single task
 Low coupling – a module has the lowest amount of connection needed with
other modules
COHESION - the degree to which a
module performs one and only one
function.
COUPLING - the degree to which a
module is "connected" to other
modules in the system.

14. 8. STEPWISE REFINEMENT
 Development of a program by successively refining levels of
procedure detail – process of elaboration
 Complements abstraction, which enables a designer to specify
procedure and data and yet suppress low-level details
open
walk to door;
reach for knob;
open door;
walk through;
close door.
repeat until door opens
turn knob clockwise;
if knob doesn't turn, then
take key out;
find correct key;
insert in lock;
endif
pull/push door
move out of way;
end repeat

15. 9. REFACTORING
 A reorganization technique that simplifies the design (or
internal code structure) of a component without changing its
function or external behaviour
 Removes redundancy, unused design elements, inefficient or
unnecessary algorithms, poorly constructed or inappropriate
data structures, or any other design failures

16. 10. ASPECTS
 Set of concerns is uncovered which includes
requirements, use cases, data structures, quality service
issues, etc.,.
 It is important to identify aspects so that the design can
properly accommodate them as refinement and
modularization to occur.

17. 11. OO DESIGN CLASSES
 Refines the analysis classes by providing design
detail that will enable the classes to be implemented
 Creates a new set of design classes that implement a
software infrastructure to support the business
solution

18. 12. DESIGN CLASSES
 User interface classes – define all abstractions necessary for
human-computer interaction.
 Business domain classes – refined from analysis classes; identify
attributes and services (methods) that are required to implement
some element of the business domain
 Process classes – implement business abstractions required to
fully manage the business domain classes
 Persistent classes – represent data stores (e.g., a database) 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 the outside world

19. CHARACTERISTICS OF “WELL-FORMED”
DESIGN CLASSES
 Complete and sufficient
 Contains the complete encapsulation of all attributes and
methods that exist for the class
 Contains only those methods that are sufficient to achieve the
intent of the class
 Primitiveness
 Each method of a class focuses on accomplishing one service
for the class

20. CHARACTERISTICS OF “WELL-FORMED”
DESIGN CLASSES
 High cohesion
 The class has a small, focused set of responsibilities and
single-mindedly applies attributes and methods to
implement those responsibilities
 Low coupling
 Collaboration of the class with other classes is kept to an
acceptable minimum
 Each class should have limited knowledge of other
classes in other subsystems

21. MIND MAP

22. SUMMARY • DesignConcepts
– Abstraction
– Architecture
– Patterns
– Separation of Concerns
– Modularity
– Information Hiding
– Functional Independence
– Refinement
– Aspects
– Refactoring
– Object-Oriented Design Concepts
• Types of design classes
• Characteristics of “well-formed” design class

23. Stimulating Question
• Suggest any three additional design concepts.