View MODAF:MODAF Release History

mod_logo_60.jpg

Introduction

This is an attempt to try and piece together a release history for MODAF as the current MoD document only really covers 1.2 with nothing of any substance before this.

Current Version

The current version of MODAF is 1.2.004, referred to as ‘1.2’.

MODAF Version History

An archive of stereotypes that have been removed as a result of updates is kept separately.

1.2.004 April 2010

From ‘Change Log for MODAF v1.2.003 to 1.2.004. Effective 01 April 2010’:

The changes to MODAF 1.2.004 were mostly in the Meta-Model. These changes are listed below:
Change Proposal A - Ports on SV-1

  • PortType (SV-2) removed.
  • ResourcePort added (SV-1, SV-2).
  • SoftwarePort added (SV-2).
  • InteractionEnd(ABSTRACT) added to allow ResourceInteractions to also go between ResourcePorts (SV-1).
  • SystemPortConnector renamed to ResourcePortConnector and now connects resource ports (SV-2).
  • SystemPortConnectorEnd renamed to ResourcePortConnectorEnd.

Change Proposal C - Minor fixes and additions to M3

  • OperationalStateDescription now only applicable to Nodes (OV-6).
  • NodeContextUsage on OperationStateDescription now displayed as taggedValue relationship instead of attribute (no semantic change) (OV-6).
  • NodeContextUsage removed for OperationalNodeLifeline (lifelines can only refer to properties anyway) (OV-6).
  • v1.2 was supposed to change StV-4 so that aggregation relationships were used for composition instead of composite class. This never ended up in M3 though.
  • tasks relationship is now a redefined ownedBehaviour (was tagged value) in StV-1.
  • LogicalFlowItem (ABSTRACT) added to enable info flows to/from KnownResources (OV-2).
  • Process added as ABSTRACT supertype of EnduringTask and OperationalActivity.
  • EnterpriseStructure and EnterpriseTemporalPart were missing from StV-1 diagram – fixed.
  • ProcessOwner (already there in OV-4) added to StV-1.
  • Link from ActualOrganisation to EnterprisePhase added (StV-1).
  • Added isProject and isOrganisation tagged values in StV-2 to allow architects to show that their enterprise is either a Project or an ActualOrganisation.
  • ResourceStateMachine owner removed - state machines only applicable to resources, not functions.
  • SystemStructureModel removed (it was not connected to anything).
  • subGoals tagged value added to EnterpriseGoal in StV-1 - used to provide a goal structure (parent-child).
  • Tagged value between ConfigurationDeployed and CapabilityConfiguration renamed to “configuration” from “fromTime” (StV-5).
  • ProjectTypeSpecialisation (extends UML::Generalization) added (AcV-1).
  • LastEdited and Architect taggedvalues added to ArchitecturalProduct in AV-1 in anticipation of MODAF/SOSA style guides.
  • ArchitectureRealisation (extends UML::Realization) added to trace between LogicalArchitecture and PhysicalArchitecture (AV-1 Architecture Product).
  • ElementOfEnvironment (abstract) added to clean up environment model in AV.
  • SupportingActivities tagged value added to EnduringTask (StV-6).
  • SupportingCapabilities tagged values added to Enduring Task (StV-1/6).
  • ResourceInterface added to support SEIG requirement for interface-based connections (SV-1).
  • Adding missing <> between servicesupportsactivity and UML::Dependency (OV-5).
  • ProtocolImplementation and ImplementsProtocol removed.
  • ImplementedProtocol, ProtocolLayer and ImplementedOn added to show how protocols can be implemented for a particular purpose.
  • ProtocolStack removed.
  • RunsOn added to show which protocols can run on other protocols (cf ImplementedOn).
  • Definitions cleaned up in SOV elements.
  • New View added SV-12b (old SV-12 renamed to SV-12a).
  • USedService renamed to RequiredService.
  • ProvidesService renamed to ProvidedService, and taggedvalue added so that it matches UsedService.

