Child pages
  • Contributions

SupersededByoimt2018.ND.021-TR-512.A.7_OnfCoreIm-Appendix-ControlAndInteractionExamples-CH.docx

<config>
<output path=’ C:\Users\ndavis\git\OnfInfoModelOutput\ ModelDescriptions\TR-512.A.7_OnfCoreIm-Appendix-ControlAndInteractionExamples.docx' />
</config>

<context model=’ C:\Users\ndavis\git\ONFInfoModel\OnfModel\ CoreModel.uml' element=’{0}’ importedBundles='gmf;papyrus' searchMetamodels='true'/>

<gendoc><drop/>

Change path substrings above from “ {path for output files}\ ” to your local path for the output files and “ {path for CoreModel}\ ” to your local path for the Core Model. <drop/>

DELETE: Prior to publishing this –gd.docx (including for review), change path substrings abo ve from “ C:\Users\ndavis\git\OnfInfoModelOutput\ ” to “ {path for output files}\ ” and from “ C:\Users\ndavis\git\ONFInfoModel\OnfModel\ ” to “ {path for CoreModel}\ ” <drop/>

 

SUE Projects:1306 ONF Misc:5-Templates:5-21 MS Word - Spec:links:ONF-horiz-med.tif  

 

 

 

 

 

 

 

 

 

 

SUE Projects:1306 ONF Misc:5-Templates:5-21 MS Word - Spec:links:bottom-shape-cyan.jpg

ONF Document Type: Technical Recommendation

ONF Document Name: Core Information Model version 1.4 Draft
 

Disclaimer

THIS SPECIFICATION IS PROVIDED "AS IS" WITH NO WARRANTIES WHATSOEVER, INCLUDING ANY WARRANTY OF MERCHANTABILITY, NONINFRINGEMENT, FITNESS FOR ANY PARTICULAR PURPOSE, OR ANY WARRANTY OTHERWISE ARISING OUT OF ANY PROPOSAL, SPECIFICATION OR SAMPLE.

Any marks and brands contained herein are the property of their respective owners.

 

Open Networking Foundation
2275 E. Bayshore Road, Suite 103, Palo Alto, CA 94303
www.opennetworking.org

©2018 Open Networking Foundation. All rights reserved.

 

Open Networking Foundation, the ONF symbol, and OpenFlow are registered trademarks of the Open Networking Foundation, in the United States and/or in other countries. All other brands, products, or service names are or may be trademarks or service marks of, and are used to identify, products or services of their respective owners.   

 

Important note

This Technical Recommendations has been approved by the Project TST, but has not been approved by the ONF board.   This Technical Recommendation is an update to a previously released TR specification, but it has been approved under the ONF publishing guidelines for ‘Informational’ publications that allow Project technical steering teams (TSTs) to authorize publication of Informational documents.   The designation of ‘-info’ at the end of the document ID also reflects that the project team (not the ONF board) approved this TR.

 

Finalizing this document once generated… delete this text prior to publication:

-           Replace “{{..}}” with square brackets (which trip up Gendoc)

-           Select text in document from beginning of table of contents (first line) to end of document

  • Click menu item “Update Field” (on this large block of text)
    • if “Update Table…” dialogue appears select “Update entire table”
  • Repeat “update fields” 2 more times (on the same large block of text)
    • if “Update Table…” dialogue appears select “Update entire table”

-           Remove reviewer comment

Note that the table of contents and figures need to be updated several times as the table length changes the page numbering and the cross references will need to be re-updated.


Table of Contents

Disclaimer

Important note

Document History

1 Introduction

1.1 References

1.2 Definitions

1.3 Conventions

1.4 Viewing UML diagrams

1.5 Understanding the figures

1.6 Appendix Overview

2 Introduction to this Appendix document

2.1 Further context

3 Control

3.1 The Basic “Network Element”

3.2 Relationship to ONF Architecture

4 Fragment: Insert class <drop/>

5 Fragment: Insert standard diagram <drop/>

6 Fragment: Insert small diagram <drop/>

7 Fragment: Insert attribute row brief not Obsolete<drop/>

8 Fragment: Insert attribute row brief <drop/>

9 Fragment: Start attribute table brief <drop/>

10 Fragment: Insert Attribute table brief <drop/>

11 Fragment: Insert Ten Specified Attribute table brief <drop/>

12 Fragment: Insert DataType <drop/>

