Introduction to SOFTWARE ARCHITECTURE

1. Introduction to SOFTWARE ARCHITECTURE Ivano Malavolta

2. Roadmap Definitions and concepts Architectural styles

3. Definitions and concepts Some contents of this part of lecture extracted from Henry Muccini’s lecture on software architecture at the University of L’Aquila (Italy)

4. Outline Definitions Static descriptions Dynamic descriptions Why software architecture?

5. Context © David Garlan, lecture @GSSI, a.y., 2013/2014

9. Refresh Example: software architecture The software architecture of a program or computing system is the structure or structures of the system, which comprise software components, the externally visible properties of those components and the relationships among them System subsystem Subsystem component component component L. Bass, P. Clements, R. Kazman, Software Architecture In Practise, Addison Wesley, 1998

10. Software Architecture definitions Perry and Wolf, ’92 (aspects): – “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 the design.” – Elements are divided into processing elements, data elements and connection elements Garlan and Shaw, ’93 (elements): – Architecture for a specific system may be captured as “a collection of computational components - or simply components - together with a description of the interactions between these components - the connectors -” Sommerville, 7th edition, ’04 (process): – The design process for identifying the sub-systems making up a system and the framework for sub-system control and communication is architectural design. The output of this design process is a description of the SA.

11. Develop systems “architecturally” If you think good architecture is expensive, try bad architecture. ... Brian Foote and Joseph Yoder – Design at an architectural level of abstraction – Build systems compositionally from parts – Assure that the system will satisfy critical requirements before it is constructed – Recognize and reuse standard architectures patterns & styles – Reuse codified architectural design expertise à reduce costs through product-lines

12. In general terms… SA describes (in a more or less “formal” notation) how a system is structured into components and connectors… – Components – Connectors – Channels and Ports … and how these components interact – Scenarios – State Diagrams – … SA Structure (topology) SA Dynamics (behavior)

13. Process (2) Architectural constraints and requirements Ideas Constraints Req1:.. Req2:.. Req3:.. ……… Architectural requirements C2 C1 C3 C4 Software Architecture Software Architecture synthesis C2 C1 C3 Software C4 Architecture Evaluation and prototype Decisions making

15. Components A component is a building block that is – A unit of computation or a data store, with an interface specifying the services it provides and requires – A unit of deployment – A unit of reuse • e.g., client, server, database, filters, ... C1 S1 S2 S3 S’x S’Y provided services required services

16. Example

17. Components vs Objects The level of abstraction is usually different • Size – Objects tend to be small – Components can be small (one object) or large (a library of objects or a complete application) • An architectural component may be implemented by several objects • Lifecycle – Objects are created and destroyed constantly – Components are created and destroyed infrequently

18. Connectors A connector is a building block that enables interaction among components – Events – Client/server middleware – Messages and message buses – Shared variables – Procedure calls (local or remote) – Pipes Connectors may be implicit or explicit – Connectors sometimes are just channels – Connectors sometimes have their own logic and complexity

19. Components and Connectors A component is (or should be) independent of the context in which it is used to provide services A connector is (or should be) dependent on the context in which it is used to connect components Connectors sometimes are modeled as special kinds of components

20. Interfaces An interface is the external connection of a component (or connector) that describes how to interact with it Provided and required interfaces are important Spectrum of interface specification – Loosely specified (events go in, events go out) – API style (list of functions) – Very highly specified (event protocols across the interface in CSP)

21. Architecting: example GUI FeedService Common FeedService Action NewsFeeder Action Admin Action Factory FeedDelegate POJOs NewsFeeder DAO FeedDAO NewsFeederDAO FeedDAO FeedDelegate Transfer Object ValidatorService NewsFeederDelegate NewsFeeder DelegatePOJOs Browser (html javascript) Web Services DATABASE Trasformation Validation BusinessFactory Validation Service