Change Proposal K - Add Security Aspects to MODAF

  • SecurityDomain (subtype of Node) added to OV-2.
  • SecurityPolicy (subtype of OperationalConstraint) added to OV-6 and OV-2.
  • OperationalConstraint added to OV-2 (this was allowed in MODAF anyway).
  • Trustline (extends UML::Dependency) added to OV-2.

Change Proposal M - Add materiel and people flows to OV-3, SV-1, OV-5, SV-4, SV-6, OV-6c, SV-10c

  • MaterielFlow, EnergyFlow and MovementOfPeople added to OV-3.
  • ResourceCommunicaiton added to SV-1 and OV-4 Typical.
  • FunctionCommunication added to SV-4.
  • MaterielFunctionFlow added to SV-4.
  • PeopleFunctionFlow added to SV-4.
  • EnergyFunctionFlow added to SV-4.
  • exchangeProperties tagged value now on LogicalFlow - was on InformationExchange) (OV-3).
  • MaterielFlow, EnergyFlow and MovementOfPeople added to OV-6c.
  • InformationExchangeMessage renamed NodeInteraction (OV-6c).
  • carriedInfoElement tagged value renamed to carried (OV-5).
  • OperationaActivityMaterielFlow added (OV-5).
  • OperationaActivityPeopleFlow added (OV-5) - any jokes about their being only one type of activity that produces people should be addressed to the Swedish Armed Forces, who requested this addition.
  • OperationaActivityEnergyFlow added (OV-5).
  • Energy (extends Class) added to OV-2,3,5 to provide compatibility with NAF 3.1.
  • ResourceMessage (extends UML::Message) added to SV-10c - allows clearer link back to materiel, human, etc. flows.

Subject to Crown Copyright


Not listed in the change log:

1.2 June 2008

From ‘MODAF Configuration Control Policy and History’:

Revision 1.2.003 Minor update of the M3 and corresponding views M3 changes:

  • DataElement added to SV-2b diagram (was missing, no model change)
  • InformationElement added to SV-11 diagram (was missing, no model change)
  • hasChildren tagged value added to DataElement and InformationElement, to allow decomposition of elements

Revision 1.2.002 Minor update of the M3 and corresponding views M3 changes:

  • Added missing Software on SV-11
  • requiredLevel tagged value added on SV-12 [SV-12a from 1.2.004] to show that when a resource uses a service it requires it to be at a given level
  • requiredLevel tagged values added on OV-2 - when a node is required to provide a certain level of service, or requires a service at a certain level
  • hasVision tagged values added to StV-1 to show that an enterprise has a vision

Revision 1.2.001 Minor update of the M3 and corresponding views M3 changes:

  • Provide a link between Functions and Service Functions (to match the link between Functions and OperationalActivities).
  • Provide a reciprical link to Resources provide Services so Resources can use Services Corresponding View changes:
    • SV-5 Alternate matrix showing Resource to Service Function relationships
    • SV-12 shows how a Resource depends on a Service being available in order to function correctly

Subject to Crown Copyright

From the MODAF Metamodel (M3):

  • Removed inaccurate description for ResourceUsage
  • ServiceFunctionToFunctionMapping added (SV-5) to show that ServiceFunctions may be implemented by Functions performed by Resources
  • UsesService added (SV-12) to show that a Resource depends on a particular Service being available in order to function correctly
  • ”<<” and “>>” symbols removed from documentation

Subject to Crown Copyright

From ‘MODAF Configuration Control Policy and History’:

Revision 1.2.000 Major revision to version 1.2 of MODAF. Note that changes specific to the M3 are documented within the M3 specification. Pages significantly updated to the new version are now labelled 1.2 in their titles. Highlight changes:

© Crown Copyright 2004-2008

