Software Engineering (PCCO6010T)

Credits : 03
Examination Scheme
Term Test : 15 Marks
Teacher Assessment : 20 Marks
End Sem Exam : 65 Marks
Total Marks : 100 Marks

Prerequisite:
1. Concepts of Object Oriented Programming & Methodology.
2. Knowledge of developing applications with front end & back end connectivity.
• Course Objectives: To provide the knowledge of Standard Software Engineering discipline.
 Unit-III
06 Hrs.

• Design Engineering and Analysis: Design Principles, Design Concepts, Effective Modular
Design-Cohesion and Coupling.
• Translating the requirement models into the design model.
• Designs: Architectural Design, Component Level Design, User Interface Design.
 Design Principles

• Principle 1. Design should be traceable to the requirements model.

The design of a system should directly connect to the requirements defined earlier. Every
feature and component should fulfill a specific need from the requirements model, ensuring
nothing unnecessary is added.

• Principle 2. Always consider the architecture of the system to be built.

Before designing details, think about the overall structure of the system. A strong architecture
ensures the system is scalable, efficient, and easy to maintain.

• Principle 3. Design of data is as important as design of processing functions.

The way data is organized and managed is just as important as how the system processes it.
Poor data design can lead to inefficiency, errors, and performance issues.
 Design Principles

• Principle 4. Interfaces (both internal and external) must be designed with care.
Interfaces connect different parts of a system and allow communication with users or other
systems. Well-designed interfaces ensure smooth interaction, usability, and compatibility.

• Principle 5. User interface design should be tuned to the needs of the end user.
However, in every case, it should stress ease of use.
The user interface should be designed based on what users need and how they interact with
the system. It should always be simple, natural, and easy to use.

• Principle 6. Component-level design should be functionally independent.

Each component should perform a specific task without relying too much on others. This
makes the system easier to understand, modify, and maintain.
 Design Principles

• Principle 7. Components should be loosely coupled to one another and to the external
environment.
Components should have minimal dependencies on each other and external systems. This improves
flexibility, scalability, and ease of maintenance.

• Principle 8. Design representations (models) should be easily understandable.

Design models should be clear and simple so that developers, testers, and stakeholders can
easily understand and use them.

• Principle 9. The design should be developed iteratively. With each iteration, the designer
should strive for greater simplicity.
Design should be created in steps, improving with each version. Every iteration should aim to
make the design clearer, more efficient, and easier to use.
 Design Concepts
Design within the context of Engineering

The figure illustrated the flow of information during software design.

 Design Concepts
• Each of the elements of the requirements model provides information that is necessary to
create the four design models required for a complete specification of design.
• The data/class design transforms class models into design class realizations and the
essential data structures required to implement the software.
• The architectural design defines the relationship between major structural elements of the
software, the architectural styles and design patterns that can be used to achieve the
requirements defined for the system, and the constraints that affect the way in which
architecture can be implemented.
• The interface design describes how the software communicates with systems that
interoperate with it, and with humans who use it. An interface implies a flow of information
(e.g., data and/or control) and a specific type of behavior.
• The component-level design transforms structural elements of the software architecture
into a procedural description of software components. Information obtained from the class-
based models, flow models, and behavioral models serve as the basis for component design.
 Abstraction
• Abstraction is a fundamental design concept in software engineering that helps manage
complexity by focusing on essential features while hiding unnecessary details.
• It allows developers to design software at different levels of granularity, making systems
easier to understand, develop, and maintain.
• It helps break down a system into manageable components and improves reusability and
maintainability.
Levels of Abstraction
• High-Level Abstraction: Focuses on system architecture and major components (e.g.,
modules, layers).
• Mid-Level Abstraction: Represents functional components like classes and objects in
Object-Oriented Programming (OOP).
• Low-Level Abstraction: Deals with implementation details like data structures and
algorithms.
 Abstraction
Types of Abstraction
• Data Abstraction: Hides internal data representation and provides access through well-
defined interfaces (e.g., classes in OOP).
• Control Abstraction: Simplifies control flow in a program by using loops, functions, and
decision structures.
• Procedural Abstraction: Encapsulates code in functions or methods, allowing code reuse
without exposing internal logic.
• Examples of Abstraction
• Abstract Classes & Interfaces (OOP): Define behavior without specifying implementation.
• Database Abstraction: SQL queries allow accessing data without knowing the underlying
storage details.
• API Abstraction: Provides a simplified interface for interacting with complex systems (e.g.,
Google Maps API).
 Architecture
