Software Engineering

Vinaya Sathyanarayana
Architecture
• https://c4model.com/
• Context, Containers, Components, and Code
System Context diagram
• A System Context diagram is a good starting point for diagramming
and documenting a software system, allowing you to step back and
see the big picture. Draw a diagram showing your system as a box in
the centre, surrounded by its users and the other systems that it
interacts with.
• Detail isn't important here as this is your zoomed out view showing a
big picture of the system landscape. The focus should be on people
(actors, roles, personas, etc) and software systems rather than
technologies, protocols and other low-level details. It's the sort of
diagram that you could show to non-technical people.
Container diagram
• Once you understand how your system fits in to the overall IT environment,
a really useful next step is to zoom-in to the system boundary with a
Container diagram. A "container" is something like a server-side web
application, single-page application, desktop application, mobile app,
database schema, file system, etc. Essentially, a container is a separately
runnable/deployable unit (e.g. a separate process space) that executes
code or stores data.
• The Container diagram shows the high-level shape of the software
architecture and how responsibilities are distributed across it. It also shows
the major technology choices and how the containers communicate with
one another. It's a simple, high-level technology focussed diagram that is
useful for software developers and support/operations staff alike.
Component diagram
• Next you can zoom in and decompose each container further to
identify the major structural building blocks and their interactions.
• The Component diagram shows how a container is made up of a
number of "components", what each of those components are, their
responsibilities and the technology/implementation details.
Code diagram
• Finally, you can zoom in to each component to show how it is
implemented as code; using UML class diagrams, entity relationship
diagrams or similar.
• This is an optional level of detail and is often available on-demand
from tooling such as IDEs. Ideally this diagram would be automatically
generated using tooling (e.g. an IDE or UML modelling tool), and you
should consider showing only those attributes and methods that
allow you to tell the story that you want to tell. This level of detail is
not recommended for anything but the most important or complex
components.
Unit 9
Design Concepts
 Software Design
• Encompasses the set of principles, concepts, and practices that lead to the development
of a high quality system or product.
• Design principles establish and overriding philosophy that guides the designer as the
work is performed.
• Design concepts must be understood before the mechanics of design practice are
applied.
• Software design practices change continuously as new methods, better analysis, and
broader understanding evolve.

8
Software Engineering Design
• Data/Class design – transforms analysis classes into
implementation classes and data structures.
• Architectural design – defines relationships among the major
software structural elements.
• Interface design – defines how software elements, hardware
elements, and end-users communicate.
• Component-level design – transforms structural elements into
procedural descriptions of software components.

9
Mapping Requirements Model to Design
Model

• Access the text alternative for slide

images.
10
 Design and Quality
• The design must implement all of the explicit requirements contained in the analysis
model, and it must accommodate all of the implicit requirements desired by the
customer.
• The design should be a readable, understandable guide for those who generate code
and for those who test and subsequently support the software.
• The design should provide a complete picture of the software, addressing the data,
functional, and behavioral domains from an implementation perspective.

11
Quality Guidelines
1. A design should exhibit an architecture (a) created
using recognizable architectural styles or patterns, (b)
composed of well designed components (c)
implemented in an evolutionary fashion.
2. A design should be modular.
3. A design should contain distinct representations of
data, architecture, interfaces, and components.
4. A design should lead to data structures that are drawn
from recognizable data patterns.
5. A design should contain functionally independent
components.
6. A design should lead to interfaces that reduce the 12
complexity of connections between components and
Common Design Characteristics
• Each new software design methodology introduces unique heuristics and notions – yet
they each contain:
1. A mechanism for the translating the requirements model into a design representation.
2. A notation for representing functional components and their interfaces.
3. Heuristics for refinement and partitioning.
4. Guidelines for quality assessment.

13
Design Concepts 1

• Abstraction – data (named collection of data describing data object), procedural (name
sequence of instructions with specific and limited function).
• Architecture - overall structure or organization of software components, ways
components interact, and structure of data used by components.
• Design Patterns - describe a design structure that solves a well-defined design problem
within a specific context.
• Separation of concerns - any complex problem can be more easily handled if it is
subdivided into pieces.
• Modularity—compartmentalization of data and function.

14
Modularity and Software Cost

• Access the text alternative for slide

images.
15
Design Concepts 2

• Information Hiding - controlled interfaces which define and enforces access to

component procedural detail and any local data structure used by the component.
• Functional independence - single-minded (high cohesion) components with aversion to
excessive interaction with other components (low coupling).
• Stepwise Refinement – incremental elaboration of detail for all abstractions.
• Refactoring—a reorganization technique that simplifies the design without changing
functionality.
• Design Classes—provide design detail that will enable analysis classes to be
implemented.

16
Design Class Example

• Access the text alternative for slide

images.
17
Design Class Characteristics
• Complete - includes all necessary attributes and methods) and sufficient (contains only
those methods needed to achieve class intent).
• Primitiveness – each class method focuses on providing one service.
• High cohesion – small, focused, single-minded classes.
• Low coupling – class collaboration kept to minimum.

18
Information Hiding
• Reduces the likelihood of “side effects.”
• Limits the global impact of local design decisions.
• Emphasizes communication through controlled interfaces.
• Discourages the use of global data.
• Leads to encapsulation—an attribute of high quality design.
• Results in higher quality software.

19
Architecture Properties
• Structural properties. This aspect of the architectural design representation defines
the components of a system (for example, modules, objects, filters) and the manner in
components are packaged and interact with one another.
• Extra-functional properties. The architectural design description should address how
the design architecture achieves requirements for performance, capacity, reliability,
security, adaptability, and other characteristics.
• Families of related systems. The architectural design should draw upon repeatable
patterns (building blocks) often encountered in the design of similar systems.

20
Design Pattern Template
• Pattern name - describes the essence of the pattern in a short but expressive name

• Intent - describes the pattern and what it does

• Also-known-as - lists any synonyms for the pattern

• Motivation - provides an example of the problem

• Applicability - notes specific design situations in which the pattern is applicable

• Structure - describes the classes that are required to implement the pattern

• Participants - describes the responsibilities of the classes that are required to implement the pattern

• Collaborations - describes how the participants collaborate to carry out their responsibilities

• Consequences - describes the “design forces” that affect the pattern and the potential trade-offs that must be considered when the
pattern is implemented

