1. Trang chủ
  2. » Luận Văn - Báo Cáo

Phân tích thiết kế hệ thống quản lý nhà hàng bằng UML (unified modeling language)

74 1,7K 11

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

THÔNG TIN TÀI LIỆU

Thông tin cơ bản

Định dạng
Số trang 74
Dung lượng 1,67 MB

Nội dung

Với mong muốn góp phần vào sự phát triển của Công nghệ Thông tin nước nhà, tôi xây dựng đề tài: Phân tích thiết kế Hệ thống quản lý Nhà hàng bằng UML Unified Modeling Language, cho kho

Trang 1

BỘ GIÁO DỤC VÀ ĐÀO TẠO TRƯỜNG ĐẠI HỌC SƯ PHẠM HÀ NỘI 2

KHOA TIN HỌC

-O0

O -NGUYỄN HOÀNG TIẾN

PHÂN TÍCH THIẾT KẾ HỆ THỐNG QUẢN LÝ NHÀ HÀNG BẰNG

UML (UNIFIED MODELING LANGUAGE)

KHOÁ LUẬN TỐT NGHIỆP ĐẠI HỌC

Chuyên ngành: Tin học

Hà Nội, 5/2009

Trang 2

LỜI CẢM ƠN

Là một sinh viên chuyên ngành Tin học Với mong muốn góp phần vào

sự phát triển của Công nghệ Thông tin nước nhà, tôi xây dựng đề tài: Phân

tích thiết kế Hệ thống quản lý Nhà hàng bằng UML (Unified Modeling

Language), cho khoá luận tốt nghiệp Nhưng để hoàn thành được đề tài, tôi

đã nhận được ủng hộ, giúp đỡ của gia đình, các thầy cô trong Khoa, cùng bạn

bè Vì vậy, lời đầu tiên tôi xin chân thành cảm ơn gia đình, các thầy cô, bạn

bè; đặc biệt là thầy Tiến sĩ Trịnh Đình Thắng - giảng viên chính khoa Tin

học, trường ĐHSP Hà Nội 2, thầy hướng dẫn tôi hoàn thành đề tài này; trong suốt thời gian qua, thầy đã nhiệt thành hướng dẫn không bởi trách nhiệm mà còn cả tấm lòng của người thầy, người thân trong gia đình

Một lần nữa tôi xin chân thành cảm ơn!

Hà Nội, tháng 05 năm 2009

Sinh viên

Nguyễn Hoàng Tiến

Trang 3

LỜI CAM ĐOAN Tôi xin cam đoan đây là công trình nghiên cứu của riêng tôi

Các số liệu, kết quả nghiên cứu trong khoá luận là hoàn toàn chân thực

và không trùng với kết quả nghiên cứu của các tác giả khác

Nếu sai tôi xin hoàn toàn chịu trách nhiệm

Hà Nội, tháng 05 năm 2009

Sinh viên

Nguyễn Hoàng Tiến

Trang 4

MỤC LỤC

Trang

LỜI CẢM ƠN

LỜI CAM ĐOAN

Phần I MỞ ĐẦU 1

1 Lý do chọn đề tài 2

2 Mục đích nghiên cứu 3

3 Đối tượng, khách thể, phạm vi nghiên cứu 3

4 Giả thiết khoa học 4

5 Nhiệm vụ nghiên cứu 4

6 Phương pháp nghiên cứu 5

Phần II NỘI DUNG 6

Chương 1: Cơ sở lý luận 7

1.1 Mô tả Chu trình Phát triển Phần mềm 7

1.1.1 Software Development – Một bài toán phức tạp 7

1.1.2 Chu trình Phát triển Phần mềm (Software Development Life Cycle) 8

1.1.3 Các giai đoạn của Chu trình Phát triển Phần mềm 10

1.2 Phương pháp hướng chức năng và phương pháp hướng đối tượng 11

1.2.1 Phương pháp hướng chức năng 11

1.2.2 Phương pháp hướng đối tượng 12

1.3 Giới thiệu UML 13

1.3.1 Sự ra đời của UML 13

1.3.2 UML (Unified Modeling Language) 14

1.3.3 Các thành phần của UML 15

1.3.4 UML trong phân tích thiết kế hệ thống 16

1.4.Rational Rose là gì? 17

Trang 5

Chương 2: Khảo sát Hệ thống quản lý Nhà hàng 18

2.1 Khảo sát tiến trình tác nghiệp 18

2.2 Phân tích lĩnh vực 25

Chương 3: Phân tích thiết kế Hệ thống quản lý Nhà hàng 34

3.1 Phân tích hệ thống 34

3.1.1 Gói và biểu đồ Use case (UC) kho - bếp 34

3.1.2 Gói và biểu đồ Use case kế toán 38

3.1.3 Gói và biểu đồ Use case thu ngân 45

3.1.4 Gói và biểu đồ Use case quản trị hệ thống 48

3.2 Biểu đồ tương tác 50

3.2.1 Biểu đồ trình tự 50

3.2.2 Biểu đồ cộng tác 55

3.3 Biểu đồ lớp 57

3.4 Biểu đồ triển khai 63

3.5 Thiết kế giao diện 64

