[2017/2018] introduction to software architecture
TRANSCRIPT
![Page 1: [2017/2018] Introduction to Software Architecture](https://reader034.vdocuments.us/reader034/viewer/2022051710/5a6d320d7f8b9ae5418b4f6d/html5/thumbnails/1.jpg)
Ivano Malavolta
Introduction to
SOFTWARE ARCHITECTURE
VRIJEUNIVERSITEITAMSTERDAM
![Page 2: [2017/2018] Introduction to Software Architecture](https://reader034.vdocuments.us/reader034/viewer/2022051710/5a6d320d7f8b9ae5418b4f6d/html5/thumbnails/2.jpg)
Roadmap
Definitions and concepts
Architectural styles
![Page 3: [2017/2018] Introduction to Software Architecture](https://reader034.vdocuments.us/reader034/viewer/2022051710/5a6d320d7f8b9ae5418b4f6d/html5/thumbnails/3.jpg)
Some contents of this part of lecture extracted from Henry Muccini’s lecture on software architecture at the University of L’Aquila (Italy)
Definitions and concepts
![Page 4: [2017/2018] Introduction to Software Architecture](https://reader034.vdocuments.us/reader034/viewer/2022051710/5a6d320d7f8b9ae5418b4f6d/html5/thumbnails/4.jpg)
Outline
Definitions
Static descriptions
Dynamic descriptions
Why software architecture?
![Page 5: [2017/2018] Introduction to Software Architecture](https://reader034.vdocuments.us/reader034/viewer/2022051710/5a6d320d7f8b9ae5418b4f6d/html5/thumbnails/5.jpg)
Context
© David Garlan, lecture @GSSI, a.y., 2013/2014
![Page 6: [2017/2018] Introduction to Software Architecture](https://reader034.vdocuments.us/reader034/viewer/2022051710/5a6d320d7f8b9ae5418b4f6d/html5/thumbnails/6.jpg)
Context
© David Garlan, lecture @GSSI, a.y., 2013/2014
![Page 7: [2017/2018] Introduction to Software Architecture](https://reader034.vdocuments.us/reader034/viewer/2022051710/5a6d320d7f8b9ae5418b4f6d/html5/thumbnails/7.jpg)
Context
© David Garlan, lecture @GSSI, a.y., 2013/2014
![Page 8: [2017/2018] Introduction to Software Architecture](https://reader034.vdocuments.us/reader034/viewer/2022051710/5a6d320d7f8b9ae5418b4f6d/html5/thumbnails/8.jpg)
Software Architecture definitionsPerry 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 architecturaldesign. The output of this design process is a description of the SA.
![Page 9: [2017/2018] Introduction to Software Architecture](https://reader034.vdocuments.us/reader034/viewer/2022051710/5a6d320d7f8b9ae5418b4f6d/html5/thumbnails/9.jpg)
Develop systems “architecturally”
– Design at an architectural level of abstraction– Build systems compositionally from parts
– Reason on critical requirements before implementing them– Reuse codified architectural design expertise à patterns & styles
If you think good architecture is expensive,
try bad architecture.
... Brian Foote and Joseph Yoder
![Page 10: [2017/2018] Introduction to Software Architecture](https://reader034.vdocuments.us/reader034/viewer/2022051710/5a6d320d7f8b9ae5418b4f6d/html5/thumbnails/10.jpg)
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)
![Page 11: [2017/2018] Introduction to Software Architecture](https://reader034.vdocuments.us/reader034/viewer/2022051710/5a6d320d7f8b9ae5418b4f6d/html5/thumbnails/11.jpg)
Outline
Definitions
Static descriptions
Dynamic descriptions
Why software architecture?
![Page 12: [2017/2018] Introduction to Software Architecture](https://reader034.vdocuments.us/reader034/viewer/2022051710/5a6d320d7f8b9ae5418b4f6d/html5/thumbnails/12.jpg)
ComponentsA 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, ...
C1S1S2S3
S’xS’Y
provided services
required services
![Page 13: [2017/2018] Introduction to Software Architecture](https://reader034.vdocuments.us/reader034/viewer/2022051710/5a6d320d7f8b9ae5418b4f6d/html5/thumbnails/13.jpg)
Example
![Page 14: [2017/2018] Introduction to Software Architecture](https://reader034.vdocuments.us/reader034/viewer/2022051710/5a6d320d7f8b9ae5418b4f6d/html5/thumbnails/14.jpg)
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
![Page 15: [2017/2018] Introduction to Software Architecture](https://reader034.vdocuments.us/reader034/viewer/2022051710/5a6d320d7f8b9ae5418b4f6d/html5/thumbnails/15.jpg)
ConnectorsA 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
![Page 16: [2017/2018] Introduction to Software Architecture](https://reader034.vdocuments.us/reader034/viewer/2022051710/5a6d320d7f8b9ae5418b4f6d/html5/thumbnails/16.jpg)
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
![Page 17: [2017/2018] Introduction to Software Architecture](https://reader034.vdocuments.us/reader034/viewer/2022051710/5a6d320d7f8b9ae5418b4f6d/html5/thumbnails/17.jpg)
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)
![Page 18: [2017/2018] Introduction to Software Architecture](https://reader034.vdocuments.us/reader034/viewer/2022051710/5a6d320d7f8b9ae5418b4f6d/html5/thumbnails/18.jpg)
Example
GUI
FeedServiceFeedService
CommonAction
NewsFeederAction
AdminAction
Factory
FeedDelegatePOJOs
NewsFeederDAO FeedDAO
NewsFeederDAO FeedDAO
FeedDelegate
Transfer Object
ValidatorService
NewsFeederDelegatePOJOs
NewsFeederDelegate
Browser(html
javascript)
Web Services
DATABASE
TrasformationValidation
BusinessFactory
ValidationService
BusinessExtensionIn
BusinessExtensionOut
PresentationExtensionOut
PresentationExtensionIn
![Page 19: [2017/2018] Introduction to Software Architecture](https://reader034.vdocuments.us/reader034/viewer/2022051710/5a6d320d7f8b9ae5418b4f6d/html5/thumbnails/19.jpg)
Outline
Definitions
Static descriptions
Dynamic descriptions
Why software architecture?
![Page 20: [2017/2018] Introduction to Software Architecture](https://reader034.vdocuments.us/reader034/viewer/2022051710/5a6d320d7f8b9ae5418b4f6d/html5/thumbnails/20.jpg)
SA dynamics
The SA dynamics is expressed in terms of:
- Labeled Transition Systems - Automata
- UML StateCharts, Sequence Diagrams, Activity Diagrams- State Diagrams- Message Sequence Charts
- …
![Page 21: [2017/2018] Introduction to Software Architecture](https://reader034.vdocuments.us/reader034/viewer/2022051710/5a6d320d7f8b9ae5418b4f6d/html5/thumbnails/21.jpg)
Customer Interface
Customer Process
Web Server
Customer Server
Order Server
Cart Server
Catalog ServerDelivery OrderProcess
SA Static Description
An example : e-commerce system
![Page 22: [2017/2018] Introduction to Software Architecture](https://reader034.vdocuments.us/reader034/viewer/2022051710/5a6d320d7f8b9ae5418b4f6d/html5/thumbnails/22.jpg)
SA Dynamic Description : Browse Catalogue Sequence Diagram
CustomerInterface
Registered Customer
CustomerProcess CatalogServer
Catalog DBInvolved
BrowseCatalogBrowseCatalog
ReadStatus
Catalog Page
Output Page
Catalog Info
An example : e-commerce system
![Page 23: [2017/2018] Introduction to Software Architecture](https://reader034.vdocuments.us/reader034/viewer/2022051710/5a6d320d7f8b9ae5418b4f6d/html5/thumbnails/23.jpg)
CustomerInterface
Registered Customer
CustomerProcess CartServer
PlaceOrderReqPlaceOrder
ReadStatus
Cart DBInvolved
pageOrderOutputPage
Order DBInvolved
OrderServer
EmptyCart
Cart DBInvolved
CustomerServer
ReadInfoCustomerDB Involved
DeliveryOrderProcess
createNewOrder
OrderInfo
newOrder
CartInfo
CustomerInfo
OrderInfo
SA Dynamic Description : Place Order Sequence Diagram (success)
An example : e-commerce system
![Page 24: [2017/2018] Introduction to Software Architecture](https://reader034.vdocuments.us/reader034/viewer/2022051710/5a6d320d7f8b9ae5418b4f6d/html5/thumbnails/24.jpg)
SA Dynamic Description : Place Order Sequence Diagram (empty cart)
CustomerInterface
Registered Customer
CustomerProcess CartServer
PlaceOrderReqPlaceOrder
ReadStatus
Cart DBInvolved
errorPageOutputPage
emptyCart
An example : e-commerce system
![Page 25: [2017/2018] Introduction to Software Architecture](https://reader034.vdocuments.us/reader034/viewer/2022051710/5a6d320d7f8b9ae5418b4f6d/html5/thumbnails/25.jpg)
Outline
Definitions
Static descriptions
Dynamic descriptions
Why software architecture?
![Page 26: [2017/2018] Introduction to Software Architecture](https://reader034.vdocuments.us/reader034/viewer/2022051710/5a6d320d7f8b9ae5418b4f6d/html5/thumbnails/26.jpg)
Advantages of explicit architecture
System analysis– Analysis of system features before they are 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
![Page 27: [2017/2018] Introduction to Software Architecture](https://reader034.vdocuments.us/reader034/viewer/2022051710/5a6d320d7f8b9ae5418b4f6d/html5/thumbnails/27.jpg)
Architecture and software qualitiesPerformance
– 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
![Page 28: [2017/2018] Introduction to Software Architecture](https://reader034.vdocuments.us/reader034/viewer/2022051710/5a6d320d7f8b9ae5418b4f6d/html5/thumbnails/28.jpg)
Tactics
A tactic is a design decision that refines a high level styleand is influential in the control of a quality attribute response
Tactics complement and refine styles that make up the architecture
Design decision Quality attributepromotes tactic
![Page 29: [2017/2018] Introduction to Software Architecture](https://reader034.vdocuments.us/reader034/viewer/2022051710/5a6d320d7f8b9ae5418b4f6d/html5/thumbnails/29.jpg)
Example: tactics for availability
© David Garlan, lecture @GSSI, a.y., 2013/2014
![Page 30: [2017/2018] Introduction to Software Architecture](https://reader034.vdocuments.us/reader034/viewer/2022051710/5a6d320d7f8b9ae5418b4f6d/html5/thumbnails/30.jpg)
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
![Page 31: [2017/2018] Introduction to Software Architecture](https://reader034.vdocuments.us/reader034/viewer/2022051710/5a6d320d7f8b9ae5418b4f6d/html5/thumbnails/31.jpg)
© Len Bass, Paul Clements, Rick Kazman, Software Architecture in Practice, 3rd edition
Architectural styles(aka patterns)
![Page 32: [2017/2018] Introduction to Software Architecture](https://reader034.vdocuments.us/reader034/viewer/2022051710/5a6d320d7f8b9ae5418b4f6d/html5/thumbnails/32.jpg)
Outline
What is an architectural style?Styles catalogue
![Page 33: [2017/2018] Introduction to Software Architecture](https://reader034.vdocuments.us/reader034/viewer/2022051710/5a6d320d7f8b9ae5418b4f6d/html5/thumbnails/33.jpg)
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
![Page 34: [2017/2018] Introduction to Software Architecture](https://reader034.vdocuments.us/reader034/viewer/2022051710/5a6d320d7f8b9ae5418b4f6d/html5/thumbnails/34.jpg)
Common styles catalogue
• MVC• Publish-subscribe• Layered• Shared-data• Peer to peer• Pipes and filters
![Page 35: [2017/2018] Introduction to Software Architecture](https://reader034.vdocuments.us/reader034/viewer/2022051710/5a6d320d7f8b9ae5418b4f6d/html5/thumbnails/35.jpg)
Model-View-Controller styleContext: 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
![Page 36: [2017/2018] Introduction to Software Architecture](https://reader034.vdocuments.us/reader034/viewer/2022051710/5a6d320d7f8b9ae5418b4f6d/html5/thumbnails/36.jpg)
MVC Example
![Page 37: [2017/2018] Introduction to Software Architecture](https://reader034.vdocuments.us/reader034/viewer/2022051710/5a6d320d7f8b9ae5418b4f6d/html5/thumbnails/37.jpg)
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
![Page 38: [2017/2018] Introduction to Software Architecture](https://reader034.vdocuments.us/reader034/viewer/2022051710/5a6d320d7f8b9ae5418b4f6d/html5/thumbnails/38.jpg)
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
![Page 39: [2017/2018] Introduction to Software Architecture](https://reader034.vdocuments.us/reader034/viewer/2022051710/5a6d320d7f8b9ae5418b4f6d/html5/thumbnails/39.jpg)
Publish-Subscribe styleContext
– 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 interact via announced messages, or events.
Components 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.
![Page 40: [2017/2018] Introduction to Software Architecture](https://reader034.vdocuments.us/reader034/viewer/2022051710/5a6d320d7f8b9ae5418b4f6d/html5/thumbnails/40.jpg)
Publish-subscribe example 1
topics nodes
![Page 41: [2017/2018] Introduction to Software Architecture](https://reader034.vdocuments.us/reader034/viewer/2022051710/5a6d320d7f8b9ae5418b4f6d/html5/thumbnails/41.jpg)
Publish-subscribe example 2
© Len Bass, Paul Clements, Rick Kazman,
![Page 42: [2017/2018] Introduction to Software Architecture](https://reader034.vdocuments.us/reader034/viewer/2022051710/5a6d320d7f8b9ae5418b4f6d/html5/thumbnails/42.jpg)
Publish-Subscribe Solution
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
![Page 43: [2017/2018] Introduction to Software Architecture](https://reader034.vdocuments.us/reader034/viewer/2022051710/5a6d320d7f8b9ae5418b4f6d/html5/thumbnails/43.jpg)
Layered Style (Virtual Machine Example)
Java Virtual Machine
Processor
Operating
System
Java
Virtual Machine
Java
Application
(Virtual Machine Style)
![Page 44: [2017/2018] Introduction to Software Architecture](https://reader034.vdocuments.us/reader034/viewer/2022051710/5a6d320d7f8b9ae5418b4f6d/html5/thumbnails/44.jpg)
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)
![Page 45: [2017/2018] Introduction to Software Architecture](https://reader034.vdocuments.us/reader034/viewer/2022051710/5a6d320d7f8b9ae5418b4f6d/html5/thumbnails/45.jpg)
Layered System Example: OSI Protocol Stack
ApplicationPresentation
SessionTransportNetworkData LinkPhysical
ApplicationPresentation
SessionTransportNetworkData LinkPhysical
NetworkData LinkPhysical
NetworkData LinkPhysical
![Page 46: [2017/2018] Introduction to Software Architecture](https://reader034.vdocuments.us/reader034/viewer/2022051710/5a6d320d7f8b9ae5418b4f6d/html5/thumbnails/46.jpg)
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 allows 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
![Page 47: [2017/2018] Introduction to Software Architecture](https://reader034.vdocuments.us/reader034/viewer/2022051710/5a6d320d7f8b9ae5418b4f6d/html5/thumbnails/47.jpg)
Shared-Data style
ContextVarious computational components need to share and manipulate large amounts of data. This data does not belong solely to any one of those components.
ProblemHow can systems store and manipulate persistent data that is accessed by multiple independent components?
SolutionIn 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.
![Page 48: [2017/2018] Introduction to Software Architecture](https://reader034.vdocuments.us/reader034/viewer/2022051710/5a6d320d7f8b9ae5418b4f6d/html5/thumbnails/48.jpg)
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
![Page 49: [2017/2018] Introduction to Software Architecture](https://reader034.vdocuments.us/reader034/viewer/2022051710/5a6d320d7f8b9ae5418b4f6d/html5/thumbnails/49.jpg)
Shared Data Example
![Page 50: [2017/2018] Introduction to Software Architecture](https://reader034.vdocuments.us/reader034/viewer/2022051710/5a6d320d7f8b9ae5418b4f6d/html5/thumbnails/50.jpg)
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
![Page 51: [2017/2018] Introduction to Software Architecture](https://reader034.vdocuments.us/reader034/viewer/2022051710/5a6d320d7f8b9ae5418b4f6d/html5/thumbnails/51.jpg)
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
![Page 52: [2017/2018] Introduction to Software Architecture](https://reader034.vdocuments.us/reader034/viewer/2022051710/5a6d320d7f8b9ae5418b4f6d/html5/thumbnails/52.jpg)
Example: Skype
![Page 53: [2017/2018] Introduction to Software Architecture](https://reader034.vdocuments.us/reader034/viewer/2022051710/5a6d320d7f8b9ae5418b4f6d/html5/thumbnails/53.jpg)
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
![Page 54: [2017/2018] Introduction to Software Architecture](https://reader034.vdocuments.us/reader034/viewer/2022051710/5a6d320d7f8b9ae5418b4f6d/html5/thumbnails/54.jpg)
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
![Page 55: [2017/2018] Introduction to Software Architecture](https://reader034.vdocuments.us/reader034/viewer/2022051710/5a6d320d7f8b9ae5418b4f6d/html5/thumbnails/55.jpg)
Pipe-and-filter example
![Page 56: [2017/2018] Introduction to Software Architecture](https://reader034.vdocuments.us/reader034/viewer/2022051710/5a6d320d7f8b9ae5418b4f6d/html5/thumbnails/56.jpg)
Pipe and Filter SolutionData 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
![Page 57: [2017/2018] Introduction to Software Architecture](https://reader034.vdocuments.us/reader034/viewer/2022051710/5a6d320d7f8b9ae5418b4f6d/html5/thumbnails/57.jpg)
Relationships between tactics and stylesStyles 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
![Page 58: [2017/2018] Introduction to Software Architecture](https://reader034.vdocuments.us/reader034/viewer/2022051710/5a6d320d7f8b9ae5418b4f6d/html5/thumbnails/58.jpg)
What this lecture means to you?
Software architecture is the main instrument for reasoning about
– high level of system design– system-level quality
• e.g., evolvability, performance, security, etc.
– large-scale reuse
Architectural style: reusable pattern – for solving recurrent problems– for obtaining qualities “out-of-the-box”
![Page 59: [2017/2018] Introduction to Software Architecture](https://reader034.vdocuments.us/reader034/viewer/2022051710/5a6d320d7f8b9ae5418b4f6d/html5/thumbnails/59.jpg)
Suggested readings
1. David Garlan. “Software architecture: a travelogue.” ICSE '14Proceedings of the Conference on The Future of SoftwareEngineering, ACM Press, 2014.
1. Perry, D. E.; Wolf, A. L. (1992). "Foundations for the study of softwarearchitecture". ACM SIGSOFT Software Engineering Notes 17 (4):40.doi:10.1145/141874.141884.
2. Garlan & Shaw (1994). "An Introduction to Software Architecture".Retrieved 2012-09-13.
![Page 60: [2017/2018] Introduction to Software Architecture](https://reader034.vdocuments.us/reader034/viewer/2022051710/5a6d320d7f8b9ae5418b4f6d/html5/thumbnails/60.jpg)
References
![Page 61: [2017/2018] Introduction to Software Architecture](https://reader034.vdocuments.us/reader034/viewer/2022051710/5a6d320d7f8b9ae5418b4f6d/html5/thumbnails/61.jpg)
ContactIvano Malavolta |
Assistant professorVrije Universiteit Amsterdam
iivanoo
www.ivanomalavolta.com