Seminar môn OOD Đề tài Mô hình cấu trúc

Seminar môn OOD Đề tài Mô hình cấu trúc

Seminar môn OOD

Đề tài: Mô hình cấu trúc

GVHD: Dương Bá Hồng Thuận

Khái niệm về mô hình cấu trúc

 Trong pha phân tích, mô hình chức năng để đưa

ra việc xử lý hệ thống nghiệp vụ thì mô hình cấu trúc đưa ra việc tổ chức và thể hiện chúng.

 Mô hình cấu trúc hay khái niệm là mô hình mô tả cấu trúc của dữ liệu hỗ trợ quá trình xử lý nghiệp

vụ trong một tổ chức.

 Mô hình cấu trúc vẽ lên để nó trở lên chi tiết hơn

và giảm tính hình tượng hơn.

 Mô hình cấu trúc nhằm thu hẹp khoảng cách giữa thế giới thực và thế giới phần mềm.

 Mục đích đầu tiên của mô hình cấu trúc là tạo ra một bộ từ vựng để có thể sử dụng chung cho cả người phân tích và người dùng

Khái niệm về mô hình cấu trúc

 Các cách thức mô tả cấu trúc:

- CRC cards, class diagrams, and object diagrams

 Các phần tử cơ bản của mô hình cấu trúc:

- Classes (Lớp)

- Attributes (Thuộc tính)

- Operations (Hành động, phương thức)

- Relationships (Các quan hệ)

Classes (Lớp)

 Một đối tượng là một thực thể có thực hoặc là một khái niệm.

 Mỗi đối tượng được mô tả bởi trạng thái và hành

vi cho biết đối tượng đó sẽ hành động như thế nào.

 Một nhóm các đối tượng có chung thuộc tính và phương thức thì tạo thành một lớp.

 Một lớp là một khuân mẫu chung để tạo ra các thực thể hoặc các đối tượng.

 Có 2 loại “Class”:

- Lớp cụ thể (Concrete)

- Lớp trừu tượng (Abtract)

Classes (Lớp)

 Lớp cụ thể dùng để tạo ra các đối tượng cụ thể

 Lớp trừu tượng dùng để tạo ra các lớp khác.

Attributes (Thuộc tính)

 Thuộc tính là những mẩu thông tin dùng để mô tả cho lớp.

 Chỉ những thuộc tính là quan trọng thì mới nên

đưa vào trong lớp.

 Chỉ nên đưa những thuộc tính dạng cơ sở, nguyên

tố vào lớp như (integer, strings, doubles, date,

time, boolean,…)

Operations (Hành động, phương thức)

 Một Operation là hành vi của lớp sẽ được định

nghĩa ở đâu.

 Trong các phase sau thì phương thức sẽ được

chuyển đối sang phương pháp (method).

 Phương thức tập trung vào các hoạt động cụ thể của của các vấn đề liên quan.

Relationships (Mối quan hệ)

 Được chia ra làm ba loại mối quan hệ chính:

• Mối quan hệ tổng quát hóa (Generalization)

• Mối quan hệ bao hàm (Aggregation)

• Mối quan hệ liên kết (Association)

 Mối quan hệ tổng quát hóa (Generalization)

• Cho phép tạo ra những lớp thừa hưởng thuộc tính và

phương thức của lớp khác.

• Mối quan hệ tổng quát hóa bao gồm kiểu quan hệ A–

kind-of.

• Trong mối quan hệ này thì lớp con (Subclasses) được

tạo ra từ lớp lớn hơn (Superclasses).

• Để đảm bảo ngữ nghĩa của những lớp con được duy

trì, sử dụng định luật thay thế substitutability.

Relationships (Mối quan hệ)

 Mối quan hệ bao hàm (Aggregation)

• Các kiểu quan hệ có thể có là a-part-of, a-member-of, contained-in, related-to, và associated-with.

• Chúng liên kết bộ phận với toàn bộ.

• Mối quan hệ này là quan hệ hai chiều trong tự nhiên.

 Ngược lại với aggregation là decomposition

 Các bộ phận có thể được mô hình hóa riêng biệt nhau.

 Mối quan hệ liên kết (Association)