KẾT LUẬN VÀ NHỮNG KIẾN NGHỊ 68

TÀI LIỆU THAM KHẢO 69

Trang 6

Phần I MỞ ĐẦU

1 Lý do chọn đề tài

2 Mục đích nghiên cứu

3 Đối tượng, khách thể, phạm vi nghiên cứu

4 Giả thiết khoa học

5 Nhiệm vụ nghiên cứu

6 Phương pháp nghiên cứu

Trang 7

Nhà hàng mọc lên ngày càng nhiều Trước áp lực của cơ chế thị trường, các Nhà hàng vừa phải nâng cao chất lượng dịch vụ nhằm tăng sự cạnh tranh, đồng thời cũng phải giảm chi phí tới mức thấp nhất Một câu hỏi đặt ra, làm thế nào để tăng chất lượng dịch vụ mà không tăng chi phí lên quá cao? Nắm bắt được nhu cầu này, các công ty phần mềm đã vào cuộc Và một số Phần mềm quản lý ra đời đã và đang: Tiết kiệm thời gian, tiết kiệm chi phí, tạo nên phong cách quản lý chuyên nghiệp

Về phía nhà Phát triển Phần mềm, các công ty phần mềm; tuy đã đạt được thành công khá toàn diện nhưng để đáp ứng được nhu cầu của các nhà quản lý, các ông chủ nhà hàng, họ gặp phải nhiều khó khăn trong: Nắm bắt yêu cầu của khách hàng, khả năng nắm bắt các dữ liệu phức tạp của con người là có hạn, Đây cũng là khó khăn của nhiều nhà Phát triển Phần mềm trong nước cũng như ngoài nước Kinh nghiệm của nhiều nhà thiết kế và phát triển cho thấy Phát triển Phần mềm là một bài toán phức tạp

Trong bối cảnh trên, người ta nhận thấy cần thiết phải cung cấp một phương pháp tiếp cận được chuẩn hoá và thống nhất cho việc mô hình hoá hướng đối tượng Yêu cầu cụ thể là đưa ra một tập hợp chuẩn hoá các ký hiệu (Notation) và các biểu đồ (Diagram) để nắm bắt các quyết định về mặt thiết

kế một cách rõ ràng, rành mạch Đã có ba công trình tiên phong nhắm tới mục tiêu đó, chúng được thực hiện dưới sự lãnh đạo của James Rumbaugh, Grady Booch và Ivar Jacobson Chính những cố gắng này dẫn đến kết quả là xây

Trang 8

dựng được một Ngôn ngữ mô hình hoá thống nhất (Unified Modeling Language – UML)

Chính vì vậy, cần thiết phải sử dụng UML trong Phát triển Phần mềm nói chung và Phần mềm quản lý Nhà hàng nói riêng ở Việt Nam hiện nay

Là một sinh viên ngành Tin học Với những kiến thức đã được trang bị trong nhà trường Tôi cũng muốn góp phần vào sự phát triển của Công nghệ Thông tin, lĩnh vực phát triển Phầm mềm quản lý, nhất là các phần mềm các Phần mềm quản lý Nhà hàng

Vì vậy, tôi xây dựng tài liệu Phân tích thiết kế Hệ thống quản lý Nhà hàng dựa trên ngôn ngữ UML

2 Mục đích nghiên cứu

- Tìm hiểu chúng ta cần làm gì?

- Tạo cơ sở kí kết hợp đồng

- Cung cấp tài liệu đặc tả

- Tạo mô hình cài đặt của phần mềm

+ Là phương tiện trao đổi thông tin để đảm bảo chất lượng

+ Dễ hiểu, dễ sửa đổi hơn mã chương trình

+ Có nhiều mức chi tiết; cung cấp cái nhìn tổng thể

- Hỗ trợ trong việc từ phát triển, thiết kế cho tới thực hiện

3 Đối tƣợng, khách thể, phạm vi nghiên cứu

- Đối tượng: Tài liệu Phân tích thiết kế cho Phần mềm quản lý Nhà hàng bằng UML

- Khách thể: Các Nhà hàng, các nhà quản lý, các ông chủ nhà hàng và các tài liệu quản trị nhà hàng

- Phạm vi nghiên cứu: Xây dựng tài liệu Phân tích thiết kế hệ thống cho Phần mềm quản lý Nhà hàng

Trang 9

4 Giả thiết khoa học

- Hiện nay, các Phần mềm quản lý Nhà hàng chỉ được cung cấp bởi một

số ít nhà phát triển Nguyên nhân:

+ Kinh doanh Nhà hàng là một lĩnh vực mới mẻ với ngành Du lịch - Dịch vụ Việt Nam Lối kinh doanh và tư duy quản lý theo phương pháp truyền thống, không chuyên nghiệp Vì vậy, nhu cầu về các Phần mềm quản

lý là chưa hình thành hoặc chưa được quan tâm nhiều Nên chỉ có số ít các công ty phát triển phần mềm quan tâm, đi trước sự phát triển

+ Ngành Công nghệ Thông tin còn khá mới với Việt Nam, đặc biệt

là Phát triển Phần mềm Các công ty phát triển phần mềm thiếu kinh nghiệm, vốn, yếu về trình độ

