Attributes and Constraints

1. Attributes and Constraints Architecture and Modelling of Information Systems (D0I71A) Prof. dr. Monique Snoeck

2. Enterprise Modelling Phase • identification of enterprise object types and business event types • identification of enterprise object types • identification of business event types • construction of EDG • construction of OET • specification of sequence constraints • specification of attributes and methods • identification of attributes • identification of object-event methods • identification of additional constraints Overview of MERODE

3. Attributesmakeobjects and eventsidentifiable. • For example: •  A customeris"identifiable" throughhis/hername, address and birth date • An accountis"identifiable" throughitsnumber • A banktransferis"identifiable" throughtwobankaccountnumbers, date and time and amounttransferred. • An attributegivesinformation on objects and events Defining Attributes Object attribute Method attribute

4. Information must be of value for enterprise • Should not beredundant, duplicate • One must be able to trace/collect the information • (garbage in - garbage out) • One must be able to maintain the information • Age of information ? • If change of r per year,after N yearsonly(1-r)Nisstill up to date Choice of attributes

5. No perfect rules ! Personal judgement remains necessary. • Guidelines: • Attribute is easier to handle • Object offers more functionality • Users must be willing to treat information as objects • Example: • Author as attribute of Title or as Object Type • Supplier as attribute of Order, or as Object Type Object or Attribute ?

6. Some rules of thumb • For each entity type, create a new relation • For each multivalued attribute type, create a new relation • Each relationship type with maximum cardinality of 1 is represented by a foreign key • For each relationship type with both maximum cardinalities n, create a new relation; include as foreign key attribute types the primary keys of the relations that represent the participating entity types • For each ternary relationship type, create a new relation; include as foreign key attribute types the primary keys of the relations that represent the participating entity types • Specialisation/generalisation can be represented by foreign keys. • … EER-to-Relational Mapping(Such as e.g seen in a Database Course)

7. Avoidconfusionwith EER-to-relationalmapping: • Thismapping is performedautomaticallywhen making the transitionfrom model to database design So, NEVER INCLUDE FOREIGN KEYS INTO YOUR MODEL: theywillbeautomaticallygenerated out of the model • Ifyouneedanattributethatreferstoan object type, this means youneedanassociationwiththat object type • Examples: INVOICE • requires customer info  invoice is ED of CUSTOMER • DO NOT ADD attributeCustomerID, CustomerName, …. etc. • Requires product info  is relatedto PRODUCT via Order Line • DO NOT ADD attributeProductList, ProductQuantities, …. etc. Attribute versus Association ?

8. An Attribute has a DATA TYPE • E.g. a BASE type: Integer, Real, Character, … • A type from a class library: String, Float, Array, List • A user defined data type: Address, AccountNR, … • An Enterprise Object Type • Class MEMBER • Number: Integer • Name: String • Category : Category Type (user definedenumeration type) • LOANs : SETof [LOAN] Data Types Attention !! Never definesuchattributesyourself: these shouldbe the result of relationshipsdefined in the EDG = the 0-many ED relationshipwith LOAN in the EDG

9. Data Types Data Type Data Type Data Type Data Type User-defined Data Type Class library Data Type = ED relationshipto LOAN Object Type Data Type

10. Specifyingattributes & data types in JMermaid Double click Left click to add new data type

11. Associationsthatwillgiveriseto extra attributes

12. Class object_type_name Inherit --list of ancestors Attributes -- references to master object types -- references to dependent object types -- state indicators -- additional attributes Invariant -- attribute constraints -- uniqueness constraints Methods -- methods for atomic event types End Template for an Enterprise Class definition(mapping domain model into code - automated) to derive from the EDG Will be derived from Roles ORreplaced by State Pattern to define List of methods given in OET method body = to define

13. Class COPY Inherit Attributes title: TITLE loan: LOAN state : INTEGER Methods acquire classify dispose borrow renew return End Example naming convention: references to master and dependent object types with Name or ref_name Assumption: relations can be navigated in both directions; for Master classes, type of reference is MASTER for dependent classes, type of reference is: -> DEPENDENT for cardinality of ONE -> SET<DEPENDENT>for cardinality of MANY

14. Enterprise Modelling Phase • identification of enterprise object types and business event types • identification of entreprise object types • identification of business event types • construction of EDG • construction of OET • specification of sequence constraints • specification of attributes and methods • identification of attributes • identification of object-event methods • identification of additional constraints Overview of MERODE

15. CLASS MEMBER ... cr_member (Input_member_id: INTEGER; Input_name: STRING; ) is require unique {member_id} input_name<> "" do state := 1 id := Input_member_id name := Input_name loan_period := 14 create loans.make end Define method body

