agile software architecturepeople.dsv.su.se/~beatrice/agile_and_iv1300/lectures/softarch.pdf · the...

AGILESoftware Architecture

Tobias [email protected]

Introduction

A bit about today

IntroductionIntroducing

Software Architecture

Architectural Patterns

Growing an Architecture ArchJava

My Inspiration for This Lecture

3

& articles(see last page)


In this section, we look at the definition of software architecture, its rationale and whether

it is a science or an art






“The decomposition of a system into a set of modules and interconnecting these modules”

“The description of elements from which systems are built, interactions among those elements, patterns that guide the composition, and constraints on these patterns” [1]

“…the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationship among them” [3]

“…deals with the design and implementation of the high-level structure of a software.” [6]

“ = { elements, form, rationale }” [8]

5

Examples

6

User Interface

Persistence Storage

Application-specific Functionality

Architecture pattern(3-tier)

Presentation

Catalogue

Shipment Selection

Customer Data

Cart

Reference model for on-line shopping

The Academic View

❖ A component-based development philosophy

❖ An architecture is a configuration of connected components

~ A component can be a module, a layer, etc.

~ A connection can be a method call, a stream, etc.

❖ A set of functional requirements can be met by several different architectures

~ These differ on the non-functional requirements

❖ We study

~ Re-occurring patterns in system architectures

~ Principles for such patterns

~ How different architectures facilitate different non-functional requirements

~ Tactics for selecting an architecture

~ Quality measurements of architectures

~ …

7

Rationale Behind the Field

❖ Managing software complexity

~ Is there a routine design for software construction?

~ Difficult to talk about and manage a solution without the proper abstraction

~ The need to reason about qualities of a system early in the construction phase

~ It turns out that large-scale structure is more important that choice of algorithms and data structures

~ …

8

The Basic Truths

❖ Proper design of architecture is crucial to fulfilling the non-functional requirements

~ A job well-done makes this possible,

~ but does not guarantee anything

❖ All non-functional requirements cannot be addressed by the software architecture

9

Art, Science, Craft, or Engineering Discipline?

10

…the only way to develop this skill is to servean apprenticeship with a proven practitioner.

Art or Science?

❖ An architecture is not inherently good or bad

❖ We can talk about how an architecture meets non-functional requirements

~ “-ilities”

~ Discussion is generally on a high-level

❖ Tools for architects

~ Guidelines

~ Abstractions

~ Lessons learned & heuristics

11

Four Popular Heuristics [10]

Don’t assume that the original statement of the problem is necessary the best, or even the right one

In partitioning, choose the elements so that they are as independent as possible (=low external and high internal complexity)

Simplify, simplify, simplify

Build in and maintain options as long as possible in the design and implementations of complex systems—you will need them

12

Heuristics for Technology-driven Systems [10]

In architecting a new program, all the serious mistakes are made in the first day

The most dangerous assumptions are the unstated ones

The choice between two systems may well depend upon which set of drawbacks the users can handle best

If you cannot understand the existing system, you can’t be sure that you are building a better one

Do the hard parts first

13

Heuristics for Software and Information Tech. Systems [10]

Programmers deliver the same number of lines of code per day regardless of the language they are writing in

Choose components so that each can be implemented independently of the internal implementation of all others

For high productivity, choose a language that is as close to the domain as possible

Software should be grown or evolved—not built

Personnel skill dominates all other factors in productivity and quality

Don’t fix bugs later, fix them now

14

The Second System Effect [13]

❖ Brooks discusses the “second system”

~ The system that you design after having finished the first (iteration)

~ You will be tempted to use all those side-tracks and ideas that came up during the design of the first

~ The general tendency is to over-design the second system— featuritis

~ This is only human

❖ When building the third etc. system, you will have learned the lesson from building the second system

~ Not as dangerous

15

A Line-and-Box Diagram is Not An Architecture!

❖ Its purpose is to be able to asses the level at which the system fulfils the non-functional requirements

~ How well does it scale?

~ How suitable is it for a real-time system?

❖ It should follow the standards

~ Easier to talk about with other people

~ Easier to compare designs

~ Easier to understand why a design was chosen

❖ Is should help in dictating organisational structure (as the basis for a work-breakdown-structure)

~ Forming teams for separate development

~ Units of planning, scheduling and budget

~ Frozen architectures are hard to change!

16

Routine Design:Shaw and Garlan’s Dream

~ (Please also read Richard P. Gabriel’s “Mob Software: The Erotic Life of Code” [2])

