Design Engineering

Difference Between Analysis Modeling and Design

Engineering

• Analysis: Some kind of understanding of a problem or

situation.

• Design: Creation of a solution for the analyzed

problem.

• Model: Simplification that is used to better understand

the problem (“analysis model”) or the solution
(“design model”).
 Software Design
• Software design is an iterative process through which
requirements are translated into a “blueprint” for constructing the
software.
• A blueprint is a reproduction of a technical drawing, documenting
an architecture or an engineering design
• Initially, the blueprint depicts a holistic view of software.
● Software Design is the process to transform the user
requirements into some suitable form, which helps the
programmer in software coding and implementation.
• During the software design phase, the design document is
produced, based on the customer requirements as documented in
the SRS document. Hence the aim of this phase is to transform the
SRS document into the design document.
The following items are designed and documented
during the design phase:
•Different modules required.
•Control relationships among modules.
•Interface among different modules.
•Data structure among the different modules.
•Algorithms required to implement among the individual
modules.
 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
Design in the context of software engineering.
Translating Analysis Model into Design Model

Please refer fig 9.1 page 260 in pressman book

 From Analysis Model to
Design Model (continued)
Component-level Design

(Class-based model, Flow-oriented

model,Behavioral model)

Interface Design

(Scenario-based model, Flow-oriented

model
Behavioral model)
Architectural Design

(Class-based model, Flow-oriented model)

Data/Class Design

(Class-based model, Behavioral model) 8

Design Process and Design Quality
 Process of Design Engineering
• During the design process the software specifications are
transformed into design models.
• Models describe the details of the data structures, system
architecture, interface, and components.
• Each design product is reviewed for quality before moving
to the next phase of software development
• At the end of the design process a design model and
specification document is produced.
• This document is composed of the design models that
describe the data, architecture, interfaces and components.
 Quality's Role
• The importance of design is quality
• Design is the place where quality is fostered
– Provides representations of software that can be
assessed for quality
– Accurately translates a customer's requirements into
a finished software product or system
– Serves as the foundation for all software engineering
activities that follow
• Without design, we risk building an unstable system that
– Will fail when small changes are made
– May be difficult to test
– Cannot be assessed for quality later in the software
process when time is short and most of the budget
has been spent
• The quality of the design is assessed through a series of
formal technical reviews or design walkthroughs

11
 Goals of a Good Design
• The design must implement all of the explicit
requirements contained in the analysis model
It must also accommodate all of the implicit
requirements desired by the customer
• The design must be a readable and understandable
guide for those who generate code, and for those
who test and 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
 Design Quality Guidelines
1) A design should display an architecture that
● has been created using recognizable architectural styles or
pattern
● is composed of components that exhibit good design
characteristic
● can be implemented in evolutionary fashion thereby
facilitating implementation and testing
2) Design should be modular. ( software should be logically
partitioned into elements and subsystems)
3) A design should contain distinct representations of data,
architecture, interfaces, & components.
4) A design should lead to data structures that are appropriate for the
objects to be implemented.
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 modules & external environment.
7) A design should be derived using a repeatable method , driven by
information obtained during SW requirement analysis.
8) A design should be represented using a notation that effectively
communicates its meaning.
 Quality Attributes of design-FURPS
Hewlett-Packard developed a set of software quality attributes that has
been given the acronym FURPS—functionality, usability, reliability,
performance, and supportability for all software design.
● 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.
● 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.
 Design Principles :

• The design process should not suffer from ‘tunnel vision’ :

– A good designer should consider alternative approaches, judging each
based on the requirements of the problem, the resources available to do
the job.
• The design should be traceable to the analysis Model :
– Because 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(create) the wheel :
– Systems are constructed using a set of design patterns, many of which
have likely been encountered before.
– These patterns should always be chosen as an alternative to reinvention.
• The design should ‘minimize the intellectual distance” between the SW and the
problem as it exists in the real world.
• The design should be structured to accommodate change
• The design should be structured to degrade gently, even when abnormal data,
events, or operating conditions are encountered .
• Design is not coding, coding is not design :
– Even when detailed procedural designs are created for program
components, the level of abstraction of the design model is higher
than source code
• 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 :
A design team should ensure that major conceptual elements of the design
(omission, ambiguity, inconsistency) have been addressed before worrying
about the syntax of the design model.
• When these design principles are properly applied, the software engineer
creates a design that exhibits both external and internal quality factors.
• External quality factors are those properties of the software that can be
readily observed by users.
• Internal quality factors are of importance to software engineers.
– They lead to a high-quality design from the technical perspective.
 I. Design Concept
● The software design concept simply means the idea or principle
behind the design.
● It describes how you plan to solve the problem of designing
software, the logic, or thinking behind how you will design
software.
● A set of fundamental software design concepts has evolved over
the history of software engineering.
● Each provides the software designer with a foundation from
which more sophisticated design methods can be applied
● Each helps you answer the following questions:
– What criteria can be used to partition software into individual
components?
– How is function or data structure detail separated from a
conceptual representation of the software?
– What uniform criteria define the technical quality of a
software design
Design Concepts
 1.Abstraction
