Documente Academic
Documente Profesional
Documente Cultură
Overview
What is it, why bother? Architecture Design Viewpoints and view models Architectural styles Architecture asssessment Role of the software architect
visualises
prescribes
appearance, behaviour
architectural design
construction, co-operation
stakeholders (few)
requirements
quality
agreement
development
Characteristics
Iteration mainly on functional requirements Few stakeholders involved No balancing of functional and quality requirements
stakeholders (few)
requirements
quality
requirements
quality
Characteristics
Iteration on both functional and quality requirements Many stakeholders involved Balancing of functional and quality requirements
10
11
Software Architecture
statement procedure module (design) pattern architecture
12
13
Software Architecture
Important issues raised in this definition:
multiple system structures; externally visible (observable) properties of components.
14
Architectural Structures
module structure conceptual, or logical structure process, or coordination structure physical structure uses structure calls structure data flow control flow class structure
15
16
Software Architecture
Architecture is conceptual. Architecture is about fundamental things. Architecture exists in some context.
17
18
19
Overview
What is it, why bother? Architecture Design Viewpoints and view models Architectural styles Architecture asssessment Role of the software architect
20
Repeat steps
21
22
Generalized model
Understand problem Solve it Evaluate solution
23
backlog requirements
24
backlog
constraints
evaluation
25
26
Taking decisions
subproblem (or issue)
Design problem
subproblem (or issue)
Problem space
Design option
Design option
Decision = best option
Decision space
Alternative solutions
Alternative solutions
27
Decision space
The space of possible designs that can be achieved by choosing different sets of alternatives.
fat-client client style client-server thin-client client in a separate user interface layer Programmed in Java
monolithic
28
Tree or graph?
Issues and options are not independent ...
flexibility
layered
MVC
monolithic
29
versus
Management deciding on new strategic partnership
or
Management deciding on budget
30
31
Types of decisions
Implicit, undocumented
Unaware, tacit, of course knowledge
Explicit, undocumented
Vaporizes over time
Explicit, documented
Preferred, exceptional situation
32
33
Evaluate impact
If we want to change an element, what are the elements impacted (decisions, design, issues)? ..., Cleanup the architecture, identify important architectural drivers
34
35
36
Overview
What is it, why bother? Architecture Design Viewpoints and view models Architectural styles Architecture asssessment Role of the software architect
37
38
39
40
41
Well-written OO programs exhibit recurring structures that promote abstraction, flexibility, modularity, & elegance
: Client
operation()
Object : Interface X
Middleware
Objectives
To explain that CBSE is concerned with developing standardised components and composing these into applications To describe components and component models To show the principal activities in the CBSE process To discuss approaches to component composition and problems that may arise
Topics covered
Components and component models The CBSE process Component composition
Component-based development
Component-based software engineering (CBSE) is an approach to software development that relies on software reuse. It emerged from the failure of object-oriented development to support effective reuse. Single object classes are too detailed and specific. Components are more abstract than object classes and can be considered to be stand-alone service providers.
CBSE essentials
Independent components specified by their interfaces. Component standards to facilitate component integration. Middleware that provides support for component inter-operability. A development process that is geared to reuse.
CBSE problems
Component trustworthiness - how can a component with no available source code be trusted? Component certification - who will certify the quality of components? Emergent property prediction - how can the emergent properties of component compositions be predicted? Requirements trade-offs - how do we do trade-off analysis between the features of one component and another?
Components
Components provide a service without regard to where the component is executing or its programming language
A component is an independent executable entity that can be made up of one or more executable objects; The component interface is published and all interactions are through the published interface;
Component definitions
Councill and Heinmann:
A software component is a software element that conforms to a component model and can be independently deployed and composed without modification according to a composition standard.
Szyperski:
A software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third-parties.
Component characteristics 1
Standardised Component standardisation means that a component that is used in a CBSE process has to conform to some standardised component model. This model may define component interfaces, component meta-data, documentation, composition and deployment. A component should be independent it should be possible to compose and deploy it without having to use other specific components. In situations where the component needs externally provided services, these should be explicitly set out in a requires interface specification. For a component to be composable, all external interactions must take place through publicly defined interfaces. In addition, it must provide external access to information about itself such as its methods and attributes.
Independent
Composable
Component characteristics 2
Deployable
To be deployable, a component has to be self-contained and must be able to operate as a stand-alone entity on some component platform that implements the component model. This usually means that the component is a binary component that does not have to be compiled before it is deployed. Components have to be fully documented so that potential users of the component can decide whether or not they meet their needs. The syntax and, ideally, the semantics of all component interfaces have to be specified.
Documented
Component interfaces
Provides interface
Defines the services that are provided by the component to other components.
Requires interface
Defines the services that must be made available for the component to execute as specified.
Component interfaces
Requires int erface Defines the services from the com ponents environm ent that it uses Com ponent
Provides int erface Defines the services that are provided by the com ponent to other com ponents
Provides/requires interfaces
These interfaces are NOT the same as input/output interfaces. Both of these interfaces define both the inputs needed and the outputs produced by the provided and required services Requires
You can think of this as defining the methods that are called by a component or before a component executes
Provides
You can think of this as defining how the component is called.
Component models
A component model is a definition of standards for component implementation, documentation and deployment. Examples of component models
EJB model (Enterprise Java Beans) COM+ model (.NET model) Corba Component Model
The component model specifies how interfaces should be defined and the elements that should be included in an interface definition.
Interaces f
Middleware support
Component models are the basis for middleware that provides support for executing components. Component model implementations provide:
Platform services that allow components written according to the model to communicate; Horizontal services that are application-independent services used by different components.
To use services provided by a model, components are deployed in a container. This is a set of interfaces used to access the service implementations.
Platform services Addressing Interface definition Exception Com ponent management com munications
Reusable components
The development cost of reusable components may be higher than the cost of specific equivalents. This extra reusability enhancement cost should be an organization rather than a project cost. Generic components may be less space-efficient and may have longer execution times than their specific equivalents.
CBSE Processes
As discussed, conventional software engineering processes have to be adapted for reuse.
Architectur al design
Component search
Component selection
Component validation
Component composition
Designing a system by integrating a number of components.
Component composition
The process of assembling components to create a system. Composition involves integrating components with each other and with the component infrastructure. Normally you have to write glue code to integrate components.
Types of composition
Sequential composition where the composed components are executed in sequence. This involves composing the provides interfaces of each component. Hierarchical composition where one component calls on the services of another. The provides interface of one component is composed with the requires interface of another. Additive composition where the interfaces of two components are put together to create a new component.
Types of composition
(a)
(b)
(c)
Sequential composition
In this case, the components are executed in sequence to provide some required effect The outputs from the provides interface from the first component executed become the inputs for the provides interface for the 2nd unit called (perhaps with some modification through an adapter component) Each component is executed independently and does not have to be aware of the other components in the sequence.
Hierarchical composition
In this case, one component (defined in the requires interface) is called directly from within the body of the other component. The calling component must know the name and the interface signature of the called component.
Additive composition
In this case, we put two components together so that the provides interface includes operations that come from both of the composed components. Essentially, this is normally implemented by defining a new small component that offers the combined interface and which than calls one of the composed components, depending on the call to the composed component.
Interface incompatibility
Parameter incompatibility where operations have the same name but are of different types. Operation incompatibility where the names of operations in the composed interfaces are different. Operation incompleteness where the provides interface of one component is a subset of the requires interface of another.
Incompatible components
string location(string pn) string owner (string pn) string proper ype (string pn) tyT
Incompatibility
The component addressFinder through its location method produces a string which is the address of the property, including street number and name and town The component mapper through its displayMap method, expects a string which is a postcode only (not a complete address)
Adaptor components
Address the problem of component incompatibility by reconciling the interfaces of the components that are composed. Different types of adaptor are required depending on the type of composition. An addressFinder and a mapper component may be composed through an adaptor (called postCodeStripper) that strips the postal code from an address and passes this to the mapper component.
sensorManagem ent
addSensor rem oveSensor star tSensor Data collector stopSensor testSensor initialise report listAll
Adapter sensorData
Adaptor functionality
The data collector component requires a sensorManagement component that provides facilities to stop and start sensors and to query sensors for data The adapter component in this case turns a string of sensor management commands e.g. sensor.stop into the commands required for a specific sensor device.
Interface semantics
You have to rely on component documentation to decide if interfaces that are syntactically compatible are actually compatible. Consider an interface for a PhotoLibrary component:
public void addItem (Identifier pid ; Photograph p; CatalogEntry photodesc) ; public Photograph retrieve (Identifier pid) ; public CatalogEntry catEntry (Identifier pid) ;
getImage
Image Manager
Composition trade-offs
When composing components, you may find conflicts between functional and non-functional requirements, and conflicts between the need for rapid delivery and system evolution. You need to make decisions such as:
What composition of components is effective for delivering the functional requirements? What composition of components allows for future change? What will be the emergent properties of the composed system?
Data collection
Data m anagement
Report
(b)
Data collection
Data base
Report
Composition trade-offs
For composition (a), reporting and data management are separate so there is more flexibility if changes in one of these functions but not the other have to be made. For composition (b), there are fewer discrete components so faster communications within the component offering both data management and report generation.
Key points
CBSE is a reuse-based approach to defining and implementing loosely coupled components into systems. A component is a software unit whose functionality and dependencies are completely defined by its interfaces. A component model defines a set of standards that component providers and composers should follow. During the CBSE process, the processes of requirements engineering and system design are interleaved.
Key points
Component composition is the process of wiring components together to create a system. When composing reusable components, you normally have to write adaptors to reconcile different component interfaces. When choosing compositions, you have to consider required functionality, non-functional requirements and system evolution.
Creates a standard virtual boundary around application component implementations that interact only via welldefined interfaces
Specify the infrastructure needed to configure & deploy components throughout a distributed system
Container
<ComponentAssemblyDescription id="a_HUDDisplay"> ... <connection> <name>GPS-RateGen</name> <internalEndPoint><portName>Refresh</portName><instance>a_GPS</instance></internalEndPoint> <internalEndPoint><portName>Pulse</portName><instance>a_RateGen</instance></internalEndPoint> </connection> <connection> <name>NavDisplay-GPS</name> <internalEndPoint><portName>Refresh</portName><instance>a_NavDisplay</instance></internalEndPoint> <internalEndPoint><portName>Ready</portName><instance>a_GPS</instance></internalEndPoint> </connection> ... </ComponentAssemblyDescription>
Container Container
Middleware Bus
Replication A/V Streaming Security Persistence Notification
Scheduling
Load Balancing
Generic port management operations in CCMObject Monolithic implementations Session/service component/ container types
Attributes
Container
Component homes
Event Sinks
Component Integrated ACE ORB Lightweight CCM implementation atop TAO Supports component-oriented paradigm for DRE applications Provides Real-time CORBA policies & mechanisms required for DRE applications
Overview of CIAO
Key DRE aspects are supported as first-class metadata First official release (CIAO 0.4) was at end of December 2003 Latest release is downloadable from deuce.doc.wustl.edu/Download.html
A small sample
106
107
108
109
110
111
So,
Different representations For different people For different purposes These representations are both descriptive and prescriptive
112
Environment
System
Architecture
Stakeholder
Architecture Description
Rationale
Concern
Viewpoint
View
Library Viewpoint
Model
113
114
Stakeholders
Architect Requirements engineer Designer (also of other systems) Implementor Tester, integrator Maintainer Manager Quality assurance people
115
Viewpoint specification
Viewpoint name Stakeholders addressed Concerns addressed Language, modeling techniques
116
Logical Viewpoint
Process Viewpoint
Integrators Performance Scalability
Deployment Viewpoint
System engineers Topology Communications
117
118
119
120
121
122
4 + 1: Logical Viewpoint
The logical viewpoint supports the functional requirements, i.e., the services the system should provide to its end users. Typically, it shows the key abstractions (e.g., classes and interactions amongst them).
123
4 + 1: Process Viewpoint
Addresses concurrent aspects at runtime (tasks, threads, processes and their interactions) It takes into account some nonfunctional requirements, such as performance, system availability, concurrency and distribution, system integrity, and fault-tolerance.
124
4 + 1: Deployment Viewpoint
The deployment viewpoint defines how the various elements identified in the logical, process, and implementation viewpoints-networks, processes, tasks, and objects-must be mapped onto the various nodes. It takes into account the system's nonfunctional requirements such as system availability, reliability (fault-tolerance), performance (throughput), and scalability.
125
4 + 1: Implementation Viewpoint
The imlementation viewpoint focuses on the organization of the actual software modules in the software-development environment. The software is packaged in small chunks-program libraries or subsystems-that can be developed by one or more developers.
126
4 + 1: Scenario Viewpoint
The scenario viewpoint consists of a small subset of important scenarios (e.g., use cases) to show that the elements of the four viewpoints work together seamlessly. This viewpoint is redundant with the other ones (hence the "+1"), but it plays two critical roles:
it acts as a driver to help designers discover architectural elements during the architecture design; it validates and illustrates the architecture design, both on paper and as the starting point for the tests of an architectural prototype.
Doc. Dr Ljubomir Lazi Kljent Server Sistemi (Softverske Arhitekture) @ 2007
127
Allocation views
Relationship between software elements and environment Work assignment, deployment, implementation
128
Module views
Decomposition: units are related by is a submodule of, larger modules are composed of smaller ones Uses: relation is uses (calls, passes information to, etc). Important for modifiability Layered is special case of uses, layer n can only use modules from layers <n Class: generalization, relation inherits from
129
130
Allocation views
Deployment: how software is assigned to hardware elements Implementation: how software is mapped onto file structures Work assignment: who is doing what
131
132
Decision visualization
133
Business viewpoint
134
A caveat on quality
A view can be used to assess one or more quality attributes E.g., some type of module view can be used to assess modifiability It should then expose the design decisions that affect this quality attribute
135
Overview
What is it, why bother? Architecture Design Viewpoints and view models Architectural styles Architecture asssessment Role of the software architect
136
Architectural styles
An architectural style is a description of component and connector types and a pattern of their runtime control and/or data transfer. Examples:
main program with subroutines data abstraction implicit invocation pipes and filters repository (blackboard) layers of abstraction
Kljent Server Sistemi (Softverske Arhitekture) @ 2007
137
Alexanders patterns
There is abundance evidence to show that high buildings make people crazy. High buildings have no genuine advantage, except in speculative gains. They are not cheaper, they do not help to create open space, they make life difficult for children, they wreck the open spaces near them. But quite apart from this, empirical evidence shows that they can actually damage peoples minds and feelings. In any urban area, keep the majority of buildings four stories high or less. It is possible that certain buildings should exceed this limit, but they should never be buildings for human habitation.
Doc. Dr Ljubomir Lazi Kljent Server Sistemi (Softverske Arhitekture) @ 2007
138
139
Components are connected by connectors. They are the building blocks with which an architecture can be described. No standard notation has emerged yet.
Doc. Dr Ljubomir Lazi Kljent Server Sistemi (Softverske Arhitekture) @ 2007
140
Types of components
computational: does a computation of some sort. E.g. function, filter. memory: maintains a collection of persistent data. E.g. data base, file system, symbol table. manager: contains state + operations. State is retained between invocations of operations. E.g. adt, server. controller: governs time sequence of events. E.g. control module, scheduler.
Doc. Dr Ljubomir Lazi Kljent Server Sistemi (Softverske Arhitekture) @ 2007
141
Types of connectors
procedure call (including RPC) data flow (e.g. pipes) implicit invocation message passing shared data (e.g. blackboard or shared data base) instantiation
142
143
Main-program-with-subroutines style
problem: hierarchy of functions; result of functional decomposition, single thread of control context: language with nested procedures solution:
system model: modules in a hierarchy, may be weak or strong, coupling/cohesion arguments components: modules with local data, as well as global data connectors: procedure call control structure: single thread, centralized control: main program pulls the strings
144
Abstract-data-type style
problem: identify and protect related bodies of information. Data representations likely to change. context: OO-methods which guide the design, OO-languages which provide the class-concept solution:
system model: component has its own local data (= secret it hides) components: managers (servers, objects, adts) connectors: procedure call (message) control structure: single thread, usually; control is decentralized
145
Implicit-invocation style
problem: loosely coupled collection of components. Useful for applications which must be reconfigurable. context: requires event handler, through OS or language. solution:
system model: independent, reactive processes, invoked when an event is raised components: processes that signal events and react to events connectors: automatic invocation control structure: decentralized control. Components do not know who is going to react.
146
Pipes-and-filters style
problem: independent, sequential transformations on ordered data. Usually incremental, Ascii pipes. context: series of incremental transformations. OS-functions transfer data between processes. Error-handling difficult. solution:
system model: continuous data flow; components incrementally transform data components: filters for local processing connectors: data streams (usually plain ASCII) control structure: data flow between components; component has own flow
variants: From pure filters with little internal state to batch processes
147
Repository style
Client
Shared Data
Client
Client
problem: manage richly structured information, to be manipulated in many different ways. Data is long-lived. context: shared data to be acted upon by multiple clients solution:
system model: centralized body of information. Independent computational elements. components: one memory, many computational connectors: direct access or procedure call control structure: varies, may depend on input or state of computation
148
Layered style
Layern Layer2 Layer1
problem: distinct, hierarchical classes of services. Concentric circles of functionality context: a large system that requires decomposition (e.g., virtual machines, OSI model) solution:
system model: hierarchy of layers, often limited visibility components: collections of procedures (module) connectors: (limited) procedure calls control structure: single or multiple threads
Kljent Server Sistemi (Softverske Arhitekture) @ 2007
149
problem: separation of UI from application is desirable due to expected UI adaptations context: interactive applications with a flexible UI solution:
system model: UI (View and Controller Component(s)) is decoupled from the application (Model component) components: collections of procedures (module) connectors: procedure calls control structure: single thread
variants: Document-View
Doc. Dr Ljubomir Lazi Kljent Server Sistemi (Softverske Arhitekture) @ 2007
150
Overview
What is it, why bother? Architecture Design Viewpoints and view models Architectural styles
151
Architecture evaluation/analysis
Assess whether architecture meets certain quality goals, such as those w.r.t. maintainability, modifiability, reliability, performance Mind: the architecture is assessed, while we hope the results will hold for a system yet to be built
152
System
Properties
properties
Qualities
153
Analysis techniques
Questioning techniques: how does the system react to various situations; often make use of scenarios Measuring techniques: rely on quantitative measures; architecture metrics, simulation, etc
154
155
156
157
Benefits
Financial gains Forced preparation Captured rationale Early detection of problems Validation of requirements Improved architecture
158
Participants in ATAM
Evaluation team Decision makers Architecture stakeholders
159
Phases in ATAM
0: partnership, preparation (informally) 1: evaluation (evaluation team + decision makers, one day) 2: evaluation (evaluation team + decision makers + stakeholders, two days) 3: follow up (evaluation team + client)
160
161
Training
Utility
Usability
Normal operations
Maintainability
Doc. Dr Ljubomir Lazi
162
Outputs of ATAM
Concise presentation of the architecture Articulation of business goals Quality requirements expressed as set of scenarios Mapping of architectural decisions to quality requirements Set of sensitivity points and tradeoff points Set of risks, nonrisks, risk themes
163
164
Evaluate indirect scenarios: changes and cost Reveal scenario interaction Overall evaluation
165
166
Overview
What is it, why bother? Architecture Design Viewpoints and view models Architectural styles Architecture asssessment
167
168
Summary
new and immature field proliferation of terms: architecture - design pattern framework - idiom architectural styles and design pattern describe (how are things done) as well as prescribe (how should things be done) stakeholder communication early evaluation of a design transferable abstraction
169
Further reading
Mary Shaw and David Garlan, Software Architecture; Perspectives of an Emerging Discipline, 1995. Philippe B. Kruchten, The 4+1 view model of architecture, IEEE Software, 12(6):42-50, November 1995. Frank Buschmann et al., Pattern-Oriented Software Architecture: A System of Patterns, 1996. Part II: 2001. Erich Gamma et al., Design Patterns: Elements of Reusable Object-Oriented Software, 1995. Len Bass et al, Sofware Architecture in Practice, 2003 (2nd edition). C. Hofmeister et al., Applied Software Architecture, 1999. Jan Bosch, Design & Use of Software Architectures, 2000.
170