1. Domain Model

2. Tiếp cận xây dựng lược đồ lớp phân tích
Hai tiếp cận chính để xây dựng lược đồ lớp:
Domain Model: iterative ‘traditional’ approach:
Xây dựng lược đồ lớp từ tri thức về miền ứng dụng
Mô hình các khái niệm, sự vật quan trọng trong miền ứng dụng và quan hệ ràng buộc giữa chúng
Use-case analysis: Use case driven approach
Identify boundary, control, entity classes needed for each use case
Consolidate into analysis model for application as a whole

3. Domain Model (Mô hình miền)
Phân hoạch và mô tả các sự vật và các khái niệm quan trọng trong miền ứng dụng.
Hoạt động phân tích hướng đối tượng cổ điển.
Mô hình lớp phân tích độc lập với các use case cụ thể
Không biểu diễn các đối tượng phần mềm mà là tự điển trực quan về các khái niệm quan trọng của miền.

4. UML Class Diagram Là mô hình chính để phân tích yêu cầu
Introduce class diagrams to the students.
Interaction diagrams show the dynamic aspects of a system, while class diagrams show the static aspects of a system.
Là mô hình chính để phân tích yêu cầu
CloseRegistrationForm
+ open()
+ close registration()
Student
+ get tuition()
+ add schedule()
+ get schedule()
+ delete schedule()
+ has pre-requisites()
Schedule
- semester
+ commit()
+ select alternate()
+ remove offering()
+ level()
+ cancel()
+ get cost()
+ delete()
+ submit()
+ save()
+ any conflicts?()
+ create with offerings()
+ update with new selections()
Professor
- name
- employeeID : UniqueId
- hireDate
- status
- discipline
- maxLoad
+ submitFinalGrade()
+ acceptCourseOffering()
+ setMaxLoad()
+ takeSabbatical()
+ teachClass()
CloseRegistrationController
+ is registration open?()
A class diagram shows the existence of classes and their relationships in the logical design of a system. A class diagram may represent all or part of the class structure of a system.
Class diagrams show the static structure of the model, in particular, the things that exist such as classes, their internal structure, and their relationships to other classes. Class diagrams do not show temporal information.
The static view of a system primarily supports the functional requirements of a system.

5. Class Diagram Usage
Set the context for this module and present some reasons for using class diagrams.
Class diagrams are not entity-relationship diagrams. They go one step further with behavior.
The database schema may not always match 1:1 with the class diagram, but they should be fairly close.
When modeling the static view of a system, class diagrams are typically used in one of three ways, to model:
The vocabulary of a system
Collaborations
A logical database schema
Class diagrams allow you to model the vocabulary of your system when you determine the abstractions that are part of, or outside of, the boundaries of your system. Class diagrams specify these abstractions and their responsibilities.
A collaboration is a grouping of classes and other elements that work together to provide a solution that is bigger than the sum of the elements in the collaboration. No class stands alone, but works in collaboration with other elements to carry out some sort of solution. Class diagrams are one way to model these collaborations.
A database schema is similar to the blueprints for the conceptual design of a database. Many of the systems that you’ll design have persistent objects, which means that they have to be stored in a database for later retrieval. You can model schemas for these databases using class diagrams. The UML’s class diagrams are a superset of entity-relationship (E-R) diagrams. However, where typical E-R diagrams focus only on data, class diagrams take it one step further and allow the modeling of behavior, too. Behavior, modeled as operations, are generally turned into triggers or stored procedures on the database.

6. Review: Class
Explain what a class is to the students. Remember, many of your students are not familiar with this term.
The course introduces objects before classes because objects are the things that actually do most of the work. Classes are the templates for the objects.
A class is a description of a set of objects that share the same attributes, operations, relationships, and semantics.
An object is an instance of a class.
A class is an abstraction in that it
Emphasizes relevant characteristics.
Suppresses other characteristics.
A Class can be defined as:
A description of a set of objects that share the same attributes, operations, relationships, and semantics. (The Unified Modeling Language User Guide, Booch, 1999.)
There are many objects identified for any domain.
Recognizing the commonalties among the objects and defining classes helps us deal with the potential complexity.
The OO principle abstraction helps us deal with complexity.
The UML notation for a class permits you to see an abstraction apart from any specific programming language, which lets you emphasize the most important parts about an abstraction – its name, attributes, and operations.
Graphically, a class is represented by a rectangle.
The UML represents public visibility with a plus (+) symbol and private visibility with a minus (-) symbol.