From the MODAF Metamodel (M3):
  • Resource renamed ResourceType
  • LogicalArchitecture and PhysicalArchitecture added - container classes for OV-2 and SV-1 configurations
  • FunctionalResource Removed
    • - Now there are just resources - we know if they are functional if they have functions. If they don’t then either they’re not functional, or we don’t care
  • System, PhysicalAsset now *usages
  • of artefacts - i.e. an artefact used in one context may be a system, in another, it’s a platform.
  • Also added platform, part, etc. as usages (see SV-1 Resources).
  • Software added (subtype of Resource)
  • ResourceStructureModel removed - now use PhysicalArchitecture or CapabilityConfiguration as top-most class in an SV-1
  • Role renamed RoleType
  • ResourceComposition renamed ResourceWholePart
  • Capability now extends Class (formerly extended OpaqueBehavior)
  • NodeAssemblyUsage renamed to Node (UML tools were displaying the stereotype of the property)
  • Node renamed to NodeType (see above NodeAssemblyUsage change)
  • NodeInProblemDomain deleted (see above NodeAssemblyUsage change)
  • RequiredNodeLocation now points at Node (i.e. the property)
  • NodeRelationshipDescription deleted
  • Needline changes:

    • Needline now abstract, and extends InformationFlow
    • Needline is subtyped to specific types of flow; InformationExchange, EnergyFlow, MovementOfPeople, MaterielFlow
    • Each of the types of flow may optionally refer to the type of thing that is flowed
    • inDomain tagged value added so that needlines can be clearly specified as part of a problem domain
  • EnduringTask now extends Activity
  • Link from EnterprisePhase to Environment removed
  • StV-2 CapabilityComposition now uses composition (black diamond) associations instead of composite structure
  • SV-6 - tagged value addded to link SystemPortConnector to the DataElements it conveys
  • SoftwareComponent added - subtype of ResourceUsage to show that one software element is a component of another.
  • Consumes added - extending dependency - asserts that a node consumes a service (SOA additions to OV-2)
  • Provides added - extending dependency - asserts that a node provides a service (SOA additions to OV-2)
  • OV-1 InstanceInConcept added - fixes error that was using FieldedConcept as a part in a composite structure
  • OV-1 Relationship from HighLevelOperationalConcept to Mission is now a tagged value
  • SystemPort is now typed by Software or Artefact (to enable better re-use of port design across architectures)
  • PortType now abstract, and is supertype of Artefact and Software
  • RadioFrequencyPort now removed - replaced by taggedvalue relating Artefact to FrequencyRange
  • BehaviouralModel and CompositeStructureModel removed

© Crown Copyright 2004-2008

From ‘The MODAF Strategic (StV) Viewpoint’:

© Crown Copyright 2004-2008

‘The MODAF Operational (OV) Viewpoint’:

© Crown Copyright 2004-2008

‘The MODAF Technical Standards Views (TV) Viewpoint’:

© Crown Copyright 2004-2008

1.1 April 2007

From modaf.com:

The new version of MODAF is an evolution of v1.0, and seeks to better integrate the concepts from the Strategic and Acquisition views with the core views inherited from DoDAF (OV,SV,TV,AV). In addition, the following improvements have been made:

  • Clearer emphasis in the documentation of the logical nature of the Operational Views (esp. OV-2 & 5).
  • Clearer distinction between OV & SV, with OV being seen as the “what” and the SV the “how” - i.e. logical architecture independent of implementation in the OV being released as a solution specification architecture in the SVs
  • Addition of “Problem Domain” concept in OV-2 to clarify the trade-space for to-be architectures.
  • Addition of human factors in the SVs - organisations, posts and roles can now be explicitly shown in SV-1, and functions in SV-4 can be conducted by roles (human), systems (machines) or Capability Configurations (combinations of humans, systems, platforms, etc.).
  • StV-6 purpose and use clarified - now acts as repository for Standard Operational Activities which can then be re-used in multiple OV-2s. It is likely that these will be JETLs or similar.
  • StV-5 shows organisational deployment of capability configurations.
  • High-level M3 overviews provided for the most popular views (more of these will be added over the next month).
From ‘The MODAF Acquisition (AcV) Viewpoint’:

© Crown Copyright 2004-2008

From the MODAF Metamodel (M3):

v1.1 Beta to v1.1 Final

