Designing Software Architecture
• All human can design !
– Do you believe in this? (matter of degree?)
• Design, as a set of activities, may be
analyzed !
– Do you believe in this? (partially or totally?)
We are even trying to “teach” this subject here!
Architecture Design Stages
The Design Process may be summed into 4 “stages”:
1. feasibility : identifying potential design concepts
2. preliminary design: selecting and developing the “best”
design concept
3. detail design: further defining and refining the
design concept
4. planning: evaluating and altering (or tuning) the design
concept to fit the requirements of software
development, production, consumption,
and retirement
Just like everything we do, this is not clear-cut and all sequential.
Some Concerns over the Design “Process”
• Start-up problem: Identifying potential design concepts (the
first step is very important & may be the key stumbling block).
• People problem: For a very large software system, there
may be a need for more than one architect or chief designer ---increasing the chance of not agreeing on any design concept.
• Complexity problem: for a system that is composed of
many heterogeneous components or parts, the complexity of
finding an overall system becomes very large and sometimes
prohibitive.
In the case of internet architecture (e.g. SOA), it becomes extremely difficult
Design Activities are Not Straightforward
Increases in difficulty
•
One may wonder around a while in the beginning to get started:
1.
2.
3.
4.
•
Looking and understanding at key requirements
mapping functional requirements to major components
relating the components to produce the overall system
Analyze the relationships in terms of non-functional required
properties (e.g. performance, security, reliability, etc.)
As we proceed, we will revisit, refine, and modify the original
ideas. Design activities are not always performed sequentially:
–
–
–
–
In cyclical mode
In parallel mode
In incremental mode
In adaptive mode
Any Help?
• Some “Basic” Design Approach/Tool:
– Abstraction
– Separation of Concern
– Decomposition/Composition (my words)
• These concepts are not totally separate
ABSTRACTION
• Abstraction may be defined in many ways:
– “The selection of a set of basic concepts to
represent a more complex whole” --- from your text
– The simplification and ignoring of the details to
emphasize what is considered as important.
“SHAPES”
– The generalization from the details and the specifics
Do you remember how many dogs and cats
you saw as a child before you realized the
“class”-dog and the “class”-cats ?! ---- follow
the 1-2 year olds sometime and see how they
cope with the problem of “classification”.
A
B
S
T
R
A
C
T
I
O
N
More on Abstraction
• We often start by “matching” a problem
component to some abstract model/solution:
– Major requirement (problem domain)
– Major solution (modeling “abstraction” or “machine”)
Application Problem domain
Simple Abstract “machine”
word processing
document & layout
process control
finite state machine
financial & accounting
spreadsheet & database
scientific computing
web pages
matrices and algorithms
HTML based document
etc.
etc.
Levels of Abstraction
Decomposition & Composition
SHAPES
Red arrow = decomposition
Blue arrow = composition
“2-D” shapes
Ovals
Triangles
Arrows
Approaches to Levels of Abstraction
• Work at a level below the “whole” component or
application.
• we are looking at solutions to sub-components and
then compose & generalize the solutions to apply to
the whole
• work at a level above the “whole” or desired
application
• we are looking at a more general solution and
applying only the specific parts of the general
solution to the problem at hand and fine tune to
specialize the solution .
Try during the class
• How would you approach “abstracting” the
description & design of a system for the following?
–
–
–
–
–
–
–
On-line classes
In-class lectures
Part-time students
Adult-students
Full-time students
Full time lecturers
Part-time lecturers
Separation of Concern
• Separation of Concern is the subdivision or
decomposing of a problem into “independent”
parts.
– Functional components and sub-components
– Connectors that “interconnect” components
• Most of the time total independence is not
possible, but we want:
– Each individual component to have strong cohesion
– The components to have loose coupling
Recall that cohesion and coupling are important software properties.
Any Other Help in Designing
Architecture?
• Just as in other fields, past experiences
provide fertile ground for potential solutions:
– to satisfy a specific goal
– within some particular application context
(context Ξ constraints?)
• In software architecture we may also use
these past experiences, expressed in the
form of architectural “styles” and “patterns”
A Broad View of Styles & Patterns
deep
some combine
these into “styles”
Architectural
patterns
Domain Specific
Software Architecture
Design
Styles
App Domain
Knowledge
Design
patterns
we focus on these 3
mostly for OO detail design & programming
shallow
programming
level
software design
component
level
Scope Applicability
Software System
level
Domain Specific Software Architecture (DSSA)
•
Domain Specific Software Architecture contains a
substantial amount of information based on past
experiences within the specific application
domain:
1.
2.
3.
a reference architecture for a specific domain,
a library of software components containing reusable
chunks of domain expertise, and
a method of choosing and configuring components to
work within an instance of the reference architecture.
(1) reference architecture
for domain x
(2) domain components
Domain
core
(3) “Core must be a part of
every instance and -------”
Architectural Patterns
• Architectural Pattern: a named collection of
architectural design decisions that are applicable to
a recurring design problem, parameterized to
account for different software development contexts
in which the problem occurs.
• Fundamental sets of architectural patterns:
– State-Logic-Display (3-tier architecture)
– Model-View-Controller (web application)
– Sense-Compute-Control (sensor-control-actuator / real time)
State-Logic-Display (3-tier)
• State-Logic-Display is the familiar architecture
pattern where
– users access business functionalities through a user
“display.”
– the business functionalities are provided through the
“logic” part,
– and the data store keeps all the persistent data or “states,”
usually in a database
• In some ways this is the precursor of the now
popular M-V-C architecture discussed next.
request
User
Interface
(Display)
response
Business
Logic
(Logic)
request
response
Database
(State)
the software components may be distributed across hardware
Model-View-Controller (MVC)
• Model-View-Controller is an architectural pattern
which resembles the 3 tier, but focuses more on the
“management of User Interaction.” It contains:
– Model which manage the storage of the data
– View which accepts and displays information to the user
– Controller which aid in the control and modification of the
way information is managed between the view and the
model. (Sometimes, especially in web applications, the
business logic is placed in Controller)
View
Model
Controller
Today’s Popular Model with JSP
for dynamic presentation content
1
Browser
JSP
4
2
Java
Bean
3
Data Base/
enterprise
system
(Simple model - more complex JSP)
1
Servlet
(controller)
3
Browser
6
JSP
(view)
2
4
Java
Bean
5 (model)
Data Base/
enterprise
system
(Model-View-Controller (MVC) model - separate controller from view)
Sense-Compute-Control (Real-time)
• Sense-Compute-Control is an architecture which is composed
of:
– Sensors which sends information from various sources
– Compute component which receives the information from sensors
and performs all the necessary numerical and logical computations
and the sends the result as signals to the Control
– Control which receives the results of the computation from the
compute component and decides how to control the various
devices.
• This is an architectural pattern often used in embedded systems.
control B
sensor 1
control C
sensor 2
sensor 3
Compute
control D
control A
Even though arrows go from sensors to compute, it could be compute polling the sensors.
Architectural Styles
• Architectural styles covers the “broadest”
lessons and experiences that are used in
software design. It reflects less domain
Recall, design decisions address:
knowledge and is higher than
programming constructs. It is a named1. elements and their arrangements
2. behavior of elements
collection of design decisions that:
3. interactions of elements
4. non-functional properties
5. implementation guidelines
– is applicable in a specific development (&
problem/solution) context
– constrains architectural design decisions to a
particular system within that context
– elicits beneficial qualities in the resulting
system
An Architectural Style descriptively defines a particular codification of design
elements and formal arrangements. It prescriptively constrains the kinds of design
elements and their arrangements. (It defines and limits the structure --- my words)
Classifying Architectural Styles
• Simple
–
–
–
–
–
–
–
Traditional programming language influenced style
Layered
Dataflow
Shared Memory (Shared State)
Interpreter
Implicit Invocation
Peer-Peer
• More Complex
– C2 (component & connectors)
– Distributed Object
Traditional Language-Influenced Style
• This is based on a “main component” that calls
upon functional “sub-components”
– Traditional programming paradigm
• Software decomposed into 1) main program and 2)
subroutines
• The main program calls the subroutine which in turn may
call other subroutines
• This paradigm gave us the traditional hierarchical style of
main and (decomposed) subcomponents
– OO programming paradigm
• Software decomposed into objects, one of which may be
assumed to play the “main” program role
• The methods in the objects are invoked much like a
procedure call.
• The objects are meant to represent the entities in the
requirements/application world.
Layered Style
• Software is decomposed
into layers where:
– Each layer may request the
service of the layer (usually
immediately) below it
– Each layer provides the service
for the layer immediately above
it.
Layer 1
Layer 2
Layer 3
Prog. A
Prog. B
Prog. C
Prog. D
any advantage or disadvantage ? ---- think of performacne, error location, secuioryt, etc.
Operating System Example of Layered Style
Applications Programs
print
“ Hi”
Operating System
Services
process
scheduler
Hardware
Interrupts &
Kernel
HP
ServicesDevice
printer
service
I/O
Cross layer
Within layer
Dataflow Style
• Separate, independent components or
programs are executed in some sequential
order as data is passed through them to be
processed
– Batch sequential processing
– Pipe and Filter (data flows through pipe to be
processed by filter)
regional daily
transactions
regional daily
transactions
sort/merge
by accnt. #
sorted daily
transactions
update
Master
file
Master File
regional daily
transactions
these “transactions” may be credit cards, stocks, etc. --- advantage/disadvantage?
Shared-State or Shared-Data Style
• Independent components or programs interact through
shared “global” data
– Blackboard
– Rule based system
• This style is used in many commercial systems that has
a “centralized” database
Strongly Data Coupled !
a) Risks?
b) Advantages?
Component
A
Component
B
Component
D
Shared
Repository
Component
C
Component
E
Interpreter Style
• This is a parse, (generate code), and execute
each command; maintain the state of the
execution.
– Basic interpreter : Basic or Java interpreter; Excel code
and graphs
– Mobile code : transmitting code to remote locations for
execution
• Code on demand (have the data but downloads the code to
execute ---- image processing with Adobe photo-shop.)
• Remote evaluation (information is sent to remote site to be
processed and results are returned --- such as in “grid”
computing)
• Mobile agent (information, code, and any required resources
are moved to another site and the results may not be returned
Implicit Invocation Style
• Components are invoked indirectly and implicitly
as a response to some event or notification
(similar to the sense-compute-control pattern
discussed earlier)
– Publish-Subscribe
• There is a producer and consumer of information
• Popular with internet “special news” such as “paid” financial
information by industry sector for investors who subscribe to
it.
– Event-Based (a general case of Publish-Subscribe)
• independent components communicate solely via sending
“events” via a event-bus connector with no designated
publisher or subscriber.
• Information (events) distribution may be processed via
– Push or
– Pull
Peer-Peer Style
• A network of “loosely-coupled” autonomous
components, each may act as a server and a
client.
– This ideal situation is usually modified with
some amount of centralized control or a
directory.
• Originally used for sharing files (e.g. Napster music files)
• Instant message or chat is closest to p2p style.
More Complex Styles
• While we do not have any formal “rules;”
but previous styles may be composed,
extended, and modified to develop more
complex styles as needed. Two such
styles catered to i) distributed and ii)
heterogeneous components are:
– C2 (component and connectors) Style
– Distributed Object Style
C2 (Components and Connectors) Style
• This styles allows various components to be
developed independently, but still communicate,
interact and produce the desired results with the
help of “connectors” and has following set of rules:
–
–
–
–
Topological connection rules
Message based communication rules
Message flow and Substrate Independence rules
Interfaces rules
Component A
Component A
Connector 1
Connector 2
Component B
Component C
C2 Rules in detail
– Topology Rules:
• each component and each connector has a defined top and bottom.
• A component may be attached to only one connector (up/down).
• Arbitrary number of components and connectors may be attached to a
connector
• The top of a component may be attached to the bottom of a connector;
the bottom of a component may be attached to the top of a connector.
Same rules applies to attaching two connectors
– Message Based Communication Rules:
• All communications between components are via “messages”
• A message is classified as i) request for performing a service or ii)
notification of information (e.g. returning information)
– Message Flow Rules:
• All request must flow “upward” in the architectural topology
• All notifications must flow “downward”
– Interface Rules:
• Each component’s top domain which specifies i) the set of requests that
it may send upward and ii) the set of notifications to which it may react
• Each components bottom domain specifies the i) the notifications it can
emit downward and ii) the set of requests to which it responds
C2 Discussions
Component A
• Each component can be attached to This is illegal
only one connector, but multiple
Connector 1
Connector 2
components may share a connector,
it forces “substrate independence”
in that you can not have a
Component C
Component B
component run on, for instance, two
different platforms.
• Using the connector, components
developed with different
programming language and
invocation methods may be
Component A
attached.
This is legal
• Provides a “layering” structure with
the top-bottom and bottom-top
Connector
topological rules
Component B
Component C
Distributed Object Style
• Distributed Object style may be viewed as an
evolution from the C2 Style, where the components
are “objects” and the connector is much more
functionally powerful:
– The objects may run on different hosts
– The objects may be programmed in different languages
– The objects provide services through well defined
interfaces
– The connector acts as the registry/repository of services
and facilitates the connections among the objects
Connector
Component B
in Java running
on HP-Unix
Component C
in C++ running
on MS-Window
remote
Component A
in smalltalk
running on SUN
CORBA: an example of Distributed Object Style
• CORBA (Common Object Request Broker Architecture) is
a middleware architecture produced by the Object
Management Group (OMG), a consortium of about 700+
companies except for Microsoft, who went off to built
Distributed Component Object Model (DCOM).
– CORBA requires all interface specifications, which defines the
component’s interface, to be expressed with Interface Definition
Language (IDL):
• Component attributes
• Invocation interface (methods the interface supports)
• Error processing (exceptions that are raised)
– The key component of CORBA is the connector called Object
Request Broker (ORB), which facilitates objects to make requests
to and receive from other objects that may be local or remote
CORBA (cont.)
• CORBA is composed of 4 main parts:
1. Object Request Broker (ORB) “bus”
2. CORBA Services that extends the services of ORB such as
concurrency service, security service, etc.
3. CORBA Facilities that extends the services for business
objects such as document service for presentation
4. CORBA Business Objects that are the “components” such
as customer order, customer payment, etc.
Client
components
Client
IDL stubs
Server
components
ORB
Interface
Server
IDL
skeletons
Design Recovery
• Many software have evolved through multiple versions
and its initial architecture and design are lost. In
recovering the software architecture one should look
for:
• Components
• Connectors and
• Topology
• Two major techniques that may apply are:
• Syntactical Clustering – grouping of the pieces together based
on “static relationship’
• Semantic clustering – grouping of the pieces based on
“behavior and execution relationship”
• The intent and rationale of the design may never be
recovered.
Design From Scratch
• If there is just no nice experience of
pattern or style and you are facing a
“truly” novel problem that requires new
solution, one may consider:
– Divergence: walk away, tear down old concepts,
and seek for new ideas
– Transformation: review, analyze and select
potential ideas from divergence
– Convergence: further refining and selecting a
single idea or solution
By the way, this is never done in a nice sequential way! On will need to iterate.
Some Suggested Techniques
• Searching for analogous problem and solution in
other fields (e.g. biological system)
• Brainstorming by listing and expanding as much
potential ideas as possible
• Literature search of published material
• Morphological chart by identifying the “primary”
components , finding solutions for them separately
and combining the sub-solutions to form a grand
solution
• Removing Mental Block by modifying the problem,
compromise to solve a lesser problem, etc.
Summarizing General Design Approach
• General Techniques:
– Abstraction
– Separation of Concern
– Modularity
• Use Past Experiences:
– Use design patterns
– Use architectural styles
• Starting from Scratch:
– Make sure that previous solutions really does not
apply
– Search and create a new design that satisfies the
problem (look to requirements carefully)