7. Representing Classes and Objects in the UML
Demonstrate how a class is modeled in UML.
Tell them that the UML represents public visibility with a plus (+) symbol and private visibility with a minus (-) symbol. Do not discuss protected visibility.
Professor
- name
- employeeID : UniqueId
- hireDate
- status
- discipline
- maxLoad
+ submitFinalGrade()
+ acceptCourseOffering()
+ setMaxLoad()
+ takeSabbatical()
+ teachClass()
class name
attributes
operations
Class
J Clark :
Professor
: Professor
Named Object
Anonymous Object
Object
The UML notation for a class permits you to see an abstraction apart from any specific programming language, which lets you emphasize the most important parts about an abstraction – its name, attributes, and operations.
Graphically, a class is represented by a rectangle.
The UML represents public visibility with a plus (+) symbol and private visibility with a minus (-) symbol.
An object is represented with a rectangle and the name of the class.
The name of the object is always underlined. To name an object, place its name before the colon.
An object can be either named or anonymous. To remain anonymous, do not include a name.

8. Review: What Is an Attribute?
Define the term attribute for the students.
Remember, there are still operations in this class, but choose to suppress them.
An attribute is a named property of a class that describes the range of values that instances of the property may hold.
A class may have any number of attributes or no attributes at all.
Attributes
Student
- name
- address
- studentID
- dateOfBirth
An Attribute can be defined as:
A named property of a class that describes the range of values that instances of the property may hold. (The Unified Modeling Language User Guide, Booch, 1999.)
A class may have any number of attributes or no attributes at all. At any time, an object of a class has specific values for every one of its class’s attributes.
An attribute defined by a class represents a named property of the class or its objects. An attribute defines the type of its instances.
An attribute has a type, which tells us what kind of attribute it is. Typical attributes are integer, Boolean, real, and enumeration. These are called primitive types. An attribute does not need to be a primitive type though.

9. Attributes in Classes and Objects
Show that an attribute is defined on a class and instantiated on an object.
Class
:Student
- name = “M. Modano”
- address = “123 Main St.”
- studentID = 9
- dateOfBirth = “03/10/1967”
Student
- name
- address
- studentID
- dateOfBirth
Objects
:Student
- name = “D. Hatcher”
- address = “456 Oak Ln.”
- studentID = 2
- dateOfBirth = “12/11/1969”
At the class level, the Student class attributes indicate that the Students have names, addresses, studentIDs, and a date of birth.
At the object level, the attributes indicate the values for the name, address, studentID, and date of birth.
Only the class instance (objects) should be able to change the value of the attributes.
The state of an object is defined by the value of its attributes and the existence of links to other objects.

10. What Is an Operation?
Define the term operation for the students.
Point out that these should be called operations. Many people use the term methods instead of operations.
In the UML, methods and operations are NOT synonymous and have distinct definitions.
An operation is simply the advertisement of a service that is offered by a class. A method is the actual code that realizes that operation.
Ứng xử chung chia sẻ cho tất cả các đối tượng của lớp
Dịch vụ mà các đối tượng có thể cung cấp cho đối tượng khác
Hành động mà một đối tượng có thể thực hiện:
Đọc hay ghi các giá trị thuộc tính
Thực hiện các tính toán
Gởi messages tới đối tượng khác
Tạo hoặc hủy các liên kết với đối tượng khác
Student
+ get tuition()
+ add schedule()
+ get schedule()
+ delete schedule()
+ has prerequisites()
An Operation can be defined as:
A service that can be requested from an object to effect behavior. An operation has a signature, which may restrict the actual parameters that are possible.
The operations in a class describe what the class can do.
An operation can either be a command or a question. A question should never change the state of the object. Only a command can change the state of the object.
An operation is described with a return-type, name, and zero or more parameters. Together, the return-type, name, and parameters are called the signature of the operation.
The outcome of the operation depends on the current state of the object. Often, but not always, invoking an operation on an object changes the object’s data or state.

