UNIT V

APPLICATIONS
5.1 Satellite Based Navigation

The development of the system architecture for the hypothetical Satellite Navigation
System (SNS) by logically partitioning the required functionality.
To keep this problem manageable, we develop a simplified perspective of the first and
second levels of the architecture, where we define the constituent segments and
subsystems, respectively.
In doing so, we show a representative subset of the process steps and artifacts
developed, but not all of them.
Showing a more complete perspective of the specification of any of these individual
segments and their subsystems could easily require a complete book.
However, the approach that we show could be applied more completely across an
architectural level (e.g., segment or subsystem) and through the multiple levels of the
Satellite Navigation Systems architecture.
We chose this domain because it is technically complex and very interesting, more so
than a simple system invented solely as an example problem.
Today there are two principal satellite-based navigation systems in existence, the U.S.
Global Positioning System (GPS) and the Russian Global Navigation Satellite System
(GLONASS).
In addition, a third system called Galileo is being developed by the European Union.

5. 1.1 Inception
The first steps in the development of the system architecture are really systems
engineering steps, rather than software engineering, even for purely or mostly
software systems.
Systems engineering is defined by the International Council on Systems Engineering
(INCOSE) as an interdisciplinary approach and means to enable the realization of
successful systems [1].
INCOSE further defines system architecture, which is our focus here, as the
arrangement of elements and subsystems and the allocation of functions to them to
meet system requirements.
Our focus here is to determine what we must build for our customer by defining the
boundary of the problem, determining the mission use cases, and then determining a
subset of the system use cases by analyzing one of the mission use cases.
In this process, we develop use cases from the functional requirements and document
the nonfunctional requirements and constraints.
But before we jump into our requirements analysis, read the sidebar to get an
introduction to the Global Positioning System.

Requirements for the Satellite Navigation System

The process of building systems to help solve our customers problems begins with
determining what we must build.
The first step is to use whatever documentation of the problem or need our customer
has given us.
 For our system, we have been given a vision statement and associated high-level
requirements and constraints.
Vision:
o Provide effective and affordable Satellite Navigation System services for our
customers.
Functional requirements:
o Provide SNS services
o Operate the SNS
o Maintain the SNS
Nonfunctional requirements:
o Level of reliability to ensure adequate service guarantees
o Sufficient accuracy to support current and future user needs
o Functional redundancy in critical system capabilities
o Extensive automation to minimize operational costs
o Easily maintained to minimize maintenance costs
o Extensible to support enhancement of system functionality
o Long service life, especially for space-based elements
Constraints:
o Compatibility with international standards
o Maximal use of commercial-off-the-shelf (COTS) hardware and software

Defining the Boundaries of the Problem

Though minimal, the requirements and constraints do permit us to take an important

first step in the design of the system architecture for the Satellite Navigation System
the definition of its context, as shown in Figure 5 1.
This context diagram provides us with a clear understanding of the environment
within which the SNS must function.
Actors, representing the external entities that interact with the system, include people,
other systems that provide services, and the actual environment.
Dependency arrows show whether the external entity is dependent on the SNS or the
SNS is dependent on it.
 Figure 5-1 The Satellite Navigation System Context Diagram
In addition to the functional requirements, weve been given high-level non-
functional requirements that apply to portions of the functional capability or to the
system as a whole.
These nonfunctional requirements concern reliability, accuracy, redundancy,
automation, maintainability, extensibility, and service life.
Also, we see that there are some design constraints on the development of the SNS.
We maintain the nonfunctional requirements and design constraints in a textual
document called a supplementary specification; it is also used to maintain the
functional requirements that apply to more than one use case.
Another critical document that we must begin at this point is the glossary; it is
important that the development team agrees on the definition of terms and then use
them accordingly.
Even from these highly elided system requirements, we can make two observations
about the process of developing the Satellite Navigation System.
1. The architecture must be allowed to evolve over time.
2. The implementation must rely on existing standards to the greatest extent
practical.
After reviewing both the vision and the requirements, we (the architecture team)
realize that the functional requirements provided to us are really containers (packages,
in the UML) for numerous mission-level use cases that define the functionality that
must be provided by the Satellite Navigation System.
These mission use case packages provide us a high-level functional context for the
SNS, as shown in Figure 52.
These packages contain the mission use cases that show how the users, operators, and
maintainers of the SNS interact with the system to fulfil their missions.

