CMPT 370: Information Systems Design

1. CMPT 370: Information Systems Design Lecture Topic: Requirement Determination Class Exercise: Domain Models Instructor: Curtis Cartmill, Simon Fraser University – Summer 2003

2. Objectives • This lecture covers two main topics: • UML as a Language • Introduction to Domain Modeling • Concept of models • Concept of domain modeling • Techniques to model the domain • Documenting domain models Domain modeling is also referred to as Business modeling

3. UML As a Language • Basic Architecture • Mechanisms of UML Problem-Solving • Views • Strengths of a UML Model

4. Basic Architecture of UML • “Things” in a Metamodel • Class and Association (Common structural behaviours, properties, and relationships) • Object and Link (Instances) • Labeling Metamodel • Descriptive Words • Multiplicities: 1-to-1, 1-to-many, etc. • Metamodel Composed of: • Behaviour Elements: Collaborations, Use Cases, State Machines, Common Behaviour • Foundation Elements: Core, Auxiliary Elements, Extension Mechanisms, Data Types • Management of the Metamodel

5. Mechanism of UML Problem-Solving (1) • Perspectives of Purpose • Conceptualize a problem (Analysis) • Specify a Solution (Design) • Construct and Realize the Solution • Dichotomies (how things viewed in two different perspectives) • Type & Instance • Specification & Realization • Static & Dynamic / Structural & Behavioural

6. Mechanism of UML Problem-Solving (2) • Layers of Abstraction represented in a System • Subsystem Levels (high-level) • Classes • Method Level (low-level) • Customizing • Stereotypes (marking elements in << >>) • Tagged Values (specify properties of model) • Constraints (specify conditions for meaning)

7. Views and Perspectives of UML • User View • Use Cases • Structural View • Class Diagrams • Object Diagrams • Behaviour View • Sequence Diagrams • Collaboration Diagrams • Statechart Diagrams • Activity Diagrams • Implementation View • Component Diagrams • Environment View • Deployment Diagrams

8. Strength in UML Models • Syntax • Legal Structure of the Language • Allows for Customization / Future Extensions • Semantics • Meaning of the Model • Reduce Ambiguity • Executable • Generate Code for Forward-Engineering • Integration Flow • Meaning between different UML Artifacts (b/w different perspectives/views)

9. From UML to Domain Modeling • UML is a specific language for Unified Modeling in Object Oriented Analysis & Design • Abstracting/Generalizing again to go back and talk about Modeling • Will specialize and talk about Domain Modeling

10. What is a model? • A model is an abstraction of what is real and required (as-is or to-be) • Models are made up of diagrams • A model must be comprehensive but focused, the real world can be complex, messy and unfocussed • Models are not just diagrams, the diagrams are only the visual rendering of the model and express views of the model Human understanding of diagrams is constrained by the limits of human cognitive capabilities, such as short term memory • A model is the interpretation of its diagrams

11. Why as-is and to-be models? • A model is an abstraction of what is real and required (as-is : to-be) • First we model the as-is to understand the current context of roles and processes • Then we model to-be to understand how we can change or optimize roles and processes to provide value to our stakeholders • If as-is and to-be are the same we are probably not attaining a good use of resources. We use domain modeling to provide the opportunity to better analyze the problem so as to determine a better solution

12. Types of diagrams • Two types of diagrams, • Static diagrams – represent the pieces of the system and their relationship • Dynamic diagram – represent the behaviour of the elements of the system and their interactions The term model and diagram are often used interchangeably

13. Textbook Modeling Terminology • Data and Relationships (Domain) • ERD - Entity Relationship Diagram • ORD - Object Relationship Diagram • In UML: Class Diagrams • Processes/Algorithms with inputs and outputs • DFD - Data Flow Diagrams • In UML: Collaboration or Sequence Diagrams • Ordering/Triggering Processes • FSM – Finite State Machine • In UML: Statechart Diagram

14. Context of domain modeling Build the right product Build the product right Requirements ( Analysis) Design ‘What’ ‘How’ SMOP -fuzzy-

15. Context of domain modeling • We need to model our understanding of the context, requirements, practices and constraints to ensure that we have the problem and the problem setting right. • Only then do we model the architecture, specification, design, implementation and deployment of what the builders should build. • Models are not right or wrong, just more or less useful

