Công nghệ phần mềm ôn tập chuong 7

CHƢƠNG 7: THIẾT KẾ CHI TIẾT
* Chủ đề:
_ Thiết kế hƣớng đối tƣợng sử dụng UML
_ Mẫu thiết kế;
_ Phát triển mã nguồn mở;
_ một số vấn đề khác.
1:Thiết kế và hiện thực - trang 3
_ Thiết kế và hiện thực phần mềm là 1 giai đoạn trong quá trình cơng nghệ phần
mềm mà tại đó hệ thống phần mềm thực thi đƣợc phát triển.
_ Hoạt động thiết kế và hiện thực phần mềm là bất biến.
+ Thiết kế phần mềm là hoạt động sáng tạo trong đó bạn xẽ định nghĩa các thành
phần của phần mềm và mối quan hệ giữa chúng, dựa trên yêu cầu của ngƣời đặt hàng
+ Hiện thực phần mềm là một quá trình hiện thực các thiết kế của chƣơng trình.
2: Xây dựng và mua (build and buy) - trang 4
_ Trong phạm vi rộng lớn của các lĩnh vực, chúng ta hiện nay có thể mua các hệ
thống để thích ứng và phù hợp với yêu cầu của ngƣời dùng.
+ Ví dụ, nếu chúng ta muốn hiện thực 1 hệ thống ghi tên thuốc, chúng ta có thể
mua 1 gói đã đƣợc sử dụng tại các bệnh viện, nó có thể rẻ hơn và nhanh hơn khi sử
dụng các phần mềm đó so với việc phát triển 1 hệ thống ngôn ngữ lập trình thơng
thƣờng.
_ Khi bạn phát triển 1 ứng dụng theo cách này, quá trình thiết kế sẽ trở nên liên quan
với việc sử dụng cấu hình của hệ thống nhƣ thế nào để cung cấp các yêu cầu cho hệ
thống.
3: Quá trình thiết kế hƣớng đối tƣợng - trang 5
_ Cấu trúc của quá trình thiết kế hƣớng đối tƣợng bao gồm phát triển một số mơ hình
hệ thống khác nhau.
_ Chúng yêu cầu nhiều phép thử cho phát triển và bảo trì của các mơ hình đó, nếu
cho 1 mơ hình nhỏ thì phƣơng pháp này khơng đem lại hiệu quả về chi phí.
_ Tuy nhiên, cho 1 chƣơng trình lớn phát triển bởi nhiều nhóm thiết kế mơ hình thì
đây là một cơ chế để trao đổi, giao tiếp với nhau giữa các nhóm rất hiệu quả và quan
trọng.

4: Các bƣớc của 1 quá trình (process) - trang 6:
_ Có một loạt các q trình thiết kế hƣớng đối tƣợng khác nhau mà phụ thuộc vào tổ
chức sử dụng quá trình
_ Hoạt động chung trong các quá trình bao gồm:
+ Xác định ngữ cảnh và các thức của việc sử dụng hệ thống.
+ Thiết kế kiến trúc hệ thống.
+ Xác định nguyên lý của hệ thống đối tƣợng.
+ Phát triển mơ hình thiết kế.
+ Đặc tả giao diện đối tƣợng.
_ Quá trình minh họa ở đây sử dụng thiết kế cho
5:Ngữ cảnh và tƣơng tác hệ thống - trang 7
_ Hiểu đƣợc mối quan hệ giữa hệ thống đang đƣợc thiết kế và mơi trƣờng bên ngồi
của nó là bản chất cho việc quyết định làm thế nào để cung cấp các chức năng do hệ
thống yêu cầu và làm thế nào để cấu trúc của hệ thống có thê giao tiếp với mơi trƣờng của


nó.
_ Hiểu đƣợc ngữ cảnh sẽ giúp bạn tạo đƣợc ranh giới của hệ thống. Tạo ranh giới hệ
thống giúp bạn quyết định đƣợc cái đặc trƣng nào đƣợc hiện thực trong hệ thống đang
đƣợc thiết kế và các đặc trƣng nào đƣợc kết hợp trong hệ thống
6: Mơ hình ngữ cảnh và mơ hình tƣơng tác - trang 8
_ Mơ hình ngữ cảnh hệ thống là một mơ hình cấu trúc mà biểu diễn các hệ thống
khác trong môi trƣờng của hệ thống đang đƣợc phát triển.
_ Mơ hình tƣơng tác là một mơ hình động mà biểu diễn làm thế nào để hệ thống
tƣơng tác với môi trƣờng của nó nhƣ cách mà nó đƣợc sử dụng
7:Mơ tả use case của báo cáo thời tiết (example usecase) - trang 11
System
Use case
Actors (đối
tƣợng)

Description

