1 Domain Model Adding Associations Chapter 11 Applying UML and Patterns -Craig Larman.

Slides:



Advertisements
Similar presentations
Object Design Examples with GRASP
Advertisements

Chapter 9 DOMAIN MODELS Objectives
Jan 21, Ron McFadyen1 Domain Modeling Specification classes “need-to-know” associations Reflexive associations “association checklist”
6/8/991 Analysis Tuesday 09/14/99 Revised: September 11, 2000 (APM)
Domain model: visualizing concepts
NJIT 1 Domain Model Visualizing Concepts Chapter 9 Applying UML and Patterns Craig Larman.
Database Systems: Design, Implementation, and Management Tenth Edition
9/18/011 Software Requirements Analysis and Design (Continued)
Domain Modeling Chandan R. Rupakheti and Steve Chenoweth Week 5, Day 1.
Objectives Design Class Diagrams Issues in system design Generalization Review UML papers.
Chapter 9 Domain Models. Domain Model in UML Class Diagram Notation A “visual dictionary”
Object-Oriented Analysis and Design
INFO 355Week #31 Systems Analysis II Domain Modeling INFO 355 Glenn Booker.
What is a domain model? “A domain model captures the most important types of objects in the context of the business. The domain model represents the ‘things’
Last lecture. What is a Use Case Use cases are stories (scenarios) of how actors use (interact with) the system to fulfill his goal. Examples Process.
Information Systems Analysis and Design Class Modeling
DOMAIN MODEL— PART 2: ATTRIBUTES SYS466. Looking For Potential Classes “Know the business”. Ask Questions Identify business concepts; filter nouns (person,
SOEN 343 Software Design Section H Fall 2006 Dr Greg Butler
TK2023 Object-Oriented Software Engineering CHAPTER 5 DOMAIN MODELLING.
Domain Modelling Presented By Dr. Shazzad Hosain.
Sept Ron McFadyen1 Section 10.1 Domain Models Domain Model: a visual representation of conceptual classes or real-world objects in a domain.
DOMAIN MODE: ASSOCIATIONS, MULTIPLICITY AND ATTRIBUTE-TEXT NOTATION SYS466.
Chapter 9 Domain Models $PH\06f522\LarmanApplUMLandPtrns\larman3EdDgmsCh01-14\09_domainModelsR2.ppt – RJL
Review ♦ System sequence diagram ♦ Domain model
Lecture 9 Enterprise Systems Development ( CSC447 ) COMSATS Islamabad Muhammad Usman, Assistant Professor.
Jan 21, Ron McFadyen1 Ch 10. Domain Model: Visualizing Concepts Domain model illustrated with a class diagram (with no operations defined)
1 Lecture 6: Operation Contracts. 2 Overview  What is contract ?  The guidelines for writing contracts for the system operations.  Use Case realizations.
Database Systems: Design, Implementation, and Management Eighth Edition Chapter 4 Entity Relationship (ER) Modeling.
Chapter 4 Entity Relationship (ER) Modeling.  ER model forms the basis of an ER diagram  ERD represents conceptual database as viewed by end user 
Conceptual Modeling Modeling the Problem Domain. Conceptual Modeling Decompose problem space into comprehensible concepts. Clarify the terminology or.
DOMAIN MODEL- VISUALIZING CONCEPTS Identify conceptual classes related to the current iteration requirements. Create an initial domain model. Distinguish.
Lecture 13-17, chitkara university.  Gives a conceptual framework of the things in the problem space  Helps you think – focus on semantics  Provides.
Chapter 9 Applying UML and Patterns -Craig Larman
Domain Model—Part 3: Associations, Multiplicity and Attribute- Text Notation.
♦ Use Case Model  Detailled use case - Important  Use case diagram- Refactoring Use case diagram  > 1 Last Lectures.
NJIT UML Class Diagrams Chapter 16 Applying UML and Patterns Craig Larman.
SYS466: Analysis and Design Using OO Models Domain Class Diagram.
SYS466: Analysis and Design Using OO Models Domain Class Diagram, Part 1.
Conceptual Model or Domain Models Chapter10 Applying UML and pattern.
Chapter 1 Applying UML and Patterns. The Need for Software Blueprints Knowing an object-oriented language and having access to a library is necessary.
Elaboration Iteration 1- Part 1
Database Systems: Design, Implementation, and Management Ninth Edition Chapter 4 Entity Relationship (ER) Modeling.
BTS430 Systems Analysis and Design using UML Domain Model—Part 2: Associations and Attributes.
Domain Model—Part 2: Attributes.  A logical data value of an object  (Text, p. 158)  In a domain model, attributes and their data types should be simple,
Repetition af Domæne model. Artifact influence emphasizing the Domain Model.
DOMAIN MODEL: ADDING ATTRIBUTES Identify attributes in a domain model. Distinguish between correct and incorrect attributes.
BTS430 Systems Analysis and Design using UML Domain Model—Part 2: Associations and Attributes.
Chapter 9: Domain Models.  The problem domain is modelled using a UML domain model: This is the first OO model that we will see (Use Cases are very useful.
Domain Model A representation of real-world conceptual classes in a problem domain. The core of object-oriented analysis They are NOT software objects.
BTS430 Systems Analysis and Design using UML Domain Model—Part 2: Associations and Attributes.
Larman chapter 101 Domain Model: Visualizing concepts Larman chapter 10.
Summary from previous lectures
1 Chapter 9: Operation Contracts Chapter 13 in Applying UML and Patterns Book.
1 Object Oriented Analysis and Design Conceptual Model.
OO DomainModeling With UML Class Diagrams and CRC Cards Chapter 6 Princess Nourah bint Abdulrahman University College of Computer and Information Sciences.
BTS430 Systems Analysis and Design using UML Design Class Diagrams (ref=chapter 16 of Applying UML and Patterns)
DOMAIN MODEL—PART 2: ATTRIBUTES BTS430 Systems Analysis and Design using UML.
Elaboration popo.
Chapter 9 Domain Models.
Domain Model: Visualizing concepts
From Inception to Elaboration
Conception OBJET GRASP Patterns
Conceptual Model.
DESIGN MODEL: USE-CASE REALIZATIONS WITH GRASP PATTERNS
OO Domain Modeling With UML Class Diagrams and CRC Cards
OO Domain Modeling With UML Class Diagrams and CRC Cards
Group Members Muhammad Zeeshan ( 16) Adnan Akhtar (4)
Object Oriented Analysis and Design Conceptual Model.
Object Oriented Analysis
Domain Model: Visualizing Concepts
Presentation transcript:

1 Domain Model Adding Associations Chapter 11 Applying UML and Patterns -Craig Larman

2 Objectives Identify associations for a domain model. Distinguish between need-to-know and comprehension-only associations.

3 Introduction Identify associations of conceptual classes needed to satisfy the information requirements of current scenarios. Also identify the aid in comprehending the domain model.

4 Associations An association is a relationship between instances of types that indicates some meaningful and interesting connection

5 Associations Fig 1.Associations

6 Useful Associations Associations for which knowledge of the relationship needs to be preserved for some duration. Associations derived from the Common Associations List.

7 UML Association Notation An association is represented as a line between classes with an association name. Associations are inherently bidirectional. Optional reading direction arrow is only an aid to the reader of the diagram.

8 UML Association Notation

9 Finding Associations-Common Associations List The common categories that are worth considering are: A is a physical part of B. Eg: Wing-Airplane A is a logical part of B. Eg: SalesLineItem- Sale. A is physically contained in B. Eg: Register- Store.

10 Common Associations List 2 A is logically contained in B. Eg:ItemDescription-Catalog. A is a description of B. Eg:ItemDescription- Item. A is a line item of a transaction or report B. Eg:SalesLineItem-Sale. A is a member of B. Eg: Cashier-Store. A uses or manages B. Eg:Cashier-Register.

11 Common Associations List 3 A is known/logged/recorded/reported/captured in B.Eg: Sale-Register. A is an organizational subunit of B. Eg:Department-Store. A communicates with B. Eg:Customer- Cashier. A is next to B. Eg:City-City.

12 Common Associations List 4 A is related to a transaction B. Eg: Customer- Payment. A is a transaction related to another transaction B. Eg:Payment-Sale. A is next to B. Eg:City-City. A is owned by B. Eg:Register-Store. A is an event related to B. Eg:Sale-Customer.

13 High-Priority Associations A is a physical or logical part of B. A is physically or logically contained in/on B. A is recorded in B.

14 Associations Guidelines The knowledge of the relationship needs to be preserved for some duration. Identifying conceptual classes is more important than identifying associations. Avoid showing redundant or derivable associations.

15 Roles Each end of an association is called a role. Roles may have name multiplicity expression navigability

16 Multiplicity Multiplicity defines the number of instances of a class A,that can be associated with one instance of class B,at a particular moment. Eg: In countries with monogamy laws,a person can be married to 1 person at any particular time.But over a span of time one person can be married to many persons.

17 Multiplicity Fig 3 Multiplicity on an association.

18 Multiplicity Fig 4. Multiplicity values.

19 Naming Associations Name an association based on TypeName- VerbPhrase-TypeName format. Names should start with a capital letter. Legal formats are: Paid-by PaidBy

20 Associations Names Fig 5.Association names.

21 Multiple Associations Two types may have multiple associations between them.

22 Multiple Associations Fig 6. Multiple associations.

23 Implementation The domain model can be updated to reflect the newly discovered associations. But,avoid updating any documentation or model unless there is a concrete justification for future use. Defer design considerations so that extraneous information is not included and maximizing design options later on.

24 Cleaning Associations 1 Do not overwhelm the domain model with associations that are not strongly required. Use need-to-know criterion for maintaining associations. Deleting associations that are not strictly demanded on a need-to-know basis can create a model that misses the point.

25 Cleaning Associations 2 Add comprehension-only associations to enrich critical understanding of the domain.

26 A partial domain model

27 Without need-to-know associations

28 Conclusion When in doubt if the concept is required,keep the concept. When in doubt if the the association is required,drop it. Do not keep derivable association.