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 concept3. detail design: further defining and refining the design concept4. 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

• One may wonder around a while in the beginning to get started:

1. Looking and understanding at key requirements

2. mapping functional requirements to major components

3. relating the components to produce the overall system

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

Increases in

difficu

lty

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.– The generalization from the details and the

specifics ABSTRACTI

ON

“SHAPES”

Do you remember how many dogs and catsyou saw as a child before you realized the “class”-dog and the “class”-cats ?! ---- followthe 1-2 year olds sometime and see how they cope with the problem of “classification”.

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

TrianglesArrows

Ovals

“2-D” shapes

SHAPES

Red arrow = decompositionBlue arrow = composition

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

App DomainKnowledge

deep

shallow

Scope Applicability

programminglevel

software designcomponentlevel

Software Systemlevel

Designpatterns

Design Styles

Architecturalpatterns

Domain SpecificSoftware Architecture

mostly for OO detail design & programming

we focus on these 3

some combinethese into “styles”

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. a reference architecture for a specific domain,2. a library of software components containing reusable

chunks of domain expertise, and3. a method of choosing and configuring components to

work within an instance of the reference architecture.

Domaincore

(2) domain components

(1) reference architecturefor domain x

(3) “Core must be a part ofevery 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.

User Interface(Display)

Business Logic

(Logic)

Database(State)

request

response response

request

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)

Controller

ModelView

Today’s Popular Model with JSPfor dynamic presentation content

BrowserData Base/enterprise

system

JSP

JavaBean

1

23

4

Browser

JSP(view)

JavaBean

(model)

Servlet(controller) Data Base/

enterprisesystem

(Simple model - more complex JSP)

(Model-View-Controller (MVC) model - separate controller from view)

1

3

56

24

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.

sensor 3

Compute

control A

sensor 1

sensor 2

control B

control D

control C

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 knowledge and is higher than programming constructs. It is a named collection of design decisions that:

– 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 designelements and formal arrangements. It prescriptively constrains the kinds of design elements and their arrangements. (It defines and limits the structure --- my words)

Recall, design decisions address:

1. elements and their arrangements2. behavior of elements3. interactions of elements4. non-functional properties5. implementation guidelines

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.

Prog. A

Prog. CProg. B

Prog. D

Layer 1

Layer 2

Layer 3

any advantage or disadvantage ? ---- think of performacne, error location, secuioryt, etc.

Operating System Example of Layered Style

Applications Programs

Operating System Services

Hardware Interrupts &

KernelServices

print“ Hi”

printerserviceHP

DeviceI/O

processscheduler

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 dailytransactions

sort/merge by accnt. #

updateMaster

file Master File

sorted dailytransactionsregional daily

transactions

regional dailytransactions

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

Shared Repository

Component A

Component B

Component C

Component E

Component D

Strongly Data Coupled !a) Risks?b) Advantages?

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 B

Component A

Connector 1 Connector 2

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

• Each component can be attached to only one connector, but multiple components may share a connector, it forces “substrate independence” in that you can not have a component run on, for instance, two different platforms.

• Using the connector, components developed with different programming language and invocation methods may be attached.

• Provides a “layering” structure with the top-bottom and bottom-top topological rules

Component B

Component A

Connector 2

Component C

Connector 1

C2 Discussions

This is illegal

Component CComponent B

Connector

Component AThis is legal

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

Component Cin C++ runningon MS-Window

Component Bin Java running

on HP-Unix

Connector

Component Ain smalltalk

running on SUN

remote

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.

ORBInterface

Clientcomponents

Servercomponents

ClientIDL stubs

ServerIDL

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)