ISO/IEC 18384-3:2016

FINAL
INTERNATIONAL ISO/IEC
DRAFT
STANDARD FDIS
18384-3
ISO/IEC JTC 1/SC 38
Information Technology — Reference
Secretariat: ANSI
Architecture for Service Oriented
Voting begins on:
2015-06-19 Architecture (SOA) —
Voting terminates on:
Part 3:
2015-08-19
Service Oriented Architecture Ontology
Technologie de l’information — Architecture de référence pour
l’architecture orientée service (SOA)
RECIPIENTS OF THIS DRAFT ARE INVITED TO
SUBMIT, WITH THEIR COMMENTS, NOTIFICATION
OF ANY RELEVANT PATENT RIGHTS OF WHICH
THEY ARE AWARE AND TO PROVIDE SUPPOR TING
DOCUMENTATION.
IN ADDITION TO THEIR EVALUATION AS
Reference number
BEING ACCEPTABLE FOR INDUSTRIAL, TECHNO-
ISO/IEC FDIS 18384-3:2015(E)
LOGICAL, COMMERCIAL AND USER PURPOSES,
DRAFT INTERNATIONAL STANDARDS MAY ON
OCCASION HAVE TO BE CONSIDERED IN THE
LIGHT OF THEIR POTENTIAL TO BECOME STAN-
DARDS TO WHICH REFERENCE MAY BE MADE IN
©
NATIONAL REGULATIONS. ISO/IEC 2015

ISO/IEC FDIS 18384-3:2015(E)
© ISO/IEC 2015, Published in Switzerland
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form
or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior
written permission. Permission can be requested from either ISO at the address below or ISO’s member body in the country of
the requester.
ISO copyright office
Ch. de Blandonnet 8 • CP 401
CH-1214 Vernier, Geneva, Switzerland
Tel. +41 22 749 01 11
Fax +41 22 749 09 47
copyright@iso.org
www.iso.org
ii © ISO/IEC 2015 – All rights reserved

ISO/IEC FDIS 18384 Part 3
67 Contents Page
68 Foreword . 8
69 Introduction . 9
70 1 Scope . 12
71 2 Normative references . 12
72 3 Terms and Definitions . 12
73 3.1 Definitions. 12
74 3.1.1 Opaque . 12
75 3.1.2 Ontology . 12
76 3.2 Acronyms. 13
77 3.3 Notations . 13
78 3.4 Conventions . 14
79 3.5 Conformance . 14
80 4 SOA Ontology Overview . 15
81 4.1 At a Glance . 15
82 4.2 Intended Use. 17
83 4.3 Applications. 17
84 5 System and Element . 18
85 5.1 Overiew . 18
86 5.2 The Element Class . 18
87 5.3 The uses and usedBy Properties . 19
88 5.4 Element – Organizational Example . 19
89 5.5 The System Class . 20
90 5.6 System – Examples . 21
91 5.6.1 Organizational Example . 21
92 5.6.2 Service Composition Example . 21
93 5.6.3 Car Wash Example . 21
94 5.7 The represents and representedBy Properties . 21
95 5.8 Represents and representedBy Examples . 23
96 5.8.1 Organizational Example . 23
97 5.8.2 Car Wash Example . 23
98 6 HumanActor and Task . 24
99 6.1 Overview . 24
100 6.2 The HumanActor Class . 24
101 6.3 HumanActor – Examples . 25
102 6.3.1 The uses and usedBy Properties Applied to HumanActor . 25
103 6.3.2 The represents and representedBy Properties Applied to HumanActor . 25
104 6.3.3 Organizational Example . 26
105 6.3.4 Car Wash Example . 26
106 6.4 The Task Class . 26
107 6.5 The does and doneBy Properties . 27
108 6.6 Task – Examples . 28
109 6.6.1 The uses and usedBy Properties Applied to Task . 28