• It is a mechanism to’ hide irrelevant details and represent only the
essential features so that one can focus on important things at a time;
• It allows managing complex systems by concentrating on the essential
features only.
• Levels of 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 procedural orientation is
taken. Finally, at the lowest level of abstraction, the solution is
stated in a manner that can be directly implemented.

Procedural abstraction:
Data abstraction:
Control abstraction
• Procedural abstraction –
A named sequence of instructions that has a specific & limited function
– The word open for a door.- walk to the door, reach out and grasp knob, turn
knob and pull door, step away from moving door, etc.

• Data abstraction (a named collection of data that describes a data object)

called door.
– data object, door - a set of attributes that describe the door - e.g., door type,
swing direction, opening mechanism, weight, dimensions
● Control Abstraction (implies a program control mechanisms without specify
internal details)
– It implies a program control mechanism without specifying internal details. E.g.
Synchronization Semaphore used to coordinate activities in an Operating System.
● In object-oriented approach, one can abstract both data and
functions.
● However, generally, the classes in OOP are defined in such a way
that the data is hidden from the outside world and the functions
form the public interface.
● That is, the functions of the class can be directly accessed by other
functions outside the class and the hidden data can be accessed
indirectly with the help of these functions.
● Since, the internal details of the class are hidden from the outside
world, thus, data abstraction ensures security of data by
preventing it from accidental changes or manipulations by other
parts of the program.
 2.Software Architecture
● Architecture comprises of the hierarchy of components and how
they interact, and the structure of data used by the components
Set of Properties that should be part of the architectural
design:
• Structural properties- Defines the components of a system
(modules, objects, filters) and the manner in which those
components are packaged and interact with one another.
• Extra-Non functional properties- Address how the design
architecture achieves requirements for performance, capacity,
reliability, security, adaptability, and other system characteristics.
• Families of related systems-Reusable Components :Draw
repeatable patterns which are commonly used in the design of
families of similar systems.
 Continued…

Different models for The architecture design

• Structural models - Organized collection of program
components.
• Framework models - To identify repeatable architectural
design frameworks (patterns) that are encountered in similar
types of applications.
• Dynamic models - Address the behavioral aspects of the
program architecture
• Process models - Design of the business or technical process.
• Functional models - Represent the functional hierarchy of a
system.
Examples of Software Architecture

S1
S1

S2

S2 S4 S5
S3

S4 S3

S5
Control architecture
•Superordinate module,
subordinate module
•Depth, width
•Fan-in, Fan-out

25
 FAN In FAN Out
• The fan-out of a module is the number of its immediately subordinate
modules. As a rule of thumb, the optimum fan-out is seven, plus or
minus 2.
• The fan-in of a module is the number of its immediately superordinate
(i.e., parent or boss) modules. The designer should strive for high fan-in
at the lower levels of the hierarchy. This simply means that normally there
are common low-level functions that exist that should be identified and
made into common modules to reduce redundant code and increase
maintainability. High fan-in can also increase portability if, for example, all
I/O handling is done in common modules.
Object-Oriented Considerations
● In object-oriented systems, fan-in and fan-out relate to interactions
between objects. In object-oriented design, high fan-in generally
contributes to a better design of the overall system. High fan-in shows
that an object is being used extensively by other objects, and is
indicative of re-use.

26
● High fan-out in object-oriented design is indicated when an object must
deal directly with a large number of other objects. This is indicative of a
high degree of class interdependency. In general, the higher the fan-out
of an object, the poorer is the overall system design.
Advantages Of FAN-In
● High fan-in reduces redundancy in coding.
● It also makes maintenance easier. Modules developed for fan-in must
have good cohesion, preferably functional. Each interface to a fan-in
module must have the same number and types of parameters.
Designing Modules That Consider Fan-In/Fan-Out
● The designer should strive for software structure with moderate fan-out
in the upper levels of the hierarchy and high fan-in in the lower levels of
the hierarchy.
● Some examples of common modules which result in high fan-in are: I/O
modules, edit modules, modules simulating a high level command (such
as calculating the number of days between two dates). Use factoring to
solve the problem of excessive fan-out. Create an intermediate module
to factor out modules with strong cohesion
Cohesion is a measure of the degree to which the elements of the module
are functionally related. It is the degree to which all elements directed
towards performing a single task are contained in the component. Basically,
cohesion is the internal glue that keeps the module together. A good
software design will have high cohesion. )and loose coupling(Coupling is the
measure of the degree of interdependence between the modules.)
 Structural Partitioning
If the system is having hierarchical architecture, the program structure can
easily be partitioned both horizontally and vertically, represents this view.
Program structure partitioned into
• Horizontal partitioning:
• Vertical partitioning (factoring)
• In given figure (a), horizontal division defines the individual branches of
the modular hierarchy for every major program function. Control
modular (shown by rectangles) are used to coordinate communication
between tasks. The three partitions are done in simple horizontal
partitions i.e., input, data transformation (processing) and output.

