Architectural design:

 When we begin architectural design, the software to be developed must be put into context
that is, the design should define the external entities (other systems, devices, people)that the
software interacts with and the nature of the interaction.
 This information can generally be acquired from the analysis model and all other information
gathered during requirements engineering.
 Once context is modeled and all external software interfaces have been described, the designer
specifies the structure of the system by defining and refining software components that
implement the architecture. This process continues iteratively until a complete architectural
structure has been derived.
1. Representing the System in Context:
 At the architectural design level, a software architect uses an architectural context diagram
(ACD) to show how the software interacts with things (external entities) outside of it. The
generic structure of the architectural context diagram is illustrated in Figure 10.5.Referring to
the figure, systems that interoperate with the target system (the system for which an
architectural design is to be developed) are represented as:

• Superordinate systems—those systems that use the target system as part of some higher
level processing scheme.
• Subordinate systems—those systems that are used by the target system and provide data or
processing that are necessary to complete target system functionality.
 • Peer-level systems—those systems that interact on a peer-to-peer basis (i.e., information is
either produced or consumed by the peers and the target system).
• Actors—those entities (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).

To illustrate the use of the ACD we again consider the home security function of the SafeHome
product.

1. SafeHome Security Function:

Think of SafeHome as a security system for a house. It has different parts that work together to keep
the home secure.

2. Components in the ACD (Architectural Context Diagram):

In the diagram (Figure 10.6), you have the main controller for the entire SafeHome product and an
Internet-based system that are like bosses overseeing everything.

The security function is like the superhero in charge of keeping the home safe.

3. Surveillance Function:

There's another superhero called the surveillance function. It works alongside the home security
function, and they help each other out.

4. Homeowner and Control Panels:

The people who own the house (homeowners) and the control panels they use are like actors in a
play. They both give and receive information from the security system. For example, a homeowner
might tell the system to activate or deactivate.

5. Sensors:

There are sensors in the house, like motion detectors or door alarms. These sensors are the eyes and
ears of the security system. They give information to the security software.

As part of the architectural design, the details of each interface shown in Figure 10.6 would
have to be specified. All data that flow into and out of the target system must be identified at
this stage
 Putting It Together:

In this architectural design, we're figuring out how all these parts talk to each other. The big
boss (controller), the internet system, the security function, surveillance, homeowners, control
panels, and sensors - they all have to work together smoothly.

 Specifying Interfaces:

As part of the design, we need to say exactly how these parts connect. For example, we'd need
to figure out how information flows between the surveillance function and the home security
function.

 Identifying Data Flow:

We also need to be clear about what information goes in and out. For instance, what data do
the sensors send to the security system, and what does the security system tell the control
panel?

2. Defining Archetypes
 An archetype is a class or pattern that represents a core abstraction that is critical to the design
of architecture for the target system.
 The target system architecture is composed of these archetypes, which represent stable
elements of the architecture.
 Archetypes can be derived by examining the analysis classes defined as part of the analysis
model.

For SafeHome home security function, we can have the following archetypes:
 Node: Represents a cohesive collection of input and output elements of the home
security function. For example a node might be comprised of

(1) Various sensors

(2) A variety of alarm (output) indicators.

 Detector: An abstraction that encompasses all sensing equipment that feeds

information into the target system.

 Indicator: An abstraction that represents all mechanisms (e.g., alarm siren, flashing
lights, bell) for indicating that an alarm condition is occurring.

 Controller: An abstraction that depicts the mechanism that allows the arming or
disarming of a node. If controllers reside on a network, they have the ability to
communicate with one another.

Each of these archetypes is depicted using UML notation as shown in Figure 10.7.

3. Refining the Architecture into Components:

 The architectural designer begins with the classes that were described as part of the
analysis model. These analysis classes represent entities within the application
(business) domain that must be addressed within the software architecture.
 The application domain is one source for the derivation and refinement of
components.
 Another source is the infrastructure domain. The architecture must accommodate
many infrastructure components that enable application components but have no
business connection to the application domain.
For example: Memory management components, communication components,
database components, and task management components are often integrated into the
software architecture.
The interfaces depicted in the architecture context diagram imply one or more
specialized components that process the data that flow across the interface.

Example: Safe Home home security function we can define the set of top-level
components that address the following functionality:
• External communication management—coordinates communication of the security
function with external entities, for example, Internet-based systems, external alarm
notification.
• Control panel processing—manages all control panel functionality.
• Detector management—coordinates access to all detectors attached to the system.
• Alarm processing—verifies and acts on all alarm conditions.

Each of these top-level components would have to be elaborated iteratively and then
positioned within the overall Safe Home architecture. Design classes (with appropriate
attributes and operations) would be defined for each.
The overall architectural structure (represented as a UML component diagram) is
illustrated in Figure 10.8.
External Communication Management:

This part deals with handling information coming in from different sources, like the SafeHome user
interface and the internet.

SafeHome Executive:

This is like the brain of the system. It decides what needs to happen based on the information it
gets. For example, if there's a security issue, it selects the right function to deal with it.

Control Panel Processing:

This is the part that interacts with the person using SafeHome (the homeowner). It manages actions
like arming or disarming the security system, essentially controlling what the system does.

Detector Management:

This component regularly checks sensors placed around the house. These sensors could be things
like motion detectors or door sensors. Their job is to figure out if there's anything unusual going on,
like an intruder.
Alarm Processing:

If a sensor detects something alarming (like a break-in), this part takes over. It processes that
information and decides what to do next. It might trigger an alarm to alert the homeowner or a
security service.

4. Describing Instantiations of the System:

Up to this point we have created a basic blueprint, or architecture, for a security system called Safe
Home. We have defined the main parts and how they connect, but it's still somewhat general.

In software engineering "instantiating the system" refers to taking a conceptual or high-level design
of a software system and implementing it in a specific, detailed way.

We need to get more specific. We are going to take our blueprint and apply it to a real example, like a
practical problem that the security system needs to solve. This is what we mean by "instantiating" the
architecture.

In the (Figure 10.9), we are taking each part of SafeHome and adding more details to it. For instance,
the part that manages detectors (like motion sensors) now works closely with a scheduler, which is
like a time manager. This scheduler makes sure that the detectors are regularly checking for any
issues.

In simpler terms, we are refining our original plan by adding more specific information. So, instead of
just saying "there is a part that deals with detectors," we are now explaining exactly how it interacts
with a scheduler to make sure it's doing its job properly. We are doing this kind of detailed work for
each part of the system.