• Software architecture refers to the high-level structure of a software system, defining how
different components interact and work together to fulfill system requirements.
• It provides a blueprint for system design and development, ensuring efficiency, scalability,
and maintainability.
• It acts as a bridge between design and implementation.
Components of Software Architecture
• Modules: Individual components with specific functionality.
• Interfaces: Defines how modules communicate.
• Data Management: Storage and retrieval of data.
• Security and Reliability: Ensuring safe and fault-tolerant operation.
Architectural Styles and Patterns
• Layered Architecture, Client-Server Architecture, Microservices Architecture, Event-Driven
Architecture and Pipe and Filter Architecture
 Information Hiding
• Information hiding is a fundamental design principle in software engineering that focuses
on restricting access to certain details of a module, class, or system component to improve
maintainability, security, and modularity.
• It refers to the practice of concealing implementation details from external modules or
users and only exposing what is necessary through a well-defined interface.
• It helps in reducing dependencies between different parts of a system.
Purpose of Information Hiding
• Encapsulation of complexity: Prevents unnecessary access to internal workings.
• Improves security: Protects data from unintended modification.
• Enhances maintainability: Changes in implementation do not affect other components.
• Reduces system dependencies: Promotes modular design and reusability.
 Separation of Concerns
• Separation of concerns is a design concept that suggests that any complex problem can be
more easily handled if it is subdivided into pieces that can each be solved and/or optimized
independently.
• A concern is a feature or behavior that is specified as part of the requirements model for the
software.
• By separating concerns into smaller, and therefore more manageable pieces, a problem takes
less effort and time to solve.
• Separation of concerns is represented in other related design concepts: modularity, aspects,
functional independence, and refinement.
 Modularity
• Modularity is the most common manifestation of separation of concerns.
• Software is divided into separately named and addressable components, sometimes 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”.
 Functional Independence
• It means that different parts of a system work separately without depending too much on
each other. This idea comes from three important software design principles- Separation of
concerns, Modularity, Abstraction and information hiding.
• The functional independence helps make software easier to develop, test, and maintain
because each part does its own job without affecting others too much.
• Independence is assessed using two qualitative criteria: cohesion and coupling.
• Cohesion is an indication of the relative functional strength of a module. Coupling is an
indication of the relative interdependence among modules.
• Cohesion is a natural extension of the information-hiding concept.
• Coupling is an indication of interconnection among modules in a software structure.
• 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.
 Coupling
• Coupling is a qualitative measure of the degree to which classes are connected to one
another.
• As classes (and components) become more dependent, coupling increases.
• An important objective in component-level design is to keep coupling as low as is possible.
• Content coupling: Occurs when one component “secretly modifies data that is internal to
another component”. This violates information hiding—a basic design concept.
• Common coupling: Occurs when components make use of a global variable.
• 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.
• Stamp coupling: Occurs when Class B is declared as a type for an argument of an
operation of Class A.
 Coupling
• Data coupling: Occurs when operations pass long strings of data arguments.
• Routine call coupling: Occurs when one operation invokes another. This level of coupling
is common and is often quite necessary. However, it does increase the connectedness of a
system.
• Type use coupling: Occurs when component A uses a data type defined in component B.
• Inclusion or import coupling: Occurs when component A imports or includes a package or
the content of component B.
• External coupling: Occurs when a component communicates or collaborates with
infrastructure components.
 Cohesion
• Cohesion refers to the degree to which the elements of a module (or component) in a
software system belong together.

• It ensures that a module performs a well-defined function and reduces unnecessary

dependencies on other modules.

• Coincidental Cohesion: The module contains unrelated tasks with no meaningful

relationship.

• Logical Cohesion: Elements perform similar activities but are logically grouped rather than
functionally related.

• Temporal Cohesion: Elements are related in time, meaning they execute together at a
specific point.
 Cohesion
• Procedural Cohesion: Elements execute in a specific sequence but are not strongly related
functionally.

• Communicational Cohesion: Elements operate on the same data or contribute to a

common task.

• Sequential Cohesion: Output from one part of the module serves as input for another.

• Functional Cohesion: The module performs a single well-defined function.

 THE DESIGN MODEL

The design model can be viewed in two different dimensions illustrated in above figure.
• 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.
• Referring to Figure, the dashed line indicates the
boundary between the analysis and design
models.
 THE DESIGN MODEL
