cgd

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 System’s 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]. 
:::Requirements for the Satellite Navigation System:::The process of building systems to help solve our customer’s 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. Functional requirements:  Provide SNS services , Operate the SNS, Maintain the SNS. Nonfunctional requirements: Level of reliability to ensure adequate service guarantees Sufficient accuracy to support current and future user needs, Functional redundancy in critical system capabilities, Extensive automation to minimize operational costs, Easily maintained to minimize maintenance costs, Extensible to support enhancement of system functionality, Long service life, especially for space-based elements.::: Constraints:Compatibility with international standards,  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.This context diagram provides us with a clear understanding of the environment within which the SNS must function.::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. ::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. 
5.1.2 Elaboration
Developing a Good Architecture::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. ::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.