diff --git a/docs/reading/OEMS.html b/docs/reading/OEMS.html index f158c1d..c8d2819 100644 --- a/docs/reading/OEMS.html +++ b/docs/reading/OEMS.html @@ -15,7 +15,7 @@ }/*]]>*/

Object Event Modeling and Simulation

For Information Systems Engineering and for
Discrete Event Simulation Engineering
Gerd Wagner G.Wagner@b-tu.de

Copyright © 2023-24 Gerd Wagner

Draft version, published - 2024-06-20.

business-process-gearwheels

Abstract

This book explains how + 2024-06-25.

business-process-gearwheels

Abstract

This book explains how to make models for Information Systems engineering and for Discrete Event Simulation engineering using the Unified Modeling Language (UML) and the Discrete Event Process Modeling @@ -26,9 +26,11 @@ Event Scheduling).

The modeling concepts of OEM&S, in particular the concepts of objects, events and activities, are ontologically grounded on corresponding categories - of the Unified Foundational Ontology (UFO).

Table of Contents

List of Figures

Table of Contents

List of Figures

  • 3-1. An OE class diagram providing an information design + for the Public Library IS.
  • 3-2. The abstract syntax of the OE Modeling + Language based on KerML metaclasses.
  • 6-1. A basic DPMN Process Diagram showing an + OEG.
  • 6-2. A basic OE class model defining an object type and three event types.
  • 7-1. Introducing an activity type in a conceptual information model of a single workstation @@ -55,7 +57,7 @@ nmrOfRooms and nmrOfDoctors.
  • 8-12. A process design model based on the information design model of Figure 8-11.
  • 8-13. An OE class model with resource object types for modeling resource roles and pools.
  • 8-14. A process design model based on the - information design model of Figure 8-13.
  • 8-15. Any resource type + information design model of Figure 8-13.
  • 8-15. Any resource type R extends the pre-defined object type Resource
  • 8-16. A simplified version of the model of Figure 8-13
  • 8-17. An OE Class Diagram modeling a single workstation system with resource-constrained processing activities @@ -587,13 +589,16 @@ opposed to the underlying conceptual information model shown in Section 2.1.3, the following information design model provides attribute ranges, standard identifiers, mandatory value and key constraint declarations (by default, in UML, attributes are mandatory and - single-valued).

    Notice also the notation "/date" in the attribute - compartments of the activity classes BookLending and - BookTakeBack, where the slash prefix indicates that the attribute - date is a derived attribute (its value can be automatically computed - from the implicit occurrenceTime attribute).

    The class model - expressed above with the visual modeling language of OE class diagrams can also be expressed - textually, following the syntax of SysML, in the following way:

    1
+  single-valued).
    Figure 3-1. An OE class diagram providing an information design
+  for the Public Library IS.
    Notice also
+  the notation "/date" in the attribute compartments of the activity classes
+  BookLending and BookTakeBack, where the slash prefix indicates
+  that the attribute date is a derived attribute (its value can be
+  automatically computed from the implicit occurrenceTime
+  attribute).
    The class model expressed above with the visual modeling
+  language of OE class diagrams can also be
+  expressed textually, following the syntax of SysML, in the following
+  way:
    1
 2
 3
 4
@@ -675,46 +680,29 @@
   attribute date : Date;
   attribute libraryUser : LibraryUser;
   attribute bookCopies : BookCopy[1..*];
-}
    An OE class model is based on a