❖ Two types of design commonly found in other fields of engineering are

~ routine design, and

~ innovative design

❖ Routine design

~ Works for most projects

~ Its properties are well-understood

❖ Innovative design

~ A novel design for a specific problem

~ Not needed in most projects

17

Hands up, you who are tired of analogies between software construction and other engineering fields!

❖

Routine Design and Innovative Design

❖ Can these distinctions be made in the software industry as well?

~ Are there reoccurring properties in the projects you work on?

~ Could many of your projects explicitly reuse design lessons from previous projects?

❖ Would you agree to the following statements?

~ Many systems have been solved using innovative rather than routine designs

~ It should have been the other way around

~ One reason for this failure is that we are not good enough to “capture and organise” what we already know

❖ We should start our routine design projects off by selecting a suitable routine design?

~ Are we there yet?

18


In this section, we look at well-documented, well-understood and “standardised” software architectures

and what properties they impose on systems built from them






❖ A way to organise architectures and a vocabulary for discussing them

❖ Definition from Bass et al. [3]:

~ Description of element and relation types, together with a set of constraints on how they may be used.

~ Their components (elements) and connectors (constraints on interaction)

❖ Where do they come from?

~ Results from longitudinal studies of software; commonly reinvented wheels

~ Well-understood and “standardised”

~ Not necessarily best-practices

20

Examples of Common Architectural Styles

❖ Dataflow systems

~ batch sequential, pipes and filters

❖ Call-and-return systems

~ main program/subroutine, OO, FP, layered systems

❖ Independent components

~ communicating processes, event systems

❖ Virtual machines

~ interpreters, rule-based systems

❖ Data-centered systems/Repositories

~ databases, hypertext systems, blackboard systems

❖ Distributed

~ client-server, n-tier, peer-to-peer

21

Recap: Components

❖ A place of computation and state

~ Client

~ Server

~ Database

~ Filter

~ Layer

~ Abstract data type

~ …

❖ Can be simple or composite, active or passive

22

Key te

rm

Recap: Connectors

❖ An architectural element that model

~ Interactions between components

~ Rules for interactions between components

❖ Simple interactions

~ Procedure calls or method calls

~ Shared variable access

❖ Complex interactions

~ Client-server protocols

~ Database access protocols

~ Asynchronous events

~ Piped data streams

23

Key te

rm

A Brief Overview of Some Existing Architectural Patterns

24

Pipes and Filters

❖ Common properties

~ Each component has a set of inputs and outputs

~ A component reads streams of data on its input and writes transformed data on its output stream

~ Usually a logical transformation which allows output before all input is processed

❖ Components are called filters and connections between components are called pipes

25

F F F

F

Pipes and Filters

❖ Invariants of Pipes and Filters architectures:

~ All filters must be independent entities and not share state with others

~ Filters don’t know the identity of any upstream or downstream component

~ Output should not depend on the order in which the filters are applied to the data

❖ Example 1: UNIX’s line-oriented tools

~ ps aux | grep tobias | cut -b 1-15

~ ps aux | cut -b 1-15 | grep tobias

❖ Example 2: Compilers (e.g., lexical analysis ➳ parsing

➳ semantic analysis ➳ code generation)

26

Pipes and Filters

❖ Advantages

~ Simplicity—the designer can understand the overall I/O behaviour or a system as a simple behavioural composition of different filters

~ Ease of reuse—any filters that accept data of the same type can be connected together

~ Ease of maintenance and enhance—just add or replace a filter

~ Support for concurrency—each filter can run in its own process and execute in parallel (cf. functional programming languages)

27

Pipes and Filters

❖ Disadvantages

~ Not good for interactive applications or incremental updates

~ Complexity if filters have more than one incoming pipe (keep correspondence between incoming data)

~ May force a lowest common denominator on processed data (which may lead to bad performance)

28

Data Abstraction & Object-Orientation

❖ State and behaviour of a domain concept are encapsulated in a single entity (e.g., an object)

~ The building blocks are instances of abstract data types (objects are instances of classes)

~ Objects exchange messages (~procedure calls) that trigger certain actions

❖ Design guidelines for classes

~ An object is responsible for preserving the integrity of its representation (e.g., some class invariant)

~ An object’s implementation details should be hidden to the outside world (this is a means to the above)

29


❖ Parnas’ famous principle [4]:

~ One must provide the intended user with all the information necessary to use the module correctly, and nothing more.

