DESIGN ENGINEERING

MODULE-04
TEIT(Sem-V) Revised 2019 ‘C’ Scheme
SOFTWARE DESIGN
• Software Design is the process to transform the user requirements into some
suitable form, which helps the programmer in software coding and
implementation.
• Software design is the process of creating a blueprint or plan for a software system
to meet a set of specific requirements. It involves transforming abstract user needs,
defined during the analysis phase, into a concrete, well-structured design that guides
the coding and implementation phase. A solid design is essential for creating
high-quality systems that are easy to maintain, reuse, and scale over time
• 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.

2
SOFTWARE DESIGN
•Following items are designed and documented during 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.

3
SOFTWARE DESIGN
•Objectives:
• Correctness: A good design should be correct i.e. it should correctly
implement all the functionalities of the system.
• Efficiency: A good software design should address the resources, time,
and cost optimization issues.
• Understandability: A good design should be easily understandable, for
which it should be modular and all the modules are arranged in layers.
• Completeness: The design should have all the components like data
structures, modules, and external interfaces, etc.
• Maintainability: A good software design should be easily amenable to
change whenever a change request is made from the customer side.

4
SOFTWARE QUALITY
• Software Quality Guidelines:
• A design is generated using the recognizable architectural styles and compose
a good design characteristic of components and it is implemented in
evolutionary manner for testing.
• A design of the software must be modular i.e the software must be logically
partitioned into elements.
• In design, the representation of data , architecture, interface and components
should be distinct.
• A design must carry appropriate data structure and recognizable data patterns.
• Design components must show the independent functional characteristic.
• A design creates an interface that reduce the complexity of connections
between the components.
• A design must be derived using the repeatable method.
• The notations should be use in design which can effectively communicates its
meaning.

5
SOFTWARE QUALITY
• Software Quality Attributes (FURPS):
• Functionality: It evaluates the feature set and capabilities of the program.
• Usability: It is accessed by considering the factors such as human factor, overall
aesthetics, consistency and documentation.
• Reliability: It is evaluated by measuring parameters like frequency and security
of failure, output result accuracy, the mean-time-to-failure(MTTF), recovery
from failure and the program predictability.
• Performance: It is measured by considering processing speed, response time,
resource consumption, throughput and efficiency.
• Supportability:
• It combines the ability to extend the program, adaptability, serviceability. These three
term defines the maintainability.
• Testability, compatibility and configurability are the terms using which a system can be
easily installed and found the problem easily.
• Supportability also consists of more attributes such as compatibility, extensibility, fault
tolerance, modularity, reusability, robustness, security, portability, scalability.
6
Software Quality Attributes (FURPS):
1. Functionality (F)
Defines what the software should do — its features, capabilities, and security
aspects.
2. Usability (U)
Refers to how easy and pleasant the software is to use. It includes user
interface design, accessibility, and learnability.
3. Reliability (R)
Indicates how dependable the system is — whether it performs consistently
under specified conditions.
Includes availability, fault tolerance, and recovery.
7
• 4. Performance (P)
• Measures how well the system performs under various conditions —
includes response time, throughput, resource usage, and efficiency.
• 5. Supportability (S)
• Refers to how easily the software can be maintained, updated,
configured, or extended.
• Includes testability, flexibility, and compatibility.

8
SOFTWARE DESIGN CONCEPTS
1. Abstraction
• A solution is stated in large terms using the language of the problem environment at
the highest level abstraction.
• The lower level of abstraction provides a more detail description of the solution.
• A sequence of instruction that contain a specific and limited function refers in a
procedural abstraction.
• A collection of data that describes a data object is a data abstraction.
2. Architecture
• The complete structure of the software is known as software architecture.
• Structure provides conceptual integrity for a system in a number of ways.
• The architecture is the structure of program modules where they interact with each
other in a specialized way.
• The components use the structure of data.
• The aim of the software design is to obtain an architectural framework of a system.
• The more detailed design activities are conducted from the framework.
9
SOFTWARE DESIGN CONCEPTS
3. Patterns
• A design pattern describes a design structure and that structure solves a
particular design problem in a specified content.
4. Modularity
• A software is separately divided into name and addressable components.
Sometime they are called as modules which integrate to satisfy the
problem requirements.
• Modularity is the single attribute of a software that permits a program to
be managed easily.
5. 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.
10
SOFTWARE DESIGN CONCEPTS
6. Functional independence
• The functional independence is the concept of separation and related to
the concept of modularity, abstraction and information hiding.
• The functional independence is accessed using two criteria i.e. Cohesion
and coupling.
• Cohesion
• Cohesion is an extension of the information hiding concept.
• A cohesive module performs a single task and it requires a small interaction with
the other components in other parts of the program.
• Coupling
• Coupling is an indication of interconnection between modules in a structure of
software.

11
SOFTWARE DESIGN CONCEPTS
7. 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.
8. Refactoring
• It is a reorganization technique which simplifies the design of components
without changing its function behavior.
• Refactoring is the process of changing the software system in a way that it
does not change the external behavior of the code still improves its internal
structure.
9. Design classes
• The model of software is defined as a set of design classes.
• Every class describes the elements of problem domain and that focus on
features of the problem which are user visible.
12
Design concepts are the fundamental principles that guide how a software
system is structured and developed. They ensure that the system is
well-organized, efficient, and easy to maintain.
• Abstraction – Focus on essential features while hiding unnecessary details.
Example: A “print” function hides the complex printer operations from the
user.
• Refinement – Step-by-step elaboration of the design from a high-level idea to
detailed implementation.
Example: Breaking “process order” into smaller steps like verify, bill, and
dispatch.
• Modularity – Dividing the system into smaller, independent modules that can
be developed and tested separately. Example: Login module, payment
module, and order-tracking module in an app.
13
• Cohesion – Each module should perform a single, well-defined task. Measures how
well elements within a module belong together. High cohesion is desirable.
• Example: A billing module should only handle billing-related operations.
• Coupling – The degree of dependency between modules should be minimal. Example:
The payment module should not directly depend on the user profile module. Degree of
interdependence between modules. Low coupling is preferred.
• Information Hiding – Internal details of a module are hidden from others; only
necessary interfaces are exposed. Example: A database module hides how data is stored
and only provides query functions.

14
THE DESIGN MODEL
• The design model can
be viewed in two
different dimensions:
• Process dimension
indicates the evolution
of the design model as
design tasks are
executed as part of the
software process.
• Abstraction dimension
represents the level of
detail as each element
of the analysis model is
transformed into a
design equivalent and
then refined
iteratively.

