1. Introduction to Software Architecture Sam Malek CS 795 / SWE 699 Spring 2010 George Mason University

2. Software Architecture Definition Definition. A software system’s architecture is the set of principal design decisions about the system. Software architecture is the blueprint for a software system’s construction and evolution. © Malek2

3. Design Decisions Design decisions encompass every aspect of the system under development This includes design decisions related to Structure Behavior Interaction Non-functional properties © Malek3

4. Defining “Principal” “Principal” implies a degree of importance that grants a design decision “architectural status”. It also implies that not all design decisions are architectural, that is, they do not necessarily impact a system’s architecture. How one defines “principal” will depend on what the stakeholders define as the system goals. © Malek4

5. Software Architecture as a Field of Study Software architecture is a field of study that is characterized by an unusual diversity of views and understandings of some fundamental concepts. A quick search of the internet will yield many definitions of architecture for example. © Malek5

6. Other Definitions of Software Architecture Perry and Wolf Software Architecture = { Elements, Form, Rationale } what how why Shaw and Garlan Software architecture [is a level of design that] involves the description of elements from which systems are built, interactions among those elements, patterns that guide their composition, and constraints on these patterns. Kruchten Software architecture deals with the design and implementation of the high-level structure of software. Architecture deals with abstraction, decomposition, composition, style, and aesthetics. © Malek6

7. Temporal Aspect Design decisions are (un)made over a system’s lifetime  Architecture has a temporal aspect. A system’s architecture will change over time. However, at any given point in time, the system has only one architecture. © Malek7

8. Prescriptive vs. Descriptive Architecture A system’s prescriptive architecture captures the design decisions made prior to the system’s construction. It is the as-designed or as-intended architecture. A system’s descriptive architecture describes how the system has been built. It is the as-implemented or as-realized architecture. © Malek8

9. As-Designed vs. As- Implemented Architecture © Malek9

10. 10© Malek As-Designed vs. As- Implemented Architecture

11. 11© Malek As-Designed vs. As- Implemented Architecture Which architecture is “correct”? Are the two architectures consistent with one another? What criteria are used to establish the consistency between the two architectures? On what information is the answer to the preceding questions based?

12. Architectural Evolution When a system evolves, ideally its prescriptive architecture is modified first. Unfortunately often the system and thus its descriptive architecture is directly modified. This failure of update happens because of Developer sloppiness Perception of short deadlines which prevent thinking through and documenting Lack of documented prescriptive architecture Need or desire for code optimizations Inadequate techniques or tool support 12© Malek

13. Architectural Drift vs. Erosion Definition. Architectural drift involves architectural design decisions that are applied directly to a system’s descriptive architecture, but are not properly reflected in the system’s prescriptive architecture. Definition. Architectural erosion involves architectural design decisions that are applied directly to a system’s descriptive architecture, and that violate design decisions captured by the system’s prescriptive architecture. 13© Malek

14. Architectural Recovery If drift or erosion are allowed to occur, the development organization is likely to be forced to recover the system’s architecture sooner or later. Definition. Architectural recovery is the process of determining a software system’s architecture from its implementation-level artifacts. Implementation-level artifacts can be Source code Executable files Java.class files 14© Malek

15. Implementation-Level View of an Application 15© Malek

16. Software Architecture’s Elements A software system’s architecture typically is not (and should not be) a uniform monolith A software system’s architecture should be a composition and interplay of different elements Processing Data, also referred as information or state Interaction 16© Malek

17. Component Elements that encapsulate processing and data in a system’s architecture are referred to as software components. Definition. A software component is an architectural building block that encapsulates a subset of the system’s functionality and/or data, and restricts access to them via an explicitly defined interface. 17© Malek

18. Connector In complex systems interaction might become more important and challenging than the functionality of the individual components. Definition. A software connector is an architectural building block tasked with regulating interactions among components. In traditional, desktop software systems, connectors would have usually manifested themselves as simple procedure calls or shared data accesses. 18© Malek

19. 19 Multiple Connectors in a Single System

20. Software Connectors Architectural element that models Interactions among components Rules that govern those interactions Simple interactions Procedure calls Shared variable access Complex & semantically rich interactions Client-server protocols Database access protocols Asynchronous event multicast Each connector provides Interaction duct(s) Transfer of control and/or data 20© Malek

21. Implemented vs. Conceptual Connectors Connectors in software system implementations Frequently no dedicated code Frequently no identity Typically do not correspond to compilation units Distributed implementation Across multiple modules Across interaction mechanisms Connectors in software architectures First-class entities Have identity Describe all system interaction Entitled to their own specifications & abstractions 21© Malek