The following benefits are provided by horizontal partitioning –

• Software, that can easily be tested.
• Software, that can easily be maintained.
• Propagation of fewer side effects.
• Software, that can easily be extended
29
Horizontal Partitioning
Vertical Partitioning
● On the other hand, vertical segmentation, also known as “factoring”,
states that control and function must be distributed across the program
structure, top to bottom. The top-level modules have to carry out control
functions and perform fewer modules in the structure are laborious,
performing all input, processing and output tasks.
● Figure (b), represents vertical partitioning. Due to the nature of changes
in program structures, vertical segmentation is required. Observing the
figure (b), it can be said that a change in the control module would make
its subordinates more likely to cause the spread of side effects.
Generally, changes are- changes to input, computation or transformation,
and output.
● The basic behavior of the program is much less likely to change. That is
why, vertically partitioned structures are less susceptible to side effects
due to changes and thus be more maintainable, which is its key quality
factor.
 3. Pattern
A design pattern describes a design structure that solves a
particular design problem within a specific context and
amid “forces” that may have an impact on the manner in
which the pattern is applied and used.
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), and
(3) whether the pattern can serve as a guide for developing
a similar, but functionally or structurally different pattern
 4. Separation Of Concerns
● A concern is a feature or behavior that is specified as
part of the requirements model for the software.
● 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.
● By separating concerns into smaller, and therefore more
manageable pieces, a problem takes less effort and time
to solve.
● Separation of concerns is manifested in other related
design concepts: modularity aspects, functional
independence, and refinement.
 5.Modularity
● Software architecture introduces modularity; that is, software is
divided into separately named and addressable components, often
called modules that are integrated to satisfy problem requirements.
It has been stated that "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 reader. The number of
control paths, span of reference, number of variables, and overall
complexity would make understanding close to impossible.
● You modularize a design (and the resulting program) 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,
○ Long-term maintenance can be there without side effects
The curves shown in Figure 8.2 do provide useful qualitative
guidance when modularity is considered. As the number of
modules grows, the effort (cost) associated with integrating the
modules also grows.You should modularize, but care should be
taken to stay in the vicinity of M. Undermodularity or
overmodularity should be avoided
 6.Information Hiding
• Modules must be specified and designed so that the information like algorithm
and data presented in a module is not accessible for other modules not
requiring that information.
The use of information hiding as a design criterion for modular
systems provides the greatest benefits when modifications are
required during testing and later during software maintenance.
Because most data and procedural detail are hidden from other
parts of the software, inadvertent errors introduced during
modification are less likely to propagate to other locations
within the software
 7.Functional Independence
• The concept of functional independence is always use in modularity, and in
concept of abstraction and information hiding.
• Functional independence is achieved by developing module with single
minded function and avoidance of excessive interaction with other module.
• Functional independence in software engineering means that when a module
focuses on a single task, it should be able to accomplish it with very little
interaction with other modules.
• Independent modules are easier to maintain (and test) because secondary
effects caused by design or code modification are limited, error propagation is
reduced, and reusable modules are possible. To summarize, functional
independence is a key to good design, and design is the key to software
quality.
• In software engineering, if a module is functionally independent of other
module then it means it has high cohesion and low coupling.
• Functional independence is essential for good software design.
• Cohesion is a natural extension of the information hiding
concept.
• Cohesion is a qualitative indication of the degree to which a
module focuses on just one thing.
• Coupling is a qualitative indication of the degree to which a
module is connected to other modules and to the outside
world.
• 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. In software
design, you should strive for the lowest possible coupling.
Simple connectivity among modules results in software that is
easier to understand and less prone to a “ripple effect” ,
caused when errors occur at one location and propagate
throughout a system
Cohesion Explanatory slides …Just go through once

• Coincidental Cohesion: (worst) A module performs a

set of task that relate to each other loosely
• Logical Cohesion: A module that perform a task that
are related logically is logical cohesion
• Temporal cohesion: when a module contain task that
are related by the fact that all must be executed
within the span of time the module exhibits temporal
cohesion
• Procedural cohesion: When Processing element of module are
related and must be executed in specific order
• Communicational Cohesion: When all processing elements are
concentrated on one area of data structure
• Sequential cohesion: Sequential cohesion is when parts of a
module are grouped because the output from one part is the input
to another part like an assembly line
• Functional cohesion (best) Functional cohesion is when parts of a
module are grouped because they all contribute to a single
well-defined task of the module
• Coupling –
– Coupling s measure of relative interdependence
among modules. It depends on Interface
Complexity.
– In software design, we strive for lowest possible
coupling.
– Simple connectivity among modules results in
software that is easier to understand and less
prone to a "ripple effect", caused when errors
occur at one location and propagate through a
system.
• No coupling Modules do not communicate at all with one
another.
• Data coupling: Data coupling is when modules share data
through the modules
• Stamp coupling : Stamp coupling is when modules share a
composite data structure and use only a part of it, possibly a
different part.
• Control coupling :Control coupling is one module
controlling the flow of another, by passing it information on
what to do
• External coupling- External coupling occurs when two
modules share an externally imposed data format,
communication protocol, or device interface.
• Common coupling: Common coupling is when two
modules share the same global data.
• Content coupling (high): Content coupling is when one
module modifies or relies on the internal workings of
another module
Extra slides ends…Main topic continues on next
slide…next data concept
 8.Refinement
