Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "OSEE/Architecture"

m (OSEE Deployment)
(Extensibility)
(30 intermediate revisions by 4 users not shown)
Line 2: Line 2:
 
The Open System Engineering Environment (OSEE) is an integrated, extensible tool environment for large engineering projects. OSEE is more than an integrated development environment (IDE), but is an integrated product life-cycle development environment.  The system captures project data into a common user-defined data model providing bidirectional traceability, project health reporting, status, and metrics which seamlessly combine to form a coherent, accurate view of a project in real-time. By building on top of a central data model, OSEE provides an integrated configuration management, requirements management, implementation, testing, validation, and project management system. All of the components work together to help an organization achieve lean objectives by reducing management activities, eliminating data duplication, reducing cycle-time through streamlined processes, and improving overall product quality through work flow standardization and early defect detection.
 
The Open System Engineering Environment (OSEE) is an integrated, extensible tool environment for large engineering projects. OSEE is more than an integrated development environment (IDE), but is an integrated product life-cycle development environment.  The system captures project data into a common user-defined data model providing bidirectional traceability, project health reporting, status, and metrics which seamlessly combine to form a coherent, accurate view of a project in real-time. By building on top of a central data model, OSEE provides an integrated configuration management, requirements management, implementation, testing, validation, and project management system. All of the components work together to help an organization achieve lean objectives by reducing management activities, eliminating data duplication, reducing cycle-time through streamlined processes, and improving overall product quality through work flow standardization and early defect detection.
 
[[Image:OSEESystemContext.png|thumb|center|400px|OSEE High Level System Overview]]
 
[[Image:OSEESystemContext.png|thumb|center|400px|OSEE High Level System Overview]]
OSEE is customizeable to meet the needs of the project.  The teams working on the project, the roles they perform, and the processes they follow are all configureable within OSEE.  Traceability is maintained from requirements through acceptance testing.  Program management can customize the metrics gathered in order to best gain insight into the project status.
+
OSEE is customizable to meet the needs of the project.  The teams working on the project, the roles they perform, and the processes they follow are all configurable within OSEE.  Traceability is maintained from requirements through acceptance testing.  The OSEE High Level System Overview diagram illustrates the range of users and the roles they may perform, which encompasses the entire product life-cycle
 +
*Requirements Engineer can create, manage, track requirements
 +
*Implementation Engineer may design, implement, integrate, unit test the product from software to hardware.
 +
*Test Engineer may perform different levels of integration or acceptance testing, and provide comprehensive test reporting.
 +
*Project Manager can track the progress of the product and gather customized metrics in order to best gain insight into the project status.
 +
*System Administrator manages the user accounts and IT needs.
 +
*Support Engineer can trace progress on customer issues
 +
*Maintenance Engineer can run validation, verification, or diagnostic tests on the target environment.
  
 
==OSEE Quality Attributes==
 
==OSEE Quality Attributes==
 
The following defines the high level quality attributes for the OSEE system
 
The following defines the high level quality attributes for the OSEE system
 
* Changeability - New or updated features/services can easily be integrated into OSEE.
 
* Changeability - New or updated features/services can easily be integrated into OSEE.
* Extensability - The services/components provided with OSEE will be reusable and/or extendable.
+
* Extensibility - The services/components provided with OSEE will be reusable and/or extendable.
* Flexibility - The tailoring of OSEE for a specific project can be accomplished through configuration.
+
* Flexibility - The tailoring of OSEE for a specific project can be accomplished through dynamic configuration.
 
* Openness - OSEE uses open standards to enable quality, standardized, and well thought-through interfaces.
 
* Openness - OSEE uses open standards to enable quality, standardized, and well thought-through interfaces.
 
* Performance - The system will respond in a timely manner to user input and queries.
 
* Performance - The system will respond in a timely manner to user input and queries.
Line 14: Line 21:
  
 
==OSEE Components==
 