15
THE DESIGN MODEL
• Types of Design Elements:
1. Data Design Elements
• The data design element produced a model of data that represent a high level of abstraction.
• This model is then more refined into more implementation specific representation which is processed by the
computer based system.
• The structure of data is the most important part of the software design. Defines how data will be stored,
organized, and accessed.
Example: Designing databases, data structures, and ER diagrams for an online shopping system.
2. Architectural Design Elements
• The architecture design elements provides us overall view of the system.
• The architectural design element is generally represented as a set of interconnected subsystem that are derived
from analysis packages in the requirement model.
• The architecture model is derived from following sources:
• The information about the application domain to built the software.
• Requirement model elements like data flow diagram or analysis classes, relationship and collaboration between
them.
• The architectural style and pattern as per availability.
• Example: A 3-tier architecture with presentation, business, and data layers.

16
THE DESIGN MODEL
•Types of Design Elements:
3. Interface Design Elements
• The interface design elements for software represents the information flow
within it and out of the system.
• They communicate between the components defined as part of architecture.
• Following are the important elements of the interface design:
• The user interface
• The external interface to the other systems, networks etc.
• The internal interface between various components.
• Specifies how users and other systems will interact with the
[Link]: UI screens, input forms, menus, and API interfaces.

17
THE DESIGN MODEL
•Types of Design Elements:
4. Component Level Design Elements
• The component level design for software is similar to the set of detailed
specification of each room in a house.
• The component level design for the software completely describes the internal
details of the each software component.
• The processing of data structure occurs in a component and an interface which
allows all the component operations.
• In a context of object-oriented software engineering, a component shown in a
UML diagram.
• Details the internal structure of each module or [Link]: Class diagrams
and logic for payment processing or user authentication.

18
THE DESIGN MODEL
•Types of Design Elements:
5. Deployment Level Design Elements
• The deployment level design element
shows the software functionality and
subsystem that allocated in the physical
computing environment which support
the software.
• Following figure shows three computing
environment as shown. These are the
personal computer, the CPI server and the
Control panel.

19
PATTERN BASED SOFTWARE DESIGN
•In software engineering, a software design pattern is a general,
reusable solution to a commonly occurring problem within a given
context in software design.
•It is not a finished design that can be transformed directly into
source or machine code. Rather, it is a description or template for
how to solve a problem that can be used in many different
situations.
•Design patterns are formalized best practices that the programmer
can use to solve common problems when designing an application
or system.

20
PATTERN BASED SOFTWARE DESIGN
•Design patterns can speed up the development process by
providing tested, proven development paradigms.
•Effective software design requires considering issues that may not
become visible until later in the implementation.
•Freshly written code can often have hidden subtle issues that take
time to be detected, issues that sometimes can cause major
problems down the road.
•Reusing design patterns helps to prevent such subtle issues, and it
also improves code readability for coders and architects who are
familiar with the patterns.

21
PATTERN BASED SOFTWARE DESIGN
•Categories of Software Design Patterns:
• Creational Patterns:
• Creational patterns emphasize the automatic creation of objects within code,
rather than requiring you to instantiate objects directly.
• In most cases, this means that a function or method can call the code necessary
to instantiate new objects on your behalf, so you only need to explicitly modify
that object creation when it is necessary, and allow default behaviors to take over
otherwise.
• Abstract Factory:
• Encapsulates groups of factories based on common themes.
• Often uses polymorphism, the concept in object-oriented programming that allows
one interface to serve as a basis for multiple functions of different types.
• Builder:
• Splits up the construction of an object from its representation.
• This is usually done by defining a Builder object that presents methods to update the
object, without directly interacting with the object itself.
22
PATTERN BASED SOFTWARE DESIGN
•Categories of Software Design Patterns:
• Creational Patterns:
• Factory:
• Creates objects without the need to specify the exact class or type of object to be
created.
• As the name suggests, this object instantiation is performed through a secondary
Factory class, again using polymorphism.
• Prototype:
• Creates new objects by prototyping or cloning a prototypical instance of an object.
• Effectively, an abstract Prototype class is created, and from that base prototype, new
secondary inherited classes are defined.
• Singleton:
• Restricts the total number of instances of a particular class to only one at a time.
• This is commonly used when global access to the object is required across the
system, and any changes or queries to the object must be consistent and identical.

23
PATTERN BASED SOFTWARE DESIGN
•Categories of Software Design Patterns:
• Structural Patterns:
• Structural patterns focus on the composition of classes and objects.
• By using inheritance and interfaces, these patterns allow objects to be composed
in a manner that provides new functionality.
• In most cases, an interface in object-oriented programming is an abstract type or
class which has no logical code, but instead is used to define method signatures
and behaviors for other classes that will implement the interface.
• Adapter:
• Allows for an interface, which is otherwise incompatible, to be adapted to fit a new class.
• Typically, this is performed by creating a new ClassNameAdapter class that implements the
interface, allowing for compatibility across the system.
• Bridge:
• Distinguishes between implementation and abstraction. Or, put another way, it’s a pattern
that separates the “look and feel” of code from the “logical behavior” of it, which we often
see in websites and other visual applications.

24
PATTERN BASED SOFTWARE DESIGN
•Categories of Software Design Patterns:
• Structural Patterns:
• Composite:
• Groups of objects should behave the same as individual objects from within that
group.
• Primarily useful when creating a collection of objects that inherit from the same type,
yet are uniquely different types themselves.
• Since they are of the same composition type, their behavior should be identical when
combined into a collective group.
• Decorator:
• Dynamically modifies the behavior of an object at run time, typically by wrapping the
object in a decorator class.
• This pattern is commonly used when an object is instantiated, but as code execution
progresses, modifications must be made to the object before it is finalized.

25
PATTERN BASED SOFTWARE DESIGN
•Categories of Software Design Patterns:
• Structural Patterns:
• Facade:
• Creates a front-end (facade) object that obfuscates and simplifies interactions
between it and the more complicated interface behind it.
• Commonly used when a complex series of actions must take place to perform a task,
where executing each and every task, in order, is too complicated.
• Instead, a simple facade replaces that series of tasks with a single task to be
executed.
• Flyweight:
• Reduces memory and resource usage by sharing data with other, similar objects.
• Often relies heavily on Factory-style patterns to access and store already generated
data during future executions.

26
PATTERN BASED SOFTWARE DESIGN
•Categories of Software Design Patterns:
• Structural Patterns:
• Proxy:
• Defines a wrapper class for an object, which acts as an interface for the wrapped
object.
• Typically, the proxy class attaches additional behavior onto the wrapped object,
without the need to modify the base object class behavior.

