1. How do I assess an architectural style that has been derived?

Design process provides a software engineer with many architecture alternatives. One has to be in a position
to assess these alternatives. A set of design criteria has to be established to do the same.
The following two questions/criteria help us get an insight into an architecture style. All these questions can
be categorized relevant to either:
Control
Data
Control relevant questions/criteria:
How is controlmanaged within the architecture?
Does a distinct control hierarchy exist?
What is the role of components within this control hierarchy?
How do components transfer control within the system?
How is control shared among components?
What is the control topology (the geometric form the control takes)?
Is control synchronizedor do components operate asynchronously?
Data relevant questions/criteria:
How are data communicated between components?
Is the flow of data continuous, or are data objects passed to the system sporadically?
What is the mode of data transfer (i.e., are data passed from one component to another or are
data available globally to be shared among system components)?
Do data components (e.g., a blackboard or repository) exist, and if so, what is their role?
How do functional components interact with data components?
Are data components passive or active (i.e., does the data component actively interact with other
components in the system)?
How do data and control interact within the system?
2. How do systems interoperate with one another?

Referring to the above figure, the systems that interoperate with the target system (system for which the
architecture design is to be developed) are represented as:
Superordinate systemsthose systems that use the target system as part of some higher-level
processing scheme.
Subordinate systemsthose systems that are used by the target system and provide data or
processing that are necessary to complete target system functionality.
Peer-level systemsthose systems that interact on a peer-to-peer basis (i.e., information is either
produced or consumed by the peers and the target system.
Actorsentities (people, devices) that interact with the target system by producing or consuming
information that is necessary for requisite processing. Each of these external entities communicates
with the target system through an interface (the small shaded rectangles).
3. What happens after the architecture has been created?
Once a software engineer creates an architecture for the target system, the focus now has to be on refining
that architecture design. An optimal design that doesnt work has questionable merit and hence architecture
design refinement is of high significance.
This refinement process should be concerned with developing a representation of software that will meet:
all functional and performance requirements and
merit acceptance based on design measures and heuristics.
Best time to do Architecture Refinement: Refinement of software architecture during early stages of design is
to be encouraged. Alternative architectural styles may be derived, refined, and evaluated for the best
approach. This approach to optimization is one of the true benefits derived by developing a representation of
software architecture.
Goal of refinement: Design refinement should strive for the smallest number of components that is consistent
with effective modularity and the least complex data structure that adequately serves information
requirements.
4. The terms architectural style, architectural pattern, and framework are often encountered in discussions
of software architecture. explain them
Architecture Style:
The software that is built for computer-based systems exhibits one of manyarchitectural styles. Each style
describes a system category that encompasses
(1) aset of components (e.g., a database, computational modules) that perform a functionrequired by a
system;
(2) a set of connectors that enable communication, coordinationand cooperation among components;
(3) constraints that define how componentscan be integrated to form the system; and
(4) semantic models that enable adesigner to understand the overall properties of a system by analyzing
the knownproperties of its constituent parts.
An architectural style is a transformation that is imposed on the design of an entire system. The intent is to
establish a structure for all components of the system.In the case where an existing architecture is to be
reengineered, theimposition of an architectural style will result in fundamental changes to the structure of
the software including a reassignment of the functionality of components.

Architectural Pattern:
Architectural patterns address an application-specific problem within a specific context and under a set of
limitations and constraints. The pattern proposes an
architectural solution that can serve as the basis for architectural design.
Representative examples for Architectural patterns are as follows:
Access control. There are many situations in which access to data, features, and functionality
delivered by an application is limited to specifically defined end users.From an architectural point of
view, access to some portion of the software architecture must be controlled rigorously.
Concurrency. Many applications must handle multiple tasks in a manner that simulates parallelism.
There are a number of different ways in which an application can handle concurrency, and each can
be presented by a different architectural pattern. For example, one approach is to use an
OperatingSystem-Process Management pattern that provides built-in OS features that
allowcomponents to execute concurrently. The pattern also incorporates OS functionalitythat manages
communication between processes, scheduling, and other capabilitiesrequired to achieve concurrency.
Another approach might be to define a task schedulerat the application level. A TaskScheduler pattern
contains a set of active objectsthat each contains a tick() operation [Bos00]. The scheduler periodically
invokestick() for each object, which then performs the functions it must perform before
returningcontrol back to the scheduler which then invokes the tick() operation for thenext concurrent
object.
Distribution. The distribution problem addresses the manner in which systems orcomponents within
systems communicate with one another in a distributed environment.Two subproblems are
considered: (1) the way in which entities connect to oneanother, and (2) the nature of the
communication that occurs. The most commonarchitectural pattern established to address the
distribution
problem
is
the
Brokerpattern.
Abroker
acts
asamiddlemanbetweenthe
clientcomponentandaservercomponent.The client sends a message to the broker (containing all
appropriate informationfor the communication to be effected) and the broker completes the
connection.
Persistence. Data persists if it survives past the execution of the process that createdit. Persistent
data are stored in a database or file and may be read or modified by otherprocesses at a later time. In
object-oriented environments, the idea of a persistent objectextends the persistence concept a bit
further. The values of all of the objects attributes,the general state of the object, and other
supplementary information are storedfor future retrieval and use. In general, two architectural
patterns are used to achievepersistencea DatabaseManagementSystem pattern that applies the
storage andretrieval capability of a DBMS to the application architecture or an Application LevelPersistence pattern that builds persistence features into the application architecture(e.g., word
processing software that manages its own document structure).
Before any one of the representative architectural patterns noted in the precedingparagraphs can be chosen,
it must be assessed for its appropriateness for the applicationand the overall architectural style, as well as the
context and system of forcesthat it specifies.
Architecture Framework:
An architecture framework establishes a common practice for creating, interpreting, analyzing and using
architecture descriptions within a particular domain of application or stakeholder community. An architecture

framework is an encapsulation of a minimum set of practices and requirements for artifacts that describe a
system's architecture.
An architecture framework provides principles and practices for creating and using the architecture
description of a system. It structures architects' thinking by dividing the architecture description into
domains, layers or views, and offers models - typically matrices and diagrams - for documenting each view.
This allows for making systemic design decisions on all the components of the system and making long-term
decisions around new design, requirements, sustainability and support.

5. Do some research and describe how each of these terms differs from their counterparts.
An architectural pattern, like an architectural style, imposes a transformation onthe design of an
architecture. However, a pattern differs from a style in a number offundamental ways:
(1) the scope of a pattern is less broad, focusing on one aspectof the architecture rather than the architecture
in its entirety;
(2) a pattern imposes arule on the architecture, describing how the software will handle some aspect of
itsfunctionality at the infrastructure level (e.g., concurrency);
(3) architecturalpatterns tend to address specific behavioural issues within the context ofthe architecture
(e.g., how real-time applications handle synchronization or interrupts).
Patterns can be used in conjunction with an architectural style to shape theoverall structure of a system.

6. Using a data flow diagram and a processing narrative, describe a computer-based system that has
distinct transform flow characteristics.

Library Management System

7. Define flow boundaries and map the DFD into a software architecture using the technique
Structured design is often characterized as a data flow-oriented design method because it provides a
convenient transition from a data flow diagram to software architecture. The transition from information flow
(represented as a DFD) to program structure is accomplished as part of a six-step process: (1) the type of
information flow is established; (2) flow boundaries are indicated; (3) the DFD is mapped into program
structure; (4) control hierarchy is defined;(5) resultant structure is refined using design measures and
heuristics; and (6) the architectural description is refined and elaborated.
The type of information flow is the driver for the mapping approach required in step 3. In the following
sections we examine two flow types.
Transform Flow
Recalling the fundamental system model (level 0 data flow diagram), information must enter and exit software
in an "external world" form. For example, data typed on a keyboard, tones on a telephone line, and video
images in a multimedia application are all forms of external world information. Such externalized data must
be converted into an internal form for processing. Information enters the system along paths that transform
external data into an internal form. These paths are identified as incoming flow. At the kernel of the software,
a transition occurs. Incoming data are passed through a transform center and begin to move along paths that

now lead "out" of the software. Data moving along these paths are called outgoing flow. The overall flow of
data occurs in a sequential manner and follows one, or only a few, "straight line" paths. When a segment of a
data flow diagram exhibits these characteristics, transform flow is present.
Transaction Flow
The fundamental system model implies transform flow; therefore, it is possible to characterize all data flow in
this category. However, information flow is often characterized by a single data item, called a transaction, that
triggers other data flow along one of many paths. When a DFD takes the form shown in figure, transaction
flow is present.

Transaction flow is characterized by data moving along an incoming path that converts xternal world
information into a transaction. The transaction is evaluated and, based on its value; flow along one of many
action paths is initiated. The hub of information flow from which many action paths emanate is called a
transaction center.

8. How do I build a decision table for component level design?

Decision tables are used to model complicated programming logic. They can make it easy to see that all
possible combinations of conditions have been considered; when conditions are missed, it is easy to see this.
The tables are composed of 4 parts: conditions, actions, condition alternatives (each column is a rule), and
actions for the rules.

Conditions and Actions

Rules

Conditions

Condition Alternatives

Actions

Action Entries

The process used to create a decision table is the following:

1.

Determine the number of conditions that may affect the decision. Combine rows that overlap, such as
conditions that are mutually exclusive. The number of conditions becomes the number of rows in the
top half of the decision table.

2.

Determine the number of possible actions that can be taken. That number becomes the number of
rows in the lower half of the decision table.

3. Determine the number of condition alternatives for each condition. In the simplest form of decision
table, there would be two alternatives (Y or N) for each condition
Printer troubleshooter

Rules

Conditions

Printer does not print

A red light is flashing

Printer is unrecognized

Check the power cable

Actions

Check the printer-computer cable

Ensure printer software is installed

Check/replace ink

Check for paper jam

9. Describe the OCP in your own words. Why is it important to create abstractions that serve as an
interface between components?
Open-Closed Principle (OCP) that should close for any modification of the module, but at the same time be
available for extension. Although this may be an unsound or absurd way of doing things, but its an
important process for a well- developed component-level design. Therefore, abstraction is created by the
Software Engineer, to act as a buffer between the class and the functionality that would most likely be
extended. It is a sound approach to ensuring that any of the internal code will not likely be modified in
any manner whatsoever
10. Describe the DIP in your own words. What might happen if a designer depends too heavily on
concretions?
Dependency Inversion Principle (DIP) totally depends on the abstractions and not concretions, where
the design of the abstraction will be without any form of complications very much unlike what concretion can
result if the Software Engineering depends on it on a very high scale
11. elect three components that you have developed recently and assess the types of cohesion that
they exhibit. If you had to define the primary benefit of high cohesion, what would it be?
Cohesion:
Cohesion is the single-mindedness of a component.
Within the context of component-level design for object- implies that a component or
class encapsulates only
attributes and operations that are closely related to one
another and to the class or component itself.
Types of Cohesion:
Functional. Exhibited primarily by operations, this level of cohesion occurs when a
component performs a targeted computation and then returns a result.
Layer. Exhibited by packages, components, and classes, this type of cohesion occurs
when a higher layer accesses the services of a lower layer,but lower layers do not access
higher layers.
Communicational. All operations that access the same data are defined

accessing and

within one class. In general, such classes focus solely on the data in question,
storing it.
Sequential cohesion:Elements are involved in activities such that output data from
one activity becomes input data to the next.Usually has good coupling and is easily
maintained
Temporal cohesion:Elements are involved in activities that are related in
time.Commonly found in initialization and termination modules.Elements are basically

unrelated, so the module will be difficult to reuse.

Logical cohesion:Elements contribute to activities of the same general category
(type).For example, a report module, display module or I/O module .Usually have

control coupling, since one of the activities will be selected

Sequential cohesion:Elements are involved in activities such that output data from
one activity becomes input data to the next.Usually has good coupling and is easily
maintained.

Benefit of high cohesion :

High cohesion n is good, and low cohesion is bad. The ideal situation is one where a module,
class, or component provides only one function or, at most, a very closely related set of

functions.
Improving the Design: Moving unrelated functions into their own units (i.e., module, class, or
component) would

be a good first-step in

improving the design.

12. What do we need to know about the environment as we begin UI design?

Before going design the user interface ,three golden rules are:
Place the user in control.
Reduce the users memory load.
Make the interface consistent.
These golden rules actually form the basis for a set of user interface design principles that guide this
important
aspect of software design.
1. Place the User in Control:
Define interaction modes in a way that does not force a user into unnecessary or undesired

2. Reduce

actions.
Provide for flexible interaction.
Allow user interaction to be interruptible and undoable.
Streamline interaction as skill levels advance and allow the interaction to be customized.
the users memory load.
Reduce demand on short-term memory.
Establish meaningful defaults.
Define shortcuts that are intuitive.
The visual layout of the interface should be based on a real world metaphor.
Disclose information in a progressive fashion.

3. Make the interface consistent

Allow the user to put the current task into a meaningful context.
Maintain consistency across a family of applications.
If past interactive models have created user expectations, do not make changes unless
there is a compelling reason to do so.

13. How do we learn what the user wants from the UI?
A key of all software engineering process models is this:
understand the problem before you attempt to design a solution.
In the case of user interface design, understanding the problem means understanding
(1) the people
(end users) who will interact with the system through the interface
(2) the tasks that end users must perform to do their work
(3) the content that is presented as part of the interface
(4) the environment in which these tasks will be conducted. In the sections that
Each of these elements of interface analysis with the intent of establishing a solid foundation for the
design tasks that follow.
User Analysis:
The phrase user interface is probably all the justification needed to spend some time understanding
the user
before worrying about technical matters. Information from a broad array of sources can be
used to accomplish this:
User Interviews. The most direct approach, members of the software team meet with end
users to better
understand their needs, motivations, work culture, and a myriad of other
issues. This can be
accomplished in one-on-one meetings or through focus groups.
Sales input. Sales people meet with users on a regular basis and can gather information that
will help
the software team to categorize users and better understand their requirements.
Marketing input. Market analysis can be invaluable in the definition of market segments and
an
understanding of how each segment might use the software in subtly different
ways.
Support input. Support staff talks with users on a daily basis. They are the most likely source
of
information on what works and what doesnt, what users like and what they
dislike, what
features generate questions and what features are easy to use.
The following set of questions will help you to better understand the users of a system:
Are users trained professionals, technicians, clerical, or manufacturing workers?
What level of formal education does the average user have?
Are the users capable of learning from written materials or have they expressed a desire for
classroom training?
Are users expert typists or keyboard phobic?
What is the age range of the user community?
Will the users be represented predominately by one gender?
How are users compensated for the work they perform?

14. Is there a set of basic principles that can be applied as you design a GUI?

Interface Design Principles-I:

AnticipationA WebApp should be designed so that it anticipates the uses next move.
CommunicationThe interface should communicate the status of any activity initiated by the
user
ConsistencyThe use of navigation controls, menus, icons, and aesthetics (e.g., color, shape,
layout)
Controlled autonomyThe interface should facilitate user movement throughout the WebApp,
but it should do so in a manner that enforces navigation conventions that have been
established for the application.
EfficiencyThe design of the WebApp and its interface should optimize the users work
efficiency, not the efficiency of the Web engineer who designs and builds it or the client-server
environment that executes it.
Interface Design Principles-II:

FocusThe WebApp interface (and the content it presents) should stay focused on the user

task(s) at hand.
Fitts LawThe time to acquire a target is a function of the distance to and size of the target.
Human interface objectsA vast library of reusable human interface objects has been

developed for WebApps.

Latency reductionThe WebApp should use multi-tasking in a way that lets the user proceed
with work as if the operation has been completed.
Learnability A WebApp interface should be designed to minimize learning time, and once
learned, to minimize relearning required when the WebApp is revisited.

15. How do we determine the format and aesthetics of content displayed as part of the UI?
Aesthetic Design:
Dont be afraid of white space.
Emphasize content.
Organize layout elements from top-left to bottom right.
Group navigation, content, and function geographically within the page.
Dont extend your real estate with the scrolling bar.
Consider resolution and browser window size when designing layout.