• Related patterns - cross-references related design patterns

21
Design Model

• Access the text alternative for slide images.

22
Design Modeling Principles 1

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

model.
• Principle #2. Always consider the architecture of the system to
be built.
• Principle #3. Design of data is as important as design of
processing functions.
• Principle #4. Interfaces (both internal and external) must be
designed with care.
• Principle #5. User interface design should be tuned to the
needs of the end-user and stress ease of use.

23
Design Modeling Principles 2

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

independent.
• Principle #7. Components should be loosely coupled to each
other than the environment.
• Principle #8. Design representations (models) should be easily
understandable.
• Principle #9. The design should be developed iteratively.
• Principle #10. Creation of a design model does not preclude
using an agile approach.

24
Data Design Elements
• Data model – data objects and database architectures.
• Examines data objects independently of processing.
• Focuses attention on the data domain.
• Creates a model at the customer’s level of abstraction.
• Indicates how data objects relate to one another.

• Data object can be an external entity, a thing, an event, a place, a

role, an organizational unit, or a structure.
• Data objects contain a set of attributes that act as an quality,
characteristic, or descriptor of the object.
• Data objects may be connected to one another in many different
ways.

25
Architectural Design Elements
• Architectural design for software - equivalent to the floor plan for a house.
• The architectural model is derived from three sources:
• Information about the application domain for the software to be built.
• Specific requirements model elements such as data flow analysis classes and their relationships
(collaborations) for the problem at hand, and
• Availability of architectural patterns and styles.

26
Interface Design Elements
• Interface is a set of operations that describes the externally
observable behavior of a class and provides access to its public
operations.
• Important elements:
• User interface (UI).
• External interfaces to other systems.
• Internal interfaces between various design components.

• UI or User Experience (UX) is a major engineering action to

ensure the creation on usable software products.
• Internal and external interfaces should incorporate both error
checking and appropriate security features.

27
Interface Model for Control Panel

• Access the text alternative for slide images.

28
Component-Level Design Elements
• Describes the internal detail of each software component.
• Defines:
• Data structures for all local data objects.
• Algorithmic detail for all component processing functions.
• Interface that allows access to all component operations.

• Modeled using UML component diagrams.

29
Deployment Design Elements
• Indicates how software functionality and subsystems will be
allocated within the physical computing environment.
• Modeled using UML deployment diagrams.
• Descriptor form deployment diagrams - show the computing
environment but does not indicate configuration details.
• Instance form deployment diagrams - identify specific hardware
configurations and are developed in the latter stages of design.

30
UML Deployment Instance Diagram

• Access the text alternative for slide images.

31
 Unit 10
Architectural Design
What is Software Architecture?
• The architecture is not the operational software, it is a representation that enables a
software engineer 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.

33
Why is Software Architecture Important?
• Software architecture provides a representation that facilitates
communication among all stakeholders interested in the
development of a computer-based system.
• Architecture highlights early design decisions that will have a
profound impact on all software engineering work that follows.
• Architecture constitutes a relatively small, intellectually
graspable mode of how the system is structured and how its
components work together.

34
Architectural Descriptions
• The IEEE Computer Society has proposed IEEE-Std-42010-2011, Systems
and Software Engineering – Architecture Description.
Describes the use of architecture viewpoints, architecture frameworks, and architecture description
languages as a means of codifying the conventions and common practices for architectural description.
The IEEE Standard defines an architectural description (AD) as a “a collection of
products to document an architecture.”
• An architecture description shall identify the system stakeholders having concerns considered fundamental to the
architecture of the system-of-interest.
• These concerns shall be considered when applicable and identified in the architecture description: system purpose,
suitability of the architecture, feasibility of constructing and deploying the system, risks and impacts of the system,
and the maintainability and evolvability of the system.

35
Architecture Decision Documentation
1. Determine information items needed for each decision.
2. Define links between each decision and appropriate requirements.
3. Provide mechanisms to change status when alternative decisions need to be evaluated.
4. Define prerequisite relationships among decisions to support traceability.
5. Link significant decisions to architectural views resulting from decisions.
6. Document and communicate all decisions as they are made.

36
Agility and Architecture
• To avoid rework, user stories are used to create and evolve an architectural model
(walking skeleton) before beginning any coding.
• Use models which allow software architects to add user stories to the evolving
storyboard and works with the product owner to prioritize the architectural stories as
“sprints” (work units) are planned.
• Well run agile projects include delivery of architectural documentation during each
sprint.
• After the sprint is completed, the architect reviews the working prototype for quality
before the team presents it to the stakeholders in a formal sprint review.

37
Architectural Styles
• Each style describes a system category that encompasses:
1. set of components (for example: a database, computational
modules) that perform a function required by a system.
2. 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.

38
Data Centered Architecture

• Access the text alternative for slide

images.
39
Data Flow Architecture

• Access the text alternative for slide images.

40
Call Return Architecture

• Access the text alternative for slide images.

41
Object-Oriented Architecture

• Access the text alternative for slide images.

42
Layered Architecture

• Access the text alternative for slide images.

43
Model View Controller Architecture

• Access the text alternative for slide images.

44
Architectural Organization and
Refinement 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 (that is, the geometric form that the
control takes)?
• Is control synchronized, or do components operate
asynchronously?

45
Architectural Organization and
Refinement 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?
• Do data components exist, and if so, what is their role?
• How do functional components interact with data components?
• Are data components passive or active?
• How do data and control interact within the system?

46
Architectural Considerations
• Economy – software is uncluttered and relies on abstraction to reduce unnecessary
detail.
• Visibility – Architectural decisions and their justifications should be obvious to
software engineers who review.
• Spacing – Separation of concerns in a design without introducing hidden dependencies.
• Symmetry – Architectural symmetry implies that a system is consistent and balanced in
its attributes.
• Emergence – Emergent, self-organized behavior and control are key to creating
scalable, efficient, and economic software architectures.

47
Architectural Design
• The software must be placed into context.
• The design should define the external entities (other systems, devices,
people) that the software interacts with and the nature of the
interaction.
• A set of architectural archetypes should be identified.
• An archetype is an abstraction (similar to a class) that represents one
element of system behavior.
• The designer specifies the structure of the system by defining
and refining software components that implement each
archetype.

48
Architecture Context Diagram

• Access the text alternative for slide