27
PATTERN BASED SOFTWARE DESIGN
•Categories of Software Design Patterns:
• Behavioral Patterns:
• Behavioral patterns are concerned with communication and assignment between
objects.
• Chain of Responsibility:
• Forces execution to follow a specific chain of command during execution, such that
the first object is used, then the second, and so on.
• Often used as a failsafe in applications, checking the validity of the primary object,
before moving onto the secondary object if the primary fails, and so forth.
• Command:
• Decouples the actions of the client from the behavior of the receiver.
• Often through the use of an interface, an object can specify individual behavior when
a particular command is invoked, while a different object type can use that same
command, but invoke its own unique behavior instead.

28
PATTERN BASED SOFTWARE DESIGN
• Categories of Software Design Patterns:
• Behavioral Patterns:
• Interpreter:
• Defines a series of classes used to interpret language syntax from a provided sentence.
• Typically, each symbol is defined by one class, and then a syntax tree is used to parse
(interpret) the overall sentence.
• Iterator:
• Allows access to underlying elements of an object, without exposing those elements or their
respective logic.
• A very commonly used pattern, often as a simple means of fetching the next item in a list or
array of objects.
• Mediator:
• Generates a third party object (mediator) that acts as a go-between for interactions
between two other similar objects (colleagues).
• Commonly, this is used when multiple objects need to communicate, but do not (or should
not) be aware of the others respective implementation or behavior.
29
PATTERN BASED SOFTWARE DESIGN
• Categories of Software Design Patterns:
• Behavioral Patterns:
• Memento:
• Stores the state of an object, allowing for restoration (rollback) of the object to a previous
state.
• This behavior is well-known when using word processors that implement the undo feature.
• Observer:
• Creates an event-based dependency between objects, such that an update to the observed
object causes the observer objects to be notified.
• Typically, this is found in many languages that utilize asynchronous functionality, which
requires events to be observed and responded to outside of typical execution order.
• State:
• Allows for the behavior of a class to change based on the current state.
• While these states are often changed throughout execution, the implementation of each
possible state is typically defined by a unique class interface.

30
PATTERN BASED SOFTWARE DESIGN
• Categories of Software Design Patterns:
• Behavioral Patterns:
• Strategy:
• Defines a pattern where logical strategy changes based on the current situation.
• This is merely an object-oriented extension of common if-else statements, by altering the
execution of code based on the outcome of previous code.
• Template:
• Allows for a skeletal template to be used as the basis for execution, without defining the
inner-workings of any individual class or object.
• This is commonly seen in web applications, where the visual interface of the application is
generated using templates, which are created using underlying data, but neither the
template nor the underlying data are aware of the implementation of the other.
• Visitor:
• Allows for new operations to be added to objects without modifying their original
implementation structures.
• Typically, the visitor class defines unique methods that are shared between it and other
objects, without the need for the other object to be aware of the additional functionality.

31
ARCHITECTURAL DESIGN
•Architectural design is concerned with understanding how a
system should be organized and designing the overall structure of
that system.
•Architectural design is the first stage in the software design
process.
•It is the critical link between design and requirements engineering,
as it identifies the main structural components in a system and the
relationships between them.
•The output of the architectural design process is an architectural
model that describes how the system is organized as a set of
communicating components.
32
ARCHITECTURAL DESIGN
•The design process for identifying the sub-systems making up a
system and the framework for sub-system control and
communication is architectural design.
•The output of this design process is a description of the software
architecture.
•An early stage of the system design process.
•Represents the link between specification and design processes.
•Often carried out in parallel with some specification activities.
•It involves identifying major system components and their
communications.
33
ARCHITECTURAL DESIGN
•Architecture of Packing Robot Control System:

34
ARCHITECTURAL DESIGN
•Architectural Abstraction
• In practice, there is a significant overlap between the processes of
requirements engineering and architectural design.
• Ideally, a system specification should not include any design information.
This is unrealistic except for very small systems.
• Architectural decomposition is usually necessary to structure and
organize the specification.
• Therefore, as part of the requirements engineering process, you might
propose an abstract system architecture where you associate groups of
system functions or features with large-scale components or
sub-systems.
• You can then use this decomposition to discuss the requirements and
features of the system with stakeholders.
35
ARCHITECTURAL DESIGN
•Architectural Abstraction
• You can design software architectures at two levels of abstraction:
1. Architecture in the small is concerned with the architecture of individual
programs. At this level, we are concerned with the way that an individual
program is decomposed into components.
2. Architecture in the large is concerned with the architecture of complex
enterprise systems that include other systems, programs, and program
components. These enterprise systems are distributed over different
computers, which may be owned and managed by different companies.

36
ARCHITECTURAL DESIGN
•Advantages of explicitly designing and documenting software
architecture:
• Stakeholder communication: The architecture is a high-level
presentation of the system that may be used as a focus for discussion by
a range of different stakeholders.
• System analysis: Making the system architecture explicit at an early stage
in the system development requires some analysis. Architectural design
decisions have a profound effect on whether or not the system can meet
critical requirements such as performance, reliability, and maintainability.
• Large-scale reuse: A model of a system architecture is a compact,
manageable description of how a system is organized and how the
components interoperate. The system architecture is often the same for
systems with similar requirements and so can support large-scale
software reuse.
37
ARCHITECTURAL DESIGN
•Advantages of explicitly designing and documenting software
architecture:
• Stakeholder communication: The architecture is a high-level
presentation of the system that may be used as a focus for discussion by
a range of different stakeholders.
• System analysis: Making the system architecture explicit at an early stage
in the system development requires some analysis. Architectural design
decisions have a profound effect on whether or not the system can meet
critical requirements such as performance, reliability, and maintainability.
• Large-scale reuse: A model of a system architecture is a compact,
manageable description of how a system is organized and how the
components interoperate. The system architecture is often the same for
systems with similar requirements and so can support large-scale
software reuse.
38
ARCHITECTURAL DESIGN
•Architectural Design Decisions:
• Architectural design is a creative process where you design a system
organization that will satisfy the functional and non-functional
requirements of a system.
• Because it is a creative process, the activities within the process depend
on the type of system being developed, the background and experience
of the system architect, and the specific requirements for the system.
• It is therefore useful to think of architectural design as a series of
decisions to be made rather than a sequence of activities.

