The way this multiplicity is described on the model does not allow references the same domain concept os different ViewComponents. This way the domain concept on the instances can be referenced only once. The same should be corrected on the diagram 8.18 on page 27.
The validation to guarantee that, for example, two databindings in the same ViewComponent cannot reference the same domain concept should be implemented with other concept than multiplicity.
So dataBinding [0..1]: DataBinding - Reference to the DataBinding in a ViewComponent that uses thecurrent DomainConcept.
Should be replaced by
dataBinding [0..*]: DataBinding - One DomainConcept can be referenced by many databindings. But one Databinding in a ViewComponent should reference only one current DomainConcept.

Dear OMG colleagues,

I am currently reading about IFML Metamodel for my graduate thesis about Web Code Generator using IFML. I am reading about his particular notation (Events) but I'm having a hardtime reading the metamodel because :

1. The text isn't clear
2. Some of class diagram notation isn't clear enough.

To avoid a misinterpretation, I am hoping that you can give a clarification or a new Metamodel Diagram Image for me so that I can interpret it clearly.

Thank you for your attention,

Best Regards,
Hafiyyan Sayyid Fadhlillah,

Post-graduate Student,
Faculty of Computer Science Universitas Indonesia

The content model (aka Domain Model) should reference a generic modeling element (e.g., DomainElement), so as to enable any kind of domain model to be used with IFML.
UML element can be associated to it.
DomainElement should be extensible.

Created new class in IFML Metamodel: DomainElement. All the classes describing the domain elements (DomainConcept, FeatureConcept, BehavioralFeatureConcept, BehaviorConcept) now extend the DomainElement class, instead of NamedElement. Association from DomainModel is to DomainElements and not to UML::Element.
Fixed Figure 5 by adding the new DomainElement class and its 4 subclasses.
Added new clause describing the DomainElement. Fixed generalization text in the 4 subclasses.

Update definition of diagrams by adding the new concepts and fixing the updated ones.

Replace:
"actionExpression:" --> "activationExpression:"

In listing of 10.6 remove rules for [modal] and [modeless], and for [clientSide]; Fix radius of the event element to static value. Add port and throwing events

No Data Available

reference to the context in the descriptive text to be removed.
Replace a "." with a "," in first sentence.
In the metamodel, remove the association with Parameter [0..1].

Text fixed as requested and as reported below. Metamodel fixed by removing association with Parameter

iagram in Fig. 3 is wrongly repeating the Albums containers twice. It should appear only once, and the arrow should go back to it after exiting from the Action.

Figure fixed as requested

(8.4.4) submitEvent [0..1]: SubmitEvent - Event that triggers a navigation, which passes the Field's values as Parameters to the target InteractionFlowElement. --> revise text. multiplicity is max N

submitEvent association completely removed, to address issue 19160. No change needed for this issue.
Disposition: Closed, no change

Replace: Order in which the ValidationRules are going to be applied to the Fields of the ViewComponent. with correct description (8.4.4)

Disposition: See issue 19158 for disposition

Change content-model in domain-model
rename in domain-model

ContentModel has been renamed as DomainModel throughout the whole specification document and machine-readable files.
Content Model has been replaced with Domain Model (matching the needed case) throughout the whole specification document.

"ContentBinding is specialized in two concepts, DataBinding and DynamicBehavior. A DataBinding references a UML Classifier that may represent an object, an XML file, a table in a database etc. A *ContentAccess* is associated with a ConditionalExpression, which determines the specific content to be obtained from the content source. A DynamicBehavior represents a content access such as a service or method that returns content after an invocation, as represented by a UMLBehavioralFeature for representing it." (8.1.8)

*ContentAccess* – replace with DataBinding

Disposition: See issue 18936 for disposition

In ConditionalExpression (8.3.6): rewrite the following: When a ConditionalExpression has an incoming NavigationFlow it means that the DataBinding is queried with the query expression represented by the ConditionalExpression for retrieving content.

The wording of the description has been changed as follows

viewelementevent can be associated with 0..1 viewelements.

should be 1

ViewElementEvent can be associated with 1 ViewElement. Metamodel and textual descriptions updated accordingly.

Conditional expression can have outgoing flow. Correct? The text says it only supports incoming flows. Constraint missing?

A conditional expression should not have an outgoing flow. The issue is closed
Disposition: Closed, no change

ViewComponentPart: association with interactionflow is missing. Correct?

It’s correct. ViewComponentPart inherits the association from InteractionFlowElement. No action needed.
Disposition: Closed, no change

"• isLandmark: Boolean - If true, the ViewContainer is directly reachable from any ViewElement. It represents an implicit link between all the other ViewElements and the ViewContainer."[8.3.34]