+ Trong Phát triển Phần mềm thì tài liệu phân tích thiết kế, đặc tả

hệ thống là công việc đầu tiên và quyết định cho sự thành công của dự án phát triển phần mềm Nhưng chúng ta còn thiếu các chuyên gia về phân tích thiết

kế hệ thống, nhằm xây dựng tài liệu đủ, chính xác

- Trong tương lai, Việt Nam sẽ là một trong các quốc gia phát triển phần mềm Chúng ta có cơ sở để tin tưởng điều này: Thế hệ trẻ Việt Nam có tinh thần, trí tuệ khá vững vàng, nhanh nhạy với thời cuộc,…Họ chỉ thiếu về điều kiện làm việc; điều này sẽ được khắc phục dần cùng với sự phát triển của nền kinh tế

- Phân tích thiết kế hệ thống sẽ là một nghề phát triển Chính sự phát triển này, thực sự sẽ đưa Công nghệ Thông tin nước nhà lên một tầm cao mới

5 Nhiệm vụ nghiên cứu

- Khẳng định tính đúng đắn của việc sử dụng UML trong quy trình Phát triển Phần mềm Ở đây là quy trình Phát triển Phần mềm quản lý Nhà hàng

- Xây dựng các thành phần của ngôn ngữ UML cho Hệ thống quản lý Nhà hàng

Trang 11

Phần II NỘI DUNG

Chương 1: Cơ sở lý luận Chương 2: Khảo sát Hệ thống quản lý Nhà hàng Chương 3: Phân tích thiết kế Hệ thống quản lý Nhà hàng KẾT LUẬN VÀ NHỮNG KIẾN NGHỊ

TÀI LIỆU THAM KHẢO

Trang 12

Chương 1: Cơ sở lý luận 1.1 Mô tả Chu trình Phát triển Phần mềm

1.1.1 Software Development – Một bài toán phức tạp

Kinh nghiệm của nhiều nhà thiết kế và phát triển cho thấy Phát triển Phần mềm là một bài toán phức tạp Xin nêu một số các lý do thường được kể đến:

- Những người phát triển phần mềm rất khó hiểu cho đúng những gì người dùng cần

- Yêu cầu của người dùng thường thay đổi trong thời gian phát triển

- Yêu cầu thường được miêu tả bằng văn bản, dài dòng, khó hiểu, nhiều khi thậm chí mâu thuẫn

- Đội quân phát triển phần mềm, vốn là người "ngoài cuộc", rất khó nhận thức thấu đáo các mối quan hệ tiềm ẩn và phức tạp cần được thể hiện chính xác trong các ứng dụng lớn

- Khả năng nắm bắt các dữ liệu phức tạp của con người (tại cùng một thời điểm) là có hạn

- Khó định lượng chính xác hiệu suất của thành phẩm và thỏa mãn chính xác sự mong chờ từ phía người dùng

- Chọn lựa phần cứng và phần mềm thích hợp cho giải pháp là một trong những thách thức lớn đối với Designer

Phần mềm ngoài ra cần có khả năng thích ứng và mở rộng Phần mềm

được thiết kế tốt là phần mềm đứng vững trước những biến đổi trong môi trường, dù từ phía cộng đồng người dùng hay từ phía công nghệ Ví dụ phần mềm đã được phát triển cho một nhà băng cần có khả năng tái sử dụng cho một nhà băng khác với rất ít sửa đổi hoặc hoàn toàn không cần sửa đổi Phần mềm thoả mãn các yêu cầu đó được coi là phần mềm có khả năng thích ứng

Trang 13

Một phần mềm có khả năng mở rộng là phần mềm được thiết kế sao cho dễ phát triển theo yêu cầu của người dùng mà không cần sửa chữa nhiều

Chính vì vậy, một số các khiếm khuyết thường gặp trong Phát triển Phần mềm là:

- Hiểu không đúng những gì người dùng cần

- Không thể thích ứng cho phù hợp với những thay đổi về yêu cầu đối với hệ thống

- Các Module không khớp với nhau

- Phần mềm khó bảo trì, nâng cấp và mở rộng

- Phát hiện trễ các lỗ hổng của dự án

- Chất lượng phần mềm kém

- Hiệu năng của phần mềm thấp

- Các thành viên trong nhóm không biết được ai đã thay đổi cái gì, khi nào, ở đâu, tại sao phải thay đổi

1.1.2 Chu trình Phát triển Phần mềm (Software Development Life Cycle)

Vì phát triển phần mềm là một bài toán khó, nên có lẽ trước hết ta cần điểm qua một số các công việc căn bản của quá trình này Thường người ta hay tập hợp chúng theo tiến trình thời gian một cách tương đối, xoay quanh chu trình của một phần mềm, dẫn tới kết quả khái niệm Chu trình Phát triển Phần mềm (Software Development Life Cycle - SDLC) như sau:

Chu trình Phát triển Phần mềm là một chuỗi các hoạt động của nhà phân tích (Analyst), nhà thiết kế (Designer), người phát triển (Developer) và người dùng (User) để phát triển và thực hiện một hệ thống thông tin Những hoạt động này được thực hiện trong nhiều giai đoạn khác nhau

Nhà phân tích (Analyst): Là người nghiên cứu yêu cầu của khách

