Sa notes by divya (rnsit) (, Study notes for Computer Network Management and Protocols

Sa notes by divya (rnsit) (, Study notes for Computer Network Management and Protocols

PDF (6 MB)
120 pages
50Number of download
1000+Number of visits
100%on 19 votesNumber of votes
9Number of comments
Network Management System for VTU
80 points
Download points needed to download
this document
Download the document
Preview3 pages / 120
This is only a preview
3 shown on 120 pages
Download the document
This is only a preview
3 shown on 120 pages
Download the document
This is only a preview
3 shown on 120 pages
Download the document
This is only a preview
3 shown on 120 pages
Download the document








7th Semester

Information Science

[email protected]



7th Semester

Information Science

[email protected]


1. Software Architecture in Practice, Second Edition by Len Bass, Paul Clements, Rick Kazman

2. Pattern-Oriented Software Architecture byFrank Buschmann, Regine Meunier, Hans Rohnert, Peter

Sornmerlad, Michael Stal

3. An Introduction To Software Architecture byDavid Garlan And Mary Shaw

Notes have been circulated on self risk. Nobody can be held responsible if anything is wrong or is improper information or insufficient information provided in it.





Prepared By: DIVYA K [1RN09IS016] & SHWETHA SHREE [1RN09IS050] Page 2



THE ARCHITECTURE BUSINESS CYCLE The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them. Software architecture is a result of technical, business and social influences. Its existence in turn affects the technical, business and social environments that subsequently influence future architectures. We call this cycle of influences, from environment to the architecture and back to the environment, the Architecture Business Cycle (ABC). This chapter introduces the ABC in detail and examine the following:  How organizational goals influence requirements and development strategy.  How requirements lead to architecture.  How architectures are analyzed.  How architectures yield systems that suggest new organizational capabilities and requirements.

1.1 WHERE DO ARCHITECTURES COME FROM? An architecture is the result of a set of business and technical decisions. There are many influences at work in its design, and the realization of these influences will change depending on the environment in which the architecture is required to perform. Even with the same requirements, hardware, support software, and human resources available, an architect designing a system today is likely to design a different system than might have been designed five years ago.

ARCHITECTURES ARE INFLUENCED BY SYSTEM STAKEHOLDERS  Many people and organizations interested in the construction of a software system are referred to

as stakeholders. E.g. customers, end users, developers, project manager etc.  Figure below shows the architect receiving helpful stakeholder “suggestions”.


Prepared By: DIVYA K [1RN09IS016] & SHWETHA SHREE [1RN09IS050] Page 3

 Having an acceptable system involves properties such as performance, reliability, availability, platform compatibility, memory utilization, network usage, security, modifiability, usability, and interoperability with other systems as well as behavior.

 The underlying problem, of course, is that each stakeholder has different concerns and goals, some of which may be contradictory.

 The reality is that the architect often has to fill in the blanks and mediate the conflicts.

ARCHITECTURES ARE INFLUENCED BY THE DEVELOPING ORGANIZATIONS.  Architecture is influenced by the structure or nature of the development organization.  There are three classes of influence that come from the developing organizations: immediate

business, long-term business and organizational structure.  An organization may have an immediate business investment in certain assets, such as existing

architectures and the products based on them.  An organization may wish to make a long-term business investment in an infrastructure to

pursue strategic goals and may review the proposed system as one means of financing and extending that infrastructure.

 The organizational structure can shape the software architecture.

ARCHITECTURES ARE INFLUENCED BY THE BACKGROUND AND EXPERIENCE OF THE ARCHITECTS.  If the architects for a system have had good results using a particular architectural approach, such

as distributed objects or implicit invocation, chances are that they will try that same approach on a new development effort.

 Conversely, if their prior experience with this approach was disastrous, the architects may be reluctant to try it again.

 Architectural choices may also come from an architect’s education and training, exposure to successful architectural patterns, or exposure to systems that have worked particularly poorly or particularly well.

 The architects may also wish to experiment with an architectural pattern or technique learned from a book or a course.

ARCHITECTURES ARE INFLUENCED BY THE TECHNICAL ENVIRONMENT  A special case of the architect’s background and experience is reflected by the technical

environment.  The environment that is current when an architecture is designed will influence that architecture.  It might include standard industry practices or software engineering prevalent in the architect’s

professional community.

RAMIFICATIONS OF INFLUENCES ON AN ARCHITECTURE  The influences on the architect, and hence on the architecture, are shown in Figure 1.3.


Prepared By: DIVYA K [1RN09IS016] & SHWETHA SHREE [1RN09IS050] Page 4

 Influences on an architecture come from a wide variety of sources. Some are only implied, while others are explicitly in conflict.

 Architects need to know and understand the nature, source, and priority of constraints on the project as early as possible.

 Therefore, they must identify and actively engage the stakeholders to solicit their needs and expectations.

 Architects are influenced by the requirements for the product as derived from its stakeholders, the structure and goals of the developing organization, the available technical environment, and their own background and experience.

THE ARCHITECTURE AFFECTS THE FACTORS THAT INFLUENCE THEM  Relationships among business goals, product requirements, architects experience, architectures and

fielded systems form a cycle with feedback loops that a business can manage.  A business manages this cycle to handle growth, to expand its enterprise area, and to take

advantage of previous investments in architecture and system building.  Figure 1.4 shows the feedback loops. Some of the feedback comes from the architecture itself, and

some comes from the system built from it.

Working of architecture business cycle: 1) The architecture affects the structure of the developing organization. An architecture prescribes a structure

for a system it particularly prescribes the units of software that must be implemented and integrated to form the system. Teams are formed for individual software units; and the development, test, and integration activities around the units. Likewise, schedules and budgets allocate resources in chunks corresponding to the units. Teams become embedded in the organization’s structure. This is feedback from the architecture to the developing organization.

2) The architecture can affect the goals of the developing organization. A successful system built from it can enable a company to establish a foothold in a particular market area. The architecture can provide opportunities for the efficient production and deployment of the similar systems, and the organization may adjust its goals to take advantage of its newfound expertise to plumb the market. This is feedback from the system to the developing organization and the systems it builds.