– > replace: from any ViewElement contained, directly or indirectly, in the same ViewContainer

proposed text change applied

Description of some association ends is missing and not listed

all the lists of association ends, attributes and ocl constraints have been checked. Missing elements added throughout the spec. Association ends names have been set to plural (adding “s”) when maximum multiplicity is bigger than 1.
Fixes applied throughout the specification and the metamodel

system event: chech difference between activation expression, triggering expression, interactionflow expression

The three concepts have different meaning. No action required in the specification.
Disposition: Closed, no change

viewelementevent cannot be associated with viewcomponentpart, is it correct?

The association ViewComponentPart – ViewElementEvent already exists. However, it is not shown in any high level metamodel picture. Now added in Figure 10. Events.

"triggeringExpression [1..*]: Expression - Expressions that determines when or under what conditions the SystemEvent should be triggered." (8.3.31)

should be 0..*

Multiplicity of association fixed.

parameterBinding [0..*]: ParameterBinding - The ParameterBindings composing the ParameterBindingGroup.(8.3.29)

should be 1..*

Multiplicity of association (and plural name of association) fixed.

In these sentences (9.3): ʺIf the computation semantics of the ViewContainer is without history, default contexts are considered in point 3. if the computation semantics is with context history, components may draw their input values either from default contexts or from the past context existing prior to the last flow navigation.ʺ

history and default context are not defined. Simplify this part.

Disposition: See issue 16162 for disposition

Fig. 53 and all others that include a XOR: add a ʺ...ʺ for showing that there are more elements in the xor

Figures have been fixed by adding “…”

Context: context variables are pointers to the corresponding element in the data model.

Added ContextVariable, SimpleContextVariable, and DataContextVariable metaclasses and respective descriptions.

Add SetContext event

SetContextEvent added for describing the happening of the setting of a ContextVariable value.

An event can have at most one incoming and one outgoing flow

Ocl constraint added to the Event metaclass

Define that dangling actions by default return back to the container containing the starting component (in Action sections)

Added appropriate text in description of Class Action. Removed ActionEventType from SystemEventType

Outgoing flows from actionevents can only end in viewcomponents o viewcontainers

No Data Available

Rename submit and select events
Call them OnSubmit and OnSelect

SubmitEvent and SelectEvent have been renamed as OnSubmitEvent and OnSelectEvent. Names have been replaced in the metamodel and in the text.

The supported content model is only UML. This should be generalized to any content model, and UML should be left as an example

Added classes to the metamodel: FeatureConcept and DomainConcept, UMLStructuralFeature and UMLDomainConcept, BehavioralFeatureConcept and BehaviorConcept, UMLBehavioralFeature and UMLBehavior.
Content can now be referenced through the FeatureConcept and DomainConcept classes. Behavior can now be referenced through the BehavioralFeatureConcept and BehaviorConcept classes. UML becomes one specific case of binding.

Add Default value to input parameters. It can be an OCL expression?

new attribute defaultValue (of type IFML::Core::Expressoin) added to Parameter

Extensibility of the language should be made more explicit. The set of extensible concepts should be listed.

No Data Available

Some view components in example images appear outside the containers (figs. 40, 43, 58). Add containers to avoid misunderstandings.

Containers added to all images when needed

Actions must have a Name property. They must also appear in the UML Profile.

Action now is now also a specialization of a NamedElement.
Action added in the UML Profile

Modules should include a reference to a BPMN Activity (optional) to represent the fact that a module could implement a business activity.

ModuleDefinition (not Module) now contains a reference to a BPMN Activity

The Module concept is missing in the UML profile.

Module has been added in the UML profile. Corresponding text fixed.

Min cardinality of relation Module--Port must be 0: a Module may have 0 Ports.

fixed minimum cardinality for associations in the metamodel, both for Module/Port and ModuleDefinition/PortDefinition and text updated. Constraint onlyOnePortPerPortDefinition added for describing relation between Ports and PortDefinitions.

Events should be subtyped by two specializations: throwing event and catching event, which allows explicit understanding of the role of the event. Corresponding icons should be designed (e.g., one negative and one positive, as in BPMN).

added CatchingEvent and ThrowingEvent. Hierarchy of events restructured accordingly. Added the text clauses describing the new events. Event description has been modified as from below.

The symbol of the submit event should be changed from simple big rightwards arrow ( ➡ ) to an arrow similar to the Return button in keyboards (↵ )

The symbol of the event has been changed and all the figures where it was used updated accordingly.

the property "kind" of Parameter must be renamed as Direction.

