20. Conceptual Package
The Conceptual Model defined in the KDM Conceptual package provides constructs for creating a conceptual model during the analysis phase of knowledge discovery from existing code. The Conceptual Model enables mapping of KDM compliant model to models compliant to other specifications. Currently, it provides “concept” classes – TermUnit and FactUnit facilitating mapping to SBVR.
These meta-model elements support the process of mining higher level (conceptual) information from lower-level KDM models and capturing it as additional KDM entities and relationship, thus allowing further analysis of an enriched model. KDM Conceptual model is aligned with SBVR specification in the following way. The KDM Conceptual Model allow representing three “concepts” that are key to SBVR: Term, Fact and Rule. The following is a mapping of this KDM “concepts” to the SBVR terminology:
- Term corresponds to SBVR Noun (collectively referring to SBVR Terms and SBVR Names)
- Fact corresponds to SBVR Fact
- Rule represents a condition, group of conditions, or constraint
The SBVR “concepts” (i.e., Term, Fact and Rule) are not defined in KDM. Instead, the KDM Conceptual Model defines the implementations of these “concepts” – TermUnit, FactUnit and RuleUnit. The mapping between KDM and SBVR is facilitated with the help of (0..*) to (0..*) relationships between pairs (i.e., <Term, TermUnit> and <Fact, FactUnit> and <Rule, RuleUnit>) as shown in See – Mapping between KDM and SBVR..
The ConceptualModel also provides “behavior” types – BehaviorUnit and ScenarioUnit that support mapping to various external models including but not limited to activities/flow chart and swim lane diagrams, and use case scenarios. The following explains the difference between these “behavior” types:
- BehaviorUnit represents a behavior graph with several paths through the application logic and associated conditions. The “implementation” of this graph is provided by the ActionElements connected with Flow relations, from the Program Elements KDM layer. The graph can be as small as a single ActionElement. BehaviorUnit is an “abstraction” of ActionElements since it provides a modeling element for representing a collection of ActionElements that is meaningful from the application domain perspective, and further manipulate with this representation as a first class citizen of the ConceptualModel of KDM.
- ScenarioUnit represents a path (or multiple related paths) through the behavior graph. For example, ScenarioUnit corresponds to a trace through the systems, or a “use case”. ScenarioUnit can own an entire collection of BehaviorUnits, connected with ConceptualFlow elements and can thus represent a slice of the original behavior graph in the implementation of the software system. The conditions responsible for navigation between alternative paths within the graph can be represented as RuleUnits
- RuleUnit represents a condition, a group of conditions, or a constraint. RuleUnit is a representation for some meaningful navigation conditions within behavior graphs represented by several BehaviorUnits.
– Mapping between KDM and SBVR
Organization of the Conceptual Package
The Conceptual package defines meta-model elements for representing high-level, high-value application-specific “conceptual” views of existing software systems.
The Conceptual Package consists of the following 5 class diagrams:
- ConceptualModel
- ConceptualInheritances
- ConceptualElements
- ConceptualRelations
- ExtendedConceptualElements
The Conceptual package depends on the following packages:
ConceptualModel Class Diagram
The ConceptualModel class diagram collects together all classes and associations of the Conceptual package. They provide basic meta-model constructs to define specialized “concept” types. These meta-model objects and relationships between them will be used as a foundation for a conceptual model built by a mining tool as a result of knowledge discovery from existing code. The ConceptualModel diagram defines meta-model elements to represent application-specific “concept” types, “fact” types and “rules”. An example of a “concept” is a “customer”, or a “savings account”. An example of a “fact” is a “customer opens a new savings account”. An example of a “rule” is “if the initial amount of money in a saving account is greater than $1000.00, then offer a higher interest account”. Even in a well-designed system an application-domain specific concept, like “customer” is rarely mapped one-to-one to a single programming language construct that can be directly discovered in the source code of the existing system. Instead, such “concept” is implemented by multiple programming language constructs, often spanning multiple source files, programming language, and technologies. These KDM meta-model objects and relationships between them provide the foundation for mining business rules and other high-value application-specific knowledge from existing code.
ConceptualModel follows the regular KDM pattern of extending the common Infrastructure framework by defining a specific KDM model class, an abstract superclass of all modeling elements in the ConceptualModel – the AbstractConceptualElement class. ConceptualModel provides another abstract superclass for all relationships, specific to this model – AbstractConceptualRelationship class. All meta-model elements of the ConceptualModel extend the AbstractConceptualElement class and implement the “model” and “ownedRelation” properties. Each entity of the ConceptualModel can own relationships, specific to this model. According to this pattern, each entity should own relationships that originate from this entity (i.e. the value of the “from” property should be equal to the id of the owner of the relationship). This framework provides several extension points for the KDM light-weight extension mechanism. In particular, in accordance to the general KDM pattern, the ConceptualModel framework includes a generic extensible modeling element ConceptualElement, and a generic ConceptualRelationship class.
The class diagram shown in See – ConceptualModel Class Diagram. captures these classes and their relations.
– ConceptualModel Class Diagram
ConceptualModel
The ConceptualModel class is a KDM model that extends the KDM Infrastructure framework to provide the infrastructure for representing conceptual views of existing software systems.
AbstractConceptualElement (abstract)
AbstractConceptualElement class is the top superclass for the ConceptualModel. It defines several common properties for all further meta-model elements in the Conceptual Package. In particular, it defines the fundamental “implementation” property – a KDM grouping mechanism to link conceptual elements to the implementation elements. The “implementation” property represents the set of elements in lower-level KDM model that represents implementation-specific high-fidelity knowledge of the software system. The “implementation” property realizes the mapping between the implementation of a certain concept to the KDM entity representing this concept – some concrete subclass of the AbstractConceptualElement. The set of KDM entities available through the “implementation” property becomes the “extent” of the application-specific concept being represented by the conceptual element. The conceptual element itself becomes the “handle” for the otherwise intangible and abstract high-value application domain specific concept.
It is expected that building conceptual models in general, and especially, determining the appropriate “implementation set, is a difficult value-added knowledge discovery process that may involve domain experts and application experts. KDM framework provides the intermediate representation for capturing the knowledge generated by this process.
For each conceptual element, the value of the from property of each conceptual relationship, owned by this element, should be equal to the identity of this element (the “relationship encapsulation” pattern)
AbstractConceptualRelationship class (abstract)
The AbstractConceptualRelationship class is determined by the KDM model pattern. It provides a common superclass for specific KDM relationships, defined in the Conceptual package.
ConceptualInheritances Class Diagram
The ConceptualInheritance class diagram defines how the conceptual meta-model elements fit into the KDM Infrastructure. The ConceptualInheritances class diagram is shown in See – ConceptualInheritances Class Diagram..
– ConceptualInheritances Class Diagram
ConceptualElements class diagram
ConceptualElements class diagram defines specific KDM modeling elements for representing domain-specific concepts as they are implemented by existing software systems. These elements are concrete subclasses of the AbstractConceptualElement class.
The classes and association of the ConceptualElements class diagram are shown at See – ConceptualElements Class Diagram.
– ConceptualElements Class Diagram
ConceptualContainer class
The ConceptualContainer class is a generic meta-model element that represents a container for conceptual entities. Several other concrete conceptual element are subclasses of ConceptualContainer, so that they can also own other conceptual elements. The purpose of the ConceptualContainer meta-model element is to facilitate hierarchical organization and grouping of “concepts” within Conceptual Model. ConceptualContainer can be also used as an extended modeling element with a stereotype.
| conceptualElement:AbstractConceptualElement[0..*] | elements that are owned by this container |
ConceptualUnit should not own ConceptualRole elements
TermUnit
The TermUnit class represents an arbitrary collection of KDM entities from the Program Elements layer or PlatformResource layer. From the knowledge discovery perspective, such collection may include program elements involved in the implementation of a certain application domain concept. A TermUnit then provides a representation of such concept inside the KDM model which can be used for further analysis and later exported into a business rule modeling tool in the process known as application business rules mining. The TermUnit class is aligned with SBVR term or name concepts. Semantically, a TermUnit represents some “noun concept”.
FactUnit
The FactUnit class represents an association between multiple Conceptual entities, such as TermUnit or FactUnit. This association can be unary, binary or n-ary. From the knowledge mining perspective, a FactUnit may correspond to some behavior of the software system (for example, a formula for calculating an allowance can be considered as a fact) or some property of the software system meaningful in the application domain. FactUnit may be also associated with an arbitrary collection of the KDM entities. A FactUnit then provides a representation of such property inside the KDM model which can be used for further analysis and later exported into a business rule modeling tool in the process known as application business rules mining. The FactUnit class is aligned with SBVR fact type concept. Semantically, a FactUnit represents a “verb concept”, or an “objectified verb concept”, that can be later used as a noun..
RuleUnit
The RuleUnit class represents an association between multiple Conceptual entities, such as TermUnit or FactUnit. This association can be unary, binary or n-ary. From the knowledge mining perspective, a FactUnit may correspond to some condition or constraint in the software system (for example, a condition under which an allowance can be increased, or a statement that a certain property should always be satisfied). RuleUnit may be also associated with an arbitrary collection of the KDM entities (these often involve action elements that represent conditions). A RuleUnit then provides a representation of such condition or constraint inside the KDM model which can be used for further analysis and later exported into a business rule modeling tool in the process known as application business rules mining. The RuleUnit class is aligned with SBVR rule concept. Semantically, a RuleUnit uses some base “verb concept” (usually represented as a fact type) and adds to it obligation, necessity, qualifications, quantifications, conditions, etc.
ConceptualRole
The ConceptualRole class represents a role played by a participant in a conceptual association, such a FactUnit or a RuleUnit. ConceptualRole elements are owned by some container, a subclass of ConceptualUnit. The ConceptualRole element provides a placeholder for capturing the name of this role as the “name” attribute of the class. Additional annotations of stereotypes can be provided by using the KDM light-weight extension mechanism.
| conceptualElement:AbstractConceptualElement[1] |
represents the participant in the assocation for the given role |
BehaviorUnit class
The BehaviorUnit class represents an arbitrary collection of KDM entities from the Program Elements layer or Platfrom Resource layer. From the knowledge discovery perspective, such collection may represent some behavior meaningful in the application domain (or simply interesting for the analysis, understanding and modernization of the software system). A BehaviorUnit then provides a representation of such behavior inside the KDM model which can be used for further analysis. In particular, larger slices of the program logic can be represented as collections of BehaviorUnit elements linked by ConceptualFlow relationships.
The BehaviorUnit class represents a behavior graph with several paths through the application logic. The “implementation” of this graph is provided by the ActionElements connected with Flow relations, from the Program Elements KDM layer. The graph can be as small as a single ActionElement. BehaviorUnit is an “abstraction” of ActionElements since it provides a modeling element for representing a collection of ActionElements that is meaningful from the application domain perspective, and further manipulate with this representation as a first class citizen of the ConceptualModel of KDM.
ScenarioUnit class
ScenarioUnit represents a path (or multiple related paths) through the behavior graph of the application logic. For example, ScenarioUnit corresponds to a trace through the systems, or a “use case”. The “implementation” of this graph is provided by the ActionElements connected with Flow relations, from the Program Elements KDM layer. Semantically, the difference between a BehaviorUnit and a ScenarioUnit is that a BehaviorUnit is an abstraction of behavior, while ScenarioUnit is an abstraction of a trace. For example, an interesting formula, or an algorithm can be represented as a BehaviorUnit rather than a ScenarioUnit. On the other hand, an interesting data flow path through the application can be represented as a ScenarioUnit rather than a BehaviorUnit. ScenarioUnit can own an entire collection of BehaviorUnits, connected with ConceptualFlow elements and can thus represent a slice of the original behavior graph in the implementation of the software system. The conditions responsible for navigation between alternative paths within the graph can be represented as RuleUnits
ConceptualRelations class diagram
ConceptualRelations class diagram defines specific conceptual relationship called ConceptualFlow.
The classes and associations involved in the ConceptualRelations class diagram are shown at See – ConceptualRelations Class Diagram.
– ConceptualRelations Class Diagram
ConceptualFlow class
The ConceptualFlow class is a KDM relationship defined for the conceptual model. It represents the fact that one behavior may be continued into some other behavior. When multiple ConceptualFlow relations exist for a given conceptual element (according to the KDM relationship encapsulation pattern, these relationships should be owned by the conceptual element and the “from” property of the relationship should be equal to the identify of the element), this means that the behavior represented by that conceptual element may be continued by either of these flows nondeterministically. The follow-up behavior is designated by the conceptual element represented by the “to” property of the ConceptualFlow relationship. When the “to” endpoint of the ConceptualFlow relationship designates a container, this means that any behavior from that container can be the continuation of the initial behavior. When the “from” endpoint of the ConceptualFlow relationship is a container, this means that any behavior element owned by that container can be used as the initial behavior. This relationship provides an abstraction for the Flow relations in the Program Elements layer. ConceptualFlow relation provides a modeling element for representing behavior slices of the application logic that are meaningful from the application domain perspective, and further manipulate with this representation as a first class citizen of the ConceptualModel of KDM.
AbstractConceptualRelationship
| from: AbstractConceptualElement[1] | represents the initial behavior |
| to:AbstractConceptualElement[1] | represents a potential follow-up behavior |
Program TransactionsApproval File Name: MM0319.Hfm
011 Field2 – Customer First Name
012 Field3 – Customer Last Name
013 Field4 (list) – Account Number
014 Field5 (list) – Account Type
015 Field6 (list) – Account Balance
Program TransactionsApproval File Name: MM0245.HLa
100 // Definitions of variables mapable to the form fields
102 Define Cust_FName (Char 25)
103 Define Cust_LName (Char 35)
104 Define Acc_Numb(Char 12)[10]
105 Define Acc_Type(Char 2)[10]
106 Define Acc_Balance(Currency)[10]
108 // Definition of other variables
111 Define AdjustedBal(Currency)
112 Define ApproveTrans(Boolean)
113 Define Allowance(Currency)
150 // Populating variables entered in the form
156 Field6[1] -> Acc_Balance[0]
201 Allowance = $100.00 // The allowance shall be calculated for each customer
203 Bal = Acc_Balance[Ind – 1]
204 AdjustedBal = Bal + Allowance
240 If(AdjustedBal > $1000.00)
<?xml version=”1.0″ encoding=”UTF-8″?>
<kdm:Segment xmi:version=”2.1″
xmlns:xmi=”http://www.omg.org/XMI”
xmlns:action=”http://kdm.omg.org/action”
xmlns:code=”http://kdm.omg.org/code”
xmlns:conceptual=”http://kdm.omg.org/conceptual”
xmlns:kdm=”http://kdm.omg.org/kdm”
xmlns:source=”http://kdm.omg.org/source”
xmlns:ui=”http://kdm.omg.org/ui” name=”Conceptual Example”>
<model xmi:id=”id.0″ xmi:type=”code:CodeModel”>
<codeElement xmi:id=”id.1″ xmi:type=”code:CodeAssembly”>
<codeElement xmi:id=”id.2″ xmi:type=”code:StorableUnit” name=”Cust_ID”
type=”id.127″ ext=”Char 20″ size=”20″>
<comment xmi:id=”id.3″ text=”// Definitions of variables mapable to the form fields”/>
<codeElement xmi:id=”id.4″ xmi:type=”code:StorableUnit” name=”Cust_FName”
type=”id.127″ ext=”Char 25″ size=”25″/>
<codeElement xmi:id=”id.5″ xmi:type=”code:StorableUnit” name=”Cust_LName”
type=”id.127″ ext=”Char 35″ size=”35″/>
<codeElement xmi:id=”id.6″ xmi:type=”code:StorableUnit” name=”Acc_Numb”
<codeElement xmi:id=”id.7″ xmi:type=”code:ArrayType” size=”10″>
<itemUnit xmi:id=”id.8″ name=”Acc_Numb[]” type=”id.127″ ext=”Char 12″ size=”12″/>
<codeElement xmi:id=”id.9″ xmi:type=”code:StorableUnit” name=”Acc_Type”
<codeElement xmi:id=”id.10″ xmi:type=”code:ArrayType” size=”10″>
<itemUnit xmi:id=”id.11″ name=”Acc_Type[]” type=”id.127″ ext=”Char 2″ size=”2″/>
<codeElement xmi:id=”id.12″ xmi:type=”code:StorableUnit” name=”Acc_Balance”
<codeElement xmi:id=”id.13″ xmi:type=”code:ArrayType” size=”10″>
<itemUnit xmi:id=”id.14″ name=”Acc_Balance[]” type=”id.128″ ext=”Currency” size=”2″/>
<codeElement xmi:id=”id.15″ xmi:type=”code:StorableUnit” name=”Bal”
type=”id.128″ ext=”” size=”1″ kind=”local”>
<comment xmi:id=”id.16″ text=”// Definition of other variables”/>
<codeElement xmi:id=”id.17″ xmi:type=”code:StorableUnit” name=”Ind”
type=”id.129″ ext=”” size=”1″ kind=”local”/>
<codeElement xmi:id=”id.18″ xmi:type=”code:StorableUnit” name=”AdjustedBal”
type=”id.128″ ext=”” size=”1″ kind=”local”/>
<codeElement xmi:id=”id.19″ xmi:type=”code:StorableUnit” name=”ApprovedTrans”
type=”id.130″ ext=”” size=”1″ kind=”local”/>
<codeElement xmi:id=”id.20″ xmi:type=”code:StorableUnit” name=”Allowance”
type=”id.128″ ext=”” size=”1″ kind=”local”/>
<codeElement xmi:id=”id.21″ xmi:type=”action:ActionElement” name=”i1″ kind=”Assign”>
<source xmi:id=”id.22″ language=”Hla” snippet=”Field1 -> Cust_ID”/>
<comment xmi:id=”id.23″ text=”// Populating variables entered in the form”/>
<codeElement xmi:id=”id.24″ xmi:type=”code:StorableUnit” name=”Field1″
type=”id.127″ kind=”register”/>
<actionRelation xmi:id=”id.25″ xmi:type=”action:Reads” to=”id.24″ from=”id.21″/>
<actionRelation xmi:id=”id.26″ xmi:type=”action:Writes” to=”id.2″ from=”id.21″/>
<actionRelation xmi:id=”id.27″ xmi:type=”action:Flow” to=”id.28″ from=”id.21″/>
<codeElement xmi:id=”id.28″ xmi:type=”action:ActionElement” name=”i2″ kind=”Assign”>
<source xmi:id=”id.29″ language=”Hla” snippet=”Field2 -> Cust_FName”/>
<codeElement xmi:id=”id.30″ xmi:type=”code:StorableUnit” name=”Field2″
type=”id.127″ kind=”register”/>
<actionRelation xmi:id=”id.31″ xmi:type=”action:Reads” to=”id.30″ from=”id.28″/>
<actionRelation xmi:id=”id.32″ xmi:type=”action:Writes” to=”id.4″ from=”id.28″/>
<actionRelation xmi:id=”id.33″ xmi:type=”action:Flow” to=”id.34″ from=”id.28″/>
<codeElement xmi:id=”id.34″ xmi:type=”action:ActionElement” name=”i3″ kind=”Assign”>
<source xmi:id=”id.35″ language=”Hla” snippet=”Field3 -> Cust_LName”/>
<codeElement xmi:id=”id.36″ xmi:type=”code:StorableUnit” name=”Field3″
type=”id.127″ kind=”register”/>
<actionRelation xmi:id=”id.37″ xmi:type=”action:Reads” to=”id.36″ from=”id.34″/>
<actionRelation xmi:id=”id.38″ xmi:type=”action:Writes” to=”id.5″ from=”id.34″/>
<actionRelation xmi:id=”id.39″ xmi:type=”action:Flow” to=”id.40″ from=”id.34″/>
<codeElement xmi:id=”id.40″ xmi:type=”action:ActionElement” name=”i4″ kind=”ArrayReplace”>
<source xmi:id=”id.41″ language=”Hla” snippet=”Field5[1] -> Acc_Type[0]”/>
<codeElement xmi:id=”id.42″ xmi:type=”code:Value” name=”0″ type=”id.129″/>
<codeElement xmi:id=”id.43″ xmi:type=”code:StorableUnit” name=”Field4″
type=”id.127″ kind=”register”/>
<actionRelation xmi:id=”id.44″ xmi:type=”action:Reads” to=”id.42″ from=”id.40″/>
<actionRelation xmi:id=”id.45″ xmi:type=”action:Addresses” to=”id.9″ from=”id.40″/>
<actionRelation xmi:id=”id.46″ xmi:type=”action:Reads” to=”id.43″ from=”id.40″/>
<actionRelation xmi:id=”id.47″ xmi:type=”action:Writes” to=”id.8″ from=”id.40″/>
<actionRelation xmi:id=”id.48″ xmi:type=”action:Flow” to=”id.49″ from=”id.40″/>
<codeElement xmi:id=”id.49″ xmi:type=”action:ActionElement” name=”i5″ kind=”ArrayReplace”>
<source xmi:id=”id.50″ language=”Hla” snippet=”Field4[1] -> Acc_Numb[0]”/>
<codeElement xmi:id=”id.51″ xmi:type=”code:Value” name=”0″ type=”id.129″/>
<codeElement xmi:id=”id.52″ xmi:type=”code:StorableUnit” name=”Field5″
type=”id.127″ kind=”register”/>
<actionRelation xmi:id=”id.53″ xmi:type=”action:Reads” to=”id.51″ from=”id.49″/>
<actionRelation xmi:id=”id.54″ xmi:type=”action:Addresses” to=”id.6″ from=”id.49″/>
<actionRelation xmi:id=”id.55″ xmi:type=”action:Reads” to=”id.52″ from=”id.49″/>
<actionRelation xmi:id=”id.56″ xmi:type=”action:Writes” to=”id.11″ from=”id.49″/>
<actionRelation xmi:id=”id.57″ xmi:type=”action:Flow” to=”id.58″ from=”id.49″/>
<codeElement xmi:id=”id.58″ xmi:type=”action:ActionElement” name=”i6″ kind=”ArrayReplace”>
<source xmi:id=”id.59″ language=”Hla” snippet=”Field6[1] -> Acc_Balance[0]”/>
<codeElement xmi:id=”id.60″ xmi:type=”code:Value” name=”0″ type=”id.129″/>
<codeElement xmi:id=”id.61″ xmi:type=”code:StorableUnit” name=”Field6″
type=”id.127″ kind=”register”/>
<actionRelation xmi:id=”id.62″ xmi:type=”action:Reads” to=”id.60″ from=”id.58″/>
<actionRelation xmi:id=”id.63″ xmi:type=”action:Addresses” to=”id.12″ from=”id.58″/>
<actionRelation xmi:id=”id.64″ xmi:type=”action:Reads” to=”id.61″ from=”id.58″/>
<actionRelation xmi:id=”id.65″ xmi:type=”action:Writes” to=”id.14″ from=”id.58″/>
<actionRelation xmi:id=”id.66″ xmi:type=”action:Flow” to=”id.67″ from=”id.21″/>
<codeElement xmi:id=”id.67″ xmi:type=”action:ActionElement” name=”p1″ kind=”Assign”>
<source xmi:id=”id.68″ language=”Hla” snippet=”Allowance = $100.00 “/>
<comment xmi:id=”id.69″ text=”// Processing”/>
<comment xmi:id=”id.70″ text=”// The allowance shall be calculated for each customer”/>
<codeElement xmi:id=”id.71″ xmi:type=”code:Value” name=”100.00″ type=”id.128″/>
<actionRelation xmi:id=”id.72″ xmi:type=”action:Reads” to=”id.71″ from=”id.67″/>
<actionRelation xmi:id=”id.73″ xmi:type=”action:Writes” to=”id.20″ from=”id.67″/>
<actionRelation xmi:id=”id.74″ xmi:type=”action:Flow” to=”id.75″ from=”id.67″/>
<codeElement xmi:id=”id.75″ xmi:type=”action:ActionElement” name=”p2″ kind=”Assign”>
<source xmi:id=”id.76″ language=”Hla” snippet=”Ind =1″/>
<codeElement xmi:id=”id.77″ xmi:type=”code:Value” name=”1″ type=”id.129″/>
<actionRelation xmi:id=”id.78″ xmi:type=”action:Reads” to=”id.77″ from=”id.75″/>
<actionRelation xmi:id=”id.79″ xmi:type=”action:Writes” to=”id.17″ from=”id.75″/>
<actionRelation xmi:id=”id.80″ xmi:type=”action:Flow” to=”id.49″ from=”id.75″/>
<codeElement xmi:id=”id.81″ xmi:type=”action:ActionElement” name=”p3″ kind=”Compound”>
<source xmi:id=”id.82″ language=”Hla” snippet=”Bal = Acc_Balance[Ind – 1]”/>
<codeElement xmi:id=”id.83″ xmi:type=”code:Value” name=”1″ type=”id.129″/>
<codeElement xmi:id=”id.84″ xmi:type=”code:StorableUnit” name=”t1″
type=”id.129″ ext=”” kind=”register”/>
<codeElement xmi:id=”id.85″ xmi:type=”action:ActionElement” name=”p3.1″ kind=”Subtract”>
<actionRelation xmi:id=”id.86″ xmi:type=”action:Reads” to=”id.17″ from=”id.81″/>
<actionRelation xmi:id=”id.87″ xmi:type=”action:Reads” to=”id.83″ from=”id.81″/>
<actionRelation xmi:id=”id.88″ xmi:type=”action:Writes” to=”id.84″ from=”id.81″/>
<actionRelation xmi:id=”id.89″ xmi:type=”action:Flow” to=”id.90″ from=”id.85″/>
<codeElement xmi:id=”id.90″ xmi:type=”action:ActionElement” name=”p3.2″ kind=”ArraySelect”>
<actionRelation xmi:id=”id.91″ xmi:type=”action:Addresses” to=”id.14″ from=”id.90″/>
<actionRelation xmi:id=”id.92″ xmi:type=”action:Reads” to=”id.84″ from=”id.81″/>
<actionRelation xmi:id=”id.93″ xmi:type=”action:Writes” to=”id.15″ from=”id.81″/>
<actionRelation xmi:id=”id.94″ xmi:type=”action:Flow” to=”id.85″ from=”id.81″/>
<actionRelation xmi:id=”id.95″ xmi:type=”action:Flow” to=”id.96″ from=”id.81″/>
<codeElement xmi:id=”id.96″ xmi:type=”action:ActionElement” name=”p4″ kind=”Assign”>
<source xmi:id=”id.97″ language=”Hla” snippet=”AdjustedBal = Bal + Allowance”/>
<actionRelation xmi:id=”id.98″ xmi:type=”action:Reads” to=”id.15″ from=”id.96″/>
<actionRelation xmi:id=”id.99″ xmi:type=”action:Reads” to=”id.20″ from=”id.96″/>
<actionRelation xmi:id=”id.100″ xmi:type=”action:Writes” to=”id.18″ from=”id.96″/>
<actionRelation xmi:id=”id.101″ xmi:type=”action:Flow” to=”id.49″ from=”id.96″/>
<codeElement xmi:id=”id.102″ xmi:type=”action:ActionElement” name=”p5″ kind=”Assign”>
<source xmi:id=”id.103″ language=”Hla” snippet=”If(AdjustedBal > $1000.00)”/>
<codeElement xmi:id=”id.104″ xmi:type=”code:StorableUnit” name=”t2″
type=”id.130″ kind=”register”/>
<codeElement xmi:id=”id.105″ xmi:type=”action:ActionElement” name=”p5.1″ kind=”GreaterThan”>
<codeElement xmi:id=”id.106″ xmi:type=”code:Value” name=”1000.00″ type=”id.128″/>
<actionRelation xmi:id=”id.107″ xmi:type=”action:Reads” to=”id.18″ from=”id.105″/>
<actionRelation xmi:id=”id.108″ xmi:type=”action:Reads” to=”id.106″ from=”id.105″/>
<actionRelation xmi:id=”id.109″ xmi:type=”action:Writes” to=”id.104″ from=”id.105″/>
<actionRelation xmi:id=”id.110″ xmi:type=”action:Flow” to=”id.111″ from=”id.105″/>
<codeElement xmi:id=”id.111″ xmi:type=”action:ActionElement” name=”p5.2″ kind=”GreaterThan”>
<actionRelation xmi:id=”id.112″ xmi:type=”action:Reads” to=”id.104″ from=”id.111″/>
<actionRelation xmi:id=”id.113″ xmi:type=”action:TrueFlow” to=”id.115″ from=”id.111″/>
<actionRelation xmi:id=”id.114″ xmi:type=”action:FalseFlow” to=”id.120″ from=”id.111″/>
<codeElement xmi:id=”id.115″ xmi:type=”action:ActionElement” name=”p6″ kind=”Assign”>
<source xmi:id=”id.116″ language=”Hla” snippet=”Then ApproveTrans = True”/>
<codeElement xmi:id=”id.117″ xmi:type=”code:Value” name=”true” type=”id.130″/>
<actionRelation xmi:id=”id.118″ xmi:type=”action:Reads” to=”id.117″ from=”id.115″/>
<actionRelation xmi:id=”id.119″ xmi:type=”action:Writes” to=”id.19″ from=”id.115″/>
<codeElement xmi:id=”id.120″ xmi:type=”action:ActionElement” name=”p7″ kind=”Assign”>
<source xmi:id=”id.121″ language=”Hla” snippet=”Else ApproveTrans = False”/>
<codeElement xmi:id=”id.122″ xmi:type=”code:Value” name=”false” type=”id.130″/>
<actionRelation xmi:id=”id.123″ xmi:type=”action:Reads” to=”id.122″ from=”id.120″/>
<actionRelation xmi:id=”id.124″ xmi:type=”action:Writes” to=”id.19″ from=”id.120″/>
<actionRelation xmi:id=”id.125″ xmi:type=”action:Flow” to=”id.105″ from=”id.102″/>
<codeElement xmi:id=”id.126″ xmi:type=”code:LanguageUnit”>
<codeElement xmi:id=”id.127″ xmi:type=”code:StringType”/>
<codeElement xmi:id=”id.128″ xmi:type=”code:DecimalType” name=”Currency”/>
<codeElement xmi:id=”id.129″ xmi:type=”code:IntegerType”/>
<codeElement xmi:id=”id.130″ xmi:type=”code:BooleanType”/>
<model xmi:id=”id.131″ xmi:type=”source:InventoryModel”>
<inventoryElement xmi:id=”id.132″ xmi:type=”source:Directory” path=”SOURCES\HLanguage”>
<inventoryElement xmi:id=”id.133″ xmi:type=”source:SourceFile” name=”mm0245.Hla”/>
<inventoryElement xmi:id=”id.134″ xmi:type=”source:SourceFile” name=”mm0319.Hfm”/>
<inventoryElement xmi:id=”id.135″ xmi:type=”source:Directory” path=”SOURCES\Hlib”/>
<model xmi:id=”id.136″ xmi:type=”ui:UIModel”>
<UIElement xmi:id=”id.137″ xmi:type=”ui:Screen” name=”Customer Information”>
<UIElement xmi:id=”id.138″ xmi:type=”ui:UIField” name=”Customer ID”>
<abstraction xmi:id=”id.139″ name=”f1″>
<actionRelation xmi:id=”id.140″ xmi:type=”action:Writes” to=”id.24″ from=”id.139″/>
<UIElement xmi:id=”id.141″ xmi:type=”ui:UIField” name=”Customer First Name”>
<abstraction xmi:id=”id.142″ name=”f2″>
<actionRelation xmi:id=”id.143″ xmi:type=”action:Writes” to=”id.30″ from=”id.142″/>
<UIElement xmi:id=”id.144″ xmi:type=”ui:UIField” name=”Customer Last Name”>
<abstraction xmi:id=”id.145″ name=”f3″>
<actionRelation xmi:id=”id.146″ xmi:type=”action:Writes” to=”id.36″ from=”id.145″/>
<UIElement xmi:id=”id.147″ xmi:type=”ui:UIField” name=”Account Number”>
<abstraction xmi:id=”id.148″ name=”f4″>
<actionRelation xmi:id=”id.149″ xmi:type=”action:Writes” to=”id.43″ from=”id.148″/>
<UIElement xmi:id=”id.150″ xmi:type=”ui:UIField” name=”Account Type”>
<abstraction xmi:id=”id.151″ name=”f5″>
<actionRelation xmi:id=”id.152″ xmi:type=”action:Writes” to=”id.52″ from=”id.151″/>
<UIElement xmi:id=”id.153″ xmi:type=”ui:UIField” name=”Account Balance”>
<abstraction xmi:id=”id.154″ name=”f6″>
<actionRelation xmi:id=”id.155″ xmi:type=”action:Writes” to=”id.61″ from=”id.154″/>
<model xmi:id=”id.156″ xmi:type=”conceptual:ConceptualModel” name=”Customer Information”>
<conceptualElement xmi:id=”id.157″ xmi:type=”conceptual:TermUnit” name=”AccountBalance”
implementation=”id.15 id.12 id.17 id.153″/>
<conceptualElement xmi:id=”id.158″ xmi:type=”conceptual:TermUnit” name=”MaxAdjustedBalance”
<conceptualElement xmi:id=”id.159″ xmi:type=”conceptual:TermUnit” name=”AllowanceAmount”
<conceptualElement xmi:id=”id.160″ xmi:type=”conceptual:TermUnit” name=”Allowance”
<conceptualElement xmi:id=”id.161″ xmi:type=”conceptual:TermUnit” name=”AdjustedBalance”
<conceptualElement xmi:id=”id.162″ xmi:type=”conceptual:TermUnit” name=”AccountBalanceField”
<conceptualElement xmi:id=”id.163″ xmi:type=”conceptual:FactUnit”
name=”AdjustedBalanceUnderThreshold” implementation=”id.105″>
<conceptualRelation xmi:id=”id.164″ xmi:type=”conceptual:ConceptualFlow”
<conceptualRelation xmi:id=”id.165″ xmi:type=”conceptual:ConceptualFlow”
<conceptualElement xmi:id=”id.166″ xmi:type=”conceptual:ConceptualRole” name=”Adjusted Balance”
<conceptualElement xmi:id=”id.167″ xmi:type=”conceptual:ConceptualRole” name=”Threshold”
<conceptualElement xmi:id=”id.168″ xmi:type=”conceptual:FactUnit” name=”AccountBalanceCalculation”
implementation=”id.58 id.75 id.81″>
<conceptualRelation xmi:id=”id.169″ xmi:type=”conceptual:ConceptualFlow”
<conceptualElement xmi:id=”id.170″ xmi:type=”conceptual:ConceptualRole” name=”Boundary element”
<conceptualElement xmi:id=”id.171″ xmi:type=”conceptual:ConceptualRole” name=”Account”
<conceptualElement xmi:id=”id.172″ xmi:type=”conceptual:FactUnit”
name=”AdjustedBalanceCalculation” implementation=”id.67 id.96″>
<conceptualRelation xmi:id=”id.173″ xmi:type=”conceptual:ConceptualFlow”
<conceptualElement xmi:id=”id.174″ xmi:type=”conceptual:ConceptualRole” name=”Account Balance”
<conceptualElement xmi:id=”id.175″ xmi:type=”conceptual:ConceptualRole” name=”Allowance Amount”
<conceptualElement xmi:id=”id.176″ xmi:type=”conceptual:FactUnit” name=”TransactionApproved”
<conceptualElement xmi:id=”id.177″ xmi:type=”conceptual:FactUnit” name=”TransactionNotApproved”
<conceptualElement xmi:id=”id.178″ xmi:type=”conceptual:RuleUnit” name=”ApproveTransaction”
implementation=”id.105 id.111 id.115″>
<source xmi:id=”id.179″ language=”SBVR”
snippet=”Transaction is approved if adjusted balance is under the threshold”/>
<conceptualRelation xmi:id=”id.180″ xmi:type=”conceptual:ConceptualFlow”
<conceptualElement xmi:id=”id.181″ xmi:type=”conceptual:ConceptualRole” name=”Condition”
<conceptualElement xmi:id=”id.182″ xmi:type=”conceptual:ConceptualRole” name=”Consequence”
<conceptualElement xmi:id=”id.183″ xmi:type=”conceptual:RuleUnit” name=”TransactionFailedApproval”
implementation=”id.105 id.111 id.120″>
<conceptualRelation xmi:id=”id.184″ xmi:type=”conceptual:ConceptualFlow”
<conceptualElement xmi:id=”id.185″ xmi:type=”conceptual:ConceptualRole” name=”NOT condition”
<conceptualElement xmi:id=”id.186″ xmi:type=”conceptual:ConceptualRole” name=”consequence”
<conceptualElement xmi:id=”id.187″ xmi:type=”conceptual:ScenarioUnit”>
<conceptualElement xmi:id=”id.188″ xmi:type=”conceptual:BehaviorUnit” name=”Calculate Balance”
implementation=”id.58 id.75 id.81″>
<conceptualRelation xmi:id=”id.189″ xmi:type=”conceptual:ConceptualFlow”
<conceptualElement xmi:id=”id.190″ xmi:type=”conceptual:BehaviorUnit”
name=”Calculate Adjusted Balance” implementation=”id.67 id.96″>
<conceptualRelation xmi:id=”id.191″ xmi:type=”conceptual:ConceptualFlow”
<conceptualElement xmi:id=”id.192″ xmi:type=”conceptual:BehaviorUnit” name=”Approve Transaction”
implementation=”id.102 id.115 id.120″/>
<conceptualElement xmi:id=”id.193″ xmi:type=”conceptual:BehaviorUnit” name=”Input”
implementation=”id.21 id.28 id.34 id.40 id.49 id.58″>
<conceptualRelation xmi:id=”id.194″ xmi:type=”conceptual:ConceptualFlow”
<conceptualElement xmi:id=”id.195″ xmi:type=”conceptual:BehaviorUnit” name=”Processing”
implementation=”id.67 id.75 id.81 id.85 id.90 id.96 id.102 id.105 id.111 id.115 id.120″/>
ExtendedConceptualElements Class Diagram
The ExtendedConceptualElements class diagram defines two “wildcard” generic elements for the conceptual model as determined by the KDM model pattern: a generic conceptual entity and a generic conceptual relationship.
The classes and associations of the ExtendedConceptualElements diagram are shown in See – ExtendedConceptualElements Class Diagram..
– ExtendedConceptualElements Class Diagram
ConceptualElement Class (generic)
The ConceptualElement is a generic meta-model element that can be used to define new “virtual” meta-model elements through the KDM light-weight extension mechanism
ConceptualElement should have at least one stereotype
A conceptual entity with underspecified semantics. It is a concrete class that can be used as the base element of a new “virtual” meta-model entity types of the conceptual model. This is one of the KDM extension points which can integrate additional language-specific, application-specific or implementer-specific pieces of knowledge into the standard KDM representation.
ConceptualRelationship Class (generic)
The ConceptualRelationship is a generic meta-model element that can be used to define new “virtual” meta-model elements through the KDM light-weight extension mechanism
AbstractConceptualRelationship
| from:AbstractConceptualElement[1] | The conceptual element origin of the relationship |
| to:KDMEntity[1] | The KDMEntity target of the relationship |
ConceptualRelationship should have at least one stereotype
A conceptual relationship with underspecified semantics. It is a concrete class that can be used as the base element of a new “virtual” meta-model relationship types of the conceptual model. This is one of the KDM extension points which can integrate additional language-specific, application-specific or implementer-specific pieces of knowledge into the standard KDM representation.