an introduction to software architecture software engineering lab

56
Software Software Architecture Architecture Software Engineering Lab Software Engineering Lab

Upload: poppy-willis

Post on 03-Jan-2016

243 views

Category:

Documents


1 download

TRANSCRIPT

Page 1: An Introduction to Software Architecture Software Engineering Lab

An Introduction to An Introduction to Software ArchitectureSoftware Architecture

Software Engineering LabSoftware Engineering Lab

Page 2: An Introduction to Software Architecture Software Engineering Lab

Table of contentTable of content

IntroductionIntroduction Architecture Business CycleArchitecture Business Cycle Architectural Structures and ViewsArchitectural Structures and Views Quality AttributesQuality Attributes Achieving QualitiesAchieving Qualities Software Architecture Analysis Software Architecture Analysis

MethodMethod

Page 3: An Introduction to Software Architecture Software Engineering Lab

IntroductionIntroduction

Page 4: An Introduction to Software Architecture Software Engineering Lab

DefinitionDefinition

The software architecture of a The software architecture of a program or computing system is program or computing system is the the structurestructure or structures of the or structures of the system, which comprise system, which comprise software software elementselements, the , the externally visible propertiesexternally visible properties of of those elements, and the those elements, and the relationshipsrelationships among them among them..

Page 5: An Introduction to Software Architecture Software Engineering Lab

Externally Visible vs. Internal Externally Visible vs. Internal PropertiesProperties

Externally visible properties are what Externally visible properties are what assumption other elements can make of assumption other elements can make of an elementan element Provided services (and interface to access Provided services (and interface to access

those services)those services) PerformancePerformance Fault handlingFault handling Shared resource usageShared resource usage……

SA intentionally abstracts away internal SA intentionally abstracts away internal properties of elements (to better properties of elements (to better encounter complexity)encounter complexity)

Page 6: An Introduction to Software Architecture Software Engineering Lab

Why is architecture Why is architecture important?important?

►Handling complexityHandling complexity

►Communication among stakeholdersCommunication among stakeholders Requirements and concerns of Requirements and concerns of

stakeholdersstakeholders TimeTime BudgetBudget Other ResourcesOther Resources

Page 7: An Introduction to Software Architecture Software Engineering Lab

Why is architecture important? Why is architecture important? (cont)(cont)

►Early Design DecisionsEarly Design Decisions Constraints implementation and Constraints implementation and

implementersimplementers Organizational structureOrganizational structure Enables predicting and ensuring quality Enables predicting and ensuring quality

attributesattributes Helps evolutionary prototyping (risk Helps evolutionary prototyping (risk

reduction)reduction)

Page 8: An Introduction to Software Architecture Software Engineering Lab

Why is architecture important? Why is architecture important? (cont)(cont)

►SA is a transferable, reusable modelSA is a transferable, reusable model Software product linesSoftware product lines Component-based developmentComponent-based development Automatic generation of lower-level Automatic generation of lower-level

modelsmodels A basis for trainingA basis for training

Page 9: An Introduction to Software Architecture Software Engineering Lab

HazardsHazards

►With regards to SA changes are With regards to SA changes are categorized tocategorized to Local (a single component)Local (a single component) Non-local (a few components)Non-local (a few components) Architectural (architectural style)Architectural (architectural style)

►Once decided architecture is extremely Once decided architecture is extremely hard to changehard to change

► It impossible to reach to some quality It impossible to reach to some quality attribute if architecture disallowsattribute if architecture disallows

Page 10: An Introduction to Software Architecture Software Engineering Lab

Software Arch. vs. System Software Arch. vs. System Arch.Arch.

►System Arch. is the overall architecture of System Arch. is the overall architecture of system including system including hardwarehardware and and softwaresoftware architecturearchitecture

► In assuring quality attributes the architect In assuring quality attributes the architect needs to think about system architecture needs to think about system architecture too (e.g. performance or reliability)too (e.g. performance or reliability)

