Software Architecture Design Space 2

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


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


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


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


5/33


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


6/33


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/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?


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?


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


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


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


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


13/33

Step 3: Identify related strategies

When a strategy belongs with more than one issue,dont repeat the strategy


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


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


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.


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


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.


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.


20/33


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.


21/33


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.


22/33


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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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.

Date post:	10-Feb-2018
Category:	Documents
Upload:	tewodros-g-le
View:	215 times
Download:	0 times

Software Architecture Design Space 2

Documents