22. Reasons for Treating Connectors Independently Connector  Component Components provide application-specific functionality Connectors provide application-independent interaction mechanisms Interaction abstraction and/or parameterization Specification of complex interactions Binary vs. N-ary Asymmetric vs. Symmetric Interaction protocols Localization of interaction definition Extra-component system (interaction) information Component independence Component interaction flexibility 22© Malek

23. Benefits of First-Class Connectors Separate computation from interaction Minimize component interdependencies Support software evolution At component-, connector-, & system-level Potential for supporting dynamism Facilitate heterogeneity Become points of distribution Aid system analysis & testing 23© Malek

24. Software Connector Roles Locus of interaction among set of components Protocol specification (sometimes implicit) that defines its properties Types of interfaces it is able to mediate Assurances about interaction properties Rules about interaction ordering Interaction commitments (e.g., performance) Roles Communication Coordination Conversion Facilitation 24© Malek

25. Connectors as Communicators Main role associated with connectors Supports Different communication mechanisms e.g. procedure call, RPC, shared data access, message passing Constraints on communication structure/direction e.g. pipes Constraints on quality of service e.g. persistence Separates communication from computation May influence non-functional system characteristics e.g. performance, scalability, security 25© Malek

26. Connectors as Coordinators Determine computation control Control delivery of data Separates control from computation Orthogonal to communication, conversion, & facilitation Elements of control are in communication, conversion & facilitation 26© Malek

27. Connectors as Converters Enable interaction of independently developed, mismatched components Mismatches based on interaction Type Number Frequency Order Examples of converters Adaptors Wrappers 27© Malek

28. Connectors as Facilitators Enable interaction of components intended to interoperate Mediate & streamline interaction Govern access to shared information Ensure proper performance profiles e.g., load balancing Provide synchronization mechanisms Critical sections Monitors 28© Malek

29. Configuration Components and connectors are composed in a specific way in a given system’s architecture to accomplish that system’s objective. Definition. Architectural configurations, or topologies, capture architectural structure via graphs whose nodes represent components and connectors, and whose edges represent their interconnectivity. 29© Malek

30. An Example Configuration 30© Malek

31. Architectural Models, Views, and Visualizations Architecture Model An artifact documenting some or all of the architectural design decisions about a system. Architecture Visualization A way of depicting some or all of the architectural design decisions about a system to a stakeholder. Architecture View A subset of related architectural design decisions. 31© Malek

32. Architectural Style An architectural style is a named set of constraints (e.g., rules) you put on your development Constraints may be topological, behavioral, communication-oriented, you name it © Malek, 200832 VS.

33. Basic Properties of Styles A vocabulary of design elements Component and connector types e.g., pipes, filters, objects, servers A set of configuration rules Topological constraints that determine allowed compositions of elements e.g., a component may be connected to at most two other components A semantic interpretation Compositions of design elements have well-defined meanings © Malek, 200833

34. Different Aspects of Styles What is the design vocabulary? Component and connector types What are the allowable structural patterns? What is the underlying computational model? What are the essential invariants of the style? What are common examples of its use? What are the (dis)advantages of using the style? What are the style’s specializations? © Malek, 200834

35. Some Common Styles “Basic” styles Pipe and filter Object-oriented Layered Blackboard State transition Client-server Many flavors Peer-to-peer Event-based (a.k.a. Implicit invocation) Push-based “Derived” styles GenVoca C2 © Malek, 200835

36. Pipe and Filter Style Components are filters Transform input data streams into output data streams Possibly incremental production of output Connectors are pipes Conduits for data streams Style invariants Filters are independent (no shared state) Filter has no knowledge of up- and down-stream filters Examples UNIX shellsignal processing Distributed systemsparallel programming © Malek, 200836

37. Pipe and Filter (cont.) Variations Pipelines — linear sequences of filters Bounded pipes — limited amount of data on a pipe Typed pipes — data strongly typed Batch sequential — data streams are not incremental Advantages System behavior is a succession of component behaviors Filter addition, replacement, and reuse Possible to hook any two filters together Certain analyses Throughput, latency, deadlock Concurrent execution Disadvantages Batch organization of processing Interactive applications Lowest common denominator on data transmission © Malek, 200837

38. Object-Oriented Style Components are objects Data and associated operations Connectors are messages and method invocations Style invariants Objects are responsible for their internal representation integrity Internal representation is hidden from other objects Advantages “Infinite malleability” of object internals System decomposition into sets of interacting agents Disadvantages Objects must know identities of servers Often very tightly coupled systems © Malek, 200838

39. Layered Style Hierarchical system organization “Multi-level client-server” Each layer exports an “API” to be used by above layers Each layer acts as a Server: service provider to layers “above” Client: service consumer from layers “below” Connectors are protocols of layer interaction Example: operating systems Virtual machine style results from fully opaque layers © Malek, 200839