11. What Is an Association?
Introduce the concept of association to the students. This is new and may pose trouble for some students.
There are also dependency relationships. However, dependencies are beyond the scope of this course since they are contingent on parameter, local variable or global reference. These topics are discussed in the Object-Oriented Analysis and Design course. For the beginner, understanding associations is enough.
Draw these examples on the board as objects to help students understand the concept.
The semantic relationship between two or more classifiers that specifies connections among their instances
A structural relationship, specifying that objects of one thing are connected to objects of another
Associations represent structural relationships between objects of different classes; they connect instances of two or more classes together for some duration.
You can use associations to show that objects know about other objects. Sometimes, objects must hold references to each other to be able to interact; for example, to send messages to each other. Thus, in some cases, associations may follow from interaction patterns in Sequence diagrams or Collaboration diagrams.
Most associations are simple (exist between exactly two classes), and are drawn as solid paths connecting pairs of class symbols. Ternary relationships are also possible. Sometimes a class has an association to itself. This does not necessarily mean that an instance of that class has an association to itself; more often, it means that one instance of the class has associations to other instances of the same class.
An association may have a name that is placed on, or adjacent to the association path. The name of the association should reflect the purpose of the relationship and be a verb phrase. The name of an association can be omitted, particularly if role names are used.
Avoid names like "has" and "contains," as they add no information about what the relationships are between the classes.
Course
CourseOffering
has
Course
require

12. Link - kết nối giữa các đối tượng
Là một thể hiện của một association giữa các lớp.
Nếu 2 đối tượng có liên kết thì các lớp tương ứng của chúng sẽ có mối kết hợp
Kết nối nhằm tạo dễ dàng cho việc truyền message
net1_05:CourseOffering
net2_05:CourseOffering
dat_05:CourseOffering
Network Basic:Course
Database:Course

13. What Are Roles? The “face” that a class plays in the association
Department
Professor
departmenthead
CourseOffering
instructor
Course
preRequisites
Role name
Each end of an association has a role in relationship to the class on the other end of the association. The role specifies the face that a class presents on each side of the association. A role must have a name, and the role names on opposite sides of the association must be unique. The role name should be a noun indicating the associated object's role in relation to the associating object.
The use of association names and role names is mutually exclusive: one would not use both an association name and a role name. For each association, decide which conveys more information.
The role name is placed next to the end of the association line of the class it describes.
In the case of self-associations, role names are essential to distinguish the purpose for the association.
In the above example, the Professor participates in two separate association relationships, playing a different role in each.

14. Multiplicity
Introduce the concept of multiplicity.
Multiplicity is the number of instances one class relates to one instance of another class.
Thể hiện các qui định nghiệp vụ (business rule).
For each association, there are two multiplicity decisions to make, one for each end of the association.
For example:
For each instance of Professor, many Course Offerings may be taught.
For each instance of Course Offering, there may be either one or zero Professor as the instructor.
Multiplicity can be defined as:
The number of instances one class relates to one instance of another class.
For each role, you can specify the multiplicity of its class and how many objects of the class can be associated with one object of the other class.
Multiplicity is indicated by a text expression on the role. The expression is a comma-separated list of integer ranges.
It is important to remember that multiplicity is referring to instances of classes (objects) and their relationships. In this example, a Course Offering object may have either zero or one Professor object related to it. Conversely, a Professor object may have zero or more Course Offering objects related to it.
Multiplicity must be defined on both ends of the association.
Professor
CourseOffering
0..1
0..*
instructor

15. Multiplicity Indicators
Show the valid multiplicity indicators.
The use of “N” instead of “*” is Booch, not UML (for example, the use of “0..N” and “N” is not UML).
The multiplicity specified for a relationship is for all instances of that relationship, not simply for a particular use-case realization or for a particular point in time.
2..4
0..1
1..*
0..* 1 *
2, 4..6
Unspecified
Exactly One
Zero or More
Zero or One (optional value)
One or More
Specified Range
Multiple, Disjoint Ranges
For each role you can specify the multiplicity of its class. Multiplicity is the number of objects of the class that can be associated with one object of the other class.
Multiplicity is indicated by a text expression on the association line. The expression is a comma-separated list of integer ranges. A range is indicated by an integer (the lower value), two dots, and an integer (the upper value). A single integer is a valid range. You may also specify narrower limits such as 2..4.
During Analysis, assume a multiplicity of 0..* (zero to many) unless there is some clear evidence of something else.
A multiplicity of zero implies that the association is optional. When you use this notation, make sure this is what you mean. If an object might not be there, operations that use the association will have to adjust accordingly.
Within multiplicity ranges, probabilities may be specified. Thus, if the multiplicity is 0..*, and is expected to be between 10 and 20 in 85% of the cases, make note of it. This information will be of great importance during Design. For example, if persistent storage is to be implemented using a relational database, narrower limits will help better organize the database tables.

