SA VTU Qns and Solns Unitwise

Software Architecture 10IS81
VTU QUESTION PAPER SOLUTIONS

UNIT-1
Q1) With the help of neat block diagram of ABC (architecture business cycle). Explain in
detail the different activities which are involved in creating software architecture.
(10 Marks)(Jun 14, Jun 15,Jan 16)
Soln:
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 the environment to t he architecture and
back to the environment, the Architecture Business Cycle (ABC).
Here is how the cycle works:

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 (or otherwise obtained) and integrated to form the s ystem. These units are the basis
for the development project's structure. Teams are formed for individual software units and the
development, test, and integration activities all revolve around the units. Likewise,schedules and
budgets allocate resources in chunks corresponding to the units. If a company becomes adept at
building families of similar systems, it will tend to invest in each team b y nurturing each area of
expertise. Teams become embedded in the organization's structure. This is feedback from the
architecture to the developing organization.
Dept. of CSE, SJBIT Page 1

The various activities involved in creating software architecture are:

Creating the business case for the system
It is an important step in creating and constraining any future requirements.
x How much should the product cost?
x What is its targeted market?
x What is its targeted time to market?
x Will it need to interface with other systems?
x Are there system limitations that it must work within?
x These are all the questions that must involve the system’s architects.
x 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
There are a variety of techniques for eliciting requirements from the stakeholders.For ex:
x Object oriented analysis uses scenarios, or “use cases” to embody requirements.
x Safety-critical systems use more rigorous approaches, such as finite-state-machine

models or formal specification languages.
Another technique that helps us understand requirements is the creation of prototypes.

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
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
x 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.
x 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

x Choosing among multiple competing designs in a rational way is one of the architect’s
greatest challenges.
x Evaluating an architecture for the qualities that it supports is essential to ensuring

that the system constructed from that architecture satisfies its stakeholders needs.

x Use scenario-based techniques or architecture tradeoff analysis method (ATAM) or cost

benefit analysis method (CBAM).
Implementing the system based on the architecture

x This activity is concerned with keeping the developers faithful to the structures and
interaction protocols constrained by the architecture.
x Having an explicit and well-communicated architecture is the first step toward

ensuring architectural conformance.
Ensuring that the implementation conforms to the architecture

x Finally, when an architecture is created and used, it goes into a maintenance phase.
x Constant vigilance is required to ensure that the actual architecture and its
representation remain to each other during this phase.
Q2) Explain the Architecture Business Cycle?(Jan 14,Jan 16)( (10 Marks)
Soln :
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 the environment to t he architecture and
back to the environment, the Architecture Business Cycle (ABC).
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 (or otherwise obtained) and integrated to form the s ystem. These units are the basis
for the development project's structure. Teams are formed for individual software units and the
development, test, and integration activities all revolve around the units. Likewise, schedules and
budgets allocate resources in chunks corresponding to the units. If a company becomes adept at
building families of similar systems, it will tend to invest in each team b y nurturing each area of
expertise. Teams become embedded in the organization's structure. This is feedback from the
architecture to the developing organization.
In the software product line, separate groups were given responsibility for building and
maintaining individual portions of the organization's architecture for a family of products. In any
design undertaken by the organization at large, these groups have a strong voice in the system's
decomposition, pressuring for the continued existence of the portions they control.
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 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.
The architecture can affect customer requirements for the next system by giving the customer the
opportunity to receive a system (based on the same architecture) in a more reliable, timely, and
economical manner than if the subsequent system were to be built from scratch. The customer
may be willing to relax some requirements to gain these economies. Shrink-wrapped software has
clearly affected people's requirements by providing solutions that are not tailored to their precise
needs but are instead inexpensive and (in the best of all possible worlds) of high quality. Product
lines have the same effect on customers who cannot be so flexible with their requirements.
The process of system building will affect the architect's experience with subsequent systems by
adding to the corporate experience base. A system that was successfully built around a tool bus or
.NET or encapsulated finite-state machines will engender similar systems built the same way in
the future. On the other hand, architectures that fail are less likely to be chosen for future projects.
A few systems will influence and actually change the software engineering culture, that is, the
technical environment in which system builders operate and learn. The first relational
databases, compiler generators, and table-driven operating systems had this effect in the 1960s
and early 1970s; the first spreadsheets and windowing systems, in the 1980s. When such
pathfinder systems are constructed, subsequent systems are affected by their legacy.
Q3) Define Software Architecture. Explain the common software Architecture Structures?
(Jan 14, Jun 14,Jan 15)(10 marks)
So l n :
Architectural structures can by and large be divided into three groups, depending on the broad nature of
the elements they show.

x 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?
x 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 so ftware elements to
development teams?
Q4) State and explain the different architectural activities (Jun 14,Jan 15) (10 Marks)
Soln:
x 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.
• 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.
Q5) Define the Software Architecture? Discuss in detail implication of the definition?
(Jun 15, Jan 16)(10 Marks)
Soln:
There are fundamentally three reasons for software architecture’s importance from a technical
perspective.
x 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.
x 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.
x 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:

x 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 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.
x 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.
i)The architecture defines constraints on implementation
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.

ii)The architecture dictates organizational structure

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.
iii)The architecture inhibits or enables a system’s quality attributes
Whether a system will be able to exhibit its desired (or required) quality attributes is substantially
determined by its architecture. However, the architecture alone cannot guarantee functionality or quality.
Decisions at all stages of the life cycle—from high-level design to coding and implementation—affect
system quality. Quality is not completely a function of architectural design. To ensure quality, a good
architecture is necessary, but not sufficient.
iv)Predicting system qualities by studying the architecture
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.
v)The architecture makes it easier to reason about and manage change
Software systems change over their lifetimes. Every architecture partitions possible changes into three
categories: local, nonlocal, and architectural.A local change can be accomplished by modifying a single
element. A nonlocal change requires multiple element modifications but leaves the underlying
architectural approach intact.
vi)The architecture helps in evolutionary prototyping
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. 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
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.
x 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.
i)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.
ii)Systems can be built using large. Externally developed elements
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.
iii)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.
iv)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.
v)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.
Q6) Define Architectural Patterns,reference models and reference architectures and bring out
relationship between them?(Jun 14,Jan 15,Jan 16)(6 Marks)
Soln:
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.
Q7) Explain Model Based Structures?(Jun 14,Jan 16)(4 Marks)

Soln:
Module-based structures include the following structures.
x 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.
x 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.
x Layered: Layers are often designed as abstractions (virtual machines) that hide
implementation specifics below from the layers above, engendering portability.
x Class or generalization: The class structure allows us to reason about re-use and the
incremental addition of functionality.

Q8) Explain various process recommendations as used by architect while developing SA?
(Jun 14,Jan 15)(4 Marks)
Soln:
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.
Q9) Briefly explain,what does Software architecture Constitute?(Jan 14,Jan 15) (5 Marks)
Soln:
Figure 2.1 : Typical, but uninformative, presentation of a software architecture

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 of ten 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.

UNIT 2
Q1) Discuss the Invariants,Advantages and Disadvantages of Pipes and Filters Architectural Style?
(Jun 15,Jan 16) (10 Marks)
Soln:
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.
Advantages:
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. They support reuse: Any two filters can be hooked
together if they agree on data. Systems are easy to maintain and enhance: New filters can be added to
exciting systems. They permit certain kinds of specialized analysis eg: deadlock, throughput They
support concurrent execution.
Disadvantages:
They lead to a batch organization of processing. Filters are independent even though they process data
incrementally. 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.
Q2) What are the Basic Requirements for Mobile Robotics Architecture? How implicit Invocation Model
Handles them?(Jan 14,Jan 15)(8 Marks)
Soln:
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)
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 and
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
Req1: permits clear cut separation of action and reaction

Req2: a tentative task tree can be built to handle uncertainty
Req3: performance, safety and fault tolerance are served
Req4: makes incremental development and replacement of components straight forward
Q3) Explain Process control Paradigms with various process control definitions?
(Jun 14,Jan 15)(6 marks)
Soln:
PROCESS CONTROL PARADIGMS

Process Variables: Properties of process that can be measured.

Controllable vehicle: Process variable whose value of 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.
Q4) Write a Note on Heterogeneous Architecture? (Jun 14/Jan 16)(3 Marks)

Soln:
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
Q5) Enlist different Architetcural styles and discuss in brief Event-based, Implicit Invocation?
(Jun 14/Jan 15)(6 Marks)
Soln:
The Architectural Styles are:Dataflow systems,Call-and-return systems,Independent components,Virtual
machines,Data-centered systems:.
x 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.

Q6) Explain Software Paradigm for process Control?(Jan 14,Jan 15) (4 Marks)
Soln:
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:
x 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
x 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
x The control loop paradigm: establishes the relation that the control algorithm exercises.
Q7) State the problem of KWIC?Propose Abstract datatypes and Implicit Invocation styles to
Implement solution for same?(Jan 14,Jun 15,Jan 16) (10 Marks)
Soln:
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.
SOLUTION 1: 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.

SOLUTION 2: IMPLICIT INVOCATION

Uses a form of component integration based on shared data
Differs from 1st solution by these two factors
Interface to the data is abstract
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.
Q8) Explain Block diagram for Cruise Control?(Jan 14,Jan 15) (4 Marks)
Soln:
A cruise control (CC) system that exists to maintain the constant vehicle speed even over varying terrain.
Inputs: System On/Off: If on, maintain speed Engine On/Off: If on, engine is on. CC is active only in this
state Wheel Pulses: One pulse from every wheel revolution Accelerator: Indication of how far accelerator
is de-pressed Brake: If on, temp revert cruise control to manual mode Inc/Dec Speed: If on,
increase/decrease maintained speed Resume Speed: If on, resume last maintained speed Clock: Timing
pulses every millisecond Outputs: Throttle: Digital value for engine throttle setting

UNIT-III
Q1) what is availability? Explain general scenario for availability? (Jun 14, Jun 15,Jan 16)
(10marks)
Soln:
AVAILABILITY SCENARIO
Availability is concerned with system failure and its associated consequences Failures are usually a result
of system errors that are derived from faults in the system. It is typically defines as .
Source of stimulus. We differentiate between internal and external indications of faults or failure since
the desired system response may be different. In our example, the unexpected message arrives from
outside the system.
Stimulus. A fault of one of the following classes occurs. - omission. A component fails to respond to an
input. - crash. The component repeatedly suffers omission faults. - timing. A component responds but the
response is early or late. - response. A component responds with an incorrect value.
Artifact. This specifies the resource that is required to be highly available, such as a processor,
communication channel, process, or storage.
Environment. The state of the system when the fault or failure occurs may also affect the desired system
response. For example, if the system has already seen some faults and is operating in other than normal
mode, it may be desirable to shut it down totally. However, if this is the first fault observed, some
degradation of response time or function may be preferred. In our example, the system is operating
normally.
Response. There are a number of possible reactions to a system failure. These include logging the failure,
notifying selected users or other systems, switching to a degraded mode with either less capacity or less
function, shutting down external systems, or becoming unavailable during repair. In our example, the
system should notify the operator of the unexpected message and continue to operate normally. Response
measure. The response measure can specify an availability percentage, or it can specify a time to repair,
times during which the system must be available, or the duration for which the system must be available
Q2) What are the qualities of a system?Explain modifiability general scenario?

(Jan 14,Jun 15,Jan 16)(10 marks)
Soln:
It is the ability of the system to do the work for which it was intended.
MODIFIABILITY SCENARIO
Modifiability is about the cost of change. It brings up two concerns.

