Design Concepts

• Abstraction
• Architecture
• Patterns
• Separation of Concerns
• Modularity
• Information Hiding
• Functional Independence
• Refinement
• Aspects
• Refactoring
• Object-Oriented Design Concepts
• Design Classes
Design Concepts
• Abstraction
• At the highest level of abstraction, a solution is stated in broad terms using
the language of the problem environment.
• At lower levels of abstraction, a more detailed description of the solution is
provided.
• A procedural abstraction refers to a sequence of instructions that have a
specific and limited function, while a data abstraction is a named collection of
data that describes a data object.
• e.g. Open door here open is a function while door is an object
• i.e. open(walk and go to door, reach out and grasp knob, turn knob,pull door, step away
from the moving door etc.), door(type of door, swing direction, weight, opening
mechanisam etc.)
Design Concepts
• Architecture
• It 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.
• A set of architectural patterns enables a software engineer to solve common
design problems.
• Shaw and Garlan [Sha95a] describe a set of properties that should be
specified as part of an architectural design:
• Structural properties
• Extra-functional properties
• Families of related systems
Design Concepts
• Architecture
• Structural properties:
• It 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. For example,
objects are packaged to encapsulate both data and the processing that manipulates the
data and interact via the invocation of methods.
• Extra-functional properties:
• It should address how the design architecture achieves requirements for performance,
capacity, reliability, security, adaptability, and other system characteristics.
• Families of related systems:
• It should draw upon repeatable patterns that are commonly encountered in the design
of families of similar systems. In essence, the design should have the ability to reuse
architectural building blocks.
Design Concepts
• Architecture design can be represented using one or more models as:
• 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.
• A number of different architectural description languages (ADLs) have been developed
to represent these models [Sha95b].
Design Concepts
• Patterns
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
Design Concepts
• 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 behavior as part of the requirements.
• By separating concerns into smaller, and therefore more manageable
pieces, a problem takes less effort and time to solve.
Design Concepts
• Modularity
Software is divided into separately named and
addressable components, sometimes called modules,
that are integrated to satisfy problem requirements.
“modularity is the single attribute of software that
allows a program to be intellectually manageable”
you should break the design into many modules,
hoping to make understanding easier and, as a
consequence, reduce the cost required to build the
software.
However, as the number of modules grows, the effort
(cost) associated with integrating the modules also
grows.
Design Concepts
• Modularity
• Undermodularity or overmodularity should be avoided
• You modularize a design (and the resulting program) so that
• development can be more easily planned;
• software increments can be defined and delivered;
• changes can be more easily accommodated;
• testing and debugging can be conducted more efficiently, and
• long-term maintenance can be conducted without serious side effects.
Design Concepts
• 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.
• The use of information hiding as a
design criterion for modular systems
provides the greatest benefits when
modifications are required during
testing and later during software
maintenance
Design Concepts
• Functional Independence
• Independent modules are easier to maintain
(and test) because secondary effects caused by
design or code modification are limited, error
propagation is reduced, and reusable modules
are possible.
• Independence is assessed using two qualitative
criteria: cohesion and coupling.
Design Concepts
• Functional Independence
• Cohesion is an indication of the relative functional strength of a module.
• A cohesive module should (ideally) do just one thing. Although you should
always strive for high cohesion.
• Coupling is an indication of the relative interdependence among modules.
• 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.
• strive for lowest possible coupling.
Design Concepts
• Refinement
• Stepwise refinement is a top-down design strategy originally proposed by
Niklaus Wirth [Wir71].
• A program is developed by successively refining levels of procedural detail.
• 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. You begin with a statement of
function (or description of information) that is defined at a high level of
abstraction.
• You then elaborate on the original statement, providing more and more detail
as each successive refinement (elaboration) occurs.
Design Concepts
• Refinement
• Stepwise refinement is a top-down design strategy
originally proposed by Niklaus Wirth [Wir71].
• A program is developed by successively refining levels of
procedural detail.
• 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. You begin
with a statement of function (or description of information)
that is defined at a high level of abstraction.
• You then elaborate on the original statement, providing
more and more detail as each successive refinement
(elaboration) occurs.
Design Concepts
• Aspects
• An aspect is a representation of a crosscutting concern.
• A crosscutting concern is some characteristic of the system that applies across
many different requirements.
• e.g. There are two requirements for abc.com
• Requirement A-Only registered users can access video and requirement B says registered
users must be validated prior to using abc.com
• An aspect is implemented as a separate module (component) rather than as
software fragments that are “scattered” or “tangled” throughout many
components [Ban06]
Design Concepts
• Refactoring
• It 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.
Fowler [Fow00]
• When software is refactored, the existing design is examined for redundancy, unused
design elements, inefficient or unnecessary algorithms, poorly constructed or
inappropriate data structures, or any other design failure that can be corrected to
yield a better design.
• For example, a first design iteration might yield a component that exhibits low
cohesion (i.e., it performs three functions that have only limited relationship to one
another). After careful consideration, you may decide that the component should be
refactored into three separate components, each exhibiting high cohesion.
Design Concepts
• Design Classes
• 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 [Amb01]:
• User interface classes
• Business domain classes
• Process classes
• Persistent classes
• System classes
Design Concepts
• Design Classes
• What is a “wellformed” design class?
• Arlow and Neustadt [Arl02] suggest that each design class be reviewed to
ensure that it is “well-formed.”
• They define four characteristics of a well-formed design class: Complete and
sufficient, Primitiveness, High cohesion, Low coupling,
Design Concepts
• Object-Oriented Design Concepts
Design Models
• Importance of Design Models
• Clarifies system structure: Helps in breaking down the system into
manageable components.
• Facilitates communication: Serves as a communication tool between
developers, designers, and stakeholders.
• Guides implementation: Provides a reference for developers when writing
code.
• Supports testing: Design models help identify potential issues early in the
development process.
Design Models
• Transforming customers requirements as per SRS into design.
• The design model has four major elements/models
• data, architecture, components, and interface, additionally deployment
Design Models
• Data Design Model
• Purpose: Defines the data structure and database design.
• Concepts:
• Data Flow: How data moves through the system.
• Data Store: Where data is stored and retrieved.
• Data Models: Logical and physical representations of data.
• e.g.
Consider an online library system:
Entities: Books, Users, Borrow Records.
Data Model: A relational database with tables for Users, Books, and BorrowRecords.
Design Models
• Architectural Design Model
• Purpose: Defines the software architecture, specifying the system's structure and the
relationship between its components. It also defines set of h/w and s/w components. S/w
architecture shows security(OTP,PW credential for authority, Antivirus),Perfomance (Request
and Response with minimum time e.g. any search engine),safety etc,
• Concepts:
• Architecture Styles: Layered, client-server, microservices.
• Components: Core elements or modules of the system.
• Connectors: Define how components interact.
e.g. In the online library system:
Layered Architecture:
Presentation Layer: User interface.
Business Logic Layer: Manages borrowing books, user authentication.
Data Access Layer: Manages database queries and updates.
Design Models
• Interface Design Model
• Purpose: Defines how the system interacts with users and other systems. i.e to communicate
externally and enable internal communication and collaboration among components
• Concepts:
• User Interfaces: Graphical and text-based interfaces. Front-end view from where user can
interact. UI design (increasingly called usability design) .
• External Interfaces: How the system communicates with external systems or services or
devices or network. i.e. which information is sent or received.
• It should incorporate error checking and (when necessary) appropriate security features.
• Internal interfaces :
e.g. Online library system:
User Interface: A web-based portal where users can view books and borrow them.
External Interface: Integration with a payment gateway for fees or an external book inventory API.
Design Models
When software becomes popular?
When its user interface is
UI design (increasingly called usability design) .
(e.g., layout, color, graphics, interaction mechanisms)
Design Models
• Component Design Model
• Purpose: Describes the internal details of each software components or modules.
• The component-level design defines data structures for all local data objects and algorithmic detail for
all processing that occurs within a component and an interface that allows access to all component
operations (behaviors).
• Concepts:
• Module Design: Defines how individual modules are implemented.
• Responsibilities: Specifies what each module does.
• Interaction: Defines how modules interact with each other.
e.g.
For the online library system:
Component 1: User Authentication Module (handles login, registration).
Component 2: Book Borrowing Module (handles the process of borrowing books).
Component 3: Notification Module (sends alerts to users for overdue books).
Design Models
• Deployment Design Model
• Purpose: Defines how the system will be deployed in the target
environment.
• Concepts:
• Hardware and Software Environment: Where and how the software will run.
• Deployment Diagram: Visualizes physical deployment of components.
e.g.
For the online library system:
Deployment: The system could be hosted on cloud servers. The user interface could be
deployed on web servers, while databases and business logic are handled by backend
servers.
Software Architecture
• What is software architecture?
• The software architecture of a program or computing system is the
structure or structures of the system, which comprise software
components, the externally visible properties of those components,
and the relationships among them. [Bass, Clements, and Kazman]
• It is a representation that enables you to (1) analyze the effectiveness of the
design in meeting its stated requirements, (2) consider architectural alternatives
at a stage when making design changes is still relatively easy, and (3) reduce the
risks associated with the construction of the software.
• It a blueprint for a system.
i.e. It shows all users, functionalities and database in one diagram.
Architecture Style
• An architectural style is a transformation that is imposed on the design of an entire
system.
• Each style of software architecture 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;
and
(4) Semantic models that enable a designer to understand the overall properties of a
system by analyzing the known properties of its constituent parts
Architecture Style
• Taxonomy of architecture style
• The architecture style is categorized as:
• Data-centered architectures
• Data-flow architectures.
• Call and return architectures.
• Object Oriented architectures
• Layered architectures
Architecture Style
• Taxonomy of architecture style
• 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.
Used in DBMS, Library management system etc. e.g. In
library management system database-students,faculties,
books, suppliers, admin, staff database etc.
Client software accesses a central repository.
In some cases the data repository is passive. That is,
client software accesses the data independent of any
changes to the data or the actions of other client
software.
Architecture Style
• Taxonomy of architecture style
• Advantages:
• User can use data independently. Every user can perform action as per requirements.
• existing components can be changed and new client components added to the architecture without
concern about other clients. i.e. Modification is easy.
• data can be passed among clients using the blackboard mechanism(that sends notifications to client
software when data of interest to the client changes)
• Disadvantages:
• Data replication or duplication is possible.
• Changes affect to other user
Architecture Style

