System and element are two of the core concepts of this ontology. Both are concepts that are often used by practitioners, including the notion that systems have elements and that systems can be hierarchically combined (systems of systems). What differs from domain to domain is the specific nature of systems and elements; for instance, an electrical system has very different kinds of elements than an SOA system.
In the ontology only elements and systems within the SOA domain are considered. Some SOA sub-domains use the term component rather than the term element. This is not contradictory, as any component of an SOA system is also an element of that (composite) system.
This chapter describes the following classes of the ontology:
In addition, it defines the following properties:
<owl:Class rdf:about="#Element"> </owl:Class>
An element is an opaque entity that is indivisible at a given level of abstraction. The element has a clearly defined boundary. The concept of element is captured by the Element OWL class, which is illustrated below.
The Element Class
In the context of the SOA ontology we consider in detail only functional elements that belong to the SOA domain. There are other kinds of elements than members of the four named subclasses (System, HumanActor, Task, and Service) described later in this ontology. Examples of such other kinds of elements are things like software components or technology components (such as Enterprise Service Bus (ESB) implementations, etc.).
<owl:ObjectProperty rdf:about="#uses"> <rdfs:domain rdf:resource="#Element"/> <rdfs:range rdf:resource="#Element"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:about="#usedBy"> <owl:inverseOf> <owl:ObjectProperty rdf:about="#uses"/> </owl:inverseOf> </owl:ObjectProperty>
Elements may use other elements in various ways. In general, the notion of some element using another element is applied by practitioners for all of models, executables, and physical objects. What differs from domain to domain is the way in which such use is perceived.
An element uses another element if it interacts with it in some fashion. Interacts here is interpreted very broadly ranging through, for example, an element simply being a member of (used by) some system (see later for a formal definition of the System class), an element interacting with (using) another element (such as a service; see later for a formal definition of the Service class) in an ad hoc fashion, or even a strongly coupled dependency in a composition (see Section 5.2 for a formal definition of the Composition class). The uses property, and its inverse usedBy, capture the abstract notion of an element using another. These properties capture not just transient relations. Instantiations of the property can include “uses at this instant”, “has used”, and “may in future use”.
For the purposes of this ontology we have chosen not to attempt to enumerate and formally define the multitude of different possible semantics of a uses relationship. We leave the semantic interpretations to a particular sub-domain, application, or even design approach.
Using an organizational example, typical instances of Element are organizational units and people. Whether to perceive a given part of an organization as an organizational unit or as the set of people within that organizational unit is an important choice of abstraction level:
This simple example expresses that some elements have an internal structure. In fact, from an internal perspective they are an organized collection of other simpler things (captured by the System class defined below).
<owl:Class rdf:about="#System"> <owl:disjointWith> owl:Class rdf:about="#Task"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Service"/> </owl:disjointWith> <rdfs:subClassOf> <owl:Class rdf:about="#Element"/> </rdfs:subClassOf> </owl:Class>
A system is an organized collection of other things. Specifically things in a system collection are instances of Element, each such instance being used by the system. The concept of system is captured by the System OWL class, which is illustrated below.
The System Class
This definition of System is heavily influenced by IEEE Std 1471-2000, adopted by ISO/IEC JTC1/SC7 as ISO/IEC 42010:2007: Systems and Software Engineering – Recommended Practice for Architectural Description of Software-intensive Systems.
In the context of the SOA ontology we consider in detail only functional systems that belong to the SOA domain. Note that a fully described instance of System should have by its nature (as a collection) a uses relationship to at least one instance of Element.
Since System is a subclass of Element, all systems have a boundary and are opaque to an external observer (black box view). This excludes from the System class structures that have no defined boundary. From an SOA perspective this is not really a loss since all interesting SOA systems do have the characteristic of being possible to perceive from an outside (consumer) perspective. Furthermore, having System as a subclass of Element allows us to naturally express the notion of systems of systems – the lower-level systems are simply elements used by the higher-level system.
At the same time as supporting an external viewpoint (black box view, see above) all systems must also support an internal viewpoint (white box view) expressing how they are an organized collection. As an example, for the notion of a service this would typically correspond to a service specification view versus a service realization view (similar to the way that SoaML defines services as having both a black box/specification part and a white box/realization part).
It is important to realize that even though systems using elements express an important aspect of the uses property, it is not necessary to “invent” a system just to express that some element uses another. In fact, even for systems we may need to be able to express that they can use elements outside their own boundary – though this in many cases will preferably be expressed not at the system level, but rather by an element of the system using that external Element instance.
System is defined as disjoint with the Service and Task classes. Instances of these classes are considered not to be collections of other things. System is specifically not defined as disjoint with the HumanActor class since an organization in many cases is in fact just a particular kind of system. We choose not to define a special intersection class to represent this fact.
Continuing the organizational example from above, we can now express that an organizational unit as an instance of System has the people in it as members (and instances of Element).
Using a service composition example, services A and B are instances of Element and the composition of A and B is an instance of System (that uses A and B). It is important to realize that the act of composing is different than composition as a thing – it is in the latter sense that we are using the term composition here.
See also below for a formal definition of the concepts of service and service composition (and a repeat of the example in that more precise context).
Consider a car wash business. The company as a whole is an organizational unit and can be instantiated in the ontology in the following way:
<owl:ObjectProperty rdf:about="#represents"> <rdfs:domain rdf:resource="#Element"/> <rdfs:range rdf:resource="#Element"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:about="#representedBy"> <owl:inverseOf> <owl:ObjectProperty rdf:about="#represents"/> </owl:inverseOf> </owl:ObjectProperty>
The environment described by an SOA is intrinsically hierarchically composite (see also Section 5.2 for a definition of the Composition class); in other words, the elements of SOA systems can be repeatedly composed to ever higher levels of abstraction. One aspect of this has already been addressed by the uses and usedBy properties in that we can use these to express the notion of systems of systems. This is still a very concrete relationship though, and does not express the concept of architectural abstraction. We find the need for architectural abstraction in various places such as a role representing the people playing that role, an organizational unit representing the people within it (subtly different from that same organizational unit using the people within it, as the represents relationship indicates the organizational unit as a substitute interaction point), an architectural building block representing an underlying construct (for instance, important to enterprise architects wanting to explicitly distinguish between constructs and building blocks), and an Enterprise Service Bus (ESB) representing the services that are accessible through it (for instance, relevant when explicitly modeling operational interaction and dependencies). The concept of such an explicitly changing viewpoint, or level of abstraction, is captured by the represents and representedBy properties illustrated below.
The represents and representedBy Properties
It is important to understand the exact nature of the distinction between using an element (E1) and using another element (E2) that represents E1. If E1 changes, then anyone using E1 directly would experience a change, but someone using E2 would not experience any change.
When applying the architectural abstraction via the represents property there are three different architectural choices that can be made:
Note that in most cases an instance of Element will represent only one kind of thing. Specifically, an instance of Element will typically represent instances of at most one of the classes System, Service, HumanActor, and Task (with the exception of the case where the same thing is both an instance of System and an instance of Actor). See later sections for the definitions of Service, HumanActor, and Task.
Expanding further on the organizational example, assume that a company wants to form a new organizational unit O1. There are two ways of doing this:
In this way the abstraction aspect of the represents property induces an important difference in the semantics of the collection defining the new organization. Any instantiation of the ontology can and should use the represents and representedBy properties to crisply define the implied semantics and lines of visibility/change.
Joe chooses to organize his business into two organizational units, one for the administration and one for the actual washing of cars. This can be instantiated in the ontology in the following way: