Design Engineering - SOftware Engineering Unit 1

1. Chapter 1
Design Engineering
UNIT - III

2. Design Engineering
 It covers the set of principles, concepts, and practices that
lead to the development of a high quality system or product.
 Goal of design engineering is to produce a model or
representation that depict:
 Firmness – program should not have any bug that inhibits its functions.
 Commodity – suitable to its intended use.
 Delight - pleasurable to use
 The design model provides detail about software data
structures, architecture, interfaces, and components that are
necessary to implement the system.

3. Why design is so important?
 It is place where quality is fostered.
 It provides us with representation of software that can be
assessed for quality.
 Only way that can accurately translate a customer’s
requirements into a finished software product.
 It serves as foundation for all software engineering
activities.
 Without design difficult to assess:
 Risk
 Test
 Quality

4. Design Process and Design Quality
 S/w design is an iterative process through
which requirements are translated into a
“blueprint” for constructing the s/w.
 As design iteration occur, subsequent
refinement leads to design representation
at much lower levels of abstraction.

5. Goal of design process
 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.

6. Quality Guidelines
Characteristics of good design
 A design should exhibit an architecture that
 as been created using recognizable architectural styles or patterns,
 is composed of components that exhibit good design characteristics and
 can be implemented in an evolutionary fashion
 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.
 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

7. Quality Guidelines (contd.)
 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.

8. Design Quality Attributes
 Acronym FURPS –
Functionality
Usability
Reliability
Performance
Supportability

9.  Functionality – is assessed by evaluating the feature set and
capabilities of the program.
 Functions that are delivered and security of the overall
system.
 Usability – assessed by considering human factors,
consistency & documentation.
 Reliability – evaluated by
 measuring the frequency and severity of failure.
 Accuracy of output results.
 Ability to recover from failure and predictability of the
program.
 Performance - measured by processing speed, response
time, resource consumption, efficiency.
 Supportability – combines the ability to extend the program
(extensibility), adaptability and serviceability.

10. Design Principles
 S/W design is both a process and a model.
 Design process - sequence of steps that enable the
designer to describe all aspects of the software to be
built.
 Design model - created for software provides a variety of
different views of the computer software

11.  The design process should not suffer from ‘tunnel vision.’ - Designer should
consider alternative approaches.
 The design should be traceable to the analysis model - a single element of the
design model often traces to multiple requirements, it is necessary to have a
means for tracking how requirements have been satisfied by the design model.
 The design should not reinvent the wheel- use already exists design pattern
because time is short and resource are limited.
 The design should “minimize the intellectual distance” between the software and
the problem as it exists in the real world. – design should be self-explanatory
Design Principles

12.  The design should exhibit uniformity and integration – before design work begins
rules of styles and format should be defined for a design team.
 The design should be structured to accommodate change.
 The design should be structured to degrade gently, even when unusual data,
events, or operating conditions are encountered.
 Design is not coding, coding is not design.
 The design should be assessed for quality as it is being created, not after the fact.
 The design should be reviewed to minimize conceptual (semantic) errors.
Design Principles

13. Design concepts
Design concepts provide the necessary framework for
“to get the thing on right way”.
1.
Abstraction
2.
Architecture
3.
Patterns
4.
Modularity
5.
Information Hiding
6.
Functional Independence
7.
Refinement
8.
Refactoring
9.
Design Classes

14. Abstraction
 At the highest level of abstraction – a solution is stated in broad terms.
 At lower level of abstraction – a more detailed description of the solution is provided.
 Two types of abstraction:
 Procedural abstraction: Sequence of instructions that have a specific and limited
function.
Ex. Open a door
open implies long sequence of activities (e.g. walk to the door, grasp knob, turn knob
and pull the door, etc).
 Data abstraction: collection of data that describes a data object.
Ex. Open a door. – door is data object.
 Data abstraction for door would encompass a set of attributes that describe the
door. (E.g. door type, swing direction, opening mechanism, etc.)

15. Architecture
 Software architecture suggest “ the overall structure of the software and the ways in which that structure
