App 1
App 1
App 1
a detailed overview of the process of developing a system architecture for a satellite-based navigation
system, focusing on principles of object-oriented analysis and design. Here's a breakdown of key points:
1. Object-Oriented Principles: The passage emphasizes that the principles of object-oriented analysis
and design, as well as UML notation, are applicable not just to software development but also to the
development of system architecture. This means that the approach involves understanding system
requirements and partitioning the system into segments or subsystems.
2. Abstraction and Scope: System architecture concerns are described as abstract, large in scope, and
impactful, but not involved in implementation or technology details. The focus is on creating a
system with long-term viability, operability, maintainability, and extensibility.
3. Satellite Navigation System Example: The example used in the text is the development of a
Satellite Navigation System (SNS). The choice of this domain is based on its technical complexity
and interest, compared to simpler invented examples. The text mentions existing satellite-based
navigation systems like the U.S. GPS, Russian GLONASS, and the European Galileo system.
4. Inception Phase: The first steps in developing the system architecture are categorized as systems
engineering rather than software engineering. The focus is on defining the problem boundary,
determining mission and system use cases, developing functional and nonfunctional requirements,
and identifying constraints.
5. Systems Engineering Approach: The International Council on Systems Engineering (INCOSE)
defines systems engineering as an interdisciplinary approach to enabling successful systems
realization. System architecture, within this context, involves arranging elements and subsystems and
allocating functions to meet system requirements.
This passage sets the stage for the subsequent development of the system architecture, highlighting the
importance of understanding requirements, abstraction, and the interdisciplinary nature of systems
engineering.
1. INCEPTION
The inception phase in the development of system architecture, emphasizing its alignment with systems
engineering principles.
1. Systems Engineering Focus: The passage underscores that the initial steps in developing system
architecture are fundamentally systems engineering activities. This implies a broad, interdisciplinary
approach to problem-solving, rather than focusing solely on software engineering aspects.
2. INCOSE Definition: The International Council on Systems Engineering (INCOSE) is referenced for
its definitions of systems engineering and system architecture. Systems engineering is characterized
as an interdisciplinary approach aimed at realizing successful systems. System architecture is defined
as the organization of elements and subsystems to meet system requirements.
3. Objectives of Inception Phase: The primary goal of the inception phase is to determine what needs
to be built for the customer. This involves several key activities:
Defining the problem boundary: Establishing the scope and context of the system.
Determining mission use cases: Identifying the primary tasks or functions the system needs to
support.
Analysing mission use cases: Breaking down mission use cases to derive system use cases,
which represent specific interactions and functionalities of the system.
4. Requirements Development: The inception phase involves developing both functional and
nonfunctional requirements, as well as identifying any constraints that may impact system design and
development.
While some may argue that defining a logical architecture is design rather than analysis, but it's crucial to
start constraining the design space. At this stage, the system architecture is principally object-oriented, with
complex objects representing major system functions. Refining these objects during analysis resembles the
process during design.
Even before conceptualizing a package diagram for the architecture, analysis begins by articulating primary
mission use cases with domain experts to understand system behaviour.
This black-box perspective avoids unnecessarily constraining the architecture, focusing on use case
functionality before allocating it to individual segments. Activity diagrams are used to illustrate expected
system behaviour, emphasizing success scenarios of mission use cases, while alternate scenarios are
addressed later.
In this context, success scenarios represent the main objectives of system interactions, as exemplified by the
ATM's "Withdraw Cash" use case.
The Withdraw Cash use case, like all others, comprises various scenarios, with the primary scenario
representing successful execution. Alternate or secondary scenarios branch off the primary scenario,
addressing situations like exceeding withdrawal limits. Real-time systems, such as the Satellite Navigation
System, often rely heavily on secondary scenarios, which are critical but receive less attention. Analyzing
these scenarios is crucial for system development efforts to ensure complete and safe operation.
We define four mission use cases for the Operate SNS package:
Initialize Operations
Provide Normal Operations
Provide Special Operations
Terminate Operations
These are based on our analysis of the overall SNS operation and rely on domain expertise, past experience,
and possibly simulations or prototypes. Activity diagram modeling aids in developing these mission use
cases, with Figure 8–4 illustrating the results for OperateSNS. Our focus now shifts to analyzing the
Initialize Operations mission use case to identify necessary system activities for enabling SNS initialization
by the operator.
The activity diagram informs the creation of system use cases through experienced systems engineering
judgment. Actions like Prepare for Launch and Launch are merged into one use case, Launch Satellite, while
other actions, deemed to embody significant system functionality, become individual use cases. This process
yields the system use cases for the Initialize Operations mission, detailed in Table.
Figure 8–6 illustrates an updated use case diagram featuring system use cases from Table 8–1. The
InitializeOperations package encompasses system use cases derived from the Initialize Operations mission
use case, while other SNS operation-related mission use cases are labeled «mission use case». This
modeling approach is deemed effective, though each team should document their preferred techniques.
Figure 8–6 System Use Cases for Initialize Operations
Launch Satellite Prepare the launcher and its satellite payload for launch, and
perform the launch.
Fly to Separation Fly the launcher to the point at which the satellite payload will
Point be separated. This involves the use and separation of multiple
launcher stages.
Activate Satellite Perform the activation of the satellite in preparation for its
deployment from the launcher.
Move Satellite into Use the satellite bus propulsion capability to position the satel-
Orbit lite into the correct orbital plane.
In the GroundSegment partition, actions like "Prepare for Launch," "Prepare Ground Segment," and
"Command Launch" form the "Control Launch" use case. Following a similar approach, the "Command
Flight" action constitutes the "Control Flight" use case. This method is repeated for all partitions to define
segment use cases, as summarized in Table 8–2.
Table 8–2 Segment Use Cases for Initialize Operations
Allocated Time
SNS Segment Segment Use Case (hours:minutes)
Developing and documenting interface specifications for the Satellite Navigation System involves analyzing
its functionality and considering various actors such as User, Operator, and Maintainer. Human/machine
interface specialists play a crucial role in this task. Interfaces with actors like ExternalPower and
ExternalCommunications can be specified early due to existing standards, while interfaces with the
Atmosphere/Space actor are largely governed by regulations and treaties set by national and international
agencies.
Figure 8–8 The Component Diagram for the Satellite Navigation System
Figure 8–9 illustrates the deployment of components from Figure 8–8 onto the architectural nodes of the
system. While this usage deviates from typical UML 2.0 notation, it effectively communicates the
information. The interfaces facilitating interaction with the Satellite Navigation System by the Operator,
Maintainer, and User actors are encapsulated within its segments, depicted through dependencies.
The decision to enhance functional redundancy by distributing the GroundSegment and LaunchSegment
across two geographically dispersed sites is depicted in the architecture. Each segment now has backup sites
ready to assume primary roles if needed, safeguarding against complete loss due to events like natural
disasters. This is symbolized by the multiplicities of 2 on the communication association between the
GroundSite and LaunchSite nodes, ensuring resilience in critical operations.
Figure 8–9 The Deployment of SNS Segments
The SatelliteConstellation node represents the satellites comprising the Satellite Navigation System, aiding
the SatelliteSegment artifacts by providing necessary support, such as gravity for orbit stability and the
atmosphere and outer space for communication. The {1..*} multiplicity on SatelliteSegment indicates the
minimum number of satellites in the constellation. The specific coverage area is pending determination by
the customer to ascertain the required number of satellites for optimal service provision to SNS users.
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 GroundSegment’s Control Launch use case to determine its
actions
Performed white-box analysis of the GroundSegment’s Control Launch actions to allocate them
across its subsystems
Figure 8–10 provides a detailed breakdown of the actions required from each GroundSegment subsystem to
fulfill its role in controlling the launch. This analysis allows us to develop the architecture for each segment
of the Satellite Navigation System. Subsequent pages will showcase the resulting architectures for each
segment.
The architecture of the GroundSegment comprises five subsystems:
1. ControlCenter: Provides command and control functionality for the entire Satellite Navigation
System, supported by TT&C and SensorStation.
2. TT&C (tracking, telemetry, and command): Monitors and controls the SatelliteSegment.
3. SensorStation: Provides position information from the SatelliteSegment and environmental data.
4. Gateway: Facilitates communication between the ControlCenter, LaunchSegment, and
SatelliteSegment for launch activities and satellite operations control.
5. UserInterface: Grants access to GroundSegment functionality for the Operator and Maintainer
actors.
This breakdown ensures effective coordination and functionality within the GroundSegment of the Satellite
Navigation System.
Decomposing the system architecture into segments and subsystems creates manageable units for work
assignments, configuration management, and version control. Each segment or subsystem is owned by an
organization, team, or individual, facilitating detailed design and implementation while managing interfaces
effectively. This approach enables the management of complex development programs by breaking down the
problem into smaller, more manageable parts. Thus, it demonstrates the applicability of object-oriented
analysis and design principles, along with UML 2.0 notation, to both software and system architecture
development.
3. CONSTRUCTION
At the end of the Elaboration phase, as we pointed out in Chapter 6, 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 chapter—to show the approach to developing the SNS system architecture by logically
partitioning the required functionality to define the constituent segments and subsystems—we do not show
any architectural development activities in this phase.
In the Construction phase, modifications to the system architecture typically focus on lower-level
architectural elements rather than segments and subsystems, which should have been stabilized during the
Elaboration phase. Therefore, our focus remains on implementing and refining the previously defined
segments and subsystems without significant architectural changes.
4. TRANSISTION
In the post-transition phase, we evaluate how well the Satellite Navigation System's design meets the
requirements of extensibility and long service life. As new users and implementations emerge, we assess the
system's ability to accommodate new functionality and adapt to changes in target hardware while ensuring
reliable operation. This evaluation helps us gauge the effectiveness of our design in meeting evolving needs
and sustaining the system over its intended lifespan.
4.1 Adding New Functionality
Adding the capability to use position information from other systems like GPS, GLONASS, and Galileo is
feasible with minimal impact on the Satellite Navigation System. Since the change is isolated to the User
Segment, existing components can be upgraded, such as the Receiver subsystem and firmware in the
Processor subsystem. This illustrates the flexibility of well-structured object-oriented systems, where new
requirements can often be accommodated by building upon existing mechanisms.
The introduction of the capability to support search and rescue (SAR) missions by receiving distress beacons
would primarily impact the Satellite Segment, with some minor impact on the Ground Segment. Ideally, if
we had anticipated this requirement, we would have already incorporated the necessary capability into the
Satellite Segment, resulting in no design impact but only operational considerations. Otherwise, we would
need to add an additional subsystem to the Satellite Segment to support this functionality. The impact on the
Ground Segment would likely involve minor software or operational modifications to relay information
about distress beacon reception to civil authorities.
Indeed, despite the challenges posed by modifications to space-based assets, adding the SAR capability to
the Satellite Segment would still have minimal impact on the overall SNS architecture. Even in the worst-
case scenario, integrating this capability into future Satellite Segment elements would entail minimal
disruption to the existing architecture or functionality.
By encapsulating all design decisions regarding the specifics of the ControlCenter subsystem and keeping
subsystem interfaces abstract, other parts of the system are shielded from the intricacies of the ControlCenter
hardware. This means that dependencies on specific characteristics of the hardware, such as workstations,
are hidden within the ControlCenter subsystem.
Therefore, when replacing the ControlCenter subsystem, as long as the new hardware adheres to the same
abstract interfaces, the software in other subsystems should require only minimal changes, if any. The
abstraction firewall provided by the ControlCenter subsystem ensures that the behavior of the workstations
remains transparent to other components of the system, thus preserving the system's overall stability and
reducing the risk of disruptions during the replacement process.
Maintaining a design where only the Gateway subsystem interfaces with network communications ensures
minimal impact from radical changes in telecommunications standards. Higher-level clients remain
unaffected, shielded from the complexities of networking by the Gateway subsystem. This design approach
provides resilience against shifts in real-world telecommunications technology.
None of the changes we have introduced rends the fabric of our existing architecture. This is indeed the
ultimate mark of a well-architected, object-oriented system.
Overall, the fact that your architecture can accommodate changes without disrupting its fundamental
structure underscores its robustness and the effectiveness of the design decisions made during its
development.