3) The architecture can affect customer requirements for the next system by giving the customer the opportunity to receive a system in a more reliable, timely and economical manner than if the subsequent system were to be built from scratch.

4) The process of system building will affect the architect’s experience with subsequent systems by adding to the corporate experience base.

5) A few systems will influence and actually change the software engineering culture. i.e, The technical environment in which system builders operate and learn.


Prepared By: DIVYA K [1RN09IS016] & SHWETHA SHREE [1RN09IS050] Page 5

1.2 SOFTWARE PROCESSES AND THE ARCHITECTURE BUSINESS CYCLE Software process is the term given to the organization, ritualization, and management of software development activities. The various activities involved in creating software architecture are:  Creating the business case for the system

o It is an important step in creating and constraining any future requirements. o How much should the product cost? o What is its targeted market? o What is its targeted time to market? o Will it need to interface with other systems? o Are there system limitations that it must work within? o These are all the questions that must involve the system’s architects. o They cannot be decided solely by an architect, but if an architect is not consulted in the creation

of the business case, it may be impossible to achieve the business goals.  Understanding the requirements

o There are a variety of techniques for eliciting requirements from the stakeholders. o For ex:

 Object oriented analysis uses scenarios, or “use cases” to embody requirements.  Safety-critical systems use more rigorous approaches, such as finite-state-machine

models or formal specification languages. o Another technique that helps us understand requirements is the creation of prototypes. o Regardless of the technique used to elicit the requirements, the desired qualities of the system

to be constructed determine the shape of its structure.  Creating or selecting the architecture

o In the landmark book The Mythical Man-Month, Fred Brooks argues forcefully and eloquently that conceptual integrity is the key to sound system design and that conceptual integrity can only be had by a small number of minds coming together to design the system's architecture.

Documenting and communicating the architecture

o For the architecture to be effective as the backbone of the project’s design, it must be communicated clearly and unambiguously to all of the stakeholders.

o Developers must understand the work assignments it requires of them, testers must understand the task structure it imposes on them, management must understand the scheduling implications it suggests, and so forth.

Analyzing or evaluating the architecture

o Choosing among multiple competing designs in a rational way is one of the architect’s greatest challenges.

o Evaluating an architecture for the qualities that it supports is essential to ensuring that the system constructed from that architecture satisfies its stakeholders needs.

o Use scenario-based techniques or architecture tradeoff analysis method (ATAM) or cost benefit analysis method (CBAM).

Implementing the system based on the architecture

o This activity is concerned with keeping the developers faithful to the structures and interaction protocols constrained by the architecture.

o Having an explicit and well-communicated architecture is the first step toward ensuring architectural conformance.

Ensuring that the implementation conforms to the architecture

o Finally, when an architecture is created and used, it goes into a maintenance phase. o Constant vigilance is required to ensure that the actual architecture and its representation

remain to each other during this phase.

1.3 WHAT MAKES A “GOOD” ARCHITECTURE? Given the same technical requirements for a system, two different architects in different organizations will produce different architectures, how can we determine if either one of them is the right one?


Prepared By: DIVYA K [1RN09IS016] & SHWETHA SHREE [1RN09IS050] Page 6

We divide our observations into two clusters: process recommendations and product (or structural) recommendations.

Process recommendations are as follows:  The architecture should be the product of a single architect or a small group of architects with an

identified leader.  The architect (or architecture team) should have the functional requirements for the system and an

articulated, prioritized list of quality attributes that the architecture is expected to satisfy.  The architecture should be well documented, with at least one static view and one dynamic view, using

an agreed-on notation that all stakeholders can understand with a minimum of effort.  The architecture should be circulated to the system’s stakeholders, who should be actively involved in

its review.  The architecture should be analyzed for applicable quantitative measures (such as maximum

throughput) and formally evaluated for quality attributes before it is too late to make changes to it.  The architecture should lend itself to incremental implementation via the creation of a “skeletal” system

in which the communication paths are exercised but which at first has minimal functionality. This skeletal system can then be used to “grow” the system incrementally, easing the integration and testing efforts.

 The architecture should result in a specific (and small) set of resource contention areas, the resolution of which is clearly specified, circulated and maintained.

Product (structural) recommendations are as follows:  The architecture should feature well-defined modules whose functional responsibilities are allocated

on the principles of information hiding and separation of concerns.  Each module should have a well-defined interface that encapsulates or “hides” changeable aspects from

other software that uses its facilities. These interfaces should allow their respective development teams to work largely independent of each other.

 Quality attributes should be achieved using well-known architectural tactics specific to each attribute.  The architecture should never depend on a particular version of a commercial product or tool.  Modules that produce data should be separate from modules that consume data. This tends to increase

modifiability.  For parallel processing systems, the architecture should feature well-defined processors or tasks that

do not necessarily mirror the module decomposition structure.  Every task or process should be written so that its assignment to a specific processor can be easily

changed, perhaps even at runtime.  The architecture should feature a small number of simple interaction patterns.




Figure 2.1 : Typical, but uninformative, presentation of a software architecture


Prepared By: DIVYA K [1RN09IS016] & SHWETHA SHREE [1RN09IS050] Page 7