• Refinement is a top-down design approach.
• It is a process of elaboration.
• A program is established for refining levels of procedural details.
• A hierarchy is established by decomposing a statement of function in a
stepwise manner till the programming language statement are reached.
 Refinement
• Stepwise refinement is a top-down design strategy.
• Decomposing statement of function in a stepwise fashion
• Design begins with a statement of function defined at the highest level
of abstraction.The statement describes function or information but does
not provides 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. It will not show the
low-level details.
• Every refinement step implies some design decisions. It is important
that . . . the programmer be aware of the underlying criteria (for design
decisions) and of the existence of alternative solutions . . .
 9. Aspects
● As requirements analysis occurs, a set of “concerns” is uncovered.
● Ideally, a requirements model can be organized in a way that allows you
to isolate each concern (requirement) so that it can be considered
independently. In practice, however, some of these concerns span the
entire system and cannot be easily compartmentalized.
● For example, consider two requirements for the SafeHomeAssured.com
WebApp.
● Requirement A is described via the ACS-DCV use case .A design
refinement would focus on those modules that would enable a registered
user to access video from cameras placed throughout a space.
● Requirement B is a generic security requirement that states that a
registered user must be validated prior to using safeHomeAssured.com.
This requirement is applicable for all functions that are available to
registered SafeHome users. As design refinement occurs, A* is a design
representation for requirement A and B* is a design representation for
requirement B. Therefore, A* and B* are representations of concerns, and
B* crosscuts A*.
● In an ideal context, an aspect is implemented as a separate module
(component) rather than as software fragments that are “scattered” or
“tangled” throughout many components.
● To accomplish this, the design architecture should support a mechanism
for defining an aspect—a module that enables the concern to be
implemented across all other concern that it crosscuts
 10.Refactoring
● An important design activity suggested for many agile methods ,
refactoring is a reorganization technique that simplifies the design (or
code) of a component without changing its function or behavior.
● Fowler [Fow00] 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.
For Example:
● A first design iteration might yield a component that exhibits low
cohesion (i.e., it performs three functions that have only limited
relationship to one another). After careful consideration, you may decide
that the component should be refactored into three separate
components, each exhibiting high cohesion.
● The result will be software that is easier to integrate, easier to test, and
easier to maintain
 11. Object oriented design concepts
● In the object-oriented design method, the system is viewed as a
collection of objects (i.e., entities).
● The state is distributed among the objects, and each object handles its
state data. For example, in a Library Automation Software,each library
representative may be a separate object with its data and functions to
operate on these data.
● Objects have their internal data which represent their state. Similar
objects create a class. In other words, each object is a member of some
class. Classes may inherit features from the superclass.
1. Objects: All entities involved in the solution design are known as
objects. For example, person, banks, company, and users are considered
as objects. Every entity has some attributes associated with it and has
some methods to perform on the attributes.
2. Classes: A class is a generalized description of an object. An object is an
instance of a class. A class defines all the attributes, which an object can
have and methods, which represents the functionality of the object.
3. Messages: Objects communicate by message passing. Messages consist
of the integrity of the target object, the name of the requested
operation, and any other action needed to perform the function.
Messages are often implemented as procedure or function calls.
4. Abstraction In object-oriented design, complexity is handled using
abstraction. Abstraction is the removal of the irrelevant and the
amplification of the essentials.
5. Encapsulation: Encapsulation is also called an information hiding concept. The
data and operations are linked to a single unit. Encapsulation not only bundles
essential information of an object together but also restricts access to the data
and methods from the outside world.

6. Inheritance: OOD allows similar classes to stack up in a hierarchical manner

where the lower or sub-classes can import, implement, and re-use allowed
variables and functions from their immediate superclasses.This property of OOD
is called an inheritance. This makes it easier to define a specific class and to
create generalized classes from specific ones.

7. Polymorphism: OOD languages provide a mechanism where methods

performing similar tasks but vary in arguments, can be assigned the same name.
This is known as polymorphism, which allows a single interface is performing
functions for different types. Depending upon how the service is invoked, the
respective portion of the code gets executed.
 12. Design Classes
