static UML Diagrams

1. KONGUNADU COLLEGE OF
ENGINEERING AND TECHNOLOGY
(AUTONOMOUS)

2. UNIT II STATIC UML
DIAGRAMS
CLASS DIAGRAM - ELABORATION - PLANNING THE NEXT
ITERATION. DOMAIN MODEL - FINDING CONCEPTUAL AND
DESCRIPTION CLASSES - ASSOCIATIONS - ATTRIBUTES -
DOMAIN MODEL REFINEMENT - FINDING CONCEPTUAL CLASS
HIERARCHIES - AGGREGATION AND COMPOSITION. SYSTEM
SEQUENCE DIAGRAMS - RELATIONSHIP BETWEEN SSDS AND
USE CASES - SYSTEM EVENTS AND OPERATIONS.

3. Class Diagrams
 Class diagrams represents the static view of an application
 Class diagram is not only used for visualizing, describing,
and documenting different aspects of a system
 It is also for constructing executable code of the software
application

4. How to draw a class diagram
 The name of the class diagram should be meaningful to
describe the aspect of the system.
 Class should be clearly identified
 Each class, minimum number of properties should be
specified
 At the end of the drawing it should be understandable to
the developer

5. Perspectives
 Conceptual
 Specification
 Implementation

6. Conceptual
 We take the concepts in the domain under study and
represent in diagrams
 These concepts will relate to the classes that implement
them
 A conceptual model should be drawn with little
implementation. Also it is considered language independent.

7. Specification
 Here we look at the interface of the software but not its
implementation.
 A type can have many classes that implement it and a
classes that implement it an a class implement many types.

8. Implementation
 Here we have classes and we later to
implement.
 This is the most often used perspective but in
many cases the specification perspective is
better than implementation.

10. Elaboration
Build the core architecture,
Resolve the high-risk elements,
Define most requirements,
Estimate the overall schedule and
resources.

11. Elaboration
Elaboration is the initial series of iterations during
which, on a normal project.
1.The core, risky software architecture is programmed
and tested
2.The majority of requirements are discovered and
stabilized
3.The major risks are mitigated

12. Elaboration often consists of two or more iterations;
– Each iteration is recommended to be 2-6 weeks
Elaboration is not a design phase the models are fully
developed in preparation for implementation
The code and design are production quality
(a production subset of the final system).

14. Start programming early
Adaptively design, implement, and test the core and
risky parts of the architecture
Realistic tests early
Adapt according to the feedback of users
Key Ideas of Elaboration

15. Domain model
 The most important and classic model in OO analysis.
 A visual representation of conceptual classes or real situation
objects in a domain.
 Domain modeling is a technique used to understand the project
problem description and to translate the requirements of that
project into software components of a solution. The software
components are commonly implemented in an object oriented
programming language

16. Contd…
 The domain model illustrates conceptual classes or vocabulary in
the domain. Informally: a conceptual class is an idea, thing, or
object.
Formally: a conceptual class may be considered in terms of its
symbol, intension, and extension.
 Symbol- words or images representing a conceptual class
 Intension- the definition of a conceptual class
 Extension - the set of examples to which the conceptual class
applies

19. Domain model should probably avoid :
 Software artifacts like window or database
 Methods and responsibilities

20.  A domain model is illustrated with a set of class diagrams(in which
no operations are defined)
It may show:
 Domain objects or conceptual classes
 Associations between conceptual classes
 Attributes of conceptual classes

22.  Find the conceptual classes
 Draw them as classes in UML class diagrams
 Add association and attributes
Creation of domain model

23.  The three strategies to find conceptual classes
1)Reuse or modify existing models
 Inventory
 Finance
 Health
2) Use a category list (business category) – Eg. POS
3) Identity noun phrases - Textual description of a domain
FINDING CONCEPTUAL CLASSES

24. Use a category list (business
category)

25. Example:
Process Sale
Main success scenario (or Basic Flow)
1) Customer arrives at a POS checkout with goods
2) Cashier starts a new sale
3) Cashier enters item identifier
4) System records SaleLineItem
Presents item description, price and running total
Price calculated from a set price rules.
5) System presents total with taxes and asks for payment
6) Cashier tells customer the total and asks for payment
7) Customer pays and system handles payment
FINDING CONCEPTUAL CLASSES

26.  A description class is a class that contains information that
describes something
Example:
Product Description is a description class that records
 Picture
 Price
 Text description
Finding Description Classes

28.  Find the conceptual classes
 Draw them as classes in UML class diagrams
 Add association and attributes
Creation of domain model

29.  An association is defined as “Semantic relationship between two
or more classifiers that involve connections among their
instances”.
 It is a relationship between two objects
Association

30. Relationships: 3 Kinds
Window
open()
close()
ConsoleWindow DialogBox Control
Event
association
dependency
generalization

31. 31
 Associations may include have the following:
 Association name
 Role names
 Multiplicity
 Navigability
Association name navigability
multiplicity
role name navigability
multiplicity
* *

