Mô hình hóa đối tượng - nhuloan.weebly.comnhuloan.weebly.com/uploads/4/5/3/6/45363345/lecture04.pdf · Nộidung trước Mô hình hóa yêu cầu: Lược đồ Use-case

Mô hình hóa đối tượngMô hình hóa đối tượng

Nội dung trước

�Mô hình hóa yêu cầu:� Lược đồ Use-case� Khái niệm Actor và Usecase� Ví dụ

�Mô hình hóa các dòng dữ liệu của mỗi Use-case

4 – Mô hình hóa đối tượng– Class Diagram 2

�Mô hình hóa các dòng dữ liệu của mỗi Use-case� Giới thiệu Mô hình DFD� Sử dụng mô hình DFD để mô hình hóa yêu

cầu lưu trữ, tra cứu, tính toán, kết xuất

Nội dung

�Quản lý yêu cầu:

� Giới thiệu

� Chi tiết quản lý yêu cầu

� Các kỹ năng


� Các kỹ năng

�Mô hình hoá đối tượng

�Class & Class Diagram

Giới thiệu

� Một trong những hoạt động đầu tiên

� Mục tiêu: tìm cái cần xây dựng

� Giao tiếp giữa người dùng và người phát triển, vì vậy� Không có ký hiệu phức tạp (ngoại trừ trong lĩnh vực chuyên môn)

� Thường dùng ngôn ngữ tự nhiên

� Hợp đồng

4 – Mô hình hóa đối tượng– Class Diagram

� Hợp đồng

� Các cách thức để xác định yêu cầu

� Các cách thức để chuẩn hóa yêu cầu� Scenarios, Use Cases, Mockups / Prototypes, Feature, Lists

� Stakeholders� Những người quan tâm đến sản phẩm

4

Thế nào là quản trị yêu cầu

�Là tiến trình tìm hiểu, sưu liệu và quản lý

các yêu cầu.

� Sử dụng những kỹ thuật mang tính hệ


thống để đảm bảo yêu cầu:

� Complete (đầy đủ)

� Consistent (nhất quán)

� Relevant (thích đáng)

5


�Diễn tả bằng văn xuôi,

� Tìm hiểu cái người dùng muốn

� Tổ chức thông tin này lại

� Sưu liệu thông tin này


� Sưu liệu thông tin này

� Theo vết thay đổi thông tin này

� Quản lý tất cả thay đổi

� Đáp ứng nhu cầu người dùng cuối

�Thiết lập quy trình và thực hiện theo nó6


�Hầu hết các tổ chức phát triển phần mềm đều làm việc

này theo những cách thức khác nhau.

�Nhưng thường chúng không mang tính hình thức và mang

tính không thống nhất từ dự án này qua dự án khác


�CMM Level 1 vs. CMM Level 2

= Định nghĩa được tiến trình quản lý yêu câu

7

Thế nào là một yêu cầu

� Là một khả năng của phần mềm được

người dùng yêu cầu, để giải quyết một

vấn đề nhằm đạt một mục tiêu nào đó


�Thành công của dự án = thoả mãn các

yêu cầu

8

Nguồn yêu cầu: Khách hàng

� Phỏng vấn khách hàng� Người trả tiền cho chúng ta� Những stakeholders

• Người sử dụng• Người quản lý

� Vấn đề:� Khách hàng có thể không biết họ muốn gì


� Khách hàng có thể không biết họ muốn gì• Phần mềm là một khái niệm trừu tượng và phức tạp

� KH có thể thay đổi ý kiến� KH không có khả năng diễn tả nhu cầu theo những thuật ngữ

chuyên môn• Giao tiếp giữa người chuyên làm p.mềm <> người bình thường

� Các kỹ thuật� Giao diện & Hệ thống đã tồn tại

9

Nguồn yêu cầu: thị trường

� Đánh giá các sản phẩm cạnh tranh

� Những gì trước đây đã thực hiện?

� Nơi nào là nơi thích hợp cho chúng ta

� Lưu ý vấn đề bản quyền, thương hiệu sáng chế

Tự đánh giá khả năng của chúng ta


� Tự đánh giá khả năng của chúng ta

� Chúng ta có thể làm gì tốt hơn đối thủ cạnh tranh

� Những kiến thức, kỹ năng, ý tưởng mà chúng ta có

10

Nguồn yêu cầu: thị trường

�Khảo sát thị trường

� Phỏng vấn khách hàng (cũ, tiềm năng, …)

