Cooperation between Concurrent Objects

• A concurrent object (active object) has its own thread of control and can execute
independently of other objects.

• Passive objects have operations that are invoked by concurrent objects.

• In the design of concurrent systems, several problems need to be considered that do not
arise in the design of sequential systems.

• In most concurrent applications, concurrent objects must cooperate with each other in
order to perform the services required by the application.

Problems
• The mutual exclusion problem occurs when concurrent objects need to have exclusive
access to a resource, such as shared data or a physical device. A variation on this problem, in
which the mutual exclusion constraint can sometimes be relaxed, is the multiple readers and
writer's problem.

• The synchronization problem occurs when two concurrent objects need to synchronize their
operations with each other.

• The producer/consumer problem occurs when concurrent objects need to communicate

with each other in order to pass data from one concurrent object to another.
Communication between concurrent objects is often referred to as inter process
communication (IPC).

Asynchronous Message Communication

• With asynchronous message communication, also referred to as loosely coupled message

communication, the producer sends a message to the consumer and either does not need a
response or has other functions to perform before receiving a response.

• Thus, the producer sends a message and continues without waiting for a response.

• The consumer receives the message.

Synchronous Message Communication with Reply

• In the case of synchronous message communication with reply, also referred to as tightly
coupled message communication with reply, the producer sends a message to the consumer
and then waits for a reply.

• When the message arrives, the consumer accepts the message, processes it, generates a
reply, and then sends the reply.

• The producer and consumer then both continue.

Design Patterns
• In software design, one frequently encounters a problem that one has solved before on a
different project.

• Often the context of the problem is different; it might be a different application, a different
platform, or a different programming language.

• Because of the different context, one usually ends up redesigning and reimplementing the
solution, thereby falling into the “reinventing the wheel” trap.

• The field of software patterns, including architectural and design patterns, is helping
developers avoid unnecessary redesign and reimplementation.

• A design pattern describes a recurring design problem to be solved, a solution to the

problem, and the context in which that solution works.

• The description specifies objects and classes that are customized to solve a general design
problem in a particular context.

• A design pattern is a larger-grained form of reuse than a class because it involves more than
one class and the interconnection among objects from different classes.

• A design pattern is sometimes referred to as a microarchitecture.

Main kinds of patterns

• Design patterns: A design pattern is a small group of collaborating objects

• Architectural patterns: Architectural patterns are larger-grained than design patterns,

addressing the structure of major subsystems of a system.

• Analysis patterns: similarities during analysis of different application domains. recurring

patterns found in object-oriented analysis such as static models, expressed in class diagrams.

• Product line–specific patterns: These are patterns used in specific application areas, such as
factory automation

• Idioms: Idioms are low-level patterns that are specific to a given programming language and
describe implementation solutions to a problem that use the features of the language

Software Architecture and Components

• A software separates the overall structure of the system, in terms of components and their
interconnections, from the internal details of the individual components.

• This section describes the design of component interfaces, an important issue in software
architecture.

• It describes how interfaces are specified before describing provided and required
interfaces, and connectors that interconnect components.

Components and Component Interfaces

 • The term component is used in different ways.

• It is often used in a general sense to mean modular systems,

• The modules could be developed in different ways depending on the particular platform
and the software architecture.

• A component is a self-contained, usually concurrent, object with a well-defined interface

that is capable of being used in applications different from that for which it was originally
designed.

• To fully specify a component, it is necessary to define it in terms of the operations it

provides and the operations it requires

Connectors
• In addition to defining the components, a software architecture must define the connectors
that join the components.

• A connector encapsulates the interconnection protocol between two or more components.

• Different kinds of message communication between components include asynchronous

(loosely coupled) and synchronous (tightly coupled).

• The interaction protocols for each of these types of communication can be encapsulated in
a connector.

Software Quality Attributes

• Maintainability.

The extent to which software is capable of being changed after deployment.

• Modifiability.

The extent to which software is capable of being modified during and after initial development.

• Testability.

The extent to which software is capable of being tested.

• Traceability.

The extent to which products of each phase can be traced back to products of previous phases.

• Scalability. The extent to which the system is capable growing after its initial deployment.

• Reusability. The extent to which software is capable of being reused.

• Performance. The extent to which the system meets its performance goals, such as
throughput and response times.

• Security. The extent to which the system is resistant to security threats.

• Availability. The extent to which the system is capable of addressing system failure.
What is User Interface Design (UID)?
• User interface design creates an effective communication medium between a human and a
computer.

