CÂU HỎI ÔN TẬP MÔN HỌC PHÂN TÍCH THIẾT KẾ HỆ THỐNG THÔNG TIN

1. Hãy trình bày quy trình chi tiết phát triển hệ thống thông tin (Software Life Development Cycle). Theo các
bạn, trong quy trình phát triển hệ thống, giai đoạn nào là quan trọng nhất? Tại sao?

SDLC: PlanningAnalysisDesignImplementation (System Analysis and Design, chapter1 )

Planning
Giai đoạn lập kế hoạch là quá trình cơ bản để hiểu tại sao một hệ thống thông tin cần được xây dựng và xác định đội
ngũ dự án sẽ xây dựng nó như thế nào. Nó có hai bước:
1. Trong quá trình bắt đầu dự án, hầu hết ý tưởng cho các hệ thống mới đến từ bên ngoài khu vực IS (từ bộ
phận tiếp thị, phòng kế toán, vv) dưới hình thức yêu cầu hệ thống. Một yêu cầu hệ thống trình bày một bản tóm
tắt ngắn về nhu cầu kinh doanh, và nó giải thích cách một hệ thống hỗ trợ nhu cầu sẽ tạo ra giá trị kinh
doanh. Bộ phận IS hoạt động cùng với người hoặc bộ phận tạo ra yêu cầu (gọi là nhà tài trợ dự án) phân tích tính
khả thi. Phân tích tính khả thi khảo sát các khía cạnh chính của dự án đề xuất:
■ Tính khả thi về mặt kỹ thuật (chúng ta có thể xây dựng nó được không?)
■ Tính khả thi về kinh tế (Nó có mang lại giá trị kinh doanh?)
■ Tính khả thi của tổ chức (nếu chúng ta xây dựng nó, nó sẽ được sử dụng?)
Yêu cầu hệ thống và phân tích tính khả thi được trình bày cho một ủy ban phê duyệt hệ thống thông tin (đôi khi được
gọi là ban chỉ đạo) quyết định dự án nên được thực hiện hay không.
2. Một khi dự án đã được phê duyệt, dự án sẽ được đưa vào quản lý dự án. Trong quá trình quản lý dự án,
người quản lý dự án sẽ lập kế hoạch, nhân viên dự án và đưa ra các kỹ thuật để giúp đội dự án kiểm soát và chỉ đạo
dự án thông qua toàn bộ SDLC. Sản phẩm cung cấp cho quản lý dự án là một kế hoạch dự án mô tả đội ngũ dự án sẽ
phát triển hệ thống như thế nào.
Analysis
Giai đoạn phân tích sẽ trả lời các câu hỏi về ai sẽ sử dụng hệ thống, hệ thống sẽ làm gì, và nơi nào và khi nào nó
được sử dụng. Trong giai đoạn này, nhóm nghiên cứu điều tra bất kỳ hệ thống hiện tại nào, xác định những cơ hội cải
tiến và phát triển khái niệm cho hệ thống mới. Giai đoạn này có ba bước:
1. Một chiến lược phân tích được xây dựng để hướng dẫn các nỗ lực của nhóm dự án. Chiến lược như vậy
thường bao gồm việc phân tích hệ thống hiện tại (được gọi là hệ thống như là) và các vấn đề của nó, và các cách để
thiết kế một hệ thống mới (được gọi là hệ thống đang được).
2. Bước tiếp theo là thu thập yêu cầu (ví dụ, thông qua các cuộc phỏng vấn hoặc bảng câu hỏi). Việc phân
tích thông tin này - kết hợp với sự đóng góp của nhà tài trợ dự án và nhiều người khác - dẫn đến sự phát triển của
một khái niệm cho một hệ thống mới. Khái niệm hệ thống sau đó được sử dụng làm cơ sở để phát triển một bộ mô
hình phân tích nghiệp vụ mô tả hoạt động của doanh nghiệp nếu hệ thống mới được phát triển. Bộ mẫu thường bao
gồm các mô hình đại diện cho dữ liệu và quy trình cần thiết để hỗ trợ quá trình kinh doanh cơ bản .
3. Các phân tích, khái niệm hệ thống, và các mô hình được kết hợp thành một tài liệu gọi là đề xuất hệ
thống, được trình bày cho nhà tài trợ dự án và các nhà ra quyết định quan trọng khác (ví dụ như các thành viên của
ủy ban phê duyệt) quyết định xem dự án nên tiếp tục di chuyển phía trước. Đề xuất hệ thống là sản phẩm ban đầu mô
tả những gì các yêu cầu kinh doanh mà hệ thống mới phải đáp ứng. Bởi vì nó thực sự là bước đầu tiên trong việc
thiết kế hệ thống mới, một số chuyên gia cho rằng không thích hợp để sử dụng thuật ngữ phân tích như là tên của
điều này giai đoạn; một số cho rằng một tên tốt hơn sẽ là phân tích và thiết kế ban đầu. Các tổ chức tiếp tục sử dụng
để phân tích tên cho giai đoạn này, tuy nhiên, vì vậy chúng tôi cũng sẽ sử dụng nó trong cuốn sách này. Chỉ cần ghi
nhớ rằng các deliverable từ giai đoạn phân tích là cả hai phân tích và một thiết kế ban đầu cấp cao cho hệ thống mới.
Design
Giai đoạn thiết kế quyết định cách hệ thống sẽ hoạt động, về mặt phần cứng, phần mềm và cơ sở hạ tầng mạng; giao
diện người dùng, các biểu mẫu và báo cáo; và các chương trình đặc biệt, cơ sở dữ liệu và các tập tin sẽ là cần thiết.
Mặc dù hầu hết các quyết định chiến lược về hệ thống đã được thực hiện trong việc phát triển khái niệm hệ thống
trong giai đoạn phân tích, các bước trong giai đoạn thiết kế xác định chính xác hệ thống sẽ hoạt động như thế nào.
Giai đoạn thiết kế có bốn bước:
1. Chiến lược thiết kế phải được phát triển. Điều này cho thấy liệu hệ thống sẽ được phát triển bởi các lập
trình viên của chính công ty, cho dù nó sẽ được thuê bên ngoài (thông thường là một công ty tư vấn), hoặc liệu công
ty sẽ mua một gói phần mềm hiện có.
2. Điều này dẫn đến việc phát triển thiết kế kiến trúc cơ bản cho hệ thống mô tả phần cứng, phần mềm và
cơ sở hạ tầng mạng sẽ được sử dụng. Trong hầu hết các trường hợp, hệ thống sẽ bổ sung hoặc thay đổi cơ sở hạ tầng
đã tồn tại trong tổ chức. Thiết kế giao diện xác định cách người dùng sẽ di chuyển qua hệ thống (ví dụ: các phương
pháp điều hướng như trình đơn và các nút trên màn hình) và các biểu mẫu và báo cáo mà hệ thống sẽ sử dụng.
3. Cơ sở dữ liệu và các đặc tả được phát triển. Chúng xác định chính xác dữ liệu nào sẽ được lưu và nơi
chúng sẽ được lưu giữ.
4. Nhóm chuyên gia phân tích phát triển thiết kế chương trình, xác định các chương trình cần phải được viết
và chính xác những gì chương trình sẽ làm. Bộ sưu tập các sản phẩm phân phối (thiết kế kiến trúc, thiết kế giao diện,
cơ sở dữ liệu và các đặc tả cụ thể, và thiết kế chương trình) là hệ thống đã được giao cho nhóm lập trình thực hiện.
Vào cuối giai đoạn thiết kế, phân tích tính khả thi và kế hoạch dự án được xem xét lại và sửa đổi, và một quyết định
khác được thực hiện bởi nhà tài trợ và ủy ban phê duyệt dự án về việc có nên chấm dứt dự án hay tiếp tục.
Implementation
Giai đoạn cuối trong SDLC là giai đoạn thực hiện, trong thời gian đó hệ thống thực sự được xây dựng (hoặc mua,
trong trường hợp thiết kế phần mềm đóng gói). Đây là giai đoạn thường được chú ý nhiều nhất, bởi vì đối với hầu hết
các hệ thống, nó là phần dài nhất và tốn kém nhất trong quá trình phát triển. Giai đoạn này có ba bước:
1. Xây dựng hệ thống là bước đầu tiên. Hệ thống được xây dựng và thử nghiệm để đảm bảo nó hoạt động
theo thiết kế. Vì chi phí của lỗi có thể là bao la, thử nghiệm là một trong những bước quan trọng nhất trong thực hiện.
Hầu hết các tổ chức dành nhiều thời gian và chú ý vào việc kiểm tra hơn là viết các chương trình ở nơi đầu tiên.
2. Hệ thống đã được cài đặt. Lắp đặt là quá trình mà hệ thống cũ bị tắt và hệ thống mới được bật. Nó có thể
bao gồm một cách tiếp cận trực tiếp (trong đó hệ thống mới thay thế ngay lập tức hệ thống cũ), một cách tiếp cận
chuyển đổi song song (trong đó cả hệ thống cũ và mới đều được vận hành trong một hoặc hai tháng cho đến khi rõ
ràng là không có lỗi hệ thống mới), hoặc chiến lược chuyển đổi theo từng giai đoạn (trong đó hệ thống mới được cài
đặt trong một bộ phận của tổ chức như là một thử nghiệm ban đầu và sau đó được cài đặt lại ở các hệ thống khác).
Một trong những khía cạnh quan trọng nhất của việc chuyển đổi là xây dựng kế hoạch đào tạo để dạy người dùng
cách sử dụng hệ thống mới và giúp quản lý những thay đổi do hệ thống mới gây ra.
3. Nhóm chuyên gia phân tích thiết lập một kế hoạch hỗ trợ cho hệ thống. Kế hoạch này thường bao gồm
một đánh giá sau khi thực hiện chính thức hoặc không chính thức, cũng như một cách có hệ thống để xác định những
thay đổi lớn và nhỏ cần thiết cho hệ thống.
2. Hãy trình bày khái niệm thiết kế theo hướng từ trên xuống (top-down design) và thiết kế theo hướng từ
dưới lên (bottom-up design). Theo các bạn, trong môi trường làm việc outsourcing thì thường sử dụng hình
thức thiết kế nào? Tại sao?

