CSSE 374: Domain Model Refinements and Iteration 3 Preparations Q1 These slides and others derived from Shawn Bohner, Curt Clifton, Alex Lo, and others.

Slides:



Advertisements
Similar presentations
CSSE 374: Object-Oriented Design Exercise Steve Chenoweth Office: Moench Room F220 Phone: (812) These slides and.
Advertisements

Chapter 22 Object-Oriented Systems Analysis and Design and UML Systems Analysis and Design Kendall and Kendall Fifth Edition.
CSSE 374: Introduction to Object- Oriented Analysis and Design Q1 Steve Chenoweth Office: Moench Room F220 Phone: (812)
Jan 2003Ron McFadyen Generalization (Ch 26) a generalization is a relationship between a general thing (the superclass or parent class) and a.
November R McFadyen1 Aggregation and Composition – section 27.2 both are associations used to denote that an object from one class is part.
Jan 16, Ron McFadyen1 Ch 9. Use-case model: drawing System Sequence Diagrams Iteration 1: a simple cash-only success scenario of Process Sale.
Copyright ©2004 Cezary Z Janikow 1 Domain Model n Visualization of entities and relationships n In UP presented as Class Diagrams – Classes, Relationships,
IMS1805 Systems Analysis Topic 4: How do you do it? Guidelines for doing analysis (continued from last week)
6/8/991 Analysis Tuesday 09/14/99 Revised: September 11, 2000 (APM)
Refining the Domain Model
Object-Oriented Analysis and Design
Sharif University of Technology Session # 7.  Contents  Systems Analysis and Design  Planning the approach  Asking questions and collecting data 
Designing with Interaction and Design Class Diagrams Chapters 15 & 16 Applying UML and Patterns Craig Larman With some ideas from students in George Blank’s.
Domain Modeling Chandan R. Rupakheti and Steve Chenoweth Week 5, Day 1.
UML Class Diagrams: Basic Concepts. Objects –The purpose of class modeling is to describe objects. –An object is a concept, abstraction or thing that.
Entity/Relationship Modelling
Business Modeling Domain Modeling Source: Use Case Driven Object Modeling with UML – A Practical Approach By Doug Rosenberg ISBN:
Object-Oriented Analysis and Design
CSSE 374: More GRASP’ing and Use Case Realization Steve Chenoweth Office: Moench Room F220 Phone: (812) These.
CSSE 374: Design Class Diagrams Steve Chenoweth Office: Moench Room F220 Phone: (812) These slides and others.
CSSE 374: Even More Object Design with Gang of Four Design Patterns These slides derived from Shawn Bohner, Curt Clifton, and others involved in delivering.
CSSE 374: Interaction Diagrams Steve Chenoweth Office: Moench Room F220 Phone: (812) These slides and others derived.
CSSE 374: Final Perspectives on Software Architecture and Design These slides derived from Shawn Bohner, Curt Clifton, Alex Lo, and others involved in.
CSSE 374: Operations Contracts and Logical Architectures Steve Chenoweth Office: Moench Room F220 Phone: (812)
CSSE 374: GRASP’ing at the First Five Patterns Principles Steve Chenoweth Office: Moench Room F220 Phone: (812)
Object-Oriented Design
CSSE 374: More Object Design with Gang of Four Design Patterns Steve Chenoweth Office: Moench Room F220 Phone: (812)
Entity-Relationship Model Ch. 3
Chandan Rupakheti Office: Moench Room F203 Phone: (812) These slides and others derived from Shawn Bohner, Curt.
CSSE 374: Introduction to Gang of Four Design Patterns
CSSE 374: 3½ Gang of Four Design Patterns These slides derived from Steve Chenoweth, Shawn Bohner, Curt Clifton, and others involved in delivering 374.
Database Management System Prepared by Dr. Ahmed El-Ragal Reviewed & Presented By Mr. Mahmoud Rafeek Alfarra College Of Science & Technology Khan younis.
11 Chapter 11 Object-Oriented Databases Database Systems: Design, Implementation, and Management 4th Edition Peter Rob & Carlos Coronel.
Sept Ron McFadyen1 Section 10.1 Domain Models Domain Model: a visual representation of conceptual classes or real-world objects in a domain.
CSSE 374: More GRASP’ing for Object Responsibilities
CS3773 Software Engineering Lecture 04 UML Class Diagram.
Conceptual Modeling Modeling the Problem Domain. Conceptual Modeling Decompose problem space into comprehensible concepts. Clarify the terminology or.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 1 Object-oriented Design.
INFO 620Lecture #81 Information Systems Analysis and Design Class Diagram Refinement INFO 620 Glenn Booker.
Domain Model Refinement Larman, chapter 31 CSE 432: Object-Oriented Software Engineering Glenn D. Blank, Lehigh University.
DOMAIN MODEL- VISUALIZING CONCEPTS Identify conceptual classes related to the current iteration requirements. Create an initial domain model. Distinguish.
Chapter 9 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.
Generalization (Ch 26) a generalization is a relationship between a general thing (the superclass or parent class) and a more specific kind of thing (the.
Repetition af Domæne model. Artifact influence emphasizing the Domain Model.
Databases Illuminated Chapter 3 The Entity Relationship Model.
Object-Oriented Analysis and Design CHAPTERS 9, 31: DOMAIN MODELS 1.
Entity-Relation Model. E-R Model The Entity-Relationship (ER) model was originally proposed by Peter in 1976 ER model is a conceptual data model that.
OO Methodology Elaboration Iteration 3 – Part 1 Refining Models.
INTRODUCTION TO DATA MODELING CS 260 Database Systems.
Chapters 10, 11 SSD (Revision) SD DCD Exam Object-Oriented Design.
Sept 2004Ron McFadyen Generalization (Ch 26) a generalization is a relationship between a general thing (the superclass or parent class) and a.
BTS430 Systems Analysis and Design using UML Domain Model—Part 2: Associations and Attributes.
Larman chapter 101 Domain Model: Visualizing concepts Larman chapter 10.
Session 33 More on SOLID Steve Chenoweth Office: Moench Room F220 Phone: (812) Chandan Rupakheti Office: Moench.
Domain Model Refinement Notation Extensions. Things not seen before in the Domain Model Similar to the concepts in the Object Models Generalization and.
DOMAIN MODEL—PART 2: ATTRIBUTES BTS430 Systems Analysis and Design using UML.
Topic 3: ER – Entity Relationship Model (ERM) 6/12/
Chapter 5: Structural Modeling
Entity/Relationship Modelling
CSSE 374: UML Activity Diagrams
Domain Model Refinement
CSSE 374: Domain Model Refinements and Iteration 3 Preparations
UML Class Diagrams: Basic Concepts
Entity – Relationship Model
Relating Use Cases popo.
Chapter 11: Class Diagram
a generalization is a relationship between a general thing (the
Chapter 11: Class Diagram
Presentation transcript:

CSSE 374: Domain Model Refinements and Iteration 3 Preparations Q1 These slides and others derived from Shawn Bohner, Curt Clifton, Alex Lo, and others involved in delivering 374. Steve Chenoweth Office: Moench Room F220 Phone: (812) Chandan Rupakheti Office: Moench Room F203 Phone: (812)

Learning Outcomes: O-O Design Demonstrate object-oriented design basics like domain models, class diagrams, and interaction (sequence and communication) diagrams. Final Exam - Thoughts Domain Model Refinement Conceptual Classes - review

Additional Design Studio Topic Ideas Look for problems where there are lots of “which class should be responsible for X” questions Challenging design problems you’ve already faced and how you solved them Current design problems that you haven't solved yet Future extensions that will need to be considered

More on Domain Modeling Above – New ideas for system modeling are proposed frequently. This figure illustrates an idea for doing domain models in color, used by Peter Coads in 1999.

Modeling Changing States Suppose a concept X has multiple states  Draft vs. Sent  Purchase Request vs. Order Do not model the states as subclasses of X! Instead:  Define a State hierarchy and associate X with State or,  Ignore showing the states in the domain model

State Example

Association Classes: Consider… In NextGen POS:  Authorization Services assign a merchant ID to each store  Payment Authorization Request from store to service must use the merchant ID  A store has a different merchant ID for each service Where should the merchant ID appear in the domain model?

Guideline If a class C can simultaneously have many values for the same attribute A, put A in another class associated with C

Association Class Guideline Association class might be useful in a domain model if:  The association has a related attribute  Instances of the association class can only last as long as the association does  There is a many-to-many association between two concepts and information is needed to distinguish the pairs Q2

Association Class Examples Q3

Recall, Composition A composition relationship implies:  An instance of the part belongs to only one composite instance at a time  The part must always belong to a composite  The composite is responsible for creating/deleting the parts Not to be confused with the composite pattern, which is similar. (sigh)

Composition in Domain Models Guideline: If in doubt, leave it out. But, consider showing composition when:  Lifetime of part is bounded within lifetime of composite  An obvious whole-part physical assembly exists  Composite properties propagate to the parts  Composite operations propagate to the parts Q4

Examples of Composition in NextGen Domain Model

Problem: What happens to old Sales when a product’s price changes? Solutions?Solutions?

Time Intervals Q5

Rolls… I’m HHUUUNNNNGRY!

Er, Roles… Pros and cons?

Qualified Associations Don’t overdo it… Q6

Supports parallel analysis work NextGen POS example: Splitting Domain Model into Packages

NextGen POS Core Package

NextGen POS Sales Package with Assocations from Core Package Store is “owned” by Core package, but also shown here to illustrate associations Q7

If Domain is big enough to partition into packages, Group conceptual Classes that: Are in the same subject area Are in the same class hierarchy Participate in the same use cases Are strongly associated Q8