16. Enterprise Modelling Phase • identification of enterprise object types and business event types • identification of entreprise object types • identification of business event types • construction of EDG • construction of OET • Specification of sequence constraints • specification of attributes and methods • identification of attributes • identification of object-event methods • identification of additional constraints Overview of MERODE

17. B. Meyer: Programming by contract: Pre-condition: conditions under which I accept to do my job properly (--> Obligations for my Client) Post-condition: To what I engage myself, my obligations (--> Benefice for my Client) Precondition, Postcondition Calculate N! Benefice for me: have not to worry about negative numbers Obligation for my client: check the preconditions Pre: N > 0 Obligation for me: ensure postconditions are satisfied Benefice for my Client: I guarantee a correct result Post: result = N! Who is responsible for checking pre/post conditions ?

18. Class constraints • = invariants, must be satisfied at any time • uniqueness constraints (e.g. definition of KEYS) (to be specified) • attribute constraints (e.g. domain) (to be specified) • Methods Constraints • pre- and post-conditions per method • referential integrity • sequence constraints • additional method constraints (to be specified) Constraints Generated because derived from EDG and FSMs

19. Uniqueness Constraints: Class ORDER Unique {ordernumber} Class ORDER LINE Unique {order-line-number, ref_order} Unique {ref_product, ref_order} Examples of constraints (to be specified) ORDER ORDERLINE PRODUCT

20. Attribute Constraints: Class MEMBER name <> '' count (ref_loan) <= 5 Class LOAN date_to_return > date_of_loan Examples of constraints (to be specified) MEMBER LOAN COPY

21. Class project Methods close_project is require Forall registration in ref_registration : registration.state = 'closed' Method Constraints (to be specified) Project Registration • Class conference • Methods • refund (...) is • require • date(today) refund_deadline Customer credit_limit • Class customer • Methods • withdraw (amount) is • require • amount <= credit_limit + sum [a.balance] • where a inref_account Account balance

22. JMermaid Preconditionsformethods Invariants in Object Types Constraintscanbewritten in pseudocode or in OCL.These constraintswillhowevernotbe taken into account for code generation. Theycanbestored here fordocumentationpurposes.

23. Lose/Dispose require Forallreservation in ref_reservation: reservation.state = 2 or reservation.state = 3 ref_loan.state= 2 or ref_loan.state = 3 or ref_loan = void Borrow require ref_loan = void or ref_loan.state = 2 or ref_loan.state = 3 End Master require Foralldependent in ref_dependent_name :dependent.state = a_final_state or (ref_dependent.state = a_final_state or ref_dependent = void) Create dependent with cardinality 1 Classmaster_object_type Create_dependentis -- with cardinality 1 require ref_dependent = void orref_dependent.state= a_final_state Referential Integrity Constraints (generated) All Constraints can be expressed in OCL

24. end_of declassify 5 4 6 copy Sequenceconstraints are transformedto pre-conditions • (Translate JSD-diagram to FSM) • Make Transition Table for FSM transition table for (complex) COPY Sequence Constraints (generated) renew 3 lose borrow return acquire _ classify 2 1 declassify

25. borrow, fetch renew bind on loan in available out return put_back reserve free reserved cancel, fetch SequenceConstraints via methodconstraints(to be specified) dispose, lose acquire register existing registered ended

26. SequenceConstraints via methodconstraints

27.  Spiralpresentation, bottom up • present all topics repeatedly, elaboratingthemfurtherduringeach pass • Passes • 1 = overview of layers, domain modelling, IS-modelling, Business Processes, model-drivendevelopment • 2 = Overview of Merode: domain modelling, IS Services • 3 = fundamentals of domain modelling (EDG, OET, FSM) IS layer • 4 = In-depth review of domain modellingtechniques (EDG, OET, FSM), IS layer, BP Layer, intermediatelayers, Interplaybetweenlayers, • 5 = model-drivendevelopment CourseOverview

28. Special caseMultiple PropagationConstraints A story with a long tail ... Marsupilami = Comic Strip heroissuedfrom the brain of André Franquin Alsofather of Gaston Lagaffe/Guust Flater

29. Building a nest NEST MARSU

30. CONTINENT The habitat … COUNTRY JUNGLE MARSU

