Basic Concepts

1. Basic Concepts Acknowledgement: some slides from: Software Architecture: Foundations, Theory, and Practice; R. Taylor, N. Medvidovic, E.Dashofy

2. “Principal” implies a degree of importance that grants a design decision “architectural status” • Implies that not all design decisions are architectural (i.e. they do not necessarily impact a system’s architecture) • How one defines “principal” will depend on what the stakeholders define as the system goals Software Architecture Definition(source: Taylor et al., “Software Architecture: Foundations, Theory, and Practice) “[Software architecture is] the set of principal design decisions governing a system” • Design decisions encompass every facet of the system under development • Structure, Behavior, Interaction, Non-functional properties

3. Architecture Views • A software architecture is a complex design artifact • Many possible ‘views’ of the architecture • Cf. with buildings – floor plan, external, electrical, plumbing, air-conditioning

4. RUP – 4+1 view model(Rational Unified Process)

5. RM-ODP Viewpoints (2001)Reference Model – Open Distributed Processing) Manager Business model Enterprise Database Modeler Designers Logical, data modeling Logical view of services Information Computational Operating Sys. Engineer Developer Servers, Comm, Physical view of data and services (IDL, WSDL) Technology Engineering

6. Temporal Aspects 6 • A software architecture is a complex design artifact • Observation: Design decisions are made and unmade over a system’s lifetime  Consequence: Architecture has a temporal aspect • At any given point in time a system has only one architecture • architecture will change over time

7. Prescriptive vs. Descriptive Architecture 7 • prescriptive architecture: captures the design decisions made prior to the system’s construction • as-conceived or as-intended architecture • descriptive architecture describes how the system has been built • as-implemented or as-realized architecture

8. As-Designed vs. As-Implemented 8

9. Architectural Evolution 9 • ideally its prescriptive architecture is modified first, when a system evolves • in practice the system – and thus its descriptive architecture – is often directly modified • Reasons • 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

10. Architectural Degradation 10 Architectural drift: introduction of principal design decisions into the descriptive architecture that • are not included in, encompassed by, or implied by the prescriptive architecture • but which do not violate any of the prescriptive architecture’s design decisions (new constraints are introduced, without violating the descriptive architecture) Architectural erosion is the introduction of architectural design decisions into a system’s descriptive architecture that violate its prescriptive architecture

11. Architectural Recovery 11 If architectural degradation is allowed to occur, one will be forced to recover the system’s architecture sooner or later • Architectural recovery: determining a software system’s architecture from its implementation-level artifacts • Source code, executables, deployment

12. Implementation-Level View of an Application Complex and virtuallyincomprehensible! 12

13. Deployment 13 • A software system cannot fulfill its purpose until it is deployed • Executable modules are physically placed on the hardware devices on which they are supposed to run • The deployment view of an architecture can be critical in assessing whether the system will be able to satisfy its requirements • Possible assessment dimensions • Available memory • Power consumption • Required network bandwidth

14. A System’s Deployment Architectural Perspective 14

15. Software Architecture’s Elements Components Connectors 15 • A software system’s architecture generally involves composition and interplay of different elements • Processing • Data (also referred as information or state) • Interaction

16. Components 16 Elements that encapsulate processing and data in a system’s architecture are referred to as software components Definition: A software component is an architectural entity that • encapsulates a subset of the system’s functionality and/or data • restricts access to that subset via an explicitly defined interface • has explicitly defined dependencies on its required execution context • Components typically provide application-specific services

17. Connectors 17 Interaction may become more important / challenging than the functionality of individual components Software connector:architectural building block tasked with effecting and regulating interactions among components • In many systems connectors are usually simple procedure calls or shared data accesses • More sophisticated connectors are possible. E.g., • Distribution connectors: RPC, message passing, streaming. • Wrapper/adaptor connectors • typically provide application-independent interaction facilities

18. [programming] Design PatternsArchitectural StylesArchitectural PatternsDomain Specific Software Architectures 18 Certain (design) choices regularly result in solutions with superior properties Compared to other possible alternatives, these solutions are more elegant, effective, efficient, dependable, evolvable, scalable, and so on

19. 19

20. Domain-Specific Software Architectures 20 • A DSSA is an assemblage of software components • specialized for a particular type of task (domain), • generalized for effective use across that domain, • composed in a standardized structure (topology) effective for building successful applications. • Since DSSAs are specialized for a domain they are only of value if one exists for the domain wherein the engineer is tasked with building a new application. • DSSAs are the pre-eminent means for maximal reuse of knowledge and prior development and hence for developing a new architectural design.

21. Architectural Patterns 21 architectural pattern: set of architectural design decisions that are applicable to a recurring design problem, and parameterized to account for different software development contexts in which that problem appears.

22. State-Logic-Display: Three-Tiered Pattern 22 • Application Examples • Business applications • Multi-player games • Web-based applications