System Analysis and Design, chapter 7

a.Top – down design:

-Là quá trình phân tích (phá hủy) các quy trình tổng thể hoặc nhiệm vụ thành các bộ phận (module) và tiếp
tục chia nhỏ các modun thành phần cho đến mức thấp nhất có thể. Nó được gọi là top-down design hoặc top-down
decomposition khi chúng ta bắt đầu “at the top” với một vấn đề chung và thiết kế các giải pháp cụ thể cho các vấn đề
phụ.
b.Bottom-up design:
-Là quá trình sử dụng các thành phần cụ thể và cơ bản hoặc có sẵn tiến hành biên soạn ra các thành phần
cao hơn quá trình này tiếp tục đến khi các thành phần không thể phát triển được nữa như là một thành phần duy nhất
(software/system).

3. Hãy trình bày chi tiết về quy trình Relational Unified Process (RUP).

Khối xây dựng RUP

RUP dựa trên một bộ các khối xây dựng và các yếu tố nội dung, mô tả những gì sẽ được sản xuất, những kỹ năng cần
thiết và giải thích từng bước mô tả cách thức đạt được các mục tiêu phát triển cụ thể.
Bốn giai đoạn của vòng đời dự án
RUP đã xác định một vòng đời dự án bao gồm bốn giai đoạn. Các giai đoạn này cho phép tiến trình được
trình bày ở mức độ cao tương tự như cách một dự án theo kiểu 'thác nước' có thể được trình bày, mặc dù về bản chất
chìa khóa của quy trình nằm ở các lặp đi lặp lại của sự phát triển nằm trong tất cả các giai đoạn . Ngoài ra, mỗi giai
đoạn có một mục tiêu chính và cột mốc quan trọng ở phần cuối biểu thị mục tiêu đã đạt được. Hình dung các giai
đoạn và kỷ luật RUP theo thời gian được gọi là biểu đồ gồ ghề RUP .
Giai đoạn khởi động
 Mục tiêu chính là để phạm vi hệ thống một cách đầy đủ làm cơ sở để xác nhận chi phí ban đầu và ngân
