thiết kế và kiến trúc của Microsoft.NET

Để thực hiện điều này, người quản trị dự án cần nghiên cứu và phân tích các vấn đề nghiệp vụ, các yêu cầu nghiệp vụ, tầm nhìn của dự án, các mục tiêu kinh doanh, và các đặc tính của ngườ

Mục lục

Mục lục 1

Lời giới thiệu 2

Danh mục hình ảnh 3

Danh mục bảng 4

Danh mục từ tiếng Anh 4

Giới thiệu về định nghĩa thiết kế và kiến trúc của Microsoft.NET 5

Hệ thống quản lí nhân sự trong trường học 37

Tài liệu tham khảo 72

Lời giới thiệu

Giao diện là một phần của ứng dụng, nó cung cấp các cơ chế giao tiếp giữa người dùng và các tầng dịch vụ của hệ thống Trong một số trường hợp nó được xem như phần quan trọng nhất của một chương trình ứng dụng, bởi vì với hầu hết người dùng nó chính là chương trình Một thiết kế giao diện tốt sẽ tạo một đảm bảo cho sự thành công của dự án

Các thành phần giao diện sẽ hiển thị dữ liệu và nhận dữ liệu từ người dùng, xử

lí các sự kiện tương ứng với các hành động của người dùng, và giúp họ theo dõi tiến trình trong các thao tác

Tài liệu này gồm hai phần, Phần I Định nghĩa thiết kế và kiến trúc của Microsoft.NET, Phần II Tạo Prototype cho chương trình quản lí nhân sự

Phẩn I: Định nghĩa thiết kế và kiến trúc của Microsoft.NET, là một quy trình

do Microsoft đề nghị cho các dự án phần mềm, quy trình được chia ra năm giai đoạn chính Trong đó, thiết kế Prototype nằm chủ yếu trong giai đoạn “Thiết kế”,

do đó tài liệu này tập trung vào các bước trong giao đoạn thiết kế

Phần II: Tạo Prototype cho chương trình quản lí nhân sự, các tài liệu trong quá trình tạo Prototype cho dự án Quy trình tạo Prototype ít các giao đoạn hơn xây dựng một hệ thống hoàn chính Ví dụ sẽ giảm nhẹ các giao đoạn thiết kế Cơ sở dữ liệu, Bảo mật, Tỷ xích

Danh mục hình ảnh.

Trang

Hình 9: Trách nhiệm của từng vai trò trong quá trình thiết kế logic 21Hình 10: Quan hệ giữa thiết kế vật lí và thiết kế khái niệm, logic 24Hình 11: Các bước trong quá trình thiết kế vật lí và liên kết giữa chúng 25Hình 12: Một phần giản đồ cơ sở dữ liệu của hệ thống bán hàng 28

Danh mục từ tiếng Anh

Từ tiếng Anh Giải thích

GroupBox Khung nhóm các điểu khiển có quan hệ logic với nhau

Detail Control Khung chứa các thông tin chi tiết của một thực thể

Browse Control Khung chứa các thông tin ngắn gọn, trợ giúp tìm kiếm các thực

thểContainer Control Khung chứa Detail Control và Browse Control

Giới thiệu về định nghĩa thiết kế và kiến trúc của Microsoft.NET

1.1 Các mô hình tiến trình.

Để đạt được các kết quả tốt nhất cho các dự án, Microsoft tạo ra các hướng dẫn cho thiết kế, phát triển, triển khai, xử lí, và hỗ trợ Một mô hình hướng dẫn sắp xếp các hoạt động và vòng đời của một dự án Có hai mô hình phát triển phần mềm chính là thác nước và xoắn ốc

1.1.1 Mô hình thác nước và xoắn ốc.

Hình 1: Mô hình thác nước và xoắn ốc

Các mô hình cung cấp hai hướng tiếp cận khác nhau về vòng đời của một dự

án

• Mô hình thác nước: mô hình này sử dụng các điểm mốc như các điểm quá

độ và đánh giá Khi sử dụng mô hình thác nước, chúng ta cần hoàn thiện một tập các công việc trong một giai đoạn trước khi chuyển sang giai đoạn khác Mô hình thác nước làm việc phù hợp với các dự án có các yêu cầu được xác định rõ ràng và không bị thay đổi trong tương lai Bởi vì mô hình tạo ra các điểm quá độ cứng giữa các giao đoạn, nhưng chúng ta có thể dễ dàng kiểm soát lịch trình và xác định rõ ràng trách nhiệm và kế hoạch

• Mô hình xoắn ốc: mô hình dựa trên việc tinh chỉnh các yêu cầu và các đánh giá của một dự án Mô hình xoắn ốc phù hợp với các dự án khi người dùng cần phát triển nhanh một ứng dụng Hướng phát triển này dựa trên khả năng điều phối giữa đội phát triển và khách hàng, bởi vì khách hàng được tham gia vào tất cả các tình huống thông qua các thông tin phản hồi và các xác nhận Tuy nhiên mô hình xoắn ốc không có các điểm kiểm soát rõ ràng

1.1.2 Mô hình Microsoft Solution Framework.

Mô hình MSF mô tả tuần tự các hành động để phát triển và triển khai một giải pháp MSF chia thành các giai đoạn, các điểm kiểm soát, mô hình lặp để có thể áp dụng phát triển và triển khai các ứng dụng truyền thống, các hệ thống thương mại điện tử, và các ứng dụng Web

Hình 2: Mô hình MSF

1.1.2.1 Các giai đoạn trong mô hình MSF.

Mô hình MSF bao gồm 5 giai đoạn chính:

Hình 3: Các giai đoạn trong mô hình MSF

Tổ chức đội dự án.

MSF cung cấp mô hình đội dự án MSF Mô hình đội MSF làm nổi bật sự quan trọng và vai trò của các vị trí, trách nhiệm, và mục tiêu của từng thành viên để giúp dự án thành công Sự mềm dẻo của mô hình MSF giúp chúng ta thích ứng với phạm vi của dự án, nhân lực của đội, và kĩ năng của từng thành viên

Các vai trò trong mô hình MSF.

Trong một dự án, một số lượng lớn các hoạt động cần thực hiện, dự án cần được xem xét theo nhiều khía cạnh khác nhau Để giúp đạt được điều đó, mô hình MSF đặc tả 6 vai trò, mỗi vai trò có các định nghĩa rõ ràng về trách nhiệm và mục đích

• Product Management: có trách nhiệm quản trị các liên lạc và các mong muốn của khác hàng Trong suốt giao đoạn thiết kế, họ thu thập các yêu cầu

và đảm bảo các nghiệp vụ cần thiết được đáp ứng, như tóm lược thông tin cho khác hàng , marketing với người dùng v.v…

• Program Management: chịu trách nhiệm trong giai đoạn phát triển và đưa

ra các giải pháp về dự án cho khách hàng, dựa trên các điều kiện của dự án

• Development: chịu trách nhiệm phát triển giải pháp kĩ thuật tùy theo các

mô tả được cung cấp bởi Program Management

• Testing: xác định các tiêu chuẩn đánh giá chất lượng của dự án, họ đánh giá

và kiểm tra các chức năng và phù hợp với phạm vi của dự án

