The History of Software Architecture Early Notions of Software

The History of Software Architecture INFO3011 Software Architecture and Design Early Notions of Software Architecture n n The earliest pioneers of what we now refer to as Software Architecture were Edgar Dijkstra, Fred Brooks Jr., and David Lorge Parnas In programming the term architecture was first applied to descriptions covering more than one computer system n i.e. “families of systems” n downloadable *. pdf file Brooks and Iverson (1969) called architecture the “…conceptual structure of a system…as seen by the programmer” Edgar Dijkstra 1968 n Fred Brooks Jr. on System Architecture (1975) n Dijkstra stressed as early as 1968 that how software is partitioned and structured is important n n Not merely simply programming a “correct” solution He introduced the idea of “layered structures” for operating systems n n Resulted in ease of development, maintenance “By the architecture of the system I mean the complete and detailed specification of the user interface….” “The architect of a system, like the architect of a building, is the user’s agent.” (“Aristocracy, Democracy and System Design” in The Mythical ManMonth, 1975) Brooks: Simplicity and Straightforwardness n ‘One Mind, Many Hands’ n “…It is not enough to learn the elements and rules of combination; one must also learn idiomatic usage, a whole lore of how the elements are combined in practice. Simplicity and straightforwardness proceed from conceptual integrity. Every part must reflect the same philosophies and the same balancing of desiderata….Ease of use, then, dictates unity of design, conceptual integrity” Conceptual integrity must proceed from one, or a small number of minds n e.g., Reims Cathedral’s Jean d’Orbais n n But schedule pressures demand many hands Two techniques proposed: n n Separation of architectural effort from implementation New structuring of software development teams n “The Surgical Team” The Surgical Team n Communication Patterns Surgeon Administrator Secretary Editor Secretary Co-pilot Programming Clerk Toolsmith Tester Language lawyer The problem n The “small, sharp” team is ideal… n Ten or less excellent programmers n …but too slow for really big systems The ‘surgical team’: one cutter, many supporters n The solution n How the Surgical Team works n Brooks on Blaauw n n n 10 people, seven professionals, work to a system which is the product of a single (or maybe two) mind. Not a democracy of equals. The surgeon rules. No “division of problem” Division of labour permits radically simpler communication patterns. Blaauw says total creative effort involves three distinct phases n Architecture n n n Implementation Realization Writing all the external specifications n Three “common objections” noted by Brooks n n n The specifications will be too rich and costly Creativity is confined to the architects Implementorswill sit idle waiting for the architecture Refuting Common Objections n The Second System Effect n “…architects will get all the creative fun” n An illusion. Implementation is a creative activity that is undiminished by external specification: “Form is a liberator” Another illusion. A matter of timing and phasing, i.e. project management. The three activities can “be begun in parallel and proceed simultaneously” A serious issue(dealt with by Brooks in “The Second-System Effect”) “Adde parvum parvo magnus acervus erit” (Ovid) n Add little to little and you get a great pile n “…implementors will sit idly by…” n n A building architects’ first design is lean and sparse n She knows he doesn’t know what she’s doing She thinks she knows it all and overspecifies it n “The specifications will be too rich…” n n Her second system is the most dangerous n “Interactive Discipline for the Architect” n Architect vs. Builder n n In building, contractors’ bids most often exceed the budget Architect has two possible responses n n To be successful, the architect must n n Suggest, not dictate, an implementation “The builder has creative and inventive responsibility for the implementation” Cut the design Challenge the bid by suggesting cheaper implementations n Always be able to suggest a way of implementing a specification n n The latter involves interactive dialogue with the builder n n n Deal privately and quietly in such suggestions Be ready to forego credit for suggested improvements Be prepared to accept alternatives “Often the builder will counter by suggesting changes to the architecture. Often he is right” David Parnas 1971-79 n David Parnas 1971-79 (contin.) n Parnas developed these ‘architectural’ concerns and turned them into fundamental tenets of Software Engineering. The main principles included: n Main principles (continued): n The “uses” relationship for controlling the connectivity between components [79] n n n Information Hiding as the basis of decomposition for ease of maintenance and reuse [72] The separation of Interface from implementation of components [71, 72] Observations on the separate character of different program elements [74] n Principles for the detection and handling of errors [72, 76] n To increase extensibility i.e., exceptions n Identifying commonalities in “families of systems” [76] n n Recognition that structure influences nonfunctional ‘qualities’ of a system [76] To provide coarse-grained, stable common structures Review n How relevant are Brooks’ 1975 concepts for today? Especially consider: n n n n The History of Software Architecture (1) INFO3011 Software Architecture and Design downloadable pdf file n n Architect as user’s agent Architecture as user’s manuals Division of labour between Architect and Builder Relationship of architecture to “creative and inventive implementation” The “Second-System Effect” The “Surgical Team” Leading Contributors n Foundations of Study n The leading contributors of the modern discipline of Software Architecture to date are: n n n The seminal work is a 1992 paper by Dewayne E. Perry and Alexander L. Wolf n n n Dewayne Perry and Alexander Wolf Mary Shaw and David Garlan Len Bass, Paul Clements, Rick Kazman and Linda Northrup Frank Buschmann et al., James O. Coplien “Foundations for the Study of Software Architecture”. ACM SIGSOFT Software Engineering Notes 17(4) pp.40-52 n Constructed a model of Software Architecture consisting of 3 components: n n n Elements Form Rationale Perry and Wolf, 1992 n Basis of the Intuition n n “We use the term ‘architecture’ rather than ‘design’ to evoke notions of codification, of abstraction, of formal training (of software architects), and of style” Benefits sought n Perry and Wolf examined other “architectural disciplines” for lessons n Computing hardware architecture n n Small number of design features Scale achieved by replication of the design elements Two kinds of components – nodes and connections Only a few topologies to be considered Multiple views Architectural styles Style and engineering Style and materials n n n Architecture as a framework for satisfying requirements Architecture as the technical basis for design Architecture as an effective basis for reuse Architecture as the basis for dependency and consistency analysis n Network architecture n n n Building architecture n n n n The Context of Architecture n n The Purpose of Architectural Specification n n n Requirements are concerned with the determination of the information, processing and characteristics of that information needed by the user of the system Architecture is concerned with the selection of architectural elements, their interactions, and the constraints on those elements and their interactions necessary to provide a framework in which to satisfy the requirements and serve as a basis for design Design is concerned with the modularisation and detailed interfaces of the design elements, their algorithms and procedures, and the data types needed to support the architecture and to satisfy the requirements; and Implementation is concerned with the representations of the algorithms and data types that satisfy the design, architecture and requirements. Architectural specifications are required to be of such a character that we can n n n n Prescribe the architectural constraints to the desired level Separate aesthetics from engineering Express different aspects of architecture in an appropriate manner Perform dependency and consistency analysis The Model: elements n The Model: form n n Software Architecture = {elements, form, rationale} Elements: n n n Form n n Consists of weighted properties and relationships Weighting is either: n n Processing elements Data elements Connecting elements n Properties n Importance of property or relationship Or necessity of selecting among alternatives Define the minimum constraints on the choice of architectural elements used to constrain the “placement” of architectural elements and how they interact n Relationships n The Model: rationale n Architectural Style n Rationale: n n Is underlying, but integral Captures the motivation for the choice of style, elements and form Rationale explicates underlying philosophical aesthetics Instead explicates the satisfaction of system constraints n n In building architecture n n n n In software architecture n Functional and non-functional Perry and Wolf noted that, distinct from other architectural disciplines, software architecture had no named styles They proposed that architectural styles be used as constraints on an architecture “The important thing about an architectural style is that it encapsulates important decisions about the architectural elements and emphasizes important constraints on their elements and their relationships” Modern Software Architecture(2) INFO3011 Software Architecture and Design downloadable pdf file Garlan and Shaw n n n n David Garlan and Mary Shaw, both of Carnegie Mellon University, wrote a book, Software Architecture: Perspectives on an Emerging Discipline in 1996 Identified three levels of software design Introduced four categories of research/development on software architecture Presented a number of common “architectural styles” Levels of Software Design n Levels of Software Design 2. The three levels of software design identified by Garlan and Shaw are: 1. Code n Architecture n n Issues involve the overall association of system capability with components Components are modules n n their interconnections can be handled in different ways n n Operators guide the composition of systems from subsystems Issues involve algorithms and data structures Components are programming language primitives Composition mechanisms include records, arrays, procedures etc., Levels of Software Design 3. Four Categories of Research/Development n Executable n n n Issues involve memory maps, data layouts, call stacks and register allocations Components are bit patterns supported by hardware Composition and operations described in the machine code How do you characterise a software system’s architecture? n Focus on Architectural Description Languages (ADL) Cataloguing and rationalizing architectural principles and patterns n How do you codify architectural expertise? n n n How do you build domain-specific frameworks? How do you formally understand an architecture? Architectural Styles n Architectural Styles n n Garlan and Shaw identify a number of common architectural styles, characterised by their respective components and connectors These styles include: n Independent Components n n Communicating processes Event systems Interpreters Rule-based Systems Database Hypertext Systems Blackboards n Virtual Machines n n Dataflow systems n n n Call-and-Return Systems n n n Batch Sequential Pipes and Filters n Data-Centred Systems n n n Main program and subroutine OO Systems Hierarchical systems Bass, Clements and Kazman n SAAM - Steps 1. n Len Bass, Paul Clements and Rick Kazman wrote a book Software Architecture in Practice in 1998 n Develop Scenarios Capture all important uses of a system 2. n Describe Candidate Architecture Described in an architectural notation From the Software Engineering Institute, based at Carnegie Mellon University n n n 3. n n Classify Scenarios Direct (directly supported by the system) Indirect (not directly supported as yet) n Presented a taxonomy for “architecture” Introduced an “Architectural Business Cycle (ABC) Explained the Software Architecture Analysis Method (SAAM) Described some Architectural Description Languages (ADLs) 4. n Perform Scenario Evaluations Cost modifications needed for indirect scenarios 5. Reveal Scenario Interaction Overall Evaluation Where a component is impacted by more than one Indirect Scenario modification 6. The Architectural Business Cycle The Architectural Business Cycle 1. The architecture affects the structure of the developing organisation n 2. The architecture can affect the enterprise goals of the developing organisation n Software units prescribed correspond to work assignments E.g., open up market opportunities, aid efficient development of product families etc . 3. The architecture can effect customer requirements for the next system n 4. 5. The architecture adds to the corporate base of experience The architecture may actually change software engineering culture E.g., through upgradeability etc., Architectural Description Languages n ADLs: System-Oriented Attributes n Architectural Description Languages can be evaluated or described by listing the following: n n n n System-oriented attributes Language-oriented attributes Process-oriented attributes n How suitable is the ADL for representing a particular type of application? How well does the ADL allow descriptions of architectural style? What broad classes of system can have their architectures represented in the ADL? n E.g., hard real-time, distributed, embedded etc., ADL’s: Language-Oriented Attributes n n ADL’s: Process-Oriented Descriptions n n n n n n Syntax and semantics formally defined? Does the ADL define completeness for an architecture Does the ADL support the ability to add new types of components, connectors How easily is the software architecture description modified? How saleable are its descriptions etc., n n Is there a textual editor or tool for manipulating ADL text? Is there a graphical editor? Can the tool import information from other descriptions into the architecture? Does the ADL support incremental refinement? Does the ADL support comparison between two architectures? Architectural Knowledge § Lessons Written in Stone INFO3011 Software Architecture and Design Download in *.PDF Format Download as *.ppt File § n ADLs and Notions of ‘Software Architecture Styles’ help us analyze structure better… but how do they help us create architectures? The built environment has a notion of architecture that goes back to Ancient Egypt § And recently the Royal Institute of British Architects (RIBA) has tried to define what an architect needs to know § Perhaps architecture offers real lessons, not just a metaphor? It is interesting and important to examine the fundamentals of building construction n Derive a notion of “architectural knowledge” as distinct from “vernacular design” Structure n Space n An architecture defines the arrangement of structural elements in a system n n Relates to form, function and characteristics Architectural style is the underlying structuring principle and philosophy Construction is both a physical and spatial transformation of a pre-existing situation At the most elementary level, a building is a construction of physical elements or materials into a more or less stable form, as a result of which space is created which is distinct from the ambient space. [Hillier1996] n But any structure contains a distribution of responsibility n In complex structures this is often a sociological as much as a technical choice Boundaries n Neighborhoods as Domains n Building has a logical aspect too n Separates notions of “inside” and “outside” n The logical structure of an architecture is based on spatial domains… n n Architecture addresses the complex whole of interrelationship between such domains Buildings, rooms, alcoves, etc. Streets, alleys, hallways, corridors, doors, etc. Christopher Alexander strongly reflects this idea of a configuration based on logical coupling, cohesion, and connections in some patterns And connection domains between them... n n And on how they are configured as a whole n The drawing of a boundary establishes not only a physical separateness, but also the social separateness of a domain– the protected space – identified with an individual or collectivity which creates and claims special rights in that domain. [Hillier1996] Neighborhood Boundary “The strength of the boundary is essential to a neighborhood. If the boundary is too weak the neighborhood will not be able to maintain its own identifiable character….” “… Encourage the formation of a boundary around each neighborhood, to separate it from the next door neighborhoods. Form this boundary by closing down streets and limiting access to the neighborhood….” “… Place gateways at those points where the restricted access paths cross the boundary; and make the boundary zone wide enough to contain meeting places for the common functions shared by several neighborhoods.” [Alexander+1977] (pp89-90) Exercise 1: Configurational Knowledge Consider the A B C 1 squares in this grid to be spaces; the green lines to be walls. At B3 is an external entrance; use exactly 8 other internal entrances to connect the rooms so that every room is accessible 2 3 Configuration of Space n Configuration of Space In the previous slide 3 notional courtyard buildings are shown n n n a b c n Same basic physical structures and cell division Same number of internal, external openings Lower figure highlights space as against normal view of ‘structure’ above ‘Only’ difference is the location of cell entrances n n But this radically changes the patterns of movement through the buildings Which offers more opportunities for “private” space? Dependencies n Software and “Space” n n n n n n Consider rooms A2, B2 and C2 in each of the configurations a, b and c and the routes by which they can be reached etc. Which other rooms is each directly dependent on? Which other rooms is each indirectly dependent upon? Which other rooms directly depend on A2,B2 and C2? Are there any parallels with software? Software does not deal with physical spaces But space is not merely a physical construct in architecture of the built environment n Also embodies notions of logical and social spaces n We can consider modules, packages, components etc., to occupy virtual spaces in software n And connectors to be access paths to these spaces which make them interdependent n Therefore the knowledge of how to put modules and connectors together appropriately is configurational Software, Space and Dependency A B A B Architecture Enables Creative Design n Design is a creational and intentional act n Conception and construction of a structure on purpose for a purpose n A B C ‘Good’ architecture provides forms which enables creativity rather Design is the activity of aligning the structure of the than dictate design application analysis with n Form is liberating the available structures of the solution domain [Coplien1999] Significance of Office Buildings n Office Architecture: 2 Traditions n Icons of the 20th Century n North American vs. North European n n Office towers dominate the skylines of cities on every continent At least 50% of the population of industrialized countries work in offices As foci for administrative and information generating work n n n n n n In function they stand closest to computing n Skyscrapers in Chicago, ground hugging buildings in Stockholm City centre in NA, suburban in NE Tall and deep in NA, short and narrow in NE Space efficient in NA, rambling in NE Corporate domination of requirements in NA, workers’ requirements better reflected in NE “Computer” originated as a term for number crunching clerks! The North American Tradition n Exemplar: Empire State Building Forces driving the North American tradition n n Late 19th century economic boom in Chicago and New York Rapid exploitation of new technology n Steel frame, elevator, electricity, air conditioning Buildings as multipliers of land value, speculator and regulator struggle, “form follows finance” n Advances in real estate financing, city planning n n Taylorist management theory Exemplar: Empire State Building n The North European Tradition n Architectural features of the Empire State Building 1930-31 n Forces driving the North European tradition n North European cities have long histories n n n n Standardized construction elements to maximize efficiency Highly service central core on each floor Surrounded by continuous “race track” of subdivisible, rentable space Relations between landlord and tenant dominate other (e.g. functional) concerns Historically established patterns of land ownership Direct Bank loans, rather than share issues, dominate the financing of construction Offices often customised for specific uses by client Statutory based negotiating procedures for working conditions, etc. n Financing n n n Social democratic political climate n Exemplar: Ninoflex Building Exemplar: Ninoflex Building n Architecture of the Ninoflax Building, 1962 n n n “Office landscaping”, open plan interiors, wall to wall carpeting, break areas Complex, dynamic, “more organic” geometry Based on a theoretical understanding of office processes and communication, rather than needs of syndicated investors/speculators Office Architecture vs. Design n Architecture as Configurational Knowledge n Complex forces shaping the two traditions reveal themselves only in retrospect n To summarise, architectural knowledge n n Most office architects took (at least some) of the prevailing forces for granted n The essentially architectural knowledge was hidden, and transmitted culturally It is clear from this analysis that architecture does not depend on architects, but can exist within the context of what we would normally call the vernacular. [Hillier1996] Deals with process, organisation as well as “product” Recognises that the “whole” is greater than the sum of its parts n n That a design choice in one place will have unintended side effects elsewhere that have to be imagined n structure “carves out” space and dealt with in design Physical, logical, social n Deals with multiple kinds of “spaces” n Architecture as Non-discursive Knowledge n n Exercise 2: Non-discursive Knowledge 1 12 6 1 1 6 1 14 6 5 9 5 9 5 9 14 3 2 4 ? 7 2 4 ? 7 2 4 ? 7 8 Architecture is knowledge “to-design-with” rather than knowledge “of” a design This kind of knowledge is inherently difficult to express (“non-discursive”) n Creative, not analytical thought “learning-by-doing” 8 n Is typically acquired socially n 25 3 15 3 n Only becomes explicit when different sets of configurational rules are compared and contrasted n 8 E.g., different “styles” of office building Explicit Architecture n Three Filters of Applied Architectural Knowledge Function imposes restraints on the configuration of space. Hillier (1996) suggests that three ‘filters’ are applied between the ‘field of possibility’ and the architectural reality: § Generic Function § Architectural knowledge is, therefore, normatively n n Configurational Non-discursive n It tends to be made explicit only when there is a need to contrast normative approaches n What type of building is it? What aspects are typical for this kind of building? To distinguish Gothic and Romanesque cathedrals § n …But it always exists, even in vernacular design n Cultural requirements for that type of building § Where it is implicit: “the way things are done here” § Idiosyncrasies of structure and expression § What uniquely distinguishes this building from all others? Exercise 3: Reflection on Design Knowledge n Building for Change Usage centered approach to office building requires a process that embraces change over time Changeability is also a feature of the product The crux both builders and architects face is coming to terms with time. In technical terms this means shifting from a professional industry based on the assumption that the relationship with the client is synchronic (that is, each transaction is separate and each comes at a unique moment in time) whereas we should be trying to devise professional professional and tech nical services which are diachronic (that is, continuing and developing through time). Consider the following creative professions. How do these practitioners gain ‘configurational knowledge’? n n n n n n Blacksmith Wheelwright Artist Novelist Architect (of the built environment) Software Engineer [Duffy+1998] Designing in Slippage n n Shearing Layers n n Flexible process requires building in slippage Recognizing that change is both inevitable and necessary over time “Leeway” has to be designed in so that products do not become brittle when faced with change n Shearing layers [Brand1994] underpin the process of new office design n n We don’t want to have to start again from scratch n Build in slippage between “layers” so that buildings don’t tear themselves apart as usage changes Layers constructed on the basis of different change rates Changes therefore get localised to particular layers Brand’s Six Ss STUFF The Six S’s of Shearing Layers (1) n SKIN n n SPACE PLAN Site Permanent or semi-permanent Determined by geology, land-ownership etc. Typically sixty years for an office building SERVICES STRUCTURE n Structure n SITE The Six S’s of Shearing Layers (2) n Shearing Layers 1 Site 1 is built on Structure 0..* 1 Space Plan 1..* Services Skin Services n Plumbing, wiring etc., changes every 7 years or so The division and sub-division of ‘social spaces’ tends to change every 5 years or so on average Furniture, plantpots, other movables etc., can change daily n Space Plan n n Stuff n Stuff * Exercise 4: Reflection on Shearing Layers n Lessons for Software Architecture n Can you think of any analogues in software for the following?: n n n n Site Services Space Plan Skin ‘Architectural Knowledge’ is fundamental to successful, usable design in the new millenium n It can be regarded as design imagination Especially in vernacular design “Culturally transmitted” n It is by nature ‘configurational’ and often tacit n n Is there a “one-size fits all” layer plan for software? n It is knowledge that is socially acquired n n n It is both deontic and time -ordered It is not reducible to “high level structure” n Affects process and organisation too Structure and Space in ObjectOriented Software INFO3011 Software Architecture and Design downloadable in *. format pdf ‘Space’ in Software n Software has no physicality n n n Michael Jackson says in order to create virtual machines we just create them Fred Brooks Jr. says software is “pure thought stuff” Source code is just a set of instructions that translates into machine instructions n N.B. strictly, therefore, source code is a specification of an executable program n But in architecture (of the built environment) space is a logical as well as a physical concept n Software has logical dependencies Object-Oriented Software Construction n Responsibility-Driven Design (1) n Objects and Classes are behavioural abstractions n Designing object systems involves n We separate objects in Class A from those in Class B on the basis of their different behaviour n But in the machine an object instance is a data abstraction n n n Identifying behavioural abstractions (Object Types) Assigning them responsibilities Mapping Object Types to Object Classes n n A pointer or reference is returned to the object’s data variables ONLY n Enforcing encapsulation and information- hiding Creating Interfaces so that client objects know how to request executable behaviour from server objects and the methods that implement them I.e. each object instance has its OWN copy of the data, but no individual operations – these belong to the class as a whole n Turning responsibilities into operations n n Objects are therefore logical abstractions n n They don’t really exist at all at machine-level! Turning ‘collaborating classes’ into data members to hold Object IDs Responsibility-Driven Design (2) n n CRC (Class, Responsibility, Collaboration) Cards CASE tool is The Class Responsibilities Collaborators a 6” x 4” index card! A well-established technique for Responsibility-Driven Design is CRC cards 6” x 4” index cards n n Divided into 3 fields (Class, Responsibility, Collaborators) One for each candidate Object n Used to role-play scenarios to see if responsibilities have been distributed properly n Each person “role-plays” a class (i.e. a CRC card) to explore distribution of responsibilities Cheap and fun way to validate the dynamic behaviour of object systems prior to coding! Encapsulation and Information Hiding Class name Encapsulation n Robot - grid: Grid “data members”, usually private or protected and therefore hidden from clients Operations, if public, form the public interface to the class: note all method implementations, whether for private or public operations, are hidden Encapsulation is the hiding of all design decisions that the client doesn’t need to know about. Typically this includes: n n n n +turnLeft( ) +turnRight( ) +moveForward( ) +reverse( ) +pickUp( ) Data structures Collaborating classes and objects Methods Private Operations etc., n An object is a therefore a sort of protected virtual space n Like a “neighbourhood” in the previous lecture Single Responsibility Principle n Separated Responsibilities Computational Geometry Application Naïve approach Computational Geometry Application Geometric Rectangle +area():double A seemingly simple, but actually quite subtle, principle of class cohesion is the Single Responsibility Principle: n Rectangle +draw() +area():double Graphical Application A class should have only one reason to change GUI Separated Responsibilities Graphical Application Rectangle +draw() n In practice this requires that the class be an abstraction of only one thing (a neighbourhood of its own?) GUI OO Design Principles n Interfaces (1) n Two other OO design principles are wellknown n They have been around since the late ’80s Ideally we would like classes and objects to be completely decoupled from each other n n The Open-Closed Principle n n Software entities should be open to extension, but closed to modification Mostly associated with class -based inheritance n n But references (objectID’s) are needed otherwise programs won’t work Collaboration requires some objects to know how to call other objects and request their behaviour Compare with gateways and access paths in “Neighborhood Boundary” pattern In Java a special Interface construct is provided In C++ an Abstract Class can be used as a protocol class to the same effect n The Liskov Substitutability Principle n Therefore Interfaces are needed n n But uncontrolled inheritance creates unwanted dependencies Only subclass when you know you can safely substitute an instance of the subclass for any of its superclass’ instances n n Interfaces (2) n Interfaces in UML <> Runnable run ( ) MyThread Runnable <> Class icon stereotyped to represent an Interface Interfaces should be designed to be stable n Operation names and parameters of abstract behaviours MyThread n Implementation can therefore vary without the Client object needing to know n n Different methods, even different (collaborating) objects can handle the request for executable behaviour Client only needs guarantee that the behaviour will be performed correctly in response to the request (message) run ( ) n N.B. A class can support 1 or many interfaces run ( ) Alternative “lollipop” notation The Significance of Interfaces for Architecture n The Dependency-Inversion Principle The use of interfaces can be seen as an application of the Dependency -Inversion Principle: a.High-level modules should not depend on low-level modules. Both should depend on abstractions b.Abstractions should not depend on details. Details should depend on abstractions. An interface can be thought of as an access path or gateway to an encapsulated “space” n Space can be an object instance, a class, a package or any logical computational component n We need to narrow interface bandwidth between spaces n An interface also implies a dependency n n If Class A holds a reference to Class B it is dependent upon it (e.g., may not be compilable without it) If the Interface is physically separate from the class that realizes it and the reference is to the Interface the client is only dependent on the Interface (recommended) n Interfaces can form a “scaffolding” for the system Naïve Layering Scheme Policy Layer ‘Inverted’ Layers Policy Layer Policy Service Interface <> Mechanism Layer Mechanism Layer Mechanism Service Interface <> Utility Layer Abstraction ‘levels’ Utility Layer The Interface-Segregation Principle n Interface Segregation Using Delegation ‘Delegated’ solution Timer Timer Client +TimeOut( ) <> <> n Interfaces can become “fat” with too many loosely related operations. This leads to the Interface Segregation Principle: Clients should not be forced to depend on operations that they do not use n Timer Door Door Timed Door Naïve approach Timer Client +TimeOut( ) Timed Door DoorTimedOut () If the ‘unused’ operations change, the client is still affected DoorTimerAdapter +TimeOut( ) <> <> Cyclical Dependency Class A Class B The arrowhead on the association means Class A has a reference to Class B built into its own definition. Therefore A is dependent on B Class A and Class B depend on each other; neither can be reused without the other Class A depends on Class B, but Class B depends on Class C and Class C depends on Class A. Class B is therefore transitively dependent on Class A Different Kinds of Dependencies n B is directly dependent on A n n Class A Class A Class B Class B n if B is a subclass of A if B holds (as a data member) a reference or pointer to A If B refers to A in a parameter in one or more of its operations n In which cases it “uses” A n If B refers to A in the implementation of any of its methods If any other class that B is dependent on is dependent on A n B is indirectly, or transitively dependent on A n Class C I The UML Package Construct n Principles of Package Cohesion n UML has a construct higher than a class n C B n Represents a “namespace” for collecting UML elements n n The package n n Same dependency rules apply Often a collection of logical classes E.g/. Collaboration, component This arrow means “DependsOn”. If the package collects classes it means at least one class in package C depends on at least one class in package B There are 3 principles of package cohesion that help developers decide how to partition classes into packages: The Reuse-Release Equivalence Principle n The granule of reuse is the granule of release The classes in a package are reused together. If you reuse one class in a package you reuse them all The classes in a package should be closed together against the same kinds of changes. A change that affects one package affects all of the classes in that package and no other package n The Common Reuse Principle n n The Common Closure Principle n Principles of Package Relationships n Dependency Heuristics n n There are three principles dealing with the relationship between packages: n The Acyclic Dependencies Principle n Minimize all dependencies As far as possible make dependencies unilateral n n Allow no cycles in the package dependency graph n n The Stable-Dependencies Principle n Avoid cyclical dependencies n i.e. “one-way” In the previous diagram (top) Class B is reusable and, provided its interface doesn’t change, can be reimplemented without disturbance to Class A They seem unilateral but have transitive dependencies Depend in the direction of stability A package should be as abstract as it is stable n The Stable-Abstractions Principle n n Only use bilateral or cyclical dependencies if classes are designed to work together in ALL circumstances n In which case package them together as collaborations or components Levelisation n A Levelized OO System Level 3 A Level 2 B C Levelisation is desirable n n Assuming a “bottom” level 0 each component in a dependency hierarchy can be assigned a unique level number Implies a structure which is a Directed Acyclic Graph (DAG) Abstract, stable (unchanging) classes tend to be at or near level 0 Concrete, volatile (often changing) classes tend to be at the highest levels n n In “good” OO System Structures n F D E Level 1 n Level 0 G H We want to minimise the number of classes dependent on changeable classes Analysing Structure in OO Systems (1) n n Simple measurements can be used to measure the structural quality of OO systems Abstractness n Analysing Structure in OO Systems (2) n Relational Cohesion n the total number of abstract classes (and interface types in Java) divided by the total number of classes and types. The measurement range is 0..1 The number of efferent couplings (Ce) divided by the number of efferent couplings plus the number of afferent couplings(Ce +Ca). Range is 0..1 n n Relational cohesion (H) is the total number of internal Relationships (R) plus 1, divided by the total classes within the package (N) n n n Stability/Volatility n H=(R+1)/N The ‘plus 1’ prevents H being 0 when N=1 and represents the relationship of the package itself to all the classes within it Ce is the number of classes outside a package that classes inside the subject package directly depend upon Ca is the number of classes outside the package that depend on classes inside subject the package Analysing Structure in OO Systems (3) n Stability Graph 1 Abstractness n All of these metrics can be arrived at by mapping class relationships on a spreadsheet The values of Abstractness, Stability can be plotted on a Stability Graph There should be some highly stable, highly abstract packages in a “good” design Most packages should be distributed in the graph in positions close to this line: the ‘Main Sequence’ There should be some highly concrete, highly volatile packages in a “good”design 0 Volatility 1 Distance from the Main Sequence n Summary (1) n n The Main Sequence is idealized by the line (A+S = 1) n Where A= abstractness, S= stability n Any package’s distance from the main sequence can be calculated by the formula n Objects are logical structures to which responsibilities are allocated in design Objects can therefore be thought of architectural spaces n D = |(A+S -1)/SQRT(2)| n As can Classes, Components and Packages n Can be normalized to a range 0..1 by n N.B.this means ignore signing range is 0..0.7 D’ = |(A+S-1)| n We can apply the lessons of “Neighbourhood Boundary” n n The value of D or D’ which is closer to 0 the better Use encapsulation, Interfaces to minimize dependencies Summary (2) n There are 5 structural principles of class design n Liskov, Open-closed,Single Responsibility, Dependency-Inversion and Interface Segregation Reuse-Release Equivalence, Common Reuse,Common Closure Architectural Styles INFO3011 Software Architecture and Design n There are 3 principles of package cohesion n n There are 3 principles of package relationships n n Simple metrics allow us to evaluate the structure of OO systems Acyclic Dependencies,Stable Dependencies and Stable Abstractions Architectural Styles n Common Architectural Styles n Shaw and Garlan present a number of architectural styles, identified by asking: n What is the design vocabulary ? n Shaw and Garlan identify Seven common architectural styles n n n n n n n n n n n n n What are the allowable structural patterns? What is the underlying computational model? What are the essential invariants of the style? What are some common examples of its use? What are the advantages/disadvantages of use? What are the common specialisations? types of connectors and components Pipes and filters Objects Implicit invocation Layering Repositories Interpreters Process Control Pipes and Filters n n Pipes and Filters: Structure Each component has a set of inputs and outputs Component reads streams of data on input and applies local transformation incrementally n Output begins before input is fully consumed n n Components are termed filters, connectors termed pipes Filters must be independent entities n n Should not share state with other filters Should not know identity of upstream and downstream filters ‘Data Abstraction and OO Organization’ n Event-based, Implicit Invocation n n Data representation captured as Abstract Data Type An ADT (or object) is representative of a ‘manager’ component n n n Responsible for preserving integrity of a resource Hides representations from other objects n n Object Ids are a disadvantage n n Style historically rooted in systems based on actors, constraint satisfaction, daemons and packet-switched networks Components’ interfaces present a set of procedures and a set of events Announcers of events do not know who will react Events are “broadcast” Provides strong support for reuse Repositories n Interpreters n Two major subcategories n Databases n A virtual machine is produced in software. Interpreter includes n n Blackboard architectures n Transaction types are main triggers Current state is main trigger pseudoprogram n n n Blackboard architectures have three main parts n n n interpretation engine n Which includes program and activation record Which includes definition of interpreter, and its current state of execution Knowledge sources Blackboard data structure Control n Four components n Interpretation engine, a memory, representation of control state, representation of current state of program being simulated Attribute Based Architectural Styles n Definition of an ABAS 1. Klein & Kazman present Attribute Based Architectural Styles (ABAS) n n Architectural Styles as defined by Shaw etc. include n n “Next generation” of Architectural Styles n Description of component types and topology Description of pattern of data and control interaction amongst the components Informal description of costs and benefits of the use of the style n 2. 3. n ABAS move towards basing such reasoning on formal quality attribute-specific models E.g., “Use pipes and filters when reuse is desired and performance is not a top priority” The topology of component types and a description of their data and control interaction A quality attribute-specific model that provides a method of reasoning about the component types that interact The reasoning that results from applying the attribute-specific model to the interacting component types Example: a pipes-and-filter performance ABAS n Mapping Architectural Styles to Attribute Models Architectural decisions Architectural properties stimuli A pipes-and-filter performance ABAS would n n n n n Describe what it means to be a pipes -and-filter Describe how its components can be legally connected Describe a queuing model of pipes -and-filter Describe the rules to instantiate a pipes -and-filter Provide the expected results of solving the resulting queuing model under varying sets of assumptions Quality Attribute Model Parameters Quality Attribute Models Actual behaviours ? Desired behaviours n Formal analysis supports “What if…?” questions n ? Predicted behaviours E.g.,What is the effect on performance of moving this behaviour to this component in pipes -and-filter?” Structure of an ABAS n Quality Attribute Model Parameters n An ABAS has a 5-part structure n n n n n Problem description n Describes design problem to be solved inc. quality attribute of interest e.g., performance, context of use, constraints etc., Quality attribute measures n Descriptions of measurable aspects of the quality attribute model, including discussion of stimuli – events that cause architecture to respond or change Architectural style Quality attribute parameters Analysis n Description of how the quality attribute models are formally related to the elements of architectural style and conclusions about architectural behaviour predicted by the models Quality Attribute Measures n Expression of non-functional requirements in terms that are measurable or at least observable Non-functional properties of the architecture Adjustable, determine whether dependent attributes will satisfy requirements Events that the architecture will have to respond to n Quality Attribute Parameters n n n Stimuli n Example: Performance Performance measured by measured by Example (Contin.) n Quality attribute concerned with timeliness Stimuli n Latency Throughput In this example the changes of state to which the architecture must respond. The pattern by which events arrive is important for performance: n n Quality attribute measure that measures time from initiation of an event until its completion Quality attribute measure that measures the rate at which a system can respond to events n Periodic: fixed interval between events Sporadic: there is a limit on how short the intervals between events are, but they are not fixed Random Example (contin.) n Using an ABAS n System Response n n n When a stimulus occurs the system uses resources to carry out computations or transmit data Multiple concurrent stimulus responses need a scheduling policy to resolve conflicts Therefore Quality Attribute Parameters include: n n ABAS are designed to map architectural styles onto attribute models n In the following example we are interested in high levels of availability for a system under construction Quality attribute measures n n n Resource characteristics: Type of resource (e.g., CPU or network) and characteristics (e.g.,speed, bandwidth) Resource scheduling policy (e.g., CPU scheduling, CPU allocation, bus and network arbitration, queueing policies etc.) Resource usage (e.g., priority of processes, messages, pre-emptiveness, execution time etc.) Reliability/Availability Attribute Model n n n n Steady state availability: portion of time a system is working Reliability: mean time to failure Faults detectable: passive failures(detectable by timeouts), active failures, timing failures, semantic failures Stimuli: types of failures, repairs and their rates Availability/Reliability Attribute Model (contin.) n The Simplex ABAS n Quality attribute parameters n n n Detection: mechanisms for detection of failures (E.g., voting, post-condition checking, deadline detection etc.) Recovery: mechanisms for recovering from failure inc., forward and backward recovery mechanisms Modes: A system can operate in various degraded modes with different availability/reliability Input The Simplex ABAS is one of a family of architectural styles that utilise redundancy to deliver Availability Leader R1 R2 Safety Decision and Switch Output A Note on Redundancy n The Simplex ABAS n The Simplex pattern consists of multiple redundant components and uses Analytical Redundancy… n Problem Description n i.e. possibly different input; different implementation; possibly different output n n Manual and automatic steering mechanisms for a car are analytically redundant: do the same thing in different ways n Quality Attribute Measures and Stimuli n How to introduce redundancy to ensure proper level of reliability/availability without introducing common mode failures? How to upgrade a system without compromising reliability/availability? What types of fault need to be tolerated? n n …and a Detection/Switch component n Timing faults(e.g.,overruns), semantic faults (wrong output values) and system faults (e.g., memory overruns) Data flows into one or more components which send their output to the component that detects failure, switches to an alternative component and possibly initiates recovery of the failed component n n What are the allowed levels of (degraded) service? What is the reliability/availability for each level of service? n There is a specified desired level for the upgraded or higher performance level of service and another for the baseline level of service The Simplex ABAS ( Contin.) n The Simplex ABAS ( Contin.) n Architectural Style n n n n The Simplex style is an instance of the redundancy style in which the components are processes. The components don’t necessarily receive the same input or generate the same output. They are not all peers. They are analytically redundant. The “leader” is the upgraded version of the critical component. All components execute concurrently. The Leader’s output is used if it passes the acceptance test of the “Decision and Switch” unit. If it fails, a new leader is picked (R1 or R2) The “safety” is a highly reliable, low performance component used only as a last resort Quality Attribute Parameters n n Analytic Redundancy A leadership -based “voting” mechanism is used n i.e. test requires that the “leader” output agrees with a specific percentage of other redundant component’s outputs n Estimates are needed for failure rates and repair rates of the various components n Failure rates for the “safety” and the “decision and switch” units should be relatively much lower than for other components The Simplex ABAS ( Contin.) n Modelling use of Simplex (1) K1 F F QR Analysis n n n To model the availability of this style you have to make estimates of the failure and repair rates of the components to calculate the system’s availability. Reliability growth models can be used for obtaining estimates. In addition, architectural styles can be compared simply by making assumptions about various repair and failure rates. State 2 = two highperformance components outputs are compared; State 1 = when they disagree; the “right” one is picked State K1 = when they disagree the wrong one is picked and the “safety” is used State 1 = use of other high performance component State K2 = state after failure in state 1 2 1 R F R=Repair rate F= Failure Rate QR= Quick Repair rate R K2 Modelling Use of Simplex (2) n Benefits of ABAS n Previous slide shows use of a “Markov model” applied to Simplex architecture n n n Based on states of the system, transitions between the states, and times to make the transitions Can be used as a basis of comparison with other candidate styles (e.g. Majority Voting ABAS) to see which is best (The relatively quick repair rate from K1 to 1 is at the heart of Simplex and means it is better if low transition rates are needed) n ABAS’ are natural extensions to Shaw and Garlan’s Architectural Styles Klein and Kaplan claim that Architectural Styles are made more rigorous by association with analytical models of quality n Quality attribute models n Permit the designer to predict the behaviour with respect to some desired quality Mapping from Architectural Styles to Analytical Models n Future Perspectives for Using ABAS n From a designer’s perspective n There is a set of decisions that accompany turning a style into an implemented design n n n E.g., decomposition of a system requires allocation functions to processes Allocation of processes to processors For a performance style priorities might also need to be allocated n Klein and Kazman suggest that repeating such questions again and again will lead to checklists Answers to questions will form new input into analytical models n n From an analyst’s perspective n There is a set of questions accompanying the style that aid in understanding it n n Key linkage is that architectural parameters are explicitly linked to parameters in the analytical model Therefore solving the model is the same as modelling expected architectural behaviour “pre-packaged design and/or analysis wisdom” can be looked up Communication mechanisms, connections speed etc., n Propose a handbook of ABAS’ n ABAS, Architecture and Engineering n Klein and Kazman conclude that ABAS are the start of an attempt n Architectural Patterns INFO3011 Software Architecture and Design n n To make architectural design more of an engineering discipline Where design decisions are based upon known properties and well-understood analyses Instead of “the currently popular practice of ‘patch-and-pray’”. Pattern-Oriented Software Architecture n Origins of Patterns n n Frank Buschmann, Regine Muenier, Hans Rohnert, Peter Sommerlad, Michael Stal.1996.Patterns of Software Architecture Presented three categories of patterns n n n There are a number of primary sources for the emergence of Software Patterns n n n Architectural Patterns Design Patterns Idoms To see difference we need to look at origins of Software Patterns n n n Have been confused with Architectural Styles n PhD work on frameworks by Eric Gamma Contract specification by Richard Helm Smalltalk frameworks by Brian Foote and Ralph Johnson Software Architecture handbook by Bruce Anderson But the patterns form originates in the built environment with the work of Christopher Alexander A Brief History of Software Patterns n Christopher Alexander n n n 1989: Alexander’s ideas introduced by Kent Beck, Ward Cunningham 1991-4: OOPSLA workshops on Software Architecture n Born in Vienna, educated in Britain and the US A leader of “post-modern” architecture n Gamma, Helm, Johnson and Vlissides meet n n n n 1993: Hillside group formed 1995: Design Patterns book published 1996: Alexander’s keynote at OOPSLA n Driven by observation that most of what humanity has built since WWII has been dehumanising rubbish Believes architecture impacts directly on our behaviour and well being n “Tall buildings make people mad” n Professional architects have failed humanity and the environment Views are controversial even amongst architects Christopher Alexander (2) n Christopher Alexander (3) n Work is represented in an 11-volume series of books (8 currently in print) n n n n n n n n n n n The Timeless Way of Building A Pattern Language The Oregon Experiment The Linz Café The Production of Houses A New Theory of Urban Design A Foreshadowing of 21st Century Art The Mary Rose Museum The Nature of Order Sketches of a New Architecture Battle: The story of a Historic Clash Between World System A and World system B Also presented a critique of modern design in Notes on the Synthesis of Form (1964) n n Identified cognitive complexity and the alienation of builders from users as the root of failure of modern design Later proposed “pattern languages” as a way of recovering lost ability to design useful things Homeostatic Structure n Biological Forms n n n n Alexander’s criticism of modern design is rooted in the belief that we have lost the ability to create ‘homeostatic (self-adjusting) structures’ In homeostatic structure the failures of form are ‘one-offs’ The culture/tradition that supports them changes more slowly n An individual tree is an homeostatic structure It responds, genetically, to the local availability of sunlight and rain n Through numbers of leaves, branches Through achieving maximum height By bending its shape n To competition n n n Each failure is easily accommodated, equilibrium between form and context is dynamically reestablished after each ‘failure’ Strongly resists all changes other than those provoked by failure Is embodied in a culturally acquired “pattern language” n To wind n n Each individual tree’s shape fits its individual context Reasons for Modern Design Crisis n Solution: Recreate the Pattern Languages n n Design tradition has been decisively weakened n In face of new requirements, new materials Professionalisation of architecture separates designers from users Has an unachievable responsibility Cognitive burden too large n Feedback loop no longer immediate n n n The rising control of the designer n n Regard a pattern as a step which transforms an existing space Develop a language, shared by all stakeholders, that allows such steps to be applied individually in sequence Each application of a pattern creates a new space n A new context for the next pattern to be used Homeostatic solutions grow piecemeal No alienation of stakeholders from system, no artificial distances between stakeholders n Results n n A Pattern Language n Gradual Stiffening “The fundamental philosophy behind the use of pattern languages is that buildings should be uniquely adaptable to individual needs and sites; and that plans of buildings should be rather loose and fluid, in order to accommodate these subtleties…” “… Recognize that you are not assembling a building from components like an erector set, but that you are instead weaving a structure which starts out globally complete, but flimsy; then gradually making it stiffer but still rather flimsy; and only finally making it completely stiff and strong….” [Alexander+1977] (pp963-968, emphasis added)) Alexander’s book: “A Pattern Language” presents 253 patterns for the built environment n n Written in a standard, narrative form supported by hand-drawn sketches Includes patterns to build alcoves, rooms, houses, towns, cities and even global society A “pattern language” n Together the patterns form a network n Example of an Alexandrian pattern n Design Patterns n “Waist High Shelf” n n Proposes that every domestic home needs a “waist-high shelf” A convenient place to deposit office keys, car keys, mobile phone etc. n Design Patterns are elements of reusable software n n introduced to the OO community through Gamma E., et al, Design Patterns, Addison-Wesley, 1994 now a thriving “patterns community” n n Everything you don’t need at home, but do need for work Can be implemented in a number of ways n n inspiration from the built environment n see http://www.hillside.net /patterns Shelf; kitchen worktop; particular stair on stairway n Christopher Alexander, architect has written about patterns since at least 1973 n Is an abstract solution to a general, recurring problem in a particular context They provide the abstract core of solutions to problems that are seen over and over again Example of a Design Pattern (Simplified) n n State Pattern Applied CopyOfBook IsbnNumber:BookCode currentState:LoanStatus checkOut ( ) return( ) CopyOfBook “holds” an instance of EITHER Available or OnLoan at run-time (as appropriate) and passes on to it the messages it receives. Available and OnLoan have different implementations of checkOut () Available OnLoan LoanStatus {abstract} checkOut ( ) return( ) Example Design Pattern: State Use when n n Behaviour depends on current state or mode When otherwise a large switch statement or long if statement would need to be used n These are difficult to maintain n Solution n Abstract state-specific behaviour into a shallow inheritance hierarchy; instantiate the appropriate state object as needed at run-time The “Gamma Patterns” n The Gamma Pattern Template n n n n n n n n n n n n The patterns in the Design Patterns book are sometimes called “Gamma patterns” n After the lead author, Erich Gamma n Also called GoF or Gang-of-Four patterns n They are a catalogue of 23 patterns n n n n NOT a pattern language Each pattern is written in a standard template form Classified into Structural, Behavioural and Creational patterns Links shown via a Pattern Map Intent A.K.A. Motivation Applicability Structure Participants Collaborations Consequences Implementation Sample Code Known Uses Related Patterns Map of the Gamma Patterns Memento Iterator creating composites enumerating children Proxy Adapter Bridge avoiding hysterisis defining traversals Builder Shared Values of People Documenting Software Patterns n n Success is more important than novelty good patterns are discovered not invented adding responsibilities to objects sharing composites Composite composedusing Command adding operations sharing terminal symbols defining the chain Decorator Visitor adding operations Flyweight changing skin versus guts n sharing states sharing strategies Interpreter Chain of Responsibility Emphasis on writing down and communicating “best practice” in a clear way n Strategy defining algorithm’s steps State Mediator complex dependency management Observer Template Method Facade Prototype single instance often uses most patterns use a standard format - a patterns template which combines literary and technical qualities effort is to describe concrete solutions to real problems, not to theorise Factory Method configure factory dynamically implement using n “Qualitative validation of knowledge” n Singleton single instance Abstract Factory Creational Patterns Behavioural Patterns Structural Patterns Shared Values of People Documenting Patterns (contin.) n n Good patterns arise from practical experience Every experienced developer has patterns that we would like them to share. We do this in Pattern Writers’ workshops n n n n Characteristics of Software Design Patterns (e.g. Gamma et al)* Problem, not solution-centred Focus on “non-functional” aspects Discovered, not invented Complement, do not replace existing techniques Proven record in capturing, communicating “best practice” design expertise J. 1994.Design Patterns - Elements of Reusable Object -Oriented Software. Addison-Wesley n Respect and recognition for the human dimension of software development n n Full recognition that design is a creative, human activity Full respect for previous gains and conquests n * Gamma E., Helm R., Johnson R., Vlissides Architectural Patterns n Architectural Patterns n “An architectural pattern expresses a fundamental organising structural organization schema for software systems. It provides a set of predefined subsystems, specifies their responsibilities, and includes rules and guidelines for organizing the relationships between them” (p.12) Buschmann et al., present a catalogue that includes 8 architectural patterns in 4 categories n “From Mud to Structure” n n Distributed Systems n Layers, Pipes and Filters, Blackboard Broker n Interactive Systems n Model View Controller, Presentation-AbstractionController Microkernel, Reflection n Adaptable Systems n The Model-View-Controller Pattern (continued) Model View Layers Pattern:Example FTP TC P IP FTP protocol TCP/IP protocol FTP TC P IP TCP protocol Controller •M-V-C originated with Smalltalk-80 - Informs the entire architecture of modern Smalltalk environments •Microsoft’s Document-View architecture is an instance of M-V-C •Model = Document, View = View -So where is the Controller? (answer: it is MS Windows!) IP protocol Ethernet Ethernet protocol Physical connection Ethernet Layers Pattern n Layers Pattern: Structure Class LayerJ Collaborator Layer J-1 Context n large system needing decomposition How to structure systems that contain a mix of high and low-level functionality Conceptually layer the system, from level 0 upwards n Problem n n Solution n Responsibility Provides services to Layer J+1 Delegates subtasks to Layer J-1 Layers Pattern: Consequences n Layers Pattern: Variants n Benefits n n n n Reuse of Layers Support for standardisation Localisation of dependencies Exchangeability Cascades of Changing Behaviour Lower Efficiency Unnecessary work Difficulty of getting ‘granularity’ right Relaxed Layer System n n A.k.a. ‘open’ layered system Layer can talk to any layer below it n In ‘closed’ layer systems can talk only to the layer immediately below n Liabilities n n n n n Gains in performance, flexibility n Loses maintainability n Layering through Inheritance n Abstract classes at Layer 0 etc., Broker Pattern n Broker Pattern:Structure Client-side Proxy pack -data() unpack_data() send_request( ) return( ) 1..* Context n Broker main_event_loop() transfers update_repository() message register_service( ) acknowledgement() 1..* 1 find_server() find_client() forward_request() 1 forward_response() 1 calls uses API transfers message 1 1 Distributed, possibly heterogeneous system of independent co-operating “components” How to partition functionality to deliver a set of decoupled, interoperating components Introduce a Broker component to decouple clients and servers Server -side Proxy n Problem n pack -data() 1..* unpack_data() call_service( ) send_response( ) 1..* calls n Solution n calls 1 uses API 1..* 0..1 1..* 1 Client call_server() start_task( ) use_Broker_API Bridge pack_data() unpack_data( ) forward_message() transmit_message() Server initialise() enter_main_loop() run_service( ) use_Broker_API Broker Pattern: Variants n Broker Pattern: Consequences n Direct Communication Broker System n Clients communicate directly with servers, broker identifies the communication channel Servers use type of message to determine action Client-side servers provide service ids rather than server ids Benefits n n n n n n n Message Passing Broker System n n Trader System n Location transparency Changeability/Extensibility of components Portability Interoperability between Broker Systems Reusability Testing and Debugging Restricted efficiency Lower fault tolerance Testing and Debugging n n Adapter Broker System Callback Broker System n n Liabilities n n n Reactive, event-driven model; makes no distinction between clients and servers Presentation-AbstractionControl n Presentation-AbstractionControl: Structure Data repository Access to data Top- level PAC agent Context n Interactive systems with the help of agents Partitioning of interactive systems horizontally and vertically Structure the solution as a tree-like hierarchy of PAC agents Spreadsheet n Problem n n Solution n Intermediate-level PAC agent View Co-ordinator pie chart Bottom-level PAC agents seat distribution bar chart Presentation-AbstractionControl: Variants n n Presentation-AbstractionControl: Consequences n PAC agents as active objects PAC agents as processes Benefits n n n Separation of Concerns Support for Change/Extension Support for multi-tasking Increased system complexity Complex control components Efficiency Restricted applicability n Liabilities n n n n Summary n Patterns n n n n Open, informal, abstract solutions to a general, recurring problem in a particular context Capture “best practice” experience of design Can be organised as Catalogues or as Pattern Languages Differ from ABAS which are closed, formal composable abstractions Masterplans v Piecemeal Growth INFO3011 Software Architecture and Design n Architectural Patterns are a sub-category of patterns n n To do with “gross structure” But arguably ALL patterns are architectural The Current Debate on Software Architecture n Characteristics of the Masterplan “camp” n n October 1999 special issue of IEEE Software exposed a debate n n n Considers “Architecture” to be gross structure n Constrains, but is separate from, “lower levels of design” Edited by J.O. Coplien Editorial entitled “Re-eveluating the Metaphor…” Included text of Chris Alexander’s speech to OOPSLA 1996 conference Masterplan vs Piecemeal Growth In the Masterplan camp: Carnegie Mellon’s SEI In the Piecemeal Growth camp: The Patterns Movement n Utilises formal methods to present the semantics of architecture Emphasis is on design in the abstract n n n Identified two “camps” n n n Drawings, models as “blueprints” to be completed before implementation “Architecture is in the documentation”- Kazman n Formal software engineering processes used to guide practical software building n n E.g., Capability Maturity Model (CMM) Architectural Tradeoff Analysis Method (ATAM) Characteristics of Piecemeal Growth approach n Philosophical Differences n Rejection of abstract design n Cognitive complexity overcomes individual capacity to understand n Stress on architecture existing at all levels of scale n Carnegie Mellon’s SEI sees architecture as an extension of “software engineering” n Including “fine detail” n n Emphasis on an holistic, human-centred approach to design n Hence reliance on traditional Computer Science themes of formality, automation, process Implies a crisis of traditional Computer Science E.g., Scrum, DSDM, Xtreme Programming n Utilisation of “lightweight” processes n Holds to a “Logical Positivist” structure of knowledge Logical Positivism n The Positivist Hierarchy of Knowledge n Logical Positivism is a philosophy of science n n n Roots date back to Decartes Dominated academia in the nineteenth, early twentieth century Now in retreat in all disciplines except Computer Science Scientist is neutral observer/recorder of scientific truths Theories are established by reproducing observed phenomena in controlled laboratory experiments to test hypotheses Practical knowledge follows a linear, hierarchical model in this philosophy n First science, then engineering (“applied science”),then problem-solving Role performed Discovered by scientist Science applied by engineers Techniques applied by craftspeople Form of Knowledge Science Engineering Problem Solving n Positivism underpins “The Scientific Method” n n Critique of “Computer Science” n Software Development: Blum’s Critique n The alternative philosophy is “holistic” n n Allows for different forms of knowledge Utilises science from many different disciplines n E.g., anthropology, sociology n Regards computing as a design discipline n The essential aim of any software development is the construction of a solution(So) in software that meets a perceived need(N) n As opposed to a branch of mathematics N → So n N.B., this critique is broader than the debate in Software Architecture n n E.g., Client-led Design, Human Computer Interaction, criticisms of Prof. Bruce Blum,Michael Jackson’s Problem Frames Practically, most processes involve specifying (Sp) the solution (So) in advance of constructing it n N → So {N → Sp,Sp → So} Needs Imply Solutions (business) Need 0..1 implies (requirements) Specification The Process of Software Development Identify Needs Transformations Specify Requirements * 0..1 implies * (software) Solution Design and Construct Solution The Key Transformations n Software Development Processes n Recall that the mapping of a Need (N) to a Software Solution (So) involves two transformations n Most software development processes are n Solution-oriented n n Computer Science has developed formal means to aid in the production of a solution that meets a requirement n n N → So {N → Sp,Sp → So} The focus is on the ‘program-in-the-computer’ as an endproduct The process is initiated by a functional specification and tested against it n Specification-driven n n We are historically weak in ensuring that the specification meets a need in the first place! n n Sp → So “The program in the computer” (Bruce I. Blum) n Deadlines tend to squeeze out design n N → Sp “The program in the world” (Bruce I. Blum) n Since many solutions can meet a specification, effort spent on choosing the best solution is not on the critical path of the project N.B.All other design disciplines recognise that “problem setting” (creating the spec.) is also part of design Characteristics of a New Paradigm n Origins of Patterns n ‘Use value’ carries a higher premium than ‘provable correctness’ n The ultimate test of the ‘program in the computer’ is its usefulness as a ‘program in the world’ There are a number of primary sources for the emergence of Software Patterns n n n n An increased attention to Non-functional Requirements n n Operational (performance, robustness etc.) Developmental (reuse, ease-of-maintenance etc.) n n PhD work on frameworks by Eric Gamma Contract specification by Richard Helm Smalltalk frameworks by Brian Foote and Ralph Johnson Software Architecture handbook by Bruce Anderson n The importance of ‘Design’ n ‘form-fitting’ to meet the above is non-trivial But the patterns form originates in the built environment with the work of Christopher Alexander A Brief History of Software Patterns n Christopher Alexander n n n 1989: Alexander’s ideas introduced by Kent Beck, Ward Cunningham 1991-4: OOPSLA workshops on Software Architecture n Born in Vienna, educated in Britain and the US A leader of “post-modern” architecture n Gamma, Helm, Johnson and Vlissides meet n n n n 1993: Hillside group formed 1995: Design Patterns book published 1996: Alexander’s keynote at OOPSLA n Driven by observation that most of what humanity has built since WWII has been dehumanising rubbish Believes architecture impacts directly on our behaviour and well being n “Tall buildings make people mad” n Professional architects have failed humanity and the environment Views are controversial even amongst architects Christopher Alexander (2) n Christopher Alexander (3) n Work is represented in an 11-volume series of books (8 currently in print) n n n n n n n n n n n The Timeless Way of Building A Pattern Language The Oregon Experiment The Linz Café The Production of Houses A New Theory of Urban Design A Foreshadowing of 21st Century Art The Mary Rose Museum The Nature of Order Sketches of a New Architecture Battle: The story of a Historic Clash Between World System A and World system B Also presented a critique of modern design in Notes on the Synthesis of Form (1964) n n Identified cognitive complexity and the alienation of builders from users as the root of failure of modern design Later proposed “pattern languages” as a way of recovering lost ability to design useful things Homeostatic Structure n Biological Forms n n n n Alexander’s criticism of modern design is rooted in the belief that we have lost the ability to create ‘homeostatic (self-adjusting) structures’ In homeostatic structure the failures of form are ‘one-offs’ The culture/tradition that supports them changes more slowly n An individual tree is an homeostatic structure It responds, genetically, to the local availability of sunlight and rain n Through numbers of leaves, branches Through achieving maximum height By bending its shape n To competition n n n Each failure is easily accommodated, equilibrium between form and context is dynamically reestablished after each ‘failure’ Strongly resists all changes other than those provoked by failure Is embodied in a culturally acquired “pattern language” n To wind n n Each individual tree’s shape fits its individual context Reasons for Modern Design Crisis n Solution: Recreate the Pattern Languages n n Design tradition has been decisively weakened n In face of new requirements, new materials Professionalisation of architecture separates designers from users Has an unachievable responsibility Cognitive burden too large n Feedback loop no longer immediate n n n The rising control of the designer n n Regard a pattern as a step which transforms an existing space Develop a language, shared by all stakeholders, that allows such steps to be applied individually in sequence Each application of a pattern creates a new space n A new context for the next pattern to be used Homeostatic solutions grow piecemeal No alienation of stakeholders from system, no artificial distances between stakeholders n Results n n A Pattern Language n Alexander and Piecemeal Growth n n Alexander’s book: “A Pattern Language” presents 253 patterns for the built environment n n Written in a standard, narrative form supported by hand-drawn sketches Includes patterns to build alcoves, rooms, houses, towns, cities and even global society n Christopher Alexander’s view can be found in his pattern, Gradual Stiffening He contrasts the work of the master carpenter… n n Seems to work smoothly, effortlessly to construct a quality product But actually builds in slippage and makes corrections through each “iteration” “panic stricken by detail” Needs a complete blueprint before making first step n For FEAR of irrecoverable failure n Together the patterns form a network n … with the novice apprentice n n A “pattern language” Alexander:Gradual Stiffening “The fundamental philosophy behind the use of pattern languages is that buildings should be uniquely adaptable to individual needs and sites; and that plans of buildings should be rather loose and fluid, in order to accommodate these subtleties…” “… Recognize that you are not assembling a building from components like an erector set, but that you are instead weaving a structure which starts out globally complete, but flimsy; then gradually making it stiffer but still rather flimsy; and only finally making it completely stiff and strong….” [Alexander+1977] (pp963-968, emphasis added)) Patterns and Pattern Languages n There are broadly two views of software patterns n Both have value n Patterns as “paramaterised collaborations” n n n e.g., in the Unified Process “Elements of reusable OO design” Catalogues, e.g. GOF book n Pattern Languages n n A “piece-meal growth” view of Architecture Shared and used by all stakeholders to generate usable solutions Pattern Languages in Software n Summary n The examples are few but growing n Jim Coplien’s ‘Generative Development-Process’ pattern language n In contrast to the Masterplan approach, piecemeal growth n A language of organisational patterns to help design highly productive software organisations For validity checking on data in interface design For re-architecting legacy systems n Rejects the possibility of designing large structures in advance in the abstract n n Ward Cunningham’s CHECKS pattern language n n Alan O’Callaghan’s ADAPTOR/Janus n n n Jim Coplien’s C++ Idioms in PloPD4 n n Regards architecture as recursive down to the smallest detail Insists on the mutual adjustment of gross structure and fine detail Design problems emerge during construction A code-level, language-specific system of patterns Also utilises 4 Gamma patterns within itself n Pattern languages can potentially reflect the piecemeal growth approach The ADAPTOR Pattern Language INFO3011 Software Architecture and Design ADAPTOR n n n n n n n Architecture Driven And Patterns-based Techniques for Object Re-engineering n Originally for reverse-engineering, now a subset of a general pattern language for software architecture called Janus Characteristics of ADAPTOR n n Research Background n n ADAPTOR is characterised as an “open, candidate pattern language” Open n n Study: “Object-oriented Architectures for Reuse” 1992Legacy System Migration (to OT) Projects n n n n n It is an evolving language It embraces patterns from other catalogues, languages Individual patterns are at different levels of maturity The language is not yet fully comprehensive, generative n Candidate n 1993-5 “future-proof VAT processor” 1996-7 Switch Manager 1997-8 Resource management project 1998-9 Billing project 1998-9 Component-based development project “Design patterns and the software development life-cycle model” n ROPA funded project n n What is a Design Pattern (1)? “There are millions of particular solutions to any given problem; but it may be possible to find some one property which will be common to all these solutions. That is what a pattern tries to do” [Christopher Alexander Timeless Way of Building 1979] What is a Design Pattern(2)? “ Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over without ever doing it the same way twice” [Christopher Alexander A Pattern Language as quoted in Gamma et al., Design Patterns, 1995] What is a Design Pattern (2)? “…towns and buildings will not be able to come alive unless they are made by all of the people in society and unless these people share a common pattern language within which to make these buildings, and unless the pattern language is alive itself.” “…we present one possible pattern language….the elements of this language are so -called patterns….” “Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over without ever doing it the same way twice” [Christopher Alexander, A Pattern Language, 1977] Patterns vs. Pattern Languages For Alexander n Patterns do not exist outside of a wider “pattern language” n In which the use of one pattern sets the context for the use of others n The pattern language is shareable amongst all “stakeholders” in a development ADAPTOR represents (part of) an attempt to see whether pattern languages exist for software development Pattern Languages as Process n Legacy Systems n A Pattern Language is a system of patterns n n But recall that patterns are abstract solutions They cannot be composed together in advance to produce a solution There are various definitions of legacy systems n n Rather each pattern when applied changes the context of the solution n And creates a new context for the next pattern to be applied n n Solution is therefore “emerges” from the process itself N.B. This corresponds to modern “reflective design” theory n n Arguably a system becomes a “legacy system” as soon as it is installed Typically, a system delivering business value today but expected to be subject to diminishing returns because of its structure n By any definition, not homeostatic E.g., D. Schön “The Reflective Practitioner” Requirements of a Successful OT Migration Approach n The problem space must be described in terms of classes and objects n Relevance of Patterns to Legacy System Migrations n n n n But the Legacy System is the problem space If reverse engineering is needed to describe system functionality then OT migration is probably the wrong choice! Development must be to interface not implementation n The focus must be on software architecture n n Resolve non-functional [i.e. architectural] forces Structure the solution according to the problem Abstract and reuse successful approaches Patterns can be considered as micro-architectures in their own right Patterned approach can instill homeostatic structure n n I.e. help deliver systems that are flexible to change n The process must be as close as possible to normal forward engineering n minimal use of specialist skills and tools Patterns for OT Migration n Some Public Domain Patterns Useful for Migrations n n n Design Patterns [Gamma et al, Design Patterns, 1995] n Facade, Adapter, Bridge, Strategy Organisational/Process Patterns [Coplien, PloP, 1995] 4e.g., Conway’s Law “Organisation follows architecture” n e.g., Semantic Wrapper [O’Callaghan, 1996] Analysis Patterns [e.g., Hay, Fowler] Design Patterns [Gamma et al., 1994] n n n n n n Organisational Patterns [Coplien 1995] n n Composite Façade Adapter Bridge Proxy n n n Conway’s Law Scenarios define problem Self-selecting team Form follows function Code ownership Example of Two Organisational Patterns Sometimes development teams especially in a migration pilot project are distracted by “noise” ADAPTOR Pattern Template n n n n n n n So - use “Firewall” to insulate the group from unwarranted distractions Then use a “Gatekeeper” to filter incoming information and present it Name Problem Context Forces Solution Resulting Context Rationale Combining Patterns to Develop a Process n n System Composite n ADAPTOR proposes piece-meal growth At first build ‘Mile-Wide, Inch Deep’ n Has flavour of Alexander’s “Gradual Stiffening” pattern An Object Type representing core abstractions in the problem space Identify ‘alternative futures’ n Use ‘Archetype’ as building block n n n Then ‘Buffer the System with Scenarios’ n A variation of the Composite pattern [Gamma 1995] allows Software System us to describe any system as recursively 1..* composed of Component subsystems 1..* We can utilise high-level system-wide techniques links Connector Package recursively 1..* 2 Developing an Object Model of the Legacy System n Separating Concerns n Using Scenarios Define the Problem [Coplien 1995] we employ Use Case analysis to develop descriptions of system and subsystem functionality (Perhaps using Form Follows Function to partition) The ‘Shamrock’ pattern identifies 3 kinds of packages n n Use Case 1 The Concept Model(s) The Interaction Domain(s) n Use Case 2 E.g., GUI’s, protocols etc., Concurrency, Persistence etc. n Actor The Infrastructure Domain(s) n Use Case 3 n ‘Time-Ordered Coupling’ n n n Reflects Brand’s Shearing Layers See Appendix A Encapsulating and “Wrapping” Subsystems n Structure the Software Development Team n To each subsystem add a Façade object which will present itself as the (sub) system interface to all of its clients. At this stage, the system will be a set of interdependent facades behind which sits legacy code n Conway’s Law [Coplien, 1995] states that “organisation follows architecture, or architecture follows organisation” Assign leaders to each Façade, and teams to leaders employing Code Ownership Problem: How do you align the organisation and its architecture? Forces: Architecture shapes the communication paths in an organisation. The de facto organisational structure shapes the formal organisational structure…. ” Develop Semantic Wrappers n Keeper of the Flame n For the parts of the system which will be wrapped, develop objects that reflect the key abstractions n Maintain a role for maintaining the architecture n n n N.B. This requires building an Object analysis model of the legacy system n The implementation of these objects calls existing legacy code…until you want to change that, too! (Semantic Wrapper) n ‘Keeper of the Flame’ Not necessarily one person Job is not to veto, but to maintain continuity Can vary the architecture, if persuaded A Pattern Language for Software Architecture? Design Patterns Process Patterns Architecture and Process INFO3011 Software Architecture and Design Organisational Patterns Analysis Patterns Patterns Catalogue Architecture, Organisation and Process n ‘Heavywight’ Process :ATAM n Architecture strongly influences Organisation and Process n E.g., Conway’s Law says “organisation follows architecture, or architecture follows organisation” Implies structured methods n Carnegie Mellon University’s SEI now promotes the Architecture Tradeoff Analysis Method (ATAM) n n n Waterfall Software Development Life Cycle n Successor to SAAM Utilises ABAS (see “Architectural Styles” lecture) “…is to assess the consequences of architectural decisions in the light of quality attribute requirements” To assess architectural specifications before resources are committed to development n Together with an hierarchical organisational structure n Top-down design, step-wise development n Purpose n Business Analyst->System Analyst->Project Leader -> Analyst/Programmer->Programmer n Aim n n Debate on architecture is also a debate on process Underlying Concepts of ATAM n The Steps of ATAM(1) Presentation 1. 2. ATAM focuses on quality attribute requirements n Present the ATAM Present business drivers Present architecture By Architect By Project Manager To assembled stakeholders n n What are the stimuli to which the architecture must respond? What is the measurable and observable manifestation of a quality attribute by which its achievement is judged? What are the key architectural decisions that impact achieving the attribute requirement? 3. Investigation and Analysis 4. 5. Identify architectural approaches Generate quality attribute utility trees See discussion on ABAS’ 6. Analyze architectural approaches The Steps of ATAM (2) Testing 7. 8. Other Heavyweight Processes n n n n n Brainstorm and prioritize scenarios Analyze architectural approaches Present results Reporting 9. Capability Maturity Model SSADM Prince MASCOT HOOD n General characteristic n n Process maintained by Management Imposed by QA staff etc., An ‘agile’ process: The SCRUM Approach n How SCRUM Works n The SCRUM Software Development Process n Initial Planning Phase n n For small (10 members or less) development teams n Chief architect identified, architecture developed SCRUM teams chosen n n Compare with Surgical Team Can change architecture in discussion with Chief Architect Each team headed by a Scrum Master Typically 1-4 weeks Timeboxed development controlled by short, daily meetings n n Utilises rugby-metaphor n n Functionality delivered in Sprints n n In a scrum 8 players, each with specific roles, co-operate tightly together to gain forward movement while controlling the ball n Deadlines are ALWAYS met, even if functionality dropped n All identified tasks captured in Backlog Product development completed by a Closure Phase Benefits of SCRUM n SCRUM Meetings n SCRUM is comparable to other lightweight processes n Dynamic System Development Method, Xtreme Programming etc., Each of the daily SCRUM meetings answers the following 3 questions: 1. n n Focuses effort of the developers on backlog items Communicates priorities constantly to all developers n 2. 3. Changing them “on the fly” if necessary In the construction process itself What have you completed, relative to the backlog, since the last Scrum meeting? What obstacles got in the way of completing your work? What specific things do you plan to accomplish, relative to the backlog, between now and the next Scrum meeting? n Addresses risk dynamically n Other Agile Processes n Architecture and the RUP n Xtreme Programming n Pair programming etc., The most well-known software development process is the Rational Unified Process (RUP) n n n n Dynamic Systems Development Method Pattern Languages n Proprietory “process framework” of Rational Inc. Likely to be the basis of the OMG’s standardisation of process Use-case driven Architecture-centric Object-oriented General characteristic n n The RUP claims to be: n n n Designed and maintained by development staff Multiviewed Software Architecture n The ‘4+1’ Views Model n Rational’s Phillipe Krutchen says that Software Architecture deals with issues of n n n n n The original views were: n n Abstraction Composition Decomposition Style Aesthetics n n Proposes a multiview model of Software Architecture n n n ‘4+1’ views Underpins the RUP n Logical View n Object model of the system Process View n Concurrency and synchronization issues Development View n Static organisation of the system in its development environment Physical View (now called Component View or Implementation View in RUP) n Mapping of software to hardware Scenario- based View (the ‘plus one’: Use Case View in the RUP) n Usage scenarios Characteristics of the 4+1 Views Model n Krutchen’s Process n Krutchen applies Perry and Wolf’s equation to each model separately n Small number of scenarios selected for an iteration n Based on relative risk, criticality cf. UP’s “small, skinny system” Classes, subsystems, collaborations, processes etc., Software Architecture = {elements, form, rationale} Appropriate notation May include attached architectural style n n “Strawman” architecture established n n Each view captured in a blueprint n n n Scenarios scripted to drive major abstractions n n n As per Garlan and Wolf n n Scenarios (use cases) used to drive an iterative, incremental approach to architecture Architectural elements mapped on to four blueprints Architecture then tested, measured, analyzed, adjusted Documentation for each view includes Architectural Blueprint and Architectural Style Guide Evaluation of ‘4+1’ Views Model and the RUP n Summary n n Extends the notion of architecture beyond mere structure n n n Places Software Architecture on the critical path BUT Software Architecture is discovered IN the project n Includes rationale, aesthetics etc., Processes cannot be divorced from Software Architecture Processes can be categorised as n n Heavyweight Agile (or ‘lightweight’) n Unclear whether RUP is ‘heavyweight’ or ‘agile’ n CBD, Software Productline architectures, enterprise architectures etc., require conformity to pre-existing architectures n n See O’Callaghan v Jacobson in ApplicationDevelopment Advisor The RUP is based on Krutchen’s 4+1 Views Model of Software Architecture There is a debate as to whether it is heavyweight or agile Web Resources n ATAM n SEI’s homepage at Carnegie Mellon University (http://www.cmu.edu/) http://www.controlchaos.com/safe http://www.jeffsutherland.org http://www.dsdm.org/ http://hillside,net/patterns/papers IEEE discussion at http://www.computer.org/seweb/Dynabook/ n SCRUM n n The Deliverables of Software Architecture INFO3011 Software Architecture and Design n n n DSDM n Organisational Patterns n Xtreme Programming n Agenda n The Zachman Framework (1) n In this chapter we will examine two approaches to software architecture that sit somewhere between the opposing ‘poles’ of masterplan and piecemeal growth approaches: n n Published in the IBM Systems Journal in 1987 n n n the Zachman Framework Dana Bredemeyer’s Visual Architecture approach n n N.B. Students should acquaint themselves via Bredemeyer’s website with the various deliverables he proposes n An ‘architecture’ for IS – not just software architecture Argues the need for a separate process, technology and technology architecture within the concept of an enterprise information architecture Rests heavily on the notion of separating data from process as in Structured Methods, Information Engineering etc. Separate architectures are addressed iteratively through a hierarchy of levels of detail or views “A Framework for Information Systems Architecture” (vol 26. no.3) The Zachman Framework (2) Ballpark View Owner’s View Designer’s View Builder’s View Detailed Representation Functioning System Data Data Data Data Data Data Process Process Process Process Process Process Technology Technology Technology A ‘Horizontal’ Approach n The Zachman Framework is claimed to be a ‘horizontal’ approach to enterprise information architecture n n n n Vertical approaches unsatisfactory because n Designed around processes not departments As opposed to ‘top down’, vertical approaches Leads to component - based systems Confines ‘IT psyche’ to departmental level n Technology Technology Technology n Reinforced by heavy emphasis on end-user satisfaction, encourages monolithic legacy systems with huge amounts of custom code Departmental interests optimized, often to detriment o the enterprise Business Views of Enterprise Information Architectures n Designing Business Views n Cook argues that it is the top two rows that deliver strategic breakthroughs n Level One (Ballpark View) n n n n Business management views (ballpark and owner view) Means development views (designer, builder etc.) “no longer have autonomy on what is built only how they deploy it” Business views provide the solid foundation for the Enterprise Information Architecture n Level Two (Owner’s View) n n Defines high-level information needs and enterprise business functions Creates a high-level definition of the EIA through fundamental classifications of data and process (e.g., sales, marketing, manufacturing etc.) Provides business owner’s view and defines business functions and information needs of the enterprise in more detail IE techniques such as data modelling, process-to-data affinity analysis used here. Information Systems analyzed for dependencies on each other; priorities established; migration plans drawn up n Identify Architectural Dependencies n Implications for Architecture n Dana Bredemeyer’s Approach n According to Cook, “The architect should ideally have well-rounded line management experience and be an expert on the Zachman Framework and information engineering….The lower levels of the architecture should be completed by information systems experts so that the architect does not have to have significant technical depth” (Melissa A. Cook.1996. Building Enterprise Information Architectures: Reengineering Information Systems. Upper Saddle River, NJ:Prentice Hall) Dana Bredemeyer outlines Software Architecture in the following way: n n n n n n Attempts to reconcile ‘creative’ and ‘analytical’ architectural approaches Architecture: Addressing “What is SW Architecture?; architecture views, patterns, styles, component specs., interfaces etc., Architecting: How do I create, recapture or migrate an architecture?: modelling, documenting, assessing. Architects: What are the roles, responsibilities and skills of architects? Architecture Strategy: Why do architecture? And When?: competitive differentiation Architectural context: Where in the organisation is architecture done? Bredemeyer’s Software Architecture Model (1) guide Meta-Architecture architects Architecture guide designers Architecture Guidelines and Policies Conceptual Architecture Logical Architecture Execution Architecture Bredemeyer’s Software Architecture Model (2) Meta-Architecture •Architectural vision, principles, styles, key concepts and mechanisms •Focus: high-level decisions that will strongly influence the structure of the system; rules certain structural choices out, and guides selection choices and tradeoffs among others Architecture •Structures and relationships, static and dynamic views, assumpti ons and rationale •Focus: decomposition and allocation of responsibility, interface design, assignment to processes and threads Architecture Guidelines and Policies •Use model and guidelines: policies, mechanisms and design patterns; frameworks, infrastructure and standards •Focus: guide engineers in creating designs that maintain the integrity of the architecture Bredemeyer’s Software Architecture Model (3) Conceptual Architecture •Architecture diagram, CRC-R cards •Focus: identification of components and allocation of responsibilities to components Conceptual Architecture Clerk dialog Logical Architecture •Updated Architecture diagram (showing interfaces), interface specifications, component specs. And usage guides •Focus: design of component interactions, connection mechanisms a nd protocols; interface design and specification; providing contextual information for component users Balance books Receive payments Enter sales Execution Architecture Accounts Customers •Abstract, system-wide view •Basis for communication •Process view (shown on Collaboration Diagrams) •Focus: assignment of the runtime component instances to processes, threads and address spaces; how they communicate and co-ordinate; how physical resources are allocated to them Logical Architecture Context_Manager ContextManager ContextData ContextParticipant client Execution Architecture server Application #1 <> r:ReservationAgent CORBA ORB {location = reservation server} <> <> h:HotelAgent {location = hotel server} <> t:TicketingManager {location = airline server} •“Blueprint”: precise, unambiguous, actionable •Basis for supplier/client contract t:TripPlanner {location = client} •Configuration of components at run-time •Basis for early system tuning Process: System-level Concerns Statements of preferred architectural direction or practice Process Overview Init/Commit System Structuring Principles Principle Name Description Rationale/Benefits Implications Counterargument Style Key Mechanisms and Concepts e.g., component interconnection mechanisms Architectural Requirements Bredemeyer calls this •Guiding principles and strategies the Meta-architecture: the first set of decisions •Basis for system decomposition and decomposition Architectural Validation Deployment How to Create a Good Architecture n Functionality Goals n Elicit stakeholder goals n Ensure architecture supports what is valued and scopes out what is not n Bredemeyer creates Context Maps, Stakeholder Profiles for documentation n n n n Drives creation of principles, selection of architectural styles, and selection/creation of mechanisms in “meta-architecture phase” Functionality goals are starting points for Use Cases Quality goals are starting points for non-functional requirements specification n Functional requirements capture the intended behaviour of the system Use Cases capture who (actor) does what (interaction) with the system for what purpose (goal) without dealing with system internals A Use Case defines a goal-oriented set of interactions between external actors and the system under consideration Quality Goals n Init/Commit Summary n n Qualities are properties or characteristics of the system that its stakeholders care about and hence will affect their degree of satisfaction with the system. Explicit, documented qualities are needed to: n Gain Management Sponsorship n n n Purpose: Ensure management support Activities: Create/communicate the architectural vision showing how it contributes to long-term success Checks: Resources? Full-time architect -team members? Management championship? Purpose: ensure a cohesive and productive team Activities: Use arch. vision to build team alignment; assess team capabilities and needs; establish team operating model Checks: strong accepted leader? Collaborative, creative team? Effective decision-making? n n n n Define architectures so that they achieve required qualities Make tradeoffs Form a basis for comparing alternatives Enhancing communication within architecture team and between architects and stakeholders Evaluate architectures to ensure compliance n Build the Architecture team n n n Architectural Requirements Summary n System Structuring Summary n Capture Context, Goals and Scope n Create the Meta-Architecture n Ensure architecture is aligned to business strategy and directions, and anticipates market and technology changes Document, communicate and validate the intended behaviour of the system Make strategic architectural choices to guide the architecting effort Create conceptual models to communicate the architecture to managers, project managers, developers and users Create detailed architectural specs. In a way that is directly actionable n Create the Conceptual Architecture n n Capture Functional Requirements n n Create the Logical Architecture n n Capture Non-Functional Requirements Validation Summary n Deployment Summary n Validate the Architecture n Build Understanding n n n n Assess the architecture to validate that it meets the requirements and identify issues and areas for improvement early Construct prototypes or proof -of-concept demonstrators or skeletal architecture to validate communication and control mechanisms Conduct reviews Conduct architectural assessments (e.g., SAAM Action Guide) n Help all developers understand the architecture, its rationale, and how to use it. Help managers understand its implications for organizational success, work assignments etc., Ensure designs and implementations adhere to the architecture and do not cause “architectural drift” Ensure the architecture remains current n Ensure Compliance n n Evolve the Architecture n Evolutionary Technical Process Pass1 From Business Strategy to Architectural Strategy Bredemeyer Consulting’s Action Guides n Pass 2 From Strategy to Concept Pass 3 From Concept to Specification Pass 4 From Specification to Execution Pass 5 From Execution to Deployme nt Developer needs Architectu ral Guidelines Action Guides are n n Action-oriented Short : fit on two sides of 8” x 5” index cards n Architectural Requirements System Structuring Architectural Validation Context Goals Scope Metaarchitecture Reasoned arguments Use cases Qualities Conceptual Architecture Impact Analysis Refine Use Cases Logical Architecture Estimates Concurrency Template: n n n n n Execution Architecture Prototypes Description Purpose Notation (optional) Guidelines for creating… Uses of… information Action Guides and the Architecting Process n Sample Action Guides n Action Guides can be n Used individually n Each produces some key result for the architecture team By selecting out a subset of Action Guides, teams can devise their own lightweight process Sample Action Guides are Downloadable from the Bredemeyer website n n n n n n Used selectively n n Used as a Complete Guide to Software Architecture n Taken together provides a comprehensive architecting process using UML Context Map Principles Template Interface Template Component Collaboration diagram Component specification Template Bredemeyer’s Deliverables n Summary (1) n Action Guides and Templates can be useful in expressing Software Architecture n n Preserve architect’s obligation to stakeholders Concept-driven n n Provide useful documentation n n E.g., stakeholder profiles, architectural principles Utilises UML Use cases, Interface and Component templates n The Zachman Framework seeks to ensure business goals are met by constraining the development process by its business management views ‘Architect’ requires knowledge of the framework and of information engineering but no technical depth Relies on separation of data and process even within business management views n n Seek to add ‘rigour’ to design ‘relevance’… n Possibly compromising its claim to ‘technology-independent’ architecture n n …without imposing heavyweight ‘processes’ The Framework a view closer to the ‘Masterplan’ approach than it is to piecemeal growth Summary (2) n n Bredemeyer seeks to add some of the rigour associated with Masterplan approaches to a basically ‘piecemeal’ growth approach ‘Meta-architecture’ ensures the primacy of business need n n ‘Architecture’ focuses on structural and dynamic views n Essentially a piecemeal growth approach Essentially a masterplan perspective