What can change (the artifact)?

When is the change made and who makes it (the environment)?
Source of stimulus. This portion specifies who makes the changes—the developer, a system
administrator, or an end user. Clearly, there must be machinery in place to allow the system administrator
or end user to modify a system, but this is a common occurrence. In Figure 4.4, the modification is to be
made by the developer.
Stimulus. This portion specifies the changes to be made. A change can be the addition of a function, the
modification of an existing function, or the deletion of a function. It can also be made to the qualities of
the system—making it more responsive, increasing its availability, and so forth. The capacity of the
system may also change. Increasing the number of simultaneous users is a frequent requirement. In our
example, the stimulus is a request to make a modification, which can be to the function, quality, or
capacity.
Artifact. This portion specifies what is to be changed—the functionality of a system, its platform, its user
interface, its environment, or another system with which it interoperates. In Figure 4.4, the modification is
to the user interface.
Environment. This portion specifies when the change can be made—design time, compile time, build
time, initiation time, or runtime. In our example, the modification is to occur at design time. Response.
Whoever makes the change must understand how to make it, and then make it, test it and deploy it. In our
example, the modification is made with no side effects.
Response measure. All of the possible responses take time and cost money, and so time and cost are the
most desirable measures. Time is not always possible to predict, however, and so less ideal measures are
frequently used, such as the extent of the change (number of modules affected). In our example, the time
to perform the modification should be less than three hours.
Q3) what do you mean by Tactics? Explain Availability Tactics with a Neat Diagram?
(Jun 14,Jun 15,Jan 16) (10 Marks)
Soln:
A tactic is a design decision that influences the control of a quality attribute response.
AVAILABILITY TACTICS

The above figure depicts goal of availability tactics. All approaches to maintaining availability involve
some type of redundancy, some type of health monitoring to detect a failure, and some type of recovery
when a failure is detected. In some cases, the monitoring or recovery is automatic and in others it is
manual.
FAULT DETECTION
1.Ping/echo. One component issues a ping and expects to receive back an echo, within a predefined time,
from the component under scrutiny. This can be used within a group of components mutually responsible
for one task
2.Heartbeat (dead man timer). In this case one component emits a heartbeat message periodically and
nother component listens for it. If the heartbeat fails, the originating component is assumed to have failed
and a fault correction component is notified. The heartbeat can also carry data.
3.Exceptions. The exception handler typically executes in the same process that introduced the exception.
FAULT RECOVERY
1.Voting. Processes running on redundant processors each take equivalent input and compute a simple
output value that is sent to a voter. If the voter detects deviant behavior from a single processor, it fails it.
2.Active redundancy (hot restart). All redundant components respond to events in parallel. The
response from only one component is used (usually the first to respond), and the rest are discarded. Active
redundancy is often used in a client/server configuration, such as database management systems, where
quick responses are necessary even when a fault occurs
3.Passive redundancy (warm restart/dual redundancy/triple redundancy). One component (the
primary) responds to events and informs the other components (the standbys) of state updates they must
make. When a fault occurs, the system must first ensure that the backup state is sufficiently fresh before
resuming services.
Spare. A standby spare computing platform is configured to replace many different failed components. It
must be rebooted to the appropriate software configuration and have its state initialized when a failure
occurs.
Shadow operation. A previously failed component may be run in "shadow mode" for a short time to
make sure that it mimics the behavior of the working components before restoring it to service.
State resynchronization. The passive and active redundancy tactics require the component being restored
to have its state upgraded before its return to service.
Checkpoint/rollback. A checkpoint is a recording of a consistent state created either periodically or in
response to specific events. Sometimes a system fails in an unusual manner, with a detectably inconsistent
state. In this case, the system should be restored using a previous checkpoint of a consistent state and a
log of the transactions that occurred since the snapshot was taken.
Q4) Explain the quality attribute general scenario? List the parts of such scenario? Distinguish
between Availability and Modifiability Scenario?(Jan 14,Jan 16) (10 Marks)
Soln:
QUALITY ATTRIBUTE SCENARIOS
A quality attribute scenario is a quality-attribute-specific requirement. It consists of six parts.
1) Source of stimulus. This is some entity (a human, a computer system, or any other
actuator) that generated the stimulus.
2) Stimulus. The stimulus is a condition that needs to be considered when it arrives at a system.

3) Environment. The stimulus occurs within certain conditions. The system may be in an
overload condition or may be running when the stimulus occurs, or some other condition may be true.
4) Artifact. Some artifact is stimulated. This may be the whole system or some pieces of it.
5) Response. The response is the activity undertaken after the arrival of the stimulus.
6) Response measure. When the response occurs, it should be measurable in some fashion so
that the requirement can be tested.
Figure 4.1 shows the parts of a quality attribute scenario.
Availability is concerned with system failure and its associated consequences Failures are usually a result
of system errors that are derived from faults in the system.
It is typically defines as
Source of stimulus. We differentiate between internal and external indications of faults or failure
since the desired system response may be different. In our example, the unexpected message arrives
from outside the system.
Stimulus. A fault of one of the following classes occurs.
- omission. A component fails to respond to an input.
- crash. The component repeatedly suffers omission faults.
- timing. A component responds but the response is early or late.
- response. A component responds with an incorrect value.
Artifact. This specifies the resource that is required to be highly available, such as a processor,
communication channel, process, or storage.
Environment. The state of the system when the fault or failure occurs may also affect the desired
system response. For example, if the system has already seen some faults and is operating in other than
normal mode, it may be desirable to shut it down totally. However, if this is the first fa ult observed,
some degradation of response time or function may be preferred. In our example, the system is operating
normally.
Response. There are a number of possible reactions to a system failure. These include logging the
failure, notifying selected users or other systems, switching to a degraded mode with either less
capacity or less function, shutting down external systems, or becoming unavailable during repair. In

our example, the system should notify the operator of the unexpected message and continue to operate
normally.
Response measure. The response measure can specify an availability percentage, or it can specify a
time to repair, times during which the system must be available, or the duration for which the system
must be available.
MODIFIABILITY SCENARIO
Modifiability is about the cost of change. It brings up two concerns.
♣ What can change (the artifact)?
♣ When is the change made and who makes it (the environment)?
Source of stimulus. This portion specifies who makes the changes—the developer, a system
administrator, or an end user. Clearly, there must be machinery in place to allow the system administrator
or end user to modify a system, but this is a common occurrence. In Figure 4.4, the modification is to be
made by the developer. Stimulus. This portion specifies the changes to be made. A change can be the
addition of a function, the modification of an existing function, or the deletion of a function. It can also be
made to the qualities of the system—making it more responsive, increasing its availability, and so forth.
The capacity of the system may also change. Increasing the number of simultaneous users is a frequent
requirement. In our example, the stimulus is a request to make a modification, which can be to the
function, quality, or capacity.
Artifact. This portion specifies what is to be changed—the functionality of a system, its platform, its user
interface, its environment, or another system with which it interoperates. In Figure 4.4, the modification is
to the user interface.
Environment. This portion specifies when the change can be made—design time, compile time, build
time, initiation time, or runtime. In our example, the modification is to occur at design time.
Response. Whoever makes the change must understand how to make it, and then make it, test it and
deploy it. In our example, the modification is made with no side effects.
Response measure. All of the possible responses take time and cost money, and so time and cost are the
most desirable measures. Time is not always possible to predict, however, and so less ideal measures are
frequently used, such as the extent of the change (number of modules affected). In our example, the time
to perform the modification should be less than three hours.
Q5) What are the qualities that architecture itself should posses?(Jan 14,Jun 15)(6 Marks)
Soln:
Achieving quality attributes must be considered throughout design, implementation, and deployment. No
quality attribute is entirely dependent on design, nor is it entirely dependent on implementation or
deployment. For example: Usability involves both architectural and non-architectural aspects
Modifiability is determined by how functionality is divided (architectural) and by coding techniques

within a module (non-architectural).Performance involves both architectural and non-architectural

dependencies The message of this section is twofold: Architecture is critical to the realization of many
qualities of interest in a system, and these qualities should be designed in and can be evaluated at the
architectural level Architecture, by itself, is unable to achieve qualities. It provides the foundation for
achieving quality.
Q6) List the Parts of Quality Attribute Scenario? (Jan 14,Jan 16)(4 Marks)
Soln:
A quality attribute scenario is a quality-attribute-specific requirement. It consists of six parts.
1) Source of stimulus. This is some entity (a human, a computer system, or any other actuator) that
generated the stimulus.
2) Stimulus. The stimulus is a condition that needs to be considered when it arrives at a system.
3) Environment. The stimulus occurs within certain conditions. The system may be in an overload
condition or may be running when the stimulus occurs, or some other condition may be true.
4) Artifact. Some artifact is stimulated. This may be the whole system or some pieces of it.
5) Response. The response is the activity undertaken after the arrival of the stimulus.
6) Response measure. When the response occurs, it should be measurable in some fashion so that the
requirement can be tested.
Q7) What is the goal of Tactics of Testability? Discuss 2 Categories of Tactics for Testing?
(Jan 14,Jan 15)(10 Marks)
Soln:
The goal of tactics for testability is to allow for easier testing when an increment of software development
is completed.
x INPUT/OUTPUT
Record/playback. Record/playback refers to both capturing information crossing an interface and using
it as input into the test harness. The information crossing an interface during normal operation is saved in
some repository. Recording this information allows test input for one of the components to be generated
and test output for later comparison to be saved.
Separate interface from implementation. Separating the interface from the implementation allows
substitution of implementations for various testing purposes. Stubbing implementations allows the
remainder of the system to be tested in the absence of the component being stubbed.
Specialize access routes/interfaces. Having specialized testing interfaces allows the capturing or
specification of variable values for a component through a test harness as well as independently from its
normal execution. Specialized access routes and interfaces should be kept separate from the access routes
and interfaces for required functionality.
x INTERNAL MONITORING
Built-in monitors. The component can maintain state, performance load, capacity, security, or other
information accessible through an interface. This interface can be a permanent interface of the component
or it can be introduced temporarily. A common technique is to record events when monitoring states have
been activated. Monitoring states can actually increase the testing effort since tests may have to be
repeated with the monitoring turned off. Increased visibility into the activities of the component usually
more than outweigh the cost of the additional testing.

Q8) Classify Secutity Tactics? What are different tactics for resisting attacks?
Soln:
Tactics for achieving security can be divided into those concerned with resisting attacks, those concerned
with detecting attacks, and those concerned with recovering from attacks.
RESISTING ATTACKS
Authenticate users. Authentication is ensuring that a user or remote computer is actually who it purports
to be. Passwords, one-time passwords, digital certificates, and biometric identifications provide
authentication.
Authorize users. Authorization is ensuring that an authenticated user has the rights to access and modify
either data or services. Access control can be by user or by user class.
Maintain data confidentiality. Data should be protected from unauthorized access. Confidentiality is
usually achieved by applying some form of encryption to data and to communication links. Encryption
provides extra protection to persistently maintained data beyond that available from authorization.
Maintain integrity. Data should be delivered as intended. It can have redundant information encoded in it,
such as checksums or hash results, which can be encrypted either along with or independently from the
original data.
Limit exposure. Attacks typically depend on exploiting a single weakness to attack all data and services
on a host. The architect can design the allocation of services to hosts so that limited services are available
on each host.
Limit access. Firewalls restrict access based on message source or destination port. Messages from
unknown sources may be a form of an attack. It is not always possible to limit access to known sources.
Q9) Explain the following with respect to Tactics? (Jun 14,Jan 15)(10 Marks)
i) Fault Prevention ii) Defer Binding Time iii) Resource Arbitration iv)Internal Monitoring v) Run
Time Tactics
Soln:
x FAULT PREVENTION
Removal from service. This tactic removes a component of the system from operation to undergo some
activities to prevent anticipated failures.
Transactions. A transaction is the bundling of several sequential steps such that the entire bundle can be
undone at once. Transactions are used to prevent any data from being affected if one step in a process
fails and also to prevent collisions among several simultaneous threads accessing the same data.