sách.
Nếu dự án không đạt được mốc quan trọng này, được gọi là cột mốc quan trọng của vòng đời, nó có thể bị
hủy bỏ hoặc lặp đi lặp lại sau khi được thiết kế lại để đáp ứng tốt hơn các tiêu chí.
Giai đoạn xây dựng (Ortner)
Mục tiêu chính là giảm nhẹ các hạng mục rủi ro chính được xác định bằng cách phân tích cho đến khi kết
thúc giai đoạn này. Giai đoạn xây dựng là nơi dự án bắt đầu hình thành. Trong giai đoạn này, phân tích lĩnh vực vấn
đề được thực hiện và kiến trúc của dự án được hình thành cơ bản.
Kết quả của giai đoạn soạn thảo là:

 Một mô hình trường hợp sử dụng, trong đó các trường hợp sử dụng và các tác nhân đã được xác định và hầu
hết các mô tả trường hợp sử dụng được phát triển. Mô hình trường hợp sử dụng phải được hoàn tất 80%.

 Mô tả về kiến trúc phần mềm trong quá trình phát triển hệ thống phần mềm.

 Một kiến trúc thực thi mà nhận ra trường hợp sử dụng kiến trúc đáng kể.

 Trường hợp kinh doanh và danh mục rủi ro được sửa đổi.

 Kế hoạch phát triển cho toàn bộ dự án.

 Các nguyên mẫu có thể làm giảm được các rủi ro kỹ thuật đã được xác định.

 Hướng dẫn sử dụng sơ bộ (tùy chọn)

