Check-in [d6f2378197]
Not logged in

Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.

Overview
Comment:Checkpoint on how to translate with micca document.
Timelines: family | ancestors | descendants | both | micca-develop
Files: files | file ages | folders
SHA1:d6f23781972f9b63ac3e23176ee9369def36c9df
User & Date: andrewm 2019-03-15 15:59:12
Context
2019-03-19
14:20
Checkpoint on how to translate using micca document. check-in: 8a1ffff90f user: andrewm tags: micca-develop
2019-03-15
15:59
Checkpoint on how to translate with micca document. check-in: d6f2378197 user: andrewm tags: micca-develop
2019-03-14
16:09
Checkpoint on how to translate with micca document. check-in: a3d130ad8e user: andrewm tags: micca-develop
Changes

Changes to micca/doc/howto/data.txt.

463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484































































485
486
487
488
489
490
491
...
516
517
518
519
520
521
522












523
524
525
526
527
528
529
530
531
532


533
534
535
536
537
538
539
540
541
542
543
544
545
546
...
591
592
593
594
595
596
597




598
599
600
601
602
603
604
...
636
637
638
639
640
641
642
643
644
645
646
647
648
649



















650
651
652
653
654
655
656
...
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
...
902
903
904
905
906
907
908



















909



910
911

912








913















































914
915
916
917
it is obtained by navigating the relationship.

=== Translating relationships

Model relationships represent constraints on the number and conditionality
of how class instances are associated with each other in the real world.
Fundamentally,
the multiplicity and conditionality of a relationship restricts
membership in the underlying set that class instances represent.
In a model,
relationships are realized by referential attributes having values
equal to those of identifying attributes.
Since `micca` supplies a unique identifier for class instances,
those identifiers may be used to realize relationships for
platform classes.

`Micca` supports translating the relationships by:

* Generating data structures and providing operations
  to handle the references for instances that participate in a relationship.
* Verifying at run-time that the constraints implied by the relationship
  are not violated by the execution of domain activities.
































































==== Translating simple associations

Consider the following model fragment:

["plantuml",title="Simple association"]
----
................................................................................
----

This fragment shows an _at least one_ to _one_ association between
a *Warehouse Clerk* and a *Warehouse*.
This situation would be translated as:

----












association R25 Warehouse_Clerk 1..*--1 Warehouse
----

The `association` command defines the characteristics of the
association between classes.
The syntax of the multiplicity and conditionality, _i.e._ **1..*--1**,
is intended to be mnemonic of the notation used in the
XUML class diagram.
Note this argument has no embedded whitespace.



The class which contains the referential attributes appears first
in the command arguments.
This is the _referring_ class.
The other participant is the _referenced_ class.
This distinction will become more important later,
but for now, simple association are always specfied from the
referring class to the referenced class.

==== Translating associative classes

Some associations require an associative class to realize the mapping
between participating instances.
An association class is required for:

................................................................................
(P, SC) .. PS : R14
@enduml
----

This association would be translated as:

----




association R14 -associator Product_Selection Product 1..*--0..* Shopping_Cart
----

==== Translating generalizations

Consider the following model fragment:

................................................................................
----

This is a generalization relationship.
In XUML,
a generalization does _not_ represent inheritance.
Rather, it represents a disjoint set partitioning.
Strictly speaking,
the relationship graphic should be annotated with `{complete, disjoint}`, but
since this is the only type of generalization used in XUML, the
annotation is usually dropped as graphical clutter.

This situation would be translated as:

----



















generalization R22 Product Book_Product Recording_Product
----

_i.e._ we use the `generalization` command giving the name of the relationship,
the name of the superclass and the names of the subclasses which participate
in the generalization.

................................................................................
assume the analysis model has specified the following initial instance
population.
Here the data is presented in tabullar form and the population is
entirely specified by the data values of the model attributes.

[options="header",cols="3*<",title="Part Description Population",width="50%"]
|===========
|Manufacturer       |Model Number       |Color
|"Acme"             |"S27"              |22
|"Sunshine"         |"B42"              |47
|===========

[options="header",cols="3*<",title="Part Population",width="50%"]
|===========
|Manufacturer       |Model Number       |Serial Number
|"Acme"             |"S27"              |"A001"
|"Acme"             |"S27"              |"A002"
|"Sunshine"         |"B42"              |"B034"
|"Sunshine"         |"B42"              |"B037"
|===========

For the platform classes,
................................................................................
for run-time creation.
Note, that at run time, there is no distinction between initial instances
and unallocated instances.
So, deleting an instance that was specified as an initial instance
makes its memory available to be used to create an instance at run-time.