� Lưy ý tới những quảng cáo, tạo nhu cầu thị trường

� Quan tâm tới xu hướng phát triển của thị trường


� Quan tâm tới xu hướng phát triển của thị trường

�Vấn đề

� Người ta không biết người ta muốn gì?

� Thị trường thay đổi rất nhanh

� Bảo mật ý tường ???

11

Nguồn các yêu cầu: các chuẩn

� Các chuẩn và các hệ thống chuyển đổi� System standard, file formats, network protocols � Usability standards � Domain standards

� Official standards� written by a standards body


� written by a standards body • ANSI • ISO (e.g. Unicode) • IEEE (e.g. Posix)

� Industry standards � Java, Dot-Net � Wimp user interface � WAMP, LAMP

12

Các loại yêu cầu

� Chức năng� Features� User interface� Input/Output

� Phi chức năng


� Phi chức năng� Hướng người dùng

• Performance, Precision, Reliability

� Hướng người phát triển• Maintainability, Reusability, Interoperability

13

Những vấn đề quản trị yêu cầu

� Nhiều hệ thống thường� Chuyền giao trễ và vượt ngân sách cho phép� Không đáp ứng đầy đủ yêu cầu người dùng� Không hoạt động hiệu quả

� Bước đầu tiên để giải quyết vấn đề


� Bước đầu tiên để giải quyết vấn đề� � xác định nguyên nhân cốt lõi

� Ví dụ về những nguyên nhân cốt lõi� Thiếu dữ liệu người dùng� Yêu cầu đặc tả không đầy đủ� Yêu cầu và đặc tả thay đổi

14

Tăng chi phí do yêu cầu sai hoặc thiếu sót

0.1

0.5

1

Requirements

Design

Coding


2

5

20

15

Tỷ lệ chi phí để sửa chữa theo t ừng giai đoạn

Unit testing

Acceptance - testing

Maintenance

Thế nào là quản trị yêu cầu tốt

�Ngăn:� Vượt chi phí và thời gian� Huỷ dự án

�Một dự án thành công cần các yếu tố:� Sự quan tâm của người dùng


� Sự quan tâm của người dùng� Hỗ trợ của người quản lý� Yêu cầu rõ ràng

16

Chất lượng của yêu cầu: tính ổn định

�Ổn định� Không có mâu thuẫn� Chương trình sẽ không thể hoạt động nếu yêu cầu

mâu thuẫn

�Khó đảm báo vì


� Số lượng yêu cầu lớn� Mâu thuẫn tiềm ẩn

�Bản chất VĐ: mâu thuẫn có thể dẫn đến mọi thứ …�Vấn đề

� Khó giải thích mâu thuẫn cho khách hàng� Khách hàng muốn những thứ không thể

17

Chất lượng yêu cầu: có thể quản lý được

� Tài nguyên phải có thể đáp ứng các yêu cầu� Có thể làm đúng thời gian� Với chi phí cho phép� Trong khả năng (kỹ năng) có thể?

� Quản lý rủi ro� Xếp độ ưu tiên các yêu cầu


� Xếp độ ưu tiên các yêu cầu� Phải có thay thế nếu cái chính không hoạt động� Mở ra những vấn đề không thể để nói đến những yêu cầu có

thể làm

� Quản lý độ phức tạp� Đừng làm mọi thứ cùng một lúc� Qui trình lặp� Prototyping

18

Chất lượng yêu cầu: sự đặc tả

� Càng chính xác và chi tiết càng tốt� Không tốt

� “program shall be fast” � “it takes a number as input”

� Tốt� “program shall give a response in less than 1s”


� “program shall give a response in less than 1s” � “it takes a 16-bit signed integer as input”

� Những định nghĩa� Luôn là những ý tưởng tốt� Vd: “by 'Number', we always mean a 16-bit signed

integer”

� Qui tắc định nghĩa� Không định nghĩa xoay vòng (phụ thuộc)

19

Chất lượng yêu cầu không thiên về cài đặt

� Thiên về cài đặt:� Đưa thông tin thiết kế� Đưa thông tin về mã nguồn

� Sử dụng những thuật ngữ chuyên môn� Không dùng từ ngữ chuyên môn kỹ thuật� Bạn muốn tập trung vài CÁI GÌ


� Bạn muốn tập trung vài CÁI GÌ� Bỏ LÀM THẾ NÀO lại phần sau

� Ví dụ không tốt� “store the checked-out books in an array”� “calculate the square root with Newton's algorithm”

