Chapter 2 Software

Architectural Design Space

 Objectives
 Introduce major perspectives and
structures for a software architecture
 Introduce major element and connector
types of a software architecture
 Introduce the iterative refinement process
for software architectural design
 Introduction
• Architectural design space
– Design alternatives that can
• support functional and non-functional requirement
specifications
• Major challenge
– how to produce “agile” software architectures that
• can be easily adapted to their changing environments
without major re-engineering
 Introduction …
• In a software architecture
– Software elements
• Includes
– process
– object
– instance of software component, service
• could be deployed on different hardware or
software platforms
• could be developed in different languages or on
different software frameworks
 Introduction …
• In a software architecture
– Connectors
• local method invocation
• remote method invocation
• service call
• messaging
 Introduction …
• Major recent changes:
– Software-component-based software engineering and
software frameworks
• have greatly enhanced the level of complexity encapsulation
• Ex : like Java EE and .NET
– Web services and service-oriented architectures have
• more flexible connector implementation technologies and
software architecture varieties
Types of Software Structures
• A software architecture can be described with
various software structures, each from a
different perspective
– Static (source code) structure
– Dynamic structure
– Deployment structure
– Management structure
• Different structures
– use different elements and connectors,
– have different performance attributes
 Static (Source Code) Structure
• At software development time, the main software
elements are
– source code modules or files
• Has assigned functional and non-functional attributes
• The connectors at this level are in the form of
module dependency
– Module A is connected to module B
• if and only if A needs to invoke some methods in module B
Static (Source Code) Structure …
• Static connectors have attributes including
– Direction
• If module A invokes a method of module B
– then there is a unidirectional connector from module A to
module B.
– Synchronization.
• A method invocation can be synchronous or
asynchronous.
– Sequence.
• Some connectors must be used in a particular
sequence.
Static (Source Code) Structure …
 Static Deployment Structure
• At software deployment time, the software
elements are
– the executable version of the project modules
and files
• Several source code modules
– may be packaged into the same deployment
unit
• The connectors are basically the same as
those for the source module structures
Static Deployment Structure
Static Deployment Structure
Managing Static Structural Representations

• Static Structural play a critical role

• Systems are developed incrementally
– increases the need for tight control of this structure in
the physical software element
• Managing static structural representations
involves
– dealing with layers of abstraction and levels of
refinements
• showing visibility and encapsulation, respectively
 Managing Static Structural Representations …

• Two kinds of static hierarchical relations

– A linear client-server relation
• is formed when a component provides primitive abstractions
to another component;
– in this sense, components can refer to abstractions that once
defined can be used throughout the entire design (at all levels).
– A tree-like hierarchy of refinement relations
• defined between an abstraction (i.e., a component) and its
implementation,
– by the recursive division of components into sub-components
Managing Static Structural Representations …
Managing Static Structural Representations …
 Software Management Structure
• A large software project
– is normally designed and implemented by several project teams,
• each having its well-defined responsibilities at specific Software
Development Life Cycle process stages
• In this structure, each element consists of
– specific manipulation (design, implementation, debugging, etc.) of
specific code units
• assigned to the same project team,
• Also often used for project resource allocation
Software Management Structure
 Software Runtime Structure
• At runtime elements are
– threads,
– processes,
– functional units,
– and data units
• These elements may run on
– the same computer or
– multiple computers across a network
 Software Runtime Structure
• The same element in a code structure can implement or
support multiple runtime elements
– In a client-server application, the same client module may run on
many client computers
• Several code structure elements may implement or
support a single runtime element
– Many threads may run multiple methods from different classes
that may be packaged in different code units
 Software Runtime Structure …
• Runtime connectors inherit attributes
– from their source-code structure counterparts, with a few extra
attributes
• Multiplicity.
– One element can be connected to multiple other elements if it needs to invoke
methods of multiple elements at runtime
• Distance and connection media
• Universally invokable.
– with this attribute set to true, it allows any external software system can invoke
the method at the connector’s target, no matter what
» hardware/ software platforms that they run on
» what programming languages or software frameworks that they are
developed in
• Self-descriptive.
– With this attribute set to true. It allows external software systems invoke its
target method without the pre-installation of any software specific for the method
Software Runtime Structure …
Software Runtime Structure …
 Software Elements
• The elements of a software architecture
– are usually refined through multiple transformation steps based
on
• the element attributes
• the project requirement specification
• Based on the function assignment, each software
element may have different
– synchronization
• Multiplicity, reentrant, …
– performance constraints
• Scalability, response time, throughput…
 Guidelines for Mapping Runtime Elements

• If an element is reentrant
– it can be implemented by a thread or a process
• If an element is
– not reentrant and
– multiple threads or processes may need to communicate with it
-> it must be run on separate threads or processes so they can be
thread-safe
• If an element has
– high multiplicity and
– its performance is important to the global system performance,
-> an application server should be used for its implementation
 Guidelines for Mapping Runtime Elements …

• If there are heavy computations

– in the elements for deployment at a particular location
• a cluster of processors
– should be considered for added CPU data processing power

• If an element is assigned
– complex
– but well-defined functions similar to those of some commercial
off-the-shelf software components and
– the performance of this element is not critical
-> then it is more cost-effective to use an existing software
component to implement the element’s functions
 Guidelines for Mapping Runtime Elements …

• A complex element can be expanded