Giai đoạn này phải vượt qua các tiêu chí cột mốc kiến trúc vòng đời trả lời các câu hỏi sau:

 Tầm nhìn của sản phẩm có ổn định không?

 Kiến trúc có ổn định không?

 Liệu các cuộc biểu tình thực thi chỉ ra rằng các yếu tố nguy cơ chính được giải quyết và giải quyết?

 Kế hoạch pha xây dựng có đầy đủ chi tiết và chính xác không?

 Tất cả các bên liên quan đều đồng ý rằng tầm nhìn hiện tại có thể đạt được bằng cách sử dụng kế hoạch hiện
tại trong bối cảnh kiến trúc hiện tại?

 Chi phí tài nguyên thực tế so với kế hoạch có thể chấp nhận được không?
Nếu dự án không thể vượt qua mốc này, vẫn còn thời gian để nó bị hủy bỏ hoặc thiết kế lại. Tuy nhiên, sau khi rời
khỏi giai đoạn này, dự án chuyển sang một hoạt động có nguy cơ cao, nơi những thay đổi khó khăn hơn và gây bất
lợi khi thực hiện.
Việc phân tích miền chính cho việc xây dựng là kiến trúc hệ thống.
Giai đoạn xây dựng [ sửa ]
Mục tiêu chính là xây dựng hệ thống phần mềm. Trong giai đoạn này, trọng tâm chính là phát triển các
thành phần và các tính năng khác của hệ thống. Đây là giai đoạn khi phần lớn mã hóa diễn ra. Trong các dự án lớn
hơn, một số lặp đi lặp lại xây dựng có thể được phát triển trong một nỗ lực để chia các trường hợp sử dụng thành các
phân đoạn có thể quản lý tạo ra các nguyên mẫu có thể minh họa.
 Giai đoạn này tạo ra bản phát hành bên ngoài đầu tiên của phần mềm. Kết luận của nó được đánh dấu bởi
cột mốc về khả năng hoạt động ban đầu.
Giai đoạn chuyển tiếp [ sửa ]
Mục tiêu chính là để "chuyển tiếp" hệ thống từ phát triển sang sản xuất, làm cho nó có sẵn và hiểu bởi người
dùng cuối. Các hoạt động của giai đoạn này bao gồm đào tạo người dùng cuối và người bảo trì và thử nghiệm beta hệ
thống để xác nhận nó theo mong muốn của người dùng cuối. Hệ thống cũng đi qua một giai đoạn đánh giá, bất kỳ
nhà phát triển nào không sản xuất được công việc cần thiết sẽ được thay thế hoặc gỡ bỏ. Sản phẩm cũng được kiểm
tra so với mức chất lượng đặt trong giai đoạn Khởi động.
Nếu đạt được tất cả các mục tiêu, bước phát hành sản phẩm đã đạt được và chu trình phát triển kết thúc.