39
ARCHITECTURAL DESIGN
• Architectural Design Decisions:
• During the architectural design process, system architects have to make a
number of structural decisions that profoundly affect the system and its
development process.
• Based on their knowledge and experience, they have to consider the following
fundamental questions about the system:
1. Is there a generic application architecture that can act as a template for the system
that is being designed?
2. How will the system be distributed across a number of cores or processors?
3. What architectural patterns or styles might be used?
4. What will be the fundamental approach used to structure the system?
5. How will the structural components in the system be decomposed into
subcomponents?
6. What strategy will be used to control the operation of the components in the system?
7. What architectural organization is best for delivering the non-functional requirements
of the system?
8. How will the architectural design be evaluated?
9. How should the architecture of the system be documented?
40
ARCHITECTURAL DESIGN
•Architectural pattern:
• The architecture of a software system may be based on a particular
architectural pattern or style.
• An architectural pattern is a description of a system organization, such as
a client–server organization or a layered architecture.
• Architectural patterns capture the essence of an architecture that has
been used in different software systems.
• You should be aware of common patterns, where they can be used, and
their strengths and weaknesses when making decisions about the
architecture of a system.

41
ARCHITECTURAL DESIGN
•Software Architectural Characteristics:
• Performance: If performance is a critical requirement, the architecture
should be designed to localize critical operations within a small number
of components, with these components all deployed on the same
computer rather than distributed across the network.
• Security: If security is a critical requirement, a layered structure for the
architecture should be used, with the most critical assets protected in the
innermost layers, with a high level of security validation applied to these
layers.
• Safety: If safety is a critical requirement, the architecture should be
designed so that safety-related operations are all located in either a
single component or in a small number of components.

42
ARCHITECTURAL DESIGN
•Software Architectural Characteristics:
• Availability: If availability is a critical requirement, the architecture
should be designed to include redundant components so that it is
possible to replace and update components without stopping the
system.
• Maintainability: If maintainability is a critical requirement, the system
architecture should be designed using fine-grain, self-contained
components that may readily be changed.
•Evaluating an architectural design is difficult because the true test
of an architecture is how well the system meets its functional and
non-functional requirements when it is in use.

43
ARCHITECTURAL DESIGN
•Architectural Views:
• It is impossible to represent all relevant information about a system’s
architecture in a single architectural model, as each model only shows
one view or perspective of the system.
• It might show how a system is decomposed into modules, how the
run-time processes interact, or the different ways in which system
components are distributed across a network.
• All of these are useful at different times so, for both design and
documentation, you usually need to present multiple views of the
software architecture.

44
ARCHITECTURAL DESIGN
•4+1 View Model of Software Architecture:
1. A logical view, which shows the key abstractions in the system as
objects or object classes. It should be possible to relate the system
requirements to entities in this logical view.
2. A process view which shows how, at run-time, the system is composed
of interacting processes.
3. A development view, which shows how the software is decomposed
for development, that is, it shows the breakdown of the software into
components that are implemented by a single developer or
development team.
4. A physical view, which shows the system hardware and how software
components are distributed across the processors in the system.

45
ARCHITECTURAL DESIGN
•Architectural Patterns:
• An architectural pattern is a stylized, abstract description of good
practice, which has been tried and tested in different systems and
environments.
• An architectural pattern should describe a system organization that has
been successful in previous systems. It should include information of
when it is and is not appropriate to use that pattern, and the pattern’s
strengths and weaknesses.

46
ARCHITECTURAL DESIGN
•Architectural Patterns:
• Example: (The Model-View-Controller) Pattern

47
48
ARCHITECTURAL DESIGN
•Architectural Patterns:
• MVC Organization

49
ARCHITECTURAL DESIGN
•Architectural Patterns:
• Web Application Architecture using MVC Architecture Pattern

50
ARCHITECTURAL DESIGN
•Architectural Patterns (Widely used Pattern Examples)
• Layered Architecture

51
ARCHITECTURAL DESIGN
•Architectural Patterns (Widely used
Pattern Examples)
• Layered Architecture
• The lowest layer includes system support
software—typically database and operating
system support.
• The next layer is the application layer that
includes the components concerned with the
application functionality and utility components
that are used by other application components.
• The third layer is concerned with user interface
management and providing user authentication
and authorization, with the top layer providing
user interface facilities.
52
ARCHITECTURAL DESIGN
•Architectural Patterns (Widely used Pattern Examples)
• Layered Architecture of LIBSYS

53
ARCHITECTURAL DESIGN
•Architectural Patterns (Widely used Pattern Examples)
• Repository Architecture

54
ARCHITECTURAL DESIGN
•Architectural Patterns (Widely used Pattern Examples)
• Repository Architecture for an IDE

55
ARCHITECTURAL DESIGN
•Architectural Patterns (Widely used Pattern Examples)
• Client-Server Architecture

56
ARCHITECTURAL DESIGN
•Architectural Patterns (Widely used Pattern Examples)
• Client-Server Architecture Components:
1. A set of servers that offer services to other components.
2. A set of clients that call on the services offered by servers.
• There will normally be several instances of a client program executing concurrently
on different computers.
3. A network that allows the clients to access these services. Most client–server
systems are implemented as distributed systems, connected using Internet
protocols.

57
ARCHITECTURAL DESIGN
•Architectural Patterns (Widely used Pattern Examples)
• Client-Server Architecture Example (Film Library)

58
ARCHITECTURAL DESIGN
•Architectural Patterns (Widely used Pattern Examples)
• Pipe & Filter Architecture
• This is a model of the run-time organization of a system where functional
transformations process their inputs and produce outputs.
• Data flows from one to another and is transformed as it moves through the
sequence.
• Each processing step is implemented as a transform. Input data flows through
these transforms until converted to output.
• The transformations may execute sequentially or in parallel. The data can be
processed by each transform item by item or in a single batch.

59
ARCHITECTURAL DESIGN
•Architectural Patterns (Widely used Pattern Examples)
• Pipe & Filter Architecture
• The name ‘pipe and filter’ comes from the original Unix system where it was
possible to link processes using ‘pipes’.
• These passed a text stream from one process to another.
• Systems that conform to this model can be implemented by combining Unix
commands, using pipes and the control facilities of the Unix shell.
• The term ‘filter’ is used because a transformation ‘filters out’ the data it can
process from its input data stream.

60
ARCHITECTURAL DESIGN
•Architectural Patterns (Widely used Pattern Examples)
• Pipe & Filter Architecture

61
ARCHITECTURAL DESIGN
•Architectural Patterns (Widely used Pattern Examples)
• Pipe & Filter Architecture Example