• Taxonomy of architecture style

• Data-flow architectures.
This architecture is applied when input data are to be transformed through a series of
computational or manipulative components into output data.
A pipe-and-filter pattern has set of components.
Pipe is a connector that transmits data directly from one component(filter) to the next.
Filter is a component that reads data in certain form from its input pipe and produces data
output (to the next filter) of a specified form.
This structure accepts a batch of data and then applies a series of sequential components
(filters) to transform it.
If the data flow degenerates into a single line of transforms, it is termed batch sequential.
Architecture Style
• Taxonomy of architecture style
• Data-flow architectures.
Advantage: concurrent execution is supported.
Disadvantage: More user engagement is not supported.
e.g. Result declared-Multiple students use-Crash or hang.n
Architecture Style
Batch will do all steps for all line of code while compiler-pipe filter
Lexical-words,token, correct word etc.
Syntax-checks syntax
Semantical- like int=A, it is incorrect
Optimizer – from text it has to generate optimized piece of information-related
Code generator-will generate code
 Architecture Style
• Taxonomy of architecture style
• 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 still other
components
• Remote procedure call architectures.
• The components of a main program/subprogram architecture
are distributed across multiple computers on a network.
Architecture Style
• Taxonomy of architecture style
• 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.
Architecture Style
• Taxonomy of architecture style
• Layered architectures
• Data moves from one level to next for processing is called layered architecture.
• A number of different layers are defined, every layer performs well defined set of operations.
• Outer layer, components service/manage user interface operations. e.g.User uses their front
end functionalities like asiaconnect.org
• Inner layer, components perform operating system interfacing.
• Intermediate layers provide utility services and application software functions. e.g. Related
to server like HTTP,HTTPS.
• Core layer means related to programming e.g. Database.
Architecture Style
• Taxonomy of architecture style
• Layered architectures
• I am using FB,YouTube,Google-single user- multiple server
• OR many users uses my app-single server multiple clients
• drop box-upload a file which will be stored on server, now if you delete it from your device,
you can get it back from drop box-client -server
Architecture Style
• 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.
• e.g. How do we offer a broad array of goods to a broad array of customers and
allow those customers to purchase our goods online? How to integrate third party
component with out system?
• The overall architectural style for an application might be call-and return or object-
oriented. But within that style, you will encounter a set of common problems that
might best be addressed with specific architectural patterns.
• Besides, layered, Onion other patterns are like event-driven(Uber,OOTPs),
hexagonal, modular, micro-kernel(plug-in)-you need database add it,CQRS(Banking
app-command-account maintains, query-shows account detials)etc.
Architecture Style
• Organization and Refinement
• Because the design process often leaves you with a number of architectural
alternatives, it is important to establish a set of design criteria that can be
used to assess an architectural design that is derived.
• 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?
• 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?
Architecture Design
• It represents a structure of data and program components that are
required to build a software.
• It should define the external entities (other systems, devices, people)
that the software interacts with and the nature of the interaction.
• An archetype is an abstraction (similar to a class) that represents one
element of system behavior.
Architecture Design
• Architectural design tasks:
1. 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 system engineer do it.
• Systems that interoperate with the target system are represented as:
• Superordinate systems
• Subordinate systems
• Peer-level systems
• Actors
• Each of these external entities communicates with the target system through an
interface.
Architecture Design
• Architectural design tasks:
• Superordinate systems
• those systems that use the target system as part of some higher-level processing scheme.
• All systems have to interact with main system
• 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
Architecture Design
The overall SafeHome product controller and the Internet-based system are both
superordinate to the security function
surveillance function is a peer system and uses (is used by) the home security function in
later versions of the product