• Release Management: chịu trách nhiệm làm mịn các xử lí và triển khai, kiểm tra cơ sở hạ tầng đảm bảo nó có thể được hỗ trợ và triển khai

• User Experience: phân tích các hiệu năng và hỗ trợ người dùng, cân nhắc chương trình có đáp ứng được các yêu cầu

Đối với các, mỗi người trong dự án có thể nắm một hay nhiều vai trò Việc quản lí nhiều công việc sẽ tăng tích rủi ro của dự án Do đó, cần cân nhắc các vị trí cho các thành viên thích hợp trong dự án Để làm tối thiểu rủi ro, MSF đưa ra hướng dẫn về những vai trò có thể giao cho một người và những vai trò không thể.Bảng 1: Vai trò trong mô hình MSF

Vai trò Product management Program management Development Testing User experience Release managementProduct

Giai đoạn khỏa sát có rất nhiều mục đích, đội dự án sử dụng giai đoạn này để:

• Xác định các tài nguyên cần thiết để phát triển dự án

• Xác định và lên kế hoạch cho các điểm mốc quan trọng của dự án

1.2.1.1 Vai trò và trách nhiệm của các thành viên trong dự án.

Mặc dù đội dự án làm việc như một khối thống nhất để đưa ra được phạm vi và cái nhìn chung tại từng điểm mốc của quá trình khảo sát, nhưng mỗi vai trò sẽ có các trọng điểm riêng

Hình 4: Các vai trò trong mô hình MSFProduct Management: nhiệm vụ của quản trị dự án đảm bảo đội làm đúng các yêu cầu của khách hàng Quản trị dự án và quản trị phát triền cộng tác với nhau tạo ra một tầm nhìn chung về dự án Để thực hiện điều này, người quản trị dự án cần nghiên cứu và phân tích các vấn đề nghiệp vụ, các yêu cầu nghiệp vụ, tầm nhìn của dự án, các mục tiêu kinh doanh, và các đặc tính của người dùng.

Program Management: thành lập các mục tiêu thiết kế, định nghĩa các nhân tố

và thước đo thành công, làm rõ các khái niệm trong dự án, xây dựng cơ sở hạ tầng cho dự án,

Development: cung cấp các thông tin phản hồi dưới dạng các thông tin kĩ thuật của dự án và tính khả thi của các vần đề khi phát triển

User experience: nhóm phân tích thể hiện cần thiết, hỗ trợ khách hàng, và cân nhắc để sản phần đáp ứng các yêu cầu của khách hàng

Testing: cung cấp các thông tin dựa trên mục tiêu chất lượng của dự án và mô

tả các hành động cần thiết để đạt được chất lượng đó Đội kiểm tra áp dụng các giải pháp để đề ra các chiến lược testing và các tiêu chuẩn đánh giá

Release Management: xác định các yêu cầu để triển khai dự án, cách thức để

dự án được triển khai, khi nào thì được triển khai, và khi triển khai có cần bổ xung thêm cơ sở hạ tầng gi không

án thành công Để lựa chọn các thành viên thích hợp cho một dự án chúng ta cần xem xét các vần đề sau cho mỗi thành viên:

• Tri thức: mô tả thông tin mà mỗi thành viên cần có để thực hiện công việc,

ví dụ như các kiến thức cơ bản vê công nghệ thông tin

• Kĩ năng: mô tả các hoạt động hay các khả năng tương ứng và phù hợp với các kĩ năng của các thành viên, ví dụ như yêu cầu về kĩ năng toán học, hay khả năng thẩm mỹ

• Hiệu suất: mô tả khả năng và kêt quả mong đợi, ví dụ bạn chọ một người có khả năng hoàn thành công việc đúng thời gian và đáp ứng được yêu cầu về chất lượng

Ngoài các vần đề nêu trên, còn có một số cân nhắc để lựa chọn các thành viên cho dự án Bao gồm:

• Các thành viên có sẵn trong dự án

• Chi phí hoặc quỹ của dự án

1.2.1.3 Cách chuẩn bị các kết quả của giai đoạn khảo sát.

Mặc dù có các điểm mốc trung gian trong quá trình khảo sát, như thành lập đội hình cốt lõi của dự án, tạo các tài liệu thô về phạm vi và tầm nhìn, các tài liệu thô

về đánh giá rủi ro, nhưng cần có 3 tài liệu quan trọng cần đưa ra trong giai đoạn khảo sát, đó là:

• Phạm vi/tầm nhìn: mô tả các mục đích và rằng buộc trong dự án Nó phác thảo dự án sẽ phát triển, các yêu cầu cần thực hiện, các đặc tính, và một kế hoạch ban đầu

• Cấu trúc dự án: phác thảo cấu trúc tổ chức dự án và mô tả tiến trình quản lý

dự án Ai sẽ là người chịu trách nhiệm cho mỗi vai trò trong mô hình MSF

• Đánh giá rủi ro: cung cấp đánh giá cơ bản và phân tích các rủi ro liên quan đến dự án, cùng với các kế hoạch làm giảm nhẹ hoặc đối phó với các tình huống bất ngờ giúp đội dự án quản lí rủi ro

Tùy thuộc vào mức độ của dự án, một số tài liệu có thể được tạo ra trong giai đoạn khỏa sát:

• Danh sách các thuộc tính có thể test

• Các yêu cầu sơ bộ và các use case

• Kiến trúc sơ bộ

• Giao diện người dùng

Để các tài liệu được chia sẻ với người dùng, đội phát triển đồng thời tạo ra các tài liệu sử dụng nội bộ như:

• Danh mục các tác nhân

• Danh mục các nguyên tắc nghiệp vụ

• Từ điển nghiệp vụ

1.3.1 Tài liệu phạm vi của dự án.

Phạm vi của dự án là một trong những tài liệu cuối cùng được thông qua trong giai đoạn khảo sát, nó chứa đựng các mục đích và các rằng buộc, là sự nhất trí đầu tiên của mọi người tham gia dự án Nó trợ giúp cho đội dự án đạt được thỏa thuận mức cao về các mục tiêu chính Đồng thời nó cũng là nhân tố chính quyết định tính khả thi của dự án Khi dự án được thông qua, đội dự án sử dụng tài liệu này

để xây dựng kế hoạch cho toàn bộ giai đoạn còn lại

Để tạo ra được tài liệu phạm vi đội cần có nhiều lần phỏng vấn với các khách hàng, các nhà tài trợ, phân tích các use case từ mức cao đên chi tiết

1.4 Thiết kế khái niệm

Trong suốt quá trình lập kế hoạch, đội sẽ định nghĩa giải pháp gồm: xây dựng cái gì, các thức xây dựng nó, ai là người xây dựng Trong toàn bộ giai đoạn này đội chuẩn bị đặc tả các chức năng, thực hiện tiến trình thiết kế, chuẩn bị lập kế hoạch công việc, đánh giá chi phí và lập lịch cho các kết quả bàn giao

Trong suốt giai đoạn khảo sát, các thông tin được thu thập đầy đủ để xác định phạm vi của dự án Quá trình lập lịch có thể bắt đầu ngay trong quá trình khảo sát, ngay khi chúng ta thu thập đầy đủ thông tin để tổ chức và phân tích các thông tin