13 Fragment: Start Data Type attribute table brief <drop/>

14 Fragment: Insert Data Type Attribute table brief <drop/>

15 Fragment: Insert enums <drop/>

15.1.1.1 [dt.name/]

List of Figures

Figure 1-1 Methodology of IM and DS Development

Document History

Version

Date

Description of Change

 

 

Appendix material was not published prior to Version 1.4

1.4

July 2018

Version 1.4

 


1        Introduction [A1]

This document is an appendix of the addendum to the TR-512 ONF Core Information Model and forms part of the description of the ONF-CIM. For general overview material and references to the other parts refer to TR-512.1 .

1.1      References

For a full list of references see TR-512.1 .

1.2      Definitions

For a full list of definition see TR-512.1 .

1.3      Conventions

See TR-512.1 for an explanation of:

  • UML conventions
  • Lifecycle Stereotypes
  • Diagram symbol set

1.4      Viewing UML diagrams

Some of the UML diagrams are very dense. To view them either zoom (sometimes to 400%) or open the associated image file (and zoom appropriately) or open the corresponding UML diagram via Papyrus (for each figure with a UML diagram the UML model diagram name is provided under the figure or within the figure).

1.5      Understanding the figures

Figures showing fragments of the model using standard UML symbols and also figures illustrating application of the model are provided throughout this document. Many of the application-oriented figures also provide UML class diagrams for the corresponding model fragments (see TR-512.1 for diagram symbol sets). All UML diagrams depict a subset of the relationships between the classes, such as inheritance (i.e. specialization), association relationships (such as aggregation and composition), and conditional features or capabilities. Some UML diagrams also show further details of the individual classes, such as their attributes and the data types used by the attributes.

1.6      Appendix Overview

This document is part of the Appendix to TR-512. An overview of the Appendix is provided in TR-512.A.1 .

2        Introduction to this Appendix document [DN2]

This document provides various examples of the use of the CIM to model control and interaction between control systems.

The examples in this document are built from descriptions in other documents. The examples are supported by a combination of … (as described in ), …..

2.1      Further context [DN3]


3        Control

The   model required to support Control discussed in . is shown in the figure below. The figure highlights the key focus of the examples in this document.

Ad mode figure with overlay highlighting coverage.

In .8 there are several discussions on the rationale for… The examples highlight how these cases are covered starting with a basic NE.

This document uses a simple self-explanatory symbol set.

During the work to break apart the n etwork   e lement concept, the logical network functions were split off into ProcessingConstruct and ConstraintDomain. What was left was the n etwork e lement   control function.

The two things that we needed to represent for control were:

  • The (logical) location of control functions in the network and how they were related ( control network )
  • The scope of network functions that each control function was controlling

 

The decision was made to create a separate control function class ControlConstruct and reuse the ConstraintDomain class for the control scope representation. Reusing ControlConstruct simplified the resulting model (otherwise we would have had to duplicate a lot of associations).

It then became apparent that this general model could also be used to model SDN controllers, giving a consistent view of the different elements in the control network .

In the text below we will start with the device and work our way up the control network.


The Basic “Network Element”

On the left of the figure below is the representation of a simple ‘device’ as defined   in the ProcessingConstruct document.   Note, to keep the diagrams simple, we are using PC to represent all of the functions PC, LTP, FC, FD, SoftwareProcess …

ConstraintDomain (CD) is used to group the network functions and also may constra in them in various ways.

On the right of the figure below a   ControlConstruct has been added and another ConstraintDomain to represent the scope of control (control domain). The ControlConstruct and ConstraintDomain are related by an association in the model.  

3.1       

Figure 3 1


The next step is to be able to show a control network. ControlConstruct has ports (using the component-port pattern) and the ports can be bound together to show the logical binding. An attribute in ControlConstructPort is used to show the type of relationship, master-slave or peer-peer. Also because ControlConstructPort is associated to LTP, it can be related to any transport functions of interest.

The control function layering is achieved by having a ControlConstruct inside of a ConstraintDomain that is controlled by another ControlConstruct.

Note that it doesn’t make sense to have control loops or ControlConstructs controlling themselves. This is not represented in the model and would be enforced by the constraints attached to the ConstraintDomains.

Note, to keep the diagrams simple, we are using PC to represent all of the functions PC, LTP, FC, FD, SoftwareProcess …