Figure 5 2 Packages for the SNS Mission Use Cases

Determining Mission Use Cases
The vision statement for the system is rather open ended: a system to Provide
effective and affordable Satellite Navigation System services for our customers.
The task of the architect, therefore, requires judicious pruning of the problem space,
so as to leave a problem that is solvable.
A problem such as this one could easily suffer from analysis paralysis, so we must
focus on providing navigation services that are of the most general use, rather than
trying to make this a navigation system that is everything for everybody (which would
likely turn out to provide nothing useful for anyone).
We begin by developing the mission use case for the SNS.
Large projects such as this one are usually organized around some small, centrally
located team responsible for establishing the overall system architecture, with the
actual development work subcontracted out to other companies or different teams
within the same company.
Even during analysis, system architects usually have in mind some conceptual model
that divides the elements of the implementation.
Based on our experience in building satellite-based systems and in their operation and
maintenance, we believe the highest-level logical architecture consists of four
segments: Ground, Launch, Satellite, and User.
A conceptual architecture at the level of a package diagram like the one shown in
Figure 5 3, we can begin our analysis by working with domain experts to articulate
the primary mission use cases that detail the systems desired behaviour.

Figure 5-3 The SNS Logical Architecture

We say even before because, even though we have a notion of the architecture of
the SNS, we should begin our analysis from a black-box perspective so as not to
unnecessarily constrain its architecture.
That is, we analyze the required functionality to determine the mission use cases for
the SNS first, rather than for the individual SNS segments.
Then, we allocate this use case functionality to the individual segments, in what is
termed a white-box perspective of the Satellite Navigation System.
 Typically, though, our analysis employs activity diagram modelling such as that which
we perform to develop the system use cases in the following subsection.
Figure 54 depicts the result of our analysis to develop the mission use cases for the
OperateSNS mission use case package.
For the remainder of this chapter, our efforts focus on analyzing the Initialize
Operations mission use case to determine the activities that the system must perform
to provide the operator with the ability to initialize the operation of the Satellite
Navigation System.

Figure 5-4 Refining the OperateSNS Mission Use Case Package

Determining System Use Cases

we develop an activity diagram of the Initialize Operations mission use case
functionality to determine the encapsulated system use cases.
In developing this activity diagram, we do not attempt to use our notion of the
segments that comprise the SNS.
We take this approach because we do not wish to constrain our analysis of SNS
operations by presupposing possible architectural solutions to the problem at hand.
We focus on the SNS as though it were a black box into which we could not peer and
thus could see only what services it provides, not how it provides those services.
From this activity diagram, we develop the respective list of system use cases by
making experienced systems engineering judgments.
For example, we decide to combine the actions Prepare for Launch and Launch into
one system use case, Launch Satellite.
 We determine that the remaining actions embody significant system functionality and
therefore should each represent an individual system use case, giving us the system
use cases for the InitializeOperations mission use case

Figure 5-5 The Black-Box Activity Diagram for Initialize Operations

 Figure 5 6 shows the updated use case diagram.
Here we have used the InitializeOperations package to contain the system use cases
that we developed from the Initialize Operations mission use case.
The other three mission use cases that embody functionality for operating the SNS are
shown with the keyword label of mission use case.
We find this modeling approach to be useful and clear; however, each development
team needs to determine and document its chosen techniques.

Figure 5-6 System Use Cases for Initialize Operations

 Table 5-1 System Use Cases for Initialize Operations