• Following a set of interface design principles, design identifies interface objects and actions

• and then creates a screen layout that forms the basis for a user interface prototype.

• A software engineer designs the user interface by applying an iterative process that draws
on predefined design principles.

Importance:
• If software is difficult to use,

• if it forces you into mistakes,

• or if it frustrates your efforts to accomplish your goals,

• you won’t like it, regardless of the computational power it exhibits, the content it delivers,
or the functionality it offers.

• The interface has to be right because it molds a user’s perception of the software.

What are the steps?

• User interface design begins with the identification of user, task, and environmental
requirements.

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

• These form the basis for the creation of screen layout that depicts graphical design and
placement of icons, definition of descriptive screen text, specification and titling of windows,
and specification of major and minor menu items.

• Tools are used to prototype and ultimately implement the design model, and the result is
evaluated for quality.

Design principles for main 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 objects that appear on the screen
Design Principles to Reduce the 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

Design principles to make interface consistent

• Allow the user to put the current task into a meaningful context

• Maintain consistency across a complete product line

• If past interactive models have created user expectations, do not make changes unless there
is a compelling reason to do so

Interface Analysis and Design Models

• Four different models come into play when a user interface is to be analyzed and designed.

• A human engineer (or the software engineer) establishes a user model,

• the software engineer creates a design model,

• the end user develops a mental image that is often called the user’s mental model or the
system perception,

• and the implementers of the system create an implementation model

• Unfortunately, each of these models may differ significantly.

• Your role, as an interface designer, is to reconcile these differences and derive a consistent
representation of the interface

• 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”

• The user’s mental model (system perception) is the image of the system that end users
carry in their heads

• The implementation model combines the outward manifestation of the computer-based

system (the look and feel of the interface), coupled with all supporting information (books,
manuals, videotapes, help files) that describes interface syntax and semantics.

The Process - Continued

• The analysis and design process for user interfaces is iterative and can be represented using
a spiral model.
 • The user interface analysis and design process begins at the interior of the spiral and
encompasses four distinct framework activities:

 (1) interface analysis and modeling,

 (2) interface design,

 (3) interface construction, and

 (4) interface validation.

• Each of these tasks will occur more than once, with each pass around the spiral representing
additional elaboration of requirements and the resultant design.

• In most cases, the construction activity involves prototyping—the only practical way to
validate what has been designed.

Interface Analysis
• Interface analysis focuses on the profile of the users who will interact with the system.

• Skill level, business understanding, and general receptiveness to the new system are
recorded; and different user categories are defined.

• For each user category, requirements are elicited.

• In essence, you work to understand the system perception

• Once general requirements have been defined, a more detailed task analysis is conducted.

• Those tasks that the user performs to accomplish the goals of the system are identified,
described, and elaborated (over a number of iterative passes through the spiral)

• Finally, analysis of the user environment focuses on the characteristics of the physical work
environment (e.g., location, lighting, position constraints).

• The information gathered as part of the analysis action is used to create an analysis model
for the interface.

• Using this model as a basis, the design activity commences.

• Understand the problem before you attempt to design a solution.

• In the case of user interface design, understanding the problem means understanding

 (1) the people (end users) who will interact with the system through the interface,

 (2) the tasks that end users must perform to do their work,

 (3) the content that is presented as part of the interface, and

 (4) the environment in which these tasks will be conducted.

User Analysis
• Are users trained professionals, technicians, clerical, or manufacturing workers?

• What level of formal education does the average user have?

• Are the users capable of learning from written materials or have they expressed a desire for
classroom training?

• Are users expert typists or keyboard phobic?

• What is the age range of the user community?

• Will the users be represented predominately by one gender?

• How are users compensated for the work they perform?

• Do users work normal office hours or do they work until the job is done?

• Is the software to be an integral part of the work users do or will it be used only occasionally?

• What is the primary spoken language among users?

• What are the consequences if a user makes a mistake using the system?

• Are users experts in the subject matter that is addressed by the system?

• Do users want to know about the technology that sits behind the interface?

Task Analysis and Modelling

The goal of task analysis is to answer the following questions:

• What work will the user perform in specific circumstances?

• What tasks and subtasks will be performed as the user does the work?

• What specific problem domain objects will the user manipulate as work is performed?

• What is the sequence of work tasks—the workflow?

• What is the hierarchy of tasks?