4. Hãy trình bày chi tiết về mô hình “4+1”view.

Mỗi góc nhìn như thầy bói xem voi, nó không thể hiện hết hệ thống nhưng thể hiện rõ hệ thống ở một khía cạnh.
Chính vì thế trong xây dựng có bản vẽ kiến trúc (nhìn về mặt kiến trúc), bản vẽ kết cấu (nhìn về mặt kết cấu), bản vẽ
thi công (nhìn về mặt thi công). Trong phần mềm cũng như vậy, OOAD sử dụng UML có các góc nhìn sau:

Trong đó,

– Use Case View: cung cấp góc nhìn về các ca sử dụng giúp chúng ta hiểu hệ thống có gì? ai dùng và dùng nó như
thế nào.

– Logical View: cung cấp góc nhìn về cấu trúc hệ thống, xem nó được tổ chức như thế nào. Bên trong nó có gì. (  chỉ
ra các biểu diễn trừu tượng trong hệ thống dưới dạng các đối tượng và lớp đối tượng. )

– Process View: cung cấp góc nhìn động về hệ thống, xem các thành phần trong hệ thống tương tác với nhau như thế
nào .( chỉ ra cách các tương tác thời gian thực xảy ra trong hệ thống.)

– Component View: Cũng là một góc nhìn về cấu trúc giúp chúng ta hiểu cách phân bổ và sử dụng lại các thành phần
trong hệ thống ra sao. .( chỉ ra phần cứng của hệ thống và cách các component của hệ thống được phân tán trên các
processor như thế nào.)

– Deployment View: cung cấp góc nhìn về triển khai hệ thống, nó cũng ảnh hưởng lớn đến kiến trúc hệ thống.( chỉ ra
cách một phần mềm được phân rã để phát triển như thế nào)

Tập hợp các góc nhìn này sẽ giúp chúng ta hiểu rõ hệ thống cần phân tích, thiết kế. Trong hình 1 chúng ta thấy góc
nhìn Use Case View nằm ở giữa và chi phối tất cả các góc nhìn còn lại. Chính vì thế chúng ta thường thấy các tài liệu
nói về 4 view + 1 chứ không phải 5 view nhằm nhấn mạnh vai trò của Use Case View.

5. Hãy định nghĩa yêu cầu của hệ thống và các loại yêu cầu của hệ thống? Cho ví dụ minh họa cho từng loại
yêu cầu.

Mục đích

• Xác định yêu cầu là một công việc quan trọng mà PTV cần thực hiện trong giai đoạn phân tích.

• Nhiều HTTT khi xây dựng bị thất bại do việc xác định yêu cầu không được thực hiện cẩn thận hoặc bị
xem thường.

• Việc xác định yêu cầu đòi hỏi PTV chủ yếu làm việc với tổ chức (nhà quản lý, người điều hành, người sử
dụng) nhiều hơn là đội ngũ kỹ thuật IT.

• Các kỹ năng thiết lập quan hệ và truyền thông tốt với tổ chức sẽ giúp PTV thực hiện tốt việc xác định yêu
cầu.

Định nghĩa yêu cầu

 • Phân biệt:

- Yêu cầu công việc (business requirements).

- Yêu cầu hệ thống (system requirements).

- User requirements (yêu cầu của khách hàng): (diễn tả bằng ngôn ngữ tự nhiên) Câu lệnh trong ngôn
ngữ tự nhiên cộng với sơ đồ của các dịch vụ hệ thống cung cấp và hạn chế hoạt động của nó. Viết cho
khách hàng.
- Yêu cầu hệ thống (system requirements) :Thiết lập một cấu trúc tài liệu trong đó có các mô tả chi tiết
của các chức năng của hệ thống, Dịch vụ và các hoạt động hạn chế.

• Các yêu cầu công việc nhấn mạnh đến HT cần phải thực hiện cái gì hoặc có những đặc tính gì (what).

