SOFTWARE ARCHITECTURE AND DESIGN QUESTIONS &
ANSWERS
1.
Question 1. What Are The Major Issues Associated With Managing
Product Line Evolution?
Answer :
Adopting a product line paradigm
creates an organizational shift. Managing product line evolution is the most
difficult part of the paradigm. The product line will change as new versions of
the current product come out. An organization would need to use the new
versions to satisfy changing client needs. Additionally, new improvements to
various components may change the way the products are built. New version of components
may not be entirely backward compatible, thus additional rework will need to be
done to accommodate the changes.
2.
Question 2. What Is The Basic Approach To Problem Solving In The
Blackboard Framework?
Answer :
The blackboard framework is a dynamic
group of independent entities that communicate and work together in order to
solve some common problem. The knowledge sources adds a solution piece to the
blackboard data structure when they (independently) think it’s appropriate.
There is no centralized control mechanism that makes decisions as to when a
knowledge source needs to contribute some piece of information. Rather the
control entity states the conditions of when and each knowledge source need to
contribute. The knowledge sources observe the commotion on the blackboard and
contribute to progress independently.
3.
Question 3. What Are The Components Of The Blackboard Model?
Answer :
The blackboard model is usually
composed of three components: knowledge sources, blackboard data structure, and
control. The knowledge source component represents the chunks of information
that is needed in order to solve a problem. These sources are separate from
each other. The blackboard data structure can be looked at as a repository for
the final solution. In this storage receptacle the final solution is slowly
developed based on the sources and controls used. The control is not a module,
but rather a mechanism or an abstract algorithm that specifies how a problem
will be solved.
4.
Question 4. In Addition To The Architecture Itself, What Are The
Assets That Can Be Considered As Members Of A Product Line?
Answer :
A collection of assets includes the
following elements:
o Components – this asset does not directly deal
with re-use of code, it encompasses and utilizes all elements of previously
built successful parts (components) of the system. This includes re-use of
design, documentation, structure, and etc. of components.
o Personnel – when the products have the same
structure, then workers can shift from project to project and be able to
quickly understand and adapt to changes.
o Defect elimination – when a component is re-used in
different projects, eliminating a fault in one component solves problems in
multiple projects.
o Project Planning – previous experiences help
planning.
o Performance – these issues are similar from
product to product. Predictability increases.
o Processes, methods, and tools – re-use occurs extensively, as the
way components have been developed before is well known and understood.
o Exemplar systems – the benefit of seeing systems in
action and in operation shows that an organization can deliver on its promises.
5.
Question 5. What Is The Main Function Of The Hla?
Answer :
The main function of the High Level
Architecture is to establish a common infrastructure, or the foundation, for a
building other components of a system. The infrastructure is then used and
re-used by other components of a system that rely on communication and other
resources through HLA. This non-software blueprint of a system has been used by
the AMG to create an environment that supports interoperability and
reusability. Interface specification is used to coordinate communication
efforts of various components that are built on top of the HLA.
6.
Question 6. When Is Middleware Not Appropriate?
Answer :
Middleware can get very complex and
difficult to develop. The difficulties arise from the need to know the location
of the servers and the amount of low-level details exposed. Certain domain
specific systems with hard real-time systems may not afford to use a middleware
services as that may slow down transaction speeds between an OS and
applications. If a development company does not trust the middleware vendors,
due to the secrecy of client’s data transmitted between databases and some applications,
then that company may need to implement such middleware layer in-house.
7.
Question 7. What Kinds Of Changes Are Difficult For An
Object-oriented System To Handle?
Answer :
Managing changes to an object’s
identify is the most significant disadvantage of an object-oriented system. If
an identify of an object changes, then all other objects that use that identify
must be updated in order to reflect the change in just one object.
Manageability of various objects becomes a major issue.
8.
Question 8. Can An Object (in The Architectural Sense) Have
Multiple Interfaces? Is Such A Feature Desirable?
Answer :
Yes, an object can have multiple
interfaces. From an architectural point of view there are advantages to having
multiple interfaces. Because an object preserves the integrity of data it
contains, the only way to send messages to that object is via interfaces. Thus
if some object A wants to communicate with some other object B, then it has to
talk through an interface. One interface does not fit the needs of all objects,
thus it is useful to have multiple interfaces to promote communication between
different objects that have different requirements.
9.
Question 9. How Can The Activity Of A Filter Be Triggered?
Answer :
The activity of a filter is triggered
when there is information to be processed. When the pipe runs dry and no
information is incoming a filter may fall asleep until more information
arrives. Additionally, feedback and feedforward controls are responsible for
continuing feeding information back into a filter.
10.
Question 10. What Problems Does Architecture Analysis Solve?
Answer :
Software defects that lead to security
problems come in two major flavors:
o bugs in the implementation and
o flaws in the design.
Implementation bugs in code account for
at least half of the overall software security problem. The other half involves
a different kind of software defect occurring at the design level. The division
of design flaws and bugs is about 50/50. Both need to be secured to ensure your
software’s well-being. You can institute the best code review program on the
planet, with the strongest tools known to humanity, but it’s unlikely that you
will be able to find and fix flaws this way.
4 ways to identify flaws
o Analyze fundamental design principles.
o Assess the attack surface.
o Enumerate various threat agents.
o Identify weaknesses and gaps in security
controls.
It is far more cost-effective to
identify and remediate design flaws early in the design process than to patch
flawed design implementations after deployment. Architecture risk analysis
(ARA), Threat Modeling, and Security Control Design Analysis (SCDA) are useful
in finding and fixing design flaws.
SCDAs are a light-weight approach to
ARA. They take less time to conduct and can be carried out by a much larger
talent pool than traditional ARA reviews. Most importantly, the lightweight
approach is efficient enough that it can be scaled to cover an entire
application portfolio.
Organizations failing to integrate
architecture and design reviews in the development process are often surprised
to find that their software suffers from systemic faults both at the design
level and in the implementation. In many cases, the defects uncovered in
penetration testing could have been identified more easily through other
techniques—earlier in the life cycle. Testers who use architecture analysis
results to direct their work often reap greater benefit.
11.
Question 11. What’s The Relationship Between Software Architecture
And Software Design?
Answer :
Software architecture exposes the
structure of a system while hiding the implementation details. Architecture
also focuses on how the elements and components within a system interact with
one other. Software design delves deeper into the implementation details of the
system. Design concerns include the selection of data structures and
algorithms, or the implementation details of individual components.
Architecture and design concerns often
overlap. Rather than use hard and fast rules to distinguish between architecture
and design, it makes sense to combine them. In some cases, decisions are
clearly more architectural in nature. In other cases, decisions focus heavily
on design and how it helps to realize that architecture.
An important detail to note is that
architecture is design, but not all design is architectural. In practice, the
architect is the one who draws the line between software architecture
(architectural design) and detailed design (non-architectural design). There
are no rules or guidelines that fit all cases—although, there have been
attempts to formalize the distinction.
Current trends in software architecture
assume that the design evolves over time and that a software architect cannot
know everything up front to fully architect a system. The design generally
evolves during the implementation stages of the system. The software architect
continuously learns and tests the design against real world requirements.
12.
Question 12. What Is Software Design?
Answer :
Software design is the process of
conceptualizing the software requirements into software implementation. This is
the initial phase within the software development life cycle (SDLC)—shifting
the concentration from the problem to the solution.
When conceptualizing the software, the
design process establishes a plan that takes the user requirements as
challenges and works to identify optimum solutions. The plan should determine
the best possible design for implementing the intended solution.
Software design includes all activities
that aid in the transformation from requirement specification to
implementation.
Major artifacts of the software design
process include:
Software requirements specification: This document describes the
expected behavior of the system in the form of functional and non-functional
requirements. These requirements should be clear, actionable, measurable, and
traceable to business requirements. Requirements should also define how the
software should interact with humans, hardware, and other systems.
High-level design: The high-level design breaks the
system’s architectural design into a less-abstracted view of sub-systems and
modules and depicts their interaction with each other. This high-level design
perspective focuses on how the system, along with all its components,
implements in the form of modules. It recognizes the modular structure of each
sub-system and their interaction among one another.
Detailed design: Detailed design involves the
implementation of what is visible as a system and its sub-systems in a high-level
design. This activity is more detailed towards modules and their
implementations. It defines a logical structure of each module and their
interfaces to communicate with other modules.
13.
Question 13. What Is Software Architecture?
Answer :
The software architecture of a system
depicts the system’s organization or structure, and provides an explanation of
how it behaves. A system represents the collection of components that
accomplish a specific function or set of functions. In other words, the
software architecture provides a sturdy foundation on which software can be
built.
A series of architecture decisions and
trade-offs impact quality, performance, maintainability, and overall success of
the system. Failing to consider common problems and long-term consequences can
put your system at risk.
There are multiple high-level
architecture patterns and principles commonly used in modern systems. These are
often referred to as architectural styles. The architecture of a software
system is rarely limited to a single architectural style. Instead, a
combination of styles often make up the complete system.
14.
Question 14. How Do Engineering Disciplines Evolve?
Answer :
The engineering disciplines evolve from
ad hoc state in two steps. Initially, talented and passionate amateurs pioneer
the discipline. They achieve their goals by all means necessary – usually
irrationally using available resources. Later the routine production occurs.
With time the need for advancement arises and supporting science for an
engineering discipline emerges. The maturing science eventuallys turn into a
“professional engineering practice,” where science will become the main driving
force of a discipline.
15.
Question 15. What Are Four Methods That Are Commonly Used By
Architects To Build Systems?
Answer :
Normative, rational, argumentative,
heuristic methodologies. The selection of the four methods depends on the
circumstances of the project and a problem at hand. The first two methodologies
are widely practiced in engineering institutions.
16.
Question 16. What Influences Architect’s Decisions?
Answer :
Architect’s decisions are influenced by
the system stakeholders, technical environment, problem domain area,
organization’s intellectual assets, architect’s education and experience, and
politics.
17.
Question 17. Why Do You Need To Have Multiple Views To Accurately
Describe System Architecture?
Answer :
Each view has a specific goals and a
purpose; each view accomplishes different objectives. Multiple views of a
system provide an abstraction – a developer does not always need to see the
whole system and all of its components. Additionally, different stakeholders
need different views to understand their role in the system. This promotes
understanding for all stakeholders and saves time, as some stakeholders may not
care at all about someone else’s view. Finally, multiple views allow for a more
concrete view. It is not possible to fit all components of the system on one
sheet of paper and make clear sense of it.
18.
Question 18. What Are The Principles Of Good Architectural
Documentation?
Answer :
o Statement of requirements establishes
the problem boundary, puts the problem in perspective and explains why the work
to be done makes sense. This is the most critical part of documentation as it
gives a reader the perspective of a problem.
o Description of context provides a list
of inputs and outputs that will interact with a system at stake. Additionally,
this description shows the interfaces of the external systems.
o Use of architectural diagrams allows
for improved communication and understanding of a system to be developed. The
diagrams depict a developer’s imagination, and allow others to see how an
original developer envisioned a system.
o Consideration of implementation-level
constraints prevents developers from fantasizing about a system that cannot be
implemented. If a developer is working with a data-oriented repository style
some of the implementation-level constraints may depend on hardware. Addressing
these issues early build confidence among many stakeholders – to convince them
that a system at stake is indeed possible.
o Rationale for architectural design
discusses different options and considerations that were entertained before a
set architecture was chosen. Keeping a record of the rationale is important, as
new employees or system maintainers will question the decisions later.
19.
Question 19. What Is The Essential Role Of A Software Architect?
Answer :
Making the right decisions at the right
time is the chief responsibility of a software architect. Specifically the
architect must evaluate various design options in light of overall system
objectives and constraints. Each architectural decision has its benefits and
costs, and since it is not possible to achieve all quality attributes that one
may desire, an architect must make tradeoffs between available options.
20.
Question 20. What Is The Difference Between Routine And Innovative
Design?
Answer :
Routine design aims at “solving
familiar problems” and designing solutions by using the knowledge base from
previous projects and experiences. For example, an accounting (payroll) system
would most likely involve routine design; as such systems have been in
production for a long time and are well understood. Routine design involves a
lot of re-use and occurs much more frequently than an innovative design that
requires original thinking. Innovative design is opposite of routine design,
and aims at solving problems that do not have any previous knowledge base.
Innovative design aims at solving original and unique problems, such as
controlling an unmanned helicopter through a remote control center.
21.
Question 21. When Should You Seriously Consider Using The Process
Control Paradigm To Organize A Software System (or Part Of One)?
Answer :
Process control paradigm is ideal for
the systems that require continuous monitoring of certain output values. In
such systems the output values need to be at a specified range in order for the
system to function. This paradigm may be applied to real-time systems, where
the timing is a critical element of system requirements. An autopilot system is
a good candidate for process control paradigm. Altitude control element of an
autopilot system is an example of a closed-loop system, as the system must be
running continuously (reading information from sensors and processing acting
accordingly). A set point of such system would be a specified attitude, and an
input variable would be the data from the altimeter. The manipulated variables
would be the engine thrust and the elevators of an airplane. The goal of the
system would be to maintain the specified altitude (controlled variable) to
ensure a smooth flight.
22.
Question 22. How Do You Reason About The Functionality Of Pure
Pipe-and-filter Systems? For Example, If Filter F With Input Stream X Delivers
The Output Stream F(x), What Does The Following Compute? Why?
Answer :
The nature of the pure pipe-and-filter
systems allows an architect to construct complex data flow system from simpler
components. This method allows an architect to understand, in detail, the
properties of simpler components. Additionally, an architect can start from a
simple system with just a few components, and then build up a more complex
system. We can reason about the example in the following manner. It is given
that when the input stream X enters filter F, the output stream will be F(X).
The output stream F(X) sequentially becomes an input stream to filter G, and
the output stream of filter G is G(F(X)). In a similar manner the input stream
G(F(X)) enters filter H and the final output stream of the system is
H(G(F(X))). The following computation leads to the final result by using the
results of previous computation.
23.
Question 23. What Is An Open Proprietary Architectural Standard?
Answer :
An open proprietary architectural
standard is promoted by Morris and Ferguson who make case for open systems
where the “complex of standards and rules” would be freely published. This open
standard would allow anyone to see how the system was designed and constructed.
This open-ended architecture would allow the software to evolve, because any
enhancements to the software would have to adhere to a defined architectural,
and freely available, standard. An example of an open proprietary product is
the CCITT fax standard and the NTSC television standard. An example of a closed
proprietary product is Adobe’s PDF file format and Windows 2000 OS, as no one
but the company can make changes to the architecture.
