Home             About             Interoperability Model

Glossary

Version 1.10

14 Dec 2017

The Glossary contains terms deemed necessary for Empowering Government, Standards Coordination, or necessary technical aspects such as Interoperability, Security, Interoperability Engineering, or Architecture. 

Terms are organized into various concept-specific vocabularies with each vocabulary containing terms from the Integrated Master List of All Terms.  For example, Activity, Architecture View, and Association are three terms in the Integrated Master List of All Terms that are a part of the Architecture and Modeling Vocabulary.  Click on the links, below, to visit a particular vocabulary’s table of contents

Vocabularies. 1

Architecture and Modeling Vocabulary. 1

Security Vocabulary. 2

Business and Operational Vocabulary. 2

Integrated Master List of All Terms. 2

Definition Sources. 102

Term Content Overview.. 104

Change Log and Version History. 105

  

Vocabularies

Architecture and Modeling Vocabulary

Activity

Activity Goal

Architecture, Conceptual

Architecture, Deployment

Architecture, Description

Architecture, Framework

Architecture, Layer

Architecture, View

Architecture, Viewpoint

Association

Attribute

Business Component

Business impact analysis

Business Object

Business Process

Business Process Model and Notation (BPMN)

Choreography

Class

Collaboration

Component

Composition

Conjunctive Composition

Controller

Dependency Injection

Deployment Diagram

Endpoint

Endpoint address

Entity

Extends Relationship

Includes Relationship

Injection, Dependency

Injection, Metadata

Model Checking (or Model Validation)

Model, Component

Model, Deployment

Modeling and Simulation (M&S)

Model, Element

Step

Unified Modeling Language (UML)

UML Profile


 

 

Security Vocabulary

 

ABAC (Attribute-based Access Control)

Access Control

Assertion

Authenticated identity

Authentication

Authorization

Bioterrorism

Control

Critical Asset

Cryptography

CyberSecurity

CyberSpace

Identity

Identity authentication

Identity domain

Identity information

Identity management

Identity verification

Information Security Risk

Information Sharing

Least Privilege

Need to Know

Personally Identifiable Information – (PII)

Privacy

Privacy Risk Assessment

Privilege

RBAC (Role-based Access Control)

RBAC-ABAC

Risk

Risk Analysis

Risk Assessment

Risk Evaluation

Risk Identification

Risk Management

Risk Response

Risk Tolerance

Robustness

Security Assertion Markup Language (SAML)

Security

Security Control

Security Functions

Security Policy

Situational Awareness

Testable (Testbed)

Threat

Threat analysis

Threat Event

Trust

Trustmark

Vulnerability

Vulnerability Assessment

 

Business and Operational Vocabulary

tbd

Integrated Master List of All Terms

 

ABAC (Attribute-based Access Control)

Access Control

Activity

Activity Goal

Architecture, Conceptual

Architecture, Deployment

Architecture, Description

Architecture, Framework

Architecture, Layer

Architecture, View

Architecture, Viewpoint

Assertion

Association

Assurance

Attribute

Authenticated identity

Authentication

Authorization

Automatic

Automation

Autonomy

Availability

Biosurveillance

Bioterrorism

Business Component

Business impact analysis

Business Object

Business Process

Business Process Model and Notation (BPMN)

Capability

Choreography

Class

Client

Collaboration

Common Profile

Common Terminology Services (CTS)

Component

Composition

Common Alerting Protocol (CAP)

Conceptual Work Product

Concern

Confidentiality

Conjunctive Composition

Consumer/ Provider

Context

Control

Controller

Cooperative Process Control

Coordinate

Coordination

Criticality

Critical Asset

Cross-cutting concern

Cross-cutting function

Cryptography

Customer

CyberSecurity

CyberSpace

Data Aggregation Reference Architecture (DARA)

Dependency Injection

Deployment Diagram

Design Pattern

Device

Device Endpoint

Device Independence

Element

Emergency Data Exchange Language Situation Reporting (EDXL-SitR)

Emergent behavior

Endpoint

Endpoint address

Entity

Environment

Security

Environment, Security

Extensible Access Control Markup Language (XACML)

eXtensible Markup Language (XML)

Extends Relationship

Federation

Firmware

Functional component

Functional domain

Functional framework

Functional Unit

Gateway

Geospatial Interoperability Reference Architecture (GIRA)

Global Federated Identity and Privilege Management (GFIPM)

Global Reference Architecture (GRA)

Health Level Seven (HL7)

Identification

Identifier

Identity

Identity authentication

Identity domain

Identity information

Identity management

Identity verification

Includes Relationship

Information Interoperability Framework (I2F)

Information Portability

Information Resource

Information Security Risk

Information Sharing

Infrastructure Services (synonym: Core Services)

Injection, Dependency

Injection, Metadata

Integrity

Interface

Internet

Interoperability

Interoperability Level

Interoperability Maturity

Inversion of Control (IoC)

IP endpoint

JavaScript Object Notation (JSON)

Late Binding

Least Privilege

Lexicon

Logical Entity Exchange Specifications (LEXS)

Measure of Effectiveness (MOE)

Measure of Performance (MOP)

Message (Payload)

Model Checking (or Model Validation)

Model, Component

Model, Deployment

Modeling and Simulation (M&S)

Model, Element

Modular Open Systems Architecture (MOSA)

National Information Exchange Model (NIEM)

Need to Know

NIEM

NIEM-UML

Network

Non-functional requirement

Observer

Ontology

Operation, Mission

Operation, UML

Orchestration

Party

Personally Identifiable Information – (PII)

Physical Entity

Pipeline

Policy

Portability

Privacy

Privacy Risk Assessment

Privilege

Profile

Reciprocal Operation

Reference Implementation

Representational State Transfer (REST)

Resilience

RBAC (Role-based Access Control)

RBAC-ABAC

Risk

Risk Analysis

Risk Assessment

Risk Evaluation

Risk Identification

Risk Management

Risk Response

Risk Tolerance

Robustness

Role

Security Assertion Markup Language (SAML)

Security

Security Control

Security Functions

Security Policy

Sensitivity

Sensor

Service

Service Broker

Service Contract

Service Oriented Architecture

Segment / Delivery Segment

Simple Object Access Protocol (SOAP)

Situational Awareness

Standards Development Organization (SDO)

Stakeholder

Step

Story

System Modeling Language (sysML)

System

System Component

Taxonomy

Task

Testable (Testbed)

Test and Conformance Platform

Test Case

Test Harness

Thread, Functional

Thing

Threat

Threat analysis

Threat Event

Trust

Trustmark

Unified Modeling Language (UML)

UML Profile

Unit of Work

Unit of Work, Transactional

Unit of Work, User

Usage capacity

Use Case

User

User Story

user endpoint

Validation

Verification

Version History

View

ViewPoint

Virtual Entity

Vocabulary

Vulnerability

Vulnerability Assessment

Work Package

 

 

Grouping

Term

Definition

Source

Security

ABAC (Attribute-based Access Control)

See RBAC-ABAC

NIST

Security

Access Control

Teaser: A means to ensure that access to assets is authorized and restricted based on business and security requirements

Note: Access control requires both authentication and authorization

ISO/IEC 27000:2014

Modeling

Activity

Teaser: A specified coordination of tasks that are required to realize the system capabilities. 

Detail: An activity requires at least one resource to perform it. The resources may be physical or informational. Both types constrain the way activity can be performed. 

Note: an activity may be composed of other activities

Synonyms: : the term Mission Operations may be used by end-users when Activities are orchestrated and assigned resources to accomplish a specified objective

ISO/IEC 17789:2014 ++

 

Modeling

Activity Goal

Teaser:  An objective specification of the physical or informational effect the Activity must have to succeed

Detail: A declarative specification of the intended effect of an operation that is independent of the means to achieve it. The effect may be a desired change in the physical world, the creation of a physical artifact, or a conceptual work product. The goal can be applied to evaluate the success of the operation.

Note:

See also MOE

See also Activity

U of Washington

Modeling

Architecture, Conceptual

Teaser:  A composition of business objects used to represent concepts of real and possible worlds without requiring any information system or communications pattern.  Below is example of a Conceptual Architecture

OMG Conceptual Architecture RFP

Modeling

Architecture, Deployment

A model of the system as it will be physically deployed

UML (MDA)

Modeling

Architecture, Description

work product used to express an architecture

ISO/IEC 42010:2011

Modeling

Architecture, Framework

conventions, principles and practices for the description of architectures established within a specific domain of application and/or community of stakeholders

ISO/IEC 42010:2011

Modeling

Architecture, Layer

A logical partitioning of the architecture

 

Modeling

Architecture, View

work product expressing the architecture of a system from the perspective of specific system concerns

ISO/IEC 42010:2011

Modeling

Architecture, Viewpoint

work product establishing the conventions for the construction, interpretation and use of architecture views to frame specific system concerns

ISO/IEC 42010:2011

Security

Assertion

Teaser: statement made by an entity without accompanying evidence of its validity

Detail:  Statements of fact (such as identity, conformance, or a level of security), particularly when made by an identified party in order to induce reliance.  Common examples include:  a statement that a specific data message conforms to a data standard;  or a statement that a data message was authored by a particular person who holds a specific identity token, name or credential.  Important because the security, reliability and safeguarding of most data transactions relies on assertions associated with specific data or messages -- such as "this message is from office X, according to certificate Y," or "this message is encrypted in conformance with the ABC data standard."  See Section (IV.C) for more.

 

ITU-T X.1252

Modeling

Association

A relationship between two or more entities. Implies a connection of some type - for example one entity uses the services of another, or one entity is connected to another over a network link.

UML/sysML

 

Assurance

grounds for justified confidence that a claim has been or will be achieved

ISO/IEC TR 15026-1:2010

Modeling

Attribute

characteristic or property of an entity that can be used to describe its state, appearance, or other aspects

ISO/IEC 24760-1:2011

Security

Authenticated identity

identity information for an entity created to record the result of identity authentication

ISO/IEC 24760-1:2011

Security

Authentication

Teaser: provision of assurance that a claimed characteristic of an entity is correct

ISO/IEC 27000:2014

Security

Authorization

Teaser: Granting of rights, which includes the granting of access based on access rights

ISO 7498-2:1989

 

Automatic

Teaser: Working by itself with little or no direct human control

OED

 

Automation

Teaser: The use or introduction of automatic equipment in a manufacturing or other process or facility.

·         Note: Automation emphasizes efficiency, productivity, quality, and reliability, focusing on systems that operate without direct control, often in structured environments over extended periods, and on the explicit structuring of such environments.

OED

 

Autonomy

The ability of an intelligent system to independently compose and select among different courses of action to accomplish goals based on its knowledge and understanding of the world, itself, and the situation.

IHMC

 

Availability

property of being accessible and usable upon demand by an authorized entity

ISO/IEC 27000:2014

 

Biosurveillance