• Các kiểu quan hệ khác 2 loại trên

• Chúng thể hiện một cách đơn giản nhất sự liên kết giữa

các thực thể của lớp.

Lưu trữ tất cả các thông tin về lớp.

Quyết định những nhân tố bên

trong CRC cards.

Responsibilities and Collaborations( Trách nhiệm và sự cộng tác )

 Responsibilities ( Trách nhiệm ) : Chia làm

2 loại.

• Knowing ( Biết ):

 Đối tượng của lớp phải có năng lực biết được.

 Năng lực của một lớp biết được từ giá trị thuộc tính

và quan hệ.

• Doing ( Làm ) :

 Đối tượng của lớp có thể thực hiện hoạt động.

 Hoặc yêu cầu đối tượng khác thực hiện hoạt động thay thế.

CLASS-RESPONSIBILITY-COLLABORATION CARDS

( Lớp – Trách nhiệm – Thẻ cộng tác )

 Collaboration ( Cộng tác )

• Mô hình cấu trúc là : mô tả những đối

tượng cần thiết, cung cấp cho mô hình qua quá trình nghiệp vụ.

• Có thể dùng một bản ghi của nhiều lớp.

• Các đối tượng tác động với nhau để thực hiện 1 yêu cầu.

• Bản ghi của lớp là dạng cộng tác.

Collaboration ( Cộng tác )

 Cộng tác client,server và contract

• Đối tượng client gửi yêu cầu tới đối

tượng khác để thao tác được thực hiện.

• Đối tượng server đáp ứng yêu cầu của đối tượng khách hàng.Contract

• Đối tượng Contract : sự tương tác giữa client và server.

 Client : là đối tượng bệnh nhân.

 Server : là đối tượng bác sỹ.

 Contract là Cả hai đều đồng ý cuộc gặp tại một địa điểm và thời gian cụ thể.

 Cách dễ dàng nhất là dùng CRC cards trong việc phát triển

mô hình cấu trúc xuyên suốt thuyết hình người giả bộ

những lớp có đặc tính người.

 Người phân tích và hoặc người sử dụng sự sắm vai ( play) và giả bộ chúng ta là đối tượng của lớp sự bao gồm.

role-CLASS-RESPONSIBILITY-COLLABORATION CARDS

( Lớp – Trách nhiệm – Thẻ cộng tác )

 Chúng ta có thể đặt câu hỏi về những gì của

chúng hoặc bị đặt câu hỏi bởi các thành viên khác trong nhóm phát triển :

 Ví dụ :

• Who or what are you ? (Bạn là ai / Bạn làm cái gì?)

• What do you know ? (Bạn biết làm cái gì ?)

• What can you do ? (Bạn có thể làm cái gì ?)

 Câu trả lời của câu hỏi đó sẽ được thêm vào bản chi tiết tiến triển CRC cards.

Elements of a CRC Card( Những nhân tố của bảng CRC Card )

Elements of a CRC Card( Những nhân tố của bảng CRC Card )

A CRC Card

Back of CRC Card

Review CRC Card

Class diagrams

mối quan hệ giữa các lớp

cùng mối quan hệ giữa các lớp đó

Class diagrams

Element of a class diagram

trữ thông tin hệ thống (person, palace…)

Attribute

đối tượng, nơi chúng ta lấy thông tin.

đối tượng nào, những đối tượng khác có thể thay đổi giá trị của nó

tượng trừ immediate subclasses.

hiện trong khung lớp ví dụ hàm “cancel

without notice” trong lớp Appointment.

lớp Bill

Constructor Operation

ra 1 thực thể patient mới.

nó không được biểu diễn trong khung lớp

Query Operation

nhưng không thay đổi đối tượng

cuối cùng bệnh nhân tới bác sĩ sẽ lấy kết quả từ đối tượng bị truy nhập bởi hệ thống chứ không làm thay đổi nó.

thông tin từ thuộc tính thì nó không thể hiện

trong biểu đồ.

Update Operation

của đối tượng, dẫn tới thay đổi trạng thái của đối tượng

