Upload
tewodros-g-le
View
215
Download
0
Embed Size (px)
Citation preview
7/22/2019 Software Architecture Design Space 2
1/33
Chapter 2-Software Architecture Design Space
hapter OutlineGlobal Analysis
Types of Software Structures
Software Static Structure
Software Runtime Structure
Software Management Structure
Software Elements
Software Connectors
An Agile Approach to Software Architecture Design
7/22/2019 Software Architecture Design Space 2
2/33
Global analysis
Identify the external influencing factors and critical
requirements that could affect the architecture
Analyze them to come up with strategies fordesigning the architecture
If all cannot be satisfied, decide which has priority,renegotiate a requirement, or change someexternal factor to come up with workable strategies
7/22/2019 Software Architecture Design Space 2
3/33
Global analysis (Contd)
Influencing factors
Organizational factors
Development schedule, budget
Organizational attitudes, software process
Technological factors
Available hardware and software technology
Product factors Performance, dependability, cost
May be different in future versions
7/22/2019 Software Architecture Design Space 2
4/33
Global analysis(contd)
Many factors affect the entire system
Strategies should address global concerns, butprovide guidance for implementing them locally
Occurs throughout the design
New factors, issues or strategies can arise at any time
Consider factors as a group
Might be contradicting
Sort out conflicts and resolve them
7/22/2019 Software Architecture Design Space 2
5/33
Global analysis(contd)
Complements the risk analysis and/or requirements
analysis
Requirements and risk analyses might give theanalyzed factors
Then develop strategies to the design
Provides a systematic way of identifying,accommodating and describing the affectingfactors
7/22/2019 Software Architecture Design Space 2
6/33
Global analysis(contd)
Analyzing factors
Take as input the organizational, technological andproduct factors
Make them explicit
Three (3) step procedure
Step 1: Identify and describe the factors
Step 2: Characterize the flexibility or the
changeability of the factors Step3: Analyze the impact of the factors
7/22/2019 Software Architecture Design Space 2
7/33
Step 1: Identify and describe the factors
Can the factors influence be localized to onecomponent or not?
During which stages of development is the factorimportant?
Does the factor require any new expertise or skills?
7/22/2019 Software Architecture Design Space 2
8/33
Step 2: Characterize the flexibility or the
changeability of the factors
Flexibility Is it possible to influence or change the factor so that
it makes your task of architecture developmenteasier?
In what way can you influence it?
To what extent can you influence it?
Changeability In what way could the factor change?
How likely will it change during or after development? How often will it change?
Will the factor be affected by changes in the otherfactors?
7/22/2019 Software Architecture Design Space 2
9/33
Step3: Analyze the impact of the factors
If a factor was to change, which of the followingwould be affected and how:
Other factors
Components
Modes of operation of the systemOther design decisions
7/22/2019 Software Architecture Design Space 2
10/33
Global analysis (contd)
Develop strategies
Three (3) steps procedure
Step 1: Identify issues and influencing factors
Step 2: Develop solutions and specific strategies
Step 3: Identify related strategies
7/22/2019 Software Architecture Design Space 2
11/33
Step 1: Identify issues and influencing
factors
Identify a handful of important issues that areinfluenced by the factor and their changeability
Limitations or constraints imposed by factors Aggressive development schedule
A need to reduce the impact of changeability offactors
Design for portability
Difficulty in satisfying product factors High throughput req. may overload CPU
A common solution to global requirements Error handling and recovery
7/22/2019 Software Architecture Design Space 2
12/33
Step 2: Develop solutions and specific
strategies
For each issue, develop strategies that address theissue and ensure the implementation changeabilityof the architecture design
Reduce or localize the factors influence Reduce the impact of the factors changeability on
the design and other factors
Reduce or localize required area of expertise or skills
Reduce overall time and effort
7/22/2019 Software Architecture Design Space 2
13/33
Step 3: Identify related strategies
When a strategy belongs with more than one issue,dont repeat the strategy
7/22/2019 Software Architecture Design Space 2
14/33
Global Analysis Summary
Consider three kinds of influencing factors
Organizational factors Constrain design choices
Technological factors
Embedded or embodied in the product
Product factors
Functional features and qualities of theproduct
7/22/2019 Software Architecture Design Space 2
15/33
Global Analysis Summary(contd)
At the end of architecture design you will
have
Characterized the important influencing factorsand
Developed strategies for ensuring
Buildability
Implementation
changeability
7/22/2019 Software Architecture Design Space 2
16/33
Software Architecture Design SpaceA software architect
is responsible for proposing a concrete architecture that bestsupports the detailed design and implementation of a specific
project.
must know what design alternatives are available to them, and
which one will best support the functional and nonfunctionalrequirements.
In short, he/she must understand the software architecture's
design space.
A software architecture design is a set of softwareelements connected by a set of connectors.
From a dynamic structure point of view, a software
element can be a process, an object, an instance of a
software component, or a service.
7/22/2019 Software Architecture Design Space 2
17/33
Software Architecture Design Space(contd)
Different software elements may run on different hardware
and software platforms and may be implemented in different
programming languages or on different software frameworks.
Two software elements can run in the same process, on the
same computer system, within an intranet, or distributed over
the Internet.
Depending on their relative location, the connectors between
a pair of software elements can be implemented in various
forms including local method invocations, remote method
invocations, service calls, and messaging through a message
queue.The connectors can also work in synchronous or asynchronous
nodes.
In terms of the static structure, a software element can be a
package, a class, a component, or a loadable library
7/22/2019 Software Architecture Design Space 2
18/33
Software Architecture Design Space(contd)
A connector can be an import clause, inheritance clause,
interface specification, pipe, or filter.A good software architecture should be able to easily
adapt to changing environments of business operations
without the need for major reengineering of
corresponding software systems.
Over the last decade, information technology has gone
through significant changes:- frameworks, technologies
such as. NET and J2EE (Java 2 Enterprise Edition)-
enhanced the level of encapsulation.
Web services and service-oriented architectures have
brought us more flexible connector implementation
technologies and software architecture varieties.
7/22/2019 Software Architecture Design Space 2
19/33
Types of Static Structure
Software architecture design can described in terms of
software code units like source/binary code files,software modules, or software component deployment
units; this is known as the static structure.
It may also be described based on the runtime dynamic
structure, in which the software elements are threads,
processes, sessions, transactions, objects, or software
component instances at execution time.
An allocation structure may also be used to describe the
project management structure of an architecture
design.
These different types of structures use different
connector types and different performance attributes.
7/22/2019 Software Architecture Design Space 2
20/33
Software Static Structure
A software project is typically implemented in multiple files-
includes static file types such as executable files; library files;binary software component modules (usually in the form of
DLLs [dynamic linking libraries], JavaBeans, and Enterprise
JavaBeans); deployment descriptors; and other resource files.
At software development time, the main software elements
are source code modules or files. Each module has assigned
functional and nonfunctional attributes, and the public APIs
(application programming interfaces), defined for each
module separate the module's interfaces and
implementations.
The connectors at this level are module dependent. Module A
is connected to module B if, and only if, A needs to invoke
some methods in B during execution.
7/22/2019 Software Architecture Design Space 2
21/33
Software Static Structure
Such connectors may exhibit the following attributes:
Direction: If module A invokes a method of module B duringexecution, 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. For example, module A may invoke a method of
module B and pass a callback reference during the invocation.
At software deployment time, the elements are binary versions of
the project modules and files. Several source code modules may
be packaged into the same deployment unit, but the connectors
in the deployment structures are the same as those for the source
module structures.
7/22/2019 Software Architecture Design Space 2
22/33
Software Static Structure
The software static structure refers to the organization of
physical software modules and their interrelations and thisstructure plays a critical role in software architecture design.
Static structure affects the architecture's clarity, construction
strategy, maintenance, reengineering, reusability, etc.
It plays a crucial role in the management of large softwaresystems because it deals with the packaging of software
modules in order to facilitate system construction and
maintenance through a clear portrayal of intermodule
relations.
Managing static structures involves layers of abstraction and
of refinement showing visibility and encapsulation,
respectively.
7/22/2019 Software Architecture Design Space 2
23/33
Software Run time Structure
At runtime a project consists of one or more
threads, processes, functional units, and data units.These elements may run on the same computer or
on multiple computers across a network.
The same element in a code structure may
implement or support multiple runtime elements.For example, in a client-server application, the
same client module may run on many client
computers.
The connectors at this level inherit attributes fromtheir source-code structure counterparts.
7/22/2019 Software Architecture Design Space 2
24/33
Software Management StructureA large software project is normally designed andimplemented by several project teams, each having itswell-defined responsibilities at specific SDLC processstages.At this level, each element consists of manipulation(design, implementation, debugging, etc.) of specificcode units assigned to each project team, and the
connectors are derived from runtime dependencyamong the code units and software processdependencies.Some software architectures are best implemented bya particular software management structure.
Software management structures are also used forproject resource allocation.Software runtime structures serve as the technicalbackbone of architecture designs and provide thebasis from which other structures are derived.
7/22/2019 Software Architecture Design Space 2
25/33
Software Elements
At runtime each software element has well-defined
functions and connects to the other elements into adependency graph through connectors.
The elements of a software architecture are usuallyrefined through multiple transformation steps based ontheir attributes and the project requirement
specifications.Depending on each software element's assignedfunction, there may be different synchronization andperformance constraints.
For example, some elements are reentrant objects or
software components (meaning that multiple threadscan execute in an element concurrently withoutinterfering with each other) while some elements arenot reentrant and no more than one thread mayexecute in it at any time.
7/22/2019 Software Architecture Design Space 2
26/33
Software Elements
Depending on the multiplicity of an element, it
could be invoked by a limited number of otherelements at execution time, or it could be invokedby unlimited elements, as in the case of a serverelement.
Scalability, response time, and throughput becomeimportant performance constraints and must beconsidered during the element's implementation.
7/22/2019 Software Architecture Design Space 2
27/33
Software Connectors
The connectors in software architecture are refinedduring the design process and are heavily influenced
by a project's deployment environment.A connector indicates the necessity during systemexecution for one of the elements to send a message toanother element and potentially get a return message.During software architecture refinement, if two
elements are mapped to a single process, theconnector can be mapped to a local methodinvocation.If two elements are mapped to two different processeson the same computer, the connector can be mappedto a local message queue or a pipe.If the two elements are mapped to two differentcomputers, then remote method invocation or webservice invocation can be used to refine the connectorbetween them.
7/22/2019 Software Architecture Design Space 2
28/33
Software ConnectorsSoftware connectors are classified according to manyattributes, including synchronization mode, initiator,
implementation type, active time span, fan-out,information carrier, and environment.
Based on the connector's synchronization mode, we canclassify all connectors into two categories: blockingconnectors and non-blocking connectors.
A blocking connector allows one of its incident elementsto send a request (method call or message) to anotherand wait for a response (method return value ormessage). The element will be blocked from furtherexecution until it receives a response.
A non-blocking connector allows one of its incident
elements to send a request (method call or message) toanother and then continue its execution without waitingfor a response.
7/22/2019 Software Architecture Design Space 2
29/33
Software ConnectorsBased on the connector's initiator, we can classify all
connectors into two categories: one-initiatorconnectors and two-initiator connectors
An initiator is an incident element of a connectorthat can make a request to its partner.
A one initiator connector allows only one of its two
incident elements to make a request to the otherelement, but not another way around.
A two-initiator connector allows either one of its twoincident elements to make a request to the other
element.For a system to support callback between its twosubsystems, the two subsystems must be connectedby a two-initiator connector.
7/22/2019 Software Architecture Design Space 2
30/33
Software Connectors
If the two incident elements are in the same
process, say as two threads, they may use a sharedvariable to exchange information.
If they are mapped to different processes on thesame processor, then resources like pipes, files, or
local message queues may be used to implementthe connector.
Method invocations and message passing are morecommon and more structured ways for carrying
information.Remote method invocation and messaging canalso allow communication among elementsdeployed on different processors.
7/22/2019 Software Architecture Design Space 2
31/33
An Agile Approach to Software
Architecture DesignTraditional software architecture designs, fundamentallybased on a waterfall model (a linear process withoutintegrating feedbacks), do not emphasize the iterativerefinement nature and do not use element and connectorattributes to capture the key architecture requirements ofa software project.
There is big gap between a project's requirementspecification and a concrete software architecture for itsdetailed design and implementation.
Another weak point of traditional architecture design isthat if the deployment environment changes, which arehappening more often with the economy's globalization,the architecture design must start from scratch.An iterative, agile approach for developing softwarearchitectures that maximizes the reuse of architecture,design, and implementation investments.
7/22/2019 Software Architecture Design Space 2
32/33
An Agile Approach to SoftwareArchitecture Design
Given a project specification, abstract high-levelsoftware architecture will first be proposed, andattributes will be identified for its elements andconnectors.
This abstract software architecture will generally be
free of deployment considerations.The architecture will then go through multiplerefinement processes to support particulardeployment constraints.
The unique features of this approach include thedelayed binding of software connectors for moreflexible implementation decisions and the seamlessintegration of multiple architecture styles in realizingdifferent subsystems or levels of the same system.
7/22/2019 Software Architecture Design Space 2
33/33
Chapter SummarySoftware architecture determines the overall structure of asoftware system and greatly impacts its quality.
The architecture can be viewed from multiple perspectivesincluding the code structure (or static structure), runtimestructure (or dynamic structure), and management structure (ordeployment structure).Each type of structure consists of elements and connectors andtheir constraint attributes, which are derived from the
requirements specification.To minimize the impact of changing project requirements and tomaximize the ability to reuse design and implementation, anarchitect should adopt an iterative process during the designphase.Initial architecture designs should focus on the core functional
and nonfunctional requirements; the resulting complex elementscan then be refined into subsystems with their own architecturedesigns.A good architecture solution is typically based on multiplearchitecture styles for different subsystems or for different systemabstraction levels.