ISO/IEC FDIS 18384 Part 3
110 6.6.2 The represents and representedBy Properties Applied to Task . 28
111 6.6.3 Organizational Example . 28
112 6.6.4 Car Wash Example . 28
113 7 Service, ServiceContract, and ServiceInterface . 29
114 7.1 Overview . 29
115 7.2 The Service Class . 30
116 7.3 The performs and performedBy Properties . 30
117 7.4 Service Consumers and Service Providers . 31
118 7.5 Service – Examples . 31
119 7.5.1 The uses and usedBy Properties Applied to Service . 31
120 7.5.2 The represents and representedBy Properties Applied to Service . 32
121 7.5.3 Exemplifying the Difference between Doing a Task and Performing a Service . 32
122 7.5.4 Car Wash Example . 32
123 7.6 The ServiceContract Class . 33
124 7.7 The interactionAspect and legalAspect Datatype Properties . 33
125 7.8 The hasContract and isContractFor Properties. 35
126 7.9 The involvesParty and isPartyTo Properties . 35
127 7.10 The Effect Class . 36
128 7.11 The specifies and isSpecifiedBy Properties . 37
129 7.12 ServiceContract – Examples. 38
130 7.12.1 Service-Level Agreements . 38
131 7.12.2 Service Sourcing . 38
132 7.12.3 Car Wash Example . 38
133 7.13 The ServiceInterface Class . 38
134 7.14 The Constraints Datatype Property . 39
135 7.15 The hasInterface and isInterfaceOf Properties . 40
136 7.16 The InformationType Class . 41
137 7.17 The hasInput and isInputAt Properties . 41
138 7.18 The hasOutput and isOutputAt Properties . 42
139 7.19 Examples . 42
140 7.19.1 Interaction Sequencing . 42
141 7.19.2 Car Wash Example . 43
142 8 Composition and its Subclasses . 43
143 8.1 Overview . 43
144 8.2 The Composition Class . 43
145 8.3 The compositionPattern Datatype Property . 44
146 8.3.1 Overview . 44
147 8.3.2 The Orchestration Composition Pattern . 45
148 8.3.3 The Choreography Composition Pattern . 45
149 8.3.4 The Collaboration Composition Pattern . 46
150 8.4 The orchestrates and orchestratedBy Properties . 46
151 8.5 The ServiceComposition Class . 47
152 8.6 The Process Class . 48
153 8.7 Service Composition and Process Examples . 49
154 8.7.1 Simple Service Composition Example . 49
155 8.7.2 Process Example . 50
156 8.7.3 Process and Service Composition Example . 50
157 8.7.4 Car Wash Example . 50
158 9 Policy . 50
159 9.1 Overview . 50
160 9.2 The Policy Class . 50
161 9.3 The appliesTo and isSubjectTo Properties . 51