provides conceptual integrity for a system.
 No. of different models can use to represent architecture.
 Structural Model- represent architecture as an organized collection of components
 Framework model – Increase level of design abstraction by identifying repeatable architectural design
framework.
 Dynamic model – address behavior of the program architecture and indicating how system or structure
configuration may change as a function.
 Process Model – focus on design of the business or technical process that the system must
accommodate.
 Functional models – used to represent the functional hierarchy of a system.

16. Patterns
 Brad Appleton defines a design pattern in the following manner:
“A pattern is a named nugget(chink/piece)of insight which conveys the essence of a
proven solution to a recurring problem within a certain context amidst competing
concerns”.
 The intent of each design pattern is to provide a description that enables a
designer to determine,
(1) whether the pattern is applicable to the current work
(2) whether the pattern can be reused (hence, saving design time)
(3) whether the pattern can serve as a guide for developing a similar,
but functionally or structurally different pattern.

17. Modularity
 Architecture and design pattern embody modularity.
 Software is divided into separately named and addressable
components, sometimes called modules, which are integrated to
satisfy problem requirement.
 modularity is the single attribute of software that allows a
program to be intellectually manageable
 It leads to a “divide and conquer” strategy. – it is easier to solve
a complex problem when you break into a manageable pieces.
 Refer fig. that state that effort (cost) to develop an individual
software module does decrease if total number of modules
increase.
 However as the no. of modules grows, the effort (cost)
associated with integrating the modules also grows.

18. Modularity and software cost

19. Information Hiding
 The principle of information hiding suggests that modules be
"characterized by design decisions that (each) hides from all
others modules.“
 In other words, modules should be specified and designed so
that information (algorithm and data) contained within a module
is inaccessible to other modules that have no need for such
information.
 The intent of information hiding is to hide the details of data
structure and procedural processing behind a module interface.
 It gives benefits when modifications are required during testing
and maintenance because data and procedure are hiding from
other parts of software, unintentional errors introduced during
modification are less.

20. Functional Independence
 Functional independence is achieved by developing
modules with "single-minded“ function and an "aversion"
to excessive interaction with other modules.
 In other words - each module addresses a specific sub-
function of requirements and has a simple interface
when viewed from other parts of the program structure.
 Independence is important –
 Easier to develop
 Easier to Test and maintain
 Error propagation is reduced
 Reusable module.

21. Functional Independence
 To summarize, functional independence is a key
to good design, and design is the key to
software quality.
 To measure independence, have two qualitative
criteria: cohesion and coupling
 Cohesion is a measure of the relative functional
strength of a module.
 Coupling is a measure of the relative
interdependence among modules.

22. Refinement
 Refinement is actually a process of elaboration.
 begin with a statement of function (or description of information)
that is defined at a high level of abstraction.
 That is, the statement describes function or information
conceptually but provides no information about the internal
workings of the function or the internal structure of the
information.
 Refinement causes the designer to elaborate on the original
statement, providing more and more detail as each successive
refinement (elaboration) occurs.
 Abstraction and refinement are complementary concepts.
Abstraction enables a designer to specify procedure and data
and yet suppress low-level details.
 Refinement helps the designer to expose low-level details as
design progresses.

23.  Undermodularity and overmodularity should be
avoided. But how do we know the vicinity of M?
 We modularize a design so that development can
be more easily planned.
 Software increments can be defined and delivered.
 Changes can be more easily accommodated.
 Testing and debugging can be conducted more
efficiently and long-term maintained can be
conducted without serious side effects.

24. Refactoring
 Refactoring is a reorganization technique that
simplifies the design (or code) of a component
without changing its function or behavior.
 “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.

25. 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
humancomputer interaction (HCI).
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 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.

26. The Design Model
Data/Class Design
Architectural Design
Interface Design
Component-level Design

27. Process Dimension (Progression)
Abstraction
Dimension
Data/Class
Elements
Interface
Elements
Architectural
Elements
Component-level
Elements
Deployment-level
Elements
Dimensions of the Design
Model
Analysis model
Design model
Low
High