31. Every NEST has 2 Marsu's, 2 jungles, 2 countries, 2 continents • Constraints in class NEST • Marsu-mother & Marsu-father are different • self.father <> self.mother • Marsu-mother & Marsu-father should be from the same jungle • self.father.ref_jungle = self.mother.ref_jungle • implies that they also are from the same country & continent • Marsu-mother & Marsu-father should be from the same country • self.father.ref_jungle.ref_country = self.mother.ref_jungle.ref_country • implies that they also are from the continent • implies that they could be from a different jungle • Marsu-mother & Marsu-father should be from the same continent • self.father.ref_jungle.ref_country.ref_continent = self.mother.ref_jungle.ref_country.ref_continent • implies that they could be from a different jungle and/or different country • Marsu-mother & Marsu-father can be from anywhere • no constraint ! How far does the tail reach ? father Nest Marsu Jungle Country Continent mother

32. Results in Multiple Instancesparticipating in 1 Event Type Happens when we have 2 pathsfrom a dependent to one master Multiple Propagation

33. Example of a Commercial Company 4 3 3 2 2 1 1 0

34. 4 4 3 3 3 3 2 2 2 2 1 1 1 0 0

35. 4 3 3 2 2 1 1 0 Multiple Instances participating in 1 Event Type PROBLEM & SOLUTION • 2 Customers are involved in 1 Delivery Line: • one of the Delivery & • one of the Order. • Raises Question: • Do youdeliverto the same customer as the onewhoplaced the order ? • YES => MP constraint • NO => use Alias

36. 4 3 3 2 2 1 0 Multiple Instances participating in 1 Event Type PROBLEM & SOLUTION • 3 Customers are involved in 1 Invoice Line: • one of the Delivery & • one of the Order & • one of the Invoice • Raises Question: • Do youInvoiceto the same customer as the onewhoplaced the order and as the oneyoudeliveredto ? • YES => MP constraint • NO => use Alias 1

37. Multiple propagation Constraint required ?

38. Contacts of the Invoice line can be different, but they should belong to the same customer

39. Multiple Propagation constraint in INVOICE_LINE: self.ref_invoice.billing_contact.ref_customer = self.ref_order_line.ref_order.sales_contact.ref_customer Required constraint:

40. Use of Aliases for method names cr_nest_as_father require self.gender = male cr_nest_as_mother require self.gender = female • Use of Hide-tool to specify constraints • Hide gray methods • Use aliases to identify different effects on/rules for different objects of the same class

41. JMermaid : user specified dependencies More than 1 dependency between 2 objects : => specify a dependency name Mouse over

42. MP Constraint: Same CategoryContext: SALES_ON_PRESCRIPTIONself.medicine.category= self. prescription.medicine.category Context: MEDICINEMethod of sold_medicine: Requires: sufficient stock Do: Decrease Stock

43. Unary Relationships Hierarchy BOM

44. 0..1 PERSON  has supervisor supervises 0..* PERSON supervises in_team_of TEAM RELATIONSHIP Hierarchy Hierarchy

45. Hierarchy The creation of a team-relationship involves two people: the team member and the team supervisor PERSON supervises ▼ supervisor▲ ▼in_team_of▲team_member TEAM RELATIONSHIP

46. Hierarchy

47. A person shouldnotbe his/her own supervisor • tobespecified as an invariant andprecondition of the event type cr_team_relin class TEAM_RELATIONSHIP • Supervises <> in_team_of • The supervisor shouldnotbesupervisedby his/her team/member (directlyor indirecty (subsumespreviousconstraint !!) • tobespecified as a precondition of the event type cr_team_relin class TEAM_RELATIONSHIP • A person shouldnotbetwice in the same team • Thisconstraint is in factalreadyrealizedby means of the cardinalityconstraint of the ED-relationship "in _team_of" Examples of Required Constraints

48. Class PERSON rank : STRING supervises: set (team_relationship) in_team_of: team_relationship Methods become_team_member(t: team_relationship) is require rank <> "director" in_team_of = void or in_team_of.state = ended do in_team_of := t end become_supervisor (t: team_relationship) is require count (self.supervises.in_team_of) < 20 do supervises.insert(t) end • Effect of the event is different depending on the role of the person: • different preconditions • different method-body end_team_membership is do in_team_of = void end end_supervisorshipis do supervises.prune(t) end … End

49. Only one team_relationship object involved in cr_team_member and end_team_member events  no Aliases ! Class TEAM_RELATIONSHIP supervisor: PERSON team_member: PERSON Invariant supervisor <> team_member Methods cr_team_member(boss, member: PERSON) is require boss <> member -- member not already in team of supervisor member not in boss.supervises.team_member -- boss is not in team of member : -- this should be checked by means of a recursive -- query getting all team_members of the member boss not in member.all_team_members do supervisor := boss team_member := member end end_team_membershipis do state := ended end … End

50. Bill of Material part type part type 0..* required_by required_pt requires  requiring_pt requires is requiredby 0..* prerequisite