62
ARCHITECTURAL DESIGN
•Application Architectures
• Application systems are intended to meet a business or organizational
need. All businesses have much in common—they need to hire people,
issue invoices, keep accounts, and so on.
• Businesses operating in the same sector use common sector specific
applications. Therefore, as well as general business functions, all phone
companies need systems to connect calls, manage their network, issue
bills to customers, etc.
• Consequently, the application systems used by these businesses also
have much in common.
• These commonalities have led to the development of software
architectures that describe the structure and organization of particular
types of software systems.
63
ARCHITECTURAL DESIGN
•Application Architectures
• Application architectures encapsulate the principal characteristics of a
class of systems.
• For example, in real-time systems, there might be generic architectural
models of different system types, such as data collection systems or
monitoring systems.
• Although instances of these systems differ in detail, the common
architectural structure can be reused when developing new systems of
the same type.

64
ARCHITECTURAL DESIGN
•Application Architectures
• Ways of Implementation:
• As a starting point for the architectural design process: If you are unfamiliar with
the type of application that you are developing, you can base your initial design
on a generic application architecture. Of course, this will have to be specialized for
the specific system being developed, but it is a good starting point for design.
• As a design checklist: If you have developed an architectural design for an
application system, you can compare this with the generic application
architecture. You can check that your design is consistent with the generic
architecture.
• As a way of organizing the work of the development team: The application
architectures identify stable structural features of the system architectures and in
many cases, it is possible to develop these in parallel. You can assign work to
group members to implement different components within the architecture.

65
ARCHITECTURAL DESIGN
•Application Architectures
• Ways of Implementation:
• As a means of assessing components for reuse: If you have components you
might be able to reuse, you can compare these with the generic structures to see
whether there are comparable components in the application architecture.
• As a vocabulary for talking about types of applications: If you are discussing a
specific application or trying to compare applications of the same types, then you
can use the concepts identified in the generic architecture to talk about the
applications.

66
ARCHITECTURAL DESIGN
•Application Architectures Types:
• Transaction Processing Systems:
• Transaction processing (TP) systems are designed to process user requests for
information from a database, or requests to update a database.
• Technically, a database transaction is sequence of operations that is treated as a
single unit (an atomic unit).
• All of the operations in a transaction have to be completed before the database
changes are made permanent.
• This ensures that failure of operations within the transaction does not lead to
inconsistencies in the database.

67
ARCHITECTURAL DESIGN
•Application Architectures Types:
• Transaction Processing Systems:
• Transaction processing (TP) systems are designed to process user requests for
information from a database, or requests to update a database.
• Technically, a database transaction is sequence of operations that is treated as a
single unit (an atomic unit).
• All of the operations in a transaction have to be completed before the database
changes are made permanent.
• This ensures that failure of operations within the transaction does not lead to
inconsistencies in the database.

68
ARCHITECTURAL DESIGN
•Application Architectures Types:
• Transaction Processing Systems Example (ATM Machine)

69
ARCHITECTURAL DESIGN
•Application Architectures Types:
• Information Systems
• An information system allows controlled access to a large base of information,
such as a library catalog, a flight timetable, or the records of patients in a hospital.
• Increasingly, information systems are web-based systems that are accessed
through a web browser.

70
ARCHITECTURAL DESIGN
•Application Architectures Types:
• Information Systems Example (MHC-PMS)
• MHC-PMS is a Mental Health Care-Patient Management System

71
ARCHITECTURAL DESIGN
•Application Architectures Types:
• Language Processing Systems
• Language processing systems translate a natural or artificial language into another
representation of that language and, for programming languages, may also
execute the resulting code.
• In software engineering, compilers translate an artificial programming language
into machine code.
• Other language-processing systems may translate an XML data description into
commands to query a database or to an alternative XML representation.
• Natural language processing systems may translate one natural language to
another e.g., French to Norwegian.

72
ARCHITECTURAL DESIGN
•Application Architectures Types:
• Language Processing Systems

73
ARCHITECTURAL DESIGN
•Application Architectures Types:
• Language Processing Systems Example (Compiler Architecture)

74
ARCHITECTURAL DESIGN
• Application Architectures Types:
• Language Processing Systems Example
(Compiler Architecture)
1. A lexical analyzer, which takes input
language tokens and converts them to an
internal form.
2. A symbol table, which holds information
about the names of entities (variables, class
names, object names, etc.) used in the text
that is being translated.
3. A syntax analyzer, which checks the syntax
of the language being translated. It uses a
defined grammar of the language and
builds a syntax tree.
4. A syntax tree, which is an internal structure
representing the program being compiled.
75
ARCHITECTURAL DESIGN
•Application Architectures Types:
• Language Processing Systems Example
(Compiler Architecture)
5. A semantic analyzer that uses information
from the syntax tree and the symbol table
to check the semantic correctness of the
input language text.
6. A code generator that ‘walks’ the syntax
tree and generates abstract machine code.

76
ARCHITECTURAL DESIGN
•Application Architectures Types:
• Language Processing Systems as an Integrated Tool(Repository
Architecture):

77
COMPONENT-LEVEL DESIGN
• A component is a modular, portable, replaceable, and reusable set of
well-defined functionality that encapsulates its implementation and
exporting it as a higher-level interface.
• A component is a software object, intended to interact with other
components, encapsulating certain functionality or a set of functionalities.
• A software component can be defined as a unit of composition with a
contractually specified interface and explicit context dependencies only.
That is, a software component can be deployed independently and is
subject to composition by third parties.

78
COMPONENT-LEVEL DESIGN
•Views of Component:
• Object Oriented View:
• A component is viewed as a set of one or more cooperating classes.
• Each problem domain class (analysis) and infrastructure class (design) are
explained to identify all attributes and operations that apply to its
implementation.
• It also involves defining the interfaces that enable classes to communicate and
cooperate.
• Conventional View:
• It is viewed as a functional element or a module of a program that integrates:
1. The processing logic, the internal data structures that are required to implement
the processing logic.
2. An interface that enables the component to be invoked and data to be passed to it.

79
COMPONENT-LEVEL DESIGN
•Views of Component:
• Process Related View:
• In this view, instead of creating each component from scratch, the system is
building from existing components maintained in a library.
• As the software architecture is formulated, components are selected from the
library and used to populate the architecture.

80
COMPONENT-LEVEL DESIGN
•Designing Class Based Components:
• When an object-oriented software engineering approach is chosen,
component-level design focuses on the elaboration of problem domain
specific classes and the definition and refinement of infrastructure
classes contained in the requirements model.
• The detailed description of the attributes, operations, and interfaces
used by these classes is the design detail required as a precursor to the
construction activity.