=== Populating associative classes



















Populating associative classes




=== Populating associative classes in reflexive relationships

Populating associative classes in reflexive relationships



























































// vim:syntax=asciidoc:







|





|








>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>







 







>
>
>
>
>
>
>
>
>
>
>
>





|



<
>
>
|
|
<
|
|
|
|







 







>
>
>
>







 







|






>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>







 







|






|







 







>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
|
>
>
>


>
|
>
>
>
>
>
>
>
>

>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>




463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
...
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606

607
608
609
610

611
612
613
614
615
616
617
618
619
620
621
...
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
...
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
...
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
....
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
it is obtained by navigating the relationship.

=== Translating relationships

Model relationships represent constraints on the number and conditionality
of how class instances are associated with each other in the real world.
Fundamentally,
the multiplicity and conditionality of a relationship restrict
membership in the underlying set that class instances represent.
In a model,
relationships are realized by referential attributes having values
equal to those of identifying attributes.
Since `micca` supplies a unique identifier for class instances,
those identifiers are used to realize relationships for
platform classes.

`Micca` supports translating the relationships by:

* Generating data structures and providing operations
  to handle the references for instances that participate in a relationship.
* Verifying at run-time that the constraints implied by the relationship
  are not violated by the execution of domain activities.

==== Direction of a relationship traversal

In a model,
relationships do not have an inherent _direction_ associated with them.
It is possible to navigate the relationship in either direction starting
with an appropriate instance of a participating class.
However,
for translation purposes it is convenient to give relationships a direction.
The concept of a direction of a relationship shortens the amount of
specification necessary to describe how navigating from one instance
to other instances across a relationship.
It is not generally necessary to specify which class the navigation arrives
at since that information is known to `micca` by the specifications
in the platform model.
A direction concept also helps disambiguate some situations that arise
in reflexive associations.

The direction of a relationship is determined by:

* For simple associations where referential attributes in one class are
  used to realize the association,
  the forward direction is from the referring class (_i.e._ the class that
  contains the referential attributes) to the referenced class.
* For generalization relationships, the forward direction is from
  subclass to superclass, which is also the direction of referring
  class to referenced class.
* For relationships realized by associative classes,
  there is no inherent direction and a direction is chosen by the
  Translator.

`Micca` uses some additional syntax to specify the direction of
relationship traversal.
The syntax to navigate a relationship in the _forward_ direction,
is simply the name of the relationship, _e.g._ `R42`.
The syntax to navigate in the _backward_ direction prepends a tilde (`~`)
character to the name of the relationship, _e.g._ `~R42`.

The following cases arise:

* For simple associations, forward and backward traversal are unambiguous
  and results in selecting instances of the participating classes.
* For generalizations, forward navigation always yields _exactly one_ instance
  of the superclass.
  Backward navigation must include the name of a participating subclass.
  Consider a generalization, called *R19*, which has a superclass named *Lamp*
  and a subclass named *Table_Lamp*.
  Navigation from an instance of *Lamp*  to an instance of *Table_Lamp*
  is specified as +
  `{R19 Table_Lamp}`.
  The result of such navigation yields _at most one_ instance of *Table_Lamp*.
* For associative classes, four situation arise.
  ** Navigating in the forward direction from one class to its corresponding
     class uses the usual relationship name, _e.g._ `R13`.
  ** Navigating in the backward direction between the two participating
     classes uses the tilde prefixed name, _e.g._ `~R13`.
  ** Navigating forward to the associative class is specified by
     including the associative class name, _e.g._ +
     `{R13 Product_Selection}`.
  ** Navigating backward to the associative class is specified by
     both a tilde prefixed relationship name and the name of the
     associative class, _e.g._ `{~R13 Product_Selection}`.


==== Translating simple associations

Consider the following model fragment:

["plantuml",title="Simple association"]
----
................................................................................
----

This fragment shows an _at least one_ to _one_ association between
a *Warehouse Clerk* and a *Warehouse*.
This situation would be translated as:

----
class Warehouse {
    attribute Name {char[50]}
    attribute Location {char[50]}
}

class Warehouse_Clerk {
    attribute Clerk_ID unsigned
    attribute Clerk_Name {char[50]}

    # Referring class for R25
}

association R25 Warehouse_Clerk 1..*--1 Warehouse
----

The `association` command defines the characteristics of the
association between classes.
The syntax of the multiplicity and conditionality, _i.e._ **1..\*--1**,
is intended to be mnemonic of the notation used in the
XUML class diagram.
Note this argument has no embedded whitespace.

