BIS 3100 Conceptual Modeling (lecture Two).pptx

Modelling and Simulation

1. Part II Conceptual/Data Modeling Most of the figures, content and tables used in these slides are from Terry Halpin’s slides ( Model Driven Development with ORM 2 and NORMA ) © 2007 T. Halpin & Neumont University

2. What is Object-Role Modeling? ORM is conceptual approach for modeling, querying, and transforming data. It is fact-oriented (attribute-free). That is to say, all facts are modeled as relationships (unary, binary, ternary …) ORM i s s emantically stable, facilitates validation through verbalization & population, and has a richly expressive graphical constraint language (compared with industrial Entity Relations (ER), or Unified Modeling Laguage (UML) class diagrams ) For data modeling, we need DATA use cases (cases of data being used), e.g. Sample reports Sample input forms Sample queries

3. ORM Working Principle How to go from a data use case to a data model? Have the domain expert verbalize the data For each use case, a domain expert who is familiar with the case should verbalize the information content in terms of natural-language sentences Rephrase this as unambiguous, elementary facts. A modeller or modellers transform that informal verbalization into a formal yet natural verbalization that is clearly understood by the domain expert S ample data as fact instances are then abstracted to fact types. Elementary facts : a simple assertion, or atomic proposition, about the Universe of Discourse ( UoD ). The word “ fact ” indicates that the assertion is taken to be true by users in that business domain. Add and validate the business rules constraining the data Constraints and perhaps derivation rules are then added and themselves validated by verbalization and sample fact populations

4. The domain expert best understands the business domain The modeler elicits and formalizes this understanding The modeler assists the domain expert to identify the business rules related to the data (constraints or derivation rules) The modeler validates the model with the client by Verbalizing the model in natural language Populating the model with positive/negative examples Analysis is a Joint Activity

5. Patient# Temperature 571 100 Data (uninterpreted syntax) The Patient with Patient# ‘571’ has a Temperature of 100 o F Fact (proposition taken to be true) Information = data + semantics 571

6. Fig. Relationships between data, information and knowledge

7. Data is a fact, raw and unprocessed e.g. “ ID K6464 ” and condition “ pregnant, diabetic ”. To transform this data into information , a human is involved. The human processes the provided data, adds meaning and communicates it. So it becomes “ The patient with ID K6464’ is pregnant and diabetic ”. To turn information into knowledge requires a domain expert (in this case a medical professional) to adequately integrate (appropriate) the provided information to produce knowledge. The information in the example is turned into knowledge when more details are added.

8. The information plus knowledge lead to “ The patient with ID ‘K6464’ is pregnant with Type 1 diabetes, therefore she is likely to experience episodes of hypoglycemia and pregnancy difficulties ”. Fig. Data , information and knowledge illustrative examples.

9. 9 An elementary fact is an assertion that an object has a property * or one or more objects participate in a relationship ** where the fact cannot be split into simpler facts with the same objects (without info-loss) * plays a role by itself ** play different roles in the same association Elementary Facts

10. The Person named ‘Jack Ssengo ’ smokes . A unary fact A binary fact The Student named ‘William Kato’ climbed the Mountain named ‘Mt Elgon’. Facts may also be of higher arity (4 or more roles). A ternary fact The Person named ‘Don Jjuko ’ played the Sport named ‘Cricket’ for the Country named ‘Kenya’.

11. 11 A unary fact A binary fact Usually a relationship involves at least two roles. example: The Student named ‘ Nakaye Mary’ reads a book titled ‘ IS’. In general, an elementary fact asserts that a particular object has a property, or that one or more objects participate together in a relationship. Facts may also be of higher arity (4 or more roles). A ternary fact The Person named ‘John Lule ’ taught a course named ‘Client server’ for the college named ‘computing and information sciences’. A single object plays a given role. e.g. consider a small domain in which people are identified by their first names. One fact about this domain might be: The Person named ‘David’ smokes . Example 2

12. Elementary Facts cont … Elementary facts usually DO NOT use logical connectives (e.g., not, and, or, if) or logical quantifiers (e.g., all, some). For example, sentences (4)–(9) are not elementary facts. 4. Ann smokes and Bob smokes. 5. Ann smokes or Bob smokes. 6. Ann does not smoke. 7. If Bob smokes then Bob is cancer prone. 8. All people who smoke are cancer prone. 9. If some person smokes then that person is cancer prone.