5.1.2 Elaboration
Developing a Good Architecture
How do we know the difference between a good architecture and a bad one?Good
architectures tend to exhibit object-oriented characteristics. This doesnt mean, quite obviously, that as
long as we use object-oriented techniques, we are assured of developing a good architecture. Good
architectures, whether system or software, typically have several attributes in common.
They are constructed in well-defined layers of abstraction, each layer representing a coherent
abstraction, provided through a well-defined and controlled interface, and built on equally
well-defined and controlled facilities at lower levels of abstraction.
There is a clear separation of concerns between the interface and implementation of each
layer, making it possible to change the implementation of a layer without violating the
assumptions made by its clients.
The architecture is simple: Common behavior is achieved through common abstractions and
common mechanisms.
Simply (or not so simply) developing a good architecture for the Satellite Navigation System is
not enough; we must effectively communicate this architecture to all of its stakeholders. The Creating
Architectural Descriptions sidebar explains how we may go about this task.

Defining Architectural Development Activities

The system architecture for the Satellite Navigation System and are presented here, reworded
for our focus.
Identify the architectural elements at the given level of abstraction to further establish the
problem boundaries and begin the object-oriented decomposition.
Identify the semantics of the elements, that is, establish their behavior and attributes.
Identify the relationships among the elements to solidify their boundaries and collaborators.
Specify the interface of the elements and then their refinement in preparation for analysis at
the next level of abstraction.

Validating the Proposed System Architecture

 Beginning with the black-box activity diagram for Initialize Operations presented earlier in
Figure 55, we allocate the system functionality, shown in the SatelliteNavigationSystem partition, to
one or more of its constituent segments: Ground, Launch, Satellite, or User. Our goal is to allocate
segment use cases, derived from the system use cases, to each of the segments. This way we see SNS
functionality provided by a collaborative effort of its segments. If we assign use cases appropriately,
the individual segments exhibit core object-oriented principles, as follows.
Abstraction: Segments provide crisply defined conceptual boundaries, relative to the
perspective of the viewer.
Encapsulation: Segments compartmentalize their subsystems, which provide structure and
behaviour. Segments are black boxes to the other segments.
Modularity: Segments are organized into a set of cohesive and loosely coupled
subsystems.
Hierarchy: Segments exhibit a ranking or ordering of abstractions
The white-box activity diagram for Initialize Operations presents the results of analyzing only a
portion of the functionality contained within the OperateSNS mission use case package. What remains
are all the preparatory activities that lead up to this point and all the activities that occur afterward,
which are contained within the other three mission use cases: Provide Normal Operations, Provide
Special Operations, and Terminate Operations. However, these are not our focus in this macro-level
analysis. If they were, we would repeat our analysis techniques to specify this behavior and thereby
develop a more complete picture of how the segments cooperate to provide the Satellite Navigation
Systems operational capability.
This capability would include preparatory activities such as activating the Ground and Launch
Segments, checking the integrity of the satellite, and mating the satellite with the launcher. In addition
to this capability, we would find that the Ground Segment performs many activities during normal
operations, including the following:
Continuously monitoring and reporting system status
Continuously evaluating satellite flight dynamics and managing station keeping
Monitoring for and reporting on alarms
Managing events, including initialization and termination
Optimizing satellite operations: estimating propellant and extending satellite life
Recovering from power failure
Managing satellite quality of service
Developing operational procedures (routine and emergency)
Figure 57 The White-Box Activity Diagram for Initialize Operations
Allocating Nonfunctional Requirements and Specifying Interfaces
The nonfunctional requirements allocated to a segment use case are then, at the next lower
level in the architecture hierarchy, apportioned across its constituent subsystem use cases, employing
the same techniques used at the segment level.
Our techniques for allocating functional and nonfunctional requirements can be applied
recursively from one level to the next in the architectural hierarchyfrom the system to the segments,
to their subsystems, and so forth.
We might then ask about potential requirements alluded to by the design constraints weve
been given:
Compatibility with international standards
Maximal use of COTS hardware and software
The constraint Compatibility with international standards drove our specification of the external
actor Atmosphere/Space, as discussed earlier. We must interact with the national and international
agencies that regulate the use of the airwaves to determine, for example, the specific frequencies at
which we may communicate with the Satellite Segment, as well as the frequencies at which it may
transmit position information. This means that the Ground Segment, Launch Segment (at least during
the flight phase), and Satellite Segment now must fulfil the external interface responsibilities of the
Satellite Navigation System. We point out these issues because in the focus on functional capability,
constraints (and nonfunctional requirements) may be considered far too late in the development
cycle or sometimes even overlooked