22. Architecting: example GUI FeedService FeedService Common Action NewsFeeder Action Admin Action Factory FeedDelegate PresentationExtensionOut PresentationExtensionIn BusinessExtensionOut FeedDelegate POJOs NewsFeederDelegate NewsFeederDAO FeedDAO NewsFeeder DAO FeedDAO Transfer Object ValidatorService NewsFeeder DelegatePOJOs Browser (html javascript) Web Services DATABASE Trasformation Validation BusinessFactory Validation Service BusinessExtensionIn

23. Architectural Elements vs Design Elements “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 the design.” “Design is concerned with the modularization 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.” (Perry & Wolf 92)

25. SA dynamics The SA dynamics is expressed in terms of component interactions via connectors - Labeled Transition Systems - Automata - UML StateCharts, Sequence Diagrams, Activity Diagrams - State Diagrams - Message Sequence Charts - …

26. An example : e-commerce system Customer Interface Customer Process Web Server Delivery Order Catalog Server Customer Server Cart Server Process Order Server SA Static Description

27. An example : e-commerce system CustomerInterface CustomerProcess CatalogServer BrowseCatalog BrowseCatalog ReadStatus Catalog Page Output Page Catalog Info SA Dynamic Description : Registered Customer Catalog DB Involved Browse Catalogue Sequence Diagram

28. An example : e-commerce system CustomerInterface Registered Customer CustomerProcess CartServer PlaceOrderReq PlaceOrder ReadStatus Cart DB Involved pageOrder OutputPage OrderServer Order DB Involved EmptyCart Cart DB Involved CustomerServer ReadInfo Customer DB Involved DeliveryOrderProcess createNewOrder OrderInfo newOrder CartInfo CustomerInfo OrderInfo SA Dynamic Description : Place Order Sequence Diagram (success)

29. An example : e-commerce system CustomerInterface CustomerProcess CartServer PlaceOrder ReadStatus errorPage emptyCart SA Dynamic Description : Registered Customer PlaceOrderReq Cart DB Involved OutputPage Place Order Sequence Diagram (empty cart)

31. Advantages of explicit architecture System analysis – Analysis of the system before it has been built – Costs saving and risks mitigation Large-scale reuse – The architecture (or part of it) may be reusable across a range of systems – Design decisions reuse à saves design costs + less risks Stakeholders communication – Architecture may be used as a focus of discussion by system stakeholders – Early design decisions reasoning, when it is still relatively easy to adapt

32. Architecture and software qualities Performance – Localise critical operations and minimise communications Security – Use a layered architecture with critical assets in the inner layers Safety – Localise safety-critical features in a small number of sub-systems Availability – Include redundant components and mechanisms for fault tolerance Maintainability – Use fine-grain, replaceable components These are all examples of TACTICS

33. Tactics A tactic is a design decision that refines a high level style and is influential in the control of a quality attribute response Tactics complement and refine styles that make up the architecture promotes tactic Design decision Quality attribute

34. Example: tactics for availability © David Garlan, lecture @GSSI, a.y., 2013/2014

35. Tactics may originate conflicts For example: • Using large-grain components improves performance but reduces maintainability • Introducing redundant data improves availability but makes security more difficult • Localising safety-related features may mean more communication so degraded performance

36. Architectural styles (aka patterns) © Len Bass, Paul Clements, Rick Kazman, Software Architecture in Practice, 3rd edition

37. Outline What is an architectural style? Styles catalogue Relation between tactics and patterns Tactics interaction Summary

38. What is an architectural style? An architectural style establishes a relationship between: • Context – A recurring situation in the world that gives rise to a problem • Problem – The problem, appropriately generalized, that arises in the context • Solution: – a set of element types • e.g., data repositories, processes, and objects – a set of interaction mechanisms or connectors • e.g., method calls, events, or message bus – a topological layout of the components – a set of semantic constraints

39. Common styles catalogue • Publish-subscribe • Layered • Shared-data • Client-server • Peer to peer • MVC • Pipes and filters

40. Publish-Subscribe Pattern Context – There are a number of independent producers and consumers of data that must interact. The precise number and nature of the data producers and consumers are not predetermined or fixed, nor is the data that they share. Problem – How can we create integration mechanisms that support the ability to transmit messages among the producers and consumers so they are unaware of each other’s identity, or potentially even their existence? Solution – Components can interact via announced messages, or events. Components may subscribe to a set of events. – Publisher components place events on the bus by announcing them; the connector then delivers those events to the subscriber components that have registered an interest in those events.