• Các yêu cầu hệ thống nhấn mạnh đến HT phải thực hiện công việc, hoặc có những đặc tính mong muốn
bằng cách nào (how).

• Đối với yêu cầu công việc:

- Giai đoạn lập kế hoạch  yêu cầu mang tính tổng quát, trừu tượng.

- Giai đoạn phân tích  yêu cầu cần cụ thể, rõ ràng, chính xác, khả thi.

• Khi HT di chuyển theo thời gian từ giai đoạn lập kế hoạch, phân tích, thiết kế và xây dựng thì yêu cầu thay
đổi theo.

- Tổng quát, trừu tượng  cụ thể, rõ ràng.

- Ít yếu tố kỹ thuật  nhiều yếu tố kỹ thuật.

• Chú ý là trong thực tế, không có một ranh giới rõ ràng giữa các yêu cầu công việc và các yêu cầu hệ thống.

• Do vậy đôi khi người ta gọi công việc “xác định yêu cầu” là “xác định yêu cầu hệ thống”.

Phân loại yêu cầu

• Yêu cầu chức năng (Function requirements):

• là yêu cầu liên quan trực tiếp đến những qui trình công việc mà hệ thống cần phải thực hiện, hoặc những
dữ liệu mà HT cần phải chứa.

• Nắm vững các yêu cầu chức năng sẽ giúp PTV thực hiện tốt việc phân tích các use cases, lập mô hình qui
trình và mô hình dữ liệu sau này.

Ví dụ:

 Tính đúng đắn: Các chức năng phải hoạt động đúng theo yêu cầu.

 Tính khoa học: Cách xây dựng, tổ chức các chức năng phải khoa học. Xây dựng CSDL hợp lý,
khoa học nhằm nâng cao tốc độ truy CSDL, giảm tài nguyên lưu trữ dữ liệu.

 Tính tin cậy: Hệ thống phải bảo đảm tính an toàn đối với người sử dụng, nhất là trong việc thanh
toán, đặt, hủy vé và sửa đổi thông tin đặt vé.

 Tính thích nghi: Hệ thống có thể chạy tốt trong nhiều hệ điều hành khách nhau như window XP,
Vista, Windows7, 8.
 • Yêu cầu phi chức năng (Non-Function Requirements):

• là yêu cầu về những tính chất hoặc đặc tính mà HT cần phải có chẳng hạn như mức độ đáp ứng, hiệu suất
làm việc, khả năng truy xuất dữ liệu, độ an toàn của HT

• Nắm vững các yêu cầu phi chức năng sẽ giúp PTV thực hiện tốt việc chọn lựa kiến trúc cho hệ thống, chọn
lựa phần cứng và phần mềm, cũng như thiết kế giao diện sau này

Ví dụ:

-Hệ thống có thể phục vụ tốt, có khả năng hoạt động tốt 24/24 giờ và 7 ngày trên tuần.

-Chức năng tìm kiếm thông minh: tìm theo điểm đi – điểm đến, theo lịch trình, ngày chạy...

-Chức năng đặt vé, sửa, hủy vé, thanh toán trực tiếp phải đảm bảo chính xác và bảo mật.

-Hệ thống được vận hành bởi khách hàng và nhà sản xuất. Các hành động phá hoại từ bên ngoài
luôn được ngăn chặn bởi quản trị viên và pháp luât.

• Trong quá trình xác định yêu cầu, có thể tổ chức không biết rõ hoặc không biết hết các yêu cầu của HTTT mới,
đặc biệt là các yêu cầu phi chức năng.

• PTV cần phối hợp với tổ chức (nhà lãnh đạo, nhà quản lý, nhà điều hành, nhân viên, …) để giúp tổ chức khám
phá, nhận diện các yêu cầu mà HT mới cần đáp ứng.

• Chú ý PTV cần tránh khuynh hướng đưa ra các yêu cầu hướng vào lợi ích hoặc thuận lợi của PTV mà không
gắn liền với nhu cầu công việc, lợi ích của tổ chức.

6. Hãy trình bày về các loại kiến trúc của hệ thống?

*Ba mô hình kiến trúc có thể xem xét:

- Kiến trúc dựa trên Server. (Server-Based Architectures)