The requirements model defines a set of analysis classes . Each describes
some element of the problem domain, focusing on aspects of the problem
that are user visible. The level of abstraction of an analysis class is relatively
high.
As the design model evolves, you will define a set of design classes that refine
the analysis classes by providing design detail that will enable the classes to
be implemented, and implement a software infrastructure that supports the
business solution.
Five different types of design classes, each representing a different layer of
the design architecture, can be developed:
1. User interface classes :Define all abstractions that are necessary for
human computer interaction (HCI). In many cases, HCI occurs within the
context of a metaphor (e.g., a checkbook, an order form, a fax machine),
and the design classes for the interface may be visual representations of
the elements of the metaphor
2. Business domain classes are often refinements of the analysis classes
defined earlier. The classes identify the attributes and services (methods)
that are required to implement some element of the business domain.
3. Process classes implement lower-level business abstractions required to
fully manage the business domain classes.
4. Persistent classes represent data stores (e.g., a database) that will persist
beyond the execution of the software
5. 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.
As the architecture forms, the level of abstraction is reduced as each analysis
class is transformed into a design representation.
Design classes present significantly more technical detail as a guide for
implementation.
They define four characteristics of a well-formed design class:
1. Complete and sufficient. A design class should be the complete
encapsulation of all attributes and methods that can reasonably be
expected (based on a knowledgeable interpretation of the class name) to
exist for the class.
2. 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. For example, In the class VideoClip for
video-editing software ,The methods, setStartPoint() and setEndPoint(),
provide the only means for establishing start and end points for the clip.
3. High cohesion. A cohesive design class has a small, focused set of
responsibilities and single-mindedly applies attributes and methods to
implement those responsibilities
4. 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 (all design classes
collaborate with all other design classes), 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.
II.The Design Model
 Design Model continues
● 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.
● The dashed line indicates the boundary between the analysis and
design models. In some cases, a clear distinction between the analysis
and design models is possible. In other cases, the analysis model slowly
blends into the design and a clear distinction is less obvious.
● The elements of the design model use many of the same UML diagrams
that were used in the analysis model.
● The difference is that these diagrams are refined and elaborated as part
of design; more implementation-specific detail is provided, and
architectural structure and style, components that reside within the
architecture, and interfaces between the components and with the
outside world are all emphasized.
● Model elements indicated along the horizontal axis are not always
developed in a sequential fashion. In most cases preliminary architectural
design sets the stage and is followed by interface design and
component-level design, which often occur in parallel. The deployment
model is usually delayed until the design has been fully developed
 II.1Data Design Elements
Like other software engineering activities, data design (sometimes referred to
as data architecting) creates a model of data and/or information that is
represented at a high level of abstraction (the customer/user’s view of data).
This data model is then refined into progressively more
implementation-specific representations that can be processed by the
computer-based system. In many software applications, the architecture of
the data will have a profound influence on the architecture of the software
that must process it.
The structure of data has always been an important part of software design.
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 (derived as part of
requirements engineering) 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
itsel
 II.2Architectural Design Elements
The architectural design for software is the equivalent to the floor plan of a
house.
Architectural design elements give us an overall view of the software. The
architectural model is derived from three sources:
(1) Information about the application domain for the software to be built;
(2) Specific requirements model elements such as data flow diagrams or
analysis classes, their relationships and collaborations for the problem at
hand; and
(3) The availability of architectural styles
The architectural design element is usually depicted as a set of
interconnected subsystems, often derived from analysis packages within the
requirements model.
Each subsystem may have it’s own architecture (e.g., a graphical user
interface might be structured according to a preexisting architectural style for
user interfaces).
 II.3Interface Design Elements
The interface design for software is analogous to a set of detailed drawings
(and specifications) for the doors, windows, and external utilities of a house.
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.
These interface design elements allow the software to communicate
externally and enable internal communication and collaboration among the
components that populate the software architecture
UI Design/Usability Design:
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). In general, the UI is a unique subsystem
within the overall application architecture.
Design of external interfaces :requires definitive information about the entity
to which information is sent or received. In every case, this information
should be collected during requirements engineering and verified once the
interface design commences.The design of external interfaces should
incorporate error checking and (when necessary) appropriate security
features.
Design of internal interfaces: is closely aligned with component-level design .
Design realizations of analysis classes represent all operations and the
messaging schemes required to enable communication and collaboration
between operations in various classes.
Each message must be designed to accommodate the requisite information
transfer and the specific functional requirements of the operation that has
been requested. If the classic input-process-output approach to design is
chosen, the interface of each software component is designed based on data
flow representations and the functionality described in a processing narrative.
 II.4 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.
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).
The design details of a component can be modeled at many different levels
of abstraction.
● A UML activity diagram can be used to represent processing logic.
● Detailed procedural flow for a component can be represented using
either pseudocode or some other diagrammatic form (e.g., flowchart or
box diagram).
● Algorithmic structure follows the rules established for structured
programming (i.e., a set of constrained procedural constructs).
● Data structures, selected based on the nature of the data objects to be
processed, are usually modeled using pseudocode or the programming
language to be used for implementation.
 II.5 Component level design for web
A WebApp component is
app
(1)A well-defined cohesive (Interrelated) function that manipulates
content or provides computational or data processing for an end user
(2) A cohesive package of content and functionality that provides the
end user with some required capability.
● Therefore, component-level design for WebApps often incorporates
elements of
○ Content design
○ Functional design.
 II.5.1 Content design
