Home > Patterns and Practices > Analysis Model

Analysis Model

The first step towards solving the problem is to model the domain in the context of the problem. The domain model is an analysis object model and represts the problem domain. We are still not into the solution domain

How do we identify conceptual classes / classify domain objects? The usual techniques followed are

  • noun-phrase identification
  • and using a conceptual class category list (Popularized by Craig Larman in his OOAD treatize, An Introduction to Object-Oriented Analysis and Design and the Unified Process

Noun-phrase identification is subjective to the language used. Hence its better to use a conceptual class category list as suggested by Larman. This list can be used to identify potential conceptual classes in the problem domain. The following is the conceptual class category list as suggested by Larman

  • physical or tangible objects
  • specifications, designs, or descriptions of things
  • Places
  • transactions
  • transaction line items
  • roles of people
  • containers of other things
  • things in a container
  • other computer or electro-mechanical systems external to the system
  • abstract noun concepts
  • organizations
  • events
  • processes (often not represented as a concept, but may be)
  • rules and policies
  • catalogs
  • records of finance, work, contracts, legal matters
  • financial instruments and services
  • manuals, documents, reference papers, books

Using this list we can identify the following conceptual classes in our domain model.

Class category Example in our domain
physical or tangible objects Book
records of finance, work, contracts, legal matters Receipt
transactions Sale
transaction line items SalesLineItem

The next step is to find how these classes are related. Again we can use a common associations list suggested by Larman.

  • A is a physical part of B
  • A is a logical part of B
  • A is physically contained in/on B
  • A is logically contained in B
  • A is a description for B
  • A is a line item of a transaction or report B
  • A is known/logged/recorded/reported/captured in B
  • A is a member of B
  • A is an organizational subunit of B
  • A uses or manages B
  • A communicates with B
  • A is related to a transaction B
  • A is a transaction related to another transaction B
  • A is next to B
  • A is owned by B
  • A is an event related to B

Though its good to capture all of these associations in the model, it will be helpful just to identify the need to know associations. Such high priority associations are

  • A is a physical or logical part of B.
  • A is physically or logically contained in/on B.
  • A is recorded in B.
Association category Example in our domain
A is a physical or logical part of B A SalesLineItem logically contains a Book, A Sale logically conatins one or many SalesLineItem
A is recorded in B A sale is recorded in a receipt

The initial domain model:

Let us see how use this Analysis Model (problem domain) to get our Design Model (solution domain) in our next post.

Advertisements
  1. No comments yet.
  1. November 19, 2010 at 10:59 pm

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: