0% found this document useful (0 votes)
253 views

RUP - Domain Model

In software engineering, a domain model is a conceptual model of the domain that incorporates both behaviour and data. In ontology engineering,

Uploaded by

Muhammad Usman
Copyright
© © All Rights Reserved
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
253 views

RUP - Domain Model

In software engineering, a domain model is a conceptual model of the domain that incorporates both behaviour and data. In ontology engineering,

Uploaded by

Muhammad Usman
Copyright
© © All Rights Reserved
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 32

Object Oriented Analysis and Design

Topic
Elaboration phase of RUP
Domain Model

Compiled by Urooj
Lecturer at CS & IT Dept, UOS
Elaboration phase of RUP
 An analysis is done to determine the risks,
stability of vision of what the product is to
become, stability of architecture and
expenditure of resources.
Elaboration - Entry criteria

 The products and artifacts described in the exit


criteria of the previous phase.
 The plan approved by the project management, and
funding authority, and the resources required for the
elaboration phase have been allocated.
Elaboration - Activities
 Get a more detailed understanding of the
requirements.
 Project plan is defined. The process,

infrastructure and development environment are


described.
– You want to gain an in-depth understanding of
the most critical requirements to validate that
the architecture has covered all the bases.
Elaboration - Activities
 Design, implement, validate, and baseline the
architecture
• to the extent that you can (and should)
conduct some initial load and performance
tests on the architecture.You make critical
design decisions, including the selection of
technologies, main components, and their
interfaces
Elaboration - Activities
 Mitigate essential risks, and produce more
accurate schedule and cost estimates. .
 Many technical risks will be addressed as a result

of detailing the Requirements and designing,


implementing, and testing the architecture
Elaboration - Activities
 Refine the development case and put the
development environment in place.
You refine the process you defined for Inception
to reflect lessons learned. You also continue
to implement the software development tools
you need for our project
Elaboration - Exit criteria
 A detailed software development plan, with an updated
risk assessment, a management plan, a staffing plan, a
phase plan showing the number and contents of the
iteration , an iteration plan, and a test plan
 The development environment and other tools
 A baseline vision, in the form of a set of evaluation
criteria for the final product
 A domain analysis model, sufficient to be able to call the
corresponding architecture ‘complete’.
 An executable architecture baseline.
Domain Model

Elaboration Iteration Phase


What is a domain model?

A domain model is visual representation of conceptual


classes of real situation objects in a domain.
 It is also called conceptual model
 A domain model captures the most important types of
objects in the context of the business. The domain model
represents the ‘things’ that exist or events that transpire
in the business environment.” – I. Jacobsen
 To understand the problem: the system’s requirements as
they exist within the context of the problem domain
Why do a domain model?

 Gives a conceptual framework of the things in the


problem space
 Helps you think – focus on semantics
 Provides a glossary of terms – noun based
 It is a static view
 Foundation for use case/workflow modelling
 Identify the rich set of conceptual classes in the
heart of OO Analysis
Example
Features of a domain model

o Domain classes – each domain class denotes a type of


object.
o Attributes – an attribute is the description of a named slot
of a specified type in a domain class; each instance of the
class separately holds a value.
o Associations – an association is a relationship between
two (or more) domain classes that describes links between
their object instances. Associations can have roles, describing
the multiplicity and participation of a class in the
relationship.
Domain classes?
 Each domain class denotes a type of object. It is a
descriptor for a set of things that share common
features. Classes can be:-
o Business objects - represent things that are
manipulated in the business e.g. Order.
Domain classes?

o Real world objects – things that the business keeps


track of e.g. Contact, Site.
o Events that transpire - e.g. sale and payment.

 A domain class has attributes and associations with


other classes.
Multiplicity
How do I make a domain model?

Perform the following in very short iterations:


o Make a list of candidate domain classes.
o Draw these classes in a UML class diagram.
o It is illustrated with the set of class diagram in which no
operation is defined
o Identify any associations that are necessary.
o Decide if some domain classes are really just attributes.
o Where helpful, identify role names and multiplicity for
associations.
Concentrate more on just identifying domain classes in
early iterations !
Identifying domain classes?

 An obvious way to identify domain classes is to


identify nouns and phrases in textual descriptions of a
domain.
 Consider a use case description as follows:-
1. Customer arrives at a checkout with goods and/or
services to purchase.
2. Cashier starts a new sale.
3. Cashier enters item identifier.
4. System records the sale line item and presents the
item description, price and running total.
What’s the Difference?
POS Domain Model
Identifying attributes ?

 A domain class sounds like an attribute if: -


o It relies on an associated class for it’s identity – e.g.
‘order number’ class associated to an ‘order’ class.
The ‘order number’ sounds suspiciously like an
attribute of ‘order’.
o It is a simple data type – e.g. ‘order number’ is a
simple integer. Now it really sounds like an
attribute!
References
 Applying UML and Patterns 3rd Edition
 Chapter No. 9
How requirements organized in UP
artifacts?
 UP offers several requirement artifacts:
1. Use Case Model
 Set of Scenarios of using a system(functional requirements)
2. Suplementry Specification
 For all non functional requirements
 Such as performance or licensing
3. Glossary
 Define noteworthy terms
 Concept of Dictionary
 Record requirments relted to data
 i.e. validation rules, acceptance values, parameter of operation
call etc.
 Vision
 Summerise high level requirements elaborated in use case
model and supplementary specification and summerise the
business case
 Quickly learning the project big idea
 Business Rules(domain rules)
 Requirments or policies in the domain or business and many
application may need to conform them
 i.e. govt. laws
 (Share by all analyst of the company)
Example:
 Process Sale
 A customer arrives at checkout with items to purchase .
 The Cashier uses the POS system to record each purchase
item .The system presents a running total and line-item
details.The Customer enter payment information, which the
system validates and records.The system update inventory
.The Customer receives a receipt from the system then leaves
with the items.
Use Case Diagram

Process
Sale
Enter
payment
info
Cashier Customer
Place
Order
Domain Model

Sale Sale Line item Order


1 1…*

Contains

Cashier Customer

You might also like