Xem mẫu
- TRƯỜNG ĐẠI HỌC CÔNG NGHỆ THÔNG TIN
KHOA CÔNG NGHỆ PHẦN MỀM
LỚP SE101.E11
---- ----
Đề tài: PHÂN TÍCH PHẦN MỀM VỚI UML
GVHD: NGUYỄN CÔNG HOAN
SVTH:
Lăng Hoài Sang 11520327
Vũ Văn Thuận 11520396
Huỳnh Hồ Thị Mộng Trinh 11520431
- 1. Mở đầu:
Trong quá xây dựng, đối với một căn nhà nhỏ thì chúng ta có thể bắt đầu vào
xây dựng ngay, chúng ta có thể tự mình xây chúng. Nhưng đối với một căn
nhà to: nhà lầu, vila, biệt thự…, trong quá trình xây dựng cần sự hợp tác của
nhiều người, có mối quan hệ giữ kĩ sư – thầu – chủ nhà, để mối giao tiếp đó
diễn ra dễ dàng ta cần có bản thiết kế.
Trong lĩnh vực phần mềm cũng vậy, phần mềm càng lớn càng phức tạp thì
việc xây dựng mô hình càng quan trọng. Xây dựng mô hình cho phép người
thiết kế thấy được bức tranh tổng quan của phần mềm, thấy được các tương
tác giữa người dùng và phần mềm, thành phần của phần mềm tương tác với
nhau. Để hỗ trợ cho việc đó, người ta sử dụng một ngôn ngữ mô hình hóa đó
chính là UML.
Trong đề tài “UML trong phân tích thiết kế phần mềm”, chúng em xin giới
thiệu về ngôn ngữ UML và vai trò của nó trong việc phân tích thiết kế phần
mềm. Trong quá trình xây dựng phần mềm quản lí thư viện, chúng ta sử dụng
UML như thế nào? Một số biểu đồ thường dùng sẽ được giới thiệu thông
qua việc phân tích cụ thể một nhánh của quá trình.
Ngoài những vấn đề trên chúng xin giới thiệu một mô hình đã ứng dụng thành
công UML vào việc phân tích thiết kế phần mềm. Đó là RUP.
2. UML và ứng dụng của UML trong phân tích thiết kế phần mềm:
3. Sơ lượt về UML:
- UML là ngôn ngữ chuẩn công nghiệp được dùng chủ yếu trong lĩnh
vực khoa học máy tính và công nghệ phần mềm.
- UML là ngôn ngữ trực quan (tức là sử dụng các biểu tượng để mô tả
các vấn đề và công việc) được dùng trong pha phân tích và pha thiết kế
trong quy trình xây dựng một phần mềm hướng đối tượng.
- UML là ngôn ngữ kí hiệu bao gồm hệ thống các kí hiệu và bộ các
nguyên tắc để kết hợp các kí hiệu đó với nhau để mô tả thiết kế phục
vụ cho vấn đề giao tiếp.
- UML cho ta biết cách tạo ra và đọc hiểu một mô hình, nhưng UML
không cho ta biết những mô hình nào nên tạo ra và khi nào tạo ra chúng.
Đó là nhiệm vụ của qui trình phát triển phần mềm.
- Lợi ích của việc sử dụng UML trong quá trình phân tích thiết kế phần
mềm:
• UML cung cấp giao diện đồ họa trực quan, đơn giản, dễ đọc, dễ
hiểu.
• UML giúp cho việc trao đổi thông tin giữ những người tham gia vào
dự án: khách hàng, nhà phân tích, nhà thiết kế, người lập trình …
trở nên dễ dàng hơn.
• UML và OOAD giúp cho việc xác định yêu cầu, phân tích thiết kế
tốt hơn, đảm bảo người tham gia sau vào dự án cũng có thể đọc
- hiều được. Tạo sự thống nhất trong suốt quá trình phát triển phần
mềm.
• Khả năng bảo trì hệ thống cao hơn, dễ tiến hóa và tái sử dụng.
• Một trong những nguyên nhân gây sự thất bại dự án là: xác định sai,
không chính xác nhu cầu người dùng, phần mềm không đảm bảo
tính tiến hóa, sự khả chuyển, khó bảo trì và tái sử dụng. Sử dụng
UML làm giảm nguy cơ thất bại của dự án phần mềm.
- Như vậy việc sử dụng UML trong quá trình phân tích thiết kế phần
mềm là vô cùng cần thiết và có hiệu quả.
4. Các sơ đồ trong UML và chức năng của nó:
- Các sơ đồ trong UML:
- UML cung cấp các loại sơ đồ biểu diễn theo hai hướng khác nhau của
hệ thống phần mềm: hướng cấu trúc và hướng hành vi:
• Hướng cấu trúc: nhấn mạnh cấu trúc tĩnh của phần mềm bao gồm
các đối tượng, thuộc tính, phương thức và mối quan hệ giữa các
đối tượng: sơ đồ class, sơ đồ đối tượng, sơ đồ đóng gói, sơ đồ
triển khai …
• Hướng hành vi: nhấn mạnh cấu trúc động của hệ thống, thể hiện
hành vi của hệ thống phần mềm thông qua sự hợp tác của các đối
tượng, sự thay đổi trạng thái của các đối tượng: sơ đồ cộng tác, sơ
đồ người dùng, sơ đồ hoạt động …
- Mỗi biểu đồ là một loại hình vẽ mô tả phần mềm trong một khung
nhìn. Các biểu đồ hay sử dụng: Use-case diagram, Class diagram,
Activity diagram, State diagram, Sequence diagram, Collaboration
diagram.
- Vai trò của các loại sơ đồ trong quá trình phân tích thiết kế phần mềm:
4.1. Use Case Diagram:
• Là biểu đồ thể hiện sự tương tác, mối quan hệ giữa các Use
Case và các Actor trong hệ thống phần mềm
- • Phục vụ cho việc trao đổi thông tin. Nó cung cấp phương
tiện để khách hàng, những người dùng tương lai của phần
mềm và những người phát triển phần mềm có thể trao đổi
với nhau về biến những yếu cầu về mặt nghiệp vụ của
người dùng thành những yếu cầu cụ thể mà lập trình viên có
thể hiểu một cách rõ ràng.
• Dùng để mô hình hóa các chuỗi hành động của phần mềm.
Cung cấp một cách nhìn tổng thể về những gì mà hệ thống
sẽ làm và ai sẽ dùng nó. Đưa ra cơ sở để xác định giao tiếp
người – máy của hệ thống. Dùng để mô hình hóa các kịch
bản (scenario) cho một trường hợp sử dụng. Để người dùng
cuối có thể hiểu được và có thể giao tiếp với hệ thống ở
mức tổng thể. Làm cơ sở cho việc phác thảo ra các đặc tả
kiểm tra.
4.2. Activity Diagram:
• Activity Diagram là một dạng đặc biệt của biểu đồ State. Nó
chỉ ra luồng đi từ hoạt động này sang hoạt động khác trong
một hệ thống. Nó đặc biệt quan trọng trong việc xây dựng
mô hình chức năng của hệ thống và nhấn mạnh tới việc
chuyển đổi quyền kiểm soát giữa các đối tượng.
• Biểu đồ hoạt động là một phương tiện mô tả các dòng công
việc (workflow) và được dùng theo nhiều cách khác nhau.
• Biểu đồ hoạt động được dùng để: mô tả chi tiết bên trong
một thao tác; ngoài ra trước khi xác định các use-case nó còn
được dùng để xác định các yêu cầu nghiệp vụ ở mức cao; là
phương tiện mô tả các use-case và các hành vi phức tạp bên
trong đối tượng; diễn tả các ứng xử của nhiều đối tượng
qua nhiều use-case; các biểu đồ hoạt động bổ sung cho biểu
đồ tương tác, và có quan hệ mật thiết với biểu đồ trạng thái
• Biểu đồ hoạt động gồm hoạt động (activity), trạng thái
(state) và chuyển tiếp (transition). Nếu các hoạt động là chủ
yếu thì ta gọi là biểu đồ hoạt động; còn nếu trạng thái là
chủ yếu thì ta gọi là biểu đồ trạng thái. Nói chung thì khái
niệm biểu đồ hoạt động rộng hơn, vì có thể xem trạng thái
cũng là một dạng hoạt động (ví dụ như chờ).
• Một vài Activity Diagram có thể dùng thay thế cho State
machince Diagram.
4.3. Sequence Diagram:
• Sequence Diagram là một dạng biểu đồ tương tác
(interaction), biểu diễn sự tương tác giữa các đối tượng theo
thứ tự thời gian. Nó mô tả các đối tượng liên quan trong một
tình huống cụ thể và các bước tuần tự trong việc trao đổi
- các thông báo (message) giữa các đối tượng đó để thực hiện
một chức năng nào đó của hệ thống.
• Biểu đồ tuần tự có thể sử dụng cả trong pha phân tích và
pha thiết kế hướng đối tượng, Biểu đồ này có 3 mức: mức
hệ thống (system-level) được sử dụng để diễn tả chính xác
scenario, nghĩa là chỉ có hai tác nhân tham gia là tác nhân bên
ngoài và hệ thống (tức là phần mềm); mức dịch vụ ( service-
level) mô tả các dịch vụ, trong đó tương tác là các hành động,
không hẳn là phương thức của các đối tượng; và mức
phương thức (method-level) trong đó các tương tác chủ yếu
là các phương thức của các đối tượng. Thực ra mức này
trong tài liệu gốc được gọi là mức đối tượng (object-level),
nhưng cách gọi này không thể hiện được bản chất của vấn
đề, vì trong biểu đồ tuần tự ở mức nào cũng do các đối
tượng tham gia cả. Trong phân tích thiết kế hướng đối
tượng thì khái niệm đối tượng được sử dụng với nghĩa rất
rộng, hầu như mọi vật đều là đối tượng, chứ không hẳn chỉ
là thể hiện của lớp. Mức phương thức thường được dùng
trong pha thiết kế để xác định các phương thức của các lớp.
Trong biểu đồ nếu đối tượng đích là thể hiện của lớp thì tên
tương tác chính là tên phương thức của đối tượng đích. Còn
nếu đối tượng đích là tác nhân hay đối tượng kiểu như bảng
dữ liệu thì tên tương tác là tên thông tin chuyển đến. Trong
quá trình phân tích thiết kế hướng đối tượng người ta
thường vẽ biểu dồ mức phương thức.
• Tương tác trong biểu đồ tuần tự là lời gọi phương thức của
đối tượng, nhưng cũng có khi chỉ là một hành động bình
thường. Hành động này không hẳn là lời gọi phương thức,
mà nó chỉ gợi ý cho ta xây dựng các phương thức của các lớp
tham gia biểu đồ mà thôi. Cách biểu diễn các đối tượng cũng
rất khác nhau: có khi là vòng tròn với một vài quy uwowsc
đặc biệt, có khi chỉ là hình chữ nhật đơn giản.
4.4. State Diagram:
• State Diagram chỉ ra một máy chuyển trạng, bao gồm các
trạng thái, các bước chuyển trạng và các hoạt động. Nó đặc
biệt quan trọng trong việc mô hình hóa hành vi của một lớp
giao diện (interface class) hay collaboration và nó nhấn mạnh
vào các đáp ứng theo sự kiện của một đối tượng, điều này
rất hữu ích khi mô hình hóa một hệ thống phản ứng
(reactive).
• Biểu đồ trạng thái (state diagram) là một phương tiện mô tả
các sự thay đổi trạng thái của các lớp (thực ra là các đối
tượng). Về hình thức, biểu đồ trạng thái giống biểu đồ hoạt
- động, trong đó công việc được thay bằng trạng thái. Biểu đồ
hoạt động chủ yếu được dùng để mô tả các dòng công việc
(workflow), còn biểu đồ trạng thái lại được dùng để mô tả
sự thay đổi trạng thái của một lớp (thực chất là thể hiện của
lớp, tức là đối tượng). Ví dụ máy điện thoại có thể có các
trạng thái: đang gác máy, đang quay số, máy bận và bị ngắt
kết nối. Như vậy, biểu đồ trạng thái chủ yếu được dùng để
mô tả hành vi của các lớp. Tuy nhiên chúng cũng được dùng
để mô tả hành vi của các phần tử khác, như use-case, actor,
hệ thống con và thao tác. Các biểu đồ trạng thái còn được sử
dụng trong quy trình phân tích để mô tả hành vi phức tạp của
các phần tử trong môi trường hệ thống, chẳng hạn như hành
vi của một khách hàng. Biểu đồ trạng thái là một trong
những biểu đồ của UML dùng để mô tả các dòng (các biểu
đồ khác là: biểu đồ hoạt động, biểu đồ tuần tự và biểu đồ
cộng tác). Tuy nhiên, biểu đồ trạng thái mô hình hóa các hành
vi từ góc độ một thực thể, chẳng hạn như một lớp; còn biểu
đồ hoạt động và biểu đồ cộng tác có thể lập mô hình hành vi
cho nhiều thực thể
• Biểu đồ trạng thái dùng để biểu diễn sự thay đổi trạng thái
của một lớp tương ứng với các thông điệp mà lớp đó gửi đi
hoặc nhận được: sử dụng để mô tả ứng xử của một đối
tượng trải qua nhiều use-case, vẽ biểu đồ trạng thái cho
những lớp mà các ứng xử của chúng không dễ hiểu và do đó
cần mô tả chi tiết hơn
• Biểu đồ trạng thái không phải là công cụ tốt để mô tả cách
ứng xử của các đối tượng khi tương tác với nhau. Biểu đồ
trạng thái chủ yếu được dùng để mô tả các trạng thái và các
sự kiện, hoạt động trong vòng đời của một đối tượng
4.5. Class Diagram:
• Biểu đồ lớp mô tả các kiểu đối tượng trong hệ thống và các
mối quan hệ tĩnh giữa chúng.
• Biểu đồ lớp cho ta biết những thành phần tạo nên phần
mềm và mối liên quan giữa chúng. Biểu đồ này chỉ cho biết
mối liên quan tĩnh giữa các thành phần. Để thấy được mối
tương quan động giữa chúng ta còn cần tới các biểu đồ khác
như biểu đồ hoạt động, biểu đồ trạng thái, biểu đồ tương
tác (tuần tự và cộng tác).
4.6. Collaboration Diagram:
• Gần giống như biểu đồ Sequence, biểu đồ Collaboration là
một cách khác để thể hiện một tình huống có thể xảy ra
trong hệ thống. Nhưng nó tập trung vào việc thể hiện việc
trao đổi qua lại các thông báo giữa các đối tượng chứ không
- quan tâm đến thứ tự của các thông báo đó. Có nghĩa là qua đó
chúng ta sẽ biết được nhanh chóng giữa 2 đối tượng cụ thể
nào đó có trao đổi những thông báo gì cho nhau.
• Biểu đồ cộng tác được dùng trong quá trình diễn tả tỉ mỉ
biểu đồ lớp nhằm giúp người phân tích hiểu được các nhóm
đối tượng tham gia thực hiện một use-case như thế nào.
Biểu đồ cộng tác được sử dụng khi biểu đồ lớp không diễn
tả được hết ý nghĩa tương tác giữa các đối tượng. Ngoài ra
biểu đồ cộng tác còn được dùng để xác định các đối tượng
có liên quan trong các thao tác.
• Một biểu đồ cộng tác chỉ ra một sự tương tác động, cũng
giống như một biểu đồ tuần tự. Việc lựa chọn loại biểu đồ
nào được thực hiện theo gợi ý sau: nếu trình tự thời gian là
quan trọng hơn thì hãy chọn biểu đồ tuần tự, còn nếu vai trò
lớp trong tương tác quan trọng hơn thì hãy chọn biểu đồ
cộng tác. Trong biểu đồ cộng tác, các thông điệp được đánh
số thứ tự để chỉ thứ tự thời gian thực hiện chúng.
4.7. Object Diagram:
• Object Diagram rất giống Class Diagram.
• Object Diagram cũng cho thấy các mối quan hệ giữa đối
tượng nhưng nó sử dụng những ví dụ cụ thể.
• Bao gồm một tập hợp các đối tượng và mối quan hệ giữa
chúng. Đối tượng là một thể hiện của lớp, biểu đồ đối
tượng là một thể hiện của biều đồ lớp.
4.8. Component Diagram:
• Dùng để mô tả mối quan hệ cấu trúc các thành phần của
một hệ thống phần mềm.
• Chỉ ra cách tổ chức và sự phụ thuộc của các thành phần
(component). Nó liên quan tới biểu đồ lớp, trong đó một
thành phần thường ánh xạ tới một hay nhiều lớp, giao diện,
collaboration.
• Thường dùng cho các hệ thống phức tạp nhiều thành phần.
Các thành phần kết nối với nhau bằng cách sử dụng giao
diện. Các giao diện dược kết nối với nhau bằng kết nối.
4.9. Deployment Diagram:
• Cho thấy phần cứng của hệ thống và các phần mềm trong
các phần cứng và mối liên hệ giữa chúng.
• Deployment Diagram rất hữu ít khi giải pháp phần mềm
được triển khai trên nhiều máy tính với nhau có cùng cấu
hình duy nhất.
- 4.10. Package Diagram:
• Package Diagram: cho thấy sự khác nhau giữa các gói trong
cùng một hệ thống.
• Package: tập hợp các yếu tố ngữ nghĩa có liên quan.
4.11. Profile Diagram:
• Là một loại Diagram mới, chỉ xuất hiện trong UML 2, và rất
ít sử dụng.
4.12. Composite Structure Diagram:
• Composite Structure Diagrams: được sử dụng để hiển thị các
cấu trúc bên trong của một lớp
• Phân loại tương tác với môi trường thông qua các cổng
(Port)
• Kết hợp với mô hình collaboration use diagram.
4.13. Communication Diagram:
• Communication Diagram: tương tự như sequence diagrams
nhưng nó tập trung chính vào mối quan hệ giữa các đối
tượng, các trao đổi giữa các đối tượng (Ví dụ như A trao cho
B cái gì, khi nào trao… ).
4.14. Interaction OverView Diagram:
• Interaction overview diagrams tương tự activity diagrams
• Activity diagrams cho thấy 1 chuổi các qui trình thì
Interaction overview diagram cho ta thấy một chuổi các
tương tác.
4.15. Timing Diagram:
• Timing Diagram cũng tương tự như Sequence Diagram
• Nó đại diện cho hành vi của hệ thống trong một hành vi.
5. Năm góc nhìn của UML trong việc phân tích thiết kế phần mềm:
- Góc nhìn (khung nhìn, hay hướng nhìn): là một khái niệm trong UML,
chứ không phải là một thành phần biểu diễn có thể nhìn thấy được
như use-case, biểu đồ, lớp... Trong đời thường, khi quan sát một vật
thể phức tạp ta phải nhìn từ nhiều hướng khác nhau. Khi biểu diễn các
vật đó trên giấy cũng không thể chỉ biểu diễn trong một bản vẽ duy
nhất mà phải dùng nhiều bản vẽ, mỗi bản vẽ biểu diễn vật từ một
hướng nhìn. Với một phần mềm phức tạp cũng vậy, ta cũng phải quan
sát từ những hướng khác nhau. Tuy nhiên hướng ở đây không còn được
hiểu theo nghĩa đen nữa, vì phần mềm không phải là một vật có thể
quan sát một cách rõ ràng như ngôi nhà, chiếc cầu... Hướng nhìn ở đây
được hiểu là các khía cạnh khác nhau cần mô tả, mô hình hoá và trừu
tượng hoá của hệ thống. Mỗi hướng nhìn gồm một số loại biểu đồ
khác nhau.
- 5.1. Góc nhìn người dùng (Use case view):
• Thể hiện mối quan hệ giữa người dùng cuối và phần mềm.
Góc nhìn người dùng mang tính trung tâm, vì nó là cơ sở cho
các hướng nhìn khác.
• Bao gồm các Use Case mô tả ứng xử của hệ thống theo cách
nhìn nhận của người dùng, người phân tích phần mềm. Nó
không chỉ ra cách cấu trúc của hệ thống phần mềm, nó chỉ
dùng để nhìn nhận một cách tổng quát những gì mà hệ thống
sẽ cung cấp, thông qua đó người dùng có thể kiểm tra xem
các yêu cầu của mình đã được đáp ứng đầy đủ hay chưa
hoặc có chức năng nào của phần mềm là không cần thiết.
Biểu đồ dùng đến là biểu đồ Use Case.
5.2. Góc nhìn logic (Logical view):
• Góc nhìn logic nhìn vào bên trong hệ thống. Nó mô tả các
cấu trúc tĩnh (lớp, đối tượng, quan hệ), cũng như sự tương
tác giữa các đối tượng để thực hiện các chức năng mong đợi
của phần mềm.
5.3. Góc nhìn tiến trình (Process view):
• Chia hệ thống thành các tiến trình (process) và luồng
(thread), mô tả việc đồng bộ hóa và các xử lý đồng thời.
Dùng cho người phát triển và tích hợp hệ thống, bao gồm
các biểu đồ sequence diagram, collaboration diagram, activity
diagram và state diagram.
5.4. Góc nhìn phát triển (Implementation view):
• Bao gồm các component và file tạo nên hệ thống vật lý. Nó
chỉ ra sự phụ thuộc giữa các thành phần này, cách kết hợp
chúng lại với nhau để tạo ra một hệ thống thực thi.
5.5. Góc nhìn triền khai (Deployment view):
• Chỉ ra cấu hình phần cứng mà hệ thống sẽ chạy trên đó. Nó
thể hiện sự phân tán, cài đặt các phần mà tạo nên kiến
- trúcvật lý của hệ thống. Biểu đồ được sử dụng là biểu đồ
Deployment.
- Kết luận, tùy vào vai trò của mỗi người tham gia vào dự án thì có sử
dụng các góc nhìn khác nhau cũng như một, một phần hoặc toàn bộ các
biểu đồ của từng góc nhìn.
- Trong các góc nhìn trên đây thì góc nhìn use-case và góc nhìn logic đóng
vai trò quan trọng cốt yếu trong phân tích và thiết kế hướng đối tượng.
6. Ví dụ và phân tích:
1. Sơ đồ Use Case:
- Actor (Các tác nhân)
- ThuThu: Là người phụ trách việc cho mượn sách và nhận trả sách, lập
báo cáo thống kê về tình hình mượn trả sách của thư viện.
- QLDocGia: Là người phụ trách quản lý độc giả: lập thẻ độc giả, gia
hạn thẻ, lập báo cáo thống kê về độc giả..
- ThuKho: Là người quản lý sách thư viện. Quản lý việc nhận thêm sách
và thanh lý sách, lập báo cáo thống kê tình hình sách của thư viện.
Danh Sách Nghiệp Vụ:
- DangNhapHeThong: đăng nhập vào hệ thống quản lý thư viện; được
sử dụng bởi thủ thư, thủ kho, nhân viên quản lý độc giả.
- TraCuuSach: tra cứu thông tin sách trong thư viện; được sử dụng bởi
thủ thư, thủ kho.
- ChoMuonSach: cho độc giả mượn sách; được sử dụng bởi thủ thư.
- QLSach: tìm kiếm, thêm, xóa và sửa các thông tin về sách trong thư
viện (tùy thuộc vào chức năng và quyền của các actor); được sử dụng
bởi thủ thư, thủ kho.
- NhanTraSach: nhận lại sách mà độc giả trả lại; được sử dụng bởi thủ
thư.
- NhanSachMoi: cập nhật sách mới cho thư viện; được sử dụng bởi thủ
kho.
- ThanhLySach: thanh lý các sách cần thanh lý; được sử dụng bởi thủ
kho, nhân viên phụ trách.
- QLDocGia: tìm kiếm, thêm, xóa và sửa các thông tin về độc giả (tùy
thuộc vào chức năng và quyền của các actor); được sử dụng bởi thủ
thư, nhân viên quản lý độc giả.
- TraCuuDocGia: tra cứu thông tin về độc giả; được sử dụng bởi thủ
thư, nhân viên quản lý độc giả.
- LapTheDocGia: lập thẻ thư viện cho độc giả; được sử dụng bởi nhân
viên quản lý độc giả.
- GiaHanDocGia: gia hạn thẻ thư viện cho độc giả; được sử dụng bởi
nhân viên quản lý độc giả.
- BCTKChoMuonSach: báo cáo thống kê về tình hình sách đã cho mượn;
được sử dụng bởi thủ thư.
- - BCTKDocGia: báo cáo thống kê về tình hình độc giả của thư viện;
được sử dụng bởi nhân viên quản lý độc giả.
- BCTKSachNhan-SachThanhLy: báo cáo thống kê về tình hình sách nhận
thêm và sách được thanh lý được sử dụng bởi thủ kho.
Kí hiệu:
- Người dùng(tác nhân) được kí hiệu là hình nhân
- Yêu cầu phần mềm được kí hiệu lad một hình elip
- Người dùng tác động trực tiếp tới yêu cầu phần mềm dùng mũi tên nét
liền
- Các mũi tên nét đứt ( ) thể hiện sự tham chiếu, liên kết giữa các
yêu cầu phần mềm với nhau
Nhân viên thủ thư tác động trực tiếp đến các yêu cầu TraCuuDocGia,
ChoMuonSach, NhanTraSach, BCTKChoMuonSach, TraCuuSach.
Phân tích nghiệp vụ tra cứu sách:
• TraCuuSach:
Điều kiện:
- Kịch bản chính:
o Người dùng mở màn hình tra cứu sách.
o Nhập thông tin cần tra cứu.
o Phần mềm hiển thị các kết quả tìm được.
- Kịch bản phụ:
- o Người dùng có thể chọn vào tìm kiếm nâng cao để lọc ra những
thông tin cần thiết
o Người dùng mở màn hình tra cứu sách nâng cao
o Nhập thông tin cần tra cứu
o Phần mềm hiển thị kết quả tìm được
- Kịch bản xử lý lỗi:
7. Sơ đồ class:
- Cung cấp logical view chi tiết: FormTraCuuSach sau khi mở lên và
nhập đầy đủ hoặc một phần thông tin sẽ chuyển thông tin đến
DKTraCuuSach thực hiện một hoặc tất cả các phương thức trong đó.
Sau đó DKTraCuuSach sẽ gửi thông tin đến QTGD_Sach tiến hành tra
cứu trong dữ liệu và trả về kết quả cho FormTraCuuSach.
- Mô tả các lớp, interface và quan hệ giữa chúng.
• Các lớp được thiết kế rõ ràng như hình vẽ: gồm 5 lớp với
những thuộc tính, phương thức đặc trưng.
• Quan hệ được thể hiện rõ qua hình với những con số
0..1(quan hệ 1-1) hay 0..*(quan hệ 1- nhiều)
- Được sử dụng trong thiết kế phần mềm hướng đối tượng. Mỗi lớp
được thể hiện trong hình là một đối tượng riêng biệt.
8. Sơ đồ Sequence
- Góc nhìn process view.
- Minh họa các sự tương tác giữa các đối tượng.
- Mô tả chuỗi sự kiện xảy ra theo trình tự thời gian.
- Có 4 đối tượng chính trong nghiệp vụ tra cứu sách là:
Để tra cứu 1 thông tin, phần mềm và người dùng sẽ phải trải qua 14
bước (gọi 14 phương thức) và mỗi đối tượng sẽ có một nhiệm vụ riêng
và liên kết với nhau như hình vẽ. Sau khi kiểm tra tính đúng đắn dữ liệu
nội bộ của từng đối tượng(thông tin nhập vô, truy xuất… thể hiện bằng
mũi tên quay ngược lại ) thì dữ liệu sẽ được chuyển qua đối
tượng khác để tiếp tục xử lý(Mũi tên trỏ qua đối tượng khác
). Kết quả trả về sẽ được kí hiệu bằng mũi tên nét đứt .
9. Sơ đồ activity:
- Thể hiện hoạt động của hệ thống theo luồng.
- • Các bước thực hiện, các hành động, các nút quyết định và điều
kiện rẽ nhánh để điều khiển luồng thực hiện của hệ thống.
• Biểu đồ hành động mô tả các hành động và các kết quả của
những hành động đó.
- Kí hiệu:
Các chấm đen là các nút thể hiện các yêu cầu và kết quả xử
lí của phần mềm. Sau khi lấy hai dữ liệu từ thủ kho và nhân viên
quản lí độc giả, thủ thư tra cứu thông tin phiếu mượn sách, tiếp
theo phiếu mượn sách sẽ được kiểm tra về sách và độc giả(Dấu
ngang và mũi tên ra hai hướng ) khi kiểm tra xong hai
điều kiện sẽ được giao lại với nhau( ) rồi xét yêu cầu
cho mượn sách. Một lệnh rẽ nhánh dùng để kiểm tra ( kí hiệu
). Nếu thông báo không hợp lệ thì trả lại phiếu và
dừng tác vụ tại đó. Nếu hợp lệ tiến hành cho mượn sách và chuyển
thông tin qua thủ kho. Tại thủ kho, phần mềm sẽ kiểm tra lại thông
tin một lần nữa, hợp lệ thì sẽ cập nhật sách hiện có và gửi lại cập
nhật cho Thủ thư, không hợp lệ sẽ thông báo lại cho thủ thư và kết
thúc yêu cầu.
- 10. Sơ đồ Deployment:
- Thể hiện quan hệ giữa các thành phần phần cứng trong cơ sở hạ
tầng vật lí.
- Mô tả chi tiết các phần cứng cũng như giao thức kết nối giữa các
phần cứng với nhau. Như ở ví dụ trên thì:
• Một máy chủ cơ sở dữ liệu có thể cho nhiều PC kết nối tới,
Các PC không giao tiếp trực tiếp với nhau mà thông qua máy
chủ CSDL. Các máy in có thể dùng chung giữa các PC.
• Các PC kết nối tới máy chủ cơ sở dữ liệu bằng giao thức
TCP/IP, kết nối với máy in bằng giao thức IPX
11. Rup:
12. Tài liệu tham khảo
nguon tai.lieu . vn