Direction of parameter is described as one of:

direction ::= 'in' | 'out' | 'inout'

and defaults to 'in' if omitted.

Property kind changed to direction. ParameterKind enumeration changed to Direction. Direction values fixed as requested. Text in Clauses 8.1.5, 8.2.1 and 8.3.27 has been fixed.

In page 26, section 7.1.8, DataAccess (old term) must be replaced with DataBinding

typo fixed. ContentAccess replaced with DataBinding in clause 8.1.8

The description of Form class in section 8.4.4 is wrong (it is actually a definition of another class). Replace with correct definition.

Fixed description of Form Class in Section 8.4.4

The class field must have an association with parameter, to allow input and output of values from the field when it has no slots.

Instead of defining an association between Field and Parameter, the class Field has been defined as extension of Parameter. In this way, a Field automatically acts as a parameter.

A misplaced image appears at the bottom of page 81 of the PDF version of the spec. Remove

This was a problem in the generation of the PDF. The image has been anchored in the right position in the document, so misplacement disappears when the PDF is generated in the new version of the spec.

Description of examples in pages 82-91 sometimes still mention the component MessageReader, while the correct label is Message Details.

(also be sure to set all the names in italics format)

Names of components in examples always shown in italics. MessageReader component references removed. Description of Figure 54 modified as below.

MessageWritter appears in figure 56 and others. Replace with MessageWriter all over the document.

MessageWritter has been replaced with MessageWriter in all the figures containing it.

remove throwing events after each action in the examples of appendix A.3.

Throwing events are left there because they have an important role. However, a more precise textual explanation has been written.

In Figure 54: Message Full Search viewcomponent must be replaced by <<Form>> Message Writer view component. The send event must be a submit event.

Also fix the description of Figure 54 accordingly (and mention MessageWriter as a view container, not component)

Figure fixed by replacing the <<Form>> component as requested. “Message Full Search” text in <<Form>> has been replaced with “Message Writer”. Send Event changed to Submit event. “Message Keyword Search” in <<Details>> replaced with “Message Details”.
Caption of Figure 53 fixed: MessageReader ? MessageDetails

Fix at page 88: An List --> A List

typo corrected

Figure 64 contains a RED [H] tag. Make it black and add the stereotype <<Window>> to all the containers.

This and other figures still contained colored elements. All figures have been transformed in black and white (with grayscale filling of ViewComponents and Modules).

Add a new event type onLoad, applicable to containers and components.

added onLoadEvent metaclass. Correspondingly, all the other catching events have been renamed by adding the “On” prefix in front.
Specific events are discussed in Clause 8.1.6. Events, and therefore their discussion is removed from Clause 8.1.10 Specific Events and ViewComponents

Add a new viewcontainer called Menu in the metamodel, as an extension, together with Window.

Peculiarity: only contains events, no sub-containers or components

Menu class added as a specialization of ViewContainer, with OCL constraint and describing text.

Action Description (page 30): replace InteractionViewElement with InteractionFlowElement.

Typo fixed and sentence specified better, for clarity reasons.

Modal and Modeless containers must be tagged as <<Window>> in Table 1.

Resolution:
Instead of adding tag Window, they must be stereotypes themselves

Add Window in the list of main concepts in Table 1.

Added new row in Table 2 (not Table 1) with Window, respective symbol, description and example

In ClassViewContainer: The property Default can be true only for containers within a XOR container. One and only one Default subcontainer must be defined for a XOR container.

Consider the option of transforming Default into an association from XOR container to one of its subcontainers.

Added OCL condition on ViewContainer and fixed describing text.

The spec misses the concept of ModuleDefinition, so one can use a module but not define it.
Module definitions should come with a packaging mechanism too.

Add ModuleDefinition and Module Package. Module renamed as ModuleDefinition (as a NamedElement); added Element, PortDefinition and ModulePackage in metamodel, with composite pattern. Added respective descriptions. Modules refer to ModuleDefinitions. Flows in PortDefinition can only be connected to elements within the ModuleDefinition. Flows in PortDefinition can only be connected to elements outside the Module. The set of Parameters of the Port is derived from the set of Parameters of the corresponding PortDefinition.
Created new general clause for describing the new concepts and showing the metamodel fragment. Created all the specific clauses needed for describing the new concepts.

ViewContainers cannot contain Actions. This should be possible.

Add containment relation between ViewContainer and Action. In clause 8.1.3 figure and text have been updated.

Define the scope of parameters. It's not clear where parameters can be referenced.

A sensible rule can be: Scope of the parameter is the component or container where defined, plus everything contained in it.

Scope and type of parameters are clarified in Clause 8.3.27 in a new piece of text.

