Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Scribd
Upload
24 views

Module-2 Part-1

The document discusses key aspects of the elaboration phase in object-oriented system design. It describes steps to take during this phase such as completing the project plan, defining use cases and the domain model, and beginning design of high priority use cases. It also discusses prototyping to mitigate risks and deliverables such as the use case model and domain model, which is a visual representation of conceptual classes and their relationships in the problem domain. The domain model is developed using class diagrams and identifies conceptual classes, attributes, associations and other relationships between classes.

Uploaded by

Pragya
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
24 views

Module-2 Part-1

The document discusses key aspects of the elaboration phase in object-oriented system design. It describes steps to take during this phase such as completing the project plan, defining use cases and the domain model, and beginning design of high priority use cases. It also discusses prototyping to mitigate risks and deliverables such as the use case model and domain model, which is a visual representation of conceptual classes and their relationships in the problem domain. The domain model is developed using class diagrams and identifies conceptual classes, attributes, associations and other relationships between classes.

Uploaded by

Pragya
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 25

Module-2

Part -1

Object Oriented System Design


Objectives

The purpose of this module is :

• To understand the key aspects of Elaboration phase.

• To acquaint with the concepts of Domain modelling.

• To understand different types of associations used in class model

• To understand the role of Aggregation and composition


 Elaboration Phase
The primary purpose of this phase is to complete the most essential parts of the
project that are high risk and plan the construction phase. During this phase
personnel requirements should be more accurately determined along with estimated
man hours to complete the project. The complete cost and time frame of the project is
more firmly determined. During this phase how the system will work must be
considered. Use cases will help identify risks.

Steps to take during this phase:

1. Complete project plan with construction iterations planned with requirements for
each iteration.
2. 80% of use cases are completed. Significant use cases are described in detail.
3. The project domain model is defined.
4. Rank use cases by priority and risk. Do the highest priority and highest risk use
cases first.
5. Begin design and development of the riskiest and highest priority use cases. There
will be an iteration for each high risk and priority use case.
6. Plan the iterations for the construction phase.
 Prototyping

A key activity in the Elaboration Phase is the mitigation of risks. The


sooner risks are identified and shot down, the lesser their impact will
be on the project.

Prototyping difficult or problematic areas of the project are a


tremendous help in the mitigation of risks. Given that we don’t want
to get bogged down in implementation
and design at this phase, the prototypes should be very focussed, and
explore just the area of concern.

Prototypes can be thrown away at the end of the exercise, or they can
be reused during
the construction phase.
 Deliverables
Apart from prototypes, we are going to develop two UML models
to help us towards our goal of understanding the problem as a
whole.

The first model is the Use Case Model. This will help us to
understand what the system needs to do, and what it should look
like to the "outside world" (ie the users, or perhaps the systems it
must interface to).

The second model is the Domain (Conceptual)Model. This model


allows us to capture, using UML, a graphical statement of the
customer’s problem. It will describe all of the major "concepts" in
the customer’s problem, and how they are related.
To build this, we’ll use the UML Class Diagram. We will use this
Conceptual Model in the Construction Phase to build our software
classes and objects
DOMAIN MODEL RELATIONSHIPS

Business Model
Domain Model

Classes, attributes, Elaboration on some terms


associations

Domain Glossary
Use Case Model objects

Requirements

Interaction Diagrams

Design
WHAT IS A DOMAIN MODEL ?
A domain model:

 Illustrates meaningful conceptual classes in a problem


domain.
 Is a representation of real-world concepts, not software
components.
 Is NOT a set of diagrams describing software classes, or
software objects and their responsibilities.
A DOMAIN MODEL IS THE MOST IMPORTANT OO
ARTIFACT

 Its development entails identifying a rich set of


conceptual classes, and is at the heart of object
oriented analysis.
 It is a visual representation of the decomposition of a
domain into individual conceptual classes or objects.
 It is a visual dictionary of noteworthy abstractions.
 Domain classes
Attributes
 Associations
 Multiplicity
 Aggregation
 Composition
 Generalization
 Roles
DOMAIN MODEL UML NOTATION
 Illustrated using a set of class diagrams for which no
operations are defined.
It may contain:
 Domain Objects or Conceptual Classes

 Associations between conceptual classes

 Attributes of conceptual classes


ARTIFACT

A Conceptual class: Software


Sale Artifacts:
SalesDatabase

Date
vs Sale
.
Tim Date
e Time
Print()
THINK OF CONCEPTUAL CLASSES IN TERMS OF:
 Symbols – words or images
 Intensions – its definition

 Extensions – the set of examples to which it applies

 Symbols and Intensions are the practical


considerations when creating a domain model.
DECOMPOSITION:
 A central distinction between Object-oriented analysis and
structured analysis is the division by objects rather than by
functions during decomposition.
 During each iteration, only objects in current scenarios are
considered for addition to the domain model.
CONCEPTUAL CLASS IDENTIFICATION:

 It is better to over-specify a domain with lots of fine-


grained conceptual classes than it is to under-specify it.
 Discover classes up front rather than later.

 Unlike data modeling, it is valid to include concepts for which


there are no attributes, or which have a purely behavioral role
rather than an informational role.
IDENTIFY CONCEPTUAL CLASSES BY CATEGORY
LIST:

Common Candidates for classes include:


Tangible objects, Descriptions, Roles,
Places, Transactions, Containers, Systems,
Abstract nouns, Rules, Organizations,
Events, Processes, Written Materials,
Catalogs, Records, Financial Instruments
and Services
IDENTIFY CONCEPTUAL CLASSES BY NOUN
PHRASE:

 Identify Nouns and Noun Phrases in textual


descriptions of the domain.
 Fully dressed Use Cases are good for this type of
linguistic analysis.
It’s not strictly a mechanical process:
 Words may be ambiguous

 Different phrases may represent the same concepts.


SALES DOMAIN EXAMPLE –
‘PURCHASE ITEMS’ USE CASE

 We find concepts such as Register, Sale, Item,


Customer, Receipt etc. in this use case.

Should we include Receipt in the Model?


 Con: As a report of a sale, it’s duplicate info.

 Pro: Business Rules for a Return require that the


customer has a receipt.
 Suggestion: Include it in the iteration where the
Return Use Case is covered.
STEPS TO CREATE A DOMAIN MODEL

 Identify Candidate Conceptual classes


 Draw them in a Domain Model

 Add associations necessary to record the relationships that


must be retained
 Add attributes necessary for information to be
preserved
 Apply existing Analysis Patterns
APPLY THE MAPMAKER STRATEGY

 Use existing names for things, the vocabulary of the


domain
 Exclude irrelevant features

 Do not add things that are not there


A COMMON MISTAKE - CLASSES AS ATTRIBUTES

 Rule: If we do not think of a thing as a number or text in the


real world, then it is probably a conceptual class.
 If it takes up space, then it is likely a conceptual class.

Examples:
 A Store is not an attribute of a Sale

 A Destination is not an attribute of a flight


SPECIFICATION OR DESCRIPTION
CONCEPTUAL CLASSES

 A Class that records information about an item.


 Even if all Instances of the item are sold out, the
description remains.
 Avoids duplication of recording the descriptive
information with each instance of the item.
DESCRIPTION OF A SERVICE EXAMPLE (FLIGHT)

Flight
Flies-to Airport
Date Name
Time vs.
Number

Flight FlightDesc Airport


Described Describe
Date -by
Date s Name
-flights-
to

Tim Tim
e e
MONOPOLY CONCEPTS (CANDIDATES)

Monopoly Playe Piec


Game r e

Die Boar Squar


d e
References

 Craig Larman,"Applying UML and Patterns: An Introduction


to object-oriented Analysis and Design and iterative
development”, Third Edition, Pearson Education, 2005
 James Rambaugh, Ivar Jacubson, Grady Booch “Unified
modeling language reference manual”, Addison Wiley, 1995
• UML Relationships with EXAMPLE: Dependency,
Generalization, Realization (guru99.com)
• UML Association vs Aggregation vs Composition with
EXAMPLE (guru99.com)
T HE END

You might also like