hàng/người dùng để định nghĩa một phạm vi bài toán, nhận dạng nhu cầu của

Trang 14

một tổ chức, xác định xem nhân lực, phương pháp và công nghệ máy tính có thể làm sao để cải thiện một cách tốt nhất công tác của tổ chức này

Nhà thiết kế (Designer): Thiết kế hệ thống theo hướng cấu trúc của

database, screens, forms và reports – quyết định các yêu cầu về phần cứng và phần mềm cho hệ thống cần được phát triển

Chuyên gia lĩnh vực (Domain Experts): Là những người hiểu thực

chất vấn đề cùng tất cả những sự phức tạp của hệ thống cần Tin học hoá Họ không nhất thiết phải là nhà lập trình, nhưng họ có thể giúp nhà lập trình hiểu yêu cầu đặt ra đối với hệ thống cần phát triển Quá trình phát triển phần mềm

sẽ có rất nhiều thuận lợi nếu đội ngũ làm phần mềm có được sự trợ giúp của

họ

Lập trình viên (Programmer): Là những người dựa trên các phân tích

và thiết kế để viết chương trình (Coding) cho hệ thống bằng ngôn ngữ lập trình đã được thống nhất

Người dùng (User): Là đối tượng phục vụ của hệ thống cần được phát

triển

Để cho rõ hơn, xin lấy ví dụ về một vấn đề đơn giản sau:

Người bình thường chúng ta khi nhìn một chiếc xe ô tô thường sẽ có một bức tranh từ bên ngoài như sau:

Vấn đề

Hình 1.1.2.1: Nhìn vấn đề ô tô của người bình thường

Trang 15

Chuyên gia lĩnh vực sẽ giúp nhà phân tích "trình bày lại" vấn đề như sau:

Hình 1.1.2.2: Nhìn vấn đề ô tô của chuyên gia phân tích

Chính vì sự trợ giúp của chuyên gia lĩnh vực có thể đóng vai trò rất quan trọng nên trong những giai đoạn đầu của quá trình phát triển phần mềm, kết quả phân tích nên được thể hiện sao cho dễ hiểu đối với các chuyên gia lĩnh vực Đây cũng là môt trong rất nhiều lý do khiến cho phương pháp hướng đối tượng được nhiều người hưởng ứng

1.1.3 Các giai đoạn của Chu trình Phát triển Phần mềm

Chu trình của một phần mềm có thể được chia thành các giai đoạn như sau:

- Nghiên cứu sơ bộ (Preliminary Investigation hay còn gọi là Feasibility Study)

- Phân tích yêu cầu (Analysis)

- Thiết kế hệ thống (Design of the System)

- Xây dựng phần mềm (Software Construction)

- Thử nghiệm hệ thống (System Testing)

- Thực hiện, triển khai (System Implementation)

- Bảo trì, nâng cấp (System Maintenance)

Trang 16

Sơ đồ tổng quát các giai đoạn của Chu trình Phát triển Phần mềm:

Hình 1.1.3: Sơ đồ tổng quát các giai đoạn của

có thể xảy ra với những hệ thống đó và cách hoạt động (ứng xử) của hệ thống

Trang 17

là ra sao Đây là lối tiếp cận xoay quanh dữ liệu và đã được áp dụng để tạo nên hàng ngàn hệ thống trong suốt nhiều năm trời

Lối tiếp cận xoay quanh dữ liệu là phương pháp tốt cho việc thiết kế ngân hàng dữ liệu và nắm bắt thông tin, nhưng nếu áp dụng cho việc thiết kế ứng dụng lại có thể khiến phát sinh nhiều khó khăn Một trong những thách thức lớn là yêu cầu đối với các hệ thống thường xuyên thay đổi Một hệ thống xoay quanh dữ liệu có thể dễ dàng xử lý việc thay đổi ngân hàng dữ liệu, nhưng lại khó thực thi những thay đổi trong nguyên tắc nghiệp vụ hay cách hoạt động của hệ thống

Phương pháp hướng đối tượng đã được phát triển để trả lời cho vấn đề

đó Với lối tiếp cận hướng đối tượng, chúng ta tập trung vào cả hai mặt của vấn đề: Thông tin và cách hoạt động

1.2.2 Phương pháp hướng đối tượng

Hướng đối tượng là thuật ngữ thông dụng hiện thời của ngành Công

nghiệp phần mềm Các công ty đang nhanh chóng tìm cách áp dụng và tích hợp công nghệ mới này vào các ứng dụng của họ Thật sự là đa phần các ứng dụng hiện thời đều mang tính hướng đối tượng Nhưng hướng đối tượng có nghĩa là gì?

Lối tiếp cận hướng đối tượng là một lối tư duy về vấn đề theo lối ánh

xạ các thành phần trong bài toán vào các đối tượng ngoài đời thực Với lối tiếp cận này, chúng ta chia ứng dụng thành các thành phần nhỏ, gọi là các đối tượng, chúng tương đối độc lập với nhau Sau đó, ta có thể xây dựng ứng dụng bằng cách chắp các đối tượng đó lại với nhau Hãy nghĩ đến trò chơi xây lâu đài bằng các mẩu gỗ Bước đầu tiên là tạo hay mua một vài loại mẩu gỗ căn bản, từ đó tạo nên các khối xây dựng căn bản của mình Một khi đã có các khối xây dựng đó, bạn có thể chắp ráp chúng lại với nhau để tạo lâu đài

