Basic Concepts Acknowledgement some slides from Software Architecture
Basic Concepts Acknowledgement: some slides from: Software Architecture: Foundations, Theory, and Practice; R. Taylor, N. Medvidovic, E. Dashofy
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” l “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 notfacet necessarily Design decisions encompass every of the system under development impact a system’s architecture) u Structure, Behavior, Interaction, Non-functional properties • How one defines “principal” will depend on what the stakeholders define as the system goals
Architecture Views l A software architecture is a complex design artifact l Many possible ‘views’ of the architecture u Cf. with buildings – floor plan, external, electrical, plumbing, airconditioning
RUP – 4+1 view model (Rational Unified Process)
RM-ODP Viewpoints (2001) Reference Model – Open Distributed Processing) Manager Business model Database Modeler Logical, data modeling Information Enterprise Designers Logical view of services Computational Operating Sys. Engineer Developer Servers, Comm, Engineering Technology Physical view of data and services (IDL, WSDL)
Temporal Aspects l A software architecture is a complex design artifact l Observation: Design decisions are made and unmade over a system’s lifetime Consequence: Architecture has a temporal aspect l At any given point in time a system has only one architecture u architecture will change over time 6
Prescriptive vs. Descriptive Architecture l prescriptive architecture: captures the design decisions made prior to the system’s construction u l as-conceived or as-intended architecture descriptive architecture describes how the system has been built u as-implemented or as-realized architecture 7
As-Designed vs. As-Implemented 8
Architectural Evolution l l l 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 u u u 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 9
Architectural Degradation Architectural drift : introduction of principal design decisions into the descriptive architecture that u are not included in, encompassed by, or implied by the prescriptive architecture u 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 10
Architectural Recovery If architectural degradation is allowed to occur, one will be forced to recover the system’s architecture sooner or later l Architectural recovery: determining a software system’s architecture from its implementation-level artifacts u Source code, executables, deployment 11
Implementation-Level View of an Application Complex and virtually incomprehensible! 12
Deployment l A software system cannot fulfill its purpose until it is deployed u Executable modules are physically placed on the hardware devices on which they are supposed to run l The deployment view of an architecture can be critical in assessing whether the system will be able to satisfy its requirements l Possible assessment dimensions u u u Available memory Power consumption Required network bandwidth 13
A System’s Deployment Architectural Perspective 14
Software Architecture’s Elements l A software system’s architecture generally involves composition and interplay of different elements u Processing Components u Data (also referred as information or state) Connectors u Interaction 15
Components 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 u u u l 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 16
Connectors 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 l In many systems connectors are usually simple procedure calls or shared data accesses u More sophisticated connectors are possible. E. g. , l l l Distribution connectors: RPC, message passing, streaming. Wrapper/adaptor connectors typically provide application-independent interaction facilities 17
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 [programming] Design Patterns Architectural Styles Architectural Patterns Domain Specific Software Architectures 18
19
Domain-Specific Software Architectures l A DSSA is an assemblage of software components u u u l l 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. 20
Architectural Patterns 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. 21
State-Logic-Display: Three-Tiered Pattern l Application Examples u Business applications u Multi-player games u Web-based applications 22
Model-View-Controller (MVC) l l l 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. 23
Sense-Compute-Control Objective: Structuring embedded control applications 24
The Lunar Lander l A simple computer game that appeared in the 1960’s l Simple concept: u You (the pilot) control the descent rate of the Apolloera Lunar Lander l Throttle setting controls descent engine l Limited fuel l Initial altitude and speed preset l If you land with a descent rate of < 5 fps: you win (whethere’s fuel left or not) u “Advanced” version: joystick controls attitude & horizontal motion 25
Sense-Compute-Control LL 26
27
Talk today: n. Vidia CTO Project Groups Lab + Assignment l 1) Deploy an application to Google App Engine. l 2) Use Google's login l 3) Send data to the servers. l 4) Store data l 5) Display stored data (dynamic page, and not only a static one) l 6) Detect current location l 7) Use a third-party component (a map) l 8) Add custom markers to a map.
Definitions of Architectural Style l architectural style: named collection of architectural design decisions that u u u 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. l A primary way of characterizing lessons from experience in software system design l Reflect less domain specificity than architectural patterns l Useful in determining everything from subroutine structure to top-level application structure 30
Common styles l Traditional, u u language-influenced Main program + subroutines Object-oriented l Layered u u Virtual machines Client-server l Data-flow u u styles Batch sequential Pipe and filter l Shared-state u u Blackboard Rule based l Interpreter u u Interpreter Mobile code l Implicit u u invocation Event-based Publish-subscribe l Peer-to-peer
The beast you fight: Complexity l A complex system can no longer be made by a single person l A very complex system can no longer be comprehended by a single person How to tackle complexity?
The Tools of “Software Engineering 101” l Abstraction u (bottom-up): look at details, and abstract “up” to concepts u (top-down): choose concepts, then add detailed substructure, and move “down” l Separation of concerns 33
Common styles l Traditional, influenced u u language- Main program and subroutines Object-oriented l Layered u u Virtual machines Client-server l Data-flow u u styles Batch sequential Pipe and filter l Shared-state u u Blackboard Rule based l Interpreter u u Interpreter Mobile code l Implicit u u invocation Event-based Publish-subscribe l Peer-to-peer
Isn’t this constraining? Yes No Incremental or “big vision”?
Observations l Different styles result in … … different architectures u …. with greatly differing properties u l A style does not fully determine resulting architecture A single style can result in different architectures u Considerable room for l Individual judgment l Variations among architects u l A style defines domain of discourse About problem (domain) u About resulting system u 36
Basic Properties of Styles l A vocabulary of design elements u u l Component and connector types; data elements e. g. , pipes, filters, objects, servers A set of configuration rules u Topological constraints that determine allowed compositions of elements l l e. g. , a component may be connected to at most two other components A semantic interpretation u Compositions of design elements have well-defined meanings 37
Benefits of Using Styles l Design reuse u l Code reuse u l Supported by style standardization Style-specific analyses u l A phrase such as “client-server” conveys a lot of information Interoperability u l Shared implementations of invariant aspects of a style Understandability of system organization u l Well-understood solutions applied to new problems Enabled by the constrained design space Visualizations u Style-specific depictions matching engineers’ mental models 38
Style Analysis Dimensions l What is the design vocabulary? u l l l Component and connector types What What are the allowable structural patterns? is the underlying computational model? are the essential invariants of the style? are common examples of its use? are the (dis)advantages of using the style? are the style’s specializations? 39
Common Styles l Traditional, language-influenced u u l Layered u u l u u u Interpreter Mobile code Implicit invocation u u l Blackboard Rule based Interpreter u l Batch sequential Pipe and filter Shared state u l Virtual machines Client-server Data-flow styles u l Main program and subroutines Object-oriented Event-based Publish-subscribe Peer-to-peer 40
Our example application: The Lunar Lander Game l A simple computer game u You (the pilot) control the descent rate of the Apollo-era Lunar Lander l Throttle setting controls descent engine l Limited fuel l Initial altitude and speed preset l If you land with a descent rate of < 5 fps: you win (whethere’s fuel left or not) “Advanced” version: joystick controls attitude & horizontal motion 41
Main Program and Subroutines LL 42
Object-Oriented Style l Components are objects u Data and associated operations l Connectors are messages and method invocations l Style invariants u u l Advantages u u u l Objects are responsible for their internal representation integrity Internal representation is hidden “Infinite malleability” of object internals System decomposition into sets of interacting agents Reuse Disadvantages u u Objects must know identities of servers Side effects in object method invocations 43
Object-Oriented LL 44
OO/LL in UML 45
Layered Styles l Hierarchical system organization u u l Each layer acts as a u u l l l Each layer exposes an interface (API) to be used by above layers “Multi-level client-server” 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 46
Layered Style (cont’d) l Advantages Increasing abstraction levels u Evolvability / reuse / separation of concerns u l l u l 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 u Performance u Determining the correct abstraction level can be hard u l Layers may have to be skipped (for performance or functionality reasons) 47
Layered Systems/Virtual Machines 48
Layered LL 49
Client-Server Style l l 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 50
Client-Server LL 51
Data-Flow Styles • • Batch Sequential Pipes and Filters 52
Pipes and Filters Style l Components are filters u u l Connectors are pipes u l u Filters are independent (no shared state) Filter has no knowledge of up- or down-stream filters Examples u u l Conduits for data streams Style invariants u l Transform input data streams into output data streams Possibly incremental production of output UNIX shell Distributed systems signal processing parallel programming Example: ls invoices | grep -e August | sort 53
Pipe and Filter (cont’d) l Variations u u u l Pipelines — linear sequences of filters Bounded pipes — limited amount of data on a pipe Typed pipes — data strongly typed Advantages u u Easy to understand: System behavior is a succession of component behaviors Filter addition, replacement, and reuse l Possible to hook any two filters together Certain analyses l Throughput, latency, deadlock Concurrent execution 54
Pipe and Filter (cont’d) l Disadvantages u u Batch organization of processing l Hard to retrofit for interactive applications Lowest common denominator on data transmission 55
Pipe and Filter LL 56
Data-Flow Styles Batch Sequential u u l Pipe-and-filter where all data is processed into one batch! Separate programs are executed in order; data is passed as an aggregate from one program to the next. Connectors: tapes between the programs, a. k. a. “sneaker-net ” Data Elements: Explicit, aggregate elements passed from one component to the next upon completion of the producing program’s execution. Typical uses: Transaction processing in financial systems. 57
Batch-Sequential: A Financial Application 58
Batch-Sequential LL Not a recipe for a successful lunar mission! 59
Shared state styles l l Blackboard Rule-based style
Blackboard Style l Summary: Independent programs (e. g. , knowledge sources) communicate exclusively a global data repository (the blackboard) l Components: u u l Connectors: Various u l l Central data structure — blackboard Components operating on the blackboard Access to the blackboard may be by direct memory reference, or through a procedure call, or a query language System control is entirely driven by the blackboard state Examples u u u Typically used for AI systems Integrated software environments (e. g. , Interlisp) Compiler architecture 61
Blackboard LL 62
Rule-Based/Expert System Style Inference engine parses user input and determines whether it is a fact/rule or a query. u u If fact/rule, it adds this entry to the knowledge base. I query it queries the knowledge base for applicable rules and attempts to resolve the query. 63
Rule-Based Style (cont’d) l Components: User interface, inference engine, knowledge base l l l Connectors: Often components are tightly interconnected, with direct procedure calls and/or shared memory. Data Elements: Facts and queries Behavior of the application can be very easily modified through addition or deletion of rules from the knowledge base. Caution: When a large number of rules are involved understanding the interactions between multiple rules affected by the same facts can become difficult. Relationship to languages: Prolog 64
Rule Based LL 65
Interpreter Styles • • Basic Interpreter Mobile code 66
Basic Interpreter Style Interpreter: parse and execute input commands, updating own state l Components: Command interpreter, program/interpreter state, user interface. l Connectors: Typically direct procedure calls / shared state. l Data elements: commands l Qualities yielded. Highly dynamic behavior possible, where the set of commands is dynamically modified. u u l System architecture may remain constant while new capabilities are created based upon existing primitives. Good end-user programmability: may support dynamically changing set of capabilities Programming languages: Lisp, Scheme, Python 67
Interpreter LL 68
Mobile-Code Style l l l Summary: a data element (some representation of a program) is dynamically transformed into a data processing component. Components: “Execution dock”, which handles receipt of code and state; code compiler/interpreter Connectors: Network protocols and elements for packaging code and data for transmission. Data Elements: Representations of code as data; program state; data Variants: Code-on-demand, remote evaluation, and mobile agent. 69
Mobile Code LL Scripting languages (i. e. Java. Script, VBScript), Active. X control, embedded Word/Excel macros. 70
Implicit Invocation Style l Event announcement instead of method invocation u u “Listeners” register interest in and associate methods with events System invokes all registered methods implicitly l Component interfaces are methods and events l Two types of connectors: events & procedure calls u l Invocation is either explicit or implicit in response to events Style invariants u u “Announcers” are unaware of their events’ effects No assumption about processing order in response to events 71
Implicit Invocation Style (cont’d) l Advantages u u Component reuse Flexible system evolution l l Both at system construction-time & run-time Disadvantages u u 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 72
Implicit Invocation Styles l l Event based Publish-subscribe 73
Publish-Subscribe l Components: Publishers, subscribers, proxies for managing distribution u u l l l Subscribers register/deregister to receive specific messages or specific content. Publishers broadcast messages to subscribers either synchronously or asynchronously. Connectors: Typically a network protocol is required. Contentbased subscription requires sophisticated connectors. Data Elements: Subscriptions, notifications, published information Topology: Subscribers connect to publishers either directly or may receive notifications via a network protocol from intermediaries l Qualities yielded: l efficient one-way dissemination of information u low-coupling of components Caution: broadcast may be needed u 74
Pub-Sub LL 75
Event-Based Style Independent components asynchronously emit and receive events communicated over event buses l l l Components: Independent, concurrent event generators and/or consumers Connectors: Event buses (at least one) Data Elements: Events – data sent as a first-class entity over the event bus Topology: Components communicate with the event buses, not directly to each other. u Variants: Component communication with the event bus may either be push or pull based. Qualities yielded: Highly scalable, easy to evolve, sometimes effective for highly distributed applications. 76
Event-based LL 77
Peer-to-Peer Style l State and behavior are distributed among peers which can act as either clients or servers. l Peers: independent components, having their own state and control thread. l l l Connectors: Network protocols, often custom. Data Elements: Network messages Topology: Network (may have redundant connections between peers); can vary arbitrarily and dynamically l Supports decentralized computing with flow of control and resources distributed among peers. l Highly robust in the face of failure of any given node. Scalable in terms of access to resources and computing power. But caution on the protocol! 78
Peer-to-Peer LL 79
Architectural Style Summary Use It When Avoid It When Language-influenced styles Main Program & Main program controls Application is small and simple. Subroutines program execution, calling multiple subroutines. Object-oriented Objects encapsulate state and accessing functions Complex data structures needed. Future modifications likely. • Close mapping between external • Application is distributed in a entities and internal objects is heterogeneous network. sensible. • Strong independence between • Many complex and interrelated data components required structures. • High performance required. Layered Virtual Machines Virtual machine, or a • Many applications can be based layer, offers services upon a single, common layer of to layers above it services. • Interface service specification resilient when implementation of a layer must change. Client-server • Many levels are required (causes inefficiency). • Data structures must be accessed from multiple layers. Clients request • Centralization of computation and • Centrality presents a singleservice from a server data at a single location (the server) point-of-failure risk; Network promotes manageability; end-user bandwidth limited; Client processing limited to data entry and machine capabilities rival 80 or exceed the server’s. presentation.
Data-flow styles Batch Separate programs Problem easily formulated as • Interactivity or concurrency sequential executed sequentially, a set of sequential, severable between components with batched input steps. necessary or desirable. • Random-access to data required. Pipe-and-filter Separate programs, (aka. Filters) executed, potentially concurrently. Pipes route data streams between filters [As with batch-sequential] • Filters are useful in more than one application. • Data structures easily serializable. • Interaction between components required. • Exchange of complex data structures between components required. Shared memory Blackboard Independent programs, access and communicate exclusively through a global repository known as blackboard • All calculation centers on a common, changing data structure; • Order of processing dynamically determined and data-driven. • Programs deal with independent parts of the common data. • Interface to common data susceptible to change. When interactions between the independent programs require complex regulation. Rule-based Use facts or rules entered into the knowledge base to resolve a query • Problem data and queries expressible as simple rules over which inference may be performed. • Number of rules is large. • Interaction between rules present. • High-performance required.
Interpreter parses and executes the input stream, updating the state maintained by the interpreter Highly dynamic behavior High performance required. High degree of end-user customizability. Mobile Code is mobile, that When it is more efficient Security of mobile code is, it is executed in to move processing cannot be assured, or a remote host to a data set than the sandboxed. data set to When tight control of processing. versions of deployed When it is desirable to software is required. dynamically customize a local processing node through inclusion of external code
Implicit Invocation Publishers broadcast messages to subscribers • Independent components asynchronously emit and receive events communicated over event buses • Peer-to-peer Peers hold state and behavior and can act as both clients and servers • Publishsubscribe Event-based • • • Components are very • loosely coupled. Subscription data is small and efficiently transported. Components are concurrent and independent. Components heterogeneous and network-distributed. • Peers are distributed in a • network, can be heterogeneous, and mutually independent. • Robust in face of independent failures. When middleware to support high-volume data is unavailable. Guarantees on real-time processing of events is required. Trustworthiness of independent peers cannot be assured or managed. Resource discovery inefficient without designated nodes.
- Slides: 83