Software Architecture Introduction

Software Architecture
Notes compiled by Prof. Suresh Mestry Mobile No:8097404245
Introduction to Software Architecture

Basic Idea about Software Architecture Software Architecture is the way of decomposing complex system into many sub problems or subsystem. The Institute of Electrical and Electronic Engineers (IEEE) recently issued a recommended practice regarding Software Architecture: IEEE 1471. The definitions we provide in this book are closely aligned with IEEE 1471. These include definitions of system, stakeholder, architect, architecture, architectural views and architectural viewpoints. IEEE 1471 defines the following key terms: System is a set of components that accomplishes a specific function or set of functions. Architecture is the fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution. Architectural Description is a set of products that document the architecture. Architectural View is a representation of a particular system or part of a system from a particular perspective. Architectural Viewpoint is a template that describes how to create and use an architectural view. A viewpoint includes a name, stakeholders, concerns addressed by the viewpoint, and the modeling and analytic conventions. Design: There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. - C.A.R. Hoare What Is Design? Requirements specification was about the WHAT the system will do Design is about the HOW the system will perform its functions provides the overall decomposition of the system allows splitting the work among a team of developers also lays down the groundwork for achieving non-functional requirements (Performance, maintainability, reusability, etc.) takes target technology into account (e.g., kind of middleware, database design, etc.) Software Development Activities Requirements Elicitation Requirements Analysis (e.g., Structured Analysis, OO Analysis) analyzing requirements and working towards a conceptual model without taking the target implementation technology into account Useful if the conceptual gap between requirements and implementation is large
Part of requirements engineering (but may produce more than what is going to be part of the requirement spec) Design coming up with solution models taking the target implementation technology into account. Implementation Test ... Levels of Design Architectural design (also: high-level design) Architecture - the overall structure: main modules and their connections Design that covers the main use-cases of the system addresses the main non-functional requirements (e.g., throughput, reliability) hard to change Detailed design (also: low-level design) the inner structure of the main modules may take the target programming language into account detailed enough to be implemented in the programming language Analogy: Architecture of Buildings We all live in them (We think) We know how they are built Requirements Design (blueprints) Construction Use
This is similar (though not identical) to how we build software.
Architectures in Context Fundamental Understanding Architecture is a set of principal design decisions about a software system Three fundamental understandings of software architecture, the recognition of which helps situate architecture with respect to the software engineering: Every application has an architecture
Every application has at least one architect Architecture is not a phase of development
Wrong View: Architecture as a Phase Treating architecture as a phase denies its foundational role in software development More than high-level design Architecture is also represented, e.g., by object code, source code,
Architecture-Centric Design Traditional design phase suggests translating the requirements into algorithms, so a programmer can implement them Architecture-centric design stakeholder issues decision about use of COTS component overarching style and structure package and primary class structure deployment issues post implementation/deployment issues
Context of Software Architecture Requirements Design Implementation Analysis and Testing Evolution Development Process
The fig shows how all context fits together (Frameworks and the implementation activity in the context of development. Activities are shown in left column; artifacts are in the central column; notes are on the right.)
Chapter 1: Basic Concepts

Terminology The major constituent elements of architectures are, including components, connectors and configuration. Two important types of potentially deep architectural knowledge-architectural patterns and styles are then defined and examined. Architecture Definition: A software systems architecture is the set of principal design decisions made about the system. Put another way, software architecture is the blueprint for a software systems construction and evolution. The notion of design decision is central to software architecture and to all of the concepts based on it. For example, Some architecture are anchored on the idea of the reference architecture, defined as follows. Definition: Reference architecture is the set of principal design decisions that are simultaneously applicable to multiple related systems, typically within an application domain, with explicitly defined points of variation. Design decisions encompass every aspect of the system under development, including: Design decision related to system Structure-for example, The architectural elements should be organized and composed exactly like this Design decision related to functional Behavior-for example, Data processing, storage, and visualization will be performed in strict sequence. Design decision related to system Interaction-for example, Communication among all system elements will occur only using event notifications. Design decision related to systems Non-functional properties-for example, The systems dependability will be ensured by replicated processing modules. Design decision related to systems implementation-for example, the user interface components will be built using the Java Swing toolkit.
What is Principal? Principal implies a degree of importance that grants a design decision architectural status It implies that not all design decisions are architectural
That is, they do not necessarily impact a systems architecture
How one defines principal will depend on what the stakeholders define as the system goals
Other Definitions of Software Architecture Perry and Wolf Software Architecture = { Elements, Form, Rationale } what how why Shaw and Garlan Software architecture [is a level of design that] involves Kruchten Software architecture deals with the design and implementation of the highlevel structure of software. Architecture deals with abstraction, decomposition, composition, style, and aesthetics. A software architecture is defined as follows: Software architecture- A model that describes the structure of a software system in terms of computational components, the relationships among components, and the constraints for assembling the components. That is, a software architecture can be defined in terms of the following elements: software architecture = {components, relationships, constraints} These elements are defined as follows: Components- Components are the computational elements which collectively constitute architecture. Software architecture is typically decomposed into subsystems, which in turn may be decomposed into modules. Further decomposition is also possible. (For example in an object-oriented design, modules may be decomposed into classes.) Examples of components include clients, services, and persistent stores. Relationships- Relationships are the logical connections between architectural components. Examples of abstract component relationships include dependency, the description of elements from which systems are built, interactions among those elements, patterns that guide their composition, and Constraints on these patterns.
aggregation, and composition. Examples of concrete component relationships include client-server protocols and database protocols. Constraints- Constraints provide conditions and restrictions for component relationships. They connect the architecture to system requirements. Examples of constraints include restrictions on parameters types for communication protocols and high availability requirements for fault tolerance. The architecture components and their interrelationships define the architectural structure.
Software Architectures Elements A software systems architecture typically is not (and should not be) a uniform monolith A software systems architecture should be a composition and interplay of different elements Processing Data, also referred as information or state Interaction
Software architectures have 3 types of elements Components Connectors Configuration
Components: Elements that encapsulate processing and data in a systems architecture are referred to as software components Definition A software component is an architectural entity that encapsulates a subset of the systems 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.
Put another way, a software component is a locus of computation and state in a system.
A component can be as simple as a single operation or as complex as an entire system, depending on the architecture, the perspective taken by the designers, and the need of the given system. The key aspect of any component is that it can be seen by its users, whether human or software, from the outside only, and via the interface it has chosen to make public. Software components are thus embodiments of the software engineering principles of encapsulation, abstraction, and modularity. In turn, this has a number of positive implications on a components composability, reusability, and evolvability. Components are often targeted at be the processing and data capture needs of a particular application; that is, they are said to be application-specific. Sometimes components are designed to address the needs of multiple applications or problem domain. For example, web servers are an integral part of any Web-based system; one will probably download, install, and configure an existing Web server rather than develop ones own. Finally, certain software components are utilities that are needed and can be reused across numerous applications, without regard for the specific application characteristics or domain. Common examples of reusable utility components are math libraries and GUI toolkits, such as Javas Swing toolkit.
Connector: Another fundamentals aspect of software systems is interaction among the systems building blocks. Software connectors are the architectural abstraction tasked with managing component interaction. Definition A software connector is an architectural element tasked with effecting and regulating interaction among components.
In traditional desktop software system, connectors usually have manifest themselves as simple procedure calla or shared data access. Simple connectors are usually restricted to enabling the interaction of pairs of components. However, as software system has become more complex, so have connectors, with their own separate identities, roles, and bodies of implantation-level code, as well as ability to simultaneously service many different components. Connectors typically provide application-independent interaction facilities.
Examples: Procedure call connectors Shared memory connectors Message passing connectors Streaming connectors Distribution connectors Wrapper/adaptor connectors
Configuration: Components and connectors are composed in a specific way in a given systems architecture to accomplish that systems objective. That composition represents the systems configuration, also referred as topology Definition An architectural configuration, or topology, is a set of specific associations between the components and connectors of a software systems architecture
A configuration may be represented as a graph wherein nodes represent components and connectors, and whose edges represent their associations.
Architectural Styles Definition An Architectural Style is a named collection of architectural design decisions that (1) are applicable in a given development context, (2) constrain architectural design decisions that are specific to a particular system within that context, and (3) elicit beneficial qualities in each resulting system.
Architectural styles classify architecture in terms of the use of form, techniques, materials, time period, region and other stylistic influences. It overlaps with, and emerges from the study of the evolution and history of architecture. In architectural history, the study of Gothic architecture, for instance, would include all aspects of the cultural context that went into the design and construction of these structures.
Hence, architectural style is a way of classifying architecture that gives emphasis to characteristic features of design, leading to a terminology such as Gothic "style".
Architectural Pattern Definition An Architectural Pattern is a named collection of architectural design decisions that are applicable to a recurring design problem parameterized to account for different software development contexts in which that problem appears.
Architectural styles provide general design decisions that both constrain and may need to be refined into additional, usually more specific design decisions in order to be applied to a system. In contrast, an architectural pattern provides a set of specific design decisions that have been identified as effective for organizing certain classes of software systems or, more typically, specific subsystems. A "pattern" has been defined as: "an idea that has been useful in one practical context and will probably be useful in others" [Analysis Patterns - Reusable Object Models].
Whats the difference between an architectural style, an architectural pattern, and a system metaphor? An architectural style is a central, organizing concept for a system. An architectural pattern describes a coarse-grained solution at the level of subsystems or modules and their relationships. A system metaphor is more conceptual and it relates more to a real-world concept over a software engineering concept.
Models A software systems architecture is captured in an architectural model using a particular modeling notation. Definition An architectural model is an artifact that captures some or all of the design decisions that comprise a systems architecture. Architectural modeling is the reification and documentation of those design decisions.
Architectural models are used as the foundation for most other activities in architecture-based software development processes, such as analysis, system implementation, deployment, and adaptation.
Processes Software architecture is not software engineering life cycle phase that follows requirements elicitation and precedes low-level design and system implementation. In that sense, software architecture helps to anchor the processes associated with different development activities, as follows, Stakeholders Architects: The software architect role is responsible for the software architecture, which includes the key technical decisions that constrain the overall design and implementation for the project. Developers: A software developer is a person or organization concerned with facets of the software development process. Testers: If releasing a relatively bug-free product is important then having a team of software testers is key. Managers: A Project Manager is responsible for managing the resources of large projects. The Project Manager is responsible for making sure a project is completed within a certain set of restraints. These restraints usually involve time, money, people and materials. The project must then be completed to a certain level of quality. Customers: who sometime buy software from developer and sell it in market to make profit. Users: end users who actually use the software. Architectural design Architecture modeling and visualization Architecture-driven system analysis Architecture-driven system implementation Architecture-driven system deployment, runtime redeployment, and mobility Architecture-based design for non-functional properties, including security and trust architectural adaptation
2. Conventional Architectural styles