images.
49
SafeHome Security Function Archetype

• Access the text alternative for slide images.

50
SafeHome Top-Level Component
Architecture

• Access the text alternative for slide

images.
51
SafeHome Refined Component
Architecture

• Access the text alternative for slide

images.
52
Architectural Tradeoff Analysis
1. Collect scenarios.
2. Elicit requirements, constraints, environment description.
3. Describe the architectural styles/patterns that have been chosen to address the scenarios
and requirements using one of these views: module, process, data flow.
4. Evaluate quality attributes by considering each one in isolation.
5. Identify the sensitivity of quality attributes to various architectural attributes for a
specific architectural style.
6. Critique candidate architectures (developed in step 3) using the sensitivity analysis
(conducted in step 5).

53
Architectural Reviews
• Assess the ability of the software architecture to meet the systems quality requirements
and identify potential risks.

• Have the potential to reduce project costs by detecting design problems early.

• Often make use of experience-based reviews, prototype evaluation, and scenario

reviews, and checklists.

54
Pattern-based Architectural Reviews
1. Identify and discuss the quality attributes by walking through
the use cases.
2. Discuss a diagram of system’s architecture in relation to its
requirements.
3. Identify the architecture patterns used and match the system’s
structure to the patterns’ structure.
4. Use existing documentation and use cases to determine each
pattern’s effect on quality attributes.
5. Identify all quality issues raised by architecture patterns used in
the design.
6. Develop a short summary of issues uncovered during the
meeting and make revisions to the walking skeleton.

55
 Unit 11
Component Level Design
What is a component?
• OMG Unified Modeling Language Specification defines a
component as
• “… a modular, deployable, and replaceable part of a system that
encapsulates implementation and exposes a set of interfaces.””
• Object-Oriented view: a component contains a set of
collaborating classes.
• Traditional view: a component contains processing logic,
internal data structures that are required to implement the
processing logic, and an interface that enables the component to
be invoked and data to be passed to it.
• Process-related view: building systems out of reusable software
components or design patterns selected from a catalog
(component-based software engineering).
57
Class-based Component-Level Design

• Access the text alternative for slide images.

58
Traditional Component-Level Design 1

• Access the text alternative for slide images.

59
Basic Component Design Principles
• Open-Closed Principle (O C P). “A module [component] should be open for extension
but closed for modification.
• Liskov Substitution Principle (L S P). “Subclasses should be substitutable for their
base classes.
• Dependency Inversion Principle (D I P). “Depend on abstractions. Do not depend on
concretions.”
• Interface Segregation Principle (I S P). “Many client-specific interfaces are better
than one general purpose interface.
• Release Reuse Equivalency Principle (R E P). “The granule of reuse is the granule of
release.”
• Common Closure Principle (C C P). “Classes that change together belong together.”
• Common Reuse Principle (C R P). “Classes that aren’t reused together should not be
grouped together.”
60
Component-Level Design Guidelines
• 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.
• Interfaces - provide important information about
communication and collaboration (as well as helping us
to achieve the O P C).
• Dependencies and Inheritance – For readability, it is a
good idea to model dependencies from left to right and
inheritance from bottom (derived classes) to top (base
classes).

61
Cohesion
• Traditional view - the “single-mindedness” of a module.
• Object-Oriented view - cohesion implies that a component
encapsulates only attributes and operations that are closely
related to one another and the component itself.
• Levels of cohesion:
• Functional - module performs one and only one computation.
• Layer - 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.

62
Coupling
• Traditional view - degree to which a component is connected
to other components and to the external world.
• Object-Oriented view - qualitative measure of the degree to
which classes are connected to one another.
• Levels of coupling.
• Content - occurs when one component “surreptitiously modifies
data that is internal to another component.
• Control – occurs when control flags a passed to components to
requests alternate behaviors when invoked.
• External - occurs when a component communicates or
collaborates with infrastructure components.

63
Component-Level Design 1

• Step 1. Identify all design classes that correspond to the problem

domain.
• Step 2. Identify all design classes that correspond to the
infrastructure domain.
• Step 3. Elaborate all design classes that are not acquired as
reusable components.
• Step 3a. Specify message details when classes or component
collaborate.
• Step 3b. Identify appropriate interfaces for each component.

64
Collaboration Diagram with Message Detail

• Access the text alternative for slide images.

65
Define Interfaces

• Access the text alternative for slide images.

66
Component-Level Design 2

• Step 3c. Elaborate attributes and define data types and data
structures required to implement them.
• Step 3d. Describe processing flow within each operation in
detail.
• Step 4. Describe persistent data sources (databases and files) and
identify the classes required to manage them.
• Step 5. Develop and elaborate behavioral representations for a
class or component.
• Step 6. Elaborate deployment diagrams to provide additional
implementation detail.
• Step 7. Factor every component-level design representation and
always consider alternatives.

67
Describe Processing Flow

• Access the text alternative for slide images.

68
Elaborate Behavioral Representations

• Access the text alternative for slide images.

69
Component-Level Design for WebApps
• WebApp component is:
1. a well-defined cohesive function that manipulates content or
provides computational or data processing for an end-user, or.
2. a cohesive package of content and functionality that provides
end-user with some required capability.

• Component-level design for WebApps often incorporates

elements of content design and functional design.

70
WebApp Content Design
• Focuses on content objects and the manner in which
they may be packaged for presentation to a WebApp
end-user
• Consider a Web-based video surveillance capability
within SafeHomeAssured.com potential content
components can be defined for the video surveillance
capability:
1. the content objects that represent the space layout (the floor plan) with
additional icons representing the location of sensors and video cameras;
2. the collection of thumbnail video captures (each an separate data object), and
3. the streaming video window for a specific camera.

• Each of these components can be separately named and manipulated as a

package.
71
WebApp Functional Design
• Modern Web applications deliver increasingly
sophisticated processing functions that:
1. perform localized processing to generate content and navigation capability
in a dynamic fashion;
2. provide computation or data processing capability that is appropriate for
the WebApp’s business domain;
3. provide sophisticated database query and access, or.
4. establish data interfaces with external corporate systems.
• To achieve these (and many other) capabilities, you will design and construct
WebApp functional components that are identical in form to software
components for conventional software.

72
Component-Level Design for Mobile Apps
• Thin web-based client.
• Interface layer only on device.
• Business and data layers implemented using web or cloud
services.