Data Design Elements
-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.
- data model is then refined into progressively more implementation-specific
representations that can be processed by the computer-based system .
Architectural Design Elements
-Architectural design elements give us an overall view of the software.
- derived from three sources:
(1) information about the application domain;
(2) specific requirements model elements such as data flow diagrams or
analysis classes, their relationships and
(3) the availability of architectural styles and patterns
- The architectural design element is depicted as a set of interconnected
subsystems
Interface Design Elements
- The interface design elements for software depict information flows into and out
of the system and how it is communicated among the components defined as
part of the architecture.
- 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
(3) internal interfaces between various design components.
- an interface is a set of operations that describes some part of the behavior of a
class and provides access to these operations.
Component-Level Design Elements
- 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).
Deployment-Level Design Elements
- indicate how software functionality and subsystems will be
allocated within the physical computing environment that will
support the software .
- deployment diagram shows the computing environment but
does not explicitly indicate configuration details
Deployment-Level Design Elements
- indicate how software functionality and subsystems will be
allocated within the physical computing environment that will
support the software .
- deployment diagram shows the computing environment but
does not explicitly indicate configuration details
Aggregation – FloorPlan has the Camera

Composition- FloorPlan owns Segments

The dashed lines with unfilled triangle arrowheads
pointing from WirelessPDA and MobilePhone to the
KeyPad interface indicate that these classes implement
the KeyPad interface.

The ControlPanel class (Figure 8.5) provides the

behavior associated with a keypad,
and therefore, it must implement the operations
readKeyStroke () and decodeKey ().
In this figure, a component named SensorManagement (part of the SafeHome security function) is
represented. A dashed arrow connects the component to a class named Sensor that is assigned to it. The
SensorManagement component performs all functions associated with SafeHome sensors including
monitoring and configuring them.
In the figure, three computing environments
are shown.

In this figure, 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).

For example, the personal computer houses

subsystems that implement security,
surveillance, home management, and
communications features.
DESIGN WITHIN THE CONTEXT OF SOFTWARE
ENGINEERING
• software design is the last software engineering action within
the modeling activity and sets the stage for construction (code
generation and testing).
• design produces a data/class design, an architectural design, an
interface design, and a component design.
• The data/class design transforms class models into design class
realizations and the requisite data structures required to
implement the software.
• The objects and relationships defined in the CRC diagram and
the detailed data content depicted by class attributes and other
notation provide the basis for the data design action.
• architectural design defines the relationship between major
structural elements of the software.
• architectural design representation—the framework of a
computer-based system—is derived from the requirements
model.
• interface design describes how the software communicates
with system.
• interface implies a flow of information (e.g., data and/or
control) and a specific type of behavior.
• component-level design transforms structural elements of
the software architecture into a procedural description of
software components
• Design provides you with representations of software that
can be assessed for quality.
• Design is the only way that you can accurately translate
stakeholder‘s requirements into a finished software product
or system.
• Software design serves as the foundation for all the
software engineering and software support activities that
follow
 THE DESIGN PROCESS
 Software Quality Guidelines and Attributes
Quality Guidelines
-McGlaughlin suggests three characteristics that serve as a guide for the evaluation of a good design:
• The design must implement all of the explicit requirements contained in the requirements model, and it must
accommodate all of the implicit requirements desired by stakeholders.
• The design must be a readable, understandable guide for those who generate code and for those who test and
subsequently support the software.
• The design should provide a complete picture of the software, addressing the data, functional, and behavioural
domains from an implementation perspective.

• A design should exhibit an architecture that

(1) has been created using recognizable architectural styles or patterns,
(2) is composed of components that exhibit good design characteristics , and
(3) can be implemented in an evolutionary fashion, thereby facilitating implementation and testing.
• A design should be modular;
• A design should contain representations of data,
architecture, interfaces, and components.
• A design should lead to components that exhibit
independent functional characteristics.
• A design should lead to interfaces that reduce the
complexity of connections between components and
with the external environment.
• A design should be derived using a repeatable method
that is driven by information obtained during software
requirements analysis.
• A design should be represented using a notation that
effectively communicates its meaning.
Quality Attributes
-FURPS—functionality, usability, reliability, performance, and supportability
 Functionality
• 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
• assessed by considering human overall aesthetics, consistency, and
documentation.
 Reliability
• 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
• measured by considering processing speed, response time, resource
consumption, throughput, and efficiency.
 Supportability
• ability to extend the program (extensibility), adaptability, serviceability
 DESIGN CONCEPTS