đó Trong giai đoạn này đội nhận các kết quả công việc đã làm được trong giai đoạn khảo sát và tiếp tục chi tiết hơn, tổ chức và phân tích các thông tin đó

Hình 5: Thiết kế khái niệm

1.4.1 Mục đích của quá trình thiết kế.

Trong suốt quá trình này, đội tiếp nhận các tài liệu trong khi khảo sát như: các yêu cầu người dùng, các tác vụ và các tác vụ tuần tự, đặc tính người dùng Kết quả của giai đoạn phân tích là kiến trúc và thiết kế của dự án, kế hoạch để đi tới phát triển và triển khai dự án, vấn đề về các nhiệm vụ và tài nguyên Mục đích nhằm đưa ra một bức tranh rõ ràng về dự án Tiến trình lập kế hoạch hướng dự án tiến về phía trước, nhưng rất nhiều dự án bị mắc kẹt trong quá trình này, họ dành quá nhiều thời gian cho lập lịch Điều quan trọng là biết được khi nào chúng ta đã có

đủ thông tin để tiếp tục dự án Quá ít thông tin sẽ tạo nên các rủi ro, quá nhiều thông tin sẽ làm dự án bị đình trệ.

1.4.1.1 Ba tiến trình thiết kế: Khái niệm, Logic, Vật lí.

Có ba tiến trình thiết kế trong giai đoạn phân tích: khái niệm, logic, vật lí Ba tiến trình này không tiến hành song song mà gối đầu lên nhau, tiến trình này phụ thuộc vào tiến trình khác Thiết kế logic phụ thuộc vào thiết kế khái niệm, thiết kế vật lí phụ thuộc vào thiết kế logic Tất cả các thay đổi ở thiết kế khái niệm đều ảnh hưởng đến thiết kế logic, dẫn tới ảnh hưởng đến thiết kế vật lí

Hình 6: Mô phỏng 3 tiến trình trong giai đoạn lập kế hoạchBảng 2: Các tiến trình thiết kế

Khái niệm Xem xét vấn đề dưới cách nhìn của

người dùng và của nghiệp vụ Định nghĩa các vấn đề và các giải pháp dưới dạng

các kịch bản sử dụng.Logic Xem xét giải pháp dưới góc nhìn

của đội dự án Định nghĩa giải pháp dựa trên một tập các dịch vụ

xử lí logicVật lí Xem xét giải pháp dưới góc nhìn

của người lập trình Định nghĩa các kĩ thuật và các dịch vụ của giải pháp

Quá trình thiết kế khái niệm có thể được chia nhỏ thành: nghiên cứu thiết kế khái niệm, phân tích thiết kế khái niệm, tối ưu thiết kế khái niệm

1.4.1.2 Vai trò và trách nhiệm.

Từng vai trò trong đội dự án sẽ chịu các trách nhiệm khác nhau, cụ thể:

Product Management: đảm bảo kế hoạch phù hợp với các yêu cầu của khác hàng Họ chịu trách nhiệm sàng lọc các yêu cầu, phân tích trạng thái nghiệp vụ hiện tại, tối ưu khái niệm, và tạo ra thiết kế khái niệm

Program Management: đảm bảo các tài nguyên cần thiết để hoàn thành kế hoạch của dự án Chịu trách nhiệm trong toàn bộ quá trình thiết kế, trong đó quan trọng nhất là thiết kế logic và đặc tả các chức năng Quản trị sản phẩm tạo ra kế hoạch và lịch của dự án, có trách nhiệm hoàn thành giai đoạn lập kế hoạch.

Development: đảm bảo tính khả thi của công nghệ sử dụng Đội phát triển có trách nhiệm tạo các thiết kế logic và thiết kế vật lí, có thể cả đặc tả các chức năng Đồng thời họ cũng chịu trách nhiệm xác định thời gian và tài nguyên cần thiết để phát triển dự án

Testing: đảm bảo kế hoạch đáp ứng được các yêu cầu, chịu trách nhiệm đánh giá thiết kế để xác định các đặc tính có thể kiểm tra đồng thời lên kế hoạch kiểm tra chúng

Release Management: đánh giá thiết kế có phù hợp với phát triển, quản lí và hỗ trợ Đồng thời có trách nhiệm lên kế hoạch và lập lịch triển khai

User Experience: đảm bảo người dùng có thể sử dụng sản phầm Công việc bao gồm: phân tích yêu cầu sử dụng, tạo chiến lược hỗ trợ, đánh giá mức độ hoàn thiện của thiết kế dựa trên tính khả dụng, đánh giá thời gian và nỗ lực để phát triển

hệ thống hỗ trợ người dùng, kiểm tra khả năng sử dụng của tất cả các giao diện người dùng

1.4.1.3 Các điểm mốc và các kết quả.

Các điểm mốc là các thời điểm mà đội dự án, khách hàng, các nhà tài trợ đạt được sự nhất trị dựa trên các kết quả bàn giao Các tài liệu bàn giao chính trong quá trình lập lịch là:

• Đặc tả chức năng: mô tả sản phẩm sẽ được phát triển, dựa trên thông tin đầu vào từ toàn đội dự án

• Kế hoạch chính của dự án: là một tập hợp các kế hoạch tương ứng với các nhiệm vụ được thực hiện bởi từng vai trò để đạt được các tính năng được

mô tả trong đặc tả chức năng Nó lưu giữ các chiến lược, thông qua đó các nhóm dự định sẽ tiến hành để hoàn thành công việc của mình

• Thời gian biểu chính của dự án: đồng bộ lịch làm việc của các nhóm trong

dự án Nó bao gồm các khoảng thời gian, trong thời gian đó mỗi đội phải hoàn thành công việc của mình Tập hợp các thời gian đơn lẻ sẽ đưa ra cái nhìn tổng thể về thời gian của dự án, qua đó có thể xác định ngày kết thúc

• Cập nhật tài liệu đánh giá rủi ro: đánh giá rủi ro được phát triển trong suốt quá trình khảo sát, và tiếp tục được xem xét và cập nhật thường xuyên, đặc biệt tại các điểm mốc Nó mô tả các rủi ro có thể xảy ra khi phát triển dự

án Thông thường các đánh giá rủi ro sẽ được sắp xếp để xác định các rủi ro cao nhất

Các tài liệu này được lưu trữ và tiếp tục được phát triển trong quá trình phát triển của dự án Mặc dù các tài liệu này có thể thay đổi, nhưng bất kì sự thay đổi nào trước hết phải được thông qua bởi sự đồng ý của khách hàng và các nhà tài trợ

1.5 Quá trình thiết kế logic

Trong quá trình thiết kế khái niệm, chúng ta đã mô tả dự án từ viễn cảnh của người dùng và của tác vụ, trong quá trình này ta sẽ dựa trên viễn cảnh của đội dự án

1.5.1 Thiết kế logic là gì?

Thiết kế logic được định nghĩa như một tiến trình mô tả giải pháp dưới dạng tổ chức, cấu trúc của nó, tương tác giữa các phần, bao gồm:

• Định nghĩa cấu tạo các phần của giải pháp

