+ Hệ thống ñược chia thành các thành phần nhỏ gọi là các ñối tượng, mỗi ñối tượng bao gồm ñầy ñủ cả dữ liệu và hành ñộng liên quan ñến ñối tượng ñó.. + Các ñối tượng trong một hệ thống t
Trang 3- 18/09/2010 - - Hoa Sen University - 3
-1 Tổng quan
OOP ( Object-Oriented Programming ) là kỹ thuật lập trình hỗ trợ công nghệ ñối tượng lấy ñối tượng làm nền tảng.
lập trình cấu trúc và sự trừu tượng hóa dữ liệu.
Trang 41 Tổng quan
Ưu ñiểm:
quan ñến nhiều lớp (các bài toán thực tế hay gặp phải)
mã chương trình có thể nằm lẫn lộn, rải rác và khó quản lý AOP (Aspect-Oriented Programming).
Trang 5- 18/09/2010 - - Hoa Sen University - 5
-2 Lớp và ñối tượng
ñể tạo ra các ñối tượng.
hành vi, trạng thái chung của một số ñối tượng.
Trang 7- 18/09/2010 - - Hoa Sen University - 7
-ðối tượng
ðối tượng = dữ liệu + hành vi của dữ liệu.
Các thuật ngữ khác:
(properties) = Thuộc tính (attributes) = Biến (variables) = Thông tin (informations) = ðặc
ñiểm (characteristics) = …
(methods) = Thao tác (operations) = Hàm (functions) = …
Trang 8ðối tượng
của nó chứa các thao tác ñể thực hiện hành vi nào ñó.
Trang 9- 18/09/2010 - - Hoa Sen University - 9
-3 Các tính chất cơ bản
Trang 10Tính ñóng gói
hành vi trên dữ liệu thành một khối
thống nhất ñối tượng.
tượng thay ñổi trực tiếp trạng thái nội
tại của một ñối tượng, chỉ có các
phương thức nội tại của ñối tượng mới
cho phép thay ñổi trạng thái của nó
(accessor methods) ñảm bảo sự
toàn vẹn dữ liệu của ñối tượng.
hành vi.
Trang 11- 18/09/2010 - - Hoa Sen University - 11
ñối tượng khác ñã có, thông qua việc kế thừa dễ dàng
chia sẻ hay mở rộng các ñặc tính có sẵn mà không phải tiến hành ñịnh nghĩa lại.
Trang 13- 18/09/2010 - - Hoa Sen University - 13
Trang 14Xảy ra trên một lớp.
Có nhiều phương thức cùng tên nhưng
khác tham số truyền vào khi ñược gọi, dựa vào tham số truyền vào, phương thức tương ứng sẽ ñược thực thi.
Khác tham số truyền vào:
Trang 15- 18/09/2010 - - Hoa Sen University - 15
-Overriding
giống như phương thức của lớp Cha,
nhưng ñược cài ñặt khác lúc thực thi,
nếu lớp Con không có phương thức riêng,
phương thức của lớp Cha sẽ ñược gọi,
ngược lại nếu có, phương thức của lớp
Con ñược gọi.
Trang 16Late binding
thức của ñối tượng, nhưng chưa xác ñịnh ñối tượng muốn gọi là ñối tượng nào ñến khi thực hiện, chương trình mới xác ñịnh cụ thể ñối tượng và gọi phương thức tương ứng
của ñối tượng ñó.
tượng cung cấp ñúng prototype của phương thức cần thiết
là ñủ.
Trang 17- 18/09/2010 - - Hoa Sen University - 17
-4 Interface
trừu tượng.
(pure abstract) chỉ chứa các phương thức trừu tượng.
Trang 184 Interface
kế mang lại 1 lớp có thể cài ñặt nhiều giao diện bổ
sung cho tính chất ñơn thừa kế trong C# || Java.
phương thức mà interface ñịnh nghĩa.
Trang 19- 18/09/2010 - - Hoa Sen University - 19
-Q&A
Trang 20-Inception
1 Mô tả dự án:
- Progress: Trả lời các câu hỏi?
+ Tầm nhìn (vision) và khả năng kinh doanh của dự án như thế nào ?
+ Tính khả thi ?
+ Mua hay xây dựng ?
+ Ước lượng chi phí ?
- Có 2 loại: (Functional, Usability, Reliability, Performance, Supportability)
+ Chức năng (functional): là yêu cầu có liên quan trực tiếp ñến hoạt ñộng mà hệ thống phải làm hoặc thông tin mà hệ thống lưu trữ
+ Phi chức năng (nonfunctional): là các yêu cầu về tính chất hoặc thuộc tính mà hệ thống phải
có như khả năng hoạt ñộng, khả năng sử dụng,
- Các kỹ thuật thu thập yêu cầu:
+ Phỏng vấn (interview): 4 bước
Chọn người ñược phỏng vấn
Thiết kế câu hỏi phỏng vấn
Thực hiện phỏng vấn
Thực hiện công việc sau phỏng vấn
+ ðiều tra (questionnaire): 4 bước
Lựa chọn nhóm ñối tượng ñiều tra
Thiết kế câu hỏi ñiều tra
Thực hiện ñiều tra
Tổng kết, thống kê, phân tích kết quả ñiều tra
+ Quan sát (observation):
Quan sát chi tiết các bước nghiệp vụ của khách hàng
Cẩn thận trước những thao tác không thường xuyên
+ Phân tích tài liệu (document analysis):
Phân loại các tài liệu ñược cung cấp (tài liệu báo cáo, tài liệu mô tả hệ thống, tài liệu qui trình nghiệp vụ, …)
Trang 21Created by Trang Hồng Sơn -
- 2 - ðọc kỹ các tài liệu ñược cung cấp rút trích thông tin quan trọng
- Output: Software Requirements Specification
Trang 22+ Nhằm trả lời cho câu hỏi “what”
Xác ñịnh các ñặc trưng mà hệ thống cần phải xây dựng là gì, chỉ ra các khái niệm liên quan và ñưa ra hướng giải quyết bài toán
- Design:
+ Nhằm trả lời cho câu hỏi “how”
Xác ñịnh hệ thống sẽ ñược xây dựng như thế nào dựa trên kết quả của việc phân tích, ñưa ra các phần tử hỗ trợ giúp tạo nên một hệ thống hoạt ñộng thực sự
1.2 Các phương pháp phân tích thiết kế:
- SOAD:
+ Phân rã (breaks down) bài toán thành các bài toán nhỏ hơn, rồi tiếp tục phân rã các bài toán con cho ñến khi nhận ñược các bài toán có thể cài ñặt ñược
+ Ưu ñiểm:
Tư duy phân tích thiết kế rõ ràng
Chương trình sáng sủa dễ hiểu
+ Khuyết ñiểm:
Không hỗ trợ việc sử dụng lại
Không phù hợp cho phát triển các phần mềm lớn
- OOAD:
+ Ánh xạ các thành phần trong bài toán vào các ñối tượng ngoài ñời thực
+ Hệ thống ñược chia thành các thành phần nhỏ gọi là các ñối tượng, mỗi ñối tượng bao gồm ñầy ñủ cả dữ liệu và hành ñộng liên quan ñến ñối tượng ñó
+ Các ñối tượng trong một hệ thống tương ñối ñộc lập với nhau và phần mềm sẽ ñược xây dựng bằng cách kết hợp các ñối tượng ñó lại với nhau thông qua các mối quan hệ và tương tác giữa chúng
+ Ưu ñiểm:
Hỗ trợ sử dụng lại mã nguồn
Phù hợp với các hệ thống lớn
Trang 23Created by Trang Hồng Sơn -
- 2 -
- Case study:
+ Bài toán:
GV tổ chức buổi seminar cho SV tham dự
Buổi seminar kết thúc thì SV phải trở về lớp học của mình
SV ko biết ñược vị trí của lớp học của mình ở ñâu
GV phải chỉ cho SV biết cách trở về lớp học của từng SV
+ Cách giải quyết 1 (SOAD):
GV lấy danh sách SV tham dự buổi seminar
ðối với mỗi SV, GV làm các bước sau:
+ Cách giải quyết 2 (OOAD):
Dán sơ ñồ lớp học ở cuối phòng và thông báo với SV ñể SV xem sơ ñồ lớp học
SV tự tìm cách ñể trở về lớp học của mình
Trách nhiệm ở GV và SV
+ Yêu cầu mở rộng thêm: ñối tượng SV tham dự bao gồm SV ñang học và cựu SV
Cách giải quyết 1:
- ðối với mỗi SV, GV phải kiểm tra là SV ñang học hay là cựu SV
- Nếu SV ñang học thì làm theo bước trên
- Nếu là cựu SV thì hướng dẫn SV ra khỏi trường
Cách giải quyết 2:
- Thêm sơ ñồ ra khỏi trường
Cách giải quyết 2 sẽ hiệu quả hơn
1.3 Các qui trình phát triển phần mềm (Software Development Process):
- Waterfall (thác nước):
+ Các pha liên tiếp từ phân tích yêu cầu, thiết kế hệ thống, phát triển hệ thống ñến thử nghiệm và triển khai hệ thống
+ Pha sau chỉ ñược bắt ñầu khi pha trước ñã hoàn thành
- Iterative and Evolutionary (lặp và tăng dần):
+ ði qua các bước phân tích, thiết kế, phát triển, kiểm tra và triển khai phần mềm theo từng bước nhỏ nhiều lần
Trang 24- Ví dụ: Trò chơi ñổ 2 xí ngầu có kịch bản như sau: người chơi lắc 2 xí ngầu, nếu tổng ñiểm
> 7 thì thắng, ngược lại thì thua
Trang 25Created by Trang Hồng Sơn -
- 4 -
2.4 Class Diagrams:
- Sơ ñồ biểu thị tất cả các thông tin và hành vi của ñối tượng và mối quan hệ giữa chúng
- Ví dụ:
Trang 26-Use Case
1 Tổng quan:
1.1 ðịnh nghĩa:
- Scenario: mô tả một chuỗi các sự kiện mà một người hay một hệ thống khác kích hoạt vào
hệ thống ñang phát triển theo tuần tự thời gian
- Actor: biểu diễn người hoặc hệ thống khác tương tác với hệ thống ñang phát triển
- Use Case: là tập hợp của một loạt các Scenario liên quan ñến việc sử dụng hệ thống theo một cách thức nào ñó
- Use Case Diagram: ñược biểu diễn một cách trực quan, chỉ ra mối quan hệ giữa các Actor
và các Use Case trong hệ thống
1.2 Vai trò:
- Trong qui trình phát triển phần mềm:
- Trong nhóm người phát triển phần mềm:
1.3 Các mối quan hệ:
- Quan hệ giao tiếp (association):
Trang 27Created by Trang Hồng Sơn -
- 2 -
+ Giữa Actor và Use Case: cho biết có một kết hợp giữa một Actor và một Use Case
- Quan hệ bao gộp (include):
+ Giữa các Use Case: cho biết một Use Case “phải” ñược sử dụng bởi một Use Case khác
- Quan hệ tổng quát hoá (generalization):
+ Giữa các Actor: sử dụng khi nhiều Actor có chung một số thuộc tính và hành vi nào ñó Actor không có thể hiện (instance) gọi là Actor trừu tượng
Trang 28-2 Các bước xây dựng:
2.1 Xác ñịnh Actor: bằng cách tìm kiếm các “danh từ” chung chỉ người hay hệ thống từ các tài liệu nguồn, trả lời các câu hỏi sau:
- Ai là người dùng hệ thống này ñể nhập thông tin ?
- Ai là người dùng hệ thống này ñể nhận thông tin ?
- Các hệ thống khác nào tương tác với hệ thống này ?
2.2 Xác ñịnh Use Case: cần tìm kiếm các sự kiện của hệ thống, bằng cách tìm kiếm các
“ñộng từ” từ các tài liệu nguồn, trả lời các câu hỏi sau:
- Tác nhân yêu cầu hệ thống làm gì ?
- Tác nhân cần lưu trữ, ñọc, sửa, xóa các thông tin nào trong hệ thống ?
- Có cần thông báo cho tác nhân về sự kiện xảy ra trong hệ thống ? Có cần tác nhân thông báo cái gì ñó cho hệ thống ?
- Thông tin input / output hệ thống từ hệ thống bên ngoài ?
2.3 Xác ñịnh Use Case tổng quát:
- Từ tập tác nhân và Use Case ñã ñược xác ñịnh ở bước trước, cần tìm ra các chức năng
chính của hệ thống Các chức năng này phải có tính tổng quát, dễ dàng nhìn thấy ñược trên quan ñiểm của các tác nhân
- Các dạng quan hệ thường dùng trong sơ ñồ Use Case mức tổng quát là quan hệ giao tiếp (association), quan hệ tổng quát hóa (generalization) và quan hệ bao gộp (include)
2.4 Phân rã Use Case:
- Tiến hành phân rã Use Case tổng quát thành các Use Case cụ thể hơn sử dụng quan hệ mở rộng (extend)
- Các Use Case con (mức thấp) ñược lựa chọn bằng cách thêm vào Use Case cha một chức năng cụ thể nào ñó và thường ñược mở rộng dựa trên cơ sở sự chuyển tiếp và phân rã các chức năng của hệ thống
2.5 ðặc tả biểu ñồ Use Case:
Trang 29Created by Trang Hồng Sơn -
- 4 -
Tiền ñiều kiện Những ñiều kiện phải có trước khi tác ñộng lên Use Case
ðảm bảo thành công Hệ thống sẽ làm gì khi Use Case thực hiện thành công
Chuỗi sự kiện chính 1 Tác nhân làm gì ?
2 Hệ thống phản ứng ra sao ?
3 Tác nhân làm gì ?
4 Hệ thống phản ứng ra sao ?
ñó trong chuỗi sự kiện chính (nếu có)
3 Case study “Hệ thống thư viện ñiện tử”:
Thống kê thông tin bạn ñọc
Thống kê thông tin sách mượn
3.3 Xác ñịnh Use Case tổng quát:
Trang 30-3.4 Phân rã Use Case:
- Phân rã Use Case “Quản lý thông tin sách”:
- Phân rã Use Case “Thống kê”:
Trang 31Created by Trang Hồng Sơn -
- 6 -
3.5 ðặc tả biểu ñồ Use Case:
- ðặc tả Use Case “ðăng nhập”:
ðảm bảo thành công Chuyển ñến trang chủ quản lý của thủ thư
Chuỗi sự kiện chính 1 Thủ thư nhập username và password
2 Thủ thư nhấn nút “ðăng nhập”
3 Hệ thống kiểm tra thông tin ñăng nhập
4 Hệ thống chuyển ñến trang quản lý của thủ thư
- ðặc tả Use Case “Thêm sách”:
Chuỗi sự kiện chính 1 Hệ thống hiển thị form thêm sách và yêu cầu thủ thư ñưa
vào thông tin sách
2 Thủ thư nhập thông tin về sách mới và nhấn nút “Thêm sách”
3 Hệ thống kiểm tra thông tin sách và xác nhận thông tin sách hợp lệ
4 Hệ thống thêm thông tin sách mới vào CSDL
5 Hệ thống thông báo ñã nhập thành công
6 Thủ thư thoát khỏi chức năng thêm sách
Trang 321 Hệ thống hỏi thủ thư có thêm số lượng sách hay không
2 Thủ thư thêm số lượng sách
3 Hệ thống thêm số lượng cho sách ñã có
4 Hệ thống thông báo nhập thành công 3b Hệ thống thông báo thông tin sách không hợp lệ
1 Hệ thống yêu cầu thủ thư nhập lại thông tin
2 Thủ thư nhập lại thông tin sách
Trang 33Created by Trang Hồng Sơn -
+ Mô tả hướng nhìn tĩnh của một hệ thống bằng các khái niệm lớp và mối liên hệ giữa chúng với nhau
+ Mục ñích là tạo nền tảng cho các biểu ñồ khác, thể hiện các khía cạnh khác của hệ thống (ví
dụ như trạng thái của ñối tượng hay cộng tác ñộng giữa các ñối tượng, ñược chỉ ra trong các biểu ñồ ñộng)
- Cung cấp 3 thông tin:
+ Các lớp (Conceptual classes hoặc Domain objects)
+ Các mối liên hệ giữa các lớp
+ Các thuộc tính của các lớp
Register
Item
Store address name
Sale date time
Payment amount
Sales LineItem quantity
Stocked-in
*
Houses 1 *
Contained-in
1 *
Records-sale-of 0 1
Paid-by
1 1 1
1 1
1
0 1
1 Captured-on 4
concept
or domain object
- Loại bỏ các lớp ứng cử viên không thích hợp:
+ Lớp dư thừa: do có hai hay nhiều danh từ cùng chỉ một thực thể nên ta chỉ cần giữ lại một từ duy nhất và loại bỏ các từ khác
+ Danh từ không thích hợp: ñó là các danh từ không liên quan ñến phạm vi của bài toán + Danh từ mô tả những lớp không rõ ràng: ñó là các danh từ hoặc không biểu diễn một thực thể cụ thể hoặc các khái niệm không rõ nghĩa
+ Các danh từ chỉ là một vai trò (role) trong mối liên hệ với một lớp khác
Trang 34-+ Các danh từ biểu diễn các công cụ xây dựng phần mềm hoặc các thuật ngữ trong lập trình hay thuật toán (ví dụ stack, list, array, …)
2.2 Xác ñịnh các mối liên hệ giữa các lớp:
- Liên hệ là một sự nối kết giữa các lớp, một liên quan về ngữ nghĩa giữa các ñối tượng của các lớp tham gia Liên hệ thường thường mang tính hai chiều, có nghĩa khi một ñối tượng này có liên
hệ với một ñối tượng khác thì cả hai ñối tượng này nhận thấy nhau
+ Những thông tin nào là thông tin riêng của lớp (các thuộc tính private), những thông tin nào có thể chia sẻ trong mối liên hệ với lớp khác (các thuộc tính protected hoặc public)
3 Case study “Hệ thống thư viện ñiện tử”:
3.2 Xác ñịnh mối liên hệ giữa các lớp:
- 1 bạn ñọc có 1 thẻ mượn (1 thẻ mượn thuộc về 1 bạn ñọc)
- 1 thẻ mượn mượn ñược nhiều sách
- 1 thủ thư ghi thông tin lên nhiều thẻ mượn
3.3 Xác ñịnh thuộc tính các lớp:
- Bạn ñọc: maBandoc, tenBandoc, diachiBandoc, …
- Thủ thư: maThuthu, tenThuthu, matkhau, …
Trang 35Created by Trang Hồng Sơn -
- 3 -
- Sách: maSach, tenSach, tacGia, nhaXB, namXB, mota, soluong, …
- Thẻ mượn: maThemuon, maBandoc, maThuthu, dsMasach, ngaytraDukien, ngaytraThucthe, tinhtrang, …
Bandoc
maBandoc tenBandoc diachiBandoc
Thuthu
maThuthu tenThuthu matkhau
Sach
maSach tenSach tacGia nhaXB namXB mota soluong
Themuon
maThemuon maBandoc maThuthu dsMasach ngaytraDukien ngaytraThucte tinhtrang
1
1
1 1
Trang 36-SYSTEM SEQUENCE DIAGRAM
1 Tổng quan:
- System Sequence Diagram (SSD):
+ Là sơ ñồ tuần tự chuỗi sự kiện trong Use Case, biểu diễn các sự kiện tương tác (tác ñộng và phản hồi) của Actor bên ngoài và hệ thống bên trong (ñược xem như black-box)
+ SSD bao gồm:
Các Actor bên ngoài và hệ thống bên trong
Các yêu cầu tác ñộng của Actor vào hệ thống
Các kết quả trả về tương ứng (nếu có) của hệ thống
Các ñoạn lặp có thể có trong quá trình tương tác giữa Actor và hệ thống
: Cashier :System
Simple cash-only Process Sale scenario:
1 Customer arrives at a POS checkout
with goods and/or services to purchase.
2 Cashier starts a new sale.
3 Cashier enters item identifier.
4 System records sale line item and
presents item description, price, and
6 Cashier tells Customer the total, and
asks for payment.
7 Customer pays and System handles
total with taxes
change due, receipt
Trang 37Created by Trang Hồng Sơn -
- 2 -
enterItem(itemID, quantity)
:System : Cashier
Process Sale Scenario
system as black box the name could be "NextGenPOS" but "System" keeps it simple
the ":" and underline imply an instance, and are explained in a later chapter on sequence diagram notation in the UML
a message with parameters
it is an abstraction representing the system event of entering the payment data by some mechanism
total with taxes
change due, receipt
total with taxes
change due, receipt
makeNewSale()
these input system events invoke system operations
the system event enterItem
invokes a system operation called enterItem and so forth this is the same as in object- oriented programming when
we say the message foo invokes the method (handling operation) foo
[ more items ]
loop
:System Process Sale Scenario
Trang 38- Operation Contract: ñặc tả các System Operations
Operation:
enterItem(…) Post-conditions:
- Operation Contracts
Sale date
Sales LineItem quantity
1 *
Domain Model
Use-Case Model
Design Model : Register
enterItem (itemID, quantity)
Require-Business Modeling
Design
Sample UP Artifact Relationships
: System
enterItem (id, quantity) Use Case Text
System Sequence Diagrams
make NewSale()
system events
Cashier
Process Sale
: Cashier
use case names
system operations
Use Case Diagram
Vision
Supplementary Specification Glossary
2 .
3 Cashier enters item identifier.
ideas for the post- conditions
Tên thao tác (Operation Name) Tên thao tác và các tham số (nếu có)
Tham chiếu (Cross References) Tên Use Case chứa thao tác
Tiền ñiều kiện (Preconditions) Những ñiều kiện giả ñịnh phải có trước khi thực hiện thao tác Hậu ñiều kiện (Postconditions) Trạng thái của ñối tượng sau khi thực hiện xong thao tác
+ Ví dụ:
Cross References UC: Process Sale
Trang 39Created by Trang Hồng Sơn -
- 4 -
Postconditions - A Sale instance “s” was created (instance creation)
- “s” was associated with a Register (association formed)
- Attributes of “s” were initialized
Operation Name enterItem(itemID: ItemID, quantity: integer)
Cross References UC: Process Sale
Postconditions - A SalesLineItem instance “sli” was created (instance creation)
- “sli” was associated with the current Sale (association formed)
- “sli.quantity” became quantity (attribute modification)
- “sli” was associated with a ProductDescription, based on itemID match (association formed)
2 Các bước xây dựng:
- Chọn Use Case
- Biểu diễn chuỗi các sự kiện tương tác
- Xác ñịnh các System Operation
- ðặc tả các System Operation Operation Contract
3 Case study “Hệ thống thư viện ñiện tử”:
- Use Case “ðăng nhập”:
ðảm bảo thành công Chuyển ñến trang chủ quản lý của thủ thư
Chuỗi sự kiện chính 1 Thủ thư chọn chức năng ñăng nhập
2 Hệ thống hiển thị form ñăng nhập và yêu cầu thủ thư nhập username, password
3 Thủ thư nhập username, password và nhấn nút “ðăng nhập”
4 Hệ thống kiểm tra thông tin ñăng nhập
5 Hệ thống chuyển ñến trang quản lý của thủ thư