Biosurveillance is an American Health Information Community breakthrough area defined as implementation of real-time, nationwide public health event monitoring to support early detection, situational awareness, and rapid response management across public health and care delivery communities and other authorized government agencies.

The House Committee on Energy and Commerce has decided to investigate the creation of the National Biosurveillance Integration System at the Department of Homeland Security.

The operation was mandated by Homeland Security Presidential Directive 10. Its mission is “to provide early detection and situational awareness of biological events of potential national consequence by acquiring, integrating, analyzing, and disseminating existing human, animal, plant, and environmental biosurveillance system data into a common operating picture.”

IJIS

Security

Bioterrorism

A bioterrorism attack is the deliberate release of viruses, bacteria, or other germs (agents) used to cause illness or death in people, animals, or plants. These agents are typically found in nature, but it is possible that they could be changed to increase their ability to cause disease, make them resistant to current medicines, or to increase their ability to be spread into the environment. Biological agents can be spread through the air, through water, or in food. Terrorists may use biological agents because they can be extremely difficult to detect and do not cause illness for several hours to several days. Some bioterrorism agents, like the smallpox virus, can be spread from person to person and some, like anthrax, cannot.

IJIS

Modeling

Business Component

See also Component  Also see Business Object

The concept of facilitating the creation and storage of reusable components for NIEM IEPD creation. Business components typically consist of an aggregation of data components into a construct that serves a specific business need, such as assembling name and address elements to create a Home Address component. These components can then be reused, saving development time and costs and avoiding duplication of effort across NIEM implementations

 

MOdeling

Business impact analysis

Teaser: The process of analyzing operational functions and the effect that a disruption might have upon them

Detail:  Impact can be specified as being

·         Beneficial:

·         Neutral

·         Derogatory

See the viewpoints of the Vision, Strategy and Scope portion of the UML Model for details.

ISO/IEC 27031:2011

Modeling

Business Object

Teaser: A Business Object is a customer/user-recognizable thing that is important to the business/mission without any preconditions on context or definition. 

Detail:  Business objects are labeled with names that make sense to the customer/user, and as is depicted below, have relationships to each other.  Ultimately, Business Objects are the nouns used in User Stories and User Stories must abide by the relationships between Business Objects in the business object model.  From the example below, you cannot define User Stories consistent with the objects in this model. Click on the image, below, to learn more.

See also Information Resource

OMG, Cockburn, the Ratio Group, etc.

Modeling

Business Process

Teaser: A collection of Steps taking place in a prescribed manner and leading to an objective.

·         A process may have multiple starting points and multiple end points.

·         The prescribed manner may be a partially ordered sequence.

·         A process specification can be a workflow specification.

·         An enterprise specification may define types of processes and may define process templates.

ISO/IEC 15414

Modeling

Business Process Model and Notation (BPMN)

Teaser: OMG graphical language for requirements analysis of people collaborating on physical and information work with computer support.

Detail: Companion to UML and sysML, the BPMN provides organizations with the capability of understanding their internal business procedures in a graphical notation that gives them the ability to communicate these procedures and processes in a standard manner. Based upon standard flowcharting techniques, BPMN diagrams are very similar to UML Activity Diagrams.

OMG

 

Capability

Teaser: A Capability is a discrete expression of a desired outcome that a Stakeholder/Mission Partner wants to see in a system.

Detail: Mission partners and stakeholders have automated computer software-based information systems capabilities that they provide to one another. These capabilities solve or support a solution for the problems [businesses] face in the course of their business. That is, capabilities are the things organizations have to solve problems and therefore add value, directly or indirectly, to their stakeholders.

Discussion: Capabilities are descriptions of behavior and for them to be unambiguous must be tangible and measurable. The specification. Depicted below, provides the detailing elements that are necessary for any capability. Click on the image to review the UML specification for a capability.  Click on the link below to explore the parts of a Capability specification.

OMG

 

 

SCC

Modeling

Choreography

Type of composition whose elements interact in a non-directed fashion with each autonomous part knowing and following an observable predefined pattern of behavior for the entire (global) composition

ISO/IEC DIS 18834-1

Modeling

Class

A logical entity encapsulating data and behavior. A class is a template for an object - the class is the design, the object the runtime instance.
Class Notation

See also Operation, UML

UML

 

Client

Teaser: A client is the requesting program or user in a client/server relationship.

Detail: For example, the user of a Web browser is effectively making client requests for pages from servers all over the Web. The browser itself is a client in its relationship with the computer that is getting and returning the requested HTML file. The computer handling the request and sending back the HTML file is a server.

 

Modeling

Collaboration

Type of composition whose elements interact in a non-directed fashion, each according to their own plans and purposes without a predefined pattern of behavior

ISO/IEC DIS 18834-1

 

Common Profile

Teaser: A Common Profile is a means to standardize the way a modular component profile or an information interoperability profile is documented.

Detail:  A common profile is a set of instructions that describes how to achieve a desired outcome. Similarly, the Common Profile supports the mission and business needs across government organizations by identifying a base set of elements, specifications, and/or standards so that these organizations can become interoperable through sharing services and information resources.  See also Profile

ISE.gov

 

Common Terminology Services (CTS)

A Joint effort of the Mayo Clinic and the OMG, Common Terminology Services provides a standard for a shared semantic model and API for the query,

interchange and update of terminological content. http://www.omg.org/spec/CTS2/1.1/  (also See HL-7)

OMG

HL-7

Modeling

Component

modular, deployable, and replaceable part of a system that encapsulates implementation and exposes a set of interfaces
UML Component Diagram

ISO/TS 19104:2008

Modeling

Composition

Teaser: Result of assembling a collection of elements for a particular purpose. 

Detail: in the UML, composition is often thought of some sort of assembly has-a component.  As an example of composition, A Person has-a Leg and has-a Hand.  Or stated another way, the Person assembly is composed of Leg and Hand.

[image[5].png]

ISO/IEC DIS 18834-1

 

Common Alerting Protocol (CAP)

The Common Alerting Protocol (CAP) provides an open, non-proprietary digital message format for all types of alerts and notifications. It does not address any particular application or telecommunications method. The CAP format is compatible with emerging techniques, such as Web services, as well as existing formats including the Specific Area Message Encoding (SAME) used for the United States National Oceanic and Atmospheric Administration (NOAA) Weather Radio and the Emergency Alert System (EAS), while offering enhanced capabilities that include: flexible geographic targeting using latitude/longitude shapes and other geospatial representations in three dimensions; multilingual and multi-audience messaging; phased and delayed effective times and expirations; enhanced message update and cancellation features; template support for framing complete and effective warning messages; compatible with digital signature capability; and facility for digital images and audio. Key benefits of CAP will include reduction of costs and operational complexity by eliminating the need for multiple custom software interfaces to the many warning sources and dissemination systems involved in all-hazard warning. The CAP message format can be converted to and from the native formats of all kinds of sensor and alerting technologies, forming a basis for a technology-independent national and international warning internet. Find out more at http://docs.oasis-open.org/emergency/cap/v1.2/CAP-v1.2-os.pdf.

OASIS

 

Conceptual Work Product

Teaser: An element of a conceptual architecture specified in an objective way to define the work of socio-technical systems.

Detail:  A declarative specification of the intended output of an activity or system in terms of business objects, relationships, constraints, states, and state rules for work that has no direct instance in the physical world until acted upon. Conceptual work activity is often performed in an environment of distributed cognition. Examples include plans, schedules, classifications, diagnoses, traffic management, etc.

 

 

Concern

Teaser: interest in a system relevant to one or more of its stakeholders .

Detail:  A concern pertains to any influence on a system in its environment, including developmental, technological, business, operational, organizational, political, economic, legal, regulatory, ecological and social influences.

ISO/IEC 42010:2011

 

Confidentiality

 property that information is not made available or disclosed to unauthorized individuals, entities, or processes

ISO/IEC 27000:2014

Modeling

Conjunctive Composition

Teaser:  the ability to use or combine services in ways not initially conceived.

Detail:  Services should be designed to provide the ability to use or combine services in ways not conceived by the service’s originators.  Conjunctiveness is achieved by applying late-binding and application specific metadata to the service.  Key aspects of conjunctiveness are (1) services interact with each other with minimal preconditions, and (2) they can evolve to meet specific needs without jeopardizing existing application contexts.  This is a key characteristic of Level 5 Interoperability.

PI

 

Consumer/ Provider

Definition 1:

Teaser: the relationship between creating a service and the use of the service

Detail: A consumer is considered a person or organization that maintains a business relationship with, and uses services from, the provider of the service. A provider is considered a person, organization, or entity responsible for making a service available to consumers.

Definition 2:

Teaser: the relationship between those who register services for usage (providers) and those who use them (consumers)

Detail: Service providers realize service specifications and/or fulfill service contracts. They may often do this by also being service consumers (or requestors) in that their provided service operations may be implemented as a composition of other service providers.

A service provider may interact with many service consumers and other service providers during its lifetime. Such a service provider will interact with other consumers and providers through specific interaction points that provide increased decoupling for more flexible service configurations and easier change management. For example, a purchase order processor service provider may need to interact with a purchaser, invoice provider, scheduler, and shipper. It would do so through separate interaction points so that a change in interactions with the invoice provider, for example, would be isolated to that interaction point and therefore limit the effect on other consumers and providers.

The Open Group

 

 

 

 

 

 

 

 

OMG: soaML

 

Context

Teaser: The boundary between the system, or part of a system, and its environment, showing the entities that interact with it.

Detail: A well typed event with associated environment descriptor recognizable as a meaningful to a system.  See Interoperability level 5: Dynamic Interoperability.

UML

 

 

Interoperability Level 5

Security

Control

Rules, devices or methods that limit the behavior of systems.  See Access_Control and Security_Control

 

Modeling

Controller

The Controller part of a Model-View-Controller software architecture.  The Controller orchestrates and manages the execution of the included view(s) and Models.  Associated with the Front End Controller Pattern.  This is necessary for level 4+ interoperability

Fowler, et.al Design Patterns

 

Cooperative Process Control

Teaser:  A focus on the lack of central control for the definition and delivery with minimal preconditions

Detail: Collaborative/cooperative process control is sort-of the same kind-of definitional thing as love: you know it when you have it.  But the problem with this is it does not help AT ALL when defining and measuring the absence or presence of interoperability.  And worse, it leaves it to the implementer to deliver against their own internal standard.  Therefore, one project’s collaboratively/cooperatively controlled component may or may not be collaboratively controlled in another usage context.  And there be the rub.  As you move further and further away from point-to-point type of connections to the ultimate of dynamically compose-able solutions that interoperate the nature of collaborative process control becomes more and more important.  If you cannot pick-and-choose the components to make up the fabric for a solution, then it becomes really-really tough to enable an environment where you can facilitate quick assembly of solutions from libraries of piece-parts.  Sort-of like what is depicted below (apologies for my artwork – or lack thereof):