• Cung cấp một khung làm việc để tập trung toàn bộ các phần của giải pháp

• Giải thích cách giải pháp kết hợp với nhau, cách tương tác với người dùng

và các giải pháp khác

Khi tạo một thiết kế logic, đội đưa vào tất cả các yêu cầu nghiệp vụ, người dùng, hệ thống, các xử lí để xác định các yêu cầu cho vấn đề bảo mật, kiểm soát, đang nhập, tính ổn định, quản lí trạng thái, kiểm soát lỗi, cấu trúc chương trình và tương tác với các hệ thống khác

1.5.2 Vị trí của thiết kế logíc.

Khi đội dự án bắt đầu xác định các đối tượng quan trọng và các thuộc tính của một thực thể, chúng ta có thể bắt đầu giai đoạn thiết kế logic Do đó, giai đoạn này

có thể bắt đầu trước khi giai đoạn thiết kế khái niệm kết thúc Việc quyết định bắt đầu quá trình thiết kế được đưa ra tùy từng trường hợp, nó phụ thuộc vào dự án và toàn đội Hình sau mô tả vị trí của quá trình thiết kế trong mô hình MSF

Hình 7: Các giai đoạn trong mô hình MSFTrong quá trình thiết kế khái niệm, đội dự án định nghĩa các vấn đề nghiệp vụ dựa trên các thông tin thu thập được từ giao tiếp nghiệp vụ và người dùng Trong suốt quá trình thiết kế logic, họ định nghĩa các thành phần của giải pháp dựa trên cách nhìn của chính họ Các thành viên xác định các yêu cầu của giải pháp cần thực hiện Dựa trên các thông tin đó, họ định nghĩa các hành động và cấu trúc của giải pháp.

Thiết kế logic giúp đội một lần nữa tinh chỉnh lại các yêu cầu đã được tạo ra trong giai đoạn khảo sát và trong quá trình thiết kế khái niệm

Một thiết kế logic tốt phụ thuộc vào một thiết kế khái niệm tốt Nếu đội tạo được một thiết kế logic tốt, nó sẽ tạo điều kiện dễ dàng cho những người mới dựa trên thiết kế xác định các phần quan trọng của dự án, hiểu các phần được cách các phẩn kết hợp với nhau đề giải quyết các vần đề Thông thường, các công việc trong quá trình thiết kế logic sẽ được lặp lại trong quá trình thiết kế vật lí Đội sẽ tối ưu cấu trúc trong quá trình thiết kế logic, và được cải thiện các xử lí của nó trong quá trình thiết kế vật lí, điều đó tạo ra một vòng lặp giữa hai quá trình thiết

kế logic và thiết kế vật lí

1.5.3 Các nhiệm vụ khi thiết kế logic.

Ở mức chi tiết hơn, thiết kế logic có thể được chia nhỏ thành các nhiệm vụ sau:

• Phân tích thiết kế logic, đội sẽ thực hiện các nhiệm vụ sau:

o Sàng lọc các kĩ thuật và các công cụ sẽ sử dụng

o Xác định các đối tượng nghiệp vụ và các dịch vụ

o Xác định các thuộc tính và các quan hệ quan trọng

• Tối ưu thiết kế logic:

o Tinh chỉnh thiết kế logic

o Kiểm tra thiết kế logic

Hình 8: Các nhiệm vụ trong quá trình thiết kế logic

Trong suốt quá trình thiết kế logic, đội có thể tìm ra một vài yêu cầu mới hoặc các tính năng mới, chưa được tìm ra trước đó Với trường hợp này, đội dự án cần gặp gỡ lại khách hành để kiểm tra lại các yêu cầu hoặc các tính năng phát sinh có hợp lí hay không, và cách họ muốn xử lí đối với vần đề mới Tùy thuộc vào câu trả lời của khách hàng, phạm vi của dự án có thể thay đổi Nếu phạm vi của dự án thay đổi, cần sửa lại các tài liệu và các mô hình để tương ứng với các yêu cầu và tính năng mới

1.5.3.1 Các mục đích chính của quá trình thiết kế.

Mục đích chính của quá trình thiết kế là xác định hệ thống cần phải làm gì và giải thích điều đó bằng cách sử dụng một tập các thành phần Thiết kế logic cho phép chúng ta:

• Mô tả các yêu cầu nghiệp vụ cần được hỗ trợ bởi các kĩ thuật Mặc dù thiết

kế logic không phải là một giải pháp kĩ thuật, tuy vậy nó giúp đội dự án mô

tả các yêu cầu mà giải pháp cần hỗ trợ

• Xác định các cơ hội và các rằng buộc kĩ thuật Mặc dù thiết kế logic là độc lập với triển khai vật lí, tuy vậy nó có thể bắt đầu xác định các cơ hội và

rằng buộc, những vấn đề có thể ảnh hưởng đến sự lựa chọn và triển khai của một kĩ thuật.

• Xác định kĩ thuật thích hợp sẽ được sử dụng Đội cần tìm hiều về giải pháp trước khi lựa chọn công nghệ để thực hiện giải pháp

• Xác định phạm vi của thiết kế logic để quyết định cơ sở hạ tầng, hoạt động,

và triển khai Thiết kế logic không bị ảnh hưởng trực tiếp bởi các kĩ thuật yêu cầu, tuy vậy nó ảnh hưởng đến thiết kế vật lí, và thiết kế vật lí lại phụ thuộc vào kĩ thuật Do đó, nếu khách hành yêu cầu một giải pháp Web-base, đội cần phải chuân bị các rằng buộc triển khai trong suốt quá trình thiết kế logic

1.5.3.2 Các lợi ích của thiết kế logic.

Tạo thiết kế logic cho một giải pháp đem lai rất nhiều lợi ích, như tạo một mối liên kết giữa các thành viên có kiến thức về công nghệ và các thành viên khác Sau đây là một vài lợi ích khác của quá trình thiết kế

• Thiết kế logic giúp quản lí độ phức tạp của dự án thông qua cấu trúc của giải pháp, mô tả các phần của giải pháp, mô tả cách các phần tương tác với nhau để giải quyết vấn đề Rất nhiều dự án đã thất bại do chúng quá phức tạp và không được thiết kế tốt trước khi thực hiện Sự phức tạp dẫn đến lộn xộn, kết quả là một thiết kế nghèo nàn

• Thiết kế logic phản chiều và hỗ trợ các yêu cầu của thiết kế khái niệm Giúp đội tìm ra các lỗi và các mâu thuẫn trong quá trình thiết kế khái niệm, xác đinh các kịch bản có khả năng sử dụng lại Các phát hiện này có thể áp dụng ngược trở lại thiết kế khái niệm và đánh giá lại các yêu cầu để chắc chắn giải pháp có thể giải quyết vấn đề

• Thiết kế logic như một điểm để liên kết các chức năng đồng xử lí giữa các

hệ thống và cung cấp một khung nhình chặt chẻ về toàn bộ dự án.Chúng ta

có thể phân tích thiết kế logic để xác định các phần sử dụng lại và làm cho thiết kế hiệu quả hơn và có khả năng bảo trì tốt hơn

• Khi thiết kế logic kết thúc, cũng là lúc bắt đầu quá trình thiết kế vật lí