Trạm khí tƣợng thủy văn ( weather station) KH: ws
Báo cáo thời tiết
Hệ thống thông tin thời tiết và trạm khí tƣợng thủy văn

Ws gửi tổng kết của dữ liệu thời tiết mà họ thu thập đƣợc từ các thiết bị
trong giai đoạn thu thập thông tin cho hệ thống thông tin thời tiêt. Dữ
liệu gửi là max, min, trung bình group và nhiệt độ khơng khí.max, min
và giá trị trung bình áp suất, max, min, và giá trị trung bình của tốc độ
gió, lƣợng mƣa trung bình và hƣớng gió đƣợc thu thập ngay lập tức cứ
sau khoảng 5 giây.
Stimulus (kích Hệ thống thơng tin thời tiết xây dựng đƣờng giao tiếp giữa vệ tinh với
thích, tác động) ws và yêu cầu chuyển giao dữ liệu.
Response
Dự liệu tổng hợp đƣợc gửi đến hệ thống thông tin thời tiết.
Comment(ghi
Ws thƣờng đƣợc yêu cầu báo cáo 1 lần/ giờ nhƣng tần số có thể khác từ
chú)
1 trạm so với các trạm khác và có thể đƣợc bổ xung trong tƣơng lai
8: Thiết kế kiến trúc - trang 12
_ Một khi tƣơng tác giữa hệ thống và môi trƣờng của nó đã đƣợc hiểu rõ, bạn có thể
sử dụng thông tin này để thiết kế kiến trúc hệ thống
_ Bạn xác định các thành phần chính tạo nên hệ thống vào mối tƣơng tác giữa chúng,
sau đó có thể tổ chức các thành phần sử dụng 1 mẫu kiến trúc nhƣ là mơ hình lớp và mơ
hình client-server.
_ trạm khí tƣợng thủy văn đƣợc phân chia thành các hệ thống con độc lập mà giao
tiếp bằng cách phát các thông điệp trong cơ sở hạ tầng chung.
9: Kiến trúc cấp cao của trạm khí tƣợng thủy văn ( ws) - trang 13
10 Kiến trúc của hệ thống chọn lọc dữ liệu - trang 14

11: Sự định nghĩa lớp đối tƣợng - trang 15
_Nhận dạng đối tƣợng class là 1 phần rất khó của thiết kết hƣớng đối tƣợng.
_ Sự nhận dạng đối tƣợng là 1 quá trình lặp đi lặp lại. Bạn khơng có khả năng nhận
đƣợc đúng nó ngay lần đầu tiên.
12: Phƣơng pháp tiếp cận để xác định vấn đề - trang 16 (cái này không hiểu)
_ Sử dụng giản đồ tiếp cận dựa vào ngôn ngữ tự nhiên mô tả hệ thống.
_ Dựa vào identification xác định những vấn đề trong các lĩnh vực của ứng dụng.
_ Xử dụng hành vi tiếp cận và xác định đối tƣợng dựa vào những gì tham gia vào
hành vi.


_ Sử dụng kịch bản dựa vào phân tích. Các đối tƣợng, thuộc tính, phƣơng thức trong
mỗi kịch bản đƣợc xách đinh.
13: Mơ tả trạm khí tƣợng thủy văn ( weather station) - trang 17
_ Weather station là 1 gói phần mềm điều khiển công cụ chọn lọc dữ liệu, biểu diễn
các quá trình xử lý dữ liệu và truyền dữ liệu cho các quá trình xử lý dữ liệu tiếp theo. Các
cơng cụ bao gồm nhiệt kế khơng khí, nhiệt kế đất, máy đo gió, cánh quạt gió, thƣớc đo
lƣợng mƣa. Dữ liệu đƣợc thu thập định kì.
_ Khi có 1 lệnh đƣợc phát ra để truyền dữ liệu thời tiết thì WS sẽ xử lý và tổng hợp
các dữ liệu về khí hậu đã thu thập đƣợc, dữ liệu tổng hợp này sẽ đƣợc truyền tới máy tính
lập biểu đồ khi nhận đƣợc 1 yêu cầu.
14: Các lớp đối tƣợng của WS - trang 18
_ Sự định nghĩa các lớp đối tƣợng trong hệ thống WS có thể dựa trên phần cứng của
nó và dữ liệu trong hệ thống.
+ Nhiệt kế đất(địa nhiệt), máy đo sức gió, máy đo áp suất.
. Phạm vi ứng dụng của các đối tƣợng đó là các đối tƣợng phần cứng quan
hệ với các thiết bị của hệ thống.
+ WS: Giao diện cơ bản của WS đối với mơi trƣờng của nó (trong slide câu này
khơng có động từ => dịch ra khơng có nghĩa). Do đó, nó phản ánh sự tƣơng tác đƣợc
xác định trong mơ hình use-case.