Terminology
Software architectures often use idiomatic patterns of system organization. Patterns and styles of design are pervasive in many engineering disciplines and an established understanding of the common forms of design is an indication of a mature engineering field. The shared vocabulary of design idioms and rules for using them are stored in engineering handbooks and in professional curricula. A common framework can be developed to compare different architectures. It consists of computational components (components and interactions between these components connectors. Examples of components are clients, servers, filters, layers and databases. Examples of connectors are procedure call, events broadcast, database protocols, and pipes. A topological layout of these components indicating their runtime interrelationship.
A Partial List of Common Architecture Styles

Dataflow Systems -- Batch sequential, Pipes and filters. Call-and-return systems -- Main program and subroutines, OO systems, Hierarchical layers. Independent components -- Communicating processes, Event Systems. Virtual Machines -- Interpreters, Rule-based systems. Data-centered systems (repositories) -- Databases, Hypertext system, Blackboards.
Pipes and Filters

Each component has a set of inputs and outputs. A component reads a stream of data on its input and produces a stream of data on its outputs. Input is transformed both locally and incrementally so that output begins before input is consumed (a parallel system). Components are called filters. Connectors serve as conduits for the information streams and are termed pipes.
Invariant traits include the condition that filters must be independent entities, and they must not know the identity of upstream or downstream filters. They may specify input format and guarantee what appears on output, but they may not know which components appear at the ends of those pipes. Common specializations include pipelines which restrict topologies to linear sequences of filters, and bounded pipes which restrict the amount of data in pipes at one time. A degenerate version occurs when each filter processes all of its input as a single entity. This is a batch sequential system. In these systems pipes no longer provide a stream of data. The best-known example of pipe-and-filter architectures are UNIX shell programs. Components are represented as UNIX processes and pipes are created through the file system. UNIX Shell: cat input.txt | grep text | sort > output.txt
Other examples include compilers (The consecutive filters perform lexical analysis, parsing, semantic analysis, and code generation.), signal-processing systems, parallel programming, functional programming, and distributed systems.
Advantages to pipe-and-filter systems include:

easy understanding of the system's behavior as the composition of filters they support reuse easy to maintain and enhance they support specialized analysis (throughput deadlock analysis) and they support concurrent execution
Disadvantages to pipe-and-filter systems include:

they often lead to batch organization of processing poor for interactive applications can be difficult to maintain synchronization between two related but separate streams May force lowest common denominator on data transmission, resulting in added work for each filter to parse input and format output data which can, in turn, affect performance and increase complexity of the filters.
Event-Based, Implicit Invocation Instead of invoking a procedure directly, a component announces (broadcasts) one or more events. Other components in the system can register interest in an event by associating a procedure with it. The system invokes all events which have registered with it.
Event announcement ``implicitly'' causes the invocation of procedures in other models. This style originates in constraint satisfaction, daemons, and packet-switched networks. Architectural components are modules whose interface provides both a collection of procedures and a set of events. Procedures may be called normally or be registered with events in the system. Implicit invocation systems are used in: programming environments to integrate tools database management systems to ensure consistency constraints user interfaces to separate data from representation For example, tools such as editors and variable monitors register for a debuggers breakpoint events. When a debugger stops at a breakpoint, it announces an event that allows the system to automatically invoke methods in those registered tools. These methods might scroll an editor to the appropriate source line or redisplay the value of monitored variables. In this scheme, the debugger simply announces an event, but does not know what other tools (if any) are concerned with that event, or what they will do when that event is announced.
Advantages of Implicit invocation to systems include:

Implicit invocation facilitates reuse by allowing any component to register for events, And eases system evolution by allowing components to be replaced without affecting the interfaces of other components in the system.
Disadvantages of Implicit invocation to systems include:
The primary disadvantage to implicit invocation is that the components relinquish control over the computation performed by the system. A component cannot assume that other components will respond to its requests and does not know what order events will be processed.
In systems with a shared repository of data the performance and accuracy of the resource manager can become critical. Reasoning about correctness can be difficult because the meaning of a procedure that announces events will depend on the context in which it was invoked.
Layered Systems A layered system is organized hierarchically with each layer providing service to the layer above it and serving as a client to the layer below. In some systems inner layers are hidden from all except the adjacent outer layer. Connectors are defined by the protocols that determine how layers will interact. Constraints include limiting interactions to adjacent layers. The best known example of this style appears in layered communication protocols OSI-ISO (Open Systems Interconnection - International Standards Organization) communication system. Lower levels describe hardware connections and higher levels describe application. Eg. UNIX OS
Advantages of Layered system include: Layered systems support designs based on increasing levels of abstraction. Complex problems may be partitioned into a series of steps. Enhancement is supported through limiting the number of other layers with which communication occurs.
Disadvantages of Layered system include: Disadvantages include the difficulty in structuring some systems in a layered fashion.
Performance considerations may not be well served by layered systems especially when high level functions require close coupling to low level implementations. It may be difficult to find the right level of abstraction especially if existing systems cross several layers.
Repositories: In a repository style there are two quite distinct kinds of components: A central data structure represents the current state, and a collection of independent components operate on the central data store. Interactions between the repository and its external components can vary significantly between systems. The choice of control discipline leads to major subcategories. If the types of transactions in an input stream of transactions trigger selection of processes to execute, the repository can be a traditional database. If the current state of the central data structure is the main trigger of selecting processes to execute, the repository can be a blackboard. In Repository architecture the data is passive. Blackboard architecture has quasi-active data, which informs the clients interested in changes. The Blackboard architecture style is similar to the Observer design pattern (Gamma et al., 1995). Advantages of Repositories include: Clients are independent from each other. Thus, a client can be changed, without affecting the others. Also further clients can be added. This advantage pales if the architecture is changed in such a way that clients are coupled closely (thus deviating from the recommended architecture style), for example in order to improve the performance of the system. Eg.
Interpreters Interpreters create a virtual machine in software. There are generally four components to an interpreter; these are the program being interpreted, the state of the program, the state of the interpreter, and the interpreter itself.
They are commonly used to narrow the gap between the computing engine in hardware and the semantics of a program. Programming languages can be thought of as providing a virtual language machine. Examples include Pascal, Java, and BASIC.
Process Control This architecture style is based on control loops. This system organization is not widely recognized in the software community. Unlike object-oriented or functional designs, which are characterized by the kinds of components that appear, control-loop designs are characterized both by the kinds of components involved and the special relations that must hold among them. Process-Control paradigms Continuous processes of many kinds convert input materials to products with specific properties by performing operations on the inputs and on intermediate products. Some useful definitions: Process variable: properties of the process that can be measured; several specific kinds are often distinguished. Controlled Variable: Process variable whose value the system is intended to control. Input variable: process variable that measures an input to the process. Manipulated variable: Process variable whose value can be changed by the controller. Set point: the desired value for a controlled variable. Open-loop system: System in which information about process variables is not used to adjust the system. Closed-loop system: System in which information about process variables is used to manipulate a process variable to compensate for variations in process variables and operating conditions.
Ch.3 Designing Architectures

3.1 Terminology: The chapter focus on question that how architectures are created. In analogy of building architectures, is not fully adequate basis for creating a fifty-story building that successfully houses business, provides the base for a television broadcast tower, and which effectively integrates with a citys electrical ,water ,data, and wastewater infrastructures. The small matter of design stands between raw materials and tools and realization of the vision. The design of a skyscraper is the product of a cadre of architects and engineers who labor to meet all the goals for the building while simultaneously satisfying all the constraints placed upon it, and upon them. The outcome of such study is a set of approaches and techniques for designing that can be described, taught, applied, evaluated, and refined. Examination of existing design helps identify good strategies for tackling various kinds of problem and helps develop a sense for associated costs and qualities. 3.2The Design Process The goal of this chapter is to set forth a variety of approaches for helping the student learn how to design software system. The typical assumption of software design is that the process can proceed in the general manner of architectural design or engineering design, which can be summarized as consisting of the following four stages. 1. Feasibity stage: Identifying a set feasible concept. 2. Preliminary design stage: Selection and development of the best concept. 3. Detailed design stage: development of engineering descriptions of the concept. 4. Planning stage: evaluating and altering the concept to suit the requirements of production, distribution, consumption and product retirement. Designing begins (stage 1) by the taking in of information. From this a set of alternative arrangements for the design as a whole is quickly derived. Stage 2 is to select one of these alternatives for further development. When this design has reached the point of satisfying the chief designer the work is split up for detailed design many people working in parallel(stage 3 and 4). The viewpoint represented by this process so pervades the software development world that it is hard to realize that the use of this process represents a choice-that, indeed, other approaches are possible. This is an important recognition because the standard approach does not always work. Even in those situations where it does work, it may not yield the best result. At a minimum, designers must be aware of some of the conditions under which the traditional approach is likely to be insufficient.
Software Architecture Conditions under which this process may not work:
If the designer is unable to produce a set of feasible concepts, progress stops. As problems and products increase in size and complexity, the probability that any one individual can successfully perform the first steps decreases. The standard approach does not directly address the situation where system design is at stake, i.e. when relationship between a set of products is at issue. As complexity increases or the experience of the designer is not sufficient, alternative approaches to the design process must be adopted.
Alternative Design Strategies Standard o Cyclic o Parallel o Independent alternatives are explored in parallel Process can revert to an earlier stage Linear model described above
Adaptive (lay tracks as you go) o The next design strategy of the design activity is decided at the end of a given stage
Incremental o Each stage of development is treated as a task of incrementally improving the existing design
3.3 Architectural conception The standard approach to architectural and engineering design says that the first major step consists of identifying a feasible set of alternative arrangements for the design as a whole, choosing one of those arrangements, and then proceeding to refine and elaborate it. Way to identify set of viable arrangements-or even one viable arrangement. 1)Apply the fundamental design tools of software engineering: abstraction and modularity. 2) Inspiration Creative inspiration is needed; to be sure, it is not a reliable magic wand to be blithely waved over complex design challenge. A more effective strategy is to minimize and isolate those parts of a design for which creative inspiration is required, and to apply more prosaic and predictable techniques elsewhere.
Notes compiled by Prof. Suresh Mestry Mobile No:8097404245 3) A common, effective, and appropriate answer to the question of how to identify a feasible set of alternative arrangement for the design as a whole is applying experience. 3.3.1Fundamental Conceptual Tools The most basic design tools are separation of concerns, abstraction, modularity, and other first principles of software engineering such as anticipation of change and design for generality. Abstraction and the Simple Machines What concepts should be chosen at the outset of a design task? One technique: Search for a simple machine that serves as an abstraction of a potential system that will perform the required task For instance, what kind of simple machine makes a software system embedded in a fax machine? At core, it is basically just a little state machine.
Simple machines provide a plausible first conception of how an application might be built. Every application domain has its common simple machines.
Simple Machines: Domain Graphics Simple Machines Pixel arrays Transformation matrices Widgets Abstract depiction graphs Structured documents Layouts Finite state machines Hypertext Spreadsheets Form templates Hypertext Composite documents Matrices Mathematical functions Spreadsheets Databases Transactions
Word processing Process control Income Tax Software
Web pages Scientific computing Banking
Software Architecture Choosing the Level and Terms of Discourse
Any attempt to use abstraction as a tool must choose a level of discourse, and once that is chosen, must choose the terms of discourse. Alternative 1: initial level of discourse is one of the applications as a whole (step-wise refinement). Alternative 2: work, initially, at a level lower than that of the whole application. Once several such sub-problems are solved they can be composed together to form an overall solution
Alternative 3: work, initially, at a level above that of the desired application. E.g. handling simple application input with a general parser.
Separation of Concerns Separation of concerns is the subdivision of a problem into (hopefully) independent parts. The difficulties arise when the issues are either actually or apparently intertwined. Separations of concerns frequently involves many tradeoffs Total independence of concepts may not be possible. Key example from software architecture: separation of components (computation) from connectors (communication)
3.3.2 The Grand Tool: Refined Experience Experience must be reflected upon and refined. Experience can be a masterful teacher, however, and can provide the guidance necessary to wield the basic tools in an effective fashion. Raw experience by itself,though,does not provide the mature guidance The lessons from prior work include not only the lessons of successes, but also the lessons arising from failure. Learn from success and failure of other engineers Literature Conferences
Experience can provide that initial feasible set of alternative arrangements for the design as a whole. Similarly, communication between development team members is enhanced: when others have experience with the same or similar preexisting systems, it is easier to describe use of or modifications to an established approach, as compared to conveying a completely new concept. Limitation: Innovation is certainly inhibited by mindlessly following ones standard approach.
Software Architecture 3.4 Refined Experience in action: Styles and architectural patterns
The distilled architectural wisdom that has arisen from a vast body experience comes in many shapes and flavors. Styles are designed to capture knowledge of effective design for achieving specified goals within a particular application context. Patterns and styles can be characterized for large problem as well as small.
Following figure for a summary of the main types architectural styles and patterns. (Domain knowledge versus scope in showing the relationship between styles and pattern).
The horizontal axis of above figure refers to the scop of applicability of the body of knowledge-the domain of discourse. For instance,design pattern are focused on the programmingof object-oriented solutions to program design problems. Such patterns are inapplicable to enterprise-level system design,which is other end of thye horizontal axis. The vertical axis reflects the amount of domain knowledge represented by the body of knowledge. Program design patterns are shown at the shallow end of this scale,reflecting that they are very generally applicable and are not restricted to use within a particular application domain.
Software Architecture At the other end of the scale are domain-specific software architecture.
Such styles are applicable to the design of very large applications and concomitantly encode substantial knowledge about the design of applications within a domain. The diagram has fuzzy boundaries, however, and should only be taken as a rough guide. Programming languages exist at many levels of abstraction;applications range from very simple to extraordinary complex.
3.4.1 Domain-specific software architectures A DSSA is an assemblage (or combination)of software components o o o A referance architecture for an application domain, and A library of software components for that architecture containing reusable chunks of domain expertise, A method of choosing and configuration components to work within an instance of the referamce architecture.
Since DSSAs are specialized for a particular 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. The difficultywith DSSAs is that they are specialised for a particular domain and so are only of value if one exists for the domain wherein the engineer is charged with building a new application.
3.4.2 Architectural Patterns An architectural pattern is a 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. Architectural patterns are similar to DSSAs but applied at a lower level and within a much narrower scope. Definition: An Architectural Pattern is a named collection of architectural design decisions that are applicable to a recurring design problem parameterized to account for different software development contexts in which that problem appears. In this sections below,we sketch three very simple examples:State-logic-display,model-view-controller,and sense-compute-control.
State-Logic-Display(aka. Three-Tier) This example is commonly employed in business applications where there is a data store behind a set of business logic rules, and that business logic is accessed by user interfacecomponents.This pattern,also known as
Notes compiled by Prof. Suresh Mestry Mobile No:8097404245 state-logic-display,has been popular since itmaps nicely to a distributed implemented in which communication between the components is by remot procedure call. Example: Business applications Multi-player games Web-based applications
Model-View-Controller(for Graphical User Interfaces) Objective: Separation between information(M), presentation(V) and user interaction(C). This pattern has been a dominent influencein the design of graphical user interfaces. When a model object value changes, a notification is sent to the view and to the controller. Thus, 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.
The simple idea shown in figure, The model component encapsulates the information used by the application; the view component encapsulates the information chosen and necessary for graphical depiction of the information; the controller component encapsulates the logic neccesary to maintain consistency between the model and the view,and to handle inputs from the user as they relate to tha depiction.
Software Architecture Sense-Compute-Control(aka. Sensor-Controller-Actuator)
The sense-compute-control (SCC) pattern is typically used in structuring embedded control applications. This may range from simple device such as those found in kitchen appliances to sophisticated syatem used in automotive applications or robotis control. The basic idea is illustrated in figure, A computer is embedded in some application; sensors from various devisec are connected to the computer and may be simpled to determine their value. Also attached to the computer are hardware actuators. By sending a signal to such devices the computer may,for example,open a vlue.lower flaps,or turn off a light, and hence control the system.
3.4.3 Introduction to Styles An architectural style is a named collection of architectural design decisions 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 Many styles exist and we will discuss them in detail in the next lecture
Definitions of Architectural Style Definition. An architectural style is a named collection of architectural design decisions that
Software Architecture 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.
Recurring organizational patterns & idioms Established, shared understanding of common design forms Mark of mature engineering field. Shaw & Garlan
Abstraction of recurring composition & interaction characteristics in a set of architectures Medvidovic & Taylor
Basic Properties of Styles A vocabulary of 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 Possible analyses of systems built in a style
Benefits of Using Styles Design reuse o Well-understood solutions applied to new problems
Code reuse o Shared implementations of invariant aspects of a style
Understandability of system organization o A phrase such as client-server conveys a lot of information
Software Architecture Interoperability o Supported by style standardization
Style-specific analyses o Enabled by the constrained design space
Visualizations o Style-specific depictions matching engineers mental models
Some Common Styles Traditional, language-influenced styles o o Layered o o Virtual machines Client-server Main program and subroutines Object-oriented
Data-flow styles o o Batch sequential Pipe and filter
Shared memory o o Blackboard Rule based
Interpreter o o Interpreter Mobile code
Implicit invocation o o Event-based Publish-subscribe
Peer-to-peer
Software Architecture Derived styles o o C2 CORBA
Traditional Language-Influenced Styles

