Slide 1

Introduction toSoftware Architecture

TV Prabhakar

Slide 2

Antecedents of Software Architecture

Slide 3

What is Software Architecture?

• 150+ definitions• What are they?• Both a process and a product

Slide 4

Slide 5

Slide 6

Slide 7

Slide 8

Slide 9

Slide 10

What type of requirements drive architectural design?

Answer: Quality attribute requirements are the primary drivers for architecture design.

Do you agree?

Slide 11

Slide 12

Slide 13

Architecture and Functionality

• Functionality is largely orthogonal to quality attribute requirements.

• Functionality is the ability of a system to do the work it was intended to do.

• Systems are decomposed into elements to achieve a variety of purposes other than function.– Architectural choices promote certain

qualities as well as implement the desired functionality.

Slide 14

Effects of Architectural Decisionson Quality Attributes

The degree to which a system meets it’s quality attribute requirements is dependent on architectural decisions.

• A change in structure improving one quality often affects the other qualities.

• Architecture is critical to the realization of quality attributes.

• These product qualities should be designed into the• architecture.• Architecture can only permit, not guarantee, any

quality attribute.

Slide 15

Architecture-centric development?• Architecture-centric development involves

– Creating the business case for the system– Understanding the requirements– Creating or selecting the architecture– Documenting and communicating the

architecture– Analyzing or evaluating the architecture– Implementing the system based on the

architecture– Ensuring that the implementation conforms to

the architecture– Maintaining the architecture

The architecture must be both prescriptive and descriptive.

Slide 16

Slide 17

Slide 18

Slide 19

Slide 20

Slide 21

Slide 22

Attribute-Driven Design

• The Attribute-Driven Design (ADD) method, developed at the SEI, is an approach to defining a software architecture that bases the decomposition process on the quality attributes the software must fill.

• a recursive decomposition process where, at each stage in the decomposition, tactics and architectural patterns are chosen to satisfy a set of quality scenarios.

Slide 23

Slide 24

ADD Method's Inputs and Outputs

• Inputs– constraints– functional requirements– quality attribute requirements

• Outputs– first several levels of module decomposition– various other views of the system as

appropriate– set of elements for functionality and the

interactions among them

Slide 25

Architecture Documentation• Architecture documentation is important if

and only if communication of the architecture is important.– How can an architecture be used if it cannot

be understood?– How can it be understood if it cannot be

communicated?

• Documenting the architecture is the crowning step to creating it.

• Documentation speaks for the architect, today and 20 years from today.

Slide 26

Slide 27

Issues Addressed byan Architectural Design

• Gross decomposition of a system into interacting components– typically hierarchical– using rich abstractions for component interaction(or system “glue”)– often using common design idioms/styles

• Emergent system properties– performance, throughput, latencies– reliability, security, fault tolerance, evolvability

• Rationale and assignment of function to components– relates requirements and implementations

• Envelope of allowed change– “load-bearing walls”, limits of scalability and adaptation– design idioms and styles

Slide 28

Schools of Thought• 4 + 1 View• Zachmann Framework• RM - ODP• IEEE• OMG• TOGAF• Product Lines

Slide 29

4 + 1 view• Philips Kruchten, Rational Software, Architectural

Blueprints - The 4+1 View Model of Software Archtecture, IEEE Software, 1995

– Use case view– Logical view– Process view– Implementation view– Deployment view

Slide 30

4+1 view

Slide 31

What do the views do?

• logical view is the object model of the design (when an object-oriented design method is used),

• process view captures the concurrency and synchronization aspects of the design,

• physical view which describes the mapping(s) of the software onto the hardware and reflects its distributed aspect,

• development view describes the static organization of the software in its development environment

• illustrated by a few selected use cases, or scenarios

Slide 32

Taxonomy of Styles• Data Flow

– Batch Sequential– Dataflow Network(pipes & filters)

» acyclic, fanout, pipeline, Unix

– Closed loop control

• Call-and-return– Main program/subroutines– Information hiding(ADT, Object naïve

client/server)

Slide 33

Taxonomy..• Interacting Processes

– LW processes, distributed objects– Event systems

» implicit invocation, pure events

• Data-oriented repository– Transactional databases

» True client/server» Blackboard» Modern compiler

Slide 34

Taxonomy..• Data-sharing

– compound documents– Hypertext– Fortran COMMON– LW processes

• Hierarchical– Layered

» Interpreter

Slide 35

Slide 36

Slide 37

Slide 38

Slide 39

Slide 40

Architectural Styles• An architectural style consists of:

– component/connector types, topology– constraints on the topology and behavior– an informal description of the costs and benefits

of the style, e.g. “use the pipe and filter style when reuse is desired and performance is not a top priority”

Slide 41

Styles, Patterns and Idioms• POSA, Buschmann etal

• GOF

Slide 42

References• sei.cmu.edu• IEEE• OMG• POSA• GOF• WWISA• www.cetus-links.org• Bredemeyer.com