Figure 3 2 - Basic ControlConstruct layering Use Case

The instance diagram below shows how the example above can be represented in the model

Figure 3 3 - Basic Use Case

It is possible to add control ports to every network function and then bind these to the control construct ports.

This may make sense architecturally and provides a nice consistency, but:

  • Locally within a NE, the binding is usually implied rather than explicitly defined and managed (I define a BGP process via the control construct so its binding is implicit)
  • It adds a lot of complexity to the instance graph, to create and manage all these ports and bindings
  • Since we expect some sort of local management agent, the bindings are local, so there are no transport (via FC ) implications

So it is recommended not to instantiate the control port bindings within a device, but to just rely on the implied binding from the ControlConstruct to the ConstraintDomain that it is controlling.

 

Figure 3 4 - control port to PC port binding

 

Having shown how a simple device can be represented, we will now turn our attention to some of the other common, but more complex, cases.

 


A common case is where a physical device can be partitioned into more than one logical device. This may be done in a number of ways, with varying degrees of partition autonomy. Note that there may only be one physical management agent, but it is likely that each partition will appear to have its own logical management function.

Figure 3 5 - Device Partitions

There is no need to change the model for this case, all that is needed is to create the required ControlConstructs and ConstraintDomains and to relate them.

Figure 3 6 - Device Partitions


Another common option is where many physical devices may be aggregated to behave like a single logical device. There may be a number of variants on this and two of these are explored below.

In this example, we will consider a single logical device where each physical device is managed separately.

Figure 3 7 - Distributed Device – Separate MA

Again, the same model represents this case. Note that there may be distributed ProcessingConstructs that cross the physical device boundaries.

 

Figure 3 8 - Distributed Device – Separate MA

 

In the single management agent option the main difference is that there is only one management access point and the remote chassis ControlConstructs are slaved from the master chassis ControlConstruct.

 

Figure 3 9 - Distributed Device – Single MA

 

Again, we see how the general model elements can be arranged to support this option too.

Figure 3 10 - Distributed Device – Single MA

 

The last option, which does occur in real life, shows the versatility of this approach, without having to resort to odd workarounds. In effect it is a hybrid of the partitioned chassis and the distributed device cases that were covered earlier.

Figure 3 11 - Distributed Device – Split Chassis

 

Figure 3 12 - Distributed Device – Split Chassis

In this section we covered a number of common cases of different network device management and control options.

The model is not limited to supporting just these cases, but it is not practicable to try and cover every possible case.

By covering the general partitioning and aggregation cases, it should be easy to determine a suitable representation for other cases.

Note also that we haven’t covered ‘virtualization’ here, but the same principles apply.

For an example of ControlConstruct controlling software, refer TR-512.A.13 Appendix – Software Examples “Section 3.7               Constraint Domain Example”. [ch4]


The SDN Controller

The ONF architecture document XXX [ch5] suggested a controller structure as shown below.

 

Figure 3 13 – ONF Controller Architecture

For the model, we will drop the concept of ResourceGroup, but this can be added back as a type of ConstraintDomain if really required.

The model doesn’t constrain how a controller can be built up, and we will explore a few possible options below.

In all cases ConstraintDomain will be used to represent LocalContext, ClientContext, ServerContext and the more general PeerContext.

We will also assume that a ControlConstruct can control many other ControlConstructs, with a dedicated port at each end.

We will also assume that a ControlConstruct can peer with many other ControlConstructs, with a dedicated port at each end.

We will also assume that a ControlConstruct can only be controlled by a single other ControlConstruct (ignoring high availability for now).


A controller:

  • May transport / route / switch other devices’ control / management messages (packets)
  • Is different from the router / switch / transport data plane because it also produces and consumes (control / management) messages ( making it a semantic content endpoint like a CPE / host)
  • The control / management messages from network devices become the controllers data plane messages (relative concept = roles !)
  • Control of the controller is done via its ControlConstruct and the controller would consider these to be control / management messages

 


The first option is one ControlConstruct per controller, plus one per client and server context (total of 1+C+S Control Constructs).

Note that we are assuming that every server context ControlConstruct is controlled by the remote server client ControlConstruct. Therefore the local master ControlConstruct will need to peer (negotiate) with every ControlConstruct in the server contexts.

 

Figure 3 14 - Mapping to ControlConstruct & CD


