Chương V: Quy trình làm phần mềm docx

Yêu cầu chức năng thường gắn với chức năng tương ứng của phần mềm cầnxây dựng và thể hiện dưới dạng các mục chọn của thực đơn, ví dụ như: "Phầnmềm cung cấp chức năng tìm kiếm hàng hóa th

CHƯƠNG V – QUI TRÌNH LÀM PHẦN MỀM.

1 MỞ ĐẦU

Quy trình làm phần mềm (hay gọi đơn giản theo tiếng Anh: softwareprocess - quy trình phần mềm) là quá trình tạo ra phần mềm Quy trình này là sựkết hợp mô hình vòng đời phần mềm, các công cụ được sử dụng và quan trọnghơn hết, là những người xây dựng nên phần mềm đó Các công ty phần mềmkhác nhau có các quy trình phần mềm khác nhau Ví dụ hãy xem vấn đề tài liệu

Có một số công ty cho rằng chính bản thân phần mềm với các mã nguồn là tàiliệu về phần mềm Họ cho rằng phần mềm có thể hiểu được bằng cách đọc các

mã nguồn này Một số công ty khác chuẩn bị tài liệu rất chi tiết Ngay cả khiphần mềm đã cài đặt cho khách hàng và chuyển sang giai đoạn bảo trì, thì mọi sựsửa đổi phần mềm cũng được ghi chép lại, các bản thiết kế cũng được thay đổicho phù hợp Từ thực tế có thể thấy rằng một phần mềm được kiểm thử kỹ lưỡng

và có các tài liệu báo cáo đầy đủ trong từng pha thì chất lượng sẽ tốt hơn vàcông việc bảo trì cũng thuận lợi hơn

Nói chung, một quy trình phần mềm thường trải qua 7 pha: xác định yêucầu, phân tích, thiết kế, cài đặt, tích hợp, bảo trì và thôi sử dụng Trong một sốtrường hợp thì tên các pha này có thể khác Ví dụ người ta hợp nhất hai pha xácđịnh yêu cầu và phân tích thành pha phân tích hệ thống Một vài pha khác lạiđược chia nhỏ hơn, ví dụ pha thiết kế được chia thành pha thiết kế kiến trúc vàthiết kế chi tiết Hai pha cài đặt và tích hợp được kết hợp thành pha cài đặt vàtích hợp Những lý do sau đây trả lời câu hỏi vì sao các pha của vòng đời phầnmềm cần được kiểm thử kỹ và báo cáo thành tài liệu chi tiết bởi nhóm thực hiệntrước khi tiến hành các pha tiếp theo:

- Vì sự thúc ép về thời gian hoàn thành nên những phần tài liệu bị trì hoãnthường ít khi được tiếp tục hoàn thiện

- Trách nhiệm về một pha nào đó có thể được chuyển giao cho nhóm khácthậm chí ở một công ty phần mềm khác

- Phần mềm thường liên tục thay đổi trong quá trình xây dựng Ví dụ thiết

kế có thể bị thay đổi trong pha cài đặt Rõ ràng nếu tài liệu thiết kế được biênsoạn đầy đủ thì sự sửa đổi sẽ thuận lợi hơn

II CÁC ĐỐI TƯỢNG

Trong những lần gặp đầu tiên giữa khách hàng và người phát triển, kháchhàng phác thảo các yêu cầu, chức năng, các công việc cần thực hiện của phầnmềm mà họ muốn đặt hàng Theo cách nhìn nhận của người phát triển thì nhữngđiều khách hàng mô tả có thể mơ hồ, có những điều không hợp lý, thậm chí mâuthuẫn hay không khả thi Nhiệm vụ của người phát triển là phải tìm hiểu xemthực chất khách hàng cần gì Ngoài những yêu cầu về chức năng và công việc,

họ còn phải tìm hiểu xem các điều kiện về phần mềm là gì? Ví dụ như phần mềmphải hoàn thành trong thời gian bao lâu, phần mềm cần làm việc với hệ điềuhành nào, trên máy tính có cấu hình ra sao, giá cả khoảng bao nhiêu thì chấpnhận được Thường thì chính khách hàng hỏi lại người phát triển giá của phầnmềm, và người phát triển phải cân nhắc khi trả lời câu hỏi này

III – PHA XÁC ĐỊNH YÊU CẦU

1 Nắm bắt yêu cầu

Quá trình khám phá các yêu cầu của khách hàng được gọi là sự nắm bắtyêu cầu (requirements capture), hoặc sự gợi mở yêu cầu (requirements

100

elicitation) hay tìm hiểu vấn đề (concept exploration) Sau khi các yêu cầu đượcxác định thì chúng được xem xét để hiệu chỉnh, lược bỏ bớt hoặc mở rộng Quátrình này được gọi là phân tích yêu cầu (requrements analysis) Pha yêu cầuthường được bắt đầu bằng việc gặp gỡ trao đổi giữa một vài thành viên củanhóm yêu cầu và một vài thành viên đại diện cho công ty khách hàng để cùngnhau xác định xem sản phẩm phần mềm cần những gì Cuộc trao đổi thườngđược thực hiện theo cách là thành viên của nhóm yêu cầu đưa ra các câu hỏi cótính gợi mở về lĩnh vực mà phần mềm được sử dụng Các thành viên của công tykhách hàng hoặc trả lời các câu hỏi của nhóm yêu cầu, hoặc chủ động nêu ra cácvấn đề mà họ cần Rõ ràng, những thành viên tham gia khám phá yêu cầu củakhách hàng phải có hiểu viết về lĩnh vực mà phần mềm ứng dụng giải quyết, để

có thể hiểu được những điều khách hàng nói, và có thể đưa ra các câu hỏi có ýnghĩa Vì vậy, nhiệm vụ đầu tiên của nhóm yêu cầu chính là tìm hiểu và làmquen với lĩnh vực ứng dụng của phần mềm mà khách hàng muốn có Ví dụ, nếuphần mềm là quản lý các chuyến bay của một hãng hàng không thì lĩnh vực cầntìm hiểu là cách thức quản lý các chuyến bay của một hãng hàng không Nếuphần mềm là chương trình quản lý thư viện thì nhóm yêu cầu cần có hiểu biếtnhất định về lĩnh vực thư viện Để sử dụng từ một cách chính xác, các thànhviên nhóm yêu cầu cần tìm hiểu các thuật ngữ Ví dụ, nếu họ đang chuẩn bị làmphần mềm trong lĩnh vực sinh học thì cần tìm hiểu các thuật ngữ về sinh học Một trong những phương pháp khắc phục vấn đề thuật ngữ là xây dựng bộ từvựng về lĩnh vực ứng dụng Mỗi lần gặp một thuật ngữ mới thì nhóm yêu cầucần tìm hiểu để biết được một cách chính xác ý nghĩa và đưa thuật ngữ này vào

bộ từ vựng Sau khi đã có những hiểu biết nhất định về lĩnh vực ứng dụng phầnmềm, các thành viên bắt đầu khám phá, tìm hiểu các yêu cầu khách hàng theocác cách thức sau:

khách hàng có ý định thay thế" Tuy nhiên, cũng không nên hỏi những câu quáchung chung, khó trả lời như: "Hãy nói cho tôi biết về sản phẩm hiện tại" Cáccâu hỏi mở nên đưa ra sao cho có thể khích lệ người được phỏng vấn có thể chocâu trả lời trong một phạm vi rộng, tuy nhiên cũng không nên rộng quá mà chỉnằm trong phạm vi các thông tin cần nắm bắt Phỏng vấn có hiệu quả là côngviệc không dễ dàng Điều kiện quan trọng đầu tiên là người phỏng vấn cần amhiểu về lĩnh vực mà họ chuẩn bị phỏng vấn Các câu hỏi đưa ra cũng phải hợp lý

để người được phỏng vấn có thể nói ra những thông tin có ích cần thiết một cách

tự nhiên, không bị gò ép hay e ngại gì Đôi khi những câu hỏi quá thẳng thắn vàtrực tiếp chưa chắc đã nhận được câu trả lời đúng Ví dụ nếu hỏi rằng "lương anhchị rất thấp, nhưng chi tiêu thì có vẻ rất nhiều Anh chị hãy cho biết làm sao cóđược khoản tiền ngoài lương kia " thì thường là người được hỏi sẽ tìm cách nétránh câu trả lời thật

Sau khi phỏng vấn xong thì người phỏng vấn cần viết báo cáo về kết quảphỏng vấn và nên đưa cho người được phỏng vấn xem và góp ý kiến

1.2 Kịch bản (scenario)

Kịch bản là một kỹ thuật được sử dụng để phân tích yêu cầu Kịch bản

là mô tả các thao tác cần thực hiện trên phần mềm cần xây dựng để hoàn thànhmột công việc nào đó (trong các công việc mà phần mềm cung cấp)

1.3 Một vài kỹ thuật nắm bắt yêu cầu khác

Một kỹ thuật khác hay được sử dụng để nắm bắt các yêu cầu kháchhàng là gửi các bảng câu hỏi cho một số thành viên đại diện của công ty kháchhàng Bằng cách này có thể gửi cho hàng trăm thành viên để nhận được các câutrả lời dưới dạng viết, được suy nghĩ kỹ Tuy nhiên, nếu từ bảng câu hỏi đã đượctrả lời, người phỏng vấn có thể đưa ra thêm các câu hỏi thích hợp với người đượcphỏng vấn thì có thể nhận được các thông tin bổ ích Đôi khi các thông tin này

có ích hơn nhiều so với trả lời viết đã có

Một cách khác để tìm hiểu và nắm bắt yêu cầu khách hàng, đặc biệt trong môitrường kinh doanh, là xem xét các biểu mẫu khác nhau mà các khách hàng sửdụng Ví dụ, từ việc xem xét các biểu mẫu được in ra có thể biết được các dạngbáo cáo, cỡ giấy; tài liệu viết về cách thức điều hành hoặc mô tả công việc là

102

những công cụ rất hữu ích để giúp tìm ra công việc gì đang được thực hiện, vàđược thực hiện như thế nào ở công ty khách hàng.