41. Publish-Subscribe Solution – 1 Elements: – Any component with at least one publish or subscribe port – The publish-subscribe connector, which will have announce and listen roles for components that wish to publish and subscribe to events Relations: – The attachment relation associates components with the publish-subscribe connector by prescribing which components announce events and which components are registered to receive events Weaknesses: – Typically increases latency and has a negative effect on scalability and predictability of message delivery time – Less control over ordering of messages – Delivery of messages is not guaranteed

42. Publish-subscribe example 1 © Len Bass, Paul Clements, Rick Kazman,

43. Publish-subscribe example 2 topics nodes

44. Layered Style (Virtual Machine Example) Java Virtual Machine Java Java Operating Processor System Virtual Machine Application (Virtual Machine Style)

45. The Layered System Style A layered system is organized hierarchically, each layer providing service to the layer above and below • Components – Programs or subprograms deployed in a layer • Connectors – Protocols • Procedure calls or system calls • Stylistic invariants – Each layer provides a service only to the immediate layer “above” (at the next higher level of abstraction) and uses the service only of the immediate layer “below” (at the next lower level of abstraction)

46. Layered System Example: OSI Protocol Stack Application Presentation Session Transport Network Data Link Physical Application Presentation Session Transport Network Data Link Physical Network Data Link Physical Network Data Link Physical

47. Layered System Advantages and Disadvantages Advantages – Decomposability: Effective separation of concerns and different level of abstractions – Maintainability: Changes that do not affect layer interfaces are easy to make – Adaptability/Portability: Can replace inner layers as long as interfaces remain the same – Understandability: Strict set of dependencies allow you to ignore outer layers Disadvantages – Not all systems are easily structured in a layered fashion – Performance degrades with too many layers – Can be difficult to cleanly assign functionality to the “right” layer

48. Shared-Data style Context Various computational components need to share and manipulate large amounts of data. This data does not belong solely to any one of those components. Problem How can systems store and manipulate persistent data that is accessed by multiple independent components? Solution In the shared-data pattern, interaction is dominated by the exchange of persistent data between multiple data accessors and at least one shared-data store. Exchange may be initiated by the accessors or the data store. The connector type is data reading and writing.

49. Shared Data Solution Elements: – Shared-data store • Concerns include types of data stored, data performance-oriented properties, data distribution, and number of accessors permitted – Data accessor component – Data reading and writing connector

50. Shared Data Example

51. Advantages and disadvantages Advantages – Simplicity: Only one connector (the blackboard) that everyone uses – Evolvability: New types of components can be added easily Disadvantages – Blackboard becomes a bottleneck with too many clients

52. Client-server • One component is a server offering a service • The other components are clients using the service • Server implementation is transparent but can be centralized or distributed, single-threaded or multi-threaded – Single interface point with physically distributed implementation – Dynamic, transparent selection from among multiple interface points

53. Client/Server Style example

54. 3-tier client-server systems 3-tier client-server systems are a common class of distributed business systems • First tier: Client (user interface) tier – Presentation logic • Second (middle, “business logic”) tier: Servers acting as “business objects”, encapsulating abstract, integrated models of multiple, disparate data sources – Computation • Third (back-end, database) tier: Legacy business applications providing data services – Database Weaknesses: Substantial up-front cost and complexity

55. 3-Tier Client-server systems (example) Web browser Key SignOnFilter *.do Main Servlet *.screen Template Servlet mappings.xml Screen JSP index.jsp Sign On Notifier screen definitions.xml sign-on-config. xml Order Facade OpcOrder TrackingService OpcPurchase OrderService Catalog Facade OPC Adventure Catalog DB User Mgmt Facade Client tier Web tier EJB tier Back end Client-side application Java EE filter Stateless session bean Java EE application Context listener Data store File Servlet Web services Container endpoint SOAP call File I/O Java call HTTP/ HTTPS JDBC

