Summery on Software Architecture

(Reading Assignment)
Lecture -7

Lecture By

Dr. Teklu Urgessa (PhD)

Adama Science and Technology University

School of Electrical Engineering and Computing
01/18/24 Department of Computer Science and Engineering 1
 Outline

 Software architecture and component-based Software

architecture
 Describes multiple views of a Software architecture
 Introduces the concept of Software architectural patterns
 How to document patterns
 Describes Software components and interfaces
 An overview of designing software architectures

01/18/24 2
 Software Architecture and Component Based
Software Architecture (Cont..)
 Software architecture is structured into subsystems, in which
each subsystem should be relatively independent of other.
 It is necessary to study the software architecture from:
 Static and Dynamic
 Functional and Nonfunctional

 A structural perspective on SW architecture is given by the

widely held concept of component-based SW architecture.
 A component is either a composite object composed of other
objects or a simple object.

01/18/24 3
 Software Architecture and Component Based
Software Architecture (Cont..)

A component provides an interface through which it

communicates with other components.
All information that is needed by one component to
communicate with another component is contained in the
interface, which is separate from the implementation.

A sequential design is a program in which the components

are classes and component instances are objects; the
components are passive classes without a thread of control.
In a sequential design, the only communication pattern is
call/return.

01/18/24 4
 SW Architecture and Component Based SW
Architecture (Cont..)

 In a concurrent or distributed design, the components are

active (concurrent) and capable of being deployed to
different nodes in a distributed environment.

 In concurrent design component can be communicated with

each other using several different types of communication
pattern such as: synchronous, asynchronous, brokered, or
group communication.

01/18/24 5
Multiple Views of a SW Architecture
 In UML 2, a modeling element can be described with more
than one stereotype.
 Analysis modeling: role characteristic of modeling element.
(boundary, entity)
 Design modeling: architectural characteristics. (subsystem,
component, service or concurrent task)
 SW architecture design can be depicted from different
perspective
 Structural view: class diagram
 Dynamic view: communication diagram
 Deployment view: deployment diagram
 Component view : component diagram

01/18/24 6
 Software Architecture Patterns
 SW architectural patterns provide the skeleton or template
for the overall software architecture or high-level design of
an application. (architecture style or pattern)
 Software architectural pattern can be grouped into two:
 Architectural structure pattern: provide the skeleton or
template (layer of abstraction)
 Architectural communication pattern: dynamic
communication (call/return, Asynchronous Message
Communication patterns, and the Synchronous Message
Communication with Replay pattern )

01/18/24 7
 Layers of Abstraction Architectural Pattern
Layers of Abstraction is a common architectural pattern.
A strict hierarchy, each layer uses services in the layers
immediately below it.
In flexible hierarchy, it can invoke services at more than one
layer below.
Software architectural structural pattern:
Centralized Control Pattern
Distributed Control Pattern
Hierarchical Control Pattern
Layers of Abstraction Pattern

01/18/24 8
 Software Architecture Pattern

Software architectural structural pattern:

Multiple Client / Multiple Service Pattern
Multiple Client / Single Service Pattern
Multi-tier Client/ Service Pattern
Software architectural communication pattern
Asynchronous Message Communication Pattern
Asynchronous Message Communication with Callback Pattern
Bidirectional Asynchronous Message Communication
Broadcast Pattern

01/18/24 9
 Software Architecture Pattern
 Software architectural communication pattern
 Broker Forwarding Pattern
 Broker Handle Pattern
 Call/ Return
 Negotiation Pattern
 Service Discovery Pattern
 Service Registration
 Subscription/ Notification Pattern
 Synchronous Message Communication with Replay Pattern
 Synchronous Message Communication without Relay Pattern

01/18/24 10
 Software Architecture Pattern
 Call / Return Pattern
 The simplest form of communication b/n objects.
 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.

01/18/24 11
 Software Architecture Pattern
 Call / Return Pattern

01/18/24 12
 Software Architecture Pattern
 Asynchronous Message Communication Pattern
 In concurrent and distributed designs, other forms of communication
are possible.
 The Asynchronous (Loosely Coupled) Message Communication
pattern, the producer component sends a message to the consumer
component and does not wait for a reply.
 Asynchronous Message Communication pattern is used wherever
possible for greater flexibility.
 It is also possible to have peer-to-peer communication between two
components, which send asynchronous messages to each other. This
kind of communication is referred to as bidirectional asynchronous
communication.

01/18/24 13
 Software Architecture Pattern

 Asynchronous Message Communication Pattern

01/18/24 14
 Software Architecture Pattern

 Synchronous Message Communication with Reply Pattern

 The client component sends a message to the service component and then
waits for a reply from the service.
 When the message arrives, the service accepts it, processes it, generates a
reply, and then sends the reply. The client and service then both continue.
 The service is suspended if no message is available.
 There might be one client and one service, it is more likely that synchronous
involves multiple clients and one service.
 This pattern is fundamental to client/server architectures.

01/18/24 15
 Software Architecture Pattern

 Synchronous Message Communication with Reply Pattern

01/18/24 16
Documenting Software Architectural Pattern

 For the sake of easy referencing, comparison with other

patterns and reuse patterns need documenting.
 Three important aspects of a pattern that need to be
captured are:
 Context: the situation that gives rise to a problem.
 Problem: a recurring problem that arise in this context.
 Solution: a proven resolution to the problem.

 A template for describing a pattern usually also addresses