+ Dữ liệu thời tiết: là sự tóm gọn dữ liệu từ các thiết bị.
Weather data
Weather station
airTemperatures
Identifier
groundTemperatures
reportWeather()
windSpeeds
reportStatus()
windDirections(hƣớng gió)
powerSave(instruments)
pressures(áp suất)
removeControl(commands)
rainfall
reconfigure(commands)
collect()
restart(commands)
summarize()
shutdown(instruments)
Ground Thermometer(địa
nhiệt)
Gt_ident (định danh của
thiết bị)
Temperature
Get()
Test()

Anemometer(đo sức gió)
An_ident
windSpeed

windDirection
Get()
Test()

Barometer(máy đo áp suất)
Ba_ident
pressure
height
Get()
Test()

15: Mơ hình thiết kế - trang 20
_Mơ hình thiết kế biểu diễn các đối tƣợng, các lớp đối tƣợng và mối quan hệ giữa các
thực thể.
_ Mơ hình tĩnh (static model) mơ tả cấu trúc tĩnh của hệ thống trong giới hạn của các
lớp đối tƣợng và các mối quan hệ.
_ Mơ hình động mơ tả các tƣơng tác động (tƣơng tác thay đổi đƣợc) giữa các đối
tƣợng.
16: Ví dụ về mơ hình thiết kế - trang 21


_ Mơ hình hệ thống con biểu diễn liên kết luận lý của các đối tƣợng vào trong hệ
thống con gắn liền với nó.
_ Sequence model biểu diễn sequence(thứ tự) các tƣơng tác của đối tƣợng
_ State machine model: biểu diễn làm thế nào mà các đối tƣợng riêng thay đổi trạng
thái của nó để trả lời lại các sự kiện (response to events).
_ Ngồi ra cịn có các mơ hình khác là use-case model, aggregation model,
generalisation model....(tồn mấy mơ hình lạ, ai bít chỉ giáo, pm qua face: An Vo Hoang)
17: Mơ hình hệ thống con - trang 22
_ Biểu diễn làm thế nào mà cách thiết kế đƣợc tổ chức thành các nhóm có liên quan

một cách logic của các đối tƣợng
_ Trong UML, có các gói biểu diễn bằng cách sử dụng các gói - 1 cấu trúc tóm gọn.
Đó là mơ hình logic. Cách tổ chức thực tế của các đối tƣợng trong hệ thống có thể khác
nhau.
18: Sequence Model - trang 23
_ Sequence model biểu diễn thứ tự của các đối tƣợng tƣơng tác diễn ra
+ các đối tƣợng đƣợc sắp xếp theo chiều ngang dọc theo top của mơ hình.
+ Thời gian đƣợc biểu diên theo chiều dọc do đó các mơ hình đƣợc đọc từ trên
top xuống bottom
+ Các tƣơng tác đƣợc biểu diễn bằng các mũi tên có nhãn. Các mũi tên khác
nhau biểu diễn các loại tƣơng tác khác nhau.
+ Hình chữ nhật dài (thời gian nó đƣợc sử dụng trong tƣơng tác) biểu diễn thời
gian khi đối tƣợng là đối tƣợng kiểm sốt trong hệ thống.
19: Ví dụ - trang 24


20:Sequence Diagram for Engage Foreign Character Use Case