sensors are used by the security software and are shown as subordinate to it.

The homeowner and control panels are actors that are both producers and consumers of
information
Architecture Design
Architecture Design
• Architectural design tasks:
2. 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. In general, a
relatively small set of archetypes is required to design even relatively complex
systems.
e.g. archetypes for home safe system:
Node. Represents a cohesive collection of input and output elements , say sensors and alarm
Detector. An abstraction that encompasses all sensing equipment that feeds information into the
target system.
Indicator. An abstraction that represents all mechanisms (e.g., alarm siren, flashing lights, bell) for
indicating that an alarm condition is occurring.
Controller. An abstraction that depicts the mechanism that allows the arming or disarming of a node.
If controllers reside on a network, they have the ability to communicate with one another.
Architecture Design
• Architectural design tasks:
3. Refining the Architecture into Components:
But how are these components chosen? Classes are used from
requirements model. Classes represent entities of application domain-
source for derivation and refinements of components are:
1. Application(Business) domain
2. Infrastructure domain
Architecture Design
• Architectural design tasks:
3. Refining the Architecture into Components:
For the SafeHome home security function example, you might define the set of
top-level components that address the following functionality:
• External communication management—coordinates communication of the security
function with external entities such as other Internet-based systems and external alarm
notification.
• Control panel processing—manages all control panel functionality.
• Detector management—coordinates access to all detectors attached to the system.
• Alarm processing—verifies and acts on all alarm conditions.
• Design classes (with appropriate attributes and operations) would be defined
for each
• Transactions are acquired by external communication management as they move in from components that
process the SafeHome GUI and the Internet interface.
• This information is managed by a SafeHome executive component that selects the appropriate product
function (in this case security).
• The control panel processing component interacts with the homeowner to arm/disarm the security
function.
• The detector management component polls sensors to detect an alarm condition, and
• The alarm processing component produces output when an alarm is detected.
Architectural Design

