4a domain model
DESCRIPTION
TRANSCRIPT
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:
1. 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
2. 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
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?()+ close registration()
5
Class Diagram Usage When modeling the static view of a system, class
diagrams are typically used in one of three ways, to model:The vocabulary of a systemCollaborationsA logical database schema
6
Review: Class 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.
7
Representing Classes and Objects in the UML
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
8
Review: What Is an Attribute? 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
9
Attributes in Classes and ObjectsClass
Objects
Student- name- address- studentID- dateOfBirth
:Student
- name = “M. Modano”- address = “123 Main St.”- studentID = 9- dateOfBirth = “03/10/1967”
:Student
- name = “D. Hatcher”- address = “456 Oak Ln.”- studentID = 2- dateOfBirth = “12/11/1969”
10
What Is an 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()
11
What Is an Association?
Course
require
Course CourseOfferinghas
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
12
Link - kết nối giữa các đối tượng
net1_05:CourseOffering
net2_05:CourseOffering
dat_05:CourseOffering
Network Basic:Course
Database:Course
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
13
What Are Roles? The “face” that a class plays in the association
DepartmentProfessor
departmenthead
CourseOfferinginstructor
Course preRequisites
Role name
14
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.
Professor CourseOffering0..1 0..*
instructor
15
Multiplicity Indicators
2..4
0..1
1..*
0..*
1
*
2, 4..6
Unspecified
Exactly One
Zero or More
Zero or More
Zero or One (optional value)
One or More
Specified Range
Multiple, Disjoint Ranges
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<<entity>>
10..* 10..*
0..3
0..*
preRequisites0..3
0..*
18
Example: Multiple Associations
Multiple associations must reflect multiple roles.
CourseOfferingSchedule0..*
0..2
alternateCourses
primaryCourses0..* 0..4
CourseOfferingSchedule
add student to
remove student from
19
Bi-directionalClass1 Class2
Uni-directional Class1 Class2
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.
Navigability is inherently a design and implementation property. In analysis, associations are usually bi-directional; in design, we really check this.
20
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..40..*0..* 0..4
primaryCourses
PrimaryScheduleOfferingInfo- grade
Domain Modeling
Phát hiện lớp miền
22
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
23
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 đó
24
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
ScheduleStudent
0..*1
CourseOffering
0..40..*
primaryCourses
0..*0..*
register
25
Ví dụ: Hệ thống đăng ký học phần
Course- credits- name- curriculum- description- number
0..n
0..n
preRequisites
0..n
0..n
Professor- professorId- name
CourseOffering- number- startTime- endTime- days/- numStudents
Schedule- semester
0..n
0..2
0..n
alternateCourses0..2
Student- name- address- studentID
0..n
0..4
0..n
primaryCourses0..4
PrimaryScheduleOfferingInfob- grade
0..n1 0..n1
offer
0..10..n
instructor
0..10..n
teach
0..n1 0..n1
has
26
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)
27
Transaction-TransactionLineItem Pattern
This is Coad’s pattern Very common in business documents Always look for the suggested attributes and operations -
e.g. calcForMe for line items
Transactionnumberdate
calcOverLineItems()
TransactionLinenumber
calcForMe()1..*11 1..*
28
ExamplesOrder
orderNumberaccountNumbercustomerNameorderDate
calcGoodsValue()calcDeliveryCharge()calcVAT()calcAmountDue()
OrderLine
catalogueCodequantityDespatcheditemDescriptionunitPriceVATCode
calcLineTotal()
1..*11 1..*
AccountStatement
branchNumberaccountNumbercustomerNamestatementDate
calcTotalWithdrawn()calcTotalPaidIn()calcBalanceCF()
StatementLine
transactionDateitemDetailsitemAmount
calcCurrentBalance()
1..*11 1..*
Order Example
Bank Account Statement Example
29
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
30
Abstraction-Occurrence
Solution: Abstraction Occurrence
*1 *1
TitlenameauthorisbnpublisherpublicationDate
LibraryItembarCodeNumber
*11 *
VideotitleactorName
CopybarCodeNumberdateOfPurchase
*11 *
Examples
31
Abstraction-Occurrence Examples
CourseOfferingofferingCodescheduleproffesorName
CoursecourseIdnamecredite 1 0..*1 0..*
TourtourIddescriptiondaysprice
TourOfferbeginDate
*11 *
32
Abstraction-Occurrence Antipatterns:
33
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?
34
Player-Role
Forces: 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:
35
Example Player-Role
36
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
37
First Solution
Operating Unit
Region
Division
Sales Office
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
38
Single Reflexive Hierarchy
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
OperatingUnit Region Division SalesOffice
Organisation 1
parent
subsidiary *
39
Modified Single Reflexive Hierarchy
{parent must be a division}{parent must be anoperating 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}
*
OperatingUnit Region Division SalesOffice
Organisation1
parent
subsidiary