-  set of data types (such as Integer, String, etc.), which are
-  special types. Object types, event types and associations are
-  classifiers, which are also special types.
+}

    3.1.1. Formal Semantics of OE Class Models

    An OE class model is based on a + set of data types (such as Integer, String, etc.). Data types, + object types, event types and associations are classifiers, which + are types. Also, features, such as attributes, are types. Specialization is a relationship between types that is subject to certain constraints (such as the constraint that object types can only - specialize other object types).

    An OE class model (based on a set of data types DT) - is a 9-tuple ⟨ OT, ET, Attr, dom, rng, Ass, ends, mul, sup ⟩ specifying a - vocabulary consisting of a set of object and event type - names OT and ET, a set of attribute names Attr - and a set of association names Ass, as well as of functions - dom and rng for assigning a domain and a - range (or codomain) to an attribute, a function - ends for assigning a tuple of object types to each association (the - object types participating in it), a function mul for assigning - multiplicities both to attributes and associations, and a function - sup for assigning supertypes to types.

    If an OE class model has only binary associations, it - can be reduced to an an association-free model ⟨ OT, ET, Attr, dom, - rng, mul, sup ⟩ by expressing/replacing the associations with the help of - corresponding reference attributes.

    An interpretation of an - (association-free) OE class model is a ⟨ - O, E, Attr, dom, rng, Ass, ends, mul, sup ⟩

    3.2. Formal Semantics of OE Class Models

    An OE class model is based on a - set of data types (such as Integer, String, etc.), which are - special types. Object types, event types and associations are - classifiers, which are also special types. - Specialization is a relationship between types that is subject to - certain constraints (such as the constraint that object types can only - specialize other object types).

    A multiplicity is an - expression l..u consisting of a lower bound l being a - non-negative integer and an upper bound u being either a positive - integer or the special symbol ∗ standing for unbounded such that - either u = ∗ or l ≤ u. Whenever the lower bound - l of a multiplicity is greater than 0, it defines a minimum - cardinality constraint ("there must be at least l values"). Whenever - the upper bound u of a multiplicity is not ∗ (unbounded), it defines - a maximum cardinality constraint ("there must be at most u values"). -

    An OE class model (based on a - finite set of data types DT) is a 9-tuple ⟨ OT, ET, attr, rng, - OAss, PAss, ends, mul, sup ⟩ specifying

      -
    1. a vocabulary ⟨ OT, ET, attr,OAss, + specialize other object types). The metaclasses Type, + Specialization, Classifier, and Feature are defined in + the Kernel Modeling + Language.

      Figure 3-2. The abstract syntax of the OE Modeling + Language based on KerML metaclasses.
      ???

      A + multiplicity is an expression l..u consisting of a + lower bound l being a non-negative integer and an upper bound + u being either a positive integer or the special symbol ∗ standing + for unbounded such that either u = ∗ or l ≤ u. + Whenever the lower bound l of a multiplicity is greater than 0, it + defines a minimum cardinality constraint ("there must be at least l + values"). Whenever the upper bound u of a multiplicity is not ∗ + (unbounded), it defines a maximum cardinality constraint ("there must be at + most u values").

      An OE class + model (based on a finite set of data types DT) is a 10-tuple

      ⟨ OT, ET, attr, rng, OAss, + PAss, ends, mul, muls, sup ⟩

      specifying

        +
      1. a vocabulary ⟨ OT, ET, attr, OAss, PAss ⟩ consisting of finite sets of object and event type names OT and ET, a finite set of composite attribute names of the form T-a where T ∈ @@ -736,27 +724,39 @@ association from PAss;
      2. a function mul for assigning multiplicities both to - attributes and association ends;
        3. + attributes and association ends (mul also expresses history + multiplicities for event class association ends of participation + associations); + +
      3. a function muls for assigning snapshot + multiplicities to event class association ends of participation + associations;
      4. a function sup for assigning supertypes to types such that for any object type T, all its supertypes T' ∈ - sup(T) are also object types (and likewise for event types).
        5. + sup(T) are also object types (and likewise for event types) and + attr(T') ⊆ attr(T);

      If an OE class model has only binary object type associations, it can be reduced to an - association-free model ⟨ OT, ET, attr, rng, mul, sup ⟩ by - expressing/replacing all associations with the help of corresponding - reference attributes.

      An - interpretation of an association-free OE class model is a sextuple ⟨ c, - Obj, Evt, type, occt, I ⟩ such that

        -
      1. c is the current time,
        2. - -
      2. Obj is a finite set of currently existing objects,
        3. + association-free model as a septuple

        ⟨ OT, ET, attr, rng, mul, muls, + sup ⟩

        by expressing/replacing all associations with the help of + corresponding reference attributes.

        An + interpretation of an association-free OE class model is a septuple

        I = ⟨ T, c, Obj, + Evt, type, occt, I ⟩

        such that

          +
        1. T is a linearly ordered set of time instants and c ∈ + T is the current time,
          2. + +
        2. Obj is a finite set of (currently existing) objects, for + which it is assumed that they have been existing in the past (and will + exist in the future),
        3. Evt is a finite set of (past or current) events with occt(e) ≤ c for all e ∈ Evt,
          4. -
        4. type is a function that assigns an object type to each object - from Obj and an event type to each event from Evt,
          5. +
        5. types is a function that assigns one or more object types to + each object from Obj and one or more event types to each event + from Evt (types assigns its direct types to an + entity,
        6. occt is a function that assigns an occurrence time t ≤ c to each event from Evt, and
          7. @@ -765,34 +765,165 @@ function for the vocabulary ⟨ OT, ET, attr ⟩ of the class model such that

          1. I(O) ⊆ Obj for all O ∈ - OT,
            2. + OT.
          2. I(E) ⊆ Evt for all E ∈ - ET,
            3. + ET. -
          3. An attribute is interpreted as a function from entities to value - sets: I(T-a) : I(T) - → 2I(R) for all attributes +

          4. An attribute T-a with multiplicity + mul(T-a) = ⟨ l, u ⟩ is + interpreted as a function from entities to value sets: + I(T-a) : I(T) → + 2I(R) for all attributes T-a with T ∈ OT ∪ ET, a ∈ attr(T) and R = rng(T-a), such that for any entity e ∈ - I(T), the cardinality of its attribute value - set I(T-a)(e) is greater than - l and smaller than u where ⟨ l, u ⟩ = - mul(T-a).

            5. - -
          5. For any type T ∈ OT ∪ ET and any of its - supertypes T' ∈ sup(T), + I(T) and its attribute value set val = + I(T-a)(e),

              +
            1. the cardinality of val is greater than l and + smaller than u,
              2. + +
            2. if the attribute has a snapshot multiplicity + muls(T-a) = ⟨ + ls, us ⟩, that is, if the + attribute represents the event class association end of a + participation association, then if ls> 0, + the cardinality of the set of current events in the attribute's + value set, card = #{ evt ∈ val | + occt(evt) = c}, is greater than + ls, and if us≠ ∗, then + card ≤ us.
              3. +
            6. + +
          6. For any entity type T ∈ OT ∪ ET and any of + its supertypes T' ∈ sup(T), I(T) ⊆ I(T').

        Together with a variable value assignment α : V → - Obj ∪ Evt for a finite set of variables V, an - interpretation I allows to interpret expressions of the form + Obj ∪ Evt for a finite set of entity variables V, an + interpretation I allows to interpret expressions of the form v.a where v is an entity variable and a is a (local) attribute name:

        Iα(v.a) = I(T-a)(e) where e = α(v) - and T = type(e)

    3.3. Process Design for IS Engineering

    In a process design model for a process-supportive IS, + and T ∈ types(e) with a ∈ attr(T)

    Whenever + the range of an attribute T-a is an entity type T', we + can interpret expressions of the form + v.a1.a2 where + a1 ∈ attr(T) and a2 ∈ + attr(T'), which are called path expressions, by iterating + the attribute function application. While it is obvious how this works for + the case of single-valued attributes a1, in the case of + multi-valued attributes a1, all resulting value sets are + simply merged together. In this way, we can form path expressions of any + length greater than zero.

    Finally, we can define how an interpretation + of a class model Iα, together with a variable value + assignment α for a set of data and entity variables, satisfies a logical + formula F formed with atomic formulas that are connected with the + help of the usual logical operations, which is symbolically expressed as + Iα ⊨ F. The base case of atomic formulas includes + the following two forms:

      +
    1. Classification atoms have the form C(x) where + C is a classifier. Iα ⊨ C(x) iff + α(x) ∈ I(C).
      2. + +
    2. Comparison atoms have the form expr1 o + expr2 where each exprk is either a + data literal (from one of the underlying datatypes), a variable, or a + path expression, and o is one of the usual comparison predicates (=, ≠, + <, ≤, >, ≥). Iα ⊨ expr1 o + expr2 iff ⟨ + Iα(expr1), + Iα(expr2) ⟩ ∈ + I(o), where I(o) is the binary + relation that interprets the comparison predicate.
      3. +

    Complex logical formulas formed with the logical operators ¬, ∧, + ∨, →, ∀, ∃ are satisfied by an interpretation in the usual way.

    3.1.2. Integrity Constraints

    An + OE class model like the one presented in + Figure 3-1 defines the following types of + (integrity) constraints:

    +
    Range Constraints
    + +

    require that an attribute must have a value from the value space + of the type that has been defined as its range. For instance, a value of + the attribute Person::birthDate must be a date. These (implicit) + constraints are expressed in a class diagram by specifying a range for + all attributes.

    + +
    Mandatory Value Constraints
    + +

    require that an attribute must have a value. These constraints + are expressed in a class diagram with the help of an attribute + multiplicity with a lower bound greater than 0. For instance, in the + class diagram to the right, an instance of Person must have a + name and a birthDate, but need not have a + biography. Notice that the default multiplicity of an attribute + is [1], implying that it is mandatory and single-valued.

    + +
    Cardinality Constraints
    + +

    apply to multi-valued attributes, only, and require that the + cardinality of a multi-valued attribute's value set is not less than a + given minimum cardinality or not greater than a given maximum + cardinality, as expressed by the attribute's multiplicity.

    +

    In addition to these types of constraints, an OE class model may specify two further, more + general, types of constraints:

      +
    1. a set of classifier invariants + CInvar, which are ordered pairs of a classifier C and a + logical formula, or Boolean expression, F(x) with one free + variable x stating that F(i) holds for all i + from the extent of C;
      2. + +
    2. a set of global invariants GInvar, + which are logical sentences, or Boolean expressions, without free + variables.
      3. +

    In a class diagram, classifier invariants are expressed within a + constraint rectangle that is attached to a classifier with the help of a + dashed line. Global invariants can be expressed within a constraint + rectangle in a corner of the diagram.

    Interpretations of an OE class model are required to satisfy all of + its invariants:

      +
    1. I ⊨ ∀x: C(x) → F(x) for + all classifier invariants ⟨C, F(x)⟩ ∈ + CInvar.
      2. + +
    2. I ⊨ F for all F ∈ GInvar.
      3. +

    There are several types of very common classifier invariants that + can be expressed in a class diagram in the simplified way of an attribute + annotation in curly braces appended to the attribute declaration:

    +
    Uniqueness Constraints (also called 'Key Constraints')
    + +

    are expressed with the keyword "key" and require that the value + of an attribute a is unique among all instances of its domain: + F(x) ≡ ∀y: C(y) → x.a ≠ + y.a.

    + +
    Interval Constraints
    + +

    are expressed with the keywords "min" and "max" and require that + the value of a numeric attribute a must be in a specific interval + [min,max]: F(x) ≡ min ≤ x.a ∧ x.a ≤ + max.

    + +
    Pattern Constraints
    + +

    are expressed with the keyword "pattern" and require that a + string attribute's value must match a certain pattern defined by a + regular expression.

    +

    The attribute annotation keyword "id" implies that the attribute + is unique and mandatory, and that its values e.a are used as + standard identifiers for the entities e.

    Examples of global + invariants are the following:

      +

    1. Each Departure event must be preceded by a corresponding + Arrival event:

      ∀x [ + Departure(x) → ∃y [ Arrival(y) ∧ + y.libraryUser = x.libraryUser ∧ occt(y) < + occt(x) ∧ ¬∃z [Departure(z) ∧ occt(z) + < occt(x) ∧ occt(z) > occt(y) ]]]

      2. + +
    2. For each book copy involved in a BookTakeBack activity there + must be a corresponding preceding BookLending activity involving + that book copy.
      3. +

