Domain Model

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

use case

 Identify boundary, control, entity classes needed for each

1

 Consolidate into analysis model for application as a whole

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.

2

UML Class Diagram

 Là mô hình chính để phân tích yêu cầu

CloseRegistrationForm

CloseRegistrationController

Schedule

- semester

+ open() + close registration()

+ is registration open?() + close registration()

Professor

Student

- name - employeeID : UniqueId - hireDate - status - discipline - maxLoad

+ commit() + select alternate() + remove offering() + level() + cancel() + get cost() + delete() + submit() + save() + any conflicts?() + create with offerings() + update with new selections()

+ get tuition() + add schedule() + get schedule() + delete schedule() + has pre-requisites()

+ submitFinalGrade() + acceptCourseOffering() + setMaxLoad() + takeSabbatical() + teachClass()

3

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 system Collaborations A logical database schema

4

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.

5

Representing Classes and Objects in the UML

Professor

J Clark : Professor

class name

Named Object

- name - employeeID : UniqueId - hireDate - status - discipline - maxLoad

: Professor

attributes

Anonymous Object

+ submitFinalGrade() + acceptCourseOffering() + setMaxLoad() + takeSabbatical() + teachClass()

operations

Class

Object

6

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.

Student

Attributes

- name - address - studentID - dateOfBirth

7

Attributes in Classes and Objects

Class

:Student

Student

- name = “M. Modano” - address = “123 Main St.” - studentID = 9 - dateOfBirth = “03/10/1967”

Objects

- name - address - studentID - dateOfBirth

:Student

- name = “D. Hatcher” - address = “456 Oak Ln.” - studentID = 2 - dateOfBirth = “12/11/1969”

8

What Is an Operation?

 Ứng xử chung chia sẻ cho tất cả

Student

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

thực hiện:

+ get tuition() + add schedule() + get schedule() + delete schedule() + has prerequisites()

 Đọ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

9

 Hành động mà một đối tượng có thể

What Is an Association?

 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

has

require

10

Course CourseOffering Course

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

net2_05:CourseOffering

net1_05:CourseOffering

Network Basic:Course

Database:Course

11

dat_05:CourseOffering

What Are Roles?

 The “face” that a class plays in the association

Professor CourseOffering Department

instructor

departmenthead

Role name

preRequisites

12

Course

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:

be taught.

 For each instance of Professor, many Course Offerings may

one or zero Professor as the instructor.

 For each instance of Course Offering, there may be either

0..1 0..* Professor CourseOffering

13

instructor

Multiplicity Indicators

Unspecified

Exactly One

1

Zero or More

0..*

Zero or More

*

One or More

1..*

Zero or One (optional value)

0..1

Specified Range

2..4

Multiple, Disjoint Ranges

14

2, 4..6

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

<> Course

0..* 0..*

1 1

0..* 0..*

0..3 0..3

preRequisites

15

Example: Multiplicity

1 1

RegisterForCoursesForm

RegistrationController

1 1

0..1 0..1

0..1

1

0..*

Student

Schedule

CourseOffering

0..*

0..4

16

Example: Multiple Associations

0..* 0..4 primaryCourses

Schedule CourseOffering

0..* 0..2

alternateCourses

add student to

Schedule CourseOffering remove student from

Multiple associations must reflect multiple roles.

17

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

Navigability is inherently a design and implementation property. In analysis, associations are usually bi-directional; in design, we really check this.

18

Class1 Class2

Association Class

CourseOffering

primaryCourses

Schedule

 A class “attached” to an

association

0..*0..*

0..4 0..4

PrimaryScheduleOfferingInfo

- grade

 Contains properties of the relationship

 One instance per link

19

 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.

Domain Modeling

Phát hiện lớp miền

Phát hiện lớp miền (Key Abstraction)

 Từ các danh từ trong phát biểu bài toán

 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)

 Tài liệu yêu cầu phải đầy đủ và đúng.

 Sở hữu một tập các thuộc tính

 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 phép toán  Phép toán có thể nhận diện sau

21

 Thuộc tính định danh: chỉ xem xét nếu có ý nghĩa thực tế.

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",

22

 Mô hình lớp theo một cách khác hoặc loại bỏ lớp đó

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

0..*

0..*

register

0..*

0..*

0..4

1

23

CourseOffering primaryCourses Student Schedule

Ví dụ: Hệ thống đăng ký học phần

Course

CourseOffering

teach

offer

preRequisites

instructor

Professor - professorId - name

0..n 0..n

0..n 0..n

0..1 0..1

1 1

0..n 0..n

- credits - name - curriculum - description - number

- number - startTime - endTime - days /- numStudents

0..n 0..n

0..4 0..4 primaryCourses