81
COMPONENT-LEVEL DESIGN
•Designing Class Based Components:
• Basic Design Principles:
• The Open-Closed Principle (OCP): “A module [component] should be open for
extension but closed for modification”
• Stated simply, you should specify the component in a way that allows it to be
extended (within the functional domain that it addresses) without the need to make
internal (code or logic-level) modifications to the component itself.
• To accomplish this, you create abstractions that serve as a buffer between the
functionality that is likely to be extended and the design class itself.
• The Liskov Substitution Principle (LSP): “ Subclasses should be substitutable for
their base classes”
• It suggests that a component that uses a base class should continue to function
properly if a class derived from the base class is passed to the component instead.
• LSP demands that any class derived from a base class must honor any implied
contract between the base class and the components that use it.
82
COMPONENT-LEVEL DESIGN
•Designing Class Based Components:
• Basic Design Principles:
• Dependency Inversion Principle (DIP): “ Depend on abstractions. Do not depend
on concretions”
• The more a component depends on other concrete components (rather than on
abstractions such as an interface), the more difficult it will be to extend.
• The Interface Segregation Principle (ISP): “Many client-specific interfaces are
better than one general purpose interface”
• ISP suggests that you should create a specialized interface to serve each major
category of clients.
• Only those operations that are relevant to a particular category of clients should be
specified in the interface for that client.
• If multiple clients require the same operations, it should be specified in each of the
specialized interfaces.

83
COMPONENT-LEVEL DESIGN
•Designing Class Based Components:
• Basic Design Principles:
• The Release Reuse Equivalency Principle (REP): “ The granule of reuse is the
granule of release.”
• When classes or components are designed for reuse, an implicit contract is
established between the developer of the reusable entity and the people who will
use it.
• The developer commits to establish a release control system that supports and
maintains older versions of the entity while the users slowly upgrade to the most
current version.
• Rather than addressing each class individually, it is often advisable to group reusable
classes into packages that can be managed and controlled as newer versions evolve.

84
COMPONENT-LEVEL DESIGN
•Designing Class Based Components:
• Basic Design Principles:
• The Common Closure Principle (CCP): “ Classes that change together belong
together.”
• Classes should be packaged cohesively.
• That is, when classes are packaged as part of a design, they should address the same
functional or behavioral area.
• When some characteristic of that area must change, it is likely that only those classes
within the package will require modification.
• This leads to more effective change control and release management.

85
COMPONENT-LEVEL DESIGN
•Designing Class Based Components:
• Basic Design Principles:
• The Common Reuse Principle (CRP): “ Classes that aren’t reused together should
not be grouped together.”
• When one or more classes with a package changes, the release number of the
package changes.
• All other classes or packages that rely on the package that has been changed must
now update to the most recent release of the package and be tested to ensure that
the new release operated without incident.
• If classes are not grouped cohesively, it is possible that a class with no relationship to
other classes within a package is changed.
• This will precipitate unnecessary integration and testing. For this reason, only classes
that are reused together should be included within a package.

86
COMPONENT-LEVEL DESIGN
•Designing Class Based Components:
• Component Level Design Guidelines:
• Following guidelines apply to components, their interfaces, and the dependencies
and inheritance characteristics that have an impact on the resultant design:
• Components:
• Naming conventions should be established for components that are specified as
part of the architectural model and then refined and elaborated as part of the
component-level model.
• Architectural component names should be drawn from the problem domain and
should have meaning to all stakeholders who view the architectural model.
• Interfaces:
• Interfaces provide important information about communication and
collaboration.
• However, uncontrolled representation of interfaces tends to complicate
component diagrams.
87
COMPONENT-LEVEL DESIGN
•Designing Class Based Components:
• Component Level Design Guidelines:
• Following guidelines apply to components, their interfaces, and the dependencies
and inheritance characteristics that have an impact on the resultant design:
• Dependencies and Inheritance:
• For improved readability, it is a good idea to model dependencies from left to
right and inheritance from bottom (derived classes) to top (base classes).
• In addition, components’ interdependencies should be represented via
interfaces, rather than by representation of a component-to-component
dependency.

88
COMPONENT-LEVEL DESIGN
•Designing Class Based Components:
• Component Level Design Guidelines:
• Following guidelines apply to components, their interfaces, and the dependencies
and inheritance characteristics that have an impact on the resultant design:
• Dependencies and Inheritance:
• For improved readability, it is a good idea to model dependencies from left to
right and inheritance from bottom (derived classes) to top (base classes).
• In addition, components’ interdependencies should be represented via
interfaces, rather than by representation of a component-to-component
dependency.

89
COMPONENT-LEVEL DESIGN
•Designing Class Based Components:
• Cohesion:
• Cohesion implies that a component or class encapsulates only attributes and
operations that are closely related to one another and to the class or component
itself.
• Types of Cohesion:
• Functional: Exhibited primarily by operations, this level of cohesion occurs when a
module performs one and only one computation and then returns a result.
• Layer: Exhibited by packages, components, and classes, this type of cohesion occurs
when a higher layer accesses the services of a lower layer, but lower layers do not
access higher layers.
• Communicational: All operations that access the same data are defined within one
class. In general, such classes focus solely on the data in question, accessing and
storing it.

90
COMPONENT-LEVEL DESIGN
•Designing Class Based Components:
• Coupling:
• Coupling is a qualitative measure of the degree to which classes are connected to
one another.
• As classes (and components) become more interdependent, coupling increases.
• An important objective in component-level design is to keep coupling as low as is
possible.
• Types of Coupling:
• Content coupling occurs when one component secretly modifies data that is internal
to another component.
• Control coupling occurs when operation A() invokes operation B() and passes a
control flag to B. The control flag then directs logical flow within B.
• External coupling occurs when a component communicates or collaborates with
infrastructure components (e.g., operating system functions, database capability,
telecommunication functions).

91
COMPONENT-LEVEL DESIGN
•Designing Class Based Components:
• Coupling:
• Software must communicate internally and externally. Therefore, coupling is a
fact of life.
• However, the designer should work to reduce coupling whenever possible and
understand the possible impacts of high coupling when it cannot be avoided.

92
COMPONENT-LEVEL DESIGN
•Conducting Component Level Design:
• You must transform information from requirements and architectural
models into a design representation that provides sufficient detail to
guide the construction (coding and testing) activity.
• The following steps represent a typical task set for component-level
design, when it is applied for an object-oriented system.
1. Identify all design classes that correspond to the problem domain:
• Using the requirements and architectural model, each analysis class and
architectural component is elaborated.
2. Identify all design classes that correspond to the infrastructure domain:
• These classes are not described in the requirements model and are often missing
from the architecture model, but they must be described at this point.

