BANSAL GROUP OF INSTITUTES

Assignment

CS-VII Sem Software Architecture (CS-701)

Questions CO

Mention different quality attributes for software

Q-1 architecture to be better functional. Explain 2
anyone with an example

Q-2 Explain about common software architecture frameworks. 2

What do you understand by software components

Q-3 1
and connectors?

Q-4 Explain with an example Layered architecture. 2

What are the basic requirements for Mobile robot

Q-5 3
architecture?
Ans 1:

Quality Attributes

Quality is a measure of excellence or the state of being free from deficiencies or

defects. Quality attributes are the system properties that are separate from the
functionality of the system.

Implementing quality attributes makes it easier to differentiate a good system from

a bad one. Attributes are overall factors that affect runtime behavior, system design,
and user experience.

They can be classified as −

Static Quality Attributes

Reflect the structure of a system and organization, directly related to architecture,

design, and source code. They are invisible to end-user, but affect the development
and maintenance cost, e.g.: modularity, testability, maintainability, etc.

Dynamic Quality Attributes

Reflect the behavior of the system during its execution. They are directly related to
system’s architecture, design, source code, configuration, deployment parameters,
environment, and platform.

They are visible to the end-user and exist at runtime, e.g. throughput, robustness,
scalability, etc.

Usability
This software quality attribute helps define the ease with which users can
perform a specific task on the system (registering an account or adding an item
to the shopping cart). What issues can be seen as usability problems? These
may include inconsistency, too complicated signup process, poor error handling,
or unclear navigation, to name a few.
Ans 2:

Common software architecture frameworks:

Definition: An architecture framework is an encapsulation of a minimum set of

practices and requirements for artifacts that describe a system's architecture.
Models are representations of how objects in a system fit structurally in and behave
as part of the system.
Ans 3:

Software components and connectors:

Component is a unit of behavior. Its description defines what the component can do
and what it requires to do that job. A connector is an indication that there is a
mechanism that relates one component to another usually through relationships
such as data flow or control flow.

Component and Connector View

Introduction:-  Component and Connector (C&C) architecture view of a system has

two main elements—components and connectors. Components are usually
computational elements or data stores that have some presence during the system
execution. Connectors define the means of interaction between these components.

A C&C view of the system defines the components, and which component is
connected to which and through what connector. A C&C view describes a runtime
structure of the system—what components exist when the system is executing and
how they interact during the execution. The C&C structure is essentially a graph,
with components as nodes and connectors as edges. C&C view is perhaps the most
common view of architecture and most box-and-line drawings representing
architecture attempt to capture this view. Most often when people talk about the
architecture, they refer to the C&C view. Most architecture description languages
also focus on the C&C view.

Components:-Components are generally units of computation or data stores in the

system. A component has a name, which is generally chosen to represent the role of
the component or the function it performs.

A component is of a component-type, where the type represents a generic

component, defining the general computation and the interfaces a component of
that type must have. Note that though a component has a type, in the C&C
architecture view.
In a diagram representing a C&C architecture view of a system, it is highly desirable
to have a different repres.entation for different component types, so the different
types can be identified visually. In a box-and-line diagram, often all components are
represented as rectangular boxes. Such an approach will require that types of the
components are described separately.

It would be useful if there was a list of standard symbols that could be used to build
an architecture diagram. However, as there is no standard list of component types,
there is no such standard list.

As there are no standard notations for different component types and an architect
can use his own symbols, the type information cannot be obtained by a reader from
the symbols used. To make sure that the meanings of the different symbols is clear
to the reader, it is therefore necessary to have a key of the different symbols to
describe what type of component a symbol represents.

A component is essentially a system in its own right providing some behavior at

defined interfaces (i.e., ports) to its environment. Like any system, a component
may be complex and have a structure of its own, which can be determined by
decomposing the component. In many situations, particularly for systems that are
not too large, there may not be a need to decompose the components to determine
their internal architecture.

