Chapter 7 moving on to design

Hoạt động chính diễn ra trong quá trình thiết kế là phát triển tập hợp các biểu diễn phân tích analysis representations thành biểu diễn thiết kế design representations Thiết kế cũng bao

NHÓM 5

TO DESIGN

1 GIỚI THIỆU

- Mục đích của phân tích là tìm ra nhu cầu của doanh nghiệp là gì Mục đích của thiết kế là

để quyết định cách thức xây dựng hệ thống Hoạt động trong quá trình thiết kế là tập hợp các biểu diễn phân tích thành biểu diễn thiết kế.

- Trong quá trình thiết kế, nhóm dự án xem xét cẩn thận cách thức hoạt động của hệ thống với môi trường hiện tại ví dụ như tích hợp với các hệ thống hiện

có, chuyển đổi dữ liệu, Mục tiêu của thiết kế là tạo ra một kế hoạch chi tiết cho một hệ thống có thể thực hiện

- Một phần quan trọng ban đầu của thiết kế là kiểm tra các chiến lược

và quyết định xem chiến lược nào sẽ được sử dụng để xây dựng hệ

thống.

- Đồng thời, phải hoàn thành việc thiết kế chi tiết các lớp và các phương thức để tìm ra khung sườn của hệ thống và cách chúng được lưu trữ.

- Thiết kế cũng bao gồm các hoạt động như thiết kế UI/UX, đầu vào/ra

hệ thống

- Cuối cùng quyết định về kiến trúc vật lý liên quan đến phần mềm và phần

cứng được đưa ra để hỗ trợ hệ thống mới và cách thức tổ chức xử lý hệ thống

2 VERIFYING AND VALIDATING THE ANALYSIS MODELS

1 Giới thiệu

Mục đích thiết kế ?

Mục đích của thiết kế là quyết định cách thức xây dựng hệ thống Hoạt động chính diễn ra

trong quá trình thiết kế là phát triển tập hợp các biểu diễn phân tích (analysis

representations) thành biểu diễn thiết kế (design representations)

Thiết kế cũng bao gồm các hoạt động như thiết kế giao diện người dùng, đầu vào hệ thống và đầu ra hệ thống, liên quan đến cách người dùng tương tác với hệ thống

Cuối cùng, các quyết định về kiến trúc vật lý được đưa ra, phần cứng và phần mềm sẽ

được mua để hỗ trợ hệ thống mới và cách thức tổ chức xử lý hệ thống

- Cần đảm bảo rằng các mô hình khác nhau là nhất quán Quá trình đảm bảo tính nhất quán giữa chúng được gọi là cân bằng các mô hình.

( Mối quan hệ giữa các mô hình)

2 Xác minh và xác thực các mô hình phân tích

2.1 Cân bằng mô hình chức năng và cấu trúc.

Để cân bằng giữa mô hình chức năng và cấu trúc, chúng ta phải đảm bảo rằng hai tập hợp mô hình

nhất quán với nhau Nghĩa là, các sơ đồ hoạt động (activity diagrams), mô tả use-case và use-case

diagrams phải thống nhất với thẻ CRC và sơ đồ lớp thể hiện mô hình phát triển của miền vấn đề

Các điều kiện:

- Đầu tiên, mọi lớp trên sơ đồ lớp và mọi CRC card phải được liên kết với ít nhất một ca sử dụng và ngược lại

- Thứ hai, mọi hoạt động hoặc hành động có trong sơ đồ hoạt động và mọi sự kiện có trong mô tả ca

sử dụng phải liên quan đến một hoặc nhiều trách nhiệm trên CRC card và một hoặc nhiều hoạt động trong một lớp trên một lớp sơ đồ và ngược lại

- Thứ ba, mỗi nút đối tượng trên sơ đồ hoạt động phải được liên kết với một thực thể của lớp trên sơ đồ lớp (tức là một đối tượng) và thẻ CRC hoặc một thuộc tính có trong một lớp và trên thẻ CRC

- Thứ tư, mọi thuộc tính và mối quan hệ liên kết/tổng hợp có trên thẻ CRC (và được kết nối với một lớp trên sơ đồ lớp) phải liên quan đến chủ đề hoặc đối tượng của một sự kiện trong mô tả use case

2.2 Cân bằng các mô hình hành vi và chức năng

Sơ đồ hoạt động, mô tả ca sử dụng và biểu đồ ca sử dụng phải thống nhất với biểu đồ trình

tự, sơ đồ giao tiếp, máy trạng thái hành vi và ma trận CRUDE

Có bốn lĩnh vực mà chúng ta phải quan tâm:

- Đầu tiên, sơ đồ trình tự và giao tiếp phải được liên kết với một ca sử dụng trên sơ đồ ca sử dụng và