• Rich client.
• All three layers (interface, business, data) implemented on
device.
• Subject to mobile device limitations.

73
Traditional Component-Level Design 2

• Design of processing logic is governed by the basic principles

of algorithm design and structured programming.
• Design of data structures is defined by the data model
developed for the system.
• Design of interfaces is governed by the collaborations that a
component must effect.

74
Component-Based Software Engineering (CBSE)
• The software team asks:
• Are commercial off-the-shelf (COTS) components available to
implement the requirement?
• Are internally-developed reusable components available to
implement the requirement?
• Are the interfaces for available components compatible within
the architecture of the system to be built?

• Access the text alternative for slide images.

75
CBSE Benefits
• Reduced lead time. It is faster to build complete
applications from a pool of existing components.
• Greater return on investment (ROI). Sometimes savings
can be realized by purchasing components rather than
redeveloping the same functionality in-house.
• Leveraged costs of developing components. Reusing
components in multiple applications allows the costs to be
spread over multiple projects.
• Enhanced quality. Components are reused and tested in
many different applications.
• Maintenance of component-based applications. With
careful engineering, it can be relatively easy to replace
obsolete components with new or enhanced components.

76
CBSE Risks
• Component selection risks. It is difficult to predict component behavior for
black-box components, or there may be poor mapping of user requirements to the
component architectural design.
• Component integration risks. There is a lack of interoperability standards
between components; this often requires the creation of “wrapper code” to
interface components.
• Quality risks. Unknown design assumptions made for the components makes
testing more difficult, and this can affect system safety, performance, and
reliability.
• Security risks. A system can be used in unintended ways, and system
vulnerabilities can be caused by integrating components in untested
combinations.
• System evolution risks. Updated components may be incompatible with user
requirements or contain additional undocumented features.

77
Component Refactoring
• Most developers would agree that refactoring components to
improve quality is a good practice.
• It is hard to convince management to expend resources fixing
components that are working correctly rather than adding new
functionality to them,
• Changing software and failing to document the changes can lead
to increasing technical debt.
• Reducing this technical debt often involves architectural
refactoring, which is generally perceived by developers as both
costly and risky.
• Developers can make of tools to examine change histories to
identify the most cost effective refactoring opportunities,

78
 Unit 12
User Experience Design
 User Experience Design Elements 1

• User experience design tries to ensure that no aspect of your software

appears the final product without the explicit decision of stakeholders to
include it.
• Strategy. Identifies user needs and customer business goals that form the
basis for all UX design work.
• Scope. Includes both the functional and content requirements needed to
realize a feature set consistent with the project strategy.
• Structure. Consists of the interaction design [For example, how the system
reacts in response to user action] and information architecture.
• Skeleton. Comprised of three components: information design, interface
design, navigation design.
• Surface. Presents visual design or the appearance of the finished project to
its users. 80
User Experience Design Elements 2

• Access the text alternative for slide

images.
81
Information Architecture
• Information architecture structures lead organization,
labeling, navigation, and searching of content objects.
• Content architecture focuses on the manner content objects are
structured for presentation and navigation.
• Software architecture addresses the manner the application is
structured to manage user interaction, effect navigation, and
present content.
• Architecture design is conducted in parallel with interface
design, aesthetic design, and content design.
• Decisions made during architecture design action will influence
work conducted during navigation design.

82
 User Interaction Design
• Interaction design focuses on interface between product and user.
• Modes of user input and output include voice input, computer speech
generation, touch input, 3D printed output, immersive augmented reality
experiences, and sensor tracking of users.
• User interaction should be defined by the stakeholders in the user stories
created to describe how users can accomplish their goals using the software
product.
• User interaction design should also include a plan for how information
should be presented within such a system and how to enable the user to
understand that information.
• It is important to recall that the purpose of the user interface is to present just
enough information to help the users decide what their next action should be
to accomplish their goal and how to perform it. 83
 Usability Engineering
• Usability engineering is part of UX design work that defines the
specification, design, and testing of the human-computer interaction portion
of a software product.
• This software engineering action focuses on devising human-computer
interfaces that have high usability.
• If developers focus on making a product easy to learn, easy to use, and easy
to remember over time, usability can be measured quantitatively and tested
for improvements in usability.
• Accessibility is the degree to which people with special needs are provided
with a means to perceive, understand, navigate, and interact with computer
products.
• Accessibility is another aspect of usability engineering that needs to be
considered during design. 84
 Visual Design
• Visual design (aesthetic design or graphic design) is an artistic
endeavor that complements the technical aspects of the user experience
design.
• Without it, a software product may be functional, but unappealing.
• With it, a product draws its users into a world that embraces them on an
emotional as well as an intellectual level.
• Graphic design considers every aspect of the look and feel of a web or
mobile app.
• Not every software engineer has artistic talent. If you fall into this
category, hire an experienced graphic designer to help.

85
Golden Rule 1: Place User in Control
• 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 screen objects.

86
Golden Rule 2: 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.

87
Golden Rule 3: Make Interface Consistent
• Allow the user to put the current task into a meaningful
context.
• Maintain consistency across a family of applications.
• If past interactive models have created user expectations, do
not make changes unless there is a compelling reason to do so.

88
User Interface Design Models
• User model — a profile of all end users of the system.
• Design model — a design realization of the user model.
• Mental model (system perception) — the user’s mental image of
what the interface is.
• Implementation model — the interface “look and feel” coupled
with supporting information that describe interface syntax and
semantics.

• An interface designer needs to reconcile these models and derive

a consistent representation of the interface.

89
User Interface Design Process

• Access the text alternative for slide

images.
90
 User Interface Analysis and Design
• Interface analysis focuses on the profile of the users who will
interact with the system.
• Interface design defines a set of interface objects and actions
that enable a user to perform all defined tasks in a manner that
meets every usability goal defined for the system.
• Interface construction normally begins with the creation of a
prototype that enables usage scenarios to be evaluated.
• Interface validation focuses on:
1. The ability of the interface to implement every user task correctly.
2. The degree to which interface is easy to use and easy to learn.
3. The user’s acceptance of the interface as a tool in her work.

91
User Experience Analysis
• In the case of user experience 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.

92
 Using Customer Journey Map