1.5.3.3 Vai trò và trách nhiệm trong thiết kế logic.

Trong quá trình thiết kế logic, mỗi nhóm sẽ chịu các trách nhiệm khác nhau.Ví

dụ, Program Management chịu trách nhiệm phát triển đặc tả chức năng, đảm bảo điều kiện giao tiếp và đàm phán trong đội, lên kế hoạch bảo trì và báo cáo tình trạng của dự án

Hình 9: Tóm lược trách nhiệm của từng vai trò trong quá trình thiết kế logic.

Testing Kiểm tra thiết kế logic có phù hợp

với thiết kế khái niệm Đinh nghĩa kế hoạch kiểm tra mức caoUser

Experience Định nghĩa các mục đích của người dùng Định nghĩa kế hoạch mức cao cho huấn luyện người dùngRelease

Management Đánh giá tính khả thi khi thực hiện giải pháp Định nghĩa cơ sở hạ tầng và triển khai giải pháp

1.6 Thiết kế vật lí.

Quá trình thiết kế vật lí là quá trình cuối cùng của giai đoạn lập lịch trong mô hình phát triển phần mềm của Microsoft Đội bắt đầu quá trình thiết kế vật lí sau khi tất cả các thành viên đồng ý thống nhất chúng ta đã có đầy đủ thông tin từ thiết

kế logic Trong suốt quá trình này, toàn đội sẽ áp dụng các rằng buộc và cân nhắc các kĩ thuật từ thiết kế khái niệm và logic Bởi vì thiết kế vật lí phát triển từ thiết

kế khái niệm và logic, kết quả phụ thuộc vào sự đúng đắn của hai quá trình thiết

kế trước đó Sự kế thừa thông tin của thiết kế vật lí từ thiết kế khái niệm và thiết

kế logic đảm bảo đội hoàn thành thiết kế vật lí phù hợp với yêu cầu của khách hàng và nghiệp vụ

1.6.1 Thiết kế vật lí là gì?

Thiết kế vật lí là tiến trình mô tả các thành phần, các dịch vụ và các kĩ thuật của giải pháp dưới góc nhìn của yêu cầu từ đội phát triển Thiết kế vật lí định nghĩa các phần của giải pháp sẽ được pháp triển, cách chúng được phát triển, và cách chúng tương tác với nhau

Trong các công việc của thiết kế vật lí, đội sẽ tạo các thiết kế dựa trên các thiết

kế trước đó và tinh chỉnh kiến trúc của hệ thông đã được tạo từ trước tới thời điểm hiện tại Các thiết kế này áp dụng các rằng buộc kĩ thuật (thực tế) cho các mô hình logic, bao gồm các công cụ phát triển và môi trường phát triển của giải pháp Hơn nữa, đội phát triển cần đáp ứng được các thiết kế như tính bảo mật, tính ổn định, tính hữu dụng v.v với mục tiêu làm phù hợp với dự án và các yêu cầu của nó.Thông tin đầu vào cho quá trình thiết kế vật lí là toàn bộ các tài liệu đã được tạo ra từ trước đến nay Nó bao gồm mô hình đối tượng mức logic, thiết kế giao diện người dùng mức cao và mô hình dữ liệu logic được tạo ra trong quá trình thiết kế logic Và các tài liệu như kế hoạch của dự án có thể được cập nhật và tạo các điểm mốc cho quá trình thiết kế logic

Ở thời điểm cuối của quá trình thiết kế, đội sẽ đưa ra các đặc tả là một tập các thành phần, các assembly, các thư viện liên kết; chi tiết về giao diện của người dùng; giản đồ cơ sở dữ liệu; các đối tượng cơ sở dữ liệu như trigger, index, store procedure; và chi tiết về các báo cáo trong giải pháp

1.6.1.1 Phạm vi của thiết kế vật lí.

Bảng 4: Phạm vi của thiết kế vật lí

Không thuộc thiết kế vật lí Hỗ trợ

triển

• Xác định nơi các thành phần được sử dụngTriển khai kĩ thuật Xác định kĩ thuật có thể sử dụng để triển khai

chương trình

Thiết kế vật lí chỉ thiết kế chương trình và không phát triển một version nào để phục vụ cho quá trình bàn giao hay triển khai.

1.6.1.2 Sự khác nhau giữa thiết kế logic và thiết kế vật lí.

Trong quá trình thiết kế logic đội nhìn vần đề dưới góc độ đội dự án, trong quá trình thiết kế vật lí đội nhìn nhận vấn đề dưới goc độ đội phát triển Trong quá trình thiết kế logic, đội ghi nhận các tài liệu về hoạt động, rằng buộc và các giả định về nghiệp vụ Trong quá trình thiết kế vật lí, đội định nghĩa một giải pháp tương ứng với các rằng buộc của các kĩ thuật phát triển và môi trường triển khai được lựa chọn

1.6.1.3 Các mục tiêu của quá trình thiết kế vật lí.

Đội dự án tạo các tài liệu thiết kế vật lí nhằm các mục đích sau:

• Xác định kĩ thuật phù hợp cho phát triển Trong quá trình thiết kế vật lí, đội đánh giá các kĩ thuật và xác định kĩ thuật tốt nhất để sử dụng phát triển cho

dự án

• Chuyển đổi từ thiết kế logic sang mô hình thiết kế vật lí Đội sử dụng các thông tin là đầu ra của quá trình thiết kế logic để tạo ra đặc tả mềm dẻo dựa trên các thành phần Đặc tả này trình bày ứng dụng từ góc nhìn của đội phát triển Chúng mô tả chương trình đủ chi tiết để cho phép đội phát triển bắt đầu tạo chương trình dựa theo các yêu cầu

• Cung cấp các ranh giới cho tiến trình phát triển Để tạo ra các mô hình và các chiến lược, đội định nghĩa các vai trò phát triển, các trách nhiệm và các tiến trình

1.6.1.3.1 Vai trò và trách nhiệm trong thiết kế vật lí.

Bảng 5: Vai trò và trách nhiệm trong quá trình thiết kế

Product

Management

Quản lí các yêu cầu người dùng và tạo các kế hoạch liên lạc

Chuẩn bị triển khai chương trình

Development Tạo các tài liệu thiết kế vật lí;

mô hình thiết kế; kế hoạch và lịch phát triển; ước lượng thời gian

Đánh giá kĩ thuật, tạo mẫu nếu cần, chuẩn bị môi trường phát triển

Testing Đánh giá và kiểm tra tính

năng và tương thích của thiết

kế vật lí và kịch bản sử dụng

Định nghĩa các kế hoạch kiểm tra chi tiết và chuẩn bị môi trường kiểm tra và đảm bảo chât lượng

1.6.1.3.2 Các tài liệu bàn giao của quá trình thiết kế vật lí.

Tại thời điểm cuối của giao đoạn thiết kế vật lí, đội dự án đã hoàn thiện các tài liệu cho đội phát triển bắt đầu tạo chương trình Các tài liệu này là đặc thù cho từng dự án, chúng bao gồm:

• Biểu đồ lớp

• Mô hình thành phần, biểu đồ tuần tự, hoặc biểu đồ hoạt động

