lethuthuy_84
New Member
Download miễn phí Luận văn Chiến lược thiết kế lĩnh vực và ứng dụng phần mềm quản lý người dùng tập trung
MỤC LỤC
LỜI CẢM ƠN . i
LỜI CAM ĐOAN . iv
MỤC LỤC .v
DANH MỤC TỪ VIẾT TẮT . vii
Danh mục hình. vii
PHẦN MỞ ĐẦU.x
Lý do chọn đề tài.x
Mục đích nghiên cứu .xi
Đối tượng và phạm vi nghiên cứu .xi
Phương pháp nghiên cứu .xi
Những nội dung chính của luận văn .xi
Chương 1.1
Tổng quan về các tiến trình phát triển phần mềm.1
và các chiến lược thiết kế.1
1.1. Tổng quan về các tiến trình phát triển phần mềm và kỹ nghệ phần mềm
hướng đối tượng.1
1.1.1. Tiến trình phát triển phần mềm .1
1.1.2. Kỹ nghệ phần mềm hướng đối tượng.11
1.2. Các cách tiếp cận thiết kế phần mềm.16
1.3. Một số chiến lược hiện đại để thiết kế phần mềm .18
1.3.1.Thiết kế phần mềm hướng mô hình.18
1.3.2. Thiết kế phần mềm hướng dữ liệu.19
1.3.3. Thiết kế phần mềm hướng Trách nhiệm .23
1.3.4. Thiết kế phần mềm hướng kiểm thử .261.3.5. Thiết kế phần mềm hướng lĩnh vực.33
KẾT LUẬN CHưƠNG .33
Chương 2.35
Chiến lược thiết kế phần mềm hướng lĩnh vực.35
2.1. Cách tiếp cận hướng lĩnh vực trong tiến trình phát triển phần mềm .35
2.1.1. Khái niệm về thiết kế hướng lĩnh vực .35
2.1.2.Tìm hiểu về lĩnh vực.36
2.1.3.Ngôn ngữ chung .38
2.2. Các đặc trưng thiết kế phần mềm hướng lĩnh vực .40
2.2.1 Thực thể.43
2.2.2 Đối tượng giá trị .45
2.2.2 Dịch vụ .47
2.2.3 Mô-đun .50
2.3. Các mô hình trong chiến lược thiết kế phần mềm hướng lĩnh vực.52
2.3.1 Aggregates and Aggregate Roots .53
2.3.2 Factory.56
2.3.3. Repository.60
2.3.4 Bounded Contexts .65
2.4. Quy trình phân tích và thiết kế phần mềm hướng lĩnh vực .67
Chương 3: Ứng dụng chiến lược thiết kế hướng lĩnh vực trong việc xây dựng phần mềm
quản lý tài khoản tập trung theo hướng dịch vụ microservice.69
3.1 Mô tả bài toán quản lý tài khoản dùng chung tại trường ĐHDL HảiPhòng .69
Đề xuất giải pháp cho các vấn đề đặt ra:.70
3.2 Tìm hiểu kiến trúc Microservices.703.3 Tìm hiểu mô hình Publisher – Subscriber Event.75
3.4 Phân tích và thiết kế yêu cầu phần mềm hướng lĩnh vực .76
3.5. Cài đặt và đánh giá phần mềm thử nghiệm .87
Đánh giá và kết luận .94
TÀI LIỆU THAM KHẢO .95
Để tải tài liệu này, vui lòng Trả lời bài viết, Mods sẽ gửi Link download cho bạn ngay qua hòm tin nhắn.
Ketnooi -
You must be registered for see links
Ai cần tài liệu gì mà không tìm thấy ở Ketnooi, đăng yêu cầu down tại đây nhé:
Nhận download tài liệu miễn phí
Tóm tắt nội dung tài liệu:
ƣợc thiết kế phần mềm hƣớng lĩnh vực sẽ đƣợc
trình bày chi tiết ngay trong chƣơng sau.
KẾT LUẬN CHƢƠNG
Một tiến trình phát triển phần mềm là một tập của các hoạt động cần thiết
(đặctả, xây dựng, đánh giá, tiến hóa) để chuyển các yêu cầu của ngƣời dùng thành
một hệ thống phần mềm đáp ứng đƣợc các yêu cầu đặt ra.
Có năm bƣớc chính cần thực hiện trong quá trình phát triển phần mềm:
- Xác định các yêu cầu
- Phân tích hệ thống
- Thiết kế hệ thống
- Lập trình và kiểm tra hệ thống
- Vận hành và bảo trì hệ thống.
34
Do các hệ phần mềm lớn là phức tạp nên ngƣời ta thƣờng dùng các cách tiếp cận
khác nhau trong việc thiết kế các phần khác nhau của một hệ thống. Chẳng có một
cách tiếp cận nào tốt nhất chung cho các dự án. Hai cách tiếp cận thiết kế hiện đang
đƣợc dùng rộng rãi trong việc phát triển phần mềm đó là cách tiếp cận theo hƣớng
chức năng và hƣớng đối tƣợng. Mỗi cách tiếp cận đều có ƣu và nhƣợc điểm riêng
phụ thuộc vào ứng dụng phát triển và nhóm phát triển phần mềm. Chúng bổ sung và
hỗ trợ cho nhau chứ không đối kháng nhau.
Có một số chiến lƣợc hiện đại để thiết kế phần mềm nhƣ thiết kế phần mềm theo
hƣớng mô hình,hƣớng dữ liệu, hƣớng trách nhiệm, hƣớng kiểm thử, hƣớng hành vi,
hƣớng lĩnh vực. Mỗi hƣớng có những đặc thù riêng và có những lợi thế riêng, trong
đó hƣớng lĩnh vực là trọng tâm nghiên cứu của luận văn.
35
Chƣơng 2
Chiến lƣợc thiết kế phần mềm hƣớng lĩnh vực
2.1. Cách tiếp cận hƣớng lĩnh vực trong tiến trình phát triển phần mềm
2.1.1. Khái niệm về thiết kế hƣớng lĩnh vực
Với cách tiếp cận truyền thống khi xây dựng một ứng dụng. Đầu tiên ta đọc
các yêu cầu đặc tả và tìm hiểu các chức năng, sau đó tiến hành chia nhỏ các công
việc. Trong phần lớn trƣờng hợp, việc này nhằm mục đích ƣớc lƣợng thời gian và
lên kế hoạch thực hiện cho các công việc. Vậy trình tự công việc sẽ là ƣớc lƣợng
thời gian, chia việc cho các thành viên trong team, thiết kế CSDL, cuối cùng là bắt
tay và code. Đây là cách thiết kế hƣớng dữ liệu hay còn gọi là Data Driven Design
[1].
Vậy vấn đề với cách tiếp cận là gì? Lâu nay ta vẫn tiếp cận theo cách này và
vẫn làm tốt ? Câu trả lời là Đúng và Sai. Đúng ở chỗ ta vẫn làm tốt trong việc bàn
giao Project, Sai ở chỗ ta chƣa thực hiện tốt trong việc bảo trì và mở rộng project.
Trong các ứng dụng điển hình có rất nhiều phần code xử lý các công việc
không liên quan đến Logic nghiệp vụ nhƣ truy cập file, mạng hay database, các
thành phần này thƣờng đƣợc gọi là plumping code (điền code) và đƣợc nhúng trực
tiếp vào trong Business Object và nhiều Business Logic cũng đƣợc nhúng vào thao
tác của giao diện Widget hay script của database, điều này thƣờng xảy ra vì nó làm
ta phát triển ứng dụng một cách nhanh chóng và dễ dàng. Việc này dẫn đến phần
lớn thời gian phát triển của Deverloper là dành cho việc viết các plumping code
thay vì viết Business Logic thực sự, nó làm cho thiết kế của ta bị mất đi tính hƣớng
đối tƣợng trong thực tế.
Ngoài ra khi logic nghiệp vụ trộn lẫn với lớp khác khiến cho việc đọc hiểu và
suy nghĩ về logic của ứng dụng trở nên khó khăn hơn đối với những ngƣời ngoài.
Chỉ một thay đổi nhỏ ở tầng UI (User interface)cũng có thể dẫn tới việc thay đổi
tầng logic và ngƣợc lại khi thay đổi một business rule của ứng dụng đòi hỏi ta phải
36
quan tâm đến từng chi tiết nhỏ phía UI cũng nhƣ database để đáp ứng đƣợc sự thay
đổi này.
Trong những ứng dụng nhỏ thì vấn đề này ta không nhìn thấy. Ở các ứng
dụng cỡ vừa thì thấy vấn đề này đã tồn tại và bắt đầu dẫn đến tình trạng phá vỡ các
thiết kế chuẩn. Đối với các ứng dụng lớn thì nó trở thành vấn đề nghiêm trọng, cách
tiếp cận trên sẽ không thể cho ta đƣa ra một thiết kế hƣớng đối tƣợng chính xác.
Giải pháp ở đây chính là Domain Driven Design.
Vậy DDD là gì ? DDD không liên quan gì đến công nghệ hay framework là
những thứ thuộc về tầng vật lý mà nó là một khái niệm thuộc về tầng logic khi ta
xây dựng một hệ thống phần mềm. Cụ thể hơn nó là mẫu thiết kế (design pattern) và
hơn nữa đây là design pattern ở cấp độ kiến trúc của hệ thống, ta cần phân biệt rõ
điều này để phân biệt các design pattern và ở cấp độ class. Nó cung cấp một cấu
trúc thực hành và các thuật ngữ cho việc ra quyết định thiết kế nhằm tập trung và
tăng tốc các dự án phần mềm trong các lĩnh vực phức tạp.
2.1.2.Tìm hiểu về lĩnh vực
Để tạo một phần mềm tốt, cần hiểu về phần mềm đó. Ta không thể làm ra hệ
thống phần mềm ngân hàng nếu trừ khi ta có hiểu biết tƣơng đối tốt về mảng ngân
hàng và những điều liên quan. Nghĩa là, để làm phần mềm tốt, ta cần hiểu lĩnh vực
ngân hàng. Liệu có thể làm đƣợc phần mềm ngân hàng phức tạp dù không có hiểu
biết nghiệp vụ tốt? Không thể. Không bao giờ. Ai hiểu về banking? Ngƣời thiết kế
phần mềm? Không. Ngƣời này chỉ tới ngân hàng để gửi tiền và rút tiền khi cần.
Ngƣời phân tích phần mềm? Cũng không hẳn. Anh ta chỉ biết phân tích một chủ đề
cụ thể khi anh ta có đầy đủ tất cả cấu phần. Lập trình viên? Vậy là ai? Nhân viên
ngân hàng, hiển nhiên. Hiểu nhất về hệ thống ngân hàng là những ngƣời ở trong đó,
những chuyên gia của họ. Họ hiểu mọi thứ chi tiết, cái haydở, mọi vấn đề có thể và
mọi quy định. Đây là nơi ta thƣờng xuất phát: Lĩnh vực (domain).
Giả sử cần xây dựng một hệ thống phần mềm quản lý bệnh viện. Rõ ràng là cần
phải làm việc với đội ngũ bác sĩ, y tá (chính là các chuyên gia trong lĩnh vực này -
domain expert) để xây dựng kiến thức về domain. Qua nói chuyện, trao đổi kiến
thức, đặt câu hỏi và trả lời. Cần hiểu rõ càng nhiều càng tốt về domain này. Bằng
37
cách đặt câu hỏi đúng, xử lý thông tin đúng cách, kỹ sƣ phần mềm và chuyên gia sẽ
dần vẽ ra một domain, một mô hình domain (domain model). Kỹ sƣ phần mềm, kết
hợp với domain expert cùng tạo nên một domain model và mô hình đó là nơi kiến
thức chuyên môn của cả hai bên đƣợc kết hợp và tổng hợp lại.
Hãy xem xét tiếp ví dụ sau. Giả sử ta đang tham gia thiết kế một tòa nhà.
Yêu cầu là:
+ Xây dựng trên một diện tích đất cố định
+ Tòa nhà cao 6 tầng
+ Mỗi tầng có 4 căn hộ
Vậy domain ở đây là gì? Là công trình xây dựng chăng? Cũng có thể. Nhƣng nếu
xem công trình xây dựng là domain, thì thể ta đang bỏ qua một vài chi tiết trong yêu
cầu. Công trình xây dựng đang thiết kế phải bao gồm thiết kế căn hộ cho ngƣời dân
sinh sống. Vậy thuật ngữ "công trình xây dựng" có thể khiến ta bỏ lỡ chi tiết, thay
vì đó ta có thể thu hẹp xuống thành "chung cư". Lúc này nếu nói với các kỹ sƣ về
việc thiết kế, rõ ràng thuật ngữ "chung cư" sẽ dễ hiểu hơn là "công trình xây dựng"
đơn thuần. Ta thấy đấy, chỉ một thay đổi nhỏ trong ngôn từ cũng có thể tạo nên sự
khác biệt. Trở lại ví dụ phần mềm bệnh viện ở trên, ngƣời thiết kế phần mềm và các
bác sĩ, y tá không thể nói cùng một ngôn ngữ đƣợc. Họ nói về từ ngữ chuyên môn,
ngƣời thiết kế phần mềm nói bằng đối tƣợng, phƣơng thức, quan hệ. Đó chính là lúc
ta cần một ngôn ngữ chung để cả hai bên có thể làm việc với nhau dễ dàng hơn.
38
2.1.3.Ngôn ngữ chung
Hình 2- 1. Mô hình ngôn ngữ chung
Ta đã thấy sự cần thiết không thể phủ nhận của việc phát triển mô hình
cho domain qua sự làm việc giữa chuyên gia phần mềm và chuyên gia domain; tuy
nhiên, cách làm này ban đầu thƣờng gặp những khó khăn về rào cản giao tiếp cơ
bản. Lập trình viên chỉ nghĩ tới lớp, method, thuật toán, pattern và có khuynh hƣớng
diễn tả mọi thứ đời thƣờng bằng những tạotác lập trình. Họ muốn nhìn lớp đối
tƣợng và tạo quan hệ mô hình giữa chúng. Họ nghĩ đến những thứ nhƣ kế thừa, đa
hình, OOP... Và họ luôn nói theo cách đó. Điều này là dễ hiểu với lập trình viên.
Lập trình viên vẫn chỉ là lập trình viên. Tuy vậy, chuyên gia domain thƣờng không
hiểu những khái niệm đó. Họ không có khái niệm gì về thƣ viện, framework phần
mềm và trong nhiều trƣờng hợp, thậm chí họ không hiểu về cơ sở dữ liệu. Tất cả
những gì họ biết là chuyên ngành cụ thể của họ.
Ví dụ: Trong theo dõi không lƣu, chuyên gia domain biết về máy bay, route,
cao độ, vĩ độ, kinh độ,độ lệch của route chuẩn, về quỹ đạo của máy bay. Họ nói về
những điều này bằng ngôn ngữ riêng của họ, đôi khi gây khó hiểu với ngƣời ngoài
ngành. Để vƣợt qua sự khác nhau về cách giao tiếp, ta xây dựng mô hình, ta phải
trao đổi, giao tiếp ý tƣởng về mô hình, về những thành phần liên quan đến mô hình,
cách ta liên kết chúng, chúng có liên quan với nhau hay không. Giao tiếp ở mức độ
39
này là tối quan trọng cho sự thành công của dự án. Nếu ai đó nói điều gì đó và
ngƣời khác không hiểu, hay tệ hơn, hiểu sai, thì liệu ta có cơ hội tiếp tục dự án
không?
Dự án sẽ gặp vấn đề nghiêm trọng nếu thành viên nhóm không chia chung
ngôn ngữ khi trao đổivề domain. Chuyên gia domain dùng từ lóng của riêng họ
trong khi thành viên kỹ thuật lại dùng ngôn ngữ riêng của họ để trao đổi về những
thuật ngữ của domain trong thiết kế. Bộ thuật ngữ trong trao đổi hành ngày tách
riêng với bộ thuật ngữ nhúng trong mã nguồn (là sản phẩm quan trọng cuối cùng
của dự ...
trình bày chi tiết ngay trong chƣơng sau.
KẾT LUẬN CHƢƠNG
Một tiến trình phát triển phần mềm là một tập của các hoạt động cần thiết
(đặctả, xây dựng, đánh giá, tiến hóa) để chuyển các yêu cầu của ngƣời dùng thành
một hệ thống phần mềm đáp ứng đƣợc các yêu cầu đặt ra.
Có năm bƣớc chính cần thực hiện trong quá trình phát triển phần mềm:
- Xác định các yêu cầu
- Phân tích hệ thống
- Thiết kế hệ thống
- Lập trình và kiểm tra hệ thống
- Vận hành và bảo trì hệ thống.
34
Do các hệ phần mềm lớn là phức tạp nên ngƣời ta thƣờng dùng các cách tiếp cận
khác nhau trong việc thiết kế các phần khác nhau của một hệ thống. Chẳng có một
cách tiếp cận nào tốt nhất chung cho các dự án. Hai cách tiếp cận thiết kế hiện đang
đƣợc dùng rộng rãi trong việc phát triển phần mềm đó là cách tiếp cận theo hƣớng
chức năng và hƣớng đối tƣợng. Mỗi cách tiếp cận đều có ƣu và nhƣợc điểm riêng
phụ thuộc vào ứng dụng phát triển và nhóm phát triển phần mềm. Chúng bổ sung và
hỗ trợ cho nhau chứ không đối kháng nhau.
Có một số chiến lƣợc hiện đại để thiết kế phần mềm nhƣ thiết kế phần mềm theo
hƣớng mô hình,hƣớng dữ liệu, hƣớng trách nhiệm, hƣớng kiểm thử, hƣớng hành vi,
hƣớng lĩnh vực. Mỗi hƣớng có những đặc thù riêng và có những lợi thế riêng, trong
đó hƣớng lĩnh vực là trọng tâm nghiên cứu của luận văn.
35
Chƣơng 2
Chiến lƣợc thiết kế phần mềm hƣớng lĩnh vực
2.1. Cách tiếp cận hƣớng lĩnh vực trong tiến trình phát triển phần mềm
2.1.1. Khái niệm về thiết kế hƣớng lĩnh vực
Với cách tiếp cận truyền thống khi xây dựng một ứng dụng. Đầu tiên ta đọc
các yêu cầu đặc tả và tìm hiểu các chức năng, sau đó tiến hành chia nhỏ các công
việc. Trong phần lớn trƣờng hợp, việc này nhằm mục đích ƣớc lƣợng thời gian và
lên kế hoạch thực hiện cho các công việc. Vậy trình tự công việc sẽ là ƣớc lƣợng
thời gian, chia việc cho các thành viên trong team, thiết kế CSDL, cuối cùng là bắt
tay và code. Đây là cách thiết kế hƣớng dữ liệu hay còn gọi là Data Driven Design
[1].
Vậy vấn đề với cách tiếp cận là gì? Lâu nay ta vẫn tiếp cận theo cách này và
vẫn làm tốt ? Câu trả lời là Đúng và Sai. Đúng ở chỗ ta vẫn làm tốt trong việc bàn
giao Project, Sai ở chỗ ta chƣa thực hiện tốt trong việc bảo trì và mở rộng project.
Trong các ứng dụng điển hình có rất nhiều phần code xử lý các công việc
không liên quan đến Logic nghiệp vụ nhƣ truy cập file, mạng hay database, các
thành phần này thƣờng đƣợc gọi là plumping code (điền code) và đƣợc nhúng trực
tiếp vào trong Business Object và nhiều Business Logic cũng đƣợc nhúng vào thao
tác của giao diện Widget hay script của database, điều này thƣờng xảy ra vì nó làm
ta phát triển ứng dụng một cách nhanh chóng và dễ dàng. Việc này dẫn đến phần
lớn thời gian phát triển của Deverloper là dành cho việc viết các plumping code
thay vì viết Business Logic thực sự, nó làm cho thiết kế của ta bị mất đi tính hƣớng
đối tƣợng trong thực tế.
Ngoài ra khi logic nghiệp vụ trộn lẫn với lớp khác khiến cho việc đọc hiểu và
suy nghĩ về logic của ứng dụng trở nên khó khăn hơn đối với những ngƣời ngoài.
Chỉ một thay đổi nhỏ ở tầng UI (User interface)cũng có thể dẫn tới việc thay đổi
tầng logic và ngƣợc lại khi thay đổi một business rule của ứng dụng đòi hỏi ta phải
36
quan tâm đến từng chi tiết nhỏ phía UI cũng nhƣ database để đáp ứng đƣợc sự thay
đổi này.
Trong những ứng dụng nhỏ thì vấn đề này ta không nhìn thấy. Ở các ứng
dụng cỡ vừa thì thấy vấn đề này đã tồn tại và bắt đầu dẫn đến tình trạng phá vỡ các
thiết kế chuẩn. Đối với các ứng dụng lớn thì nó trở thành vấn đề nghiêm trọng, cách
tiếp cận trên sẽ không thể cho ta đƣa ra một thiết kế hƣớng đối tƣợng chính xác.
Giải pháp ở đây chính là Domain Driven Design.
Vậy DDD là gì ? DDD không liên quan gì đến công nghệ hay framework là
những thứ thuộc về tầng vật lý mà nó là một khái niệm thuộc về tầng logic khi ta
xây dựng một hệ thống phần mềm. Cụ thể hơn nó là mẫu thiết kế (design pattern) và
hơn nữa đây là design pattern ở cấp độ kiến trúc của hệ thống, ta cần phân biệt rõ
điều này để phân biệt các design pattern và ở cấp độ class. Nó cung cấp một cấu
trúc thực hành và các thuật ngữ cho việc ra quyết định thiết kế nhằm tập trung và
tăng tốc các dự án phần mềm trong các lĩnh vực phức tạp.
2.1.2.Tìm hiểu về lĩnh vực
Để tạo một phần mềm tốt, cần hiểu về phần mềm đó. Ta không thể làm ra hệ
thống phần mềm ngân hàng nếu trừ khi ta có hiểu biết tƣơng đối tốt về mảng ngân
hàng và những điều liên quan. Nghĩa là, để làm phần mềm tốt, ta cần hiểu lĩnh vực
ngân hàng. Liệu có thể làm đƣợc phần mềm ngân hàng phức tạp dù không có hiểu
biết nghiệp vụ tốt? Không thể. Không bao giờ. Ai hiểu về banking? Ngƣời thiết kế
phần mềm? Không. Ngƣời này chỉ tới ngân hàng để gửi tiền và rút tiền khi cần.
Ngƣời phân tích phần mềm? Cũng không hẳn. Anh ta chỉ biết phân tích một chủ đề
cụ thể khi anh ta có đầy đủ tất cả cấu phần. Lập trình viên? Vậy là ai? Nhân viên
ngân hàng, hiển nhiên. Hiểu nhất về hệ thống ngân hàng là những ngƣời ở trong đó,
những chuyên gia của họ. Họ hiểu mọi thứ chi tiết, cái haydở, mọi vấn đề có thể và
mọi quy định. Đây là nơi ta thƣờng xuất phát: Lĩnh vực (domain).
Giả sử cần xây dựng một hệ thống phần mềm quản lý bệnh viện. Rõ ràng là cần
phải làm việc với đội ngũ bác sĩ, y tá (chính là các chuyên gia trong lĩnh vực này -
domain expert) để xây dựng kiến thức về domain. Qua nói chuyện, trao đổi kiến
thức, đặt câu hỏi và trả lời. Cần hiểu rõ càng nhiều càng tốt về domain này. Bằng
37
cách đặt câu hỏi đúng, xử lý thông tin đúng cách, kỹ sƣ phần mềm và chuyên gia sẽ
dần vẽ ra một domain, một mô hình domain (domain model). Kỹ sƣ phần mềm, kết
hợp với domain expert cùng tạo nên một domain model và mô hình đó là nơi kiến
thức chuyên môn của cả hai bên đƣợc kết hợp và tổng hợp lại.
Hãy xem xét tiếp ví dụ sau. Giả sử ta đang tham gia thiết kế một tòa nhà.
Yêu cầu là:
+ Xây dựng trên một diện tích đất cố định
+ Tòa nhà cao 6 tầng
+ Mỗi tầng có 4 căn hộ
Vậy domain ở đây là gì? Là công trình xây dựng chăng? Cũng có thể. Nhƣng nếu
xem công trình xây dựng là domain, thì thể ta đang bỏ qua một vài chi tiết trong yêu
cầu. Công trình xây dựng đang thiết kế phải bao gồm thiết kế căn hộ cho ngƣời dân
sinh sống. Vậy thuật ngữ "công trình xây dựng" có thể khiến ta bỏ lỡ chi tiết, thay
vì đó ta có thể thu hẹp xuống thành "chung cư". Lúc này nếu nói với các kỹ sƣ về
việc thiết kế, rõ ràng thuật ngữ "chung cư" sẽ dễ hiểu hơn là "công trình xây dựng"
đơn thuần. Ta thấy đấy, chỉ một thay đổi nhỏ trong ngôn từ cũng có thể tạo nên sự
khác biệt. Trở lại ví dụ phần mềm bệnh viện ở trên, ngƣời thiết kế phần mềm và các
bác sĩ, y tá không thể nói cùng một ngôn ngữ đƣợc. Họ nói về từ ngữ chuyên môn,
ngƣời thiết kế phần mềm nói bằng đối tƣợng, phƣơng thức, quan hệ. Đó chính là lúc
ta cần một ngôn ngữ chung để cả hai bên có thể làm việc với nhau dễ dàng hơn.
38
2.1.3.Ngôn ngữ chung
Hình 2- 1. Mô hình ngôn ngữ chung
Ta đã thấy sự cần thiết không thể phủ nhận của việc phát triển mô hình
cho domain qua sự làm việc giữa chuyên gia phần mềm và chuyên gia domain; tuy
nhiên, cách làm này ban đầu thƣờng gặp những khó khăn về rào cản giao tiếp cơ
bản. Lập trình viên chỉ nghĩ tới lớp, method, thuật toán, pattern và có khuynh hƣớng
diễn tả mọi thứ đời thƣờng bằng những tạotác lập trình. Họ muốn nhìn lớp đối
tƣợng và tạo quan hệ mô hình giữa chúng. Họ nghĩ đến những thứ nhƣ kế thừa, đa
hình, OOP... Và họ luôn nói theo cách đó. Điều này là dễ hiểu với lập trình viên.
Lập trình viên vẫn chỉ là lập trình viên. Tuy vậy, chuyên gia domain thƣờng không
hiểu những khái niệm đó. Họ không có khái niệm gì về thƣ viện, framework phần
mềm và trong nhiều trƣờng hợp, thậm chí họ không hiểu về cơ sở dữ liệu. Tất cả
những gì họ biết là chuyên ngành cụ thể của họ.
Ví dụ: Trong theo dõi không lƣu, chuyên gia domain biết về máy bay, route,
cao độ, vĩ độ, kinh độ,độ lệch của route chuẩn, về quỹ đạo của máy bay. Họ nói về
những điều này bằng ngôn ngữ riêng của họ, đôi khi gây khó hiểu với ngƣời ngoài
ngành. Để vƣợt qua sự khác nhau về cách giao tiếp, ta xây dựng mô hình, ta phải
trao đổi, giao tiếp ý tƣởng về mô hình, về những thành phần liên quan đến mô hình,
cách ta liên kết chúng, chúng có liên quan với nhau hay không. Giao tiếp ở mức độ
39
này là tối quan trọng cho sự thành công của dự án. Nếu ai đó nói điều gì đó và
ngƣời khác không hiểu, hay tệ hơn, hiểu sai, thì liệu ta có cơ hội tiếp tục dự án
không?
Dự án sẽ gặp vấn đề nghiêm trọng nếu thành viên nhóm không chia chung
ngôn ngữ khi trao đổivề domain. Chuyên gia domain dùng từ lóng của riêng họ
trong khi thành viên kỹ thuật lại dùng ngôn ngữ riêng của họ để trao đổi về những
thuật ngữ của domain trong thiết kế. Bộ thuật ngữ trong trao đổi hành ngày tách
riêng với bộ thuật ngữ nhúng trong mã nguồn (là sản phẩm quan trọng cuối cùng
của dự ...