• Introduction
• Identifying Concepts
• Identifying Associations
• Identifying Attributes

• Definition:
  • A representation of meaningful concepts in a problem domain
  • Focuses on domain concepts not software entities
• To Be Aware Of:
  • Require existing uses cases and actors
  • May be built at the same time as use cases and actors

• What They Illustrate:
  • Concepts (i.e., ideas, things, or objects)
  • Associations between concepts
  • Attributes of concepts
• Purpose:
  • Decompose the problem domain into comprehensible units
  • Clarify terminology

1. List the candidate concepts
2. Add associations
3. Add attributes

• Physical Objects
• Places
• Organizations
• Events
• Records
• Containers
• Roles of People
• Descriptions, Specifications, Rules
• Processes

• Don't confuse concepts and attributes
  • If you do not think of it as numbers or letters in the real world it is probably a concept
    
    

• Dont include things that aren't relevant
  • 
    

• Include specifications
  • Will deleting an instance result in information loss?
  • Can a description reduce redundancy?
    
    

• Part-of (physical or logical)
• Contained-in (physical or logical)
• Description-of
• Member-of
• Uses/Manages/Controls
• Communicates-with
• Related-to
• Owned-by
• Near/Far-from/Above/Below...

• Look for relationships that need to be preserved
• Avoid redundant or derivable associations
• Think about verb phrases

• Each end of an association is called a role
• In conceptual models roles often have:
  • A name
    
    

  • A multiplicity expression
    
    

• Two concepts can have more than one association
  
  

• One concept alone can have an association
  
  

• Think about the information requirements of the use cases
• Think about what needs to be remembered
• Focus on simple/pure data types (i.e., in which unique identity is not meaningful)

• Attributes need not be primitive types (e.g., phone number, social security number)
• Use non-primitive types if:
  • Units are important
  • Delimiters are useful

The Display Map use case description includes the concept of a "Route". What is a Route?

• A Route "has" Streets
  
  A Route that uses Elm St. does not use all of Elm St.
  
• A Route "has" Intersections
  
  What about cul-de-sacs?
  
• A Route "has" Locations
  
  Seems duplicative
  
• A Route "has" StreetSegments
  
  Seems like a good approach
  Requires us to change StreetSegment - it needs to include Locations (i.e., shape points)