View MODAF:SOV-1 Service Taxonomy View



The SOV-1 Service Taxonomy View is part of the MODAF Service Oriented Viewpoint* and one of the 47 MODAF views*.

Version & Date

Version 1.2.004.

* =  changed at 1.2.004

+ =  new at 1.2.004

The change history is derived from the definition of each MODAF view within the The MODAF Service Oriented Viewpoint viewpoint defining document from

See MODAF Release History.


From The MODAF Service Oriented Viewpoint p3:

The SOV-1 specifies a hierarchy of services. The elements in the hierarchy are M3 Services (i.e. service specifications rather than service implementations), and the relationships between the elements are specialisations – i.e. one service is a special type of another. Service attributes, interfaces and constraints are inherited down a service taxonomy – e.g. if Service A is a specialisation of Service B then it also inherits all the features of Service B.

Subject to Crown Copyright


From The MODAF Service Oriented Viewpoint p3:

The purpose of an SOV-1 is to provide a governance structure for a Service-Oriented Architecture. Along with SOV-2, it specifies a standard library of service specifications for an enterprise, which service implementers are expected to conform to.

Subject to Crown Copyright


From The MODAF Service Oriented Viewpoint p4:

In MODAF terms, a service is an implementation-independent specification of a packaged element of functionality and/or capability.

There is, however, potential for confusion between services and capabilities. To help clarify this:

The key indicator of a service is that it provides a standard interface to consumers. This means that services may be used as wrappers for one or more capability in order to provide a standard method of access to the capability. A well-designed service taxonomy provides a set of specifications for capability providers to adhere to.

An SOV-1 depicts services, specialisation relationships between services, service attributes and service policy (i.e. constraints). A service taxonomy persists over time (an architect may wish to specify historical, current or future services) and may be referenced by multiple architectures.

In SOV-1, services are only defined in the abstract, i.e. SOV-1 does not specify how a service is to be implemented. An SOV-1 is structured as a specialisation hierarchy of services, with the most general at the root and most specific at the leaves.

In contrast to AV-2, Integrated Dictionary, an SOV-1 is structured using only one type of specialisation relationship between elements: super- subtype. A super-subtype relationship is a relationship between two classes with the second being a pure specialisation of the first. Any service that specialises from another must implement all the functionality of its parent, and provide all the same input and output interfaces of its parent; in other words, any specialised service shall be entirely compatible with its parent (however, it may add functionality and interfaces). For example, if a service, Printing, requires input of paper size and ink colours, a service, Hi-Resolution Printing, that specialises from it must also accept these parameters and produce equivalent behaviour when initiated.

Services may have attributes and constraints (service policy) defined against them. Attributes are inherited by specialised services. Where an attribute is specified for a service, implementations of that service shall specify their values for the attribute.

Subject to Crown Copyright


Data Objects

From The MODAF Service Oriented Viewpoint p3:

The data in an SOV-1 can include:


Subject to Crown Copyright


From The MODAF Service Oriented Viewpoint p4:

  • Tabulation
  • Hierarchical (connected shapes)
  • UML class diagram

Subject to Crown Copyright

Configuration History




Other Frameworks

See also:

Category:Framework -> View
Category:MODAF -> View



© 2010 Eclectica Systems Ltd.