13. ORM Graphical Modeling Language Object = Entity or Value Entity = Object that is identified by a definite description. Entities typically change their state over time. Entities may be concrete or abstract. e.g. The Country that has CountryCode ‘AU’. The President named ‘Abraham Lincoln’. The Course with course code ‘CS542’. Entity types (Object types) are depicted as named, soft rectangles. As a configuration option, soft rectangles may be replaced by hard rectangles or ellipses. 13

14. Value = Lexical Constant (typically a character string or number). Values are literal and cannot change their state. A value is a constant that is self-identifying in the sense that when you see the constant written down in some context you always know what is being referred to. Values are constants (typically character strings or numbers). As a result, values can be referenced directly, without needing to identify them with a description. e.g. The CountryCode ‘UG’. The CourseCode ‘BIS3100’. The RoomNumber ‘102’. The SerialNumber 66884. Value Types are depicted as named, dashed rectangles. Optionally, ellipses or hard rectangles may be used instead . 14

15. Examples to Elementary Facts Note that some authors use the word “entity” for “entity type”. We sometimes expand “entity” to “entity instance” to avoid any confusion. Consider the sentence Lee is located in 10B. This could be talking about a horse located in a stable, or a dog in a room, and so on. By stating the entity types involved, ( b ) avoids this kind of referential ambiguity. Names of object types are highlighted here by starting them with a capital letter. b) The P atient ‘Lee’ is located in the W ard ‘10B’.

16. Examples to Elementary Facts Cont .. Consider the following sentence: The Person with firstname ‘Ann’ smokes. The object term is “The Person with firstname ‘Ann’”. The predicate may be shown by itself as “… smokes ” using an ellipsis “…” as a placeholder for an object instance.

17. Examples to Elementary Facts Cont .. A binary predicate is a sentence with two object holes. Most predicates in information models are binary. Example : The Person with firstname ‘Ann’ employs the Person with firstname ‘Bob’. the predicate may be shown by itself as “... Employs …”

18. Examples to Elementary Facts Cont .. Mixfix For naturalness, we write predicates in mixfix (or distfix ) form, where the terms may be mixed in with the predicate. For example, the following ternary fact uses the predicate “… moved to … during …”. The Scientist with surname ‘Einstein’ moved to the Country with code ‘USA’ during the Year 1933 CE.

19. Examples to Elementary Facts Cont .. In reports like Table 1, the column headings and table names or captions often give a clue as to the object types and predicates. The column entries provide the values. Designer Language Smith Kay Smith Pascal Smalltalk Modula-2

20. From Examples to Elementary Facts Cont .. translating row 1 as an elementary fact: The Person with surname ‘Smith’ designed the Language named ‘Pascal’. entity types and reference modes appear as nouns the predicate as a verb phrase. If we read it from right to left, we might say: 2. The Language named ‘Pascal’ was designed by the Person with surname ‘Smith’.

21. Example Explanation Entity types (object types) are shown as named ellipses Value types are shown as named, dashed ellipses (e.g., ActivityName ) A role is a part played in a n association , and is depicted as a box A n association is shown as a named sequence of one or more role boxes, each connected to the object type that plays it A predicate is a sentence with object holes in it A fact table may be added with a sample population to help validate the constraints The arrow-tipped bars are internal uniqueness constraints , indicating which roles or role combinations must have unique entry A ORM Diagram for Room Scheduling

22. 22 Conceptual analysis usually involves: High level service (essential business process) modeling and information modeling. For large applications: Divide the UoD into manageable sub-sections Prioritize the order in which sub-sections will be modeled Apply the Conceptual Schema Design Procedure ( CSDP) to each sub-section Integrate the subschemas into a global conceptual schema Many applications build on existing applications: Re verse-engineer the existing model(s) to a conceptual model Refine the conceptual model to fit the new business needs

23. Seven Steps for Conceptual Modeling Transform familiar information examples into elementary facts, and apply quality checks Draw the fact types, and apply a population check Check for entity types that should be combined, and note any arithmetic derivations Add uniqueness constraints, and check arity of fact types Add mandatory role constraints, and check for logical derivations Add value, set comparison, and subtyping constraints Add other constraints and perform final checks

24. Lecturer Department Building Nankya CS B-block Mutumba IT A-block Ssonko IS B-block Apio NW A-block Consider the output report in the table below. Suppose that, with the help of a domain expert, row one is expressed as follows: The lecturer with surname ‘ Nankya ’ works for the Department coded ‘CS’, which is located at Building ‘B-block’.

