Software Architectures Lecture 7 15 Oct 2014
2 14-Oct-14 Roadmap of the course What is software architecture? Designing Software Architecture Requirements: quality attributes or qualities How to achieve requirements : tactics How do tactics lead to architectural styles Case studies on architectural styles, observed the achieved qualities The ADD method Evaluating an architecture Documenting software architecture Bass et al Hofmeister et al Today: ADLs, PLs, COTS
3 Linguistic character of architectural description Idiomatic constructs in different architectures common kinds of elements common inter-module connection strategies Languages describe complex relations among primitive elements and combinations of these Semantic constructs => There is an appropriate linguistic basis in architectural descriptions
4 Common patterns of SW organization SA description often Box-and-line diagrams boxes à major components lines à communication, control, data relation Boxes and lines may mean different things For different described systems For different people Supplemented with prose, no precise meaning Informal terms Still useful
5 Common component classes (pure) Computation Simple input/output relations, no retained state Exp: Math functions, filters, transforms Memory Shared collection of persistent structured data Exp: Database, file system, symbol table, hypertext Manager State and closely related operations Exp: Abstract data type, servers Controller Governs time sequences of other s events Exp: Scheduler, synchronizer Link Transmits information between entities Exp: Communication link, user interface
6 Common interactions among components Procedure call Single thread of control passes among definitions Exp: Ordinary procedure call, remote procedure call Dataflow Independent processes interact through streams of data Exp: Unix pipes Implicit invocation Computation is invoked by the occurrence of an event; no explicit interactions among processes Exp: Event systems, automatic garbage collection Message passing Independent processes interact by explicit, discrete hand-off of data; may be synchronous or asynchronous Exp: TCP/IP Shared data Components operate concurrently (with provisions for atomicity) on the same data space Exp: Blackboard systems, multiuser databases Instantiation Instantiator uses capabilities of instantiated definition by providing space for state required by instance Exp: using abstract data types
Critical elements of a design language 7 A (programming) language requires Components Primitive semantic elements and their values Exp: integers, floating-point numbers, strings, records, arrays Operators Functions that combine components Exp: iteration, conditional constructs, +,-,*,/ Abstraction Rules for naming expressions of components and operators Exp: definition of macros and procedures Closure Rules to determine which abstractions can be added to the classes of primitive components and operators Exp: procedures or user-defined types - first class entities Specification Association of semantics to the syntactic form Formal, informal (in reference manual)
8 The language problem for SA SA deals with Allocation of functionality to components Data and communication connectivity Quality attributes and system balance Different from programming language concerns Specific forms of the various language elements are also different
9 Critical elements of a SA design language Components Module-level elements; component classes listed before Operators Interaction mechanisms as listed before Patterns/ abstraction Compositions in which code elements are connected in a particular way; Exp: client-server relation Closure Conditions in which composition can serve as a subsystem in development of larger systems Specification Not only of functionality, but also of quality attributes
10 Implication of the critical elements Basis for designing ADLs provided by Identification of architectural components Identification of architectural techniques, for combining them into subsystems and systems Such a language would support Simple expressions of connections among simple modules, plus Subsystems Configurations of subsystems into systems Common paradigms for such combinations Expression of quality attributes and functional properties
11 Requirements for ADLs 1. To provide models, notations, tools to describe architectural components and their interactions 2. To handle large-scale, high-level designs 3. To support the adaptation of designs to specific implementations 4. To support user-defined abstractions 5. To support application-specific abstractions 6. To support the principled selection of architectural paradigms
12 ADL and environment Close relation between ADL and its environment ADL: precise descriptions Environment: (re)uses the descriptions Ideal ADL should support Composition Abstraction Reusability Configuration Heterogeneity Analysis
13 Composition Describe a system as composition of independent components and connections Aspects Divide a complex system (hierarchically) into smaller parts Assemble a large system from constituent elements Independent elements Can be understood in isolation from the system Separate issues of implementation-level from those of architectural level
14 Composition, 2 Another name: modularity Closure rule: can see entities as both primitives and composites At different levels of abstraction Independence rule: can reuse parts of a composite
15 Composition, 3 Need for explicit and abstract composition rules Pipe and filter Sequence of pipes and filters Layered systems Collection of abstract layers interacting according to certain rules Filter can internally be decomposed in Another pipe and filter system Instance of something else Filter may be used in any data stream transformation system Pipe may be used for any data transmission
16 Abstraction Describe the abstract roles of elements and their interaction within SA at a level well understood by designers Clearly Explicitly Intuitively Suppress unneeded detail but reveal important properties high-level pgm languages: register usage suppressed, sequential control flow abstractions revealed Interface: suppresses implementation issues, reveals use dependencies
17 Abstraction, 2 Necessary for representing new architectural styles, new forms of interaction between them as first-class abstractions Architectural level of design Different form of abstraction, to reveal high-level structure Distinct roles of each element in the high-level structure are clear Example: client-server relationship
18 Reusability Reuse components, connectors, architectural styles in different architectural descriptions Reuse generic patterns of components and connectors Families of SA as open-ended sets of architectural elements Structural and semantic constraints Differs with respect to reusing components from libraries Those are completely closed / parameterized components, retain identities, are leaves of is-composed-of system structure Reusing generic patterns of components and connectors: further instantiation, indefinite replication of relations, reuse of structured collections of internal nodes
19 Reusability, 2 Systems rarely conceived in isolation Instances of a family of similar systems that share many architectural properties Shared properties Structural: specific topology of component and connectors Constraints on using certain architectural elements We need parameterized collections of modules Eg: pipeline architecture: has pipes, filters and constrains topology to be linear
20 Configuration Architectural descriptions should localize the description of system structure Independently of the elements being structured Dynamic reconfiguration permissible Evolvability Create/remove components, interactions initiated Allows to understand and change architectural structure Without examining individual components ADL: should separate descriptions of compositions from those of elements Reason about composition as a whole
21 Heterogeneity Combine multiple, heterogeneous architectural descriptions Ability to combine different architectural styles in a single system Component A communicates with component B via a pipe, but also accesses a shared database with a query Different levels of architectural description should be allowed to use different architectural idioms Ability to combine components written in different languages Architectural description is at a higher level of abstraction than the algorithms and data structures used for implementation
22 Analysis Possible to perform rich and varied analyses of architectural descriptions Each style facilitates a certain type of properties Pipe and filter: possible to analyze throughput, investigate deadlock and resource usage, deduce the system I/O behavior from that of the filters Should be possible to tailor special purpose analysis tools to architecture types Automated and non-automated reasoning about architectural descriptions
23 Analysis, 2 Important for architectural formalisms Many of the interesting architectural properties are dynamic Exp If connector associated with protocol, is the use of connector correct in its context? Timing, performance, resource usage may aid in reasoning if SA adequate Variety of analyses => no single semantic framework will be enough Should be possible to associate specifications with architectures as they become relevant to particular components, connectors, styles
24 First-class connectors: needed SA treats SW systems as composition of components Focus on components Description of interactions among components is implicit, distributed, hard to identify When interfaces explicit: import/export lists of data and procedures Implicit interactions: include files => Info organized around components, significance of interactions, connections is ignored
25 Problems with this practice 1. Inability to localize info about interactions 2. Poor abstractions 3. Lack of structure on interface definitions 4. Mixed concerns in programming language specification 5. Poor support for components with incompatible packaging 6. Poor support for multi-language or multiparadigm systems 7. Poor support for legacy systems
26 Fresh view of software system composition Systems composed of identifiable components of various distinct types These interact in identifiable, distinct ways Correspond to compilation units (roughly) Connectors mediate interactions among components Establish rules that govern component interaction Specify any auxiliary mechanisms required Do not correspond to compilation units
27 Connectors Manifest as Table entries Instructions to a linker Dynamic data structures System calls Initialization parameters Servers with multiple independent connections Define a set of roles that specific named entities of the components must play
28 Connectors, 2 Place of relations among components Mediate interactions Have protocol specifications defining their properties Rules about types of interfaces they are able to mediate for Assurances about properties of interactions Rules about order in which things happen Commitments about interaction (ordering, performance, etc) Are of some type/subtype Roles to be satisfied: specific, visible named entities in the protocol of a connector
29 Components Place of computation and state Have interfaces specifying their properties Signatures Functionality of resources Global relations Performance properties Are of some type/subtype Interface points: specific, visible named entities in the interface of a component
30 Primitive vs composite: components Primitive components coded in the programming language Composite components define configurations in independent notation Constituent components and connectors identified Match connection points of components with roles of connectors Check integrity of the above
31 Primitive vs composite: connectors Of different kinds Shared data representations Remote procedure calls Dataflow Document-exchange standards Standardized network protocols Rich enough set to require taxonomy to show relations among similar connector kinds
32 Primitive connectors Built-in mechanisms of programming languages System functions of the OS Shared data Entries in task/routing tables Interchange formats for static data Initialization parameters etc
33 Summing up principles for ADL Purpose: define roles and relationships instead of algorithms and data structures Must support System configuration Independence of entities (reusability) Abstraction Analysis of functional properties and QA Has syntax and Defines semantics for connectors and their compositions Generalize from import/export rules to rules with symmetry, multiplicity, abstraction, locality, naming Defines type structures for system organizations, components, connectors, primitive units of associations of these Sets out appropriate rules for architectural abstractions
34 Large grained structure of ADL Component Interface Component type Player Implementation Connector Protocol Connector type Role Implementation
35 On ADL structure Specify whether element primitive Not further defined at architectural level, but implemented in a programming language Non-primitive element Implementation: list of parts, composition instructions, related specs => no more name matching
36 Architecture Description Languages The positives ADLs provide a formal way of representing architecture ADLs are intended to be both human and machine readable ADLs support describing a system at a higher level than previously possible ADLs permit analysis of architectures completeness, consistency, ambiguity, and performance ADLs can support automatic generation of software systems The negatives There is no universal agreement on what ADLs should represent, particularly wrt the behavior of the architecture Representations currently in use are relatively difficult to parse and are not supported by commercial tools Most ADL work today has been undertaken with academic rather than commercial goals in mind Most ADLs tend to be very vertically optimized toward a particular kind of analysis
37 Software Architecture: ADL Perspective The ADL community generally agrees that Software Architecture is a set of components and the connections among them. components connectors configurations constraints
38 ADLs Leading candidates ACME (CMU/USC) Rapide (Stanford) Wright (CMU) Unicon (CMU) Secondary candidates Aesop (CMU) MetaH (Honeywell) C2 SADL (UCI) SADL (SRI) Others Lileanna UML Modechart
39 14-Oct-14 ADL Scope and Applicability
(#, /JCC=A@ D=A!=E?H9>: '=>>?<@=AB 40 14-Oct-14
41 14-Oct-14
42 UML as an ADL The Positive lowers entry barrier, mainstreams modeling, tools Shortcomings of UML as an ADL Weakly integrated models with inadequate semantics for (automated) analysis Connectors are not first class objects Visual notation with little generation support, hidden and ambiguous relationships between views, both too much and too little
43 Hence There is a rich body of research to draw upon Much has been learned about representing and analyzing architectures Effort is needed now to bring together the common knowledge and put it into practice
44 For More Information ACME: http://www.cs.cmu.edu/~acme Rapide: http://pavg.stanford.edu/rapide/ Wright: http://www.cs.cmu.edu/afs/cs/project/able/www/wright/ index.html Aesop: http://www.cs.cmu.edu/afs/cs/project/able/www/aesop/ aesop_home.html Unicon: http://www.cs.cmu.edu/afs/cs/project/vit/www/unicon/ index.html C2 SADL: http://www.ics.uci.edu/pub/arch/ SSEP: http://www.mcc.com/projects/ssepp ADML: http://www.mcc.com/projects/ssepp/adml
45 Formalisms Formal models and techniques are cornerstones of a mature engineering discipline Engineering disciplines used models and techniques in different ways Provide precise, abstract models Provide analytical techniques based on models Provide design notations Provide basis for simulations
46 What to formalize? Architecture of a specific system Allow the architect to plan a specific system Becomes part of the specification of the system Augments the informal characteristics of the SA Permits specific analyses of the system
47 What to formalize? Architectural style Describe architectural abstractions for families of systems Purposes: Make common idioms, patterns and reference architectures precise Show precisely how different architectural representations can be treated as specializations of some common abstraction
48 What to formalize Theory of software architecture Clarify the meaning of generic architectural concepts Architectural connection, hierarchical architectural representation, architectural style Provide deductive basis for analyzing systems at an architectural level Might provide rules for determining when an architectural description is well formed Compositionality
49 What to formalize Formal semantics of ADL:s Architectural description is a language issue Apply traditional techniques for representing semantics of languages
50 Some takeaway SA has a linguistic character Programming languages are useful for comparison Connectors are needed in addition to components ADLs may grow in the future
51 14-Oct-14 SW Product line (SW PL) Ø Set of SW-intensive systems sharing a common, managed set of features that satisfy specific needs of particular market segment or mission and that are developed from a common set of core assets in a prescribed way
52 14-Oct-14 Why Product Lines? SA significant investment in time and effort Senior experience Want to maximize the return on this investment Reuse SA across multiple systems SA valuable intellectual property Can be leveraged to produce additional revenue, reduce costs
53 14-Oct-14 What does PL involve? Vision: set of reusable assets that include Base architecture Common, tailorable elements that populate it Designs, their documentations, user manuals, budgets, schedules, test plans, test cases etc Achieving vision depends critically on establishing the correct scope for the PL
54 14-Oct-14 What does PL imply? Successfully established PL Each reusable asset saved in core asset base To be applied to more than one system Reusing it cheaper than reinventing it Core assets designed with variation points Places where they can be tailored in preplanned ways System building becomes Accessing appropriate assets Tailoring them as required for system at hand Assembling the system The needed new SW (if any) accounts for about 20% of the total SW Integration and testing replace design and coding as predominant activities
55 14-Oct-14 Who does it? Boeing, Ford, Dell, McDonalds, etc Nokia: 25-30 models/year (up from 4) Cummins, Inc: SW for diesel engine in 1 week from 1 year Motorola: 400% productivity improvement in a family of one-way pagers HP: time-to-market reduced 7 times, increased productivity 6 times for a printer family Family of satellite ground control systems: 10% of usual number of developers and 90% fewer defects (US National Reconnaissance Office)
56 14-Oct-14 What does it take to do a PL? Coordinated strategy involving SW engineering Technical management Organization management We check the SA aspects of SW engineering All aspects must work together
57 14-Oct-14 Scoping Scope of a PL Defines what systems are in it and what are out of it Statement about what systems an organization is willing to build as part of this PL and what systems is not willing to build The organization s best prediction on the products to build in foreseeable future Strategic planners, marketing staff, domain analysts (can catalog similar things, existing and planned), technology experts Doughnut analogy
58 14-Oct-14 Scope is critical For success of that PL Too narrow: insufficient nr of products derived to justify the development investment Too broadly: effort required to develop individual products from core assets to big to lead to great savings Scope can be refined During initial establishment of PL Opportunistically depending on PL adoption strategy
59 14-Oct-14 Defining scope Finding commonality Not between two systems That leads to substantially reduce cost of constructing systems that an organization intends to build Consider Systems to be built Market segmentation Type of assumed customer interactions
60 14-Oct-14 SA for PL SA in core asset repository: most central role Essence of building successful SW PL: discriminating between what is constant across all family members and what is expected to vary SA ready made for this duality SA is an abstraction that admits plurality of instances In SW PL: SA is an expression of the nonvarying aspects
61 14-Oct-14 SA for PL, 2 PL SA goes beyond this dichotomy Set of explicitly allowed variations (conventional SA: any instance will do as long as functionality and qualities are respected) PL SA s responsibility Identifying variation points May be substantial Variations in behavior, qualities, platform, network, physical configuration, middleware, scale factors, etc Provide built-in mechanisms for achieving them
62 14-Oct-14 PL SArchitect needs to consider Identifying variation points Supporting variation points Evaluating the architecture for PL suitability
63 14-Oct-14 Identifying variation points Ongoing activity Products can vary in many ways => variants can be identified at any time in the development process During requirements process Features, platforms, UI, qualities, target markets -> some are interdependent During design process Options for implementing the variations identified during requirements process Normal variations during design Some decisions deferred until more info is available During implementation Also during implementation of second (subsequent) products
64 14-Oct-14 Supporting variation points Inclusion / omission of elements Inclusion of a different number of replicated elements Selection of version of elements that have the same interface but different behavior/qualities Selection can occur at compile/build/runtime
65 14-Oct-14 Supporting variation points more sophisticated techniques OO-systems write generalizations and specializations of classes Building extension points into the element s implementation Introducing build-time parameters to an element Reflection Ability of a program to manipulate data on itself, its execution environment, or state Reflective programs can adjust their behavior based on their context Overloading Reusing named functionality to operate on different types Promotes code reuse; cost of understandability and code complexity
66 14-Oct-14 Supporting variation points - documentation For the PL SA as it resides in the core asset base For each product s SA (to the extent that it varies from PL architecture) Should clearly show its variation points Should also show rationale for each Scope definition used as justification Should describe architecture s instantiation process How its variation points are exercised
67 14-Oct-14 Evaluating the architecture for PL suitability PL SA should be evaluated for fitness or purpose Typical SA evaluation techniques work PL SA should be evaluated For robustness and generality To make sure it can serve as basis for products in PL s scope To make sure it meets qualities of product
68 14-Oct-14 What makes PLs work? Potential for reuse is broad Requirements Architectural design Elements Modeling and analysis Testing Project planning Processes, methods, tools People Exemplar systems Defect elimination
69 14-Oct-14 Building systems from COTS components Commercial-Off-The-Shelf (COTS) Architecture should respect quality attributes Control over system design = control over achieved qualities?? Not true with COTS components COTS components used Economical reasons Change design process, constrain SA Typically to achieve some functionality They also embody architectural (quality) assumptions We need to discover assemblies of components that will work in concert With each other With system that integrates them
70 14-Oct-14 Impact of COTS components to SA Use of components Essential in many cases Also introduces new challenges Component capabilities and liabilities are constraining SA Example Chemical plant monitoring All but the simplest components have a presumed architectural pattern that is difficult to violate Components assume an architectural pattern => it is difficult to select an architecture before understanding component assembly under consideration
71 14-Oct-14 Architectural mismatch Not all components work together Some only appear to, but give wrong results (subtle errors) Components not developed for the system at hand may not work Discovered after buying and trying to use them Interfaces notoriously poor at specifying quality attributes Architectural mismatch Impediment to successfully integrating component-based systems Mismatch between assumptions embodied in separately developed components Exp: which component invokes the other Shows up at integration time System will not compile, link, run
72 14-Oct-14 Interface mismatch General case of architectural mismatch Interface: assumptions components can make about each other Not the Java interface specification Assumptions Provide assumptions: services provided by the component to its user/clients Require assumptions: detail the services / resources needed for the component for working correctly Mismatch: provide and require assumptions do not match
73 14-Oct-14 What to do about interface mismatch Avoid mismatch by specifying and inspecting components for the system Detect cases not avoided by qualifying components Repair detected cases by adapting the components
74 14-Oct-14 Techniques for repairing interface mismatch Little systematic attention One obvious method Change the code of offending component Not often possible, not desirable even The other methods: insert code for one or both components that reconciles their interaction to solve the mismatch Wrappers Bridges Mediators
75 14-Oct-14 Wrappers A form of encapsulation where some component is encased within an alternative abstraction Clients access wrapped component services through an alternative interface Provided by the wrapper Yielding an alternative interface to the component
76 14-Oct-14 Interface translation for wrappers includes Translation of an element of a component interface into an alternative element Hiding an element of a component interface Preserving an element of a component s interface unchanged
77 14-Oct-14 Bridges Translate some require assumptions of some component into provide assumptions of another component Difference wrt to wrapper Repair code of bridge independent of any particular component Bridge must be explicitly invoked by some external agent Possibly one of the components the bridge spans Specific translation done at the time of bridge construction Compile time Bridges usually transient
78 14-Oct-14 Bridges and wrappers Bridges focus on narrower range of interface translations than wrappers Bridges address specific assumptions More assumptions => fewer components it applies to Script could be written to execute bridge Need to address component-specific interface peculiarities for both components Not a wrapper then
79 14-Oct-14 Mediators Exhibit properties of both wrappers and bridges Mediators incorporate a planning function Runtime determination of the translation Bridges establish translation at construction Mediators become a more explicit component in the overall SA Semantically primitive bridges: incidental repair mechanisms, their role in design remains implicit Semantically more complex mediators: runtime autonomy to be more first class in SA
Mediator examples 1. Intelligent data fusion: sensor generates high volume of high-fidelity data At runtime: different information consumers arise that have different operating assumptions about data fidelity Low-fidelity consumer: some info needs to be stripped Similar fidelity but different throughput characteristics requiring temporary buffering of data In each case the mediator accommodates differences between the sensor and its customers 2. Runtime assembly of sequence of bridges Integrate components with integration requirements at runtime One component produces data in format D0, another consumes data in format D2; if there is no bridge D0->D2, but separate D0->D1, D1->D2, these could be chained by a mediator
81 14-Oct-14 Techniques for detecting interface mismatch Identifying mismatches Enhanced form of component qualification Component qualification Process of determining whether a commercial component satisfies various fit for use criteria Prototype integration of candidate component Can discover subtle forms of interface mismatch, exp. resource contention
82 14-Oct-14 Component qualification Observation For each service provided by a component, a set of require assumptions must be satisfied Service convenient way of describing how component functionality is packaged for use Qualification process of Discovering all require assumptions for each service to be provided Ensuring that each require assumption is satisfied by some provide assumptions in the system
83 14-Oct-14 Techniques for avoiding interface mismatch From earliest phase of design Disciplined approach to specifying as many assumptions about an interface as feasible Assumptions state assertions about Sufficiency of services provided Implementability of each service (identifying resources needed)
84 14-Oct-14 Interfaces Interface: set of assumptions Different interfaces advantageous Parameterized interfaces Provide and require assumptions can be changed by changing value of variable before component service is invoked Result in adaptation code, both external and internal Negotiated interface Parameterized interface with self-repair logic
85 14-Oct-14 Component-based design as search Component based system design Search for compatible ensembles of COTS that can meet system objectives Flexibility in system requirements Beneficial to integration of component-based systems Important to know when certain requirement is essential to system success => not allow its compromise
86 14-Oct-14 Model problems Description of design context, defining the constraints of the implementation Required quality attributes included in the design context Model solution Prototype situated in a specific design context Several solutions to a problem possible Used by design teams Evaluation of ensembles to ensure Components can successfully be integrated They can support quality attribute objectives
87 15-Oct-14 More take away Product lines and components are about reuse Product lines fit naturally into the SA idea Components apparent paradox for designing (controlling) SA with certain QA