16. Why do we need domain models? • Gap between stakeholders and developers • Stakeholders have the vision • Developers need the specifications • Domain models begin to close this gap • Capture needs in a format that is interpretable and understandable to stakeholders • It validates user needs • Model needs in a format that begins to formulate an understanding of the solution to developers • Re-iterate • Document the nature of things • Store the essence of a thing for retrieval • Communicate the nature of things to others • Discuss the correctness of the model without observing real objects in action • Can write a program to implement things Stakeholders ?? Developers

17. Domain requirements considerations • Understandability • Requirements need to be expressed in the language of the application domain • These requirements may not be understood by software engineers developing the system • Domain models begin the road to understanding through the identification of vocabulary • Implicitness • Domain specialists (SMEs) understand the area so well that they do not think of making the domain requirements explicit • Domain models help stakeholders fill in the gaps so that the model can be properly interpreted

18. What is domain modeling? • A domain is a package of business features and services at some level of abstraction that is meaningful to an organization and its stakeholders • These are the essential activities, services and things • Domain modeling – the study of these fundamental business abstractions. • Modeling at this level is conceptual and independent of implementation • Domain models are useful for bounding a domain so it is useful as well for software and planning purposes.

19. What is a domain model? Domain models include the following • The context for multiple applications within an area of study (a domain) • A definition of scope for the domain • Information (or objects) at the conceptual level • Features (or use cases), including factors that lead to variations, again high level and business oriented • Operational/ behavioral characteristics (consider that this will be more important when we do Class Diagrams later)

20. A domain model must be capable of being directly validated and explained by the end users. There should be no implementation detail in the domain model. Domain information is the critical context for design decisions. Design decisions must be traceable to the domain. Domain model use

21. Domain models • Domain models should be simple • The simple model is not necessarily the first one that we come up with • Finding a simple model takes time and effort • When a simple model is found it is obvious (we will know it when we see it) • Simple models make things easier to design, build, maintain and expand

22. How to model domains • Identify essential information through the use of a vocabulary understandable by stakeholders - Concepts • Identify roles that will perform interactions with the system – Actors • Identify interactionsor domain activities – Use Cases • Illustrate the domain model using a set of class diagrams

23. Questions to ask when domain modeling • For each concept • What is known about this concept • What parts are this concept made of • For each action • Who is involved in this action • What steps are involved • Whom does it affect • What could be different from one occasion to another

24. Organizing/Representing Concepts in a Data Model (1) • “Things” / Physical Objects / Tangible Things / External Entities • People, Equipment, Cars, Robot, Letters, Reports, Signals • Places • Parking Spot, University, Warehouse • Organizations, Organizational Units • Team, Flight Crew • Roles • Customer, Sub-Teacher, Manager • Incidents/Transactions to be recorded / Records of Events • Purchases, Customer Order, Airplane Landing, Phone Call, Sale, Payment • Transaction Line Items (sub-records on receipt) From Various Sources, one good one is Larman, Craig - “Applying UML and Patterns”

25. Organizing/RepresentingConcepts in a Domain Model (2) • Specifications / Procedures / Rules and Policies • Repair Manual, Recipes, Organic Compound, Refund Policy • Intangible Concepts / Abstract Noun Concepts • Bank Account, Time Delay, Sound Recording, Hunger, Acrophobia • Relationships / Interaction b/w two objects • Customer’s Sales Associate, Flight’s Captain, Marriage • Structures (Containers and Things in a Container) • Airplane parts: Body, Wings, Engines, Tail • Displayable Field • String, Icon, Image

26. Associations in a Domain Model (1) • Has / Ownership • A Plane is owned by an Airline • Uses / Manages • An Employee is managed by a Manager • Membership / Organizational Unit Information • A Pilot is a member of a Union • Communications With • A Passenger communicates with A Flight Attendant • Part-of (Physical or Logical) • A Wing is part-of an Airplane • Containment (Physically or Logically) • Passengers are physically contained in an Airplane From Larman, Craig - “Applying UML and Patterns”