Figure 2.1, taken from a system description for an underwater acoustic simulation, purports to describe that system's "top-level architecture" and is precisely the kind of diagram most often displayed to help explain an architecture. Exactly what can we tell from it?  The system consists of four elements.  Three of the elements— Prop Loss Model (MODP), Reverb Model (MODR), and Noise Model (MODN)—

might have more in common with each other than with the fourth—Control Process (CP)—because they are positioned next to each other.

 All of the elements apparently have some sort of relationship with each other, since the diagram is fully connected.

Is this an architecture? What can we not tell from the diagram?  What is the nature of the elements?

What is the significance of their separation? Do they run on separate processors? Do they run at separate times? Do the elements consist of processes, programs, or both? Do they represent ways in which the project labor will be divided, or do they convey a sense of runtime separation? Are they objects, tasks, functions, processes, distributed programs, or something else?

What are the responsibilities of the elements? What is it they do? What is their function in the system?

What is the significance of the connections? Do the connections mean that the elements communicate with each other, control each other, send data to each other, use each other, invoke each other, synchronize with each other, share some information-hiding secret with each other, or some combination of these or other relations? What are the mechanisms for the communication? What information flows across the mechanisms, whatever they may be?

What is the significance of the layout? Why is CP on a separate level? Does it call the other three elements, and are the others not allowed to call it? Does it contain the other three in an implementation unit sense? Or is there simply no room to put all four elements on the same row in the diagram?

This diagram does not show a software architecture. We now define what does constitute a software architecture:

The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them.

Let's look at some of the implications of this definition in more detail. Architecture defines software elements The definition makes clear that systems can and do comprise more than one structure and that no one

structure can irrefutably claim to be the architecture. The definition implies that every computing system with software has a software architecture because

every system can be shown to comprise elements and the relations among them. The behavior of each element is part of the architecture insofar as that behavior can be observed or

discerned from the point of view of another element. Such behavior is what allows elements to interact with each other, which is clearly part of the architecture.

The definition is indifferent as to whether the architecture for a system is a good one or a bad one, meaning that it will allow or prevent the system from meeting its behavioral, performance, and life- cycle requirements.

2.2 OTHER POINTS OF VIEW The study of software architecture is an attempt to abstract the commonalities inherent in system design, and as such it must account for a wide range of activities, concepts, methods, approaches, and results.  Architecture is high-level design. Other tasks associated with design are not architectural, such as

deciding on important data structures that will be encapsulated.  Architecture is the overall structure of the system. The different structures provide the critical

engineering leverage points to imbue a system with the quality attributes that will render it a success or failure. The multiplicity of structures in an architecture lies at the heart of the concept.

Architecture is the structure of the components of a program or system, their interrelationships, and the principles and guidelines governing their design and evolution over time.Any system has an architecture that can be discovered and analyzed independently of any knowledge of the process by which the architecture was designed or evolved.


Prepared By: DIVYA K [1RN09IS016] & SHWETHA SHREE [1RN09IS050] Page 8

Architecture is components and connectors.Connectors imply a runtime mechanism for transferring control and data around a system. When we speak of "relationships" among elements, we intend to capture both runtime and non-runtime relationships.

2.3 ARCHITECTURAL PATTERNS, REFERENCE MODELS & REFERENCE ARCHITECTURES An architectural pattern is a description of element and relation types together with a set of constraints on how they may be used. For ex: client-server is a common architectural pattern. Client and server are two element types, and their coordination is described in terms of the protocol that the server uses to communicate with each of its clients. A reference model is a division of functionality together with data flow between the pieces. A reference model is a standard decomposition of a known problem into parts that cooperatively solve the problem. A reference architecture is a reference model mapped onto software elements (that cooperatively implement the functionality defined in the reference model) and the data flows between them. Whereas a reference model divides the functionality, A reference architecture is the mapping of that functionality onto a system decomposition.

Reference models, architectural patterns, and reference architectures are not architectures; they are useful concepts that capture elements of an architecture. Each is the outcome of early design decisions. The relationship among these design elements is shown in Figure 2.2. A software architect must design a system that provides concurrency, portability, modifiability, usability, security, and the like, and that reflects consideration of the tradeoffs among these needs.

2.4 WHY IS SOFTWARE ARCHITECTURE IMPORTANT? There are fundamentally three reasons for software architecture’s importance from a technical perspective.

Communication among stakeholders: software architecture represents a common abstraction of a system that most if not all of the system’s stakeholders can use as a basis for mutual understanding, negotiation, consensus and communication.

Early design decisions: Software architecture manifests the earliest design decisions about a system with respect to the system's remaining development, its deployment, and its maintenance life. It is the earliest point at which design decisions governing the system to be built can be analyzed.

Transferable abstraction of a system: software architecture model is transferable across systems. It can be applied to other systems exhibiting similar quality attribute and functional attribute and functional requirements and can promote large-scale re-use.

We will address each of these points in turn:

ARCHITECTURE IS THE VEHICLE FOR STAKEHOLDER COMMUNICATION  Each stakeholder of a software system – customer, user, project manager, coder, tester and so on - is

concerned with different system characteristics that are affected by the architecture.  For ex. The user is concerned that the system is reliable and available when needed; the customer is

concerned that the architecture can be implemented on schedule and to budget; the manager is


Prepared By: DIVYA K [1RN09IS016] & SHWETHA SHREE [1RN09IS050] Page 9

worried that the architecture will allow teams to work largely independently, interacting in disciplined and controlled ways.

 Architecture provides a common language in which different concerns can be expressed, negotiated, and resolved at a level that is intellectually manageable even for large, complex systems.

ARCHITECTURE MANIFESTS THE EARLIEST SET OF DESIGN DECISIONS Software architecture represents a system’s earliest set of design decisions. These early decisions are the most difficult to get correct and the hardest to change later in the development process, and they have the most far-reaching effects.  The architecture defines constraints on implementation