►But architect has more freedom in But architect has more freedom in software architecture than hardware software architecture than hardware (hardware choices is less under the (hardware choices is less under the architects control)architects control)

Page 11: An Introduction to Software Architecture Software Engineering Lab

Architecture Business CycleArchitecture Business Cycle

Page 12: An Introduction to Software Architecture Software Engineering Lab

Who influences SA?Who influences SA?

Page 13: An Introduction to Software Architecture Software Engineering Lab

Summary: Influences on the Summary: Influences on the ArchitectArchitect

Page 14: An Introduction to Software Architecture Software Engineering Lab

Architecture Business CycleArchitecture Business Cycle

Page 15: An Introduction to Software Architecture Software Engineering Lab

Architectural Structures and Architectural Structures and ViewsViews

Page 16: An Introduction to Software Architecture Software Engineering Lab

Architectural Structures and Architectural Structures and ViewsViews

In construction, there are In construction, there are blueprintsblueprints of of PlanPlan Different sides of constructionDifferent sides of construction Electrical wiringElectrical wiring PlumbingPlumbing……

Each of these views specifies a single entity (i.e. Each of these views specifies a single entity (i.e. the construction) from a different perspective the construction) from a different perspective (used by a different person, for a different goal).(used by a different person, for a different goal).

Similarly there are different structures and views Similarly there are different structures and views in SA.in SA.

Page 17: An Introduction to Software Architecture Software Engineering Lab

Structures and Views (cont)Structures and Views (cont)

► Structures is a set of coherent elements and the Structures is a set of coherent elements and the relations among them. For each structure these we relations among them. For each structure these we can specify:can specify:

► Types of Types of elementselements► Types of Types of relationsrelations► A set of A set of syntactic constraintssyntactic constraints► SemanticsSemantics of the diagram of the diagram► RationaleRationale, , principlesprinciples, and , and guidelinesguidelines► For what For what purposespurposes it is useful it is useful

► View is a representation of software architecture View is a representation of software architecture based on an structure as written by the architect and based on an structure as written by the architect and read by stakeholders (an instance of the structure)read by stakeholders (an instance of the structure)

► SA is documented by a number of views.SA is documented by a number of views.

Page 18: An Introduction to Software Architecture Software Engineering Lab

Categorization of StructuresCategorization of Structures

1.1. Module StructuresModule Structures

2.2. Component and Connector Component and Connector StructuresStructures

3.3. Allocation StructuresAllocation Structures

Page 19: An Introduction to Software Architecture Software Engineering Lab

1 Module Structures1 Module Structures

►Elements: Elements: modulesmodules (units of (units of implementation). Modules are a code based implementation). Modules are a code based way of considering the systemway of considering the system

►Specifies:Specifies: Functional responsibility of modulesFunctional responsibility of modules Other elements a module is allowed to useOther elements a module is allowed to use Generalization and specialization relations Generalization and specialization relations

►Run-time operation of software is not a Run-time operation of software is not a concern from this viewconcern from this view

Page 20: An Introduction to Software Architecture Software Engineering Lab

1.1 Decomposition 1.1 Decomposition StructureStructure

►Elements: modules in a Elements: modules in a hierarchyhierarchy►Relations: Relations: is a sub-module ofis a sub-module of,, shares shares

secret withsecret with

►Function Example:Function Example: Contributes to system's Contributes to system's modifiabilitymodifiability, by , by

ensuring that likely changes fall within ensuring that likely changes fall within the scope of at most a few small the scope of at most a few small modules.modules.

Page 21: An Introduction to Software Architecture Software Engineering Lab

1.2 Uses Structure1.2 Uses Structure

►Elements: Elements: modulesmodules, , proceduresprocedures, or , or resources on the interfacesresources on the interfaces of modules of modules