- Thứ tư, tất cả các đối tượng phức tạp được đại diện bởi một nút đối tượng trong sơ đồ hoạt động phải

có một máy trạng thái hành vi đại diện cho vòng đời của đối tượng

2.3 Cân bằng mô hình cấu trúc và hành vi

- Thứ tư, thông điệp chứa trên sơ đồ trình tự và giao tiếp, chuyển tiếp trên máy trạng thái hành

vi và các mục nhập ô trên ma trận CRUDE phải được liên kết với trách nhiệm và liên kết trên thẻ CRC và hoạt động trong các lớp và kết nối với các lớp trên sơ đồ lớp

- Thứ năm, các trạng thái trong máy trạng thái hành vi phải được liên kết với các giá trị khác nhau của một thuộc tính hoặc tập hợp các thuộc tính mô tả một đối tượng

2.4 Tóm lược

- Việc cân bằng tất cả các mô hình chức năng, cấu trúc và hành vi là một nhiệm vụ rất tốn thời gian và khó khăn Tuy nhiên, nếu không chú ý đến các mô hình đang phát triển đại diện cho hệ thống, các mô hình sẽ không cung cấp một nền tảng vững chắc để thiết kế và xây dựng hệ thống

3 EVOLVING THE ANALYSIS MODELS INTO DESIGN MODELS

- Mục đích của các mô hình phân tích là đại diện cho miền vấn đề cơ bản dưới dạng một

tập hợp các đối tượng hợp tác

- Mục đích chính của các mô hình thiết kế là tăng khả năng cung cấp thành công một hệ

thống thực hiện các yêu cầu chức năng theo cách có thể thực hiện được và dễ bảo trì

- Dựa vào pha thiết kế, ,chỉnh lại các lớp, các thuộc tính , them miền xác định, xác định

liên kết giữa các lớp…

3.1 Factoring

- Factoring là quá trình tách một mô-đun thành một mô-đun độc lập Mô-đun mới có thể là một lớp mới hoặc một phương thức mới

- Trừu tượng hóa và sàng lọc là hai quá trình liên quan chặt chẽ đến bao thanh toán

- Tính trừu tượng liên quan đến việc tạo ra một ý tưởng cấp cao hơn từ một tập hợp các ý tưởng

- Quá trình sàng lọc ngược lại với quá trình trừu tượng hóa

3.2 Phân vùng và cộng tác

Phân vùng là phần tương đương hướng đối tượng của một hệ thống con, trong

đó hệ thống con là sự phân rã của một hệ thống lớn hơn thành các hệ thống thành phần của nó

(Ví dụ: một hệ thống con hệ thống thông tin có thể được phân tách về mặt chức năng thành một hệ thống tài khoản phải trả, một hệ thống tài khoản-phải thu, hệ thống tính lương, v.v.)

- Lớp tương tác giữa con người với máy tính: Lớp tương tác giữa con người và máy tính chứa các lớp được liên kết với ý tưởng View và Controller từ

Smalltalk

- Lớp kiến trúc vật lý: Lớp kiến trúc vật lý giải quyết cách phần mềm sẽ thực thi trên các máy tính và mạng cụ thể

- Lớp quản lý dữ liệu: Lớp quản lý dữ liệu giải quyết các vấn đề liên quan đến

sự tồn tại của các đối tượng trong hệ thống

4 PACKAGES AND PACKAGE DIAGRAMS

4 PACKAGES AND PACKAGE DIAGRAMS

4.2 Biểu đồ gói (Package Diagram)

⮚ Thành phần

▪ Gói: một nhóm của các phần tử trong UML

▪ Mối quan hệ giữa các gói: Các quan hệ phụ thuộc (dependency) Nếu một gói có sự thay đổi, gói phụ thuộc nó cũng có thể bị thay đổi Các quan hệ phụ thuộc được biểu diễn bởi mũi tên nét đứt được vẽ từ một lớp đến lớp mà nó phụ thuộc

4 PACKAGES AND PACKAGE DIAGRAMS

4.3 Hướng dẫn tạo một biểu đồ gói

⮚ Sử dụng các gói để nhóm các lớp lại với nhau khi có các mối quan hệ như inheritance, aggregation hoặc composition, hoặc khi các lớp hình thành sự cộng tác giữa chúng.

⮚ Khi có quan hệ inheritance giữa các gói, nên sắp xếp theo chiều dọc với gói chứa lớp cha được đặt ở phía trên gói chứa lớp con Với mối quan hệ aggregation hoặc association thì nên được để ngang cạnh nhau.

⮚ Với mối quan hệ dependency, biểu tượng mũi tên có nét đứt biểu diễn sự phụ thuộc, được hướng từ lớp phụ thuộc đến lớp mà nó phụ thuộc.