Process monitor. Once a fault in a process has been detected, a monitoring process can delete the
nonperforming process and create a new instance of it, initialized to some appropriate state as in the spare
tactic.
x DEFER BINDING TIME
Many tactics are intended to have impact at loadtime or runtime, such as the following.
Runtime registration supports plug-and-play operation at the cost of additional overhead to manage the
registration.
Configuration files are intended to set parameters at startup.
Polymorphism allows late binding of method calls.
Component replacement allows load time binding.
Adherence to defined protocols allows runtime binding of independent processes.
x RESOURCE ARBITRATION
First-in/First-out. FIFO queues treat all requests for resources as equals and satisfy them in turn.
Fixed-priority scheduling. Fixed-priority scheduling assigns each source of resource requests a
particular priority and assigns the resources in that priority order. Three common prioritization strategies
are semantic importance. Each stream is assigned a priority statically according to some domain
characteristic of the task that generates it,deadline monotonic. Deadline monotonic is a static priority
assignment that assigns higher priority to streams with shorter deadlines,.rate monotonic. Rate monotonic
is a static priority assignment for periodic streams that assigns higher priority to streams with shorter
periods.
Dynamic priority scheduling:
1.round robin. Round robin is a scheduling strategy that orders the requests and then, at every assignment
possibility, assigns the resource to the next request in that order.
2.earliest deadline first. Earliest deadline first assigns priorities based on the pending requests with the
earliest deadline.
Static scheduling. A cyclic executive schedule is a scheduling strategy where the pre-emption points and
the sequence of assignment to the resource are determined offline.
x INTERNAL MONITORING
Built-in monitors. The component can maintain state, performance load, capacity, security, or other
information accessible through an interface. This interface can be a permanent interface of the component
or it can be introduced temporarily. A common technique is to record events when monitoring states have
been activated. Monitoring states can actually increase the testing effort since tests may have to be
repeated with the monitoring turned off. Increased visibility into the activities of the component usually
more than outweigh the cost of the additional testing.
x RUNTIME TACTICS
Maintain a model of the task. In this case, the model maintained is that of the task. The task model is
used to determine context so the system can have some idea of what the user is attempting and provide
various kinds of assistance. For example, knowing that sentences usually start with capital letters would
allow an application to correct a lower-case letter in that position.
Maintain a model of the user. In this case, the model maintained is of the user. It determines the user's
knowledge of the system, the user's behavior in terms of expected response time, and other aspects
specific to a user or a class of users. For example, maintaining a user model allows the system to pace
scrolling so that pages do not fly past faster than they can be read.

Maintain a model of the system. In this case, the model maintained is that of the system. It determines
the expected system behavior so that appropriate feedback can be given to the user. The system model
predicts items such as the time needed to complete current activity.
Q10) Explain Business Qualities?(Jan 14,Jan 16) (4 Marks)

Soln:
1.Time to market.
If there is competitive pressure or a short window of opportunity for a system or product, development
time becomes important. This in turn leads to pressure to buy or otherwise re-use existing elements.
2.Cost and benefit.
The development effort will naturally have a budget that must not be exceeded. Different architectures
will yield different development costs. For instance, an architecture that relies on technology (or expertise
with a technology) not resident in the developing organization will be more expensive to realize than one
that takes advantage of assets already inhouse. An architecture that is highly flexible will typically be
more costly to build than one that is rigid (although it will be less costly to maintain and modify).
3. Projected lifetime of the system.
If the system is intended to have a long lifetime, modifiability, scalability, and portability become
important. On the other hand, a modifiable, extensible product is more likely to survive longer in the
marketplace, extending its lifetime.
4. Targeted market.
For general-purpose (mass-market) software, the platforms on which a system runs as well as its feature
set will determine the size of the potential market. Thus, portability and functionality are key to market
share. Other qualities, such as performance, reliability, and usability also play a role.
5. Rollout schedule.
If a product is to be introduced as base functionality with many features released later, the flexibility and
customizability of the architecture are important. Particularly, the system must be constructed with ease of
expansion and contraction in mind.
Q11) Explain Modifiability Tactics?(Jan 14,Jun 15,Jan 16)(10 Marks)

Soln:
LOCALIZE MODIFICATIONS
Maintain semantic coherence. Semantic coherence refers to the relationships among responsibilities in a
module. The goal is to ensure that all of these responsibilities work together without excessive reliance on
other modules.
Anticipate expected changes. Considering the set of envisioned changes provides a way to evaluate a
particular assignment of responsibilities. In reality this tactic is difficult to use by itself since it is not
possible to anticipate all changes.
Generalize the module. Making a module more general allows it to compute a broader range of
functions based on input
Limit possible options. Modifications, especially within a product line, may be far ranging and hence
affect many modules. Restricting the possible options will reduce the effect of these modifications

Unit-IV
Q1) What do you mean by architectural pattern ? how it is categorized ?Explain the
structure part of the solution for ISO layered architecture.(Jun 14,Jun 15)
Soln:
Architectural patterns express fundamental structural organization schemas for software systems.
They provide a set of predefined subsystems, specify their responsibilities, and include
rules and guidelines for organizing the relationships between them
The layers architectural pattern helps to structure applications that can be decomposed
into groups of subtasks in which each group of subtasks is at a particular level of abstraction.
Example: Networking protocols are best example of layered architectures. Such a protocol
consists of a set of rules and conventions that describes how computer programmer
communicates across machine boundaries. The format, contacts and meaning of all messages
are defined. The protocol specifies agreements at a variety of abstraction levels, ranging from the
details of bit transmission to high level abstraction logic. Therefore the designers use secured sub
protocols and arrange them in layers. Each layer deals with a specific aspect of communication
and users the services of the next lower layer. (see diagram & explain more)
Context: a large system that requires decomposition.
Problem: The system we are building is divided by mix of low and high level issues,
where high-level operations rely on the lower-level ones. for ex, high-level will be interactive to user
and low-level will be concerned with hardware implementation
In such a case, we need to balance the following forces:

x Late source code changes should not ripple through the systems. They should be
confined to one component and not affect others.
x Interfaces should be stable, and may even be impressed by a standards body.
x Parts of the system should be exchangeable (i.e, a particular layer can be changed).
x It may be necessary to build other systems at a later date with the same low-level issues
as the system you are currently designing.
x Similar responsibilities should be grouped to help understandability and maintainability.
x There is no ‘standard’ component granularity.
x Complex components need further decomposition.

x Crossing component boundaries may impede performance, for example when a

substantial amount of data must be transferred over several boundaries.
x The system will be built by a team of programmers, and works has to be

subdivided along clear boundaries.
x Structure your system into an appropriate number of layers and place them on top of each
other.
x Lowest layer is called 1 (base of our system), the highest is called layer N. i.e, Layer 1,
……. Layer J-1,
x Layer J, ….. Layer N.
x Most of the services that layer J Provides are composed of services provided by
layer J-1. In other words, the services of each layer implement a strategy for combining
the services of the layer below in a meaningful way. In addition, layer J’s services may
depend on other services in layer J.
Structure:
x An individual layer can be described by the following CRC card:
o
The main structural characteristics of the layers patterns is that services of layer J are only use by
layer J+1-there are no further direct dependencies between layers. This structure can be
compared with a stack, or even an onion. Each individual layer shields all lower from direct
access by higher layers.

Dynamics:
x Scenario I is probably the best-known one. A client Issues a request to Layer N. Since
Layer N cannot carry out the request on its own. It calls the next Layer N - 1 for
supporting subtasks. Layer N - I provides these. In the process sending further requests
to Layer N-2 and so on until Layer I is reached. Here, the lowest-level services are finally
performed. If necessary, replies to the different requests are passed back up from Layer 1
to Layer 2, from Layer 2 to Layer 3, and so on until the final reply arrives at Layer N.
x Scenario II illustrates bottom-up communication-a chain of actions starts at Layer 1,

for example when a device driver detects input. The driver translates the input into an
internal format and reports it to Layer 2 which starts interpreting it, and so on. In this way
data moves up through the layers until it arrives at the highest layer. While top-down
information and control flow are often described as 'requests'. Bottom-up calls can be
termed 'notifications'.
x Scenario III describes the situation where requests only travel through a subset of the
layers. A top level request may only go to the next lower level N- 1 if this level can satisfy
the request. An example of this is where level N- 1 acts as a cache and a request from level
N can be satisfied without being sent all the way down to Layer 1 and from here to a
remote server.
x Scenario IV An event is detected in Layer 1, but stops at Layer 3 instead of travelling all
the way up to Layer N. In a communication protocol, for example, a resend request
may arrive from an impatient client who requested data some time ago. In the meantime
the server has already sent the answer, and the answer and the re-send request cross. In this
case, Layer 3 of the server side may notice this and intercept the re-send request without
further action.
x Scenario V involves two stacks of N layers communicating with each other. This scenario
is well-known from communication protocols where the stacks are known as
'protocol stacks'. In the following diagram, Layer N of the left stack issues a request.
'The request moves down through the layers until it reaches Layer 1, is sent to Layer 1 of
the right stack, and there moves up through the layers of the right stack. The response to
the request follows the reverse path until it arrives at Layer N of the left stack.

Implementation:
The following steps describe a step-wise refinement approach to the definition of a layered
architecture. Define the abstraction criterion for grouping tasks into layers.
o This criterion is often the conceptual distance from the platform (sometimes, we encounter
other abstraction paradigm as well).
o In the real world of software development we often use a mix of abstraction criterions. For ex,
the distance from the hardware can shape the lower levels, and conceptual complexity
governs the higher ones.
o Example layering obtained using mixed model layering principle is shown below User-
visible elements
x Specific application modules
x Common services level
x Operating system interface level
x Operating system
x Hardware
Determine the number of abstraction levels according to your abstraction criterion.
x Each abstraction level corresponds to one layer of the pattern.
x Having too many layers may impose unnecessary overhead, while too few layers
can result in a poor structure.
Name the layers and assign the tasks to each of them.
x The task of the highest layer is the overall system task, as perceived by the client.
x The tasks of all other layers are to be helpers to higher layers.
Specify the services
x It is often better to locate more services in higher layers than in lower layers.
x The base layers should be kept ‘slim’ while higher layers can expand to cover a
spectrum of applicability.
x This phenomenon is also called the ‘inverted pyramid of reuse’.
Refine the layering
x Iterate over steps 1 to 4.
x It is not possible to define an abstraction criterion precisely before thinking about
the implied layers and their services.
x Alternatively it is wrong to define components and services first and later impose
a layered structure.
x The solution is to perform the first four steps several times until a natural and
stable layering evolves.
Specify an interface for each layer.
x If layer J should be a ‘black box’ for layer J+1, design a flat interface that offers all layer
J’s services.
x ‘White box’ approach is that in which, layer J+1 sees the internals of layer J.