In the option below, the ClientContexts and ServerContexts have been merged into a PeerContext, so there is only one context per peer, irrespective of if it is a client, server or peer.

Client and Server context assumes a static relationship, where it is more likely that the client and server roles are per request.

 

Figure 3 15 - Mapping to ControlConstruct & CD – Peer Option

 


While ControlDomains are lightweight and will scale to large numbers, ControlConstructs are likely to be heavyweight and unlikely to scale well.

Therefore we will look to see if we can reduce the number of ControlConstructs.

The basic options seem to be:

  • One ControlConstruct per controller, plus one per client and server context (1+C+S)
  • One ControlConstruct per controller, plus a client context one and a server context one (3)
  • One ControlConstruct per controller (1)

 

The first option has already been covered, so now we will investigate the other two.


Having a single ControlConstruct for all client contexts and a single ControlConstruct for all server contexts reduces the number of ControlConstructs. It also allows for each ControlConstruct to focus on a particular task. It is unclear if there is any security (or any other) advantage in separating these functions.

Figure 3 16 - Mapping to ControlConstruct & CD – Peer Option – shared Client & Server CtrlC (3)


 

The simplest option is to only have a single ControlConstruct per controller.

Then a ConstraintDomain can be created for every peer device. Further ConstraintDomains can be created for a server context and client context within each peer context if required.

 

 

Figure 3 17


 

Earlier we discussed using peer control relationships instead of master-slave relationships. Rather than having a hierarchy formed of individual controllers, it seems to make more sense to form controllers into layers.

The controllers would have peer control relationships within a layer and use master-slave control relationships between layers. The controllers would also have a master-slave relationship with the network devices that they are controlling.

For high availability needs, controllers could be pooled (using ConstraintDomains to represent the pool groupings).

 

The control architecture:

  • Should allow, but not impose a hierarchy on the control structure
  • Should support peering of controller and controller groups, rather than requiring a ‘super-controller’ to be added, allowing :
    • Enterprise peering between regions
    • peering between Service Providers

 

The following two diagrams show how this could be applied.


 

 

Figure 3 18 - The High Level Architecture should allow a mix of Master-Slave and Peering

 

Figure 3 19 - And this can be applied recursively

 


Even though we have progressed a long way from the initial ONF architectural concepts, we are still assuming a relatively static architecture with relatively static allocations via the client and server contexts.

More work needs to be done to look at supporting more dynamic requirements.

For example ExposureSession could be used to create ‘dynamic client and server contexts’. These would be created on request from another controller and when no longer needed would be torn down and the resources (PC, LTP …) returned to the local pool.

 

Figure 3 20 - Exposure Session allows a ControlConstruct to expose network functions to another ControlConstruct

 

It is likely that a controller would use both strategies:

  • client and server contexts for static allocations
  • ExposureSessions for dynamic requests

3.2      Relationship to ONF Architecture  

The ONF architecture specified in xxx [DN6] emphasizes a hierarchy. The model… enables bot hierarchy and peer with a symmetric treatment of the basic ControlConstructPort and the opportunity to take provider and user roles together…

<Show architecture figure and then Chris’ modified figure>

Figure 3 24


3.3      ERPS G.8032

One last example that is worth considering is that a ControlConstruct may control a ‘network’.

Consider ERPS G.8032 (hereafter just called ERPS).

Each Ethernet switch may be performing other normal switching functions as well as an ERPS node function. A ControlConstruct can be created for every ERPS node that receives and processes control information from other nodes.

Figure 3 21 - ERP G.8032 Concept Example

We could also consider that this distributed control also creates a logical network level ControlConstruct. Once again, the building block nature of the model also allows for this case to be represented in a sensible manner.

Figure 3 22 - ERP Network Example 1

 

 

End of Document


 

</gendoc><drop/>

To take latest template: <drop/>

  • delete text from “ Template version… ” to end of file <drop/>
  • insert a line in “Normal” style<drop/>
  • insert text (Insert Object Text from File… (alt njf)) from: <drop/>
    • TR-512.GT_OnfCoreIm-CommonGendocTemplate-Fragments.docx <drop/>

Template version 0.0.10 17 September 2017 <drop/>

<fragment name=’ insertClass ’ importedBundles=’commons;gmf;papyrus’><drop/>
<arg name=’ cl ’ type=’uml::Class’/><drop/>
<arg name=’ className ’ type=’String’/><drop/>
<arg name=’ packageName ’ type=’String’/><drop/>
[if (not cl.qualifiedName.contains(packageName))]<drop/>
[else] <drop/>
[if(cl.name.contains(className))]<drop/>