3.2. Process Design for IS Engineering

In a process design model for a process-supportive IS, we refine a conceptual process model by adding all details needed for obtaining a computationally complete definition of the business processes to be supported. An important question is whether these processes consist of @@ -848,13 +979,13 @@ average and maximal length of the waiting line at the service desk, then we can abstract away from the object type Person and the attributes Book::title, Book::year, and - Book::authors described in the domain model shown in Section 2.1.2). We may even drop the object types + Book::authors described in the domain model shown in Section 2.1.2. We may even drop the object types Book and BookCopy altogether, if we just count the number of books lended and taken back in the simulation design model.

  • If the purpose is to support operational decision making, - then a digital twin design model has to be made an + then a digital twin design model has to be made as an extension of the IS design model. For instance, if the purpose of our library simulation is to support making decisions like testing if a library clerk can take a one hour break without taking the risk of @@ -1567,10 +1698,10 @@ unreliable semantics of certain simulation models in favor of performance.

    • 6.2. Object Event Graphs

    The following basic DPMN diagram shows an OEG defining a process pattern that is instantiated by the above discrete event process - example.

    Figure 6-1. A basic DPMN Process Diagram showing an + example.

    Figure 6-1. A basic DPMN Process Diagram showing an OEG.

    This process model is based on the following Object Event (OE) class - model:

    Figure 6-2. A basic OE + model:

    Figure 6-2. A basic OE class model defining an object type and three event types.

    Notice that the multiplicity 1 (standing for "exactly one") at the association end touching the object class @@ -2367,7 +2498,7 @@ role and resource pool properties (association ends stereotyped «res» and «pool»). Such object types can be categorized as «resource type» with the implied meaning that they inherit a resource status attribute from a - pre-defined class Resource, as shown in Figure 8-16.

    Figure 8-15. Any resource type + pre-defined class Resource, as shown in Figure 8-16.

    Figure 8-15. Any resource type R extends the pre-defined object type Resource

    The introduction of resource types to OEM class models allows simplifying models by dropping the diff --git a/docs/reading/OEMS_files/OEML-Metamodel.svg b/docs/reading/OEMS_files/OEML-Metamodel.svg new file mode 100644 index 0000000..5d3325d --- /dev/null +++ b/docs/reading/OEMS_files/OEML-Metamodel.svg @@ -0,0 +1,1721 @@ + + + + + + + + + Page-1 + + + + + + + + + + + + + + + + + + Class + + Sheet.3 + + + Sheet.4 + + + Sheet.5 + + + Sheet.6 + + + Operations + + + Attributes + + + Name + Element + + + + Element + + Parameters + + + + + + + + + + + + + + + + + + + Class.11 + + Sheet.12 + + + Sheet.13 + + + Sheet.14 + + + Sheet.15 + + + Operations + + + Attributes + + + Name + Relationship + + + + Relationship + + Parameters + + + + + + + + + + + + + + + + + + + Class.20 + + Sheet.21 + + + Sheet.22 + + + Sheet.23 + + + Sheet.24 + + + Operations + + + Attributes + + + Name + Namespace + + + + Namespace + + Parameters + + + + + + + + + + + + + + + + Generalization + + Discriminator + + + + + + + + + + + + + + + + + + + Generalization.31 + + Discriminator + + + + + + + + + + + + + + + + + + + + + + + + Binary Association + + end1_name + source + + + source + + end1_mp + * + + + * + + end2_name + + + end2_mp + * + + + * + + + + + + + + + + + + + + + + + + + + + + + Binary Association.38 + + end1_name + target + + + target + + end1_mp + * + + + * + + end2_name + + + end2_mp + * + + + * + + + + + + Sheet.43 + + + + Sheet.44 + KerML Root Layer + + + + KerMLRoot Layer + + Sheet.45 + + + + Sheet.46 + + + + + + + + + + + + + + + + + + + Class.47 + + Sheet.48 + + + Sheet.49 + + + Sheet.50 + + + Sheet.51 + + + Operations + + + Attributes + + + Name + Type + + + + Type + + Parameters + + + + + + + + + + + + + + + + Generalization.56 + + Discriminator + + + + + + + + + + + + + + + + + + + + + + Class.58 + + Sheet.59 + + + Sheet.60 + + + Sheet.61 + + + Sheet.62 + + + Operations + + + Attributes + + + Name + Specialization + + + + Specialization + + Parameters + + + + + + + + + + + + + + + + Generalization.67 + + Discriminator + + + + + + + + + + + + + + + + + + + + + + + + Binary Association.69 + + end1_name + general (redefines target} + + + general (redefines target} + + end1_mp + 1 + + + 1 + + end2_name + + + end2_mp + * + + + * + + + + + + + + + + + + + + + + + + + + + + + Binary Association.74 + + end1_name + + + end1_mp + 1 + + + 1 + + end2_name + + + end2_mp + * + + + * + + + + + + Sheet.79 + + + + Sheet.80 + + + + + + + + + + + + + + + + + + + Class.81 + + Sheet.82 + + + Sheet.83 + + + Sheet.84 + + + Sheet.85 + + + Operations + + + Attributes + + + Name + Classifier + + + + Classifier + + Parameters + + + + + + + + + + + + + + + + Generalization.90 + + Discriminator + + + + + + + + + + + + + + + + + + + + + + Class.92 + + Sheet.93 + + + Sheet.94 + + + Sheet.95 + + + Sheet.96 + + + Operations + + + Attributes + + + Name + Feature + + + + Feature + + Parameters + + + + + + + + + + + + + + + + Generalization.101 + + Discriminator + + + + + + + + + + + + + + + + + + + + + + Class.103 + + Sheet.104 + + + Sheet.105 + + + Sheet.106 + + + Sheet.107 + + + Operations + + + Attributes + + + Name + Datatype + + + + Datatype + + Parameters + + + + + + + + + + + + + + + + Generalization.112 + + Discriminator + + + + + + + + + + + + + + + + + + + + + + Class.114 + + Sheet.115 + + + Sheet.116 + + + Sheet.117 + + + Sheet.118 + + + Operations + + + Attributes + + + Name + EntityType + + + + EntityType + + Parameters + + + + + + + + + + + + + + + + Generalization.123 + + Discriminator + + + + + + + + + + + + + + + + + + + + + + Class.125 + + Sheet.126 + + + Sheet.127 + + + Sheet.128 + + + Sheet.129 + + + Operations + + + Attributes + + + Name + ObjectAssociation + + + + ObjectAssociation + + Parameters + + + + + + + + + + + + + + + + Generalization.134 + + Discriminator + + + + + + + Sheet.136 + + + + Sheet.137 + KerML Core Layer + + + + KerMLCore Layer + + + + + + + + + + + + + + + + + Class.138 + + Sheet.139 + + + Sheet.140 + + + Sheet.141 + + + Sheet.142 + + + Operations + + + Attributes + + + Name + EventType + + + + EventType + + Parameters + + + + + + + + + + + + + + + + + + + Class.149 + + Sheet.150 + + + Sheet.151 + + + Sheet.152 + + + Sheet.153 + + + Operations + + + Attributes + + + Name + ParticipationAssociation + + + + ParticipationAssociation + + Parameters + + + + + + + + + + + + + + + + Generalization.158 + + Discriminator + + + + + + + + + + + + + + + + + + + + + + Class.160 + + Sheet.161 + + + Sheet.162 + + + Sheet.163 + + + Sheet.164 + + + Operations + + + Attributes + + + Name + Attribute + + + + Attribute + + Parameters + + + + + + + + + + + + + + + + Generalization.169 + + Discriminator + + + + + + + Sheet.171 + specific {redefines source} + + + + specific {redefines source} + + + + + + + + + + + + + + + + + + + Binary Association.172 + + end1_name + type + + + type + + end1_mp + 1 + + + 1 + + end2_name + + + end2_mp + * + + + * + + + + + + Sheet.177 + + + + + + + + + + + + + + + + + + + Class.178 + + Sheet.179 + + + Sheet.180 + + + Sheet.181 + + + Sheet.182 + + + Operations + + + Attributes + + + Name + FeatureTyping + + + + FeatureTyping + + Parameters + + + + + + + + + + + + + + + + + + + + + Binary Association.187 + + end1_name + typedFeature + + + typedFeature + + end1_mp + 1 + + + 1 + + end2_name + + + end2_mp + * + + + * + + + + + + Sheet.193 + + + + + + + + + + + + + + + + + + + + + Binary Association.194 + + end1_name + attributes + + + attributes + + end1_mp + * + + + * + + end2_name + domain + + + domain + + end2_mp + 1 + + + 1 + + + + + + Sheet.192 + + + + Sheet.199 + + + + + + + + + + + + + + + + + + + Class.200 + + Sheet.201 + + + Sheet.202 + + + Sheet.203 + + + Sheet.204 + + + Operations + + + Attributes + + + Name + ObjectType + + + + ObjectType + + Parameters + + + + + + + + + + + + + + + + + + + + + Binary Association.147 + + end1_name + + + end1_mp + * + + + * + + end2_name + + + end2_mp + 1 + + + 1 + + + + + + + + + + + + + + + + + + + + + + + Binary Association.212 + + end1_name + + + end1_mp + * + + + * + + end2_name + + + end2_mp + 1 + + + 1 + + + + + + + + + + + + + + + + + + Generalization.217 + + Discriminator + + + + + + + + + + + + + + + + + + + Generalization.219 + + Discriminator + + + + + + + + + + + + + + + + + + + + + + + + Binary Association.221 + + end1_name + + + end1_mp + 2..* + + + 2..* + + end2_name + + + end2_mp + * + + + * + + + + + + Sheet.226 + + + + Sheet.227 + + + + + + + + + + + + + + + + + + + Class.228 + + Sheet.229 + + + Sheet.230 + + + Sheet.231 + + + Sheet.232 + + + Operations + + + Attributes + + + Name + DataAttribute + + + + DataAttribute + + Parameters + + + + + + + + + + + + + + + + + + + + + Binary Association.237 + + end1_name + + + end1_mp + * + + + * + + end2_name + range + + + range + + end2_mp + 1 + + + 1 + + + + + + Sheet.242 + + + + + + + + + + + + + + + + + + + Class.243 + + Sheet.244 + + + Sheet.245 + + + Sheet.246 + + + Sheet.247 + + + Operations + + + Attributes + + + Name + ReferenceAttribute + + + + ReferenceAttribute + + Parameters + + + + + + + + + + + + + + + + Generalization.252 + + Discriminator + + + + + + + + + + + + + + + + + + + Generalization.254 + + Discriminator + + + + + + + + + + + + + + + + + + + + + + + + Binary Association.256 + + end1_name + + + end1_mp + * + + + * + + end2_name + range + + + range + + end2_mp + 1 + + + 1 + + + + + + Sheet.261 + + + + diff --git a/docs/reading/OEMS_files/PublicLibrary-Person__IDM_IS.svg b/docs/reading/OEMS_files/PublicLibrary-Person__IDM_IS.svg new file mode 100644 index 0000000..c2e87a4 --- /dev/null +++ b/docs/reading/OEMS_files/PublicLibrary-Person__IDM_IS.svg @@ -0,0 +1,70 @@ + + + + + + + + + Page-1 + + + + + + + + + + + + + + + + + + Class + + Sheet.3 + + + Sheet.4 + + + Sheet.5 + + + Sheet.6 + + + Operations + + + Attributes + id[1] : Integer {id} name[1] : String birthDate[1] : Date bio... + + + + id[1] : Integer {id}name[1] : StringbirthDate[1] : Datebiography[0..1] : String + + Name + «object type»Person + + + + «object type»Person + + Parameters + + + + diff --git a/docs/reading/OEMS_files/PublicLibrary_IDM_IS.svg b/docs/reading/OEMS_files/PublicLibrary_IDM_IS.svg index 5235370..393c6fc 100644 --- a/docs/reading/OEMS_files/PublicLibrary_IDM_IS.svg +++ b/docs/reading/OEMS_files/PublicLibrary_IDM_IS.svg @@ -1,6 +1,6 @@ - + - + Page-1 @@ -35,16 +35,16 @@ Class - + Sheet.3 - + Sheet.4 - + Sheet.5 - + Sheet.6 @@ -54,16 +54,16 @@ Attributes id[1] : Integer {id} name[1] : String birthDate[1] : Date bio... - - - id[1] : Integer {id}name[1] : StringbirthDate[1] : Datebiography[0..1] : String + + + id[1] : Integer {id}name[1] : StringbirthDate[1] : Datebiography[0..1] : String Name «object type»Person - - - «object type»Person + + + «object type»Person Parameters @@ -85,16 +85,16 @@ Class.11 - + Sheet.12 - + Sheet.13 - + Sheet.14 - + Sheet.15 @@ -104,16 +104,16 @@ Attributes isbn : String {id} title : String year : Integer - - - isbn : String {id}title : Stringyear : Integer + + + isbn : String {id}title : Stringyear : Integer Name «object type» Book - - - «object type»Book + + + «object type»Book Parameters @@ -123,15 +123,15 @@ - - + + - + - + @@ -144,25 +144,25 @@ end1_mp * - - * + + * end2_name authors - - authors + + authors end2_mp * - - * + + * - + - + @@ -179,38 +179,38 @@ Class.39 - + Sheet.40 - + Sheet.41 - + Sheet.42 - + Sheet.43 Operations onActivityEnd() - + Attributes id : Integer {id} /date : Date - - - id : Integer {id}/date : Date + + + id : Integer {id}/date : Date Name «activity type» BookLending - - - «activity type»BookLending + + + «activity type»BookLending Parameters @@ -232,38 +232,38 @@ Class.121 - + Sheet.49 - + Sheet.50 - + Sheet.51 - + Sheet.52 Operations onActivityEnd() - + Attributes id : Integer {id} /date : Date - - - id : Integer {id}/date : Date + + + id : Integer {id}/date : Date Name «activity type» BookTakeBack - - - «activity type»BookTakeBack + + + «activity type»BookTakeBack Parameters @@ -280,8 +280,8 @@ - - + + @@ -290,12 +290,12 @@ end1_name - + end1_mp - 0..1 + * - - 0..1 + + * end2_name @@ -303,95 +303,95 @@ end2_mp 1..* - - 1..* + + 1..* - + - + - - + + - - - - + + + + Binary Association.99 - + end1_name - + end1_mp - 0..1 + * - - 0..1 - + + * + end2_name - + end2_mp 1..* - - 1..* + + 1..* - + - + - - + + - - - - + + + + Binary Association.104 - + end1_name - + end1_mp - 0..1 + * - - 0..1 - + + * + end2_name - + end2_mp 1 - - 1 + + 1 - + - + @@ -408,16 +408,16 @@ Class.27 - + Sheet.73 - + Sheet.74 - + Sheet.75 - + Sheet.76 @@ -427,16 +427,16 @@ Attributes userId : Integer {key} address : String - - - userId : Integer {key}address : String + + + userId : Integer {key}address : String Name «object type» LibraryUser - - - «object type»LibraryUser + + + «object type»LibraryUser Parameters @@ -446,21 +446,21 @@ - + - + Generalization.28 - + Discriminator - - + + @@ -480,16 +480,16 @@ Class.50 - + Sheet.84 - + Sheet.85 - + Sheet.86 - + Sheet.87 @@ -499,16 +499,16 @@ Attributes id : Integer {id} status : BookCopyStatusEL - - - id : Integer {id}status : BookCopyStatusEL + + + id : Integer {id}status : BookCopyStatusEL Name «object type» BookCopy - - - «object type»BookCopy + + + «object type»BookCopy Parameters @@ -524,7 +524,7 @@ - + @@ -539,8 +539,8 @@ end1_mp * - - * + + * end2_name @@ -548,10 +548,10 @@ end2_mp 1 - - 1 + + 1 - + @@ -576,59 +576,59 @@ Attributes AVAILABLE LENDED - - - AVAILABLELENDED + + + AVAILABLELENDED Name «enumeration» BookCopyStatusEL - - - «enumeration»BookCopyStatusEL + + + «enumeration»BookCopyStatusEL - - + + - - - - + + + + Binary Association.176 - + end1_name - + end1_mp - 0..1 + * - - 0..1 - + + * + end2_name - + end2_mp 1 - - 1 + + 1 - + - + @@ -645,23 +645,23 @@ Class.68 - + Sheet.145 - + Sheet.146 - + Sheet.147 - + Sheet.148 Operations onEvent() - + Attributes @@ -670,14 +670,14 @@ Name «event type» Arrival - - - «event type»Arrival + + + «event type»Arrival Parameters - + @@ -694,23 +694,23 @@ Class.77 - + Sheet.154 - + Sheet.155 - + Sheet.156 - + Sheet.157 Operations onEvent() - + Attributes @@ -719,14 +719,14 @@ Name «event type» Departure - - - «event type»Departure + + + «event type»Departure Parameters - + @@ -738,36 +738,36 @@ - + - + Binary Association.86 - + end1_name - + end1_mp - 0..1 + * - - 0..1 - + + * + end2_name - + end2_mp 1 - + - + - + @@ -778,34 +778,34 @@ - - - - + + + + Binary Association.91 - + end1_name - + end1_mp - 0..1 + * - - 0..1 - + + * + end2_name - + end2_mp 1 - - 1 + + 1 - +