Mô hình Nghiệp vụ: Thêm các Thuộc tính

Một phần của tài liệu Sử dụng hiệu quả ngôn ngữ đặc tả UML trong phát triển phần mềm (Trang 38)

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

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 (adsbygoogle = window.adsbygoogle || []).push({});

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

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 (adsbygoogle = window.adsbygoogle || []).push({});

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ị

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 (adsbygoogle = window.adsbygoogle || []).push({});

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

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 đơn xin thì công trình của đơn xin cũng được tạo và lưu lại, rồi bấm nút lưu để lưu lại, sau khi tạo mới đơn xin thì tiếp tục tạo mới đơn vị thiết kế đơn vị thẩm định

6.5.1.11 Thiết kế giao diện: Tạo mới đơn vị thiết kế, đơn vị thẩm định

6.5.1.12 Sơ đồ tuần tự (Sequence Diagram): Tạo mới giấy chứng nhận sở hữu

: CtlChungNhanSoHuu : 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 giấy chứng nhận sở hữu, rồi bấm nút ...

6.5.1.13 Thiết kế giao diện: Tạo mới giấy Chứng nhận sở hữu

6.5.1.14 Sơ đồ tuần tự (Sequence Diagram): Bổ xung hồ sơ

: CtlHoSo : Cán bộ tiếp nhận : FrmMainCpmApp : CtlBoXungHoSo : CtlTiepNhanHoSo (adsbygoogle = window.adsbygoogle || []).push({});

1 : \Chọn Bổ xung hồ sơ\ 2 : OnUpdateDataSource ( ) 3 : OnEdit ( ) 4 : OnEdit ( ) 5 : OnSave ( ) 6 : OnSave ( ) Cán bộ tiếp nhận chọn mục bổ xung hồ sơ để ghi nhận thêm hồ sơ, double click để chọn một hồ sơ trong danh sách, soạn thảo bổ xung rồi lưu lại

6.5.1.15 Thiết kế giao diện: Bổ xung hồ sơ

6.5.1.16 Sơ đồ tuần tự (Sequence Diagram): Chuyển lên phòng cấp phép

Object1 : Cán bộ tiếp nhận Object2 : FrmMainCpmApp Object3 : CtlChuyenCapPhep

1 : \Chọn Chuyển lên phòng CP\

2 : OnUpdateDataSource ( ) 3 : btnAdd_Click ( sender , e )

4 : btnRemove_Click ( sender , e ) Cán bộ tiếp nhận sau khi nhận đủ

các hồ sơ hợp lệ thì tập trung lại và chuyển lên phòng cấp phép để trưởng phòng có thể phân công thụ lý, nếu cần có thể hủy bỏ việc chuyển lên phòng cấp phép khi đó hồ sơ trở về trạng thái vẫn nằm ở bộ phận tiếp nhận

6.5.2 Use Case – Thụ lý

6.5.2.1 Mô tả:

Sau khi hồ sơ đã đƣợc chuyển lên phòng cấp phép. Tác nhân trƣởng phòng sẽ phải tiến hành phân công cho tác nhân thụ lý để tiến hành thụ lý hồ sơ.

Hồ sơ sau khi đã đƣợc phân công thì tác nhân thụ lý trực tiếp sẽ phải tiến hành thụ lý, xem xét các tài liệu, kiểm tra các thông tin liên quan đến quy hoạch, kiểm tra các thông số kỹ thuật của hồ sơ và nhập dữ liệu vào chƣơng trình.

Xác định đƣợc công trình sau khi đã thụ lý thì tác nhân thụ lý cần phải tính phí cho công trình, nêu ý kiến và trình lên tác nhân trƣởng phòng.

6.5.2.2 Các quan hệ

6.5.2.3 Sơ đồ hoạt động (Activity Diagram): Trưởng phòng Phân công thụ lý Cán bộ thụ lý Kiểm tra hồ sơ: thiết kế, quy hoạnh Yêu cầu bổ xung hồ sơ Xác minh thực tế

Hỏi cơ quan chức năng Tính lệ phí cấp phép Trình trưởng ph... Yêu cầu bổ xung tiếp hồ sơ

Lập kết quả thụ lý Hợp lệ

6.5.2.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 thụ lý

Hồ sơ mới được chuyển lên phòng CP, chưa phân công thụ lý

Đã phân công thụ lý, Đang thụ lý, Chưa trình trưởng phòng Trưởng phòng phân công thụ lý Hủy bỏ HS đã trình trưởng phòng, trưởng phòng chưa xem xét HS bị lãnh đạo

Một phần của tài liệu Sử dụng hiệu quả ngôn ngữ đặc tả UML trong phát triển phần mềm (Trang 38)