x ‘Gray box’ approach is a compromise between black and white box approaches.
Here layer J+1 is aware of the fact that layer J consists of three components, and
address them separately, but does not see the internal workings of individual components.
Structure individual layers
x When an individual layer is complex, it should be broken into separate components.
x This subdivision can be helped by using finer-grained patterns.
Specify the communication between adjacent layers.
x Push model (most often used): when layer J invokes a service of layer J+1, any required
information is passed as part of the service call.
x Pull model: it is the reverse of the push model. It occurs when the lower layer
fetches available information from the higher layer at its own discretion.
Decouple adjacent layers.
x For top-down communication, where requests travel top-down, we can use one-way
coupling (i.e, upper layer is aware of the next lower layer, but the lower layer is unaware
of the identity of its users) here return values are sufficient to transport the results in the
reverse direction.
x For bottom-up communication, you can use callbacks and still preserve a top-
down one way coupling. Here the upper layer registers callback functions with the lower
layer.
x We can also decouple the upper layer from the lower layer to a certain degree using
object oriented techniques.
Design an error handling strategy
x An error can either be handled in the layer where it occurred or be passed to the next
higher layer.
x As a rule of thumb, try to handle the errors at the lowest layer possible.
Q2) List the Components of Pipes and Filters Architectural Pattern?With Sketch explain CRC
Card for the same?(Jan 14,Jun 14)(8 Marks)
Soln:
The componenets of Pipes and Filters are:
1.Filter Component
2.Pipe Component
3.Data Source
4.Data Sink
1.Filter component:
Filter components are the processing units of the pipeline. A filter enriches, refines or transforms its input
data. It enriches data by computing and adding information, refines data by concentrating or extracting
information, and transforms data by delivering the data in some other representation. It is responsible for
the following activities:
The subsequent pipeline element pulls output data from the filter. (passive filter)

2. Pipe component:
x Pipes denote the connection between filters, between the data source and the first filter, and between
the last filter and the data sink.
x If two active components are joined, the pipe synchronizes them.
x This synchronization is done with a first-in- first-out buffer.
3. Data source component:

x The data source represents the input to the system, and provides a sequence of data values of the same
structure or type.
x It is responsible for delivering input to the processing pipeline.
4.Data sink component:

x The data sink collects the result from the end of the pipeline (i.e, it consumes output).
x Two variants of data sink:
x An active data sink pulls results out of the preceding processing stage.
x An passive data sink allows the preceding filter to push or write the results into it.

Q3) Explain the forces that influence the solution to problems based on black board pattern?
(Jan 14,Jun 15,Jan 16)(7 Marks)
Soln:
The following forces influence solutions to problems of this kind:
A complete search of the solution space is not feasible in a reasonable time.Since the domain is immature,
we may need to experiment with different algorithms for the same subtask. Hence, individual modules
should be easily exchangeable.
There are different algorithms that solve partial problems.

Input as well as intermediate and final results, have different representation, and the algorithms are
implemented according to different paradigms. An algorithm usually works on the results of other
algorithms. Uncertain data and approximate solutions are involved. Employing dis fact algorithms
induces potential parallelism.
Q4) Write a note on HEARSEY-II System?(Jun 14,Jun 15)(5 Marks)

Soln:
HEARSAY-II --The first Blackboard system was the HEARSAY-II speech recognition system from the
early 1970's. It was developed as a natural language interface to a literature database. Its task was to
answer queries about documents and to retrieve documents from a collection of abstracts of Artificial
Intelligence publications. The inputs to the system were acoustic signals that were semantically
interpreted and then transformed to a database query. The control component of HEARSAY-I1 consists
of the following:
x The focus of control database, which contains a table of primitive change types of blackboard changes,
and those condition-parts that can be executed for each change type.
x The scheduling queue, which contains pointers to condition- or action-parts of knowledge source.
x The monitor, which keeps track of each change made to the blackboard.
x The scheduler, which uses experimentally-derived heuristics to calculate priorities for the condition-
and action- parts waiting in the scheduling queue.
Q4) Discuss the steps involved in implementation of pipes of filters architecture?(Jan 15)(12 Marks)
Soln:
Implementation:
x Divide the system’s tasks into a sequence of processing stages.
Each stage must depend only on the output of its direct predecessor.
All stages are conceptually connected by the data flow.
x Define the data format to be passed along each pipe.
Defining a uniform format results in the highest flexibility because it makes recombination of its filters
easy.
You must also define how the end of input is marked.
x Decide how to implement each pipe connection.
This decision directly determines whether you implement the filters as active or passive components.
Adjacent pipes further define whether a passive filter is triggered by push or pull of data.
x Design and implement the filters.

Design of a filter component is based both on the task it must perform and on the adjacent pipes.
You can implement passive filters as a function, for pull activation, or as a procedure for push activation.
Active filters can be implemented either as processes or as threads in the pipeline program.
x Design the error handling.
Because the pipeline components do not share any global state, error handling is hard to address and is
often neglected. As a minimum, error detection should be possible. UNIX defines specific output
channel for error messages, standard error. If a filter detects error in its input data, it can ignore input
until some clearly marked separation occurs. It is hard to give a general strategy for error handling
with a system based on the pipes and filter pattern.
x Set up the processing pipeline.
If your system handles a single task you can use a standardized main program that sets up the pipeline and
starts processing. You can increase the flexibility by providing a shell or other end-user facility to set
up various pipelines from your set of filter components.
Q5) Explain layers architectures Pattern,with sketches and CRC cards? (Jan 15,Jun 15)(6 Marks)
Soln:
Structure your system into an appropriate number of layers and place them on top of each other. Lowest
layer is called 1 (base of our system), the highest is called layer N. i.e, Layer 1, ……. Layer J-1, Layer J,
….. Layer N. Most of the services that layer J Provides are composed of services provided by layer J-1. In
other words, the services of each layer implement a strategy for combining the services of the layer below
in a meaningful way. In addition, layer J’s services may depend on other services in layer J.
Structure:
An individual layer can be described by the following CRC card:
The main structural characteristics of the layers patterns is that services of layer J are only use by layer
J+1-there are no further direct dependencies between layers. This structure can be compared with a stack,
or even an onion. Each individual layer shields all lower from direct access by higher layers.
Overall Architecture Looks Something Like this:

Q6) Explain implementation steps of Layered Pattern?(Jan 14)(10 Marks)

Soln:
The following steps describe a step-wise refinement approach to the definition of a layered architecture.
x Define the abstraction criterion for grouping tasks into layers.
This criterion is often the conceptual distance from the platform (sometimes, we encounter other
abstraction paradigm as well). In the real world of software development we often use a mix of
abstraction criterions. For ex, the distance from the hardware can shape the lower levels, and
conceptual complexity governs the higher ones.
Example layering obtained using mixed model layering principle is shown below User-visible elements
x Specific application modules
x Common services level
x Operating system interface level
x Operating system
x Hardware
x Determine the number of abstraction levels according to your abstraction criterion.
Each abstraction level corresponds to one layer of the pattern. Having too many layers may impose
unnecessary overhead, while too few layers can result in a poor structure.
x Name the layers and assign the tasks to each of them.
The task of the highest layer is the overall system task, as perceived by the client. The tasks of all other
layers are to be helpers to higher layers.
x Specify the services
It is often better to locate more services in higher layers than in lower layers. The base layers should be
kept ‘slim’ while higher layers can expand to cover a spectrum of applicability. This phenomenon is
also called the ‘inverted pyramid of reuse’.
x Refine the layering
Iterate over steps 1 to 4.
It is not possible to define an abstraction criterion precisely before thinking about the implied layers and
their services.
Alternatively it is wrong to define components and services first and later impose a layered structure.
The solution is to perform the first four steps several times until a natural and stable layering evolves.
x Specify an interface for each layer.
If layer J should be a ‘black box’ for layer J+1, design a flat interface that offers all layer J’s services.
‘White box’ approach is that in which, layer J+1 sees the internals of layer J.
‘Gray box’ approach is a compromise between black and white box approaches. Here layer J+1 is aware
of the fact that layer J consists of three components, and address them separately, but does not see the
internal workings of individual components.
x Structure individual layers
When an individual layer is complex, it should be broken into separate components.
This subdivision can be helped by using finer-grained patterns.
x Specify the communication between adjacent layers.
Push model (most often used): when layer J invokes a service of layer J+1, any required information is
passed as part of the service call.

Pull model: it is the reverse of the push model. It occurs when the lower layer fetches available
information from the higher layer at its own discretion.
x Decouple adjacent layers.
For top-down communication, where requests travel top-down, we can use one-way coupling (i.e, upper
layer is aware of the next lower layer, but the lower layer is unaware of the identity of its users) here
return values are sufficient to transport the results in the reverse direction.
Q7) Explain Benefits and Liabilities of Pipes and filter pattern?(Jan14)(6 Marks)
Soln:
The Pipes and Filters architectural pattern has the following benefits
x No intermediate files necessary, but possible.
Computing results using separate programs is possible without pipes, by storing intermediate results in
pipes.
x Flexibility by the filter change
Filters have simple interface that allows their easy exchange within a processing pipeline.
x Flexibility by recombination
This benefit combined with reusability of filter component allows you to create new processing pipelines
by rearranging filters or by adding new ones.
x Reuse of filter components.
Support for recombination leads to easy reuse of filter components.
x Rapid prototyping of pipelines.
Easy to prototype a data processing system from existing filters.
x Efficiency by parallel processing.
It is possible to start active filter components in parallel in a multiprocessor system or a network.
The Pipes and Filters architectural pattern has the following Liabilities
x Sharing state information is expensive or inflexible
This pattern is inefficient if your processing stage needs to share a large amount of global data.
x Efficiency gain by parallel processing is often an illusion, because:
The cost for transferring data between filters is relatively high compared to the cost of the computation
carried out by a single filter.Some filter consumes all their input before producing any output. Context-
switching between threads or processes is expensive on a single processor machine. Synchronization
of filters via pipes may start and stop filters often.
x Data transformation overhead
Using a single data type for all filter input and output to achieve highest flexibility results in data
conversion overheads.
x Error handling
Is difficult. A concrete error-recovery or error-handling strategy depends on the task you need to solve.
Q8) What are the known uses of Black Board Pattern?(Jan 14,Jan 16)(4 marks)
Soln:
Known uses:
HEARSAY-II The first Blackboard system was the HEARSAY-II speech recognition system from the
early 1970's. It was developed as a natural language interface to a literature database. Its task was to
answer queries about documents and to retrieve documents from a collection of abstracts of Artificial

Intelligence publications. The inputs to the system were acoustic signals that were semantically
interpreted and then transformed to a database query. The control component of HEARSAY-I1 consists
of the following:
The focus of control database, which contains a table of primitive change types of blackboard changes,
and those condition-parts that can be executed for each change type.
x The scheduling queue, which contains pointers to condition- or action-parts of knowledge source.
x The monitor, which keeps track of each change made to the blackboard.
x The scheduler, which uses experimentally-derived heuristics to calculate priorities for the condition-
and action- parts waiting in the scheduling queue.
HASP/SIAP
CRYSALIS
TRICERO
SUS
Q9) Illustrate the behavior of the black board architecture based on Speech recognition and list the
steps to implement black board pattern?(Jun 14,Jun 15)(10 marks)
Soln:
Implementation:
x Define the problem
Specify the domain of the problem
Scrutinize the input to the system
Define the o/p of the system
Detail how the user interacts with the system.
x Define the solution space for the problem
Specify exactly what constitutes a top level solution
List the different abstraction levels of solutions
Organize solutions into one or more abstraction hierarchy.
Find subdivisions of complete solutions that can be worked on independently.
x Divide the solution process into steps.
Define how solutions are transformed into higher level solutions.
Describe how to predict hypothesis at the same abstraction levels.
Detail how to verify predicted hypothesis by finding support for them in other levels.
Specify the kind of knowledge that can be uses to exclude parts of the solution space.
x Divide the knowledge into specialized knowledge
These subtasks often correspond to areas of specialization.
x Define the vocabulary of the blackboard
Elaborate your first definition of the solution space and the abstraction levels of your solution.
Find a representation for solutions that allows all knowledge sources to read from and contribute to the
blackboard.
The vocabulary of the blackboard cannot be defined of knowledge sources and the control component.
x Specify the control of the system.
Control component implements an opportunistic problem-solving strategy that determines which
knowledge sources are allowed to make changes to the blackboard.The aim of this strategy is to construct
a hypothesis that is acceptable as a result. The following mechanisms optimizes the evaluation of

