Một biểu đồ tuần tự hệ thống là một artifact đƣợc tạo ra nhanh và dễ dàng, nó biểu diễn các sự kiện đầu vào và đầu ra liên quan tới hệ thống đó
Use Case thì mô tả các tác nhân bên ngoài tƣơng tác với hệ thống phần mềm nhƣ thế nào. Trong quá trình tƣơng tác này một tác nhân sinh ra các sự kiện đối với hệ thống, thƣờng là yêu cầu vài hoạt động đáp trả. UML có các biểu đồ tuần tự có thể minh họa các tƣơng tác của tác nhân và các hoạt động kích hoạt bởi chúng
Một Biểu đồ Tuần tự Hệ thống (SSD) là một bức tranh mà chỉ ra trong tình huống cụ thể của một Use Case các sự kiện mà tác nhân bên ngoài sinh ra, thứ tự của chúng và các sự kiện liên hệ thống. Tất cả các hệ thống đƣợc xem nhƣ các hộp đen, điểm quan trọng của biểu đồ là các sự kiện đi qua biên của hệ thống từ các tác nhân tới các hệ thống.
Hình 5.1 Biểu đồ tuần tự hệ thống cho tình huống xử lý bán hàng
5.2.2 Mô hình Nghiệp vụ: Hình tượng hóa các Khái niệm
Mô hình nghiệp vụ đƣợc sử dụng rộng rãi nhƣ là nguồn cảm hứng để thiết kế các đối tƣợng phần mềm và sẽ là đầu vào bắt buộc cho nhiều Artifact mà ta sẽ đề cập tiếp theo.
Một mô hình nghiệp vụ biểu diễn các lớp khái niệm có ý nghĩa trong một vùng nghiệp vụ, nó là Artifact quan trọng nhất cần tạo trong phân tích hƣớng đối tƣợng. UML chứa các ký hiệu dƣới dạng biểu đồ lớp để biểu diễn các mô hình nghiệp vụ
Một mô hình nghiệp vụ là một biểu diễn của các lớp khái niệm thế giới thực, không phải các thành phần phần mềm. Nó không phải tập các biểu đồ mô tả các lớp phần mềm hay các đối tƣợng phần mềm cùng các trách nhiệm.
RUP định nghĩa mô hình nghiệp vụ nhƣ là một Artifact mà có thể tạo ra trong Business Modeling Discipline
Sử dụng các ký hiệu của UML, một mô hình nghiệp vụ đƣợc minh họa bởi một tập các Biểu đồ lớp trong đó không hoạt động nào đƣợc định nghĩa. Nó có thể biểu diễn:
Kiểu liên kết giữa các lớp khái niệm - Các thuộc tính của các lớp khái niệm
Hình 5.2 Một mô hình nghiệp vụ
5.2.3 Mô hình Nghiệp vụ: Thêm các Liên kết
- Cần tập trung vào các mối liên kết mà kiến thức về mối quan hệ cần đƣợc lƣu giữ trong một khoảng thời gian nào đó(Gọi là các liên kết “need to know”) - Việc xác định các lớp khái niệm quan trọng hơn là việc tìm các liên kết
- Quá nhiều mối liên kết sẽ gây rối mô hình nghiệp vụ, việc tìm ra chúng có thể mất thời gian
- Tránh chỉ ra các liên kết dƣ thừa và liên kết hệ quả
Sau đây là các loại liên kết đƣợc ƣu tiên và luôn hữu dụng khi bao gồm trong mô hình nghiệp vụ:
- A là một phần vật lý hoặc lôgic của B
- A đƣợc chứa một cách vật lý hoặc lôgic trong B - A đƣợc ghi nhớ trong B
Hình 5.3 Một mô hình nghiệp vụ với các liên kết
5.2.4 Mô hình Nghiệp vụ: Thêm các Thuộc tính
Một thuộc tính là giá trị dữ liệu logic của một đối tƣợng, chúng ta sẽ đƣa các thuộc tính vào trong mô hình nghiệp vụ khi trong các yêu cầu có gợi ý hoặc đề nghị cần phải nhớ thông tin.
5.2.5 Các biểu đồ tương tác
Biểu đồ tƣơng tác là khái quát hóa 2 loại biểu đồ UML đặc biệt, cả hai có thể biểu diễn tƣơng tác thông điệp một cách tƣơng tự.
- Biểu đồ cộng tác - Biểu đồ tuần tự
Biểu đồ cộng tác biểu diễn các tƣơng tác đối tƣợng trong một biểu đồ mà các đối tƣợng có thể đặt bất cứ đâu, nhƣ vẽ trong hình dƣới đây
Hình 5.4 Biểu đồ cộng tác
Hình 5.5 Biểu đồ tuần tự
Mỗi loại biểu đồ có điểm mạnh và điểm yếu, biểu đồ cộng tác có thể vẽ trên diện tích có chiều ngang hẹp, còn biểu đồ tuần tự thì diễn đạt tốt hơn tuần tự các thông điệp
5.2.6 GRASP: Thiết kế các đối tượng cùng các Trách nhiệm
Sau khi xác định yêu cầu và tạo ra mô hình nghiệp vụ, việc thêm các phƣơng thức vào các lớp phần mềm và định nghĩa các thông điệp để đáp ứng các yêu cầu là một cách để mô tả quá trình thiết kế đối tƣợng (adsbygoogle = window.adsbygoogle || []).push({});
GRASP đƣợc biểu diễn nhƣ là các hình mẫu dùng để mô tả các nguyên lý căn bản về thiết kế đối tƣợng và gán trách nhiệm cho đối tƣợng.
UML định nghĩa “Trách nhiệm” nhƣ là một hợp đồng, một bắt buộc đối với một phân lớp, về cơ bản các “Trách nhiệm” này đƣợc chia làm hai loại sau:
- Trách nhiệm biết - Trách nhiệm làm
Trách nhiệm làm của một đối tƣợng bao gồm:
- Tự làm gì đó, chẳng hạn tạo ra một đối tƣợng, hoặc thực hiện một tính toán - Khởi tạo hành động trong các đối tƣợng khác
- Điều khiển và phối hợp hành động trong các đối tƣợng khác Trách nhiệm biết của một đối tƣợng bao gồm:
- Biết dữ liệu đóng gói riêng - Biết các đối tƣợng liên quan
- Biết những điều mà nó có thể thừa kế hoặc tính toán
Trách nhiệm đƣợc gán cho các lớp của đối tƣợng trong khi thiết kế đối tƣợng Năm hình mẫu đầu tiên của GRASP là:
- Information Expert (Chuyên gia thông tin): Gán trách nhiệm cho lớp mà có chứa thông tin cần thiết để đáp ứng trách nhiệm.
- Creator (Ngƣời tạo): Gán trách nhiệm cho lớp B tạo ra thực thể của lớp A khi một trong các điều kiện sau đây là đúng:
o B tập hợp các đối tƣợng của A o B chứa các đối tƣợng của A o B ghi nhớ các thực thể của A o B sử dụng gần các đối tƣợng A
o B có dữ liệu khởi tạo mà sẽ đƣợc truyền cho A khi A đƣợc tạo ra
- High Cohesion (Cố kết cao): Gán trách nhiệm sao cho sự cố kết duy trì ở mức cao
- Low Coupling (Móc nối thấp): Gán trách nhiệm sao cho sự móc nối duy trì ở mức thấp
- Controller (Bộ điều khiển): Gán trách nhiệm nhận và xử lý các thông điệp sự kiện hệ thống cho lớp mà đại diện cho một trong các lựa chọn sau:
o Biểu diễn tổng thể hệ thống, thiết bị, hoặc thiết bị con
o Biểu diễn một ngữ cảnh Use Case trong đó sự kiện hệ thống xảy ra
5.2.7 Mô hình Thiết kế: Hiện thực hóa Use Case với các khuôn mẫu GRASP
Hiện thực hóa Use Case mô tả một Use Case sẽ đƣợc hiện thực nhƣ thế nào trong mô hình thiết kế. Chính xác hơn, một ngƣời thiết kế có thể mô tả thiết kế của một hay nhiều tình huống của Use Case, mỗi công việc này gọi là hiện thực hóa Use Case. Hiện thực hóa Use Case là một thuật ngữ của RUP, hay một khái niệm đƣợc sử dụng để nhắc chúng ta về mối liên kết giữa những yêu cầu đƣợc thể hiện bởi các Use Case và các thiết kế đối tƣợng thỏa mãn những yêu cầu đó.
Các biểu đồ tƣơng tác của UML là ngôn ngữ chung để minh họa việc hiện thực hóa Use Case. Và có các nguyên lý, hình mẫu của thiết kế đối tƣợng, nhƣ là “Chuyên gia Thông tin”, “Móc nối thấp”, có thể áp dụng cho quá trình thiết kế này
Hình 5.6 Biểu đồ tuần tự dùng hiện thực hóa Use Case
5.2.8 Mô hình Thiết kế: Xác định tính khả năng thấy được
Khả năng thấy đƣợc(Visibility) là khả năng một đối tƣợng có thể nhìn thấy hoặc tham chiếu tới một đối tƣợng khác.
Các thiết kế tạo ra cho các sự kiện hệ thống đƣợc minh họa bởi các thông điệp giữa các đối tƣợng. Để đối tƣợng gửi gửi một thông điệp tới đối tƣợng nhận thì đối tƣợng nhận phải có thể nhìn thấy đối với đối tƣợng gửi, đối tƣợng gửi phải có tham chiếu hoặc con trỏ tới đối tƣợng nhận.
Hình 5.7 Minh họa khả năng nhìn thấy
5.2.9 Mô hình Thiết kế: Tạo ra các Biểu đồ Lớp Thiết kế
Sau khi đã hoàn thành các biểu đồ tƣơng tác cho việc hiện thực hóa các Use Case ta có thể xác định các đặc tính của lớp phần mềm(và các giao diện) mà tham gia vào giải pháp phần mềm, và chú giải chúng với các chi tiết thiết kế, nhƣ các phƣơng thức chẳng hạn.
Chương 6: Áp dụng UML để phân tích thiết kế ứng dụng
6.1 PHÁT BIỂU BÀI TOÁN (adsbygoogle = window.adsbygoogle || []).push({});
Nghiệp vụ bài toán quản lý và cấp phép xây dựng trên địa bàn Thành phố Hà Nội thực hiện theo mô hình quản lý phân cấp: Cấp Thành Phố và cấp Quận Huyện. Hai mô hình (hệ thống con -Subsystem) nay đều có đặc điểm:
Qui trình nghiệp vụ chức năng quản lý của hai hệ thống hỗ trợ cấp phép xây dựng cơ bản là nhƣ nhau. Cụ thể theo phân cấp thực hiện quản lý, chức năng quản lý tập hợp thông tin báo cáo tình hình CPXD trên toàn địa bàn thành phố, quản lý lập thông tin qui phạm qui chuẩn trong xây dựng, quản lý qui hoạch và cấp phép các công trình có qui mô lớn là thực hiện bởi Sở Xây Dựng.
Hệ thống thông tin phục vụ công tác cấp phép xây dựng Sở xây dựng - Phạm vi Sở xây dựng quản lý và cấp phép công trình xây dựng.
Hệ thống thông tin phục vụ công tác cấp phép xây dựng Quận / Huyện - Phạm vi phân cấp trực thuộc Quận/ Huyện quản lý và cấp phép xây dựng công trình..
Cả hai hệ thống con đều có chung qui trình nghiệp vụ chức năng quản lý thực hiện cấp phép xây dựng:
o Tiếp nhận hồ sơ xin cấp phép xây dựng.
o Kiểm tra hồ sơ, thực tế, thiết kế kỹ thuật và thụ lý hồ sơ. o Phê duyệt cấp phép.
o Trả giấy phép xây dựng và thực hiện thu nghĩa vụ tài chính. o Quản lý theo dõi sau cấp phép.
Hai hệ thống thực hiện báo cáo, trao đổi thông tin “Hồ sơ cấp phép xây dựng” của các giấy phép xây dựng dựa trên các đối tƣợng thông dữ liệu về văn bản qui phạm, qui hoạch và kho dữ liệu hồ sơ kỹ thuật chung (dữ liệu bản đồ qui hoạch,…).
Đối tƣợng thông tin “Hồ sơ cấp phép xây dựng” là đầu ra (quản lý) của hệ thống thông tin cấp Quận/ Huyện và là đầu vào hệ thống thông tin cấp Sở.
Hệ thống hỗ trợ quản lý cấp phép xây dựng để triển khai trên hai hệ thống mạng Phòng quản lý và Cấp phép xây dựng, mạng các máy tính Phòng Xây dựng đô
thị các Quận/ Huyện. Hình thức trao đổi thông tin dữ liệu CPXD đƣợc thực hiện theo cơ chế:
o Mạng Internet: Gửi thông tin dữ liệu CPXD qua Modem theo dịnh kỳ báo cáo.
o Thiết bị lƣu trữ: Ghi dữ liệu CPXD vào thiết bị lƣu trữ CDROM, Đĩa mềm,… thực hiện trao đổi hai cấp.
Khi Phòng quản lý và cấp phép xây dựng - Sở Xây Dựng tổ chức (hosting) hệ thống hỗ trợ quản lý cấp phép xây dựng hoạt động trực tuyến trên cổng giao tiếp điện tử hoặc kênh giao tiếp trực tuyến, các đơn vị Phòng Xây dựng đô thị cấp Quận/Huyện sẽ hoạt động và báo cáo tình hình cấp phép xây dựng trƣc tiếp (Online).
6.3 SƠ ĐỒ USE CASE
6.3.1 Sơ đồ use case Main:
Tiếp nhận một cửa
Thụ lý hồ sơ
Phê duyệt Trả hồ sơ thu lệ phí
Tra cứu web
Tiện ích hỗ trợ Quản lý sau cấp phép Lập báo cáo Quản trị hệ thống Quản lý danh mục Cán bộ tiếp nhận Cán bộ thụ lý Trưởng phòng
Văn thư lưu trữ
Lãnh đạo
Cán bộ tiếp nhận
Cán bộ thụ lý
Trưởng phòng
Lãnh đạo
Văn thư lưu trữ
Người quản trị (adsbygoogle = window.adsbygoogle || []).push({});
6.4 CÁC TÁC NHÂN
6.4.1 Tác nhân – Cán bộ tiếp nhận
Là tác nhân khởi tạo hình thành qui trình nghiệp vụ xin cấp GPXD từ hồ sơ xin CPXD của tác nhân “Chủ đầu tƣ”. Đồng thời là đối tƣợng tác nhân khép kín (kết thúc) qui trình CPXD và trả GPXD cho chủ đầu tƣ.
6.4.2 Tác nhân – Trưởng phòng
Là đối tƣợng chịu trách nhiệm quản lý, điều phối, phân công thụ lý và ký kết quả thụ lý của hồ sơ xin phép xây dựng.
6.4.3 Tác nhân – Cán bộ thụ lý
Là đối tƣợng chịu trách nhiệm kiểm tra, thụ lý hồ sơ xin phép xây dựng.
6.4.4 Tác nhân – Văn thư lưu trữ
Là đối tƣợng chịu trách nhiệm quản lý, lƣu trữ hồ sơ xin phép xây dựng và GPXD đã cấp theo thời gian trên toàn địa bàn quản lý
6.4.5 Tác nhân – Lãnh đạo
Là đối tƣợng chịu trách nhiệm quản lý, điều hành công tác quản lý cấp phép xây dựng trên toàn địa bàn và là ngƣời phê duyệt cấp GPXD.
6.4.6 Tác nhân – Người quản trị
Là đối tƣợng thực hiện các thao tác quản trị trong chƣơng trình, phân quyền, tạo các danh mục để các đối tƣợng khác lựa chọn khi thực hiện CPXD cho một hồ sơ.
6.5 MÔ TẢ CHI TIẾT CÁC USE CASE
6.5.1 Use Case – Tiếp nhận hồ sơ
6.5.1.1 Mô tả:
Khi chủ đầu tƣ mang hồ sơ đến cơ quan cấp phép để xin cấp phép xây dựng một công trình cụ thể. Chủ đầu tƣ sẽ mang hồ sơ đến phòng tiếp nhận một cửa, tác nhân tiếp nhận sẽ tiếp nhận hồ sơ, kiểm tra hồ sơ và yêu cầu chỉnh lý (nếu cần thiết), và lập giấy hẹn giải quyết đồng thời nhập dữ liệu hồ sơ đó vào chƣơng trình.
Sau khi đã tiếp nhận hồ sơ nếu thấy hồ sơ chƣa đƣợc hoàn thiện thì tác nhân tiếp nhận có thể yêu cầu chủ đầu tƣ bổ sung hồ sơ và nhập những thông tin bổ sung vào chƣơng trình.
Sau khi đã xác định hồ sơ là hoàn thiện thì tác nhân tiếp nhận có thể chuyển hồ sơ lên phòng cấp phép.
6.5.1.2 Các quan hệ
6.5.1.3 Sơ đồ hoạt động (Activity Diagram): : Cán bộ tiếp nhận Tiếp nhận hồ sơ Yêu cầu bổ xung, chỉnh lý Viết phiếu nhận hồ sơ và phiếu hẹn giải quyết
Tạo mới hồ sơ và nhập dữ liệu hồ sơ
vào cơ sở dữ liệu
Bổ xung dữ liệu hồ sơ vào cơ sở dữ liệu
Chuyển hồ sơ lên phòng cấp phép Hợp lệ
6.5.1.4 Sơ đồ chuyển đổi trạng thái (State Chat Diagram): Trạng thái hồ sơ xin cấp phép trong quá trình tiếp nhận
HS mới tiếp nhận
Hồ sơ đã chuyển lên phòng CP, chưa phân công thụ lý
Cán bộ tiếp nhận chuyển hồ sơ lên phòng cấp phép Hủy bỏ
6.5.1.5 Sơ đồ Class Diagram (adsbygoogle = window.adsbygoogle || []).push({});
Cán bộ tiếp nhận CtlChungNhanS... + CtlChungNhanSo... # OnNew ( ) # OnEdit ( ) # OnDelete ( ) # OnSave ( ) CtlDonXin + CtlDonXin ( ) # OnNew ( ) # OnEdit ( ) # OnDelete ( ) # OnSave ( ) CtlChuDauTu + CtlChuDauTu ( ) # OnNew ( ) # OnEdit ( ) # OnDelete ( ) # OnSave ( ) CtlHoSo + CtlHoSo ( ) # OnNew ( ) # OnEdit ( ) # OnDelete ( ) # OnSave ( ) CtlTiepNhanHoSo # OnSave ( ) # OnNew ( ) # OnDelete ( ) # OnEdit ( ) FrmMainCpmApp # OnInitModuleInformation ( ) - Login ( ) - ctlHoSo1 - ctlChuDauTu1 - ctlDonXin1 - ctlChungNhanSoHuu1 - OnClick() 0..1
6.5.1.6 Sơ đồ tuần tự (Sequence Diagram): Tạo mới chủ đầu tư
: CtlChuDauTu : CtlHoSo
: FrmMainCpmApp
: Cán bộ tiếp nhận : CtlTiepNhanHoSo
1 : \Chọn Tiếp nhận hồ sơ\ 2 : OnNew ( )
3 : OnNew ( ) 4 : OnSave ( ) 5 : OnSave ( ) 6 : OnNew ( ) 7 : OnSave ( ) Cán bộ tiếp nhận chọn tiếp nhận hồ sơ, tạo mới một hồ sơ, lưu lại rồi tạo mới chủ đầu tư, rồi bấm nút lưu để lưu lại
6.5.1.7 Thiết kế giao diện: Tạo mới hồ sơ
6.5.1.9 Sơ đồ tuần tự (Sequence Diagram): Tạo mới đơn xin, đơn vị thiết kế, đơn vị thẩm định : CtlDVThamDinh : CtlDonViThietKe : CtlCongTrinh : CtlDonXin : CtlHoSo : CtlTiepNhanHoSo : FrmMainCpmApp : Cán bộ tiếp nhận
1 : \Chọn Tiếp nhận hồ sơ\ 2 : OnNew ( )
3 : OnNew ( ) 4 : OnSave ( ) 5 : OnSave ( ) 6 : OnNew ( ) 7 : OnNew ( ) 8 : OnSave ( ) 9 : OnSave ( ) 10 : OnNew ( ) 11 : OnSave ( ) 12 : OnNew ( ) 13 : OnSave ( ) Cán bộ tiếp nhận chọn tiếp nhận hồ sơ, tạo mới một hồ sơ, lưu lại rồi tạo mới đơn xin, trong khi tạo mới