- Kiến trúc dựa trên Client. (Client-Based Architectures)

- Kiến trúc Client-Server. (Client-Server Architectures)

*Bốn chức năng của phần mềm (HTTT) sẽ được phân bố thực hiện trên những thành phần

máy tính khác nhau tùy theo kiến trúc hệ thống.

• Trong kiến trúc Client-Server: - Phía client chịu trách nhiệm về logic biểu diễn. Còn phía server chịu trách nhiệm
về logic truy xuất dữ liệu và lưu trữ dữ liệu. - Còn logic ứng dụng có thể ở phía client hoặc server, hoặc chia ra giữa
hai phía. Phân loại thick client và thin client dựa vào phía client chịu trách nhiệm nhiều hay ít logic ứng dụng.

• Ưu điểm của kiến trúc Client-Server.

- Có thể điều chỉnh tăng hoặc giảm năng lực lưu trữ, khả năng xử lý của các server. Mạng tin cậy hơn vì
không có một máy server nào hỗ trợ hết mọi ứng dụng.

- Có thể dùng nhiều loại máy tính client và server khác nhau với hệ điều hành khác nhau nhờ các
middleware.

- Đối với kiến trúc thin client-server dùng các chuẩn Internet thì dễ tách ra logic biểu diễn, logic ứng dụng
và logic truy xuất dữ liệu.
• Hạn chế của kiến trúc Client-Server.

- Việc xử lý phức tạp hơn. Mọi ứng dụng trên kiến trúc này đều phải có hai phần, phần mềm trên client và
phần mềm trên server.

- Việc cập nhật phần mềm cũng phức tạp, phải làm cả hai nơi, ở phía client lẫn phía server.

- Xuất hiện các kỹ thuật và ngôn ngữ lập trình mới đòi hỏi chuyên viên IT phải học hỏi và cập nhật.

*Tham khảo

- Client/Server: Kiến trúc Client/Server là kiến trúc yêu cầu các Client phải tuân theo giao thức của Server,
nhưng quá trình giao tiếp này chỉ là một chiều. Các Client gửi các yêu cầu đến Server, các Server sẽ cung
cấp các dịch vụ hợp lệ với yêu cầu và quá trình này chỉ là một chiều.
- Peer-to-Peer: Kiến trúc Peer-to-Peer yêu cầu mỗi hệ thống đều biết giao thức của hệ thống khác. Quá trình
giao tiếp là hai hướng mỗi hệ thống ngang hàng đều có thể yêu cầu dịch vụ từ hệ thống thác.
- Layered Architecture: Tổ chức hệ thống thành các lớp với các chức năng liên quan kết hợp với mỗi lớp. Một
lớp cung cấp dịch vụ cho các lớp trên nó để các lớp cấp thấp nhất đại diện cho các dịch vụ cốt lõi có khả
năng được sử dụng trên toàn hệ thống.
- MVC: Tách biệt giao diện và tương tác từ các hệ thống. Hệ thống được cấu trúc lại thành ba phần hợp lý và
tương tác với nhau. “The Model” là thành phần quản lý dữ liệu và các hoạt động liên quan đến dữ liệu đó.
“The View” thành phần xác định và quản lý cách dữ liệu được trình bày cho người dùng. “Controller”
thành phần quản lý tương tác người dùng (ví dụ, bấm phím, nhấp chuột, vv) và chuyển tác những tương tác
này cho View và Model.
- Broker Architecture: Không tìm thấy trong tài liệu của cô, ai biết thì làm.
- Reposity Architecture: Tất cả các dữ liệu trong hệ thống được quản lý trong một kho lưu trữ trung ương có
thể truy cập đến tất cả các thành phần trong hệ thống. Các thành phần không tương tác trực tiếp chỉ thông
qua kho lưu trữ.
- Piper and Filter: Việc xử lý các dữ liệu trong một hệ thống được tổ chức để mỗi thành phần xử lý (lọc/filter)
là rời rạc và thực hiện một loại hình chuyển đổi dữ liệu. Dòng chảy dữ liệu (data flows) (giống như trong
một ống) từ thành phần khác đến xử lý.

7. Hãy trình bày các loại quan hệ giữa các lớp? Cho ví dụ minh họa bằng lời văn?

