Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

Q 2:what Is Software Architecture Important?

Download as docx, pdf, or txt
Download as docx, pdf, or txt
You are on page 1of 6

Q 1:What is an architecture business cycle?

Ans: • Architecture Business Cycle (ABC) “Architecture Business Cycle (ABC) is description of
a system, used to represent relationship among structures/ components of the system to the
environment in which the system is developed and implemented.”
Q 2:What is software architecture important?
Ans: Communication among stakeholders. Software architecture represents a common abstraction
of a system that most if not all of the system's stakeholders can use as a basis for mutual
understanding, negotiation, consensus, and communication.
Early design decisions. Software architecture manifests the earliest design decisions about a
system, and these early bindings carry weight far out of proportion to their individual gravity
with respect to the system's remaining development, its deployment, and its maintenance life.
It is also the earliest point at which design decisions governing the system to be built can be
analyzed.
Transferable abstraction of a system. Software architecture constitutes a relatively small,
intellectually graspable model for how a system is structured and how its elements work
together, and this model is transferable across systems. In particular, it can be applied to other
systems exhibiting similar quality attribute and functional requirements and can promote
large-scale re-use.
Q 3:List all the common software architecture structures. Explain the component connector
structure?
Ans:
View
A representation of a set of elements and the relations among them.
Structure
The set of elements itself, as they exist in software or hardware
Restrict our attention at any one moment to one (or a small number) of the software system’s
structures.
To communicate meaningfully about an architecture, we must make clear which structure or
structures we are discussing at the moment
SOFTWARE STRUCTURES

Module structures
Elements are modules, which are units of implementation.
 * 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?
Decomposition
 * shows how larger modules are decomposed into smaller ones recursively 
Uses
 * The units are: modules, procedures or  resources on the interfaces of modules
 * The units are related by the uses relation
Layered
 * "uses relations" structured into layers
Class, or generalization
 * shows the “inherits-from” or “is-an-instance-of” relations among the modules
Component-and-connector structures
Elements are runtime components (units of computation) and connectors (communication
vehicles among components)
The relation is attachment, showing how the components and connectors are hooked together
 * 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?
Process, or communicating processes
 * units are processes or threads that are connected with each other by communication,
synchronization, and/or exclusion operations
Concurrency
 * The units are components and the connectors are “logical threads”
 * A logical thread is a sequence of computation that can be allocated to a separate physical
thread .
 * This structure comprises components and connectors that create, store, and access persistent
data
Client-server
 * The components are the clients and servers, and the connectors are protocols and messages
Allocation structures
the relationship between the software elements and the elements in one or more external
environments
 * What processor does each software element execute on?
 * In what files is each element stored during development, testing, and system building?
 * What is the assignment of software elements to development teams?
Deployment
 * Shows how software (usually a process from a component-and-connector view) is assigned
to hardware-processing and communication elements
 * Relations are “allocated-to” and “migrates-to” if the allocation is dynamic
Implementation
 * how software elements (usually modules) are mapped to the file structure(s)
Work assignment
 * assigns responsibility for implementing and integrating the modules to development teams
Q 4: Define software architecture. Explain the common software architecture structure?
Ans: Software architecture refers to the fundamental structures of a software system and the
discipline of creating such structures and systems. Each structure comprises software
elements, relations among them, and properties of both elements and relations.
Module structures. Here the elements are modules, which are units of implementation. Modules
represent a code-based way of considering the system. They are assigned areas of functional
responsibility. There is less emphasis on how the resulting software manifests itself at
runtime. Module structures allow us to answer questions such as What is the primary
functional responsibility assigned to each module? What other software elements is a module
allowed to use? What other software does it actually use? What modules are related to other
modules by generalization or specialization (i.e., inheritance) relationships?
Component-and-connector structures. Here the elements are runtime components (which are the
principal units of computation) and connectors (which are the communication vehicles among
components). Component-and-connector structures help answer questions such as What are
the major executing components and how do they interact? What are the major shared data
stores? Which parts of the system are replicated? How does data progress through the system?
What parts of the system can run in parallel? How can the system's structure change as it
executes?
Allocation structures. Allocation structures show the relationship between the software elements
and the elements in one or more external environments in which the software is created and
executed. They answer questions such as What processor does each software element execute
on? In what files is each element stored during development, testing, and system building?
What is the assignment of software elements to development teams?
Q 5: Explain how the architecture business cycle works, with a neat diagram?
Ans:Working:
1. The architecture affects the structure of the developing organization. An architecture prescribes
a structure for a system; as we will see, it particularly prescribes the units of software that
must be implemented (or otherwise obtained) and integrated to form the system. 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 by 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 case study, 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.
2. The architecture can affect the goals of the developing organization. A successful system built
from it can enable a company to establish a foothold in a particular market area. The
architecture can provide opportunities for the efficient
 