Trang 18

Tương tự như vậy, một khi đã xây dựng một số đối tượng căn bản trong thế giới máy tính, bạn có thể chắp chúng lại với nhau để tạo ứng dụng của mình

Xin lấy một ví dụ đơn giản: Vấn đề rút tiền mặt tại nhà băng Các “mẩu gỗ” thành phần ở đây sẽ là ánh xạ của các đối tượng ngoài đời thực như tài khoản, nhân viên, khách hàng,…Và ứng dụng sẽ được sẽ được nhận diện cũng như giải đáp xoay quanh các đối tượng đó

1.3 Giới thiệu UML

1.3.1 Sự ra đời của UML

Đầu những năm 1980, ngành Công nghệ phần mềm chỉ có duy nhất một ngôn ngữ hướng đối tượng là Simula Sang nửa sau của thập kỷ 1980, các ngôn ngữ hướng đối tượng như Smalltalk và C++ xuất hiện Cùng với chúng, nảy sinh nhu cầu mô hình hoá các hệ thống phần mềm theo hướng đối tượng

Và một vài trong số những ngôn ngữ mô hình hoá xuất hiện những năm đầu thập kỷ 90 được nhiều người dùng là:

- Grady Booch’s Booch Modeling Methodology

- James Rambaugh’s Object Modeling Technique – OMT

- Ivar Jacobson’s OOSE Methodology

- Hewlett- Packard’s Fusion

- Coad and Yordon’s OOA and OOD

Mỗi phương pháp luận và ngôn ngữ trên đều có hệ thống ký hiệu riêng, phương pháp xử lý riêng và công cụ hỗ trợ riêng, khiến nảy ra cuộc tranh luận phương pháp nào là tốt nhất Đây là cuộc tranh luận khó có câu trả lời, bởi tất

cả các phương pháp trên đều có những điểm mạnh và điểm yếu riêng Vì thế, các nhà phát triển phần mềm nhiều kinh nghiệm thường sử dụng phối hợp các điểm mạnh của mỗi phương pháp cho ứng dụng của mình Trong thực tế, sự khác biệt giữa các phương pháp đó hầu như không đáng kể và theo cùng tiến trình thời gian, tất cả những phương pháp trên đã tiệm cận lại và bổ sung lẫn

Trang 19

cho nhau Chính hiện thực này đã được những người tiên phong trong lĩnh vực mô hình hoá hướng đối tượng nhận ra và họ quyết định ngồi lại cùng nhau để tích hợp những điểm mạnh của mỗi phương pháp và đưa ra một mô hình thống nhất cho lĩnh vực Công nghệ phần mềm

Trong bối cảnh trên, người ta nhận thấy cần thiết phải cung cấp một phương pháp tiếp cận được chuẩn hoá và thống nhất cho việc mô hình hoá hướng đối tượng Yêu cầu cụ thể là đưa ra một tập hợp chuẩn hoá các ký hiệu (Notation) và các biểu đồ (Diagram) để nắm bắt các quyết định về mặt thiết

kế một cách rõ ràng, rành mạch Đã có ba công trình tiên phong nhắm tới mục tiêu đó, chúng được thực hiện dưới sự lãnh đạo của James Rumbaugh, Grady Booch và Ivar Jacobson Chính những cố gắng này dẫn đến kết quả là xây dựng được một Ngôn ngữ mô hình hoá thống nhất (Unified Modeling Language – UML)

UML là một Ngôn ngữ mô hình hoá thống nhất có phần chính bao gồm những ký hiệu hình học, được các phương pháp hướng đối tượng sử dụng để thể hiện và miêu tả các thiết kế của một hệ thống Nó là một ngôn ngữ để đặc

tả, trực quan hoá, xây dựng và làm tư liệu cho nhiều khía cạnh khác nhau của một hệ thống có nồng độ phần mềm cao UML có thể được sử dụng làm công

cụ giao tiếp giữa người dùng, nhà phân tích, nhà thiết kế và nhà phát triển phần mềm

Trong quá trình phát triển có nhiều công ty đã hỗ trợ và khuyến khích phát triển UML có thể kể tới như: Hewlett Packard, Microsoft, Oracle, IBM, Unisys

1.3.2 UML (Unified Modeling Language)

Ngôn ngữ mô hình hóa thống nhất (Unified Modeling Language – UML) là một ngôn ngữ để biểu diễn mô hình theo hướng đối tượng được xây dựng bởi ba tác giả trên với chủ đích là:

Trang 20

- Mô hình hoá các hệ thống sử dụng các khái niệm hướng đối tượng

- Thiết lập một kết nối từ nhận thức của con người đến các sự kiện cần

Một số những thành phần chủ yếu của ngôn ngữ UML:

Hướng nhìn (View): Hướng nhìn chỉ ra những khía cạnh khác nhau