The Evolution of Software Design
- Early design work on modular programs and methods for refining software
structures in a topdown manner .
- Procedural aspects of design definition evolved into a philosophy called
structured programming.
- methods for the translation of data flow or data structure into a design
definition.
- Newer design proposed an object-oriented approach.
- More recent emphasis on software architecture and the design patterns that
can be used to implement software architectures and lower levels of design
abstractions .
- Growing emphasis on aspect-oriented methods, Model-driven development
and test-driven development
 Abstraction
- At the highest level of abstraction, a solution is stated
in broad terms using the language of the problem
environment. At lower levels of abstraction, a more
detailed description of the solution is provided.
procedural abstraction:refers to a sequence of
instructions that have a specific and limited function
-(e.g., walk to the door, reach out and grasp knob,
turn knob and pull door, step away from moving door,
etc.).
data abstraction:is a named collection of data that
describes a data object . (e.g., door type, swing
direction, opening mechanism, weight, dimensions)
 Architecture
- Software architecture ―the overall structure of the software and
the ways in which that structure provides conceptual integrity for a
system .
- architecture is the structure or organization of program components
(modules), the manner in which these components interact, and the
structure of data that are used by the components
- Structural properties: defines the components of a system (e.g.,
modules, objects, filters) and the manner in which those
components are packaged and interact with one another.
Extra-functional properties: address how the design architecture
achieves requirements for performance, capacity, reliability,
security, adaptability, and other system characteristics.
Families of related systems:design should have the ability to reuse
architectural building blocks.
- Structural models represent architecture as an organized collection of program
components.
- Framework models increase the level of design abstraction by attempting to identify
repeatable architectural design frameworks that are encountered in similar types of
applications.
- Dynamic models address the behavioral aspects of the program architecture, indicating
how the structure or system configuration may change as a function of external events.
- Process models focus on the design of the business or technical process that the system
must accommodate.
- functional models can be used to represent the functional hierarchy of a system.
 Patterns
• 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
 Separation of Concerns
-It is a design concept that suggests that any
complex problem can be more easily handled if
it is subdivided into pieces that can each be
solved and/or optimized independently.
- A concern is a feature or behaviour that is
specified as part of the requirements model for
the software.
- By separating concerns into smaller, and
therefore more manageable pieces, a problem
takes less effort and time to solve
 DESIGN CONCEPTS continued…..
 Modularity
- Software is divided into separately named and addressable components, sometimes
called modules, that are integrated to satisfy problem requirements.
- Referring to Figure , the effort (cost) to develop an individual software module does
decrease as the total number of modules increases.
- Given the same set of requirements, more modules means smaller individual size. as the
number of modules grows, the effort (cost) associated with integrating the modules also
grows.
- There is a number, M, of modules that would result in minimum development cost, but we
do not have the necessary sophistication to predict M with assurance.
 Information Hiding
• modules should be specified and designed so that information
(algorithms and data) contained within a module is inaccessible to
other modules that have no need for such information.
• Hiding implies that effective modularity can be achieved by defining
a set of independent modules that communicate with one another
only that information necessary to achieve software function
 Functional Independence
- design software so that each module addresses a specific subset of
requirements and has a simple interface when viewed from other
parts of the program structure.
- functional independence is a key to good design, and design is the
key to software quality
- Independence is assessed using two qualitative criteria: cohesion
and coupling.
Cohesion is an indication of the relative functional strength of a module.
Coupling is an indication of the relative interdependence among modules.
cohesive module performs a single task, requiring little interaction with
other components in other parts of a program. Stated simply, a cohesive
module should (ideally) do just one thing
Coupling is an indication of interconnection among modules in a software
structure. Coupling depends on the interface complexity between modules,
 Refinement
- top-down design strategy
- A hierarchy is developed by decomposing a macroscopic statement of
function (a procedural abstraction) in a stepwise fashion until programming
language statements are reached. Refinement is actually a process of
elaboration
- elaborate on the original statement, providing more and more detail as
each successive refinement (elaboration) occurs. Abstraction and
refinement are complementary concepts.
- Refinement helps to reveal low-level details
 Aspects
-a requirements model can be organized in a way that allows you to isolate each concern
(requirement) so that it can be considered independently.
- aspect is a representation of a crosscutting concern .
- It is important to identify aspects so that the design can properly accommodate them as
refinement and modularization occur.
- an aspect is implemented as a separate module (component) rather than as software
fragments that are scattered‖.
- design architecture should support a mechanism for defining an aspect—a module that
enables the concern to be implemented across all other concerns that it crosscuts .
 Refactoring