Connectors: - The different components of a system are likely to interact while the
system is in operation to provide the services expected of the system. After all,
components exist to provide parts of the services and features of the system, and
these must be combined to deliver the overall system functionality. For composing a
system from its components, information about the interaction between
components is necessary.

Interaction between components may be through a simple means supported by the

underlying process execution infrastructure of the operating system. For example, a
component may interact with another using the procedure call mechanism (a
connector,) which is provided by the runtime environment for the programming
language. However, the interaction may involve more complex mechanisms as well.
Examples of such mechanisms are remote procedure call, TCP/IP ports, and a
protocol like HTTP. These mechanisms require a fair amount of underlying runtime
infrastructure, as well as special programming within the components to use the
infrastructure.

A connector also has a name that should describe the nature of interaction the
connector supports. A connector also has a type, which is a generic description of
the interaction, specifying properties like whether it is a binary or n-way, types of
interfaces it supports, etc. Sometimes, the interaction supported by a connector is
best represented as a protocol. A protocol implies that when two or more
components use the connector using the protocol to communicate, they must
follow some conventions about order of events or commands, order in which data is
to be grouped for sending, error condition setc. For example, if TCP ports are to be
used to send information from one process to another (TCP ports are the connector
between the two components of process type), the protocol requires that a
connection must first be established and a port number obtained before sending
the information, and that the connection should be closed in the end. A protocol
description makes all these constraints explicit, and defines the error conditions and
special scenarios. If a protocol is used by a connector type, it should be explicitly
stated.
Ans 4:
Have you ever wondered how Google makes Gmail work in different languages all over the world?
Users can use Gmail every day in English, Spanish, French, Russian, and many more languages.

Did Google develop different Gmail applications for each country? Of course not. They developed
an internal version that does all the message processing, and then developed different external user
interfaces that work in many languages.

Google developed the Gmail application in different layers:

 There is an internal layer that does all the processing.

 There is an external layer that communicates with the users in their language. 
 There is also another layer that interacts with a database where user email messages are
stored (millions or maybe billions).
Gmail is divided into at least three layers, every one of them has a mission, and they exist
separately to handle different processes at different levels. It is an excellent example of a layered
architecture.

Ans 5:

Mobile robot requirements

 • Requirements

– (1) Must behave in a deliberate manner

– (2) Must react appropriately to it’s environment

– (3) Must anticipate uncertain information

– (4) Must be both robust and fault tolerant

– (5) Architecture must be incrementally flexible

• Typical software functions

– Acquiring and interpreting input from sensors

– Controlling the motion of all moving parts

– Planning future activities

– Responding to current difficulties

Mobile robot architectures

• Closed loop control architecture

• Layered architecture

• Implicit invocation

• Blackboard architecture

• Incremental architecture

Closed loop architecture

• Simple interconnection between sensors and actuators.

• Appropriate for rigid requirements. Eg. follow black line.

• Doesn’t scale well. Inflexible, hard to change or refine.

• Conflicts between multiple feedback loops. (eg. getting dark, near water, low battery).

Layered architecture

• User input and supervisory functions

• Global planning

• Control logic

• Navigation

• Real-world modelling via data structures

• Collective sensor integration

• Individual sensor interpretation

• Robots hardware control

Implicit invocation

• Task control architecture.

 • Hierarchy of tasks called task trees.

• Task trees are directed at one or more tasks registered to handle them.

• Task trees may be revised following exceptions etc.

Blackboard architecture

• Central repository of data reflecting real-world view/knowledge base seen by robot.

• Operated on by:

– Captain

– Navigator

– Lookout

– Pilot

– The perception subsystem

Iterative improvement approach

• Build the robot in iterative stages.

• Carefully progress the software from being overly simple and restrictive, towards showing
intelligent behaviour.

• Design the software based not on perceived needs but on observed behaviour.

• Limited knowledge about expected final behavior of robot.