28. 28
 The design model can be viewed in two different dimensions
 (Horizontally) The process dimension indicates the evolution of the
parts of the design model as each design task is executed
 (Vertically) The abstraction dimension represents the level of detail
as each element of the analysis model is transformed into the
design model and then iteratively refined
 Elements of the design model use many of the same UML
diagrams used in the analysis model
 The diagrams are refined and elaborated as part of the design
 More implementation-specific detail is provided
 Emphasis is placed on
 Architectural structure and style
 Interfaces between components and the outside world
 Components that reside within the architecture

29. 29
 Design model elements are not always developed in a
sequential fashion
 Preliminary architectural design sets the stage
 It is followed by interface design and component-level design,
which often occur in parallel
 The design model has the following layered elements
 Data/class design
 Architectural design
 Interface design
 Component-level design
 A fifth element that follows all of
the others is deployment-level design
Data/Class Design
Architectural Design
Interface Design
Component-level Design

30. Chapter 2
Creating an Architectural
Design

31. Software Architecture
 “The software architecture of a program or computing system is the
structure or structures of the system, which comprise the software
components, the externally visible properties of those components,
and the relationships among them.”
 It is not operational software but it is representation that enables
software engineer to
 Analyze the effectiveness of design in meeting its stated
requirement.
 consider architectural alternatives at a stage when making
design changes is still relatively easy,
 reduce the risks associated with the construction of the software.

32. Importance of Software Architecture
 Representations of software architecture are an
enabler for communication between all parties
(stakeholders) interested in the development
 Architecture highlights early design decisions
that will have a profound impact on all software
engineering work that follows.
 Architecture “constitutes a relatively small,
intellectually graspable model of how the system
is structured and how its components work
together”

33. Data Design
 The structure of data has always been an
important part of software design.
 Component level – the design of data
structures and the associated algorithms
required to manipulate them is essential to
the creation of high-quality applications.
 Application level – the translation of a data
model into a database design

34. Data Design at architectural design
 Today, business (i.e. irrespective of its size large or
small) have dozens of database serving many
applications encompassing hundreds of gigabytes of
data.
 Challenge is to extract useful information from its data
environment, particularly when the information desired is
cross-functional.
 To solve this challenge, developed technique called
 Data Mining (also called knowledge discovery in
databases (KDD)),
 Data Warehouse
 Data mining that navigate through existing databases in
an attempt to extract appropriate business-level
information

35.  However, the existence of multiple databases, their
different structures, the degree of detail contained with
the databases, and many other factors make data mining
difficult within an existing database environment.
 A data warehouse is a separate data environment that is
not directly integrated with day-to-day applications but
encompasses all data used by a business
 A data warehouse is a large, independent database that
encompasses some, but not all, of the data that are
stored in databases that serve the set of applications
required by a business.

36. Data design at the component level
 Component level focuses on the representation of data structures
that are directly accessed by one or more software components.
Principles are applicable to data design
1. The systematic analysis principles applied to function and
behavior should also be applied to data.
2. All data structures and the operations to be performed on each
should be identified.
3. A data dictionary should be established and used to define both
data and program design (operations)
4. Low-level data design decisions should be deferred until late in
the design process.

37. 5. The representation of data structure should be known
only to those modules that must make direct use of the
data contained within the structure.
6. A library of useful data structures and the operations
that may be applied to them should be developed.
7. A software design and programming language should
support the specification and realization of abstract
data types.

38. Architectural Styles and Patterns
 Style describes a system category that encompasses
1. A set of components (e.g., a database, computational
modules) that perform a function required by a system;
2. a set of connectors that enable “communication, co-
ordinations and cooperation” among components;
3. constraints that define how components can be integrated to
form the system
4. semantic models that enable a designer to understand the
overall properties of a system
It can be represented by
 Data-centered architecture
 Data flow architecture
 Call and return architecture
 Object oriented architecture
 Layered architecture.

39. Data-centered architecture

40. Data-centered architecture
 A data store (e.g., a file or database) resides at the center of this