4 PACKAGES AND PACKAGE DIAGRAMS

4.3 Hướng dẫn tạo một biểu đồ gói

⮚ Khi dùng các gói để nhóm các use-case lại với nhau, đảm bảo rằng nó có chứa các tác nhân và liên kết giữa các tác nhân với các use-case của chúng.

⮚ Đặt tên đơn giản đủ để người dùng hiểu thông tin của gói.

⮚ Đảm bảo các thành phần trong gói gắn kết với nhau, các thành phần phụ thuộc vào nhau thường được nhóm vào chung một gói.

4 PACKAGES AND PACKAGE DIAGRAMS

4.4 Tạo một biểu đồ gói

⮚ Thiết lập ngữ cảnh cho biểu đồ gói với quy tắc các gói có thể được sử dụng để

mô hình hóa việc phân vùng hoặc lớp.

⮚ Tập hợp các lớp lại với nhau tạo thành các phân vùng dựa trên các mối quan

hệ giữa các lớp Các mối quan hệ bao gồm generalization, aggregation, associations và các thông điệp giữa các đối tượng trong hệ thống.

⮚ Phân cụm các lớp lại với nhau trong một phân vùng và mô hình hóa các phân vùng như các gói.

⮚ Xác định các mối quan hệ phụ thuộc giữa các gói.

⮚ Bố trí và vẽ sơ đồ Sử dụng các hướng dẫn ở mục 4.3, đặt các gói và các mối quan hệ phụ thuộc vào trong sơ đồ.

4 PACKAGES AND PACKAGE DIAGRAMS

4.5 Xác minh và xác thực biểu đồ gói

⮚ Các gói được nhận dạng phải có ý nghĩa từ quan điểm problem domain

⮚ Tất cả các mối quan hệ phụ thuộc phải dựa trên các mối quan hệ gửi thông điệp trên biểu đồ giao tiếp, các mục ô trong ma trận CRUDE và các liên kết trên biểu đồ lớp

5 DESIGN STRATEGIES

Có ba cách để tiếp cận việc tạo ra một hệ thống mới:

- Phát triển ứng dụng tùy chỉnh nội bộ

- Mua và tùy chỉnh một hệ thống đã được xây dựng

- Dựa vào nhà cung cấp, nhà phát triển hoặc nhà cung cấp dịch vụ bên ngoài để phát triển sản phẩm.

5 DESIGN STRATEGIES

5.1 Phát triển ứng dụng tùy chỉnh nội bộ

5.1.1 Ưu điểm

- Team sẽ có toàn quyền quản lý xem hệ thống sẽ như thế nào và các chức năng trong hệ thống

- Cho phép nhà phát triển linh hoạt và sáng tạo trong quá trình giải quyết vấn đề

- Dễ dàng để ứng dụng các công nghệ hiện đại, giúp cho giải pháp hiệu quả hơn

- Nâng cao kỹ năng của các thành viên trong công ty

5.1.2 Nhược điểm

- Tự phát triển ứng dụng tốn rất nhiều thời gian và khó khăn trong công việc

- Nguồn nhân lực cho các dự án rất khó kiếm khi mọi người trong công ty đều đang có các công việc cần phải làm

- Khó tìm được nguồn nhân lực có trình độ cao để thuê

5 DESIGN STRATEGIES

5.2 Tùy chỉnh hệ thống xây dựng sẵn

5.2.1 Ưu điểm

- Đã được viết và phát triển bởi nhà phát triển khác

- Chi phí sẽ rẻ hơn và tốn ít thời gian hơn tự phát triển phần mềm

- Chương trình đã được tạo sẵn, thử nghiệm và kiểm thử

- Có thể tái sử dụng hoặc tùy chỉnh từ một phần mềm đóng gói.

- Cần phải phát triển thêm một vài tính năng nếu trong hệ thống xây dựng sẵn chưa có.

- Các tính năng được tùy chỉnh hoặc thêm vào hệ thống xây dựng sẵn khó có thể đạt được hiệu quả như hệ thống ban đầu

5 DESIGN STRATEGIES

5.3 Phát triển nhờ các nhà phát triển bên ngoài (Outsourcing)

- Việc ra quyết định, kiểm soát quản lý các chức năng hệ thống được chuyển sang cho các nhà cung cấp bên ngoài

- Sự chuyển giao này yêu cầu hai sự đồng thuận

+ Trao đổi thông tin

+ Sự tin tưởng giữa nhà cung cấp và nhà kinh doanh

5 DESIGN STRATEGIES

5.3.1 Ưu điểm