its strength, weakness, and related patterns.
01/18/24 17
Documenting Software Architectural Pattern

 A typical template looks like this:

 Pattern name:
 Aliases: Other name 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.

01/18/24 18
Documenting Software Architectural Pattern

01/18/24 19
 Interface Design
 An important goal of both object-oriented design and
component-based software architecture is the separation of
the interface from the implementation.
 An interface specifies the externally visible operations of a
class, service, or component without revealing the internal
structure (implementation) of the operations.

 An interface can be depicted with a different name from the

class or component that realizes the interface.

01/18/24 20
 Interface Design

 By convention, the name starts with the letter “I.”

 An interface can be depicted in two ways: simple and
expanded.
 Simple case: the interface is depicted as a little circle with the
interface name next to it. The class or component that
provides the interface is connected to the small circle.
(provided / required)
 Expanded case: the interface is depicted in a rectangular box
with the static modeling notation, with the stereotype
«interface» and the interface name in the first compartment.

01/18/24 21
 Interface Design

01/18/24 22
 Design of SW Architecture

 Object oriented Software Architectures:

 Using the concepts of information hiding, classes, and
inheritance.
 Client/ Server Architecture
 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.

01/18/24 23
 Design of Software Architecture
 Distributed Component –based Software Architecture
 It describes the component structuring criteria for designing
components that can be deployed to execute on distributed
platforms in a distributed configuration.
 Concurrent and Real Software Architecture
 Which are concurrent architectures usually having to deal
with multiple streams of input events? state-dependent
 Software Product Line Architecture
 Which are architectures for families of products that need to
capture both the commonality and variability in the family?

01/18/24 24
 II. Software Subsystem Architecture
Design

01/18/24 25
 Outline

 Describes issues in software architectural design.

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

01/18/24 26
Issues in Software Architecture Design
 During analysis modeling, the problem is analyzed by
breaking it down and studying it on a use case–by–use case
basis.
 During design modeling, the solution is synthesized by
designing a software architecture that defines the structural
and behavioral properties of the software system.

 In the analysis of the problem domain and structuring a

system into subsystem, the emphasis is on functional
decomposition.

01/18/24 27
 Issue in Software Architecture Design

 The design goal is a major function that is relatively

independent of the other subsystems functionality.
 Some subsystems can be determined relatively easily
because of geographical distribution or server
responsibility. E.g. client and server

01/18/24 28
 Issue in Software Architecture Design
 In other applications, it is not so obvious how to structure
the system into subsystem.
 One of the goals of subsystem structuring is to have objects
that are functionally related and highly coupled in the same
subsystem, a good place to start is with the use cases.
 Objects that participate in the same use case are candidates
to be grouped into the same subsystem.
 Because of this, subsystem structuring is often done after
the interaction among the constituent objects of each use
case has been determined during dynamic modeling.

01/18/24 29
 Issue in Software Architecture Design

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

01/18/24 30
 Issue in Software Architecture Design

 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.
 However, there are also situations in which objects that
participate in the same use case need to be assigned to
different subsystems (e.g., because they are located in
separate geographical locations).

01/18/24 31
 Integrated Communication Diagrams
 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 to support the use cases.
 On way to reduce the clutter of the integrated
communication diagram is to aggregate the messages.
 The aggregate message does not represent an actual
message sent from one object to another rather it represents
messages sent at different times between the same pair of
objects.

01/18/24 32
 Integrated Communication Diagrams

01/18/24 33
 Integrated Communication Diagrams

01/18/24 34
 Separation of Concerns in Subsystem Design
 Some important structuring decision need to be made
when designing subsystem.
 The goal is to make subsystem more self-contained, so that
different concerns are addressed by different subsystems.
 Composite Objects
 Objects that are parts of the same composite object should be
in the same subsystem.(they are created, live and die
together)
 Geographical Location
 If two objects separated in different geographical locations,
they should be in different subsystem.

01/18/24 35
 Separation of Concerns in Subsystem Design

Clients and Services

Clients and services should be in separate subsystem.
User Interaction
The most flexible option is to keep user interaction objects in
separate subsystems.
Interface to External Objects
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.

01/18/24 36
 Subsystem Structuring Criteria
 A subsystem can satisfy more than one of the structuring
criteria. (design considerations)
 Client Subsystem
 It include: user interaction, control and I/O subsystems.
 User Interaction Subsystem
 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 subsystem.
 It include entity, coordinator and business logic objects.

01/18/24 37
 Subsystem Structuring Criteria
 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.
 A control subsystem is often state dependent, in which case
it includes at least one state-dependent control object.

01/18/24 38
 Subsystem Structuring Criteria
 Coordinator Subsystem
 Coordinator subsystems coordinate the execution of other
subsystems, such as control 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.

01/18/24 39
 Decisions about message communication between subsystems

 In the transition from the analysis model to the design

model, one of the most important decisions relates to what
type of message communication is needed between the
subsystems.
 A second related decision is to determine more precisely
the name and parameters of each message (i.e. the interface
specification)

01/18/24 40
Decisions about message communication between subsystems

 In design modeling, after the subsystem structure is

determined, a decision has to be made about the precise
semantic of message communication, such as whether
message communication will be synchronous or
asynchronous.
 Message communication between two subsystems can be
unidirectional or bidirectional.

01/18/24 41
Decisions about message communication between subsystems

01/18/24 42
Decisions about message communication between subsystems

01/18/24 43
 The End----

01/18/24 44
 Thank You !!!

It was nice to have you as my Students

01/18/24 45