Techniques for UI Analysis

• Use Cases: When used as part of task analysis, the use case is developed to show how an
end user performs some specific work-related task.

• Task Elaboration: functional decomposition or stepwise refinement) as a mechanism for

refining the processing tasks that are required for software to accomplish some desired
function.

• Object Elaboration: Objects can be categorized into classes. Attributes of each class are
defined, and an evaluation of the actions applied to each object provides a list of operations.

• Workflow Analysis: Allows you to understand how a work process is completed when
several people are involved.

• Hierarchical Representation: The hierarchy is derived by a stepwise elaboration of each task

identified for the user
Analysis of Display Content
• Are different types of data assigned to consistent geographic locations on the screen (e.g.,
photos always appear in the upper right-hand corner)?

• Can the user customize the screen location for content?

• Is proper on-screen identification assigned to all content?

• If a large report is to be presented, how should it be partitioned for ease of understanding?

• Will mechanisms be available for moving directly to summary information for large
collections of data?

• Will graphical output be scaled to fit within the bounds of the display device that is used?

• How will color be used to enhance understanding?

• How will error messages and warnings be presented to the user?

Analysis of the Work Environment

• People do not perform their work in isolation.

• They are influenced by the activity around them, the physical characteristics of the
workplace, the type of equipment they are using, and the work relationships they have with
other people.

• In some applications the user interface for a computer-based system is placed in a “user-
friendly location” (e.g., proper lighting, good display height, easy keyboard access),

• but in others (e.g., a factory floor or an airplane cockpit), lighting may be suboptimal, noise
may be a factor, a keyboard or mouse or touch screen may not be an option, display
placement may be less than ideal.

• In addition to physical environmental factors, the workplace culture also comes into play

Interface Design:
• Once interface analysis has been completed, all tasks (or objects and actions) required by
the end user have been identified in detail and the interface design activity commences.

• Interface design, like all software engineering design, is an iterative process.

• Each user interface design step occurs a number of times, elaborating and refining
information developed in the preceding step.

Interface Design Steps

Although many different user interface design models have been proposed, all suggest some
combination of the following steps:

1. Define interface objects and actions (operations),

2. Identify events (user actions) that will cause the state of the user interface to change,
 3. Depict the representation of each state, and

4. Indicate how the user interprets each state from information provided through the
interface.

Applying Interface Design Steps

1. The definition of interface objects and the actions that are applied to them is an important
step in interface design.

2. To accomplish this a use case is written.

3. Nouns (objects) and verbs (actions) are isolated to create a list of objects and actions.

4. Once the objects and actions have been defined and elaborated iteratively, they are
categorized by type.

5. Target, source, and application objects are identified.

6. A source object (e.g., a report icon) is dragged and dropped onto a target object (e.g., a
printer icon).

7. When you are satisfied that all important objects and actions have been defined (for one
design iteration), screen layout is performed.

Design Issues:
• Response Time

• Help Facilities

• Error Handling

• Menu and Command Labeling

• Application Accessibility

• Internationalization

Webapp and Mobile Interface Design

• Every user interface—whether it is designed for a WebApp, a mobile device, a traditional
software application, a consumer product, or an industrial device— should exhibit the
usability characteristics

• WebApp and mobile interfaces should answer three primary questions:

 Where am I?

 What can I do now?

 Where have I been and where can I go?

• Answers to these questions allow a user to understand context and navigate more
effectively through the app.

• The user interface of a Web or mobile app is its “first impression.”

 • Regardless of the value of its content, the sophistication of its processing capabilities and
services, and the overall benefit of the application itself, a poorly designed interface will
disappoint the potential user and may, in fact, cause the user to go elsewhere.

• Because of the sheer volume of competing Web-Apps and mobile apps in virtually every
subject area, the interface must “grab” a potential user immediately.

Web/Mobile Interface Design Principles and Guidelines