- Các nhà phát triển bên ngoài có đội ngũ có nhiều kinh nghiệm hơn hoặc

đã từng phát triển các ứng dụng có liên quan đến ứng dụng đang cần.

- Giảm được chi phí cần cho phát triển hệ thống.

5.3.2 Nhược điểm

- Giao một hệ thống mới cho người khác phát triển có thể gây ra các vấn đề về thất thoát thông tin hoặc mất kiểm soát hệ thống trong tương lai

- Không nâng cao được kỹ năng cho các thành viên trong công ty

- Các vấn đề về ngôn ngữ, múi giờ, văn hóa khác nhau

- Các nhà cung cấp nhận phát triển cũng gặp rủi ro như việc chi phí phát triển hệ thống vượt quá mức đã đề ra trong hợp đồng, khi đó họ sẽ phải chịu chi phí phát sinh

5 DESIGN STRATEGIES

5.4 So sánh các chiến lược

thiết kế

Sử dụng phát triển ứng dụng tùy chỉnh nội bộ khi

Sử dụng tùy chỉnh hệ thống xây dựng sẵn khi…

Sử dụng outsourcing khi…

Nhu cầu kinh doanh

Nhu cầu kinh doanh

nội bộ

Tồn tại chức năng nội bộ và kinh nghiệm kỹ thuật

Tồn tại chức năng nội bộ

Không tồn tại chức năng nội bộ và kinh nghiệm kỹ thuật

án có tay nghề cao

và phương pháp luận đã được chứng minh

Dự án có quản lý dự

án có thể điều phối các nỗ lực của nhà cung cấp.

Dự án có người quản lý

dự án có tay nghề cao

ở cấp tổ chức phù hợp với phạm vi của thỏa thuận thuê ngoài.

Khung thời gian

Khung thời gian linh hoạt.

Khung thời gian ngắn Khung thời gian ngắn

hoặc linh hoạt

6 SELECTING AN ACQUISITION STRATEGY

- Khi lựa chọn một giải pháp thay thế tùy chỉnh, đội dự án phải hiểu rõ về công

cụ, công nghệ nào sẽ được sử dụng,

- Ngoài ra đội dự án có thể liên hệ với các công ty khác có nhu cầu tương tự và tìm hiểu các loại hệ thống mà họ đã áp dụng

- Tuy nhiên các công ty nên chắc chắn xác thực với thông tin mà họ nhận được

từ nhà tư vấn hay nhà cung cấp

- Vd: một đội dự án tranh luận về việc sử dụng Java làm công cụ phát triển và hệ thống quản trị CSDL từ Oracle hay thuê ngoài công ty phát triển như CGI Mỗi

giải pháp thay thế đều có ưu nhược điểm và cần được xem xét kỹ lưỡng và cuối cùng chỉ có thể chọn 1 giải pháp

- Nhóm dự án có thể sử dụng RFP để tiếp cận thu thập thông tin bổ sung cần thiết RFP mô tả chi tiết hệ thống hoặc dịch vụ cần thiết và các nhà cung cấp phản hồi bằng cách mô tả chi tiết cách họ có thể cung cấp những nhu cầu đó

6 SELECTING AN ACQUISITION STRATEGY

- RFP không chỉ là một cách để thu thập thông tin mà nó có gợi ý tới một đề xuất những nhà cung cấp có thể hoàn thành nhiệm vụ được mô tả trong RFP

- Đối với dự án nhỏ hơn thì yêu cầu cung cấp thông tin RFI có thể đã đủ RFI là một yêu cầu ngắn hơn, ít chi tiết hơn được gửi đến các nhà cung cấp tiềm năng để có được thông tin chung về các sản phẩm và dịch vụ của họ

- Khi danh sách thiết bị đầy đủ mà nhà cung cấp chủ cần cung cấp giá mà không cần phân tích hay mô tả thì yêu cầu báo giá RFQ có thể được sử dụng

- Cách sử dụng ma trận thay thế để chọn chiến lược chuyển đổi:

6 SELECTING AN ACQUISITION STRATEGY

1.Vẽ một lưới các lựa chọn thay thế trên tiêu chí hàng đầu và các tiêu chí khác nhau dọc theo bên 1 đường. 

2.Điền vào lưới với mô tả chi tiết về từng phương án

7 APPLYING THE CONCEPTS AT PATTERSON SUPERSTORE

- Ta cần cân bằng giữa các mô hình chức năng, cấu trúc & hành vi

- Hoạt động này sẽ tiết lộ sự mâu thuẫn và phát hiện ra thông tin mới về hệ thống định triển khai

- Sau khi tạo các lần lặp lại đã sửa trong ba mô hình, nhóm đã xác định được một chiến lược thiết kế

CHAPTER REVIEW