1. Gather stakeholders.
2. Conduct research. Collect all information you can about all the things
users may experience as they use the software product and define your
customer phases (touchpoints).
3. Build the model. Create a visualization of the touch points.
4. Refine the design. Recruit a designer to make the deliverable visually
appealing and ensure touchpoints are identified clearly.
5. Identify gaps. Note any gaps in the customer experience or points of
friction or pain (poor transition between phases).
6. Implement your findings. Assign responsible parties to bridge the gaps
and resolve pain points found.
93
Customer Journey Map

• Access the text alternative for slide

images.
94
 Creating and Using Personas in UX Design
• Data collection and analysis. Stakeholders collect information about
proposed product users and determine the user group needs.
• Describe personas. The developers need to decide how many personas
to create and decide which persona will be their focus.
• Develop scenarios. Scenarios are user stories about how personas will
use the product being developed. They may focus on the touchpoints and
obstacles described in the customer journey.
• Acceptance by stakeholders. Often this is done by validating the
scenarios using a review technique or demonstration called cognitive
walkthrough (stakeholders assume the role defined by a persona and
work through a scenario using a system prototype).

95
Persona Example

• Access the text alternative for slide

images.
96
Task Analysis
• Goal of task (scenario) 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?

97
Iterative UX Design Process

• Access the text alternative for slide

images.
98
 Google 5-Day UX Design Sprint 1

• Understand. User research activities (user needs and business goals) for
the software product. This information is posted on whiteboards (For
example, customer journey maps, personas, user task workflow) for easy
reference throughout the sprint.
• Sketch. Individual stakeholders are given the time and space needed to
brainstorm solutions to the problems discovered in the understand phase.
Paper drawings and notes are easy to generate, easy to modify, and quite
inexpensive.
• Decide. Each stakeholder presents his solution sketch and the team votes
to determine the solutions that should be tackled in the prototyping
activities that will follow. If there is not a clear consensus following the
voting, the development team may decide to consider assumptions that
involve project constraints and resources.
99
Google 5-Day UX Design Sprint 2

• Prototype. May be a minimally viable product based

on the solution selected from the sketch phase, or it
may be based on the portions of the customer journey
map or storyboard you want to evaluate with potential
users in the validate phase. This means the team should
be developing test cases based on the user stories as the
prototype is being built.
• Validate. Every developer watching users try out the
prototype this is the best way to discover major issues
with its UX design, which in turn lets you start
iterating immediately. This is critical to capturing
potential learning opportunities by exposing product
decision makers to user feedback in real time.
100
Interface Design Evaluation Cycle

• Access the text alternative for slide images.

101
 User Interface Design Evaluation Criteria
• The design model (user stories, storyboard, personas, etc.) of the interface can be
evaluated during early design reviews:
1. 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. 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. 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.

102
 Usability Guidelines 1

• Anticipation. An application should be designed so that it anticipates the

user’s next move.
• Communication. The interface should communicate the status of any
activity initiated by the user.
• Consistency. The use of navigation controls, menus, icons, and aesthetics
(For example, color, shape, layout) should be consistent throughout.
• Controlled Autonomy. The interface should facilitate user movement
throughout the application, but it should do so in a manner that enforces
navigation conventions that have been established for the application.
• Efficiency. The design of the application and its interface should optimize
the user’s work efficiency.

103
 Usability Guidelines 2

• Flexibility. The interface should be flexible enough to enable some users to

accomplish tasks directly and others to explore the application in a
somewhat random fashion.
• Focus. The interface (and the content it presents) should stay focused on
the user task(s) at hand.
• Human Interface Objects. A vast library of reusable human interface
objects has been developed for both Web and mobile apps. Use them.
• Latency Reduction. Rather than making the user wait for some internal
operation to complete (for example, downloading a complex graphical
image), the application should use multitasking in a way that lets the user
proceed with work as if the operation has been completed.

104
 Usability Guidelines 3

• Learnability. An application interface should be designed to minimize

learning time and, once learned, to minimize relearning required when
the app is revisited.
• Metaphors. An interface that uses an interaction metaphor is easier to
learn and easier to use, as long as the metaphor is appropriate for the
application and the user.
• Readability. All information presented through the interface should be
readable by young and old.
• Track State. When appropriate, the state of the user interaction should be
tracked and stored so that a user can log off and return later to pick up
where he left off.
• Visible Navigation. A well-designed interface provides the illusion that
users are in the same place, with the work brought to them. 105
 Accessibilty Guidelines 1

• Application Accessibility. Software engineers must ensure that interface

design encompasses mechanisms that enable easy for people with special
needs.
• Response Time. System response time has two important characteristics:
length and variability. Aim for consistency to avoid user frustration.
• Help Facilities. Modern software should provide online help facilities that
enable a user to get a question answered or resolve a problem without
leaving the interface.
• Error Handling. Every error message or warning produced by an
interactive system should: use user understandable jargon, provide
constructive error recovery advice, identify negative consequences of errors,
contain an audible or visual cue, and never blame user for causing the error.
106
 Accessibilty Guidelines 2

• Menu and Command Labeling. The use of window-oriented, point-

and-pick interfaces has reduced reliance on typed commands. How
every it is important to: ensure every menu option has a command
version, make commands easy for users to type, make commands easy
to remember, allow for command abbreviation, make sure menu labels
are self-explanatory, make sure submenus match style of master menu
items, and ensure command conventions work across the family of
applications.
• Internationalization. Software engineers and their managers invariably
underestimate the effort and skills required to create user interfaces that
accommodate the needs of different locales and languages.

107
Unit 13
Mobile Design
Mobile Development Challenges
• Mobile devices have many features in common with each other, but often provide very
different user experiences.
• Some users expect the same features provided on their laptops.
• Other users like freedom that portable devices give them and accept reduced
functionality in a mobile software product version.
• Some users expect unique experiences not possible on traditional computing or
entertainment devices.
• The user’s perception of “goodness” might be more important than any of the technical
quality dimensions of the mobile product itself.
• Software engineers should craft a user experience that takes advantage of device
characteristics and context-aware applications.
• Testing mobile software products provides additional challenges.

109
Mobile Technical Considerations
• Multiple hardware and software platforms.
• Many development frameworks and programming languages.
• Many app stores with different rules and tools.
• Very short development cycles.
• User interface limitations and complexities of interaction with sensors and cameras.
• Effective use of context.
• Power management.
• Security and privacy models and policies.
• Computational and storage limitations.
• Applications that depend on external services.
• Testing complexity.

