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:
BÁO
CÁO
PHÂN TÍCH
PHẦN MỀM VỚI UML
CUỐI
KÌ
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
Mục lục
I.
Mở đầu:.......................................................................................................................3
II. UML và ứng dụng của UML trong phân tích thiết kế phần mềm:...............................3
1. Sơ lượt về UML:......................................................................................................3
2. Các sơ đồ trong UML và chức năng của nó:............................................................4
2.1.
Use Case Diagram:............................................................................................4
2.2.
Activity Diagram:..............................................................................................5
2.3.
Sequence Diagram:............................................................................................5
2.5.
Class Diagram:..................................................................................................7
2.6.
Collaboration Diagram:.....................................................................................8
2.7.
Object Diagram:................................................................................................8
2.8.
Component Diagram:........................................................................................8
2.9.
Deployment Diagram:.......................................................................................9
2.10.
Package Diagram:..........................................................................................9
2.11.
Profile Diagram:.............................................................................................9
2.12.
Composite Structure Diagram:.......................................................................9
2.13.
Communication Diagram:..............................................................................9
2.14.
Interaction OverView Diagram:.....................................................................9
2.15.
Timing Diagram:............................................................................................9
3. Năm góc nhìn của UML trong việc phân tích thiết kế phần mềm:.........................10
III.
3.1.
Góc nhìn người dùng (Use case view):............................................................10
3.2.
Góc nhìn logic (Logical view):........................................................................11
3.3.
Góc nhìn tiến trình (Process view):.................................................................11
3.4.
Góc nhìn phát triển (Implementation view):....................................................11
3.5.
Góc nhìn triền khai (Deployment view):.........................................................11
Ví dụ và phân tích:.................................................................................................11
2. Sơ đồ class:............................................................................................................14
3. Sơ đồ Sequence......................................................................................................14
4. Sơ đồ activity:........................................................................................................16
5. Sơ đồ Deployment:................................................................................................17
IV.
Rup:........................................................................................................................ 17
V. Tài liệu tham khảo.....................................................................................................17
I.
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.
II.
UML và ứng dụng của UML trong phân tích thiết kế phần mềm:
1. 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ả.
2. 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:
2.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 .
2.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.
2.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ụ (servicelevel) 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.
2.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
2.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).
2.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.
2.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.
2.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.
2.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.
2.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.
2.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.
2.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.
2.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… ).
2.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.
2.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.
3. 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.
3.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.
3.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.
3.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.
3.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.
3.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.
-
III.
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.
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:
4. 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ệ 11) 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.
5. 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
.
6. 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.
7. 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
IV.
V.
Rup:
Tài liệu tham khảo
- Xem thêm -