● Content Design at the Component Level
○ Content design at the component level focuses on content
objects and the manner in which they may be packaged for
presentation to a WebApp end user.
○ The formality of content design at the component level should be
tuned to the characteristics of the WebApp to be built.
○ However, as the size and complexity (of the WebApp, content
objects, and their interrelationships) grows, it may be necessary
to organize content in a way that allows easier reference and
design.
○ For example, consider a Web-based video surveillance capability
within SafeHomeAssured.com. Among many capabilities, the
user can select and control any of the cameras represented as
part of a floor plan, require video-capture thumbnail images
from all the cameras, and display streaming video from any one
camera.
 II.5.2Functional Design
● Functional Design at the Component Level
○ Modern Web applications deliver increasingly sophisticated
processing functions that
○ (1) Perform localized processing to generate content and
navigation capability in a dynamic fashion,
○ (2) Provide computation or data processing capability that is
appropriate for the WebApp’s business domain,
○ (3) Provide sophisticated database query and access,
○ (4) Establish data interfaces with external corporate systems.
● To achieve these (and many other) capabilities, you will design and
construct WebApp functional components that are similar in form to
software components for conventional software.
 II.6 Deployment-Level Design Elements
Deployment-level design elements indicate how software functionality and
subsystems will be allocated within the physical computing environment that
will support the software.
For example, the elements of the SafeHome product are configured to
operate within three primary computing environments—a home-based PC,
the SafeHome control panel, and a server housed at CPI Corp. (providing
Internet-based access to the system)
During design, a UML deployment diagram is developed and then refined. In
the figure, three computing environments are shown (in actuality, there
would be more including sensors, cameras, and others). The subsystems
(functionality) housed within each computing element are indicated. For
example, the personal computer houses subsystems that implement security,
surveillance, home management, and communications features.
In addition, an external access subsystem has been designed to manage all
attempts to access the SafeHome system from an external source. Each
subsystem would be elaborated to indicate the components that it
implements.
The diagram shown in Figure is in
descriptor form. This means that
the deployment diagram shows the
computing environment but does
not explicitly indicate configuration
details. For example, the “personal
computer” is not further identified.
It could be a Mac or a
Windows-based PC, a Sun
workstation, or a Linux-box. These
details are provided when the
deployment diagram is revisited in
instance form during the latter
stages of design or as construction
begins. Each instance of the
deployment (a specific, named
hardware configuration) is
identified.
 III.Architectural Design
Architectural design begins with data design and then proceeds to the
derivation of one or more representations of the architectural structure of
the system.
Alternative architectural styles or patterns are analyzed to derive the
structure that is best suited to customer requirements and quality attributes.
Once an alternative has been selected, the architecture is elaborated using an
architectural design method.
The software 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
(1) analyze the effectiveness of the design in meeting its stated requirements,
(2) consider architectural alternatives at a stage when making design changes
is still relatively easy, and
(3) reduce the risks associated with the construction of the software
● In the context of architectural design, a software component can be
something as simple as a program module or an object-oriented class,
but it can also be extended to include databases and “middleware” that
enable the configuration of a network of clients and servers. The
properties of components are those characteristics that are necessary for
an understanding of how the components interact with other
components.
● At the architectural level, internal properties (e.g., details of an
algorithm) are not specified. The relationships between components can
be as simple as a procedure call from one module to another or as
complex as a database access protocol
 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”
 Architectural Design: Design Decisions
•A designer is faced with a series of design issues
•There are sub-problems of the overall design problem.
• There Are always several alternative solutions: design options.
•Designer makes design decisions to resolve each issue.
—This process involves choosing the best option from among the
alternatives.

•Recognize that there may be a number of solutions – in fact,

there may be a number of good solutions for the problem to be
solved.
•We would like the ‘best’ one.
 Architectural Design: Design Decisions
•To make each design decision, the software engineer uses:
•Knowledge of
—the requirements (use cases, UI prototype, supplementary
specification document, class diagrams, interaction diagrams …)
—the design as created ‘so far’
—Available technologies (RMI, RPC, xml, jsp, servlets, html, jdbc, etc.
etc.) given a development environment
—Software design principles and ‘best practices’
—What has worked well in the past

•Sometimes there is no single, best solution.

•Sometimes they conflict – each presenting pros and cons
•The space of possible designs that could be achieved by choosing
different sets of alternatives is often called the design space
 IV.Architectural Styles
● Architectural design represents the structure of data and program
components that are required to build a computer-based system.

● It considers the architectural style that the system will take, the
structure and properties of the components that constitute the
system, and the interrelationships that occur among all
architectural components of a system.

● 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.
Architectural style and Patterns
Each style describe a system category that
encompass:
• A set of components ( e.g. database,
computational modules )
• A set of connectors that enable communication,
coordination and cooperation among components
• Constraints that define how components can be
integrated to from the system
• Semantic models that enable a designer to
understand the overall properties of system by
analysis the know properties of its constituent
parts .
 Taxonomy of Architectural Styles