The order of the classes in the command is in the forward direction
of traversal.
The class which contains the referential attributes (*Warehouse_Clerk*)
appears first in the command arguments.

In this example, navigating from an instance of *Warehouse_Clerk* across
*R25* yields _exactly one_ instance of *Warehouse* and
navigating from an instance of *Warehouse* across *~R25* yields
_at least one_ instance of *Warehouse*.

==== Translating associative classes

Some associations require an associative class to realize the mapping
between participating instances.
An association class is required for:

................................................................................
(P, SC) .. PS : R14
@enduml
----

This association would be translated as:

----
class Product_Selection {
    attribute Quantity unsigned
}

association R14 -associator Product_Selection Product 1..*--0..* Shopping_Cart
----

==== Translating generalizations

Consider the following model fragment:

................................................................................
----

This is a generalization relationship.
In XUML,
a generalization does _not_ represent inheritance.
Rather, it represents a disjoint set partitioning.
Strictly speaking,
the relationship graphic should be annotated with `{disjoint, complete}`, but
since this is the only type of generalization used in XUML, the
annotation is usually dropped as graphical clutter.

This situation would be translated as:

----
class Product {
    attribute Name {char[25]}
    attribute Unit_Price Money_t

    # superclass of R22
}

class Book_Product {
    attribute Title {char[25]}

    # subclass of R22
}

class Recording_Product {
    attribute Run_Time Duration_t

    # subclass of R22
}

generalization R22 Product Book_Product Recording_Product
----

_i.e._ we use the `generalization` command giving the name of the relationship,
the name of the superclass and the names of the subclasses which participate
in the generalization.

................................................................................
assume the analysis model has specified the following initial instance
population.
Here the data is presented in tabullar form and the population is
entirely specified by the data values of the model attributes.

[options="header",cols="3*<",title="Part Description Population",width="50%"]
|===========
|Manufacturer {I}   |Model Number {I}   |Color
|"Acme"             |"S27"              |22
|"Sunshine"         |"B42"              |47
|===========

[options="header",cols="3*<",title="Part Population",width="50%"]
|===========
|Manufacturer {I,R1}|Model Number{I,R1} |Serial Number
|"Acme"             |"S27"              |"A001"
|"Acme"             |"S27"              |"A002"
|"Sunshine"         |"B42"              |"B034"
|"Sunshine"         |"B42"              |"B037"
|===========

For the platform classes,
................................................................................
for run-time creation.
Note, that at run time, there is no distinction between initial instances
and unallocated instances.
So, deleting an instance that was specified as an initial instance
makes its memory available to be used to create an instance at run-time.

=== Populating associative classes

Specifying the population of an associative class requires a different
format.
Recall that an associative class has references to the two other classes
that participate in the association.
So when we give an initial value for references, we must give a list
of values.
Consider the previous example of the *Product_Selection* class.
It population might appear as:

----
class Product_Selection {
    instance ps1 R14 {Product prod1 Shopping_Cart sc1} Quantity 1
    instance ps2 R14 {Product prod2 Shopping_Cart sc2} Quantity 2

    # ...
}
----

So for an associative class,
specifing the references needed for a relationship involves specifying
a set of pairs giving the class name and the instance name of each
participating class instance.

=== Populating associative classes in reflexive relationships

The previous scheme for populating associative classes does not
work when the association is reflexive.
In a reflexive association,
both instances participating in the association are from the same class.
We cannot use class names alone to distinguish reference.
In the case of reflexive associative classes,
we use `forward` and `backward` to specify how the references are
stored.
For example the following simple reflexive association,

["plantuml",title="Reflexive Association"]
----
@startuml
hide methods
hide circle
skinparam class {
    BackgroundColor yellow
    BorderColor black
    LineColor black
    ArrowColor black
}

class Component {
    Component ID : unique ID
}

class Sequence {
    Next Component : unique ID {I,R24}
    Last Component : unique ID {I2,R24}
}

Component "0..1" - "0..1" Component
(Component, Component) .. Sequence : R24
@enduml
----

might be populated as:

----
class Component {
    instance c1 Component_ID 1
    instance c2 Component_ID 2
    instance c3 Component_ID 3
    instance c4 Component_ID 4
}

class Sequence {
    instance s1 R24 {backward c1 forward c2}
    instance s2 R24 {backward c2 forward c3}
    instance s3 R24 {backward c3 forward c4}
}
----

This population creates a chain of *Component* instances.
Navigating from *c2* in the forward direction will select the *c3*
instance.
Navigating from *c1* in the backward direction selects no instances.



// vim:syntax=asciidoc: