Download Cse Vii Software Architectures [06is72] Notes PDF

TitleCse Vii Software Architectures [06is72] Notes
File Size2.0 MB
Total Pages120
Document Text Contents
Page 1



Software Architecture (06IS72)

UNIT - 1
INTRODUCTION: The Architecture Business Cycle: Where do architectures come from? Software
processes and the architecture business cycle; What makes a “good” architecture? What software
architecture is and what it is not; Other points of view; Architectural patterns, reference models and
reference architectures; Importance of software architecture; Architectural structures and views. 6

UNIT - 2
ARCHITECTURAL STYLES AND CASE STUDIES: Architectural styles; Pipes and filters; Data
abstraction and object-oriented organization; Event-based, implicit invocation; Layered systems;
Repositories; Interpreters; Process control; Other familiar architectures; Heterogeneous
architectures. Case Studies: Keyword in Context; Instrumentation software; Mobile robotics; Cruise
control; Three vignettes in mixed style.

7 Hours
UNIT - 3

QUALITY: Functionality and architecture; Architecture and quality attributes; System quality
attributes; Quality attribute scenarios in practice; Other system quality attributes; Business
qualities; Architecture qualities.

Achieving Quality: Introducing tactics; Availability tactics; Modifiability tactics; Performance tactics;
Security tactics; Testability tactics; Usability tactics; Relationship of tactics to architectural patterns;
Architectural patterns and styles. 6 Hours

UNIT - 4
ARCHITECTURAL PATTERNS – 1: Introduction; from mud to structure: Layers, Pipes and Filters,
Blackboard. 7 Hours

Page 2



UNIT - 5

ARCHITECTURAL PATTERNS – 2: Distributed Systems: Broker; Interactive Systems: MVC,
Presentation-Abstraction-Control. 7 Hours

UNIT - 6
ARCHITECTURAL PATTERNS – 3:Adaptable Systems: Microkernel; Reflection.

6 Hours
UNIT - 7
SOME DESIGN PATTERNS: Structural decomposition: Whole – Part; Organization of work:
Master – Slave; Access Control: Proxy. 6 Hours

UNIT - 8

designing the architecture; Forming the team structure; Creating a skeletal system. Uses of
architectural documentation; Views; choosing the relevant views; Documenting a view;
Documentation across views. 7 Hours

1. Software Architecture in Practice – Len Bass, Paul Clements, Rick Kazman, 2nd

Edition, Pearson Education, 2003.
2. Pattern-Oriented Software Architecture, A System of Patterns - Volume 1 – Frank

Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, Michael Stal, , John
Wiley and Sons, 2006.

1. Mary Shaw and David Garlan: Software Architecture- Perspectives on an Emerging
Discipline, Prentice-Hall of India, 2007.

1. Design Patterns- Elements of Reusable Object-Oriented Software – E. Gamma, R.

Helm, R. Johnson, J. Vlissides:, Addison-Wesley, 1995. Web site for Patterns:

Page 60



Portion of Possible Values

Source End user

Stimulus At runtime or configure time System provides one or more of the following responses:
to support "learn system features"

Response Wants to learn system features; efficiently; minimize impact of errors; adapt system; feel

Artifact System help system is sensitive to context; interface is familiar to user;interface is usable in an unfamiliar

contextto support "use system efficiently

Table 4.7. Quality Attribute Stimuli



Availability Unexpected event, nonoccurrence of expected event

Modifiability Request to add/delete/change/vary functionality, platform, quality attribute, or capacity

Performance Periodic, stochastic, or sporadic

Security Tries to

display, modify, change/delete information, access, or reduce availability to system

Testability Completion of phase of system development

Table 4.7 gives the stimuli possible for each of the attributes and shows a number of different
concepts. Some stimuli occur during runtime and others occur before. The problem for the
architect is to understand which of these stimuli represent the same occurrence, which are
aggregates of other stimuli, and which are independent.

Once the relations are clear, the architect can communicate them to the various stakeholders
using language that each comprehends. We cannot give the relations among stimuli in a general
way because they depend partially on environment. A performance event may be atomic or may
be an aggregate of other lower-level occurrences; a failure may be a single performance event or
an aggregate.

For example, it may occur with an exchange of several messages between a client and a server
(culminating in an unexpected message), each of which is an atomic event from a performance

Business Qualities :

In addition to the qualities that apply directly to a system, a number of business quality goals
frequently shape a system's architecture. These goals center on cost, schedule, market, and
marketing considerations. Each suffers from the same ambiguity that system qualities have, and

Page 61



they need to be made specific with scenarios in order to make them suitable for influencing the
design process and to be made testable. Here, we present them as generalities, however, and
leave the generation of scenarios as one of our discussion questions.

 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. Time to market is often
reduced by using prebuilt elements such as commercial off-the- shelf (COTS) products or
elements re-used from previous projects. The ability to insert or deploy a subset of the
system depends on the decomposition of the system into elements.

 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).

 Projected lifetime of the system. If the system is intended to have a long
lifetime, modifiability, scalability, and portability become important. But building
in the additional infrastructure (such as a layer to support portability) will usually
compromise time to market. On the other hand, a modifiable, extensible product is more
likely to survive longer in the marketplace, extending its lifetime.

 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. To attack a large market with a
collection of related products, a product line approach should be considered in which a
core of the system is common (frequently including provisions for portability) and
around which layers of software of increasing specificity are constructed.

 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

 Integration with legacy systems. If the new system has to integrate with existing
systems, care must be taken to define appropriate integration mechanisms. This property
is clearly of marketing importance but has substantial architectural implications. For
example, the ability to integrate a legacy system with an HTTP server to make it
accessible from the Web has been a marketing goal in many corporations over the past
decade. The architectural constraints implied by this integration must be analyzed.

Page 119



which portions should be stubbed? By using the architecture as a guide, a sequence of
implementation becomes clear.

 First, implement the software that deals with the execution and interaction of
architectural components. This may require producing a scheduler in a real-time system,
implementing the rule engine (with a prototype set of rules) to control rule firing in a
rule-based system, implementing process synchronization mechanisms in a multi-process
system, or implementing client-server coordination in a client-server system.

 Often, the basic interaction mechanism is provided by third-party middleware, in which
case the job becomes ones of installation instead of implementation. On top of this
communication or interaction infrastructure, you may wish to install the simplest of
functions, one that does little more than instigate some rote behavior. At this point, you
will have a running system that essentially sits there and hums to itself, but a running
system nevertheless. This is the foundation onto which useful functionality can be added.

 You can now choose which of the elements providing functionality should be added to
the system. The choice may be based on lowering risk by addressing the most
problematic areas first, or it may be based on the levels and type of staffing available, or it
may be based on getting something useful to market as quickly as possible.

 Once the elements providing the next increment of functionality have been chosen, you
can employ the uses structure to tell you what additional software should be running
correctly in the system (as opposed to just being there in the form of a stub) to support
that functionality.

 This process continues, growing larger and larger increments of the system, until it is all in
place. At no point is the integration and testing task overwhelming; at every increment it is
easy to find the source of newly introduced faults. Budgets and schedules are more
predictable with smaller increments, which also provide management and marketing with
more delivery options.

 Even the stubbed-out parts help pave the way for completion. These stubs adhere to the
same interfaces that the final version of the system requires, so they can help with
understanding and testing the interactions among components even in the absence of
high-fidelity functionality.

 These stub components can exercise this interaction in two ways, either producing hard
coded canned output or reading the output from a file. They can also generate a synthetic
load on the system to approximate the amount of time the actual processing will take in
the completed working version.

 This aids in early understanding of system performance requirements, including

Page 120



performance interactions and bottlenecks.

--- END---

Similer Documents