The document discusses key design concepts in software engineering including abstraction, architecture, patterns, separation of concerns, modularity, information hiding, refinement, functional independence, aspects, refactoring, object-oriented design concepts, and design classes. It provides details on each concept, their importance in software design, and how they lead to the development of high-quality software.

1. UNIT-4
Design Concepts
1

2. • Software design encompasses a set of
• Principles
• Concepts and
• Practices
That lead to the development of high quality system or product.
2

3. Design
• The goal of design is to produce
• Good software design should exhibit:
• Firmness: A program should not have any bugs that inhibit its function.
• Commodity: A program should be suitable for the purposes for which it
was intended.
• Delight: The experience of using the program should be pleasurable
one.
3

4. Design within the contest of software Engineering:
• Software design is the last software engineering action within the
modelling activity and sets the stage for construction(code generation
and testing)
4

5. Analysis Model -> Design Model
5
Analysis Model
use-cases - text
use-case diagrams
activity diagrams
swim lane diagrams
data flow diagrams
control-flow diagrams
processing narratives
f low- or ient ed
element s
behavior al
element s
class- based
element s
scenar io- based
element s
class diagrams
analysis packages
CRC models
collaboration diagrams
state diagrams
sequence diagrams
Da t a / Cla ss De sign
Arc hit e c t ura l De sign
Int e rfa c e De sign
Com pone nt -
Le v e l De sign
Design Model

6. • The data/class design transforms class models into design class
realization(an actual form given to a concept of work),
requisite(a thing that is necessary for the achievement of a specified
end),
data structures required to implement the software.
6

7. • The architectural design defines the relationship between major
structural element of the software.
• The interface design describes how the software communicates with
the system that incorporates with it, and with humans who use it.
• The component design transforms structural elements of the
software architecture into a procedural description of software
components.
The importance of software design can be stated with a single word-
QUALITY
7

8. Design Process and Design quality
• Software design is a iterative process through which requirement are
translated into a blueprint for constructing the software.
• Initially the blueprint depicts a holistic view of the software,ie:the
design is represented at a high level of abstraction.
Characteristics
Quality guidelines
Quality attributes
8

9. Design and Quality
Characteristics:
• The design must implement all of the explicit requirements contained in the
analysis model, and it must accommodate all of the implicit requirements
desired by the customer.
• The design must be a readable, understandable guide for those who generate
code and for those who test and subsequently support the software.
• The design should provide a complete picture of the software, addressing the
data, functional, and behavioral domains from an implementation perspective.
9

10. Quality Guidelines
• A design should exhibit an architecture that (1) has been created using recognizable
architectural styles or patterns, (2) is composed of components that exhibit good design
characteristics and (3) can be implemented in an evolutionary fashion
• For smaller systems, design can sometimes be developed linearly.
• A design should be modular; that is, the software should be logically partitioned into
elements or subsystems
• A design should contain distinct representations of data, architecture, interfaces, and
components.
10

11. • A design should lead to data structures that are appropriate for the classes to be
implemented and are drawn from recognizable data patterns.
• A design should lead to components that exhibit independent functional characteristics.
• A design should lead to interfaces that reduce the complexity of connections between
components and with the external environment.
• A design should be derived using a repeatable method that is driven by information
obtained during software requirements analysis.
• A design should be represented using a notation that effectively communicates its
meaning. 11

12. Quality Attributes
• Functionality is assessed by evaluating the feature set and
capabilities of the program, the generality of the functions that are
delivered, and the security of the overall system.
• Usability is assessed by considering human factors , overall aesthetics,
consistency, and documentation.
• Reliability is evaluated by measuring the frequency and severity of
failure, the accuracy of output results, the mean-time-to-failure
(MTTF), the ability to recover from failure, and the predictability of
the program.
• Performance is measured by considering processing speed, response
time, resource consumption, throughput, and efficiency.
12

13. • Supportability combines the ability to extend the program
(extensibility), adaptability, serviceability—these three attributes
represent a more common term,maintainability—and in addition,
testability, compatibility, configurability (the ability to organize and
control elements of the software configuration), the ease with which
a system can be installed, and the ease with which problems can be
localized.
13

14. Fundamental Concepts
• Abstraction—data, procedure, control
• Architecture—the overall structure of the software
• Patterns—”conveys the essence” of a proven design solution
• Separation of concerns—any complex problem can be more easily handled if it is
subdivided into pieces
• Modularity—compartmentalization of data and function
• Hiding—controlled interfaces
• Functional independence—single-minded function and low coupling 14

15. • Refinement—elaboration of detail for all abstractions
• Aspects—a mechanism for understanding how global requirements affect
design
• Refactoring—a reorganization technique that simplifies the design
• OO design concepts
• Design Classes—provide design detail that will enable analysis classes
to be implemented
15