Qualified Name: [cl.qualifiedName/]

[for (co:Comment | cl.ownedComment)]<drop/>

<dropEmpty> [cleanAndFormat(co._body.clean())/] </dropEmpty>

[/for]<drop/>
[if (cl.isAbstract)]<drop/>

This class is abstract.

[/if]<drop/>

[if ( cl.oclAsType(uml::Class).general ->notEmpty())]<drop/>

 

Inherits properties from:

[for (gen:Class | cl.oclAsType(uml::Class).general)]<drop/>

  • [gen.name/]

[/for]<drop/>

[/if]<drop/>

[for (st:Stereotype | cl.getAppliedStereotypes())]<drop/>
[if(not st.name.contains(‘OpenModelClass’))]<drop/>

This class is [st.name/].

[else] <drop/>
[/if]<drop/>
[/for]<drop/>
[else] <drop/>
[/if]
[/if]
</fragment><drop/>

<fragment name=’ insertStandardDiagram ’ importedBundles=’commons;gmf;papyrus’><drop/>
<arg name=’ p ’ type=’uml::Package’/><drop/>
<arg name=’ diagramName ’ type=’String’/><drop/>
<arg name=’ diagramTitle ’ type=’String’/><drop/>

[for (d:Diagram|p.getPapyrusDiagrams())]<drop/>

[if d.name.contains(diagramName)]

<drop/>

<image object='[d.getDiagram()/]' maxW='true' keepH='false' keepW = ‘false’> </image>

CoreModel diagram: [d.name/]

Figure 5 1 [diagramTitle/]

[else]<drop/>

[/if]<drop/>

[/for]<drop/>
</fragment ><drop/>

 

<fragment name=’ insertSmallDiagram ’ importedBundles=’commons;gmf;papyrus’><drop/>
<arg name=’ p ’ type=’uml::Package’/><drop/>
<arg name=’ diagramName ’ type=’String’/><drop/>
<arg name=’ diagramTitle ’ type=’String’/><drop/>

[for (d:Diagram|p.getPapyrusDiagrams())]<drop/>

[if d.name.contains(diagramName)]

<drop/>

<image object='[d.getDiagram()/]' maxW='true' keepH='false' keepW = ‘false’> </image>

CoreModel diagram: [d.name/]

Figure 6 1 [diagramTitle/]

[else]<drop/>

[/if]<drop/>

[/for]<drop/>
</fragment ><drop/>

<fragment name=’ insertAttributeRowBriefNotObsolete ’ importedBundles=’commons;gmf;papyrus’><drop/>

Does not work unless we have Mature stereotype… <drop/>
<arg name=’ p ’ type=’uml::Property’/><drop/>

[for (st:Stereotype | p.getAppliedStereotypes())]<drop/>

[if(not st.name.contains(‘OpenModelAttribute’))]

[if(not st.name.contains(‘Obsolete’))]

[p.name/]

[for (st:Stereotype | p.getAppliedStereotypes())]<drop/>

[if(not st.name.contains(‘OpenModelAttribute’))] [st.name/]

[ /if]<drop/>

[/for]<drop/>

 

Do NOT remove the previous line as word throws an error if the cell is empty <drop/>

[if  p.ownedComment->notEmpty()]<drop/>

[for (c:Comment | p.ownedComment)] <drop/>

[cleanAndFormat(c._body.clean())/]

[/for]

[else] [if (p.name.contains (‘_’))] See referenced class

[else] To be provided

[/if]<drop/>

[/if]<drop/>

 

Do NOT remove the previous line as word throws an error if the cell is empty <drop/>

[/if]<drop/>

[/if]<drop/>

[/for]<drop/>
</fragment><drop/>

<fragment name=’ insertAttributeRowBrief ’ importedBundles=’commons;gmf;papyrus’><drop/>
<arg name=’ p ’ type=’uml::Property’/><drop/>

[p.name/]

[for (st:Stereotype | p.getAppliedStereotypes())]<drop/>

[if(not st.name.contains(‘OpenModelAttribute’))] [st.name/]

[ /if]<drop/>

[/for]<drop/>

 

Do NOT remove the previous line as word throws an error if the cell is empty <drop/>

