THIẾT KẾ KIẾN TRÚC PHẦN MỀM

Nhóm lớp : 08

Nhóm bài tập lớn : 01

Tên đề tài : Quản lý trung tâm ngoại ngữ

Thành viên :

● Trần Anh Đức : B19DCCN199

Module : Cho giáo viên đăng ký dạy

Lên lịch dạy chính thức cho giáo viên

● Nguyễn Văn Bến : B19DCCN065

Module: Chấm công cho giảng viên theo lịch

Trả lương theo đợt, tuần tháng

● Nguyễn Viết Huy : B19DCCN315

Module: Học viên đăng kí học

Học viên thanh toán lệ phí

Biểu đồ lớp
Cơ sở dữ liệu

I. Module chấm công cho giảng viên theo các buổi của lịch

Người thiết kế: Nguyễn Văn Bến

Mã sinh viên: B19DCCN065

1. Thiết kế giao điện và biểu đồ lớp

● Tầng giao diện gồm các trang GDChonGV, GDChonKip, GDSetState
● Tầng xử lý truy cập dữ liệu: DAO, GiangVienDAO, LichDayDAO,
ChamCongDAO, KipIter, ThucHienIter
● Các lớp thực thể liên quan
2. Biểu đồ hoạt động
1) Tại giao diện chính của quản lý, quản lý chọn chấm công cho giảng viên

2) Trang GDChinhQL gọi GDChonGV

3) GDChonGV gọi lớp GiangVienDAO yêu cầu tìm danh sách của giảng viên

4) Lớp GiangVienDAO gọi hàm getdsGiangVien()

5) Hàm getdsGiangVien() gọi lớp GiangVien để đóng gói thông tin

6) Lớp GiangVien đóng gói thông tin thực thể

7) Lớp GiangVien trả về cho hàm getdsGiangVien()

8) Lớp GiangVienDAO trả về cho giao diện để hiển thị

9) GDChonGV hiên thị danh sách giảng viên

10) Quản lý click chọn giảng viên

11) GDChonGV gọi GDChonKip

12) GDChonKip nhận thông tin của giảng viên được chọn
13) GDChonKip gọi lớp LichDayDAO

14) Lớp LichDayDAO gọi getLichDay()

15) Hàm getLichDay() gọi lớp LichDay để đóng gói thông tin

16) Lớp LichDay đóng gói thông tin thực thể

17) Lớp LichDay trả về cho hàm getLichDay()

18) Lớp LichDayDAO trả về cho GDChonKip

19) GDChonKip gọi lớp KipIter để khởi tạo Lớp KipIter

20) Lớp KipIter được khởi tạo

21) GDChonKip gọi KipDAO

22) KipDAO gọi hàm getKip()

23) getKip() gọi lớp KipDay để đóng gói dữ liệu

24) Lớp Kip đong gói thông tin thực thể

25) Lớp Kip trả về thông tin cho hàm getKip()

26) Lớp KipDAO trả về cho GDChonKip

27) GDChonKip gọi lớp KipContext

28) Lớp KipContext gọi hàm khởi tạo KipConText()

29) KipContext() được khởi tạo

30) Hàm KipContext() trả về cho GDChonKip

31) GDChonKip gọi KipIter()

32) Lớp KipIter gọi hàm addKip()

33) KipContext() được add vào KipIter()

34) Sau khi them hết kip vào KipIter() thì GDChonKip hiển thị

35) Quản lý chọn kíp

36) GDChonKip gọi GDSetState

 37) GDSetState nhận thông tin Kip

38) GDSetSate hiển thị thông tin kíp

39) Quản lý click chọn đi làm

40) GDSetState gọi lớp KipIter

41) Lớp KipIter() gọi hàm getKipContext().setState()

42) Lớp KipIter().getKipContext() được cập nhật trạng thái

43) GDSetState cập nhập lại trạng thái của kíp

44) GDSetState hiển thị thông tin của kip

45) Quan Lý chon Next

46) GDSetState gọi lớp KipIter()

47) Lớp KipIter gọi lớp hasNext()

48) Lớp hasNext trả về giá trị true

49) Lớp KipIter() gọi hàm next()

50) Hàm next trả về KipContext()

51) GDSetState nhận thông tin KipContext()

52) GDSetState hiển thị thông tin KipConText()

53) Quản lý chọn lưu

54) GDSetState gọi GDChonKip

55) GDChonKip nhận thông tin từ KipIter()

56) GDChonKip hiển thị

