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/Users Guide/Concepts"

 
(10 intermediate revisions by one other user not shown)
Line 1: Line 1:
=Artifact=
+
=Artifacts=
  
The artifact is the base object in OSEE. It represents any data object that is to be stored. Object data is stored in attributes. Artifacts are defined by their Artifact Type. Artifact Types can inherit from one another. All artifacts inherit from '''Artifact''' which is similar to the Object class in Java.
+
The '''artifact''' is 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. Any type of data can be stored in OSEE as an artifact; not only systems engineering data (such as processes and requirements), but also anything from meeting minutes to architecture diagrams.
 
+
Example:  a single requirement, a user object, a piece of code (or class), a document
+
  
 
=Attributes=
 
=Attributes=
  
An attribute is a key/value pair representing a single data element. Attributes define an artifact's meta-data. Attributes are defined by its attribute type.
+
An '''attribute''' is data attached to an artifact. A <tt>User</tt> artifact might have <tt>Email</tt>, <tt>Name</tt>, and <tt>Phone Number</tt> attributes. A <tt>Software Requirement</tt> artifact might have attributes such as <tt>Qualification Method</tt>, <tt>Safety Criticality</tt>, or <tt>Subsystem</tt>.
An attribute type defines classes to handle how an attribute's value will be stored, search, and tagged. In addition, the attribute type defines the attribute value's data type.
+
  