o This means that the implementation must be divided into the prescribed elements, the elements must interact with each other in the prescribed fashion, and each element must fulfill its responsibility to the others as dictated by the architecture.

The architecture dictates organizational structure o The normal method for dividing up the labor in a large system is to assign different groups

different portions of the system to construct. This is called the work breakdown structure of a system.

The architecture inhibits or enables a system’s quality attributes o Whether a system will be able to exhibit its desired (or required) quality attributes is

substantially determined by its architecture. o However, the architecture alone cannot guarantee functionality or quality. o Decisions at all stages of the life cycle—from high-level design to coding and

implementation—affect system quality. o Quality is not completely a function of architectural design. To ensure quality, a good

architecture is necessary, but not sufficient.  Predicting system qualities by studying the architecture

o Architecture evaluation techniques such as the architecture tradeoff analysis method support top-down insight into the attributes of software product quality that is made possible (and constrained) by software architectures.

The architecture makes it easier to reason about and manage change o Software systems change over their lifetimes. o Every architecture partitions possible changes into three categories: local, nonlocal, and

architectural. o A local change can be accomplished by modifying a single element. o A nonlocal change requires multiple element modifications but leaves the underlying

architectural approach intact.  The architecture helps in evolutionary prototyping

o The system is executable early in the product's life cycle. Its fidelity increases as prototype parts are replaced by complete versions of the software.

o A special case of having the system executable early is that potential performance problems can be identified early in the product’s life cycle.

The architecture enables more accurate cost and schedule estimates o Cost and schedule estimates are an important management tool to enable the manager to

acquire the necessary resources and to understand whether a project is in trouble.

ARCHITECTURE AS A TRANSFERABLE, RE-USABLE MODEL The earlier in the life cycle re-use is applied, the greater the benefit that can be achieved. While code re- use is beneficial, re-use at the architectural level provides tremendous leverage for systems with similar requirements.  Software product lines share a common architecture A software product line or family is a set of software-intensive systems sharing a common, managed set of features that satisfy the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way.Systems can be built using large. Externally developed elements


Prepared By: DIVYA K [1RN09IS016] & SHWETHA SHREE [1RN09IS050] Page 10

Whereas earlier software paradigms focused on programming as the prime activity, with progress measured in lines of code, architecture-based development often focuses on composing or assembling elements that are likely to have been developed separately, even independently, from each other.  Less is more: it pays to restrict the vocabulary of design alternatives We wish to minimize the design complexity of the system we are building. Advantages to this approach include enhanced re-use more regular and simpler designs that are more easily understood and communicated, more capable analysis, shorter selection time, and greater interoperability.  An architecture permits template-based development An architecture embodies design decisions about how elements interact that, while reflected in each element's implementation, can be localized and written just once. Templates can be used to capture in one place the inter-element interaction mechanisms.  An architecture can be the basis for training The architecture, including a description of how elements interact to carry out the required behavior, can serve as the introduction to the system for new project members.

2.5 ARCHITECTURAL STRUCTURES AND VIEWS Architectural structures can by and large be divided into three groups, depending on the broad nature of the elements they show.  Module structures.

Here the elements are modules, which are units of implementation. Modules represent a code-based way of considering the system. They are assigned areas of functional responsibility. There is less emphasis on how the resulting software manifests itself at runtime. Module structures allow us to answer questions such as What is the primary functional responsibility assigned to each module? What other software elements is a module allowed to use? What other software does it actually use? What modules are related to other modules by generalization or specialization (i.e., inheritance) relationships?

Component-and-connector structures. Here the elements are runtime components (which are the principal units of computation) and connectors (which are the communication vehicles among components). Component-and-connector structures help answer questions such as What are the major executing components and how do they interact? What are the major shared data stores? Which parts of the system are replicated? How does data progress through the system? What parts of the system can run in parallel? How can the system's structure change as it executes?

Allocation structures.

Allocation structures show the relationship between the software elements and the elements in one or more external environments in which the software is created and executed. They answer questions such as What processor does each software element execute on? In what files is each element stored during development, testing, and system building? What is the assignment of software elements to development teams?


Prepared By: DIVYA K [1RN09IS016] & SHWETHA SHREE [1RN09IS050] Page 11


Module Module-based structures include the following structures.  Decomposition: The units are modules related to each other by the "is a submodule of " relation,

showing how larger modules are decomposed into smaller ones recursively until they are small enough to be easily understood.

Uses: The units are related by the uses relation. One unit uses another if the correctness of the first requires the presence of a correct version (as opposed to a stub) of the second.

Layered: Layers are often designed as abstractions (virtual machines) that hide implementation specifics below from the layers above, engendering portability.

Class or generalization: The class structure allows us to reason about re-use and the incremental addition of functionality.

Component-and-connector Component-and-connector structures include the following structures  Process or communicating processes: The units here are processes or threads that are connected with

each other by communication, synchronization, and/or exclusion operations.  Concurrency: The concurrency structure is used early in design to identify the requirements for

managing the issues associated with concurrent execution.  Shared data or repository: This structure comprises components and connectors that create, store,

and access persistent data  Client-server: This is useful for separation of concerns (supporting modifiability), for physical

distribution, and for load balancing (supporting runtime performance).

Allocation Allocation structures include the following structures  Deployment: This view allows an engineer to reason about performance, data integrity, availability, and

security  Implementation: This is critical for the management of development activities and builds processes.  Work assignment: This structure assigns responsibility for implementing and integrating the modules

to the appropriate development teams.

RELATING STRUCTURES TO EACH OTHER Each of these structures provides a different perspective and design handle on a system, and each is valid and useful in its own right. In general, mappings between structures are many to many. Individual structures bring with them the power to manipulate one or more quality attributes. They represent a powerful separation-of- concerns approach for creating the architecture.