==OSEE Components==
At the core of OSEE is the OSEE Framework.  On top of the framework sits four core components: Action Tracking System (ATS), Define, Coverage, and Open System Engineering Test Environment (OTE).  The User Management component, which allows for user authentication, verification and role based access control (RBAC), is used by all of the OSEE components.
+
OSEE follows a client server architecture with a thin client and one to N servers.  The client can exist in two different forms: One, a web browser client; Two, an [http://wiki.eclipse.org/Main_Page Eclipse] based IDE.  The OSEE Server is built utilizing the [http://www.eclipse.org/equinox/ Eclipse Equinox] [http://www.osgi.org/Technology/WhatIsOSGi OSGi framework].  All instances of the server attach to a single centralized data repository.
 +
[[Image:OSEE_ClientServer.png|thumb|center|420px|OSEE Client Server View]]
 +
 
 +
At the core of OSEE Application Server is the Object Revision Control System Framework.  On top of the framework sits four core components: Action Tracking System (ATS), Define, Coverage, and Open System Engineering Test Environment (OTE).  The User Management component, which allows for user authentication, verification and role based access control (RBAC), is used by all of the OSEE components.
 
[[Image:OSEEComponentDiagram.png|thumb|center|260px|OSEE Component Diagram]]
 
[[Image:OSEEComponentDiagram.png|thumb|center|260px|OSEE Component Diagram]]
OSEE is built on top of [http://wiki.eclipse.org/Main_Page Eclipse], and utilizes the [http://www.osgi.org/Technology/WhatIsOSGi OSGi framework] to manage it's bundles.
+
OSEE is built on top of [http://wiki.eclipse.org/Main_Page Eclipse], and utilizes the [http://www.osgi.org/Technology/WhatIsOSGi OSGi framework] to manage the component bundles.
 
Capabilities provided by 3rd party libraries and exposed in the Base Level API include:
 
Capabilities provided by 3rd party libraries and exposed in the Base Level API include:
 
* Logging - Provide a consistent logging mechanism
 
* Logging - Provide a consistent logging mechanism
* Console
+
* Console - User ability to issue command line operations on the server
* Event Systems - Manage the use of events
+
* [http://en.wikipedia.org/wiki/Java_API_for_RESTful_Web_Services JAX-RS] - Java REST API for web services
* [http://en.wikipedia.org/wiki/Java_API_for_RESTful_Web_Services JAX-RS] - Java REST API implementation
+
* Event Management - [http://activemq.apache.org/ ActiveMQ] is used for event messaging
* [http://activemq.apache.org/ ActiveMQ] - Event Messaging
+
* Servelet Management
+
* JDK Extensions
+
  
 
===OSEE Framework===
 
===OSEE Framework===
 +
====OSGi Framework====
 +
The OSGi Framework Linked above provides the underlying support for the OSEE Framework. The Eclipse implementation of OSGi is called Equinox. The Equinox framework supports Extensions, Services, Declarative Services and Spring-OSGi. Since OSEE is built on top of this extendable foundation, it inherits these capabilities. OSEE developers have taken advantage of this, and primarily use Extensions and Declarative Services to further extend capabilities.
 +
 +
====Extensibility====
 +
The layered approach provides extensibility to OSEE. The IDE Client is extended through the use of Eclipse Extension Points. The OSEE Application Server is extended through Declarative Services. As described in the following sections, the data model is abstracted one level up, so that a broad variety of specific data can be expressed in the data model. The database interface complies with standard SQL-99 ("with" clause is used so SQL-92 is not sufficient), so relational databases providing SQL-99 compliance can be substituted in through the use of JSON configuration files provided in OSEE.
 +
 +
====Object Revision Control System====
 
The heart of the OSEE Framework is the Object Revision Control System (ORCS).  ORCS provides the foundation the rest of the components are built on top of.
 
The heart of the OSEE Framework is the Object Revision Control System (ORCS).  ORCS provides the foundation the rest of the components are built on top of.
 
The key capabilities provided by ORCS are:
 
The key capabilities provided by ORCS are:
* Object Management - The definition and persistance of any object of any simple or complex type can be managed, and type safety is ensured on all operations.
+
* Object Management - The definition and persistence of any object of any simple or complex type can be managed, and type safety is ensured on all operations.
 
* Data Model - the underlying data model is configurable per project
 
* Data Model - the underlying data model is configurable per project
 
* Version management - baselines and branching for a project are managed
 
* Version management - baselines and branching for a project are managed
 +
* Generic UI editor framework - customized editors can be created
 
* Searching/Indexing
 
* Searching/Indexing
 
* Transaction Management
 
* Transaction Management
Line 38: Line 53:
  
 
====Data Model====
 
====Data Model====
The object management provides the core building blocks for the centralized data model.  The core build block for the data model consists of:
+
The object management provides the core building blocks for the centralized data model.  The core building block for the data model consists of:
* Artifact - The fundamental object in OSEE. All data objects stored within OSEE are artifacts. Artifacts are strongly typed and can store any data throughout the systems engineering lifecycle. Artifacts have a Description, Type, and set of 1..n Attributes.  Any type of data can be stored as an artifact; not only systems engineering data (such as processes and requirements), but also anything from meeting minutes to architecture diagrams.
+
* '''Artifact''' - The fundamental object in OSEE. All data objects stored within OSEE are artifacts. Artifacts are strongly typed and can store any data throughout the systems engineering lifecycle. Artifacts have a Description, Type, and set of 1..n Attributes.  Any type of data can be stored as an artifact; not only systems engineering data (such as processes and requirements), but also anything from meeting minutes to architecture diagrams.
* Attribute - A specific piece of data attached to an Artifact.  Attribute consists of Description, Type, default value (optional), Min occurances in an artifact, Max occurances in an artifacts.   
+
* '''Attribute''' - A specific piece of data attached to an Artifact.  Attribute consists of Description, Type, default value (optional), Min occurrences in an artifact, Max occurrences in an artifactAn Attribute can be a basic type or a more complex type like another Artifact.
* Relation - Defines the relationship (link) between two artifacts.  The relation is strongly typed, which means it can only be used to link the specified artifact types.  The relation allows the multiplicity between the two types to specified as: 1..1, 1..*, *..1, *..*  
+
* '''Relation''' - Defines the relationship (link) between two artifacts.  The relation is strongly typed, which means it can only be used to link the specified artifact types.  The relation allows the multiplicity between the two types to be specified as: 1..1, 1..*, *..1, *..*  
[[Image:OSEE_ArtifactAttribute.png|thumb|center|360px|Artifact Attribute Diagram]]
+
[[Image:OSEE_ArtifactAttribute.png|thumb|center|360px|Artifact Attribute Relation Diagram]]
 +
 
 
====Version Management====
 
====Version Management====
Version management allows for the parallel development of different variations of a product, as-well-as the sharing of common information across similar products.  Changes made to one version baseline can be merged to another version baseline in order to maintain commonality as desired.
+
Version management allows for the parallel development of different variations of a product, as well as the sharing of common information across similar products.  Changes made to one version baseline can be merged to another version baseline in order to maintain commonality as desired.
 
[[Image:OSEE_Versions.png|center|thumb|420px|Version management example]]
 
[[Image:OSEE_Versions.png|center|thumb|420px|Version management example]]
  
 
===Action Tracking System ([[OSEE/Architecture/ATS_Details|Details]])===
 
===Action Tracking System ([[OSEE/Architecture/ATS_Details|Details]])===
The Action Tracking System (ATS) is a tightly integrated tracking system that manages changes throughout the different aspects of a product's lifecycle. ATS provides integrated change management to all OSEE applications through customizable work processes (workflows) and ensures traceability from start to completion.
+
The Action Tracking System (ATS) is a tightly integrated tracking system that manages changes throughout the different aspects of a product's lifecycle. ATS provides integrated change management to all OSEE applications through customizable work processes (workflows) and ensures traceability from start to completion.  ATS utilizes the core capabilities provided by the [[#OSEE_Framework|ORCS]] layer.
  
ATS is highly configurable and can be configured to meet any project's work tracking needs.  The level of detail of work items, team organization, process to complete work item types are all configurable for a project.  The configuration is realized through the use of the [[#Data_Model|data model]] to create the core building blocks of ATS: Action, Actionable Item, Team Definition, Workflow Definition, Task, Version.
+
ATS is highly configurable and can be configured to meet any project's work tracking needs.  The level of detail of work items, team organization, and process to complete work item types are all configurable for a project.  The configuration is realized through the use of the [[#Data_Model|data model]] to create the core building blocks of ATS: Action, Actionable Item, Team Definition, Workflow Definition, Task, and Version.
  
 
At the highest level, an item of work to be completed is referred to as an Action.  Actions are created as work is needed for a project.
 
At the highest level, an item of work to be completed is referred to as an Action.  Actions are created as work is needed for a project.
Line 60: Line 76:
 
[[Image:OSEE_ATS_TeamDefinition.png|thumb|center|160px|Team Definition Example]]
 
[[Image:OSEE_ATS_TeamDefinition.png|thumb|center|160px|Team Definition Example]]
  
Each Team Definition has a Workflow Definition (or state machine) that defines the process that team uses to track and complete the work.  Each state of the workflow can have configured conditions or fields that are required to transition.  A Review can be attached to a state and can block the tranisition until successfully completed.
+
Each Team Definition has a Workflow Definition (or state machine) that defines the process that team uses to track and complete the work.  Each state of the workflow can have configured conditions or fields that are required to transition.  A Review can be attached to a state and can block the transition until successfully completed.
 
[[Image:OSEE_ATS_WorkflowDefinition.png|thumb|center|400px|Workflow Definition Example]]
 
[[Image:OSEE_ATS_WorkflowDefinition.png|thumb|center|400px|Workflow Definition Example]]
 
A Task is the lowest level of work, and is used to allocate the work to individuals.  A Task can be associated with a particular state or a state can have multiple tasks that need completing before the workflow can advance to the next state.
 
A Task is the lowest level of work, and is used to allocate the work to individuals.  A Task can be associated with a particular state or a state can have multiple tasks that need completing before the workflow can advance to the next state.
 
[[Image:OSEE_ATS_TaskDefinition.png|thumb|center|260px|Task Allocation Example]]
 
[[Image:OSEE_ATS_TaskDefinition.png|thumb|center|260px|Task Allocation Example]]
  
A Version is used to group a set of Actions together into a "build", "release", "edition", etc.
+
A Version is used to group a set of Actions together into a "build", "release", "edition", etc.  A common set of actions can apply to more than one version enabling data sharing across similar or variant projects.  The version capability relies on the [[#Version_Management|version management]] framework.
  
Status data associated with tasks can be used to create metrics that roll-up to the Workflow, which can roll up to the Team, which can roll-up to the Action, which roll-up to the projuct.  Metrics can be obtained for any specified grouping within the project (e.g. Team, Version, etc.)
+
Status data associated with tasks can be used to create metrics that roll-up to the Workflow, which can roll up to the Team, which can roll-up to the Action, which roll-up to the project.  Metrics can be obtained for any specified grouping within the project (e.g. Team, Version, etc.)
  
 
[[OSEE/Architecture/ATS_Details|ATS Architecture Details]]
 
[[OSEE/Architecture/ATS_Details|ATS Architecture Details]]
Line 74: Line 90:
 
Define is the requirements management component of OSEE.  Define provides support for concurrent and distributed requirements development.  Requirements can be imported from other sources to provide comprehensive and coherent requirements management across the product life-cycle.
 
Define is the requirements management component of OSEE.  Define provides support for concurrent and distributed requirements development.  Requirements can be imported from other sources to provide comprehensive and coherent requirements management across the product life-cycle.
  
Since Define uses the OSEE [[OSEE/Architecture#Data_Model|data model]] and [[OSEE/Architecture#Version_Management|version management]], requirements:
+
Since Define uses the OSEE [[OSEE/Architecture#Data_Model|data model]] and [[OSEE/Architecture#Version_Management|version management]], the following list of properties applies.
 +
Requirements in OSEE:
 +
* can be hierarchical
 
* can be integrated into the processes and workflows
 
* can be integrated into the processes and workflows
 
* will have bidirectional traceability from beginning to end of the product life-cycle
 
* will have bidirectional traceability from beginning to end of the product life-cycle
Line 82: Line 100:
 
===Coverage===
 
===Coverage===
 
Coverage provides for the configuration management and tracking of coverage disposition efforts throughout a project.  OSEE allows for the configuration of what is tracked for verification and validation on the project.  For example, in a software project the lines of code in the software can be exercised through software tests, and tools can determine how many of the software lines of code where executed during the tests.  A report is generated and can be imported by Coverage and a complete coverage report generated.
 
Coverage provides for the configuration management and tracking of coverage disposition efforts throughout a project.  OSEE allows for the configuration of what is tracked for verification and validation on the project.  For example, in a software project the lines of code in the software can be exercised through software tests, and tools can determine how many of the software lines of code where executed during the tests.  A report is generated and can be imported by Coverage and a complete coverage report generated.
[[Image:OSEE_Coverage.png|center|thumb|420px|High Level Coverage Overview]]
+
[[Image:OSEE_Coverage.png|center|thumb|420px|Coverage Overview]]
 
The Coverage is configurable through the creation of a Coverage Package.  The Coverage Package configuration includes all the inputs (unit tests, test scripts, coverage test report imports), traceability (results to tests, tests to requirements) and outputs (reports, metrics) desired.  The Coverage Package will also allow for checking the differences between test runs by comparing different instances of test result imports.
 
The Coverage is configurable through the creation of a Coverage Package.  The Coverage Package configuration includes all the inputs (unit tests, test scripts, coverage test report imports), traceability (results to tests, tests to requirements) and outputs (reports, metrics) desired.  The Coverage Package will also allow for checking the differences between test runs by comparing different instances of test result imports.
  
===Open System Engineering Test Environment (OTE)===
+
===Open System Engineering Test Environment===
OTE is an integrated approach to product testing, and follows a client/server architecture.  The OTE client is part of the OSEE client, while the OTE Server is separate from the OSEE Application Server.
+
The Open System Engineering Test Environment (OTE) is an integrated approach to product testing, and follows a client/server architecture.  The OTE client is part of the OSEE client, while the OTE Server is separate from the OSEE Application Server.
The OTE Client provides for:
+
 
* Test Manager for configuration and automated testing
+
The OTE Client provides:
* An API to create simulated components (models)
+
* Test Manager for configuration of tests and test environment
* Managing of test scripts
+
* Automated test execution
 +
* An API to create simulated test components (models)
 +
* Managing of tests (unit tests, scripts, etc.)
 
* Real-time test result monitoring, recording, and playback
 
* Real-time test result monitoring, recording, and playback
 +
* Test result reporting and [[OSEE/Architecture#Coverage|coverage]]
  
The OTE Test Server provides for:
+
The OTE Test Server provides:
 
* A test execution manager
 
* A test execution manager
* A simulated test environment that manages/executes models
+
* A simulated test environment that manages/executes test models
 
* Managing I/O connections to the target test environment
 
* Managing I/O connections to the target test environment
 +
* Managing the test environment resources
 +
* Relay real-time test data to client
  
 
[[Image:OSEE_OTE.png|thumb|center|420px|OTE Architecture Diagram]]
 
[[Image:OSEE_OTE.png|thumb|center|420px|OTE Architecture Diagram]]
Line 103: Line 126:
  
 
==OSEE Deployment==
 
==OSEE Deployment==
OSEE utilizes the client-server paradigm to seperate the user interface from the component capabilities.  The clients first contact an arbitration server, which may also be an application server, to acquite a connection to an appropriate server based on version and server load.
+
OSEE is designed to work in a collaborative environment, supporting many developers working on the same data. One of the many considerations to help accomplish this is the use of a multi-tier architecture to maintain a common set of underlying data for all.
[[Image:OSEE_NetworkArchitecture.png|thumb|center|400px|OSEE Network Architecture]]
+
Specifically, OSEE utilizes a [https://en.wikipedia.org/wiki/Multitier_architecture three tier paradigm] to separate the user interface from the component capabilities.  There are three cases that are important to understand.
 +
===Single User Deployment===
 +
This is the default deployment if you download OSEE from the web. The embedded HSQL database will be automatically created when the server is run in a command shell. The client is configured to connect to the local server by default.
 +
[[Image:OSEESingleUser.png|thumb|center|400px|OSEE Single User Diagram]]
 +
 
 +
===Multi-User, Single Application Server Deployment===
 +
The multi-user deployment can be achieved by installing OSEE clients on separate machines that have network access to the server machine. The client .ini file needs to be configured to connect to the Application Server machine. A more robust database can be configured for the Application Server via the database [[OSEE/Developers_Guide#Server_OSGi_properties|JOSN configuration file]].
 +
 
  
[[Image:OSEENetworkDiagram.png|thumb|center|260px|OSEE Network Diagram]]
+
[[Image:OSEEMultiUser.png|thumb|center|400px|OSEE Multi User Diagram]]
 +
===Multi-User, Multi-Application Server Deployment===
 +
Multi-Application Server deployment should be considered if:
 +
* higher availability for the application server is required
 +
* the Application Server becomes over burdened, impacting server response time
 +
In these cases, load balancing across multiple application servers is encouraged.  OSEE Application servers are designed to support load balancing, and do not require the client to connect to a specific application server, and do not maintain lists of the clients they service.  The load balancer is allowed to distribute client requests according to its configured distribution scheme.
 +
[[Image:OSEENetworkDiagram.png|thumb|center|400px|OSEE Network Diagram]]
  
 
==Links==
 
==Links==

Revision as of 12:33, 7 May 2016

System Overview

The Open System Engineering Environment (OSEE) is an integrated, extensible tool environment for large engineering projects. OSEE is more than an integrated development environment (IDE), but is an integrated product life-cycle development environment. The system captures project data into a common user-defined data model providing bidirectional traceability, project health reporting, status, and metrics which seamlessly combine to form a coherent, accurate view of a project in real-time. By building on top of a central data model, OSEE provides an integrated configuration management, requirements management, implementation, testing, validation, and project management system. All of the components work together to help an organization achieve lean objectives by reducing management activities, eliminating data duplication, reducing cycle-time through streamlined processes, and improving overall product quality through work flow standardization and early defect detection.

OSEE High Level System Overview

OSEE is customizable to meet the needs of the project. The teams working on the project, the roles they perform, and the processes they follow are all configurable within OSEE. Traceability is maintained from requirements through acceptance testing. The OSEE High Level System Overview diagram illustrates the range of users and the roles they may perform, which encompasses the entire product life-cycle

  • Requirements Engineer can create, manage, track requirements
  • Implementation Engineer may design, implement, integrate, unit test the product from software to hardware.
  • Test Engineer may perform different levels of integration or acceptance testing, and provide comprehensive test reporting.
  • Project Manager can track the progress of the product and gather customized metrics in order to best gain insight into the project status.
  • System Administrator manages the user accounts and IT needs.
  • Support Engineer can trace progress on customer issues
  • Maintenance Engineer can run validation, verification, or diagnostic tests on the target environment.

OSEE Quality Attributes

The following defines the high level quality attributes for the OSEE system

  • Changeability - New or updated features/services can easily be integrated into OSEE.
  • Extensibility - The services/components provided with OSEE will be reusable and/or extendable.
  • Flexibility - The tailoring of OSEE for a specific project can be accomplished through dynamic configuration.
  • Openness - OSEE uses open standards to enable quality, standardized, and well thought-through interfaces.
  • Performance - The system will respond in a timely manner to user input and queries.
  • Scalability - The system will scale as the number of users and managed projects increase.

OSEE Components

OSEE follows a client server architecture with a thin client and one to N servers. The client can exist in two different forms: One, a web browser client; Two, an Eclipse based IDE. The OSEE Server is built utilizing the Eclipse Equinox OSGi framework. All instances of the server attach to a single centralized data repository.

OSEE Client Server View

At the core of OSEE Application Server is the Object Revision Control System Framework. On top of the framework sits four core components: Action Tracking System (ATS), Define, Coverage, and Open System Engineering Test Environment (OTE). The User Management component, which allows for user authentication, verification and role based access control (RBAC), is used by all of the OSEE components.

OSEE Component Diagram

OSEE is built on top of Eclipse, and utilizes the OSGi framework to manage the component bundles. Capabilities provided by 3rd party libraries and exposed in the Base Level API include:

  • Logging - Provide a consistent logging mechanism
  • Console - User ability to issue command line operations on the server
  • JAX-RS - Java REST API for web services
  • Event Management - ActiveMQ is used for event messaging

OSEE Framework

OSGi Framework

The OSGi Framework Linked above provides the underlying support for the OSEE Framework. The Eclipse implementation of OSGi is called Equinox. The Equinox framework supports Extensions, Services, Declarative Services and Spring-OSGi. Since OSEE is built on top of this extendable foundation, it inherits these capabilities. OSEE developers have taken advantage of this, and primarily use Extensions and Declarative Services to further extend capabilities.

Extensibility

The layered approach provides extensibility to OSEE. The IDE Client is extended through the use of Eclipse Extension Points. The OSEE Application Server is extended through Declarative Services. As described in the following sections, the data model is abstracted one level up, so that a broad variety of specific data can be expressed in the data model. The database interface complies with standard SQL-99 ("with" clause is used so SQL-92 is not sufficient), so relational databases providing SQL-99 compliance can be substituted in through the use of JSON configuration files provided in OSEE.

Object Revision Control System

The heart of the OSEE Framework is the Object Revision Control System (ORCS). ORCS provides the foundation the rest of the components are built on top of. The key capabilities provided by ORCS are:

  • Object Management - The definition and persistence of any object of any simple or complex type can be managed, and type safety is ensured on all operations.
  • Data Model - the underlying data model is configurable per project
  • Version management - baselines and branching for a project are managed
  • Generic UI editor framework - customized editors can be created
  • Searching/Indexing
  • Transaction Management
  • Administration
  • Data Import/Export - external systems can supply or consume data

Data Model

The object management provides the core building blocks for the centralized data model. The core building block for the data model consists of:

  • Artifact - The fundamental object in OSEE. All data objects stored within OSEE are artifacts. Artifacts are strongly typed and can store any data throughout the systems engineering lifecycle. Artifacts have a Description, Type, and set of 1..n Attributes. Any type of data can be stored as an artifact; not only systems engineering data (such as processes and requirements), but also anything from meeting minutes to architecture diagrams.
  • Attribute - A specific piece of data attached to an Artifact. Attribute consists of Description, Type, default value (optional), Min occurrences in an artifact, Max occurrences in an artifact. An Attribute can be a basic type or a more complex type like another Artifact.
  • Relation - Defines the relationship (link) between two artifacts. The relation is strongly typed, which means it can only be used to link the specified artifact types. The relation allows the multiplicity between the two types to be specified as: 1..1, 1..*, *..1, *..*
Artifact Attribute Relation Diagram

Version Management

Version management allows for the parallel development of different variations of a product, as well as the sharing of common information across similar products. Changes made to one version baseline can be merged to another version baseline in order to maintain commonality as desired.

Version management example

Action Tracking System (Details)

The Action Tracking System (ATS) is a tightly integrated tracking system that manages changes throughout the different aspects of a product's lifecycle. ATS provides integrated change management to all OSEE applications through customizable work processes (workflows) and ensures traceability from start to completion. ATS utilizes the core capabilities provided by the ORCS layer.

ATS is highly configurable and can be configured to meet any project's work tracking needs. The level of detail of work items, team organization, and process to complete work item types are all configurable for a project. The configuration is realized through the use of the data model to create the core building blocks of ATS: Action, Actionable Item, Team Definition, Workflow Definition, Task, and Version.

At the highest level, an item of work to be completed is referred to as an Action. Actions are created as work is needed for a project.

A project can specify a work hierarchy for the different kinds of work tasks that need to be performed and tracked. Each defined work category is referred to as an Actionable Item (AI). An Action can be composed of a single or multiple AIs.

Actionable Item Hierarchy Example

A team can be assigned to work on an AI. The team definition is similar to an organization chart, or a logical grouping of teams that perform certain types of work.

Team Definition Example

Each Team Definition has a Workflow Definition (or state machine) that defines the process that team uses to track and complete the work. Each state of the workflow can have configured conditions or fields that are required to transition. A Review can be attached to a state and can block the transition until successfully completed.

Workflow Definition Example

A Task is the lowest level of work, and is used to allocate the work to individuals. A Task can be associated with a particular state or a state can have multiple tasks that need completing before the workflow can advance to the next state.

Task Allocation Example

A Version is used to group a set of Actions together into a "build", "release", "edition", etc. A common set of actions can apply to more than one version enabling data sharing across similar or variant projects. The version capability relies on the version management framework.

Status data associated with tasks can be used to create metrics that roll-up to the Workflow, which can roll up to the Team, which can roll-up to the Action, which roll-up to the project. Metrics can be obtained for any specified grouping within the project (e.g. Team, Version, etc.)

ATS Architecture Details

Define

Define is the requirements management component of OSEE. Define provides support for concurrent and distributed requirements development. Requirements can be imported from other sources to provide comprehensive and coherent requirements management across the product life-cycle.

Since Define uses the OSEE data model and version management, the following list of properties applies. Requirements in OSEE:

  • can be hierarchical
  • can be integrated into the processes and workflows
  • will have bidirectional traceability from beginning to end of the product life-cycle
  • will have meaningful review metrics
  • can support parallel project development

Coverage

Coverage provides for the configuration management and tracking of coverage disposition efforts throughout a project. OSEE allows for the configuration of what is tracked for verification and validation on the project. For example, in a software project the lines of code in the software can be exercised through software tests, and tools can determine how many of the software lines of code where executed during the tests. A report is generated and can be imported by Coverage and a complete coverage report generated.

Coverage Overview

The Coverage is configurable through the creation of a Coverage Package. The Coverage Package configuration includes all the inputs (unit tests, test scripts, coverage test report imports), traceability (results to tests, tests to requirements) and outputs (reports, metrics) desired. The Coverage Package will also allow for checking the differences between test runs by comparing different instances of test result imports.

Open System Engineering Test Environment

The Open System Engineering Test Environment (OTE) is an integrated approach to product testing, and follows a client/server architecture. The OTE client is part of the OSEE client, while the OTE Server is separate from the OSEE Application Server.

The OTE Client provides:

  • Test Manager for configuration of tests and test environment
  • Automated test execution
  • An API to create simulated test components (models)
  • Managing of tests (unit tests, scripts, etc.)
  • Real-time test result monitoring, recording, and playback
  • Test result reporting and coverage

The OTE Test Server provides:

  • A test execution manager
  • A simulated test environment that manages/executes test models
  • Managing I/O connections to the target test environment
  • Managing the test environment resources
  • Relay real-time test data to client
OTE Architecture Diagram

OSEE Functional Use Cases

OSEE Deployment

OSEE is designed to work in a collaborative environment, supporting many developers working on the same data. One of the many considerations to help accomplish this is the use of a multi-tier architecture to maintain a common set of underlying data for all. Specifically, OSEE utilizes a three tier paradigm to separate the user interface from the component capabilities. There are three cases that are important to understand.

Single User Deployment

This is the default deployment if you download OSEE from the web. The embedded HSQL database will be automatically created when the server is run in a command shell. The client is configured to connect to the local server by default.

OSEE Single User Diagram

Multi-User, Single Application Server Deployment

The multi-user deployment can be achieved by installing OSEE clients on separate machines that have network access to the server machine. The client .ini file needs to be configured to connect to the Application Server machine. A more robust database can be configured for the Application Server via the database JOSN configuration file.


OSEE Multi User Diagram

Multi-User, Multi-Application Server Deployment

Multi-Application Server deployment should be considered if:

  • higher availability for the application server is required
  • the Application Server becomes over burdened, impacting server response time

In these cases, load balancing across multiple application servers is encouraged. OSEE Application servers are designed to support load balancing, and do not require the client to connect to a specific application server, and do not maintain lists of the clients they service. The load balancer is allowed to distribute client requests according to its configured distribution scheme.

OSEE Network Diagram

Links

Images were created using Inkscape

Back to the top