knowledge sources, and so increase the effectiveness and performance of control strategy. Classifying
changes to the blackboard into two types. One type specify all blackboard change that may imply new set
of applicable knowledge sources, and the other specifies all blackboard changes that do not. Associating
categories of blackboard changes with sets of possibly applicable knowledge sources. Focusing of
control. The focus contains either partial results on the blackboard or knowledge sources that should be
preferred over others. Creating on queue in which knowledge sources classified as applicable wait for
their execution.
x Implement the knowledge sources
Split the knowledge sources into condition parts and action-parts according to the needs of the control
component. We can implement different knowledge sources in the same system using different
technologies

Unit-V
Q1) What do you mean by broker architecture?What are the steps involved in implementing
distributed broker architecture patterns?(Jun 14,Jun 15) (10 Marks)
Soln:
The broker architectural pattern can be used to structure distributed software systems with decoupled
components that interact by remote service invocations. A broker component is responsible for
coordinating communication, such as requests, as well as for transmitting results and exceptions.
Implementation:
1) Define an object existing model, or use an existing model.
Each object model must specify entities such as object names, requests, objects, values, exceptions,
supported types, interfaces and operations.
2) Decide which kind of component-interoperability the system should offer.
You can design for interoperability either by specifying a binary standard or by introducing a high-level
IDL.
IDL file contains a textual description of the interfaces a server offers to its clients.
The binary approach needs support from your programming language.
3) Specify the API’S the broker component provides for collaborating with clients and servers.
Decide whether clients should only be able to invoke server operations statically, allowing clients to bind
the invocations at complete time, or you want to allow dynamic invocations of servers as well.
This has a direct impact on size and no. of API’S.
4) Use proxy objects to hide implementation details from clients and servers.
Client side proxies package procedure calls into message and forward these messages to the local broker
component.
Server side proxies receive requests from the local broker and call the methods in the interface
implementation of the corresponding server.
5) Design the broker component in parallel with steps 3 and 4
During design and implementations, iterate systematically through the following steps
5.1 Specify a detailed on-the-wire protocol for interacting with client side and server side proxies.
5.2 A local broker must be available for every participating machine in the network.
5.3 When a client invokes a method of a server the broker system is responsible for returning all results
and exceptions back to the original client.
5.4 If the provides do not provide mechanisms for marshalling and un marshalling parameters results, you
must include functionality in the broker component.
5.5 If your system supports asynchronous communication b/w clients and servers, you need to provide
message buffers within the broker or within the proxies for temporary storage of messages.
5.6 Include a directory service for associating local server identifiers with the physical location of the
corresponding servers in the broker.
5.7 When your architecture requires system-unique identifiers to be generated dynamically during server
registration, the broker must offer a name service for instantiating such names.
5.8 If your system supports dynamic method invocation the broker needs some means for maintaining
type information about existing servers.

5.9 Plan the broker’s action when the communication with clients, other brokers, or servers fails.
6) Develop IDL compliers
An IDL compiler translates the server interface definitions to programming language code. When many
programming languages are in use, it is best to develop the compiler as afrarnework that allows the
developer to add his own code generators.
Q2)Explain with neat diagram, dynamic scenario of MVC?(Jun 15,Jan 16) (10 Marks)
Soln:
Dynamics: The following scenarios depict the dynamic behavior of MVC. For simplicity only one view-
controller pair is shown in the diagrams.
Scenario I shows how user input that results in changes to the model triggers the change-propagation
mechanism:
The controller accepts user input in its event-handling procedure, interprets the event, and activates a
service procedure of the model.
The model performs the requested service. This results in a change to its internal data.
The model notifies all views and controllers registered with the change-propagation mechanism of the
change by calling their update procedures.
Each view requests the changed data from the model and redisplays itself on the screen.
Each registered controller retrieves data from the model to enable or disable certain user functions..
The original controller regains control and returns from its event handling procedure.
Scenario II shows how the MVC triad is initialized. The following steps occur:
The model instance is created, which then initializes its internal data structures.
A view object is created. This takes a reference to the model as a parameter for its initialization.
The view subscribes to the change-propagation mechanism of the model by calling the attach procedure.
The view continues initialization by creating its controller. It passes references both to the model and to
itself to the controller's initialization procedure.
The controller also subscribes to the change-propagation mechanism by calling the attach procedure.
After initialization, the application begins to process events.

Q3) explain MVC pattern?(Jan 14)(10marks)

Soln:
MVC architectural pattern divides an interactive application into three components.
The model contains the core functionality and data.
Views display information to the user.
Controllers handle user input.
Views and controllers together comprise the user interface.
A change propagation mechanism ensures consistence between the user interface and the model.
Consider a simple information system for political elections with proportional representation. This offers
a spreadsheet for entering data and several kinds of tables and charts for presenting the current results.
Users can interact with the system via a graphical interface. All information displays must reflect changes
to the voting data immediately.
Context: Interactive applications with a flexible human-computer interface
Problem: Different users place conflicting requirements on the user interface. A typist enters information
into forms via the keyboard. A manager wants to use the same system mainly by clicking icons and
buttons. Consequently, support for several user interface paradigms should be easily incorporated. How
do you modularize the user interface functionality of a web application so that you can easily modify the
individual parts? The following forces influence the solution:
Same information is presented differently in different windows. For ex: In a bar or pie chart. The display
and behavior of the application must reflect data manipulations immediately. Changes to the user

interface should be easy, and even possible at run-time. Supporting different ‘look and feel’ standards or
porting the user interface should not affect code in the core of the application.
MVC divides an interactive application into the three areas: processing, output and input.
Model component encapsulates core data and functionality and is independent of o/p and i/p.
View components display user information to user a view obtains the data from the model. There can be
multiple views of the model.
Each view has an associated controller component controllers receive input (usually as mouse events)
events are translated to service requests for the model or the view. The user interacts with the system
solely through controllers.
The separation of the model from view and controller components allows multiple views of the same
model.
Structure:
x Model component:
Contains the functional core of the application.
Registers dependent views and controllers
Notifies dependent components about data changes (change propagation mechanism)
x View component:
Presents information to the user
Retrieves data from the model
Creates and initializes its associated controller
Implements the update procedure
x Controller component:
Accepts user input as events (mouse event, keyboard event etc)
Translates events to service requests for the model or display requests for the view.
An object-oriented implementation of MVC would define a separate class for each component. In a C++
implementation, view and controller classes share a common parent that defines the update interface. This
is shown in the following diagram.

Dynamics: The following scenarios depict the dynamic behavior of MVC. For simplicity only one view-
controller pair is shown in the diagrams.
Scenario I shows how user input that results in changes to the model triggers the change-propagation
mechanism:
The controller accepts user input in its event-handling procedure, interprets the event, and activates a
service procedure of the model.
The model performs the requested service. This results in a change to its internal data.
The model notifies all views and controllers registered with the change-propagation mechanism of the
change by calling their update procedures.
Each view requests the changed data from the model and redisplays itself on the screen.
Each registered controller retrieves data from the model to enable or disable certain user functions..
The original controller regains control and returns from its event handling procedure.
Scenario II shows how the MVC triad is initialized. The following steps occur:
The model instance is created, which then initializes its internal data structures,A view object is created.
This takes a reference to the model as a parameter for its initialization,The view subscribes to the
change-propagation mechanism of the model by calling the attach procedure,The view continues
initialization by creating its controller. It passes references both to the model and to itself to the
controller's initialization procedure.
The controller also subscribes to the change-propagation mechanism by calling the attach procedure.
After initialization, the application begins to process events.

Implementation:
1) Separate human-computer interaction from core functionality
Analysis the application domain and separate core functionality from the desired input and output
behavior
2) Implement the change-propagation mechanism
Follow the publisher subscriber design pattern for this, and assign the role of the publisher to the model.
3) Design and implement the views
design the appearance of each view and Implement all the procedures associated with views.
4) Design and implement the controllers
For each view of application, specify the behavior of the system in response to user actions.
We assume that the underlying pattern delivers every action of and user as an event. A controller receives
and interprets these events using a dedicated procedure.
5) Design and implement the view controller relationship.
A view typically creates its associated controller during its initialization.
6) Implement the setup of MVC.
The setup code first initializes the model, then creates and initializes the views.
After initialization, event processing is started.
Because the model should remain independent of specific views and controllers, this set up code should
be placed externally.
7) Dynamic view creation
If the application allows dynamic opening and closing of views, it is a good idea to provide a component
for managing open views.
8) ‘pluggable’ controllers
The separation of control aspects from views supports the combination of different controllers with a
view.
This flexibility can be used to implement different modes of operation.
9) Infrastructure for hierarchical views and controllers
Apply the composite pattern to create hierarchically composed views.
If multiple views are active simultaneously, several controllers may be interested in events at the same
time.
Q4) Discuss the most common scenario illustrating dynamic behavior of Broker system?
(Jun 15,Jan 16)(10 Marks)
Soln:
Scenario 1. illustrates the behaviour when a server registers itself with the local broker component:

Scenario II illustrates the behaviour when a client sends a request to a local server. In this scenario we
describe a synchronous invocation, in which the client blocks until it gets a response from the server. The
broker may also support asynchronous invocations, allowing clients to execute further tasks without
having to wait for a response.
Q5) Discuss the Consequences of Presentation abstraction control architectural pattern?

(Jun 14,Jan 15)( (10 Marks)
Soln:
Consequences:
Benefits:-
separation of concerns
o Different semantic concepts in the application domain are represented by separate agents.
Support for change and extension
o Changes within the presentation or abstraction components of a PAC agent do not affect other agents in
the system.
Support for multi tasking
o PAC agents can be distributed easily to different threads, processes or machines.
o Multi tasking also facilitates multi user applications.
Liabilities:
Increased system complexity
Implementation of every semantic concept within an application as its own PAC agent may result in a
complex system structure.
Complex control component
Individual roles of control components should be strongly separated from each other. The
implementations of these roles should not depend on specific details of other agents.
The interface of control components should be independent of internal details.
It is the responsibility of the control component to perform any necessary interface and data adaptation.
Efficiency:
Overhead in communication between PAC agents may impact system efficiency.
Example: All intermediate-level agents are involved in data exchange. if a bottom-level agent retrieve
data from top-level agent.

The smaller the atomic semantic concepts of an applications are, and the greater the similarly of their user
interfaces, the less applicable this pattern is.
Q6) What are known uses of PAC?(Jan 14,Jan 16)

Soln:
Known uses:
Network traffic management
Gathering traffic data from switching units.
Threshold checking and generation of overflow exceptions.
Logging and routing of network exceptions.
Visualization of traffic flow and network exceptions.
Displaying various user-configurable views of the whole network.
Statistical evaluations of traffic data.
Access to historic traffic data.
System administration and configuration.
Mobile robot