Các loại quan hệ giữa các lớp:

- Dependency: Thể hiện mối quan hệ không bền giữa 2 lớp với nhau,có thể chỉ là thực hiện 1 phương thức
nào đó rồi dừng, ngoài ra không có sự quan hệ chặt chẽ nào

Ví dụ: Susan là bác sĩ đã khám cho vợ của Alex vào năm trước (khám cho vợ của alex chứ không khám cho
alex, có thể hai người này biết hoặc chỉ gặp nhau đúng 1 lần) :v.
- Association: Thể hiện 2 lớp có quan hệ, liên quan với nhau, mối quan hệ này rõ ràng và chặt chẽ.
Association thể hiện qua các quan hệ như “has: có”, “Own: sở hữu” v.v…
 Ví dụ: Một nhân viên có thể làm việc cho không hoặc chỉ một công ty.
Một công ty có ít nhất 1 hoặc nhiều nhân viên.
- Aggregation: Giống với Association nhưng sự phụ thuộc giữa các lớp mạnh hơn, có tính chất bổ sung cho
nhau. Aggregation thể hiện các quan hệ như “Exclusive owns: sở hữu độc quyền”, “Owns: sở hữu”,
“Member: Thành viên”, ...

Ví dụ: Một dự án có nhiều nhân viên tham gia, nếu dự án bị hủy thì nhân viên vẫn có thể làm việc bình
thường.
Bốn ngữ nghĩa có thể của Aggregation
• Sở hữu độc quyền (Exclusive Owns): Book has Chapter
• Có sự phụ thuộc tồn tại (không có chapter nếu không có book)
• Không chia sẻ
• Là thuộc tính cố định (một chapter không thể chuyển sang book khác)
• Sở hữu (Owns): Car has Tire
• Không chia sẻ
• Không là thuộc tính cố định (có thể chuyển tire sang một car khác)
• Có (Has): Department has Student
• Không có sự phụ thuộc tồn tại, có thể chia sẻ.

- Composition: Là Aggregation nhưng mạnh hơn nữa, nó thể hiện: Tại một thời điểm, mỗi đối tượng thành
phần (part) chỉ có thể thuộc chỉ một đối tượng bao gồm (whole), nếu đối tượng “whole” bị phá hủy thì “part
cũng sẽ bị hủy”. Thể hiện các mối quan hệ như: “Exclusive Owns: Sở hữu độc quyền”, “Owns: Sở hữu”

Ví dụ: Cơ thể bao gồm đầu, mình, tay, chân

- Inherritance: dùng để thể hiện lớp này là một kiểu, dạng của lớp kia (mối quan hệ cha con). Hai lớp có nhiều
đặc điểm giống nhau, lớp con thừa hưởng những đặc trưng của lớp cha (thuôc tính, phương thức).

Ví dụ: Nhân viên có thể có 2 kiểu: quản lý hoặc nhân viên thường

8. Hãy so sánh 3 quan hệ Association, Aggregation và Composition? Cho ví dụ minh họa hiện thực 3 quan hệ
trên bằng java code?

+ Association (liên kết)

Association là quan hệ giữa hai lớp với nhau, thể hiện chúng có liên quan với nhau.
• Một lớp sử dụng lớp khác
• Lời gọi phương thức của đối tượng thuộc lớp này trong lớp kia
• Thường được cài đặt bằng tham chiếu (nhưng không bắt buộc).

+ Aggregation (kết tập)

Aggregation là một loại của quan hệ Association nhưng mạnh hơn. Nó có thể cùng thời gian sống (cùng
sinh ra hoặc cùng chết đi)
Là một dạng đặc biệt của liên kết mô hình hóa mối quan hệ toàn thể-bộ phận (whole-part) giữa đối tượng
toàn thể và các bộ phận của nó. ▫ Aggregation là mối quan hệ “là một phần” (“is a part-of”).
Composition là một loại mạnh hơn của Aggregation thể hiện quan hệ class này là một phần của class kia

+ Composition nên dẫn đến cùng tạo ra hoặc cùng chết đi.

Public class House{

Private Room room;
Public House(){
room = new Room();
}
}