Changes to text definitions: (These changes were made to accomodate the requirements of the NATO Architecture Framework - i.e. references to MODAF, MOD, M3 and UK have been made more generic)

  • ActivityComposition - reference to m3 replaced by “this meta-model”. “UML::” added to CallBehaviorAction
  • ActivityToFunctionMapping - reference to SystemFunction replaced with Function
  • ActualLocation - “GeographicLocation” changed to “ActualLocation” (this was a cut-and-paste error from a previous version of M3)
  • ActualOrganisation - “UK Ministry of Defence” changed to “US Department of Defense”
  • ActualOrganisationRelationship - whole organisations added to definition, added to reference
  • ActualPost - reference to “Post” replaced by “PostType” - example changed to President of USA
  • ArchitecturalDescription - reference to MODAF re-worded to “this meta-model”
  • ArchitectureMetaData - “meta data” changed to MetaData
  • CapabilityComposition - MOD reference now confined to a “Note for MOD Users”
  • CapabilitySpecialisation - referred to “RequiredCapability” now “Capability”
  • Concern - reference to Stakeholder replaced by OrganisationalResource
  • EnterpriseStructure - definition added
  • EnterpriseTemporalPart - definition added
  • EnvironmentalProperty - definition added
  • ExternalIndividual - definition added
  • ExternalType - definition added
  • FieldedCapability - example now says *UK
  • Type 23 Frigate
  • FunctionFlow - “UML::” added to “ObjectFlow”.
  • MessageHandler - definition added
  • MetaData - reference to MOD MetaData standard moved to a “Note for MOD Users”
  • NodeAssemblyUsage - added to definition
  • NodeConnector - added to definition
  • NodeRealisation - note about MODAF Technical Working Group decision removed
  • OperationalActivityAction - added to definition
  • OrganisationProjectRelationship - upper case P on Project
  • PhysicalAsset - definition revised in light of Resource approach. Tornado/Raptor example removed
  • PostType - SO1 reference removed from example
  • ProductOfView - definition added
  • ProjectSequence - definition added
  • ProjectTheme - added
  • Protocol - added
  • ProtocolStack - added
  • RadioFrequencyPort - definition added
  • RelatedProjectReference - added
  • Resource - reference to FunctionalResource added
  • ResourceConstraint - added
  • ResourceInteraction - had no definition, now fixed
  • ResourceInteractionSpecification - added
  • ResourceLifeline - definition changed to “A UML::Lifeline that represents a ResourceLifelineItem that interacts with another ResourceLifelineItem”
  • ResourceLifelineItem - definition changed to “An element that may be represented as a ResourceLifeLine in a ResourceInteractionSpecification. [ABSTRACT]”
  • SameAs - definition added
  • ServiceParameterType - “UML::” added to “DataType”
  • ServiceSupportsActivity - typo corrected - OperationALActivity
  • SubjectOfForecast - added
  • SubjectOfOperationalConstrain - added - OperationalStateDescription added
  • SubtypeRelationship - added
  • System - note referring to v0.96 removed
  • SystemPort - added

Model Changes in 1.1 Final: AV Changes

  • StereotypeExtension added - this allows ontology references to be represented as new stereotypes by architects - i.e. it’s a shorthand for displaying ontology references that are used several times in an architecture.
  • OntologyReference added - abstract supertype of ExternalType and ExternalIndividual

SV Changes

  • ImplementsDataModel added - Stereotype of Realization, used to assert that a System implements a PhysicalDataModel

TV Changes

  • StandardConfiguration added - stereotype of UML::Comment which may be attached to a CapabilityConfiguration to show that it is a standard pattern for re-use in the architecture

Proposed Service Views / NSOV

  • ServiceAimsToAchieve now points to Capability
  • ServiceConsumerAdded - extends UML::Actor

Version 1.0 to 1.1 Beta

AV Changes

  • Environment now extends class
  • Climate and LightCondition added
  • Environment is a composite class of Climate,LightCondition and LocationType
  • Stakeholder Removed and simply replaced with the existing OrganizationalResource concept - i.e. PostType or OrganizationType
  • FrequencyRange added as a subtype of MeasuredProperty
  • QualitativeProperty added
  • EffectivityConstraint, EffectivityConstrainedItem and TimePeriod removed - effectivity now implemented as tagged values referring to begin and end ISO8601DateTime instances
  • ISO8601DateTime now extends UML::LiteralString