The two styles considered here reflect the program styles that result from the traditional use of programming lamguages such C,C++,Java,and Pascal. Main program and Subroutines. The main program and subroutine style should be instantly familiar to anyone who has programmed in a language such C,Fortran,Pascal, or Basic. The components are the main program and the various subroutines(procedures);the connectors between the components are procedure calls.
Main program
Procedure Call Call
Procedure Call
Procedure Call
Subroutines Object-Oriented
Subroutines
Subroutines
Components are objects o Data and associated operations Connectors are messages and method invocations Style invariants o Objects are responsible for their internal representation integrity o Internal representation is hidden from other objects Advantages o Malleable object internals o System decomposition into sets of interacting agents Disadvantages o Objects must know identities of servers
o Side effects in object method invocations Layered

Layered styles are as simple and familiar as those above that reflect the traditional use of programming languages such C or Java. The essence of a layered style is that architecture is separated into ordered layers, wherein a program within one layer may obtain services from a layer below it.
Virtual Machines Refer Interpreter in ch.2 Client-server
The client-server style can be simply understood as a two-layer virtual machine with network connections. That is, the server (component) is a virtual machine below the clients, each of which accesses the virtual machines interfaces via remote procedure calls or equivalent network access methods (connector). Typically, there are multiple clients that access the same server; the clients are mutually independent. Dataflow Styles The two styles presented here can be characterized as dataflow styles. Their essence concerns the movement of data between independent processing elements. Batch-sequential The batch-sequential style is one of the oldest in the design of computer system. It arose in the early days of data processing when the limitations of computing equipment required that large problems be subdivided into severable components that could communicate by the transfer of magnetic tapes. Pipe-and-Filter Refer ch.2 Shared State (Shared memory styles) The essence of shared state styles is that multiple components have access to the same data store, and communicate through that data store. Blackboard Two kinds of components Central data structure blackboard Components operating on the blackboard System control is entirely driven by the blackboard state Examples Speech recognition Planner component for RADRSAT-1 satellite
Rule-based/Expert System A rule-based architecture is a highly specialized type of shared memory architecture. The shared memory is a so-called knowledge base, that is, a database that contain facts and production rules which consist of ifthen clauses over the set of variables. Inference engine parses user input and determines whether it is a fact/rule or a query If a fact/rule, add this entry to the knowledge base Rules often take if (condition) then {action} form Otherwise, query the knowledge base for applicable rules and attempt to resolve the query. Components: User interface, inference engine, knowledge base Connectors: Components are tightly interconnected, with direct procedure calls and/or shared memory Data Elements: Facts and queries Pro: can easily modify system behavior through addition or deletion of rules Con: as number of rules grows understanding overall system behavior becomes very difficult
Interpreter The basic interpreter architectural style involves the execution of commands one at a time. Similarly, though typically at a large granularity, the mobile code style involves the execution of one chunk of code at a time. The difference with mobile code is that the place where the commands are executed may vary over time. Basic Interpreter Interpreter parses and executes input commands, updating the state maintained by the interpreter Components: Command interpreter, program/ interpreter state, user interface Connectors: Typically very closely bound with direct procedure calls and shared state Highly dynamic behavior possible, where the set of commands is dynamically modified. Good for end-user programming; supports dynamically changing set of capabilities System architecture remains constant while new capabilities can be added Examples: Microsoft Excel, Postscript. Mobile Code Mobile code styles enable code to be transmitted to a remote host for interpretation. Mobile code may be classified as code on demand, remote evaluation, or mobile agent depending on where the code is being transmitted, who requested the transmission, and where the program state resides. Data elements become processing comps 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.
Implicit Invocation The two styles below are characterized by calls that are invoked indirectly and implicitly as a response to a notification or an event. Publish-Subscribe Subscribers register/deregister to receive specific messages or specific content. Publishers broadcast messages to subscribers either synchronously or asynchronously. Components: Publishers, subscribers, proxies Connectors: Network protocols. Content-based subscription requires sophisticated connectors. Data Elements: Subscriptions, notifications, published information Topology: Subscribers connect to publishers or receive notifications from intermediaries. Event-Based Style Independent components asyn. emit and receive events over event buses 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. Variants: Component communication with the event bus may either be push or pull based. Highly scalable, easy to evolve, effective for highly distributed applications. Peer-to-Peer style State and behavior are distributed among peers which can act as either clients or servers. Peers: independent components, having their own state and control thread. Connectors: Network protocols, often custom. Data Elements: Network messages Topology: Network (may have redundant connections between peers); can vary arbitrarily and dynamically Supports decentralized computing with flow of control and resources distributed among peers Highly robust to node failure Scalable in terms of resources and comp. power Resource discovery is key concern Security detecting/handling malicious peers.
Chapter 4: Connectors
Introduction Designing and implementing the functionality and managing the data of modern large, complex, distributed, multilingual software systems is undoubtedly very difficult. The particular importance in modern systems of mechanisms for assembling functional components and supporting their interaction, that is, software connectors, mandates that they be treated and studied separately. Software connectors perform transfer of control and data among components. Connectors can also provide services, such as persistence, invocation, messaging, and transactions, that are largely independent of the interacting components functionalities. What is a Software Connector? Architectural element that models o Interactions among components o Rules that govern those interactions Simple interactions o Procedure calls o Shared variable access Complex & semantically rich interactions o Client-server protocols o Database access protocols o Asynchronous event multicast Each connector provides o Interaction duct(s) o Transfer of control and/or data Where are Connectors in Software Systems?
Reasons for Treating Connectors Independently Connector Component o Components provide application-specific functionality o Connectors provide application-independent interaction mechanisms Interaction abstraction and/or parameterization Specification of complex interactions o Binary vs. N-ary o Asymmetric vs. Symmetric o Interaction protocols Localization of interaction definition Extra-component system (interaction) information Component independence. Component interaction flexibility. Benefits of First-Class Connectors Separate computation from interaction Minimize component interdependencies Support software evolution o At component-, connector-, & system-level Potential for supporting dynamism Facilitate heterogeneity Become points of distribution Aid system analysis & testing Connector Foundation The underlying, elementary building blocks of every connector are the primitives for managing the flow of control (that is, changing the processor program counter) and flow of data (that is, performing memory access) in a system. These primitives give enough conceptual power to build sophisticated and complex connectors. In addition to these primitives, every connector maintains one or more channels, also referred to as ducts, which are used to link the interacting components and support the flow of data and control between them. Simple connectors, such as module linkers, provide their service simply by forming duct between components. Very complex connectors can also have an internal architecture that includes computation and information storage. For example, a load balancing connector would execute an algorithm for switching incoming traffic among a set of components based on the knowledge about the current and past load state of components.
Connector Roles A software connector can provide one or more of four general classes of services: communication, coordination, conversion, and facilitation. Communication Connectors providing communication services support transmission of data among components. Data transfer services are a primary building block of component interaction. Components routinely pass messages, exchange data to be processed, and communicate results of computations. Coordination Connectors providing coordination services support transfer of control among components. Components interact by passing the thread of execution to each other. Function calls and method invocations are examples of coordination connectors. Higher-order connectors, such as signals and load balancing connectors provide richer, more complex interaction built and coordination services. Conversion Connectors providing conversion services transform the interaction required by one component to that provided by another. Enabling heterogonous components to interact with each other is not a trivial task. Conversion services allow components that have not been specifically tailored for each other to establish and conduct interaction. Facilitation Improve interaction of components that were intended to interoperate Usually optimizes or streamlines interactions Ensure proper performance profiles Load balancing or scheduling Synchronization mechanisms Monitors (enforce mutex access to resources)
Connector types and their variation dimensions

