SRM UNIVERSITY

DEPARTMENT OF SOFTWARE ENGINEERING

SE1010- SOFTWARE ARCHITECTURE

MODEL THEORY EXAMINATION ANSWER KEY

MARKS:100

PART-A (20*1=20)

1. C

2. A

3. C

4. A

5. B

6. B

7. A

8. A

9. A

10.C

11.B

12.B

13.A

14.C

15.B

16.D

17.D

18.A

19.C

20.C
 PART-B (5*4=20)

21. UTILITY TREE

A utility tree begins with the word "utility" as the root node. Utility is an
expression of the overall "goodness" of the system. We then elaborate this root
node by listing the major quality attributes that the system is required to exhibit.

22. PALM

ALM is a seven-step method. The steps are these:

1 .PALM overview presentation. Overview of PALM, the problem it solves, its

steps, and its expected outcomes.

2. Business drivers presentation. Briefing of business drivers by project

management.

3. Architecture drivers presentation. Briefing by the architect on the driving

business and quality attribute requirements: the ASRs.

4. Business goals elicitation. Using the standard business goal categories to

guide discussion.
5. Identification of potential quality attributes from business goals. For each
important business goal scenario, participants describe a quality attribute that
(if architected into the system) would help achieve it.

6. Assignment of pedigree to existing quality attribute drivers. For each

architectural driver named in step 3, we identify which business goals it is there
to support.

7. Exercise conclusion. Review of results, next steps, and participant feedback.

23. AGILE MANIFESTO

The authors of the Manifesto go on to describe the principles that underlie their
reasoning:

1. Our highest priority is to satisfy the customer through early and continuous
delivery of valuable software.

2. W elcmne changing requirements, even late in development. Agile processes

harness change for the custotner's competitive advantage.

3. Deliver working software frequently, from a couple of weeks to a couple of

months, with a preference to the shorter timescale.

4. Business people and developers must work together daily throughout the
project.

5. Build projects around motivated individuals. Give them the environment and
support they need, and trust them to get the job done.

6. The most efficient and effective method of conveying information to and

within a development team is face-to-face conversation.

7. Working software is the primary measure of progress.

8. Agile processes promote sustainable development. The sponsors, developers,

and users should be able to maintain a constant pace indefinitely.

9.Continuous attention to technical excellence and good design enhances agility.

10. Simplicity the art of maximizing thev amount of work not done is essential.
24. VFC, BENEFIT AND NORMALIZATION

25. SEVICE MODELS IN CLOUD

Cloud Service Models

Software as a Service (SaaS)

The consumer in this case is an end user. The consumer uses applications that happen to be
running on a cloud.

Platform as a Service (PaaS)

The consumer in this case is a developer or system administrator. The platform provides a
variety of services that the consumer may choose to use.

Infrastructure as a Service (IaaS)

The capability provided to the consumer is to provision processing, storage, networks, and
other fundamental computing resources.

Deployment Models

The various deployment models for the cloud are differentiated by who owns and operates
the cloud. It is possible that a cloud is owned by one party and operated by a different party.
26. EDGE DOMINANT SYSTEMS:

All successful edge-dominant systems, and the organizations that develop and use these
systems, share a common ecosystem structure . This is called a "Metropolis" structure,
byanalogy with a city.

It is a representation of three communities

of stakeholders:

Customers and end users, who consume the value produced by the Metropolis

Developers, who write software and key content for the Metropolis

Prosumers, who consume content but also produce it

27. DUTIES REQUIRED FOR AN ARCHITECT

Technical duties:

Non Technical duties:

 PART-C (5*12=60)

28.A. ARCHITECTURE AND AGILE

To address the complexity of this domain, the WebArrow architect and developers found that
they needed to think and work in two different modes at the same time:

Top-down designing and analyzing architectural structures to meet the demanding quality

attribute requirements and tradeoffs

Bottom-up analyzing a wide array of implementation-specific and environment-specific

