Introduction to design concepts and explanation

1. Module:3
Modeling (Design) Design within the context
of Software Engineering, Design Process,
Design Concepts, Design Model Software
Architecture.
5 hours

2. 2
Purpose of Design
• Design is where customer requirements, business needs, and
technical considerations all come together in the formulation of a
product or system
• The design model provides detail about the software data
structures, architecture, interfaces, and components
• The design model can be assessed for quality and be improved
before code is generated and tests are conducted

3. 3
Purpose of Design (continued)
• A designer must practice diversification and convergence
• Software design is an iterative process through which requirements are
translated into a blueprint for constructing the software

4. 4
From Analysis Model to
Design Model
• Each element of the analysis model provides information that is
necessary to create the four design models
– The data/class design transforms analysis classes into design classes along
with the data structures required to implement the software
– The architectural design defines the relationship between major structural
elements of the software; architectural styles and design patterns help
achieve the requirements defined for the system
– The interface design describes how the software communicates with
systems that interoperate with it and with humans that use it
– The component-level design transforms structural elements of the
software architecture into a procedural description of software
components
(More on next slide)

5. 5
From Analysis Model to
Design Model (continued)
Data/Class Design
(Class-based model, Behavioral model)
Architectural Design
(Class-based model, Flow-oriented model)
Interface Design
(Scenario-based model, Flow-oriented model
Behavioral model)
Component-level Design
(Class-based model, Flow-oriented model
Behavioral model)

6. Translating the requirements model into the design mode

7. Translating the requirements model into the design
model
The requirements model, manifested by scenario-
based, class-based, flow-oriented, and behavioral
elements, feed the design task.
design produces a data/class design, an architectural
design, an interface design, and a component design

8. Translating the requirements
model into the design mode
The data/class design transforms class models into design
class realizations and the requisite data structures required to
implement the software.
The objects and relationships defined in the CRC diagram and
the detailed data content depicted by class attributes and other
notation provide the basis for the data design action.
Part of class design may occur in conjunction with the design
of software architecture. More detailed class design occurs as
each software component is designed.

9. Translating the requirements
model into the design mode
The architectural design defines the relationship between
major structural elements of the software, the
architectural styles and design patterns that can be used
to achieve the requirements defined for the system, and
the constraints that affect the way in which architecture
can be implemented [Sha96]. The architectural design
representation—the framework of a computer-based
system—is derived from the requirements model

10. Translating the requirements
model into the design mode
The interface design describes how the software
communicates with systems that interoperate with it, and with
humans who use it.
An interface implies a flow of information (e.g., data and/or
control) and a specific type of behavior. Therefore, usage
scenarios and behavioral models provide much of the
information required for interface design. The component-
level design transforms structural elements of the software
architecture into a procedural description of software
components. Information obtained from the class-based
models, flow models, and behavioral models serve as the
basis for component design

11. Software Quality Guidelines and Attributes
McGlaughlin suggests three characteristics that serve as a guide for the
evaluation of a good design:
• The design must implement all of the explicit
requirements contained in the requirements model, and
it must accommodate all of the implicit requirements
desired by stakeholders.
• 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.

12. 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,2 thereby facilitating
implementation and testing.
2. A design should be modular; that is, the software should be logically
partitioned into elements or subsystems.
3. A design should contain distinct representations of data, architecture,
interfaces, and components

13. Quality guidelines
4. A design should lead to data structures that are appropriate for the
classes to be implemented and are drawn from recognizable data
patterns.
5. A design should lead to components that exhibit independent
functional characteristics.
6. A design should lead to interfaces that reduce the complexity of
connections between components and with the external environment.

14. Quality guidelines
7. A design should be derived using a repeatable method
that is driven by information obtained during software
requirements analysis.
8. A design should be represented using a notation that
effectively communicates its meaning.

15. Quality attributes
functionality, usability, reliability, performance, and
supportability

16. 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.

17. Performance is measured by considering processing
speed, response time, resource consumption,
throughput, and efficiency.
• Supportability combines the ability to extend the
program (extensibility), adaptability, serviceability—
these three attributes represent a more common term,
maintainability

18. The Evolution of Software Design:
• The evolution of software design is a continuing
process that has now spanned almost six
decades.
• All these methods have a number of common
characteristics:
1. A mechanism for the translation of the
requirements model into a design representation,
2. A notation for representing functional
components and their interfaces,
3. Heuristics for refinement and partitioning, and
4. Guidelines for quality assessment

19. 19
Design Concepts
Abstraction
• At the highest level of abstraction, a solution is stated in broad
terms using the language of the problem environment.
• At lower levels of abstraction, a more detailed description of
the solution is provided.
– Procedural abstraction – a sequence of instructions that have
a specific and limited function
– Data abstraction – a named collection of data that describes
a data object

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

21. Procedural Abstraction
open
details of enter
algorithm
Open implies a long sequence of
procedural steps (e.g., walk to the door,
reach out and grasp knob, turn knob and
pull door, step away from moving door

22. Architecture
architecture is the structure or organization of
program components (modules), the manner
in which these components interact, and the
structure of data that are used by the
components

23. Shaw and Garlan [Sha95a] describe a set of
properties that should be specified as part of
an architectural design:
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.

24. Architecture
• Structural models represent architecture as
an organized collection of program
components.
• Framework models increase the level of
design abstraction by attempting to identify
repeatable architectural design frameworks
that are encountered in similar types of
application

25. Architecture:
• Dynamic models address the behavioral aspects of
the program architecture, indicating how the structure or
system configuration may change as a function of external
events
• Procedural models focus on the design of the
business or technical process that the system must
accommodate.

26. Architecture
• Function models can be used to represent
the functional hierarchy of a system

27. Pattern
Design pattern describes a design structure that solves a
particular design problem within a specific context.
– Each design pattern is to provide a description that enables
a designer to determine
• Whether the pattern is applicable to the current work
• Whether the pattern can be reused
• Whether the pattern can serve as a guide for developing a
similar, but functionally or structurally different pattern

28. Separation of Concerns
Separation of concerns is a design concept that suggests that
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.

29. Separation of Concerns
For two problems, p1 and p2, if the perceived complexity of
p1 is greater than the perceived complexity of p2, it follows
that the effort required to solve p1 is greater than the effort
required to solve p2.
It also follows that the perceived complexity of two problems
when they are combined is often greater than the sum of the
perceived complexity when each is taken separately.
This leads to a divide-and-conquer strategy—it’s easier to
solve a complex problem when you break it into manageable
pieces.

30. Modularity
Software is divided into separately named and
addressable components, sometimes called
modules, that are integrated to satisfy problem
requirements.
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

31. Modularity and software cost

32. There is a number, vicinity (M), of modules
that would result in minimum development
cost,