16. 1.Abstraction
• It is the act of representing the essential features without including
the background details or explanations.
Many level of abstraction can be posed:
Highest level of abstraction
Low level of abstraction
As different levels of abstraction are developed:
Procedural and
Data abstraction
16

17. Data Abstraction
17
door
implemented as a data structure
manufacturer
model number
type
swing direction
inserts
lights
type
number
weight
opening mechanism

18. Procedural Abstraction
18
open
implemented with a "knowledge" of the
object that is associated with enter
details of enter
algorithm

19. 2.Architecture
19
“The overall structure of the software and the ways in which that structure provides conceptual integrity for a
system.”
•Structural properties. This aspect of the architectural design representation defines the components of a
system (e.g., modules, objects, filters) 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, adaptability, and other
system characteristics.
•Families of related systems. The architectural design should draw upon 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.

20. The architectural design can be represented using one or more of a
number of different models:
Structural models: These represent architecture as an organized
collection of program components.
Framework models : They increase the level of design abstraction by
attempting to identify repeatable architectural design frameworks
that are encountered in similar types of applications.
Dynamic models: They address the behavioral aspects of the program
architecture, indicating how the structure or system configuration
may change as a function of external events.
Process models: They focus on the design of the business or technical
process that the system must accommodate.
Functional models can be used to represent the functional hierarchy of
a system.
20

21. 3.Patterns
21
Pattern provides a proven solution to a recurring problem.
Design Pattern Template
•Pattern name—describes the essence of the pattern in a short but expressive name
•Intent—describes the pattern and what it does
•Also-known-as—lists any synonyms for the pattern
•Motivation—provides an example of the problem
•Applicability—notes specific design situations in which the pattern is applicable
•Structure—describes the classes that are required to implement the pattern
•Participants—describes the responsibilities of the classes that are required to implement the pattern
•Collaborations—describes how the participants collaborate to carry out their responsibilities
•Consequences—describes the “design forces” that affect the pattern and the potential trade-offs that
must be considered when the pattern is implemented
•Related patterns—cross-references related design patterns

22. 4.Separation of Concerns
• Any complex problem can be more easily handled if it is subdivided into
pieces that can each be solved and/or optimized independently
• A concern is a feature or behavior that is specified as part of the
requirements model for the software
• By separating concerns into smaller, and therefore more manageable
pieces, a problem takes less effort and time to solve.
22

23. 5.Modularity
• "Modularity is the single attribute of software that allows a program to be intellectually
manageable"
• Monolithic software (i.e., A large program composed of a single module) cannot be
easily grasped by a software engineer.
• The number of control paths, span of reference, number of variables, and overall
complexity would make understanding close to impossible.
• In almost 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.
23

24. Modularity: Trade-offs
24
What is the "right" number of modules
for a specific software design?
optimal number
of modules
cost of
software
number of modules
module
integration
cost
module development cost

25. 6.Information Hiding
• Modules should be specified and designed so that information
(algorithms and data) contained within a module is inaccessible to
other modules that have no need for such information.
25

26. 6.Information Hiding
26
module
controlled
interface
"secret"
• algorithm
• data structure
• details of external interface
• resource allocation policy
clients
a specific design decision

27. 7.Refinement
• Refinement is actually a process of elaboration.
• We elaborate on the original statement, providing more and more
detail as each successive refinement (elaboration) occurs.
Note : Abstraction and refinement are complementary concepts.
27

28. Stepwise Refinement
28
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

29. 8.Functional Independence
• Functional independence is achieved by developing modules with "single-minded" function and an
"aversion" to excessive interaction with other modules.
• Cohesion is an indication of the relative functional strength of a module.
• A cohesive module performs a single task, requiring little interaction with other
components in other parts of a program. Stated simply, a cohesive module
should (ideally) do just one thing.
• Coupling is an indication of the relative interdependence among modules.
• Coupling depends on the interface complexity between modules, the point at
which entry or reference is made to a module, and what data pass across the
interface.
29

30. 8.Aspects
• Consider two requirements, A and B. Requirement A crosscuts
requirement B “if a software decomposition [refinement] has been
chosen in which B cannot be satisfied without taking A into account.
• An aspect is a representation of a cross-cutting concern.
30

31. 9.Refactoring
• Fowler defines refactoring in the following manner:
• "refactoring is the process of changing a software system in such a way that it does not
alter the external behavior of the code [design] yet improves its internal structure.”
• When software 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 design failure that can be corrected to yield a better design.
31

32. Sizing Modules: Two Views
32
MODULE
What's
inside??
How big
is it??