56. Peer-to-peer style Context: need to cooperate and collaborate to provide a service to a distributed community of users Problem: How can a set of “equal” distributed computational entities be connected to each other via a common protocol so that they can organize and share their services with high availability and scalability? Solution: components directly interact as peers. All peers are “equal” and no peer or group of peers can be critical for the health of the system. Peer-to-peer communication is typically a request/reply interaction without the asymmetry found in the client-server pattern

57. Example: Napster

58. Example: Gnutella

59. Example: Skype

60. Advantages and Disadvantages Advantages – Interoperability A natural high-level architectural style for heterogeneous distributed systems – Scalability: Powerful enough server tiers can accommodate many clients – Distributability: Components communicate over a network Disadvantages – Visibility, Maintainability: Difficult to analyze and debug • Distributed state • Potential for deadlock, starvation, race conditions, service outages – Require sophisticated interoperability mechanisms • Data marshalling and unmarshalling • Proxies and stubs for RPC • Legacy wrappers

61. Model-View-Controller Pattern Context: User interface software is typically the most frequently modified portion of an interactive application. Users often wish to look at data from different perspectives, such as a bar graph or a pie chart. These representations should both reflect the current state of the data. Problem: How can user interface functionality be kept separate from application functionality and yet still be responsive to user input, or to changes in the underlying application’s data? And how can multiple views of the user interface be created, maintained, and coordinated when the underlying application data changes? Solution: The model-view-controller (MVC) style separates application functionality into three kinds of components: – A model, which contains the application’s data – A view, which displays some portion of the underlying data and interacts with the user – A controller, which mediates between the model and the view and manages the notifications of state changes

62. MVC Example

63. MVC Solution - 1 The MVC pattern breaks system functionality into three components: a model, a view, and a controller that mediates between the model and the view • Elements: – The model is a representation of the application data or state, and it contains (or provides an interface to) application logic – The view is a user interface component that either produces a representation of the model for the user or allows for some form of user input, or both – The controller manages the interaction between the model and the view, translating user actions into changes to the model or changes to the view

64. MVC Solution - 2 Relations: The notifies relation connects instances of model, view, and controller, notifying elements of relevant state changes Constraints: – There must be at least one instance of each of model, view, and controller – The model component should not interact directly with the controller Weaknesses: – The complexity may not be worth it for simple user interfaces – The model, view, and controller abstractions may not be good fits for some user interface toolkits

65. Pipe and Filter Pattern Context: Many systems are required to transform streams of discrete data items, from input to output. Many types of transformations occur repeatedly in practice, and so it is desirable to create these as independent, reusable parts Problem: Such systems need to be divided into reusable, loosely coupled components with simple, generic interaction mechanisms. The components, being generic and loosely coupled, are easily reused. The components, being independent, can execute in parallel Solution: The pattern of interaction in the pipe-and-filter pattern is characterized by successive transformations of streams of data. Data arrives at a filter’s input port(s), is transformed, and then is passed via its output port(s) through a pipe to the next filter. A single filter can consume data from, or produce data to, one or more ports

66. Pipe and Filter Solution Data is transformed from a system’s external inputs to its external outputs through a series of transformations performed by its filters connected by pipes Elements: – Filter, which is a component that transforms data read on its input port(s) to data written on its output port(s) – Pipe, which is a connector that conveys data from a filter’s output port(s) to another filter’s input port(s). A pipe preserves the sequence of data items, and it does not alter the data passing through Relations: The attachment relation associates the output of filters with the input of pipes and vice versa Constraints: – Pipes connect filter output ports to filter input ports – Connected filters must agree on the type of data being passed along the connecting pipe

67. Pipe-and-filter example

68. Architectural styles vs design patterns Many similarities between patterns and styles – Goal: packaged engineering experience – Formulation: organization and interaction among “key” components But they have come from different communities – Many architectural styles have been well known for a long time in the software engineering community – Patterns are a relatively recent development in OO design Differences: Architectural styles Design patterns few many large-scale system organization localized, small-scale design solutions

69. Relationships between tactics and styles Styles are built from tactics à if a style is a molecule, a tactic is an atom MVC, for example utilizes the tactics: – Increase semantic coherence – Encapsulation – Use an intermediary – Use run-time binding

