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)
Software Architecture
In this section, we look at the definition of software architecture, its rationale and whether
it is a science or an art
IntroductionIntroducing
Software Architecture
Architectural Patterns
Growing an Architecture ArchJava
Software Architecture
“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
Architectural Patterns
In this section, we look at well-documented, well-understood and “standardised” software architectures
and what properties they impose on systems built from them
IntroductionIntroducing
Software Architecture
Architectural Patterns
Growing an Architecture ArchJava
Architectural Patterns
❖ 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
Data Abstraction & Object-Orientation
❖ 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
Data Abstraction & Object-Orientation
❖ 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
Data Abstraction & Object-Orientation
❖ 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
Event-Based, or Implicit Invocations
❖ 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
Event-Based, or Implicit Invocations
❖ 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
Event-Based, or Implicit Invocations
❖ 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
Model-View-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
Model-View-Controller
❖ 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
Model-View-Controller
❖ 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
Service-Oriented Architectures
❖ 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
Service-Oriented Architectures
❖ 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
IntroductionIntroducing
Software Architecture
Architectural Patterns
Growing an Architecture ArchJava
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
Quantified Design Space
❖ 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
Quantified Design Space
82
Quantified Design Space
❖ 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
IntroductionIntroducing
Software Architecture
Architectural Patterns
Growing an Architecture ArchJava
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
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