3. Biểu đồ tuần tự
4. Biểu đồ giao tiếp
 5. Các pattern đã sử dụng: iterator, state
6. Lý do sử dụng
● Lý do sử dụng state: sử dụng state chong lưu trạng thái của kíp dạy để có thể dễ
dàng thay đổi trạng thái và hành vi đối với từng trạng thái riêng biệt. giúp cho việc
mở rộng thêm hoặc thay đổi chức năng cho từng trạng thái nghỉ dạy hay đi dạy
riêng hoặc lịch chưa đến. Giúp cho nhà phát triển dễ dàng cập nhật code.
● Lý do sử dụng iterator: để có thể dễ dàng truy cập được hết các phần tử theo lần
lượt mà không cần lưu hết toàn bộ danh sách mà vẫn có thể hiển thị danh sách.
Đặc biệt khi ta thay đổi cấu trúc của kip thì ta cũng không cần thay đổi code của
KipIter()
II. Module trả công cho giảng viên theo tuần, tháng, đợt

Người thiết kế: Nguyễn Văn Bến

Mã sinh viên: B19DCCN065

1. Thiết kế giao diện biểu đồ lớp

● Tầng giao diện gồm các trang: GDChinhQL, GDChonGV, GDTraCong
● Tầng xử lý truy cập dữ liệu: DAO, GiangVienDAO, LuongDAO,
HoaDonDAO, LuongControl, HoaDonBuild
● Các lớp thực thể liên quan
2. Biểu đồ hoạt động
1) Tại giao diện chính của quản lý, quản lý chọn chấm công cho giảng viên

2) Trang GDChinhQL gọi GDChonGV

3) GDChonGV gọi lớp GiangVienDAO yêu cầu tìm danh sách của giảng viên

4) Lớp GiangVienDAO gọi hàm getdsGiangVien()

5) Hàm getdsGiangVien() gọi lớp GiangVien để đóng gói thông tin

6) Lớp GiangVien đóng gói thông tin thực thể

7) Lớp GiangVien trả về cho hàm getdsGiangVien()

8) Lớp GiangVienDAO trả về cho giao diện để hiển thị

9) GDChonGV hiên thị danh sách giảng viên

10) Quản lý click chọn giảng viên

11) GDChonGV gọi GDTraCong

12) GDTraCong gọi lớp LuongDAO

13) Lớp LuongDAO gọi hàm getLuong()

14) Hàm getLuong() gọi lớp Luong để đóng gói dữ liệu

15) Lớp Luong đóng gói dữ liệu

16) Lớp Luong trả về cho hàm getLuong()

17) Lớp LuongDAO trả về cho GDTraCong để hiển thị

18) GDTraCong hiển thị

19) GDTraCong gọi lớp LuongControl

20) Lớp LuongControl gọi hàm khởi tạo LuongControl()

21) Lớp LuongControl trả về cho GDTraCong

22) GDTraCong gọi lớp HoaDonBuild

23) Lớp HoaDonBuild gọi hàm khởi tạo HoaDonBuild()

24) Lớp HoaDonBuild trả về cho GDTraCong

 25) Quản lý chọn trả lương

26) GDTraCong gọi lớp LuongControl

27) Lớp LuongControl gọi hàm traluong()

28) Hàm traluong() trả về 1 hóa đơn

29) Lớp LuongControl trả về cho GDTraCong

30) GDTraCong gọi lớp HoaDonDAO

31) Lớp HoaDonDAO gọi hàm addHoaDon()

32) Hàm addHoaDon() thực hiện thêm hóa đơn vào cơ sở dữ liệu

3. Biểu đồ tuần tự
4. Biểu đồ giao tiếp
 5. Các pattern được sử dụng: Strategy, builder
6. Lý do sử dụng:
● Strategy pattern: Vì mỗi nhân viên có một cách tính lương khác nhau và có thể
thay đổi cách tính lương nên e chon strategy pattern để có thể dễ dàng đổi cách
tính lương mà không phải sửa lại code mà còn có thể hỗ trợ nhiều cách tính
lương cùng một lúc
● Builder pattern: Vì hóa đơn mỗi lần trả lương cho nhân viên có rất nhiều thuộc
tính phức tạp vì vậy e chọn builder pattern để tạo hóa đơn hạn chế gây lỗi mà
sau này còn có thể dễ dàng thay đổi hóa đơn nếu muốn thay đổi.

III. Module cho giáo viên đăng ký dạy :

-Người thực hiện : Trần Anh Đức - B19DCCN199
1. Hoạt động của module
-Giáo viên đăng nhập vào hệ thống

