Enterprise Modelling Basics and Refinement Approach Overview

This overview delves into Enterprise Modelling basics, covering Domain Model, Enterprise Object Types, Atomic Activities, Life Cycles, and refinement techniques like adding attributes and constraints. The content explores extending the model to upper layers and emphasizes the importance of clarity for improved modelling and consistency checking. Visual aids and detailed explanations enhance the comprehension of complex concepts in Enterprise Modelling.

• Enterprise Modelling
• Basics
• Refinement Approach
• Domain Model
• Enterprise Object Types

lau_ser Follow

Uploaded on Feb 15, 2025 | 0 Views

Download Presentation

Please find below an Image/Link to download the presentation.

The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.

You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.

The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.

Presentation Transcript

1. 1 1. Introduction 2. Basics of Enterprise Modelling (Domain Model) Overview of the approach Enterprise Object Types: EDG Basics Atomic activities: OET Basics Life cycles: FSM Basics 3. Refining & extending the model Refining: Adding attributes & constraints Extending to the upper layers: Information Services, Business Processes 08:05

2. 2 08:05

3. 3 UML MERODE- EDG Classes Enterprise Object Types Classes Associations Existence Dependency relationships Associations Simple binary association Aggregation Inheritance Inheritance 08:05

4. 4 1. 2. it provides the class diagram with more precise semantics it allows enhancing the modelling process by removing ambiguities it enables improved modelling and consistency checking of the behavioural aspects and as a result of the previous elements, it enables improved possibilities for the automatic transformation of specifications to code. 3. 4. 08:05

5. 5 UML doesn t discern between frozen versus modifiable association ends 0..* 0..* 1 1 ORDER SALESPERSON CUSTOMER is managed by is placed by Identical Representation Identical meaning ?? 08:05

6. 6 0..* 0..* CUSTOMER ROOM reserves Where do we keep the reservation date ? As an attribute of customer ? As an attribute of room ? Normalisation: Reserves(CustomerID, RoomID) What if the customer makes several reservations for the same room ? 08:05

7. 7 0..* 0..* CUSTOMER ROOM RESERVATION UML AssociationClass: A model element that has both association and class properties. reservation date Confirm Cancel . 08:05

8. 8 CUSTOMER ROOM 1 1 0..* 0..* RESERVATION makes has Reservation is Existence Dependent of ROOM and CUSTOMER ! 08:05

9. 9 Remember: Every Enterprise Object Type is involved in at least two Business Event Types: one for the creation of objects, one for the ending of objects life cycle of A A create_A end_A create_A end_A life cycle of B B create_B end_B create_B end_B 08:05

10. 10 ED: Life Cycle implications When B is existence dependent of A, this implies a sequence on the events for the creation and ending of A and B: life cycle of A sample life cycles of B s 08:05

11. 11 EDG is a DATA view .... BUT implies behavioural constraints This is NOT a data(base) modelling exercise ALWAYS evaluate the behavioural implications !! ED induces a natural sequencing of creating and ending of objects. create customer and room first, then create reservation end reservation first, then end customer and room This facilitates consistency checking with other diagrams intended to capture the behavioural aspects of the domain. 08:05

12. 12 0..* 0..* 1 1 ORDER SALESPERSON CUSTOMER is managed by is placed by 0..* 1 ORDER SALESPERSON CUSTOMER is placed by 1 for 1 Assigned to ED of 0..* ORDER MANAGER 1 has responsible as 08:05

13. 13 Let P and Q be object types. P is existence dependent on Q (notation: P Q) if and only if the life of each occurrence p of type P is embedded in the life of one single and always the same occurrence q of type Q. p is called the dependent object, (P is the dependent object type) and is existence dependent on q, q is called the master object (Q is the master object type). 08:05

14. 14 Time Life span of the master object Possibilities for life span of the dependent object = start of life = end of life Master = the one that exists first 08:05

15. 15 How to represent ED in UML ? 0..* 0..* 1 1 ORDER SALESPERSON CUSTOMER is managed by is placed by Expresses ED Does NOT express ED 08:05

16. 16 Information Engineering EER UML Bachman 0..1 0..* (0..1) (0..n) 1..1 1..* (1..1) (1..n) D0I62A (?) (D0I60A) D0I71A Basis for MERODE notation M. Fowler s Analysis Patterns 08:05