• Giản đồ cơ sở dữ liệu

• Ranh giới mô hình triển khai

• Đặc tả component: cấu trúc bên trong và các giao diện component

• Chiến lược đóng gói và phân chia: xác định các dịch vụ để tập trung với nhau thành một component, và cách các component được phân chia trên mạng

1.6.1.3.3 Các bước trong quá trình thiết kế vật lí.

Hình 10: Quan hệ giữa thiết kế vật lí và thiết kế khái niệm, logic

Hình 11: Các bước trong quá trình thiết kế vật lí và liên kết giữa chúng.

• Nghiên cứu, bao gồm các nhiệm vụ sau:

o Xác định cac rằng buộc và yêu cầu vật lí

o Xác định các thay đổi hoặc liên quan đến cơ sở hạ tầng

• Phân tích:

o Phát triển một mô hình triển khai sơ bộ

o Lựa chọn công nghệ để phát triển chương trình

o Mô tả các thuộc tính, giao diện, và các dịch vụ của component

1.6.1.3.3.1 Xác định các yêu cầu và các rằng buộc vật lí.

Trong suốt quá trình thiết kế, chúng ta thu thập và phân tích thông tin về các yêu cầu và các rằng buộc nghiệp vụ Trong quá trình thiết kế vật lí, đội tập trung vào các yêu cầu và rằng buộc vật lí ảnh hưởng đến phát triển của dự án Các thông tin này được thu nhận từ kiến trúc của tổ chức và môi trường kinh doanh hiện tại.Một vài kiểu yêu cầu vật lí:

1.6.1.3.3.2 Giải quyết xung đột giữa yêu cầu và rằng buộc.

Các yêu cầu và các rằng buộc thường xung đột với nhau Bằng cách xác định trước các xung đột tiềm năng trong quá trình thiết kế có thể làm giảm bớt các ảnh hưởng Nếu vấn đề xảy ra, chúng ta đã có những biện pháp để giảm nhẹ

Để tránh các xung đột, ta nên tiến hành các công việc sau:

• Xác định các yêu cầu thực sự cần thiết cho dự án Xác đinh xung đột giữa các yêu cầu và đồng thời phân tích tương tác với bất kì rằng buộc nào

• Xác định các khu vực trong cơ sở hạ tầng nơi các yêu cầu có thể xung đột với các rằng buộc

• Phân tích các kẽ hở giữa yều cầu và rằng buộc, xác định liệu chúng ta cần tiến hành lựa chọn để giải quyết xung đột

1.7 Thiết kế tầng cơ sở dữ liệu.

Tầng dữ liệu của một ứng dụng bao gồm lưu trữ dữ liệu và dịch vụ dữ liệu Lưa trữ dữ liệu thường là một cơ sở dữ liệu, nơi dữ liệu được cấu trúc và lưu trữ Chúng ta sẽ tìm hiểu về mô hình dữ liệu và cách dữ liệu được cấu trúc trong các

mô hình dữ liệu khác nhau Chúng ta sẽ tìm hiểu cách nhận các bảng và các cột từ nơi lưu trữ và các quan hệ giữa các thực thể khác nhau

1.7.1 Giản đồ cơ sở dữ liệu.

Suốt quá trình lập kế hoạch, đội tập trung vào phân tích các yêu cầu và thiết kế giải pháp phù hợp với các yêu cầu đó Để xác định thêm các đặc tính của chương trình, đội phân tích các dữ liệu cần thiết và mô tả cách dữ liệu được cấu trúc, lưu trữ, truy cập, và kiểm tra trong chương trình

Nghiên cứu và phân tích các yêu cầu dữ liệu được bắt đầu ngay từ quá trình khảo sát Các yêu cầu này giúp xác định, những thông tin cần được lưu trữ và xử lí trong nghiệp vụ của chương trình Trong quá trình thiết kế logic, đội nhận một tập các thực thể dữ liệu từ các nguồn: mô hình đối tượng logic, kịch bản sử dụng, và các tài liệu (giản đồ dữ liệu, trigger, constraint, các mẫu) từ bất kì nguồn dữ liệu

có sẵn nào Trong quá trình thiết kế vật lí, đội định nghĩa các bảng, các quan hệ, các kiểu dữ liệu cho từng trường, index, các thủ tục để tạo một giản đồ cơ sở dữ liệu, và các dịch vụ cơ sở dữ liệu Ngoài ra, đội có thể lập kế hoạch để cung cấp các dịch vụ import/export, sao lưu và phục hồi cơ sở dữ liệu

1.7.1.1 Định nghĩa giản đồ cơ sở dữ liệu.

Một cơ sở dữ liệu được đĩnh nghĩa là một tập hợp các giá trị dữ liệu, được tổ chức theo một cách đặc biệt Một giản đồ cơ sở dữ liệu mô tả cách dữ liệu được tổ chức trong cơ sở dữ liệu Trong suốt quá trình thiết kế vật lí, các thành viên một giản đồ cơ sở dữ liệu để họ có thể tập trung vào những vấn đề cần thực hiện trước khi xem xét cách thực hiện nó

Trong quá trình thiết kế logic, đội mô tả các thực thể và các thuộc tính sẽ được lưu trữ trong cơ sở dữ liệu và cách người dùng sẽ truy cập đến, xử lí và duyệt dữ liệu Trong quá trình thiết kế vật lí, đội tạo giản đồ cơ sở dữ liệu cung cấp các đặc

tả cho tạo, đọc, cập nhật, và xóa các dữ liệu được sử dụng trong chương trình.Khi đội bắt đầu thiết kế giản đồ cơ sở dữ liệu, giản đồ có một tập quan hệ dựa trên mô hình đối tượng logic Giản đồ định nghĩa các thực thể chính được quan tâm, các thuộc tính của chúng, và các quan hệ giữa các thực thể Hầu hết các kĩ thuật mô hình hóa dữ liệu định nghĩa một thực thể là trừu tượng hóa của một cái gì

đó trong thế giới thực

Hình 12: Một phần giản đồ cơ sở dữ liệu của hệ thống bán hàng.

1.7.1.2 Các kiểu mô hình dữ liệu vật lí.

Để thiết kế cơ sở dữ liệu logic, chúng ta phải lựa chọn một công nghệ lưu trữ

dữ liệu dưới dạng vật lí Mô hình dữ liệu vật lí của một hệ quản trị cơ sở dữ liệu định nghĩa cấu trúc bên trong, hệ quản trị cơ sở dữ liệu sử dụng để lưu trữ dữ liệu Cấu trúc ảnh hưởng đến các kiểu bảng cơ sở dữ liệu chúng ta sẽ tạo, cũng như tốc

độ truy cập và tính linh hoạt của cơ sở dữ liệu Một số kiểu mô hình dữ liệu vật lí thường được sử dụng là:

• File dữ liệu: một file dữ liệu lưu trữ toàn bộ dữ liệu trong một file, dưới dạng một tập các hàng và cột Không có một quan hệ nào giữa các file dữ liệu, bởi vì các file tồn tại và không biết đến sự tồn tại cũng như cấu trúc của các file khác Chúng cung cấp cơ chế cập nhật và lấy thông tin nhanh bởi chúng hỗ trợ một một phương thức index (phương thức truy cập index tuần tự)