• 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 (e.g., colour,
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, not the efficiency of the developer who designs and builds it or the client-server
environment that executes it.

• 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, the application should use multitasking in a way that lets the user proceed with
work.

• 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 logoff and return later to pick up where she left off.

• Visible Navigation. A well-designed interface provides “the illusion that users are in the
same place, with the work brought to them
A few pragmatic “don’ts” for interface design
• Don’t force the user to read voluminous amounts of text, particularly when the text
explains the operation of the WebApp or assists in navigation.

• Don’t make users scroll unless it is absolutely unavoidable.

• Don’t rely on browser functions to assist in navigation.

• Don’t allow aesthetics to supersede functionality.

• Don’t force the user to search the display to determine how to link to other content or
services.

Interface Design Workflow for Web and Mobile Apps

 Review information contained in the requirements model and refine as required.

 Develop a rough sketch of the WebApp interface layout

 Map user objectives into specific interface actions

 Define a set of user tasks that are associated with each action

 Storyboard screen images for each interface action

 Refine interface layout and storyboards using input from aesthetic design

 Identify user interface objects that are required to implement the interface

 Develop a procedural representation of the user’s interaction with the Interface

 Develop a behavioural representation of the interface

 Describe the interface layout for each state

 Refine and review the interface design model

Design Evaluation
• Once you create an operational user interface prototype, it must be evaluated to determine
whether it meets the needs of the user.

• Evaluation can span a formality spectrum.

• It ranges from an informal “test drive,” in which a user provides impromptu feedback to a
formally designed study that uses statistical methods for the evaluation of questionnaires
completed by a population of end users.

• After the design model has been completed, a first-level prototype is created.

• The prototype is evaluated by the user, who provides you with direct comments about the
efficacy of the interface.

• In addition, if formal evaluation techniques are used (e.g., questionnaires, rating sheets),
you can extract information from these data.

• Design modifications are made based on user input, and the next level prototype is created.
 • The evaluation cycle continues until no further modifications to the interface design are
necessary.

• The prototyping approach is effective, but is it possible to evaluate the quality of a user
interface before a prototype is built?

• If you identify and correct potential problems early, the number of loops through the
evaluation cycle will be reduced and development time will shorten.

• If a design model of the interface has been created, a number of evaluation criteria can be
applied during early design reviews

Evaluation Criteria for Design

1. The length and complexity of the requirements model or written specification of the system
and its interface provide an indication of the amount of learning required by users of the
system.

2. The number of user tasks specified and the average number of actions per task provide an
indication of interaction time and the overall efficiency of the system.

3. The number of actions, tasks, and system states indicated by the design model imply the
memory load on users of the system.

4. Interface style, help facilities, and error handling protocol provide a general indication of
the complexity of the interface and the degree to which it will be accepted by the user.

5. Once the first prototype is built, you can collect a variety of qualitative and quantitative
data that will assist in evaluating the interface.

6. To collect qualitative data, questionnaires that allow users to assess the interface prototype
can be distributed.

7. If quantitative data are desired, a form of time-study analysis can be conducted.

8. Users are observed during interaction, and data—such as number of tasks correctly
completed over a standard time period, frequency of actions, sequence of actions, time
spent “looking” at the display, number and types of errors, error recovery time, time spent
using help, and number of help references per standard time period—are collected and used
as a guide for interface modification.

Pattern Based Designs

• In software engineering, a design pattern is a general repeatable solution to a commonly
occurring problem in software design.

• A design pattern isn't a finished design that can be transformed directly into code.

• It is a description or template for how to solve a problem that can be used in many
different situations.

• Pattern-based design creates a new application by finding a set of proven solutions to a

clearly delineated set of problems.
 • Each problem and its solution is described by a design pattern that has been catalogued
and vetted by other software engineers who have encountered the problem and
implemented the solution while designing other applications.

• Each design pattern provides you with a proven approach to one part of the problem to be
solved.

Importance:
• Have you ever heard the phrase “reinventing the wheel”?

• It happens all the time in software development, and it’s a waste of time and energy.

• By using existing design patterns, you can acquire a proven solution for a specific problem.

• As each pattern is applied, solutions are integrated and the application to be built moves
closer to a complete design.

Design Patterns:
• A design pattern can be characterized as “a three-part rule which expresses a relation
between a certain context, a problem, and a solution”.

• For software design, context allows the reader to understand the environment in which the
problem resides and what solution might be appropriate within that environment.

• A set of requirements, including limitations and constraints, acts as a system of forces that
influences how the problem can be interpreted within its context and how the solution can
be effectively applied.

Characteristics of an effective design pattern

• It solves a problem : Patterns capture solutions, not just abstract principles or strategies.

• It is a proven concept : Patterns capture solutions with a track record, not theories or
speculation.

• The solution isn’t obvious : Many problem-solving techniques (such as software design
paradigms or methods) try to derive solutions from first principles.

• The best patterns generate a solution to a problem indirectly—a necessary approach for
the most difficult problems of design.

• It describes a relationship : Patterns don’t just describe modules but describe deeper system
structures and mechanisms.

• The pattern has a significant human component (minimize human intervention).

• All software serves human comfort or quality of life; the best patterns explicitly appeal to
aesthetics and utility.

Uses of Design Patterns

• Design patterns can speed up the development process by providing tested, proven
development paradigms.
 • Effective software design requires considering issues that may not become visible until later
in the implementation.

• Reusing design patterns helps to prevent subtle issues that can cause major problems and
improves code readability for coders and architects familiar with the patterns.

• Often, people only understand how to apply certain software design techniques to certain
problems.

• These techniques are difficult to apply to a broader range of problems.

• Design patterns provide general solutions, documented in a format that doesn't require
specifics tied to a particular problem.

• In addition, patterns allow developers to communicate using well-known, well understood

names for software interactions.

• Common design patterns can be improved over time, making them more robust than ad-
hoc designs.

Fundamental types of design patterns

• Architectural patterns describe broad-based design problems that are solved using a
structural approach.

• Data patterns describe recurring data-oriented problems and the data modelling solutions
that can be used to solve them.

• Component 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.

• 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 Web-Apps and
often incorporates many of the other patterns categories just mentioned.

• Mobile patterns describe commonly encountered problems when developing solutions for
mobile platforms.

Object Oriented Design Patterns

• Creational patterns focus on the “creation, composition, and representation” of objects
and provide mechanisms that make the instantiation of objects easier within a system and
enforce “constraints on the type and number of objects that can be created within a system”

• Structural patterns focus on problems and solutions associated with how classes and
objects are organized and integrated to build a larger structure.

• Behavioural patterns address problems associated with the assignment of responsibility

between objects and the manner in which communication is affected between objects.
Frameworks:
• A framework is not an architectural pattern, but rather a skeleton.

• 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.

• That is, you can select a “ reusable mini-architecture that provides the generic structure and
behaviour for a family of software abstractions, along with a context . . .

• which specifies their collaboration and use within a given domain”

Differences between design patterns and frameworks

• Design patterns are more abstract than frameworks

• Design patterns are smaller architectural elements than frameworks

• Design patterns are less specialized than frameworks

• Frameworks are applied with no changes

• Framework is a reusable mini-architecture is applicable to all software to be developed

within a limited domain of application.

Describing a Pattern
• How do you find patterns that fit your needs?

• Pattern-based design begins with the recognition of patterns within the application you
intend to build,

• continues with a search to determine whether others have addressed the pattern,

• and concludes with the application of an appropriate pattern to the problem at hand.

• The second of these three tasks is often the most difficult.

Design Pattern Template

• 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 the 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

• 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

Approach to design patterns

1. Be sure you understand the big picture—the context in which the software to be built
resides.

2. The requirements model should communicate this to you.

3. Examining the big picture, extract the patterns that are present at that level of abstraction.

4. Begin your design with “big picture” patterns that establish a context or skeleton for further
design work.

5. “Work inward from the context” looking for patterns at lower levels of abstraction that
contribute to the design solution.

6. Repeat steps 1 to 4 until the complete design is fleshed out.

7. Refine the design by adapting each pattern to the specifics of the software you’re trying to
build.

Design Tasks
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 appropriate patterns to address them.

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

6. If user interface design problems have been isolated (this is almost always the case), search
the many 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.
Common Design Mistakes
• A number of common mistakes occur when pattern-based design is used.

• In some cases, not enough time has been spent to understand the underlying problem and
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.

Architectural patterns
• An Architectural Pattern expresses a fundamental structural organization schema for
software systems.

• It provides a set of predefined subsystems, their responsibilities, and includes rules and
guidelines for organizing the relationships between them.

• An architectural pattern is a general, reusable solution to a commonly occurring problem in

software architecture within a given context.

• The architectural patterns address various issues in software engineering, such as computer
hardware performance limitations, high availability and minimization of a business risk.

Software Architecture
The software architecture separates the overall structure of the system, in terms of subsystems and
their interfaces, from the internal details of the individual subsystems.

A software architecture is structured into subsystems, in which each subsystem should be relatively
independent of other subsystems.

Software architecture is also referred to as a high- level design.

“The software architecture of a program or computing system is the structure or structures of the
system, which comprise software elements, the externally visible properties of those elements, and
the relationships among them.”

Component-Based Software Architecture

• A component-based software architecture consists of multiple components in which each
component is self-contained and encapsulates certain information.

• A component is either a composite object composed of other objects or a simple object.

• A component provides an interface through which it communicates with other

components.
Component-Based Software Architecture
All information that is needed by one component to communicate with another component is
contained in the interface, which is separate from the implementation.

Thus, a component can be considered a black box, because its implementation is hidden from other
components.

Components communicate with each other in different ways using predefined communication
patterns.

Multiple views of a software architecture

The design of the software architecture can be depicted from different perspectives, referred to as
different views.

The structural view of the software architecture is depicted on class diagrams.

The dynamic view of the software architecture is depicted on communication diagrams.

The deployment view of the software architecture is depicted on deployment diagrams.

Another architectural view is the component-based software architecture view.

Structural View of a Software Architecture

• The structural view of a software architecture is a static view, which does not change with
time.

• At the highest level, subsystems are depicted on a class diagram.

• In particular, a subsystem class diagram depicts the static structural relationship between
the subsystems.

• Are represented as composite or aggregate classes, and multiplicity of associations among

them.

• As an example of the structural view of a software architecture, consider the design of a

client/server software architecture,

• In which there are multiple clients and a single service.

• An example of such an architecture is the Banking System,

• In which there are multiple instances of the ATM Client subsystem and a single instance of
the Banking Service subsystem.

Dynamic View of a Software Architecture

The dynamic view of a software architecture is a behavioural view, which is depicted on a
communication diagram.

A subsystem communication diagram shows the subsystems (depicted as aggregate or composite

objects) and the message communication between them.
As the subsystems can be deployed to different nodes, they are depicted as concurrent components,
because they execute in parallel and communicate with each other over a network.

Deployment View of a Software Architecture

The deployment view of the software architecture depicts the physical configuration of the software
architecture,

And in particular how the subsystems of the architecture are allocated to physical nodes in a
distributed configuration.

A deployment diagram can depict a specific deployment with a fixed number of nodes.

Alternatively, it can depict the overall structure of the deployment – for example, identifying that a
subsystem can have many instances, each deployable to a separate node, but not depicting the
specific number of instances.

Software architectural patterns

Software architectural patterns provide the skeleton or template for the overall software
architecture or high-level design of an application.

Software architectural patterns can be grouped into two main categories:

architectural structure patterns, which address the static structure of the architecture,

and architectural communication patterns, which address the dynamic communication among
distributed components of the architecture.

This chapter introduces the concept of software architectural patterns and describes one
architectural structure pattern, the Layers of Abstraction pattern

Layers of Abstraction Architectural Pattern

The Layers of Abstraction pattern (also known as the Hierarchical Layers or Levels of Abstraction
pattern) is a common architectural pattern that is applied in many different software domains.

Operating systems, database management systems, and network communication software are
examples of software systems that are often structured as hierarchies.

Call/Return Pattern
The simplest form of communication between objects uses the Call/Return pattern.

A sequential design consists of passive classes, which are instantiated as passive objects.

The only possible form of communication between objects in a sequential design is operation (also
known as method) invocation, which is also referred to as the Call/Return pattern.

In this pattern, a calling operation in the calling object invokes a called operation in the called object

Documenting software architectural patterns

A typical template looks like this:
■ Pattern name

■ Aliases. Other names by which this pattern is known.

■ Context. The situation that gives rise to this problem.

■ Problem. Brief description of the problem.

■ Summary of solution. Brief description of the solution.

■ Strengths of solution

■ Weaknesses of solution

■ Applicability. When you can use the pattern.

■ Related patterns

■ Reference. Where you can find more information about the pattern.

Types of software architectures

Object-oriented software architecture: describes object-oriented design using the concepts of
information hiding, classes, and inheritance

Client/server software architecture: describes the design of client/server software architectures. A

typical design consists of one service and multiple clients.

Service-oriented architecture: typically consist of multiple distributed autonomous services that can
be composed into distributed software applications

Distributed component-based software architecture: describes the component structuring criteria

for designing components that can be deployed to execute on distributed platforms in a distributed
configuration

Concurrent and real-time software architecture: describes the design of real-time software
architectures, which are concurrent architectures usually having to deal with multiple streams of
input events

Software product line architecture: are architectures for families of products that need to capture
both the commonality and variability in the family

Software Subsystem Architectural Design

During analysis modelling, the problem is analysed by breaking it down and studying it on a use
case–by–use case basis.

During design modelling, the solution is synthesized by designing a software architecture that
defines the structural and behavioural properties of the software system.

To successfully manage the inherent complexity of a large-scale software system, it is necessary to

provide an approach for decomposing the system into subsystems and developing the overall
software architecture of the system.

After performing this decomposition, each subsystem can then be designed independently
Designing software architecture
Several decisions need to be made in designing the software architecture:

Integrate the use case–based interaction models into an initial software architecture.

Determine the subsystems using separation of concerns and subsystem structuring criteria.

Determine the precise type of message communication among the subsystems.

Issues In Software Architectural Design

In the analysis of the problem domain and structuring a system into subsystems, the emphasis is on
functional decomposition, such that each subsystem addresses a distinctly separate part of the
system.

The design goal is for each subsystem to perform a major function that is relatively independent of
the functionality provided by other subsystems.

A subsystem can be structured further into smaller subsystems, consisting of a subset of the
functionality provided by the parent subsystem.

After the interface between subsystems has been defined, subsystem design can proceed
independently.

A subsystem provides a larger-grained information hiding solution than an object.

To structure the system into subsystems, start with the use cases.

Objects that realize the same use case have higher coupling because they communicate with each
other and have lower (or no) coupling with objects in other use cases.

Whereas an object can participate in more than one use case, it can only be part of one subsystem;

thus, an object that participates in more than one use case needs to be allocated to a single
subsystem, usually the subsystem with which it is most highly coupled.

Integrated Communication Diagrams

To transition from analysis to design and to determine the subsystems, it is necessary to synthesize
an initial software design from the analysis carried out so far.

This is done by integrating the use case–based interaction diagrams developed as part of the
dynamic model.

Although dynamic interaction between objects can be depicted on either sequence diagrams or
communication diagrams,

this integration uses communication diagrams because they visually depict the interconnection
between objects, as well as the messages passed between them.

In the analysis model, at least one communication diagram is developed for each use case.

The integrated communication diagram is a synthesis of all the communication diagrams developed
to support the use cases.
The integrated communication diagram is, in effect, a merger of the communication diagrams

Separation of concerns in subsystem design

Composite Object
Objects that are part of the same composite object should be in the same subsystem and separate
from objects that are not part of the same composite object.

Clients and Services

Clients and services should be in separate subsystems.

This guideline can be viewed as a special case of the geographical location rule because clients and
services are usually at different locations.

User Interaction
Users often use their own PCs as part of a larger distributed configuration, so the most flexible
option is to keep user interaction objects in separate subsystems.

Because user interaction objects are usually clients, this guideline can be viewed as a special case of
the client/service guideline.

Interface to External Objects

A subsystem deals with a subset of the actors shown in the use case model and a subset of the
external real-world objects shown on the context diagram.

An external real-world object should interface to only one subsystem

Scope of Control
A control object and all the entity and I/O objects it directly controls should all be part of one
subsystem and not split among subsystems.

An example is the ATM

Subsystem structuring criteria

A subsystem can satisfy more than one of the structuring criteria.

Subsystems are generally depicted with the stereotype «subsystem».

For certain software architectures consisting of distributed component-based subsystems, the

stereotype «component» is used for such a subsystem,

and in service-oriented architecture consisting of service subsystems, the stereotype «service» is

used for a service subsystem.

Subsystem types
Client Subsystem
A client subsystem is a requester of one or more services.

There are many different types of clients; some may be wholly dependent on a given service, and
some may be only partially dependent.
User Interaction Subsystem
A user interaction subsystem provides the user interface and performs the role of a client in a
client/server system, providing user access to services.

There may be more than one user interaction subsystem – one for each type of user

Service Subsystem
A service subsystem provides a service for client subsystems.

It responds to requests from client subsystems, although it does not initiate any requests.

A service subsystem is any subsystem that provides a service, servicing client requests.

Control Subsystem
A control subsystem controls a given part of the system.

The subsystem receives its inputs from the external environment and generates outputs to the
external environment, usually without any human intervention.

Coordinator Subsystem
Coordinator subsystems coordinate the execution of other subsystems, such as control subsystems
or service subsystems.

In software architectures with multiple control subsystems, it is sometimes necessary to have a

coordinator subsystem that coordinates the control subsystems

Input/Output Subsystem
An input, output, or input/output subsystem is a subsystem that performs input and/or output
operations on behalf of other subsystems.

It can be designed to be relatively autonomous.