~ One must provide the implementer with all the information necessary to complete the module, and nothing more.

30


❖ Advantages

~ An object’s implementation can be updated without changing of the rest of the program

~ A design is easily decomposed into a “set of interacting agents”

~ Provides a higher level of abstraction than pure procedural decomposition

31


❖ Disadvantages

~ Objects must know the identity of each other to interact—changing identity of an object might require propagating changes

~ Aliasing—sharing might have unexpected side effects on sharers

~ Sometimes too low-level to be a “high-level design”

32

Event-Based, or Implicit Invocations

❖ Instead of directly invoking a procedure, a component broadcasts one or more events

~ Components may register themselves as interested in an event by associating a procedure (etc.) with it

~ An event implicitly invokes all procedures associated with it in some order

~ Can be combined with other architectural styles, e.g., object-orientation

33

Event Manager

C C C

C C


❖ Invariants of event-based architectures

~ A component does not know what (if any) other components are interested in an event

~ A component cannot make any assumptions about the order the events are processed in

~ A component cannot make any assumptions about what the results of broadcasting an event might be

34


❖ Advantages

~ Ease of reuse—low coupling between components allow reuse of one part without “propagating inclusion”

~ Ease of extendibility—A component can be introduced into a system by just registering for (some of) its events

~ Ease of maintenance—components may be replaced by others that respond to and generate the same events

35


❖ Disadvantages

~ Implicit control relinquishes control over system behaviour

~ Lack of assumptions may sometimes prove too hard

~ Cannot rely on an event being processed in a particular order

~ Global performance and resource management can become critical depending on how data is shared between components (copying, shared repository, etc.)

~ Reasoning about correctness or functional behaviour of a system becomes hard, since there are (for example) no pre and post conditions

36

Layered Systems

❖ The system is partitioned into layers, each layer providing services to the above layer, and acting as a client to the layer below

~ In some systems, layers are hidden to all but the adjacent outer layer—virtual machine

~ Connectors between layers are usually procedure calls

❖ Example: OSI network model (7 layers)

~ Application, Presentation, Session, Transport, Network, Data link, Physical

37

ApplicationBase util.Core

Useful systems

Basic utils

Module or equivalent

Layered Systems

❖ Invariants of layered systems

~ Strictly layered

~ Non-strictly layered

❖ Strictly layered systems: only downwards dependencies

~ Bottom layer is self-contained (=stable)

~ Top layer is built on a stack of dependent layers (=less stable that all other layers)

~ Minimises dependencies between layers (only one per layer)

❖ Non-strictly layered

~ Neighbouring principles are important—inter-layer communication must be carefully done so as not to reduce the system into a graph

38

Layered Systems

❖ Advantages

~ Supports design based on increasing level of abstraction (e.g, can develop as incremental steps)

~ Facilitates enhancement—changes are localised (or do not propagate far)

~ Facilitates reuse or substitution of entire layers (allows defining standard layer definitions with open implementation)

39

Layered Systems

❖ Disadvantages

~ Not all systems are easily structured into a set of layers

~ Forcing a layered architecture when not suitable may have performance issues or create a strong coupling between low-level functions and their high-level implementation

~ Finding the right levels of abstraction is tricky

~ Hard to scale down

40

Repositories

❖ Two kinds of components

~ Central data structure—current state

~ Collection of independent components that operates on the central data

❖ Central data can be a database or a blackboard

~ Closely related to how processes are triggered

❖ Commonly used for speech and pattern recognition, but also (incremental) compilers

41

Blackboard (shared data)

Data access

Computational entity

Repositories

❖ Advantages

~ Components are loosely coupled

~ Components can be added to the system independent of each other

~ Suitable for modelling co-operating systems

❖ Disadvantages

~ Representation differences cause problems

~ Hard to build a system that determines what component to trigger on what data

~ Problem with co-ordinating independent processes

~ Hard to co-ordinate multiple writes to the same part of the repository

42

Model-View-Controller

❖ A well-known architecture originated from Smalltalk in the 80’s for building GUI applications

~ Three kinds of components: model, view, and controller

~ Model objects are data objects and “business rules”

~ View objects are GUI objects that presents the model in some format to the user

~ Controller objects co-ordinate model and view and represent mouse and keyboard events

❖ Most OO GUI frameworks encourage MVC separation (e.g., MFC, Cocoa, AWT, Swing)

43

Interface

ModelView

Controller


❖ Invariants in MVC separation

~ Changes to the model are notified using a publish/subscriber technique (event-based)