• Cấu trúc: cơ sở dữ liệu cấu trúc lưu trữ một phạm vi thông tin lớn với nhiều định dạng khác nhau Do đó chúng rất mềm dẻo và có khả năng mở rộng Chúng ta sử dụng kiểu cơ sở dữ liệu này khi thông tin cần lưu trữ là rất lớn Một ví dụ của dữ liệu cấu trúc là Microsoft Exchange, nơi lưu trữ rất nhiều loại thông tin để dễ dàng thông báo và công tác giữa các ứng dụng, khi nó được yêu cầu nhiều loại thông tin cần được đóng gói trong các thông báo

• Quan hệ: trong cơ sở dữ liệu mô hình quan hệ, dữ liệu được lưu trữ trong nhiều bảng và nhiều cột Cơ sở dữ liệu quan hệ tập hợp được các ưu điểm của cả file dữ liệu và cơ sở dữ liệu cấu trúc thông qua cung cấp tính năng

và sự mềm dẻo Mô hình quan hệ đang phát triển rộng rãi, bởi vì các bảng

có thể liên kêt với nhau thông qua các trường unique Các thành phần quan

hệ có thể được lấy dễ dàng thông qua các câu truy vấn

• Hướng đối tượng: trong một cơ sở dữ liệu hướng đối tượng, các đối tượng

cơ sở dữ liệu như các đối tượng trong ngôn ngữ lập trình Hệ quản trị cơ sở

dữ liệu hướng đối tượng mở rộng ngôn ngữ với dữ liệu liên tục, kiểm soát đồng thời, khôi phục dữ liệu, liên kết các truy vấn và các khả năng khác của

cơ sở dữ liệu Chúng ta sử dụng cơ sở dữ liệu hướng đối tượng nếu chúng

ta cần lưu trữ dữ liệu phức tạp và yêu cầu hiệu suất cao Dữ liệu phức tạp được mô tả thiếu xác định duy nhất, quan hệ nhiều nhiều, và thường sử dụng kiểu lập trình giống mô hình quan hệ

1.7.2 Cách xác định thực thể và thuộc tính.

Trong quá trình thiết kế logic, đội dự án phân tích các use case và các kịch bản

sử dụng để xác định các thực thể và các thuộc tính Các thực thể và thuộc tính này tạo nên thành phần cơ bản cho thiết kế logic, và được sử dụng trong trong tiến trình thiết kế vật lí để mô hình thiết kế vật lí của dự án Thiết kế logic đảm bảo chắc chắn thiết kế dữ liệu cho chương trình mô tả và tương ứng với các yêu cầu khái niệm

1.7.2.1 Hướng dẫn để thu thập các thực thể.

Khi xác định các thực thể cho thiết kế dữ liệu logic, cần lưu ý các điểm sau:

• Các đối tượng, thông tin sẽ được lưu trữ

• Điểm bắt đầu là thiết kế dữ liệu logic Xác định các thực thể là bước đầu tiên trong thiết kế cơ sở dữ liệu

• Một thể hiện của một thực thể là một hàng trong một bảng.

1.7.2.1.1 Các đặc điểm của thuộc tính.

Sau khi xác định các thực thể, chúng ta phải xác định các thuộc tính chúng ta muốn quản lí trong cơ sở dữ liệu Thuộc tính có các đặc điểm sau:

• Các thuộc tính mô tả một thực thể Ví dụ, các thuộc tính của một chiếc ô tô

có thể bao gồm: mầu, model, và năm sản xuất Mặc dù kích thước là một đặc điểm của ô tô, nhưng nó không được đưa vào vì không có quan hệ đến chương trình

• Các thuộc tính chỉ tồn tại khi gắn với một thực thể Ví dụ, thuộc tính màu sắc không miêu tả gì cho một tam giác trừ khi màu sắc được quan tâm đến

• Các thuộc tính định nghĩa các cột trong các bảng cơ sở dữ liệu Khi thiết kế vật lí được thực hiện, các thuộc tính trở thành các cột Chúng được mô tả đầy đủ gồm: kiểu, kích thước, và các quan hệ có thể khác

1.7.2.1.2 Cách xác định bảng và cột.

Dữ liệu trong từng bản ghi được lưu trong các cột, hoặc trong các trường, chúng được xác định từ các thuộc tính của các thực thể định nghĩa bảng Mỗi trường chứa một thành phần dữ liệu

1.7.2.1.2.1 Kiểu dữ liệu

Kiểu dữ liệu mô tả loại dữ liệu được lưu trữ trong một trường Tất cả các trường trong một cơ sở dữ liệu phải có một kiểu dữ liệu Kiểu dữ liệu cho phép chúng ta, và bản thân các cơ chế của cơ sở dữ liệu xác định giá trị nhập vào cho một trường có hợp lí với thông tin mà trường đó mô tả Cần chú ý, kiểm tra kiểu

dữ liệu không phải là kiểm tra dữ liệu

Khi định nghĩa các bảng, lựa chọn kiểu dữ liệu đảm bảo tối ưu, không chiếm dung lượng đĩa, cho phép phát triển Hầu hết các hệ quản trị cơ sở dữ liệu hỗ trợ hai loại dữ liệu chính sau:

• Kiểu dữ liệu của hệ thống: tất cả các hệ quản trị cơ sở dữ liệu có các kiểu

dữ liệu riêng của nó

• Kiểu dữ liệu do người dùng định nghĩa: một vài hệ quản trị cơ sở dữ liệu cho phép chúng ta tự định nghĩa kiểu dữ liệu riêng, dựa trên các kiểu dữ liệu có sẵn của hệ thống

1.7.2.1.2.2 Các khóa.

Các khóa là một thành phần quan trọng trong một cơ sở dữ liệu quan hệ Khóa xác định duy nhất một thể hiện của một thực thể trong mô hình dữ liệu Khóa đồng thời cũng cung cấp các cơ chế để kết hợp các thực thể với nhau

Một cơ sở dữ liệu quan hệ có thể có một vài kiểu khóa sau:

• Khóa chính: xác định một hàng duy nhất trong cơ sở dữ liệu

• Khóa ngoại: liên kết hai bảng

Trong quá trình thiết kế vật lí, chúng ta mô tả các quan hệ giữa các thực thể bằng cách thêm các khóa từ một bảng đến một bảng khác Các loại quan hệ chính là:

1.8 Thiết kế bảo mật.

Thiết kế đặc điểm và cơ chế bảo mật là một trong các khía cạnh quan trọng của phát triển ứng dụng Chi phí được dành cho bảo mật ngày càng tăng, để tránh mất mát sinh ra dưới dạng ăn cắp tri thức, hệ thống treo, mất sản phẩm, hủy hại danh tiếng, mất các khách hàng tin cậy Có thể bảo vệ chương trình trong môi trường cạnh tranh đó bằng cách áp dụng các cơ chế xác thực và cấp phép, đảm bảo toàn vẹn dữ liệu, và thực hiện kiểm soát dữ liệu