The attribute base type is used to convert raw data into a native type or other object. See [#Attribute Base Types] below for a list of the default attribute base types.
+
The default attribute <tt>Name</tt> is required for all artifacts. Other attribute types can be created and associated with any artifact in the system.
The attribute's backing data is managed by an attribute data provider which transfers data between client/server or can be extended to server data from outside the OSEE data store.
+
  
The default attribute "Name" is required for all Artifacts.
+
=Relations=
Other attribute types can be created and associated with any Artifact Type in the system.
+
  
Example: Artifact representing a "User" of an application may have attributes such as "Phone", "Address", "City", etc...
+
A '''relation''' is a link between two artifacts. Like artifacts, they are strongly typed; an <tt>attend</tt> relation <tt>attend</tt> might relate a <tt>User</tt> artifact to a <tt>Meeting</tt> artifact. Similarly, a <tt>Customer Requirement</tt> might be linked to the low-level <tt>Software Requirement</tt> that satisfies it.
  
==Attribute Base Types==
+
=Branches=
  
* String
+
A fundamental feature provided by OSEE is the concurrent management of multiple variants or lines of a product. After a set of requirements is developed, it may become the baseline for variant sets of requirements for similar products. In other words, you may develop the same product for another customer, but have slight changes to the requirements, code, and test for features specific to that customer.
** Word Templated Content
+
** Word Whole Document
+
* Date
+
* Boolean
+
* Integer
+
* Floating Point
+
* Enumeration
+
  
=Relations=
+
Historically, this would mean maintaining completely separate "copies" of all the requirements and other artifacts. This is costly to maintain when changes from the baseline artifacts must be propagated to the other product line. The expense of this undertaking increases dramatically as more customers are added, each with their own set of requirements changes.
 +
 
 +
For this reason, OSEE provides full '''branching''' functionality. Using OSEE, it is possible to create these variant branches, record where they originated, and to apply changes made to a baseline branch to its variants.
 +
 
 +
By default, OSEE has two system branches. The <tt>System Root Branch</tt> is the parent of all other branches in the system. The <tt>Common</tt> branch is used to store OSEE configuration information, such as users. <tt>Common</tt> is a child of <tt>System Root Branch</tt>.
 +
 
 +
==Working Branches==
 +
 
 +
On complex projects, artifacts can be subject to modification by any one of hundreds of engineers. To have requirements "locked" while they are being modified by one user can cause significant delays in schedule.  The need for parallel development (multiple users working on the same requirements) is a necessity to keeping a project moving forward.  In addition, users making mistakes need the ability to revert or throw away their changes and start over without polluting the baseline branch. This is done using '''working branches'''. A working branch is a sandbox area used to prepare a commit to a baseline branch.
 +
 
 +
=BLAM=
 +
 
 +
'''BLAM Lightweight Artifact Manipulation''' (BLAM) allows non-programmers to graphically construct workflows to automate repetitive tasks. A given workflow can be used for variety of similar tasks by using customizable controls to specify workflow parameters.  BLAM also provides programmers the ability to interact with the OSEE Artifact Framework API to build and execute tasks.
 +
 
 +
=Requirements traceability for a system=
 +
 
 +
Every requirement for a system is defined at a distinct level of detail, and these levels are ordered from the highest level down to the lowest level.  A trace relation connects two requirements from adjacent levels.  Every requirement that is not a top level (highest level) requirement, must trace to one or more requirement at the next higher level.  All requirements, except those at the lowest level, must trace to one or more requirement at the next lower level.
  
A relation relates two or more artifact instances. A relation is defined by its relation type which specified what artifact type is allowed on the A side, what artifact type is allowed on the B side, and how many artifact instances are allowed on either side of the relation.
+
=Functional decomposition of a system=
  
=Branch=
+
The functional decomposition of a system produces a proper tree (i.e. every node in the tree has exactly one parent except the root which has no parent).  The tree's root represents the system in its entirety.  The root is decomposed into some number of components that can be further decomposed to any desired level.  Neither the root nor any of its components are themselves requirements.
  
Changes to artifacts, attributes, and relations are managed by a transaction based version control system using fine grained change identification. These changes are managed under branches. By default, OSEE has two system branches:
+
=Allocation of Requirements=
# '''System Root Branch''' - is the parent of all other branches in the system.
+
# '''Common Branch''' - is used to store OSEE configuration information such as users, etc.. The Common Branch is a child of the System Root Branch.
+
  
Product data is defined in child branches of the System Root Branch.
+
Requirements are allocated using allocation relation links to components (of the functional decomposition).  A requirement at a given level is allocated to a component at the corresponding next lower level in the functional decomposition.
  
A branch goes through the following states during its life-cycle: Created, Modified, Committed, Re-Baselined, Deleted.
+
=Verification and Validation relations=
  
=Configure a New Project in OSEE=
+
Verification and Validation relations should be defined for requirements at every level of the requirements decomposition.
# Create baseline branch
+
## From the Branch Manager's select parent branch -> open context menu -> select "branch" and enter new branch name
+
## From the Branch Manager's select new branch -> open context menu -> access control
+
### Add system administrators with Full Access
+
### Add Everyone with Read Access
+

Latest revision as of 13:45, 19 October 2010

Artifacts

The artifact is 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. Any type of data can be stored in OSEE as an artifact; not only systems engineering data (such as processes and requirements), but also anything from meeting minutes to architecture diagrams.

Attributes

An attribute is data attached to an artifact. A User artifact might have Email, Name, and Phone Number attributes. A Software Requirement artifact might have attributes such as Qualification Method, Safety Criticality, or Subsystem.

The default attribute Name is required for all artifacts. Other attribute types can be created and associated with any artifact in the system.

Relations

A relation is a link between two artifacts. Like artifacts, they are strongly typed; an attend relation attend might relate a User artifact to a Meeting artifact. Similarly, a Customer Requirement might be linked to the low-level Software Requirement that satisfies it.

Branches

A fundamental feature provided by OSEE is the concurrent management of multiple variants or lines of a product. After a set of requirements is developed, it may become the baseline for variant sets of requirements for similar products. In other words, you may develop the same product for another customer, but have slight changes to the requirements, code, and test for features specific to that customer.

Historically, this would mean maintaining completely separate "copies" of all the requirements and other artifacts. This is costly to maintain when changes from the baseline artifacts must be propagated to the other product line. The expense of this undertaking increases dramatically as more customers are added, each with their own set of requirements changes.

For this reason, OSEE provides full branching functionality. Using OSEE, it is possible to create these variant branches, record where they originated, and to apply changes made to a baseline branch to its variants.

By default, OSEE has two system branches. The System Root Branch is the parent of all other branches in the system. The Common branch is used to store OSEE configuration information, such as users. Common is a child of System Root Branch.

Working Branches

On complex projects, artifacts can be subject to modification by any one of hundreds of engineers. To have requirements "locked" while they are being modified by one user can cause significant delays in schedule. The need for parallel development (multiple users working on the same requirements) is a necessity to keeping a project moving forward. In addition, users making mistakes need the ability to revert or throw away their changes and start over without polluting the baseline branch. This is done using working branches. A working branch is a sandbox area used to prepare a commit to a baseline branch.

BLAM

BLAM Lightweight Artifact Manipulation (BLAM) allows non-programmers to graphically construct workflows to automate repetitive tasks. A given workflow can be used for variety of similar tasks by using customizable controls to specify workflow parameters. BLAM also provides programmers the ability to interact with the OSEE Artifact Framework API to build and execute tasks.

Requirements traceability for a system

Every requirement for a system is defined at a distinct level of detail, and these levels are ordered from the highest level down to the lowest level. A trace relation connects two requirements from adjacent levels. Every requirement that is not a top level (highest level) requirement, must trace to one or more requirement at the next higher level. All requirements, except those at the lowest level, must trace to one or more requirement at the next lower level.

Functional decomposition of a system

The functional decomposition of a system produces a proper tree (i.e. every node in the tree has exactly one parent except the root which has no parent). The tree's root represents the system in its entirety. The root is decomposed into some number of components that can be further decomposed to any desired level. Neither the root nor any of its components are themselves requirements.

Allocation of Requirements

Requirements are allocated using allocation relation links to components (of the functional decomposition). A requirement at a given level is allocated to a component at the corresponding next lower level in the functional decomposition.

Verification and Validation relations

Verification and Validation relations should be defined for requirements at every level of the requirements decomposition.

Copyright © Eclipse Foundation, Inc. All Rights Reserved.