– into a sub-system with its own elements and connectors
• A complex element can be transformed into
– a sequence of
• vertical layered elements
– if each layer provides a virtual machine or interface to its immediate
upper layer element and each layered element hides away some low-
level system details from the upper layers
• horizontally tiered elements
– if the business logic can be achieved by processing data with a
sequence of discrete processing stages and these processing stages
can be implemented by tiered elements with well-defined interfaces and
balanced workloads
 Software Connectors
• The connectors of a software architecture should be
– refined within the design process
• Connector refinement is heavily influenced by
– a project’s deployment environment
• In the most abstract form a connector
– just indicates the necessity during system execution time for one
of the elements
• to send a message to another element and potentially get some
return message
 Guidelines for Mapping Software Connectors …

• During the refinement of the software architecture

– If the two elements are mapped to a single process,
• the connector could be mapped to a local method invocation
– If the two elements are mapped to two different processes on
the same computer
• then the connector could be mapped to a local message queue or a
pipe
– If the two elements are mapped to two different computers,
• then remote method invocation or Web service invocation could be
used
– for the architectural refinement for the corresponding connector
between them
 Software Connector Classification

• Based on connector’s synchronization mode

– blocking
• allows one of its incident elements to send a request
(method call or message) to another
• wait for a response (method return value or message),
• the element will be blocked from further execution until it
receives a response
– non-blocking
• allows one of its incident elements to send a request
(method call or message) to another and
• continue its execution without waiting for a response
 Software Connector Classification …

• Based on the connector’s initiator

– An initiator is an incident element of a connector that
can make a request to its partner
– one-initiator connectors
• allows one of its two incident elements to make a request to
the other element, but not the another way around
– two-initiator connectors
• allows either of its two incident elements to make a request
to the other element
– For a system to support callback between its two sub-systems, the two
sub-systems must be connected by a two-initiator connector
 Software Connector Classification …

• Based on connector’s information carrier

– Variable
• for elements in the same process
– Environment resource
• for elements in different processes of the same system
– Method
• Local invocation
• Remote invocation
 Software Connector Classification …
• Based on connector’s information carrier …
– Message
• An example message system,
– consisting of a message sender module and a message receiver
module connected by a network,
– is used to implement a one-initiator connector for sub-system 1 to send
messages/requests to sub-system 2
• A message format must be defined so both the message sender
and the message receiver can understand the messages
• a protocol must be adopted to decide the proper handshaking and
synchronization between the two parties
message system

Message network Message

Sub-system 1 Sub-system 2
sender receiver
 Software Connector Classification …

• Based on connector’s implementation type

– Signature-based
• The method’s name indicates an operation, and the
parameters carry argument values for the execution of the
operation
• If we assign one or more parameters of a method also to
indicate operation types, then the connector can be used to
implement protocols
– Protocol-based
• A protocol-based connector can implement multiple
operation types with a single binding signature
 Software Connector Classification …

• Based on connector’s active time

– Programmed
• A method call will be made at a time specified at
programming time
– Event-driven
• One element will function as an event source
• All elements that need be notified of the event will register as
listeners of the event source
• When the event happens, all the registered listener elements
will be notified for potential reaction
– Method callback can be considered as a special case of this event-
driven mechanism
 Software Connector Classification …

• Based on connector span

– Local
• The incident elements are located in the same processor
– Networked
• Normally implemented with the proxy design pattern to
support object-oriented programming paradigm in a
distributed environment

Sub-system 1 Same interface Sub-system 2

Message network Message

sender receiver
Proxy Skeleton
message system
 Software Connector Classification …

• Based on connector fan-out

– “1-1”
• for connecting two elements only
– “1-*”
• for connecting one element with variable elements of the
same type
– A web server and the web browsers are connected with a 1-* connector
– So are the server and clients in a client-server architecture
 Software Connector Classification …

• Based on connector environment

– Homogeneous
• The incident elements of a homogeneous connector are
implemented with the same programming language and
software framework and run on the same operating system
– Heterogeneous
• The incident elements of a heterogeneous connector may be
implemented with different programming languages or
software frameworks and may run on different operating
systems
 Software Connector Classification …

• Based on connector environment …

– Heterogeneous …
• CORBA, Web services and messaging are typical
implementation technologies for heterogeneous connectors
• Heterogeneous connectors are usually implemented with the
broker design pattern
• A message system could be implemented with the message
sender and receiver modules implemented in different
programming languages or on different platforms
 An Agile Example to Software Architecture Design

• A standalone data presenter

Client Data retrieval

Data
GUI & processing
An Agile Example to Software Architecture Design …

• Networked data presenter

Server

Client networked Data retrieval

Data
GUI & processing
An Agile Example to Software Architecture Design …

• HTML and HTTP based data presenter

HTML HTTP HTML Server

presenter generator

Data retrieval
Data
& processing
An Agile Example to Software Architecture Design …

• The web architecture

HTML HTTP HTML Data retrieval

presenter Data
generator & processing

Application
Web Browser Web Server Data storage
Server
 Conclusion
• Software architectures determine the overall structures of
software systems and have great impact on their quality
• Software architectures can be viewed from multiple
perspectives
• Each type of structure consists of elements and connectors
as well as constraint attributes for both, the elements and
the connectors; these are derived from the requirements
specification
• To minimize the impact of changing project requirements
and to maximize design and implementation reuse, an
architect should adopt an iterative process for the
architecture design