33. 10. OO Design Concepts
• Inheritance—all responsibilities of a superclass is immediately inherited by all
subclasses
• Messages—stimulate some behavior to occur in the receiving object
• Polymorphism—a characteristic that greatly reduces the effort required to
extend the design
33

34. 11.Design classes
• Five different types of design classes, each representing a different layer of the design
architecture, can be developed.
User interface classes define all abstractions that are necessary for human
computer interaction (HCI).
Business domain classes are often refinements of the analysis classes. The classes
are recognized as attributes and services (methods) that are required to
implement some element of the business domain
Process classes implement lower-level 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 with the outside world.
34

35. They define four characteristics of a well-formed design class:
• Complete and sufficient. A design class should be the complete
encapsulation of all attributes and methods that can reasonably be
expected to exist for the 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, the 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. Within the design model, it is necessary for design classes to
collaborate with one another. However, collaboration should be kept to an
acceptable minimum. If a design model is highly coupled, the system is
difficult to implement, to test, and to maintain over time. In general, design
classes within a subsystem should have only limited knowledge of other
classes.
35

36. 11.Design Classes
• Analysis classes are refined during design to become entity classes
• Boundary classes are developed during design to create the interface (e.G., Interactive screen
or printed reports) that the user sees and interacts with as the software is used.
• Boundary classes are designed with the responsibility of managing the way entity objects are represented
to users.
• Controller classes are designed to manage
• The creation or update of entity objects;
• the instantiation of boundary objects as they obtain information from entity objects;
• complex communication between sets of objects;
• validation of data communicated between objects or between the user and the application. 36

37. 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 part of the software process.
• The abstraction dimension represents the level of detail as each
element of the analysis model is transformed into a design equivalent
and then refined iteratively.
37

38. The Design
Model
38
process dimension
archit ect ure
element s
int erface
element s
component -level
element s
deployment -level
element s
low
high
class diagrams
analysis packages
CRCmodels
collaborat ion diagrams
use-cases - t ext
use-case diagrams
act ivit y diagrams
swim lane diagrams
collaborat ion diagrams dat a f low diagrams
cont rol-f low diagrams
processing narrat ives
dat a f low diagrams
cont rol-f low diagrams
processing narrat ives
st at e diagrams
sequence diagrams
st at e diagrams
sequence diagrams
design class realizat ions
subsyst ems
collaborat ion diagrams
design class realizat ions
subsyst ems
collaborat ion diagrams
ref inement s t o:
deployment diagrams
class diagrams
analysis packages
CRC models
collaborat ion diagrams
component diagrams
design classes
act ivit y diagrams
sequence diagrams
ref inement s t o:
component diagrams
design classes
act ivit y diagrams
sequence diagrams
design class realizat ions
subsyst ems
collaborat ion diagrams
component diagrams
design classes
act ivit y diagrams
sequence diagrams
a na ly sis mode l
de sign mode l
Requirement s:
const raint s
int eroperabilit y
t arget s and
conf igurat ion
t echnical int erf ace
design
Navigat ion design
GUI design

39. Design Model Elements
The design model has four major elements
• Data elements
• Data model --> data structures
• Data model --> database architecture
• Architectural elements
• Application domain
• Analysis classes, their relationships, collaborations and behaviors are transformed into design realizations
• Patterns and “styles”
• Interface elements
• The user interface (UI)
• external interfaces to other systems, devices, networks or other producers or consumers of information
• Internal interfaces between various design components.
• Component elements
• Deployment elements 39

40. Data Design Elements:
• Data design creates a model of data and or information that is
represented at a high level of abstraction.
• 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 applications.
• At the application level, the translation of a data model into a
database is pivotal to achieving the business objectives of a system.
• At the business level, the collection of information stored in disparate
databases and reorganized into a “data warehouse” enables data
mining or knowledge discovery that can have an impact on the
success of the business itself.
40

41. Architectural Elements
• The architectural model is derived from three sources:
• information about the application domain for the software to be built;
• specific requirements model elements such as data flow diagrams or
analysis classes, their relationships and collaborations for the problem
at hand, and
• the availability of architectural patterns and styles.
41

42. Interface Design Elements
• The interface design elements for software depict information flows
into and out of the system and how it is communicated among the
components defined as part of the architecture.
• There are three important elements of interface design:
1.The user interface (UI);
2.External interfaces to other systems, devices, networks, or other
producers or consumers of information; and
3.Internal interfaces between various design components.
42

43. Interface Design Elements
• These interface design elements allow the software to communicate
externally and enable internal communication and collaboration
among the components that populate the software architecture.
43

44. • UI design (increasingly called usability design) is a major software
engineering action. Usability design incorporates aesthetic elements
(e.g., layout, color, graphics, interaction mechanisms), ergonomic
elements (e.g., information layout and placement, metaphors, UI
navigation), and technical elements (e.g., UI patterns, reusable
components).
• The design of external interfaces requires definitive information
about the entity to which information is sent or received.
• The design of internal interfaces is closely aligned with component-
level design.
44