ISO/IEC FDIS 18384 Part 3
162 9.4 The setsPolicy and isSetBy Properties . 52
163 9.5 Examples . 53
164 9.5.1 Car Wash Example . 53
165 10 Event . 53
166 10.1 Overview . 53
167 10.2 The Event Class . 53
168 10.3 The generates and generatedBy Properties . 54
169 10.4 The respondsTo and respondedToBy Properties . 54
170 Annex A (Informative) Complete Car Wash Example. 56
171 Annex B (Informative) Internet Purchase Example . 63
172 Annex C (Normative) The OWL Definition of the SOA Ontology . 65
173 Annex D (Informative) Class Relationship Matrix. 77
174 Annex E (Informative) Terms Mapping between the SOA RA Parts . 80
175 Bibliography . 93
ISO/IEC FDIS 18384 Part 3
178 Table of Figures
179 Figure 1 ― SOA Ontology – Graphical Overview . 16
180 Figure 2 — The Element Class . 18
181 Figure 3 — The System Class . 20
182 Figure 4 — The represents and representedBy Properties . 22
183 Figure 5 ― The HumanActor Class . 25
184 Figure 6 ― The Task Class . 27
Figure 7 — The Service Class . 30
186 Figure 8 — The ServiceContract Class . 33
187 Figure 9 — The Effect Class . 36
188 Figure 10 — The ServiceInterface Class . 39
189 Figure 11 — The InformationType Class . 41
190 Figure 12 — The Composition Class . 44
191 Figure 13 ― The ServiceComposition Class . 48
192 Figure 14 — The Process Class . 49
193 Figure 15 ― The Policy Class . 51
194 Figure 16 ― The Event Class . 54
195 Figure A.1 ― Car Wash Example – The Organizational Aspect . 57
196 Figure A.2 ― Car Wash Example – The Washing Services . 59
197 Figure A.3 ― Car Wash Example – The Washing Processes . 61
ISO/IEC FDIS 18384 Part 3
200 Foreword
201 ISO (the International Organization for Standardization) is a worldwide federation of national standards
202 bodies (ISO member bodies). The work of preparing International Standards is normally carried out through
203 ISO technical committees. Each member body interested in a subject for which a technical committee has
204 been established has the right to be represented on that committee. International organizations,
205 governmental and knon-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely
206 with the International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
207 International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
208 The main task of technical committees is to prepare International Standards. Draft International Standards
209 adopted by the technical committees are circulated to the member bodies for voting. Publication as an
210 International Standard requires approval by at least 75 % of the member bodies casting a vote.
211 ISO 18384 was prepared by Technical Committee ISO/JTC 1, Subcommittee SC 38, Cloud Computing and
212 Distributed Platforms.
213 ISO/IEC FDIS 18384 consists of three parts, under the general title: Reference Architecture for Service
214 Oriented Architecture
215 ISO/IEC FDIS 18384-1, Information technology – Reference Architecture for Service Oriented Architecture –
216 Part 1: Terminology and Concepts for SOA
217 ISO/IEC FDIS 18384-2, Information technology – Reference Architecture for Service Oriented Architecture –
218 Part 2: Reference Architecture for SOA Solutions
219 ISO/IEC FDIS 18384-3, Information technology – Reference Architecture for Service Oriented Architecture –
220 Part 3: SOA Ontology
221 Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
222 rights. ISO/IEC shall not be held responsible for identifying any or all such patent rights.
ISO/IEC FDIS 18384 Part 3
224 Introduction
225 Service Oriented Architecture (abbreviated SOA) is an architectural style in which business and IT systems
226 are designed in terms of services available at an interface and the outcomes of these services. A service is a
227 logical representation of a set of activities that has specified outcomes and is self-contained, it may be
228 composed of other services but consumers of the service (3.1.20) need not be aware of any internal
229 structure.
230 SOA takes ‘service’ as its basic element to constitute and integrate information systems so that they are
231 suitable for a variety of solution requirements. SOA enables interactions between businesses without needing
232 to specify aspects of any particular business domain. Using the SOA architectural style can improve the
233 efficiency of developing information systems, and integrating and reusing IT resources. In addition, using the
234 SOA architectural style can help enable rapid response of information systems to ever-changing business
235 needs.
236 ISO/IEC 18384 is intended to be a single set of SOA technical principles, specific norms, and standards for
237 the world-wide market to help remove confusion about SOA and improve the standardization and quality of
238 solutions.
239 ISO/IEC 18384 defines the terminology, technical principles, reference architecture and ontology for SOA.
240 ISO/IEC 18384 can be used to introduce SOA concepts, as a guide to the development and management of
241 SOA solutions, as well as be referenced by business and industry standards
242 This ISO/IEC 18384 contains three parts:
243 1. Part 1: Terminology and Concepts – which defines the terminology, basic technical principles and
244 concepts for SOA
245 2. Part 2: Reference Architecture for SOA Solutions – which defines the detailed SOA reference
246 architecture layers, including a metamodel, capabilities, architectural building blocks, as well as types of
247 services in SOA solutions.
248 3. Part 3: SOA Ontology – which defines the core concepts of SOA and their relationships in
249 anOntology.
250 The targeted audience of ISO/IEC 18384 includes, but is not limited to, standards organizations;
251 architects, architecture methodologists, system and software designers, business people, SOA service
252 providers, SOA solution and service developers, and SOA service consumers who are interested in
253 adopting and developing SOA.
254 Users of ISO/IEC 18384 will find it useful to read ISOIEC 18384-1 for an understanding of SOA basics.
255 ISOIEC 18384-1 should be read before reading or applying ISOIEC 18384-2. For those new to the SOA
256 reference architecture, clause 4 in ISOIEC 18384-2 provides a high level understanding of the Reference
257 Architecture for SOA Solutions. The remaining clauses provide comprehensive details of the architectural
258 building blocks and tradeoffs needed for a SOA Solution. This part of this International Standard contains the
259 SOA Ontology, which is a formalism of the core concepts and terminology of SOA, with mappings to both
260 UML and OWL. The SOA Ontology can be used independent of or in conjunction with the other two Parts.
261 The purpose of this part of this International Standard is to contribute to developing and fostering common
262 understanding of Service-Oriented Architecture (SOA) in order to improve alignment between the business
263 and information technology communities, and facilitate SOA adoption.

