ExternalVendorCode/openmct
1
0
Fork 0
mirror of https://github.com/nasa/openmct.git synced 2025-06-18 07:08:12 +00:00
Code Issues Actions 4 Packages Projects Releases Wiki Activity

[Branding] Change name in docs hierarchy

Browse Source 
...from Open MCT Web to plain-old Open MCT.
This commit is contained in:
Victor Woeltjen
2016-05-04 10:13:09 -07:00
parent de2703ee48
commit 431b836568
10 changed files with 226 additions and 227 deletions
Download Patch File Download Diff File Expand all files Collapse all files

16
docs/src/architecture/framework.md
View File

@ -5,7 +5,7 @@ software components to communicate. The software components it recognizes
are:
* _Extensions_: Individual units of functionality that can be added to
or removed from Open MCT Web. _Extension categories_ distinguish what
or removed from Open MCT. _Extension categories_ distinguish what
type of functionality is being added/removed.
* _Bundles_: A grouping of related extensions
(named after an analogous concept from [OSGi](http://www.osgi.org/))
@ -19,7 +19,7 @@ manner which the framework layer can understand.
```nomnoml
#direction: down
[Open MCT Web|
[Open MCT|
[Dependency injection framework]-->[Platform bundle #1]
[Dependency injection framework]-->[Platform bundle #2]
[Dependency injection framework]-->[Plugin bundle #1]
@ -35,7 +35,7 @@ manner which the framework layer can understand.
```
The "dependency injection framework" in this case is
[AngularJS](https://angularjs.org/). Open MCT Web's framework layer
[AngularJS](https://angularjs.org/). Open MCT's framework layer
is really just a thin wrapper over Angular that recognizes the
concepts of bundles and extensions (as declared in JSON files) and
registering extensions with Angular. It additionally acts as a
@ -60,7 +60,7 @@ activities which were performed by the framework component.
## Application Initialization
The framework component initializes an Open MCT Web application following
The framework component initializes an Open MCT application following
a simple sequence of steps.
```nomnoml
@ -97,7 +97,7 @@ a simple sequence of steps.
[Extension]o->[Dependency #3]
```
Open MCT Web's architecture relies on a simple premise: Individual units
Open MCT's architecture relies on a simple premise: Individual units
(extensions) only have access to the dependencies they declare that they
need, and they acquire references to these dependencies via dependency
injection. This has several desirable traits:
@ -121,11 +121,11 @@ injection. This has several desirable traits:
the framework.
A drawback to this approach is that it makes it difficult to define
"the architecture" of Open MCT Web, in terms of describing the specific
"the architecture" of Open MCT, in terms of describing the specific
units that interact at run-time. The run-time architecture is determined
by the framework as the consequence of wiring together dependencies.
As such, the specific architecture of any given application built on
Open MCT Web can look very different.
Open MCT can look very different.
Keeping that in mind, there are a few useful patterns supported by the
framework that are useful to keep in mind.
@ -229,4 +229,4 @@ otherwise a single provider) will be exposed as a single service that
other extensions can acquire through dependency injection. Because all
components of the same type of service expose the same interface, users
of that service do not need to be aware that they are talking to an
aggregator or a provider, for instance.
aggregator or a provider, for instance.

24
docs/src/architecture/index.md
View File

@ -1,14 +1,14 @@
# Introduction
The purpose of this document is to familiarize developers with the
overall architecture of Open MCT Web.
overall architecture of Open MCT.
The target audience includes:
* _Platform maintainers_: Individuals involved in developing,
extending, and maintaing capabilities of the platform.
* _Integration developers_: Individuals tasked with integrated
Open MCT Web into a larger system, who need to understand
Open MCT into a larger system, who need to understand
its inner workings sufficiently to complete this integration.
As the focus of this document is on architecture, whenever possible
@ -17,25 +17,25 @@ omitted. These details may be found in the developer guide.
# Overview
Open MCT Web is client software: It runs in a web browser and
Open MCT is client software: It runs in a web browser and
provides a user interface, while communicating with various
server-side resources through browser APIs.
```nomnoml
#direction: right
[Client|[Browser|[Open MCT Web]->[Browser APIs]]]
[Client|[Browser|[Open MCT]->[Browser APIs]]]
[Server|[Web services]]
[Client]<->[Server]
```
While Open MCT Web can be configured to run as a standalone client,
While Open MCT can be configured to run as a standalone client,
this is rarely very useful. Instead, it is intended to be used as a
display and interaction layer for information obtained from a
variety of back-end services. Doing so requires authoring or utilizing
adapter plugins which allow Open MCT Web to interact with these services.
adapter plugins which allow Open MCT to interact with these services.
Typically, the pattern here is to provide a known interface that
Open MCT Web can utilize, and implement it such that it interacts with
Open MCT can utilize, and implement it such that it interacts with
whatever back-end provides the relevant information.
Examples of back-ends that can be utilized in this fashion include
databases for the persistence of user-created objects, or sources of
@ -43,13 +43,13 @@ telemetry data.
## Software Architecture
The simplest overview of Open MCT Web is to look at it as a "layered"
The simplest overview of Open MCT is to look at it as a "layered"
architecture, where each layer more clearly specifies the behavior
of the software.
```nomnoml
#direction: down
[Open MCT Web|
[Open MCT|
[Platform]<->[Application]
[Framework]->[Application]
[Framework]->[Platform]
@ -64,14 +64,14 @@ These layers are:
established an abstraction by which different software components
may communicate and/or interact.
* [_Platform_](platform.md): The platform layer defines the general look,
feel, and behavior of Open MCT Web. This includes user-facing components like
feel, and behavior of Open MCT. This includes user-facing components like
Browse mode and Edit mode, as well as underlying elements of the
information model and the general service infrastructure.
* _Application_: The application layer defines specific features of
an application built on Open MCT Web. This includes adapters to
an application built on Open MCT. This includes adapters to
specific back-ends, new types of things for users to create, and
new ways of visualizing objects within the system. This layer
typically consists of a mix of custom plug-ins to Open MCT Web,
typically consists of a mix of custom plug-ins to Open MCT,
as well as optional features (such as Plot view) included alongside
the platform.

40
docs/src/architecture/platform.md
View File

@ -1,6 +1,6 @@
# Overview
The Open MCT Web platform utilizes the [framework layer](Framework.md)
The Open MCT platform utilizes the [framework layer](Framework.md)
to provide an extensible baseline for applications which includes:
* A common user interface (and user interface paradigm) for dealing with
@ -16,7 +16,7 @@ building application, the platform adds more specificity by defining
additional extension types and allowing for integration with back end
components.
The run-time architecture of an Open MCT Web application can be categorized
The run-time architecture of an Open MCT application can be categorized
into certain high-level tiers:
```nomnoml
@ -29,7 +29,7 @@ into certain high-level tiers:
[Browser APIs]->[Back-end]
```
Applications built using Open MCT Web may add or configure functionality
Applications built using Open MCT may add or configure functionality
in __any of these tiers__.
* _DOM_: The rendered HTML document, composed from HTML templates which
@ -60,7 +60,7 @@ in __any of these tiers__.
functionality needed to support the information model. This includes
exposing underlying sets of extensions and mediating with the
back-end.
* _Back-end_: The back-end is out of the scope of Open MCT Web, except
* _Back-end_: The back-end is out of the scope of Open MCT, except
for the interfaces which are utilized by adapters participating in the
service infrastructure. Includes the underlying persistence stores, telemetry 
streams, and so forth which the Open MCT Web client is being used to interact 
@ -70,15 +70,15 @@ in __any of these tiers__.
Once the
[application has been initialized](Framework.md#application-initialization)
Open MCT Web primarily operates in an event-driven paradigm; various
Open MCT primarily operates in an event-driven paradigm; various
events (mouse clicks, timers firing, receiving responses to XHRs) trigger
the invocation of functions, typically in the presentation layer for
user actions or in the service infrastructure for server responses.
The "main point of entry" into an initialized Open MCT Web application
The "main point of entry" into an initialized Open MCT application
is effectively the
[route](https://docs.angularjs.org/api/ngRoute/service/$route#example)
which is associated with the URL used to access Open MCT Web (or a
which is associated with the URL used to access Open MCT (or a
default route.) This route will be associated with a template which
will be displayed; this template will include references to directives
and controllers which will be interpreted by Angular and used to
@ -107,11 +107,11 @@ both the information model and the service infrastructure.
# Presentation Layer
The presentation layer of Open MCT Web is responsible for providing
The presentation layer of Open MCT is responsible for providing
information to display within templates, and for handling interactions
which are initiated from templated DOM elements. AngularJS acts as
an intermediary between the web page as the user sees it, and the
presentation layer implemented as Open MCT Web extensions.
presentation layer implemented as Open MCT extensions.
```nomnoml
[Presentation Layer|
@ -143,12 +143,12 @@ to primitives from AngularJS:
attributes and tags.
* [_Routes_](https://docs.angularjs.org/api/ngRoute/service/$route#example)
are used to associate specific URLs (including the fragment identifier)
with specific application states. (In Open MCT Web, these are used to
with specific application states. (In Open MCT, these are used to
describe the mode of usage - e.g. browse or edit - as well as to
identify the object being used.)
* [_Templates_](https://docs.angularjs.org/guide/templates) are partial
HTML documents that will be rendered and kept up-to-date by AngularJS.
Open MCT Web introduces a custom `mct-include` directive which acts
Open MCT introduces a custom `mct-include` directive which acts
as a wrapper around `ng-include` to allow templates to be referred
to by symbolic names.
@ -189,10 +189,10 @@ to displaying domain objects.
]
```
Domain objects are the most fundamental component of Open MCT Web's
Domain objects are the most fundamental component of Open MCT's
information model. A domain object is some distinct thing relevant to a
user's work flow, such as a telemetry channel, display, or similar.
Open MCT Web is a tool for viewing, browsing, manipulating, and otherwise
Open MCT is a tool for viewing, browsing, manipulating, and otherwise
interacting with a graph of domain objects.
A domain object should be conceived of as the union of the following:
@ -254,7 +254,7 @@ Concrete examples of capabilities which follow this pattern
# Service Infrastructure
Most services exposed by the Open MCT Web platform follow the
Most services exposed by the Open MCT platform follow the
[composite services](Framework.md#composite-services) to permit
a higher degree of flexibility in how a service can be modified
or customized for specific applications.
@ -327,7 +327,7 @@ A short summary of the roles of these services:
[DomainObjectProvider]o-[CapabilityService]
```
As domain objects are central to Open MCT Web's information model,
As domain objects are central to Open MCT's information model,
acquiring domain objects is equally important.
```nomnoml
@ -338,7 +338,7 @@ acquiring domain objects is equally important.
[<state> Instantiate DomainObject]->[<end> End]
```
Open MCT Web includes an implementation of an `ObjectService` which
Open MCT includes an implementation of an `ObjectService` which
satisfies this capability by:
* Consulting the [Model Service](#model-service) to acquire domain object
@ -437,9 +437,9 @@ objects (this allows failures to be recognized and handled in groups.)
The telemetry service is responsible for acquiring telemetry data.
Notably, the platform does not include any providers for
`TelemetryService`; applications built on Open MCT Web will need to
`TelemetryService`; applications built on Open MCT will need to
implement a provider for this service if they wish to expose telemetry
data. This is usually the most important step for integrating Open MCT Web
data. This is usually the most important step for integrating Open MCT
into an existing telemetry system.
Requests for telemetry data are usually initiated in the
@ -721,6 +721,6 @@ disallow.
```
The type service provides metadata about the different types of domain
objects that exist within an Open MCT Web application. The platform
objects that exist within an Open MCT application. The platform
implementation reads these types in from extension category `types`
and wraps them in a JavaScript interface.
and wraps them in a JavaScript interface.