Procedure call Event Data access Linkage Stream Arbitrator Adaptor Distributor
Procedure Call Procedure call connectors model the flow of control among components through various invocation techniques. They are thus coordination connectors. Additionally, procedure calls perform transfer of data among the interacting components through the use of parameters and return values. They are thus also communication connectors. Examples of procedure call connectors include object-oriented methods, fork and exec in Unix-like environments, call-back invocation in event-based system, and operating system call. Procedure calls are frequently used as the basis for composite connectors, such as remote procedure call or RPC which also perform facilitation service.
Event An event as the instantaneous effect of the termination of the invocation of an operation on an object, which occurs at that objects location. Event connectors are similar to procedure call connectors in that they affect the flow of control among components, and thus provide coordination services.in this case, the flow is precipitated by an event. Once the event connector learn about the occurrence of an event, it generates messages for all interested parties and yields control to the components for processing those messages. The contents of an event can be structured to contain more information about the event, such as the time and place of occurrence, and other application-specific data. Events connectors therefore also provide communication service. An example is a windowing application, where GUI inputs serve as the events that activate the system. Finally, some events, such as interrupts, page faults, and traps, are triggered by hardware and then processed by software.
Data Access Connectors Data access connectors allow components to access maintained by a data store component. Therefore they provide communication services. In case there is a difference in the format of the required data and format in which data is stored and provided, data access connectors may perform translation of the information being accecced, that is conversion. The data can be stored either persistently data access include query mechanism, such as SQL for database access, example of transient data access include heap and stack memory access and information caching. Eg.JDBC
Linkage Connectors Linkage connectors are used to tie the system components together and hold them in such a state during their operation. Linkage connectors enable the establishment of ducts- the channels for communication and coordination-that are then used by higher-order connectors to enforce interaction semantics. In other words, linkage connectors provide facilitation service. Once ducts are established, a linkage connector may disappear from the system or remain in place to assist in the systems evolution.
Stream connectors Streams are used to perform transfer of large amounts of data between autonomous processes. Thus they provide communication services in a system. Streams are also used in client-server system with data transfer protocol to deliver results of computation. Stream can be combined with other connector types such as data access connectors, to provide composite connectors for performing database and file storage access, and event connectors, to multiplex the delivery of a large number of events. Examples include UNIX pipes, TCP/UDP communication sockets, and proprietary client-server protocols.
Arbitrator Connectors When components are aware of the presence of other components but cannot make assumptions about their needs and state, arbitrators streamline system operation and resolve any conflicts (thereby providing facilitation services), and redirect the flow of control (providing coordination services). For example, multithreaded systems that require shared memory access use synchronization and concurrency control to guarantee consistency and atomicity of operations. Arbitrators can also provide facilities to negotiate service levels and mediate interaction requiring guarantees for reliability and atomicity. They also provide scheduling and load balancing services.
Adaptor Connectors Adaptor connectors provide facilities to support interaction between components that have not been designed to interoperate. Adaptors involve matching communication policies and interaction protocols among components, thereby providing conversion services. These are necessary for interoperation of components in heterogeneous environments, such as different programming languages or computing platforms.
Distributer Connectors Distributer connectors perform the identification of interaction paths and subsequent routing of communication and coordination information among components along these paths. Therefore, they provide facilitation services. Distributor connectors never exist by themselves, but provide assistance to other connectors, such as streams or procedure calls. Distributed system exchange information using distributer connectors to direct the data flow. Example, Domain Name Service (DNS), routing, switching, and many other network services belong to this connector type.
Example Connectors
In this section, we illustrate the connector classification discussed above with four composite distribution connectors that are in wide use today: event-based, grid-based, client-server-based, and peer-to-peer-based (or p2p-based) connectors. These connectors distribute large amounts of content over a wide area network, such as the Internet. Several implementations of these connectors are in wide use by a number of research, industry, and government projects, as well as a large number of individuals around the world. Distribution connectors can be described as different combinations of six of the connector types defined in the classification. The exact combinations of the six types dimensions varies across the different distribution connectors, but in general, each distribution connector performs some form of data access ,involving a stream-based reading(and packaging) of data, and distribution of the data to end users. Some connectors classes are invoked via procedure call (for example, client-based), or arbitration (for example, P2P-based).
Event-Based Data Distribution Connectors Event-based utilizes 4 of the 6 connectors: o Event o Data access o Stream o Distributor These connectors send and receive data via asynchronous notification called events An example is a middle ware that performs publish-subscribe architectural style and involves some producer of information alerting subscribers ---events, which then kicks- off the accessing of various data. The accessed data is then packaged and streamlined for distribution by the distributor to the subscribers. Grid-based Distribution Connector Grid-based utilizes 4 of the 6 connectors: o Procedure call o Data access
o Stream o Distributor These connectors move and deliver large amounts of data among software components arranged in a network (grid) of shared computing and data resources. This middle-ware is invoked via a named, synchronous procedure call. User authentication and security functionalities are provided, data-provider & functionality source and destinations are provided, parameters are passed by values with keyword equals value, actual data is packaged and streamlined, etc. in the grid-network with location & directory services to help distribution.
Client Server-based Distribution Connector Client server-based utilizes the same 4 connectors as Grid : o Procedure call o Data access o Stream o Distributor These connectors allow seamless distribution of data between client and server system using Remote Procedure Call (RPC). This middle-ware is very much like the grid-based distribution connector, except the customer of service and the provider of service operates in a much more seamless manner (as if the service and data are local). Peer-to-Peer-based Distribution Connector P2P-based utilizes the 4 connectors : o Arbitrator o Data access o Stream o Distributor These connectors differ from the previous 3 in that it is invoked via arbitration, which involves control flow redirection among distributed, peer resources. Arbitrators can negotiate various issues such as timing, scheduling, or protocols. Once a peer is invoked via arbitration then the collection of data may also be through the peers in a distributed environment (also via arbitration). Data is then organized and package in chunks for transmission to other peers. Other peers are located via arbitration and the data is distributed to them.
Chapter 5: Modeling
Introduction Every software system has architecture, whether it is a good architecture or not. Recall that we have characterized architecture as the set of principal design decisions made about a system. Once design decisions have been made, they can be recorded. Design decisions are captured in models; the process of creating models is called modeling.
Definitions: An architectural model is an artifact that captures some or all of the design decisions that comprise a systems architecture Architectural modeling is the reification and documentation of those design decisions
Without a model, architecture is inscrutable. Modeling notations can be rich and ambiguous (for example, natural language), highly formal (such as the Rapide notation), semantically weak (such as Power-Point diagrams), or semantically formal. Several notations can be combined to describe architecture - for example, a UML class diagram can be annotated with natural language.
(Note: This chapter deals with basic architectural concepts and design decisions that need to be modelled, as well as modeling views, viewpoints, and visualizations. Other section covers various modeling notations: natural language (3.1); informal graphical styles (3.2); Unified Modeling Language (3.3); early Architecture Description Languages (3.4) Darwin (3.4.1), Rapide (3.4.2), and Wright (3.4.3); domain-specific and style-specific Architecture Description Languages (3.5) Koala (3.5.1), Weaves (3.5.2), and AADL (3.5.3); extensible Architecture Description Languages (3.6) Acme (3.6.1), ADML (3.6.2), and xADL (3.6.3); User Requirements Notation (3.7); and Dialog Flow Notation (3.8). )
Throughout the chapter, we also discuss how architecture modeling notations are used to capture design decisions. Definition: An architectural modeling notation is a language or means of capturing design decisions.
5.1 Modeling Concepts In this chapter, we discuss a broad spectrum of kinds of things that can be modeled in architecture, and then how various notations can be selected and used to facilitate this modeling. 5.1.1 Stakeholder-Driven Modeling One of the most critical decisions that architects and other stakeholders will make in developing architecture is to choose:
Software Architecture 1. What architectural decisions and concepts should be modeled, 2. At what level of detail, and 3. With how much rigor or formality.
These decisions should be based on costs and benefits. Architects should balance the benefits of having certain models in certain forms or notations with the cost of creating and maintaining those models. Thus, the choice of what to model, and at what level of detail, will be stakeholder driven.
Figure shows five concerns about the system identified by stakeholders. In this particular case, Concerns 1 is of great importance, and will be considered and modeled deeply. Concerns 2 and 4 are less important and will be modeled shallowly.
Modeling is an activity, and as such it is often governed by a process. The basic activities behind stakeholder-driven modeling are to: 1. Identify relevant aspects of the software to model. 2. Roughly categorize them in terms of importance. 3. Identify the goals of modeling for each aspect (communication, bug finding, quality analysis, generation of other artifacts, and so on). 4. Select modeling notations that will model the selected aspects at appropriate levels of depth to achieve the modeling goals. 5. Create the models. 6. Use the models in manner consistent with the modeling goals. Although the steps outlined above are in rough chronological order, they can be incorporated into an iterative process. 5.1.2 Basic Architectural Concepts Components Components are the architectural building blocks that encapsulate a subsets of system's functionality and data, and restrict access to them via an explicitly defined interfaces. Connectors - Connectors are the architectural building blocks that effect regulate interactions among components. Interfaces - points at which components and connectors interact with the outside world. Configurations - specific associations between the components and connectors in the system.
Notes compiled by Prof. Suresh Mestry Mobile No:8097404245 Rationale Rational is the information that explains why particular architectural decisions were made ,and what purpose various elements serve .
5.1.3 Elements of the Architectural Style Architectural style is a collection of design decisions that are applicable in a given development context, constrain design decisions within that context, and elicit beneficial qualities in the resulting system. Explicitly modeling the architectural style can be helpful for a number of reasons. 1. It reduces confusion about what is and is not allowed in the architecture. 2. It can help to reduce architectural drift and erosion. 3. It makes it easier to distinguish whether a specific design decision in architecture was made to conform to a stylistic constraint or for some other reason. 4. It can help to guide the evolution of the architecture. 5. Style represent a single place capture cross-cutting concerns and rational for an architecture. The kinds of design decisions found in an architectural style are generally more abstract or general than those found in architecture. Some kind of design decisions that might be captured in a style model include: Specific elements - particular components, interfaces and connectors to be used in a particular way in specific situations. Modeling templates or base models can be thus created. Component, connector, and interface types - kinds of elements permitted, required, or prohibited in the architecture. Interaction constraints - temporal (call one before another), topological (can be invoked only by components belonging to a certain layer), protocol (one or a group) constraints on interaction between Components and connectors. Behavioral constraints - from simple rules to complete finite state automata of the system. Concurrency constraints - rules for concurrency, synchronization, access to shared resources.
Software Architecture 5.1.4 5.1.5 Static and Dynamic Aspects
Static aspects are easier to model as they do not include changes over time. Typical models of static system aspects might include component/connector topologies, assignments of components and connectors to processing elements or host and network configurations, or mappings of architectural elements to code or binary artifacts. Dynamic aspects of a system are harder to represent. This includes interaction models, data flow models, and behavioral models. In cases when the system is usually stable but might have to change behavior if one of the components fails, both the static and dynamic models might be needed. Modeling dynamic aspects of a system can be done using static modeling (for example, interaction diagrams). Dynamic models can be employed to visualize the behavior of a running system, and are updated on-the-fly. Functional and Non-Functional Aspects Architecture can capture both functional and non-functional aspects of a system. Functional aspects relate to what a system does. Non-functional aspects relate to how a system performs its functions. Functional aspects of a system can be described using declarative, subject-verb sentences: Eg: The system prints medical records.
Non-functional aspects of a system can be described by adding adverbs to these sentences. Eg: The system prints medical records quickly and confidentially.
Architectural models tend to be functional, but like rationale it is often important to capture non-functional decisions even if they cannot be automatically or deterministically interpreted or analyzed.
Functional (what a system does) and non-functional (constraints on what a system does) aspects of the system can be captured through modeling. Functional aspects are easier to model as they are complete. Most modeling notations are designed to capture primarily functional aspects. Non-functional aspects are often captured less rigorously, as they are qualitative and subjective.
5.2 Ambiguity, Accuracy, and Precision Architectures are abstractions of systems. They capture information about some aspect of the system and leave out other aspects. Three key concepts can be used to characterize architectural models: ambiguity, accuracy, and precision. 5.2.1 Ambiguity Definition: A model is ambiguous if it is open to more than one interpretation Because conflicting interpretations of a model may lead to misunderstandings, bugs, and errors, it is generally desirable to eliminate ambiguity in design.
Notes compiled by Prof. Suresh Mestry Mobile No:8097404245 Incompleteness is a primary reason for ambiguity in models: When some aspect of a system is left unspecified, different stakeholders may make different assumptions about hoe the gap should be filled in. Architectures are necessarily incomplete: They address principal design decisions about a system, not every design decision.
5.2.2 Accuracy and Precision Many conceptions of accuracy and precision, including dictionary definition, conflate the two terms. Here, we will adopt an interpretation that more clearly delineates them. Definition: A model is accurate if it is correct, conforms to fact, or deviates from correctness within acceptable limits. Definition: A model is precise if it is sharply exact or delimited. Accuracy deals with correctness, while precision deals with exactness. In architectural terms, a model is accurate if it conveys correct information about the modeled system. A model is precise if it conveys a lot of detailed information about the modeled system.
5.3 Complex Modeling: Mixed Content and Multiple views Architectural models are complex artifacts. They attempt to capture all the design decisions about a system that are important to a wide variety of stakeholders. There can be multiple or different aspects of same concern captured simultaneously. Some basics about views and viewpoints are as follows.
Software Architecture 5.3.1 Views and Viewpoints
Generally, it is not feasible to capture everything we want to model in a single model or document o The model would be too big, complex, and confusing
So, we create several coordinated models, each capturing a subset of the design decisions o Generally, the subset is organized around a particular concern or other selection criteria
We call the subset-model a view and the concern (or criteria) a viewpoint Definitions A view is a set of design decisions related by a common concern (or set of concerns). A viewpoint is the perspective from which a view is taken. A view (what you see) is an instance of a viewpoint (filter) for a specific system .
A viewpoint is a filter for information, and a view is what you see when you look at a system through that filter. Viewpoints provide a way to limit presented information to a cognitively manageable subset of the architecture, display related concepts simultaneously, can be tailored to the needs of specific stakeholders, can be used to display the same data at various levels of abstraction. Listed below are several traditional viewpoints frequently used in modeling: 1. Logical - logical (often software) entities in the system and how they are interconnected. 2. Physical - physical (often hardware) entities in the system and how they are interconnected. 3. Deployment - how logical entities are mapped onto physical entities. 4. Concurrency - how concurrency and threading are managed in the system 5. Behavioral - expected behavior of the system or its parts. The use of views and viewpoints in modeling is important for several reasons: 1. 2. 3. 4. They provide a way to limit presented information to a cognitively manageable subset of the architecture. They display related concepts simultaneously. They can be tailored to the needs of specific stakeholders. They can be used to display the same data at various levels of abstraction.
5.3.2 Consistency among Views Views can contain overlapping and related design decisions o There is the possibility that the views can thus become inconsistent with one another
Views are consistent if the design decisions they contain are compatible o Views are inconsistent if two views assert design decisions that cannot simultaneously be true
Inconsistency is usually but not always indicative of problems o Temporary inconsistencies are a natural part of exploratory design
Software Architecture o Inconsistencies cannot always be fixed.
The following inconsistencies may exist among views: Direct inconsistencies - two views assert directly contradictory propositions, automatically detectable. E.g., The system runs on two hosts and the system runs on three hosts. Refinement inconsistencies - two views at different levels of detail assert contradictory propositions; can be automatically detected with appropriate consistency rules. Static versus dynamic aspect inconsistencies - view of a static aspect conflicts with a view of the dynamic aspect of the system, harder to automatically detect, depending on how explicit the dynamic aspect's specification is. Dynamic aspect inconsistencies - two views of dynamic aspects of the system conflict, often extremely difficult to detect automatically as it requires extensive state exploration or simulations. Functional versus non-functional aspect inconsistencies - non-functional property prescribed by a nonfunctional view is not met by the design expressed in functional views; the most difficult to detect because of the general and abstract nature of non-functional properties.
5.4 Specific Modeling Techniques This section evaluate different modeling techniques for software architecture Generic approaches 1. Natural language 2. PowerPoint-style modeling 3. UML, the Unified Modeling Language Early architecture description languages 1. Darwin 2. Rapide 3. Wright Domain- and style-specific languages 1. Koala 2. Weaves 3. AADL Extensible architecture description languages 1. Acme 2. ADML 3. xADL 5.4.1 Generic Techniques These techniques are often used to describe software architecture in whole or in part, although they were not specifically developed or adopted for this purpose, they tend to be flexible but have few semantics. Natural Language Natural (human) languages, such as English, are expressive, but ambiguous, non-formal, and non-rigorous. They cannot be effectively processed and understood by machines, and so can only be inspected by humans. Natural languages are easily accessible to stakeholders and can be handled using common word-processing tools. Due to the abstract and qualitative nature of non-functional requirements, natural languages are best in capturing those. Sometimes, a restricted form of a language is used instead of a pure language.
Notes compiled by Prof. Suresh Mestry Mobile No:8097404245 This is achieved by users employing a particular dictionary of terms, to avoid ambiguity. Extensive use of this technique is not effective, as it results in a domain-specific language without the advantages of having a flexibility of a natural language. Advantages Highly expressive Accessible to all stakeholders Good for capturing non-rigorous or informal architectural elements like rationale and non-functional requirements Plentiful tools available (word processors and other text editors) Disadvantages Ambiguous, non-rigorous, non-formal Often verbose Cannot be effectively processed or analyzed by machines/software.
Informal Graphical PowerPoint-style Modeling Informal Power-Point-style modeling allows for creation of decorative diagrams of interconnected shapes. They are easily accessible to stakeholders, assuming the tools for their manipulation are available. The slide nature of these presentations limits the diagram size, which ensures suitable abstraction. Advantages o Can be aesthetically pleasing o Size limitations (e.g., one slide, one page) generally constrain complexity of diagrams o Extremely flexible due to large symbolic vocabulary Disadvantages o Ambiguous, non-rigorous, non-formal But often treated otherwise o Cannot be effectively processed or analyzed by machines/software. The Unified Modeling language (and its Cousins) 13 loosely-interconnected notations called diagrams that capture static and dynamic aspects of softwareintensive systems UML (Booch, Rumbaugh, and Jacobson 2005) combines concepts from earlier notations: Booch diagrams, OMT, OOSE, and Statecharts. UML provides a wide variety of modeling constructs and viewpoints. There are many tools that provide varying degrees of support for UML (from diagram construction to generation of code from UML models). UML is an extensive notation that traditionally employs graphical symbols with textual annotations to represent the system from thirteen different viewpoints (as of UML 2.0). Early versions of UML focused on detailed design modeling. UML 2.0 has added support for higher-level architectural constructs. Advantages Support for a diverse array of viewpoints focused on many common software engineering concerns. Ubiquity improves comprehensibility. Extensive documentation and tool support from many vendors. Disadvantages Needs customization through profiles to reduce ambiguity. Difficult to assess consistency among views. Difficult to capture foreign concepts or views.
5.4.2 Early Architecture Description Languages There is no single definition of what constitutes an architecture description language. The uncertainty regarding this issue hinges on disagreement on what should and should not be included in the concept of software architecture. Looking at architecture as a set of principal design decisions about a system, there are several languages that fall into the category of ADLs. The early ADLs did not go past the research project stage and are not used in practice. However, they are an important part of architectural modeling development. A brief feature overview is provided below for three early ADLs: Darwin, Rapide, and Wright. Darwin Darwin is a General-purpose architecture description language for specifying the structure of system composed from components that communicate through explicit interfaces. Darwin has a canonical textual representation in which components and their interconnections are described. It is general purpose language with graphical and textual visualizations focused on structural modeling of systems. Darwin is a declarative language that describes systems as collections of components interacting via explicit interfaces. The notion of a software connector is not present, but a component that facilitates interactions can be considered a connector. Darwin components expose a set of provide and required services, sometimes called ports. Advantages Simple, straightforward mechanism for modeling structural dependencies Interesting way to specify repeated elements through programmatic constructs Can be modeled in pi-calculus for formal analysis Can specify hierarchical (i.e., composite) structures Disadvantages Limited usefulness beyond simple structural modeling No notion of explicit connectors Although components can act as connectors. Eg: component DataStore{ provide values; } component Calculation{ require values; provide calculationService; } component UserInterface{ require calculationService; require values; Rapide Rapide is a language that focuses on modeling systems that consist of components communicating via events. Procedure calls are supported by using two events: one for the call and one for the return value. Events in Rapide are combined into partially-ordered sets.
Components in the system work concurrently. Rapides textual description is similar to Darwins, except it also includes behavioral specifications. Events can be subject to causal relationships. Such relationships exist if: both events are generated by the same process; process triggered by one event generates the other; Process triggered by one event assigns a value to a variable and the process triggered by the other event reads it; one event triggers a connection that generates the other event; or events are related transitively (event A precedes C which precedes B). Rapide provides a single viewpoint and focuses on modeling dynamic aspects of the architecture. The static aspects are captured by interconnections among components. Rapide models can be executed to simulate the system's operation. The result of execution is a graph showing causal and temporal relationships between events present in the system. Consistency between multiple models of the same architecture can be checked via manual inspection of simulator outputs. Advantages o Unique and expressive language for describing asynchronously communicating components o Tool-set supports simulation of models and graphical visualization of event traces Disadvantages o No natural or explicit mapping to implemented systems o High learning curve o Important tool support is difficult to run on modern machines.
Wright Wright language deals with checking component interactions through their interfaces. The models include components, connectors, ports, roles (interfaces), attachments, and styles. Wright interfaces are based on notation derived from CSP - Communicating Sequential Process - and can be translated into CSP. The resulting model can be analyzed in an automated way (using FDR) to determine compatibility of the interfaces and to identify deadlocks. Wright supports static structural models with behavioral annotations describing component interactions. There is no support for non-functional aspects of the architecture. Structural, behavioral, and style viewpoints are supported. Automated correctness, consistency, and deadlock checks can be performed using a CSP evaluator. Advantages Structural specification similar to Darwin or Rapide Formal interface specifications can be translated automatically into CSP and analyzed with tools Can detect subtle problems e.g., deadlock Disadvantages High learning curve No direct mapping to implemented systems Addresses a small number of system properties relative to cost of use. 5.4.3 Domain- and Style Specific ADLs Domain- and style specific ADLs are important for several reasons. First, their scope is better tailored to stakeholder needs since they target particular group of stakeholder, rather than system and software developer in general.
Second they are able to leave unnecessary details. Some architectural languages are created to support a particular architectural style or to model applications within a particular domain. Below three such ADLs are presented: Koala notation for modeling products in Philips TV product line, Weaves notation for a modified pipe-and-filter architectural style , and AADL notation used for embedded and real-time system modeling .
Koala Koala is a language developed by Philips to describe the architecture of consumer electronic devices. Koala models include components that communicate via explicit provided and required interfaces. It is a Darwin-inspired notation for specifying product lines of embedded consumer-electronics devices. Koala combines the concept of portals found in Darwin with constructs that support product-line architectures. Thus multiple products can be described with a single model representing a structural viewpoint where differences are encoded as variation points. Advantages Advanced product-line features let you specify many systems in a single model Direct mapping to implemented systems promotes design and code reuse Disadvantages Limited to structural specification with additional focus on interfaces Weaves Weaves [18] is an architectural style supported by a graphical modeling notation. Weaves can be seen as a variation of pipe-filter systems with three differences: o Instead of byte streams, weaves deals with object streams. o Instead of implicit pipes, Weaves connectors are object queues of explicit size. o Instead of a single input and a single output, Weaves tools allows for multiple inputs and outputs. Models allow for components, connectors (queues) and directed interconnections. An architectural style and notation for modeling systems of small-grain tool fragments that communicates through data flows of objects. Augmenting Weaves o Weaves diagrams do not capture the protocol or kinds of data that flow across component boundaries o This could be rectified through, for example, additional natural language or more formal (e.g., CSP) protocol specifications Advantages o Extremely optimized notation. Even simpler than Darwin diagrams. o Close mapping to implemented systems. Disadvantages o Addresses structure and data flows only. AADL-The Architecture Analysis & Design Language AADL was initially created to model avionics systems. The notation is not specifically bound to that domain, however, and can be used in embedded and real-time system modeling. AADL is a textual language that can be expressed graphically and is accompanied by a UML profile to capture the information in several ways.
Notes compiled by Prof. Suresh Mestry Mobile No:8097404245 AADL includes constructs that describe both software and hardware components, as well as mapping between them. The components available include those for networks, buses, ports, threads, processes, and a large variety of others. AADL allows for specification of interfaces for flow of control and data. There exists limited support for dynamic aspect modeling. There is also support for some non-functional properties, such as timing, reliability, and safety, although they cannot be automatically analysed. The models include a high level of detail. The basic building block of this notation is a component, defined by its category (hardware, software, or composite), type (how the component interacts with the outside world) and its implementation (an instance of the component type). Notation and tool-set for modeling hardware/software systems, particularly embedded and real-time systems Advantages o Allows detailed specification of both hardware and software aspects of a system o Automated analysis tools check interesting end-to-end properties of system Disadvantages o Verbose; large amount of detail required to capture even simple systems o Emerging tool support and UML profile support
5.4.4 Extensible ADLs Modeling involves a trade-off between being able to describe a variety of systems, and taking advantage of semantically powerful features of more specialized languages, such as being able to automate model analysis and code generation. One way to resolve this is to use a combination of several languages to describe the system. This entails keeping models in sync, which requires knowledge of multiple notations. This approach might also result in inability to describe certain concerns in any of the notations. Another way to deal with the trade-off is to use extensible ADLs that strive to combine the flexibility of generic languages with precision and analyzability of semantically rich languages. Extensible ADLs normally support the common architectural constructs (such as components and connectors) and allow the user to extend the syntax to support user-defined constructs [1]. Below three extensible ADLs are presented: Acme, ADML, and xADL. ACME It is early general purpose ADL with support for extensibility through properties Acme provides a set of seven constructs: connectors, components, ports (interfaces on components), roles (interfaces on connectors), attachments (links), systems (configurations), and representations (inner architectures for components and connectors). Acme allows describing static aspects of the system natively, as well as dynamic and non-functional aspects through the use of properties. Advantages Structural specification capabilities similar to Darwin Simple property structure allows for arbitrary decoration of existing elements Tool support with AcmeStudio Disadvantages No way to add new views
Notes compiled by Prof. Suresh Mestry Mobile No:8097404245 Property specifications can become extremely complex and have entirely separate syntax/semantics of their own. ADML is a language based on XML with its syntax derived from Acme. Semantically ADML is nearly identical to Acme, with the exception of meta-properties, which allow for specification of the properties and property types that should be present on particular elements. ADML's syntax is defined using an XML DTD. Advantages o XML parsers and tools readily available. o Added some ability to reason about types of properties with meta-properties. Disadvantages o Properties are still name-value pairs. o Did not take advantage of XML extension mechanisms.
Architectural Description Markup Language (ADML)
Extensible XML-based ADL (xADL)
xADL [22] is an XML-based domain-neutral extensible ADL that fully leverages XML's extensibility mechanisms to extend the language. The syntax of xADL is defined by XML Schemas. xADL models are well-formed XML documents. Extensibility is achieved through defining derived data types in separate schemas, thus allowing data types declared in one schema to be extended in a different schema. Advantages u Growing set of generically useful modules available already u Tool support in ArchStudio environment u Users can add their own modules via well-defined extensibility mechanisms Disadvantages u Extensibility mechanisms can be complex and increase learning curve u Heavy reliance on tools
Chapter 6: Analysis
Introduction Architectural analysis is the activity of discovering important system properties using the systems architectural models. Early, useful answers about relevant architectural aspects Available prior to systems construction 6.1 Concerns Relevant to Architectural Analysis Goals of analysis Scope of analysis Primary architectural concern being analyzed Level of formality of architectural models Type of analysis Level of automation System stakeholders interested in analysis 6.2 Architectural Analysis Goals The four Cs o Completeness o Consistency o Compatibility o Correctness Completeness Completeness is both an external and an internal goal It is external with respect to system requirements o Challenged by the complexity of large systems requirements and architectures o Challenged by the many notations used to capture complex requirements as well as architectures It is internal with respect to the architectural intent and modeling notation o Have all elements been fully modeled in the notation? o Have all design decisions been properly captured?
Consistency Consistency is an internal property of an architectural model Ensures that different model elements do not contradict one another The goal of analysis is to find following inconsistencies, and then evaluate them Dimensions of architectural consistency o Name Component and connector names Component service names May be non-trivial to establish at the architectural level o Multiple system elements/services with identical names o Loose coupling via publish-subscribe or asynchronous event broadcast o Dynamically adaptable architectures o Interface
Encompasses name consistency Also involves parameter lists in component services A rich spectrum of choices at the architectural level Example: matching provided and required interfaces ReqInt: getSubQ(Natural first, Natural last, Boolean remove) returns FIFOQueue; ProvInt1: getSubQ(Index first, Index last) returns FIFOQueue; ProvInt2: getSubQ(Natural first, Natural last, Boolean remove) returns Queue;
Behavior Names and interfaces of interacting components may match, but behaviors need not. Example: subtraction Subtract (Integer x, Integer y) returns Integer; o Can we be sure what the subtract operation does? o If operation is arithmetic then,427-27=27 o And, if operation is computer calendar then, 427(27,april)-27(days)=331(31 march) Example: QueueClient and QueueServer components QueueClient precondition q.size > 0; postcondition ~q.size = q.size; QueueServer precondition q.size > 1; postcondition ~q.size = q.size - 1;
o Interaction Names, interfaces, and behaviors of interacting components may match, yet they may still be unable to interact properly Example: QueueClient and QueueServer components
Refinement Architectural models are refined during the design process A relationship must be maintained between higher and lower level models o All elements are preserved in the lower level model o All design decisions are preserved in the lower-level model o No new design decisions violate existing design decisions
Compatibility Compatibility is an external property of an architectural model It is to check the compatibility between new and reused components\connectors, reference architecture and propose architecture. Ensures that the architectural model adheres to guidelines and constraints of o a style o a reference architecture o an architectural standard Correctness Correctness is an external property of an architectural model Ensures that o the architectural model fully realizes a system specification
o the systems implementation fully realizes the architecture Inclusion of off-the-shelf elements impacts correctness o System may include structural elements, functionality, and non-functional properties that are not part of the architecture o The notion of fulfillment is key to ensuring architectural correctness.
6.3 Scope of Analysis A software systems architecture can be analyzed from different perspectives and at different levels. Architects may be interested in assessing the properties of individual components or connectors, or even their constituent, such as interfaces or ports. Components- and Connector-Level Analysis This analysis ensures that the given component or connector provides the services expected of it. For example, a components or connectors interface can be inspected to make sure that no expected services are missing. Subsystem- and system-Level Analysis Architects may assess the properties of connector-component compositions at the level of the entire system or incrementally, by focusing on particular subsystems. The most manageable increment is pair-wise conformance, where only two interacting components are considered at a time, and name, interface, behavior, and interaction conformance are established. The next step up is to take a set of components possibly interacting techniques can easily support both these cases. Ensuring desirable properties at the techniques have tried to get a handle on this problem. In many real-time systems, a component that computes its results or provides data more quickly and/or frequently than the system requires will be composed with a (simple) component that introduces the necessary delays. Data Exchanged in the System or Subsystem Distributed software systems large amounts of data are processed, exchanged, and stored. It is important that systems data is properly modeled, implemented, and exchanged among the structural elements. This involves assessing the data elements, include the following. 1. The structure of the data, such as typed versus untyped or discrete versus streamed. 2. The flow of the data through the system, such as point-to-point versus broadcast. 3. The properties of data exchanged, such as consistency, security, and latency. Example: In the following figure, Producer generating data at 1 mbps and, that data transfer to consumer1 and comsumer2 at 2Mbps and 500kbps respectively through common connector.so here is the chances of data lost because data has to wait for long time due to varying in their frequencies.
Architecture at Different Abstraction Levels During the architectural design process, architects frequently address the critical system requirements first, and then both introduce additional elements into the architecture and refine the architecture to include additional details that are necessary for the architectures realization into the final system. This may involve the addition and refinement of existing design. Example: in following figure, c1, c2, c3, c4 are components interacting through connectors, but this can be design in more depth by extracting each component with their internal communication.
6.4 Architectural concern being analyzed Architectural analysis techniques are directed at different facets of a given architecture. Some techniques ensure structural properties, other focus on the behavior provided by the architectural elements and their composition; In this section, we focus on each concern individually for ease of exposition and also discuss the relevant characteristics of each. Structural Characteristics The structural characteristics of software architecture include concerns such as the connectivity among an architectures components and connectors, containment of lower-level architectural element into composite higher-level elements, possible points of network distribution, and a given systems potential deployment architecture.Thses concerns can help to determine whether the architecture is well formed. Behavioral Characteristics Analyzing architectures behavioral characteristics are needed if components and their interaction do not provide expected behaviors.it has two facets; 1. Considering the internal behaviors of individual components. 2. Considering the architectural structure to assess composite behaviors. Interaction characteristics The relevant characteristics of interactions in a given architecture may include the numbers and types of distinct software connectors, and their values for different connector dimensions.Intraction characteristics can help to establish whether the architecture will actually be able to fulfill some of its requirements. Analysis of interaction characteristics may also encompass the interaction protocols for different system components and internal behaviors specified for different system connectors.
Non-Functional Characteristics Non-functional characteristics form a critical dimension of almost all software systems. These characteristics typically cut across multiple components and connectors, which make them particularly difficult to assess. 6.5 Level of Formality of Architectural Models Architectural models can be classified as follows Informal models o Informal models are typically captured in boxes-and-lines diagrams. Informal models can provide a useful high-level picture of the system. o They are amenable to informal and manual analysis, typically by a broad section of stakeholders, including nontechnical stakeholders such as managers and system customers. o For example, system managers can use them to determine a projects overall staffing needs. Semi-formal models o Most architectural models used in practice are semiformal. o A notation that strives to be useful to a large number of system stakeholders, both technical and nontechnical, will typically try to strike a balance between a high degree of precision and formality on the one hand, and expressiveness and understandability on the other. o Example: a semiformal languages such as the UML are amenable both to manual and automated analysis. Formal models o While semiformal modeling notations typically only have a formally defined syntax, formal notations also have formally defined semantics. o For example formal notation is wright, which was used to specify the Pipe-connector.
6.6 Types of Analysis Static analysis o Static analysis involves inferring the properties of a software system from one or more of its models, without actually executing those models. o A simple example of static analysis is syntactic analysis: determining if the system model adheres to the syntactic rules of the modeling notation. o Static analysis can be automated (for eg.compilation) or manual (for eg.inspection). Dynamic analysis o This analysis involves actually executing or simulating the execution of a model of the software system. o In order to perform dynamic analysis on an architectural model, its semantic underpinning must be executable or amenable to simulation. Scenario-driven analysis o It can be an instance of both static and dynamic. o It is used for large and complex software system. For such systems, specific-use cases are identified that represent the most important or most frequently occurring system usage scenarios, and the analysis is focus on those.
Software Architecture Note: Architectural Analysis in a Nutshell
6.7 Analysis Techniques Inspection- and review-based Architectural models studied by human stakeholders for specific properties The stakeholders define analysis objective Manual techniques Can be expensive Useful in the case of informal architectural descriptions Useful in establishing soft system properties E.g., scalability or adaptability Able to consider multiple stakeholders objectives and multiple architectural properties Inspections and Reviews in a Nutshell Analysis Goals any Analysis Scope any Analysis Concern any, but particularly suited for non-functional properties Architectural Models any, but must be geared to stakeholder needs and analysis objectives Analysis Types mostly static and scenario-based Automation Level manual, human intensive Stakeholders any, except perhaps component vendors Example ATAM Stands for architectural trade-off analysis method Human-centric process for identifying risks early on in software design
Focuses specifically on four quality attributes (NFPs) Modifiability Security Performance Reliability Reveals how well an architecture satisfies quality goals and how those goals trade-off ATAM Process
Model-based Analysis techniques that manipulate architectural description to discover architectural properties Tool-driven, hence potentially less costly Typically useful for establishing hard architectural properties only o Unable to capture design intent and rationale Usually focus on a single architectural aspect o E.g., syntactic correctness, deadlock freedom, adherence to a style Scalability may be an issue Techniques typically used in tandem to provide more complete answers
Model-Based Analysis in a Nutshell Analysis Goals consistency, compatibility, internal correctness Analysis Scope any Analysis Concern structural, behavioral, interaction, and possibly non-functional properties Architectural Models semi-formal and formal Analysis Types static Automation Level partially and fully automated Stakeholders mostly architects and developers Eg: Model-Based Analysis in ADLs Wright uses CSP to analyze for deadlocks
Notes compiled by Prof. Suresh Mestry Mobile No:8097404245 Aesop ensures style-specific constraints MetaH and UniCon support schedulability analysis via NFPs such as component criticality and priority ADL parsers and compilers ensure syntactic and semantic correctness E.g., Rapides generation of executable architectural simulations Architectural constraint enforcement E.g., Armani or UMLs OCL Architectural refinement E.g., SADL and Rapide
Simulation-based Requires producing an executable system model Simulation need not exhibit identical behavior to system implementation Many low-level system parameters may be unavailable It needs to be precise and not necessarily accurate Some architectural models may not be amenable to simulation Typically require translation to a simulatable language Simulation-Based Analysis in a Nutshell Analysis Goals any Analysis Scope any Analysis Concern behavioral, interaction, and non-functional properties Architectural Models formal Analysis Types dynamic and scenario-based Automation Level fully automated; model mapping may be manual Stakeholders any Example XTEAM eXtensible Tool-chain for Evaluation of Architectural Models Targeted at mobile and resource-constrained systems Combines two underlying ADLs o xADL and FSP Maps architectural description to adevs o An OTS event simulation engine Implements different analyses via ADL extensions and a model interpreter o Latency, memory utilization, reliability, energy consumption
Chapter 7: Implementation and Deployment

Implementation is the one phase of software development that is not optional. To achieve the goal specified in software, that architecture must be implemented. In terms of implementation, architecture is both prescriptive and restrictive. it is prescriptive in the sense that it gives implementers direction on what to produce-how to structure code modules, how they should be interconnected, and how they should behave. it is restrictive in the sense that its guidelines-particularly those specified in the architectural style-tell the developers what they may not do: the form of communication that are prohibited, the kinds of behaviors or system states that are not allowed, and so on. 7.1 Concepts 7.1.1 The Mapping Problem Implementation is the one phase of software engineering that is not optional Architecture-based development provides a unique twist on the classic problem o It becomes, in large measure, a mapping activity
Design Decisions
Implementation Artifacts
Maintaining mapping means ensuring that our architectural intent is reflected in our constructed systems Common Element Mapping Components and Connectors o Partitions of application computation and communication functionality o Modules, packages, libraries, classes, explicit components/connectors in middleware Interfaces o Programming-language level interfaces (e.g., APIs/function or method signatures) are common o State machines or protocols are harder to map Configurations o Interconnections, references, or dependencies between functional partitions o May be implicit in the implementation o May be externally specified through a MIL and enabled through middleware o May involve use of reflection Design rationale o Often does not appear directly in implementation o Retained in comments and other documentation. Dynamic Properties (e.g., behavior): o Usually translate to algorithms of some sort o Mapping strategy depends on how the behaviors are specified and what translations are available o Some behavioral specifications are more useful for generating analyses or testing plans
Non-Functional Properties o Extremely difficult to do since non-functional properties are abstract and implementations are concrete o Achieved through a combination of human-centric strategies like inspections, reviews, focus groups, user studies, beta testing, and so on One-Way vs. Round Trip Mapping Architectures inevitably change after implementation begins o For maintenance purposes o Because of time pressures o Because of new information Implementations can be a source of new information o We learn more about the feasibility of our designs when we implement o We also learn how to optimize them.
7.1.2 Architecture Implementation Frameworks Ideal approach: develop architecture based on a known style, select technologies that provide implementation support for each architectural element OO CLASS
Design Decisions
Software Library
Database
This is rarely easy or trivial o Few programming languages have explicit support for architecture-level constructs o Support infrastructure (libraries, operating systems, etc.) also has its own sets of concepts, metaphors, and rules To mitigate these mismatches, we leverage an architecture implementation framework Definition: An architecture implementation framework is a piece of software that acts as a bridge between a particular architectural style and a set of implementation technologies. It provides key elements of the architectural style in code, in a way that assists developers in implementing systems that conform to the prescriptions and constraints of the style.
OO Class
Design Design Decisions Decisions
Software Library
Database
7.1.3 Evaluating Frameworks Can draw out some of the qualitative properties just mentioned Platform support o Target language, operating system, other technologies Fidelity o How much style-specific support is provided by the framework? Many frameworks are more general than one target style or focus on a subset of the style rules o How much enforcement is provided? Matching Assumptions o Styles impose constraints on the target architecture/application o Frameworks can induce constraints as well E.g., startup order, communication patterns o To what extent does the framework make too many (or too few) assumptions? Efficiency o Frameworks pervade target applications and can potentially get involved in any interaction o To what extent does the framework limit its slowdown and provide help to improve efficiency if possible (consider buffering in stdio)? Other quality considerations o Nearly every other software quality can affect framework evaluation and selection Size Cost Ease of use Reliability Robustness Availability of source code Portability Long-term maintainability and support
7.1.4 Middleware and Component Models This may all sound similar to various kinds of middleware/component frameworks o CORBA, COM/DCOM, JavaBeans, .NET, Java Message Service (JMS), etc. They are closely related o Both provide developers with services not available in the underlying OS/language o CORBA provides well-defined interfaces, portability, remote procedure call o JavaBeans provides a standardized packaging framework (the bean) with new kinds of introspection and binding Indeed, architecture implementation frameworks are forms of middleware o Theres a subtle difference in how they emerge and develop o Middleware generally evolves based on a set of services that the developers want to have available E.g., CORBA: Support for language heterogeneity, network transparency, portability o Frameworks generally evolve based on a particular architectural style that developers want to use Why is this important? By focusing on services, middleware developers often make other decisions that substantially impact architecture E.g., in supporting network transparency and language heterogeneity, CORBA uses RPC o But is RPC necessary for these services or is it just an enabling technique? In a very real way, middleware induces an architectural style o CORBA induces the distributed objects style o JMS induces a distributed implicit invocation style Understanding these implications is essential for not having major problems when the tail wags the dog! Resolving Mismatches A style is chosen first, but the middleware selected for implementation does not support (or contradicts) that style A middleware is chosen first (or independently) and has undue influence on the architectural style used Strategies o Change or adapt the style o Change the middleware selected Use the middleware o Develop glue code as the basis for o Leverage parts of the middleware a framework and ignore others o Hide the middleware in components/connectors 7.1.5 Building a New Framework Occasionally, you need a new framework o The architectural style in use is novel o The architectural style is not novel but it is being implemented on a platform for which no framework exists
Notes compiled by Prof. Suresh Mestry Mobile No:8097404245 o The architectural style is not novel and frameworks exist for the target platform, but the existing frameworks are inadequate Good framework development is extremely difficult o Frameworks pervade nearly every aspect of your system o Making changes to frameworks often means changing the entire system o A task for experienced developers/architects Understand the target style first o Enumerate all the rules and constraints in concrete terms o Provide example design patterns and corner cases Limit the framework to the rules and constraints of the style o Do not let a particular target applications needs creep into the framework o Rule of three for applications Choose the framework scope o A framework does not necessarily have to implement all possible stylistic advantages (e.g., dynamism or distribution) Avoid over-engineering o Dont add capabilities simply because they are clever or cool, especially if known target applications wont use them o These often add complexity and reduce performance Limit overhead for application developers o Every framework induces some overhead (classes must inherit from framework base classes, communication mechanisms limited) o Try to put as little overhead as possible on framework users Develop strategies and patterns for legacy systems and components o Almost every large application will need to include elements that were not built to work with a target framework o Develop strategies for incorporating and wrapping these. o 7.1.6 Concurrency Concurrency is one of the most difficult concerns to address in implementation o Introduction of subtle bugs: deadlock, race conditions o Another topic on which there are entire books written Concurrency is often an architecture-level concern o Decisions can be made at the architectural level o Done carefully, much concurrency management can be embedded into the architecture framework Consider our earlier example, or how pipe-and-filter architectures are made concurrent without direct user involvement 7.1.7 Generative Technologies With a sufficiently detailed architectural model, various implementation artifacts can be generated o Entire system implementations
o o
Notes compiled by Prof. Suresh Mestry Mobile No:8097404245 Requires extremely detailed models including behavioral specifications More feasible in domain-specific contexts Skeletons or interfaces With detailed structure and interface specifications Compositions (e.g., glue code) With sufficient data about bindings between two elements
7.1.8 Ensuring Architecture-to-Implementation Consistency Strategies for maintaining one-way or round-trip mappings o Create and maintain traceability links from architectural implementation elements Explicit links in a database, in architectural models, in code comments can all help with consistency checking o Make the architectural model part of the implementation When the model changes, the implementation adapts automatically May involve internal generation o Generate some or all of the implementation from the architecture.
7.2 Existing Frameworks 1. Different frameworks for pipe-and-filter Framework #1: stdio Standard I/O framework used in C programming language Each process is a filter Reads input from standard input (aka stdin) Writes output to standard output (aka stdout) Also a third, unbuffered output stream called standard error (stderr) not considered here Low and high level operations getchar(), putchar() move one character at a time printf() and scanf() move and format entire strings Different implementations may vary in details (buffering strategy, etc.)
Evaluating stdio Platform support o Available with most, if not all, implementations of C programming language
Software Architecture o
Notes compiled by Prof. Suresh Mestry Mobile No:8097404245 Operates somewhat differently on OSes with no concurrency (e.g., MS-DOS)
Fidelity o Good support for developing P&F applications, but no restriction that apps have to use this style
Matching assumptions o Filters are processes and pipes are implicit. In-process P&F applications might require modifications
Efficiency o Whether filters make maximal use of concurrency is partially up to filter implementations and partially up to the OS
Framework #2: java.io Standard I/O framework used in Java language Object-oriented Can be used for in-process or inter-process P&F applications o o o All stream classes derive from InputStream or OutputStream Distinguished objects (System.in and System.out) for writing to process standard streams Additional capabilities (formatting, buffering) provided by creating composite streams (e.g., a Formatting-Buffered-InputStream)
Evaluating java.io Platform support o o Available with all Java implementations on many platforms Platform-specific differences abstracted away
Fidelity o Good support for developing P&F applications, but no restriction that apps have to use this style
Matching assumptions o o Easy to construct intra- and inter-process P&F applications Concurrency can be an issue; many calls are blocking
Software Architecture Efficiency o o Users have fine-grained control over, e.g., buffering
Very high efficiency mechanisms (memory mapped I/O, channels) not available (but are in java.nio)
2. Different frameworks for the C2 style Framework #1: Lightweight C2 Framework 16 classes, 3000 lines of code Components & connectors extend abstract base classes Concurrency, queuing handled at individual comp/conn level Messages are request or notification objects
Software Architecture Evaluating Lightweight C2 Framework Platform support o Fidelity o o Available with all Java implementations on many platforms
Assists developers with many aspects of C2 but does not enforce these constraints Leaves threading and queuing policies up to individual elements
Matching assumptions o o Comp/conn main classes must inherit from distinguished base classes All messages must be in dictionary form
Efficiency o Lightweight framework; efficiency may depend on threading and queuing policy implemented by individual elements.
Chapter 8: Applied Architectures and Styles

In this chapter, we discussing how a wide variety of important and challenging architectural problem solved, thereby enhancing the repertoire of insights and styles that a designer possesses to bring to bear on his own problem. Goals of this chapter are thus to: Describe how the concepts from the previous chapters can be used, sometimes in combination, to solve challenging design problems. Highlight key issues in emerging application domains that have architectural implications, or where an architectural perspective is essential for system development within that domain. Show how emerging architectures, such as P2P, can be characterized and understood through the lens of software architecture. 8.1 Distributed and networked architectures The phrase distributed application is used to denote everything from an application that is simply distributed across multiple operating system processes all running on the same physical uniprocessor, to integrated applications that run on multiple computers connected by the internet. 8.1.1 Limitations of the distributed systems viewpoint A particular design choice the designer made was to attempt to provide the illusion of location transparency. That is, that a developer should not know where the other object is located in order to interact with that object.(similarly, in Implementation transparency ,developer need not know that choice of programming language in which that object is implemented.) If such transparency is provided to the developer, all the concerns and issues associated across a network can be ignored, for those issues will be taken care of by the underlying CORBA support. But by looking at CORBA API, reveals that, achieving such transparency has not proved to be fully possible. The multiple difficulties of attempting to mask the presence of networks and their properties from application developers was recognized early and become canonized by Peter Deutsch in his short list, as Deutsch and his colleague James say, Essentially everyone ,when they first build a distributed application, makes the following eight assumptions. All prove to be false in the long run and all cause big trouble and painful learning exercises. The fallacies are, The network is reliable Latency is zero Bandwidth is infinite The network is secure
Software Architecture Topology doesnt change There is one administrator Transport cost is zero The network is homogeneous
8.2 Architectures for the Network-Based Applications 8.2.1 The REpresentational State Transfer Style (REST) The REST architectural style was used to design the post-1994 World Wide Web (which includes the HTTP/1.1 protocol, the Uniform Resource Identifier specification, and other elements). The goal of that representation was to begin to indicate the power of software architecture, showing its impact on one of the worlds most widespread technologies. That presentation also indicated how software architecture is not something you can necessarily derive by looking at piece of code (for example, the Apache web server). Application Drivers Architecture in Action: WWW Fig.1 Fig.2
Software Architecture Fig. 3
All three ideas (Fig.1, 2, 3) are of WWW WWWs Architecture The application is distributed (actually, decentralized) hypermedia Architecture of the Web is wholly separate from the code There is no single piece of code that implements the architecture. There are multiple pieces of code that implement the various components of the architecture. u E.g., different Web browsers
Stylistic constraints of the Webs architectural style are not apparent in the code u The effects of the constraints are evident in the Web
One of the worlds most successful applications is only understood adequately from an architectural vantage point.
Software Architecture REST Principles
The key abstraction of information is a resource, named by an URL. Any information that can be named can be a resource. The representation of a resource is a sequence of bytes, plus representation metadata to describe those bytes. The particular form of the representation can be negotiated between REST components. All interactions are context-free: each interaction contains all of the information necessary to understand the request, independent of any requests that may have preceded it. Components perform only a small set of well-defined methods on a resource producing a representation to capture the current or intended state of that resource and transfer that representation between components. These methods are global to the specific architectural instantiation of REST; for instance, all resources exposed via HTTP are expected to support each operation identically. Idempotent operations and representation metadata are encouraged in support of caching and representation reuse. The presence of intermediaries is promoted. Filtering or redirection intermediaries may also use both the metadata and the representations within requests or responses to augment, restrict, or modify requests and responses in a manner that is transparent to both the user agent and the origin server. An Instance of REST
Proxy $ Gateway $ http Origin Servers orb
a
User Agent $
http DNS
http
b c
Proxy $ http
$ http
DNS
wais Server Connector: Server+Cache: $
Client Connector:
Client+Cache: $
REST Data Elements Resource u Key information abstraction Resource ID Representation u Data plus metadata
Software Architecture Representation metadata Resource metadata Control data u e.g., specifies action as result of message REST Connectors Modern Web Examples client libwww, libwww-perl server libwww, Apache API, NSAPI cache browser cache, Akamai cache network resolver bind (DNS lookup library) tunnel SOCKS, SSL after HTTP CONNECT REST Components User agent o e.g., browser Origin server o e.g., Apache Server, Microsoft IIS Proxy o Selected by client Gateway o Squid, CGI, Reverse proxy o Controlled by server
Derivation of REST Key choices in this derivation include, Layered Separation (a theme in the middle portion of diagram) is used to increase efficiencies, enable independent evolution of elements of the system, and provide robustness; In order to further improve behavior for Internet-scale requirements, we add layered system constraints. The layered system style allows architecture to be composed of hierarchical layers by constraining component behavior such that each component cannot "see" beyond the immediate layer with which they are interacting. By restricting knowledge of the system to a single layer, we place a bound on the overall system complexity and promote substrate independence. Layers can be used to encapsulate legacy services and to protect new services from legacy clients, simplifying components by moving infrequently used functionality to a shared intermediary. Intermediaries can also be used to improve system scalability by enabling load balancing of services across multiple networks and processors. The primary disadvantage of layered systems is that they add overhead and latency to the processing of data, reducing user-perceived performance . For a network-based system that supports cache constraints, this can be offset by the benefits of shared caching at intermediaries. Placing shared caches at the boundaries of an organizational domain can result in significant performance benefits . Such layers also allow security policies to be enforced on data crossing the organizational boundary, as is required by firewalls.
Notes compiled by Prof. Suresh Mestry Mobile No:8097404245 Replication (left side of the diagram) is used to address latency and contention by allowing the reuse of information; the existence of replication is hidden from clients, of course, as a result of intermediate layers. One particular form of replication is caching information. Rather than duplicating information sources irrespective of the particular information actually requested of them, caches may maintain copies of information that has already been requested or that is anticipated to be requested. Cache can be located on the interface to a client or server connector in order to save cacheable responses to current interactions so that they can be reused for later requested interactions. A cache may be used by a client to avoid repetition of network communication, or by a server to avoid repeating the process of generating a response, with both cases serving to reduce interaction latency. A cache is typically implemented within the address space of the connector that uses it. Limited commonality (right side) addresses the competing needs for universally understood operations with extensibility. The parts of a distributed application can be made to work together either by demanding that a common body of a code be used for managing all communications, or through imposition of standards governing that communication. Clearly the use of standards to govern communication is superior to common code in an open, heterogeneous application. Innovation is fostered; local specialization may be support, different hardware platforms used, and so on.
8.3 Commercial Internet-scale applications 8.3.1 Akamai Caching to the max Akamai's technology at its core, applied mathematics and algorithms - has transformed the chaos of the Internet into a predictable, scalable, and secure platform for business and entertainment. The Akamai EdgePlatform comprises 84,000 servers deployed in 72 countries that continually monitor the
Notes compiled by Prof. Suresh Mestry Mobile No:8097404245 Internet traffic, trouble spots and overall conditions. We use that information to intelligently optimize routes and replicate content for faster, more reliable delivery. As Akamai can handle up to 15-20% of Web traffic on any given day, our view of the Internet is the most comprehensive and dynamic collected anywhere.
8.3.2
Google Google distributed file system (GFS) MapReduce o o Data selection and reduction All parallelization done automatically
Abstraction layers abound: GFS hides details of data distribution and failure, for instance; MapReduce hides the intricacies of parallelizing operations; By designing, from the outset, for living with failure of processing, storage, and network elements, a highly robust system can be created; Scale is everything: Googles business demands that everything be built with scaling issues in mind; By specializing the design to the problem domain, rather than taking the generic industry standard approach, high performance and very cost-effective solutions can be developed; By developing a general approach (MapReduce) to the data extraction/reduction problem, a highly reusable service was created.
8.4 Decentralized applications Networked applications where there are multiple authorities In other words u Computation is distributed u Parts of the network may behave differently, and vary over time
8.4.1
Shared Resource Computation: The Grid world Coordinated resource sharing in a distributed environment u E.g., Folding-at-home GLOBUS u A commonly used infrastructure Standard architecture u Fabric manages low-level resources u Connectivity: communication and authentication
Software Architecture u Resource: sharing of a single r. u Collective: coordinating r. usage Grid GLOBUS (Recovered)
8.4.2
Peer-to-peer styles Decentralized resource sharing and discovery o Napster o Gnutella P2P that works: Skype o And BitTorrent Peer-to-peer style State and behavior are distributed among peers which can act as either clients or servers. Peers: independent components, having their own state and control thread. Connectors: Network protocols, often custom. Data Elements: Network messages Topology: Network (may have redundant connections between peers); can vary arbitrarily and dynamically Supports decentralized computing with flow of control and resources distributed among peers. 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!
Software Architecture Hybrid Client-Server/P2P:Napster
Pure Decentralized P2P:Gnutella (original)
Software Architecture Overlayed P2P: SKype
Insights from Skype A mixed client-server and peer-to-peer architecture addresses the discovery problem. Replication and distribution of the directories, in the form of supernodes, addresses the scalability problem and robustness problem encountered in Napster. Promotion of ordinary peers to supernodes based upon network and processing capabilities addresses another aspect of system performance: not just any peer is relied upon for important services. A proprietary protocol employing encryption provides privacy for calls that are relayed through supernode intermediaries. Restriction of participants to clients issued by Skype, and making those clients highly resistant to inspection or modification, prevents malicious clients from entering the network.
Software Architecture Service-Oriented Architectures and web services.
Chapter 9: Designing for Non-Functional Properties

9.1 What Is an NFP? A software systems non-functional property (NFP) is a constraint on the manner in which the system implements and delivers its functionality Example of NFPs u u u u u u Efficiency Complexity Scalability Heterogeneity Adaptability Dependability
9.2 Designing for FPs Any engineering product is sold based on its functional properties (FPs) u TV set, DVD player, stereo, mobile telephone
Providing the desired functionality is often quite challenging u u u u Market demands Competition Strict deadlines Limited budgets
However, the systems success will ultimately rest on its NFPs u u u u u This system is too slow! It keeps crashing! It has so many security holes! Every time I change this feature I have to reboot! I cant get it to work with my home theater!
Software Architecture 9.3 FPs vs. NFPs An Example Microsoft Word 6.0 u u u u u u u Released in the 1990s Both for the PC and the Mac Roughly the same functionality It ran fine on the PC and was successful It was extremely slow on the Mac
Microsoft solved the problem by charging customers for downgrades A lot of bad publicity
9.4 Design Guidelines for Ensuring NFPs Only guidelines, not laws or rules Promise but do not guarantee a given NFP Necessary but not sufficient for a given NFP Have many caveats and exceptions Many trade-offs are involved
9.5 Efficiency Efficiency is a quality that reflects a software systems ability to meet its performance requirements while minimizing its usage of the resources in its computing environment u Efficiency is a measure of a systems resource usage economy
What can software architecture say about efficiency? u Isnt efficiency an implementation-level property?
Efficiency starts at the architectural level! Software Components and Efficiency Keep the components small whenever possible Keep component interfaces simple and compact Allow multiple interfaces to the same functionality Separate data components from processing components Separate data from meta-data
Software Architecture Software Connectors and Efficiency Carefully select connectors Use broadcast connectors with caution Make use of asynchronous interaction whenever possible Use location/distribution transparency judiciously
Architectural Configurations and Efficiency Keep frequently interacting components close Carefully select and place connectors in the architecture Consider the efficiency impact of selected architectural styles and patterns. 9.6 Complexity IEEE Definition u Complexity is the degree to which a software system or one of its components has a design or implementation that is difficult to understand and verify Complexity is a software systems a property that is directly proportional to the size of the system, number of its constituent elements, their internal structure, and the number and nature of their interdependencies Software Components and Complexity Separate concerns into different components Keep only the functionality inside components u Interaction goes inside connectors Keep components cohesive Be aware of the impact of off-the-shelf components on complexity Insulate processing components from changes in data format Software Connectors and Complexity Treat connectors explicitly Keep only interaction facilities inside connectors Separate interaction concerns into different connectors Restrict interactions facilitated by each connector Be aware of the impact of off-the-shelf connectors on complexity Architectural Configurations and Complexity Eliminate unnecessary dependencies Manage all dependencies explicitly Use hierarchical (de)composition 9.7 Scalability and Heterogeneity Scalability is the capability of a software system to be adapted to meet new requirements of size and scope Heterogeneity is the quality of a software system consisting of multiple disparate constituents or functioning in multiple disparate computing environments u Heterogeneity is a software systems ability to consist of multiple disparate constituents or function in multiple disparate computing environments u Portability is a software systems ability to execute on multiple platforms with minimal modifications and without significant degradation in functional or non-functional characteristics
Software Architecture Software Components and Scalability Give each component a single, clearly defined purpose Define each component to have a simple, understandable interface Do not burden components with interaction responsibilities Avoid unnecessary heterogeneity u Results in architectural mismatch Distribute the data sources Replicate data when necessary Software Connectors and Scalability Use explicit connectors Give each connector a clearly defined responsibility Choose the simplest connector suited for the task Be aware of differences between direct and indirect dependencies Avoid placing application functionality inside connectors u Application functionality goes inside components Leverage explicit connectors to support data scalability Architectural Configurations and Scalability Avoid system bottlenecks Make use of parallel processing capabilities Place the data sources close to the data consumers Try to make distribution transparent Use appropriate architectural styles
9.8 Adaptability Adaptability is a software systems ability to satisfy new requirements and adjust to new operating conditions during its lifetime. Software Components and Adaptability Give each component a single, clearly defined purpose Minimize component interdependencies Avoid burdening components with interaction responsibilities Separate processing from data Separate data from metadata Software Connectors and Adaptability Give each connector a clearly defined responsibility Make the connectors flexible Support connector composability Architectural Configurations and Adaptability Leverage explicit connectors Try to make distribution transparent Use appropriate architectural styles
9.9 Dependability Dependability is a collection of system properties that allows one to rely on a system functioning as required u Reliability is the probability that a system will perform its intended functionality under specified design limits, without failure, over a given time period u Availability is the probability that a system is operational at a particular time u Robustness is a systems ability to respond adequately to unanticipated runtime conditions u Fault-tolerant is a systems ability to respond gracefully to failures at runtime u Survivability is a systems ability to resist, recognize, recover from, and adapt to mission-compromising threats u Safety denotes the ability of a software system to avoid failures that will result in (1) loss of life, (2) injury, (3) significant damage to property, or (4) destruction of property Software Components and Dependability Carefully control external component inter-dependencies Provide reflection capabilities in components Provide suitable exception handling mechanisms Specify the components key state invariants Software Connectors and Dependability Employ connectors that strictly control component dependencies Provide appropriate component interaction guarantees Support dependability techniques via advanced connectors Architectural Configurations and Dependability Avoid single points of failure Provide back-ups of critical functionality and data Support non-intrusive system health monitoring Support dynamic adaptation
Software Architecture References 1. All chapters ppts. http://www.softwarearchitecturebook.com/svn/main/slides/ppt/ 2. REST Information http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

Software Architecture Introduction

Загружено:

Сведения о документе

Исходное описание:

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Software Architecture Introduction

Загружено:

Авторское право:

Доступные форматы

Software Architecture

Notes compiled by Prof. Suresh Mestry Mobile No:8097404245

Introduction to Software Architecture

Notes compiled by Prof. Suresh Mestry Mobile No:8097404245

This is similar (though not identical) to how we build software.

Notes compiled by Prof. Suresh Mestry Mobile No:8097404245

Notes compiled by Prof. Suresh Mestry Mobile No:8097404245

Notes compiled by Prof. Suresh Mestry Mobile No:8097404245

Chapter 1: Basic Concepts

Notes compiled by Prof. Suresh Mestry Mobile No:8097404245

That is, they do not necessarily impact a systems architecture

Notes compiled by Prof. Suresh Mestry Mobile No:8097404245

Software architectures have 3 types of elements Components Connectors Configuration

Components typically provide application-specific services.

Notes compiled by Prof. Suresh Mestry Mobile No:8097404245

Notes compiled by Prof. Suresh Mestry Mobile No:8097404245

Notes compiled by Prof. Suresh Mestry Mobile No:8097404245

Notes compiled by Prof. Suresh Mestry Mobile No:8097404245

Notes compiled by Prof. Suresh Mestry Mobile No:8097404245

2. Conventional Architectural styles

A Partial List of Common Architecture Styles

Pipes and Filters

Notes compiled by Prof. Suresh Mestry Mobile No:8097404245

Advantages to pipe-and-filter systems include:

Disadvantages to pipe-and-filter systems include:

Notes compiled by Prof. Suresh Mestry Mobile No:8097404245

Advantages of Implicit invocation to systems include:

Disadvantages of Implicit invocation to systems include:

Notes compiled by Prof. Suresh Mestry Mobile No:8097404245

Notes compiled by Prof. Suresh Mestry Mobile No:8097404245

Notes compiled by Prof. Suresh Mestry Mobile No:8097404245

Notes compiled by Prof. Suresh Mestry Mobile No:8097404245

Ch.3 Designing Architectures

Notes compiled by Prof. Suresh Mestry Mobile No:8097404245

Word processing Process control Income Tax Software

Web pages Scientific computing Banking

Software Architecture Choosing the Level and Terms of Discourse

Notes compiled by Prof. Suresh Mestry Mobile No:8097404245

Notes compiled by Prof. Suresh Mestry Mobile No:8097404245

Notes compiled by Prof. Suresh Mestry Mobile No:8097404245

Software Architecture Sense-Compute-Control(aka. Sensor-Controller-Actuator)

Notes compiled by Prof. Suresh Mestry Mobile No:8097404245

Software Architecture are applicable in a given development context

Notes compiled by Prof. Suresh Mestry Mobile No:8097404245

Code reuse o Shared implementations of invariant aspects of a style

Understandability of system organization o A phrase such as client-server conveys a lot of information

Software Architecture Interoperability o Supported by style standardization

Notes compiled by Prof. Suresh Mestry Mobile No:8097404245

Style-specific analyses o Enabled by the constrained design space

Visualizations o Style-specific depictions matching engineers mental models

Data-flow styles o o Batch sequential Pipe and filter

Shared memory o o Blackboard Rule based

Interpreter o o Interpreter Mobile code

Implicit invocation o o Event-based Publish-subscribe

Software Architecture Derived styles o o C2 CORBA

Notes compiled by Prof. Suresh Mestry Mobile No:8097404245

Traditional Language-Influenced Styles

Procedure Call Call

Notes compiled by Prof. Suresh Mestry Mobile No:8097404245

o Side effects in object method invocations Layered

Virtual Machines Refer Interpreter in ch.2 Client-server

Notes compiled by Prof. Suresh Mestry Mobile No:8097404245