Provide the robot with a description of the environment it will work in, places in this environment, and
routes between places.
Subsequently modify the environment.
Specify missions for the robot.
Control the execution of missions.
Observe the progress of missions.

UNIT-VI
Q1) State and explain the properties of reflection pattern .(Jan 14,Jun 15,Jan 16)(10marks)
Soln:
The reflection architectural pattern provides a mechanism for changing structure and behavior of software
systems dynamically. It supports the modification of fundamental aspects, such as the type structures and
function call mechanisms. In this pattern, an application is split into two parts:
A Meta level provides information about selected system properties and makes the s/w self aware.
A base level includes application logic changes to information kept in the Meta level affect subsequent
base-level behavior.
Context: Building systems that support their own modification a prior
Problem:Designing a system that meets a wide range of different requirements a prior can be an
overwhelming task.
A better solution is to specify an architecture that is open to modification and extension i.e., we have to
design for change and evolution.
Several forces are associated with the problem: Changing software is tedious, error prone and often
expensive. Adaptable software systems usually have a complex inner structure. Aspects that are subject to
change are encapsulated within separate components.The more techniques that are necessary for keep in a
system changeable the more awkward and complex its modifications becomes Changes can be of any
scale, from providing shortcuts for commonly used commands to adapting an application framework for a
specific customer. Even fundamental aspects of software systems can change for ex. communication
mechanisms b/w components. Make the software self-aware, and make select aspects of its structure
and behavior accessible for adaptation and change.
This leads to an architecture that is split into two major parts:

A Meta level
A base level
Meta level provides a self representation of the s/w to give it knowledge of its own structure and behavior
and consists of so called Meta objects (they encapsulate and represent information about the software).
Ex: type structures algorithms or function call mechanisms.
Base level defines the application logic. Its implementation uses the Meta objects to remain independent
of those aspects that are likely to change.
An interface is specified for manipulating the Meta objects. It is called the Meta object protocol (MOP)
and allows clients to specify particular changes.
Structure:
1.Meta level
2.Meta objects protocol(MOP)
3.Base level
1.Meta level
Meta level consists of a set of Meta objects. Each Meta object encapsulates selected information about a
single aspect of a structure, behavior, or state of the base level.
There are three sources for such information.
It can be provided by run time environment of the system, such as C++ type identification objects.

It can be user defined such as function call mechanism

It can be retrieved from the base level at run time.
All Meta objects together provide a self representation of an application.
What you represent with Meta objects depends on what should be adaptable only system details that are
likely to change r which vary from customer to customer should be encapsulated by Meta objects.
The interface of a Meta objects allows the base level to access the information it maintains or the services
it offers.
2.Base level
It models and implements the application logic of the software. Its component represents the various
services the system offers as well as their underlying data model.
It uses the info and services provided by the Meta objects such as location information about components
and function call mechanisms. This allows the base level to remain flexible.
Base level components are either directly connected to the Meta objects and which they depend or submit
requests to them through special retrieval functions.
3.Meta object protocol (MOP)
Serves an external interface to the Meta level, and makes the implementation of a reflective system
accessible in a defined way.
Clients of the MOP can specify modifications to Meta objects or their relationships using the base level
MOP itself is responsible for performing these changes. This provides a reflective application with
explicit control over its own modification.
Meta object protocol is usually designed as a separate component. This supports the implementation of
functions that operate on several Meta objects.
To perform changes, the MOP needs access to the internals of Meta objects, and also to base level
components (sometimes).
One way of providing this access is to allow the MOP to directly operate on their internal states. Another
way (safer, inefficient) is to provide special interface for their manipulation, only accessible by MOP.

The general structure of a reflective architecture is very much like a Layered system
Implementation: Iterate through any subsequence if necessary.

1. Define a model of the application
Analyze the problem domain and decompose it into an appropriate s/w structure.
2. Identify varying behavior
Analyze the developed model and determine which of the application services may vary and which
remain stable.
Following are ex: of system aspects that often vary
Real time constraints
Transaction protocols
Inter Process Communication mechanism
Behavior in case of exceptions
Algorithm for application services.
3. Identify structural aspects of the system, which when changed, should not affect the implementation
of the base level.
4. Identify system services that support both the variation of application services identified
In step 2 and the independence of structural details identified in step 3 Eg: for system services are
Resource allocation
Garbage allocation
Page swapping
Object creation.
5. Define the meta objects
For every aspect identified in 3 previous steps, define appropriate Meta objects.
Encapsulating behavior is supported by several domain independent design patterns, such as objectifier
strategy, bridge, visitor and abstract factory.
6. Define the MOP
There are two options for implementing the MOP.
Integrate it with Meta objects. Every Meta object provides those functions of the MOP that operate on it.
Implement the MOP as a separate component.
Robustness is a major concern when implementing the MOP. Errors in change specifications should be
detected wherever possible.
7. Define the base level

Implement the functional core and user interface of the system according to the analysis model developed
in step 1.
Use Meta objects to keep the base level extensible and adaptable. Connect every base level component
with Meta objects that provide system information on which they depend, such as type information etc.
Provide base level components with functions for maintaining the relationships with their associated Meta
objects. The MOP must be able to modify every relationship b/w base level and Meta level.
Q2) What are the steps involved in implementing micro kernel system?
(Jan 14,Jun 15,Jan 16)(12 Marks)
Soln:
Implementation:
1. Analyze the application domain:
Perform a domain analysis and identify the core functionality necessary for implementing ext servers.
2. Analyze external servers
That is polices ext servers are going to provide
3. Categorize the services
Group all functionality into semantically independent categories.
4. Partition the categories
Separate the categories into services that should be part of the microkernel, and those that should be
available as internal servers.
5. Find a consistent and complete set of operations and abstractions
for every category you identified in step 1.
6. Determine the strategies for request transmission and retrieval.
Specify the facilities the microkernel should provide for communication b/w components.
Communication strategies you integrate depend on the requirements of the application domain.
7. Structure the microkernel component
Design the microkernel using the layers pattern to separate system-specific parts from system-
independent parts of the kernel.
8. Specify the programming interfaces of microkernel
To do so, you need to decide how these interfaces should be accessible externally. You must take into an
account whether the microkernel is implemented as a separate process or as a module that is physically
shared by other component in the latter case, you can use conventional method calls to invoke the
methods of the microkernel. 9. The microkernel is responsible for managing all system resources such
as memory blocks, devices or device contexts - a handle to an output area in a GUI implementation. 10.
9.Design and implement the internal servers as separate processes or shared libraries
Perform this in parallel with steps 7-9, because some of the microkernel services need to access internal
servers. It is helpful to distinguish b/w active and passive servers Active servers are implemented as
processes Passive servers as shared libraries. Passive servers are always invoked by directly calling their
interface methods, where as active server process waits in an event loop for incoming requests.
11 Implement the external servers
Each external server is implemented as a separate process that provide its own service interface
The internal architecture of an external server depends on the policies it comprises
Specify how external servers dispatch requests to their internal procedures.
12. Implement the adapters

Primary task of an adapter is to provide operations to its clients that are forwarded to an external server.
You can design the adapter either as a conventional library that is statically linked to client during
complication or as a shared library dynamically linked to the client on demand.
13. Develop client applications
or use existing ones for the ready-to-run microkernel system.
Q3) Explain the known uses of reflection pattern(Jun 15,Jan 16)(10 Marks)
Soln:
Known uses:
CLOS.
This is the classic example of a reflective programming language [Kee89]. In CLOS, operations defined
for objects are called generic functions, and their processing is referred to as generic function invocation.
Generic function invocation is divided into three phases:
The system first determines the methods that are applicable to a given invocation.
It then sorts the applicable methods in decreasing order of precedence.
The system finally sequences the execution of the list of applicable methods.
MIP
It is a run-time type information system for C++. The functionality of MIP is separated into four layers:
The first layer includes information and functionality that allows software to identify and compare types.
The second layer provides more detailed information about the type system of an application.
The third layer provides information about relative addresses of data members, and offers functions for
creating 'empty' objects of user-defined types.
The fourth layer provides full type information, such as that about friends of a class, protection of data
members, or argument and return types of function members.
PGen
It allows an application to store and read arbitrary C++ object structures.
NEDIS
NEDIS includes a meta level called run-time data dictionary. It provides the following services and
system information:
Properties for certain attributes of classes, such as their allowed value ranges.
Functions for checking attribute values against their required properties.
Default values for attributes of classes, used to initialize new objects.
Functions specifying the behavior of the system in the event of errors
Country-specific functionality, for example for tax calculation.
Information about the 'look and feel' of the software, such as the layout of input masks or the language to
be used in the user interface.
OLE 2.0
It provides functionality for exposing and accessing type information about OLE objects and their
interfaces.
Q4) Explain the components of microkernel pattern (Jun 15/Jan 16)(10 Marks)
Soln:
Microkernel pattern defines 5 kinds of participating components.
Internal servers

External servers
Adapters
Clients
Microkernel
Microkernel
The microkernel represents the main component of the pattern.
It implements central services such as communication facilities or resource handling.
The microkernel is also responsible for maintaining system resources such as processes or files.
It controls and coordinates the access to these resources.
A microkernel implements atomic services, which we refer to as mechanisms.
These mechanisms serve as a fundamental base on which more complex functionality called policies are
constructed.
An internal server (subsystem)

Extends the functionality provided by microkernel.
It represents a separate component that offers additional functionality.
Microkernel invokes the functionality of internal services via service requests.
Therefore internal servers can encapsulates some dependencies on the underlying hardware or software
system.
An external server (personality)

Uses the microkernel for implementing its own view of the underlying application domain.
Each external server runs in separate process.
It receives service requests from client applications using the communication facilities provided by the
microkernel, interprets these requests, executes the appropriate services, and returns its results to clients.

Different external servers implement different policies for specific application domains.
Client:
o It is an application that is associated with exactly one external server. It only accesses the programming
interfaces provided by the external server.
o Problem arises if a client accesses the interfaces of its external server directly ( direct dependency)
Such a system does not support changeability
If ext servers emulate existing application platforms clients will not run without modifications.
Adapter (emulator)
Represents the interfaces b/w clients and their external servers and allow clients to access the services of
their external server in a portable way.
They are part of the clients address space.
The following OMT diagram shows the static structure of a microkernel system.
The OMT Diagram shows a static structure of MicroKernel Syetm.
Q5) Explain the advantages and disadvantages of reflexive architectural pattern?

Soln:
The reflection architecture provides the following Benefits:

No explicit modification of source code:

You just specify a change by calling function of the MOP.
Changing a software system is easy
MOP provides a safe and uniform mechanism for changing s/w. it hides all specific techniques such as
use of visitors, factories from user.
Support for many kind of change:
Because Meta objects can encapsulate every aspect of system behavior, state and structure. The reflection
architecture also has Liabilities:
Modifications at meta level may cause damage:
Incorrect modifications from users cause serious damage to the s/w or its environment. Ex: changing a
database schema without suspending the execution of objects in the applications that use it or passing
code to the MOP that includes semantic errors
Robustness of MOP is therefore of great importance.
Increased number of components:

It includes more Meta objects than base level components.
Lower efficiency:
Slower than non reflective systems because of complex relnp b/w base and meta level.
Not all possible changes to the software are supported
Ex: changes or extensions to base level code.
Not all languages support reflection
Difficult to implement in C ++