WHICH STRUCTURES TO CHOOSE? Kruchten's four views follow:  Logical.The elements are "key abstractions," which are manifested in the object-oriented world as

objects or object classes. This is a module view.  Process.This view addresses concurrency and distribution of functionality. It is a component-and-

connector view.  Development.This view shows the organization of software modules, libraries, subsystems, and units

of development. It is an allocation view, mapping software to the development environment.  Physical.This view maps other elements onto processing and communication nodes and is also an

allocation view


Prepared By: DIVYA K [1RN09IS016] & SHWETHA SHREE [1RN09IS050] Page 12



1 What is a architecture business cycle? Dec 09 7

2 Why is software architecture important? Dec 09 3

3 List all the common software architecture structures. Explain the component

connector structure.

Dec 09 10

4 Define software architecture. Explain the common software architecture structures. June 10 10

5 Explain how the architecture business cycle works, with a neat diagram June 10 10

6 Explain how the software architectures affect the factors of influence. Hence or

otherwise explain ABC.

Dec 10 8

7 Briefly explain the technical importance of software architectures. Further elaborate

on the fact that architecture is the vehicle for stakeholder communication

Dec 10 7

8 What is an allocation structure as applied to software architectures? Explain the

three allocation structures in practice.

Dec 10 5

9 With the help of a neat block diagram of ABC, explain in detail the different activities

which are involved in creating a software architecture

June 11 10

10 Enumerate and explain in detail the different groups software architecture

structures are categorized into with the help of appropriate pictorial descriptions

June 11 10

11 Define software architecture. Discuss in detail, the implications of the definition Dec 11 10

12 Define the following terms:

i)architectural model

ii)reference model

iii)reference architecture

Dec 11 6

13 Explain the module based structures Dec 11 4

14 Define software architecture. What is a architecture business cycle? Explain with a

neat diagram

June 12 10

15 Define architectural model, reference model, reference architecture and bring out

the relationship between them

June 12 6

16 Explain the various process recommendations as used by an architect while

developing software architectures

June 12 4


Prepared By: DIVYA K [1RN09IS016] & SHWETHA SHREE [1RN09IS050] Page 13


ARCHITECTURAL STYLES List of common architectural styles:

Dataflow systems:  Batch sequential  Pipes and filters

Virtual machines:  Interpreters  Rule-based systems

Call-and-return systems:  Main program and subroutine OO systems Hierarchical layers.

Data-centered systems:  Databases  Hypertext systems  Blackboards.

Independent components:  Communicating processes  Event systems

PIPES AND FILTERS  Each components has set of inputs and set of outputs  A component reads streams of data on its input and produces streams of data on its output.  By applying local transformation to the input streams and computing incrementally, so that output

begins before input is consumed. Hence, components are termed as filters.  Connectors of this style serve as conducts for the streams transmitting outputs of one filter to inputs of

another. Hence, connectors are termed pipes.

Conditions (invariants) of this style are:  Filters must be independent entities.  They should not share state with other filter  Filters do not know the identity of their upstream and downstream filters.  Specification might restrict what appears on input pipes and the result that appears on the output

pipes.  Correctness of the output of a pipe-and-filter network should not depend on the order in which filter

perform their processing.

Common specialization of this style includes :  Pipelines:

Restrict the topologies to linear sequences of filters.  Bounded pipes:

Restrict the amount of data that can reside on pipe.  Typed pipes:

Requires that the data passed between two filters have a well-defined type. Batch sequential system:


Prepared By: DIVYA K [1RN09IS016] & SHWETHA SHREE [1RN09IS050] Page 14

A degenerate case of a pipeline architecture occurs when each filter processes all of its input data as a single entity. In these systems pipes no longer serve the function of providing a stream of data and are largely vestigial.

Example 1: Best known example of pipe-and-filter architecture are programs written in UNIX-SHELL. Unix supports this style by providing a notation for connecting components [Unix process] and by providing run-time mechanisms for implementing pipes. Example 2: Traditionally compilers have been viewed as pipeline systems. Stages in the pipeline include lexical analysis parsing, semantic analysis and code generation other examples of this type are.  Signal processing domains  Parallel processing  Functional processing  Distributed systems.


o They allow the designer to understand the overall input/output behavior of a system as a simple composition of the behavior of the individual filters.

o They support reuse: Any two filters can be hooked together if they agree on data. o Systems are easy to maintain and enhance: New filters can be added to exciting systems. o They permit certain kinds of specialized analysis eg: deadlock, throughput o They support concurrent execution.


o They lead to a batch organization of processing. o Filters are independent even though they process data incrementally. o Not good at handling interactive applications  When incremental display updates are required.  They may be hampered by having to maintain correspondences between two separate but

related streams.  Lowest common denominator on data transmission.

This can lead to both loss of performance and to increased complexity in writing the filters.

OBJECT-ORIENTED AND DATA ABSTRACTION In this approach, data representation and their associated primitive operations are encapsulated in the abstract data type (ADT) or object. The components of this style are- objects/ADT’s objects interact through function and procedure invocations. Two important aspects of this style are:

 Object is responsible for preserving the integrity of its representation.  Representation is hidden from other objects.

Advantages  It is possible to change the implementation without affecting the clients because an object hides its

representation from clients.


Prepared By: DIVYA K [1RN09IS016] & SHWETHA SHREE [1RN09IS050] Page 15

 The bundling of a set of accessing routines with the data they manipulate allows designers to decompose problems into collections of interacting agents.

Disadvantages  To call a procedure, it must know the identity of the other object.  Whenever the identity of object changes it is necessary to modify all other objects that explicitly invoke