Architectural design tasks:

4. Describing Instantiations of the System.
• further refinement is still necessary. To accomplish this, an actual instantiation of
the architecture is developed.
Assessing Alternative Architectural
Designs
• From Design, Coding is done. i.e. Structured is directly copied to coding. Cost and
approval from customer is necessary. Not use complex or hybrid structure-
customer may not ready to pay more.
• Design results in a number of architectural alternatives that are each assessed to
determine which is the most appropriate for the problem to be solved, for this
there are two approaches:
1. An Architecture Trade-Off Analysis Method
2. A pseudo-quantitative technique
Assessing Alternative Architectural
Designs
1. An Architecture Trade-Off Analysis Method(ATAM)
Developed by The Software Engineering Institute (SEI).
It is an iterative evaluation process.
It performs required activities as:
i. Collect scenarios-use cases are developed to represent the system from user pint of view-how you should
define, what you should define-outer structure
ii. Elicit requirements, constraints, and environment description
iii. Describe the architectural styles/patterns that have been chosen to address the scenarios and
requirements-Module view(Sub program view), Process view(Single process), Data flow view.
iv. Evaluate quality attributes by considering each attribute in isolation like security,performance,reliability etc.
v. Identify the sensitivity of quality attributes to various architectural attributes for a specific architectural style
like any bugs or risks
vi. Critique candidate architectures (developed in step 3) using the sensitivity analysis conducted in step 5.
Assessing Alternative Architectural
Designs
Assessing Alternative Architectural
Designs
1. An Architecture Trade-Off Analysis Method
Once the architectural sensitivity points have been determined, finding trade-off points is
simply the identification of architectural elements to which multiple attributes are sensitive. For
example, the performance of a client-server architecture might be highly sensitive to the
number of servers (performance increases, within some range, by increasing the number of
servers). . . . The number of servers, then, is a trade-off point with respect to this architecture.
After setp5 & 6, few are eliminated and one or more of the remaining architectures may be modified and represented in
more detail, and then the ATAM steps are reapplied
Assessing Alternative Architectural
Designs
1. An Architecture Trade-Off Analysis Method
Access Architectural Complexity
A useful technique for assessing the overall complexity of a proposed architecture is to consider
dependencies between components within the architecture
three types of dependencies:
i. Sharing dependencies-like two components u and v sharing global variables
ii. Data flow dependencies-relationships between producers and consumers of resources-like two components
communicates through parameters
iii. Constrained dependencies-the relative flow of control among a set of activities-like two components u and
v, and v cannot execute at the same time .
Architectural Description Languages:Architectural description language (ADL) provides a semantics and syntax for
describing a software architecture. Hofmann and his colleagues [Hof01] suggest that an ADL should provide the
designer with the ability to decompose architectural components, compose individual components into larger
architectural blocks, and represent interfaces (connection mechanisms) between components. Then after,
effective assessment methods for architectures will be established.
Architectural mapping using
Dataflow
• In order to perform the mapping, the type of information flow must
be determined.
• One type of information flow is called transform flow.
• Transform mapping is a set of design steps that allows a DFD with
transform flow characteristics to be mapped into a specific
architectural style.
Architectural mapping using
Dataflow
• Step 1: Review the fundamental system model or context diagram
depicts the targeted system as a single transformation, representing
the external producers and consumers of data that flow into and out
of the system.
Architectural mapping using
Dataflow
• Step 2: Review and refine data flow diagrams for the software. Information
obtained from the requirements model is refined to produce greater detail
like Level 1,2 etc.
• Step 3. Determine whether the DFD has transform or transaction flow
characteristics.
• Step 4. Isolate the transform center by specifying incoming and outgoing flow
boundaries.
• Step 5. Perform “first-level factoring.”
• Step 6. Perform “second-level factoring.”
• Step 7. Refine the first-iteration architecture using design heuristics for
improved software quality.
Architectural mapping using
Dataflow
Evaluating the above DFD, we see data entering the software along one incoming path and exiting along
three outgoing paths. Therefore, an overall transform characteristic will be assumed for information
flow. an incoming flow boundary separating read sensors and acquire response info could be proposed.
Incoming and outgoing flow boundaries are open to interpretation
• Factoring leads to a program structure in which top-level components
perform decision making and low level components perform most
input, computation, and output work. Middle-level components
perform some control and do moderate amounts of work.
• An incoming information processing controller, called sensor input controller, coordinates receipt of all incoming
data.
• A transform flow controller, called alarm conditions controller, supervises all operations on data in internalized
form (e.g., a module that invokes various data transformation procedures). An outgoing information processing
controller, called alarm output controller, coordinates production of output information.
• Step 7:
• Refine the first-iteration architecture using design heuristics for improved software quality:Refinements are
dictated by the analysis and assessment methods
• e.g., when the controller for incoming data flow is totally unnecessary, when some input processing is required in
a component that is subordinate to the transform controller, when high coupling due to global data cannot be
avoided, or when optimal structural characteristics cannot be achieved.
• That is, once structure is defined, we can evaluate and refine software architecture by viewing it as a whole.
Modifications made at this time require little additional work, yet can have a profound impact on software quality.
Refining the Architectural Design
• Refinement of software architecture during early stages of design is to
be encouraged.
• Design refinement should strive for the smallest number of
components that is consistent with effective modularity and the least
complex data structure that adequately serves information
requirements.
User Interface Design
• Theo Mandel [Man97] coins three golden rules for UI design:
1. Place the user in control.
2. Reduce the user’s memory load.
3. Make the interface consistent.
User Interface Design
• Theo Mandel [Man97] coins three golden rules for UI design:
1. Place the user in control.
 Define interaction modes in a way that does not force a user into unnecessary or undesired