16. What Does Multiplicity Mean?
Multiplicity answers two questions:
Is the association mandatory or optional?
What is the minimum and maximum number of instances that can be linked to one instance?
CourseOffering
<<entity>>
Course 1
0..*
0..3
preRequisites
Multiplicity lets you know the lower and the upper bound number of relationships that a given object can have with another object. Many times you do not know what the maximum number of instances may be, and you will use the “*” to specify that this number is unknown.
The most important question that multiplicity answers: Is the association is mandatory? A lower bound number that is greater than zero indicates that the relationship is mandatory.
This example indicates that a course object can be related to zero or more course offerings. You can tell that the relationship is optional because the lower bound number is zero. The upper bound number of the relationship is unknown, as indicated by the “*”. If you read the association the other way, you will see that a given course offering object can be related to only one course. This relationship is mandatory and indicates that it is not possible for a course offering object to exist without an associated course object.

17. Example: Multiple Associations
CourseOffering
Schedule
0..*
0..2
alternateCourses
primaryCourses
0..4
CourseOffering
Schedule
add student to
remove student from
There can be multiple associations between the same two classes, but they should represent distinct relationships, and DIFFERENT ROLES; they should not be just for invoking different operations.
If there is more than one association between two classes then they MUST be named.
It is unusual to find more than one association between the same two classes. Occurrences of multiple associations should be carefully examined.
To determine if multiple associations are appropriate, look at instances of the classes. ClassA and ClassB have two associations between them, Assoc1 and Assoc2. If an instance of ClassA has a link with two SEPARATE instances of ClassB, then multiple associations are valid.
In the above example, the top diagram is an appropriate use of multiple associations, but the bottom diagram is not. In the valid case, two associations are required between Schedule and CourseOffering, as a Schedule can contain two kind of CourseOfferings, primary and alternate. These must be distinguishable, so two separate associations are used. In the invalid case, the two relationships represent two operations of CourseOffering, not two roles of CourseOffering.
Remember, Students and CourseOfferings are related via the Schedule class. Students are enrolled in a CourseOffering if there is a relationship between the Student’s Schedule and the CourseOffering.
Multiple associations must reflect multiple roles.

18. Navigability Bi-directional Uni-directional
Navigability (at least a first pass) needs to be done in analysis, otherwise, the architectural dependencies are not properly validated. This navigation may be refined in design (specifically, Class Design).
Note: Double headed arrows are also valid UML.
Rose uses the straight line rather than the double arrows to model bi-directional associations. This means that you cannot distinguish between a bi-directional relationship and a relationship with non-specified navigability.
Possible to navigate from an associating class to the target class – indicated by arrow which is placed on the target end of the association line next to the target class (the one being navigated to).
Associations are bi-directional by default – suppress arrows.
Arrows only drawn for associations with one-way navigability.
Bi-directional
Class1
Class2
Uni-directional
Class1
Class2
Navigability is inherently a design and implementation property. In analysis, associations are usually bi-directional; in design, we really check this.

19. Association Class A class “attached” to an association
Contains properties of the relationship
One instance per link
Allows you to store information about the relationship itself, where the info is not appropriate (does not belong to) within the classes at either end of the relationship.
Schedule
CourseOffering
0..4
0..*
primaryCourses
PrimaryScheduleOfferingInfo
- grade

20. Domain Modeling
Phát hiện lớp miền

21. Phát hiện lớp miền (Key Abstraction)
Từ các danh từ trong phát biểu bài toán
Tài liệu yêu cầu phải đầy đủ và đúng.
Là một phát biểu có mục đích
Miêu tả cho một tập các đối tượng (nhiều hơn 1)
Không xét các lớp chỉ có một thể hiện (Singleton)
Sở hữu một tập các thuộc tính
Thuộc tính định danh: chỉ xem xét nếu có ý nghĩa thực tế.
Sở hữu một tập các phép toán
Phép toán có thể nhận diện sau

22. Kiểm tra tính hợp lý của các lớp ứng viên
Nó có nằm ngoài phạm vi của hệ thống không?
Nó có ám chỉ tới toàn bộ hệ thống không?
Nó có lập lại một lớp khác không?
Nó có quá mơ hồ không?
Nó có buộc quá chặt với inputs và outputs vật lý không?
Nó có là một thuộc tính hay không?
Nó có là một mối kết hợp hay không?
Nếu câu trả lời là "Yes",
Mô hình lớp theo một cách khác hoặc loại bỏ lớp đó

