CHƢƠNG 7: THIẾT KẾ CHI TIẾT...+ 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ế

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 quá 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 ngoà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

CuuDuongThanCong.com https://fb.com/tailieudientucntt

http://cuuduongthancong.com

https://fb.com/tailieudientucntt

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 Trạm khí tƣợng thủy văn ( weather station) KH: ws

Use case Báo cáo thời tiết

Actors (đối

tƣợng)

Hệ thống thông tin thời tiết và trạm khí tƣợng thủy văn

Description 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

thích, tác động)

Hệ thống thông tin thời tiết xây dựng đƣờng giao tiếp giữa vệ tinh với

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

chú)

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ừ

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 station

Identifier

reportWeather()

reportStatus()

powerSave(instruments)

removeControl(commands)

reconfigure(commands)

restart(commands)

shutdown(instruments)

Ground Thermometer(địa

nhiệt)

Gt_ident (định danh của

thiết bị)

Temperature

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

Weather data

airTemperatures

groundTemperatures

windSpeeds

windDirections(hƣớng gió)

pressures(áp suất)

rainfall

collect()

summarize()

Anemometer(đo sức gió)

An_ident

windSpeed

windDirection

Get()

Test()

Barometer(máy đo áp suất)

Ba_ident

pressure

height

Get()

Test()




_ 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).

_ Ngoài ra còn có các mô hình khác là use-case model, aggregation model,

generalisation model....(toà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 soá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 yê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 toà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 yê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

pháp

_ Gồm 2 đối tƣợng trừu tƣợng, chủ đề và quan sát (subject and observer)

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ệ

quả

_ Các subject chỉ biết các Observer trừu tƣợng và không thể biết chi tiết

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ể yê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 đoá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 quá 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 luôn luôn đƣợ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 quá trình dịch code.

_ Có thể yê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ị toà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)







Documents

CHƢƠNG 7: THIẾT KẾ CHI TIẾT...+ 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ế