93
COMPONENT-LEVEL DESIGN
•Conducting Component Level Design:
3. Elaborate all design classes that are not acquired as reusable components:
• Elaboration requires that all interfaces, attributes, and operations necessary to
implement the class be described in detail.
• Design heuristics (e.g., component cohesion and coupling) must be considered as this
task is conducted.
a. Specify message details when classes or components collaborate.
b. Identify appropriate interfaces for each component.
c. Elaborate attributes and define data types and data structures required to
implement them.
d. Describe processing flow within each operation in detail.
5. Describe persistent data sources (databases and files) and identify the classes
required to manage them:

94
COMPONENT-LEVEL DESIGN
•Conducting Component Level Design:
4. Describe persistent data sources (databases and files) and identify the classes
required to manage them:
• Databases and fi les normally transcend the design description of an individual
component. In most cases, these persistent data stores are initially specified as part
of architectural design.
• However, as design elaboration proceeds, it is often useful to provide additional
detail about the structure and organization of these persistent data sources.
5. Develop and elaborate behavioral representations for a class or component:
• During component-level design, it is sometimes necessary to model the behavior of a
design class.
• you should examine all use cases that are relevant to the design class throughout its
life.

95
COMPONENT-LEVEL DESIGN
•Conducting Component Level Design:
6. Elaborate deployment diagrams to provide additional implementation detail:
• Deployment diagrams are used as part of architectural design and are represented in
descriptor form.
• In this form, major system functions (often represented as subsystems) are represented
within the context of the computing environment that will house them.
• During component-level design, deployment diagrams can be elaborated to represent the
location of key packages of components.
7. Refactor every component-level design representation and always consider
alternatives:
• The first component-level model you create will not be as complete, consistent, or accurate as
the nth iteration you apply to the model. It is essential to refactor as design work is conducted.

96
USER-INTERFACE DESIGN
•User interface design creates an effective communication medium
between a human and a computer.
•Following a set of interface design principles, design identifies
interface objects and actions and then creates a screen layout that
forms the basis for a user interface prototype.
•A software engineer designs the user interface by applying an
iterative process that draws on predefined design principles.

97
USER-INTERFACE DESIGN
•The Golden Rules:
• The golden rules actually form the basis for a set of user interface design
principles that guide this important aspect of software design.
1. Place the User in Control:
• As a designer, you may be tempted to introduce constraints and limitations to
simplify the implementation of the interface.
• The result may be an interface that is easy to build, but frustrating to use.
• Following Design Principles help the use to maintain control on UI:
• Define interaction modes in a way that does not force a user into unnecessary or
undesired actions
• Provide for flexible interaction
• Allow user interaction to be interruptible and undoable
• Streamline interaction as skill levels advance and allow the interaction to be customized
• Hide technical internals from the casual user
• Design for direct interaction with objects that appear on the screen

98
USER-INTERFACE DESIGN
• The Golden Rules:
2. Reduce the User’s Memory Load:
• Whenever possible, the system should “remember” pertinent information and assist the
user with an interaction scenario that assists recall.
• Design Principles to Reduce User’s Memory Load:
• Reduce demand on short-term memory
• Establish meaningful defaults
• Define shortcuts that are intuitive
• The visual layout of the interface should be based on a real-world metaphor
• Disclose information in a progressive fashion
3. Make the Interface Consistent:
• The interface should present and acquire information in a consistent fashion. This implies
that:
1. All visual information is organized according to design rules that are maintained
throughout all screen displays.
2. Input mechanisms are constrained to a limited set that is used consistently
throughout the application.
3. Mechanisms for navigating from task to task are consistently defined and
implemented.

99
USER-INTERFACE DESIGN
•The Golden Rules:
3. Make the Interface Consistent:
• Design Principles to make the interface consistent:
• Allow the user to put the current task into a meaningful context
• Maintain consistency across a complete product line
• If past interactive models have created user expectations, do not make changes unless
there is a compelling reason to do so

100
USER-INTERFACE DESIGN
•User Interface Design Steps:
• Interface design, like all software engineering design, is an iterative
process.
• Each user interface design step occurs a number of times, elaborating
and refining information developed in the preceding step.
• Although many different user interface design models have been
proposed, all suggest some combination of the following steps:
1. Define interface objects and actions (operations).
2. Identify events (user actions) that will cause the state of the user interface to
change.
3. Depict the representation of each state.
4. Indicate how the user interprets each state from information provided through
the interface.

101
USER-INTERFACE DESIGN
•User Interface Design Steps:
• Applying Interface Design Steps:
• When you are satisfied that all important objects and actions have been defined
(for one design iteration), screen layout is performed.
• Like other interface design activities, screen layout is an interactive process in
which graphical design and placement of icons, definition of descriptive screen
text, specification and titling for windows, and definition of major and minor
menu items are conducted.
• If a real-world metaphor is appropriate for the application, it is specified at this
time, and the layout is organized in a manner that complements the metaphor.

102
USER-INTERFACE DESIGN
•User Interface Design Steps:
• User Interface Design Patterns:
• A design pattern is an abstraction that prescribes a design solution to a specific,
well-bounded design problem.
• A vast array of interface design patterns has been proposed over the past decade.
• Design Issues:
• As the design of a user interface evolves, four common design issues almost
always surface: system response time, user help facilities, error information
handling, and command labeling.
• Unfortunately, many designers do not address these issues until relatively late in
the design process. Unnecessary iteration, project delays, and end-user
frustration often result.
• It is far better to establish each as a design issue to be considered at the
beginning of software design, when changes are easy and costs are low.
103
USER-INTERFACE DESIGN
•User Interface Design Steps:
• Design Issues:
• Response Time:
• System response time has two important characteristics: length and variability.
• If system response is too long, user frustration and stress are inevitable.
• Variability refers to the deviation from average response time, and in many ways, it is the
most important response time characteristic.
• Low variability enables the user to establish an interaction rhythm, even if response time is
relatively long.
• Help Facilities:
• Almost every user of an interactive, computer-based system requires help now and then.
• Modern software should provide online help facilities that enable a user to get a question
answered or resolve a problem without leaving the interface.