- refactoring is a reorganization technique that simplifies the design (or code) of a
component without changing its function or behavior .
- Refactoring is the process of changing a software system in such a way that it
does not alter the external behavior of the code [design] yet improves its
internal structure.
- When software is refactored, the existing design is examined for redundancy,
unused design elements, inefficient or unnecessary algorithms, poorly
constructed or inappropriate data structures, or any other design failure ‖
 Object-Oriented Design Concepts
- OO design concepts such as classes and objects, inheritance, messages, and polymorphism,
among others.
 Design Classes
- 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
• 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.
• Business domain classes :The classes identify the attributes and services (methods) that are
required to implement some element of the business domain.
• Process classes implement lower-level business abstractions required to fully manage the
business domain classes.
• Persistent classes represent data stores (e.g., a database) that will persist beyond the
execution of the software.
• System classes implement software management and control functions that enable the
system to operate and communicate within its computing environment and with the outside
world.
ARCHITECTURAL DESIGN
 ARCHITECTURAL STYLES
• The software that is built for computer-based systems exhibits one of
many architectural styles. Each style describes a system category that
encompasses
(1) a set of components (e.g., a database, computational modules) that
perform a function required by a system;
(2) a set of connectors that enable ―communication, coordination and
cooperation among components;
(3) constraints that define how components can be integrated to form the
system;
(4) semantic models that enable a designer to understand the overall
properties of a system by analyzing the known properties of its
constituent parts.
- An architectural style is a transformation that is imposed on the design
of an entire system.
- The intent is to establish a structure for all components of the system.
A Brief Taxonomy of Architectural Styles
1.Data-centered architectures
- A data store (e.g., a file or database) resides at the center of this architecture and is
accessed frequently by other components that update, add, delete, or otherwise modify
data within the store.
- Figure illustrates a typical data-centered style.
- Client software accesses a central repository.
- 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
- Data-centered architectures promote integrability. That is, existing components can be
changed and new client components added to the architecture without concern about
other clients
2.Data-flow architectures
• 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 (Figure 9.2) has a set of components, called filters,
connected by pipes that transmit data from one component to the other.
• Each filter works independently of those components upstream and
downstream, is designed to expect data input of a certain form, and produces
data output (to the next filter) of a specified form.
• the filter does not require knowledge of the workings of its neighboring filters.
ARCHITECTURAL STYLES ..
3.Call and return architectures
• This architectural style enables you to achieve a program structure that is
relatively easy to modify and scale.
• A number of substyles 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 that in turn may invoke other components.
- Figure 9.3 illustrates an architecture of this type.
- Remote procedure call architectures. The components of a main
program/subprogram architecture are distributed across multiple computers on a
network.
4.Object-oriented architectures
• 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.
5. Layered architectures
• A number of different layers are defined, each accomplishing operations
that progressively become closer to the machine instruction set.
• At the outer layer, components performs user interface operations.
• At the inner layer, components perform operating system interfacing.
• Intermediate layers provide utility services and application software
functions.
ARCHITECTURAL STYLES
 Architectural Patterns
- Architectural patterns address an application-specific
problem within a specific context and under a set of
limitations and constraints.
- The pattern proposes an architectural solution that can
serve as the basis for architectural design.
 Organization and Refinement
