Intro to Software Architecture - Software Engineering at...

J. Scott Hawker/R.Kuehl p. 1 Some material © Pearson EducationR I T

Software Engineering

Software Architecture Introduction



What is Architecture?

Vision and Structure



What is Software Architecture?



A Typical View of Software Architecture

“Components and Connectors”

“Overall structure of the system”

X

A B C



What’s Wrong with This Description?

Component meaning?

Task, process, module, object, program, function, library, processor, server, subsystem …?

Connector meaning?

Calls, invokes, signals, uses, data flow, subclass, runs with, excludes, co-located with, ….?

Overall structure meaning (boxes and lines)?

What is the significance of the topological layout?

Pattern?

Conclusion – the diagram is not the architecture but a starting point, one view



Definitions

Bass, Clements, Kazman p. 4;

“The software architecture of a system is the set of structures needed to reason about the system, which comprise software elements, relations among them, and properties of both.”

Martin Fowler in Patterns of Enterprise Application Architecture

“The highest-level breakdown of a system into its parts; the decisions that are hard to change; there are multiple architectures in a system; what is architecturally significant can change over a system's lifetime; and, in the end, architecture boils down to whatever the important stuff is.”

Fowler again (Who Needs an Architect? Martin Fowler 2003 IEEE SOFTWARE 3 DESIGN)

“…expert developers … have a shared understanding of the system design. This shared understanding is called ‘architecture.’ This understanding includes how the system is divided into components and how the components interact through interfaces.”



Another Definition

Philippe Kruchten, Grady Booch, Kurt Bittner, and Rich Reitman - based on work by Mary Shaw and David Garlan (Shaw and Garlan 1996)

“Software architecture encompasses the set of significant decisions about the organization of a software system including the selection of the structural elements and their interfaces by which the system is composed; behavior as specified in collaboration among those elements; composition of these structural and behavioral elements into larger subsystems; and an architectural style that guides this organization. Software architecture also involves functionality, usability, resilience, performance, reuse, comprehensibility, economic and technology

constraints, tradeoffs and aesthetic concerns.”

Real world analog examples of system

architecture – structure, elements,

properties, relationships?



Typical Software Architecture Diagram



Observations

Every system has a software architecture

Is it known, is it engineered?

Architectural anti-pattern: Big Ball of Mud

Architecture is a structural abstraction of (usually large) systems

Systems have many structural representations (views)

Components, connectors (interfaces)

No single view completely represents the architecture

Principles and guidelines governing designconformance and evolution are needed



Observations, continued

Architecture styles (patterns) - reoccurring reusable architecture designs

The underlying intuition or decision rationalebehind the pattern, or the system model

The kinds of components that are used in developing a system according to the pattern

The connectors, or kinds of interactions among the components

The control structure or execution discipline

From Mary Shaw, “Some Patterns for Software Architectures,” Pattern

Languages of Program Design, Vol 2, John Vlissides, James Coplien, Norman

Kerth (eds), Addison-Wesley 1996, pp. 255-269.

Example?

http://www.cs.cmu.edu/afs/cs/project/vit/www/paper_abstracts/PLoP95.html



Why is Architecture Important (Essential)?

1. Solution communication and consensus among stakeholders

2. Earliest and most fundamental design analysis and decisions Directs and constrains remaining software

development, deployment, and maintenance

Dictates structure of development organization

Enables early evolutionary prototyping

Enables more accurate cost and schedule estimation

3. Transferable (reusable) abstraction of a system Training - relatively small, intellectually

understandable model of the software system

Enables software product lines

Enables component reuse and integration, subsystem interoperability



What Makes a “Good” Architecture?Process Guidelines

Single architect or small group with identified leader

Based on validated business, functional, and non-functional (quality attributes) requirements

Actively reviewed and understood by stakeholders

“Evangelized”

Well-documented using understandable views

Incremental construction is enabled



What Makes a “Good” Architecture?Product (Structural) Guidelines

Well defined functional modules using information hiding, and separation of concerns

Encapsulates changeable aspects to facilitate change

Enables independent concurrent development by separate teams

Quality attributes achieved using well-known architectural patterns and tactics specific to each attribute

Limited dependencies on a particular technology or commercial product or tool



Account for the runtime environment (quality attributes)

Logical modules assigned to processes and tasks to accommodate real time, distributed, transactional, computational, parallel, etc. needs

Process assignment to processors easily changed

Small set of resource contention areas (memory, bandwidth, time, etc.)

Consistency – do the same things in the same ways

What Makes a “Good” Architecture?Product (Structural) Guidelines (cont)

What is a common theme? There is a planned structure based on

good design principles



Claims

Architecture design gives the highest return on investment (ROI) with respect to quality, schedule and cost

Relatively inexpensive to check and fix, upstream

Substantial downstream consequences

Conceptual integrity promotes sound system design that contributes to system success

Conceptual integrity can only be had by a small number of minds coming together to design the system’s architecture [Brooks]

Design decisions that are hard to change



The Benefit of Good Architecture

Value of reuse

Requirements DesignArchitecture Code

Cost of defects

Increase

Increase



Architecture or Design Work?

Architecture Design

Fitness for purpose – heuristic

analysis based on non-quantified

information

Engineering optimization - find

optimal solutions to well defined

problems

Architect’s role - make correct

inferences (general design

solution derived from specific

requirements)

Designers role – make correct

design decisions compliant to

the architecture (deduction)

Essentials dictated by needs Choices compatible with

architecture

Different architectures imply

different needs

Many different designs may

satisfy the same need

Roberto Rivera, Am I Doing Architecture or Design Work?, IT Professional, 12/2007



“Architecture” Terminology

Architecture pattern – description of element and relationship types, and a set of constraints on how they can be used; e.g., layered; design patterns are lower level

Architecture style – an architecture pattern (most authors)

Reference model – partition of functionality into parts with associated data flow between them; e.g., protocol stack

Reference architecture – reference model mapped onto software elements that implement the model

Framework – an architecture of reusable components for building applications in a particular domain; platform

Architecture framework – establishes common practices and resources for designing architectures for some (information) domain

System architecture – the architecture of holistic systems

Enterprise Architecture – the architecture of a business processes, organization, and information

Intro to Software Architecture - Software Engineering at...

Documents

Transcript of Intro to Software Architecture - Software Engineering at...