chapter 4

• Domain Modeling


  Systems Analysis and Design in a Changing World 7th Ed
• Chapter 4 Outline


  • "Things" in the Problem Domain
  • The Domain Model Class Diagram
• Learning Objectives


  • Explain how the concept of "things" in the problem domain also define requirements
  • Identify and analyze data entities and domain classes needed in the system
  • Read, interpret, and create a domain model class diagram
  • Understand the domain model class diagram for the RMO Consolidated Sales and Marketing System
• Problem domain


  The specific area (or domain) of the users' business need that is within the scope of the new system
• "Things"


  Items users work with when accomplishing tasks that need to be remembered
• "Things"


  • products, sales, shippers, customers, invoices, payments, etc.
• Domain classes


  The "Things" that are modeled
• In this course, we will call them domain classes. In database class you may call them data entities
• Brainstorming Technique


  1. Identify a user and a set of use cases

  2. Brainstorm with the user to identify things involved when carrying out the use case

  3. Use the types of things (categories) to systematically ask questions about potential things

  4. Continue to work with all types of users and stakeholders to expand the brainstorming list

  5. Merge the results, eliminate any duplicates, and compile an initial list
• Noun Technique


  A technique to identify problem domain classes (things) by finding, classifying, and refining a list of nouns that come up in in discussions or documents
• The Noun Technique is a popular, systematic technique but it does end up with long lists and many nouns that are not things that need to be stored by the system. It has difficulty identifying synonyms and things that are really attributes. It is a good place to start when there are no users available to help brainstorm.
• The Noun Technique: Steps

  1. Using the use cases, actors, and other information about the system— including inputs and outputs—identify all nouns.

  2. Using other information from existing systems, current procedures, and current reports or forms, add items or categories of information needed.

  3. As this list of nouns builds, refine it by asking questions to decide whether to include, exclude, or research further.

  4. Create a master list of all nouns identified and then note whether each one should be included, excluded, or researched further.

  5. Review the list with users, stakeholders, and team members and then define the list of things in the problem domain.
• Partial List of Nouns for RMO


  • With notes on whether to include as domain class
• Attribute


  Describes one piece of information about each instance of the class
• Identifier or key


  One attribute uniquely identifies an instance of the class. Required for data entities, optional for domain classes.
• Compound attribute


  Two or more attributes combined into one structure to simplify the model.
• Class


  A type of thing
• Object


  A specific instance of the class
• Association


  A naturally occurring relationship between classes (UML term)
• Multiplicity


  The number of associations between classes: 1 to 1 or 1 to many (synonym to cardinality)
• UML is the primary emphasis of this text
• Relationship


  The term for number of relationships in entity relationship diagrams: 1 to 1 or 1 to many (synonym to multiplicity)
• Associations and Relationships apply in two directions
• Minimum and Maximum Multiplicity


  Associations have minimum and maximum constraints. Minimum is zero (optional) or at least one (mandatory).
• Domain Class


  Classes that describe objects in the problem domain
• Class Diagram


  A UML diagram that shows classes with attributes and associations (plus methods if it models software classes)
• Domain Model Class Diagram

  A class diagram that only includes classes from the problem domain, not software classes so no methods
• UML Domain Class Notation

  Domain class has a name and attributes (no methods). Class name is always capitalized. Attribute names are not capitalized and use camelback notation.
• A Simple Domain Model Class Diagram

  • Matches the semantic net shown previously. Shows associations between Customer, Order, and Order Item.
• UML Notation for Multiplicity

  Notation for minimum and maximum multiplicity of associations
• Domain Model Class Diagram

  • Bank with many branches, showing notation for key, attributes, and multiplicity
• Domain Model Class Diagram

  A diagram that models the "things" in the problem domain, called domain classes or data entities
• Domain Model Class Diagram

  • Shows domain classes and their associations
  • Does not include methods, as they are not yet software classes
• Association Relationships


  Naturally occurring relationships among classes
• Generalization/Specialization Relationships


  Hierarchical relationships where subordinate classes are special types of the superior classes (inheritance)
• Whole Part Relationships


  Relationships where one class is part of or a component of another class (aggregation or composition)
• Abstract Class


  A class that allows subclasses to inherit characteristics but never gets instantiated
• Concrete Class


  A class that can have instances
• Inheritance


  The concept that subclasses inherit characteristics of the more general superclass
• Aggregation


  A whole-part relationship where the component part exists separately and can be removed and replaced