25. Many entities are identified by their relationship to a simple value. If this is true for all instances of their entity type, the reference (identification) scheme for their entity type may be displayed as a reference mode in parenthesis. The reference mode may be popular, unit-based, or general. A popular reference mode has a corresponding value type that is used to identify entities of one type only, and is preceded by a dot. e.g. The value type name appends the reference mode name to the entity type name, with a user-definable format that may include a separator e.g. CountryCode CourseCode StudentName etc . Country_Code Course_Code Student_Name etc.

26. A unit-based (or measurement ) reference mode uses a unit based on some unit dimension (whose display is often suppressed) 1 . A colon “:” is appended to the unit e.g. The value type name appends “Value” to the reference mode name (if the language is English) with a user-definable format e.g. cmValue USDValue cm_Value USD_Value If desired, the unit type may be displayed after the colon, e.g.

27. Different units based on the same unit dimension are permitted in the same model, e.g. General reference modes have the same name as their value type. The value type may be used to reference multiple entity types e.g.

28. An independent object type may have instances that exist in the model without participating in any other relationships. Independent object types have a “!” placed after their name e.g. If an object type shape is duplicated in the diagram (either on the same page or on different pages) this is shown by a shadow e.g. An external object type is defined in another model. The display notation “^” is tentative e.g.

29. Predicates ( relationships ) have one or more roles , each played by instances of a single object type. Predicate readings may be shown in mixfix notation using … as an object placeholder, e.g. … introduced … to … For unary and binary predicates with no leading or trailing text, the placeholder may be omitted e.g. smokes i.e. … smokes likes i.e. … likes … Roles may also be named. Duplicate predicate shapes are shadowed.

30. For binary predicates, forward and inverse readings may be shown separated by “/”. Alternatively, arrow tips may be used. Combining a predicate with its object type(s) forms an elementary or compound fact type . An elementary fact can’t be split into smaller facts with the same objects, without information loss e.g.

31. A compound fact type includes two or more fact types, and if used in a model must be declared to be derived e.g. An existential fact (or reference) simply asserts the existence of an object e.g. There exists a Country that has CountryCode ‘US’. Existential fact types are displayed either using a reference mode or an explicit relationship, e.g. This includes constraints (see later).

32. e.g. An elementary fact type may be objectified , resulting in another object type. A fact type may be: asserted ( base fact type) fully derived derived and stored semi-derived

33. Uniqueness constraints require instances of their role or role sequence to be unique in the role or role sequence population. Internal uniqueness constraints apply to a single predicate and are depicted by bar(s) over the constrained role(s). External uniqueness constraints apply to roles from different predicates and are depicted by circled bars connected to the roles. If the constraint applies to role(s) used to provide the preferred identification scheme for an object type, a double-bar is used.

34. A simple mandatory role constraint requires its role to be played by all instances of its object type’s population and is shown by a solid dot at either end of the role-type connector. An inclusive-or (or disjunctive mandatory role ) constraint requires at least one of its roles to be played by all instances of its object type’s population and is shown by a circled, solid dot connected to the roles.

35. e.g.

36. Object Value Constraints Role Value Constraints

37. Subset Constraints

38. Equality Constraints

39. Exclusion Constraints Exclusive-Or Constraints

40. Subtyping

41. Frequency Constraints

42. Ring Constraints

43. The previous constraints are all alethic (necessarily true for each state). ORM 2 also supports deontic versions of all these constraints

44. Uniqueness constraint on first role + ve form: Each Moon orbits at most one Planet . Illustrated by a satisfying fact population . - ve form: It is impossible that the same Moon orbits more than one Planet . Test with a counter-example . Phobos Mars Deimos Mars Io Jupiter Io Mars } Counter-example Model Validation

45. 45 The absence of a uniqueness constraint on the second role may be verbalized using default form : It is possible that the same Planet is orbited by more than one Moon . Illustrated by a satisfying fact population. Phobos Mars Deimos Mars Io Jupiter

46. 46 Sample screenshot showing automated verbalization (+ ve plus some default) for some selected aspects. Currently about 80% of constraints are verbalized. The rest should be implemented in a few months.

47. Alethic: It is possible that more than one Patient is a husband of the same Patient and that more than one Patient is a wife of the same Patient . Each Patient , Patient combination occurs at most once in the population of Patient is a husband of Patient . Deontic: It is obligatory that each Patient is a husband of at most one Patient . It is obligatory that each Patient is a wife of at most one Patient . In ORM 2, rules may be assigned different modalities