27. Associations in a Domain Model (2) • Description-for • A Flight Description is a description for a Flight • Events • Flight Arrival is an event related to a Flight • Transactional • Line Item of Transaction for (Flight Leg is a line item of transaction for a Booking) • Is Related to a Transaction (Customer is related to a Payment) • Is a Transaction related to another Transaction (Reservation and Cancellation) • Captured Information (Recorded / Reported) • A Reservation is reported in a Flight Manifest

28. Vocabulary In Models • Vocabulary may apply to more than one concept • Need to get agreement among stakeholders • Each concept must be uniquely labeled • The ‘hand’ concept • A concept may be labeled more than once • Customer, member

29. Relationships in Models • Illustrations of Links between Entities • Map showing route for Navigation • Navigability Preference • Arrow if a Relationship goes one-way • Labeling for Readability (Clockwise) • Cardinality • Optionality (lower-bound – can or must exist) • Multiplicity (upper-bound – 1, n, * are used) • 0..1 – zero or one • 1 – one and only one (default, usually omitted) • 0..* – zero or more (also can be written as just *) • 1..* - one or more • n1..n2 – between n1 and n2

30. Relationships in Models • ‘can be’ should be modeled as a 0..n • Use ‘may be’ to interpret this cardinality in a relationship • The activity cardinality should be validated and agreed to by stakeholders • Is rents a 1..* or a 0..* relationship? • All relationships should be modeled • A ‘has’ relationship can sometimes be modeled using a more active verb (ie: owns, is ordered by) • Conversations about the domain should be recognizable in the model (have we identified all concepts – round, rotate dealer ) • Some relationships can be derived and thus need not be modeled (a card game uses cards)

31. Modeling considerations • Level of abstraction • Abstraction: a description that omits details that are not relevant (generalize) • Abstract concepts • Abstract relationships • Try and keep away from detail and implementation • Remove implementation details through abstraction • “Barcode” can be abstracted to “Code Identifier” • Helps us to look a problem before determining solution • When in doubt go more abstract • One person’s view of reality can be different from another’s • Try and remove inconsistencies • Modeling is an active exercise • This is not passive discovery, it is active construction

32. Modeling Example • Card Game domain • What is some of the common vocabulary ? • Who are some of the actors? • What are usual “use cases” in a card game?

33. Modeling Example • Card Game domain • Common vocabulary • deck, card, suit, card value, deal, trick, trump, game, game rules • Actors • dealer, player • Use cases • deals, trumps, shuffles, plays

34. Card game domain model

35. Modeling Result A domain model shows the main types of interests • Concepts and links on how they interact (Relationships) • High level abstractions should accomplish a business task or objective or should abstract a group of such actions • The resulting business model acts as a central glossary of terms for all projects associated with it • A domain model is owned by the people who own the business

36. Domain Model Validation • Domain models should be validated with stakeholders • Technically Models are (by default) read from left to right and top to bottom – • consider that in general think of it as “clockwise direction” • Exceptions can be made in UML, need a little by-itself arrow head (not on an association) pointing to denote direction • Can the model be read and understood • Is the vocabulary used applicable to the domain • Are the concepts correct • Do the relationships between concepts exist and are they correctly labeled • Is the cardinality of each relationship correct

37. A word about “Normalization” and Modeling • Highly developed process for relationship modeling in relational database design (data) • It is concerned more with the proper assignment of Primary Keys, Foreign Keys, Composite Keys, and proper division between relationships in database design • In object design, we need to consider we have things like object references, etc. in order to accomplish links between objects

38. Textbook References • Section 2.1 - Fundamentals of Object Technology • REQUIRED READING for upcoming classes • Section 2.2 – Guided Tutorial In Analysis Modeling • Good reading to understand potential flow for project • Sections 2.2.4, 2.2.5 – are partial examples of our domain modeling exercise, but heavily influenced by UML diagrams to produce • Section 2.3 – Problem Statement for Case Studies • Examples that are referenced throughout the book (University Enrolment, Video Store, Contact Mgmt, Telemarketing)

39. In-Class Exercises for Week #3 • Domain Modeling • Validate Card Domain Model against games • DM from Problem Statement (textbook) • DM from Use Case(s) • DM from Requirements Document