17. 17 UML Bachman MERODE 1..1 0..1 1..1 1..1 1..1 0..* 1..1 1..* 08:05

18. 18 Frozen 1 0..* ORDER CUSTOMER ORDER CUSTOMER 1..* 1 ORDER CUSTOMER ORDER CUSTOMER 0..1 1 ORDER CUSTOMER ORDER CUSTOMER 1..1 1 ORDER CUSTOMER ORDER CUSTOMER 08:05

19. 19 DOT Indicates the Master Each dependent object belongs to exactly one and always the same (unmodifiable) master object Example: each order belongs to one and always the same (unmodifiable) master Number of dependents ? = optional zero to . = mandatory at least one = maximum one = many 08:05

20. 20 One Many Optional Optional One Many Mandatory Mandatory 08:05

21. 21 TITLE TITLE 1 1 [0..*] [0..*] MEMBER COPY MEMBER COPY 1 1 1 1 [0..*] [0..*] [0..1] [0..*] LOAN LOAN 08:05

22. 22 Check this by reading the learning report generated by the tool ! (see File->Settings->Learning Facilities) 08:05

23. 23 Double check the cardinalities of the associations and what this implies in terms of object life cycles. 08:05

24. 24 1 0..* A B A B create_A end_A create_B end_B create_A end_A create_B end_B Each A-object has zero to many B-objects Each B-object refers to exactly one and always the same A-object life cycle of A sample life cycles of B s 08:05

25. 25 1 1..* A B A B create_A end_A create_B end_B create_A end_A create_B end_B Each A-object has at least one and possibly many B-objects Each B-object refers to exactly one and always the same A-object life cycle of A sample life cycles of B s 1 2 3 08:05

26. 26 1 0..1 A B A B create_A end_A create_B end_B create_A end_A create_B end_B Each A-object has zero to one B-objects Each B-object refers to exactly one and always the same A-object life cycle of A sample life cycles of B s 08:05

27. 27 1 1..1 A B A B create_A end_A create_B end_B create_A end_A create_B end_B Each A-object has exactly one B-objects, possibly several B s consecutively Each B-object has exactly one and always the same A-object life cycle of A sample life cycles of B s 1 2 3 08:05

28. 28 1 1..* Customer Order Customer Order create_Customer end_Customer Create_Order end_Order create_Customer end_Customer create_Order end_Order life cycle of Customer sample life cycles of Order This EDG implies that a customer cannot exist without living orders. As soon as the last order is terminated, the customer should be terminated as well. Better is to model this as an optional-many association. 08:05

29. 29 1 0..* Customer Order Customer Order create_Customer end_Customer Create_Order end_Order create_Customer end_Customer create_Order end_Order life cycle of Customer sample life cycles of Orders 1 2 3 08:05

30. 30 1 1..1 InvoiceLine InvoiceLine BusTrip BusTrip cr_InvoiceLine end_InvoiceLine cr_InvoiceLine end_InvoiceLine cr_BusTrip end_BusTrip cr_BusTrip end_BusTrip life cycle of BusTrip sample life cycles of InvoiceLines for this BusTrip This EDG implies that as soon as a BusTrip is registered, an invoice line should be created as well. Better is to model this as an optional-one association. 08:05

31. 31 1 0..1 InvoiceLine InvoiceLine BusTrip BusTrip cr_InvoiceLine end_InvoiceLine cr_InvoiceLine end_InvoiceLine cr_BusTrip end_BusTrip cr_BusTrip end_BusTrip life cycle of BusTrip sample life cycles of InvoiceLines for this BusTrip Use the FSM to enforce the invoicing at some point and to prevent the creation of a second invoice. 08:05

32. 32 Invoice Line Invoice Line 1 1..* Invoice Invoice Invoice Invoice cr_InvoiceLine end_InvoiceLine cr_Invoice end_Invoice cr_InvoiceLine end_InvoiceLine cr_Invoice end_Invoice life cycle of Invoice sample life cycles of InvoiceLines This EDG implies that as soon as an Invoice is created, an invoice line should be created as well. If modelled with an optional-many association, more flexibility is allowed in the Invoice registration process. 08:05

33. 33 Every UML class is a class in the EDG When an UML association expresses ED is an ED relation in EDG does NOT express ED is transformed to an association as a class , i.e. a class in the EDG. 1 to Many association that does not express existence dependency Many to Many Association Unary Association N-ary Association 08:05