In figure 50: The model of the interaction flow for moving a message to an existing or newly created tag:

• the XOR container is not needed

• add the needed dataflow to the second action CreateTag

• the missing parent Folder must be added

• fix the newPage event

Figure 50 fixed by: removing the XOR container and adding the missing DataFlow.

Field can contain any sub-viewcomponentpart, not only slot.

remove rule from Field Class:

Constraints
• viewComponentPartsAreSlots
self.subViewComponentPart -> forAll(v | v.oclIsTypeOf(Slot))

Constraint Removed

Issue: Remove: The IFML textual syntax offers a textual syntax for expressing IFML models alternative, but equivalent, to the visual syntax

Text above removed from Clause 6.3 – IFML artfacts. The reason is that IFML does not specify any textual syntax

Issue: UML profile: reorganize viewelement UML profile correspondance as classes and components.

At the purpose of solving implementability and semantics problems, some stereotypes have been redefined (from UML component to class).
Furthermore, new stereotypes have been added for the new elements added in the metamodel for addressing the issues filed on IFML Beta 1, and respective descriptions and symbols have been added too

Figure 29 and figure 32: the nested component notation does not mean packaging but component realization. Fix figure and UML Profile structure. ViewComponents can be classes and not components. Nested component instances, on the other hand, mean composite structure, which is neither component packaging nor component realization!

The figures derive from the definition of most of the IFML concepts as stereotypes of the UML Component class. The definition of the profile has been updated to fix this problem, as from resolution of issue 19164.
The whole clause 11.3 has been restructured by using classes instead of components for defining ViewComponents. Furthermore, events have been stereotyped from UML Ports. Figures and respective descriptions have been fixed.

most images in the spec document are difficult to read, due to low resolution exporting problems.
Solution: if possible, replace images with vector versions

Diagram images have been replaced with vector graphics diagram images where possible. (note: this doesn’t change the content of the images, just the quality of the printing)

Issue: Simplify description of history management. Remove references to context and contextual flows

Rephrasing has been applied throughout Clause 9 for removing the concept of context and contextual flows. Final text reported below.

Issue: SimpleField expose automatically an output parameter. Slots expose an input parameter.
Solution: say that in the metamodel. Make simpleField and Slot inherit from Parameter and add OCL expressions? Rephrase Slot definition

This applies to 8.4.10 (slot) and 8.4.3 (field).
Slot description has been rewritten in 8.4.10.
Slot now inherits from Parameter too.
Field now inherits from Parameter too

ISSUE 11:
Section 8.4.4:
Issue: SubmitEvent property must be removed in text (not there in metamodel)

Association end removed from text

Issue: lists of ViewComponentParts and SubViewComponentParts

added “a” in text of 8.3.33. The rest of the issue does not apply.

Issue: Text description of Form is incomplete

New text describing the form added.

Section 8.1.7
Issue: "The Expression's context is any IFML element denoted by Element. The Expression values"- Rewrite.
Solution: Replace with: "The values". And add: "ConditionalExpressions can be defined only inside a DataBinding ViewComponentPart."

Text rephrased as below

Issue: Parameters in parameterBinding must be characterized as input or output. (in text and metamodel)

Fixed text and metamodel by characterizing parameters as input or output, through the attribute direction

Issue: add description of behaviour of data flows related to navigation flows

Issue actually applies to section 8.3.26. New text added, both in section 8.3.26 and also in 8.3.13 to make DataFlow description compatible with the new description

Section 8.3.24:
Issue: Remove the following miselading sentence: Modules may be replaced by other InteractionFlowElements with the same input and output Parameters.

Sentence removed

Section 8.1.6
Issue: the URI attribute of ContentBinding must be optional

The affected Clause is 8.1.8, not 8.1.6.
Added “optional” in the textual description and optionality in the metamodel diagram (figure 12).

Section 8.1.4:
Issue: Rephrase unclear sentence: "This new window may be a modal blocking interaction in all other previously active containers"

sentence rephrased as below

Issue: authors list does not reflect contribution
Solution: Put Brambilla, Fraternali first as main contributors

Applied suggestion. Added Andrea Mauri as further author as he contributed to the finalization work.

Issue: scope not well described
Solution: Remove: "; and the distribution of control, data and business logic at the different tiers of the architecture" - not explicitly covered. Add the fact we are only referencing the business logic and not controlling the sequence of actions

new text formulation, according to suggestion

Two of the XMI files use the XMI 2.1 namespace instead of XMI 2.4

XMI namespace version has been fixed to 2.4

A new event type should be added, for allowing direct jump from one place in the diagram to another.