110
Mobile Development Life Cycle
• Inception. Goals, features, and functions of the mobile product are identified to
determine the scope and the size of the first increment.
• Design. Developers define the app user experience using screen mockups and paper
prototypes to help a user interface design that will take different screen sizes and
capabilities into account.
• Development. Mobile software is coded, test cases are created. Usability and
accessibility tests conducted as the product evolves.
• Stabilization. Most mobile products go through a series of prototypes: feasibility (one
logic path ); alpha prototype (minimum viable product); beta prototype (largely
complete); and release candidate (all required functionality) ready for product owner
review.
• Deployment. Once stabilized a mobile product is reviewed by a commercial app store
and made available for sale and download.
111
Useful Mobile User Interface Design
Models
• A platform model describes the constraints imposed by each
platform to be supported.

• A presentation model describes the appearance of the user

interface.

• The task model is a structured representation of the tasks a user

needs to perform to meet her task goals.

112
Mobile User Interface Design
Considerations
• Define user interface brand signatures.
• Focus the portfolio of products.
• Identify the core user stories.
• Optimize user interface flows and elements.
• Define scaling rules.
• User performance dashboard.
• Champion-dedicated user interface engineering skills.

113
Mobile User Interface Evaluation
• In trying to meet stakeholder usability expectations, mobile developers should attempt to
answer these questions to assess the out-of-the-box readiness of the device:
• Is the user interface consistent across applications?
• Is the device interoperable with different network services?
• Is the device acceptable in terms of stakeholder values in the target market area?

114
Mobile Design Approaches
• Usage Scenarios. Must consider context variables (location, user, and
device) and transitions between contextual scenarios (locations and
settings, movement and posture, devices and usages, workloads and
distractions, user preferences).
• Ethnographic Observation. Used method to gather information about
representative users of a software product by observing them as they use
the product in a natural setting. Can be tricky to observe them without
interfering with their product use.
• Low-Fidelity Paper Prototypes (for example: cards or Post-it notes).
Cost-effective usability assessment approach in user interface design that
can be used before any programming takes place. It is important for these
prototypes to be similar in size, weight, appearance to allow their use in a
variety of contexts.
115
Mobile Design Mistakes
• Kitchen sink. Avoid adding too many features to the app and too many widgets on the
screen.
• Inconsistency. Set standards for page navigation, menu use, buttons, tabs, and other UI
elements. Stick to uniform look and feel.
• Overdesigning. Remove unnecessary elements and wasteful graphics. Do not be
tempted to add things without thinking.
• Lack of speed. Users do not care about device constraints—they want to view things
quickly. Preload what you can.
• Verbiage. Unnecessarily long, wordy menus and screen displays
• Nonstandard interaction. Take advantage of the user’s experience with the way things
are done on the platform.
• Help-and-FAQ-itis. Adding online help is not the way to repair a poorly designed user
interface.
116
Services Computing
• Focuses on architectural design and enables application development through service
discovery and composition.
• Allows mobile app developers to avoid the need to integrate service source code into the
client running on a mobile device.
• Runs out of the provider’s server and is loosely coupled with applications that use it via
messaging protocols.
• Provides an API (application programming interface) to allow service to be treated like
an abstract black box.

117
Cloud Computing
• Cloud architecture has three service layers
• Software as service layer consists of software components and applications hosted by
third-party service providers.
• Platform as service layer provides a collaborative development platform to assist with
design, implementation, and testing by geographically distributed team members.
• Infrastructure and service provides virtual computing resources (storage, processing
power, network connectivity) on the cloud.

118
Context-Aware Apps
• Context allows the creation of apps based on the location of the mobile
device and the device functionality to be delivered.
• Context helps tailor personal computer apps for mobile devices.
• Mobile computing merges real and virtual worlds by allowing devices to be
aware of other objects and its surroundings.
• Device must detect the presence and identity of a user, as well as the
attributes of the context that are relevant for that user.
• Extracting relevant context information from several sensors is challenging
(for example: noise, miscalibration, wear and tear, weather).
• Event-based communication is preferable to the management of continuous
streams of high-abstraction-level data in context-aware applications.
119
Web Design Pyramid

• Access the text alternative for slide

images
120
Objectives of Web Interface Design
• Establish a consistent window into the content and functionality
provided by the interface.
• To achieve a consistent interface, you should use visual
design to establish a coherent “look.”
• Guide the user through series of WebApp interactions.
• You may draw on an appropriate metaphor that enables the
user to gain an intuitive understanding of the interface.

• Organize navigation options available to the user.

• It is important to note that one or more navigation mechanisms
should be provided at every level of the content hierarchy.

121
Aesthetic Design
• Don’t be afraid of white space.
• Emphasize content.
• Organize layout elements from top-left to bottom right.
• Group navigation, content, and function geographically within
the page.
• Don’t extend your real estate with the scrolling bar.
• Consider resolution and browser window size when designing
layout.

122
Content Design
• Content design develops a representation for content objects.

• A content object has attributes that include content-specific information and

implementation-specific attributes that are specified as part of design.

• For WebApps, a content object is more closely aligned with a data object for
conventional software.

123
Architecture Design
• Architecture design is conducted in parallel with interface design, aesthetic design and
content design.
• Content architecture focuses on the manner in which content objects (or composite
objects such as Web pages) are structured for presentation and navigation.
• Information architecture is also used to connote structures that lead to better
organization, labeling, navigation, and searching of content objects.
• WebApp architecture addresses ways the application is structured to manage user
interaction, handle processing tasks, effect navigation, and present content.

124
Model View Controller (MVC)

• Access the text alternative for slide

images
125
WebApp MVC Architecture
• The model contains application specific content and processing logic:
• all content objects.
• access to external data/information sources,
• all processing functionality that are application specific.

• The view contains all interface specific functions and enables

• presentation of content and processing logic.
• access to external data/information sources,
• all processing functionality required by the end-user.

• The controller manages access to the model and the view and
coordinates the flow of data between them.
126
Navigation Design
• Begins with a consideration of the user hierarchy and related
use-cases
• Each actor may use the WebApp somewhat differently and
therefore have different navigation requirements.

• As each user interacts with the WebApp, she encounters a series