constraints and fashioning solutions to them To compensate for the difficulty in analyzing
architectural tradeoffs with any precision, the team adopted an agile architecture discipline
combined with a rigorous program of experiments aimed at answering specific tradeoff
questions. These experiments are what are called "spikes" in Agile terminology. And these
experiments proved to be the key in resolving tradeoffs, by helping to tum unknown
architectural parameters into constants or ranges.

Making architecture processes agile does not require a radical re-invention of either Agile
practices or architecture methods. The Web-Arrow team's emphasis on experimentation

Guidelines for the Agile Architect

Barry Boehm and colleagues have developed the Incremental Commitment Model a hybrid
process model framework that attempts to find the balance between agility and commitment.
This model is based upon the following six principles:

1. Commitment and accountability of success-critical stakeholders

2. Stakeholder "satisficing" (meeting an acceptability threshold) based on success-

basednegotiations and tradeoffs

3. Incremental and evolutionary growth of system definition and stakeholder commitment

4. Iterative system development and definition

5. Interleaved system definition and development allowing early fielding of core capabilities,

continual adaptation to change, and timely growth of complex systems without waiting for

every requirement and subsystem to be defined

6. Risk management risk -driven anchor point milestones, which are key to synchronizing
and stabilizing all of this concurrent activity

28.B. ARCHITECTURE AND REQUERMENTS

Requirements for a system come in a variety of forms: textual requirements, mockups,

existing systems, use cases, user stories, and more. No matter the source, all requirements
encompass the following categories:

1 . Functional requirements.

2. Quality attribute requirements.

3. Constraints.

Specifying Quality Attribute Requirements

In summary, here are the six parts:

1 . Source of stimulus.

2. Stimulus.

3.Environment.

4. Artifact.

5.Response.

6. Response measure.

29.A. DESIGN AND DOCUMENTATION OF SOFTWARE ARCHITECTURE

We present three ideas that are key to architecture design methods:

Decomposition Module decomposition Quality attributes - use of preexisting

componentscomponents and-connectors (C&C) -

Designing to architecturally significant requirements - the non-ASR requirements -

Design for all of the ASRs or one at a time -

Generate and test. - Creating the Initial Hypothesis test hypothesis Genarate next
hypothesis - Terminating the Process

Architecture documentation is both prescriptive and descriptive. For some

audiences, it prescribes what should be true, placing constraints on decisions yet
to be made. For other audiences, it describes what is true, recounting decisions
already made about a system's design.

Fundamentally, architecture documentation has three uses:

1 . Architecture documentation serves as a means of education.

2. Architecture documentation serves as a primary vehicle for communication

among stakeholders.

3. Architecture documentation serves as the basis for system analysis and

construction.
 30.A. CBAM

the method we use for economic analysis: the

Cost Benefit Analysis Method. CBAM has for
the most part been applied when an organization was considering a major
upgrade to an existing system and they wanted to understand the utility and
value for cost of making the upgrade. Its key concepts (quality attribute response
curves, cost, and utility) do not depend on the setting.

Process flow diagram for the CBAM

30.B.

ARCHITECTURE COMPETENCE SET

Architects perform many activities beyond directly producing an architecture.

These activities, which we call duties, form the backbone of an individual's
architecture competence.
To give
examples
of these concepts:

''Design the architecture" is a duty.

"Ability to think abstractly" is a skill.

"Patterns and tactics" is a part of the body of knowledge.

individual architectural competence is gained by the following:

1 . Gain experience carrying out the duties. Apprenticeship is a productive path

to achieving experience.

2. Improve your nontechnical skills. This dimension of improvement involves

taking professional development courses, for example, in leadership or time
management.

3. Master the body of knowledge. One of the most itnportant things a competent
architect must do is master the body of knowledge and retnain up to date on it.

Here are some things architecture efforts:

duties that an organization can perform to help improve the success of its

Hire talented architects.

Establish a career track for architects.

Make the position of architect highly regarded through visibility, reward, and
prestige.

31.A. HDFS

A component-and-connector view ofHDFS within a cluster is a storage sysstem.