23. Nhận diện quan hệ
Từ các động từ biểu diễn các quy định nghiệp vụ (business rules) trong phát biểu bài toán
Tránh các chu trình trong quan hệ
có thể có ý nghĩa giống nhau
Schedule
Student
0..* 1
CourseOffering
0..4
primaryCourses
register

24. Ví dụ: Hệ thống đăng ký học phần
Course
- credits
- name
- curriculum
- description
- number
0..n
preRequisites
Professor
- professorId
CourseOffering
- startTime
- endTime
- days
/- numStudents
Schedule
- semester
0..2
alternateCourses
Student
- address
- studentID
0..4
primaryCourses
PrimaryScheduleOfferingInfob
- grade 1
offer
0..1
instructor
teach
has

25. Analysis Patterns: Definition
“A pattern is an idea that...
has been useful in one practical context...
and will probably be useful in others”
“Analysis patterns…
are groups of concepts…
that represent a common construction in business modelling...
may be relevant to only one domain, or may span many domains”
(Fowler, 1997)

26. Transaction-TransactionLineItem Pattern
number
date
calcOverLineItems()
TransactionLine
calcForMe()
1..* 1
This is Coad’s pattern
Very common in business documents
Always look for the suggested attributes and operations - e.g. calcForMe for line items

27. Examples Order Example Bank Account Statement Example AccountStatement
orderNumber
accountNumber
customerName
orderDate
calcGoodsValue()
calcDeliveryCharge()
calcVAT()
calcAmountDue()
OrderLine
catalogueCode
quantityDespatched
itemDescription
unitPrice
VATCode
calcLineTotal()
1..* 1
Order Example
AccountStatement
branchNumber
accountNumber
customerName
statementDate
calcTotalWithdrawn()
calcTotalPaidIn()
calcBalanceCF()
StatementLine
transactionDate
itemDetails
itemAmount
calcCurrentBalance()
1..* 1
Bank Account Statement Example

28. The Abstraction-Occurrence Pattern
Context:
Often in a domain model you find a set of related objects (occurrences).
The members of such a set share common information
but also differ from each other in important ways.
Problem:
What is the best way to represent such sets of occurrences in a class diagram?
 Forces:
You want to represent the members of each set of occurrences without duplicating the common information

29. Abstraction-Occurrence
Solution:
Abstraction
Occurrence * 1
Title
name
author
isbn
publisher
publicationDate
LibraryItem
barCodeNumber * 1
Examples
Video
title
actorName
Copy
barCodeNumber
dateOfPurchase * 1

30. Abstraction-Occurrence Examples
CourseOffering
offeringCode
schedule
proffesorName
Course
courseId
name
credite 1
0..*
Tour
tourId
description
days
price
TourOffer
beginDate * 1

31. Abstraction-Occurrence
Antipatterns:

32. The Player-Role Pattern
Context:
A role is a particular set of properties associated with an object in a particular context.
An object may play different roles in different contexts.
Problem:
How do you best model players and roles so that a player can change roles or possess multiple roles?

33. Player-Role Forces: Solution:
It is desirable to improve encapsulation by capturing the information associated with each separate role in a class.
You want to avoid multiple inheritance.
You cannot allow an instance to change class
Solution:

34. Example Player-Role

35. Organisation Hierarchies Patterns
Another application for patterns
Consider an organisation that is divided into
Operating Units...
which are divided into regions...
which are divided into divisions...
which are divided into sales offices…
Draw a class diagram to represent this

36. First Solution This describes the reality but is difficult to modify
Removal of a region would force a significant change to the model
A more flexible structure can be based on a reflexive (self) association
Operating Unit
Region
Division
Sales Office

37. Single Reflexive Hierarchy
OperatingUnit
Region
Division
SalesOffice
Organisation 1
parent
subsidiary *
This model has further weaknesses
As it stands, it would permit a division to be part of a sales office
This could be overcome by introducing constraints at subclass level

38. Modified Single Reflexive Hierarchy*
OperatingUnit
Region
Division
SalesOffice
Organisation 1
parent
subsidiary
{parent must be a division}
{parent must be an
operating unit}
{parent must be a region}
UML Constraints
UML’s Object Constraint Language (OCL) expresses constraints like these more formally. E.g: {self.parent.oclType=division}