của hệ thống cần phải được mô hình hóa Một hướng nhìn không phải là một bản vẽ, mà là một sự trừu tượng hóa bao gồm một loạt các biểu đồ khác nhau Chỉ qua việc định nghĩa của một loạt các hướng nhìn khác nhau, mỗi hướng nhìn chỉ ra một khía cạnh riêng biệt của hệ thống, người ta mới có thể tạo dựng nên một bức tranh hoàn thiện về hệ thống Cũng chính các hướng nhìn này nối kết ngôn ngữ mô hình hóa với quy trình được chọn cho giai đoạn phát triển

Biểu đồ (Diagram): Biểu đồ là các hình vẽ miêu tả nội dung trong một

hướng nhìn UML có tất cả 9 loại biểu đồ khác nhau được sử dụng trong những sự kết hợp khác nhau để cung cấp tất cả các hướng nhìn của một hệ thống

Phần tử mô hình hóa (Model Element): Các khái niệm được sử dụng

trong các biểu đồ được gọi là các phần tử mô hình, thể hiện các khái niệm hướng đối tượng quen thuộc Ví dụ như lớp, đối tượng, thông điệp cũng như

Trang 21

các quan hệ giữa các khái niệm này, bao gồm cả liên kết, phụ thuộc, khái quát hóa Một phần tử mô hình thường được sử dụng trong nhiều biểu đồ khác nhau, nhưng nó luôn luôn có chỉ một ý nghĩa và một kí hiệu

Cơ chế chung: Cơ chế chung cung cấp thêm những lời nhận xét bổ

sung, các thông tin cũng như các quy tắc ngữ pháp chung về một phần tử mô hình; chúng còn cung cấp thêm các cơ chế để có thể mở rộng ngôn ngữ UML cho phù hợp với một phương pháp xác định (một quy trình, một tổ chức hoặc một người dùng)

1.3.4 UML trong phân tích thiết kế hệ thống

UML có thể được sử dụng trong nhiều giai đoạn, từ phát triển, thiết kế cho tới thực hiện và bảo trì Vì mục đích chính của ngôn ngữ này là dùng các biểu đồ hướng đối tượng để mô tả hệ thống nên miền ứng dụng của UML bao gồm nhiều loại hệ thống khác nhau như:

- Hệ thống thông tin (Information System): Cất giữ, lấy, biến đổi

biểu diễn thông tin cho người sử dụng Xử lý những khoảng dữ liệu lớn có các quan hệ phức tạp, mà chúng được lưu trữ trong các cơ sở dữ liệu quan hệ hay hướng đối tượng

- Hệ thống kỹ thuật (Technical System): Xử lý và điều khiển các

thiết bị kỹ thuật như viễn thông, hệ thống quân sự, hay các quá trình công nghiệp Đây là loại thiết bị phải xử lý các giao tiếp đặc biệt, không có phần mềm chuẩn và thường là các hệ thống thời gian thực (Real Time)

- Hệ thống nhúng (Embeded System): Thực hiện trên phần cứng gắn

vào các thiết bị như điện thoại di động, điều khiển xe hơi,…Điều này được thực hiện bằng việc lập trình mức thấp với hỗ trợ thời gian thực Những hệ thống này thường không có các thiết bị như: Màn hình, đĩa cứng,…

- Hệ thống phân bố (Distributed System): Được phân bố trên một số

máy cho phép truyền dữ liệu từ nơi này đến nơi khác một cách dễ dàng

Trang 22

Chúng đòi hỏi các cơ chế liên lạc đồng bộ để đảm bảo toàn vẹn dữ liệu và thường được xây dựng trên một số các kỹ thuật đối tượng như CORBA, COM/DCOM, hay Java Beans/RMI

- Hệ thống Giao dịch (Business System): Mô tả mục đích, tài nguyên

(con người, máy tính,…), các quy tắc (luật pháp, chiến thuật kinh doanh, cơ chế,…) và công việc hoạt động kinh doanh

- Phần mềm hệ thống (System Software): Định nghĩa cơ sở hạ tầng

kỹ thuật cho phần mềm khác sử dụng, chẳng hạn như hệ điều hành, cơ sở dữ liệu, giao diện người sử dụng

1.4 Rational Rose là gì?

Rational Rose là phần mềm công cụ hỗ trợ phân tích, thiết kế hệ thống phần mềm theo hướng đối tượng Nó đảm bảo tính đúng đắn, hợp lý của kiến trúc hệ thống từ khi khởi đầu dự án Mô hình Rose là bức tranh hệ thống, nó bao gồm toàn bộ biểu đồ UML, tác nhân, trường hợp sử dụng, đối tượng, lớp, thành phần và các nút triển khai trong hệ thống Nó mô tả chi tiết hệ thống bao gồm cái gì và chúng làm việc ra sao để người phát triển hệ thống có thể

sử dụng mô hình như kế hoạch chi tiết cho việc xây dựng hệ thống Rose hỗ trợ giải quyết vấn đề muôn thủa là đội ngũ dự án giao tiếp với khách hàng và làm tài liệu yêu cầu

Hình 1.4: Giao diện chương trình Rational Rose

Trang 23

Chương 2: Khảo sát Hệ thống quản lý Nhà hàng

2.1 Khảo sát tiến trình tác nghiệp