Gần đây, người ta thường áp dụng thêm một phương pháp nữa là quay băngvideo cảnh làm việc ở công ty khách hàng (tất nhiên là được sự cho phép củacông ty và của những người được quay) Như vậy, có thể biết được chính xácnhững gì đang xảy ra Tuy nhiên, cách này có một nhược điểm là phải tốn khánhiều thời gian để xem lại băng và phân tích để rút ra những thông tin cần thiết Một nhược điểm rất lớn khác của phương pháp này là phần lớn những ngườiđược quay đều không thích mình xuất hiện trong máy quay và trở nên dè dặt khihành động

Sau khi thu được các thông tin ban đầu về yêu cầu khách hàng, bước tiếp theo

là phân tích các yêu cầu đó để rút ra những thông tin cơ bản nhất có thể giúp íchcho việc xây dựng phần mềm

2 Phân tích yêu cầu

Tới thời điểm này, nhóm yêu cầu đã có được tập hợp khởi đầu các yêu cầukhách hàng Các yêu cầu này được phân làm hai loại: chức năng (functional) vàphi chức năng (nonfunctional)

Yêu cầu chức năng thường gắn với chức năng tương ứng của phần mềm cầnxây dựng và thể hiện dưới dạng các mục chọn của thực đơn, ví dụ như: "Phầnmềm cung cấp chức năng tìm kiếm hàng hóa theo tên hàng và ngày bán" Đặc tảphi chức năng dùng để chỉ rõ tính chất nào đó của phần mềm cần xây dựng, ví dụtính tin cậy và bảo trì được; hoặc liên quan đến môi trường mà phần mềm được

sử dụng, ví dụ: tất cả các mã khách hàng được nhập trực tiếp từ bàn phím vàđược lưu trong một tệp bảng dữ liệu" Tóm lại yêu cầu chức năng là nói đến mộtcông việc cụ thể, thường thể hiện bằng các mục chọn trong chương trình; cònyêu cầu phi chức năng thì nói về các tính chất của phần mềm, các tính chất nàykhông thể thể hiện được bằng một việc cụ thể Thí dụ từ câu: "yêu cầu phần mềmphải có giao diện đẹp, thân thiện với người sử dụng", ta không thể nói được cụthể là phải làm gì

Một điều rất quan trọng là phần mềm phải theo dõi được (traceable) Điềunày có nghĩa là có thể kiểm tra xem tất cả các yêu cầu đã được thể hiện trong bảnđặc tả chưa; điểm nào trong bản báo cáo yêu cầu tương ứng với điểm nào trongbáo cáo đặc tả Tương tự, báo cáo thiết kế hay chương trình cũng phải tương ứng

với các tài liệu trước đó Như vậy, nhóm bảo đảm chất lượng phần mềm có thểkiểm tra xem có phải tất cả các mục trong các yêu cầu khách hàng đã được thựchiện hay chưa.

Tất cả các yêu cầu thu thập được ban đầu đều được đưa cho khách hàng xemxét Họ sẽ sắp xếp các mục yêu cầu theo thứ tự quan trọng, phát hiện và hiệuchỉnh những điều không chính xác hoặc bỏ đi những mục không cần thiết Tiếp theo, nhóm yêu cầu sẽ thảo luận với những khách hàng đã được phỏngvấn và xem xét lại các vấn đề một cách kỹ càng, xem có điều gì còn bị bỏ sótkhông Và như chúng ta biết, kỹ thuật phân tích yêu cầu hiệu quả và chính xácnhất là làm bản mẫu, vì vậy nếu có thể thì nhóm chuyển qua bước làm bản mẫu

để đưa cho khách hàng xem xét một cách trực quan hơn

3 Làm bản mẫu (prototyping)

Bản mẫu được xem là kỹ thuật phân tích yêu cầu chính xác nhất

Bản mẫu là phần mềm được xây dựng nhanh chủ yếu để thể hiện các chứcnăng quan trọng nhất của phần mềm cần xây dựng Mục đích của bản mẫu là thểhiện các yêu cầu khách hàng, do đó khi xây dựng người ta chú ý nhiều đến giaodiện và các báo cáo in ra Những vấn đề quan trọng khác mà một phần mềm sảnphẩm cần phải có như tính bảo mật, an toàn dữ liệu, tốc độ tính toán, kiểm tra vàkhắc phục lỗi đều chưa được chú ý khi làm bản mẫu; nghĩa là bản mẫu chỉ làthể hiện bên ngoài của sản phẩm và bỏ qua những phần được che dấu Bản mẫuđược cài đặt để khách hàng sử dụng thử Qua việc thao tác trực tiếp với bản mẫu,

họ sẽ thấy được các chức năng của phần mềm đã thể hiện đúng các yêu cầu của

họ chưa, cái gì cần thêm bớt hay hiệu chỉnh bổ sung Những người phát triển sẽhiệu chỉnh bản mẫu cho đến khi khách hàng vừa ý và cho rằng mọi yêu cầu của

họ đã được bao hàm trong phần mềm (tất nhiên là về hình thức) Bản mẫu sẽđược dùng làm cơ sở để biên soạn tài liệu đặc tả

Như tên gọi của nó, bản mẫu nhanh (rapid prototype) được xây dựng với mụcđích để người phát triển và khách hàng thống nhất càng nhanh càng tốt nhữngđiều mà sản phẩm chính cần làm Như vậy, nhiều điều có thể bỏ qua khi làm bảnmẫu Bản mẫu có thể thường xuyên gặp sự cố và phải khởi động lại; màn hìnhnhập dữ liệu có thể chưa đẹp; báo cáo in ra còn thiếu biểu tượng công ty kháchhàng,

104

4 Tính thân thiện với người dùng của phần mềm

Khách hàng thao tác với bản mẫu thông qua giao diện người sử dụng (userinterface) hay còn gọi là "giao diện người máy" (human-computer interface,HCI) Nên khuyến khích khách hàng làm quen và chú ý tới giao diện người máy.Điều này có thể giúp cho sản phẩm sau này đạt được "tính thân thiện vớingười sử dụng" (user-friendliness), một tiêu chuẩn quan trọng của tất cả các phầnmềm Một phần mềm có tính thân thiện với người sử dụng có nghĩa là phần mềm

đó dễ học sử dụng đối với cả những người ít hiểu biết về máy tính

Một chương trình thân thiện với người sử dụng thường bao gồm các yếu tốsau: dùng thực đơn hoặc các biểu tượng thay cho lệnh phải nhớ; luôn có sẵn trợgiúp màn hình mỗi khi ấn phím; các chức năng của chương trình được tổ chứctrên bàn phím theo một trật tự logic; các thông báo lỗi có giải thích nguyên nhân

và cách khắc phục; các tính năng trung gian và phức tạp được làm ẩn, khôngnhìn thấy để khỏi gây rối màn hình và lẫn lộn cho người mới học

Bản mẫu nên được xây dựng có giao diện người máy thân thiện với ngườidùng (user-friendly HCI) HCI của bản mẫu gần giống với HCI của sản phẩmthật, như vậy sau này khách hàng sẽ nhanh chóng làm quen với sản phẩm thật vàcảm thấy là các yêu cầu của họ đã được đáp ứng

5 Bản mẫu như một kỹ thuật đặc tả

Bản mẫu được sử dụng như một công cụ để xác định rằng: các yêu cầu củakhách hàng đã được nhận biết một cách chính xác Khi bản đặc tả hoàn thành vàđược ký duyệt bởi khách hàng thì vai trò của bản mẫu cũng kết thúc Tuy nhiên,

có một cách tiếp cận khác là người ta xem bản mẫu như đặc tả, hoặc một phầnquan trọng của đặc tả Như vậy, không cần tốn thời gian viết bản đặc tả và nhữngkhó khăn thường gặp trong phần đặc tả như sự không rõ ràng, thiếu các thànhphần hoặc có sự mâu thuẫn sẽ không còn Vì bản mẫu thay thế đặc tả, nên ta chỉcần ghi chú rằng: sản phẩm thật sẽ hoạt động giống như bản mẫu, đồng thời liệt

kê thêm các đặc trưng khác mà sản phẩm cần có như cập nhật tệp, bảo mật, xử lýlỗi Tuy nhiên, việc sử dụng bản mẫu như đặc tả cũng có nhiều nhược điểm khókhắc phục Đặc tả là tài liệu được khách hàng ký duyệt, là căn cứ để nhà pháttriển và khách hàng ký hợp đồng Rõ ràng, bản mẫu không thể thay thế vai trònày của đặc tả, không thể căn cứ vào bản mẫu để kết luận rằng điểm này hay

điểm khác của hợp đồng chưa được thực hiện đúng Cho dù phần mềm đượcphát triển trong nội bộ cơ quan thì vẫn có thể có vấn đề nảy sinh giữa người pháttriển và người quản lý Rõ ràng, các nhà phát triển không thể chỉ dựa vào bảnmẫu để thuyết phục các nhà quản lý là họ đã làm đúng các yêu cầu mà cơ quanđặt ra.

Lý do thứ hai khiến cho việc sử dụng bản mẫu làm đặc tả bị hạn chế là vấn đềbảo trì Cho dù có đầy đủ các tài liệu thì việc bảo trì bao giờ cũng là công việckhó khăn và tốn nhiều tiền của Nếu thiếu tài liệu đặc tả thì việc bảo trì thực sựtrở thành cơn ác mộng Đặc biệt với công việc bảo trì nâng cao (enhancement),tức là thay đổi các yêu cầu ban đầu thì công việc thay đổi lại thiết kế đặc biệt khókhăn nếu không có tài liệu đặc tả

Vậy chỉ nên xem bản mẫu là một kỹ thuật phân tích yêu cầu Nó được sửdụng để bảo đảm rằng các yêu cầu của khách hàng đã được nắm bắt một cáchđầy đủ và chính xác Bước tiếp theo là dựa vào bản mẫu để biên soạn tài liệu đặc

tả dưới dạng văn bản

Có nên sử dụng lại bản mẫu?