[if  p.ownedComment->notEmpty()]<drop/>

[for (c:Comment | p.ownedComment)] <drop/>

[cleanAndFormat(c._body.clean())/]

[/for]

[else] [if (p.name.contains (‘_’))] See referenced class

[else] To be provided

[/if]<drop/>

[/if]<drop/>

 

Do NOT remove the previous line as word throws an error if the cell is empty <drop/>

</fragment><drop/>

<fragment name=’ insertAttributeTableHeader ’ importedBundles=’commons;gmf;papyrus’><drop/>
<arg name=’ cl ’ type=’uml::Class’/><drop/>

Attribute Name

Lifecycle Stereotype (empty = Mature)

Description

</fragment><drop/>

<fragment name=’ insertAttributeTableBrief ’ importedBundles=’commons;gmf;papyrus’ importedFragments=' insert AttributeTableHeader; insert AttributeRowBrief ’><drop/>
<arg name=’ cl ’ type=’uml::Class’/><drop/>
[if  cl.ownedAttribute->notEmpty()]<drop/>

Table 1 : Attributes for [cl.name/]

<table><drop/>

[cl. insert AttributeTableHeader ()/]

[for (p:Property|cl.ownedAttribute)]<drop/>

[if (not p.name.contains(‘_’))]<drop/>

[p. insert AttributeRowBrief ()/]

[/if]<drop/>

[/for]<drop/>

[for (p:Property|cl.ownedAttribute)]<drop/>

[if (p.name.contains(‘_’))]<drop/>

[p. insert AttributeRowBrief ()/]

[/if]<drop/>

[/for]<drop/>

</table><drop/>

[/if]<drop/>

</fragment><drop/>

<fragment name=’ insertTenSpecifiedAttributeTableBrief ’ importedBundles=’commons;gmf;papyrus’ importedFragments=' insert AttributeTableHeader; insert AttributeRowBrief ’><drop/>
<arg name=’ cl ’ type=’uml::Class’/><drop/>

<arg name=’ p1 ’ type=‘String’/><drop/>

<arg name=’ p2 ’ type=‘String’/><drop/>
<arg name=’ p3 ’ type=‘String’/><drop/>
<arg name=’ p4 ’ type=‘String’/><drop/>
<arg name=’ p5 ’ type=‘String’/><drop/>
<arg name=’ p6 ’ type=‘String’/><drop/>
<arg name=’ p7 ’ type=‘String’/><drop/>
<arg name=’ p8 ’ type=‘String’/><drop/>
<arg name=’ p9 ’ type=‘String’/><drop/>
<arg name=’ p10 ’ type=‘String’/><drop/>
[if  cl.ownedAttribute->notEmpty()]<drop/>

Table 1 : Attributes for [cl.name/]

<table><drop/>

[cl. insert AttributeTableHeader ()/]

[for (p:Property|cl.ownedAttribute)]<drop/>

[if  (p.name.contains( p1 ) or p.name.contains( p2 ) or p.name.contains( p3 ) or p.name.contains( p4 ) or p.name.contains( p5 ) or p.name.contains( p6 ) or p.name.contains( p7 ) or p.name.contains( p8 ) or p.name.contains( p9 ) or p.name.contains( p10 ))]<drop/>

[if (not p.name.contains(‘_’))]<drop/>

[p. insert AttributeRowBrief ()/]

[/if]<drop/>

[/if]<drop/>

[if  (p.name.contains( p1 ) or p.name.contains( p2 ) or p.name.contains( p3 ) or p.name.contains( p4 ) or p.name.contains( p5 ) or p.name.contains( p6 ) or p.name.contains( p7 ) or p.name.contains( p8 ) or p.name.contains( p9 ) or p.name.contains( p10 ))]<drop/>

[if (p.name.contains(‘_’))]<drop/>

[p. insert AttributeRowBrief ()/]

[/if]<drop/>

[/if]<drop/>

[/for]<drop/>

</table><drop/>

[/if]<drop/>

</fragment><drop/>

<fragment name=’ insertDataType ’ importedBundles=’commons;gmf;papyrus’><drop/>
<arg name=’ dt ’ type=’uml::DataType’/><drop/>
<arg name=’ dataTypeName ’ type=’String’/><drop/>
<arg name=’ packageName ’ type=’String’/><drop/>
[if (dt.qualifiedName.contains(packageName))]<drop/>
[if(dt.name.contains(dataTypeName))]<drop/>