►Relations: Relations: uses: uses: one unit uses another one unit uses another if the correctness of the first requires if the correctness of the first requires the presence of a correct version (not the presence of a correct version (not a stub of) of the second.a stub of) of the second.

►Function Example:Function Example: Allows Allows incremental developmentincremental development

Page 22: An Introduction to Software Architecture Software Engineering Lab

1.3 Layered Structure1.3 Layered Structure

► Is a subclass of uses structureIs a subclass of uses structure► Elements: Elements: layerslayers: a coherent set of related : a coherent set of related

functionalityfunctionality► Relations: Relations: usesuses (ideally layer (ideally layer n n may only use may only use

the services of layer the services of layer n n – 1),– 1), provides provides abstraction toabstraction to

► Function Example: Function Example: Layers are often designed as Layers are often designed as abstractions abstractions ((virtual virtual

machinesmachines) that hide implementation specifics below ) that hide implementation specifics below from the layers above, engendering from the layers above, engendering portabilityportability..

Page 23: An Introduction to Software Architecture Software Engineering Lab

1.4 Class Structure1.4 Class Structure

►Elements: Elements: classesclasses►Relations: Relations: inherits frominherits from, , is an instance is an instance

ofof

►Function Example:Function Example: Allows us to reason about Allows us to reason about reusereuse and the and the

incremental addition of functionalityincremental addition of functionality

Page 24: An Introduction to Software Architecture Software Engineering Lab

2 Component and Connector 2 Component and Connector StructuresStructures

► Elements: Elements: run-time componentsrun-time components (principal units (principal units of computation) and of computation) and connectorsconnectors (communication (communication vehicle among components.)vehicle among components.)

► Specifies:Specifies: Major executing components and how they interactMajor executing components and how they interact Major shared data-storesMajor shared data-stores Which part of system is replicatedWhich part of system is replicated Flow of data through the systemFlow of data through the system What parts can run in parallelWhat parts can run in parallel How can system structure change as it executesHow can system structure change as it executes

Page 25: An Introduction to Software Architecture Software Engineering Lab

2.1 Process Structure2.1 Process Structure

►Elements: Elements: processesprocesses or or threadsthreads►Relations: Relations: attachment attachment (that allow (that allow

communication, synchronization, communication, synchronization, and/or exclusion operations)and/or exclusion operations)

►Function Example:Function Example: Engineering a system's execution Engineering a system's execution

performance and availability.performance and availability.

Page 26: An Introduction to Software Architecture Software Engineering Lab

2.2 Shared Data or Repository 2.2 Shared Data or Repository StructureStructure

►Elements: dataElements: data stores, stores, datadata producers, producers, and dataand data consumers consumers

►Relations: Relations: data-flowdata-flow

►Function Example:Function Example: To ensure good performance and data To ensure good performance and data

integrity.integrity.

Page 27: An Introduction to Software Architecture Software Engineering Lab

2.3 Client-Server Structure2.3 Client-Server Structure

►Elements: Elements: clientsclients and and serversservers►Relations: Relations: protocolsprotocols and and message message

passing infrastructurepassing infrastructure..

►Function Example:Function Example: Separation of concerns (supporting Separation of concerns (supporting

modifiability)modifiability) Load balancing (supporting runtime Load balancing (supporting runtime

performance)performance)

Page 28: An Introduction to Software Architecture Software Engineering Lab

3 Allocation Structures3 Allocation Structures

►Show the relationship between the Show the relationship between the software and the elements in one or more software and the elements in one or more external environment in which software is external environment in which software is created and executed.created and executed.

►Specifies:Specifies: The processor that executes each software The processor that executes each software

elementelement The file that stores each software element The file that stores each software element

during developmentduring development Assignments of software to development teamAssignments of software to development team

Page 29: An Introduction to Software Architecture Software Engineering Lab

3.1 Deployment Structure3.1 Deployment Structure

► Shows how software is assigned to hardwareShows how software is assigned to hardware► Elements:Elements: software software (usually a process from (usually a process from

a component and connector view), a component and connector view), hardware hardware entitiesentities, and , and communication pathwayscommunication pathways