AV-1

  • IEEE1471 Alignment:
    • NOTE Enterprise has not been renamed to System (the IEEE1471 name) because System already exists, and because MODAF is about Enterprise Architecture, not Systems Architecture.
    • DiagramCompositeClass renamed to CompositeStructureModel and now inherits from ArchitecturalProduct
  • Also added other product types:

    • BehaviouralModel, Matrix, Ontology, InformationModel, TextProduct
  • View (was ArchitecturalProduct) now extends UML::Package
  • A major change for v1.1 of MODAF is the idea of enterprise phases - the whole-life enterprise is split into phases (i.e. periods of time in the life of the enterprise)
  • Enterprise Stereotype replaced by WholeLifeEnterprise and EnterprisePhase

AV-2

  • ClassifiedElement removed.
  • Mechanism for referencing MODAF ontology is added to replace ClassifiedElement. New Stereotypes are:
    • ExternalType, ExternalIndividual
    • UML instantiate and generalisation, and SameAs (extends UML Trace) relationships used to relate all elements in AV-2 to each other and to external definitions

StV Changes

  • RequiredCapability removed - now all handled by capability.
  • CapabilitySpecification removed.

StV-1

  • Capability now extends UML::OpaqueBehaviour instead of UML::Class - can still be used in Composite Structure models however
  • CapabilityVision now renamed to EnterpriseVision (by popular demand)
  • GoalForVision removed - now handled by tagged value from vision.
  • CapabilityContributesToVision removed - Capability now links directly to EnterprisePhase.
  • EnduringTask now used for high-level strategic tasks the enteprise as a whole undertakes (no longer used in StV-6).

StV-2

  • CapabilityContext added to enable MeasuredCapabilitys to be specified in terms of the environment they are valid for (see also environment model added to AVs).
  • EnvironmentalConditions added (stereotype of dependency) to link Capability to Environment

StV-3

  • ResourceForCapability removed
  • ConfigurationDeployed added to show a CapabilityConfiguration going into service with an ActualOrganisationalResource
  • ConfigurationNoLongerUsed added to show a CapabilityConfiguration going out of service with an ActualOrganisationalResource

StV-6

  • StandardOperationalActivity added - subtype of OperationalActivity.
  • CapabilitySupportsTask removed

OV-1

  • AspectOfHLOC & HLOCAspect Removed - now covered by MeasuredCapability traced to Node
  • ArbitraryConnection connection added to allow connections to be shown on an OV-2 that are not derived from the architecture

OV-2

  • ActivityConductedAtNode renamed to NodeHasBehaviour
  • RequiredNodeLocation.node now points at NodeAssemblyUsage
  • RequiredCapabilityForNode renamed to CapabilityForNode
  • CapabilityForNode node now has optional usage context for when a capability is required for a specific usage of a node
  • NodeConnectionType removed - not needed as connectors need not be typed - besides, needlines always carry at least one info flow
  • Definition of Node changed to “A logical entity that performs operational activities. Note: nodes are specified independently of any physical realisation.”
  • ProblemDomain and NodeInProblemDomain added (see MODAF documentation).
  • InformationExchange now extends UML::InformationFlow and specifies exchange properties (OV-3) through exchangeProperties tagged value
  • NodeRelationshipDescription added (subtype of CompositeStructureModel) used as container for Node and ProblemDomain

