UNIT II
Elaboration - Domain Models - Finding conceptual classes and description classes–
Associations – Attributes – Domain model refinement – Finding conceptual class
Hierarchies- Aggregation and Composition- UML activity diagrams and modeling
2.1) ELABORATION
Elaboration phase is dependent on better to design, implement, and test a critical
conditions to identify what type of architectural mechanisms needed
Elaborations phases are analyze the problem domain, establish an architectural
foundation, develop the project plan and eliminate the highest risk elements of the
project.
At the end of the elaboration phase, the detailed system objectives, scope, choice of
architecture, and the resolution of major risks are examined
Elaboration normally consists of two or three iterations, during these iterations will
analyse the following sources
1. Does serious investigations
2. implements programs and tests for core architecture
3. clarifies requirements tackles high risk issues
1) SOME BASIC OBJECTIVES OF THE ELABORATION
Build the core architecture;
resolve the high-risk elements,
define most requirements, and
estimate the overall schedule and resources
2) Elaboration must pass the Lifecycle Architecture by meeting the following criteria:
A use-case model in which the use-cases and the actors have been identified and
most of the use-case descriptions are developed. The use-case model should be 80%
complete.
A description of the software architecture in a software system development
process.
An executable architecture that realizes architecturally significant use cases.
Business case and risk list which are revised.
A development plan for the overall project.
Prototypes that demonstratively mitigate each identified technical risk .
GOALS OF ELABORATION
Get a more detailed understanding of the requirements
Having a good understanding of the majority of requirements enables you to
create a more detailed plan and to get buy-in from stakeholders. Be sure to gain an in-depth
understanding of the most critical requirements to be validated by the architecture.
Design, implement, validate, and establish the baseline for the architecture
Design, implement, and test a skeleton structure of the system. the functionality is
not complete yet, most of the interfaces between the building blocks are implemented
and tested. This is referred to an executable architecture
moderate essential risks, and produce accurate schedule and cost estimates
Many technical risks are addressed as a result of detailing the requirements and of
designing, implementing, and testing the architecture. Refine and detail the high-level
project plan.
ARTIFACTS IN ELABORATION
Some refined over a series of iterations in elaboration are
1) Domain Model
1) Visualization of domain concepts
2) It is similar to static information model
2) Design Model
It is a set of diagrams that describe logical design. It includes
1) class diagrams
2) Object interaction diagrams
3) Package diagrams
3) Software architecture documents
i) A summary of design ideas
ii) Summarizes key architecture issues and their resolution in design
4) Data Model
It includes data base schemas, mapping strategies
5) Use case story Boards
1) Description of user interface
2) Path of navigation
3) Usability model
Some key ideas in elaboration:
• Do short time-boxed risk-driven iterations
• Start programming early
• Adaptively design, implement, and test the core and risky parts of the
architecture
• Test early, often, realistically
• Adapt based on feedback from tests, users, developers
• Write most of the use cases and other requirements in detail
2.2) DOMAIN MODELS
It represents indentifiable object in problem
A domain model is a representation of real-world conceptual classes
A domain model is a visual represents of conceptual classes or real situation. It is not
a representation of software components or objects.
It is not a set diagrams describing software classes
The domain model is a static model. Time flow, with sequence of events or
information flow is not shown in the domain model
Using UML notation a domain model is described with a set of class diagrams in
which no operation are defined. It may show
i) domain object or conceptual classes
ii) associations between conceptual classes
iii) attributes of conceptual classes
Domain models are not models of software classws such as java or c++ classes, so
that domain may be provide
1) software artifacts like window or database
2) methods and responsibility
3) not a data model do include concepts that have no attributes or
play a behavioral role
The domain model provides a structural view of the domain that can be
complemented by other dynamic views, such as Use Case models
The domain model can be effectively used to verify and validate the understanding of
the problem domain.
Difference between DOMAIN MODEL and DESIGN MODEL
Domain model shows only a structural view but the design model show entire
funtionalities of the domain.
EXAMPLE FOR DOMAIN MODEL
CONCEPTUAL CLASSES OR DOMAIN CONCEPT
Conceptual class is an idea or object
A conceptual class may be considered in terms of
i) Symbol Words or images representing a conceptual classes
ii) Intension The definition of a conceptual class
iii) Extension the set of examples to which the conceptual class
Example
1) Symbol sale (English Word)
2) Intension represents events of purchase transaction, having date and time
3) Extension set of all instances in the universe.
CREATION OF DOMAIN MODEL
1) To understand the key concept and vocabulary
2) Lower gap between the software representation and logical model of the domain
Steps for creating a domain model are
I. Find the conceptual classes
II. Draw them as classes in UML class diagram
III. Add association and attributes
2.3) FINDING CONCEPTUAL CLASSES AND DESCRIPTION CLASSES
1) FINDING CONCEPTUAL CLASSES
Only cover what is being considered in the current iteration
The three strategies to find conceptual classes are
1) Reuse or modify exiting models
2) Use category list
3) Identify noun phrase
REUSE OR MODIFY EXITING MODELS
It is the easiest approach
There are published and well crafted domain models and data models(which can be
modified into domain model) like
Inventory
Finance
Health
USE CATEGORY LIST
Some of the common categories found in
1) Physical or tangible objects example register, Airplane
2) Specification or description of things Example product specification, Flight
description
3)
Conceptual Class Category Examples
business transactions Sale, Payment
Guideline: These are critical (they involve money), Reservation
so start with transactions.
transaction line items SalesLineItem
Guideline: Transactions often come with related
line items, so consider these next.
product or service related to a transaction or Item
transaction line item Flight, Seat, Meal
Guideline: Transactions are for something (a
product or service). Consider these next.
where is the transaction recorded? Register, Ledger
Guideline: Important. FlightManifest
IDENTIFY NOUN PHRASE
Identify Nouns and Noun Phrases in textual descriptions of the domain
Use Cases are good for this type of linguistic analysis to identify Concepts and
Attributes.
it’s not strictly a mechanical process:
Words may be ambiguous
Different phrases may represent the
OBJECTIVES
1) Use cases
2) Domain experts
3) Other documents
EXAMPLE
Customer arrives at a checkout with items to purchase
Noun Phrases are
1. Customer
2. Checkout
3. Items
FINDING DESCRIPTION CLASSES
A description class is a class that contains information that describes something
Example
Product Description is a description class that records the
Picture
Price and
Text description
2.4) ASSOCIATION
Association is a relation b/w concepts that indicates some meaningful and interesting
connection
Definition
An association is defined as semantic relationship between two or more classifiers
that involve connection among their instances.
An association represents a structural relationship that connects two classifiers. Like
attributes, associations
Association defines the relationship between two or more classes in the System.
Associations are modeled as lines connecting use cases and actors to one another,
with an optional arrowhead on one end of the line.
NOTATION
1) Association is a solid line connecting two class symbols
2) The ends of association contains multiplicity expression
3) Legal formats of compound association name
Work-for
Work for
4) Each end of association is called role. Roles may optionally have
Multiplicity expression
Name
Navigability
1) MULTIPLICITY
Describes how many instances of one concept can be associated with one instance of the
related concept.
* = Zero or more
0..3 = Zero to three
2,4,6 = Two, four, or six
10 = Exactly 10
1..* = One or more
0..* = Zero or more
2) NAMING THE ASSOCIATION
Name an association based on a TypeName-VerbPhrase- Type Name format.
Association names should start with a capital letter.
Name an association based on a verb phrase creates a sequence that is readable
and meaningful
The default direction to read an association name is left to right, or top to bottom.
3) NAVIGABILITY
Association navigation represents the direction in which a relationship can be
traversed. It can be either unidirectional, i.e., in one direction, or bi-directional, i.e.,
in both directions
An optional reading direction arrow indicates direction to read association name.
Association navigation represents the direction in which a relationship can be traversed. It can
be either unidirectional, i.e., in one direction, or bi-directional, i.e., in both directions
Here it means association from person to BankAccount
Person has BankAccount and not the reverse
MULTIPLE ASSOCIATIONS BETWEEN TWO CLASSES
It is common to have multiple associations between two types.
In the example, not every flight is guaranteed to land at an airport.
2.5 ATTRIBUTES
An attribute is a logical data value of an object. An attribute is property of a class
Attributes: those for which the requirements suggest or imply a need to remember
information.
Attributes are shown in the second compartment of the class box.
The type of an attribute may optionally be shown.
It includes things which are not associations (but valid attributes)
Notation of an Attribute
An attribute's signature is the line that represents it in a class or interface on a UML class
diagram. It has this form:
Visibility name: Type Name [*]= default{ property-String}
+ denotes public Visibility. The other permitted values are - (private), # (protected), ~
(package).
Attribute Name is underlined if the attribute is static.
Type Name is omitted if the attribute has no type.
[*] denotes the multiplicity. It is omitted if the multiplicity is 1.
Attribute Types
Instance attributes
– Each object of the class has its own attribute
– Changing the value of the attribute affects only the containing object
Class attributes
– Only one instance of the attributes for all objects of the class
– Changing the value of the attribute affects all objects of the class
– Underline the attribute
Properties
The following table describes the properties of an attribute in a class or interface on a UML class
diagram
Property Default Description
Default Value (empty The value of the attribute when the classifier is instantiated.
)
Is Read Only False If true, the value of the attribute cannot be changed.
Is Static False If true, a single value for this attribute is shared between all instances of this
type.
If true, the name of the attribute is underlined where it appears on the diagram.
Is Leaf False If true, it is not intended to allow redefinition of this attribute in derived types.
Description (empty For general notes, or for defining constraints on the values in the attribute.
)
Multiplicity 1 1 - this attribute has a single value of the specified Type.
0..1 - this attribute can have a value of null.
* - this attribute's value is a collection of values.
1..* - this attribute's value is a collection that contains at least one value.
n.. m - this attribute's value is a collection that contains between n and m
values.
Is Ordered False If true, the collection forms a sequential list. For Multiplicity of more than 1.
Is Unique False If true, there are no duplicate values in the collection. For Multiplicity of
more than 1.
DERIVED ATTRIBUTES
If an attribute is derived from some other information then it is called derived attributes
Example
Quantity calculated from actual multiplicity value of the association
DATA TYPE ATTRIBUTE
Simple attributes or pure data values.
o Types include: Boolean, Data, Number, String(Text), Time
Other common types include:
o Address, Color, Geometric (point, rectangle,…), Phone number, Social
Security Number, Universal Product Code(UPC), ZIP or postal codes
enumerated types.
2.6 DOMAIN MODEL REFINEMENT
It is useful or valuable to identify conceptual super class and sub class
Identify superclasses and subclasses when the concepts in more general, abstracts
terms and reduce repeated information
Expand class hierarchy relevant to the current iteration and show them in the
domain model
The fundamental concepts of the domain model refinement are
i) Generalization
ii) Specialization
iii) Conceptual class hierarchies
FINDING CONCEPTUAL CLASS HIERARCHIES
GENERALIZATION
Generalization is the activity to identify conceptual super class and subclass
A conceptual super class is more general or encompassing than the subclass
Here cash payment is transferring money from one party to another
Credit payment is transfer of money also one among them
GENERALIZATION AND CLASS SETS
All Members of a conceptual subclass set are members of their superclass set
Example
In terms of set membership, all instances of set “CreditPayment” are also
members of set “payment”
Payment
Cash Check
Credit
payment Payment
Payment
Conceptual subclass Definition conformance
During creation of class hierarchy, statements about superclass that apply to
subclass are made
There are two constraints to define a conceptual subclass
1) 100% Rule Subclass must conform to 100% of superclass attributes and
association
2) Is-a Rule(informal Test) The subclass Is a kind of or Relationship of the
superclass (or) all the members of a subclass set must be members of their
superclass set
Example: All “payments” have an attribute “amount” which are associated with sale
A conceptual subclass may defined as
1) Subclass has additional attributes and association
2) Subclass behaves (or) is operated on (or) handled differently than super class or
other subclasses
CONCEPTUAL SUPERCLASS DEFINITION
When Common property is identified among subclasses, generalization concept is done
in the conceptual super class
1) Conceptual subclass represent similar concept
2) Subclass conform to 100% rules
3) All subclass have same attributes and association
Here Credit Card and Cheque services have common attributes and hence shown as class
hierarchy
UML ACTIVITY DIAGRAM
Activity diagrams are graphical representations of workflows of stepwise activities
and actions that are conditional or parallel
Activity diagrams are the object-oriented equivalent of flow charts and data-flow
diagrams from structured development
Activity diagrams describe the workflow behavior of a system
Activity diagram illustrates the dynamic nature of a system
Activity diagrams are similar to state diagrams because activities are the state of
doing something
NOTATIONS
Activity diagrams are constructed from a limited repertoire of shapes, connected with
arrows. The most important shape types:
rounded rectangles represent activities;
diamonds represent decisions;
bars represent the start (split) or end (join) of concurrent activities;
a black circle represents the start (initial state) of the workflow;
An encircled black circle represents the end (final state).
Arrows run from the start towards the end and represent the order in which
activities happen
USES OF ACTIVITY DIAGRAMS
To explore the logic of
Modeling work flow by using activities.
Modeling business requirements.
High level understanding of the system's functionalities.
Investigate business requirements at a later stage.
PURPOSES
Purposes can be described as:
Draw the activity flow of a system.
Describe the sequence from one activity to another.
Describe the parallel, branched and concurrent flow of the system
STEPS TO DRAW UML ACTIVITY DIAGRAMS
1. Identify the scope of the activity diagram--
2. Add start and end points
3. Add activities
4. Add transitions from the activities
5. Add decision points
6. Identify opportunities for parallel activities
EXAMPLE _: CREATING DOCUMENT
1. Open the word processing package
2. Create a file
3. Save the file under a unique name within its directory_
4. Type the document
5. If graphics are necessary, open the graphics package, create the graphics, and paste
the graphics into the document
6. If a spreadsheet is necessary, open the spreadsheet package, create the spreadsheet,
and paste the spreadsheet into the document
7. Save the file
8. Print a hard copy of the document
9. Exit the word processing package
EXAMPLE-2 PROCESSING ON ORDER
COMPOSITION AND AGGREGATION