20: giản đồ trạng thái (state diagram) - trang 28
_Biểu đồ trạng thái đƣợc sử dụng để biểu diễn làm thế nào mà các đối tƣợng trả lời
lại các yêu cầu về dịch vụ khác nhau và kích hoạt chuyển đổi trạng thái bởi các u cầu
đó.
_ Biểu đồ trạng thái là mơ hình cấp cao ( high - level model) rất hữu ích của hệ thống
hoặc hành vi của thời gian chạy 1 đối tƣợng (object's run-time behavior)
_ Bạn không nhất thiết phải cần 1 biểu đồ trạng thái cho toàn bộ các đối tƣợng trong
hệ thống. Nhiều đối tƣợng trong hệ thống rất đơn giản và 1 biểu đồ trạng thái chỉ thêm
vào các chi tiết không cần thiết cho việc thiết kế.
21: Weather station state diagram - trang 29

22: Đặc tả giao diện - trang 30
_ Các giao diện của đối tƣợng phải đƣợc đặc tả vì thế mà các đối tƣợng và các
thành phần khác có thể thiết kế song song với nhau.
_ Các đối tƣợng có thể có vài giao diện là các quan điểm do hệ thống cung cấp.
_ UML sử dụng class diagram cho đặc tả giao diện nhƣng java cũng có thể đƣợc
sử dụng.
23:Weather station interfaces - trang 31:

24: Các mẫu(mơ hình) thiết kế - trang 32
_ Một mẫu thiết kế là 1 cách để sử dụng lại các kiến thức trừu tƣợng về 1 vấn đề và
giải pháp của nó.
_ Một mẫu là 1 sự mô tả của vấn đề và bản chất của giải pháp của vấn đề đó
_ Mẫu thiết kế nên đủ trừu tƣợng để đƣợc tái sử dụng trong các bản chỉnh sửa khác
nhau.
_ Mẫu mô tả thƣờng sử dụng các đặc điểm hƣớng đối tƣợng nhƣ là thừa kế, đa hình.
25: Các phần tử mẫu(mơ hình) - trang 33
_ Tên (định danh).
_ Mô tả vấn đề
_ Mô tả giải pháp
_ Kết quả - hệ quả
+ Kết quả và giá trị của việc áp dụng mẫu


26:Mơ hình quan sát - trang 34
_Tên: quan sát;
_ Sự mô tả:
+ Tách các hiển thị của đối tƣợng trạng thái từ các đối tƣợng của chính nó;
_ Mơ tả vấn đề
+ Đƣợc sử dụng khi nhiều hiển thị của trạng thái đƣợc yêu cầu
_ Mô tả giải pháp

_ Kết quả - hệ quả
27: Mơ hình quan sát tt - trang 35
Tên mơ hình
Quan sát
Sự mơ tả
Chia hiển thị của các trạng thái của các đối tƣợng từ các đối tƣợng của
chính nó và cho phép thay đổi các hiển thị đƣợc cung cấp. Khi các đối
tƣợng trạng thái đƣợc thay đổi, mọi hiển thị đƣợc tự động thông báo và
update để đáp ứng sự thay đổi
Mô tả vấn đề Trong nhiều trƣờng hợp, bạn phải cung cấp đa hiển thị của thơng tin
trạng thái, ví dụ nhƣ là 1 hiển thị đồ thị và hiển thị bảng. Không phải tồn
bộ các vấn đề đều đƣợc biết đến khi thơng tin đƣợc đặt tả chi tiết. Tất cả
các biểu diễn thay thế có thể hỗ trợ tƣơng tác và khi các trạng thái đƣợc
thay đổi toàn bộ các hiển thị có thể đƣợc update
_ Mơ hình này có thể đƣợc sử dụng trong tất cả các trƣờng hợp, nơi mà
có nhiều hơn 1 cái khuông mẫu hiển thị cho thông tin trạng thái đƣợc u
cầu và nó khơng cần thiết cho các đối tƣợng phải duy trì trạng thái thơng
tin để biết về đặc tả khuông mẫu hiển thị đƣợc sử dụng
Mô tả giải
_ Gồm 2 đối tƣợng trừu tƣợng, chủ đề và quan sát (subject and observer)
pháp
và hai đối tƣợng cụ thể đó là chủ đề cụ thể và đối tƣợng cụ thể
(ConcreteSubject vs ConcreteObject) nó kế thừa các thuộc tính của các
đối tƣợng quan hệ trừu tƣợng. Các đối tƣợng trừu tƣợng bao gồm các
thao tác chung đƣợc áp dụng vào tất cả các trƣờng hợp. Các trạng thái
đƣợc hiển thị đƣợc duy trì trong ConcreteSubject, kế thừa những thao tác
từ chủ đề cho phép nó thêm, xóa các quan sát (Observer) (Mỗi Observer
tƣơng ứng với 1 hiển thị) và kết quả của 1 thông báo khi trạng thai có sự
thay đổi.
_ ConcreteObserver duy trì bản sao của 1 trạng thái của ConcreteSubject

và hiện thực phƣơng thức update() giao diện của Observer, nó cho phép
các bản sao này đƣợc giữ trong các bƣớc. ConcreteObserver hiển thị tự
động các trạng thái và các thay đổi khi trạng thái đƣợc update.
Kết quả - hệ
_ Các subject chỉ biết các Observer trừu tƣợng và không thể biết chi tiết
quả
của các lớp cụ thể. Do đó có mắt xích tối thiểu giữa các đối tƣợng.
_ Thay đổi các subject có thể là nguyên nhân của tập các liên kết
Observer đƣợc sinh ra, một số trong số chúng có thể khơng cần thiết
28:Mơ hình UML của mẫu Observer - trang 38


29: Các vấn đề thiết kế - trang 39
_ Để sử dụng các mẫu (mơ hình) trong thiết kế của bạn, bạn cần nhìn nhận rằng bất
kì vấn đề thiết kế nào bạn đang đảm nhiệm đều có 1 cái mẫu kết hợp đƣợc với nó có thể
ứng dụng vào
+ Nói với một vài đối tƣợng rằng trạng thái của các đối tƣợng khác có thể thay
đổi (mẫu Observer)
+ Dọn dẹp các giao diện cho một số các đối tƣợng liên quan mà thƣờng đƣợc
phát triển theo từng bƣớc.
+ Cung cấp một phƣơng pháp chuẩn để truy cập các phần tử trong 1 chọn lọc,
không kể làm thế nào mà việc chọn lọc đƣợc hiện thực.(Iterator pattern)
+ Cho phép việc có thể mở rộng chức năng của các lớp hiện hành trong thời gian
chạy. (Decorator pattern)
30: Tái sử dụng ( reuse) - trang 40
_ Từ những năm 1960 đến những năm 1990, phần lớn các phần mềm mới đƣợc phát
triển từ những thứ linh tinh bằng cách viết toàn bộ code trong 1 ngơn ngữ lập trình cấp
cao.
+ Chỉ sử dụng lại những gì quan trọng hoặc phần mềm là tái sử dụng của các
chức năng và các đối tƣợng trong các thƣ viện ngơn ngữ lập trình.

_ Chi phí và áp lực tiến độ là những yếu tố có ảnh hƣởng đến việc phƣơng pháp này
trở nên không hợp lý, đặc biệt là các hệ thống thƣơng mại và hệ thống cơ sở internet.
_ Phƣơng pháp tiếp cần phát triển dựa vào vòng sử dụng của phần mềm tồn tại từng
bƣớc nổi lên và ngày nay đƣợc sử dụng chung cho các phần mềm kinh doanh và khoa học
31: Các cấp độ của việc tái sử dụng - trang 41
_ Cấp trừu tƣợng:
+ Ở cấp này bạn không thế sử dụng lại phần mềm ngay lập tức nhƣng sử dụng
kiến thức trừu tƣợng đã ứng dụng thành công trong thiết kế phần mềm của bạn
_ Cấp đối tƣợng
+ Ở cấp độ này bạn sử dụng lại đƣợc phần mềm ngay lập tức từ 1 thƣ viện tốt
hơn sơ với việc bạn tự viết lại code.
_ Cấp thành phần:
+ Các thành phần là sự chọn lọc của các đối tƣợng và các lớp đối tƣợng mà bạn
sử dụng lại trong các hệ thống ứng dụng.
_ Cấp hệ thống:


+ Ở cấp độ này bạn sử dụng lại toàn bộ hệ thống ứng dụng
32: Chi phí tái sử dụng - trang 42
_ Giá trị của thời gian bỏ ra trong việc tìm kiếm phần mềm cho việc tái sử dụng và
đánh giá và cả trƣờng hợp khơng có cái mà bạn cần.
_ Nếu có, chi phí của việc mua phần mềm sử dụng lại đƣợc. Đối với hệ thống lớn chi
phí có thể rất là cao.
_ Các chi phí của việc thêm vào và hiệu chỉnh các thành phần của phần mềm hoặc hệ
thống có thể sử dụng lại đƣợc để phản ánh ( đáp ứng ) lại các yêu cầu của hệ thống mà
bạn đang phát triển
_ Các chi phí của việc tích hợp các phần tử của phần mềm có thể sử dụng lại đƣợc
với các phần tử khác trong hệ thống.( nếu bạn đang sử dụng phần mềm từ những nguồn
khác nhau) và với code mới mà bạn đang phát triển cho phần mềm.
33: Các công cụ nền tảng hỗ trợ phát triển - trang 43

_ Là sự tích hợp giữa compiler và chỉnh sửa hệ thống theo cú pháp cho phép bạn tạo,
chỉnh sửa và compile code.
_ Hệ thống debug ngôn ngữ.
_ Các công cụ chỉnh sửa đồ họa ví dụ nhƣ cơng cụ chỉnh sửa mơ hình UML
_ Cơng cụ kiểm tra (testing) ví dụ nhƣ JUnit có thể tự động chạy một tập các testcase
trong một phiên bản mới (new version) của chƣơng trình
_ Các cơng cụ hỗ trợ project có thể giúp bạn tổ chức lại code cho các project phát
triển khác nhau.
34: Tích hợp các mơi trƣờng phát triển ( IDEs) - trang 44
_ Các công cụ phát triển phần mềm thƣờng đƣợc nằm trong một group để tạo ra1 tích
hợp môi trƣờng phát triển ( Integrated Development Evironment - IDE)
_ Một IDE là 1 tập các công cụ hỗ trợ phần mềm hỗ trợ các mặt khác nhau của việc
phát triển phần mềm trong một số sƣờn và giao diện ngƣời dùng chung.
_ Các IDE đƣợc tạo ra để hộ trỡ phát triển trong một số ngơn ngữ lập trình đặc biệt
nhƣ java. IDE ngơn ngữ có thể đƣợc phát triển rất đặc biệt hoặc có thể đặc trung cho mục
đích chung của IDE với cơng cụ hỗ trợ ngơn ngữ đặc biệt.
35: Các yếu tố triển khai của hệ thống hoặc của thành phần - trang 45
_ Nếu 1 thành phần đƣợc thiết kế cho 1 kiến trúc phần cứng đặc biệt hoặc dựa vào
một số hệ thống phần mềm khác, nó rõ ràng phải đƣợc triển khai trên 1 nền tảng đã đƣợc
cung cấp các yêu cầu phần mềm và hỗ trợ phần cứng.
_ Các hệ thống có tính sử dụng cao có thể u cầu các thành phần đƣợc triển khai
trên nhiều hơn 1 nền tảng. Điều này có nghĩa rằng trong trƣờng hợp nền tảng bị lỗi
(failure), thì một hiện thƣc thay thế của phần tử đƣợc sử dụng.
_ Nếu có 1 cấp giao tiếp cao giữa các thành phần, nó thƣờng phán đốn để triển khai
chúng trong nền tảng tƣơng tự hoặc trên các nền tảng mà các tính chất vật lý gần giống
với các cái khác. Điều này giúp giảm delay giữa thời gian 1 message đƣợc gửi bởi 1
thành phần và nhận đƣợc bởi 1 thành phần khác.
36: Phát triển mã nguồn mở - trang 46
_ Phát triển mã nguồn mở là 1 phƣơng pháp tiếp cận tới phát triển phần mềm mà
trong đó code nguồn của 1 hệ thống phần mềm là public và những tình nguyện viên đƣợc

mời tham gia vào q trình phát triển.
_ Nguồn gốc của nó là các phần mềm miễn phí. Với chủ trƣờng code nguồn có thể
khơng có quyền sở hữu nhƣng ln ln đƣợc sử dụng cho ngƣời dùng kiểm tra và bổ


xung nếu họ muốn.
_ Phần mềm mã nguồn mở mở rộng ý tƣởng này bằng cách sử dụng internet bằng
cách tuyển mộ thêm một lƣợng lớn các tình nguyện viên phát triển mới. Nhiều ngƣời
trong số họ cũng là ngƣời dùng của code này
37: Các hệ thống mã nguồn mở - trang 47
_ Sản phẩm mã nguồn mở nổi tiếng nhất là linux, nó đƣợc mở rộng sử dụng với 1 hệ
thống server và ngày càng trở thành 1 máy tính để bàn.
_ Những sản phẩm mã nguồn mở quan trọng khác là Java, server web Apache và
mySQL hệ quản lý cơ sở dữ liệu.
38: Các vấn đề của mã nguồn mở - trang 48
_ Các sản phẩm đang phát triển có nên sử dụng các thành phần mã nguồn mở
khơng ?
_ Phƣơng pháp tiếp cận mã nguồn mở có nên đƣợc sử dụng cho phát triển phần
mềm ?
39: Kinh doanh mã nguồn mở - 49
_ Càng ngày càng nhiều các công ty sản phẩm đang sử dụng mã nguồn mở tiếp cận
cho việc phát triển.
_ Mơ hình kinh doanh của họ không đáng tin cậy để bán 1 sản phẩm phần mềm
nhƣng lại hỗ trợ cho việc bán sản phẩm đó
_ Họ tin rằng việc mở rộng kinh doanh mã nguồn mở phổ biến sẽ cho phép phần
mềm đƣợc phát triển 1 cách rẻ hơn, nhanh hơn và sẽ tạo ra sự phổ biến đối với ngƣời
dùng phần mềm này.
40: Giấy phép mã nguồn mở - trang 50
_ Nguyên lý cơ bản của sự phát triển mã nguồn mở là nguồn code có thể sử dụng tự
do, nó khơng có nghĩa là bất cứ ai cũng có thể làm những gì họ muốn với code đó.

_ Về hợp pháp thì các nhà phát triển code( kể cả cơng ty hoặc cá nhân) vẫn sở hữu
code của họ. Họ có thể đặt ra các hạn chế trong việc sử dụng phần mềm bằng cách bao
gồm các điều kiện ràng buộc hợp pháp trong giấy phép mã nguồn mở.
_ Một số nhà phát triển mã nguồn mở tin rằng nếu 1 thành phần nguồn mở đƣợc sử
dụng để phát triển 1 phần mềm mới, sau đó hệ thống cũng có thể trở thành nguồn mở.
_ Một số khác sẽ cho phép code của họ đƣợc sử dụng mà khơng có hạn chế nào. Các
hệ thống phát triển có thể độc quyền và đƣợc bán nhƣ 1 hệ thống nguồn đóng.
41: Các mơ hình giấy phép - trang 51
_ Giấy phép cơng khai( General Public License - GPL) GNU. Có một giấy phép gọi
là "reciprocal" có nghĩa là nếu bạn sử dụng phần mềm mã nguồn mở đƣợc cấp giấy phép
dƣới dạng giấy phép GPL thì bạn phải chắc rằng đó là phần mềm mã nguồn mở.
_ Giấy phép ít cơng khai (Lesser General Public License -LGPL) GNU là 1 loại giấy
phép GPL khác, chúng ta có thể viết các thành phần liên kết với code nguồn mở mà
khơng có xuất bản nguồn của các thành phần đó.
_ Giấy phép phân phối chuẩn Berkley ( Berkley Standard Distribution - BSD). Có 1
giấy phép "non-reciprocal", nó có nghĩa là bạn khơng bắt buộc phải tái bản lại bất cứ thay
đổi hoặc bổ xung nào để xây dựng mã nguồn mở. Có thể bao gồm code trong các hệ
thống có chủ quền đƣợc bán.
42: Quản lý giấy phép - trang 52
_ Tạo ra 1 hệ thống nhằm duy trì thơng tin về các thành phần của mã nguồn mở đƣợc
download và sử dụng.


_ Để nhận biết các loại khác nhau của giấy phép và hiểu đƣợc làm thế nào 1 thành
phần đƣợc cấp phép trƣớc khi sử dụng.
_ Nhận biết đƣợc các con đƣờng mở rộng cho các thành phần.
_ Giảng giải cho mọi ngƣời về mã nguồn mở
_ Có các hệ thống kiểm tra ở các vị trí thích hợp.
_ Tham gia vào việc public mã nguồn mở.

43: Tóm lượt - trang 53
_ Thiết kê và hiện thực phần mềm là các hoạt động không tách rời. Cấp độ chi tiết
trong thiết kế phụ thuộc vào kiểu hệ thống và bạn đang sử dụng phƣơng pháp tiếp cận
nhanh hay là hoạch định kế hoạch từng bƣớc.
_ Quá trình thiết kế hƣớng đối tƣợng bao gồm các hoạt động thiết kế kiến trúc hệ
thống, xác định các đối tƣợng trong hệ thống, mơ tả các thiết kế sử dụng các mơ hình đối
tƣợng khác nhau và lập tài liệu các giao diện thành phần.
_ Hàng loạt các mơ hình khác nhau có thể đƣợc tạo ra trong suốt quá trình thiết kế
hƣớng đối tƣợng. Bao gồm các mơ hình tĩnh nhƣ : class models, generalization models,
association models và các mơ hình động nhƣ : sequence models, state machine models.
_ Khi phát triển phần mềm, bạn nên xem xét tính có thể sử dụng lại của phần mềm
đang tồn tại, kể cả các thành phần, các dịch vụ, hoặc các hệ thống hoàn chỉnh
_ Quản lý cấu hình là quá trình quản lý sự thay đổi của hệ thống phần mềm mở rộng.
Nó rất cần thiết khi 1 nhóm ngƣời đang hợp tác để phát triển phần mềm.
_ Hầu hết các phát triển phần mềm là sự phát triển hƣớng mục tiêu. Bạn sử dụng IDE
trong máy chủ để phát triển phần mềm. Nó đƣợc chuyển cho máy đích để thực thi.
_ Phát triển mã nguồn mở mở rộng code nguồn của một hệ thống có thể sử dụng
cơng cộng (public). Điều này có nghĩa là nhiều ngƣời có thể tham gia vào việc thay đổi
và hoàn thiện cho phần mềm.
44: Đặc tả 1 lớp - trang 56
1: Tập hợp danh sách các thuộc tính trong SRS ( nếu SRS đƣợc tổ chức thành các
lớp)
2: Thêm các thuộc tính bổ xung theo yêu cầu của việc thiết kế.
3: Tên của phƣơng thức phải tƣơng ứng cho mỗi yêu cầu của lớp đó.
4: Tên của các phƣơng thức thêm vào theo yêu cầu của việc thiết kế
5: Biểu diễn các thuộc tính và các phƣơng thức trong mơ hình đối tƣợng.
6: Trạng thái lớp bất biến
45: Đặc tả 1 chức năng - trang 57
1: Chú ý các thành phần của SRS và SDD mà các chức năng(method) này đáp ứng.
2: Trạng thái của những biểu thức chức năng gì phải là bất biến.

3: Trạng thái điều kiện đầu tiên của phƣơng thức ( giả thuyết là gì)
4: Trạng thái điều kiện sau của phƣơng thức ( kết quả của nó).
5: Cung cấp 1 pseudocode hoặc/và 1 flowchart để đặc tả chi tiết cho giải thuật đang
đƣợc sử dụng.( trừ khi nó rất đơn giản)
46: Các
lớp trong thiết kế chi tiết - trang 58


47: Đặc tả các chức năng (ở đây là chức năng withdrawn() trong class Account) - trang 60
_ Không dịch đƣợc đoạn này do không hiểu lắm


48: Đặc tả giải thuật: Flowcharts và Pseudocode - trang 61

protected final void setName( String aName )
{
// Check legitimacy of parameter and settings
if( ( aName == null ) || ( maxNumCharsInName() <= 0 ) ||
( maxNumCharsInName() > alltimeLimitOfNameLength() ) )
{ _name = new String( "defaultName" );
System.out.println ( "defaultName selected by
GameCharacter.setName()");
} else
// Truncate if aName too long
if( aName.length() > maxNumCharsInName() )
_name = new String ( aName.getBytes(), 0,
maxNumCharsInName() );
else // assign the parameter name
_name = new String( aName );
}

49: Ví dụ pseudocode - trang 63
_FOR number of microseconds supplied by operator
IF number of microseconds exceeds critical value
Try to get supervisor's approval
IF no supervisor's approval
abort with "no supervisor approval for unusual duration" message
ENDIF
ENDIF
IF power level exceeds critical value
abort with "power level exceeded" message
ENDIF
IF ( patient properly aligned & shield properly placed & machine self-test
passed )
Apply X-ray at power level p
ENDIF
ENDFOR


50: Ƣu điểm của pseudocode và flowcharts - trang 64
_ Chọn lọc các giải thuật trong nhiều trƣờng hợp.
_ Áp đặt các bƣớc phát triển của quá trình thiết kế chi tiết tài liệu.
_ Cung cấp thêm cấp độ mà tại đó kiểm tra có thể đƣợc thực hiện.
+ Giúp phát hiện các khiếm khuyết trƣớc khi code
+ Tăng độ tin cậy cho sản phẩm.
_ Có thể giảm chi phí tổng thế.
51: Nhƣợc điểm của Pseudocode và flowchart - trang 65
Chú ý: dịch slide sao thấy nó giống Ƣu điểm hơn là nhƣợc điểm. Cẩn thận đối chiếu
lại, có thể t dịch sai.
_ Phải tạo thêm các cấp để duy trì đƣợc thơng tài liệu. (có mỗi ý đây giống nhƣợc
điểm, còn 2 cái sau là ƣu điểm cmnr chứ nhƣợc điềm gì lạ vậy)

_ Giới thiệu đƣợc các lỗi có thể có trong q trình dịch code.
_ Có thể u cầu cơng cụ để trích dẫn psuedocode và tạo điều kiện thuận lợi cho vẽ
flowchart.
52: Các bƣớc để xây dựng giao diện ngƣời dùng - trang 66
1: Biết đƣợc ngƣời dùng của bạn.
2: Hiểu đƣợc mục đích kinh doanh trong câu hỏi.
3: Áp dụng các nguyên lý thiết kế 1 giao diện tốt
4: Chọn loại của sổ giao diện thích hợp
5: Phát triển các menu của hệ thống
6: Chọn các thiết bị điều khiển cơ sở thích hợp
7: Chọn các giao diện điều khiển cở sở thích hợp
8: Tổ thức và đƣa ra hiển thị cho các cửa sổ
9: Chọn các màu phù hợp
10: Tạo ra các icon mang đầy đủ ý nghĩa
11: Cung cấp các thông điệp báo kết quả, thông tin phản hồi và hƣớng dẫn.
53: Nguyên lý để thiết kế 1 giao diện tốt - trang 67
_ Đảm bảo tính thống nhất giữa các giao diện thiết kế ứng dụng và giữa các giao diện
bên trong chúng.
_ Phán đoán trƣớc đƣợc nơi nào ngƣời dùng sẽ thƣờng xuyên bắt đầu khi sử dụng
ứng dụng.
+ Thƣờng sắp xếp sao cho các phần tử đầu tiên thƣờng đƣợc bắt đầu ở trên cùng
bên trái. (nghĩa là muốn ngƣời dùng nhập tên và địa chỉ vào thì tên nằm ở trên địa chỉ
nếu xếp từ trên xuống hoặc nằm bên trái nếu xếp theo hàng ngang)
_ Làm cho càng đơn giản cang tốt:
+ Sắp xếp theo các phần tử giống nhau
+ Nhóm các phần tử giống nhau lại
+ Xem xét phạm vi ràng buộc của các phần tử (phần tử hoặc là yếu tố)
_ Áp dụng hệ thống phân cấp để làm nhấn mạnh các vấn đề quan trọng khác
_ Áp dụng nguyên lý pleasing visuals -- usually( ƣu tiên nhiều hình ảnh, dễ hiểu)
_ Cung cấp các chú thích.

54: Áp dụng nguyên lý thiết kế giao diện tốt - trang 68


55: trang 69

56: Phát triển các menu cho hệ thống - trang 70
_ Cung cấp 1 menu chính.
_ Hiển thị tồn bộ các thay thế có liên quan.
_ Nối cấu trúc của menu với cấu trúc của các nhiệm vụ ứng dụng
_ Tối giản hóa một số cấp menu (tối đa chỉ nên có 4 cấp menu)