► Relations: Relations: is-allocated-to is-allocated-to andand migrates-to migrates-to (for dynamic allocations)(for dynamic allocations)

► Function Example:Function Example: Allows reasoning about Allows reasoning about performanceperformance, , data data

integrityintegrity, , availabilityavailability, and , and securitysecurity..

Page 30: An Introduction to Software Architecture Software Engineering Lab

3.2 Implementation 3.2 Implementation StructureStructure

► Shows how software elements (usually Shows how software elements (usually modules) are mapped to the file structure(s) modules) are mapped to the file structure(s) in the system's development, integration, or in the system's development, integration, or configuration management environments.configuration management environments.

► Elements: any Elements: any logical unit logical unit (e.g. module)(e.g. module)► Relations: Relations: implemented inimplemented in

► Function Example:Function Example: management of development activities and build management of development activities and build

processprocess

Page 31: An Introduction to Software Architecture Software Engineering Lab

3.3 Work Assignment 3.3 Work Assignment StructureStructure

► Assigns responsibility for implementing and integrating Assigns responsibility for implementing and integrating the modules to the appropriate development teamsthe modules to the appropriate development teams

► Elements: any Elements: any logical unit logical unit (e.g. module)(e.g. module)► Relations: Relations: is assigned tois assigned to

► Function Example:Function Example: The architect will know the expertise required on The architect will know the expertise required on

each teameach team The means for factoring functional commonalities The means for factoring functional commonalities

and assigning them to a single team, rather than and assigning them to a single team, rather than having them implemented by everyone who needs having them implemented by everyone who needs them.them.

Page 32: An Introduction to Software Architecture Software Engineering Lab

NotesNotes

► Each structure is useful on its own right but Each structure is useful on its own right but not all structures are used in all projects.not all structures are used in all projects.

► Structures are not independent and must be Structures are not independent and must be considered togetherconsidered together e.g. relationship of modules with components e.g. relationship of modules with components

(many to many)(many to many) Some structures may be the same in some Some structures may be the same in some

systemssystems Some structures may be combined (e.g. all Some structures may be combined (e.g. all

component and connector structures may be component and connector structures may be combined in a single structure)combined in a single structure)

Page 33: An Introduction to Software Architecture Software Engineering Lab

4 + 1 View Model of 4 + 1 View Model of ArchitectureArchitecture

► Logical:Logical: objects and classes (a objects and classes (a module module view)view)► Process:Process: (a (a component and connectorcomponent and connector view) view)►Development:Development: modules, libraries, modules, libraries,

subsystems, and units of development (an subsystems, and units of development (an allocationallocation view) view)

► Physical:Physical: mapping of elements to hardware mapping of elements to hardware and communication (an and communication (an allocationallocation view) view)

► Scenarios (Use-cases) view is not itself Scenarios (Use-cases) view is not itself architectural.architectural.

Page 34: An Introduction to Software Architecture Software Engineering Lab

Quality AttributesQuality Attributes

Page 35: An Introduction to Software Architecture Software Engineering Lab

Traditional Classification of Traditional Classification of RequirementsRequirements

Functional Functional Non-Functional (Quality Attributes)Non-Functional (Quality Attributes)

A popular software A popular software mythmyth: first we build : first we build a software that satisfies functional a software that satisfies functional requirements, then we will add or requirements, then we will add or injectinject non-functional requirements to it. non-functional requirements to it.

• This idea leads to This idea leads to loss of resourcesloss of resources and and finally poor finally poor qualityquality..

• So we should So we should design for qualitiesdesign for qualities from from the very beginning (the very beginning (architecture levelarchitecture level).).

Page 36: An Introduction to Software Architecture Software Engineering Lab

Functionality and Functionality and ArchitectureArchitecture