~ The model is a publisher and unaware of its subscribers

~ The model provides a set of interfaces through which changes can be initiated

~ Controller and view objects subscribe to changes in the model

~ Mixing view and controller logic in a single object is bad practice

❖ Note that MVC is not specific to OO

44


❖ Benefits of MVC separation

~ Allows for separate development of presentation and model

~ Allows model and GUI to change invariantly

~ Allows multiple views of a single model (e.g., a web view and a regular application view)

~ Changing the way a user event is handled without changing logic in the presentation (even at run-time)

~ Allows executing the model without the GUI (good for testing or batch-mode processing)

45


❖ Downsides to MVC separation

~ No guidelines for modularising different requirements in a single application

~ Might be hard to navigate a sea of controllers

~ The model layer may become too big, or too coupled with logic for e.g., loading and storing data

46

PCMEF Separation

❖ Has four layers

❖ An extended version of MVC

~ Presentation (GUI objects)

~ Control (objects handling user interactions)

~ Entity (handles control layer requests, business objects)

~ Mediator (mediates between entity and foundation objects)

~ Foundation (handles persistent data; interacts with storage, data-bases, web services, etc.

❖ Foundation and mediator are not in MVC

47

Presentation

Control

Foundation

MediatorEntity

Dependency

PCMEF Separation

❖ PCMEF design principles

~ Downward dependency

~ Upward notification

~ Neighbour communication

~ Explicit association

~ Cycle elimination

~ (Class) naming

~ Acquaintance package

48

Presentation

Control

Foundation

MediatorEntity

Client-Server Architectures

❖ Decomposition into a set of services with associated servers and clients

~ Servers offering services

~ Clients accessing services (possibly concurrently)

~ Network that allows the connections (not strictly necessary, but standard)

❖ Thin or fat client?

~ Thin client—client only does presentation

~ Fat client—server only manages data

49

S1 S2

C1

C3

C5

C2

C4

C6

Client-Server Architectures

❖ Advantages

~ Easy to add and integrate a new service with an existing system

~ Easier to upgrade a service transparently than with a non-distributed architecture

❖ Disadvantages

~ Changes to servers may require changes to clients

~ Mapping of three layers onto two—presentation, logic and data storage onto clients and servers

~ Thin client—high load on server and network (scalability issues)

~ Fat client—more expensive and complex to update and manage clients

50

3-Tier Architectures

❖ Similar to layered style and MVC style

❖ The application is partitioned into separate modules—tiers—often on different platforms

~ Presentation

~ Business Logic

~ Data storage

❖ Invariants

~ Don’t mix contents for different tiers

❖ Can be scaled to n-tier, with additional flexibility and scalability, but also complexity and network load

51

3-Tier Architectures

❖ Advantages

~ Scalability—add more machines to distribute load (additional improvement over 2-tier systems)

~ Flexibility and extendibility—low coupling between the different modules

❖ Disadvantages

~ More complex to build and deploy

~ Cost of sending data between the machines

~ Hard to make distribution transparent if you want performance

~ Some claim testing is harder because more different machines need interact

52

Service-Oriented Architectures

❖ A blend of many architectures, e.g., client-server

~ Distributed services that register themselves in one or more registries

~ Ideally, applications are just chains of uses of services

~ Services and clients share a common context that facilitates infrastructure operations

❖ User credentials exchange

❖ Global transactions

❖ …

53

Service registry

Service provider

Client

find publish

bind


❖ Invariants

~ Services should not depend on the state of other functions or processes

~ Services should acquire all information needed to process a request from the request itself

~ The relationship between a service provider and consumer is dynamic

54

http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=soa-rm


❖ Advantages

~ Can integrate services from many sources and providers

~ Can delay binding of services until execution time

~ Add, upgrade and replace services (fairly) transparently and add redundant servers

❖ Good scalability, flexibility and manageability, availability

~ Natural separation of concerns

❖ Disadvantages

~ High network load (performance)

~ Might require redundancy

~ Complex to manage—bad manageability

55

Selecting the Right Software Architecture

In this section we look at ways to determine what type of architecture to select for a

set of requirements as well as spread-sheet models for structuring this decision process





Issues in Decomposition

❖ How do we arrive at components, connectors and a configuration for them?

❖ What is the adequate level of granularity?

❖ What constraints on components are imposed by non-functional requirements?

~ “-ilities”

~ Predicted system evolution

~ System scale

~ Computing environment

~ Customers and users

❖ What assumptions can one component make about another?

57

Issues in Decomposition

❖ How will the components interact?

❖ What are the connectors in the system?

❖ What are the roles of the connectors?

~ Mediation

~ Co-ordination

~ Communication

❖ What kinds of connectors are there?

~ Type of interaction

~ Level of parallelism

~ Extent of information exchange

❖ Questions are good, but we need guidelines!

58

Ways of Selecting an Architecture

❖ Process-driven

~ Broad scope

~ Tailorable

~ Dynamic

~ Generality vs. practical usefulness

❖ Checklist-driven

~ Domain-specific

~ Static

~ Practical

59

Process-Driven:“Object-Orientation”

❖ Guided by the problem domain rather than a solution

~ Problem domain is a set of interacting entities (objects)

~ Every object belongs to a family of objects (classes)

~ Object families may share attributes or behaviour (inheritance)

❖ Objects are combined to form the application that solves the problem

60

OO

Object-Oriented Design

❖ How to go from problem description to an object-oriented design

~ Identify the objects in the problem domain

~ Specify state, behaviour and interface for each object

~ Locate existing classes or implement new ones for the object families

~ Object composition is derived from object relationships in the problem domain

61

OO

Process-Driven: “4+1”

❖ Due to Philippe Kruchen [6]

~ Is now a fundamental piece of the Unified Process (variances apply)

~ Four views: Logical, Process, Development, and Physical + Scenarios (key use cases)

62

4+1

Logical View Development view

Process view Physical view

Scenarios

End-user Functionality

ProgrammersSoftware management

IntegratorsPerformance

Scalability

System engineersTopologyCommunication

Logical Architecture

❖ Primarily supports functional requirements

❖ Key abstractions from the problem domain

❖ Kruchten suggests use of object-oriented architectural styles for this view of the system

63

4+1

Process Architecture

❖ Considers non-functional requirements

~ performance, availability, concurrency, distribution, integrity, fault tolerance and how the key abstractions from the logical view fits into the process architecture

❖ Can be described at several levels of abstraction

~ e.g., describe the system as a set of individually executing, communicating programs

❖ Partition the software into a set of tasks

~ A task is an independent thread of control

~ Major tasks that are architectural elements

~ Minor tasks that are introduced locally for implementation reasons

❖ Kruchten suggests e.g., Pipes-and-filters or client-server architectural styles for this view

64

4+1

Development Architecture

❖ Focuses on the actual software module organisation on the software development environment.

~ Partitioning, grouping and visibility are key constraints that govern this activity

~ Takes into account internal requirements related to the ease of development, software management, reuse or commonality, and to the constraints imposed by the toolset, or the programming language.

~ Partition the software into subsystems that can be developed by small teams

~ The subsystems should be layered

65

4+1

Physical Architecture

❖ Primarily considers the system’s non-functional requirements

~ availability, reliability (fault-tolerance), performance (throughput), and scalability

~ The elements of the system (processes, tasks and objects) are mapped to hardware nodes

~ Different mappings are likely at different phases of development (e.g., testing and deployment)—thus, the mapping must be flexible

66

4+1

Scenarios

❖ Key use-cases for the most important requirements

~ Information in the scenarios are redundant with the four other views

❖ Scenarios are important

~ for validation after the architecture design is complete

~ as the starting point for the tests of an architectural prototype

~ as a driver to discover the architectural elements during the architecture design

67

4+1

❖ Prototype, test, measure, analyse and refine the architecture in subsequent iterations

~ Choose key scenarios based on risk and criticality

~ Build a straw-man architecture, and use the scenarios to identify classes, mechanisms, processes and subsystems

~ Map the architectural elements from above to the four views

~ Implement, test, analyse and enhance the architecture, and capture lessons learned

❖ Continues on next slide!

68

4+1

“Iterative Architecting” with 4+1 Scenarios

“Iterative Architecting” with 4+1 Scenarios (cont’d)

❖ Now, the loop

~ Re-asses risks and extend set of key scenarios

~ Add to original architecture, and make necessary changes; update the four views

~ Revise old scenarios based on these changes

~ Upgrade the implementation

~ Test; measure under load in real target environment if possible

~ Review all four views + scenarios to detect possible simplification, reuse, etc.

~ Update design guidelines

~ Start over, from top of this slide until done

69

4+1

Checklist-driven:“Design Spaces”

❖ “A means of codifying software design knowledge for use in day-to-day practice” [1]

❖ Attacks the problem of organising software design knowledge to create routine design methods

❖ Several other benefits

~ Aids in understanding someone else’s design choices (good for e.g., maintenance)

~ Good for training designers (it is structured)

~ Helps developers to go from a high-level functional design to a software architecture

~ Aids in rejecting bad designs early, even when it cannot be used to create a design

❖ Deals with both functional requirements and system structure

70

Design

Spac

es

0

1

2

3

4

Messages Semaphores Monitors Rendezvous Other None

Fast

Medium

Slow

The Notion of Design Spaces

❖ Although the above image is a bit contrived, it communicates the essence of a design space

~ Each dimension describes variation in one system characteristic or design choice

~ Shows correlation between them

71

Design

Spac

es

Response time—Interprocess synchronisation mechanism

Dimensions of the Design Space

❖ Functional

~ Describe functional or performance requirements

~ Stem from analysis and gross functional design

❖ Structural

~ Describes structural choices

~ Stem from system decomposition

❖ Note

~ Dimensions are not continuous, nor need they posses any useful metric

~ Structural dimension commonly comprised of discrete values, that may not have a meaningful ordering (x-axis on previous page)

72

Design

Spac

es

The Notion ofDesign Spaces

❖ Example structural dimensions

~ Communication (events, state, both, …)

~ Control flow (single or multi thread, multi process, …)

❖ Look for correlation and use that to guide design choices

~ Some choices are more likely to meet functional requirements than others

~ Some choices are mutually exclusive

73

Design

Spac

es

Design Spaces

❖ Aids in understanding someone else’s design choices (good for maintenance)

~ Repeatability (routine design) vs. optimality (innovative resign)

❖ This idea is not new, similar constructs exist for lower-level design decisions

~ Choosing an algorithm (based on speed, memory, scalability, etc.)

~ Choosing a data structure for representing certain kinds of data layout

74

Design

Spac

es

Rules for Design Spaces

❖ Most rules say that a choice in one dimension favours certain choices in another dimension

~ Strength of such correlation will vary

~ The designer’s task is to consider them all and make a choice according to the “evidence”

~ Positive or negative weights is a standard way of expressing rules like this

❖ Two categories of rules

~ Linking functional to structural dimensions—allows requirements to drive design

~ Interconnecting structural dimensions—facilitates keeping the design consistent

~ Satisfying all the rules can be complex

75

Design

Rules

Example: Rules for User-Interface Architectures

❖ See [7] for the full example; around 170 design rules. (Rules here are abbreviated.)

❖ Examples of rules that relate functional to structural dimensions:

~ If external event-handling requires pre-emption of user commands, then a pre-emptive control-thread mechanism is favoured, or severe user constraints must be placed all over to guarantee response time

~ A distributed system organisation favours event-based communication. State-based communication requires shared memory, which is expensive in a distributed setting

~ Portability favours event-based or pure state-based communication over hybrid forms as hybrids are normally tuned to particular communication patterns, which might change when an application is ported

76

Design

Rules

Quantified Design Space

❖ Analyse and compare designs in a specific application domain

~ “A structured encapsulation of design knowledge” [1]

~ Spreadsheet-driven, for designers

~ Extends the design space concept with Quality function deployment

❖ Rules are described as positive or negative weights

~ We can calculate a score (sum of weights) for a set of design choices

~ Allows formal comparison between two different designs

77

78

Sample QFD chartQFD

Quality Function Deployment

❖ QA technique for translating customer needs into technical requirements

~ In use since 1977

~ Supported by a specific graphical notation

❖ The QFD produces a correlation matrix

~ Recruit representatives for all stake-holders to a QFD team

~ Identify requirements R and enter them into the left column of QDF chart

~ Identify mechanisms M that will meet the requirements and enter them in the top row of the QFD chart

~ Establish target values (either qualitative or quantitative) for each mechanism in the bottom row of the chart

~ Record relationships between each R and M (using symbols, blank means there is none)

79

QFD

Quality Function Deployment

❖ Continues from previous slide

~ Determine positive or negative correlation between the realisation mechanisms, record them in the “roof” of the chart

~ Asses difficulty of implementing each mechanism based on strengths and weaknesses in the organisation

~ Calculate technical importance by multiplying customer weight for some R by the relationship factor for each M

~ Analyse and select—a negative correlation may be assessed using prototyping

❖ Our example here is from [1]

80

QFD


❖ Rules are indicated by weights

~ Designers determine the weights

~ No automatic process, but a good framework

81

Concepts Customer weight

Functional #1 Functional #2 Functional #3Alt#1 Alt#2 Alt#3 Alt#1 Alt#2 Alt#3 Alt#1 Alt#2 Alt#3

Requirement #1 10 1 9 0 9 3 1 0 0 0Requirement #2 9 3 1 0 3 0 3 3 3 9Requirement #3 2 1 3 0 3 0 0 1 1 3Requirement #4 8 3 3 1 9 1 3 1 1 3Calculated weight 63 129 8 195 38 61 37 37 111

Requirement #1 10 90 0 90 30 10 0 0 0Requirement #2 27 9 0 27 0 27 27 27 81Requirement #3 2 6 0 6 0 0 2 2 6Requirement #4 24 24 8 72 8 24 8 8 24

Design decision 1 1 1Effective weight 0 129 0 195 0 0 0 0 111


82


❖ QDS can be implemented on a spreadsheet

~ Allows interactive investigations of design choices

~ Cross-design score comparison is not possible

~ Proven to work in real projects

❖ It is important to document rules and rationale for selecting weights

~ Allows others to review design choices

~ Good to have when requirements change

~ Good tool to improve the result of working with QDS over time

❖ Downsides

~ Cannot handle more than two-way relationships

~ No “roof” for correlating functional alternatives

83

Enforcing Architecture through

Programming Languages

In this section we briefly look at the ArchJavacompiler, that allows programmers to specify and

statically check architectural constrains in a high-level language





ArchJava

❖ ArchJava [9] is a research language developed by Jonathan Aldrich at CMU

~ Can be used to statically infer from code that the system follows a certain architectural specification

~ First-class components and connectors

~ Uses a “strong” encapsulation mechanism to confine components

~ Components can only communicate through connections that are declared in the architecture—thus, architecture knowledge gets encoded in the written program

85

http://www.archjava.org/

GraphicsPipeline

A Pipeline Architecture

86

Generate Transform Rasterize

out in out in

❖ A graphics pipeline that applies filters to a dot-matrix image

❖ Constraints we want to enforce

~ No shared state between filters

~ No shared data between filters

~ Components organised in a linear fashion

A Pipeline Architecture

87

4

ship domains, and ownership domains can be shared along connections, permitting the connected components to communicate through shared data. This section introduces these concepts through two example architectures.

3.1. Example: Pipeline Architecture

Figure 3 shows the architecture of a simple graphics pipe-line. The generate component stores the current scene and generates shapes to be displayed. These shapes are passed on to the transform component, which stores the current transformation and applies it to each shape in turn. It then passes the shapes on to the rasterize component to be displayed.

We want to enforce two architectural invariants that are important to the pipeline architectural style [GS93]. First, the components are arranged in a linear sequence, with each component getting information from its predecessor and sending it on to its successor. Second, no data is shared between components; instead, shapes are handed

off from one component to another. As the ArchJava lan-guage is introduced through this example, we will discuss how these invariants are specified and enforced.

3.2. Components and the Ownership Hierarchy

A component in ArchJava is a special kind of object whose communication patterns are declared explicitly using architectural declarations. Component code is de-fined in ArchJava using component classes. Figure 3 shows the code that defines the GraphicsPipeline and Transform component classes. We assume that Generate and Rasterize are component classes de-fined elsewhere, and Trans3D and Shape are ordinary classes that are not part of the architecture.

The GraphicsPipeline class contains three fields, one for each component in the pipeline. The fields types are annotated with the implicit ownership domain owned, meaning that generate, transform, and raster-ize are subcomponents of the GraphicsPipeline component instance that owns them.

3.3. Ports and Unique Data

Components communicate through explicitly declared ports. A port is a communication endpoint declared by a component. For example, the Transform component class declares an in port that receives incoming shapes and an out port that passes transformed shapes on to the next component.

Each port declares a set of required and provided methods. A provided method is implemented by the com-ponent and is available to be called by other components connected to this port. Conversely, each required method is provided by some other component connected to this port. Each provided method must be implemented inside the component. For example, the draw method’s imple-mentation transforms its shape argument and then calls the required method draw on the out port. As the example shows, a component can invoke one of its required meth-ods by sending a message to the port that defines the re-quired method.

Annotating the Shape objects as unique enforces the architectural invariant that shapes are handed off from one component to another. ArchJava’s type system en-sures that no component may retain a reference to a shape after it passes it on to the next component. This invariant allows the developers of each component to assume they have exclusive access to the shape they are manipulating.

3.4. Connections and Connect Patterns

ArchJava requires developers to declare in the architec-ture the connection patterns that are permitted at run time. The declaration connect pattern Gener-ate.out, Transform.in permits the graphics pipe-line component to make connections between the out port of its Generate subcomponents and the in port of its Transform subcomponents. The connect patterns declared in GraphicsPipeline constrain its subcom-

GraphicsPipeline out in out in

transform rasterize generate

public component class GraphicsPipeline {

protected owned Generate generate = ... ;

protected owned Transform transform = ... ;

protected owned Rasterize rasterize = ... ; connect pattern Generate.out, Transform.in;

connect pattern Transform.out, Rasterize.in; public GraphicsPipeline() {

connect(generate.out, transform.in);

connect(transform.out, rasterize.in); } } public component class Transform {

protected owned Trans3D currentTransform; public port in {

provides void draw(unique Shape s); } public port out {

requires void draw(unique Shape s); } void draw(unique Shape s) { currentTransform.apply(s); out.draw(s); } }

Figure 3. The architectural specification of a graphics pipeline in ArchJava. GraphicsPipeline is made up of

three subcomponents: the Generator generates shapes,

which are transformed by Transform and then displayed

by Rasterize. The Transform component accepts a

unique Shape on its in port, transforms it according to

the current transformation, and passes it on through the out port.

ArchJava Code Explained

❖ Added concepts:

~ Component classes

~ Connector ports

~ Ownership prevents encapsulation breaches

~ Unique values prevent incidental sharing

❖ Ports

~ Not possible to connect components other than through ports

~ Provided are there to call

~ Required must be at other end of port

88

The ArchJava Communication Integrity

Invariant

❖ Communication can only occur to

~ Unique object

~ To objects deeper nested within a component

~ Through ports

~ Through objects in domains that are explicitly linked in the architecture

89

Wrapping Up

Concluding Remarks

❖ Conscious thinking about software architectures is important

❖ Architectural patterns are useful and a good starting point—state of the art today

~ They make it easier for developers to understand other developers’ programs

~ They facilitates reuse of knowledge about a certain architecture’s different properties

❖ Selecting a software architecture is not straightforward

~ Many issues to consider

~ Methods may help, but cannot give a single answer

~ Experience and codifying experience is the only way to learn how to do it

~ However, patterns and heuristics is a good start

91

End of Today’s Lecture

Thanks for your attention!

References

1. Mary Shaw and David Garlan, Software Architecture—Perspectives on an Emerging Discipline, Prentice Hall, 1996.

2. Richard P. Gabriel and Ron Goldman, Mob Software: The Erotic Life of Code, keynote at OOPSLA 2000. (Available online at http://www.dreamsongs.com/MobSoftware.html)

3. Len Bass, Paul Clements and Rick Kazman, Software Architecture in Practice, Pearson Eduction 2003.

4. David L. Parnas, On the criteria for decomposing a system into modules, Communications of the ACM, 15(12), December 1972, pp. 1053–1058, 1972. (Available online at http://www.acm.org/classics/may96/)

5. Design Patterns in Dynamic Programming, Peter Norvig, Harlequin Inc. Presentation.

6. Philippe Kruchten, Architectural Blueprints—The “4+1” View Model of Software Architecture, IEEE Software 12(6) November 1995.

7. Thomas G. Lane, User Interface Software Structures, Ph.D. thesis, Carnegie Mellon University, May 1990.

8. Dewayne Perry and Alexande Wolf, Foundations for the Study of Software Architecture, ACM SIGSOFT Software Engineerings Notes 17(4), 1992.

9. Jonathan Aldrich, Using Types to Enforce Architectural Structure, Ph.D. thesis, Carnegie Mellon University, 2003.

93

http://www.dreamsongs.com/MobSoftware.html

http://www.dreamsongs.com/MobSoftware.html

References

10. Mark W. Maier, Eberhardt Rechtin, The Art of Systems Architecting, CRC Press, 2002

11. Jan Bosch, Design & Use of Software Architectures—Adopting and evolving a product-line approach, Addison-Wesley, 2000

12. Tom DeMarco and Timothy Lister, Waltzing with Bears—Managing Risk on Software Projects, Dorset House, 2003

13. Fred P. Brooks Jr., The Mythical Man-Month (anniversary edition), Addison-Wesley, 1995

94

agile software architecturepeople.dsv.su.se/~beatrice/agile_and_iv1300/lectures/softarch.pdf · the...

Documents