ISO/IEC FDIS 18384 Part 3
264 The SOA Ontology defines the concepts, terminology, and semantics of SOA in both business and technical
265 terms, in order to:
266 • Create a foundation for further work in domain-specific areas
267 • Enable communications between business and technical people
268 • Enhance the understanding of SOA concepts in the business and technical communities
269 • Provide a means to state problems and opportunities clearly and unambiguously to promote mutual
270 understanding
271 • It may provide a starting point for model-driven development of SOA solutions
273 The content of this part of this International Standard is defined in the following clauses:
274 Forward – abstract for this part
275 Introduction – high level overview of this Part
276 Clause 1 – Scope
277 Clause 2 Normative references
278 Clause 3 – Terminology – defines terms used when discussing or designing Service Oriented Solutions.
279 Terms defined here are used in some unique fashion for SOA. It does not define terms that are used in
280 general English manner.
281 Clause 4 – SOA ontology overview - provides an introduction to the SOA ontology.
282 Clauses 5 through 10 provide the formal definitions (OWL and natural language) of the terms and
283 concepts included in the ontology organized as follows:
284 Clause 5 – System and Element – describes the System and Element concepts
285 Clause 6 – Human Actor and Task – describes the Human Actor and Task concepts
286 Clause 7 – Service, Service Contract, and Service Interface – describes the Service, Service Contract
287 and Service Interface concepts
288 Clause 8 – Composition and its Subclasses– describes the Composition concepts
289 Clause 9 – Policy– describes the Policy concept
290 Clause 10 – Event– describes the Event concept
291 Annex A contains the complete car wash example that is used as a common example throughout.
292 Annex B contains an additional elaborate example utilizing most of the classes in the ontology.
293 Annex C contains the formal OWL definitions of the ontology, collected together.

