This document summarizes a lecture on software architecture and component-based software architecture. It discusses: 1) Software architecture, components, interfaces, and multiple views of software architecture including structural, dynamic, deployment, and component views. 2) Software architectural patterns including layers of abstraction, centralized/distributed control, and asynchronous/synchronous message communication patterns. 3) Documenting architectural patterns with context, problem, and solution templates. 4) Interface design with provided and required interfaces. 5) Designing software architectures including object-oriented, client-server, service-oriented, and distributed component-based architectures.

1. 1/6/2024 1
Adama Science and Technology University
School of Electrical Engineering and Computing
Department of Computer Science and Engineering
Summery on Software Architecture
(Reading Assignment)
Lecture -7
Dr. Teklu Urgessa (PhD)
Lecture By

2. 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
1/6/2024 2

3. 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.
1/6/2024 3

4. 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.
1/6/2024 4

5. 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.
1/6/2024 5

6. 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
1/6/2024 6

7. 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 )
1/6/2024 7

8. 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
1/6/2024 8

9. 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
1/6/2024 9

10. 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
1/6/2024 10

11. 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.
1/6/2024 11

12. Software Architecture Pattern
 Call / Return Pattern
1/6/2024 12

13. 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.
1/6/2024 13

14. Software Architecture Pattern
 Asynchronous Message Communication Pattern
1/6/2024 14

15. 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.
1/6/2024 15

16. Software Architecture Pattern
 Synchronous Message Communication with Reply Pattern
1/6/2024 16

17. 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.
1/6/2024 17

18. 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.
1/6/2024 18

19. Documenting Software Architectural Pattern
1/6/2024 19

20. 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.
1/6/2024 20

21. 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.
1/6/2024 21

22. Interface Design
1/6/2024 22

23. 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.
1/6/2024 23

24. 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?
1/6/2024 24

25. II. Software Subsystem Architecture
Design
1/6/2024 25

26. 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.
1/6/2024 26

27. 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.
1/6/2024 27

28. 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
1/6/2024 28

29. 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.
1/6/2024 29

30. 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.
1/6/2024 30

31. 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).
1/6/2024 31

32. 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.
1/6/2024 32

33. Integrated Communication Diagrams
1/6/2024 33

34. Integrated Communication Diagrams
1/6/2024 34

35. 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.
1/6/2024 35

36. 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.
1/6/2024 36

37. 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.
1/6/2024 37

38. 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.
1/6/2024 38

39. 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.
1/6/2024 39

40. 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)
1/6/2024 40

41. 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.
1/6/2024 41

42. Decisions about message communication between subsystems
1/6/2024 42

43. Decisions about message communication between subsystems
1/6/2024 43

44. 1/6/2024 44
The End----

45. Thank You !!!
It was nice to have you as my
Students
1/6/2024 45