EVENT-BASED, IMPLICIT INVOCATION  Instead of invoking the procedure directly a component can announce one or more events.  Other components in the system can register an interest in an event by associating a procedure to it.  When the event is announced, the system itself invokes all of the procedure that have been registered

for the event. Thus an event announcement “implicitly” causes the invocation of procedures in other modules.

 Architecturally speaking, the components in an implicit invocation style are modules whose interface provides both a collection of procedures and a set of events.

Advantages: It provides strong support for reuse

Any component can be introduced into the system simply by registering it for the events of that system.  Implicit invocation eases system evolution.

Components may be replaced by other components without affecting the interfaces of other components.

Disadvantages:  Components relinquish control over the computation performed by the system.  Concerns change of data

Global performance and resource management can become artificial issues.

LAYERED SYSTEMS:  A layered system is organized hierarchically  Each layer provides service to the layer above it.  Inner layers are hidden from all except the adjacent

layers.  Connectors are defined by the protocols that determine

how layers interact each other.  Goal is to achieve qualities of modifiability portability.

Examples:  Layered communication protocol  Operating systems  Database systems


o They support designs based on increasing levels abstraction. o Allows implementers to partition a complex problem into a sequence of incremental steps. o They support enhancement o They support reuse.


o Not easily all systems can be structures in a layered fashion.


Prepared By: DIVYA K [1RN09IS016] & SHWETHA SHREE [1RN09IS050] Page 16

o Performance may require closer coupling between logically high-level functions and their lower-level implementations.

o Difficulty to mapping existing protocols into the ISO framework as many of those protocols bridge several layers. Layer bridging: functions is one layer may talk to other than its immediate neighbor.

REPOSITORIES: [data cantered architecture]  Goal of achieving the quality of integrability of data.  In this style, there are two kinds of components.

i. Central data structure- represents current state. ii. Collection of independent components which operate on central data store.

The choice of a control discipline leads to two major sub categories.  Type of transactions is an input stream trigger selection of process to execute  Current state of the central data structure is the main trigger for selecting processes to execute.

Active repository such as blackboard.

Blackboard: Three major parts:

Knowledge sources: Separate, independent parcels of application – dependents knowledge.

Blackboard data structure: Problem solving state data, organized into an application-dependent hierarchy

Control: Driven entirely by the state of blackboard

 Invocation of a knowledge source (ks) is triggered by the state of blackboard.  The actual focus of control can be in

- knowledge source - blackboard - Separate module or - combination of these

Blackboard systems have traditionally been used for application requiring complex interpretation of signal processing like speech recognition, pattern recognition.

INTERPRETERS  An interpreter includes pseudo program being

interpreted and interpretation engine.  Pseudo program includes the program and

activation record.  Interpretation engine includes both definition of

interpreter and current state of its execution. Interpreter includes 4 components:

1 Interpretation engine: to do the work 2 Memory: that contains pseudo code to be

interpreted. 3 Representation of control state of interpretation

engine 4 Representation of control state of the program

being simulated.Ex: JVM or “virtual Pascal machine”


Prepared By: DIVYA K [1RN09IS016] & SHWETHA SHREE [1RN09IS050] Page 17

Advantages: Executing program via interpreters adds flexibility through the ability to interrupt and query the program Disadvantages: Performance cost because of additional computational involved


PROCESS CONTROL PARADIGMS Useful definitions: Process variables  properties of the process that can be measured Controlled variable  process variable whose value of 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 Feedback control system  the controlled variable is measured and the result is used to manipulate one or more of the process variables Feed forward control system  some of the process variables are measured, and anticipated disturbances are compensated without waiting for changes in the controlled variable to be visible.

The open-loop assumptions are rarely valid for physical processes in the real world. More often, properties such as temperature, pressure and flow rates are monitored, and their values are used to control the process by changing the settings of apparatus such as valve, heaters and chillers. Such systems are called closed loop systems.

Figure 2.8 open-loop temperature control

A home thermostat is a common example; the air temperature at the thermostat is measured, and the furnace is turned on and off as necessary to maintain the desired temperature. Figure 2.9 shows the addition of a thermostat to convert figure 2.8 to a closed loop system.

Figure 2.9 closed-loop temperature control

Feedback control: Figure 2.9 corresponds to figure 2.10 as follows:  The furnace with burner is the process  The thermostat is the controller  The return air temperature is the input variable  The hot air temperature is the controlled variable


Prepared By: DIVYA K [1RN09IS016] & SHWETHA SHREE [1RN09IS050] Page 18

 The thermostat setting is the set point  Temperature sensor is the sensor

Figure 2.10 feedback control

Feedforward control: It anticipates future effects on the controlled variable by measuring other process variables and adjusts the process based on these variables. The important components of a feedforward controller are essentially the same as for a feedback controller except that the sensor(s) obtain values of input or intermediate variables.

Figure 2.11 feedforward control

 These are simplified models  They do not deal with complexities - properties of sensors, transmission delays & calibration issues  They ignore the response characteristics of the system, such as gain, lag and hysteresis.  They don’t show how combined feedforward and feedback  They don’t show how to manipulate process variables.

A SOFTWARE PARADIGM FOR PROCESS CONTROL An architectural style for software that controls continuous processes can be based on the process-control model, incorporating the essential parts of a process-control loop:  Computational elements: separate the process of interest from the controlled policy

Process definition, including mechanisms for manipulating some process variables  Control algorithm, for deciding how to manipulate variables

Data element: continuously updated process variables and sensors that collect them  Process variables, including designed input, controlled and manipulated variables and

knowledge of which can be sensed  Set point, or reference value for controlled variable  Sensors to obtain values of process variables pertinent to control

The control loop paradigm: establishes the relation that the control algorithm exercises.