70. Tactics augment styles Styles solve a specific problem but are neutral or have weaknesses with respect to other qualities Consider the shared-data pattern – May have a single point of failure We may use tactics such as: – Increase resources will help performance – Maintain multiple copies will help availability

71. Tactics and interactions • Each tactic has pluses (its reason for being) and minuses – side effects. • Use of tactics can help alleviate the minuses • But nothing is free… à tactics should interact with each other

72. Tactics and interactions - 2 A common tactic for detecting faults is Ping/Echo Common side-effects of Ping/Echo are: • security – how to prevent a ping flood attack? • performance – how to ensure that the performance overhead of ping/echo is small? • modifiability – how to add ping/echo to the existing architecture?

73. Tactics and interactions - 3 System Ping/Echo Add to system Ping flood Performance overhead

74. Tactics and interactions - 4 A tactic to address the performance side-effect is “Increase Available Resources” Common side effects of Increase Available Resources are: • cost – increased resources cost more • performance – how to utilize the increase resources efficiently?

75. Tactics and interactions - 5 System Ping/Echo Add to system Ping flood Performance overhead Increase Available Resources Cost Resource Utilization

76. Tactics and interactions - 6 A tactic to address the efficient use of resources side-effect is “Scheduling Policy” Common side effects of Scheduling Policy are: • modifiability – how to add the scheduling policy to the existing architecture • modifiability – how to change the scheduling policy in the future?

77. Tactics and interactions - 7 System Ping/Echo Add to system Ping flood Performance overhead Increase Available Resources Cost Resource Utilization Scheduling Policy Add to system Modify policy

78. Tactics and interactions - 8 A tactic to address the addition of the scheduler to the system is “Use an Intermediary” Common side effects of Use an Intermediary are: • modifiability – how to ensure that all communication passes through the intermediary?

79. Tactics and interactions - 9 System Ping/Echo Add to system Ping flood Performance overhead Increase Available Resources Cost Resource Utilization Scheduling Policy Add to system Modify policy Use an Intermediary Ensure usage

80. Tactics and interactions – 10 A tactic to address the concern that all communication passes through the intermediary is “Restrict Communication Paths” Common side effects of Restrict Communication Paths are: • performance: – how to ensure that the performance overhead of the intermediary are not excessive? Note: this design problem has now become recursive!

81. How does this process end? • Each use of tactic introduces new concerns • Each new concern causes new tactics to be added • Are we in an infinite progression? No. Eventually the side-effects of each tactic become small enough to ignore

82. What this lecture means to you? Software architecture is the main instrument for reasoning about – high level of system design – system-level properties and qualities • e.g., modularity, evolvability, etc. – large-scale reuse Architectural style: reusable pattern – for solving recurrent problems – for obtaining qualities “out-of-the-box” It establishes a relationship between: – context – problem – solution • components, their relationships, constraints

83. Suggested readings 1. David Garlan. “Software architecture: a travelogue.” ICSE '14 Proceedings of the Conference on The Future of Software Engineering, ACM Press, 2014. 2. Perry, D. E.; Wolf, A. L. (1992). "Foundations for the study of software architecture". ACM SIGSOFT Software Engineering Notes 17 (4): 40.doi: 10.1145/141874.141884. 3. Garlan & Shaw (1994). "An Introduction to Software Architecture". Retrieved 2012-09-13.

84. References

85. Contact Ivano Malavolta | Post-doc researcher Gran Sasso Science Institute iivanoo ivano.malavolta@gssi.infn.it www.ivanomalavolta.com

Introduction to SOFTWARE ARCHITECTURE

Estás leyendo una previsualización.

Eche un vistazo a continuación

Introduction to SOFTWARE ARCHITECTURE

Más Contenido Relacionado

Presentaciones para usted (20)

A los espectadores también les gustó (20)

Similares a Introduction to SOFTWARE ARCHITECTURE (20)

Más de Ivano Malavolta (20)

Más reciente (20)

Introduction to SOFTWARE ARCHITECTURE