architecture and is accessed frequently by other components
that update, add, delete, or otherwise modify data within the
store.
 Client software accesses a central repository which is in passive
state (in some cases).
 client software accesses the data independent of any changes to
the data or the actions of other client software.
 So, in this case transform the repository into a “Blackboard”.
 A blackboard sends notification to subscribers when data of
interest changes, and is thus active.
 Data-centered architectures promote integrability.
 Existing components can be changed and new client
components can be added to the architecture without concern
about other clients.
 Data can be passed among clients using the blackboard
mechanism. So Client components independently execute
processes

41. Data Flow architecture
Pipes and filters
Batch Sequential

42. Data Flow architecture
 This architecture is applied when input data are to be
transformed through a series of computational or
manipulative components into output data.
 A pipe and filter pattern (Fig .1) has a set of components,
called filters, connected by pipes that transmit data from
one component to the next.
 Each filter works independently (i.e. upstream,
downstream) and is designed to expect data input of a
certain form, and produces data output (to the next filter)
of a specified form.
 the filter does not require knowledge of the working of its
neighboring filters.
 If the data flow degenerates into a single line of
transforms, it is termed batch sequential.

43. Call and return architecture

44. Call and return architecture
 Architecture style enables a software designer
(system architect) to achieve a program structure
that is relatively easy to modify and scale.
 Two sub-styles exist within this category:
1. Main/sub program architecture:
 Program structure decomposes function into a
control hierarchy where a “main” program invokes
a number of program components, which in turn
may invoke still other components.
2. Remote procedure Call architecture:
 The components of a main program/subprogram
architecture are distributed across multiple
computers on a network

45. Object-oriented architecture

46. Object-oriented architecture
 The object-oriented paradigm, like the abstract data type
paradigm from which it evolved, emphasizes the
bundling of data and methods to manipulate and access
that data (Public Interface).
 Components of a system summarize data and the
operations that must be applied to manipulate the data.
 Communication and coordination between components
is accomplished via message passing.

47. Layered Architecture

48.  A number of different layers are defined,
each accomplishing operations that
progressively become closer to the
machine instruction set.
 At the outer layer, components examine
user interface operations.
 At the inner layer, components examine
operating system interfacing.
 Intermediate layers provide utility services
and application software functions.

49. Architecture Patterns
 Architectural patterns address an application-specific
problem within a specific context and under a set of
limitations and constraints.
 The pattern proposes an architectural solution that
can serve as the basis for architectural design.
 Representative Examples:
 Concurrency
 Persistence
 Distribution

50. Organization and Refinement
 It is important to establish a set of design criteria that
can be used to assess an architectural design that is
derived.
 The following questions provide insight into an
architectural style.
 These questions provide the designer with an early
assessment of design quality and lay the foundation for
more detailed analysis of the architecture.

51. Control:
How is control managed within the architecture?
Does a distinct control hierarchy exist, and if so, what is the role of
components within this control hierarchy?
How do components transfer control within the system?
How is control shared among components?
What is the control topology (i.e., the geometric form that the
control takes)?
Is control synchronized or do components operate
asynchronously?

52. Data:
How are data communicated between components?
Is the flow of data continuous, or are data objects passed to the
system sporadically?
What is the mode of data transfer (i.e., are data passed from one
component to another or are data available globally to be shared
among system components)?
Do data components (e.g., a blackboard or repository) exist, and if
so, what is their role? How do functional components interact with
data components?
Are data components passive or active (i.e., does the data
component actively interact with other components in the system)?
How do data and control interact within the system?

53. ARCHITECTURAL DESIGN
 As architectural design begins, the software to be developed must be
put into
context—that is, the design should define the external entities that the
software interacts with and the nature of the interaction.
 An archetype is an abstraction (similar to a class) that represents one
element of system behavior.
 The set of archetypes provides a collection of abstractions that must be
modeled architecturally if the system is to be constructed, but the
archetypes themselves do not provide enough implementation detail.

54. Architectural context diagram for the SafeHome
security function