OTHER FAMILIAR ARCHITECTURES Distributed processes: Distributed systems have developed a number of common organizations for

multi-process systems. Some can be characterized primarily by their topological features, such as ring and star organizations. Others are better characterized in terms of the kinds of inter-process protocols that are used for communication (e.g., heartbeat algorithms).

Main program/subroutine organizations: The primary organization of many systems mirrors the programming language in which the system is written. For languages without support for modularization this often results in a system organized around a main program and a set of subroutines.

Domain-specific software architectures: These architectures provide an organizational structure tailored to a family of applications, such as avionics, command and control, or vehicle management


Prepared By: DIVYA K [1RN09IS016] & SHWETHA SHREE [1RN09IS050] Page 19

systems. By specializing the architecture to the domain, it is possible to increase the descriptive power of structures.

State transition systems: These systems are defined in terms a set of states and a set of named transitions that move a system from one state to another.

HETEROGENEOUS ARCHITECTURES Architectural styles can be combined in several ways:  One way is through hierarchy. Example: UNIX pipeline  Second way is to combine styles is to permit a single component to use a mixture of architectural

connectors. Example: “active database”  Third way is to combine styles is to completely elaborate one level of architectural description in a

completely different architectural style. Example: case studies


KEYWORD IN CONTEXT (KWIC) This case study shows how different architectural solutions to the same problem provide different benefits. Parnas proposed the following problems:

KWIC index system accepts an ordered set of lines. Each line is an ordered set of words and each word is an ordered set of characters. Any line may be circularly shifted by repeated removing the first word and appending it at the end of the line. KWIC index system outputs a listing of all circular shifts of all lines in alphabetical order.

Parnas used the problem to contrast different criteria for decomposing a system into modules. He describes 2 solutions:

a) Based on functional decomposition with share access to data representation. b) Based on decomposition that hides design decision.

From the point of view of Software Architecture, the problem is to illustrate the effect of changes on software design. He shows that different problem decomposition vary greatly in their ability to withstand design changes. The changes that are considered by parnas are:

1. The changes in processing algorithm: Eg: line shifting can be performed on each line as it is read from input device, on all lines after they are read or an demand when alphabetization requires a new set of shifted lines.

2. Changes in data representation: Eg: Lines, words, characters can be stored in different ways. Circular shifts can be stored explicitly or implicitly

Garlan, Kaiser and Notkin also use KWIC problem to illustrate modularization schemes based on implicit invocation. They considered the following.

3. Enhancement to system function: Modify the system to eliminate circular shift that starts with certain noise change the system to interactive.

4. Performance: Both space and time

5. Reuse: Extent to which components serve as reusable entities

Let’s outline 4 architectural designs for KWIC system.


Prepared By: DIVYA K [1RN09IS016] & SHWETHA SHREE [1RN09IS050] Page 20

SOLUTION 1: MAIN PROGRAM/SUBROUTINE WITH SHARED DATA  Decompose the problem according to 4 basic functions performed.

o Input o Shift o Alphabetize o output

 These computational components are coordinated as subroutines by a main program that sequence through them in turn.

 Data is communicated between components through shared storage.  Communication between computational component and shared data is constrained by read-write


Advantages:  Allows data to be represented efficiently. Since, computation can share the same storage

Disadvantages:  Change in data storage format will affect almost all of the modules.  Changes in the overall processing algorithm and enhancement to system function are not easily

accommodated.  This decomposition is not particularly support reuse.

SOLUTION 2: ABSTRACT DATA TYPES  Decomposes The System Into A Similar Set Of Five Modules.  Data is no longer directly shared by the computational components.  Each module provides an interface that permits other components to access data only by invoking

procedures in that interface.



Prepared By: DIVYA K [1RN09IS016] & SHWETHA SHREE [1RN09IS050] Page 21

 Both Algorithms and data representation can be changed in individual modules without affecting others.

 Reuse is better supported because modules make fewer assumption about the others with which they interact.

Disadvantage:  Not well suited for functional enhancements  To add new functions to the system  To modify the existing modules.

SOLUTION 3: IMPLICIT INVOCATION  Uses a form of component integration based on shared data  Differs from 1st solution by these two factors

o Interface to the data is abstract o Computations are invoked implicitly as data is modified. Interactions is based on an active data

model. Advantages:  Supports functional enhancement to the system  Supports reuse.

Disadvantages:  Difficult to control the processing order.  Because invocations are data driven, implementation of this kind of decomposition uses more space.

SOLUTION 4: PIPES AND FILTERS:  Four filters: Input, Output, Shift and alphabetize  Each filter process the data and sends it to the next filter  Control is distributed

o Each filter can run whenever it has data on which to compute.  Data sharing between filters are strictly limited.



Prepared By: DIVYA K [1RN09IS016] & SHWETHA SHREE [1RN09IS050] Page 22

 It maintains initiative flow of processing  It supports reuse  New functions can be easily added to the system by inserting filters at appropriate level.  It is easy to modify.

Disadvantages:  Impossible to modify the design to support an interactive system.  Solution uses space inefficiently.


INSTRUMENTATION SOFTWARE:  Describes the industrial development of software architecture.  The purpose of the project was to develop a reusable system architecture for oscilloscope  Oscilloscope is an instrumentation system that samples electrical signals and displays pictures of them

on screen.  Oscilloscope also performs measurements on the signals and displays them on screen.  Modern oscilloscope has to perform dozens of measurements supply megabytes of internal storage.  Support an interface to a network of workstations and other instruments and provide sophisticated

user interface, including touch panel screen with menus, built-in help facilities and color displays.  Problems faced:

 Little reuse across different oscilloscope products.  Performance problems were increasing because the software was not rapidly configurable