• Data Centered architecture
• Data Flow Architecture
• Call and Return Architecture
• Object Oriented Architecture
• Layered Architecture
IV.1Data Centered Architecture

please refer to page 293 fig

10.1from Roger pressman book
● 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 modify data within
the store.
● Client software accesses a central repository. In some cases
the data repository is passive. That is, client software
accesses the data independent of any changes to the data or
the actions of other client software.
● A variation on this approach transforms the repository into a
“blackboard” that sends notifications to client software
when data of interest to the client change.
● Data-centered architectures promote integrability .
That is, existing components can be changed and new client
components can be added to the architecture without
concern about other clients (because the client components
operate independently).
IV.2Data Flow Architectures

Please refer fig 10.2 page 293 from

Roger pressman book
• 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 has a set of components, called
filters, connected by pipes that transmit data from one
component to the ne x t.
• Each filter works independently of those components
upstream and downstream, and is designed to expect data
input of a certain form, and produces data output (to the next
filter) of a specified form.
• If the data flow degenerates into a single line of transforms, it
is termed batch sequential. This structure accepts a batch of
data and then applies a series of sequential
components(filters) to transform it.
 Main Program Subprogram Architectur
in call and Return Architecture.

Please refer fig 10.3 page 294 from

Roger pressman book
 IV. 3 Call and Return architecture
This architectural style enables a software designer (system
architect) to achieve a program structure that is relatively
easy to modify and scale.
A number of sub styles exist within this category:
• Main program/subprogram architectures. This classic
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.
• Remote procedure call architectures. The components of
a main program/subprogram architecture are distributed
across multiple computers on a network
 IV.4 Layered Architecture

Please refer dia 10.4 on page

295 from Roger pressman book
• A number of different layers are defined, each accomplishing
operations that progressively become closer to the machine
instruction set.
• At the outer layer, components service user interface
operations.
• At the inner layer, components perform operating system
interfacing.
• Intermediate layers provide utility services and application
software functions.
 IV.5 Object-Oriented Architecture
• The components of a system encapsulate data and the
operations that must be applied to manipulate the data.
• Communication and coordination between components
are accomplished via message passing…
EXTRA SLIDES FOR UI DESIGN and INTERFACE
DESIGN…GO THROUGH ONCE FOR
KNOWLEDGE.
U can follow UI design and Interface design in
PBL, MINI projects
 User Interface Design
User interface is the front-end application view to which user interacts in order
to use the software. The software becomes more popular if its user interface is:
● Attractive
● Simple to use
● Responsive in short time
● Clear to understand
● Consistent on all user screens

There are two types of User Interface:

1. Command Line Interface: Command Line Interface provides a command
prompt, where the user types the command and feeds to the system.
The user needs to remember the syntax of the command and its use.
2. Graphical User Interface: Graphical User Interface provides the simple
interactive interface to interact with the system. GUI can be a
combination of both hardware and software. Using GUI, user interprets
the software.

Work product of UI design is user scenarios are created and screen layouts
are generated. An interface prototype is developed and modified in a
iterative fashion
 Golden Rules of UI
Three Golden Rules by Theo Mandel are:
1.Place the user in control
2.Reduce the user’s memory load
3.Make the interface consistent

1.Place the user in control:

● Define the interaction modes in such a way that it does not force the user
into unnecessary or undesired actions: The user should be able to easily enter
and exit the mode with little or no effort.eg. Spell checking mode
● Provide for flexible interaction: Different people will use different interaction
mechanisms, some might use keyboard commands, some might use mouse,
some might use touch screen, etc, Hence all interaction mechanisms should
be provided.
● Allow user interaction to be interruptable and undoable: When a user is
doing a sequence of actions the user must be able to interrupt the sequence
to do some other work without losing the work that had been done. The user
should also be able to do undo operation.
● Streamline interaction as skill level advances and allow the interaction
to be customized: Advanced or highly skilled user should be provided
a chance to customize the interface as user wants which allows
different interaction mechanisms so that user doesn’t feel bored
while using the same interaction mechanism.
● Hide technical internals from casual users: The user should not be
aware of the internal technical details of the system. He should
interact with the interface just to do his work.
● Design for direct interaction with objects that appear on screen: The
user should be able to use the objects and manipulate the objects
that are present on the screen to perform a necessary task. By this,
the user feels easy to control over the screen.
2.Reduce the user’s memory load:
● Reduce demand on short-term memory: When users are involved in
some complex tasks the demand on short-term memory is
significant. So the interface should be designed in such a way to
reduce the remembering of previously done actions, given inputs
and results.This can be done by providing visual cues
● Establish meaningful defaults: Always initial set of defaults should be
provided to the average user, if a user needs to add some new
features then he should be able to add the required features.
● Define shortcuts that are intuitive: Mnemonics should be used by
the user. Mnemonics means the keyboard shortcuts to do some
action on the screen. eg alt P for print
● The visual layout of the interface should be based on a real-world
metaphor: Anything you represent on a screen if it is a metaphor for
● Real-world entity then users would easily understand. eg a bill payment
system should use check book and check register metaphor to guide
user through
● Disclose information in a progressive fashion: The interface should be
organized hierarchically i.e. on the main screen the information about
the task, an object or some behavior should be presented first at a high
level of abstraction. More detail should be presented after the user
indicates interest with a mouse pick.