104
USER-INTERFACE DESIGN
•User Interface Design Steps:
• Design Issues:
• Error Handling:
• In general, every error message or warning produced by an interactive system should have
the following characteristics:
1. Describes the problem in a manner that the user can understand.
2. Provides constructive advice for recovering from the error
3. Indicates any negative consequences of the error.
• Suggested measure, for example can be an audible or visual cue.
• System should never place blame for the error on the user.
• Menu and Command Labeling:
• Provide both modes of operation, as much as possible.
• Application Accessibility:
• Software engineers must ensure that interface design encompasses mechanisms that enable
easy access for those with special needs.

105
USER-INTERFACE DESIGN
•User Interface Design Steps:
• Design Issues:
• Internationalization:
• The challenge for interface designers is to create “globalized” software.
• That is, user interfaces should be designed to accommodate a generic core of functionality
that can be delivered to all who use the software.
• Localization features enable the interface to be customized for a specific market.

106
USER-INTERFACE DESIGN
•User Interface Analysis:
• User Analysis:
• The phrase user interface is probably all the justification needed to spend some
time understanding the user before worrying about technical matters.
• Each user has a mental image of the software that may be different from the
mental image developed by other users. In addition, the user’s mental image may
be vastly different from the software engineer’s design model.
• The only way that you 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.
• Information from a broad array of sources (user interviews, sales input, marketing
input, support input) can be used to accomplish this.

107
USER-INTERFACE DESIGN
•User Interface Analysis:
• User Analysis:
• The following set of questions will help to better understand the users of a
system:
• Are users trained professionals, technicians, 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 is the age range of the user community?
• Will the users be represented predominately by one gender?
• How are users compensated for the work they perform?
• Do users work normal office hours or do they work until the job is done?

108
USER-INTERFACE DESIGN
•User Interface Analysis:
• User Analysis:
• The following set of questions will help to better understand the users of a
system:
• Is the software to be an integral part of the work users do or will it be used only
occasionally?
• What is the primary spoken language among users?
• What are the consequences if a user makes a mistake using the system?
• Are users experts in the subject matter that is addressed by the system?
• Do users want to know about the technology that sits behind the interface?
• Once these questions are answered, you’ll know 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.

109
USER-INTERFACE DESIGN
•User Interface Analysis:
• Task Analysis and Modeling:
• The goal of task analysis is to answer following questions:
1. What work will the user perform in specific circumstances?
2. What tasks and subtasks will be performed as the user does the work?
3. What specific problem domain objects will the user manipulate as work is
performed?
4. What is the sequence of work tasks—the workflow?
5. What is the hierarchy of tasks?

110
USER-INTERFACE DESIGN
•User Interface Analysis:
• Use Cases:
• Use case describes the manner in which an actor (in the context of user interface
design, an actor is always a person) interacts with a system.
• When used as part of task analysis, the use case is developed to show how an end
user performs some specific work-related task.
• In most instances, the use case is written in an informal style (a simple paragraph)
in the first person.
• Use case provides a basic description of one important work task for the
computer-aided design system. From it, you can extract tasks, objects, and the
overall flow of the interaction.
• In addition, other features of the system that would please the interior designer
might also be conceived.

111
USER-INTERFACE DESIGN
•User Interface Analysis:
• Task Elaboration:
• Task analysis for interface design uses an elaborative approach that assists in
understanding the human activities the user interface must accommodate.
• You should define and classify the human tasks that are required to accomplish
the goal of the system or app.
• The classification can also be done to create the subtasks and refine them if
needed.
• Identify and categorize which of the tasks will work through user interface and
which of them must be automatically managed.
• The design model of the interface should accommodate each of these tasks in a
way that is consistent with the user model and system perception.

112
USER-INTERFACE DESIGN
•User Interface Analysis:
• Object Elaboration:
• Rather than focusing on the tasks that a user must perform, you can examine the
use case and other information obtained from the user and extract the physical
objects that are used.
• These objects can be categorized into classes. Attributes of each class are defined,
and an evaluation of the actions applied to each object provides a list of
operations.
• Workflow Analysis:
• When a number of different users, each playing different roles, makes use of a
user interface, it is sometimes necessary to go beyond task analysis and object
elaboration and apply workflow analysis.
• This technique allows you to understand how a work process is completed when
several people (and roles) are involved.

113
USER-INTERFACE DESIGN
•User Interface Analysis:
• Hierarchical Representation:
• A process of elaboration occurs as you begin to analyze the interface.
• Once workflow has been established, a task hierarchy can be defined for each
user type.
• The hierarchy is derived by a stepwise elaboration of each task identified for the
user.

114
USER-INTERFACE DESIGN
• Analysis of Display Contents:
• During this interface analysis step, the format and aesthetics of the content (as
it is displayed by the interface) are considered.
• Among the questions that are asked and answered are:
1. Are different types of data assigned to consistent geographic locations on the screen
(e.g., photos always appear in the upper right-hand corner)?
2. Can the user customize the screen location for content?
3. Is proper on-screen identification assigned to all content?
4. If a large report is to be presented, how should it be partitioned for ease of
understanding?
5. Will mechanisms be available for moving directly to summary information for large
collections of data?
6. Will graphical output be scaled to fi t within the bounds of the display device that is
used?
7. How will color be used to enhance understanding?
8. How will error messages and warnings be presented to the user?

115
USER-INTERFACE DESIGN
•Analysis of Work Environment:
• In some applications the user interface for a computer-based system is
placed in a “user-friendly location” (e.g., proper lighting, good display
height, easy keyboard access).
• But in others (e.g., a factory floor or an airplane cockpit), lighting may be
suboptimal, noise may be a factor, a keyboard or mouse or touch screen
may not be an option, display placement may be less than ideal.
• The interface designer may be constrained by factors that mitigate
against ease of use.
• In addition to physical environmental factors, the workplace culture also
comes into play.

116
USER-INTERFACE DESIGN
•Design Evaluation:
• Once you create an operational user interface prototype, it must be
evaluated to determine whether it meets the needs of the user.
• Evaluation can span a formality spectrum that ranges from an informal
“test drive,” in which a user provides unplanned feedback to a formally
designed study that uses statistical methods for the evaluation of
questionnaires completed by a population of end users.

117
USER-INTERFACE DESIGN
•Design Evaluation:
• Evaluation Criteria for Interface Design:
1. The length and complexity of the requirements model or written specification
of the system and its interface provide an indication of the amount of learning
required by users of the system.
2. The number of user tasks specified and the average number of actions per task
provide an indication of interaction time and the overall efficiency of the
system.
3. The number of actions, tasks, and system states indicated by the design model
imply the memory load on users of the system.
4. Interface style, help facilities, and error handling protocol provide a general
indication of the complexity of the interface and the degree to which it will be
accepted by the user.

118