DRUPAL, of course, has solved the Collaborative/ cooperative Process Control problem.  Their CORE service plus manifesting system does a good job of permitting assembly of components into “Assembler-specified” solutions.  All the DRUPAL “Deliverers” build stuff in parallel with very lightweight governance structures (read: none), but abide by a pretty strict set of “Collaborative Process Control” rules that both utilize the “Core” services and enable “Assemblers.”  Looking at DRUPAL under the covers reveals it’s that it is both elegant and crude.  The SCC can learn-from  benchmark against DRUPAL.  Or Spring.  Or Amazon.  Or angularJS.  Or dotNet. Or …But ultimately, we need to anchor on both a definition-for and an ethic-of Collaborative Process Control as foundational to Interoperability.

So recognizing the importance as a foundation for a definition of Cooperative/Collaborative Process Control, there is a struggle for a good, concise definition that will be meaningful and understandable and useful in the teaser form and illustrative and informative in extended forms.  One such teaser is this:

“A focus on the lack of central control for the definition and delivery with minimal preconditions”

Unsatisfying and not especially useful.  Here is another harvested from IEEE

“A business process interoperability and cooperative process enactment are important in order to achieve a common objective despite the distribution in space, time and organizations. This approach outlines a generic process to building cooperative controlled services.”

Not especially useful.  Stay tuned to this space as one of the most important of Project Interoperability definitions matures.

<In the Works>

 

Coordinate