45. Component-Level Design Elements
• The component-level design for software is the equivalent to a set of detailed
drawings (and specifications) for each room in a house.
• These drawings depict wiring and plumbing within each room, the location of
electrical receptacles and wall switches, faucets, sinks, showers, tubs, drains, cabinets,
and closets.
• The component-level design for software fully describes the internal detail of each
software component.
• To accomplish this, the component-level design defines data structures for all local
data objects and algorithmic detail for all processing that occurs within a component
and an interface that allows access to all component operations (behaviors).
45

46. Component Elements
46
SensorManagement
Sensor

47. Deployment Elements
47
Deployment-level design
elements indicate how software
functionality and subsystems will
be allocated within the physical
computing environment that will
support the software.

48. SOFTWARE ARCHITECTURE
• What Is Architecture?
• Why Is Architecture Important?
• Architectural Descriptions
48

49. What Is Architecture?
• The software architecture of a program or computing system is the structure or
structures of the system, which comprise software components, the externally
visible properties of those components, and the relationships among them.
The architecture is not the operational software. Rather, it is a representation
that enables you to
• analyze the effectiveness of the design in meeting its stated requirements
• architectural alternatives at a stage when making design changes is still relatively
easy
• reduce the risks associated with the construction of the software.
49

50. • There is a distinct difference between the terms architecture and
design.
• A design is an instance of an architecture similar to an object being an
instance of a class.
• Eg: In client-server architecture ,there is one architecture, but many
designs can be created based on that architecture.
• Architectural design focuses on the representation of the structure of
software components, their properties, and interactions.
50

51. Why Is Architecture Important?
Three key reasons that software architecture is important:
• Representations of software architecture are an enabler for communication
between all parties (stakeholders) interested in the development of a computer-
based system.
• The architecture highlights early design decisions that will have a profound
impact on all software engineering work that follows and, as important, on the
ultimate success of the system as an operational entity.
• Architecture “constitutes a relatively small, intellectually graspable model of how
the system is structured and how its components work together”.
51

52. Architectural Descriptions
• Different stakeholders will see an architecture from different viewpoints that are
driven by different sets of concerns. This implies that an architectural description
is actually a set of work products that reflect different views of the system.
• The IEEE standard defines an architectural description (AD) as “a collection of
products to document an architecture.” The description itself is represented using
multiple views, where each view is “a representation of a whole system from the
perspective of a related set of [stakeholder] concerns.”
• Each view developed as part of an architectural description addresses a specific
stakeholder concern. To develop each view the system architect considers a
variety of alternatives and ultimately decides on the specific architectural
features that best meet the concern. Therefore, architectural decisions
themselves can be considered to be one view of the architecture.
52

53. ARCHITECTURAL GENRES
• In the context of architectural design, genre implies a specific
category within the overall software domain.
• The architectural genre will often dictate the specific architectural
approach to the structure that must be built.
Eg: Buildings
following general styles: houses, apartment buildings, office buildings,
industrial building, warehouses, and so on.
53

54. Grady Booch suggests the following architectural genres for software-
based systems:
• Artificial intelligence—Systems that simulate or augment human
cognition, locomotion, or other organic processes.
• Commercial and nonprofit—Systems that are fundamental to the
operation of a business enterprise.
• Communications—Systems that provide the infrastructure for
transferring and managing data, for connecting users of that data, or
for presenting data at the edge of an infrastructure.
54

55. • Content authoring—Systems that are used to create or manipulate
textual or multimedia artifacts.
• Devices—Systems that interact with the physical world to provide
some point service for an individual.
• Entertainment and sports—Systems that manage public events or
that provide a large group entertainment experience.
• Financial—Systems that provide the infrastructure for transferring
and managing money and other securities.
• Games—Systems that provide an entertainment experience for
individuals or groups.
• Government—Systems that support the conduct and operations of a
local, state, federal, global, or other political entity.
55

56. • Industrial—Systems that simulate or control physical processes.
• Legal—Systems that support the legal industry.
• Medical—Systems that diagnose or heal or that contribute to medical
research.
• Military—Systems for consultation, communications, command,
control, and intelligence (C4I) as well as offensive and defensive
weapons.
• Operating systems—Systems that sit just above hardware to provide
basic software services.
• Platforms—Systems that sit just above operating systems to provide
advanced services.
56

57. • Scientific—Systems that are used for scientific research and
applications.
• Tools—Systems that are used to develop other systems.
• Transportation—Systems that control water, ground, air, or space
vehicles.
• Utilities—Systems that interact with other software to provide some
point service.
57

58. THANKS…
58