ISO/IEC FDIS 18384 Part 3
294 Annex D contains a relationship matrix that details the class relationships implied by the OWL definitions
295 of the ontology.
296 Annex E conatins a mapping of the terms from ISO/IEC 18384-1 to the terms and concepts in this part of
297 this International Standard and identifies where the terms are discussed in 18384-2 .
298 Bibliography
ISO/IEC FDIS 18384 Part 3
300 1 Scope
301 This part of this International Standard defines a formal ontology for Service-Oriented Architecture (SOA), an
302 architectural style that supports service orientation. The terms defined in this ontology are key terms from the
303 vocabulary in ISO/IEC 18384-1.
304 2 Normative references
305 The following referenced documents are indispensable for the application of this document. For dated
306 references, only the edition cited applies. For undated references, the latest edition of the referenced
307 document (including any amendments) applies.
308 ISO/IEC 18384 1, Information technology – Reference architecture for SOA – Part 1 Terminology and
309 Concepts for SOA
310 OWL Web Ontology Language Reference, W3C Recommendation, 10 February 2004, World-Wide Web
311 Consortium; available from www.w3.org/TR/owl-ref.
312 ISO/IEC 19505-2:2012, Information technology -- Object Management Group Unified Modeling Language
313 (OMG UML) -- Part 2: Superstructure
314 ISO/IEC TR 24800-1:2007, Information technology – JPSearch – Part 1: System framework and components
315 3 Terms and Definitions
316 3.1 Definitions
317 For the purposes of this document, the terms and definitions given in ISO/IEC 18384-1 and the following
318 apply.
319 3.1.1 Opaque
320 having no internal structure that is visible to an external observer
321 3.1.2 Ontology
322 model that represents a domain and is used to reason about the objects in that domain and the relations
323 between them [SOURCE: ISO/IEC TR 24800-1:2007, 2.1.9]
324 Note 1 to entry: This part of this International Standard is high level and not meant to be used for formal
325 reasoning
ISO/IEC FDIS 18384 Part 3
326 3.2 Acronyms
327 BPMN – Business Process Model and Notation
328 EA – Enterprise Architecture
329 ESB – Enterprise Service Bus
330 IT – Information Technology
331 OWL – Web Ontology Language
332 RA – Reference Architecture
333 RDF – Resource Definition Framework
334 SLA – Service Level Agreement
335 SOA – Service Oriented Architecture
336 UML – Unified Modeling Language
337 3.3 Notations
338 The ontology is represented in the Web Ontology Language (OWL) defined by the World-Wide Web
339 Consortium. OWL has three increasingly expressive sub-languages: OWL-Lite, OWL-DL, and OWL-Full.
340 (See Bibliography [8] for a definition of these three dialects of OWL.) This ontology uses OWL-DL, the sub-
341 language that provides the greatest expressiveness possible while retaining computational completeness and
342 decidability.
343 The ontology contains classes and properties corresponding to the concepts of SOA. The formal OWL
344 definitions are supplemented by natural language descriptions of the concepts, with graphic illustrations of
345 the relations between them, and with examples of their use. For purposes of exposition, the ontology also
346 includes UML (See Bibliography [6]) diagrams that graphically illustrate its classes and properties of the
347 ontology. The natural language and OWL definitions contained in this document constitute the authoritative
348 definition of the ontology; the diagrams are for explanatory purposes only. Some of the natural language
349 terms used to describe the concepts are not formally represented in the ontology; those terms are meant in
350 their natural language sense.
351 The availability of an OWL expression a standard RDF format allows easy loading into tools for architects
352 and developers and allows validation.
353 This document uses examples to illustrate the ontology. One of these, the car-wash example, is used
354 consistently throughout to illustrate the main concepts (See Annex A for the complete example.) Other
355 examples are used ad hoc in individual clauses to illustrate particular points.