Chúng ta có thể bảo vệ ứng dụng bằng cách áp dụng các cơ chế bảo mật như tường lửa, proxy, kênh bảo mật, cơ chế xác thực Tuy nhiên, tất cả chúng đều có các kẽ hở để kẻ tấn công có thể tìm ra điểm yếu trong hệ thống

• Kết nối Internet: cài đặt mặc định của IIS phiên bản 5.0 thường cung cấp các dịch vụ và các cổng nhiều hơn sự cần thiết để thực hiện một ứng dụng Các dịch vụ và cổng thêm này tạo ra các cơ hội cho kẻ tấn công Ví dụ, kết nối modem thông qua tường lửa bảo vệ mạng bởi những người bên ngoài Nếu người ngoài có thể xác định số điện thoại và mật khẩu của modem, thì

họ có thể kết nối tới bất kì máy nào trong mạng

• Truyền dữ liệu không mã hóa: nếu dữ liệu được truyền giữa server và client dưới dạng thuần text, có khả năng dữ liệu có thể bị tấn công, đọc, sửa đổi trong quá trình truyền

• Tràn vùng đệm: kẻ tấn công điều tra chương trình theo cách kích tràn vùng đệm, vì họ có thể làm tràn vùng đệm của một ứng dụng hoặc của hệ điều hành Sau đó họ có thể lấy được nhiều thông tin từ các thông báo lỗi

• Tiêm SQL: tiêm SQL xảy ra khi người lập trình tạo ra các câu truy vấn động từ các thông tin người dùng nhâp Kẻ tấn công có thể thay đổi câu SQL và thực hiện các xử lí không mong muốn

• Bảo mật trong code: kẻ tấn công có thể tìm thấy mật khẩu và chìa khóa mã hóa được nhúng trong code

1.8.2 Hạn chế của mô hình bảo mật truyền thống.

Các mô hình truyền thống không đáp ứng được các thách thức trong môi trường mạng máy tính Hầu hết các mô hình truyền thống giới hạn truy cập đến các tài nguyên dựa trên xác định xem ai đang thực hiện chức năng đó Bảo mật dựa trên xác định người dùng bị phá vỡ nếu người dùng vô tình chạy một đoạn code, đoạn code này có thể là: mở một email, chạy một đoạn script được nhúng trong trang Web, mở một file lấy từ Internet

1.8.2.1 Các chiến lược bảo mật.

Để thiết kế một ứng dụng bảo mật, chúng ta nên theo các nguyên tắc bảo mật

và áp dụng chúng khi tạo các chiến lược bảo mật

• Dựa vào các hệ thống bảo mật để kiểm tra Bất kì khi nào có thể, chúng ta nên sử dụng các hệ thống trên hơn là tạo ra một giải pháp riêng

• Không tin tưởng vào các thông tin bên ngoài, chúng ta nên kiểm tra tất cả các thông tin nhập bởi người sử dụng và các dịch vụ bên ngoài

• Giả định hệ thống bên ngoài là không an toàn

• Áp dụng đúng quyền

• Giảm dữ liệu và các thành phần

1.9 Kết thúc quá trình lập kế hoạch.

Trong suốt giai đoạn lập kế hoạch, rất nhiều nhân tố ảnh hưởng và định hướng thiết kế của ứng dụng, Một vài nhân tố có thể là các tài nguyên không ước lượng được, như thời gian, chi phí, nỗ lực Các nhân tố khác như, công nghệ, tri thức và

kĩ năng là linh động và thay đổi trong suốt vòng đời phát triển Các nhân tố này ảnh hưởng đến thiết kế ứng dụng trong một vài phạm vi nào đó, chúng ta cần phải chỉ ra các khả năng mà ứng dụng cần có

1.9.1 Thiết kế tỉ xích.

Tỉ xích được định nghĩa là khả năng tăng các tài nguyên để tạo nên các dịch vụ mới Trong một ứng dụng tỉ xích, chúng ta có thể thêm các tài nguyên để quản lí thêm các lĩnh vực khác mà không phải thay đổi ứng dụng

Một ứng dụng tỉ xích đòi hỏi sự cân bằng giữa phần cứng và phần mềm được

sử dụng để thực hiện chương trình Chúng ta có thêm tài nguyên cho cả phần cứng lẫn phần mềm để tăng cưởng khả năng của ứng dụng Thêm các tài nguyên có thể tạo thêm lợi ích; tuy nhiên, nó cũng có thể là các nỗ lực vô ích hoặc phản tác dụng, ứng dụng không có gì thay đổi

Có hai hướng phát triển tỉ xích thường được sử dụng

Tỉ xích trên: đạt được các tỉ xích thông qua cung cấp thêm phần cứng cho máy chủ hiện tại, bao gồm thêm bộ nhớ, thêm hoặc thay bộ xử lí tốc độ cao, hoặc chuyển ứng dụng sang một máy tính tốt hơn Mục đích chính của tỉ xích trên là tăng cường tài nguyên phần cứng cho một ứng dụng Nói chung, chúng ta có thể thực hiện công việc này mà không phải thay đổi code cũ Ngoài ra, các nỗ lực của người quản trị không mấy thay đổi Tuy nhiên, lợi ích của tí xích trên sẽ giảm dần đến khi đạt tới khả năng xử lí tối đa của chương trình

Hình 13: Tỉ xích trên của một ứng dung.

Tỉ xích ngoài: phân chia xử lí trên nhiều máy chủ Mặc dù tỉ xích ngoài đạt được bằng cách sử dụng nhiều máy tích, nhứng một tập các máy tính liên tiếp hoạt động như như một thiết bị duy nhất nhìn từ người sử dụng Một lần nữa, sự cân bằng giữa phần cứng và phần mềm là hết sức quan trọng Ứng dụng cần phải thực hiện được mà không cần các thông tin về máy chủ nó đang chạy Tỉ xích ngoài cũng đồng thời tăng khả năng thất bại của một ứng dụng

ảnh hưởng nhiều nhất đến tỉ xích Để thiết kế tốt chúng ta sẽ xem xét các vấn đề sau:

• Các tiến trình sẽ không phải chờ đợi các tiến trình khác Một tiến trình sẽ không phải chở đợi lâu hơn khoảng thời gian cho phép Một tiến trình có thể là đồng bộ hoặc không đồng bộ Một tiến trình đồng bộ phải chờ một tiến trình khác thực hiện thành công hay thất bại để tiếp tục xử lí công việc của mình Ứng dụng thực hiện các tiến trình đồng bộ có thể đương đầu với các nút thắt khi sử dụng các tài nguyên Các nút thắt này ảnh hưởng đến hiệu suất và cả tỉ xích của ứng dụng Một cách để đạt được điều này là sử dụng các tiến trình không đồng bộ Với một ứng dụng có các tiến trình không đồng bộ, các tiến trình xử lí có thời gian lớn có thể được xếp xử lỉ sau

• Các tiến trình không cạnh tranh tài nguyên: một trong những nguyên nhân lớn nhất của vấn để tỉ xích là cạnh tranh tài nguyên như bộ nhớ, bộ xử lí, băng thông, kết nối cơ sở dữ liệu Lập kế hoạch sử dụng tài nguyên để giảm tối thiểu các vấn đề này:

o Sử dụng các tài nguyên có số lượng lớn trước