University of Southern California
Center for Systems and Software Engineering
CS577a: Domain Modeling
The First Step in Object-Oriented
Analysis & Design
David Klappholz
Nupul Kukreja
September 25, 2009
09/26/2009
© USC-CSSE 2005-2009
1
University of Southern California
Center for Systems and Software Engineering
Agenda
•Provide an in-depth discussion of Object Oriented
Analysis and Design (OOA&D):
The entire process of OOA&D is split over a ‘set’ of
lectures – incremental in presentation
We start off with ‘Domain Modeling’ in this lecture
and will deal with Architecture, Use-Case analysis
and Realization over subsequent lectures
•We teach ONE specific approach for ‘Domain Modeling’
– The Color Coded Approach.
•The approach is presented using an example of an
Internet Bookstore application that is to be developed.
09/26/2009
© USC-CSSE 2005-2009
2
University of Southern California
Center for Systems and Software Engineering
Points to Note
•The ideal location for ‘documenting’ the Domain
Model is the OCD, however, for this semester, we
shall be documenting this in the SSAD (The additional
content of the various sections will also be covered in
subsequent OOA&D lectures)
•Activity diagrams have been explained earlier in the
context of Business Workflows and the RSM Tutorials
and thus won’t be covered in our discussion of
OOA&D
•Use-Case Modeling i.e. diagrammatic representation
will NOT be covered since it’s covered in the RSM
Tutorial.
09/26/2009
© USC-CSSE 2005-2009
3
University of Southern California
Center for Systems and Software Engineering
Domain Modeling
• The end goal of object-oriented analysis and
design is the construction of the classes that will
be used to implement the desired software
system -- excluding, of course, that part of the
system that will consist of NDI’s and NCS’s, but
including those classes that will interact with any
NDI’s and NCS’s.
• Domain modeling is a first step in that direction.
09/26/2009
© USC-CSSE 2005-2009
4
University of Southern California
Center for Systems and Software Engineering
What is a Domain Model?
• If the system being constructed is an automated version
of an existing manual system, or an upgrade of an
existing software system then the Domain Model (DM) is
a model of the project client’s organization/domain –
sometimes referred to as the “problem domain”
• A DM describes:
– the entities that make up those parts of the project client’s
organization that are relevant to the new/upgraded
software that is to be developed
– the relationships between and among these entities
– The interactions between and among the entities, i.e., the
way the organization currently does its business, i.e., preautomation.
09/26/2009
© USC-CSSE 2005-2009
5
University of Southern California
Center for Systems and Software Engineering
What is a Domain Model (cont)?
• The discussion on the previous slide suggests that
entity-relationship (ER) notation be used for domain
modeling
• Using ER notation is a poor choice, because UML
class diagrams are becoming more popular for DMs
and DB definitions, so we’ll be using the latter notation.
• Note that in class diagrams entities are called “classes”
and relationships are called “associations,” but we’ll
allow ourselves to be sloppy about this distinction.
09/26/2009
© USC-CSSE 2005-2009
6
University of Southern California
Center for Systems and Software Engineering
Why do Domain Modeling (DM)?
• Software project clients live in one world/culture
• Software developers live in a very different
world/culture
• This is often referred to as the “Two Cultures”
problem
• It is a problem because if the developers don’t learn
enough about the client’s domain, they are likely to
design the wrong (useless) software
• Domain Modeling is one way for the developers to
begin to understand the client’s domain
• …and a DM can be used as the first step in going to
a requirements analysis model, and, eventually to an
implementation class model
09/26/2009
© USC-CSSE 2005-2009
7
University of Southern California
Center for Systems and Software Engineering
What is a Domain Model? (cont.)
• If, on the other hand, the system being developed is not
an automated version of an existing manual system, but
is, rather, a completely new software system, then the
domain model will be an initial class model of what the
client wants the new system to look like.
• In either case, once we get to the design stage, the final
(implementation) class model will likely look
considerably different from the original domain model,
but there will likely be some classes in it that were in the
original domain model, probably with modified details.
09/26/2009
© USC-CSSE 2005-2009
8
University of Southern California
Center for Systems and Software Engineering
Internet Bookstore
• The system that we will use as our example in
the discussion of domain modeling will be an
Internet bookstore.
• If the Internet bookstore were simply an
automated version of an existing bricks and
mortar bookstore, then the initial domain model
would include nothing about Internet
objects/classes like log-ins or shopping carts.
Rather, it would contain only objects/classes that
occur in brick and mortar bookstores
09/26/2009
© USC-CSSE 2005-2009
9
University of Southern California
Center for Systems and Software Engineering
Internet Bookstore (cont.)
• Since, in the case to be discussed here, the client has no
bricks and mortar bookstore, the domain model will, in
fact, include objects/classes that we initially feel will likely
be in the Internet bookstore software system – and which
feeling we must, naturally, check with the relevant clientside project stakeholders.
• In either case, i.e., whether the to-be-built system is an
automated version of a manual system or a from-scratch
software system, the domain model will end up being a
good starting point in the development of the ultimate
implementation class model; i.e., the domain model will
morph, step by step, into an implementation model.
09/26/2009
© USC-CSSE 2005-2009
10
University of Southern California
Center for Systems and Software Engineering
Internet Bookstore Desired Functionalities – I
• The bookstore should accept orders over the internet
• The bookstore should maintain a list of accounts for up
to 1,000,000 customers
• The bookstore should provide password protection for
all accounts
• The bookstore should provide the ability to search the
master book catalog
• The bookstore should provide a number of search
methods on that catalog, including search by author,
search by title, search by ISBN number, and search by
keyword
• The bookstore should provide a secure means of
allowing customers to pay by credit card
09/26/2009
© USC-CSSE 2005-2009
11
University of Southern California
Center for Systems and Software Engineering
Internet Bookstore Desired Functionalities – I
•The bookstore should provide a secure means of
allowing Customers to pay via purchase order
•The bookstore should provide a special kind of account
that is pre-authorized to pay via purchase order
•The bookstore should provide electronic links between
the Web and the book information database (BID) and
the shipping fulfilment center
•The bookstore should also provide electronic links
between the Web and BID and the inventory
management system
•The bookstore should maintain reviews of books and
should allow anyone to upload review comments
•The bookstore should maintain ratings on books based
on customer inputs
09/26/2009
© USC-CSSE 2005-2009
12
University of Southern California
Center for Systems and Software Engineering
Domain Modeling
Using Color Coded UML
• The specific Domain Modeling approach/method
that we will use, one of many possible
approaches/methods, is a very simplified version
of a domain modeling methods called “Color
Modeling (CM).”
09/26/2009
© USC-CSSE 2005-2009
13
University of Southern California
Center for Systems and Software Engineering
Brief History of Color Modeling
• Color modeling was first used on a Java
software development project in Singapore in
1997
• Peter Coad, an important advocate of the
object oriented approach, along with a
number of colleagues, refined the technique
over time and in 1999 an introduction to the
technique was published in the book – Java
Modeling in Color with UML
09/26/2009
© USC-CSSE 2005-2009
14
University of Southern California
Center for Systems and Software Engineering
Color Modeling
• In our version of color modeling there are three*
varieties of ‘domain classes’ (also known as
Archetypes)
• The three varieties (archetypes) are:
– Party/Place/Thing classes
– Role classes
– Activity classes
*The original approach has four archetypes. The 4th one occurs only during
low level design. It’s called the ‘Description’ Archetype. It is NOT needed
for domain modeling and hence won’t be covered here.
09/26/2009
© USC-CSSE 2005-2009
15
University of Southern California
Center for Systems and Software Engineering
Domain Modeling
• In our version of the color modeling approach to
domain modeling we start with Activity Classes.
• That is, we attempt to identify all, or most, of the
activities that occur in the problem domain, and:
– For each activity, create a class representing the activity --with the stereotype <activity>
– Identify each Party, Place or Thing who participate in the
activity and create respective classes with the stereotype
<Party>, <Place> or <Thing>
– Identify what ‘Roles’ do the Party, Place or Things play while
interacting with the activity. These identified ‘Role’ classes
are stereotyped with <Role> (elaborated later).
09/26/2009
© USC-CSSE 2005-2009
16
University of Southern California
Center for Systems and Software Engineering
Internet Bookstore Domain Model
• As an initial example let us focus on the activity of
Registration that is one of the requirements of the
system
• Since the requirements refer to accounts with password
protection, a software developer is likely to assume that
‘People’ in the role of ‘Customers’ will have to register
with the Internet bookstore in order to create accounts
for themselves
• Of course, like everything else during this early phase of
the development process, this assumption must be
verified with the relevant critical stakeholders
(Assuming it has been verified, a first version of the classes
that arise from it are shown on the next slide)
09/26/2009
© USC-CSSE 2005-2009
17
University of Southern California
Center for Systems and Software Engineering
<Party>
Person
Is A
<Role>
Customer
Performs
<Activity>
Registration
Produces
<Thing>
Account
<Thing>
Privileged Account
09/26/2009
<Thing>
Ordinary Account
© USC-CSSE 2005-2009
18
University of Southern California
Center for Systems and Software Engineering
Classes & Colors
• In color modeling
– <activity> classes are colored pink
– <party>, <place>, and <thing> classes are colored green
– and <role> classes are colored yellow
• You can decide for yourself, when you’ve seen a more
complete domain model, or have developed one yourself,
whether the proponents of color modeling are right about
the usefulness of the colors
• The following slides elaborate on each of the color model
‘Archetypes’ and how the related colors are ‘linked’ to one
another
09/26/2009
© USC-CSSE 2005-2009
19
University of Southern California
Center for Systems and Software Engineering
‘Activity’ Class Archetype - I
•
An Activity class, (i.e. an instance of the Activity
Class Archetype) models an activity involved in
the problem domain’s workflow/business that
happens:
– Either in an moment/instant of time, e.g.: the
reading of a sensor, Customer Registration, the
placing of an order to buy something, etc.
– Or over an interval of time, e.g.: a flight, a
meeting, etc.
09/26/2009
© USC-CSSE 2005-2009
20
University of Southern California
Center for Systems and Software Engineering
– In color modeling every Activity
class
• is Pink
• has the stereotype <activity>
– The Activity archetype shown to
the right includes (arche)typical*
• Attributes
• and Methods (responsibilities)
that Activity classes have
*these are suggested attributes/methods
there will be more, but these are
commonly seen to occur
09/26/2009
© USC-CSSE 2005-2009
<<activity>>
Activity
referenceNumber (or id)
date OR dateAndTime
priority
status
complete
cancel
getPreviousActivities
getNextActivities
startNextActivity
listInstances
21
University of Southern California
Center for Systems and Software Engineering
‘Activity’ Class Archetype - II
• Typical Attributes:
– referenceNumber (or id): The domain may require that
every ‘activity’ be tracked by a unique identification
number
– date OR dateAndTime: It may be required that the date
or both date and time of occurrence of the activity be
recorded, for business reasons (e.g. The date and time of
placing and order on the internet bookstore)
– status: the status of the activity i.e. ‘In Process’,
‘Completed’ or ‘Canceled’
– priority: There may be a need to assign a priority to an
activity (e.g. Shipping of a ‘delayed’ order is of a higher
priority)
09/26/2009
© USC-CSSE 2005-2009
22
University of Southern California
Center for Systems and Software Engineering
‘Activity’ Class Archetype - III
• Typical methods:
– complete, cancel: methods to mark the corresponding status of
the activity
– getPreviousActivity: (can be criteria based) This is used to get
the list of activities that ‘must’ occur before the current activity
(e.g. For the Internet Bookstore, a Customer MUST be registered
before placing an order)
– getNextActivity: similarly there may be a need to know what
subsequent activities are possible after the current activity
– startNextActivity: The current activity may be a ‘starting point’
(or responsible for) generating a new Activity (e.g. Once an order
is placed it MUST be ready for being shipped)
– listInstances: list all current ‘instance’ of this activity (i.e. listing
the customers ‘browsing’ the bookstore)
09/26/2009
© USC-CSSE 2005-2009
23
University of Southern California
Center for Systems and Software Engineering
‘Role’ Class Archetype - I
• A role class, i.e., an instance of the Role Class
Archetype, models a way in which one or more
instances of a Party, Place, or Thing participates in
the problem domain
• Examples of role classes are: Job Applicant,
Account Holder, Pilot, Librarian, Administrator
09/26/2009
© USC-CSSE 2005-2009
24
University of Southern California
Center for Systems and Software Engineering
– In color modeling every Role
class
• Is Yellow
• has the stereotype <role>
– The Role archetype shown to
the right includes (arche)typical
• Attributes
• And Methods (responsibilities)
that Role classes have
09/26/2009
© USC-CSSE 2005-2009
<<role>>
Role
status (or permission)
id
isAuthorized
listAllActivities
listActivitiesByCriteria
listInstances
25
University of Southern California
Center for Systems and Software Engineering
‘Role’ Class Archetype - II
• Typical Attributes:
– status (or permission): Records the current
authorization status of the entity that participates in a
given activity
– id: most organizations will allocate a special form of
identification for a role (e.g. System Administrator may
also be stored as SysAdminWinXP_SP#2_007)
– But no specific ‘name’ attribute? The actual ‘name’ of
this class must be a descriptive of that i.e. if there is a
role ‘Manager’ then the name of the class itself should
be ‘Manager’ – the color should tell you that it’s a role
class. You may have an explicit ‘name’ attribute if you
wish.
09/26/2009
© USC-CSSE 2005-2009
26
University of Southern California
Center for Systems and Software Engineering
‘Role’ Class Archetype - III
• Typical Methods:
– isAuthorized: A check to see if the role is authorized to
participate in the said activity
– listAllActivities: lists all activities that this role
participates in (e.g. List all activities that a ‘Customer’ can
perform)
– listActivitiesByCriteria: lists the activities that this role
participates in based on some criteria specific to the
domain)
– listInstances: lists all ‘instances’ of the said role that are
currently participating in a given activity based on some
criteria (e.g. list all ‘Customers’ currently logged in to the
system)
09/26/2009
© USC-CSSE 2005-2009
27
University of Southern California
Center for Systems and Software Engineering
‘Party/Place/Thing’ Class Archetype - I
• A party/place/thing class, i.e., an instance of the
Party/Place/Thing Class Archetype, models, as
might be expected, a party, a place, or a thing that is
part of the problem domain, where:
– A ‘Party’ is a person or an organization, examples of
which are:
• Person: Sam Smith, Jane Jones, etc.
• Organization: Billing Department, Leadership Council, etc.
– Examples of Places are: Airport, Office, Store,
Warehouse, Bank Branch
– A Thing is a physical object, examples of which are: CD,
Airplane, Book, Copying Machine, etc.
09/26/2009
© USC-CSSE 2005-2009
28
University of Southern California
Center for Systems and Software Engineering
– In color modeling every
Party/Place/Thing class
• is colored Green
• has the stereotype <party>,
<place>, or <thing>
– The Party/Place/Thing archetype
shown to the right includes
(arche)typical
• Attributes
• and Methods (responsibilities) that
Party/Place/Thing classes have
<<party, place, thing>>
Party Place Thing
id
name
address
listAllRoles
listRolesByCriteria
listInstances
– These ‘typical’ attributes and
methods are elaborated on the
following slides
09/26/2009
© USC-CSSE 2005-2009
29
University of Southern California
Center for Systems and Software Engineering
‘Party, Place, Thing’ Archetype - II
• Typical Attributes:
– id: some form of identification (e.g SSN,
Building number, serial number etc.,)
– name: a human readable name (e.g. John
Smith, Olin Hall of Engineering, RSM DVD)
– address: the actual ‘address’ of the entity (e.g.
residential/official address of Party, location of
the Place or the actual ‘physical location’ of a
thing i.e. CD in a warehouse)
09/26/2009
© USC-CSSE 2005-2009
30
University of Southern California
Center for Systems and Software Engineering
‘Party, Place, Thing’ Archetype - III
• Typical Methods:
– listAllRoles: used to list all the roles that the entity ‘plays’
when participating in any activity (e.g. a Person can play a
role of an ‘Employee’ or a ‘System Administrator’ or
‘Manager’)
– listRolesByCriteria: instead of listing all the roles list only
certain selective ones based on some criteria (e.g. list the
all ‘Employees’ who are allowed to make changes to the
Shipping records)
– listInstances : lists all the Party, Places or Things entities
that belong to this ‘set’ (it would be better to name them as
listParties, listPlaces and listThings – the ‘listing’ could be
based on some criteria too!)
09/26/2009
© USC-CSSE 2005-2009
31
University of Southern California
Center for Systems and Software Engineering
Color Modeling
• The previous slides gave an overview of what
archetypes exist and their typical attributes
and methods
• NOTE: The attributes and methods are only
suggestive of ‘possible’ things to consider
when looking at the respective archetypes –
NONE could be related to the domain you
model or only some could; but they serve as a
‘starting point’ for analysis/discussion
09/26/2009
© USC-CSSE 2005-2009
32
University of Southern California
Center for Systems and Software Engineering
The Relations between Archetypes
• Each of the previously shown archetypes are
‘related’ by specific associations/relations
• The original approach calls it the ‘Domain Neutral
Component (DNC)’ – i.e. it is NOT specific to any
domain
• The DNC is an ‘analysis strategy’ that is applied
to every ‘activity’ to help discover various domain
classes and their corresponding associations
• The DNC and it’s application follows on
subsequent slides
09/26/2009
© USC-CSSE 2005-2009
33
University of Southern California
Center for Systems and Software Engineering
<<party>>
Party
<<place>>
Place
1
0..1
1
0..1
<<role>>
Party Role
participates
<<role>>
Place Role
1
1
participates
0..*
<<activity>>
Previous Activity
0..*
<<activity>>
Activity
1
0..*
1
0..*
<<activity>>
Next Activity
0..*
participates (or produces)
1
<<role>>
Thing Role
09/26/2009
© USC-CSSE 2005-2009
0..1
1
<<thing>>
Thing
34
University of Southern California
Center for Systems and Software Engineering
More about the DNC
• NOTE: That during the ‘first-cut’ at domain modeling you
need not bother about the association multiplicities. You
can use them, if required, in later iterations of the model
• The associations shown serve as ‘reminders’ to the
analyst for considering these cases and ensuring that at
least those aspects of the domain have been captured
• The DNC is ‘overlayed’ on every activity in turn and
irrelevant classes are removed
• The DNC applies the strategy of identifying classes by
‘subtraction’ rather than ‘addition’ i.e. what typically
happens in brainstorming sessions.
09/26/2009
© USC-CSSE 2005-2009
35
University of Southern California
Center for Systems and Software Engineering
Applying the DNC
• In a previous slide we showed an example color model
for the ‘Registration’ activity for the Internet Bookstore.
• We now show ‘how’ did we arrive at such a model
• Question: But how does one ‘start’ the process of
identifying these activities? Isn’t that
brainstorming/discussion based?
• Answer: You have already done a preliminary
‘activities’ identification when you modeled the business
workflow!! That serves as a useful starting point for
domain modeling! (and hopefully it has been verified
with the relevant stakeholders too).
09/26/2009
© USC-CSSE 2005-2009
36
University of Southern California
Center for Systems and Software Engineering
Step 1: Identifying
an activity Registration
<<party>>
Party
<<place>>
Place
1
0..1
1
0..1
<<role>>
Party Role
participates
<<role>>
Place Role
1
1
participates
0..*
<<activity>>
Previous Activity
0..*
<<activity>>
Registration
1
0..*
1
0..*
<<activity>>
Next Activity
0..*
participates (or produces)
1
<<role>>
Thing Role
09/26/2009
© USC-CSSE 2005-2009
0..1
1
<<thing>>
Thing
37
University of Southern California
Center for Systems and Software Engineering
Step 2: Identifying
the relevant
entities in the
‘Party-Leg’
(elaborated later)
<<party>>
Person
1
0..1
1
0..1
<<role>>
Customer
participates
<<role>>
IBWebsiteRole
1
1
participates
0..*
<<activity>>
Previous Activity
0..*
<<activity>>
Registration
1
Step 3: Identifying
the relevant
entities in the
‘Place-Leg’
(elaborated later)
<<place>>
IBWebsite
0..*
1
0..*
<<activity>>
Next Activity
0..*
Step 4: Identifying
the relevant
entities in the
‘Thing-Leg’
(elaborated later)
09/26/2009
produces
1
<<role>>
AccountRole
© USC-CSSE 2005-2009
0..1
1
<<thing>>
Account
38
University of Southern California
Center for Systems and Software Engineering
<<party>>
Person
<<place>>
IBWebsite
1
0..1
1
0..1
<<role>>
Customer
participates
<<role>>
IBWebsiteRole
1
1
participates
0..*
Step 5: Identifying
the relevant
‘previous’ and
‘next’ activities
0..*
<<activity>>
Registration
1
0..*
produces
1
<<role>>
AccountRole
09/26/2009
0..*
<<activity>>
Search
© USC-CSSE 2005-2009
0..1
1
<<thing>>
Account
39
39
University of Southern California
Center for Systems and Software Engineering
<<party>>
Person
<<place>>
IBWebsite
1
0..1
1
0..1
<<role>>
Customer
participates
<<role>>
IBWebsiteRole
1
1
participates
0..*
Step 6: Removing
Irrelevant entities –
they don’t seem to
‘make much sense’. Of
course this needs to
be verified!!!
0..*
<<activity>>
Registration
1
0..*
produces
1
<<role>>
AccountRole
09/26/2009
0..*
<<activity>>
Search
© USC-CSSE 2005-2009
0..1
1
<<thing>>
Account
40
40
University of Southern California
Center for Systems and Software Engineering
<<party>>
Person
<<place>>
IBWebsite
1
1
1
<<role>>
Customer
participates
Step 7: Adjusting the
relations/multiplicities
due to removal of
entities and performing
further analysis on
those that remain.
1
participates
0..*
0..*
<<activity>>
Registration
1
0..*
produces
1
<<thing>>
Account
<<thing>>
Privileged Account
09/26/2009
1
<<activity>>
Search
<<thing>>
Ordinary Account
© USC-CSSE 2005-2009
41
41
University of Southern California
Center for Systems and Software Engineering
Notes about Domain Analysis
• We applied the DNC to one activity of ‘Registration’ and
ended up with the above model
• The need for the <Place> IBWebsite may be irrelevant but
could serve as a place holder for further analysis. However, if
NOTHING about the website ever needs to be maintained it
can be safely removed.
• The multiplicities have been left in place, you need NOT use
it for the initial iteration(s).
• The initial iteration need not even have attributes or methods
• The domain model strives to establish a ‘communication’
glossary to bridge the ‘two cultures’ – ensure that domain
vocabulary is used for classes and not technical names!!
09/26/2009
© USC-CSSE 2005-2009
42
University of Southern California
Center for Systems and Software Engineering
(Non-)Persistence of Classes
• It is very important to understand, as has been
indicated earlier, that:
– NOT ALL the <person>, <place>, and <thing> classes in the
DM will necessarily end up being in the implementation class
model (e.g. The IBWebsite class may not exist in the
implementation at all!)
– Similarly NOT ALL the <role> classes or <activity> classes in
the DM will end up being in the implementation class model
• The point is that constructing a DM helps overcome the
Two Cultures problem.
09/26/2009
© USC-CSSE 2005-2009
43
University of Southern California
Center for Systems and Software Engineering
Typical Attributes and Methods
<<Party>>
Person
name
address
SSN
listPersons
<<role>>
Customer
authorization
userId
isAuthorized
listParticipatingActivities
listCustomers
Using the ‘typical attributes and methods’ as a guide we came up with the
above attributes and methods that seem relevant for the corresponding
entities and which have relevance in the domain. More may be needed
and that is where brainstorming/discussions are required, to understand
more about the domain. There is NO need for arguments/parameters or
datatypes – this model is ALSO for NON-TECHNICAL people like the
clients!
09/26/2009
© USC-CSSE 2005-2009
44
University of Southern California
Center for Systems and Software Engineering
Is it really THAT simple?
• Well, not exactly!
• There are quite a few special cases to that
you need to consider – these are shown on
the following slides
• You need to ‘ask’ the relevant questions to be
able to identify (or discard) the relevant
entities in the domain model
09/26/2009
© USC-CSSE 2005-2009
45
University of Southern California
Center for Systems and Software Engineering
Sources for identifying ‘Roles’ and ‘Party,
Place, Things’
• Asking Who, What and Where about the Activity
classes helps identifies both the ‘Party, Place, Things’
as well as the ‘Roles’ they play when participating with
the activity
• ‘Actors’ in UML Use-Case Diagrams – they give a
good inkling as to who is doing what with the system
• Roles act as proxies for green (party, place and thing)
classes in specific transactions and are generally
named for the transaction, moment in time or period of
time for which they participate in the activity
09/26/2009
© USC-CSSE 2005-2009
46
University of Southern California
Center for Systems and Software Engineering
Modeling Roles - I
•For a given organization, a
‘Person’ can play many roles
(even more than one or
exactly one).
•The role determines the
levels of access,
authorizations or just ‘roles’ in
a transaction
09/26/2009
© USC-CSSE 2005-2009
47
47
University of Southern California
Center for Systems and Software Engineering
Modeling Numerous Roles - II
•The previous model is quite ‘tightly coupled’
•Rearranging it  ‘Person’ class only needs to be associated with
‘Person Role’ super class. This provides a ‘cleaner’ model
09/26/2009
© USC-CSSE 2005-2009
48
University of Southern California
Center for Systems and Software Engineering
‘Subsequent’ Roles
•This may be needed at times in some domains: Eg. to be a user of
certain systems within an organization, a person may have to be an
Employee of that organization
09/26/2009
© USC-CSSE 2005-2009
49
University of Southern California
Center for Systems and Software Engineering
Using a ‘Rules’ or ‘Policy’ Engine
•For large complex systems it may be advisable to refer an external
rules/policy engine for retrieving the authorizations/permissions for the
various ‘green’ classes.
•The organization may already be using one. The system would then need
to ‘connect’ to this external system and that too must be captured in the
domain model
09/26/2009
© USC-CSSE 2005-2009
50
University of Southern California
Center for Systems and Software Engineering
Complex Activity Relations
• In some cases the relationship may not be as straight forward
as a simple sequence of Previous, Current and Next Activities
<<activity>>
<<activity>>
<<activity>>
<<activity>>
09/26/2009
© USC-CSSE 2005-2009
51
University of Southern California
Center for Systems and Software Engineering
Internet Bookstore Domain Modeling
(cont.)
• Another activity, arising from the Internet
bookstore requirement “The bookstore should
provide a number of search methods on that
catalogue, including search by author, search by
title, search by ISBN number, and search by
keyword” is Search
• A first attempt at adding Search, along with
associated <thing> classes to the DM is
shown on the next slide.
09/26/2009
© USC-CSSE 2005-2009
52
University of Southern California
Center for Systems and Software Engineering
<party>
Person
performs
<role>
Customer
performs
<activity>
Registration
<activity>
Search
on
produces
<thing>
Account
<thing>
Privileged Account
09/26/2009
<thing>
Master Book Catalog
<thing>
Ordinary Account
© USC-CSSE 2005-2009
produces
<thing>
List of Matches
<thing>
Book Record
53
University of Southern California
Center for Systems and Software Engineering
Internet Bookstore Domain Modeling
(cont.)
• Note that in a later draft of the DM we might add <activity>
subclasses of Search, named “Search By Author,”
“Search By Title,” “Search by ISBN Number,” and “Search
By Keyword.”
• As an alternative to adding the four subclasses of Search,
we might, rather:
– Add the type of search, and relevant details, as attributes of
Search
– Or add <thing> classes, associated with the Search, to hold
the type of search and its details
09/26/2009
© USC-CSSE 2005-2009
54
University of Southern California
Center for Systems and Software Engineering
Internet Bookstore Domain Modeling
(cont.)
• The decision of which way to handle the four varieties of
search may, at a later point, closer to the implementation
stage, have serious consequences regarding
understandability, debug-ability, performance, etc., of the
code derived from the alternative chosen.
• Since the main purpose of domain modeling is to help the
developer gain an understanding of the problem domain,
however, the choice made at this point as to how to model
the four types of search is not likely to be of much
consequence.
09/26/2009
© USC-CSSE 2005-2009
55
University of Southern California
Center for Systems and Software Engineering
Internet Bookstore Domain Modeling
(cont.)
• In the next three slides, additional <activity>, and
related <thing> classes have been added to the initial
draft of the, still-incomplete, domain model of the
Internet bookstore.
• We apply the DNC for various activities and ‘merge’
the models – it is guaranteed to be a fully connected
graph i.e. it won’t happen that parallel analysis of
various activities would produce disjoint sub-domain
models.
09/26/2009
© USC-CSSE 2005-2009
56
University of Southern California
Center for Systems and Software Engineering
<party>
Person
performs
<role>
Customer
performs
<activity>
Registration
<activity>
Search
on
produces
<thing>
Account
<thing>
Privileged Account
09/26/2009
<thing>
Master Book Catalog
<thing>
Ordinary Account
© USC-CSSE 2005-2009
performs
<activity>
Insertion Into
Shopping Cart
produces
<thing>
List of Matches
<thing>
Book Record
57
University of Southern California
Center for Systems and Software Engineering
<activity>
Insertion Into
Shopping Cart
<activity>
Ordering
produces
requires
Customer
<activity>
Shipping
of
<activity>
Payment
<thing>
Order
<party>
Shipping
Department
submitted via
<party>
Internet
Bookstore
<party>
Payment
Organization/
Method
<party>
Paypal
09/26/2009
<party>
Credit Card
Issuer
© USC-CSSE 2005-2009
58
University of Southern California
Center for Systems and Software Engineering
Customer
Registration
<activity>
Review Book
produces
<thing>
Book Review
<thing>
Rating
09/26/2009
© USC-CSSE 2005-2009
<thing>
Comments
59
University of Southern California
Center for Systems and Software Engineering
Color Modeling – Fine Print
• You shouldn’t compose an archetype with
other archetypes i.e Don’t have a ‘Green’
class composed of ‘Yellow’ classes!! Such a
composition relation implies very strong
coupling! Do it only if you are really, really
sure of it!
• Classes ‘inherit’ the color of their base class
09/26/2009
© USC-CSSE 2005-2009
60
University of Southern California
Center for Systems and Software Engineering
References
• [Paul2002] Domain Modeling by Paul Oldfield, Mentors of Cally
Ltd, http://www.aptprocess.com
• [Coad99] Java Modeling In Color With UML by Peter Coad,
Eric Lefebvre and Jeff De Luca
• [Palmer] http://knol.google.com/k/stephen-palmer/objectmodelling-in-colour/3e0t9wv30hso7/2#
• [Anderson] http://conferences.codegear.com/article/32095
09/26/2009
© USC-CSSE 2005-2009
61
University of Southern California
Center for Systems and Software Engineering
Note(s)
• Domain modeling will help with a good deal of
understanding of the use-cases, business
workflows and sequence diagrams. It will also
be helpful in designing an overall architecture
and ensuring the actual system is as close to
the domain as possible.
09/26/2009
© USC-CSSE 2005-2009
62