32. UML has a notation for multiplicity:
 1 one and only one
 0 .. 1 zero or one
 M .. N from M to N
 * zero or more
 1..* one or more

33. Associations
Professor Course
teaches
relationship name
direction indicator:
how to read relation name
teacher class
role names
Multiplicity
defines the number of objects
associated with an instance of the
association.
Default of 1;
Zero or more (*);
n..m; range from n to m
inclusive
1..*
*
 Represent conceptual relationships between classes

34. At this level of class design this is know as an association and these
come in three types
− A one to one association where one object of a class has a link to
one other object of a class
− A one to many association, where one object of a class has links
with many objects of a particular class
− A many to many association, where many objects of one class
have links with many objects of a particular class.
Associations more frequently occur between objects of different
classes, but also occur between different objects of the same class

35. Association Relationships
If two classes in a model need to communicate with
each other, there must be link between them.
An association denotes that link.
Instructor
Student

36. Association Relationships (Cont’d)
We can indicate the multiplicity of an association by
adding multiplicity adornments to the line denoting the
association.
The example indicates that a Student has one or more
Instructors:
Instructor
Student
1..*

37. Association Relationships (Cont’d)
The example indicates that every Instructor has one or
more Students:
Instructor
Student
1..*

38. Association Relationships (Cont’d)
We can also indicate the behavior of an object in an
association (i.e., the role of an object) using rolenames.
Instructor
Student
1..*
1..*
learns from teaches

39. Examples: one-to-one
Class_A Class_B
1 1
Class_A Class_B
1 *
one-to-many

40. many-to-many
Class_A Class_B
* *

41. Class
Attribute
Object
Attribute Value
What is an Attribute?
CourseOffering
number
startTime
endTime
:CourseOffering
number = 101
startTime = 900
endTime = 1100
:CourseOffering
number = 104
startTime = 1300
endTime = 1500

42. The different types of attributes
Single valued attributes
Multi valued attributes
Compound /Composite attributes
Simple / Atomic attributes
Stored attributes
Derived attributes
Complex attributes
Key attributes
Non key attributes
Required attributes
Optional/ null value attributes

43. Difference between Attribute and
Association
 From conceptual perspective, there is no difference between
attribute and association.
 Example: dateReceived [0….1]: Date
 The difference occurs at the specification and implementation
levels.

44. Class
Operation
What is an Operation?
CourseOffering
addStudent
deleteStudent
getStartTime
getEndTime
• The processes carried out but a class are called operations.

46. Student
+ name: string [1] = “Ram” {readOnly}
+ registeredIn: Course [*]
+ register (c: Course)
+ isRegistered (c: Course) : Boolean
Name of the class
Visibility:
+, -, #
Attribute
name
Operation
name
Parameters
Return value
Attribute
type
Multiplicity
Default value
Other Properties

47. Derived attributes
 Attributes is derived from some other information
 A derived attribute is an attribute whose value is calculated
(derived) from other attributes. The derived attribute need not
be physically stored within the database; instead, it can
be derived by using an algorithm.

48. Example:

49. Data type attribute in domain model:
 Number
 Booleans
 Characters
 Date
 String

50. Case Study : Monopoly game

51. DOMAIN MODEL REFINEMENT
 In the domain model refinement the fundamental concepts are
(i) Generalization
(ii) Specialization and
(iii) Conceptual class hierarchies

52. Finding conceptual class hierarchies
 Generalization has to be understand to identify conceptual super
and subclass
 A conceptual super class is more general or hold within the
subclass

53. Venn Diagram of set
relationships

54. Aggregation and composition
 Aggregation is a form of association.
 A hollow diamond is attached to the end of the path to indicate
aggregation
 Composition is denoted as solid diamond at the end of the path.
 Composition is also called as part whole relationship

57. Benefits of composition
 Composition is very useful in design than analysis.
 It assists in identification of creator using GRASP.
 Operations like copy, delete apply to parts.

58. Relationship between sequence diagrams
and use case
 System Sequence Diagram (SSD) shows systems events for one
scenario of a use case.
 The SSD is generated from inspection of a use case.
 SSDs are derived from use cases.
 While naming the system events, use the abstract level of
representation rather than physical input device.

59. Relationship between sequence diagrams
and use case

60. Relationship between sequence diagrams
and use case
Always start the system event with a verb like
• add
• enter
• end
• make

61. SSDs are highly useful
• To understand the interface
• Collaborations of existing systems
• To document the architecture.
Their purpose is to
1) Identify details of system events
2)Clarify major operations the system is designed to handle
3) Write system operation contracts

62. WHEN TO USE CLASS DIAGRAMS
 A class diagram describes the types of objects in the system and
the various kinds of static relationship that exist among them.
 The class diagrams show the attributes and operations of a class
and the constraints that apply to the way objects are connected.

63. Perspectives
 There are three different perspectives; we use in drawing class
diagrams. They are
• Conceptual
• Specification
• Implementation

64. Perspectives
 There are three different perspectives; we use in drawing class
diagrams. They are
• Conceptual
• Specification
• Implementation