NameNode process for the whole cluster, multiple DataNodes, and potentially
multiple client applications. To explain the function of HDFS, we trace through a
use case. We describe the successful use case for "write." HDFS also has facilities
to handle failure.

For the "write" use case, we will assume that the file has already been opened.
HDFS does not use locking to allow for simultaneous writing by different
processes. Instead, it assumes a single writer that writes until the file is
complete, after which multiple readers can read the file simultaneously. The
application process has two portions: the application code and a client library
specific to HDFS. The application code can write to the client using a standard
(but overloaded) Java I/0 call. The client buffers the information until a block of
64 MB has been collected. Two of the techniques used by HDFS for enhancing
performance are the avoidance of locks and the use of 64-MB blocks as the only
block size supported. No substructure of the blocks is supported by HDFS. The
blocks are undifferentiated byte strings. Any substructure and typing of the
information is managed solely by the application. This is one example of a
phenomenon that we will notice in portions of the cloud: moving application-
specific functionality up the stack as opposed to moving it down the stack to the
infrastructure.

31.B. METROPOLIS MODEL

The Metropolis model, is paired with the core/periphery pattern for architecture
for edge-dominant systems. Adopting this duo brings with it changes to the way
that software is developed; in effect, it implies a software development model,
with its implications on tools, processes, activities, roles, and expectations.

The Metropolis model requires a new perspective on system development,

resulting in several

important changes to how we must create systems:

1 . Indifference to phases. The Metropolis model uses the metaphor of a bull' s

eye, as opposed to a waterfall, a spiral, a "V," or other representations that
previous models have adopted.

2. Crowd management. Policies for crowd management must be aligned with the
organization's strategic goals and must be established early.

3. Core versus periphery. The Metropolis model differentiates the core and
periphery communities, with different tools, processes, activities, roles, and
expectations for each.

4. Requirements process. The requirements for a Metropolis system are primarily

asserted by the periphery, not elicited from the masses.

5. Focus on architecture. The core architecture is the fabric that holds together a
Metropolis system.

6. Distributed testing. The core/periphery distinction also provides guidance for

testing activities.

7. Automated delivery. Delivery mechanisms must be created that work in a

distributed, asynchronous manner.

8. Management of the periphery. One important aspect of the core/periphery

model is that the core exercises very little control over the periphery.

32.A.

DEPLOYMENT MODELS
The various deployment models for the cloud are differentiated by who owns and
operates the cloud. It is possible that a cloud is owned by one party and
operated by a different party, but we will ignore that distinction and assume that
the owner of the cloud also operates the cloud.

There are two basic models and then two additional variants of these. The two
basic models are

private cloud and public cloud:

Private cloud. The cloud infrastructure is owned solely by a single organization

and operated

solely for applications owned by that organization. The primary purpose of the
organization is not the selling of cloud services.

Public cloud. The cloud infrastructure is made available to the general public or
a large industry group and is owned by an organization selling cloud services.

The two variants are community cloud and hybrid cloud:

Community cloud. The cloud infrastructure is shared by several organizations

and supports a specific c01nmunity that has shared concerns

Hybrid cloud. The cloud infrastructure is a composition of two or more clouds

(private, community, or public) that remain unique entities.

Multi-tenancy

Multi-tenancy applications such as Salesforce.com or Microsoft Office 365 are

architected explicitly to have a single application that supports distinct sets of
users. The economic benefit of multi-tenancy is based on the reduction in costs
for application update and management. Consider what is involved in updating
an application for which each user has an individual copy on their own desktop.
New versions must be tested by the IT department and then pushed to the
individual desktops. Different users may be updated at different times because
of disconnected operation, user resistance to updates, or scheduling difficulties.
Incidents result because the new version may have some incompatibilities with
older versions, the new version may have a different user interface, or users with
old versions are unable to share information with users of the new version.

32.B. EDGE-DOMINANT SYSTEM REQUIREMENTS:

1 . Indifference to phases.

2. Crowd management.

3. Core versus periphery.

4. Requirements process.

5. Focus on architecture.

6. Distributed testing.

7. Automated delivery.

8. Management of the periphery.