� Ví dụ tốt� •“the library knows which books are checked out”� “return the square root with 5-digit precision”

20

Đội ngũ phát triển phần mềm

�Quản lý yêu cầu đụng đến từng cá nhân

trong đội ngũ phát triển

�Nếu nhóm xác định yêu cầu làm việc tốt


� ảnh hưởng tốt đến kết quả của toàn

nhóm phát triển dự án

21

Những kỹ năng xác định yêu cầu

6 kỹ năng cần thiết

� Phân tích vấn đề

� Hiểu nhu cầu người dùng


� Định nghĩa được hệ thống

� Quản lý được phạm vi

� Tinh lọc được hệ thống

� Xây dựng đúng hệ thống cần thiết22

Kỹ năng làm việc

Cũng cần phải có

�Giao tiếp

�Phân tích và suy nghĩ


�Diễn giải

�Lập báo cáo

�Trình diễn

23

Chi phí cho việc xác định yêu cầu

�Chi phí:

� Chiếm từ 15% đến 30% kinh phí toàn dự án

�Khi bỏ ra càng nhiều thời gian cho công

đoạn xác định yêu cầu, chúng ta sẽ càng


đoạn xác định yêu cầu, chúng ta sẽ càng

tiết thời gian cho:

� Thiết kế

� Triển khai

� Kiểm chứng24

Qui trình lấy yêu cầu

Requirememtseliciation

RequirememtsAnalysis & Negotiation

Requirememtsdocumentation

Requirememtsvalidation


Requirememtsdocument

Systemspecification

User needs domain

information, existing system

information, regulations,

standards, etc.

AgreedRequirements

Phân tích kiến trúc trong ngữ cảnh


Tổng quan về phân tích


Mô hình “4+1 View”


UML trong mô hình 4+1 view

� Use case View: đây là hướng nhìn chỉ ra khía cạnh chức năng của một hệ thống, nhìn từ hướng tác nhân bên ngoài.�Use case Diagrams

� Logical View: chỉ ra chức năng sẽ được thiết kế bên


� Logical View: chỉ ra chức năng sẽ được thiết kế bên trong hệ thống như thế nào�Class Diagrams�Object Diagrams�Package Diagrams�Composite Structure Diagrams�State Machine Diagrams

29


� Process View: chỉ ra sự tồn tại song song/ trùng hợp trong hệ thống, hướng đến vấn đề giao tiếp và đồng bộ hóa trong hệ thống.�Sequence Diagrams�Communication Diagrams�Activity Diagrams


�Activity Diagrams�Timing Diagrams�Interaction Overview Diagrams

30

� Implementation View/ Development View: chỉ rakhía cạnh tổ chức của các thành phần code.�Component Diagrams