-The following questions provide insight into an architectural style:
1.Control:
• How is control managed within the architecture?
• Does a distinct control hierarchy exist, and if so, what is the role
of components within this control hierarchy?
• How do components transfer control within the system?
• How is control shared among components?
• What is the control topology (i.e., the geometric form that the
control takes)?
• Is control synchronized or do components operate
asynchronously?
2. Data.
• How are data communicated between components?
• Is the flow of data continuous, or are data objects passed to the system
sporadically?
• What is the mode of data transfer (i.e., are data passed from one
component to another or are data available globally to be shared among
system components)?
• Do data components (e.g., a blackboard or repository) exist, and if so,
what is their role?
• How do functional components interact with data components?
• Are data components passive or active (i.e., does the data component
actively interact with other components in the system)?
• How do data and control interact within the system?
• These questions provide the designer with an early assessment of design
quality and lay the foundation for more detailed analysis of the
architecture.
ARCHITECTURAL DESIGN
Representing the System in Context
• At the architectural design level, a software architect uses an
architectural context diagram (ACD) to model the manner in which
software interacts with entities external to its boundaries.
• The generic structure of the architectural context diagram is
illustrated in Figure 9.5.
-Superordinate systems—those systems that use the target system as
part of some higher-level processing scheme.
-Subordinate systems—those systems that are used by the target
system and provide data or processing that are necessary to
complete target system functionality.
- Peer-level systems—those systems that interact on a peer-to-peer
basis (i.e., information is either produced or consumed by the peers
and the target system.
-Actors—entities (people, devices) that interact with the target system
by producing or consuming information that is necessary for requisite
processing. Each of these external entities communicates with the
target system through an interface (the small shaded rectangles).
 ARCHITECTURAL DESIGN
Defining Archetypes
• An archetype is a class or pattern that represents a core abstraction that is
critical to the design of an architecture for the target system.
• a relatively small set of archetypes is required to design even relatively complex
systems.
• The target system architecture is composed of these archetypes, which
represent stable elements of the architecture but may be instantiated many
different ways based on the behavior of the system.
 ARCHITECTURAL DESIGN
Refining the Architecture into Components
• the application domain is one source for the derivation and refinement of components.
Another source is the infrastructure domain.
• The architecture must accommodate many infrastructure components that enable
application components but have no business connection to the application domain.
• For example, memory management components, communication components, database
components, and task management components are often integrated into the software
architecture.
• The interfaces depicted in the architecture context diagram imply one or more specialized
components that process the data that flows across the interface.
• In some cases (e.g., a graphical user interface), a complete subsystem architecture with
many components must be designed.
USER INTERFACE DESIGN
• User interface design creates an effective communication medium between a human
and a computer.

• User interface design begins with the identification of user, task, and environ-mental
requirements.

• Once user tasks have been identified, user scenarios are created and analyzed to define
a set of interface objects and actions.

• These form the basis for the creation of screen layout that depicts graphical design and
placement of icons, definition of descriptive screen text, specification and titling for
windows, and specification of major and minor menu items.
 USER INTERFACE ANALYSIS AND DESIGN
• The Process
-The analysis and design process for user interfaces is
iterative and can be represented using a spiral model.
-User interface analysis and design process begins at the
interior of the spiral and encompasses four distinct
framework activities
(1) interface analysis and modeling,
(2) interface design,
(3) interface construction, and
(4) interface validation.
-The spiral shown in Figure suggests that each of these
tasks will occur more than once, with each pass around
the spiral representing additional elaboration of
requirements and the resultant design.
- In most cases, the interface is built using prototypes, as
this is the best way to test and improve the design.
 USER INTERFACE ANALYSIS AND DESIGN
• Framework activities of User Interface Design
Interface Analysis and Modeling: This initial phase focuses on understanding user needs, tasks,
and the overall context of use. It involves creating models and representations of the interface.

Interface Design: Here, the focus shifts to creating the actual layout, structure, and visual elements
of the interface based on the analysis and modeling.

Interface Construction: This phase involves building the functional prototype or final interface
using software tools and technologies.

Interface Validation: The constructed interface is evaluated through testing and feedback to
ensure it meets user requirements and is usable.
 INTERFACE ANALYSIS
- In the case of user interface design, understanding the problem 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.

User Analysis
Information from a broad array of sources can be used to accomplish this:
 User Interviews -Members of the software team meet with end users to better understand their needs,
motivations, work culture.
 Sales input -Sales people meet with users on a regular basis and can gather information that will help the
software team to categorize users and better understand their requirements.
 Marketing input - Market analysis helps identify different user groups and understand how each group
may use the software differently.
 Support input -Support staff interact with users daily and can provide valuable insights into what works
well, what doesn’t, what users like or dislike, and which features are easy to use or cause confusion.
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?
Techniques applied to the user interface :-
Use cases
- Use case is developed to show how an end user performs some specific work-related task
Task elaboration
- Process of breaking down a task into smaller, detailed steps to better understand its requirements,
dependencies, and execution. It helps in effective planning, resource allocation, and problem-
solving.
Object elaboration
- Objects can be categorized into classes Attributes of each class are defined, and an evaluation of
the actions applied to each object provide a list of operations.
Workflow analysis
- Technique allows you to understand how a work process is completed when several people (and
roles) are involved
Hierarchical representation
- Once workflow has been established, a task hierarchy can be defined for each user type.
- hierarchy is derived by a stepwise elaboration of each task identified for the user
User Interface Design Steps :-
After interface analysis, all user tasks and actions are identified, and interface design
begins. This design process is iterative, refining and improving with each step based on
previous insights.
User interface design models suggest some combination of the following steps:
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.