-Chỉnh sửa thông tin cá nhân

-Giáo viên đăng ký dạy theo môn dạy :
Hệ thống sẽ hiển thị lịch sử đăng ký dạy của giáo viên.
2. Kiến trúc thiết kế
3. Pattern sử dụng
Sử dụng pattern template

4. Lý do
 Bởi vì module đăng ký có nhiệm vụ chủ yếu là thêm, sửa, xóa lịch dạy của giáo viên
cho nên những hành động này sẽ được tái sử dụng rất nhiều lần. Vì vậy ta sẽ thêm
những hành động này vào một lớp abstract để có thể tái sử dụng nhiều lần.
IV.Module lên lịch dạy chính thức cho giáo viên
1.Hoạt động của module
-Giáo viên đăng nhâp :

-Chọn chức năng xem thời khóa biểu :

Hệ thống hiển thị ra lịch dạy của giáo viên

2.Kiến trúc thiết kế :
3.Design Pattern
-Không sử dụng pattern nào cả
 ● Học viên đăng kí học (Nguyễn Viết Huy B19DCCN315)
- Giao diện :

- Mô tả :
+ Học viên có thể vào trong trang đăng kí học, chọn khóa học, lịch học theo ý
muốn.

- Vấn đề :
+ Với mỗi cơ sở dữ liệu khác nhau, sẽ có những câu lệnh truy vấn khác nhau,
do đó ta cần một lớp có thể bao bọc quá trình tạo lệnh truy vấn và thực thi câu
lệnh kết quả bởi DAO.

- Mẫu thiết kế sử dụng (Builder) :

 + Các IQueryBuilder định nghĩa một giao diện để bao bọc việc tạo các lệnh
truy vấn.
+ Các lớp thừa kế IQueryBuilder như SQLQueryBuilder,
MySQLQueryBuilder sẽ được implement từ IQueryBuilder, mỗi khai triển sẽ
có cách cài đặt lệnh khác nhau.
+ Các phương thức mà IQueryBuilder cung cấp như select(String),
insert(String), where(String) sẽ được dùng để xây dựng truy vấn.
Kết quả sẽ được lấy ra bằng build().

- Sơ đồ lớp :

- Sơ đồ hoạt động :
 ● Học viên thanh toán học phí (Nguyễn Viết Huy B19DCCN315)
- Giao diện :

- Mô tả :
 + Học viên sau khi đăng kí các khóa học sẽ cần thanh toán lệ phi mà khóa học
quy định.
+ Học viên có thể sẽ sử dụng những loại hình thức thanh toán học phí khác
nhau..

- Vấn đề :
+ Ban đầu chỉ có phương thức thanh toán thông qua thẻ tín dụng, ta chỉ việc
viết thuật toán này ở bất kỳ chỗ nào cần sử dụng.
+ Nhưng sau này khi yêu cầu tăng lên như phải hỗ trợ thêm việc thanh toán
qua nhiều phương thức khác (Ví dụ Paypal) sẽ dẫn đến phải thay đổi thuật
toán ở những chỗ đã sử dụng. Việc thay đổi thuật toán liên tục sẽ dẫn tới hậu
quả khiến chương trình trở nên khó maintain và gây nên những bug trên
những phần đang hoạt động tốt.

- Mẫu thiết kế sử dụng (Strategy) :

+ Ta cần tạo cho mỗi thuật toán thanh toán trong một class riêng gọi là
strategy. Phần code gọi tới các strategy sẽ không cần biết chi tiết về loại
strategy mà nó sử dụng, nó có thể sử dụng mọi strategy với interface được
cung cấp.
+ Với phần thuật toán được tách biệt khỏi phần sử dụng, điều này sẽ giúp
chương trình dễ bảo trì và phát hiện lỗi.

- Sơ đồ lớp :
- Mô tả hoạt động khái quát :
Khi MakePaymentController được yêu cầu xử lí request thanh toán từ người
dùng. Nó sẽ gọi hàm makePayment() từ IPaymentStrategy với tham số đầu
vào là một lớp PaymentModel được cung cấp bởi người dùng.
IPaymentStrategy sẽ kiểm tra kiểu lớp khai triển của IPaymentModel. Tùy
vào đó mà nó sẽ gọi những IPaymentService phù hợp.
Kết quả trả về là true khi thành công (và ngược lại). Nếu thanh toán thành
công, MakePaymentController sẽ thực hiện các tác vụ thêm như xuất hóa đơn,
xử lí CSDL, thông báo, v.v…

- Sơ đồ hoạt động :