Thực tế cho thấy rằng cho dù về hình thức bản mẫu giống với sản phẩm thật

và có thể hiệu chỉnh để trở thành sản phẩm thật, nhưng về chất lượng thực sự thìbản mẫu và sản phẩm thật còn một khoảng cách rất lớn Ví dụ như phần lưu trữ

dữ liệu hay một số phần chất lượng cao như thuật toán tối ưu, tính bảo mật, cònchưa có trong bản mẫu Kinh nghiệm cho thấy rằng nên thiết kế lại và xây dựnglại hoàn toàn phần mềm Chỉ nên sử dụng một số phần của bản mẫu được tạonên bởi các bộ công cụ CASE như bộ tạo màn hình (screen generator), tạo báocáo (report generator) Cũng có khi bản mẫu và bản chính không sử dụng cùngmột ngôn ngữ lập trình Trong trường hợp này thì việc viết lại hoàn toàn bảnchính là điều khá hiển nhiên, không thể khác được

6 Sử dụng các công cụ CASE trong pha yêu cầu

Có thể sử dụng một ngôn ngữ lập trình nào đó để viết bản mẫu Vai trò của

bản mẫu là cầu nối giữa người phát triển và khách hàng để người phát triển nắmbắt nhanh và đầy đủ các yêu cầu khách hàng Như vậy bản mẫu cần được viếtcàng nhanh càng tốt Người ta thấy rằng ngôn ngữ lập trình thông dịch(interpreted language) khá thích hợp cho việc xây dựng bản mẫu, vì không mất

106

thời gian để dịch hay liên kết như ngôn ngữ biên dịch (compiler) Tính hiệu quảđược nâng cao nếu công cụ CASE được liên kết cùng với ngôn ngữ lập trình Các ngôn ngữ có hỗ trợ công cụ CASE như Smalltalk, Java, Perl (PracticalExtraction and Report Language) có thể sử dụng để xây dựng bản mẫu nhanh vàhiệu quả HTML cũng là một ngôn ngữ làm bản mẫu được ưa chuộng Nếu bảnmẫu chắc chắn được vứt đi thì HTML còn một lợi điểm nữa: thật khó hình dungsản phẩm chuyển giao lại được viết bằng HTML, như vậy việc viết bản mẫubằng HTML gần như được ngầm hiểu là bản mẫu sẽ được vứt đi

Trong những năm gần đây, một số ngôn ngữ lập trình thuộc thế hệ thứ 4(fourth-generation laguage, 4GL) như Oracle, PowerBuilder và DB2 cũng được

sử dụng để làm bản mẫu Mục đích thiết kế của hầu hết 4GL là viết ít dòng lệnhhơn cho cùng một chức năng so với ngôn ngữ thế hệ thứ 3 như Java, Ada hay C++ Phần lớn 4GL là thông dịch và được hỗ trợ các công cụ CASE tính năng cao,

do đó làm tăng tốc độ xây dựng bản mẫu

Tuy nhiên 4GL cũng có nhược điểm Môi trường CASE trong đó 4GL đượcnhúng thường là một phần của một tập hợp lớn hơn các công cụ được sử dụngcho một quy trình phần mềm đầy đủ (complete software process) Các nhà cungcấp 4GL thường khuyến khích sử dụng ngôn ngữ của họ làm bản mẫu, sau đóhoàn thiện dần thành bản chính thức Các nhà cung cấp không nhận thức đượcrằng bằng cách này quy trình phần mềm có thể suy thoái thành mô hình xâydựng-và-hiệu chỉnh (build-and-fixed model) Đáng tiếc là các nhà cung cấp 4GLmuốn khách hàng mua sản phẩm của họ và họ quảng cáo rằng công cụ CASEcủa họ có thể thực hiện mọi phần công việc của một dự án phần mềm

Giả sử rằng người quản lý dự án đã bỏ ra khá nhiều tiền để mua công cụCASE hỗ trợ cho tất cả các pha của quy trình phần mềm Thật khó thuyết phục

họ bỏ thêm tiền mua một ngôn ngữ khác để phát triển phần mềm chính thức và

bỏ đi bản mẫu vừa mới xây dựng Tuy nhiên, cần chỉ cho họ thấy rằng cho dùnhư vậy vẫn còn rẻ hơn là cố giữ lại bản mẫu và phát triển nó thành sản phẩmchính thức Sẽ tốn một số tiền khổng lồ cho việc chuyển đổi bản mẫu thành bảnchính thức và bảo trì sau này

7 Kiểm thử pha xác định yêu cầu

Trong mỗi công ty phần mềm cần có một nhóm làm việc mà nhiệm vụchính của họ là bảo đảm rằng phần mềm hoạt động tốt và đáp ứng đúng các yêu

cầu của khách hàng Nhóm này được gọi là nhóm bảo đảm chất lượng phần mềm(SQA = software quality assurance) Nhóm SQA bắt đầu thực hiện vai trò củamình ngay từ pha khởi đầu Nếu sử dụng bản mẫu thì trong pha này nhóm cùngkhách hàng kiểm thử phiên bản cuối cùng của bản mẫu xem nó đã thực hiệnđúng các yêu cầu mà khách hàng cần hay không.

8 Tài liệu báo cáo trong pha xác định yêu cầu

Tài liệu được biên soạn trong pha yêu cầu bao gồm bản mẫu và cácghi chép trong quá trình trao đổi với khách hàng Những ghi chép này chính là

cơ sở để những người phát triển xây dựng và sửa đổi bản mẫu Nếu nhóm pháttriển không làm bản mẫu thì tài liệu sẽ mô tả những yêu cầu của khách hàng Tàiliệu này được kiểm tra bởi khách hàng và một số người sử dụng trước khi đượcnhóm SQA kiểm tra kỹ lưỡng và chi tiết

IV – PHA ĐẶC TẢ CÓ CẤU TRÚC

Pha đặc tả hay còn được gọi là pha phân tích, là tiếp theo pha yêu cầu Nếugọi là pha phân tích thì dễ nhầm với giai đoạn phân tích yêu cầu trong pha yêucầu, do đó người ta thường gọi là pha đặc tả (specification) Tài liệu báo cáo củapha này phải thỏa mãn hai yêu cầu trái ngược nhau Một mặt, tài liệu phải rõràng, dễ hiểu đối với khách hàng, thường là những người không phải là chuyêngia máy tính Mặt khác, tài liệu đặc tả lại phải đầy đủ và chi tiết, bởi vì đây gầnnhư là nguồn duy nhất để soạn thảo thiết kế Như vậy tài liệu đặc tả là mô tả sảnphẩm trong một khuôn dạng không mang tính kỹ thuật quá, sao cho có thể dễhiểu đối với khách hàng, nhưng đồng thời cũng phải đủ chính xác để căn cứ vào

đó có thể xây dựng được phần mềm không có lỗi, đúng như yêu cầu của kháchhàng Chúng ta sẽ tìm hiểu hai kỹ thuật đặc tả: kỹ thuật cổ điển hay còn gọi là

kỹ thuật đặc tả có cấu trúc (hoặc còn gọi là phân tích có cấu trúc) và phân tíchhướng đối tượng Chương này, chúng ta sẽ tìm hiểu kỹ thuật đặc tả có cấu trúc,còn trong chương 5 tiếp theo sẽ nghiên cứu kỹ thuật đặc tả hướng đối tượnghay còn được gọi đơn giản là phân tích hướng đối tượng Lưu ý rằng trong thuậtngữ "phân tích có cấu trúc" thì từ "cấu trúc" đóng vai trò tính từ bổ nghĩa chophân tích Thuật ngữ này được dịch từ tiếng Anh là "structured analysis" hoặc

"structured specification" Như vậy, nếu dịch đúng thì phải là "phân tích theokiểu cấu trúc" Từ "cấu trúc" ở đây khác với ý nghĩa của từ "cấu trúc" trong câu

108

"phân tích cấu trúc câu", vì trong câu này thì từ "cấu trúc" là danh từ Thuật ngữ

"phân tích hướng đối tượng" cũng được dịch từ thuật ngữ tiếng Anh là oriented analysis", và cũng có nghĩa là "phân tích theo kiểu hướng đối tượng" Như vậy, cùng một hệ thống cần xây dựng, nhưng ta có thể nhìn nhận và xemxét theo phương pháp cấu trúc hoặc theo phương pháp hướng đối tượng Để bạnđọc tránh được sự hiểu nhầm, chúng tôi đôi khi sẽ gọi là "phân tích (hay đặc tả)theo phương pháp cấu trúc" và "phân tích theo phương pháp hướng đối tượng" Tuy nhiên, thường thì chúng tôi cũng viết đơn giản là "phân tích có cấu trúc"

"object-và "phân tích hướng đối tượng" như các tài liệu khác thường sử dụng Chúng ta

sẽ sử dụng khá nhiều lần thuật ngữ "hệ thống" Từ "hệ thống" ở đây là nói tớiphần mềm cần xây dựng được đặt trong môi trường nó được ứng dụng Cho nên

ta nói "phân tích hệ thống", có nghĩa là ta xem xét chương trình cần xây dựngcùng với các yếu tố liên quan Ví dụ, với chương trình quản lý bán hàng thì taxem xét chương trình cùng với các thao tác liên quan đến người bán hàng vàkhách hàng Tóm lại, khi nói "phân tích hệ thống" thì ta hiểu đó chính là phântích phần mềm cần xây dựng

1 Tài liệu đặc tả

Ta đã biết rằng tài liệu trong pha yêu cầu hoặc là bản mẫu, tức là chươngtrình trong đó chỉ chú ý đến giao diện, cốt thể hiện được các yêu cầu của kháchhàng; hoặc là tài liệu mô tả các yêu cầu của khách hàng được viết bằng ngôn ngữ

tự nhiên Nhiệm vụ của pha đặc tả là mô tả phần mềm thực hiện các yêu cầu đó Phải mô tả đầy đủ và chi tiết, sao cho có thể dựa vào đó để đánh giá phầnmềm sau này có đáp ứng được yêu cầu đặt ra hay không Tài liệu đặc tả còn là cơ