of navigation semantic units (NSUs)
• NSU—“a set of information and related navigation structures
that collaborate in the fulfillment of a subset of related user
requirements”.

127
Creating NSU

• Access the text alternative for slide

images
128
Mobile Component Design
• Mobile apps deliver sophisticated processing functions
that:
1. Perform localized processing to generate content and
navigation capability in a dynamic fashion.
2. Provide computation or data processing capability that
are appropriate for the app’s business domain.
3. Provide sophisticated database query and access, and
4. Establish data interfaces with external corporate
systems.
• To achieve these (and many other) capabilities, you must
design and construct program components that are identical
in form to software components for traditional software. 129
Mobility and Web Quality

• Access the text alternative for slide

images
130
Mobility and Design Quality 1

• Security
• Rebuff external attacks.
• Exclude unauthorized access.
• Ensure the privacy of users/customers.

• Availability
• Percentage of time that an is available for use.

• Scalability
• Can the app and the systems with which it is interfaced handle
significant variation in user or transaction volume.

131
Mobility and Design Quality 2

• Time to Market
• Measure of quality from a business point of view.
• First mobile product to address a specific market segment often
captures the most end users.

• Content Quality
• Lots of competition on the web.
• How does the user assess the quality (for example: veracity,
accuracy, completeness, timeliness) of the content that is
presented within a mobile product?
• This is part of what data science tries to address.

132
Mobility Product Quality Checklist 1

• Can content and/or function and/or navigation options be tailored to the

user’s preferences?
• Can content and/or functionality be customized to the bandwidth at which
the user communicates? Does the app account for weak or lost signal in an
acceptable manner?
• Can content and/or function and/or navigation options be made context
aware according to the user’s preferences?
• Has adequate consideration been given to the power availability on the
target device(s)?
• Have graphics, media (audio, video), and other web or cloud services been
used appropriately?
133
Mobility Product Quality Checklist 2

• Is the overall page design easy to read and navigate?

• Does the app take screen size differences into account?
• Does the user interface conform to the display and interaction standards
adopted for the targeted mobile device(s)?
• Does the app conform to the reliability, security, and privacy expectations
of its users?
• What provisions have been made to ensure app remains current?
• Has the mobile product been tested in all targeted user environments and
for all targeted devices?

134
Mobility Design Best Practices
• Identify the audience.
• Design for context of use.
• There is a fine line between simplicity and laziness.
• Use the platform as an advantage.
• Make scrollbars and selection highlighting more salient.
• Increase discoverability of advanced functionality.
• Use clear and consistent labels.
• Cleaver icons should never be developed at the expense of user
Understanding.
• Support user expectations for personalization.
• Long scrolling forms trump multiple screens on mobile devices.
135
Unit 14
Design Patterns
Design Patterns
• Design pattern can be thought of as a three-part rule which
expresses a relation between a certain context, a problem, and a
solution.
• Context allows the reader to understand the environment in
which the problem resides and what solution might be
appropriate within that environment.
• Requirements, including limitations and constraints, acts as a
system of forces that influences how:
• The problem can be interpreted within its context.
• The solution can be effectively applied.

137
Effective Design Pattern
• Solves a problem: Patterns capture solutions, not just abstract
principles or strategies.
• Proven concept: Patterns capture solutions with proven track
records, not theories or speculation.
• Solution isn't obvious: The best patterns generate a solution to a
problem indirectly--a necessary approach for the most difficult
problems of design.
• Describes a relationship: Patterns don't just describe modules,
but describe deeper system structures and mechanisms.
• Elegant in its approach and utlity: describes simple solutions to
specific problems; the best patterns explicitly appeal to
aesthetics and usefulness.

138
Kinds of Patterns 1

• Architectural patterns describe broad-based design problems

that are solved using a structural approach.
• Data patterns describe recurring data-oriented problems and
the data modeling solutions that can be used to solve them.
• Component patterns (design patterns) address problems
associated with the development of subsystems and
components, the manner in which they communicate with one
another, and their placement within a larger architecture.

139
Kinds of Patterns 2

• Interface design patterns describe common user interface

problems and their solution with a system of forces that
includes the specific characteristics of end-users.
• WebApp patterns address a problem set that is encountered
when building WebApps and often incorporate many of other
patterns categories.
• Mobile patterns describe solutions to problems commonly
encountered when developing solutions for mobile platforms.

140
Kinds of Patterns 3

• Creational patterns focus on “creation, composition, and representation of objects”

• Abstract factory pattern: centralize decision of what factory to instantiate.
• Builder pattern: separates the construction of a complex object from its representation.

• Structural patterns focus on problems and solutions associated with how classes and objects are
organized and integrated to build a larger structure:
• Adapter pattern: 'adapts' one interface for a class into one that a client expects.
• Container pattern: create objects for the sole purpose of holding other objects and managing them.

• Behavioral patterns address problems associated with the assignment of responsibility between
objects and the manner in which communication is effected between objects:
• Chain of responsibility pattern: Command objects are handled or passed on to other objects by logic-containing processing
objects.
• Command pattern: Command objects encapsulate an action and its parameters.

141
Frameworks
• Patterns themselves may not be sufficient to develop a complete design.
• In some cases it may be necessary to provide an implementation-specific
skeletal infrastructure, called a framework, for design work.
• You can select a reusable architecture that provides the generic structure and
behavior for a family of software abstractions along with their context which
specifies use within a given domain.

• A framework is not an architectural pattern, but rather a skeleton with a

collection of “plug points” (hooks or slots) that enable it to be adapted to a
specific problem domain.
• Plug points enable you to integrate problem specific classes or functionality
within the skeleton.
• Collection of cooperating classes.

142
Pattern Description 1

• Pattern name—describes the essence of the pattern in

a short but expressive name
• Problem—describes the problem that the pattern
addresses
• Motivation—provides an example of the problem
• Context—describes the environment in which the
problem resides including application domain
• Forces—lists the system of forces that affect the
manner in which the problem must be solved; includes
a discussion of limitation and constraints that must be
considered
• Solution—provides a detailed description of the
solution proposed for the problem 143
Pattern Description 2

• Intent—describes the pattern and what it does