“change status()”.

Relationship

với nhau hoặc với chính nó trên biểu đồ lớp

nó

có tên của mối quan hệ

đối tượng có thể quan hệ với nhiều thực thể khác khác)

maximum and minimum thực thể có liên quan tới nhau trong mối quan hệ biểu diễn dưới

dạng minimum number…maximum number

Bill” đây là quan hệ 1 nhiều.

nhiều (1 bệnh có nhiều triệu trứng và 1 tri

biệt trong trường hợp mối quan hệ là nhiều nhiều.

lớp mà tự nó có những thuộc tính và hoạt động.

quan hệ và tên của hình vuông được gán là tên của mối quan hệ,

có nhiều bệnh Hình 7-2 shown cách lớp quan hệ lấy thông tin

của illness và symptoms.

thường; tuy nhiên, có 2 trường hợp đặc biệt của mối quan hệ:

với các đối tượng lớp subclass.

subclass tới lớp supperclass và có một mũi tên ở lớp

supperclass.

thuộc lớp employees và lớp employee và patient thuộc lớp person.

Aggregation

khác.

nurse, administrative personnel Khi 1 patient đến khám bệnh tại phòng này.

được thể hiện trong biểu đồ lớp Một hình kim cương được đặt gần lớp health team, và những đường nối từ lớp dotor, nurse, administrative.

Simplifying class diagrams

thống thực, biểu đồ lớp sẽ rất khó để phân biệt quá phức tạp.

Sử dụng view machanism có thể làm đơn giản biểu đồ lớp.

thống.

aggregation, association, generalization.

diễn tên lớp, tên thuộc tính hay tên của hoạt động…

Simplifying class diagrams…

không quá phức tạp

trong mẫu UML.

Object Diagrams

Có thời điểm biểu đồ đối tượng có thể tiện dụng hơn.

cả hoặc 1 phần biểu đồ lớp.

tượng hơn là trừu tượng hóa đối tượng

Object Diagrams…

Object Diagrams…

Object Diagrams…

Dr.Smith) chúng ta có thể tìm được những thuộc tính, mối quan hệ, hoạt động cần thiết và những cái có thể bỏ qua

mối liên hệ với lớp “symptom” Hiện tại thì lớp

“symptom” có mốilieen hệ với lớp “patient”

lỗi và chúng ta cần sửa biểu đồ lớp để giải quyết vấn đề.

Tạo thẻ CRC và biểu đồ

lớp

Việc tạo một mô hình cấu trúc là 1 quá trình lặp

đi lặp lại nhờ đó mà người phân tích có thể tạo ra

1 mô hình thô và sau đó được chỉnh sửa dần Mô hình cấu trúc có thể trở nên khá phức tạp Trên thực tế, một vài hệ thống có biểu đồ lớp chứa tới

hàng trăm lớp con

 Trong phạm vi phần này , chúng ta sẽ làm rõ một chu trình lặp của việc tạo một mô hình cấu trúc, nhưng mô hình có thể bị thay đổi một

cách đột ngột khi bạn giao tiếp với người sử

dụng

 Tuy nhiên, đầu tiên chúng ta sẽ giới thiệu về các cách tiếp cận để phát hiện và chỉnh sửa

một bộ các đối tượng ứng cử cũng như đưa ra các bước cụ thể dựa trên những cách tiếp cân

đó, những cách tiếp cân mà có thể được sử

dụng để tạo ra mô hình cấu trúc thô ban đầu

Nhận biết đối tượng

 Có rất nhiều cách tiếp cận khác nhau có thể dùng trong pha phân tích để phát hiện ra bộ các đối tượng ứng cử cho mô hình cấu trúc 3 cách phổ biến nhất hiện nay là: phân tích văn bản, liệt kê các đối tượng thường gặp, và mô hình mẫu

 Cách phân tích hiệu quả nhất là kết hợp cả 3 cách trên để chắc chắn

rằng không có đối tương quan trọng nào hay thuộc tính nào của đối tượng ,cũng như cách hoạt động và các mối quan hệ của đối tượng bị bỏ qua