0..2 0..2 alternateCourses

PrimaryScheduleOfferingInfob

- grade

0..n 0..n

0..n 0..n

Student

has

Schedule - semester

0..n 0..n

- name - address - studentID

1 1

24

Analysis Patterns: Definition

 “A pattern is an idea that...

 “Analysis patterns…

 has been useful in one practical context...  and will probably be useful in others”

modelling...

 are groups of concepts…  that represent a common construction in business

domains”

 may be relevant to only one domain, or may span many

(Fowler, 1997)

25

Transaction-TransactionLineItem Pattern

Transaction

TransactionLine number

number date

1..* 1..*

11

calcForMe()

calcOverLineItems()

 This is Coad’s pattern

 Very common in business documents

 Always look for the suggested attributes and operations -

e.g. calcForMe for line items

26

Examples

Order

OrderLine

orderNumber accountNumber customerName orderDate

Order Example

11

1..* 1..*

catalogueCode quantityDespatched itemDescription unitPrice VATCode

calcLineTotal()

calcGoodsValue() calcDeliveryCharge() calcVAT() calcAmountDue()

AccountStatement

StatementLine

branchNumber accountNumber customerName statementDate

transactionDate itemDetails itemAmount

1..* 1..*

11

Bank Account Statement Example

calcCurrentBalance()

calcTotalWithdrawn() calcTotalPaidIn() calcBalanceCF()

27

The Abstraction-Occurrence Pattern

 Context:

(occurrences).

 Often in a domain model you find a set of related objects

 Problem:

 The members of such a set share common information  but also differ from each other in important ways.

in a class diagram?

 Forces:

 What is the best way to represent such sets of occurrences

to represent

the members of each set of

occurrences without duplicating the common information

28

 You want

Abstraction-Occurrence

Solution:

Abstraction

Occurrence

1 1

* *

Title

LibraryItem barCodeNumber

11

* *

name author isbn publisher publicationDate

Examples

Video

title actorName

Copy barCodeNumber dateOfPurchase

11

* *

29

Abstraction-Occurrence Examples

1 1

0..* 0..*

courseId name credite

Course

CourseOffering offeringCode schedule proffesorName

Tour

11

* *

tourId description days price

30

TourOffer beginDate

Abstraction-Occurrence

31

 Antipatterns:

The Player-Role Pattern

 Context:

object in a particular context.

 A role is a particular set of properties associated with an

 Problem:

 An object may play different roles in different contexts.

can change roles or possess multiple roles?

32

 How do you best model players and roles so that a player

Player-Role

 Forces:

information associated with each separate role in a class.

 It is desirable to improve encapsulation by capturing the

 Solution:

33

 You want to avoid multiple inheritance.  You cannot allow an instance to change class

Example Player-Role

34

Organisation Hierarchies Patterns

 Another application for patterns

 Consider an organisation that is divided into

 Draw a class diagram to represent this

35

 Operating Units...  which are divided into regions...  which are divided into divisions...  which are divided into sales offices…

First Solution

Operating Unit

 This describes the reality but is difficult to modify

Region

 Removal of a region would force a significant change to the model

 A more flexible structure

Division

can be based on a reflexive (self) association

Sales Office

36

Single Reflexive Hierarchy

subsidiary *

1 Organisation

parent

OperatingUnit Region Division SalesOffice

 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

37

Modified Single Reflexive Hierarchy

subsidiary *

1

Organisation parent

{parent must be a division}

{parent must be a region}

{parent must be an operating unit}

OperatingUnit Region Division SalesOffice

UML’s Object Constraint Language (OCL) expresses constraints like these more formally. E.g: {self.parent.oclType=division}

38

UML Constraints

Two Hierarchies

 Now imagine each sales office has a “Product

Service Team”

 Product Service Teams report to both:

 I.e. there are two separate hierarchies

sales parent

1

*

product parent

Organisation

sales subsidiary

1

*

product subsidiary

39

 their sales office, and  their product division

Two Hierarchies

 Again this works, but further constraints would

need to be modeled

 The practical limit of modelling is two hierarchies

 More, and the structure becomes totally unwieldy

 The next model provides greater flexibility

40

1

*

Constrains

OrganisationStructureType

Rule

1

ExampleOf

*

*

ParentOf

1

OrganisationStructure

Organisation

*

1

SubsidiaryOf

*

AppliesTo

SalesOffice

Region

Division

OperatingUnit

1

TimePeriod

Multiple Hierarchies

 This pattern is now truly generic

 The class Organisation Structure Type permits an

arbitrary number of hierarchies

 The class Rule accommodates any necessary

constraints

 The class Time Period allows a structure to be

valid for a defined period of time

42