Trong thời đại ngày nay việc ứng dụng tin học vào cuộc sống đã trở thành nhu cầu buôn bán là điều cần thiết của con người. Với sự phát triển mạnh mẽ của công nghệ thông tin làm cho tin học không còn xa lạ đối với mỗi chúng ta. Máy tính cùng với các công nghệ khác đã giúp con người xử lý công việc nhanh chóng và hiệu quả, do đó các chương trình quản lý bán hàng đã ra đời.Từ thực tế, một cửa hàng muốn kinh doanh hiệu quả và mở rộng quy mô thì vấn đề quản lý mua bán trở nên cấp thiết, xuất phát từ nhu cầu đó việc xây dựng phần mềm để quản lý mua bán để thuận tiện cho việc quản lý kinh doanh là rất cần thiết đối với mỗi chủ kinh doanh. Để làm một phầm mềm quản lý, việc đầu tiên cần làm là phải phân tích và thiết kế hệ thống. Vì thế, em đã chọn đề tài “Phân tích thiết kế hệ thống thông tin phần mềm quản lý bán Pizza” làm đề tài lần này.Trong khuôn khổ của đồ án môn học và thời gian cho phép, đồ án của em sẽ có những điểm chưa hoàn thiện. Sau này nếu có điều kiện và thời gian cho phép, đồ án này sẽ được mở rộng và phát triển hoàn thiện hơn, để có thể ứng dụng hiệu quả cho việc quản lý mua bán, đặc biệt là quản lý quán pizza.1.Giới thiệu1.1.Lý do chọn đề tàiĐời sống ngày càng nâng cao nên nhu cầu trao đổi, buôn bán hàng hóa ngày càng tăng. Việc quản lý hàng hóa, ghi chép hóa đơn một cách thủ công không mấy khả quan, rất dễ xảy ra sai sót trong khâu quản lý, thống kê, chính vì thế các chương trình quản lý được viết ra nhằm phục vụ nhu buôn bán của con người. Tuy nhiên, để viết được một chương trình áp dụng vào thực tiễn đều phải trải qua giai đoạn phân tích thiết kế hệ thống, để hiểu rõ về cách hoạt động, từng bước xây dựng một chương trình hoàn chỉnh. Thế nên em chọn đề tài phân tích thiết kế hệ thống phần mềm quản lý quán pizza lần này để hiểu rõ thêm về bước đầu xây dựng chương trình.1.2.Mục tiêu nghiên cứuPhân tích các chức năng trong hệ thống để thiết kế chương trình một cách có trình tự và hoàn thiện.Công việc cụ thể:•Mô tả được các chức năng có trong hệ thống•Thiết kế mô hình phát triển phần mềm•Thiết kế sơ đồ Usecase•Thiết kế sơ đồ Class•Thiết kế lược đồ cơ sở dữ liệu với những quan hệ chặt chẽ•Thiết kế sơ đồ trình tự•Thiết kế sơ đồ hoạt động•Xây dựng chương trình, hệ thống form va menu.1.3.Phương tháp nghiên cứu•Tìm hiểu, nghiên cứu tài liệu cụ thể để phân tích hệ thống•Học cách sử dụng starUML để vẽ sơ đồ•Tham khảo những bản vẽ có sẵn để cải tiến, áp dụng vào bản vẽ bản thân2.Tìm hiểu lý thuyết2.1.Phân tích thiết kế hệ thống thông tinPhân tích thiết kế hệ thống thông tin là phương pháp luận để xây dựng và phát triển hệ thống thông tin bao gồm các lý thuyết, mô hình, phương pháp và các công cụ sử dụng trong quá trình phân tích và thiết kế hệ thống.Thứ tự các giai đoạn phát triển hệ thống gồm:•Giai đoạn khảo sát, tìm hiểu nhu cầu hệ thống nhằm xác định hệ thống được lập ra đáp ứng nhu cầu gì của người dùng.•Giai đoạn phân tích nhằm đi sâu chi tiết vào các chức năng và dữ liệu của hệ thống, cho biết hệ thống phải làm gì.•Giai đoạn thiết kế nhằm đưa ra các quyết định về cài đặt hệ thống, để sao cho hệ thống vừa thoả mãn các các yêu cầu mà giai đoạn phân tích đã đưa ra đồng thời chú trọng đến khả năng thích ứng với các ràng buộc trong thực tế, mang tính khả thi dù phải thoả hiệp một số các tiêu chuẩn nhất định.•Giai đoạn cài đặt bao gồm công việc chính là lập trình và kiểm sửa. Đây là giai đoạn chuyển các kết quả phân tích thiết kế thành các sản phẩm ứng dụng.•Giai đoạn khai thác và bảo trì là triển khai hệ thống vào sử dụng đồng thời hiệu chỉnh các sai lỗi và thay đổi khi phát hiện những chỗ chưa thích hợp.2.1.1.Mô tả hệ thốngNhận thức và mô tả các chức năng có trong hệ thống, thường dùng cho các mô hình, các biểu đồ để trừu tượng hoá và là công cụ giúp con người trao đổi với nhau trong quá trình phát triển hệ thống. Mỗi mô hình là một khuôn dạng để nhận thức về hệ thống và nó mang ý thức chủ quan.2.1.2.Mô hình UsecaseKhái niệm•Use case là kỹ thuật được dùng trong kỹ thuật phần mềm và hệ thống nhằm nắm bắt những yêu cầu chức năng của hệ thống. Use case mô tả sự tương tác đặc trưng giữa người dùng bên ngoài (actor) và hệ thống. Use case cũng mô tả các yêu cầu đối với hệ thống.•Mỗi Use case sẽ mô tả cách thức người dùng bên ngoài tương tác với hệ thống để đạt được mục tiêu nào đó. Một hoặc nhiều kịch bản (scenario) có thể được tạo ra từ mỗi use case, tương ứng với chi tiết về mỗi cách thức đạt được mục tiêu nào đó. Khi mô tả Use case, người ta thường tránh dùng thuật ngữ kỹ thuật, thay vào đó họ sử dụng ngôn ngữ của người dùng cuối hoặc chuyên gia về lĩnh vực đó. Để tạo ra use case, cần phải có sự hợp tác chặt chẽ giữa người phân tích hệ thống và người dùng cuối. Một trong những cách biểu diễn trực quan phổ biến hiện nay là lược đồ use case của UML.•Use case thường được đặt tên giống động từ hoặc động từ + cụm danh từ. Đặc điểm của tên Use case là ngắn gọn, cụ thể và miêu tả đầy đủ nghĩa của đối tượng người dùng. Những động từ như “do”, “perform”, các danh từ như ”data”, “information” nên tránh nếu có thể.•Người dùng sử dụng Use case để đại diện cho các nghiệp vụ trong hệ thống.Các thành phần UseCaseActor: để chỉ người sử dụng hoặc một đối tượng nào đó bên ngoài tương tác với hệ thống.Các quan hệ trong Use case:•Use case «include»: Một Use case (gọi là base Use case) có thể chứa («include») chức năng của một Use case khác (gọi là inclusion Use case) như một phần xử lý của nó. Nói chung, nó giả sử rằng mọi Use case «include» sẽ được gọi mỗi khi tuyến Use case chính chạy. Quan hệ này còn gọi là quan hệ sử dụng «uses». Ví dụ, việc thực thi Use case Card Identification (Xác nhận thẻ) là một phần của Use case Withdraw (Rút tiền). Khi thực thi Use case Withdraw, Use case Card Identification sẽ được gọi.•Use case «extend»: Một Use case mở rộng (gọi là extension Use case) có thể được mở rộng («extend») hành vi từ một Use case khác (gọi là base Use case); điều này thường dùng cho các trường hợp tùy chọn, ngoại lệ, chèn thêm vào … Ví dụ, nếu trước khi thay đổi một kiểu đặt hàng cụ thể (Modify Order), người dùng có thể phải nhận được sự chấp thuận (Get Approval) từ cấp phân quyền cao hơn, thì Use case Get Approval có thể tùy chọn mở rộng («extend») Use case Modify Order thông thường.•Use case Generalizations: Một quan hệ generalization có giữa một Use case cụ thể hơn (specifilized) đến với một Use case tổng quát hơn (generalized). Một generalized có thể cụ thể hóa thành nhiều specifilized, một specifilized cũng có thể được cụ thể hóa từ nhiều generalized. Một quan hệ generalization giữa các Use case trình bày thành một đường đặc từ specifilized đến generalized, với đầu mũi tên là một tam giác rỗng chỉ generalized. Tránh nhằm lẫn với quan hệ phụ thuộc «extend».2.1.3.Biểu đồ hoạt độngGiới thiệuBiểu đồ hoạt động là biểu đồ mô tả 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. Đối với những luồng thực thi có nhiều tiến trình chạy song song thì biểu đồ hoạt động là sự lựa chọn tối ưu cho việc thể hiện. Biểu đồ hoạt động khá giống với biểu đồ trạng thái ở tập các kí hiệu nên rất dễ gây nhầm lẫn. Khi vẽ chúng ta cần phải xác định rõ điểm khác nhau giữa hai dạng biểu đồ này là biểu đồ hoạt động tập trung mô tả các hoạt động và kết qủa thu được từ việc thay đổi trạng thái của đối tượng còn biểu đồ trạng thái chỉ mô tả tập tất cả các trạng thái của một đối tượng và những sự kiện dẫn tới sự thay đổi qua lại giữa các trạng thái đó.
LỜI MỞ ĐẦU Trong thời đại ngày việc ứng dụng tin học vào sống trở thành nhu cầu buôn bán điều cần thiết người Với phát triển mạnh mẽ công nghệ thông tin làm cho tin học khơng cịn xa lạ Máy tính với cơng nghệ khác giúp người xử lý công việc nhanh chóng hiệu quả, chương trình quản lý bán hàng đời Từ thực tế, cửa hàng muốn kinh doanh hiệu mở rộng quy mơ vấn đề quản lý mua bán trở nên cấp thiết, xuất phát từ nhu cầu việc xây dựng phần mềm để quản lý mua bán để thuận tiện cho việc quản lý kinh doanh cần thiết chủ kinh doanh Để làm phầm mềm quản lý, việc cần làm phải phân tích thiết kế hệ thống Vì thế, em chọn đề tài “Phân tích thiết kế hệ thống thông tin phần mềm quản lý bán Pizza” làm đề tài lần Trong khuôn khổ đồ án môn học thời gian cho phép, đồ án em có điểm chưa hồn thiện Sau có điều kiện thời gian cho phép, đồ án mở rộng phát triển hồn thiện hơn, để ứng dụng hiệu cho việc quản lý mua bán, đặc biệt quản lý quán pizza MỤC LỤC Contents LỜI CẢM ƠN LỜI MỞ ĐẦU CHƯƠNG I: CƠ SỞ LÝ THUYẾT 10 Giới thiệu .10 1.1 Lý chọn đề tài 10 1.2 Mục tiêu nghiên cứu 10 1.3 Phương tháp nghiên cứu 10 Tìm hiểu lý thuyết 10 2.1 Phân tích thiết kế hệ thống thơng tin 11 2.2 Giới thiệu Ngơn ngữ lập trình 26 CHƯƠNG II: PHÂN TÍCH THIẾT KẾ HỆ THỐNG THÔNG TIN PHẦN MỀM QUẢN LÝ QUÁN PIZZA 27 Mô tả hệ thống .27 Sơ đồ Usecase 27 Sơ đồ Class 30 Lược đồ sở liệu quan hệ .31 4.1 Lược đồ CSDL quan hệ 31 4.2 Câu lệnh truy vấn SQL .32 CHƯƠNG III: XÂY DỰNG PHẦN MỀM QUẢN LÝ QUÁN PIZZA 34 Hệ thống menu .34 - Thanh menu bên gốc trái gồm: Quản lý chung, quản lý hóa đơn Thốt chương trình .34 Các Trang/Form 34 Một số code (đối với mơn lập trình) .38 KẾT LUẬN .42 DANH MỤC CÁC HÌNH Hình Actor 13 Hình Use case 14 Hình Trạng thái khởi tạo 15 Hình Trạng thái hoạt động 15 Hình Nút định rẻ nhánh 16 Hình Thanh đồng kết hợp 16 Hình Thanh đồng chia nhánh .16 Hình Cạnh gián đoạn 17 Hình Luồng hoạt động 17 Hình 10 Thời gian kiện 17 Hình 11 Gửi nhận tín hiệu .17 Hình 12 Trạng thái kết thức 18 Hình 13 Đối tượng .18 Hình 14 Đường đời đối tượng 18 Hình 15 Thông điệp .19 Hình 16 Xử lý bên đối tượng 19 Hình 17 Thông điệp đồng .19 Hình 18 Thơng điệp không đồng 20 Hình 19 Thơng điệp 20 Hình 20 Thơng điệp trả lời trở 20 Hình 21 Thơng điệp tạo 20 Hình 22 Thơng điệp xóa 21 Hình 23 Các thành phần lớp 22 Hình 24 Liên kết 22 Hình 25 Bội số quan hệ 23 Hình 26 Biểu diễn bội số quan hệ kết tập 24 Hình 27 Minh họa mối liên kết Part Whole bị bỏ .24 Hình 28 Access Modifier .25 Hình 29 Relationship 26 Hình 30 Multiplicity 27 Hình 31 Usecase Tổng quát 29 Hình 32 Usecase Quản lý khách hàng 29 Hình 33 Usecase quản lý ăn 30 Hình 34 Usecase Quản lý nhân viên 30 Hình 35 Usecase Quản lý hóa đơn .31 Hình 36 Sơ đồ class hệ thống quản lý quán pizza .32 Hình 37 Lược đồ CSDL quan hệ 33 Hình 38 Form .35 Hình 39 Form Loại 36 Hình 40 Form Món ăn 36 Hình 41 Form Khách hàng 37 Hình 42 Form Nhân viên .37 Hình 43 Form Hóa đơn 38 Hình 44 Tìm kiếm hóa đơn 38 CHƯƠNG I: CƠ SỞ LÝ THUYẾT Giới thiệu 1.1 Lý chọn đề tài Đời sống ngày nâng cao nên nhu cầu trao đổi, bn bán hàng hóa ngày tăng Việc quản lý hàng hóa, ghi chép hóa đơn cách thủ công không khả quan, dễ xảy sai sót khâu quản lý, thống kê, chương trình quản lý viết nhằm phục vụ nhu buôn bán người Tuy nhiên, để viết chương trình áp dụng vào thực tiễn phải trải qua giai đoạn phân tích thiết kế hệ thống, để hiểu rõ cách hoạt động, bước xây dựng chương trình hồn chỉnh Thế nên em chọn đề tài phân tích thiết kế hệ thống phần mềm quản lý quán pizza lần để hiểu rõ thêm bước đầu xây dựng chương trình 1.2 Mục tiêu nghiên cứu Phân tích chức hệ thống để thiết kế chương trình cách có trình tự hồn thiện Cơng việc cụ thể: Mơ tả chức có hệ thống Thiết kế mơ hình phát triển phần mềm Thiết kế sơ đồ Usecase Thiết kế sơ đồ Class Thiết kế lược đồ sở liệu với quan hệ chặt chẽ Thiết kế sơ đồ trình tự Thiết kế sơ đồ hoạt động Xây dựng chương trình, hệ thống form va menu 1.3 Phương tháp nghiên cứu Tìm hiểu, nghiên cứu tài liệu cụ thể để phân tích hệ thống Học cách sử dụng starUML để vẽ sơ đồ Tham khảo vẽ có sẵn để cải tiến, áp dụng vào vẽ thân Tìm hiểu lý thuyết 2.1 - Phân tích thiết kế hệ thống thơng tin Phân tích thiết kế hệ thống thơng tin phương pháp luận để xây dựng phát triển hệ thống thông tin bao gồm lý thuyết, mơ hình, phương pháp cơng cụ sử dụng q trình phân tích thiết kế hệ thống - Thứ tự giai đoạn phát triển hệ thống gồm: Giai đoạn khảo sát, tìm hiểu nhu cầu hệ thống nhằm xác định hệ thống lập đáp ứng nhu cầu người dùng Giai đoạn phân tích nhằm sâu chi tiết vào chức liệu hệ thống, cho biết hệ thống phải làm Giai đoạn thiết kế nhằm đưa định cài đặt hệ thống, để cho hệ thống vừa thoả mãn các yêu cầu mà giai đoạn phân tích đưa đồng thời trọng đến khả thích ứng với ràng buộc thực tế, mang tính khả thi dù phải thoả hiệp số tiêu chuẩn định Giai đoạn cài đặt bao gồm công việc lập trình kiểm sửa Đây giai đoạn chuyển kết phân tích thiết kế thành sản phẩm ứng dụng Giai đoạn khai thác bảo trì triển khai hệ thống vào sử dụng đồng thời hiệu chỉnh sai lỗi thay đổi phát chỗ chưa thích hợp 2.1.1 - Mô tả hệ thống Nhận thức mô tả chức có hệ thống, thường dùng cho mơ hình, biểu đồ để trừu tượng hố cơng cụ giúp người trao đổi với trình phát triển hệ thống Mỗi mơ hình khn dạng để nhận thức hệ thống mang ý thức chủ quan 2.1.2 Mơ hình Use-case Khái niệm Use case là kỹ thuật dùng kỹ thuật phần mềm hệ thống nhằm nắm bắt những yêu cầu chức hệ thống Use case mô tả tương tác đặc trưng người dùng bên ngồi (actor) hệ thống. Use case cũng mơ tả u cầu hệ thống Mỗi Use case mơ tả cách thức người dùng bên ngồi tương tác với hệ thống để đạt mục tiêu Một nhiều kịch (scenario) tạo từ use case, tương ứng với chi tiết cách thức đạt mục tiêu Khi mơ tả Use case, người ta thường tránh dùng thuật ngữ kỹ thuật, thay vào họ sử dụng ngôn ngữ người dùng cuối chuyên gia lĩnh vực Để tạo use case, cần phải có hợp tác chặt chẽ người phân tích hệ thống người dùng cuối Một cách biểu diễn trực quan phổ biến lược đồ use case UML Use case thường được đặt tên giống động từ hoặc động từ + cụm danh từ. Đặc điểm tên Use case là ngắn gọn, cụ thể miêu tả đầy đủ nghĩa đối tượng người dùng Những động từ “do”, “perform”, danh từ ”data”, “information” nên tránh Người dùng sử dụng Use case để đại diện cho nghiệp vụ hệ thống Các thành phần UseCase Actor: để người sử dụng đối tượng bên ngồi tương tác với hệ thống Hình Actor Use case: là chức mà Actor sử dụng - Hình Use case Các quan hệ Use case: Use case «include»: Một Use case (gọi base Use case) chứa («include») chức Use case khác (gọi inclusion Use case) phần xử lý Nói chung, giả sử Use case «include» gọi tuyến Use case chạy Quan hệ cịn gọi quan hệ sử dụng «uses» Ví dụ, việc thực thi Use case Card Identification (Xác nhận thẻ) phần Use case Withdraw (Rút tiền) Khi thực thi Use case Withdraw, Use case Card Identification gọi Use case «extend»: Một Use case mở rộng (gọi extension Use case) mở rộng («extend») hành vi từ Use case khác (gọi base Use case); điều thường dùng cho trường hợp tùy chọn, ngoại lệ, chèn thêm vào … Ví dụ, trước thay đổi kiểu đặt hàng cụ thể (Modify Order), người dùng phải nhận chấp thuận (Get Approval) từ cấp phân quyền cao hơn, Use case Get Approval tùy chọn mở rộng («extend») Use case Modify Order thông thường Use case Generalizations: Một quan hệ generalization có Use case cụ thể (specifilized) đến với Use case tổng quát (generalized) Một generalized cụ thể hóa thành nhiều specifilized, specifilized cụ thể hóa từ nhiều generalized Một quan hệ generalization Use case trình bày thành đường đặc từ specifilized đến generalized, với đầu mũi tên tam giác rỗng generalized Tránh nhằm lẫn với quan hệ phụ thuộc «extend» 2.1.3 Biểu đồ hoạt động Giới thiệu Biểu đồ hoạt động biểu đồ mô tả bước thực hiện, hành động, nút định điều kiện rẽ nhánh để điều khiển luồng thực hệ thống Đối với luồng thực thi có nhiều tiến trình chạy song song biểu đồ hoạt động lựa chọn tối ưu cho việc thể Biểu đồ hoạt động giống với biểu đồ trạng thái tập kí hiệu nên dễ gây nhầm lẫn Khi vẽ cần phải xác định rõ điểm khác hai dạng biểu đồ biểu đồ hoạt động tập trung mô tả hoạt động kết qủa thu từ việc thay đổi trạng thái đối tượng biểu đồ trạng thái mô tả tập tất trạng thái đối tượng kiện dẫn tới thay đổi qua lại trạng thái Các thành phần biểu đồ hoạt động Trạng thái khởi tạo điểm bắt đầu (Initial State or Start Point) Hình Trạng thái khởi tạo Hoạt động trạng thái hoạt động (Activity or Action State): Hoạt động chuyển đổi hoạt động ký hiệu cách sử dụng hoàn toàn giống trạng thái biểu đồ trạng thái nêu Hình Trạng thái hoạt động Nút định rẽ nhánh: Nút rẽ nhánh biểu đồ hoạt động kí hiệu hình thoi màu trắng Hình Nút định rẻ nhánh Thanh tương tranh hay đồng bộ: Có thể có nhiều luồng hành động bắt đầu thực hay kết thúc đồng thời hệ thống - Thanh đồng kết hợp: Hình Thanh đồng kết hợp - Thanh đồng chia nhánh: Hình Thanh đồng chia nhánh Cạnh gián đoạn (Interrupting Edge) Hình Cạnh gián đoạn Luồng hoạt động (Action Folow) Hình Luồng hoạt động Phân (Swimlanes): Phân biểu đồ sử dụng đường nét đứt thẳng đứng theo đối tượng Phần kí hiệu thường sử dụng để làm rõ luồng hoạt động đối tượng riêng biệt Thời gian kiện (Time Event) Hình 10 Thời gian kiện Gửi nhận tín hiệu (Sent and Received Signals) Hình 11 Gửi nhận tín hiệu Trạng thái kết thúc điểm cuối (Final State or End Point) 10