sở để thực hiện thiết kế Nếu như tài liệu đặc tả trả lời câu hỏi "phần mềm phảilàm những việc gì?" thì tài liệu thiết kế lại trả lời câu hỏi "phải làm những việc

đó như thế nào?"

Vào những năm 60, 70 của thế kỷ trước, người ta vẫn dùng ngôn ngữ tự nhiên

để viết tài liệu đặc tả Tuy nhiên, người ta phát hiện rằng tài liệu biên soạn theokiểu như thế này rất hay lỗi và có nhiều điều mập mờ Ví dụ, chỉ với tài liệu đặc

tả của Naur (1969) cho vấn đề xử lý văn bản mà từ đó có thể viết thành chươngtrình khoảng từ 25 đến 30 dòng lệnh, người ta đã phát hiện ra nhiều lỗi

Trong năm 1985, Mayer đã viết một bài báo nói về vấn đề này Mayer đưa rakết luận rằng: nếu dùng ngôn ngữ tự nhiên để viết đặc tả thì sẽ dẫn đến tình trạng

tài liệu đặc tả chứa đựng các mâu thuẫn, những điều nhập nhằng không hiểuđược nghĩa chính xác hoặc bị thiếu, không đầy đủ Ông đề nghị sử dụng cácthuật ngữ toán học để biểu diễn đặc tả một cách hình thức Mayer đã dùng cáchnày để đặc tả vấn đề xử lý văn bản và từ đặc tả toán học ông đã chuyển đổi thànhđặc tả bằng tiếng Anh Tuy nhiên người ta lại tìm thấy những điều nhập nhằngtrong đặc tả tiếng Anh này Vậy ngôn ngữ tự nhiên không phải là cách thức tốt

để biểu diễn đặc tả Vào những năm 70, có một số tác giả đã dùng các biểu tượngtrực quan (đồ họa) để biểu diễn đặc tả Có ba kỹ thuật đồ họa đã trở thành nổitiếng và được sử dụng nhiều Đó là của DeMarco (1978), Gane và Sarsen(1979), Yourdon và Constantine (1979) Cả ba kỹ thuật này đều khá tốt và về cơbản là tương đương Tuy nhiên kỹ thuật của Gane và Sarsen được sử dụng nhiềuhơn và do đó chúng ta sẽ tìm hiểu kỹ thuật này trong các phần tiếp theo

2 Phân tích hệ thống bằng phương pháp cấu trúc

Phương pháp phân tích có cấu trúc (structured analysis, SA) do DeMacro

và những người khác đề xuất vào khoảng những năm 70 của thế kỷ trước

Phương pháp này ngày nay vẫn còn phát huy tác dụng, đặc biệt là với các hệthống thông tin quản lý Nó vẫn là nền tảng của một số phần mềm trợ giúp phântích và thiết kế nổi tiếng, như Designer 2000 của Oracle chẳng hạn Đặc điểmcủa phương pháp này là đơn giản, dễ thực hiện nhưng không quá sơ lược Công

cụ chính được sử dụng là biểu đồ luồng dữ liệu (data flow diagram, DFD) mà ta

sẽ tìm hiểu trong các phần sau Mục đích của SA là tiến hành phân tích các chứcnăng của hệ thống thực tế để thành lập một mô hình logic cho hệ thống, dướidạng một hay nhiều DFD Nó vận dụng ba kỹ thuật:

- Kỹ thuật phân mức, hay còn gọi là phân tích từ trên xuống (top-downanalysis): thực chất là phân rã yếu tố phức tạp thành các yếu tố đơn giản hơn

- Kỹ thuật chuyển đổi DFD vật lý (trong đó chứa đựng các yếu tố vật lý nhưđĩa, băng từ, giấy, máy in ) thành DFD logic (đã loại bỏ các yếu tố vật lý)

- Kỹ thuật chuyển đổi DFD của hệ thống cũ thành DFD của hệ thống mớibằng cách thêm, bớt, hiệu chỉnh lại các yếu tố trên DFD cũ

110

2.1 Một số kỹ thuật thường sử dụng trong công nghệ phần mềm

Các kỹ sư phần mềm thường sử dụng hai loại công cụ: loại công cụdùng để phân tích (analytical tool) như tinh chỉnh từng bước (stepwiserefinement) hoặc phân tích mối quan hệ vốn-lãi (cost-benefit analysis), và cácphần mềm được dùng để phát triển, bảo trì các phần mềm khác Các bộ phầnmềm đóng vai trò như máy cái để phát triển các phần mềm khác được gọi làcông cụ CASE (computer-aided software engineering) Trong phần này, chúng ta

sẽ chỉ xem xét kỹ thuật tinh chỉnh từng bước, là kỹ thuật được làm nền tảng chorất nhiều kỹ thuật khác của công nghệ phần mềm Bản chất của tinh chỉnh là

"hoãn đưa ra các quyết định về chi tiết đến chừng nào có thể, nhằm tập trung vàocác điểm trọng yếu nhất" Lý do sử dụng kỹ thuật tinh chỉnh chính là định luật doMiller đưa ra vào năm 1956, trong đó nói rằng con người ta cùng lúc chỉ có thểtập trung sự chú ý của họ vào một vấn đề Khi phát triển phần mềm thường cókhá nhiều vấn đề cần xem xét trong cùng thời gian Ví dụ như class thường cónhiều hơn 7 thuộc tính và phương thức, mỗi khách hàng thường có nhiều hơn 7yêu cầu Kỹ thuật tinh chỉnh giúp cho các kỹ sư phần mềm chỉ cần chú ý tớikhoảng 7 vấn đề thích hợp nhất tại mỗi thời điểm trong quá trình phát triển phầnmềm

2.2 Một số dạng biểu đồ thường sử dụng

Như chúng tôi đã đề cập, việc dùng đồ họa để biểu diễn các vấn đềđược sử dụng từ khá lâu và tỏ ra khá hiệu quả, không chỉ riêng trong lĩnh vựccông nghệ phần mềm mà cả trong các lĩnh vực khác Biểu diễn đồ họa cho chúng

ta một hình ảnh trực quan, dễ nắm bắt hơn là viết hoặc sử dụng lời nói Trongcông nghệ phần mềm, kỹ thuật này chủ yếu được dùng từ pha đặc tả, nhưng đôikhi được sử dụng cả trong pha yêu cầu để làm cho vấn đề được rõ ràng hơn Ví

dụ, trong pha yêu cầu có thể dùng sơ đồ biểu diễn tổ chức một cơ quan, sự traođổi thông tin giữa các bộ phận Ta thường gặp những dạng sơ đồ sau đây trongcông nghệ phần mềm:

2.2.1 Biểu đồ phân cấp chức năng (FD)

Biểu đồ phân cấp chức năng (functional diagram, FD) là loại biểu

đồ có cấu trúc cây diễn tả sự phân rã dần dần các chức năng từ đại thể đến chitiết Mỗi nút trong biểu đồ là một chức năng, và quan hệ duy nhất giữa các nút là

quan hệ bao hàm: chức năng trong nút cha bao gồm các chức năng trong các nútcon Hình 5.1 sau là biểu đồ biểu diễn các chức năng quản lý của một doanhnghiệp.

Hình 5.1 Một biểu đồ phân cấp chức năng

Đặc điểm của biểu đồ chức năng là:

- Cho một cách nhìn khái quát, từ đại thể đến chi tiết về các chức năng,nhiệm vụ cần thực hiện

- Dễ xây dựng, bằng các phân rã dần các chức năng từ trên xuống

- Thiếu sự trao đổi thông tin giữa các chức năng

Đối với hệ thống phức tạp thì sự trao đổi thông tin giữa các chức năng làkhông thể thiếu, do đó biểu đồ này chỉ được sử dụng làm mô hình chức năng nhưphần mở đầu của pha đặc tả, hoặc thậm chí được sử dụng trong pha yêu cầu hoặctrong phần riêng về tìm hiểu lĩnh vực ứng dụng

Đối với hệ thống đơn giản, các chức năng được xử lý một cách độc lập (tức làkhông có trao đổi thông tin cho nhau) thì mô hình phân tích chức năng có thể sửdụng làm tài liệu đặc tả cho hệ thống Có thể thấy rằng, những xử lý thực sự chỉxẩy ra ở các nút lá, vì chức năng ở nút cha lại được phân rã thành các chức năng

ở các nút con của nó Thường thì chức năng ở nút lá là khá đơn giản, có thể giảithích trực tiếp mà không cần phân rã tiếp Cách diễn tả thao tác cần thực hiện ởnút lá được gọi là đặc tả chức năng và gọi tắt là P-spec (process specification)

Mô tả này thường được trình bày một cách ngắn gọn, không vượt quá mộttrang giấy A4, và gồm hai phần: đầu đề và thân Đầu đề gồm tên chức năng, các

dữ liệu vào, dữ liệu hoặc kết quả ra Phần thân mô tả nội dung xử lý, ví dụ côngthức toán học, bảng hoặc cây quyết định, sơ đồ khối, ngôn ngữ tự nhiên cấu trúchóa Hình sau là một ví dụ về đặc tả chức năng

112

Theo dõi

nhân sự Trả công Kế toán thu chi tổng hợpKế toán

Quản lý doanh nghiệp

Đầu đề:

Tên chức năng:Trả công

Đầu vào: Hệ số lương a và số ngày công n trong

Hình 5.3 Một sơ đồ tổ chứcBởi sự phân cấp quản lý cũng thường được áp dụng trong các cơ quan, chonên sơ đồ tổ chức cũng có dạng cây Nói chung cũng có sự tương ứng giữa tổchức và chức năng, nhưng sự tương ứng này không nhất thiết là 1-1, do đó cấutrúc cây phân cấp chức năng có thể không có dạng như cây sơ đồ tổ chức Cácnút trên cây chức năng biểu thị các chức năng tức là công việc cần thực hiện; còncác nút trên cây sơ đồ tổ chức lại là tên các bộ phận