� Deployment View/ Physical View: chỉ ra khía cạnh triển khai hệ thống vào các kiến trúc vật lý (các máy tính



triển khai hệ thống vào các kiến trúc vật lý (các máy tính hay trang thiết bị được coi là trạm công tác).�Deployment Diagrams

31

Class Diagram

�Class Diagram là sơ đồ mô tả các lớp, các giao

diện (interface) và các mối liên hệ giữa chúng, cho

ta một khung nhìn tĩnh của các lớp trong mô hình.


Ví dụ


Object & Class

� Class (Lớp)� Là 1 nhóm Object chung thuộc tính và hành vi� Chung mối quan hệ và chung ngữ nghĩa� Là khuôn mẫu để tạo ra đối tượng

� Object (Đối tượng): là thể hiện thực tế của 1


� Object (Đối tượng): là thể hiện thực tế của 1 lớp

Ví dụ: Lớp Sinh viên có thể tạo ra 2 đối tượng làsinh viên A và sinh viên B.

34

Analysis Class

� Bước đầu cho một hệ thống có khả năng thực thi


Tìm các class từ Use Case Behavior

� Toàn bộ hành vi của Use Case phải đượcphân bổ về cho các analysis class


Các Stereotyle của lớp

Trong biểu đồ lớp, stereotype là cơ chế để phân lớp. Có

3 loại lớp phân tích:


Boundary Class

�Là lớp trung gian thể hiện sự tương tác giữa hệthống và những gì bên ngoài hệ thống

�Các lớp biên:� Lớp giao diện giữa người dùng và hệ thống� Lớp giữa hệ thống và các hệ thống bên ngoài


� Lớp giữa hệ thống và các hệ thống bên ngoài• Ví dụ giao dịch với “Hệ thống tài vụ”

� Lớp giữa hệ thống và thiết bị ngoại vi• Ví dụ “Thiết bị giải mã vạch”

�Với mỗi cặp Actor/Use-Case bao giờ cũng có 1 lớp biên

Boundary Class


Mô hình hoá sự tương tác giữa hệ thống và môi trườngbao quanh nó

Entity Class

�Là các lớp mô tả những thực thể chính xuất hiện trong hệ thống

�Thực thể là những thông tin tồn tại và được lưu trữ lâu dài trong hệ thống

�Chỉ mô tả ở mức trừu tượng, không mô tả quá


�Chỉ mô tả ở mức trừu tượng, không mô tả quá chi tiết các thuộc tính của thực thể này

Entity Class


Lưu trữ và quản lý các thông tin trong System

Tìm kiếm Entity Class� Nguồn thông tin có thể tìm Entity Class:

� Các Use case� Các yêu cầu� Nghiên cứu hệ thống tương tự đã có� Sự trợ giúp của các chuyên gia ứng dụng


Tìm kiếm Entity Class

�Sử dụng luồng sự kiện của Use-Case là đầu vào. Lọc các danh từ:� Tìm các mệnh đề danh từ trong luồng sự kiện� Loại bỏ các từ mô tả cụ thể một thuộc tính thông tin

nào đó, nhưng lưu lại để sau này có thể sử dụng cho:• Thuộc tính


• Thuộc tính• Thao tác

� Ngoài ra, cần nghiên cứu:� Các danh từ trong yêu cầu� Kiến thức chuyên ngành thuộc phạm vi bài toán� Xem xét các hệ thống tương tự

Loại bỏ các Entity Class không thích hợp

�Lớp dư thừa: định nghĩa cùng 1 thực thể

�Lớp không thích hợp: không liên quanđến vấn đề hiệntại

�Lớp không rõ ràng: không có chức năng cụ thể

�Cáclớp chỉ vai trò (Roles) đối với 1 lớp kháccũngđược


�Cáclớp chỉ vai trò (Roles) đối với 1 lớp kháccũngđượclọc để giữ lại lớp chính

44

Ví dụ

Xem xét, với ví dụ ATM chúng ta có thể thấy các đối tượng là Entity Class như sau:

� Customers: khách hàng giao dịch là một thực thể có thật và quản lý trong hệ thống.

� Accounts: Tài khoản của khách hàng cũng là một đối tượng thực tế.

� ATM Cards: Thẻ dùng để truy cập ATM cũng được quản lý trong hệ thống.


�

hệ thống.� ATM Transactions: Các giao dịch được lưu giữ lại, nó cũng là một

đối tượng có thật.� Banks: Thông tin ngân hàng bạn đang giao dịch, nếu có nhiều nhà

Bank tham gia vào hệ thống bạn phải quản lý nó. Lúc đó Bank trở thành đối tượng bạn phải quản lý.

� ATM: Thông tin ATM bạn sẽ giao dịch. Nó cũng được quản lý tương tự như Banks.

45

Ví dụ

Ví dụ: Đặc tả uscase đăng ký môn học1. Sinh viên: Đưa vào mật khẩu và tên đăng

nhập2. Hệ thống xác nhận mật khẩu và tên đăng

nhập


nhập3. Sinh viên chọn học kỳ và năm học4. Hệ thống hiển thị các môn học có thể có

trong học kỳXác định các class trong trường hợp này?

46

Lưu ý

�Cần phân biệt giữa khái niệm và thuộctính.

�Ví dụ: Cần xây dựng phần mềm quản lýcác chuyến bay. Đích đến của chuyến bay là thuộc tính của chuyến bay hay một lớp


là thuộc tính của chuyến bay hay một lớpkhác?

47

Control Class

�Được sử dụng để thực hiện một hoặc nhiềuhành động nào đó trong hệ thống�Là lớp thực hiện chức năng chính trong các UC�Với những Use Case phức tạp, có thể có nhiều hơnmột lớp điều khiển


Control Class


Thể hiện hành động, chức năng của từng Use Case

Tóm tắt các Stereotyle của class


Trách nhiệm của các lớp phân tích

�Lớp biên (Boundary Class)� Chịu trách nhiệm thể hiện sự tương tác giữa hệ thống

và tác nhân bên ngoài� Chịu trách nhiệm kiểm tra dữ liệu qua lại trong quá trình

tương tác

�Lớp thực thể (Entity Class)


�Lớp thực thể (Entity Class)� Chịu trách nhiệm quản lý thông tin của nó� Đóng gói thông tin, và thay đổi trạng thái của nó

�Lớp điều khiển (Control Class)� Chịu trách nhiệm chính cho một Use Case nào đó� Tránh để lớp điều khiển làm quá ít việc

Class trong Class Diagram

� Class là thành phần chính của bản vẽ Class Diagram. Class mô tả về một nhóm đối tượng có cùng tính chất, hành động trong hệ thống. Class Name

Attributes

Operations


� Class Name: là tên của lớp.� Attributes (thuộc tính): mô tả tính chất của các đối tượng. Ví

dụ như khách hàng có Mã khách hàng, Tên khách hàng, Địa chỉ, Ngày sinh v.v…

� Operations (thao tác/phương thức): chỉ các hành động mà đối tượng này có thể thực hiện trong hệ thống. Nó thể hiện hành vi của các đối tượng do lớp này tạo ra.

52

Biểu diễn thuộc tính

� Chỉ ra tên, kiểu và giá trị mặc định nếu có

AttributeName : Type = Default

� Tuân theo quy ước đặt tên của ngôn ngữ cài đặt và của

dự án.

Kiểu (type) nên là kiểu dữ liệu cơ bản trong ngôn ngữ


� Kiểu (type) nên là kiểu dữ liệu cơ bản trong ngôn ngữ

thực thi

� Kiểu dữ liệu có sẵn, kiểu dữ liệu người dùng định nghĩa,

hoặc lớp tự định nghĩa.

Ví dụ: CustomerID: int

53

Mô tả phương thức

� Tên phương thức:� Mô tả kết quả� Sử dụng góc nhìn của đối tượng khách (client – đối

tượng gọi)� Nhất quán giữa các lớp


� Nhất quán giữa các lớpOperationName(parameter:type,...):returnType

Ví dụ: GetCustomerName(CustomerID:int): string

54

Gói (Package)

�Một cơ chế chung để tổ chức các phần tử thành nhóm.

�Một phần tử trong mô hình có thể chứa các phần tử

khác.

�Vd: Registration Package


�Vd: Registration Package

55

Phạm vi truy cập (Visibility)

� Phạm vi truy cập được sử dụng để thực hiện khả

năng đóng gói

� Public : + Public access

� Private: - Private access


� Protected: # Protected access

� Package: ~ Package access

56

Phạm vi (Scope)

� Xác định số lượng thể hiện của thuộc tính/thao tác:

– Instance: Một thể hiện cho mỗi thể hiện của mỗi lớp

– Classifier: Một thể hiện chung cho tất cả các thể hiện của

lớp (static)

� Phạm vi Classifier được ký hiệu bằng cách gạch dưới tên


� Phạm vi Classifier được ký hiệu bằng cách gạch dưới tên

thuộc tính/thao tác.

57


Class Diagram -Khung tĩnh cho hệ thống

�Ví dụ


Relationships (Mối quan hệ giữa các lớp)

� Association (Kết hợp) – Bản số và chiều

� Aggregation (Thu nạp): toàn thể và bộ phận

� Composition (Cấu thành)

� Dependency (Phụ thuộc)

Generalization (Tổng quát hóa) Đơn/Đa kế thừa


� Generalization (Tổng quát hóa) Đơn/Đa kế thừa

� Realization (Hiện thực hoá)

60

Association

�Mối liên hệ ngữ nghĩa giữa hai hay nhiều lớp chỉ ra sự

liên kết giữa các thể hiện của chúng

�Mối quan hệ về mặt cấu trúc chỉ ra các đối tượng của

lớp này có kết nối với các đối tượng của lớp khác.


lớp này có kết nối với các đối tượng của lớp khác.

61

Bội số quan hệ (Multiplicity)

� Bội số quan hệ là số lượng thể hiện của một lớp liên

quan tới MỘT thể hiện của lớp khác.

� Với mỗi liên kết, có hai bội số quan hệ cho hai đầu của

liên kết.

– Với mỗi đối tượng của Professor, có nhiều Course


– Với mỗi đối tượng của Professor, có nhiều Course

Offerings có thể được dạy.

– Với mỗi đối tượng của Course Offering, có thể có 1 hoặc

0 Professor giảng dạy.

62

Biểu diễn bội số quan hệ


Ví dụ


Aggregation

� Là một dạng đặc biệt của liên kết mô hình hóa mối quan hệ

toàn thể-bộ phận (whole-part) giữa đối tượng toàn thể và các

bộ phận của nó.

– Thu nạp là mối quan hệ “là một phần” (“is a part-of”).

Bội số quan hệ được biểu diễn giống như các liên kết khác


� Bội số quan hệ được biểu diễn giống như các liên kết khác

65

Ví dụ


Association hay Aggregation


Cấu thành (Composition)

� Một dạng của kết tập với quyền sở hữu mạnh và các

vòng đời trùng khớp giữa hai lớp

– Whole sở hữu Part, tạo và hủy Part.

– Part bị bỏ đi khi Whole bị bỏ, Part không thể tồn tại


nếu Whole không tồn tại.

68

Association, Aggregation and Composition

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

(relationship)

� Liên kết (Association)

• Sử dụng (use-a)

� Thu nạp (Aggregation)


� Thu nạp (Aggregation)

• Strong association

• has-a/is-a-part

� Hợp thành (Composition)

• Strong aggregation

• Share life-time69

Tổng quát hóa (Generalization)

�Mối quan hệ giữa các lớp trong đó một lớp chia sẻ

cấu trúc và/hoặc hành vi với một hoặc nhiều lớp

khác

�Xác định sự phân cấp về mức độ trừu tượng hóa

trong đó lớp con kế thừa từ một hoặc nhiều lớp


trong đó lớp con kế thừa từ một hoặc nhiều lớp

cha

– Đơn kế thừa (Single inheritance)

– Đa kế thừa (Multiple inheritance)

� Là mối liên hệ “là một loại” (“is a kind of”)

70

Abstract and Concrete Class

�Lớp trừu tượng không thể có đối tượng� Chứa phương thức trừu tượng� Chữ nghiêng

�Lớp cụ thể có thể có đối tượng


Đơn kế thừa

� Một lớp kế thừa từ MỘT lớp khác


Đa kế thừa

�Một lớp có thể kế thừa từ nhiều lớp khác�Sử dụng đa kế thừa khi cần thiết và cẩn thận khi

sử dụng vì có thể dẫn đến nhiều rắc rối, phứctạp.


Đa kế thừa

� Phụ thuộc vào ngôn ngữ lập trình

Xung đột về tên trêncác thuộc tính hoặc phương thức

Kế thừa lặp lại


Đa hình (Polymorphism)

�Khả năng che giấu các thực thi khác nhau dưới

một giao diện duy nhất.


Ví dụ


Ví dụ


Xây dựng Class Diagram cần chú ý� Quản lý sự toàn vẹn (xét theo trình tự)

� Dư thừa trách nhiệm giữa các lớp� Các trách nhiệm bị tách rời giữa các lớp� Lóp chỉ có 1 trách nhiệm� Lớp không có trách nhiệm� Sự phân tán các hành vi


� Sự phân tán các hành vi� Lớp có quá nhiều tương tác với các lớp khác

78

Checkpoints: Analysis Classes

�Các class có hợp lý không?�Tên của các class có phản ánh đúng vai trò của

chúng?�Class có biểu diễn 1 single well-defined

abstraction?


�Tất cả các attribute và responsibility có gắn kếtvới nhau về mặt chức năng không?

�Class có cung cấp các hành vi được yêu cầu?�Tất cả các yêu cầu cụ thể đã được thể hiện trên

class chưa?

79

Tham khảo

�Tham khảo: GeekCorps 2004

� IBM - RUP

� Introduction to Rational Rose 98i


� Bài giảng: Công cụ và môi trường phát triển

phần mềm – ĐHKHTN

� Bài giảng: OOLT, Ms.Trang, Vietnam &

Japan Joint ICT HRD Program.80

Thực hànhThực hành

81

Thực hành

� Làm việc với công cụ Rational Rose

� Làm bài tập theo mẫu

� 5 – Business.Vision.pdf


� 6 - Business.Glossary.pdf

� Xác định Class

� Thực hành vẽ Class Diagram

82

Lập biểu đồ lớp

� Giúp người phát triển

quan sát, lập kế hoạch

cấu trúc hệ thống trước

khi viết code


� Trong Rose

� Hình thành trong

Logical View

83

Documents

Mô hình hóa đối tượng - nhuloan.weebly.comnhuloan.weebly.com/uploads/4/5/3/6/45363345/lecture04.pdf · Nộidung trước Mô hình hóa yêu cầu: Lược đồ Use-case