actions. e.g. When user is using spell check, he also can do text editing.
 Provide for flexible interaction like via keyboard commands, mouse movement, a digitizer
pen, a multitouch screen, or voice recognition commands, which ever is appropriate. Say for
drawing Keyboard is not appropriate.
 Allow user interaction to be interruptible and undoable. i.e. user can interrupt ongoing work
without loss of data, also can undo an action.
 Streamline interaction as skill levels advance and allow the interaction to be customized. e.g.
for repeatedly task-macro mechanism
 Hide technical internals from the casual user. i.e. Hide type of OS,I/O functions,
 Design for direct interaction with objects that appear on the screen. g. For example, an
application interface that allows a user to “stretch” an object (scale it in size) is an
implementation of direct manipulation.
User Interface Design
• Theo Mandel [Man97] coins three golden rules for UI design:
2. Reduce the user’s memory load: The more a user has to remember, the
more error-prone the interaction with the system will be.
 Reduce demand on short-term memory: Providing visual cues that enable a user to
recognize past actions, rather than having to recall them. Submit button,Links etc.
 Establish meaningful defaults:“reset” option should be available.
 Define shortcuts that are intuitive: the mnemonic should be tied to the action in a
way that is easy to remember. e.g. Ctl+P for print command
 The visual layout of the interface should be based on a real-world metaphor. This