Phân tích văn bản

 Phân tích văn bản là cách phân tích trên giấy

tờ trong mô tả use-case Bươc phân tích bắt

đầu bằng việc xem xét lại mô tả và mô hình use-case Văn bản trong những mô tả được

nghiên cứu để từ đó phát hiện ra những đối

tượng tiềm năng, các thuộc tính, các hoạt động

và các mối quan hệ của đối tượng

 Tên của 1 lớp có thể có phải là danh từ còn tên của những hoạt động có thể có phải là động từ Hình 7-6 là bảng tóm tắt những hướng dẫn Phân tích văn bản trong mô tả use-case có

nhược điểm là quá đơn giản nhưng bởi vì mục đích chính chỉ là tạo ra 1 mô hình thô ban đầu nên đây lại chính là một ưu điểm lớn

Liệt kê danh sách các đối tượng

thường gặp

 Đúng như tên của phương pháp, liệt kê danh sách các đối tượng thường gặp chỉ đơn giản là đưa ra tất cả phạm vi nghiệp vụ của hệ thống Thêm vào đó, để thấy được các trường hợp sử dụng cụ thể, người phân tích cũng cần chú ý tới bài toán nghiệp vụ một cách tách biệt với các trường hợp sử dụng cụ thể đã nói ở trên

 Một vài loại đối tượng đã được tạo ra để giúp người phân tích trong việc lập danh sách như các đối tượng vật lí hay hữu hình, các sự việc lien quan, vai trò và sự tác động qua lại lẫn

nhau Đầu tiên người phân tích nên tìm kiếm những phần tử hữu hình trong phạm vi nghiệp vụ

 Đó có thể là sách, bàn, ghế hay các thiết bị văn

phòng Thông thường thì đây là những đối tượng

dễ nhận diện nhất Các sự việc lien quan là những

sự kiện xuất hiện trong phạm vi nghiệp vụ như

các cuộc họp, các chuyến bay, các buổi trình diễn

các cuộc họp, các chuyến bay, các buổi trình diễn

và cả các điều ngoài ý muốn Xem xét lại các

trường hợp sử dụng có thể giúp ta dễ dàng phát hiện ra vai trò của các tác nhân trong các sự việc các tác nhân như bác sĩ, y tá, bệnh nhân, hay các nhân viên tiếp tân

 Một cách điển hình, sự tác động qua lại chính

là sự giao dịch diễn ra trong phạm vi nghiệp

vụ như sự mua bán qua lại, những loại đối tượng khác co thể được nhận diện như địa

điểm, nội dung, tổ chức, bản ghi kinh doanh, bảng mục lục, và chiến lược Trong các

trường hợp như thế này, những quá trình cần 1 đối tượng cụ thể, thêm vào 1 trường hợp sử

dụng để đặc trưng

Mô hình mẫu

 Ý tưởng sử dụng mô hình mẫu trong việc phát triển hệ thống hướng đối tượng thì khá là mới

mẻ hiện nay có rất nhiều định nghĩa chính xác

về phương pháp này Ở đây chúng ta hiểu rằng

mô hình mẫu đơn giản là một nhóm các lớp

liên kết với nhau và có thể tạo ra những giải

pháp cho các vấn đề thường xuyên xảy ra Và cũng chính vì điều này mà chúng có tính chất

là có thể sử dụng lại được

 Kiến trúc sư Christopher Alexander là người

đã sử dụng mô hình mẫu trong việc phát triển những hệ thống hướng đối tượng Theo

Christopher Alexander và những đồng nghiệp thì những công trình phưc tạp được xây lên bằng cách ghép nối những kiểu mẫu cơ bản thường gặp hơn là tạo ra 1 mẫu thiết kế hoàn toàn mới

 Hoàn toàn tương tự, chúng ta có thể kết hợp những mô hình mẫu hướng đối tượng cơ bản thường gặp để tạo ra 1 hệ thống thông tin

hướng đối tượng hoàn chỉnh Ví dụ như, cùng một loại đối tượng và cùng sự tác động qua lại nhưng có thể bao gồm nhiêù “business

