Question#10

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. The architecture of a software system is
a metaphor, analogous to the architecture of a building.

Architectural Structure:
Architecture of software directly affects system-wide properties like availability, reliability,
security, etc. Well- structured software also supports requirements for change, reusability,
interoperability with other systems, etc. If all different requirements were supported by the same
architectural structure it would be impossible to satisfy them independently. And indeed, this is
often the case. For example, requirements concerning performance and reliability interact since
software execution structure affects both kinds of requirements. Software exists in multiple
component domains as a set of modules, a set of set threads, a set of processes, a set of files,
etc. In each component domain a system can form a different structure. Often system
requirements may be grouped so that requirements in different groups may be addressed by
different and at least partly independent software structures established by partitions of software
in different component domains. Such partitions exist simultaneously and often are independent
of each other. A few examples: Run-time requirements are addressed by partitioning software
into execution threads of varying priority (or utility), specifying thread scheduling policies,
regulating use of shared resources, etc.
Portability requirements are addressed by defining software layers and establishing
conformance of layers and their interfaces to existing standards. Reuse requirements are
addressed by partitioning software into modules - substitutable, unit-testable components
having well-defined boundaries, predictable interaction with the environment, and minimal, well-
specified dependencies on other modules.

Question#11
Software architecture is the defining and structuring of a solution that meets technical
and operational requirements. Software architecture optimizes attributes involving a
series of decisions, such as security, performance, and manageability. These decisions
ultimately impact application quality, maintenance, performance, and overall success.
Explanation:

Software architecture is a structured framework used to conceptualize software

elements, relationships, and properties. This term also references software architecture
documentation, which facilitates stakeholder communication while documenting early
and high-level decisions regarding design and design component and pattern reuse for
different projects. The software architecture process works through the abstraction and
separation of these concerns to reduce complexity.
Architecture Description Language (ADL) describes software architecture. Different
ADLs are developed by various organizations. Common ADL elements are connectors,
components and configuration. Software architecture is about making fundamental structural
 choices that are costly to change once implemented. Software architecture choices include specific
structural options from possibilities in the design of the software. For example, the systems that
controlled the Space Shuttle launch vehicle had the requirement of being very fast and very reliable.
Therefore, an appropriate real-time computing language would need to be chosen. Additionally, to
satisfy the need for reliability the choice could be made to have multiple redundant and
independently produced copies of the program, and to run these copies on independent hardware
while cross-checking results.

QUESTION#12
Architectural model:
An architectural model is a type of scale model – a physical representation of a structure – built to
study aspects of an architectural design or to communicate design ideas. Depending on the
purpose, models can be made from a variety of materials, including blocks, paper, and wood, and at
a variety of scales.

Reference model
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. Arising from experience, reference models are a
characteristic of mature domains. Can you name the standard parts of a compiler or a
database management system? Can you explain in broad terms how the parts work
together to accomplish their collective purpose? If so, it is because you have been taught a
reference model of these applications.

Reference architecture:

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. The mapping may be, but by no means necessarily is, one to one. A software
element may implement part of a function or several functions.

Question#13
Module based structure:
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.

Explanation:

 A program module (common module, object module, object manager module, form module,
command module, and so on) can have the following sections ordered as listed below:

 module header
 variable description section
 export procedures and functions of the module, which comprise its program interface
 event handlers of an object (form)
 internal procedures and functions of the module
 initialization section

Some sections only appear in modules of specific types. For example, event handlers of form
items can only exist in form modules, while the variable description and initialization sections
cannot be defined in nonglobal common modules, object manager modules, record set
modules, constant value modules, or the session module.

Dividing the module code into sections makes the code easier to read and modify for different
authors (developers), both during group development and during application customization
within specific deployment projects.

Question#14:

Software Architecture:

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.

Architecture business cycle:

“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 the architecture and back
to the environment, the Architecture Business Cycle (ABC).”

1.The organization goals of Architecture Business Cycle are beget requirements, which beget
an architecture, which begets a system. The architecture flows from the architect's experience
and the technical environment of the day.

 
2.Three things required for ABC are as follows:

i. Case studies of successful architectures crafted to satisfy demanding requirements, so as to

help set the technical playing field of the day.

ii. Methods to assess an architecture before any system is built from it, so as to mitigate the
risks associated with launching unprecedented designs.

 iii.Techniques for incremental architecture-based development, so as to uncover design flaws

before it is too late to correct them.

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.

Question#15:
Architectural model:
An architecture model is a partial abstraction of a system. It is an approximation, and it captures
the different properties of the system. It is a scaled-down version and is built with all the
essential details of the system. Architecture modeling involves identifying the characteristics of
the system and expressing it as models so that the system can be understood. Architecture
models allow visualization of information about the system represented by the model. The
modeling process can be bottom up/inside out, by which details of the system are built utilizing
knowledge about components and interconnections and how they compose together to realize
the characteristics of the system. Alternatively, it can be top-down/outside in, by which details of
the components and interconnections are extracted from knowledge of the whole.

Reference Model:

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. Arising from experience, reference models are a characteristic of mature
domains. Can you name the standard parts of a compiler or a database management system?
Can you explain in broad terms how the parts work together to accomplish their collective
purpose? If so, it is because you have been taught a reference model of these applications.

Reference Architecture:

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. The mapping may be, but by no
means necessarily is, one to one. A software element may implement part of a function or
several functions.

Relationship:

Question#16:

Software process is the term given to the organization, ritualization, and management of
software development activities. What activities are involved in creating a software architecture,
using that architecture to realize a design, and then implementing or managing the evolution of
a target system or application. These activities include the following:

 Creating the business case for the system

 Understanding the requirements
 Creating or selecting the architecture
 Documenting and communicating the architecture
 Analyzing or evaluating the architecture
 Implementing the system based on the architecture
 Ensuring that the implementation conforms to the architecture