enables the user to rely on well-understood visual cues, rather than memorizing.
e.g. Payment-Online credit card , interface should like real-word.
 Disclose information in a progressive fashion: The user must pick underlining; then
all underlining options (e.g., single underline, double underline, dashed underline)
are presented.
User Interface Design
• Theo Mandel [Man97] coins three golden rules for UI design:
3. Make the Interface Consistent.
Allow the user to put the current task into a meaningful context.
Provide indicators that enable the user to know the context of the work at
hand. e.g., window titles, graphical icons, consistent color coding.
In addition, the user should be able to determine where he has come from and
what alternatives exist for a transition to a new task. A set of applications (or
products) should all implement the same design rules so that consistency is
maintained for all interaction.
Maintain consistency across a family of applications: Accurate output or result
User Interface Design
• Theo Mandel [Man97] coins three golden rules for UI design:
3. Make the Interface Consistent.
If past interactive models have created user expectations, do not make
changes unless there is a compelling reason to do so. e.g. the use of alt-S to
save a file is done in one, the user expects this in every application. A change
(e.g., using alt-S to invoke scaling) will cause confusion.
User Interface Analysis and Design
• Interface Analysis and Design Models: user interface analysis and
design begins with the creation of different models of system
function.
• Four different models are used:
1. User model
2. Design model
3. User’s mental model
4. Implementation model
User Interface Analysis and Design
• User model created by a human engineer (or the software engineer).
• The user model establishes the profile of end users of the system.
• To build an effective user interface, “all design should begin with an understanding of the
intended users, including profiles of their age, gender, physical abilities, education,
cultural or ethnic background, motivation, goals and personality
• users can be categorized as:
• Novices. No syntactic knowledge of the system and little semantic knowledge of the application or
computer usage in general.
• Knowledgeable, intermittent users. Reasonable semantic knowledge of the application but relatively
low recall of syntactic information necessary to use the interface.
• Knowledgeable, frequent users. Good semantic and syntactic knowledge that often leads to the
“power-user syndrome”; that is, individuals who look for shortcuts and abbreviated modes of
interaction.
• Design model created by the software engineer.
User Interface Analysis and Design
• User’s mental model developed by the end user as a mental image or
the system perception. e.g. if the user of a particular word processor
were asked to describe its operation, the system perception would
guide the response.
• Implementation model created by the implementers of the system. It
covers the look and feel of the interface.
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 with the following activities:
• (1) interface analysis and modeling: focuses on the profile of the users (2)
interface design: defines a set of interface objects and actions. screen
representations.
• (3) interface construction: begins with the creation of a prototype that
enables usage scenarios to be evaluated.
• (4) interface validation: focuses on (1) the ability of the interface to
implement every user task correctly, to achieve all general user
requirements, how easy to learn and use, and users’ acceptance
User Interface Analysis and Design
• Interface Analysis
• Understand
1. the people (end users) who will interact with the system through the interface
known as user analysis. For this User Interviews can be done, inputs from sales,
marketing or support person can be taken.
2. the tasks that end users must perform to do their work, as task analysis.
What tasks and subtasks will be performed, What is the sequence of work tasks—the workflow?,
What is the hierarchy of tasks? etc., for this diagrams like Usecase can be used. Task analysis can
be done either mapping manual work with automated tasks or you can study an existing
specification for a computer-based solution and derive task that accommodate users model.
Focus on object elaboration with attributes as classes, understand how a work process is
completed when several people (and roles) are involved as work flow, a task hierarchy can be
defined for each user type.
User Interface Analysis and Design
• Interface Analysis
• Understand
3. the content that is presented as part of the interface:
display content can range from character-based reports (e.g., a spreadsheet), graphical
displays (e.g., a histogram, a 3-D model, a picture of a person), or specialized information (e.g.,
audio or video files).
4. the environment in which these tasks will be conducted:
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 may not be an option, display placement may be less than ideal
Interface Design Steps
1. Using information developed during interface analysis, define
interface objects and actions (operations):
• they are categorized by type. Target, source, and application objects are
identified.
• A source object (e.g., a report icon) is dragged and dropped onto a target
object (e.g., a printer icon), action is to create a hard-copy report.
• Application object represents application-specific data that are not directly
manipulated as part of screen interaction. For example, a mailing list is used
to store names for a mailing. The list itself might be sorted, merged, or purged
(menu-based actions), but it is not dragged and dropped via user interaction.
• After this, screen layout is performed.
Interface Design Steps
2. Define events (user actions) that will cause the state of the user
interface to change. Model this behavior.
• User Interface Design Patterns.
• A design pattern is an abstraction that prescribes a design solution to a
specific, well-bounded design problem. e.g. consider a situation in which a
user must enter one or more calendar dates, solution is CalendarStrip that
produces a continuous, scrollable calendar.
Interface Design Steps
3. Design Issues
• system response time, user help facilities, error information handling, and
Menu & command labeling.