►Functionality and quality attrs are Functionality and quality attrs are orthogonal orthogonal [in theory]. But not all [in theory]. But not all qualities are achievable to any level qualities are achievable to any level desired with any functionality.desired with any functionality.

►Functionality may be achieved in Functionality may be achieved in many ways (it is not so architectural.)many ways (it is not so architectural.)

►Architecture is a means of achieving Architecture is a means of achieving quality attributes by structuring quality attributes by structuring functionality into elements.functionality into elements.

Page 37: An Introduction to Software Architecture Software Engineering Lab

Architecture and QualitiesArchitecture and Qualities

►Achieving qualities must be considered Achieving qualities must be considered throughout design (including SA), throughout design (including SA), implementation, and deployment. implementation, and deployment.

►Qualities have both Qualities have both architectural architectural and and non-architecturalnon-architectural aspects. For example aspects. For example Performance: amount of Performance: amount of communication communication

among components vs. algorithms among components vs. algorithms

Page 38: An Introduction to Software Architecture Software Engineering Lab

Classification of Quality Classification of Quality AttributesAttributes

1.1. Qualities of the system: Qualities of the system: availability, modifiability, availability, modifiability, performance, security, testability, performance, security, testability, and usability.and usability.

2.2. Business qualities (such as time to Business qualities (such as time to market) that are affected by the market) that are affected by the architecture.architecture.

3.3. Architecture qualities, such as Architecture qualities, such as conceptual integrity.conceptual integrity.

Page 39: An Introduction to Software Architecture Software Engineering Lab

System Quality AttributesSystem Quality Attributes

►Availability Availability (related to (related to ReliabilityReliability))►ModifiabilityModifiability (includes (includes ProtabilityProtability and and

ReusabilityReusability,, Scalability Scalability) ) ►PerformancePerformance►SecuritySecurity►TestabilityTestability►Usability Usability (includes (includes Self-AdaptabilitySelf-Adaptability

and and User-AdaptabilityUser-Adaptability))

Page 40: An Introduction to Software Architecture Software Engineering Lab

Business QualitiesBusiness Qualities

►Time to marketTime to market►Cost and benefitCost and benefit►Predicted lifetime of the systemPredicted lifetime of the system►Targeted marketTargeted market►Rollout scheduleRollout schedule► Integration with legacy systemsIntegration with legacy systems

Page 41: An Introduction to Software Architecture Software Engineering Lab

Qualities of the ArchitectureQualities of the Architecture

►Conceptual IntegrityConceptual Integrity Conceptual integrity is the most important Conceptual integrity is the most important

consideration in system design. consideration in system design. It is better to It is better to have a system omit certain anomalous have a system omit certain anomalous features and improvements, but to reflect features and improvements, but to reflect one set of design ideas, than to have one one set of design ideas, than to have one that contains many good but independent that contains many good but independent and uncoordinated ideasand uncoordinated ideas. [. [Brooks 75Brooks 75]]

►Correctness and CompletenessCorrectness and Completeness►BuildabilityBuildability

Page 42: An Introduction to Software Architecture Software Engineering Lab

Achieving QualitiesAchieving Qualities

Page 43: An Introduction to Software Architecture Software Engineering Lab

The Whole StoryThe Whole Story

Tactics Selection

QualityRequirements

BusinessRequirements

Tactics Implementation:Design Patterns &

Architectural Patterns

Page 44: An Introduction to Software Architecture Software Engineering Lab

TacticsTactics

► A tactic is a A tactic is a design decisiondesign decision that influences a that influences a quality attributequality attribute. .

► e.g. using redundancy to increase availabilitye.g. using redundancy to increase availability► Tactics can be refined to other tactics to become Tactics can be refined to other tactics to become

more concrete; e.g. more concrete; e.g. redundancy: redundancy of redundancy: redundancy of data + processdata + process

Page 45: An Introduction to Software Architecture Software Engineering Lab

Availability Tactics Availability Tactics