Stipulating the System Architecture and Its Deployment

The component diagram may be used to hierarchically decompose a system, and thus it here
represents the highest-level abstraction of the Satellite Navigation System architecture, that is, its
segments and their relationships. Figure 88 illustrates two ways to represent the interface between
segments, the ball-and-socket notation (LaunchSupport interface) and the dashed dependency line
connecting the required and provided interfaces (PositionInformation interfaces). Looking back at
Figure 51, we see that three of the system actors are not accounted for by the SNS interfaces shown
in Figure 58: ExternalPower, ExternalCommunications, and Atmosphere/Space. These actors
provide important services to the Satellite Navigation System; however, they are not central to our
focus on developing its logical architecture

Figure 58 The Component Diagram for the Satellite Navigation System

Figure 5 9 shows the deployment of the components represented. We recognize that this is not a
typical use of the notation; typically, we would deploy software artifacts (such as code, a source file, a
document, or another item relating to the code) onto processing nodes. However, this diagram clearly
presents the information, and some nonstandard usage The interfaces through which the Operator,
Maintainer, and User actors interact with the Satellite Navigation System are contained within its
segments, so weve chosen to illustrate these relationships with dependencies .

Figure 59 The Deployment of SNS Segments

Decomposing the System Architecture

Our analysis techniques are presented here for completeness.
1. Perform black-box analysis for each system use case to determine its actions.
2. Perform white-box analysis of these system actions to allocate them across segments.
3. Define segment use cases from these allocated system actions.
4. Perform black-box analysis for each segment use case to determine its actions.
5. Perform white-box analysis of these segment actions to allocate them across subsystems.
6. Define subsystem use cases from these allocated segment actions.
A perspective of the black-box and white-box system analysis approach that weve used is
provided in the Similar Architectural Analysis Techniques sidebar.

The steps numbered above are to be applied horizontally across each architectural level of the
system to provide a complete, holistic view of the system that can be validated at any point along the
way. We continued our analysisnot shown hereby performing the following activities:
Performed black-box analysis for the Launch Satellite system use case to determine its actions
Performed white-box analysis of these system actions to allocate them across segments
Defined GroundSegment use cases from these allocated system actions
Performed black-box analysis for the GroundSegments Control Launch use case to determine
its actions
 Performed white-box analysis of the GroundSegments Control Launch actions to allocate
them across its subsystems

Figure 511 The Logical Architecture of the GroundSegment

Figure 512 The Logical Architecture of the LaunchSegment

5.1.3 Construction
At the end of the Elaboration phase, a stable architecture of our system should have been
developed. Any modifications to the system architecture that are required as a result of activities in the
Construction phase are likely limited to those of lower-level architectural elements, not the segments
and subsystems of the Satellite Navigation System that have been our concern.
In line with the stated intent of this chapterto show the approach to developing the SNS
system architecture by logically partitioning the required functionality to define the constituent
segments and subsystemswe do not show any architectural development activities in this phase.

5.1.4 Post-Transition
The Satellite Navigation Systems original nonfunctional requirements included two that
caused us to develop a flexible architecture: extensibility and long service life. This long service life
dictates, in addition to many other aspects, a design that is extensible to ensure the reliable provision
of desired functionality. As there are more users of the Satellite Navigation System, and as we adapt
this design to new implementations, they will discover new, unanticipated uses for existing
mechanisms, creating pressure to add new functionality to the system. We now investigate how well
our SNS design has met these requirements as we add new functionality and also change the systems
target hardware.

5.2