0% found this document useful (0 votes)
19 views36 pages

Agile Software Architecture Guide

Software architecture and design

Uploaded by

8b6y7t5vnj
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
19 views36 pages

Agile Software Architecture Guide

Software architecture and design

Uploaded by

8b6y7t5vnj
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd

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
• Major recent changes:
– Software-component-based software engineering and
software frameworks, like Java EE and .NET, have greatly
enhanced the level of complexity encapsulation
– Web services and service-oriented architectures have
brought us more flexible connector implementation
technologies and software architecture varieties
Introduction
• Software architecture
– Software elements: process, object, instance of software
component, service
• Elements could be deployed on different hardware or
software platforms, developed in different languages
or on different software frameworks
– Connectors: local method invocation, remote method
invocation, service call, messaging
Outline

● Types of Software Structure


● Software elements
● Software connectors
● An Agile Approach to Software structural design
Types of Software Structures
• A software architecture can be described with various software
structures, each from a different perspective:
1. Static source code structure
2. Static deployment structure
3. Runtime structure
4. Management structure

• Different structures use different elements and connectors, and


have different performance attributes
1. Static Source Code Structure

• At software development time, the main software


elements are source code modules or files
– Each of these software modules 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 during execution
1. Static Source Code Structure

• Static connectors have attributes including


– Direction. If module A invokes a method of module
B during execution, 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.
2. Static Deployment Structure

• At software deployment time, the software elements


are the executable version of the project modules
and files; able to be run by a computer.
– Several source code modules may be packaged
into the same deployment unit.
• The connectors in the deployment structures are
basically the same as those for the source module
structures.
Managing Static Structural
Representations
• The software static structure plays a critical role in
software architectural design
• The fact that 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
3. Software Runtime Structure
• At runtime elements are threads, processes, functional units,
and data units
• 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
3. Software Runtime Structure
• Runtime connectors inherit attributes from their source-code
structure counterparts, with a few extra attributes such as:
– 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
4. Software Management Structure

• A large software project is normally designed and


implemented by several project teams, each having its
well-defined responsibilities at specific SDLC 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.
• The connectors are derived from runtime dependency among
the code units and software process dependencies
• Software management structures are also often used for project
resource allocation
Outline

● Types of Software Structure


● Software Elements
● Software Connectors
● An Agile Approach to Software Structural
Design
Software Elements

• The elements of a software architecture are usually refined


through multiple transformation steps based on the element
attributes and the project requirement specification
• Each software element may have different synchronization and
performance constraints
Some Guidelines for Mapping Runtime
Elements -1

• 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
• 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 its performance is not critical
– it is more cost-effective to use an existing software component
to implement the element’s functions
Some Guidelines for Mapping Runtime
Elements -2
• 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
• A complex element can be transformed into a sequence of
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
Outline

● Types of Software Structure


● Software Elements
● Software Connectors
● An Agile Approach to Software Structural
Design
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
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

Software connectors can be classified based on


connector’s
1. synchronization mode
2. initiator
3. information carrier
4. implementation type
5. active time
6. span
7. fan-out
8. environment
1. Synchronization mode

– Blocking
• allows one of its incident elements to send a request
(method call or message) to another and wait for a response
(method return value or message), and 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 then continue its
execution without waiting for a response
2. 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 other way around

– two-initiator connectors
• allows either of its two incident elements to make a request to the
other element
3. Information carrier
• Variable
– for elements in the same process
• Environment resource
– for elements in different processes of the same system
• Method
– Local invocation or Remote invocation
• Message
– An example message system, consisting of a message sender and a message
receiver modules connected by a network, is used to implement a one-initiator
connector for sub-system 1 to send messages/requests to sub-system 2

Message network Message


Sub-system 1 Sub-system 2
sender receiver
4. Implementation type

– Signature-based
• The method’s name indicates an operation, and the parameters
carry argument values for the execution of the operation

– Protocol-based
• A protocol-based connector can implement multiple operation types
with a single binding signature
5. 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
6. 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
7. 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
8. 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
Outline

● Types of Software Structure


● Software Elements
● Software Connectors
● An Agile Approach to Software Structural
Design
An Agile Example to Software
Architecture Design

• A standalone data presenter


An Agile Example to Software
Architecture Design -2

• Networked data presenter


An Agile Example to Software
Architecture Design -3

• HTML and HTTP based data presenter


An Agile Example to Software
Architecture Design -4

• The web architecture


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

You might also like