ISO/IEC FDIS 18384 Part 3
356 3.4 Conventions
357 Bold font is used for OWL class, property, and instance names where they appear in clause text.
358 Italic strings are used for emphasis and to identify the first instance of a word requiring definition.
359 OWL definitions and syntax are shown in fixed-width font.
360 An unlabeled arrow in the illustrative UML diagrams means subclass.
362 The examples in this document are strictly informative and are for illustrative purposes.
363 3.5 Conformance
364 ISO/IEC 18384 contains three parts which have different conformance requirements:
365 1. Terminology and Concepts – conformance only to terms and adherence to the semantics in the
366 definitions
367 2. Reference Architecture for SOA Solutions – conformance only to semantics of the metamodel and
368 any Layers, ABBs, or capabilities that are used.
369 3. SOA Ontology – conformance for OWL or non-OWL applications
370 Conformance to this part of this International Standard is defined as follows:
371 There are two kinds of applications that may conform to this ontology. One is the OWL-based ontologies
372 (typically extensions of the SOA ontology); the other is a non-OWL application such as a meta-model or a
373 piece of software. (See clause 2 for the OWL version that is required)
374 A conforming OWL application (derived OWL-based ontology):
375 • Shall conform to the OWL standard specified in clause 2
376 • Shall include the whole of the ontology contained in Annex C of this document
377 • May add other OWL constructs, including class and property definitions
378 • May import other ontologies in addition to the SOA ontology
379 Note: this part of this International Standard does not use any OWL 2 (See Bibliography [13]) constructs;
380 however, conforming applications may choose to use OWL or OWL 2.
381 A conforming non-OWL application:
382 • Shall include a defined and consistent transformation (at least semantic mapping) to a non-trivial
383 subset of the ontology contained in Annex C of this document
384 • May add other constructs, including class and property definitions
385 • May import and/or use other ontologies in addition to the SOA ontology

ISO/IEC FDIS 18384 Part 3
386 4 SOA Ontology Overview
387 4.1 At a Glance
388 A graphically compressed visualization of the entire ontology is shown in Figure 1.
389 The concepts illustrated in this figure (Figure 1) are described in the body of this document.
390 This part of this International Standard starts by explaining the most basic foundational concept of Elements
391 and Systems followed by explaining the elements of SOA Human Actor and Task and then Service concepts
392 and descriptions and contracts for services and building on that to explain compositions of services. Finally
393 this document wraps up with Policies and Events which are relavant to all of the elements of SOA.

ISO/IEC FDIS 18384 Part 3
395 Figure 1 ― SOA Ontology – Graphical Overview

ISO/IEC FDIS 18384 Part 3
396 4.2 Intended Use
397 This clause describes caveats and assumptions for how this ontology should be interpreted:
398 • This ontology is intended for high level representation of concepts and is not intended for formal
399 reasoning.
400 • This part of this International Standard is designed for use by business people, architects and
401 systems and software designers to enable communications between business and technical people.
402 • This part of this International Standard a focuses on a minimal set of SOA terms, modeling those
403 terms in detail.
404 • This part of this International Standard explains relationships to other important concepts, but not at
405 the same level of detail as the SOA terms. For example, Policy is modelled, but not in great detail.
406 • This part of this International Standard restricts itself to OWL constructs, not using those introduced
407 in OWL 2 (See Bibliography [13]), because the OWL constructs are sufficient for the scope of this
408 document. It is consistent with OWL 2 and does not preclude others from using it with OWL 2.
409 • This part of this International Standard elaborates on the SOA terms and relationships in ISOIEC
410 18384-1 and ISOIEC 18384-2. A separate metamodel in ISOIEC 18384-2 provides the basis for the
411 modeling in ISOIEC 18384-2 and is used to describe and understand the reference architecture.
412 • This part of this International Standard defines the concepts, terminology, and semantics of SOA in
413 both business and technical terms, in order to create a foundation for further work in domain-specific
414 areas.
415 • This part of this International Standard provides a means to state problems and opportunities clearly
416 and unambiguously to promote mutual understanding.
417 • This part of this International Standard may provide a starting point for model-driven development of
418 SOA solutions.
419 4.3 Applications
420 The SOA Ontology was developed in order to aid understanding and can simply be read.
421 It can also be used as a starting point for model-driven development, by applying it to particular usage
422 domains and applications.
423 The ontology is applied to a particular usage domain by adding SOA OWL class instances of things in that
424 domain. This is sometimes referred to as “populating the ontology.” In addition, an application can add
425 definitions of new classes and properties, can import other ontologies, and can import the ontology OWL
426 representation into other ontologies.
427 The ontology defines the relations between terms, but does not prescribe exactly how they should be applied.
428 For explanations of what ontologies are and why they are needed, see Bibliography [9] and Bibliography [12].
429 The examples provided in this document are describing one way in which the ontology could be applied in
430 practical situations. Different applications of the ontology to the same situations would nevertheless be