• Collaborations—describes how other patterns
contribute to the solution
• Consequences—describes the potential trade-offs that
must be considered when the pattern is implemented
and the consequences of using the pattern
• Implementation—identifies special issues that should
be considered when implementing the pattern
• Known uses—provides examples of actual uses of the
design pattern in real applications
• Related patterns—cross-references related design
patterns
144
Pattern-Based Design
• A software designer begins with a requirements model (either
explicit or implied) that presents an abstract representation of
the system.
• The requirements model describes the problem set, establishes
the context, and identifies the system of forces that hold sway.
• If you discover you are faced with a problem, context, and
system of forces that have solved before then use that solution.
• If it is a new problem then use the methods and modeling tools
available for architectural, component-level, and interface
design to create a new solution (pattern).

145
Pattern-Based Design in Context

• Access the text alternative for slide

images.
146
Thinking in Patterns
1. Be sure you understand big picture (requirements model) - the
context in which the software to be built resides.
2. Examining the big picture, extract the patterns that are present
at that level of abstraction.
3. Begin your design with ‘big picture’ patterns that establish a
context or skeleton for further design work.
4. Work inward from the context, look for patterns at lower levels
of abstraction that contribute to design solution.
5. Repeat steps 1 to 4 until complete design is fleshed out.
6. Refine the design by adapting each pattern to the specifics of
the software you’re trying to build.

147
Design Tasks 1

1. Examine the requirements model and develop a problem

hierarchy.
2. Determine if a reliable pattern language has been developed
for the problem domain.
3. Beginning with a broad problem, determine whether one or
more architectural patterns are available for it.
4. Using the collaborations provided for the architectural pattern,
examine subsystem or component level problems, and search
for patterns to address them.

148
Design Tasks 2

5. Repeat steps 2 through 5 until all broad problems have been

addressed.
6. If user interface design problems have been isolated, search
the user interface design pattern repositories for appropriate
patterns.
7. Regardless of its level of abstraction, if a pattern language
and/or patterns repository or individual pattern shows promise,
compare the problem to be solved against the existing
pattern(s) presented.
8. Be certain to refine the design as it is derived from patterns
using design quality criteria as a guide.

149
Pattern Organizing Table

• Access the text alternative for slide

images.
150
Common Mistakes
• Not enough time has been spent to understand the underlying
problem, its context and forces, and as a consequence, you
select a pattern that looks right, but is inappropriate for the
solution required.
• Once the wrong pattern is selected, you refuse to see your error
and force fit the pattern.
• In other cases, the problem has forces that are not considered
by the pattern you’ve chosen, resulting in a poor or erroneous
fit.
• Sometimes a pattern is applied too literally and the required
adaptations for your problem space are not implemented.

151
Architectural Patterns
• Example: every house (and every architectural style for houses)
employs a Kitchen pattern.
• Kitchen pattern and patterns it collaborates with address
problems associated with storage and preparation of food, tools
required to accomplish these tasks, and rules for placement of
these tools relative to workflow in the room.
• The pattern might address problems associated with counter
tops, lighting, wall switches, a central island, flooring, and so
on.
• Obviously, there is more than a single design for a kitchen, but
every design can be conceived within the context and system
forces of the ‘solution’ suggested by the Kitchen pattern.

152
Component-Level Design Patterns 1

• Component-level design patterns provide a proven solution that

addresses one or more sub-problems extracted from the
requirement model.

• In many cases, design patterns of this type focus on some

functional element of a system.

• For example: the SafeHomeAssured.com application must

address the following design sub-problem: How can we get
product specifications and related information for any
SafeHome device?

153
Component-Level Design Patterns 2

• Having enunciated the sub-problem that must be solved,

consider context and the system of forces that affect the
solution.
• Examining the appropriate requirements model use case, the
specification for a SafeHome device (for example: a security
sensor or camera) is used for informational purposes by the
consumer.
• However, other information that is related to the specification
(for example: pricing) may be used when e-commerce
functionality is selected.
• The solution to the sub-problem involves a search. Since
searching is a very common problem, it should come as no
surprise that there are many search-related patterns.

154
Search Patterns
• HelpWizard. Users need help on a certain topic related to the
website or when they need to find a specific page within the
site.
• SearchArea. Users must find a page.
• SearchTips. Users need to know how to control the search
engine.
• SearchResults. Users must process a list of search results.
• SearchBox. Users must find an item or specific information.

155
Anti-Patterns
• Anti-patterns describe commonly used solutions to design
problems that usually have negative effects on software quality.
• Anti-patterns can provide tools to help developers recognize
when these problems exist and may provide detailed plans for
reversing the underlying problem causes and implementing
better solutions to these problems.
• Anti-patterns can provide guidance to developers looking for
ways to refactor software to improve its quality.
• Anti-patterns can be used by technical reviewers to uncover
areas of concern.

156
Selected Anti-Patterns
• Blob. Single class with large number of attributes, operators, or both.
• Stovepipe system. A barely maintainable assemblage of ill-related
components.
• Boat anchor. Retaining a part of system that no longer has any use.
• Spaghetti code. Program whose structure is barely comprehensible,
especially because of misuse of code structures.
• Copy and paste programming. Copying existing code several times rather
than creating generic solutions.
• Silver bullet. Assume that a favorite technical solution will always solve a
larger process or problem.
• Programming by permutation. Trying to approach a solution by
successively modifying the code to see if it works.
157
 User Interface (UI) Patterns
• Whole UI. Provide design guidance for top-level structure and
navigation throughout the entire interface.
• Top-level Navigation. Provides a top-level menu, often
coupled with a logo or identifying graphic, that enables direct
navigation to any of the system’s major functions.
• Page layout. Address the general organization of pages (for
Websites) or distinct screen displays (for interactive
applications).
• E-commerce. Specific to Web sites, these patterns implement
recurring elements of e-commerce applications.
• Shopping cart. Provides a list of items selected for purchase.
158
Mobility Design Patterns
• Check-in screens. How do I check in from a specific location, make a
comment, and share comments with friends and followers on a social
network?
• Maps. How do I display a map within the context of an app that
addresses some other subject?
• Popovers. How do I represent a message or information that arises in real
time or as the consequence of a user action?
• Sign-up flows. How do I provide a simple way to sign in or register for
information or functionality?
• Custom tab navigation. How do I represent a variety of different content
objects in a manner that enables user to select one?
• Invitations. How do I inform the user that he must participate in some
action or dialog?

159