48. ER and UML class diagrams are attribute-based, leading to more compact diagrams that are closer to implementation schemas. UML also includes many other diagram types to deal with process modeling etc. ORM’s attribute-free nature facilitates validation by verbalization and population and semantic stability. ORM’s graphic language is far richer for data modeling than that of ER and UML, and its textual languages are far easier for non-technical users to understand than UML’s OCL. ORM’s graphical language is also orthogonal and unambiguous (unlike UML).

49. UML’s multiplicity notation is fine for binaries but not for n - aries e.g. can’t express as a multiplicity

50. UML’s xor is defined between associations, not association roles, so this is ambiguous. ORM correctly defines the constraint between roles and treats it as a combination of exclusion and inclusive-or.

51. 51 ORM models are immune to changes that reshape attributes as entity types or relationships. The meaning of a query is not changed if we change a constraint or add a new fact type. ORM queries respect this principle and hence facilitate schema evolution. ER and OO queries do not: such changes can cause attributes to be remodeled; hence, existing queries need to be reformulated. Semantic stability

52. List titled people and their gender ü Person --- has Title --- is of ü Gender select SSN, gender from Person where title is not null

53. 53 List titled people and their gender ü Person --- has Title --- is of ü Gender select Person.SSN, gender from Person join PersonTitle on Person.SSN = PersonTitle.SSN

54. Next Class Exercise

55. Model this final report from the same business domain. Review Assignment ISBN Title PNr Name Result 1 - 33456 - 012 - 3 2 - 55860 - 123 - 6 3 - 540 - 25432 - 2 4 - 567 - 12345 - 3 Client Server Things fall apart Informatics Informatics 1 4 2 5 6 1 7 1 5 David Lule Cate Apio Jack Baddy Mary Nankya Deo Kirya David Lule David Lule David L ule Mary Nankya 4 5 5 5 4 4 5

56. Solution

57. END!! Next Part III Network Models

58. Feasibility study Requirements analysis Conceptual design ( data , process) Logical design ( data , process) External design (data, process) Prototyping Internal design and implementation Testing, validation, and maintenance Large projects are often developed iteratively Overall Procedure: Information systems life cycle

59. Conceptual analysis usually involves: high level service (essential business process) modeling information modeling For large applications: divide the UoD into manageable sub-sections prioritize the order in which sub-sections will be modeled apply the Conceptual Schema Design Procedure ( CSDP ) to each sub-section integrate the subschemas into a global conceptual schema Many applications build on existing applications: reverse-engineer the existing model(s) to a conceptual model refine the conceptual model to fit the new business needs

60. Conceptual schema design procedure 1 Transform familiar examples into elementary facts and apply quality checks 2 Draw the fact types and apply a population check 3 Check for entity types that should be combined and note any arithmetic derivations 4 Add uniqueness constraints and check arity of fact types 5 Add mandatory role constraints and check for logical derivations 6 Add value, set comparison, and subtyping constraints 7 Add other constraints and perform final checks

61. ORM 2 Graphical Modeling Language Object = Entity or Value Entity = Object that is identified by a definite description. Entities typically change their state over time. Entities may be concrete or abstract. e.g. The Country that has CountryCode ‘AU’. The President named ‘Abraham Lincoln’. The Course with course code ‘CS542’. Entity types are depicted as named, soft rectangles. As a configuration option, soft rectangles may be replaced by hard rectangles or ellipses.

62. Value = Lexical Constant (typically a character string or number). Values are literal and cannot change their state. e.g. The CountryCode ‘AU’. The PresidentName ‘Abraham Lincoln’. The CourseCode ‘CS542’. The RoomNumber ‘207’. The SerialNumber 1090. Value Types are depicted as named, dashed rectangles. Optionally, ellipses or hard rectangles may be used instead.

63. ORM Example T he top row may be read by a domain expert as: Room 20 at 9 a.m. Monday isbooked for the activity ‘VMC’ which has the name ‘ VisioModeler class’ A modeler may transform it into two elementary facts: the Room numbered ‘20’ at Time with day-hour-code ‘Mon 9 a.m.’ is booked for the Activity coded ‘VMC’; the Activity coded ‘VMC’ has the ActivityName ‘ VisioModeler class’ Once the domain expert agrees with this verbalization, fact types are abstracted from the fact instances , and an ORM diagram with population of sample data will be drawn (a) A Simple Room Scheduling Use Case (b) A ORM Diagram for Room Scheduling