40. Layered Style (cont.) Advantages Increasing abstraction levels Evolvability Changes in a layer affect at most the adjacent two layers Reuse Different implementations of layer are allowed as long as interface is preserved Standardized layer interfaces for libraries and frameworks Disadvantages Not universally applicable Performance Layers may have to be skipped Determining the correct abstraction level © Malek, 200840

41. Blackboard Style Two kinds of components Central data structure — blackboard Components operating on the blackboard System control is entirely driven by the blackboard state Examples Typically used for AI systems Integrated software environments (e.g., Interlisp) Compiler architecture © Malek, 200841

42. Client-Server Style Instance of a more general style Distributed systems Components are clients and servers Servers do not know number or identities of clients Clients know server’s identity Connectors are point-to-point interaction protocols A number of different flavors of client- server © Malek, 200842

43. Peer-to-Peer Style Similar to Client-Server Point-to-point communication between components There is no distinction between a client and server i.e., a client can also be a server It is almost a “null” style Not that many constraints © Malek, 200843

44. Implicit Invocation Style Event announcement instead of method invocation “Listeners” register interest in & associate methods with events System invokes all registered methods implicitly Component interfaces are methods and events Two types of connectors Invocation is either explicit or implicit in response to events Style invariants “Announcers” are unaware of their events’ effects, if any No assumption about processing in response to events © Malek, 200844

45. Implicit Invocation (cont.) Advantages Component reuse System evolution Both at system construction-time & run-time Disadvantages Counter-intuitive system structure Components relinquish computation control to the system No knowledge of what components will respond to event No knowledge of order of responses © Malek, 200845

46. Push-Based Style Specialization of this style is the Publish-Subscribe style Distinguished from pull-based (e.g., the Web) Examples employee information systems maintenance manuals stock ticker © Malek, 200846

47. Push-Based Style (cont.) “Components” Producer Receiver Channel Broadcaster Transport system Repeater, cache, proxy Transparent to all other components Asymmetric communication model Producers/Receivers More receivers than producers © Malek, 200847

48. The C2 Style Topological Constraints All components, connectors have two interfaces, “top” and “bottom” Components can be connected to 0-1 connector on each interface Connectors can be connected to 0+ components or connectors on each interface Component Connector top bottom top bottom © Malek, 200848

49. The C2 Style Communication Constraints Components & connectors communicate using only independent events or messages Requests go up (“requests rise”) Notifications go down No passing pointers Components & connectors communicate asynchronously Can send/receive events at any time No blocking! Data Store GUI Interpreter Alarm Notifications Requests © Malek, 200849

50. The C2 Style Dependency Constraints Components may make assumptions about services provided above them But not who is providing them Components may NOT make assumptions about services provided below them © Malek, 200850

51. C2 Example Data Store GUI Interpreter Alarm © Malek, 200851

52. C2 Example Data Store GUI Interpreter Alarm Stores data; emits notifications whenever data changes. © Malek, 200852

53. C2 Example Data Store GUI Interpreter Alarm Interprets basic GUI actions & translates them into data store operations © Malek, 200853

54. C2 Example Data Store GUI Interpreter Alarm Rings a bell whenever value of X changes © Malek, 200854

55. C2 Example Data Store GUI Interpreter Alarm Accept & process user actions © Malek, 200855

56. C2 Example Data Store GUI Interpreter Alarm Connector routes messages: requests are broadcasted up, notifications are broadcasted down © Malek, 200856

57. What ilities does C2 buy us? Flexibility and Adaptability Loose coupling lets you swap out components, interpose components Flexible connectors allow run-time changes Distributability Since no assumption of shared address space, distributing an app across machines is easy Event routing is determined by the configuration of the architecture Visibility Since all messages go through connectors, they are easy to catch and log Parallelizability Since the same event is delivered to multiple components in a given layer © Malek, 200857

58. Heterogeneous Styles © Malek, 200858

59. General Benefits of Using Styles Design reuse Well-understood solutions applied to new problems Code reuse Shared implementations of invariant aspects of a style Understandability of system organization A phrase such as “client-server” conveys a lot of information Interoperability Supported by style standardization Style-specific analyses Enabled by the constrained design space Visualizations Style-specific depictions matching engineers’ mental models © Malek, 200859

60. The impact of style on software qualities In general, styles could have a significant impact on the properties of a software system: Performance Scalability Modifiability/Adaptability Visibility Portability Reliability Simplicity © Malek, 200860

61. Style Comparison (from Fielding’s paper) © Malek, 200861

62. Observations Different styles often result in Different architectures Architectures with greatly differing properties A style does not fully influence resulting architecture A single style can result in different architectures Considerable room for Individual judgment Variations among architects Different emphases –e.g., Imposed by customer © Malek, 200862