Unit VII
Q1) What are the application areas of master slave pattern? (Jan 14,Jun 15,Jan 16) ( 10 Marks)
Soln:
There are 3 application areas for master slave pattern.
Master-slave for fault tolerance
In this variant the master just delegates the execution of a service to a fixed number of replicated
implementations, each represented by a slave.
Master-slave for parallel computation
In this variant the master divides a complex task into a number of identical sub-tasks, each of which is
executed in parallel by a separate slave.
Master-slave for computational concurrency.
In this variant the execution of a service is delegated to at least three different implementations, each of
which is a separate slave.
Other variants
Slaves as processes
To handle slaves located in separate processes, you can extend the original Master-Slave structure with
two additional components
Slaves as threads
In this variant the master creates the threads, launches the slaves, and waits for all threads to complete
before continuing with its own computation.
Master-slave with slave co ordination
In this case the computation of all slaves must be regularly suspended for each slave to coordinate itself
with the slaves on which it depends, after which the slaves resume their individual computation.
Q2) Give the structure of Whole port design with CRC?

(Jan 14)(5 Marks)
Soln:
The Whole-Part pattern introduces two types of participant:
Whole
Whole object represents an aggregation of smaller objects, which we call parts.
It forms a semantic grouping of its parts in that it co ordinates and organizes their collaboration.
Some methods of whole may be just place holder for specific part services when such a method is
invoked the whole only calls the relevant part services, and returns the result to the client.
Part
Each part object is embedded in exactly one whole. Two or more parts cannot share the same part.
Each part is created and destroyed within the life span of the whole.

Static relationship between whole and its part are illustrated in the OMT diagram below
Q3) What are the variants of Proxy Pattern?(Jun 14)(5 Marks)

Soln:
Variants:
Remote proxy:
Clients of remote components should be scheduled from network addresses and IPC protocols.
Protection proxy:
Components must be protected from unauthorized access.
Cache proxy:
Multiple local clients can share results from remote components.
Synchronization proxy:
Multiple simultaneous accesses to a component must be synchronized.
Counting proxy:
Accidental deletion of components must be prevented or usage statistics collected
Virtual proxy:
Processing or loading a component is costly while partial information about the component may be
sufficient.
Firewall proxy:
Local clients should be protected from the outside world.
Q4) Discuss the 5 steps implementation of master slave pattern?(Jun 15,Jan 16)(10 Marks)
Soln:
Implementation:
1. Divide work:
Specify how the computation of the task can be split into a set equal sub tasks. Identify the sub services
that are necessary to process a subtask.
2. Combine sub-task results
Specify how the final result of the whole service can be computed with the help of the results obtained
from processing individual sub-tasks.
3. Specify co operation between master and slaves
Define an interface for the subservice identified in step1 it will be implemented by the slave and used by
the master to delegate the processing of individual subtask. One option for passing subtasks from the
master to the slaves is to include them as a parameter when invoking the subservice.
Another option is to define a repository where the master puts sub tasks and the slaves fetch them.

4. Implement the slave components according to the specifications developed in previous step.
5. Implement the master according to the specifications developed in step 1 to 3
There are two options for dividing a task into subtasks.
The first is to split work into a fixed number of subtasks.
The second option is to define as many subtasks as necessary or possible.
Use strategy pattern to support dynamic exchange and variations of algorithms for subdividing a task.
Q5) Define Proxy Design.Discuss benefits and liabilities of same?(Jun 14,Jun 15,Jan 16)(10 Marks)
Soln:
Proxy design pattern makes the clients of a component communicate with a representative rather than to
the component itself. Introducing such a place holder can serve many purposes, including enhanced
efficiency, easier access and protection from unauthorized access.
The Proxy pattern provides the following Benefits:
Enhanced efficiency and lower cost
The Virtual Proxy variant helps to implement a 'load-on-demand' strategy. This allows you to avoid
unnecessary loads from disk and usually speeds up your application
Decoupling clients from the location of server components
By putting all location information and addressing functionality into a Remote Proxy variant, clients are
not affected by migration of servers or changes in the networking infrastructure. This allows client code
to become more stable and reusable.
Separation of housekeeping code from functionality.
A proxy relieves the client of burdens that do not inherently belong to the task the client is to perform.
The Proxy pattern has the following Liabilities:
Less efficiency due to indirection
All proxies introduce an additional layer of indirection.
Over kill via sophisticated strategies
Be careful with intricate strategies for caching or loading on demand they do not always pay.
Q6) How the whole-part can be implemented? Also mention the advantages and disadvantages of
whole-part(Jun 15,Jan 16)(10 Marks)
Soln:
Implementation:
1. Design the public interface of the whole
Analyze the functionality the whole must offer to its clients.
Only consider the clients view point in this step.

Think of the whole as an atomic component that is not structured into parts.
2. Separate the whole into parts, or synthesize it from existing ones.
There are two approaches to assembling the parts either assemble a whole ‘bottom-up’ from existing
parts, or decompose it ‘top-down’ into smaller parts.
Mixtures of both approaches is often applied
3. If you follow a bottom up approach, use existing parts from component libraries or class libraries and
specify their collaboration.
4. If you follow a top down approach, partition the Wholes services into smaller collaborating
services and map these collaborating services to separate parts.
5. Specify the services of the whole in terms of services of the parts.
Decide whether all part services are called only by their whole, or if parts may also call each other. Two
are two possible ways to call a Part service: @ If a client request is forwarded to a Part service, the Part
does not use any knowledge about the execution context of the Whole, relying on its own environment
instead. @ A delegation approach requires the Whole to pass its own context information to the Part.
6. Implement the parts
If parts are whole-part structures themselves, design them recursively starting with step1 . if not reuse
existing parts from a library.
7. Implement the whole
Implement services that depend on part objects by invoking their services from the whole.
The whole-part pattern offers several Benefits:
8.Changeability of parts:
Part implementations may even be completely exchanged without any need to modify other parts or
clients.
9.Separation of concerns:
Each concern is implemented by a separate part.
10.Reusability in two aspects:
Parts of a whole can be reused in other aggregate objects
Encapsulation of parts within a whole prevents clients from ‘scattering’ the use of part objects all over its
source code.
The whole-part pattern suffers from the following Liabilities:
11.Lower efficiency through indirection
Since the Whole builds a wrapper around its Parts, it introduces an additional level of indirection between
a client request and the Part that fulfils it.
12.Complexity of decomposition into parts.
An appropriate composition of a Whole from different Parts is often hard to find, especially when a
bottom-up approach is applied.
Q7) Briefly explain benefits of Master Slave Pattern?(june 2012)(6 Marks)

Soln:
The Master-Slave design pattern provides several Benefits:
Exchangeability and extensibility
By providing an abstract slave class, it is possible to exchange existing slave implementations or add new
ones without major changes to the master.
Separation of concerns

The introduction of the master separates slave and client code from the code for partitioning work,
delegating work to slaves, collecting the results from the slaves, computing the final result and handling
slave failure or inaccurate slave results.
Efficiency
The Master-Slave pattern for parallel computation enables you to speed up the performance of computing
a particular service when implemented carefully.
Q8) Briefly comment on the different steps carried out to realize the implementation of Proxy
pattern?(Jan 14,Jun 15)(6 Marks)
Soln:
1. Identify all responsibilities for dealing with access control to a component
Attach these responsibilities to a separate component the proxy.
2. If possible introduce an abstract base class that specifies the common parts of the interfaces of
both the proxy and the original.
Derive the proxy and the original from this abstract base.
3. Implement the proxy’s functions
To this end check the roles specified in the first step
4. Free the original and its client from responsibilities that have migrated into the proxy.
5. Associate the proxy and the original by giving the proxy a handle to the original. This handle may be
a pointer a reference an address an identifier, a socket, a port, and so on.
6. Remove all direct relationships between the original and its client
Replace them by analogous relationships to the proxy.

Unit-VIII
Q1) Write a note on View Catalog?(Jan 14,Jan 16)(4 Marks)

Soln:
View Catalog
A view catalog is the reader's introduction to the views that the architect has chosen to include in the suite
of documentation. There is one entry in the view catalog for each view given in the documentation suite. -
Each entry should give the following:
x The name of the view and what style it instantiates
x A description of the view's element types, relation types, and properties
x A description of what the view is for
x Management information about the view document, such as the latest version, the location of the
view document, and the owner of the view document
Q2) Explain with neat diagram, evolutionary delivery life cycle model?(Jun 15)(10 Marks)
Soln:
Any organization that embraces architecture as a foundation for its software development processes needs
to understand its place in the life cycle. Several life-cycle models exist in the literature, but one that puts
architecture squarely in the middle of things is the evolutionary delivery life cycle model shown in figure
The intent of this model is to get user and customer feedback and iterate through several releases before
the final release. The model also allows the adding of functionality with each iteration and the delivery of
a limited version once a sufficient set of features has been developed.
Q3) What are the suggested standard organization points for interface
documentation?(Jun 15)(12 Marks)
Soln:

An interface is a boundary across which two independent entities meet and interact or communicate with
each other.
1. Interface identify
When an element has multiple interfaces, identify the individual interfaces to distinguish them. This
usually means naming them. You may also need to provide a version number.
2. Resources provided:
The heart of an interface document is the resources that the element provides.
Resource syntax – this is the resource’s signature
Resource Semantics:
x Assignment of values of data
x Changes in state
x Events signaled or message sent
x how other resources will behave differently in future
x humanly observable results
x Resource Usage Restrictions
x initialization requirements
x limit on number of actors using resource
3. Data type definitions:
If used if any interface resources employ a data type other than one provided by the underlying
programming language, the architect needs to communicate the definition of that type. If it is defined by
another element, then reference to the definition in that element’s documentation is sufficient.
4. Exception definitions:
These describe exceptions that can be raised by the resources on the interface. Since the same exception
might be raised by more than one resource, if it is convenient to simply list each resource’s exceptions but
define them in a dictionary collected separately.
5. Variability provided by the interface.
Does the interface allow the element to be configured in some way? These configuration parameters and
how they affect the semantics of the interface must be documented.
6. Quality attribute characteristics:
The architect needs to document what quality attribute characteristics (such as performance or reliability)
the interface makes known to the element's users
7. Element requirements:
What the element requires may be specific, named resources provided by other elements. The
documentation obligation is the same as for resources provided: syntax, semantics, and any usage
restrictions.
8. Rationale and design issues:
Why these choices the architect should record the reasons for an elements interface design. The rationale
should explain the motivation behind the design, constraints and compromises, what alternatives designs
were considered.
9. Usage guide:
Item 2 and item 7 document an element's semantic information on a per resource basis. This sometimes
falls short of what is needed. In some cases semantics need to be reasoned about in terms of how a broad
number of individual interactions interrelate.

Q4) List the steps of ADD and explain?(Jan 14,Jan 16)(10 Marks)
Soln:
ADD Steps:
Steps involved in attribute driven design (ADD)
1. Choose the module to decompose
Start with entire system
Inputs for this module need to be available
Constraints, functional and quality requirements
2. Refine the module
a) Choose architectural drivers relevant to this decomposition
b) Choose architectural pattern that satisfies these drivers
c) Instantiate modules and allocate functionality from use cases representing using multiple views
d) Define interfaces of child modules
e) Verify and refine use cases and quality scenarios
3. Repeat for every module that needs further decomposition
1. Choose The Module To Decompose
x the following are the modules: system->subsystem->submodule
x Decomposition typically starts with system, which then decompose into subsystem and then into
sub-modules.
x In our Example, the garage door opener is a system
x Opener must interoperate with the home information system
2. Refine the module