OV-4

  • OrgResourceConductsActivity removed - now covered by combination of ResourceHasCompetence Competence.toConduct
  • ProcessOwner added - asserts that an org resource is responsible for an op activity
  • Competence was a specialisation of UML::Class, now fixed to be an extension
  • Competence.toConduct now points to Function
  • RoleInOrganisation removed - now handled by ResourceComposition
  • ResourceHasCompetence now renamed to CompetenceForRole and points at Role (see SV-1).
  • RequiredCompetence removed (now covered by CompetenceForRole
  • ActualOrganisationalRole renamed to ActualOrganisationComposition
  • ActualOrganisationRelationship now extends UML::InformationFlow

OV-5

  • IDEF0FlowEnd renamed to FlowEnd to remove any suggestion that OV-5 should be IDEF-0 based.
  • OpActivityControlPin and OpActivityMechanismPin deleted - replaced by boolean tagged values on OpActivityInputPin
  • NodeProvidesControlOrMechanism deleted
  • FLowEnd deleted - control and mechanism pins now descend from OpActivityInputPin
  • ContributionToTask Removed
  • InfoElementInFlow deleted - replaced by carriedInfoElements tagged value
  • OperationalSwimlane added - stereotype of UML::ActivityPartition

OV-6

  • All three view meta-model excerpts now on one page.
  • OperationalStateDescriptionOwner removed - SubjectOfOperationalConstraint used instead.
  • Constraints may now apply to Entity (from a logical data model) and NodeAssemblyUsage (i.e. when only one usage of a type of node is to be constrained)

SV Changes

  • usageContext attribute added to NodeRealisation - because there may be different solutions for each node usage
  • CapabilityConfiguration and Resource moved to SV package

SV-1

  • OrganisationalDeploymentToAsset replaced by ResourceComposition
  • Hosting replaced by ResourceComposition
  • SystemConnector, SystemConnectionSpecification and SystemConnectorEnd removed and replaced by ResourceInteraction
  • CapabilityProvider removed, Resource now used
  • ConnectionRealisesIER removed - now handled by “realization” attribute of InformationExchange
  • CapabilityRealisation added.
  • Role added - i.e. a functional aspect of an organizational resource.

SV-2

  • SystemPortConnectionMap removed - now covered by realizingConnector attribute on ResourceInteraction
  • RadioFrequencyPort added as subtype of PortType, with min and max frequency tagged values
  • RadioFrequencyPortConnector added as subtype of SystemPortConnector - constrained to connect ports which are typed as RadioFrequencyPort
  • SystemStructureModel added (subtype of CompositeStructureModel) used as container for Systems

SV-4

  • Function replaces SystemFunction and is conducted by any FunctionalResource (i.e. CapabilityConfiguration,System,Role).
  • ManualFunction added as subtype of Function to reflect human factors now included in SVs
  • SystemConnectionToFlowMapping deleted - covered by realizingActivityEdge association on
  • SystemFunctionFlow renamed FunctionFlow
  • WholeLifeConfiguration added

SV-10a

  • SystemConstraint renamed to ResourceConstraint to reflect human factors now included in SVs
  • Role added as a subject for an ResourceConstraint

SV-10b

  • SystemStateMachine renamed to ResourceStateMachine to reflect human factors now included in SVs
  • SystemStateMachineOwner renamed to ResourceStateMachineOwner and is now supertype of Resource or Function

SV-10c

  • SystemInteractionSpecification renamed to ResourceInteractionSpecification to reflect human factors now included in SVs
  • SystemLifeliner renamed to ResourceLifeline

TV Changes

  • RatificationBody stereotype of UML:Dependency added to indicate the ActualOrganisation that ratified the standard
  • SpectrumAllocation subtype of Standard added to represent standard frequency bands

AcV Changes

  • OrganizationProjectRelationship now refers to ActualOrganisationalResource so that ActualPosts can own projects.
  • ProjectMilestone now subtype of ISO8601DateTime
  • ConfigurationOfProjectDeliverable removed - CapabilityIncrement now optionally refers to a delivery configuration
  • CapabilityDelivery removed. Instead, a CapabilityConfiguration should be created (even if its structure is not known), traced to the necessary capabilities, and linked to the CapabilityIncrement
  • ProjectAimsToDeliver removed. Milestones in the projects deliver CapabilityConfigurations instead, which is a more realistic representation of what actually goes on - i.e. a project rarely delivers a capability in one tranche.

© Crown Copyright 2004-2008

1.0 August 2005

References

Other Frameworks

References

Category:Framework -> Revision
Category:Framework -> Release
Category:Framework -> History

 

Categories:

 

© 2010 Eclectica Systems Ltd.