34. 34 Employee Department Employee 0..* 1..1 Department Assignment 08:05

35. 35 Server Server Client 0..* 0..* Connection Client 08:05

36. 36 Person 0..1 Person husband wife 0..1 married to Marriage How to allow for Polygamy ? 08:05

37. 37 Department 0..1 sub_dept head_dept Department 0..* subdepartments Assignment KUL ASSIGNMENT Head Dept. KUL FBE FBE DSIM DSIM M&O Sub Dept. FBE DSIM M&O LIRIS P&L ... FBE ... DSIM M&O Liris P&L. ... 08:05

38. 38 COURSE 0..** 0..** 0..* ROOM PROFESSOR 0..* ROOM COURSE PROFESSOR LECTURE 08:05

39. 39 AGGREGATION [0..*] [1..*] COURSE MODULE COURSE composed of part of [1..1] [1..*] ORDER LINE ORDER composed of part of [0..1] [0..*] PARCEL ITEM composed of part_of

40. 40 AGGREGATION SHARED aggregation [0..*] [1..*] COURSE MODULE COURSE Description1: shared Indicates that the Property has shared aggregation semantics. Precise semantics of shared aggregation varies by application area and modeler :. 1 p. 110 in OMG Document "Normative Reference": http://www.omg.org/spec/UML/2.5 40

41. 41 AGGREGATION COMPOSITE aggregation [1..1] [1..*] ORDER LINE ORDER [0..1] [0..*] PARCEL ITEM Description1: composite Indicates that the Property is aggregated compositely, i.e., the composite object has responsibility for the existence and storage of the composed objects. 1 p. 110 in OMG Document "Normative Reference": http://www.omg.org/spec/UML/2.5 41

42. 42 AGGREGATION Composite aggregation is a strong form of aggregation that requires a part object be included in at most one composite object at a time. If a composite object is deleted, all of its part instances that are objects are deleted with it. [1..1] [1..*] ORDER LINE ORDER [0..1] [0..*] PARCEL ITEM NOTE. A part object may (where otherwise allowed) be removed from a composite object before the composite object is deleted, and thus not be deleted as part of the composite object. .... The precise lifecycle semantics of composite aggregation is intentionally not specified. The order and way in which composed objects are created is intentionally not defined.

43. 43 AGGREGATION CONCLUSION Aggregation = syntactic sugar "Normal" binary associations have the same expressive power Use (conventional) binary associations with appropriate role names to avoid confusion in a model reader's mind. [0..1] [0..*] PARCEL ITEM composed of part_of

44. 44 PC MONITOR KEYBOARD EXTERNAL SYSTEM DRIVE BOX 08:05

45. 45 Order Order Order Line Order Line Mind that according to the previous definition, not all composite aggregations express ED !! A case-by-case analysis is therefore always required ! 08:05

46. 46 Learning report Learning report A B object can have 0 or n dependent objects of type A. A B object cannot be ended as long as it has dependent A objects. An A object can only exist in the context of exactly 1 object of type B: it refers to one and always the same B. An A object can only be created after the B object it refers to has been created. A C object can have 0 or n dependent objects of type A. A C object cannot be ended as long as it has dependent A objects. An A object can only exist in the context of exactly 1 object of type C: it refers to one and always the same C. An A object can only be created after the C object it refers to has been created. Conclusion: MASTERS = AND A must have one B AND one C 08:05

47. 47 Learning report Learning report A A object can have 0 or n dependent objects of type B. A A object cannot be ended as long as it has dependent B objects. A B object can only exist in the context of exactly 1 object of type A: it refers to one and always the same A. A B object can only be created after the A object it refers to has been created. A A object can have 0 or n dependent objects of type C. A A object cannot be ended as long as it has dependent C objects. A C object can only exist in the context of exactly 1 object of type A: it refers to one and always the same A. A C object can only be created after the A object it refers to has been created. Conclusion: DEPENDENTS : OR A can have Bs OR Cs Notice: this is an inclusive OR 08:05

48. 48 In summary An object mandatorily has all its masters simultaneously AND-relationship for all the masters An object can have dependents OR-relationship for all non-mandatory dependents 08:05

49. 49 A lecture has a room AND a course AND a professor 08:05

50. 50 A PC has a monitor OR an external drive optional and inclusive OR, so a PC can have none, one or both 08:05

Load More ...