Choose Architectural Drivers:
choose the architectural drivers from the quality scenarios and functional requirements
The drivers will be among the top priority requirements for the module.
In the garage system, the 4 scenarios were architectural drivers,
By examining them, we see
x Real-time performance requirement
x Modifiability requirement to support product line
x Requirements are not treated as equals

x Less important requirements are satisfied within constraints obtained by satisfying more
important requirements
This is a difference of ADD from other architecture design methods
2. Choose Architectural Pattern

For each quality requirement there are identifiable tactics and then identifiable patterns that implement
these tactics.
The goal of this step is to establish an overall architectural pattern for the module
The pattern needs to satisfy the architectural pattern for the module tactics selected to satisfy the drivers
Two factors involved in selecting tactics:
Architectural drivers themselves
Side effects of the pattern implementing the tactic on other requirements
This yields the following tactics:
Semantic coherence and information hiding. Separate responsibilities dealing with the user interface,
communication, and sensors into their own modules. Increase computational efficiency. The
performance-critical computations should be made as efficient as possible. Schedule wisely. The
performance-critical computations should be scheduled to ensure the achievement of the timing deadline.
3. Instantiate Modules And Allocate Functionality Using Multiple Views

Instantiate modules
The non-performance-critical module of Figure 7.2 becomes instantiated as diagnosis and
raising/lowering door modules in Figure 7.3. We also identify several responsibilities of the virtual
machine: communication and sensor reading and actuator control. This yields two instances of the virtual
machine that are also shown in Figure 7.3.
Allocate functionality
Assigning responsibilities to the children in a decomposition also leads to the discovery of necessary
information exchange. At this point in the design, it is not important to define how the information is
exchanged. Is the information pushed or pulled? Is it passed as a message or a call parameter? These are
all questions that need to be answered later in the design process. At this point only the information itself
and the producer and consumer roles are of interest
Represent the architecture with multiple views

Module decomposition view
Concurrency view
Two users doing similar things at the same time
x One user performing multiple activities simultaneously
x Starting up the system
x Shutting down the system
x Deployment view
4. Define Interfaces Of Child Modules

It documents what this module provides to others.
Analyzing the decomposition into the 3 views provides interaction information for the interface
Module view:

Producers/consumers relations,patterns of communication, Concurrency view:

Interactions among threads
Synchronization information
Deployment view
Hardware requirement
Timing requirements
Communication requirements
5. Verify And Refine Use Cases And Quality Scenarios As Constraints For The Child Modules
Functional requirements
Using functional requirements to verify and refine
Decomposing functional requirements assigns responsibilities to child modules
We can use these responsibilities to generate use cases for the child module
x User interface:
Handle user requests
Translate for raising/lowering module
Display responses
x Raising/lowering door module
Control actuators to raise/lower door
Stop when completed opening or closing
x Obstacle detection:
Recognize when object is detected
Stop or reverse the closing of the door
x Communication virtual machine
Manage communication with house information system(HIS)
x Scheduler
Guarantee that deadlines are met when obstacle is detected
x Sensor/actuator virtual machine
Manage interactions with sensors/actuators
x Diagnosis:
Manage diagnosis interaction with HIS
Constraints:
The decomposition satisfies the constraint
OS constraint-> satisfied if child module is OS
The constraint is satisfied by a single module
Constraint is inherited by the child module
The constraint is satisfied by a collection of child modules
E.g., using client and server modules to satisfy a communication constraint
Quality scenarios:
Quality scenarios also need to be verified and assigned to child modules
A quality scenario may be satisfied by the decomposition itself, i.e, no additional impact on child modules
A quality scenario may be satisfied by the decomposition but generating constraints for the children
The decomposition may be “neutral” with respect to a quality scenario
A quality scenario may not be satisfied with the current decomposition

Q5) What are the uses of architectural documentation? Bring out the concept of view as
applied to architectural documentation?(Jun 15,Jan 16)(10 Marks)
Soln:
The Uses of Architectural Documentation are:
Architecture documentation is both prescriptive and descriptive. That is, for some audiences it prescribes
what should be true by placing constraints on decisions to be made. For other audiences it describes what
is true by recounting decisions already made about a system's design.
All of this tells us that different stakeholders for the documentation have different needs—different kinds
of information, different levels of information, and different treatments of information.
One of the most fundamental rules for technical documentation in general, and software architecture
documentation in particular, is to write from the point of view of the reader. Documentation that was easy
to write but is not easy to read will not be used, and "easy to read" is in the eye of the beholder—or in this
case, the stakeholder.
Documentation facilitates that communication. Some examples of architectural stakeholders and the
information they might expect to find in the documentation are given in Table 9.1.
In addition, each stakeholders come in two varieties: seasoned and new. A new stakeholder will want
information similar in content to what his seasoned counterpart wants, but in smaller and more
introductory doses. Architecture documentation is a key means for educating people who need an
overview: new developers, funding sponsors, visitors to the project, and so forth.
The concept of a view, which you can think of as capturing a structure, provides us with the basic
principle of documenting software architecture Documenting an architecture is a matter of documenting
the relevant views and then adding documentation that applies to more than one view. This principle is
useful because it breaks the problem of architecture documentation into more tractable parts, which
provide the structure for the remainder of this chapter:
Choosing the relevant views
Documenting view
Documenting information that applies to more than one view
Q6) Architecture serves as a Communication vehicle across stake holders?

Documentation facilitates that communication?(Jan 15)(10 Marks)
Soln:
Every suite of architectural documentation needs an introductory piece to explain its organization to a
novice stakeholder and to help that stakeholder access the information he or she is most interested in.
There are two kinds of "how" information:
View Catalog
A view catalog is the reader's introduction to the views that the architect has chosen to include in the suite
of documentation. There is one entry in the view catalog for each view given in the documentation suite.
Each entry should give the following: The name of the view and what style it instantiates, A description
of the view's element types, relation types, and properties A description of what the view is for
Management information about the view document, such as the latest version, the location of the view
document, and the owner of the view document

View Template
A view template is the standard organization for a view. It helps a reader navigate quickly to a section of
interest, and it helps a writer organize the information and establish criteria for knowing how much work
is left to do.
WHAT THE ARCHITECTURE IS

This section provides information about the system whose architecture is being documented, the relation
of the views to each other, and an index of architectural elements.
System Overview
This is a short prose description of what the system's function is, who its users are, and any important
background or constraints. The intent is to provide readers with a consistent mental model of the system
and its purpose. Sometimes the project at large will have a system overview, in which case this section of
the architectural documentation simply points to that.
Mapping between Views
Since all of the views of an architecture describe the same system, it stands to reason that any two views
will have much in common. Helping a reader of the documentation understand the relationships among
views will give him a powerful insight into how the architecture works as a unified conceptual whole.
Being clear about the relationship by providing mappings between views is the key to increased
understanding and decreased confusion.
Element List
The element list is simply an index of all of the elements that appear in any of the views, along with a
pointer to where each one is defined. This will help stakeholders look up items of interest quickly.
Project Glossary
The glossary lists and defines terms unique to the system that have special meaning. A list of acronyms,
and the meaning of each, will also be appreciated by stakeholders. If an appropriate glossary already
exists, a pointer to it will suffice here.
Q7) What are the suggested standard organization points for view documentation?
(Jan 15,Jun 15)(8 Marks)
Soln:
Primary presentation- elements and their relationships, contains main information about these system ,
usually graphical or tabular.
Element catalog- details of those elements and relations in the picture,
Context diagram- how the system relates to its environment
Variability guide- how to exercise any variation points a variability guide should include documentation
about each point of variation in the architecture, including
The options among which a choice is to be made
The binding time of the option. Some choices are made at design time, some at build time, and others at
runtime.
Architecture background –why the design reflected in the view came to be? an architecture background
includes
o rationale, explaining why the decisions reflected in the view were made and why alternatives were
rejected

o analysis results, which justify the design or explain what would have to change in the face of a
modification
o assumptions reflected in the design
Glossary of terms used in the views, with a brief description of each.
Other information includes management information such as authorship, configuration control data, and
change histories. Or the architect might record references to specific sections of a requirements document
to establish traceability

SA VTU Qns and Solns Unitwise

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

SA VTU Qns and Solns Unitwise

Încărcat de

Drepturi de autor:

Formate disponibile

Software Architecture 10IS81

VTU QUESTION PAPER SOLUTIONS

Here is how the cycle works:

Dept. of CSE, SJBIT Page 1

The various activities involved in creating software architecture are:

x Safety-critical systems use more rigorous approaches, such as finite-state-machine

Another technique that helps us understand requirements is the creation of prototypes.

Analyzing or evaluating the architecture

x Evaluating an architecture for the qualities that it supports is essential to ensuring

Dept. of CSE, SJBIT Page 2

x Use scenario-based techniques or architecture tradeoff analysis method (ATAM) or cost

Implementing the system based on the architecture

x Having an explicit and well-communicated architecture is the first step toward

Ensuring that the implementation conforms to the architecture

The architecture affects the structure of the developing organization. An architecture

Dept. of CSE, SJBIT Page 3

Dept. of CSE, SJBIT Page 4

Dept. of CSE, SJBIT Page 5

We will address each of these points in turn:

Dept. of CSE, SJBIT Page 6

ii)The architecture dictates organizational structure

x ARCHITECTURE AS A TRANSFERABLE, RE-USABLE MODEL

Dept. of CSE, SJBIT Page 7

Q7) Explain Model Based Structures?(Jun 14,Jan 16)(4 Marks)

Dept. of CSE, SJBIT Page 8

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

Dept. of CSE, SJBIT Page 9

Common specialization of this style includes :

Dept. of CSE, SJBIT Page 10

Req1: permits clear cut separation of action and reaction

Dept. of CSE, SJBIT Page 11

Process Variables: Properties of process that can be measured.

Q4) Write a Note on Heterogeneous Architecture? (Jun 14/Jan 16)(3 Marks)

Dept. of CSE, SJBIT Page 12

Dept. of CSE, SJBIT Page 13

SOLUTION 2: IMPLICIT INVOCATION

Dept. of CSE, SJBIT Page 14

Q2) What are the qualities of a system?Explain modifiability general scenario?

Dept. of CSE, SJBIT Page 15

What can change (the artifact)?

Dept. of CSE, SJBIT Page 16

Dept. of CSE, SJBIT Page 17

Dept. of CSE, SJBIT Page 18

Dept. of CSE, SJBIT Page 19

within a module (non-architectural).Performance involves both architectural and non-architectural

Dept. of CSE, SJBIT Page 20

Dept. of CSE, SJBIT Page 21

Dept. of CSE, SJBIT Page 22

Q10) Explain Business Qualities?(Jan 14,Jan 16) (4 Marks)

Q11) Explain Modifiability Tactics?(Jan 14,Jun 15,Jan 16)(10 Marks)

Dept. of CSE, SJBIT Page 23

In such a case, we need to balance the following forces:

x Interfaces should be stable, and may even be impressed by a standards body.

x Similar responsibilities should be grouped to help understandability and maintainability.

x There is no ‘standard’ component granularity.

x Complex components need further decomposition.

Dept. of CSE, SJBIT Page 24

x Crossing component boundaries may impede performance, for example when a

x The system will be built by a team of programmers, and works has to be

Dept. of CSE, SJBIT Page 25

x Scenario II illustrates bottom-up communication-a chain of actions starts at Layer 1,

Dept. of CSE, SJBIT Page 26

Dept. of CSE, SJBIT Page 27

Dept. of CSE, SJBIT Page 28