ISO/IEC FDIS 18384 Part 3
431 possible. The precise instantiation of the ontology in particular practical situations is a matter for users of the
432 ontology; as long as the concepts and constraints defined by the ontology are correctly applied, the
433 instantiation is valid.
434 5 System and Element
435 5.1 Overiew
436 System and element are two of the concepts of this ontology. Both are concepts that are often used by
437 practitioners, including the notion that systems have elements and that systems can be hierarchically
438 combined (systems of systems). What differs from domain to domain is the specific nature of systems and
439 elements; for instance, an electrical system has very different kinds of elements than an SOA system.
440 In the ontology only elements and systems within the SOA domain are considered. Some SOA sub-domains
441 use the term component rather than the term element. This is not contradictory, as any component of an
442 SOA system is also an element of that (composite) system.
443 This clause describes the following classes of the ontology:
444 Element
445 System
446 In addition, it defines the following properties:
447 uses and usedBy
448 represents and representedBy
449 5.2 The Element Class
450
451
452 An element is an entity that is opaque and indivisible at a given level of abstraction. The element has a
453 clearly defined boundary. The concept of element is captured by the Element OWL class, which is illustrated
454 in Figure 2.
456 Figure 2 — The Element Class

ISO/IEC FDIS 18384 Part 3
457 In the context of the SOA ontology, only functional elements that belong to the SOA domain are considered
458 in detail. There are other kinds of Elements than members of the four named subclasses (System,
459 HumanActor, Task, and Service) described later in this ontology. Examples of such other kinds of Elements
460 are things like software components or technology components (such as Enterprise Service Bus (ESB)
461 implementations, etc.).
462 5.3 The uses and usedBy Properties
463
464 
465 
466
468
469 
470  
471 
472
473 Elements may use other elements in various ways. In general, the notion of some element using another
474 element is applied by practitioners for all of models, executables, and physical objects. What differs from
475 domain to domain is the way in which such use is perceived.
476 An element uses another element if it interacts with it in some fashion. Interacts here is interpreted very
477 broadly ranging through, for example, an element simply being a member of (used by) some system (see
478 later for a formal definition of the System class), an element interacting with (using) another element (such
479 as a service; see later for a formal definition of the Service class) in an ad hoc fashion, or even a strongly
480 coupled dependency in a composition (see later for a formal definition of the Composition class). The uses
481 property, and its inverse usedBy, capture the abstract notion of an element using another. These properties
482 capture not just transient relations. Instantiations of the property can include “uses at this instant”, “has used”,
483 and “may in future use”.
484 For the purposes of this ontology, the multitude of different possible semantics of a uses relationship is not
485 enumerated and formally defined .The semantic interpretations are left to a particular sub-domain, application
486 or even design approach.
487 5.4 Element – Organizational Example
488 Using an organizational example, typical instances of Element are organizational units and people. Whether
489 to perceive a given part of an organization as an organizational unit or as the set of people within that
490 organizational unit is an important choice of abstraction level:
491 Inside the boundary of the organizational unit, as the organizational unit can in fact use the people that are
492 members of it. Note that the same person can in fact be a member of (be used by) multiple organizational
493 units.
494 Outside the boundary the internal structure of an organizational unit must remain opaque to an external
495 observer, as the enterprise wants to be able to change the people within the organizational unit without
496 having to change the definition of the organizational unit itself.

ISO/IEC FDIS 18384 Part 3
497 This simple example expresses that some elements have an internal structure. In fact, from an internal
498 perspective they are an organized collection of other simpler things (captured by the System class defined in
499 5.5).
500 5.5 The System C
...