bài số 3 tổng quan về ooad

Tầm quan trọng của OOAD Nhiều người phát triển dự án  Cho rằng phần mềm chủ yếu được xây dựng bằng cách gõ “code” từ bàn phím  Không dành đủ thời gian cho quá trình phân tích và thiế

Trang 1

OBJECT-ORIENTED ANALYSIS AND DESIGN WITH UML 2.0

Trang 3

1.1 Tầm quan trọng của OOAD

Nhiều người phát triển dự án

 Cho rằng phần mềm chủ yếu được xây dựng bằng

cách gõ “code” từ bàn phím

 Không dành đủ thời gian cho quá trình phân tích và

thiết kế phần mềm

 Họ phải “cày bừa” để hoàn thành chương trình vì

 Không hiểu hoặc hiểu sai yêu cầu

 Giao tiếp với các thành viên không tốt

 Không tích hợp được với module của đồng nghiệp…

 Họ nhận ra rằng “Phân tích” và “Thiết kế” cần

được coi trọng hơn, nhưng đã quá muộn

Trang 4

1.1 Tầm quan trọng của OOAD (2)

Cần thiết lập một cơ chế hiệu quả để nắm

bắt yêu cầu, phân tích thiết kế

Cơ chế này phải như là một “ngôn ngữ

thống nhất” giúp cho quá trình hợp tác

hiệu quả giữa các thành viên trong nhóm

phát triển phần mềm.

 OOAD

Trang 5

1.2 Mục đích của OOAD

Chuyển các yêu cầu của bài toán thành một bản

thiết kế của hệ thống sẽ được xây dựng

Tập trung vào quá trình phân tích các YÊU CẦU

của hệ thống và thiết kế các MÔ HÌNH cho hệ

thống đó trước giai đoạn lập trình

Được thực hiện nhằm đảm bảo mục đích và yêu cầu của hệ thống được ghi lại một cách hợp lý

trước khi hệ thống được xây dựng

Trang 6

1.2 Mục đích của OOAD (2)

Cung cấp cho người dùng, khách hàng, kỹ sư

phân tích, thiết kế nhiều cái nhìn khác nhau về

 Ở mức chi tiết, thiết kế sẽ phụ thuộc vào nền tảng,

ngôn ngữ lập trình, hay cơ sở dữ liệu.

Trang 8

2 Phương pháp OOAD

OOAD được chia thành 2 giai đoạn

OOA là giai đoạn nhằm tạo ra các mô

hình cơ bản (mô hình khái niệm) của hệ

thống dựa theo những gì khách hàng yêu

cầu về hệ thống của họ

OOD sẽ bổ sung thêm các thông tin thiết

kế chi tiết cho các mô hình nói trên

Trang 9

Mô hình Phân tích

Phân tích tập trung vào việc trừu tượng hóa các

vấn đề nghiệp vụ

Xây dựng mô hình bằng cách tìm kiếm các lớp,

các đối tượng chính có trong hệ thống

 Các lớp, đối tượng này chỉ là những khái niệm nghiệp

vụ cơ bản nhằm tìm hiểu hệ thống

 Tránh cung cấp các khái niệm, thông tin cài đặt quá

chi tiết (cho dù có thể đã tìm được tại thời điểm đó)

Trang 10

 Chỉ rõ hành động và thuộc tính của các đối tượng

Đơn giản hoá của việc phát triển mã nguồn

 Ví dụ như thuật toán, sơ đồ khối…

Thể hiện được bản thiết kế mã nguồn sẽ được

cấu trúc và phát triển như thế nào

Trang 11

Các bước trong OOAD

1 Mô hình hóa yêu cầu sử dụng UC

(Requirement modeling using UC)

2 Phân tích use case

(Use case analysis)

3 Xác định phần tử thiết kế và

6 Thiết kế đặc tả ngoài (External Specification Design)

4 Thiết kế lớp (Class design)

7 Thiết kế trường hợp kiểm thử

(Test case design)

Trang 12

1 Mô hình hóa yêu cầu sử dụng UC

(Requirement modeling using UC)

(Use case analysis)

(Test case design)

Mô hình hóa yêu cầu người dùng thành các biểu đồ use case, đặc

tả use case, biểu đồ hoạt động

Trang 13

2 Phân tích use case

(Use case analysis)

(Test case design)

Tìm các lớp phân tích và xây dựng các biểu đồ tương tác

Trang 14

(Use case analysis)

4 Thiết kế lớp

(Test case design)

Ánh xạ các phần tử thiết kế từ các lớp phân tích và thiết kế UC

Trang 15

(Use case analysis)

4 Thiết kế lớp (Class design)

(Test case design)

Tinh chỉnh các lớp phân tích để thiết kế lớp và tạo biểu đồ lớp

Trang 16

(Use case analysis)

(Test case design)

thành mô hình thực thể liên kết

- Chuẩn hóa mô hình thực thể liên kết

thành dạng chuẩn 3 để thiết kế CSDL

Trang 17

(Use case analysis)

6 Thiết kế đặc tả ngoài (External Specification Design)

(Test case design)

Thiết kế biểu đồ chuyển đổi giữa các

giao diện người dùng và thiết kế chi tiết

các giao diện ấy

Trang 18

(Use case analysis)

7 Thiết kế trường hợp kiểm thử

(Test case design)

Thiết kế trường hợp kiểm thử dựa trên các use case đã phân tích và thiết kế

Trang 19

Chương 2 Tổng quan về phân tích

thiết kế hướng đối tượng

Trang 20

3 Case study Case study mẫu: Course Registration

Case study bài tập: Library System

Trang 21

Course Registration CS

The system manages course registration in

university It manages course information for

semesters of past one year and next semester

Course registration can be done for only next

semester Course information for past one year

is only for viewing

Registrars, lecturers, and students have to login

to use the system After completing their work,

they can log out the system because of security

Admistrators can manage users in the system

(including search, add, delete and update)

Trang 22

Registrars manage course information through

registrar GUI Registrars add, delete, and update basic information of courses for preparing

course information of the next semester

Information about each course, such as

lecturers, department and prerequisites will be

included to help students make informed

decisions A course will have a maximum of 30

students and minimum 3 students

Trang 23

After completion of preparation for all course

information of the next semester, registrars open course information to students for registration

After that, students can register for courses

At the end of course registration period,

registrars close course registration After closing

course registration, students cannot register nor

cancel registration

A course with fewer than 3 students will be

canceled If a course is canceled, system must

notifies students who registered the course

about this cancellation

Trang 24

Lecturers make input and update detail of

course information of corresponding

course through lecturer GUI.

Registrars and lecturers can view lists of

students who registered for courses after

registration period

 Registrars can view all lists

 Lecturers can view only lists for corresponding courses

Trang 25

Students make registration for courses

through student GUI

 Students browse course list for the next

semester and register for the course after

choosing it

 If the course to be registered is full or its time

is the same as the course he/she has

registered or he/she does not satisty the

prerequisites, the student must be notified

Trang 26

Students can view the list of own

registration courses.

Students can cancel course registration

from registration list GUI.

Registrars, lecturers, students can view

course list for all semesters and search

course information using keyword

Trang 27

Multiple users must be able to perform

their work concurrently The system shall

support up to 500 simultaneous users at

any one time.

The system shall be available 24 hours a

day, 7 days a week, with no more than

10% down time.

Trang 29

4 Công cụ UML

Xem chi tiết trên:

Định dạng
Số trang	29
Dung lượng	1,71 MB