Công việc của một Nhà hàng sẽ được làm rõ dần thông qua đối thoại giữa Phân tích viên với khách hàng, nhân viên từng bộ phận trong Nhà hàng

Giữa phân tích viên với khách hàng:

- Phân tích viên: Khách hàng làm gì khi muốn nhận được sự phục vụ?

- Khách hàng: Khách hàng đặt chỗ trước, yêu cầu phục vụ theo địa chỉ, đến Nhà hàng và gọi món

- Phân tích viên: Khách hàng yêu cầu cần cung cấp thông tin gì?

- Khách hàng: Số chỗ, thực đơn, ngày được phục vụ hoặc địa chỉ yêu cầu Đây là những thông tin cơ bản

- Phân tích viên: Quyền của khách hàng là gì?

- Khách hàng: Có quyền đòi hỏi những yêu cầu đã thoả thuận, có quyền

từ chối hay thay đổi nếu như không được phục vụ đúng chất lượng, đúng yêu cầu Tất nhiên, phải trả tiền nếu yêu cầu được đáp ứng tốt

- Phân tích viên: Với nhóm khách hàng đến Nhà hàng và gọi món?

- Khách hàng: Khách hàng gọi món theo thực đơn, dùng món, thanh toán và ra về Và họ cũng có đầy đủ các quyền như các nhóm khác

- Phân tích viên: Khách hàng thanh toán bằng hình thức nào?

- Khách hàng: Bằng tiền mặt (USD, VND), séc thanh toán

Giữa Phân tích viên với nhân viên phục vụ:

- Phân tích viên: Khi có yêu cầu từ phía khách hàng, nhân viên phục vụ làm gì?

- Nhân viên: Lễ tân, nhận các yêu cầu và kiểm tra khả năng đáp ứng của Nhà hàng

- Phân tích viên: Khả năng ở đây là gì?

- Nhân viên: Lễ tân, là lượng chỗ, thực đơn, thời gian

Trang 24

- Phân tích viên: Nếu có khả năng đáp ứng được hay không thì?

- Nhân viên: Lễ tân thông báo cho khách hàng

- Phân tích viên: Nếu có khả năng thì sao?

- Nhân viên: Lễ tân sẽ ghi lại, lập thành danh sách và báo cho thu ngân, cho nhà bếp qua các danh sách này

- Phân tích viên: Ngoài ra, lễ tân còn làm những công việc gì?

- Nhân viên: Tổ chức đón tiếp, hướng dẫn khách khi đến Nhà hàng, đồng thời hướng họ vào những loại hình dịch vụ của Nhà hàng

Giữa Phân tích viên với nhân viên thu ngân:

- Phân tích viên: Nhiệm vụ của nhân viên thu ngân?

- Nhân viên: Xử lý hàng bị trả lại, lên lịch đặt bàn, thêm món mới,…

- Phân tích viên: Xử lý hàng bị trả lại?

- Nhân viên: Lưu kho nếu hàng tái sử dụng được hoặc phải bỏ hoàn toàn

- Phân tích viên: Quản lý bàn ăn?

- Nhân viên: Ghép bàn, chuyển bàn, lập phiếu đặt bàn

- Phân tích viên: Và?

- Nhân viên: Thu ngân, lập các loại hoá đơn và thu tiền

Giữa Phân tích viên với nhân viên kho - bếp:

- Phân tích viên: Các công việc của một Nhà bếp?

- Nhân viên: Nhà bếp, nhận các yêu cầu từ khách hàng do nhân viên phục vụ hay quầy lễ tân cung cấp Sau đó, lên thực đơn, ước lượng nguyên, nhiên, vật liệu Và báo cho Nhà kho để được cung cấp Nếu được cung cấp đủ thì Nhà bếp tổ chức thực hiện

- Phân tích viên: Các công việc của một Nhà kho?

- Nhân viên: Nhà kho, tìm các Nhà cung cấp (về nguyên, nhiên, vật liệu), tổ chức lưu trữ và bảo quản chúng Khi có yêu cầu từ các bộ phận trong

Trang 25

Nhà hàng thì Nhà kho quyết định nhập kho hay xuất kho Mặt khác, Nhà kho lưu kho chính những nguyên, nhiên, vật liệu do: Không dùng đến, không dùng hết hay hàng bị trả lại có thể lưu kho để tái sử dụng

- Phân tích viên: Để quản lý một Nhà kho tốt thì?

- Nhân viên: Nhà kho, phải thường xuyên kiểm kê kho, tính toán kĩ khi quyết định nhập kho, phải xây dựng các biểu đồ, báo cáo thường xuyên, cùng với Quản lý nhà hàng ra những quyết định đúng

Giữa Phân tích viên với nhân viên kế toán:

- Phân tích viên: Nhiệm vụ của một nhân viên kế toán?

- Nhân viên: Kế toán, lập các danh sách, lập phiếu thu, lập phiếu chi, lập phiếu thu nội bộ, các báo cáo, lập bảng chấm công,…

- Phân tích viên: Việc tính lương cho từng nhân viên được thực hiện như thế nào?

- Nhân viên: Kế toán, dựa vào các bảng chấm công tính toán và trả lương cho nhân viên

- Phân tích viên: Ngoài việc như vậy kế toán còn làm gì?