transaction”

 Hầu hết tất cả các giao dịch đều cần 1 lớp giao dịch , 1 dãy lớp, 1 lớp định vị, và lớp thành phần Bằng cách sử dụng lại những mô hình mẫu của những lớp đã tồn tại, chúng ta có thể định nghĩa 1 lớp nhanh hơn và hoàn chỉnh hơn

là bắt đầu với 1 tờ giấy trắng

 Rất nhiều những mô hình mẫu đã được đưa

ra, từ những mô hình hướng nghiệp vụ mức độ cao đến những mô hình thiết kế ở mức độ thấp hơn Hình 7-7 đưa ra một vài phạm vi nghiệp

vụ mà mô hình mẫu có thể phát triển, cũng

như nguồn gốc của chúng

 Nếu bạn đang phát triển một hệ thống thông tin kinh doanh mà nằm trong những phạm vi nghiệp vụ trên thì những mô hình mẫu phát

triển cho phạm vi đó có thể sẽ rất hữu ích cho bước khởi đầu trong việc nhận dạng các lớp cần thiết, các thuộc tính, phương thức hoạt

động cũng như các mối quan hệ của chúng

Xây dựng thẻ CRC và biểu đồ lớp

 Cần phải biết rằng, mặc dù thẻ CRC và biểu

đồ lớp được sử dụng để mô tả cả mô hình cấu trúc As-Is và To-Be của hệ thống lien quan nhưng chúng chủ yếu được sử dụng cho mô hình To-Be Có rất nhiều cách khác nhau để nhận dạng 1 bộ đối tượng ứng cử và để tạo ra thẻ CRC và biểu đồ lớp

 Ngày nay việc nhận dang đối tượng chủ yếu bắt đầu bằng cách sử dụng các trường hợp sử dụng trong các vấn đề Trong phần này, chúng

ta sẽ nói về một quá trình gồm bảy bước được

sử dụng để tạo ra mô hình cấu trúc cho vấn đề

Tạo thẻ CRC

 Chúng ta hoàn toàn có thể bắt đầu việc tạo ra

mô hình cấu trúc với biểu đồ lớp thay vì với thẻ CRC Tuy nhiên, do tính đơn giản của thẻ CRC mà ban đầu người ta sẽ tạo thẻ CRC

trước rồi sau đó sẽ chuyển thông tin từ thẻ

CRC sang biểu đồ lớp sau Và như vậy, bước đầu tiên trong quá trình 7 bước của chúng ta chính là tạo thẻ CRC

 Việc này được thực hiện bằng cách phân tích các văn bản trong mô tả use case Hãy nhớ lại, những dòng sự kiện thông thường, các dòng trên, các dòng luôn phiên/ngoại lệ của mô tả use case được thể hiện dưới 1 hình thức đăc biệt gọi là Subject Verb Direct object

Preposition Indirect object (SVDPI)

 Bằng cách thể hiện các sự kiện use-case theo hình thức này, sẽ dễ dàng hơn để sử dụng

những hướng dẫn trong việc phân tích use-

case (hình 7-6) để nhận dạng đối tượng Việc xem xét lại các tác nhân quan trọng,

stakeholders, lãi suất và đưa ra những mô tả ngắn gọn của mỗi use case cho phép phát hiện

ra những đối tượng ứng cử thêm vào

 Hơn thế nữa, việc quay lại và xem xét các

yêu cầu ban đầu để tìm kiếm những thông tin

mà không chứa trong các văn bản của use case

là rất hữu ích Việc ghi lại tất cả các thông tin làm lộ ra mỗi đối tượng ứng cử trên thẻ CRC

Kiểm tra danh sách những lớp

thường gặp

 Bước thứ 2 là bắt đầu tạo ra ý tưởng về các

đối tượng các thuộc tính, các hoạt động và các mối quan hệ ứng cử thêm vào bằng cách sử

dụng cách tiếp cận liệt kê các đối tượng

thường gặp Những thứ hữu hình mà có liên kết tới vấn đề là gì? Vai trò của con người

trong phạm vi vấn đề là gì? Những việc bất ngờ và sự tương tác nào có thể diễn ra trong phạm vi vấn đề?