Sơ đồ tổ chức chỉ được dùng khi cần thiết trong pha yêu cầu hoặc trong phầnriêng về tìm hiểu lĩnh vực ứng dụng

- Chỉ rõ các công việc cần thực hiện

- Chỉ rõ trình tự các công việc và các thông tin được chuyển giao giữa cáccông việc đó

Ban Giám đốc

Loại biểu đồ này được IBM đề xuất SD phục vụ cho sự diễn tả ở mức độ vật

lý và cũng khá dễ hiểu SD được sử dụng nhiều vào những năm 60-70 của thế kỷtrước Chúng thường được sử dụng ở giai đoạn khảo sát hệ thống cũ hoặc ở giaiđoạn thiết kế Ngày nay các phương tiện xử lý và lưu trữ thông tin khá đa dạng,nên việc xây dựng biểu đồ quá chi tiết, chỉ rõ cả các phương tiện lưu trữ sẽ làmcho biểu đồ trở nên quá phức tạp và bị hạn chế trong ứng dụng, do đó người ta ít

sử dụng

2.2.3 Biểu đồ luồng dữ liệu (DFD)

Biểu đồ luồng dữ liệu, tên tiếng Anh là "data flow diagram"(DFD), là một loại biểu đồ được sử dụng để diễn tả quá trình xử lý thông tin củamột hệ thống với các đặc điểm sau:

- Sự diễn tả là ở mức logic (nghĩa là không chỉ rõ phương tiện xử lý và lưutrữ thông tin)

- Chỉ rõ các công việc cần thực hiện

- Chỉ rõ trình tự các công việc và các thông tin được chuyển giao giữa cáccông việc đó

Các tác giả sử dụng một số biểu tượng khác nhau để biểu diễn DFD Sau đây

là 4 biểu tượng mà Gane và Sarsen đã sử dụng:

(1)Các tác nhân: Một tác nhân (hay còn được gọi chính xác hơn là tác nhân

ngoài hay điểm mút), là một thực thể ngoài hệ thống, có trao đổi thông tinvới hệ thống (Thực thể là một đối tượng tồn tại trong thế giới thực, ví dụ:người, dự án, xe máy)

Tác nhân trong DFD được biểu diễn bằng một hình vuông, bên trong làtên tác nhân Ví dụ tác nhân "khách hàng" được biểu diễn như sau:

(Một số tác giả sử dụng biểu tượng hình chữ nhật)

(2)Các chức năng: Một chức năng là một thao tác biến đổi dữ liệu (thao tác

này có thể gồm nhiều thao tác khác nên còn được gọi là quá trình)

Chức năng được biểu diễn bằng hình chữ nhật có góc tròn Ví dụ chứcnăng "lập hóa đơn" được biểu diễn như sau:

114

Kháchhàng

Lập hóa đơn