Bring the different elements of (a complex activity or organization( into a harmonious or efficient relationship

OED

 

Coordination

The organization of the different elements of a complex body or activity so as to enable them to work together effectively

OED

 

Criticality

A measure of the degree to which an organization depends on the information or information system for the success of a mission or of a business function.

NISTIR 7298 R2

Security

Critical Asset

The physical, data and network objects essential to an entity's operation, safety and resilience that are to be protected by IS&S systems and adequate physical and cybersecurity measures.   Important because an organization's cybersecurity planning and risk management requires identification of its critical assets, and evaluation of the degree and type of protection each warrants.

 

 

Cross-cutting concern

concern that affects the whole system and thus may impact multiple layers of the architecture.

 

 

Cross-cutting function

a function that may be applied and realized across multiple layers of the architecture to address cross-cutting concerns.

 

Security

Cryptography

discipline that embodies principles, means, and mechanisms for the transformation of data in order to hide its information content, prevent its undetected modification and/or prevent its unauthorized use

ISO/IEC 18014-2:2009

 

Customer

A person or a company that requests and receives goods and services.  The “customer” of Project Interoperability are the pipeline projects.  The “customer” of a pipeline project is one who is an actor in one or more use cases..

 

Security

CyberSecurity

Definition 1

The ability to protect or defend the use of cyberspace from cyber attacks.

Definition 2

The activity or process, ability or capability, or state whereby information and communications systems and the information contained therein are protected from and/or defended against damage, unauthorized use or modification, or exploitation.

Extended Definition: Strategy, policy, and standards regarding the security of and operations in cyberspace, and encompass[ing] the full range of threat reduction, vulnerability reduction, deterrence, international engagement, incident response, resiliency, and recovery policies and activities, including computer network operations, information assurance, law enforcement, diplomacy, military, and intelligence missions as they relate to the security and stability of the global information and communications infrastructure

NIST CNSSI-4009

 

 

National Initiative for Cybersecurity Careers and Studies

Security

CyberSpace

A global domain within the information environment consisting of the interdependent network of information systems infrastructures including the Internet, telecommunications networks, computer systems, and embedded processors and controller

NIST CNSSI-4009

 

Data Aggregation Reference Architecture (DARA)

The Data Aggregation Reference Architecture (DARA) is in direct response to President’s National Strategy for Information Sharing and Safeguarding (NSISS) Priority Objective 10, “Develop a reference architecture to support a consistent approach to data discovery and entity resolution and data correlation across disparate datasets,” The DARA provides a reference architecture that can enable rapid information sharing, particularly for correlated data, but also for raw data, by providing a framework for interoperability between systems, applications and organizations.

See also MOISA. 

Program Manager, Information Sharing Environment

MODELING

Dependency Injection

See Injection, Dependency

Google:AngularJS

Modeling

Deployment Diagram

Teaser: A Deployment diagram shows how and where the system is to be deployed; that is, its execution architecture.

Detail: Hardware devices, processors and software execution environments (system Artifacts) are reflected as Nodes, and the internal construction can be depicted by embedding or nesting Nodes. Deployment relationships indicate the deployment of Artifacts, and Manifest relationships reveal the physical implementation of Components. As Artifacts are allocated to Nodes to model the system's deployment, the allocation is guided by the use of Deployment Specifications. See the image below, and click on it to review in the model:
https://empoweringgovernment.org/Digital_Engineering_and_Interoperability/EARoot/EA14/EA1/EA1/EA11711.png

Click on the image below to review a Service Catalog used to specify a data center model

https://empoweringgovernment.org/Digital_Engineering_and_Interoperability/EARoot/EA14/EA1/EA2/EA11716.png

UML

 

Design Pattern

Teaser:  A design pattern is a reusable solution to a commonly occurring problem within a given context in software design.

Detail: A design pattern is a general reusable solution to a commonly occurring problem within a given context in software design. A design pattern is not a finished design that can be transformed directly into source or machine code. It is a description or template for how to solve a problem that can be used in many different situations.

Fowler, et.al.

 

Device

A Physical Entity embedded inside, or attached to, another Physical Entity in its vicinity, with capabilities to convey digital information from or to that Physical Entity.

IIC

 

Device Endpoint

Endpoint that enables access to a device  and thus to the related Physical Entity.

IIC

 

Device Independence

See also Platform Independence

The process of making a software application be able to function on a wide variety of devices regardless of the local hardware on which the software is used.  Usually based upon the usage of Hardware Abstraction Layers that provide a common interface to hardware resources such as memory, CPU, the OS, and attached devices.  Often implemented as Virtual Machine architectures. The Common Object Request Broker Architecture (CORBA), the Java Virtual Machine (JVM) and the Windows Hardware Abstraction are common examples of device independence.

OMG, W3C, and the Java Development Community

 

Element

Unit that is indivisible at a given level of abstraction and has a clearly defined boundary

·         Note: An element can be any type of entity

ISO/IEC DIS 18834-1

 

Emergency Data Exchange Language Situation Reporting (EDXL-SitR)

This eXtensible Markup Language (XML)-based Emergency Data Exchange Language (EDXL) Situation Reporting specification, known as EDXL-SitRep, describes a set of standard reports and elements that can be used for data sharing among emergency information systems, and that provide incident information for situation awareness on which incident command can base decisions. The ongoing goal of the Emergency Data eXchange Language (EDXL) project is to facilitate emergency information sharing and data exchange across the local, state, tribal, national and non-governmental organizations of different professions that provide emergency response and management services. EDXL accomplishes this goal by focusing on the standardization of specific messages (messaging interfaces) to facilitate emergency communication and coordination particularly when more than one profession or governmental jurisdiction is involved. Find out more at http://docs.oasis-open.org/emergency/edxl-sitrep/v1.0/cs01/edxl-sitrep-v1.0-cs01.html.

OASIS

 

Emergent behavior

behavior of a system realized by the interactions of its components.

 

Modeling

Endpoint

One of two components that either implements and exposes an interface to other components or uses the interface of another component

Alternatively, an endpoint is the contact point through which clients can obtain access to a service provided by a server.

 

ISO/IEC 24791-1:2010

 

 

W3C Architecture//Service Points

Modeling

Endpoint address

data element designating the originating source or destination of data being transmitted

ISO 14814:2006

OASIS

Modeling

Entity

item inside or outside an information and communication technology system, such as a person, an organization, a device, a subsystem, or a group of such items that has recognizably distinct existence

ISO/IEC 24760-1:2011

 

Environment

Teaser1: Business, regulatory, technological, operational, organizational, political, economic, legal, ecological or social context in which an application is used, including all processes, products, information and actors involved in the application

 

Teaser2: Factors in the setting and circumstances that constrain the performance of Activity, including interactions and influences with the system of interest.

 

Detail: The enabling authorities for US IS&S efforts refer to a community of cooperating entities, taken together with the assets, systems, policies and practices that they employ for sharing and safeguarding, as an "environment" that facilitates those sharing,  safeguarding and security goals.  A number of agencies and cooperative programs (such as the federal PM-ISE and the New Jersey ISE) use this word to describe their collaborative and enabling IS&S programs and tools.   

Synonym: Context

ISO/IEC 27034-1:2011-11-15

 

 

 

 

 

 

ISO/IEC 42010:2011 as modified by
U of Washington.

 

 

 

 

IS&S-Security

Security

Environment, Security

The enabling authorities for US IS&S efforts refer to a community of cooperating entities, taken together with the assets, systems, policies and practices that they employ for sharing and safeguarding, as an "environment" that facilitates those sharing,  safeguarding and security goals.   A number of agencies and cooperative programs (such as the federal PM-ISE and the New Jersey ISE) use this word to describe their collaborative and enabling IS&S programs and tools. 

 

 

 

Extensible Access Control Markup Language (XACML)

Extensible Access Control Markup Language (XACML) defines a core schema and corresponding namespace for the expression of authorization policies in XML against objects that are themselves identified in XML. There are many proprietary or application-specific access control policy languages, but this means policies cannot be shared across different applications, and provides little incentive to develop good policy composition tools. Many of the existing languages do not support distributed policies, are not extensible, or are not expressive enough to meet new requirements. XACML enables the use of arbitrary attributes in policies, role-based access control, security labels, time/date-based policies, indexable policies, 'deny' policies, and dynamic policies — all without requiring changes to the applications that use XACML.

OASIS

 

eXtensible Markup Language (XML)

The eXtensible Markup Language (XML) is a simple, flexible text format derived from SGML (ISO 8879) that defines a set of rules for encoding documents in a format which is both human-readable and machine-readable.  Originally designed to meet the challenges of large-scale electronic publishing, XML is also playing an increasingly important role in the exchange of a wide variety of data on the Web and elsewhere.

W3C

Modeling

Extends Relationship

Teaser: directed relationship that specifies how and when the behavior defined in usually supplementary (optional) extending use case can be inserted into the behavior defined in the extended use case.

Detail: A relationship between two use cases in which one use case 'extends' the behavior of another. Typically this represents optional behavior in a use case scenario - for example a user may optionally request a list or report at some point in a performing a business use case.

UML extend relationship example - Registration use case is conditionally extended by Get Help On Registration.

See Use Case

UML, sysML

 

Federation

Teaser: Federation means using independently conceived information sets together for purposes beyond those for which the individual information sets were originally defined.

Includes Federated and Federate

Detail: This refers to arrangements where multiple independent entities cooperate on defined goals, conforming to shared rules, policies and interoperable methods.   For example, an existing statewide network of cooperating law enforcement agencies may work, as a group, with a similar network from another state, or with a statewide network composed of stakeholders in a relevant industry, such as a network of banks or retailers, on an area of common IS&S concern such as fraud prevention.   Important because large networks that support IS&S activity usually are formed by combining pre-existing groups of cooperating units into larger networks across boundaries.  Federations often serve as useful islands of reliable data and policy interoperability.  Common examples of federations include Trust Federations to share identity and authorization credential data, and Information Sharing Federations for threat data such as ISAOs, ISACs, and regional Information Sharing Environments.   

OMG

 

 

 

 

 

 

IS&S-Security

 

 

Firmware

Computer System] Low-level software for booting and operating an intelligent device.

Firmware generally resides in read-only memory (ROM) on the device

SNIA Dictionary

 

Functional component

functional building block needed to engage in an activity realized by an implementation.

ISO/IEC 17789:2014

 

Functional domain

top-level functional decomposition of an Industrial Internet System that provides a predominantly distinct functionality in the overall system

IIC

 

Functional framework

A set of abstract re-useable functional components that can be extended/customized and applied to several applications in a specific domain.

 

 

Functional Unit

Teaser: The element of a computer architecture that carries out the execute phase of a Fetch-Decode-Execute-Writeback sequence.

Detail:

Also see Unit of Work for the companion definition for commit scopes of Functional Units

Also see Work Package the companion definition as a project management specification

 

 

Gateway

a forwarding component, enabling various networks to be connected.

[IOT-A] ++

 

Geospatial Interoperability Reference Architecture (GIRA)

The Geospatial Interoperability Reference Architecture (GIRA) is aligned with current federal policy, principles, and practices for Enterprise Architecture and further adds to the authoritative body of knowledge of geospatial architecture documentation. It is an unclassified document aimed at an audience consisting of: executive leaders, program managers, and solution architects across federal, state, local, territorial, and tribal governments and private sector stakeholders. It is intended to be a practical roadmap to increase government geospatial information sharing through interoperable capabilities that result in reduced operational costs within and across mission systems. It documents geospatial and architecture policy alignment, references authoritative practices, and provides practical guidance including: templates, charters, exchange agreements, baseline requirements matrices, architecture artifacts, and tools.

Not to be confused with GRA.

Program Manager, Information Sharing Environment

 

Global Federated Identity and Privilege Management (GFIPM)

The Global Federated Identity and Privilege Management (GFIPM) framework provides the justice community and partner organizations with a standards-based approach for implementing federated identity.  The concept of globally understood metadata across federation systems is essential to GFIPM interoperability. Just as a common Extensible Markup Language (XML) data model was the key to data interoperability, a standard set of XML elements and attributes about a federation user's identities, privileges, and authentication can be universally communicated.

it.ojp.gov/GFIPM.

 

Global Reference Architecture (GRA)

The Global Reference Architecture (GRA) is a service-oriented reference architecture for justice and public safety information sharing.  It is designed to cut 80 percent of implementation time and costs for state and local justice agencies through reuse of established promising practices in IT architecture and design.

 

NOT to be confused with the GIRA – the Geospatial Interoperability Reference Architecture.

See also MOSA

https://it.ojp.gov/documents/GRAFAQ2012_compliant.pdf

 

Health Level Seven (HL7)

HL7 and its members provide a framework (and related standards) for the exchange, integration, sharing, and retrieval of electronic health information. These standards define how information is packaged and communicated from one party to another, setting the language, structure and data types required for seamless integration between systems. HL7 standards support clinical practice and the management, delivery, and evaluation of health services, and are recognized as the most commonly used in the world.

HL7 standards are grouped into reference categories:

·        Section 1: Primary Standards - Primary standards are considered the most popular standards integral for system integrations, inter-operability and compliance. Our most frequently used and in-demand standards are in this category.

·        Section 2: Foundational Standards - Foundational standards define the fundamental tools and building blocks used to build the standards, and the technology infrastructure that implementers of HL7 standards must manage.

·        Section 3: Clinical and Administrative Domains - Messaging and document standards for clinical specialties and groups are found in this section. These standards are usually implemented once primary standards for the organization are in place.

·        Section 4: EHR Profiles - These standards provide functional models and profiles that enable the constructs for management of electronic health records.

·        Section 5: Implementation Guides - This section is for implementation guides and/or support documents created to be used in conjunction with an existing standard. All documents in this section serve as supplemental material for a parent standard.

·        Section 6: Rules and References - Technical specifications, programming structures and guidelines for software and standards development.

·        Section 7: Education & Awareness - Find HL7's Draft Standards for Trial Use (DSTUs) and current projects here, as well as helpful resources and tools to further supplement understanding and adoption of HL7 standards.

HL7 encompasses the complete life cycle of a standards specification including the development, adoption, market recognition, utilization, and adherence.  (Also see Common Terminology Services)

HL7.org

 

Identification

process of recognizing an entity in a particular identity domain as distinct from other entities

ISO/IEC 24760-1:2011

 

Identifier

identity information that unambiguously distinguishes one entity from another one in a given identity domain

ISO/IEC 24760-1:2011

Security

Identity

Teaser: the characteristics determining who or what a person or thing is.

Detail: Data about a person or entity that may accurately be used to point to that unique subject.   A subject's asserted identity may be authenticated as correct by using data in the form of names, codes, biometric tokens, third-party assertions or other methods. 

OED

Security

Identity authentication

formalized process of identity verification that, if successful, results in an authenticated identity for an entity

ISO/IEC 24760-1:2011

Security

Identity domain

environment where an entity can use a set of attributes for identification and other purposes

ISO/IEC 24760-1:2011

Security

Identity information

set of values of attributes optionally with any associated metadata in an identity.

Note:: In an information and communication technology system an identity is present as identity information.

ISO/IEC 24760-1:2011

Security

Identity management

Processes and policies involved in managing the lifecycle and value, type and optional metadata of attributes in identities known in a particular identity domain

ISO/IEC 24760-1:2011

Security

Identity verification

process to determine that presented identity information associated with a particular entity is applicable for the entity to be recognized in a particular identity domain at some point in time

ISO/IEC 24760-1:2011

Modeling

Includes Relationship

A relationship between two use cases in which one use case 'includes' the behavior. This is indicated where there a specific business use cases which are used from many other places - for example updating a train record may be part of many larger business processes.

See Use Case

UML/sysML

 

Information Interoperability Framework (I2F)

The Information Interoperability Framework (I2F)  is a national architecture framework designed to support information sharing for the public safety and national security missions across all levels of government – federal, state, local, tribal, and territorial. Source:

Program Manager, Information Sharing Environment

 

Information Portability

Teaser: The loose coupling of a payload specification from its usage context.

Detail: Software portability refers to the ease by which software developed to execute properly within one computational environment can be transferred to execute properly within another, dissimilar, computational environment.  Portability is achieved by assuring that all the target computational environment facilities that support proper operation of the software are identical to or compatible with those of the original computational environment

ISO/IEC JTC1SC38

 

Information Resource

Teaser: An object where information is actually accessed by parties to perform activities.

Detail: Information can be accessed from a wide variety of information resource types, including digital, paper, equipment, human, or the observable environment.

See also Business Object

U of Washington

Security

Information Security Risk

Teaser: potential that a given threat will exploit vulnerabilities of an asset or group of assets and thereby cause harm to the organization

Detail: There are two contexts to the specification of Information Security Risks:

As perceived by the organization that has or will experience the risk (e.g., A security risk to a movie studio)

As perceived by the geopolitical entity and the implication on national security (e.g., the US Government, and most specifically, ODNI, sees the security risk to a movie studio in a larger and national context.

ISO/IEC 27005:2008

Security

Information Sharing

Teaser: The requirements for sharing data by an IT system with one or more other IT systems or applications, for information sharing to support multiple internal or external organizations, missions, or public programs.

Detail:  In the IS&S context, this means the exchange of threat information among cooperating organizations, usually on a voluntary basis, for the purpose of promoting more widespread defenses and resiliency.  Often conducted among participants in a Federation, or may be accomplished less formally by software, proxies, or point-to-point negotiated exchanges.   Generally uses common data standards;  should use appropriate safeguarding measures to assure adequate CyberSecurity and privacy.    Important as a key method for maintaining resiliency from attacks and vulnerabilities, as recognized in the 2007 and 2012 National Strategies, and the subject of mandates requiring federal public-private information sharing programs to be offered starting with the 2015 Cybersecurity Act.  See the US-CERT Automated Indicated Sharing (AIS) service.

NISTIR 7298 R2

 

Infrastructure Services (synonym: Core Services)

Teaser: Part of the Environment or Context in which Activity is performed.

Detail: Specific services that are essential for any implementation to work properly. Such services provide support for essential features.

 

Modeling

Injection, Dependency

Teaser: the act of inserting (injecting) the context characteristics and attributes between provider and consumer components dynamically during execution.

Detail: A programming approach to decoupling the configuration of a capability and its agreed-upon provision to a consumer, with the advantage that differently configured capabilities can be provided to other consumers without requiring breach or modification of the agreement with the first consumer. Contrast with, for example, a hard-wired code that simultaneously locks in both the configuration and consumption of a capability: any change by consumer or provider typically requires a corresponding change by the other party. With dependency injection, the dependency between provider and consumer is dynamically “injected” by a 3rd-party (e.g., a container framework) when needed.

Extended Discussion: Injection, one of the key characteristics for compose able and interoperable architectures, is a technique for assuring loose coupling by using a third party to resolve the relationship between a consumer component and a provider component.  This “third party” might be a service registry, as in a SOA environment, or an injectable metadata object requested by a consumer service, as in a DRUPAL installation.  A simple example is depicted below.

Dependency Injection and Inversion of Control are often used together.  In reality Dependency Injection is a pattern, and Inversion Control is a Container model that implements the Dependency Injection pattern.  What it all means is that it is a technique by which you externalize the choice of which implementation of a given interface is selected is externalized from a component and decided at runtime. (Fowler, 2004). Below is the Dependency Injection pattern:

http://martinfowler.com/articles/injection.html

Modeling

Injection, Metadata

Teaser:  The insertion of metadata into a component that implements one or more service factory methods. 

Detail: The resultant generated service is context specific based upon the injected metadata.  The injected metadata is often implemented with JSON because of its inherent object serialization.

OMG

 

Integrity

property of accuracy and completeness

ISO/IEC 27000:2014

 

Interface

Teaser: a shared boundary across which two separate components of a computer system exchange information.

Detail:  An interface is a kind of classifier that represents a declaration of a set of coherent public features and obligations. An interface specifies a contract; any instance of a classifier that realizes the interface must fulfill that contract. The obligations that may be associated with an interface are in the form of various kinds of constraints (such as pre- and post-conditions) or protocol specifications, which may impose ordering restrictions on interactions through the interface.

Since interfaces are declarations, they are not instantiable. Instead, an interface specification is implemented by an instance of an instantiable classifier, which means that the instantiable classifier presents a public facade that conforms to the interface specification. Note that a given classifier may implement more than one interface and that an interface may be implemented by a number of different classifiers.

OMG UML specification

 

Internet

A global computer network providing a variety of information and communication facilities, consisting of interconnected networks using standardized communication protocols.

OED

 

Interoperability

Teaser:  Interoperability is a feature and capability of software and hardware components  that allows them to collaborate to solve problems.

Harmonized Definition: Interoperability is more than just information exchange.  Interoperability is the ability for diverse systems and system components to understand each other’s application and service interfaces, configuration, forms of Authentication and Authorization, data formats, etc. in order to cooperate and Reciprocal Operation as Services in Consumer/ Provider relationships with each other.  The result is diverse Systems and System Components communicate, execute, and transfer data among various Functional Units in a manner that requires the user or assembler to have little or no knowledge of the unique characteristics of those units. Interoperability includes systems, processes, procedures, organizations, and missions over the life cycle and must be balanced with cybersecurity.  To overcome conversion tasks, import/export obstacles, and distributed resource access barriers imposed by heterogeneous processing environments and heterogeneous data, Interoperability includes both the technical exchange of information and the end-to-end operational effectiveness of that exchange of information as required for mission accomplishment. MEASURE OF EFFECTIVENESS (MOE) for Interoperability includes the ability for systems or system components to provide information Portability, both inter-application and inter-service; cooperative process control; autonomous development of services; composability; and Metadata Injection for context awareness ; and, overall, a measureable improvement in mission accomplishment.

Discussion: There is no single way of enabling interoperability, nor is there a single outcome that can be declared as “this” is interoperability.  Rather, kinds-of interoperability exists.  Each kind-of interoperability has specific sets of outcomes that can be achieved for a specific set of software and hardware features that have been included.  Each kind-of interoperability is driven by specific business needs as well as an evolution in what is technically possible. Click on model snippet below to explore how different interoperability frameworks are based upon a common foundation but define and specify different levels.

 

 

 

 

 

Interoperability Level

Teaser: A capability based specification of interoperability that defines and characterizes what components at a specific interoperability level can do. 

Detail: There is no single way of enabling interoperability, nor is there a single outcome that can be declared as “this” is interoperability.  Rather, kinds-of interoperability, expressed as levels in particular interoperability frameworks, exists. 

Interoperability is a continuum of capability as specified by the Interoperability Continuum.  For example, a Level 1-Specified interoperable component would utilize NIEM payloads to enable point-to-point/program-to-program communication whereas Level 5-Dynamic and Discoverable interoperability still utilizes NIEM payloads but adds conjunction composition characteristics to enable dynamic compositions of autonomously developed/deployed services.

Regardless of the framework, each kind-of interoperability has specific sets of outcomes that can be achieved for specific sets of software and hardware features that have been included.  Each kind-of interoperability is driven by specific business needs as well as an evolution in what is technically possible.  The Model snippet, below, describes the foundation of how interoperability is specified.  Click on the image to view more details in the online model.

 

 

 

Interoperability Maturity

See Interoperability Level

 

 

Inversion of Control (IoC)

Teaser: Using metadata to decouple the implementation of a service from how it is known.

Detail: In the context of using a framework, the framework dictates the architecture of the application. It predefines design parameters so that the programmer can focus on the specifics of the application. This form of “design reuse” leads to a swapping (inversion) of control between the application and the software on which it’s based. When a toolkit or conventional subroutine library is used, the programmer writes the application main body, which calls the code it wishes to reuse. By contrast, when using a framework, the main body is reused and the programmer writes the code that it calls (GoF Design Patterns, Addison-Wesley, 1994, pp.26-27).

Detail: Inversion of Control, the implementation of Dependency Injection pattern, is best understood by explanation of what it is not.  In procedural and transactional systems a central piece of code, the controller node, manages the execution of all the modules.  Further, in procedural design apriori knowledge that component “A” will invoke component “B” places the control of the invocation and management of “B” in “A’s” hands.  IoC inverts this in many ways.

1.    There is a decoupling of how a service is implemented from how it is known – that is, its interface – in a service oriented architecture.  This decoupling is based upon the specification of metadata compliant instances in a service registry.

2.    Factories are used as intermediaries that decide how to “manufacture” a specific class.  So continuing on the Figure 1-2 example, the ServiceConsumer might actually include a command something like this:
factory(OrbitalMechaics,myDataObject)
the factory would manufacture the plugin, invoke the logic to decide whether to instantiate the orbital mechanics calculator inside of ServiceConsumer, or invoke via a call to the service registry resulting in the selection of theMotherofCalculators

IoC is key to loose coupling and is centrally important to interoperable and compostable solutions and mandatory for effective metadata driven architecture-based systems.

OMG, Fowler

 

IP endpoint

An endpoint which has an IP address, a hostname, transport, and port number

W3C

 

JavaScript Object Notation (JSON)

JSON (JavaScript Object Notation) is a lightweight data-interchange format. It is easy for humans to read and write. It is easy for machines to parse and generate. It is based on a subset of the JavaScript Programming Language Standard ECMA-262 3rd Edition - December 1999. JSON is a text format that is completely language independent but uses conventions that are familiar to programmers of the C-family of languages, including C, C++, C#, Java, JavaScript, Perl, Python, and many others. These properties make JSON an ideal data-interchange language. JSON is built on two structures: a collection of name/value pairs. In various languages, this is realized as an object, record, struct, dictionary, hash table, keyed list, or associative array; and an ordered list of values. In most languages, this is realized as an array, vector, list, or sequence. These are universal data structures. Virtually all modern programming languages support them in one form or another. It makes sense that a data format that is interchangeable with programming languages also be based on these structures. Find out more at

Json.org

 

Late Binding

Teaser: The resolution of a service request as late as possible during execution.

DetailLate binding, or dynamic binding, is a computer programming mechanism in which the method being called upon an object is looked up by name at runtime. With early binding, or static binding, the compilation phase fixes all types of variables and expressions.

Late Binding results in—

  Selecting a service by specifying a service interface that satisfies the consumer need as late as possible during execution and then,

  Resolving the interface to a specific component and the component API that best satisfies the service interface signature also as late as possible. 

Each binding should be considered a configuration that can change dynamically as needed without loss of correctness and be consistently applied regardless of the enabling environment.

ACM

Security

Least Privilege

The principle that a security architecture should be designed so that each entity is granted the minimum system resources and authorizations that the entity needs to perform its function.

NISTIR 7298 R2

 

Lexicon

A lexicon is a language’s super-dictionary that includes both words and sub-words.

 

 

Logical Entity Exchange Specifications (LEXS)

Logical Entity Exchange Specifications (LEXS) is a comprehensive, National Information Exchange Model (NIEM)-based, framework for the development of information exchanges. Initially developed for the law enforcement information sharing program at US Department of Justice, LEXS is now being widely used in criminal justice community at large, as well as by the homeland security, intelligence, and other communities. Learn how you can use LEXS and see how others use it. All LEXS artifacts and documents can be downloaded from http://lexsdev.org/.

NIEM

 

Measure of Effectiveness (MOE)

Teaser: A metric by which a customer will measure satisfaction with products produced by the technical effort.

Detail: In uml.standardscoordination.org, go to Technical SpecificationàUML Profiles and Standards LibrariesàViewpointsàPerformance and TPMSàEffectiveness to review.  It is important to note that the criterion of the measure should be stated in a manner that is independent of the means to achieve it.  This affects the specification of how the Measure of Performance (see below) is both attributed and described.

DoD, OMG

 

Measure of Performance (MOP)

Teaser: A performance measure that provides design requirements that are necessary to satisfy an MOE. There are generally several measures of performance for each measure of effectiveness.

Detail: Click on the image below to review the elements of an MOP as a UML specification.

KPPPERFORMANCE

DoD, OMG

 

Message (Payload)

Teaser: the entire payload of information sent between service consumer and service (or vice versa), even if there is a logical partitioning of the message into segments or sections.

Detail: For instance, if an interface expresses actions as operations or functions that take arguments, and a particular operation has two arguments, both arguments would be considered part of the same message, even though they may be logically separated within the message structure. A message also includes the concept of an attachment, in which there are several additional sections (attachments) that relate to a distinct, primary section.  Click on the image below to review the elements of a Message(Payload) as a UML specification.  Note the dependency on Segmentation and specification of Entities.

 

IIC

Modeling

Model Checking (or Model Validation)

Teaser: Usage of a modeling tool to check the integrity of a model using specified rules for syntax and semantics of a Model.  Sometimes referred to as Model Validation.

Detail: Model Checking, in a formal sense “is a method for formally verifying finite-state concurrent systems. Specifications about the system are expressed as temporal logic formulas, and efficient symbolic algorithms are used to traverse the model defined by the system and check if the specification holds or not.” 

In a UML/sysML/ BPMN sense it is really more a process of validating, via a pre-specified set of tool or use-specified rules, the syntax and semantics of a model.  For example, all requirements must connect to either Use Cases, Classes, or Activities.  And these model elements must connect, ultimately, to some form of deployment package.  If a requirement does not connect then this is a warning that the model may not be valid.  All modeling tools, even free ones such as Eclipse Papyrus or Modelio, perform some form of Model Validation.  And some commercial tools have extensive toolkits that permit the establishment of complex validation rules.

OMG

Modeling

Model, Component

The component model provides a detailed view of the various hardware and software components that make up the proposed system. It shows both where these components reside and how they inter-relate with other components. Component requirements detail what responsibilities a component has to supply functionality or behavior within the system.

Also See definition of Component. 

 

Modeling

Model, Deployment

A model of the system as it will be physically deployed

UML, sysML

Modeling

Modeling and Simulation (M&S)

Teaser: using the built-in capabilities of a modeling tool to simulate the execution of the model

Detail:

M&S involves two activities:  Model Animation

Model Animation involves adding various models such as state diagrams, timing charts, and event models.  Once this is done the model can be animated in the modeling tool.  This results in moving from class to class as specified by the model.  Results are checked.  For example, if “Class B” is intended to be invoked by “Class A” but B is never executed this results in an error that must be fixed in the model.  If everything executes as expected then Model Simulation, or even code generation, may occur.

Historically, simulations occur in another tool such as SPIN.  By building Model Simulation into the modeling tools simulation builds upon and extends Model Animation by adding various kinds of event models that mimic real world conditions, such as expected user loads, when these loads occur in a day, and worst-case scenarios.  Minimal rework is required and no Simulation tool specific model of the system needs to be created.

F-UML is an executable for of a UML model and builds upon model animation by generating an executable directly from the model as opposed to code which then is modified/added-too before the executable is generated.

OMG:MOF

Modeling

Model, Element

An element that is an abstraction of a structural or behavioral feature of the system being modeled. All model elements have properties, such as a name. Other features, such as attributes and operations that belong to a class, can further define some UML model elements.  In the MOF specification model elements are considered to be meta-objects. 

OMG::MOF

 

Modular Open Systems Architecture (MOSA)

A US Department of Defense Acquisition strategy and framework to satisfy “A modular, open-systems approach shall be employed, where feasible.” (DoDD 5000.1.  Defined, MOSA is an integrated business and technical strategy that:

·         provides an enabling environment

·         employs a modular design and, where appropriate,

·         defines key interfaces,

·         using widely supported, consensus-based (i.e., open) standards that are published and maintained by a recognized industry standards organization

·         and uses certified conformant products.

Also see GRA

http://www.acq.osd.mil/se/briefs/16943-2014_10_29_NDIA-SEC-Welby-MOSA-vF.pdf

 

 

National Information Exchange Model (NIEM)

Teaser: The National Information Exchange Model (NIEM) is a community-driven, standards-based approach to exchanging information using commonly accepted data packets.

Detail:  NIEM connects communities of people who share a common need to exchange information in order to advance their mission. Information exchange is about connecting data from one computer to another, and another, and so on. The idea behind NIEM is to let systems speak to one another, even if they've never spoken before. NIEM ensures that information is well-understood and carries the same consistent meaning across various communities, allowing interoperability to occur. With NIEM, you only need to know two languages—your own and NIEM. NIEM is driven by the community, for the community. Source: http://www.niem.gov.  See also NIEM-UML

NIEM.gov

Security

Need to Know

Teaser: A dynamic criterion for providing access to sensitive data or information limited to parties specifically declared as “needing to know.”

Detail: Need To Know for a specific party can be determined by such attributes as the party’s privilege, organizational role, operation goal, and current activity. These factors can be analyzed in a dynamic manner to identify information that is relevant to the party’s responsibilities in a dynamic manner, but possibly unknown to the party.

 

 

NIEM

See NATIONAL INFORMATION EXCHANGE MODEL (NIEM)

 

 

NIEM-UML

Teaser: A UML Profile implemented in Modeling tools that permits the specification of NIEM models.

Detail: NIEM UML is a UML profile for modeling NIEM at a logical and XML specific level.  NIEM-UML is available in many standard modeling tools. See http://www.omg.org/spec/NIEM-UML/1.0/PDF/ for the specification.

Click on the below to review a model of NIEM.

 

OMG

 

Network

a system of interconnected endpoints

W3C, others

 

Non-functional requirement

requirement that defines the overall qualities or attributes of the resulting system.

NOTE: Non-functional requirements place restrictions on the system being developed, the development process, and specifies external constraints that the system must meet.

OMG

 

Observer

A software design pattern in which an object, called the subject, maintains a list of its dependents, called observers, and notifies them automatically of any state changes, usually by calling one of their methods. It is mainly used to implement distributed event handling systems.  The Observer is a foundation to Inversion of Control (IoC)

Gang-of-Four Patterns, Fowler Patterns, etc.

 

Ontology

Ontologies define a common vocabulary for sharing information in a domain. They provide a standardized, machine-interpretable definition of basic concepts within the domain, and of relations among them. Formally defined ontologies give stakeholders the ability to:

·           Share common understanding of the structure of information among themselves or among software agents

·           Reuse domain knowledge

·           Explicitly codify domain assumptions

·           Separate domain knowledge from operational knowledge

·           Analyze domain knowledge effectively

OMG (Ontology Definition MetaModel)

 

Operation, Mission

The orchestrated performance of activities with assigned resources to achieve a specified goal under current context constraints.

U of Washington

 

Operation, UML

Teaser: An operation is a method or function that can be performed by an instance of a class.

Detail: Operation is a behavioral feature that may be owned by an interface, data type, or class. Operations may also be templated and used as template parameters. An operation may be directly invoked on instances of its featuring classifiers. The operation specifies the name, type, parameters, and constraints for such invocations.

UML

 

Orchestration

Teaser: Directed Collaboration

Detail: Type of composition where one particular element is used by the composition to oversee and direct the other elements

Note: the element that directs an orchestration is not part of the orchestration.

ISO/IEC DIS 18834-1

 

Party

an entity, human or logical (e.g. an administrator, a legal entity, an agent) that has some autonomy, interest and responsibility in the execution of activities

Note: A party may assume more than one roles, and a role may be fulfilled by several parties (i.e. by any one of them).

IIC

Security

Personally Identifiable Information – (PII)

Any information—

·   that identifies or can be used to identify, contact, or locate the person to whom such information pertains,

·   from which identification or contact information of an individual person can be derived, or

·   that is or might be directly or indirectly linked to a natural person

ISO/IEC 24745:2011

 

Physical Entity

An Entity that is the subject of monitoring and control actions.

[IOT-A] ++

 

Pipeline

A specified and outcome-driven project of Project Interoperability Initiative

 

 

Policy

Teaser: a course or principle of action adopted or proposed by an organization or individual

Detail: In the IS&S context, this means the exchange of threat information among cooperating organizations, usually on a voluntary basis, for the purpose of promoting more widespread defenses and resiliency.  Often conducted among participants in a federation, or may be accomplished less formally by software, proxies, or point-to-point negotiated exchanges.   Generally uses common data standards;  should use appropriate safeguarding measures to assure adequate cybersecurity and privacy.    Important as a key method for maintaining resiliency from attacks and vulnerabilities, as recognized in the 2007 and 2012 National Strategies, and the subject of mandates requiring federal public-private information sharing programs to be offered starting with the 2015 Cybersecurity Act.  See the US-CERT Automated Indicated Sharing (AIS) service.

OED

 

Portability

Teaser:  Portability is the capability of taking processes developed on one hardware and software platform and move them to another with minimal disruption. 

Detail: Software portability refers to the ease by which software developed to execute properly within one computational environment can be transferred to execute properly within another, dissimilar, computational environment.  Portability is achieved by assuring that all the target computational environment facilities that support proper operation of the software are identical to or compatible with those of the original computational environmentPortability is usually implemented with some form of a FAÇADE pattern, depicted below, by encapsulating a systems classes providing thereby providing context independence and portability.

The Facade is an integral part of the Interface specification and is represented in the Interfaces model as the ServiceInterfaceFacade.

US Army LCMM Volume 3

Security

Privacy

Right of individuals to control or influence what information related to them may be collected and stored and by whom and to whom that information may be disclosed

ISO  TS 17574:2009

Security

Privacy Risk Assessment

Overall process of risk identification, risk analysis and risk evaluation with regard to the processing of personally identifiable information (PII)

NOTE:  This process is also known as a privacy impact assessment

ISO/IEC 29100:2011

Security

Privilege

capacity assigned to an entity by an authority 

ISO 27789:2013

 

Profile

A representation -- an outline, sketch, analysis, or graph -- of an object -- person, thing, data or concept.  A profile generally is not a formal mathematical model (see).  In context of Project Interoperability there are two specializations—

a)    Common Profile that outlines how to use standards together to achieve interoperability;

b)    UML Profile that represents the tailoring of a language (UML) to represent a specific domain.

Based on Merriam Webster Unabridged online, http://unabridged.merriam-webster.com/unabridged/Profile

 

Reciprocal Operation

A component is said to operate reciprocally when it can act as both a service provider and as a service consumer.

 

 

Reference Implementation

Teaser: a reference implementation is the standard from which all other implementations and corresponding customizations are derived.

Detail:  A Reference Implementation is a collection of stories and scenarios organized around a particular requested outcome.  The Reference implementation is then used to qualify and test specific production implementations that might result by utilizing the Reference Implementation test cases as the basis for checking the expected results against the received results.

Characteristics of a Reference Implementation:

1.   Developed concurrently with the specification and test suite;

2.   Verifies that specification is implementable;

3.   Enables the test suite to be tested;

4.   Serves as a Gold Standard against which other implementations can be measured;

5.   Helps to clarify the intent of the specification in situations where conformance tests are inadequate

 

 

Representational State Transfer (REST)

Representational State Transfer (REST) architectural style was developed as an abstract model of the Web architecture to guide our redesign and definition of the Hypertext Transfer Protocol and Uniform Resour0ce Identifiers by Roy T. Fielding and Richard N. Taylor, Information and Computer Science, University of California, Irvine. In their paper entitled Principled Design of the Modern Web Architecture , they describe the software engineering principles guiding REST and the interaction constraints chosen to retain those principles, contrasting them to the constraints of other architectural styles

 

 

Resilience

The ability to continue to: (i) operate under adverse conditions or stress, even if in a degraded or debilitated state, while maintaining essential operational capabilities; and (ii) recover to an effective operational posture in a time frame consistent with mission needs.

NISTIR 7298 R2

Security

RBAC (Role-based Access Control)

See RBAC-ABAC

NIST

Security

RBAC-ABAC

TEASERS:

Role-based-access-control (RBAC) is a policy neutral access control mechanism defined around roles and privileges. The components of RBAC such as role-permissions, user-role, and role-role relationships make it simple to perform user assignments.

Attribute-Based Access Control (ABAC) is a logical access control methodology where authorization to perform a set of operations is determined by evaluating attributes associated with the subject, object, requested operations, and, in some cases, environment conditions against policy, rules, or relationships that describe the allowable operations for a given set of attributes.

RBAC-ABAC associates roles with system element permissions thereby combining RBACV and ABAC.

DISCUSSION:  Popularized by systems such as DRUPAL and WordPress, the combining of RBAC with ABAC provides a high degree of access/usage permission granularity.  For example, Person “A” could be assigned the Administrator role and have full Create-Retrieve-Update-Delete (CRUD) services for all the attributes of a particular component – say the Personnel service.  Another person, Person “B”, might also be assigned the administrator role but only have 2 or 3 of the personnel services that they have CRUD services.  This is the essence of RBAC with ABAC: finer grained control over who does what.

NIST

Security

Risk

effect of uncertainty on objectives

Note 1 to entry: An effect is a deviation from the expected — positive or negative.

Note 2 to entry: Uncertainty is the state, even partial, of deficiency of information related to, understanding or knowledge of, an event, its consequence  or likelihood.

Note 3 to entry: Risk is often characterized by reference to potential events and consequences, or a combination of these.

Note 4 to entry: Risk is often expressed in terms of a combination of the consequences of an event (including changes in circumstances) and the associated likelihood of occurrence.

Note 5 to entry: In the context of information security management systems, information security risks can be expressed as effect of uncertainty on information security objectives.

Note 6 to entry: Information security risk is associated with the potential that threats will exploit vulnerabilities of an information asset or group of information assets and thereby cause harm to an organization. (see definition of information security risk)

ISO/IEC 27000:2014

Security

Risk Analysis

process to comprehend the nature of risk (2.68) and to determine the level of risk (2.44)

Note 1 to entry: Risk analysis provides the basis for risk evaluation (2.74) and decisions about risk treatment (2.79).

Note 2 to entry: Risk analysis includes risk estimation

ISO/IEC 27000:2014

Security

Risk Assessment

Overall process of risk identification, risk analysis, and risk evaluation

See also Privacy Risk Assessment.

ISO/IEC 27000:2014

 

Security

Risk Evaluation

process (2.61) of comparing the results of risk analysis (2.70) with risk criteria (2.73) to determine whether the risk (2.68) and/or its magnitude is acceptable or tolerable

Note 1 to entry: Risk evaluation assists in the decision about risk treatment (2.79).

ISO/IEC 27000:2014

Security

Risk Identification

process of finding, recognizing and describing risks (2.68)

[SOURCE: ISO Guide 73:2009]

Note 1 to entry: Risk identification involves the identification of risk sources, events, their causes and their potential consequences.

Note 2 to entry: Risk identification can involve historical data, theoretical analysis, informed and expert opinions, and stakeholders’ needs

ISO/IEC 27000:2014

Security

Risk Management

coordinated activities to direct and control an organization (2.57) with regard to risk (2.68)

ISO/IEC 27000:2014

Security

Risk Response

Accepting, avoiding, mitigating, sharing, or transferring risk to organizational operations (i.e., mission, functions, image, or reputation), organizational assets, individuals, other organizations, or the Nation.

NISTIR 7298 R2

Security

Risk Tolerance

The level of risk an entity is willing to assume in order to achieve a potential desired result.

NISTIR 7298 R2

 

Robustness

The ability of an Information Assurance entity to operate correctly and reliably across a wide range of operational conditions, and to fail gracefully outside of that operational range.

NISTIR 7298 R2

 

Role

A particular and attributed context that an actor – human or non-human – plays in interacting with a system.  Example usages include the role relationship between UML classes and Role-Based Access Control (RBAC)

UML

Security

Security Assertion Markup Language (SAML)

SAML is an XML-based framework for communicating user authentication, entitlement, and attribute information. SAML allows business entities to make assertions regarding the identity, attributes, and entitlements of a subject (an entity that is often a human user) to other entities, such as a partner company or another enterprise application.

OASIS

Security

Security

property of a system by which confidentiality, integrity, availability, accountability, authenticity, and reliability are achieved

ISO TR 15443-1:2012

Security

Security Control

measure that is modifying risk (2.68)

Note 1 to entry: Controls include any process, policy, device, practice, or other actions which modify risk.

Note 2 to entry: Controls may not always exert the intended or assumed modifying effect.

ISO/IEC 27000:2014

Security

Security Functions

cryptographic algorithms together with modes of operation, such as block ciphers, stream ciphers, symmetric or asymmetric key algorithms, message authentication codes, hash functions, or other security functions, random bit generators, entity authentication and SSP generation and establishment all approved either by ISO/IEC or an approval authority

ISO/IEC 19790:2012

Security

Security Policy

Rules, directives and practices that govern how assets, including sensitive information, are managed, protected and distributed within an organization and its systems, particularly those which impact the systems and associated elements

NISTIR 7298 R2

 

Sensitivity

Teaser: A measure of the importance assigned to information by its owner, for the purpose of denoting its need for protection.

Summary:  There are two contexts in which sensitivity is applicable:  (1) as a risk to be measured and accommodated; and (2) as a threat that has a signature and outcome.

NISTIR 7298 R2

 

Sensor

A sensor is a special Device that perceives certain characteristics of the real world and transfers them into a digital representation.

[IOT-A]

 

Service

Teaser: A distinct part of the functionality that is provided by an entity through interfaces

Detail:  A Service is a ‘unit of work’ performed by a ‘Service Provider’ to achieve desired capability for a ‘Service Requestor’ under a ‘Contract’ optionally facilitated by a ‘Service Broker

·  Services could be aggregated to perform an end-to-end Business function or a stand-alone fine grained function

·  A Web Service is a ‘Type of Service’ (not all Services are Web Services)

·  Services can be aggregated to a Composite Service

In the SOA sense, a service is a collection of ports, logic, and methods that is injectable.

ISO/TR 14252:1996

 

OMG SOA Modeling Language

 

Service Broker

Teaser: A specific kind of service provider that can pass on service requests to one or more additional service providers.

Detail: A service broker is any capability that receives messages from a consumer and subsequently, as a service consumer itself, interacts with another service. The term intermediary indicates that these capabilities sit between other services and mediate the interaction by managing, controlling, brokering, or facilitating the transmission of messages between them.  There are two typical implementations of Service Brokers:

SOA:  a registry of services that stores information about what services are available and who may use them. For example, UDDI which was originally conceived as a web service registry is now considered a SOA Service Broker.

CORBA:  The implementation of ab an Object Request Broker (ORB) that acts as a "broker" between a client request for a service from a distributed object or component and the completion of that request.

OMG

 

Service Contract

Teaser: Service contracts provide a way of specifying service requirements without constraining the architecture for how those requirements might be realized.

Detail:  Service contracts can be used to sketch key services consumers and providers and their interactions in order to accomplish some stated objective – without having to address unnecessary architectural decisions. A solution architecture consisting of specific service consumers and providers can then be designed after more is known about the requirements that must be met. Service contracts can also realize many use cases providing another flexible means of linking contracts to requirements they fulfill while providing a more formal expression of requirements than is possible with use cases.

The SOAM Modeling Language,soaML, has a complete specification of SOA and SOA Contracts.  The soaML has been added to the SCC model.  Click the image below to review the specifics of the specification of SOAs, in general, and Service Contracts, in particular.

OMG:soaML

 

Service Oriented Architecture

Alternative Definition 1 from OMG:
Service Oriented Architecture (SOA) is an architectural paradigm for defining how people, organizations, and systems provide and use services to achieve results. Specifically, it is a way of describing and understanding organizations, communities, and systems to maximize agility, scale, and interoperability. People, organizations, and systems provide services to each other. These services allow us to get something done without doing it ourselves or even without knowing how to do it; enabling us to be more efficient and agile. Services also enable us to offer our capabilities to others in exchange for some value; thus establishing a community, process, or marketplace. The SOA paradigm works equally well for integrating existing capabilities as well as creating and integrating new capabilities.
(soaML specification:
http://www.omg.org/spec/SoaML/ )

Alternative Definition 2 from OASIS:
A paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. It provides a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with measurable preconditions and expectations.

OMG: soaML

 

 

 

 

 

 

 

 

 

 

 

 

 

 

OASIS

 

Segment / Delivery Segment

A specific deliverable section of the Statement of work.  There are four Segments:  Project Management, Technology and Standards Architecture, Interoperability Testing and Conformance, and Performance Management.

 

 

Simple Object Access Protocol (SOAP)

Simple Object Access Protocol (SOAP) is a lightweight protocol for exchange of information in a decentralized, distributed environment. It is an XML based protocol that consists of three parts: an envelope that defines a framework for describing what is in a message and how to process it, a set of encoding rules for expressing instances of application-defined datatypes, and a convention for representing remote procedure calls and responses. SOAP can potentially be used in combination with a variety of other protocols; however, the only bindings defined in this document describe how to use SOAP in combination with HTTP and HTTP Extension Framework.

W3C

Security

Situational Awareness

Within a volume of time and space, the perception of an enterprise’s security posture and its threat environment; the comprehension/meaning of both taken together (risk); and the projection of their status into the near future.  See also Need to Know.

NISTIR 7298 R2

 

Standards Development Organization (SDO)

A domestic or international organization that plans, develops, establishes, or coordinates voluntary consensus standards using procedures that incorporate the attributes of openness, balance of interests, due process, an appeals process, and consensus in a manner consistent with the Office of Management and Budget Circular Number A-119, as revised February 10, 1998.

OMB Circular 119, Feb 1998

 

Stakeholder

individual, team, organization, or classes thereof, having an interest in the system of interest

ISO/IEC 42010:2011 ++

Modeling

Step

Teaser: An abstraction of an action, used in a Process, that may leave unspecified objects that participate in that action.

ISO/IEC 15414

 

Story

Teaser: A device used to elicit requirements, process characteristics, and actors. 

Detail: Operational Scenarios/Stories are often depicted using BPMN-based models and are used as the basis to qualify what success looks like to the user.  Initially popularized in Agile Architecture methods.  Also see Modeling tool’s help for Story or User Story. Click on the diagram, below, to look at the particular model details for a Stories.

Synonym: User Story.

www.agilemodeling.com

 

System Modeling Language (sysML)

Companion to UML and BPMN, the Systems Modeling Language (SysML) is general purpose visual modeling language for systems engineering applications. SysML is defined as a dialect of the Unified Modeling Language (UML) standard, and supports the specification, analysis, design, verification and validation of a broad range of systems and systems-of-systems. These systems may include hardware, software, information, processes, personnel, and facilities.

OMG

 

System

An integrated set of regularly interacting or interdependent components created to accomplish a defined objective, with defined and maintained relationships among its components, and the whole producing or operating better than the simple sum of its components.  Systems may be either physical process based or management process based, or more commonly a combination of both.

PMBOK

 

System Component

The configuration control items used to form a mission focused set of functionality. 

Also see Component

 

 

Taxonomy

A taxonomy represents a classification of the standardized terminology for all terms used within a knowledge domain. In a taxonomy, all elements are grouped and categorized in a strict hierarchical way, and are usually represented by a tree structure. In a taxonomy, the individual elements are required to reside in the same semantic scope, so all elements are semantically related with one another to one degree or another.

European Interoperability Framework

 

Task

Teaser:  A unit of work specified as a single action that occurs in a business process

Detail:  There are two contexts in which a Task is specified in UML models:

1.  In the decomposition and specification of Use Cases resulting is tasks, or steps, of the Use Case.  Tasks are typically grouped into scenarios of the Use Case:  Primary Success Scenario has a set of tasks as do alternative success scenarios, recoverable failure scenarios, and unrecoverable failure scenarios.

2.  As a decomposition of a BPMN Model into leaf node activity representing a single action in a business process by a single actor with a well specified and not decomposable outcome.

UML

 

Testable (Testbed)

The presence of a test and conformance platform as the basis for controlled experimentation and conformance checking to a reference architecture and its use cases.

 

 

Test and Conformance Platform

The build out of a Test Harness for a specific testing context.  The testing context consisting of test cases, triggering events, and usually, a testing plan that guides the degree of testing required and the expectations. 

 

IIC

 

Test Case

A part of a Test Harness that specifies the specific event(s) that trigger a testing scenario, the data context of the scenario, and the expected results

OMG

 

Test Harness

A test harness or automated test framework is a collection of software and test data configured to test a program unit by running it under varying conditions and monitoring its behavior and outputs. It has two main parts: the test execution engine and the test script repository. See Conformance Specification and see Test and Conformance Platform.

The specification

 

IIC

 

Thread, Functional

Not to be confused with an execution thread, such as a JAVA Thread, but rather the specification of a specific success, alternative success, or failure scenario implemented in a testbed.  As such, a thread is a finer grained specification of a story.  As such, it is a synonym for an Interoperability Exercise.

 

 

Thing

An object or entity that is not or cannot be named specifically or characterized as having a specific role.

 

Security

Threat

potential cause of an unwanted incident, which may result in harm to a system or organization

ISO/IEC 27000:2014

Security

Threat analysis

The examination of threat sources against system vulnerabilities to determine the threats for a particular system in a particular operational environment.

NISTIR 7298 R2

Security

Threat Event

An event or situation that has the potential for causing undesirable consequences or impact. 

NISTIR 7298 R2

Security

Trust

relationship between two entities and/or elements, consisting of a set of activities and a security policy in which element x trusts element y if and only if x has confidence that y will behave in a well-defined way (with respect to the activities) that does not violate the given security policy

ISO/IEC 27036-1:2014

Security

Trustmark

A trustmark is a statement of conformance to a well-scoped set of identity trust and/or interoperability requirements. (Source: GTRI NSTIC Trustmark Pilot, sponsored by the National Institute of Standards and Technology.

 

Click on the model snippet below to review the complete trustmark model

https://trustmark.gtri.gatech.edu/technical-framework/)

Modeling

Unified Modeling Language (UML)

Companion to sysML and BPMN, the Unified Modeling Language (UML) is a graphical language for specifying, visualizing, constructing, and documenting the artifacts of software and hardware systems, as well as for business modeling and other non-software systems. The UML represents a collection of the best engineering practices that have proven successful in the modeling of large and complex systems

OMG

Modeling

UML Profile

Teaser:  A UML Profile is an extension (or restriction) of the Unified Modeling Language (UML) to accommodate particular descriptive requirements. 

Detail:  Examples include the SOA Modeling Language (soaML), a UML Profile for describing SOA based architectures, or the Unified Profile for DoDAF and MoDAF, a profile for describing DoDAF/MoDAF architectures.  OMG SysML both extends and restricts the UML.  “SysML” may be conceived of as UML minus parts of UML not required plus SysML extensions.

OMG UML 2.5, Section 12.3, http://www.omg.org/spec/UML/

OMG SysML, 1.4, Section 4. http://www.omg.org/spec/SysML/

 

Unit of Work

Teaser:  The commit scope of a Functional Unit

Summary:  There are two viewpoints for Unit of work:

·         Transactional, and

·         User

Both are specified, below

See also Unit of Work, Transactional and Unit of Work, User

 

Unit of Work, Transactional

A transaction scope often associated with the setting of database commit and roleback criteria.  Most often, but not always, the transactional UoW is set to be consistent with a specific user-specified UoW.

Also see here for the Unit of Work Design Pattern

 

 

Unit of Work, User

A user-recognized and value producing activity often associated-with and specified-by a specific Business Process Model (BPMN) Activity.

 

 

Usage capacity

the ability to initiate, to participate in the execution of, or to consume the outcome of some tasks or functions.

IIC

 

Use Case

Teaser: A Use Case represents a discrete unit of interaction between a user (human or machine) and the system.

Detail: A Use Case is a single unit of meaningful work; for example creating a train, modifying a train and creating orders are all Use Cases. Each Use Case has a description which describes the functionality that will be built in the proposed system. A Use Case may 'include' another Use Case's functionality or 'extend' another Use Case with its own behavior.

Use Cases are typically related to 'actors'. An actor is a human or machine entity that interacts with the system to perform meaningful work.

UML

 

User

An Entity that is interested in interacting with a particular Physical Entity.  Users can be humans, machines, or other software components.

[IOT-A] ++

 

User Story

See Story

 

 

user endpoint

An endpoint used by a user to interact.

IIC proposed

 

Validation

confirmation, through the provision of objective evidence, that the requirements for a specific intended use or application have been fulfilled

ISO/IEC 27000:2014

 

Verification

confirmation, through the provision of objective evidence, that specified requirements have been fulfilled

Note 1 to entry: This could also be called compliance testing."

 

ISO/IEC 27000:2014

 

Version History

 

 

View

See Architecture, View

 

 

ViewPoint

See Architecture, Viewpoint

 

 

Virtual Entity

Computational or data element representing a Physical Entity.

[IOT-A]

 

Vocabulary

A vocabulary is a set of terms (words or phrases) that describe information in a particular domain.

European Interoperability Framework

Security

Vulnerability

A weakness of an asset or security control that can be exploited by one or more threats

ISO/IEC 27000:2014

Security

Vulnerability Assessment

Systematic examination of an information system or product to determine the adequacy of security measures, identify security deficiencies, provide data from which to predict the effectiveness of proposed security measures, and confirm the adequacy of such measures after implementation.

NISTIR 7298 R2

 

Work Package

Teaser: The work defined at the lowest level of the work breakdown structure for which cost and duration can be estimated and managed.

Detail: In the context of project management

PMBOK


 

Definition Sources

The table below captures the sources used for the definitions.

European Interoperability Framework

Section 7.2 http://ec.europa.eu/isa/documents/isa_annex_ii_eif_en.pdf

Fowler

Fowler, M. (2004). Inversion of control containers and the dependency injection pattern. Retrieved August 3, 2004: http://martinfowler.com/articles/injection.html

HL-7

Health Level Seven International

IIC

Industrial Internet Consortium http://www.iiconsortium.org/

[IOT-A]

EU IOT-A Terminology http://www.iot-a.eu/public/terminology/copy_of_term 

IHMC

http://www.ihmc.us/groups/datkinson/wiki/fcb0e/intelligent_system_autonomy_automation_robots_and_agents.html

ISO 27789:2013

Health informatics — Audit trails for electronic health records

ISO 7498-2:1989

Information processing systems — Open Systems Interconnection — Basic Reference Model — Part 2: Security Architecture

ISO TS 19104:2008

Geographic information Terminology

ISO/IEC 14814:2006

Road transport and traffic telematics — Automatic vehicle and equipment identification — Reference architecture and terminology

ISO/IEC 18014-2:2009

Information technology — Security techniques — Time-stamping services — Part 2: Mechanisms producing independent tokens

ISO/IEC 19790:2012 

Information technology — Security techniques — Security requirements for cryptographic modules

ISO/IEC 24745:2011

Information technology — Security techniques — Biometric information protection

ISO/IEC 24760-1:2011

Information technology — Security techniques — A framework for identity management — Part 1: Terminology and concepts

ISO/IEC 24791-1:2010

Information technology — Radio frequency identification (RFID) for item management — Software system infrastructure — Part 1: Architecture

ISO/IEC 15414:2015

Information technology — Open distributed processing — Reference model — Enterprise language

ISO/IEC 27000:2014

Information technology — Security techniques — Information security management systems — Overview and vocabulary http://standards.iso.org/ittf/PubliclyAvailableStandards/c063411_ISO_IEC_27000_2014.zip  .

ISO/IEC 27000:2014

Information technology — Security techniques -- Information security management systems -- Overview and vocabulary

ISO/IEC 27005:2008

Information technology — Security techniques — Information security risk management

ISO/IEC 27036-1:2014 

Information technology — Security techniques — Information security for supplier relationships — Part 1: Overview and concepts

ISO/IEC 29100:2011 

Information technology — Security techniques — Privacy framework

ISO/IEC/IEEE 42010:2011

Systems and software engineering -- Architecture description

ISO/IEC DIS 18834-1

RA SOA – Terminology and Concepts

ISO/IEC TR 15026-1:2010 

Systems and software engineering -- Systems and software assurance -- Part 1: Concepts and vocabulary

ISO/IEC TR 15443-1:2012 

Information technology — Security techniques — Security assurance framework — Part 1: Introduction and concepts

ISO/TS 17574:2009 

Electronic fee collection — Guidelines for security protection profiles

ISO/TS 19129:2009

Geographic information — Imagery, gridded and coverage data framework

IS&S-Security

Director of National Intelligence (DNI) Information Sharing and Safeguarding (IS&S) CYBERSECURITY ROADMAP

JASON.ORG

http://json.org/.

NISTIR 7298 R2

Glossary of Key Information

Security Terms

http://nvlpubs.nist.gov/nistpubs/ir/2013/NIST.IR.7298r2.pdf

OASIS

Organization for the Advancement of Structured Information Standards  http://docs.oasis-open.org/

 

OED

Oxford Dictionary of English, 2nd Edition

OMG

Object Management Group UML/sysML/BPMN and other specifications www.omg.org.  Also found in numerous modeling tools.

PI

Information Sharing Environment Project Interoperability Initiative.  See www.ise.gov

PMBOK

Project Management Book of Knowledge.  ANSI/PMI 99-001-2004

UoW

University of Washington College of Engineering https://www.engr.washington.edu/

W3C

World Wide Web Consortium (W3C) http://www.w3.org/standards/

 

Term Content Overview

Regardless of the vocabulary (or vocabularies) that a term is associated with, each term’s definition has Four parts:

1.    The first column contains a classification for which specialized vocabulary the term.  For example, Activity belongs to the Security Vocabulary (as well as the master vocabulary).  If classification field is blank, the term is (currently) only a member of the Master list of terms and not a particular vocabulary.. 

2.    The second column contains the term’s name.  For example, Activity. 

3.    Next is the definition area. There are two, sometimes three, parts to the definition:

a.    Teaser:  this is a short, 1 or 2 line abbreviated definition.  The concept and initial implementation of teasers are from new feeds.  News feeds contain titles; associated summaries for the items – designed to make the reader to want to read more (hence, a Teaser); and a read more button.

b.    Detail Definition: usually a verbatim quote from the Definition Source (last column).  Sometimes expanded to include more detailed and explanatory text.

c.     Interoperability Model Segment.  Many definitions include graphics to help better explain the definition.  And in most cases, the graphic is of the specific segment of the UML Profile for Interoperability.  Clicking on the graphic will result in navigation to the part of the model that depicts and explains the various model elements – classes, attributes, kinds of associations, …) used to unambiguously specify the term and, perhaps most importantly, provide a basis for both measurement and code generation.

4.    And finally, the authoritative source for the definition of the term. Go to Definition Sources for a list of sources used in this Terminology

Change Log and Version History

Version

Point of Contact for Rev.

Revision Date

Description

1.05 and 1.06

Harrison, Victor

17 July 2017

Added Terms

1.    Model Checking (or Validation)

2.    Modeling and Simulation (M&S)

3.    RBAC-ABAC

4.    Testable

5.    Test Case

Revised Terms

6.    Testing and Conformance Platform

7.    Test Harness

8.    Trustmark

 

1.04

Harrison, Victor

05 July 2017

Added Terms

1.    Business Process

2.    Step

 

1.03

Harrison, Victor

23 June 2017

Revised Terms

1.    Interoperability

2.    Interoperability Level (and Synonym: Interoperability Maturity

1.02

Harrison, Victor

12 June 2017

New Citation Source:

IS&S-Security

Director of National Intelligence (DNI) Information Sharing and Safeguarding (IS&S) CYBERSECURITY ROADMAP

Revised Terms

1.    Assertion

2.    Environment

3.    Federation

4.    Numerous terms classified into vocabularies

5.    Moved Term Content Overview.  See Table of Contents.

Added Terms

1.    Critical Asset

2.    Control

3.    Information Sharing

1.01

Harrison, Victor

02 June, 2017

Reorganized Vocabulary

Added and Associated Terms to