Qualified Name: [dt.qualifiedName/]

[for (co:Comment | dt.ownedComment)]<drop/>

<dropEmpty> [cleanAndFormat(co._body.clean())/] </dropEmpty>

[/for]<drop/>
[if ( dt.oclAsType(uml::DataType).general ->notEmpty())]<drop/>

 

Inherits properties from:

[for (tp:DataType | dt.oclAsType(uml::DataType).general)]<drop/>

  • [tp.name/]

[/for]<drop/>

[for (gen:Class | dt.oclAsType(uml::DataType).general)]<drop/>

  • [gen.name/]

[/for]<drop/>

[/if]<drop/>

 

[for (st:Stereotype | dt.getAppliedStereotypes())]<drop/>
This class is [st.name/].

[/for]<drop/>
[else] <drop/>
[/if]
[/if]
</fragment><drop/>

<fragment name=’ insertDataTypeAttributeTableHeader ’ importedBundles=’commons;gmf;papyrus’><drop/>
<arg name=’ dt ’ type=’uml::DataType’/><drop/>

Attribute Name

Lifecycle Stereotype (empty = Mature)

Description

</fragment><drop/>

<fragment name=’ insertDataTypeAttributeTableBrief ’ importedBundles=’commons;gmf;papyrus’ importedFragments=' insertDataType AttributeTableHeader; insertA ttributeRowBrief ’><drop/>
<arg name=’ dt ’ type=’uml::DataType’/><drop/>
[if  dt.ownedAttribute->notEmpty()]<drop/>

Table 1 : Attributes for [dt.name/]

<table><drop/>

[dt. insertDataType AttributeTableHeader ()/]

[for (p:Property|dt.ownedAttribute)]<drop/>

[p. insert AttributeRowBrief ()/]

[/for]<drop/>

</table><drop/>

[/if]<drop/>

</fragment><drop/>

 

<fragment name=’ insertEnums ’ importedBundles=’commons;gmf;papyrus’><drop/>
<arg name=’ dt ’ type=’uml::DataType’/><drop/>

15.1.1.1                   [dt.name/]

Qualified Name: [dt.qualifiedName/]

[for (co:Comment | dt.ownedComment)]<drop/>

<dropEmpty> [cleanAndFormat(co._body.clean())/] </dropEmpty>

[/for]<drop/>

 

Applied stereotypes:

[if dt.getAppliedStereotypes()->notEmpty()] <drop/>

[for (st:Stereotype | dt.getAppliedStereotypes())]<drop/>

  • [st.name/]

[/for]<drop/>

[else] No stereotypes applied

[/if]<drop/>

[if ( dt.oclAsType(uml::DataType).general ->notEmpty())]<drop/>

 

Inherits literals from:

[for (tp:DataType | dt.oclAsType(uml::DataType).general)]<drop/>

  • [tp.name/]

[/for]

[/if]<drop/>

[if ( dt.oclAsType(Enumeration).ownedLiteral->notEmpty())]<drop/>

 

Contains Enumeration Literals:

[for (e:EnumerationLiteral|dt.oclAsType(Enumeration).ownedLiteral)]<drop/>

  • [e.name/]:
    • [for (co:Comment | e.ownedComment)]<drop/>
    • <dropEmpty> [cleanAndFormat(co._body.clean())/]
    • </dropEmpty>[/for]<drop/>
    • [if dt.getAppliedStereotypes()->notEmpty()] <drop/>
    • Applied stereotypes:
      • [for (st:Stereotype | e.getAppliedStereotypes())]<drop/>
      • [st.name/]
      • [/for]<drop/>
    • [/if]<drop/>

[/for]<drop/>

[/if]<drop/>

</fragment><drop/>

 

 


[A1] To the reviewer

-           Hypertext document references “TR-512…” will not work at this point (as they reference the .pdf files that have not yet been generated).

-           There are some comments in some documents please consider the comments as you review.

-           If you have proposals to change text (typos or small rewordings for grammar errors), please modify the text with change tracking enabled.

-           If you have major concerns or questions or general comments please use word comments (like this)

 

This is a new document.

 

[DN2] Add a black box device and strand view to the intro and explain the flow of the document against that.

[DN3] To be added

[ch4] Nigel- add reference

[ch5] Nigel, add reference

[DN6] Add reference