Page 46: An Introduction to Software Architecture Software Engineering Lab

Modifiability TacticsModifiability Tactics

Page 47: An Introduction to Software Architecture Software Engineering Lab

PatternsPatterns► A pattern is a common abstract solution to A pattern is a common abstract solution to

a common abstract problem thata common abstract problem that Can be tailored to a given situationCan be tailored to a given situation Has predefined characteristicsHas predefined characteristics

► Abstraction level of patternsAbstraction level of patterns BusinessBusiness AnalysisAnalysis ArchitectureArchitecture DesignDesign Implementation (Idioms)Implementation (Idioms) Test Patterns (or guideline to testing patterns)Test Patterns (or guideline to testing patterns)

Page 48: An Introduction to Software Architecture Software Engineering Lab

Relationship of Tactics to Relationship of Tactics to Patterns Patterns

►An architect usually chooses a An architect usually chooses a pattern or a collection of patterns pattern or a collection of patterns designed to realize one or more designed to realize one or more tactics.tactics.

►However, each pattern implements However, each pattern implements multiple tactics, whether desired or multiple tactics, whether desired or not.not.

Page 49: An Introduction to Software Architecture Software Engineering Lab

Famous Pattern (Style) Famous Pattern (Style) categoriescategories

Data-centeredData-centered RepositoryRepository Blackboard (publisher-subscriber)Blackboard (publisher-subscriber)

► Structural solution to integrability of dataStructural solution to integrability of data► ScalabilityScalability►ModifiabilityModifiability

Client

Client Client

Client

Shared Data

Page 50: An Introduction to Software Architecture Software Engineering Lab

DataflowDataflow Bach sequentialBach sequential Pipes and filtersPipes and filters

► ReusabilityReusability►ModifiabilityModifiability►Not interactiveNot interactive► Poor performancePoor performance

Famous Pattern (Style) Famous Pattern (Style) categoriescategories

Page 51: An Introduction to Software Architecture Software Engineering Lab

Call and ReturnCall and Return Main program and sub-routineMain program and sub-routine

►ModifiabilityModifiability Remote procedure callRemote procedure call

►Performance tuningPerformance tuning Object-oriented or abstract data typeObject-oriented or abstract data type

►ModifiabilityModifiability►ReuseReuse

LayeredLayered►ModifiabilityModifiability►PortabilityPortability

Famous Pattern (Style) Famous Pattern (Style) categoriescategories

Page 52: An Introduction to Software Architecture Software Engineering Lab

Example: ATM SoftwareExample: ATM Software

Develop 3 different architectures for ATM Develop 3 different architectures for ATM software and compare them regarding software and compare them regarding fulfillment of quality attributes.fulfillment of quality attributes.

ATM = Automatic Teller MachineATM = Automatic Teller Machine

User operations:User operations: Insert card and enter PINInsert card and enter PIN Withdraw moneyWithdraw money Check BalanceCheck Balance

Page 53: An Introduction to Software Architecture Software Engineering Lab

Shared-Memory StyleShared-Memory Style

Page 54: An Introduction to Software Architecture Software Engineering Lab

Ab

stract D

ata

Typ

e

Ab

stract D

ata

Typ

e

Sty

leS

tyle

Page 55: An Introduction to Software Architecture Software Engineering Lab

Layere

d

Layere

d

Sty

leS

tyle

Page 56: An Introduction to Software Architecture Software Engineering Lab

Analysis and ComparisonAnalysis and Comparison

Shared-Shared-MemMem

ADTADT LayereLayeredd

PerformancePerformance 33 22 11

Change account record Change account record formatformat

11 33 33

New service: close account New service: close account and withdraw the remained and withdraw the remained balancebalance

11 22 33

PortabilityPortability 11 22 33

Availability and ReliabilityAvailability and Reliability 22 22 22

Buildability and IntegrabilityBuildability and Integrability 11 22 33

SumSum 99 1313 1515