23. Model-View-Controller (MVC) 23 Objective: Separation between information, presentation and user interaction. When a model object value changes, a notification is sent to the view and to the controller. So that the view can update itself and the controller can modify the view if its logic so requires. When handling input from the user the windowing system sends the user event to the controller; If a change is required, the controller updates the model object.

24. Sense-Compute-Control Objective: Structuring embedded control applications 24

25. The Lunar Lander 25 • A simple computer game that appeared in the 1960’s • Simple concept: • You (the pilot) control the descent rate of the Apollo-era Lunar Lander • Throttle setting controls descent engine • Limited fuel • Initial altitude and speed preset • If you land with a descent rate of < 5 fps: you win (whether there’s fuel left or not) • “Advanced” version: joystick controls attitude & horizontal motion

26. Sense-Compute-Control LL 26

29. Talk today: nVidia CTO Project Groups Lab + Assignment 1) Deploy an application to Google App Engine. 2) Use Google's login 3) Send data to the servers. 4) Store data 5) Display stored data (dynamic page, and not only a static one) 6) Detect current location 7) Use a third-party component (a map) 8) Add custom markers to a map.

30. Definitions of Architectural Style 30 • architectural style: named collection of architectural design decisions that • are applicable in a given development context • constrain architectural design decisions that are specific to a particular system within that context • elicit beneficial qualities in each resulting system. • A primary way of characterizing lessons from experience in software system design • Reflect less domain specificity than architectural patterns • Useful in determining everything from subroutine structure to top-level application structure

31. Common styles • Traditional, language-influenced • Main program + subroutines • Object-oriented • Layered • Virtual machines • Client-server • Data-flow styles • Batch sequential • Pipe and filter • Shared-state • Blackboard • Rule based • Interpreter • Interpreter • Mobile code • Implicit invocation • Event-based • Publish-subscribe • Peer-to-peer

32. The beast you fight: Complexity A complex system can no longer be made by a single person A very complex system can no longer be comprehended by a single person How to tackle complexity?

33. The Tools of “Software Engineering 101” 33 • Abstraction • (bottom-up): look at details, and abstract “up” to concepts • (top-down): choose concepts, then add detailed substructure, and move “down” • Separation of concerns

34. Common styles • Traditional, language-influenced • Main program and subroutines • Object-oriented • Layered • Virtual machines • Client-server • Data-flow styles • Batch sequential • Pipe and filter • Shared-state • Blackboard • Rule based • Interpreter • Interpreter • Mobile code • Implicit invocation • Event-based • Publish-subscribe • Peer-to-peer

35. Isn’t this constraining? Yes No Incremental or “big vision”?

36. Observations 36 • Different styles result in … • … different architectures • …. with greatly differing properties • A style does not fully determine resulting architecture • A single style can result in different architectures • Considerable room for • Individual judgment • Variations among architects • A style defines domain of discourse • About problem (domain) • About resulting system

37. Basic Properties of Styles 37 • A vocabularyof design elements • Component and connector types; data elements • 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

38. Benefits of Using Styles 38 • 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

39. Style Analysis Dimensions 39 • 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?

40. Common Styles • Traditional, language-influenced • Main program and subroutines • Object-oriented • Layered • Virtual machines • Client-server • Data-flow styles • Batch sequential • Pipe and filter • Shared state • Blackboard • Rule based • Interpreter • Interpreter • Mobile code • Implicit invocation • Event-based • Publish-subscribe • Peer-to-peer 40

41. Our example application: The Lunar Lander Game 41 • A simple computer game • You (the pilot) control the descent rate of the Apollo-era Lunar Lander • Throttle setting controls descent engine • Limited fuel • Initial altitude and speed preset • If you land with a descent rate of < 5 fps: you win (whether there’s fuel left or not) “Advanced” version: joystick controls attitude & horizontal motion

42. Main Program and Subroutines LL 42

43. Object-Oriented Style 43 • 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 • Advantages • “Infinite malleability” of object internals • System decomposition into sets of interacting agents • Reuse • Disadvantages • Objects must know identities of servers • Side effects in object method invocations

44. Object-Oriented LL 44

45. OO/LL in UML 45

46. Layered Styles 46 • Hierarchical system organization • Each layer exposes an interface (API) to be used by above layers • “Multi-level client-server” • Each layer acts as a • Server: service provider to layers “above” • Client: service consumer of layer(s) “below” • Connectors are protocols of layer interaction • Example: operating systems • Virtual machine style results from fully opaque layers

47. Layered Style (cont’d) 47 • Advantages • Increasing abstraction levels • Evolvability / reuse / separation of concerns • Changes in a layer affect at most the adjacent two layers • Different implementations of a layer are allowed as long as interface is preserved • Standardized layer interfaces for libraries and frameworks • Disadvantages • Not universally applicable • Performance • Determining the correct abstraction level can be hard • Layers may have to be skipped (for performance or functionality reasons)

48. Layered Systems/Virtual Machines 48

49. Layered LL 49

50. Client-Server Style 50 Components are clients and servers Servers do not know number or identities of clients Clients know server’s identity Connectors are RPC-based network interaction protocols