- Nhân viên: Quản lý nhân viên, quản lý tiền quỹ,…

Trang 26

Xây dựng các biểu đồ hoạt động:

Hình 2.1.1: Biểu đồ hoạt động

Trang 27

Hình 2.1.2: Biểu đồ hoạt động (tiếp)

Trang 28

Hình 2.1.3: Biểu đồ hoạt động của kho - bếp

Trang 29

Hình 2.1.4: Biểu đồ hoạt động của thu ngân

Trang 30

Hình 2.1.5: Biểu đồ hoạt động của kế toán

- Nhóm nhà hàng: Nhà hàng, nhân viên, thực đơn, bàn ăn

- Nhóm công việc: Nhà bếp, nhà kho, quầy ba, thu ngân, kế toán, lễ tân, phục vụ bàn, quản trị hệ thống

- Nhóm khác: Tiền, nhà cung cấp, báo cáo, hoá đơn, phiếu, danh sách, lương, hệ thống tin học

Trang 31

Và dưới đây là biểu đồ mối quan hệ giữa các lớp:

Hinh 2.2.1: Lớp “khách hàng”

Một đến nhiều khách hàng thuộc một loại khách hàng khác nhau: Khách đặt chỗ trước, khách đặt theo địa chỉ, khách đến và gọi món Tức là, có thể có nhiều khách hàng cùng là khách hay đặt chỗ trước hoặc nhiều khách cùng đến Nhà hàng và họ gọi món,…Đây là cơ sở để phân loại khách, nhằm

có những chính sách ưu đãi hợp lý với từng đối tượng khách hàng khác nhau

Từ đó, chương trình được xây dựng để quản lý thông tin khách hàng và phân loại

Trang 32

Hình 2.2.2: Lớp “Hệ thống Tin học”

Trong một Nhà hàng có một Hệ thống Tin học Với hệ thống này, nó được sử dụng bởi nhiều nhân viên có chức trách (tuỳ theo từng đơn vị sử dụng Hệ thống Tin học thì số lượng nhân viên này nhiều hay ít); mỗi Hệ thống như vậy được cung cấp một máy chủ (Server), một cơ sở dữ liệu, được kết nối mới nhiều máy trạm (Client), trong Hệ thống mà ta đang xét có 5 máy trạm; trên các máy tính trạm chương trình được cài đặt, có giao diện tương ứng với số máy trạm Để các máy tính có thể giao tiếp với nhau, ta phải thiết lập một cơ sở hạ tầng mạng LAN

Trang 33

- Thực hiện nhiều công việc

Đó là những gì mà một Nhà hàng tối thiểu cần phải có Các yếu tố này cấu thành nên một Nhà hàng Tất nhiên để có và kinh doanh Nhà hàng cần phải có rất nhiều yếu tố khác hợp thành Chúng ta không quan tâm đến việc làm thế nào để có thể kinh doanh mà chỉ quan tâm đến vấn đề liên quan Hệ thống đang xét

Trang 34

Hình 2.2.4: Lớp “nhân viên”

Trong Hệ thống Tin học, nhân viên chịu trách nhiệm sẽ đăng nhập vào

Hệ thống và nhập dữ liệu (tuỳ theo công việc)

Mỗi nhân viên có:

- Từ một đến nhiều lương (do đảm trách nhiều vai trò)

- Một đến nhiều nhân viên làm một đến nhiều công việc

- Một đến nhiều nhân viên nhập liệu cho Hệ thống Tin học

- Nhiều nhân viên làm việc cho một Nhà hàng

Nhân viên là một trong những yếu tố cấu thành Nhà hàng Tuỳ theo chức năng của từng nhân viên, họ đảm trách nhiều vai trò khác nhau và có những chế độ ưu đãi khác nhau

Trang 35

Để chi tiết hơn, đối tượng nhân viên với chức năng cụ thể Và được thể hiện trong hình dưới đây

Hình 2.2.5: Lớp “Nhà bếp”

Nhà bếp là bộ phận của Nhà hàng và có:

- Nhiều nhân viên

- Làm từ một đến nhiều thực đơn khác nhau

- Lập nhiều báo cáo (đây là các báo cáo quản lý liên quan đến bếp)

Trang 36

Hình 2.2.6: Lớp “Nhà kho”

Nhà kho là một phận của Nhà hàng có:

- Nhiều nhân viên

- Giao dịch với từ một đến nhiều nhà cung cấp

- Xuất hàng cho một quầy ba

- Xuất hàng cho một Nhà bếp

- Xuất nhiều báo cáo (đây cũng là các báo cáo quản lý liên quan đến kho)

Trang 37

Hình 2.2.7: Lớp “kế toán”

Kế toán là bộ phận của Nhà hàng có:

- Từ một đến hai nhân viên (tuỳ theo phạm vi của Nhà hàng)

- Lập nhiều loại phiếu

- Trả nhiều loại lương cho nhân viên

- Xuất nhiều báo cáo

- Lập nhiều danh sách

Ngày đăng: 16/11/2015, 11:53

TRÍCH ĐOẠN

TÀI LIỆU CÙNG NGƯỜI DÙNG

TÀI LIỆU LIÊN QUAN

w