(Một số tác giả sử dụng hình tròn hoặc hình ô van.

(3)Các luồng dữ liệu: một luồng dữ liệu là một tuyến truyền dẫn thông tin.

Luồng dữ liệu được biểu diễn bằng mũi tên, phía trên mũi tên là tên củaluồng dữ liệu Ví dụ luồng dữ liệu "hóa đơn đã lập" được biểu diễn nhưsau:

(4)Các kho dữ liệu: Một kho dữ liệu là nơi chứa dữ liệu để sử dụng về sau.

Tên kho dữ liệu được chứa trong một hình chữ nhật mở về phía bên phải

Ví dụ kho dữ liệu "Hàng hóa" chứa danh sách các mặt hàng được biểudiễn như sau:

Có tác giả sử dụngbiểu tượng là hai đoạn thẳng song song, ở giữa là tênkho dữ liệu Ví dụ kho dữ liệu "khách hàng" chứa danh sách các kháchhàng được biểu diễn như sau:

Ghi chú: từ định nghĩa các biểu tượng, ta có thể rút ra một số điều cần lưu ýnhư sau:

- Không có luồng dữ liệu giữa hai tác nhân ngoài Ví dụ với hệ thống phầnmềm hỗ trợ bán hàng của cửa hàng H có thể có các tác nhân ngoài là kháchhàng K và nhà cung cấp C Rõ ràng có thể có mối liên hệ giữa khách hàng Kvới nhà cung cấp C, nhưng mối liên hệ này không liên quan đến hệ thống nênkhông được đưa vào biểu đồ

- Không có luồng dữ liệu trực tiếp giữa hai kho dữ liệu (vì không có hai khokhác nhau chứa cùng một loại dữ liệu)

- Nếu luồng dữ liệu cùng tên với đầu ra của chức năng thì không cần viếtlên luồng dữ liệu Ví dụ:

Hóa đơn đã lập

Hàng hóa

Hàng hóa

Khi sử dụng DFD để làm tài liệu đặc tả người ta thường bổ sung thêm một sốyếu tố nữa Ví dụ, ta thêm vào biểu đồ những biểu tượng diễn tả sự điều khiển Cũng giống với biểu đồ phân cấp chức năng, trong DFD đối với các chứcnăng đơn giản ở mức cuối cùng phải có thêm P-spec, tức là bản đặc tả chứcnăng

2.2.4 Một số dạng biểu đồ khác

Ngoài các dạng biểu đồ nói trên người ta còn sử dụng nhiều dạngbiểu đồ khác, như biểu đồ MERISE chẳng hạn Thậm chí, đôi khi nếu thấy cầnthiết, người ta có thể tự tạo lấy biểu đồ để diễn tả vấn đề của mình (ví dụ biểu đồdiễn tả quá trình trao đổi công văn giấy tờ ở một cơ quan chẳng hạn) Nói chocùng, mục tiêu của chúng ta là xây dựng được phần mềm đúng như mong đợi,vừa dễ bảo trì lại hoạt động chính xác Nếu bằng cách nào đó, có thể làm đượcđiều này và có thể giải thích cho mọi người hiểu thì ta có thể làm Những kiếnthức về công nghệ phần mềm mà con người đã tích lũy được dĩ nhiên là nguồntham khảo quý giá

2.2.5 Các phương tiện đặc tả chức năng

Một điểm chung trong FD và DFD là để diễn tả một yếu tố, ta phân

rã nó thành các yếu tố đơn giản hơn Ví dụ như với FD chẳng hạn, ta phân rã cácchức năng theo sơ đồ hình cây cho đến khi gặp chức năng đơn giản nhất khôngphân rã được nữa thì dừng lại Trên cây biểu diễn thì chức năng không phân rãđược thể hiện bằng nút lá và phải giải thích cụ thể Cách giải thích này được gọi

là đặc tả chức năng (P-Spec), như chúng ta đã xem xét ở phần trên Ở ví dụ trên,

ta đã dùng một công thức toán học làm phương tiện mô tả trong phần thân của spec (Lương= n*a*10) Người ta còn sử dụng một số phương tiện khác như sau:

P Các bảng quyết định và cây quyết định

Được sử dụng khi chức năng được đặc tả thực chất là một sự phân chia cáctrường hợp tùy thuộc vào một điều kiện nào đó

- Các sơ đồ khối

116Lập hóa đơn Khách hàng

Sơ đồ khối sử dụng 3 loại biểu tượng: hình thoi biểu diễn điều kiện, hình chữnhật biểu diễn hành động phải làm và mũi tên biểu diễn sự chuyển giao điềukhiển (chuyển giao quyền thực hiện) Với vấn đề đơn giản thì việc diễn tả bằng

sơ đồ khối khá dễ hiểu, vì vậy nó thích hợp cho người mới lập trình Nếu nhưcác DFD chỉ tập trung diễn tả những việc phải làm thì sơ đồ khối ngoài các việcphải làm, còn chỉ ra cách dẫn dắt thực hiện các việc đó Vì vậy với vấn đề lớn, cónhiều yếu tố và nhiều mối quan hệ thì sơ đồ khối rất phức tạp và khó xây dựng

Do đó sơ đồ khối không thích hợp cho việc diễn tả các chức năng phức tạp

- Ngôn ngữ giả lập trình (mã giả)

Về hình thức trông giống ngôn ngữ lập trình nhưng bỏ đi những chi tiết cụthể Mục đích là giúp người đọc hiểu được thuật toán và cách thức viết chươngtrình cho một ngôn ngữ lập trình bất kỳ nào đó

2.3 Phân tích có cấu trúc một hệ thống cụ thể

Có thể nói rằng: không có một chuẩn mực chung để theo đó cứ thựchiện từng bước là có thể xây dựng nên một phần mềm đáp ứng được yêu cầu đặt

ra Cho dù đã có những nguyên lý chung, nhưng với từng vấn đề cụ thể, mỗi kỹ

sư phần mềm lại có cách nhìn nhận và phân tích khác nhau, do đó đưa ra cáccách giải quyết vấn đề khác nhau

Bây giờ chúng ta sẽ bắt đầu công việc phân tích theo phương pháp cấu trúccho một bài toán cụ thể: xây dựng phần mềm hỗ trợ công việc bán hàng cho mộtcửa hàng chuyên bán các đĩa CD lưu trữ các phần mềm máy tính, như đĩa cài đặtVietkey, Microsoft Office, VB, đĩa trò chơi

Giả sử chủ nhân của cửa hàng có tên là Hoa Hoa mua các phần mềm từ cácnhà cung cấp khác nhau và bán lại cho khách hàng Cô lưu trữ các đĩa đượcnhiều người ưa chuộng và đặt mua các loại đĩa khác nếu cần Hoa cho một vài cơquan và cá nhân có thể mua chịu Có thể hình dung công việc hàng ngày của Hoadiễn ra như sau:

Khi có khách hàng đến, hoặc là họ xem catalog chứa danh sách các băng đĩa,hoặc họ nói ra tên băng đĩa cần mua Hoa sẽ xem trên các ngăn để đĩa, hoặctrong catalog để tìm đĩa mà khách yêu cầu Nếu tìm thấy thì Hoa sẽ xem trongdanh sách khách hàng xem người khách này còn nợ không Nếu khách đồng ýmua thì hoặc là Hoa viết hoá đơn thanh toán bằng tiền mặt, hoặc lại ghi vào sổ

nợ Giả sử bạn là người giúp Hoa tin học hóa công việc bán hàng này, và Hoa trở

thành khách hàng đặt bạn làm phần mềm Gane và Sarsen đã đề nghị một kỹthuật gồm 9 bước để phân tích nhu cầu khách hàng (ở đây là khách hàng đặt làmphần mềm, vậy chính là Hoa) như sau:

Bước 1 Xây dựng DFD (biểu đồ luồng dữ liệu)

Căn cứ vào vấn đề thực tế, bước đầu tiên có thể xây dựng DFD logic như sau:

Hình 5.4 DFD đầu tiên trong quá trình tinh chỉnhCăn cứ vào biểu đồ này ta có thể hình dung ra hai cách diễn tả như sau:

Cách diễn tả 1: kho dữ liệu đĩa CD chứa nhiều đĩa, ví dụ 900 đĩa chẳng hạn Các đĩa được xếp trên các ngăn Trong ngăn kéo có một vài catalog chứadanh sách các đĩa này Kho dữ liệu khách hàng chính là tập các danh thiếp củakhách hàng được buộc bằng dây cao su, kèm theo là danh sách các khách hàng

mà tiền nợ đã quá hạn Thao tác "xử lý yêu cầu mua hàng" có nghĩa là khi cókhách hàng yêu cầu mua đĩa nào đó, Hoa sẽ tìm trên các giá để đĩa và có thể làtrong các catalog Sau đó Hoa lại tìm trong tập danh thiếp, rồi danh sách kháchhàng để kiểm tra khách hàng còn nợ chưa trả không Nếu mọi việc ổn thì Hoa bắtđầu viết hóa đơn đưa cho khách hàng Đây là mô tả các thao tác trong thực tế,chưa hề có bóng dáng của máy tính, nó phản ánh đúng những thao tác mà Hoathực hiện hàng ngày

Cách diễn tả 2: kho dữ liệu đĩa CD hoặc danh sách khách hàng là các tệpđược lưu trữ trên đĩa cứng Còn thao tác xử lý yêu cầu có nghĩa là Hoa nhập từbàn phím tên khách hàng và tên đĩa cần mua Máy tính sau đó sẽ tìm kiếm trêntệp chứa danh sách các đĩa và danh sách khách hàng Trong trường hợp việc tìmkiếm có kết quả và mọi điều kiện cần thiết thỏa mãn thì hóa đơn sẽ được in racho khách hàng Các diễn tả này tương ứng với giải pháp tin học hóa với mọithông tin được cung cấp trực tuyến (available online)

Trên đây là hai cách diễn tả Thực ra còn có thể có nhiều cách khác

118

Khách hàng Xử lý yêu cầu mua hàng

Kho đĩa CD

Yêu cầu

Hóa đơn

Thông tin về đĩa

Thông tin về tiền nợ

Danh sách khách hàng

Bây giờ chúng ta sẽ tinh chỉnh biểu đồ này Ta thấy rằng thao tác "xử lý yêucầu khách hàng" còn quá đơn giản Trong thực tế khi khách hàng muốn mua mộtđĩa mà không có thì thường chủ hàng ghi lại thông tin này Nếu có nhiều kháchhàng hỏi mua thì chủ hàng sẽ gửi yêu cầu của họ tới các nhà cung cấp để mualoại đĩa mới này Ta sẽ tinh chỉnh DFD 5.4 bằng cách chi tiết hoá thao tác "xử

lý yêu cầu khách hàng" như sau: nếu khách hàng yêu cầu thì Hoa xem xét ở khođĩa, đồng thời kiểm tra các thông tin về khách hàng Nếu đĩa có trong kho vàthông tin về khách hàng không có vấn đề gì thì hóa đơn sẽ được lập và gửi chokhách hàng Nếu đĩa không có trong kho thì yêu cầu này tạm thời được đưa vàokho dữ liệu "các yêu cầu đang treo", tức là các yêu cầu chưa được đáp ứng Nếu

số yêu cầu đang treo đạt đến một số nào đó hoặc yêu cầu đã chờ 5 ngày thì mộtđơn đạt hàng trong đó liệt kê các yêu cầu đang treo (tức là danh sách các đĩakhách hàng yêu cầu mà không có trong kho) rồi gửi tới các nhà cung cấp

Từ những điều mô tả này ta có DFD sau:

Hình 5.5 DFD trong bước tinh chỉnh thứ haiTuy nhiên DFD này cũng chưa phải là cái cuối cùng Ví dụ, còn thiếu thôngtin về luồng dữ liệu biểu thị các đĩa được nhập từ các nhà cung cấp và cách thứcthanh toán

DFD đầy đủ của bài toán này có thể chiếm tới 6 trang giấy Đây chỉ mới làbài toán nhỏ Đối với vấn đề lớn thì không thể biểu diễn trong một DFD

Thông tin về đĩa

Thông tin về tiền nợ

Danh sách khách hàng

Lập hóa đơn

Hóa đơn

Đĩa bán cho khách hàng

Các yêu cầu còn treo

Đĩa yêu cầu nhưng không có

Đặt hàng nhà cung cấp

Thông tin về đĩa cần đặt hàng

Nhà cung cấp

Địa chỉ hoặc số điẹn thoại

Lúc đó, nhiều DFD được xây dựng và được sắp xếp theo kiểu phân tầng Mỗinút tại một mức nào đó sẽ được phát triển thành một DFD đầy đủ ở mức thấphơn.

Bước 2 Quyết định sẽ tin học hóa phần nào trong các công việc nói trên, và

theo cách gì, xử lý theo bó hay tương tác? (batched processing or interactiveprocessing, nguyên bản là xử lý theo bó hay trực tuyến, online) Sau khi xác địnhđược phần cần tin học hóa thì trong 3 bước tiếp theo của kỹ thuật Gane và Sarsen

là tinh chỉnh từng bước các luồng dữ liệu, các thao tác và các kho dữ liệu

Bước 3 Xác định chi tiết của các luồng dữ liệu.

Trước hết xác định xem những mục dữ liệu nào có trong luồng dữ liệu Trong

ví dụ trên đây thì một yêu cầu từ khách hàng có thể bao gồm:

Yêu cầu:

Định danh yêu cầu (order identification hay viết tắt là order ID)

Thông tin về khách hàng (họ tên, giới tính, địa chỉ )

Thông tin về các đĩa cần mua (tên đĩa, giá cả )

Tiếp theo là tinh chỉnh các mục dữ liệu Đối với vấn đề lớn thì cần xây dựng

từ điển dữ liệu ghi lại các giải thích cần thiết của tất cả các thành phần dữ liệu

Ví dụ như, order_ID là số nguyên 10 chữ số, là số không được lặp lại vàđược tự động tạo ra bởi một thủ tục có tên là gen_order_ID chẳng hạn Tất nhiên

là từ điển dữ liệu cần được trình bày theo dạng văn bản có cầu trúc, ví dụ theocác cột: tên, mô tả, giải thích, Trong từ điển này ngoài tên các mục dữ liệu còn

có các hàm (thủ tục) nếu cần thiết Ví dụ với luồng dữ liệu "yêu cầu" có thể cóthủ tục very_order_is_valid chẳng hạn, với đầu vào là các thông tin về yêu cầu

và đầu ra là có hợp lệ hay không

Bước 4 Định nghĩa logic của các chức năng (các thao tác xử lý).

Sau khi các luồng dữ liệu đã được xác định, bước tiếp theo là định nghĩa cácchức năng xử lý chúng, tức là cần mô tả điều gì xảy ra trong các nút chức năng Giả sử hệ thống có một thao tác "giảm giá cho kỹ sư CNTT", lúc đó Hoa cầncho người làm phần mềm biết thông tin về sự giảm giá, ví dụ nếu kỹ sư CNTTmua trên 4 đĩa thì được giảm giá 15%, mua ít hơn được giảm 10% Để tránh mô

120

tả bằng ngôn ngữ tự nhiên, ta có thể biểu diễn những điều này bằng cây quyếtđịnh như sau:

Hình 5.6 Cây quyết định diễn tả sự giảm giá

Bước 5 Định nghĩa các kho dữ liệu.

Trong bước này cần xác định những dữ liệu được chứa trong mỗi kho dữ liệu

và khuôn dạng của chúng

Bước 6 Định nghĩa các tài nguyên vật lý.

Trong phần này ta xác định cụ thể cách lưu trữ dữ liệu Ví dụ, nếu ta sử dụng

hệ quản trị cơ sở dữ liệu để thao tác với dữ liệu như Foxpro, Access, thì ta phảiđịnh nghĩa cấu trúc các bảng

Bước 7 Xác định các đặc tả vào ra.

Xác định màn hình nhập liệu, các dạng biểu mẫu xem thông tin, các dạng báocáo cần in ra

Bước 8 Xác định kích cỡ.

Phần này cần tích toán kích cỡ các tệp dữ liệu, tính thường xuyên của thao tácnhập dữ liệu: hàng ngày hay hàng giờ, thời gian in ấn các báo cáo định kỳ

Bước 9 Xác định các yêu cầu phần cứng.

Trên cơ sở tính toán ở bước 8, xác định các yêu cầu phần cứng: cần CPU nhưthế nào, tốc độ bao nhiêu, RAM bao nhiêu MB, ổ cứng có dung lượng bao nhiêu,cần máy in màu hay in đen trắng

Tóm lại kỹ thuật đặc tả của Gane và Sarsen gồm 9 bước như sau:

(1) Xây dựng biểu đồ luồng dữ liệu

Khác 0 %

Kỹ sư CNTT

4 đĩa 10%

>5 đĩa 15%

(2) Xác định phần nào của DFD sẽ được tin học hóa.

(3) Xác định chi tiết của các luồng dữ liệu

(4) Định nghĩa logic của các chức năng

(5) Định nghĩa các kho dữ liệu

(6) Định nghĩa các nguồn tài nguyên vật lý

Kỹ thuật này đã có tính hình thức hơn kỹ thuật đặc tả dùng ngôn ngữ tự nhiênnhưng chưa phải là hình thức hoàn toàn Kỹ thuật của Gane và Sarsen thuộc loạinửa hình thức (semiformal technique)

Còn một số kỹ thuật bán hình thức tương tự như kỹ thuật trên đây Có một vài

kỹ thuật hình thức hoàn toàn, như các máy trạng thái hữu hạn, lưới Petri, nhưng để sử dụng những công cụ này đòi hỏi các kiến thức toán khá tốt, là điềukhó thực hiện đối với các kỹ sư phần mềm và đặc biệt là với các khách hàng

3 Phân tích hệ thống về dữ liệu

SA là phương pháp phân tích dựa vào các hành động (chức năng) Vì cáchành động trong một hệ thống phần lớn là xử lý dữ liệu, do đó trong mô hình SAthì dữ liệu cũng được thể hiện, nhưng chỉ đóng vai trò thứ yếu sau hành động màthôi Đối với các hệ thống lớn, đặc biệt là các hệ thống thông tin quản lý, thì dữliệu thường rất lớn, và do đó việc tổ chức dữ liệu một cách hợp lý sẽ làm chotính hiệu quả của hệ thống tăng lên, ví dụ có thể cập nhật dữ liệu nhanh, truyxuất thông tin, in ấn báo cáo nhanh và chính xác Trong nhiều trường hợp, bêncạnh việc phân tích hệ thống về mặt chức năng, người ta còn tiến hành phân tích

về mặt dữ liệu (data-oriented analysis, DOA) và hai việc phân tích này được tiếnhành độc lập nhau, bởi vì người ta muốn tập trung nghiên cứu cấu trúc tĩnh của

dữ liệu (không phụ thuộc vào các xử lý, không phụ thuộc vào thời gian) Mụcđích của phân tích hệ thống về dữ liệu là lập lược đồ khái niệm về dữ liệu, làmcăn cứ cho việc thiết kế cơ sở dữ liệu của hệ thống sau này Sở dĩ nó được gọi làlược đồ khái niệm (để phân biệt với lược đồ vật lý), bởi vì khi thiết kế còn phảichỉnh sửa ít nhiều mới phù hợp cho việc cài đặt trên máy tính

122

Nói rằng việc phân tích hệ thống về mặt dữ liệu được tiến hành độc lập vớiviệc phân tích theo chức năng không có nghĩa là ta bỏ qua mối liên hệ tất yếugiữa các xử lý và dữ liệu, mà ta chỉ tạm hoãn việc xem xét mối liên quan này chotới giai đoạn thiết kế, khi cần lập lược đồ vật lý của cơ sở dữ liệu.

Lược đồ khái niệm về dữ liệu được thành lập theo mô hình thực thể-liên kết(entity-relationship modeling, ERM), rồi được hoàn chỉnh theo mô hình cơ sở dữliệu quan hệ (Relational Database Model, RDM) Trong mục này, chúng ta chỉxem xét sơ lược mô hình ERM cùng mô hình quan hệ được phát triển từ nó

3.1 Thực thể (entity)

Theo từ điển tiếng Việt thì thực thể là cái có sự tồn tại độc lập Như vậy con người là thực thể, còn các thuộc tính như màu sắc không phải là thực thể

Trong mô hình tin học ta cũng dùng khái niệm thực thể để chỉ cái tồn tại trong thế giới thực, nhưng có phần khái quát hơn một chút Thực thể có thể là vậtnhìn thấy được và có thể tiếp xúc được bằng tay như con người, hạt cát, mặt hàng; nhưng cũng có thể là khái niệm trừu tượng như dự án, kế hoạch

Thông thường khi xây dựng mô hình dữ liệu, các thực thể được biểu diễn bằng những hình chữ nhật, ví dụ:

và một thực thể khi đó đại diện cho một lớp đối tượng trong thực tế, chứ không chỉ một trường hợp cụ thể Ví dụ thực thể "khách hàng" sẽ chỉ tập hợp các khách hàng của một cửa hàng mà ta đang quan tâm khảo sát Khi đó khách hàng cụ thể

có tên là "Trần Nguyên Đán", địa chỉ 14 Lò Sũ, Hà Nội là một thể hiện của thực thể "khách hàng" (Cũng có tài liệu định nghĩa thực thể là đối tượng cụ thể, còn kiểu thực thể, hay entity type, mới chỉ một lớp các đối tượng được mô tả bởi cùng một số thuộc tính)

3.2 Thuộc tính (attribute)

Trong một hệ thông tin, ta cần lựa chọn một số tính chất đặc trưng để diễn tả một thực thể, các tính chất này được gọi là các thuộc tính của thực thể

Khách hàng

Ví dụ:

Các thuộc tính: họ tên, địa chỉ, ngày sinh của thực thể "Sinhviên"

Các thuộc tính: tên, giá của thực thể "Mặt hàng"

Giá trị các thuộc tính của một thực thể cho phép diễn tả một trường hợp cụ thể của thực thể và được gọi là thể hiện của thực thể đó

Ví dụ.

("Nguyễn Cao Ráo", "10 Lò Đúc - Hà nội",{19/02/1982}) là một thể hiện của thực thể "Sinh viên"

("Xe máy Dream II",29 000 000) là thể hiện của thực thể "Mặt hàng"

Một thuộc tính được gọi là sơ cấp hay đơn trị khi ta không cần phân tích nó thành nhiều thuộc tính khác Thí dụ khi lưu trữ thông tin nhân sự thì thuộc tính

"Phần lý lịch bản thân" bao gồm các thuộc tính Họ tên, Ngày sinh, Quê quán, Giới tính Do đó thuộc tính "Phần lý lịch bản thân" không phải là đơn trị

Thông thường một thực thể tương ứng với một bảng (hay một quan hệ của

Codd)

Mỗi thực thể phải có một tập thuộc tính mà mỗi giá trị của nó vừa đủ cho phép nhận diện một cách duy nhất một thể hiện của thực thể, tập các thuộc tính này được gọi là các thuộc tính nhận dạng hay là khóa Tập khóa có khi chỉ là mộtthuộc tính, nhưng cũng có khi chứa nhiều thuộc tính Một thực thể có thể chứa nhiều khóa Trong trường hợp đó người ta chọn một khóa làm khóa chính (hay khóa sơ cấp, trong Access khóa này được gọi là Primary key) các khóa còn lại được gọi là các khóa phụ hay khóa thứ cấp Giá trị của một khóa luôn luôn xác định các giá trị khác của các thuộc tính

Hóa đơn

S ố ch ứ ng t ừ Khách hàng Ngày bán Giá tiền

3.3 Mối liên hệ (relationship)

Khái niệm mối liên hệ ở mục này được dùng với nghĩa là liên quan, nhằm nhóm hai hay nhiều thực thể với nhau để biểu hiện một mối liên quan tồn tại trong thế giới thực giữa các thực thể này (vậy khái niệm này khác với khái niệm quan hệ theo cách Codd định nghĩa, vì vậy chúng tôi dùng từ mối liên hệ

để tránh sự nhầm lẫn) Số thực thể tham gia trong mối liên hệ có thể là một số nguyên bất kỳ Tuy nhiên, trong thực tế người ta tránh dùng những mối liên hệ

có quá nhiều thực thể tham gia

Trong một mô hình dữ liệu, các quan hệ được biểu diễn bằng những hình thoi Trong một số trường hợp, mối liên hệ cũng có thể có những thuộc tính riêng

Phân loại các mối liên hệ

Mối liên hệ 1-1 (một-một): Ta nói rằng thực thể A và thực thể B có mối liên

hệ 1-1 nếu mỗi thể hiện của thực thể A được kết hợp với 0 hoặc 1 thể hiện của thực thể B và ngược lại

Ví dụ Mỗi độc giả ở một thời điểm chỉ được đọc một quyển sách.

Hình 5.7 Mối quan hệ 1-1

Mối liên hệ 1- n (một-nhiều): mỗi thể hiện của thực thể A được kết hợp với

0, 1 hoặc nhiều thể hiện của thực thể B và mỗi thể hiện của thực thể B được kết hợp với một thể hiện duy nhất của A Đây là một loại mối liên hệ thông dụng và đơn giản nhất

Ví dụ Trong thực tế ta thấy rằng trong một cửa hàng một nhân viên bán hàng

có thể bán nhiều mặt hàng, nhưng một một mặt hàng chỉ do một nhân viên bán,

do đó ta nói rằng có mối liên hệ một-nhiều giữa các nhân viên bán hàng trong một cửa hàng và các mặt hàng của cửa hàng đó

Hình 5.8 Mối quan hệ 1-n

Mối liên hệ n - m (nhiều-nhiều): mỗi thể hiện của thực thể A được kết hợp với 0 , 1 hoặc nhiều thể hiện của thực thể B và ngược lại

Ví dụ Một hóa đơn dùng để thanh toán một hay nhiều sản phẩm.

Một sản phẩm có thể xuất hiện trong 0,1 hay nhiều hóa đơn

Hình 5.9 Mối quan hệ nhiều-nhiều

3.4 Mô hình cơ sở dữ liệu quan hệ

Có thể đưa ra định nghĩa có tính trực quan sau đây về mô hình cơ sở

dữ liệu quan hệ:

Mô hình cơ sở dữ liệu quan hệ (rerational database model, RDM) hay gọi đơngiản: mô hình quan hệ là một mô hình dùng để biểu diễn dữ liệu, trong đó dữ liệu được biểu diễn trong các bảng hai chiều Thường thì mỗi bảng tương ứng với một kiểu thực thể trong thực tế, tuy nhiên cũng có trường hợp thông tin về một thực thể trong thực tế có thể được lưu trữ trong nhiều bảng (ví dụ thực thể

"nhân viên" trong cơ quan có thể được lưu trử trong bảng "thông tin cá nhân" và bảng "công việc" chẳng hạn) Dòng đầu tiên của mỗi bảng biểu diễn tên các thuộc tính của thực thể, còn các dòng tiếp theo trong bảng là giá trị các thuộc tính của một cá thể thuộc thực thể này, ví dụ như bảng sau:

Ví dụ Bảng hồ sơ các nhân viên của một cơ quan:

Hóa đơn

STT MS HOTEN NS TD QUE GT LUONG 1

2

3

4

01 02 03 04

Quang Huy Trần Kiểm Thu Lan Tuyết Mai

1982 1979 1956 1964

Đại học Cao Đẳng Tiến sỹ Trung cấp

Hòa Bình Yên Bái Hải Dương Nam Định

Nam Nam Nữ Nữ

450 390 480 425

Về hình thức có vẻ như không có sự khác biệt giữa ERM và RDM Thực ra thì vẫn có sự khác biệt: ERM tập trung vào mối liên hệ giữa các thực thể, còn RDM lại chú ý hơn đến mối liên hệ giữa các thuộc tính trong một bảng, giữa các thuộc tính trong các bảng Trong RDM, mối liên hệ giữa các bảng cùng được khảo sát thông qua mối liên hệ giữa các thuộc tính Nói tóm lại, ERM có thể xem

là mô hình ban đầu, còn RDM là một mô hình có cơ sở toán học vững chắc Tuynhiên về mặt thực hành thì hai mô hình khác biệt không nhiều ERM không phải

là kỹ thuật mới Nó được đưa ra từ năm 1976 bởi P.P.Chen Tuy nhiên, hiện nay ERM như đang được hồi sinh vì nó trở thành một phần tử của OOA

4 Kiểm thử pha đặc tả

Như đã nói dến trong chương 1, phần lớn các lỗi trong phần mềmchuyển giao cho khách hàng thường do lỗi trong tài liệu đặc tả gây nên Các lỗinày chỉ bị phát hiện khi phần mềm được cài đặt trên máy tính của khách hàng Vìvậy nhóm SQA cần phải kiểm tra tài liệu đặc tả một cách kỹ lưỡng, nhận ranhững điều mâu thuẫn, mơ hồ hoặc chưa đầy đủ Ngoài ra, nhóm SQA còn phảixem xét tính khả thi của đặc tả, ví dụ các phần cứng nói đến trong phần này thực

sự có phù hợp với việc cài đặt phần mềm không, dung lượng các bộ nhớ trênmáy khách hàng có đủ để vận hành phần mềm không Tài liệu đặc tả phải có thểkiểm thử được, ví dụ có thể dựa vào tài liệu này mà kiểm tra tiến độ công việcthực hiện, có thể so sánh với từng mục trong pha yêu cầu Tài liệu đặc tả cũngnên có các phần, các mục được đánh số tương ứng với tài liệu xác định yêu cầu

để tiện theo dõi Nếu có bản mẫu trong pha yêu cầu thì trong tài liệu đặc tả cũngnên có các mục tương ứng với các chức năng trong bản mẫu

Cách tốt nhất để kiểm tra tài liệu đặc tả là xem xét Đại diện của nhóm đặc tả

và nhóm khách hàng cùng ngồi lại dưới sự chủ tọa của thành viên nhóm SQA,xem xét kỹ lưỡng bản đặc tả, phát hiện những sai sót, những điều chưa chínhxác

Sau khi khách hàng đã vừa lòng với bản đặc tả thì chuyển sang xem xét bản

kế hoạch thực hiện dự án Cũng như với bản đặc tả, cách tốt nhất để kiểm tra bản

kế hoạch là xem xét Hai yếu tố cần chú ý là thời gian thực hiện và chi phí Thường thì các ước lượng về thời gian và chi phí được hai hoặc nhiều nhómnghiên cứu độc lập nhau, sau đó cùng trao đổi để đưa ra kết luận thống nhất

5 Tài liệu báo cáo trong pha đặc tả có cấu trúc

Tài liệu được biên soạn trong pha đặc tả bao gồm hai tài liệu: bản báocáo đặc tả và bản kế hoạch quản lý dự án phần mềm (SPMP)

V – PHA PHÂN TÍCH HƯỚNG ĐỐI TƯỢNG

Pha đặc tả còn được gọi là pha phân tích, đó là nguyên nhân để ta gọi phađặc tả dùng phương pháp hướng đối tượng là phân tích hướng đối tượng

1 Phân tích hướng đối tượng

1.1 Xây dựng mô hình use-case (use-case modeling)

Xác định xem những kết quả gì được tính toán bởi hệ thống (chưa cần

để ý đến cách thức và trình tự tính toán) Thực chất là xác định các use-casetrong hệ thống và xây dựng các biểu đồ use-case cùng các kịch bản kèm theo(kịch bản, tiếng Anh là scenario, là một thể hiện cụ thể của use-case) Bước nàycòn được gọi là mô hình hóa chức năng (functional modeling), mà phần lớn làhướng hành động (action oriented) Như vậy, có thể nói rằng phép phân tíchtrong giai đoạn này là phân tích hướng chức năng

1.2 Xây dựng mô hình lớp (class modeling)

Xác định các lớp và các thuộc tính của chúng Sau đó xác định mốiquan hệ và tác động qua lại giữa các lớp Hiện tại các thông tin dưới dạng biểu

đồ trông giống như biểu đồ thực thể-quan hệ và được gọi là biểu đồ lớp Bướcnày phần lớn là định hướng dữ liệu (data oriented)

1.3 Xây dựng mô hình động (dynamic modeling)

Xác định các hành động được thực hiện bởi (tới) các lớp hoặc các lớpcon Biểu diễn các thông tin này trong dạng biểu đồ gần giống với biểu đồ các

128

máy hữu hạn trạng thái và gọi là biểu đồ trạng thái Bước này là hướng hànhđộng (action oriented).

Trong thực tế, ba bước trên đây không phải bao giờ cũng được thực hiện lầnlượt theo thứ tự Thay đổi trong một bước sẽ dẫn tới thay đổi trong các bước kia Như vậy ba bước trên đây của OOA thực chất được thực hiện đồng thời Việcthực hiện các bước như thế nào sẽ phụ thuộc vào vấn đề cụ thể

Có thể nói rằng để thực hiện tốt pha phân tích, đòi hỏi sự sáng tạo và kinhnghiệm thực tế của các kỹ sư phần mềm Sau đây chúng ta sẽ tìm hiểu cách thứcthực hiện pha phân tích thông qua bài toán Air Gourmet đã được giới thiệu

2 Quản lý thông tin về chế độ ăn đặc biệt trên máy bay

Chúng ta đã tìm hiểu bài toán xây dựng phần mềm để quản lý dịch vụ cungcấp thức ăn đặc biệt cho hành khách trên các chuyến bay Để các bạn tiện theodõi, chúng tôi xin nhắc lại vài nét chính

Khi hành khách đi máy bay thì họ được cung cấp các bữa ăn Do những điềukiện hạn chế, trên máy bay người ta không thể chuẩn bị quá nhiều món ăn để chokhách hàng lựa chọn theo ý mình Do đó, khi hành khách đặt vé thì nhân viênbán vé hỏi về thức ăn mà họ yêu cầu Các yêu cầu này sau đó sẽ được xử lý, vàngười ta cố gắng phục vụ các thức ăn đặc biệt như hành khách yêu cầu Thôngtin phản hồi cũng được ghi nhận thông qua các phiếu đánh giá của hành khách Bài toán đặt ra là xây dựng phần mềm để quản lý thông tin về vấn đề này Trong tài liệu tiếng Anh người ta gọi vấn đề này là the Air Gourmet Nếudịch ra tiếng Việt thì từ air gourmet có nghĩa là dịch vụ cung cấp thức ăn đặcbiệt cho các hành khách đi máy bay (gourmet theo tiếng Anh có nghĩa là ngườisành ăn, a gourmet restaurant có nghĩa là cửa hàng phục vụ những người sành

ăn, tức là cửa hàng gồm các thức ăn chọn lọc) Để đơn giản trong cách viết,chúng tôi tạm để nguyên tiếng Anh Bản mẫu nhanh viết bằng C và Java của airgourmet có thể tìm thấy ở trang web www.mhhe.com/engcs/compsci/schach Thực đơn chính của bản mẫu này liệt kê danh sách các use-case Tuy nhiêntrong số các use-case chỉ có một vài use-case là chủ chốt mà chúng tôi sẽ giớithiệu ngay sau đây Những use-case đóng vai trò phụ, thực chất là được mở rộng

từ các use-case chính, sẽ không được nói tới trong phần phân tích

Bằng phương pháp giới thiệu trên đây, bước đầu ta có thể xác định được haiuse-case chính của hệ thống như sau:

Use-case đặt chỗ:

Hình 5.10 Use-case đặt chỗ

Để hiểu rõ hơn use-case này, ta cần sử dụng hai scenario: chuẩn và ngoại lệ.Tuy nhiên trong trường hợp này ta không gọi là scenario ngoại lệ (exception) màgọi là mở rộng (extended scenario) để chỉ những tình huống khác có thể xảy ra

Để đơn giản trong cách viết, chúng ta tạm gọi Air Gourmet là AG, cơ sở dữliệu của air gourmet là AGD, hành khách là HK, điện thoại viên (phoneoperator), người trực tiếp nghe điện thoại của hành khách, là ĐTV

Scenario chuẩn:

1 HK gọi điện tới phòng vé xin đặt chỗ cho chuyến bay

2 ĐTV đề nghị hành khách cho biết họ tên và địa chỉ

3 HK cung cấp các thông tin được yêu cầu

4 ĐTV hỏi hành khách ngày giờ và số chuyến bay

5 HK cung cấp các thông tin được yêu cầu

6 ĐTV hỏi HK xem có yêu cầu gì về thức ăn đặc biệt không

7 HK nói loại thức ăn đặc biệt nếu có yêu cầu

8 ĐTV hỏi xem HK có yêu cầu gì về chỗ ngồi không

9 KH nói chỗ ngồi ưa thích

10.ĐTV yêu cầu trả tiền

11.HK cho biết số thẻ tín dụng

12.ĐTV chuyển các thông tin đặt chỗ tới AGD

13.AGD đưa ra mã số đặt chỗ (reservation ID)

130

Hành khách

Air Gourmet

Đặt chỗ

Điện thoại viên