within the instrument.  Goal of the project was to develop an architectural framework for oscilloscope.  Result of that was domain specific software architecture that formed the basis of the next generation of


SOLUTION 1: OBJECT ORIENTED MODEL Different data types used in oscilloscope are:  Waveforms  Signals  Measurements  Trigger modes so on

There was no overall model that explained how the types fit together. This led to confusion about the partitioning of functionality. Ex: it is not clearly defined that measurements to be associated with types of data being measured or represented externally.


Prepared By: DIVYA K [1RN09IS016] & SHWETHA SHREE [1RN09IS050] Page 23

SOLUTION 2: LAYERED MODEL  To correct the problems by providing a layered model of an oscilloscope.  Core-layer: implemented in hardware represents signal manipulation functions that filter signals as

they enter the oscilloscope.  Initially the layered model was appealing since it partitioned the functions of an oscilloscope into well

defined groups.  But, it was a wrong model for the application domain. Because, the problem was that the boundaries of

abstraction enforced by the layers conflicted with the needs for interaction among various functions.

SOLUTION 3: PIPE-AND-FILTER MODEL:  In this approach oscilloscope functions were viewed as incremental transformers of data.

o Signal transformer: to condition external signal. o Acquisition transformer: to derive digitized waveforms o Display transformers: to convert waveforms into visual data.

 It is improvement over layered model as it did not isolate the functions in separate partition.  Main problem with this model is that

o It is not clear how the user should interact with it.

SOLUTION 4: MODIFIED PIPE-AND-FILTER MODEL: To overcome the above said problem, associate control interface with each filter that allowed external entity to set parameters of operation for the filter. Introduction of control interface solves a large part of the user interface problem  It provides collection of setting that determines what aspect of the oscilloscope can be modified

dynamically by the user.  It explains how user can change functions by incremental adjustments to the software.

FURTHER SPECIALIZATION The above described model is greater improvement over the past. But, the main problem with this is the performance. a. Because waveform occupy large amount of internal storage

It is not practical for each filter to copy waveforms every time they process them. b. Different filters run at different speeds


Prepared By: DIVYA K [1RN09IS016] & SHWETHA SHREE [1RN09IS050] Page 24

It is unacceptable to slow one filter down because another filter is still processing its data. To overcome the above discussed problems the model is further specialized. Instead of using same kind of pipe. We use different “colors” of pipe. To allow data to be processed without copying, slow filters to ignore incoming data. These additional pipes increased the stylistic vocabulary and allowed pipe/filter computations to be tailored more specifically to the performance needs of the product.

MOBILE ROBOTICS Mobile Robotic systems

 Controls a manned or semi-manned vehicle o E.g., car, space vehicle, etc

 Used in space exploration missions  Hazardous waste disposal  Underwater exploration

The system is complex  Real Time respond  input from various sensors  Controlling the motion and movement of robots  Planning its future path/move

Unpredictability of environment  Obstacles blocking robot path  Sensor may be imperfect  Power consumption  Respond to hazardous material and situations

DESIGN CONSIDERATIONS REQ1: Supports deliberate and reactive behavior. Robot must coordinate the actions to accomplish its

mission and reactions to unexpected situations  REQ2: Allows uncertainty and unpredictability of environment. The situations are not fully defined

and/or predicable. The design should handle incomplete and unreliable information  REQ3: System must consider possible dangerous operations by Robot and environment  REQ4: The system must give the designer flexibility (mission’s change/requirement changes)

SOLUTION 1: CONTROL LOOP Req1: an advantage of the closed loop paradigm is its simplicity  it captures the basic interaction

between the robot and the outside.  Req2: control loop paradigm is biased towards one method  reducing the unknowns through

iteration  Req3: fault tolerance and safety are supported which makes duplication easy and reduces the chances

of errors  Req4: the major components of a robot architecture are separated from each other and can be replaced



Prepared By: DIVYA K [1RN09IS016] & SHWETHA SHREE [1RN09IS050] Page 25

SOLUTION 2: LAYERED ARCHITECTURE Figure shows Alberto Elfes’s definition of the layered architecture.  Level 1 (core) control routines (motors, joints,..), Level 2-3 real world I/P (sensor interpretation and integration (analysis of combined I/Ps) Level 4 maintains the real world model for robot Level 5 manage navigation Level 6-7 Schedule & plan robot actions (including exception handling and re-planning) Top level deals with UI and overall supervisory functions  Req1: it overcomes the limitations of control loop and it

defines abstraction levels to guide the design  Req2: uncertainty is managed by abstraction layers  Req3: fault tolerance and passive safety are also served  Req4: the interlayer dependencies are an obstacle to easy

replacement and addition of components.

SOLUTION 3: IMPLICIT INVOCATION The third solution is based on the form of implicit invocation, as embodied in the Task-Control-Architecture (TCA). The TCA design is based on hierarchies of tasks or task trees  Parent tasks initiate child task  Temporal dependencies between pairs of tasks can be defined

 A must complete A must complete before B starts (selective concurrency)  Allows dynamic reconfiguration of task tree at run time in response to sudden change(robot and

environment)  Uses implicit invocation to coordinate tasks

 Tasks communicate using multicasting message (message server) to tasks that are registered for these events

TCA’s implicit invocation mechanisms support three functions:  Exceptions: Certain conditions cause the execution of an associated exception handling routines

 i.e., exception override the currently executing task in the sub-tree (e.g., abort or retry) tasks  Wiretapping: Message can be intercepted by tasks superimposed on an existing task tree

 E.g., a safety-check component utilizes this to validate outgoing motion commands  Monitors: Monitors read information and execute some action if the data satisfy certain condition

 E.g. battery check

1-5 of 9
This is only a preview
3 shown on 120 pages
Download the document