production and deployment of similar systems, and the organization may adjust its goals to take
advantage of its newfound expertise to plumb the market. This is feedback from the system to
the developing organization and the systems it builds.
 
3. The architecture can affect customer requirements for the next system by giving the customer
the opportunity to receive a system (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. A Case Study in Product Line Development will show how a product line
architecture caused customers to happily compromise their requirements because they could
get high-quality software that fit their basic needs quickly, reliably, and at lower cost.
 
4. 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.
 
5. 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. The World Wide
Web is the example for the 1990s. J2EE may be the example for the first decade of the
twenty-first century. When such pathfinder systems are constructed, subsequent systems are
affected by their legacy.
 
These and other feedback mechanisms form what we call the ABC, illustrated in Figure , which
depicts the influences of the culture and business of the development organization on the
software architecture. That architecture is, in turn, a primary determinant of the properties of
the developed system or systems. But the ABC is also based on a recognition that shrewd
organizations can take advantage of the organizational and experiential effects of developing
an architecture and can use those effects to position their business strategically for future
projects.

Q 6:Explain how the software architecture affect the factors of influence.Hence or


otherwise explain ABC.
Ans:
1. The main message of this book is that the relationships among business goals, product
requirements, architects' experience, architectures, and fielded systems form a cycle with
feedback loops that a business can manage.

2. A business manages this cycle to handle growth, to expand its enterprise area, and to take
advantage of previous investments in architecture and system building.

Some of the feedback comes from the architecture itself, and some comes from the system built
from it
Q 7: Briefly explain the technical importance of software architecture. Further elaborate
on the fact that architecture is the vehicle for the stakeholders communication?
Ans: Here are the three main reasons why a good software architecture is so important when it
comes to development.
Communication among stakeholders: software architecture represents a common
abstraction of a system that most if not all of the system’s stakeholders can use as a
basis for mutual understanding, negotiation, consensus and communication.
Early design decisions: Software architecture manifests the earliest design decisions
about a system with respect to the system's remaining development, its deployment,
and its maintenance life. It is the earliest point at which design decisions governing
the system to be built can be analyzed.
Transferable abstraction of a system: software architecture model is transferable across
systems. It can be applied to other systems exhibiting similar quality attribute and
functional attribute and functional requirements and can promote large-scale re-use.

ARCHITECTURES ARE INFLUENCED BY SYSTEM STAKEHOLDERS:


 
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

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


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

Allocation structures include the following.


• Deployment. The deployment structure shows how software is assigned to hardware-
processing and communication elements. The elements are software (usually a process from a
component-and-connector view), hardware entities (processors), and communication
pathways. Relations are "allocated-to," showing on which physical units the software elements
reside, and "migrates-to," if the allocation is dynamic. This view allows an engineer to reason
about performance, data integrity, availability, and security. It is of particular interest in
distributed or parallel systems.
• Implementation. This structure shows how software elements (usually modules) are mapped
to the file structure(s) in the system's development, integration, or configuration control
environments. This is critical for the management of development activities and build
processes.
• Work assignment. This structure assigns responsibility for implementing and integrating the
modules to the appropriate development teams. Having a work assignment structure as part of
the architecture makes it clear that the decision about who does the work has architectural as
well as management implications. The architect will know the expertise required on each
team. Also, on large multi-sourced distributed development projects, the work assignment
structure is the means for calling out units of functional commonality and assigning them to a
single team, rather than having them implemented by everyone who needs them.
Q 9: With the help of a neat block diagram of ABC, explain in detail the different activities
which are involved in creating a software architecture
Ans: taken from a system description for an underwater acoustic simulation, purports to describe
that system's "top-level architecture" and is precisely the kind of diagram most often displayed
to help explain 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.

You might also like