3.Make the interface consistent:

● Allow the user to put the current task into a meaningful context: Many
interfaces have dozens of screens. So it is important to provide indicators
consistently so that the user know about the doing work.
 The user should also know from which page has navigated to the
current page and from the current page where can navigate.
● Maintain consistency across a family of applications: The
development of some set of applications all should follow and
implement the same design, rules so that consistency is
maintained among applications.
● If past interactive models have created user expectations do not
make changes unless there is a compelling reason. eg alt S for
saving
Interface Analysis
Interface design analysis means understanding:
(1) The people (end-users) who will interact with the system through the
interface;
(2) The tasks that end-users must perform to do their work,
(3) The content that is presented as part of the interface,
(4) The environment in which these tasks will be conducted.
The only way that a designer can get the mental image and the design model to
converge is to work to understand the users themselves as well as how these
people will use the system.
This can be accomplished by:
User Interviews: The software team meets with the end-users to better
understand their needs, motivations, work culture, and a myriad of other issues.
Sales Input: Sales people meet with customers and users to help developers
categorize users and better understand their requirements.
Marketing Input: Market analysis can be invaluable in the definition of market segments
while providing an understanding of how each segment might use the software in
different ways.
Support Input: Support staff talks with users on a daily basis, making them the most likely
source of information on what works and what doesn’t, and what they like and what they
don’t.

The following set of questions help the interface designer better understand the
users of a system:
· Are users trained professionals, technician, clerical, or manufacturing
workers?
· What level of formal education does the average user have?
· Are the users capable of learning from written materials or have they
expressed a desire for classroom training?
· Are users’ expert typists or keyboard phobic?
· What are the consequences if a user makes a mistake using the system?
 Is the software to be an integral part of the work users do or will it be
used only occasionally?
The answers to these and similar questions will allow the designer to
understand who the end-users are, what is likely to motivate and please
them, how they can be grouped into different user classes or profiles, what
their mental models of the system are and how the user interface must be
characterized to meet their needs.
Task Analysis and Modeling
The goal of task analysis is to answer the following questions:
What work will the user perform in specific circumstances?
● What tasks and subtasks will be performed as the user does the work?
● What specific problem domain objects will the user manipulate as
work is performed?
● What is the sequence of work tasks—the workflow?
● What is the hierarchy of tasks?
The techniques below are applied to the user interface:

● Use-cases define basic interaction

● Task elaboration refines interactive tasks
● Object elaboration identifies interface objects (classes)
● Workflow analysis defines how a work process is completed when
several people (and roles) are involved
 Interface Design Steps
Once interface analysis has been completed, all tasks required by the
end-user have been identified in detail.Interface design is an iterative
process.Each user interface design step occurs a number of time ,each
elaborating and refining information developed in preceding step
1. Using information developed during interface analysis , define interface
objects and actions (operations).
2. Define events (user actions) that will cause the state of the user interface
to change. Model this behavior.
3. Depict each interface state as it will actually look to the end-user.
4. Indicate how the user interprets the state of the system from information
provided through the interface.
Interface Design Patterns

Various design patterns are selected

Patterns are available for

● The complete UI
● Page layout
● Forms and input
● Tables
● Direct data manipulation
● Navigation
● Searching
● Page elements
● e-Commerce
 Design Issues
As the design of the system evolves following issues need to be addressed in design
steps
· Response time: System response time has two important characteristics:
length ( should not be too long) and variability. Variability refers to the deviation
from average response time.
· Help facilities: Help must be available for all system functions. Include help
menus, print documents.
· Error handling: Describe the problem in a language the user can understand.
Never blame the user for the error that occurred.
· Menu and command labeling: Menu options should have corresponding
commands. Use control sequences for commands.
· Application accessibility: Especially for the physically challenged.
· Internationalization: The Unicode standard has been developed to address
the daunting challenge of managing dozens of natural languages with hundred of
characters and symbols.
 Design Evaluation
Once an operational UI prototype has been created , it must be evaluated to
determine whether it meets with the needs of the user.
Evaluation can be your informal “test drive “ in which user provides promptu
feedback to a formally designed study that uses statistical methods for the
evaluation of questionnaires by end users.
After the design model has been completed a first level prototype is created
Two interface design evaluation techniques are mentioned in this section, usability
questionnaires and usability testing. The process of learning how to design good
user interfaces often begins with learning to identify the weaknesses in existing
products.
Once the first prototype is built, the designer can collect a variety of qualitative
and quantitative data that will assess in evaluating the interface. Questions can be
a simple Y/N response, numeric response, scaled response, Likert scale (strongly
agree, etc.), percentage response, and open-ended ones
EXTRA SLIDES END