Bài 2: Phân tích thiết kế hướng đối tượng UML

BÀI 2: KHẢO SÁT HỆ THỐNG
Xác định các yêu cầu hệ thống, mô hình hoá trường hợp sử dụng, phân tích các actor 
và các use case, tạo các biểu đồ và các luồng sự kiện
Mục tiêu:
-  Giải thích thế nào là use case, actor
-  Mô tả quá trình khảo sát hệ thống
-  Mô tả mục đích của việc phát biểu vấn đề.
-  Minh họa các use case và actor trong các mô hình use sử dụng ký pháp UML
-  Giải thích việc phát sinh luồng các sự kiện từ một use case.
Nội dung:
I. Giới thiệu UML. 
1- Mô hình hóa hệ thống phần mềm:
     Như đã trình bày ở  phần trước, mục tiêu của giai đoạn phân tích hệ  thống là sản xuất ra một
mô  hình  tổng  thể  của  hệ  thống  cần  xây  dựng.  Mô  hình  này  cần  phải  được  trình  bày  theo
hướng nhìn (View) của khách hàng hay người sử  dụng và làm sao để  họ  hiểu được. Mô hình
này cũng có thể  được sử  dụng để  xác định các yêu cầu của người dùng đối với hệ  thống và
qua đó giúp chúng ta đánh giá tính khả thi của dự án.
     Tầm quan trọng của mô hình đã  được lĩnh hội một cách thấu đáo trong hầu như tất cả  các
ngành khoa học kỹ  thuật từ  nhiều thế  kỷ  nay. Bất kỳ  ở  đâu, khi muốn xây dựng một vật thể
nào đó, đầu tiên người ta đã tạo nên các bản vẽ  để  quyết định cả  ngoại hình lẫn phương thức
hoạt  động  của  nó.  Chẳng  hạn  các  bản  vẽ  kỹ  thuật  thường  gặp  là  một  dạng  mô  hình  quen
thuộc. Mô hình nhìn chung là một cách mô tả  của một vật thể  nào đó. Vật đó có thể  tồn tại
trong một số  giai đoạn nhất định, dù đó là giai đoạn thiết kế  hay giai đoạn xây dựng hoặc chỉ
là một  kế  hoạch. Nhà thiết kế  cần phải tạo ra các mô hình mô tả  tất cả  các khía cạnh khác
nhau của sản phẩm. Ngoài ra, một mô hình có thể  được chia thành nhiều hướng nhìn, mỗi
hướng nhìn trong số  chúng sẽ  mô tả  một khía cạnh riêng biệt của sản phẩm hay hệ  thống cần
được xây dựng. Một mô hình cũng có thể  được xây dựng trong nhiều giai đoạn và ở mỗi giai
đoạn, mô hình sẽ được bổ sung thêm một số chi tiết nhất định.
    Mô hình thường được mô tả trong ngôn ngữ trực quan, điều đó có nghĩa là đa phần các thông
tin được thể  hiện bằng các ký hiệu đồ  họa và các kết nối giữa chúng, chỉ  khi cần thiết một số
thông tin mới được biểu diễn  ở  dạng văn bản; Theo đúng như câu ngạn ngữ  "Một bức tranh
nói nhiều hơn cả  ngàn từ". Tạo mô hình cho các hệ  thống phần mềm trước khi thực sự  xây
dựng nên chúng, đã trở  thành một chuẩn mực trong việc phát triển phần mềm và được chấp
nhận trong cộng đồng làm phần mềm giống như trong bất kỳ  một ngành khoa học kỹ  thuật
nào khác. Việc biểu diễn mô hình phải thoã mãn các yếu tố sau:
  • Chính xác (accurate): Mô tả đúng hệ thống cần xây dựng.
  • Đồng nhất (consistent): Các view khác nhau không được mâu thuẩn với  nhau.
  • Có thể  hiểu được (understandable): Cho những người xây dựng lẫn sử dụng
  • Dễ thay đổi (changeable)
  • Dễ dàng liên lạc với các mô hình khác.
     Có thể  nói  thêm rằng mô hình là một sự  đơn giản hoá hiện thực. Mô hình được xây dựng nên
để  chúng ta dễ  dàng hiểu và hiểu tốt hơn hệ  thống cần xây dựng. Tạo mô hình sẽ  giúp cho
chúng ta hiểu thấu đáo một hệ thống phức tạp trong sự toàn thể của nó.
Nói tóm lại, mô hình hóa một hệ thống nhằm mục đích:
  • Hình dung một hệ  thống theo thực tế  hay theo mong muốn của chúng ta.
  • Chỉ rõ cấu trúc hoặc ứng xử của hệ thống.
  • Tạo một khuôn mẫu hướng dẫn nhà phát triển trong suốt quá trình xây dựng hệ thống.
  • Ghi lại các quyết định của nhà phát triển để sử dụng sau này.
2- Trước khi UML ra đời:
     Đầu những năm 1980, ngành công nghệ  phần mềm chỉ  có duy nhất một ngôn ngữ  hướng đối
tượng  là  Simula.  Sang  nửa  sau  của  thập  kỷ  1980,  các  ngôn  ngữ  hướng  đối  tượng  như
Smalltalk và C++ xuất hiện. Cùng với chúng, nảy sinh nhu cầu mô hình hoá các hệ  thống
phần mềm theo hướng đối tượng. Và một vài trong số những ngôn ngữ mô hình hoá xuất hiện
những năm đầu thập kỷ 90 được nhiều người dùng là:
  • Grady Booch’s Booch Modeling Methodology
  • James Rambaugh’s Object Modeling Technique – OMT
  • Ivar Jacobson’s OOSE Methodology
  • Hewlett- Packard’s Fusion
  • Coad and Yordon’s OOA and OOD
    Mỗi phương pháp luận và ngôn ngữ  trên đều có hệ  thống ký hiệu riêng, phương pháp xử  lý
riêng và công cụ  hỗ  trợ  riêng, khiến nảy ra cuộc tranh luận phương pháp nào là tốt nhất. Đây
là  cuộc  tranh  luận  khó  có  câu  trả  lời,  bởi  tất  cả  các  phương  pháp  trên  đều  có  những  điểm
mạnh và điểm yếu riêng. Vì thế, các nhà phát triển phần mềm nhiều kinh nghiệm thường sử
dụng phối hợp các điểm mạnh của mỗi phương pháp cho  ứng dụng của mình. Trong thực tế,
sự  khác biệt giữa các phương pháp đó hầu như không đáng kể  và theo cùng tiến trình thời
gian, tất cả những phương pháp trên đã tiệm cận lại và bổ sung lẫn cho nhau. Chính hiện thực
này đã được những người tiên phong trong lĩnh vực mô hình hoá hướng đối tượng nhận ra và
họ  quyết định ngồi lại cùng nhau để  tích hợp những điểm mạnh của mỗi phương pháp và đưa
ra một mô hình thống nhất cho lĩnh vực công nghệ phần mềm.
3- Sự ra đời của UML:
    Trong bối cảnh trên, người ta nhận thấy cần thiết phải cung cấp một phương pháp tiệm cận
được chuẩn hoá và thống nhất cho việc mô hình hoá hướng đối tượng. Yêu cầu cụ  thể  là đưa
ra một tập hợp chuẩn hoá các ký hiệu (Notation) và các biểu đồ  (Diagram) để  nắm bắt các
quyết định về mặt thiết kế một cách rõ ràng, rành mạch. Đã có ba công trình tiên phong nhắm
tới mục tiêu đó, chúng được thực hiện dưới sự  lãnh đạo của James Rumbaugh, Grady Booch
và Ivar Jacobson. Chính những cố gắng này dẫn đến kết quả là xây dựng được một Ngôn Ngữ
Mô Hình Hoá Thống Nhất (Unifield Modeling Language – UML).
UML là một ngôn ngữ  mô hình hoá thống nhất có phần chính bao gồm những ký hiệu hình
học, được các phương pháp hướng đối tượng sử  dụng để  thể  hiện và miêu tả  các thiết kế  của
một hệ  thống. Nó là một ngôn ngữ  để  đặc tả, trực quan hoá, xây dựng và làm sưu liệu cho
nhiều khía cạnh khác nhau của một hệ thống có nồng độ phần mềm cao. UML có thể được sử
dụng làm công cụ  giao tiếp giữa người dùng, nhà phân tích, nhà thiết kế  và nhà phát triển
phần mềm.
    Trong quá trình phát triển có nhiều công ty đã hỗ  trợ  và khuyến khích phát triển UML có thể
kể tới như: Hewlett Packard, Microsoft, Oracle, IBM, Unisys.
4- UML (Unifield Modeling Language):
    Ngôn ngữ mô hình hóa thống nhất (Unifield Modeling Language – UML) là một ngôn ngữ để
biểu diễn mô hình theo hướng đối tượng được xây dựng bởi ba tác giả trên với chủ đích là:
  • Mô hình hoá các hệ thống sử dụng các khái niệm hướng đối tượng.
  • Thiết lập một kết nối từ  nhận thức của con người đến các sự  kiện cần mô hình hoá.
  • Giải quyết vấn đề  về  mức độ  thừa kế  trong các hệ  thống phức tạp, có nhiều ràng buộc khác nhau.
  • Tạo một ngôn ngữ mô hình hoá có thể sử dụng được bởi người và máy.
5- Phương pháp và các ngôn ngữ mô hình hoá:
     Phương pháp hay phương thức (method) là một cách trực tiếp cấu trúc hoá sự  suy nghĩ và
hành động của con người. Phương pháp cho người sử dụng biết phải làm gì, làm như thế nào,
khi nào và tại sao (mục đích của hành động). Phương pháp chứa các mô hình (model), các mô
hình được dùng để  mô tả  những gì sử  dụng cho việc truyền đạt kết quả  trong quá trình sử
dụng phương pháp. Điểm khác nhau chính giữa một phương pháp và một ngôn ngữ  mô hình
hoá (modeling language) là ngôn ngữ  mô hình hoá không có một tiến trình (process) hay các
câu lệnh (instruction) mô tả những công việc người sử dụng cần làm.
Một mô hình được biểu diễn theo một ngôn ngữ  mô hình hoá. Ngôn ngữ  mô hình hoá bao
gồm các ký hiệu  –  những biểu tượng được dùng trong mô hình  –  và một tập các quy tắc chỉ
cách sử dụng chúng. Các quy tắc này bao gồm:
  • Syntactic (Cú pháp): cho biết hình dạng các biểu tượng và cách kết hợp chúng trong ngôn ngữ.
  • Semantic (Ngữ  nghĩa): cho biết ý nghĩa của mỗi biểu tượng, chúng được hiểu thế  nào  khi  nằm  trong  hoặc  không  nằm  trong  ngữ  cảnh  của  các  biểu  tượng khác.
  • Pragmatic:  định  nghĩa  ý  nghĩa  của  biểu  tượng  để  sao  cho  mục  đích  của  mô hình được thể hiện và mọi người có thể hiểu được.

II Khái niệm mô hình của UML.
     UML có thể  được sử  dụng trong nhiều giai đoạn, từ  phát triển, thiết kế  cho tới thực hiện và
bảo trì. Vì mục đích chính của ngôn ngữ này là dùng các biểu đồ hướng đối tượng để mô tả hệ
thống nên miền ứng dụng của UML bao gồm nhiều loại hệ thống khác nhau như:





  • Hệ  thống thống tin  (Information System): Cất giữ, lấy, biến đổi biểu diễn thông tin cho người sử  dụng. Xử  lý những khoảng dữ  liệu lớn có các quan hệ  phức tạp, mà chúng được lưu trữ  trong các cơ sở  dữ  liệu quan hệ  hay hướng đối tượng.
  • Hệ thống kỹ thuật (Technical System): Xử lý và điều khiển các thiết bị kỹ thuật  như  viễn  thông,  hệ  thống  quân  sự,  hay  các  quá  trình  công  nghiệp. Đây là loại thiết bị  phải xử  lý các giao tiếp đặc biệt, không có phần mềm chuẩn và thường là các hệ thống thời gian thực (real time).
  • Hệ  thống nhúng  (Embeded System): Thực hiện trên phần cứng  gắn vào các thiết bị  như điện thoại di động, điều khiển xe hơi, …  Điều này được thực hiện bằng việc lập trình mức thấp với hỗ  trợ thời gian thực. Những hệthống này thường không có các thiết bị như màn hình đĩa cứng, …
  • Hệ  thống phân bố  ( Distributed System): Được phân bố  trên một số  máy cho phép truyền dữ  liệu từ  nơi này đến nơi khác một cách dễ  dàng. Chúng đòi hỏi các cơ chế  liên lạc đồng bộ  để  đảm bảo toàn vẹn dữ  liệu và thường được  xây  dựng  trên  một  số  các  kỹ  thuật  đối  tượng  như  CORBA, COM/DCOM, hay Java Beans/RMI.
  • Hệ  thống Giao dịch  (Business System): Mô tả  mục đích,  tài nguyên (con người,  máy  tính,  …),  các  quy  tắc  (luật  pháp,  chiến  thuật  kinh  doanh,  cơ chế, …), và công việc hoạt động kinh doanh.
  • Phần  mềm  hệ  thống  (System  Software):  Định  nghĩa  cơ  sở  hạ  tầng  kỹthuật cho phần mềm khác sử  dụng, chẳng hạn như hệ  điều hành, cơ sở  dữ liệu, giao diện người sử dụng. UML và các giai đoạn phát triển hệ thống
  • Preliminary Investigation: use cases thể  hiện các yêu cầu của người dùng. Phần miêu tả use case xác định các yêu cầu, phần diagram thể hiện mối quan hệ và giao tiếp với hệ thống. 
  • Analysis: Mục đích chính của giai đọan này là trừu tượng hóa và tìm hiểu các cơ cấu có trong phạm vi bài toán. Class diagrams trên bình diện trừu tượng hóa các thực thể  ngoài đời thực được sử  dụng để  làm rõ sự  tồn tại cũng như mối quan hệcủa chúng. Chỉ những lớp (class) nằm trong phạm vi bài toán mới đáng quan tâm. 
  • Design: Kết quả  phần analysis được phát triển thành giải pháp kỹ  thuật. Các lớp được mô hình hóa chi tiết để  cung cấp hạ  tầng kỹ  thuật như giao diện, nền tảng cho database, … Kết quả phần Design là các đặc tả chi tiết cho giai đoạn xây dựng phần mềm. 
  • Development: Mô hình Design được chuyển thành code. Programmer sử dụng các UML diagrams trong giai đoạn Design để hiểu vấn đề và tạo code.
  • Testing: Sử  dụng các UML diagrams trong các giai đoạn trước. Có 4 hình thức kiểm tra hệ thống: 
     o  Unit testing  (class diagrams & class specifications): kiểm tra từng đơn
thể, được dùng để kiểm tra các lớp hay các nhóm đơn thể.
     o  Integration  testing  (integration  diagrams  &  collaboration  diagrams):
kiểm tra tích hợp là kiểm tra kết hợp các component với các lớp để xem
chúng hoạt động với nhau có đúng không.
     o  System testing  (use-case diagrams): kiềm tra xem hệ  thống có đáp  ứng
được chức năng mà người sử dụng yêu cầu hay không.
     o  Acceptance testing: Kiểm tra tính chấp nhận được của hệ thống, thường
được thực hiện bởi khách hàng, việc kiểm tra này thực hiện tương tự
như kiểm tra hệ thống.
III. Khả năng sử dụng UML.
1- UML và các giai đoạn của chu trình phát triển phần 
1.1- Giai đoạn nghiên cứu sơ bộ: 
    UML đưa ra khái niệm  Use Case  để  nắm bắt các yêu cầu của khách hàng (người sử  dụng).
UML sử dụng biểu đồ Use case (Use Case Diagram) để nêu bật mối quan hệ cũng như sự giao
tiếp với hệ thống.
    Qua phương pháp mô hình hóa Use case, các tác nhân (Actor) bên ngoài quan tâm  đến hệ
thống sẽ  được mô hình hóa song song với chức năng mà họ  đòi hỏi từ  phía hệ  thống (tức là
Use case). Các tác nhân và các Use case được mô hình hóa cùng các mối quan hệ  và được
miêu tả  trong biểu đồ  Use case của UML. Mỗi một Use case được mô tả  trong  tài liệu, và nó
sẽ  đặc tả  các yêu cầu của khách hàng: Anh ta hay chị  ta chờ  đợi điều gì  ở  phía hệ  thống mà
không hề để ý đến việc chức năng này sẽ được thực thi ra sao.
1.2- Giai đoạn phân tích: 
    Giai đoạn phân tích quan tâm đến quá trình trừu tượng hóa đầu tiên (các lớp và các đối tượng)
cũng như cơ chế  hiện hữu trong phạm vi vấn đề. Sau khi nhà phân tích đã nhận biết được các
lớp thành phần của mô hình cũng như mối quan hệ giữa chúng với nhau, các lớp cùng các mối
quan hệ  đó sẽ  được miêu tả  bằng công cụ  biểu đồ  lớp (class diagram) của UML. Sự  cộng tác
giữa các lớp nhằm thực hiện các Use case cũng sẽ  được miêu tả  nhờ  vào các mô hình động
(dynamic models) của UML. Trong giai đoạn phân tích, chỉ  duy nhất các lớp có tồn tại trong
phạm vi vấn đề (các khái niệm đời thực) là được mô hình hóa. Các lớp kỹ thuật định nghĩa chi
tiết  cũng  như  giải  pháp  trong  hệ  thống  phần  mềm,  ví  dụ  như  các  lớp  cho  giao  diện  người
dùng, cho ngân hàng dữ  liệu, cho sự  giao tiếp, trùng hợp, v.v..., chưa phải là mối quan tâm
của giai đoạn này.
1.3- Giai đoạn thiết kế: 
    Trong giai đoạn này, kết quả của giai đoạn phân tích sẽ được mở rộng thành một giải pháp kỹ
thuật. Các lớp mới sẽ  được bổ  sung để  tạo thành một hạ  tầng cơ sở  kỹ  thuật: Giao diện người
dùng, các chức năng để  lưu trữ  các đối  tượng trong ngân hàng dữ  liệu, giao tiếp với các hệ
thống khác, giao diện với các thiết bị  ngoại vi và các máy móc khác trong hệ  thống,.... Các
lớp thuộc phạm vi vấn đề  có từ  giai đoạn phân tích sẽ  được "nhúng" vào hạ  tầng cơ sở  kỹ
thuật này, tạo ra khả  năng thay đổi trong cả  hai phương diện: Phạm vi vấn đề  và hạ  tầng cơ
sở. Giai đoạn thiết kế sẽ đưa ra kết quả là bản đặc tả chi tiết cho giai đoạn xây dựng hệ thống.
1.4- Giai đoạn xây dựng: 
    Trong giai đoạn xây dựng (giai đoạn lập trình), các lớp của giai đoạn thiết kế  sẽ  được biến
thành những dòng code cụ  thể  trong một ngôn ngữ  lập trình hướng đối tượng cụ  thể  (không
nên dùng một ngôn ngữ  lập trình hướng chức năng!). Phụ  thuộc vào khả  năng của ngôn ngữ
được sử  dụng, đây có thể  là một công việc khó khăn hay  dễ  dàng. Khi tạo ra các mô hình
phân tích và thiết kế  trong UML, tốt nhất nên cố  gắng né tránh việc ngay lập tức biến đổi các
mô hình này thành các dòng code. Trong những giai đoạn trước, mô hình được sử dụng để dễ
hiểu, dễ  giao tiếp và tạo nên cấu trúc của hệ  thống; vì vậy, vội vàng đưa ra những kết luận về
việc viết code có thể sẽ thành một trở ngại cho việc tạo ra các mô hình chính xác và đơn giản.
Giai đoạn xây dựng là một giai đoạn riêng biệt, nơi các mô hình được chuyển thành code.
1.5- Thử nghiệm:
    Như  đã  trình  bày  trong  phần  Chu  Trình  Phát  Triển  Phần  Mềm,  một  hệ  thống  phần  mềm
thường được thử  nghiệm qua nhiều giai đoạn và với nhiều nhóm thử  nghiệm khác nhau. Các
nhóm sử  dụng nhiều loại biểu đồ  UML khác nhau làm nền tảng cho công việc của mình: Thử
nghiệm đơn vị sử dụng biểu đồ lớp (class diagram) và đặc tả lớp, thử nghiệm tích hợp thường
sử  dụng  biểu  đồ  thành  phần  (component  diagram)  và  biểu  đồ  cộng  tác  (collaboration
diagram), và giai đoạn thử  nghiệm hệ  thống sử  dụng biểu đồ  Use case (use case diagram) để
đảm bảo hệ  thống có phương thức hoạt động đúng như đã được định nghĩa từ  ban đầu trong
các biểu đồ này.
2- Các thành phần của ngôn ngữ UML
    Ngôn ngữ  UML bao gồm một loạt các phần tử  đồ  họa (graphic element) có thể  được kếp hợp
với nhau để tạo ra các biểu đồ. Bởi đây là một ngôn ngữ, nên UML cũng có các nguyên tắc để
kết hợp các phần tử đó.
Một số những thành phần chủ yếu của ngôn ngữ UML:
  • Hướng nhìn (view):  Hướng nhìn chỉ  ra những khía cạnh khác nhau của hệ thống cần phải được mô hình hóa. Một hướng nhìn không phải là một bản vẽ, mà là một sự  trừu tượng hóa bao gồm một loạt các biểu đồ  khác nhau. Chỉ  qua  việc  định  nghĩa  của  một  loạt  các  hướng  nhìn  khác  nhau,  mỗi hướng nhìn chỉ  ra một khía cạnh riêng biệt của hệ  thống, người ta mới có thể  tạo dựng nên một bức tranh hoàn thiện về  hệ  thống. Cũng  chính các hướng nhìn này nối kết ngôn ngữ mô hình hóa với quy trình được chọn cho giai đoạn phát triển.


  • Biểu  đồ  (diagram):  Biểu  đồ  là  các  hình  vẽ  miêu  tả  nội  dung  trong  một hướng nhìn. UML có tất cả  9 loại biểu đồ  khác nhau được sử  dụng trong những sự  kết hợp khác nhau để  cung cấp tất cả  các hướng nhìn của một hệ thống.
  • Phần tử mô hình hóa (model element): Các khái niệm được sử dụng trong các biểu đồ được gọi là các phần tử mô hình, thể hiện các khái niệm hướng đối tượng quen thuộc. Ví dụ  như lớp, đối tượng, thông điệp cũng như các quan hệ  giữa các khái niệm này, bao gồm cả  liên kết, phụ  thuộc, khái quát hóa. Một phần tử  mô hình thường được sử  dụng trong nhiều biểu đồ  khác nhau, nhưng nó luôn luôn có chỉ một ý nghĩa và một kí hiệu.
  • Cơ chế  chung:  Cơ chế  chung cung cấp thêm những lời nhận xét bổ  sung, các  thông  tin  cũng  như  các  quy  tắc  ngữ  pháp  chung  về  một  phần  tử  mô hình; chúng còn  cung cấp thêm các  cơ chế  để  có thể  mở  rộng ngôn ngữ UML cho phù hợp với một phương pháp  xác định (một quy trình, một tổ chức hoặc một người dùng).
3- Hướng nhìn (View)
    Mô hình hóa một hệ  thống phức tạp là một việc làm khó khăn. Lý tưởng nhất là toàn bộ  hệ
thống được miêu tả chỉ trong một bản vẽ, một bản vẽ định nghĩa một cách rõ ràng và mạch lạc
toàn bộ  hệ  thống, một bản vẽ  ngoài ra lại còn dễ  giao tiếp và dễ  hiểu. Mặc dù vậy, thường thì
đây là chuyện bất khả thi. Một bản vẽ không thể nắm bắt tất cả các thông tin cần thiết để miêu
tả  một hệ  thống. Một hệ  thống cần phải được miêu tả  với một loạt các khía cạnh khác nhau:
     Về  mặt chức năng (cấu trúc tĩnh của nó cũng như các tương tác động), về  mặt phi chức năng
(yêu cầu về  thời gian, về  độ  đáng tin cậy, về  quá trình thực thi, v.v. và v.v.) cũng như về  khía
cạnh  tổ  chức  (tổ  chức  làm  việc,  ánh  xạ  nó  vào  các  code  module,...).  Vì  vậy  một  hệ  thống
thường được miêu tả  trong một loạt các hướng nhìn khác nhau, mỗi hướng nhìn sẽ  thể  hiện
một bức ảnh ánh xạ của toàn bộ hệ thống và chỉ ra một khía cạnh riêng của hệ thống.

Hình 2.1- Các View trong UML
     Mỗi một hướng nhìn được miêu tả  trong một loạt các biểu đồ, chứa đựng các thông tin nêu
bật khía cạnh đặc biệt đó của hệ thống. Trong thực tế khi phân tích và thiết kế rất dễ xảy ra sự
trùng lặp thông tin, cho nên một biểu đồ  trên thật tế  có thể  là thành phần của nhiều hướng
nhìn khác nhau. Khi nhìn hệ  thống từ  nhiều hướng nhìn khác nhau, tại một thời điểm có thể
người ta chỉ  tập trung vào một khía cạnh của hệ  thống. Một biểu đồ trong một hướng nhìn cụ
thể  nào đó cần phải đủ  độ  đơn giản để  tạo điều kiện giao tiếp dễ  dàng, để  dính liền với các
biểu đồ  khác cũng như các hướng nhìn khác, làm sao cho bức tranh toàn cảnh của hệ  thống
được miêu tả  bằng sự  kết hợp tất cả  các thông tin từ  tất cả  các hướng nhìn. Một biểu đồ  chứa
các kí hiệu hình học mô tả  các phần tử  mô hình của hệ  thống. UML có tất cả  các hướng nhìn 
sau:
  • Hướng nhìn Use case (use case view): đây là hướng nhìn chỉ  ra khía cạnh chức năng của một hệ thống, nhìn từ hướng tác nhân bên ngoài.
  • Hướng  nhìn  logic  (logical  view):  chỉ  ra  chức  năng  sẽ  được  thiết  kế  bên trong hệ  thống như thế  nào, qua các khái niệm về  cấu trúc tĩnh cũng như ứng xử động của hệ thống.
  • Hướng  nhìn  thành  phần  (component  view):  chỉ  ra  khía  cạnh  tổ  chức  của các thành phần code.
  • Hướng  nhìn  song  song  (concurrency  view):  chỉ  ra  sự  tồn  tại  song  song/ trùng hợp trong hệ thống, hướng đến vấn đề giao tiếp và đồng bộ hóa trong hệ thống.
  • Hướng nhìn triển khai (deployment view): chỉ  ra khía cạnh triển khai hệ thống vào các kiến trúc vật lý (các máy tính hay trang thiết bị  được coi là trạm công tác). 
    Khi bạn chọn công cụ  để  vẽ  biểu đồ, hãy chọn công cụ  nào tạo điều kiện dễ  dàng chuyển từ
hướng nhìn này sang hướng nhìn khác. Ngoài ra, cho mục đích quan sát  một chức năng sẽ
được thiết kế  như thế  nào, công cụ  này cũng phải tạo điều kiện dễ  dàng cho bạn chuyển sang
hướng nhìn Use case (để xem chức năng này được miêu tả như thế nào từ phía tác nhân), hoặc
chuyển sang hướng nhìn triển khai (để  xem chức năng này sẽ  được phân bố  ra sao trong cấu
trúc vật lý - Nói một cách khác là nó có thể nằm trong máy tính nào).
    Ngoài các hướng nhìn kể  trên, ngành công nghiệp phần mềm còn sử  dụng cả  các hướng nhìn
khác, ví dụ hướng nhìn tĩnh-động, hướng nhìn logic-vật lý, quy trình nghiệp vụ (workflow) và
các hướng nhìn khác. UML không yêu cầu chúng ta phải sử  dụng các hướng nhìn này, nhưng
đây cũng chính là những hướng nhìn mà các nhà thiết kế  của UML đã nghĩ tới, nên có khả
năng nhiều công cụ sẽ dựa trên các hướng nhìn đó.
3.1- Hướng nhìn Use case (Use case View): 
     Hướng nhìn Use case miêu tả  chức năng của hệ  thống sẽ  phải cung cấp do được tác nhân từ
bên ngoài mong đợi. Tác nhân là thực thể  tương tác với hệ  thống; đó có thể  là một người sử
dụng hoặc là một hệ  thống khác. Hướng nhìn Use case là hướng nhìn dành cho khách hàng,
nhà thiết kế, nhà phát triển và người thử  nghiệm; nó được miêu tả  qua các biểu đồ  Use case (use case diagram) và thỉnh thoảng cũng bao gồm cả các biểu đồ hoạt động (activity diagram).
    Cách sử  dụng hệ  thống nhìn chung sẽ  được miêu tả  qua một loạt các Use case trong hướng
nhìn Use case, nơi mỗi một Use case là một lời miêu tả  mang tính đặc thù cho một tính năng
của hệ thống (có nghĩa là một chức năng được mong đợi).
    Hướng nhìn Use case mang tính trung tâm, bởi nó đặt ra nội dung thúc đẩy sự  phát triển các
hướng  nhìn  khác.  Mục  tiêu  chung  của  hệ  thống  là  cung  cấp  các  chức  năng  miêu  tả  trong
hướng nhìn này  –  cùng  với một vài các thuộc tính mang tính phi chức  năng khác  –  vì thế
hướng nhìn này có ảnh hưởng đến tất cả  các hướng nhìn khác. Hướng nhìn này cũng được sử
dụng để  thẩm tra (verify) hệ  thống qua việc thử  nghiệm xem hướng nhìn Use case có đúng
với mong đợi của khách hàng (Hỏi: "Đây có phải là thứ bạn muốn") cũng như có đúng với hệ
thống vừa được hoàn thành (Hỏi: "Hệ thống có hoạt động như đã đặc tả?”).
3.2- Hướng nhìn logic (Logical View):
    Hướng nhìn logic miêu tả phương thức mà các chức năng của hệ thống sẽ được cung cấp. Chủ
yếu nó được sử  dụng cho các nhà thiết kế  và nhà phát triển. Ngược lại với hướng nhìn Use
case, hướng nhìn logic nhìn vào phía bên trong của hệ  thống. Nó miêu tả  kể  cả  cấu trúc tĩnh
(lớp, đối tượng, và quan hệ) cũng như sự tương tác động sẽ xảy ra khi các đối tượng gửi thông
điệp cho nhau để cung cấp chức năng đã định sẵn. Hướng nhìn logic định nghĩa các thuộc tính
như trường tồn (persistency) hoặc song song (concurrency), cũng như các giao diện cũng như
cấu trúc nội tại của các lớp.
    Cấu trúc tĩnh được miêu tả  bằng các biểu đồ  lớp (class diagram) và biểu đồ  đối tượng (object
diagram).  Quá  trình  mô  hình  hóa  động  được  miêu  tả  trong  các  biểu  đồ  trạng  thái  (state
diagram), biểu đồ  trình tự  (sequence diagram), biểu đồ  tương tác (collaboration diagram) và
biểu đồ hoạt động (activity diagram).
3.3- Hướng nhìn thành phần (Component View): 
    Là một lời miêu tả  của việc thực thi các modul cũng như sự  phụ  thuộc giữa chúng với nhau.
Nó thường được sử  dụng cho nhà phát triển và thường bao gồm nhiều biểu đồ  thành phần.
    Thành phần ở  đây là các modul lệnh thuộc nhiều loại khác nhau, sẽ  được chỉ  ra trong biểu đồ
cùng với cấu trúc cũng như sự phụ thuộc của chúng. Các thông tin bổ sung về các thành phần,
ví dụ  như vị trí của tài nguyên (trách nhiệm đối với một thành phần), hoặc các thông tin quản
trị  khác, ví dụ như một bản báo cáo về  tiến trình của công việc cũng có thể  được bổ  sung vào
đây.
3.4- Hướng nhìn song song (Concurrency View): 
    Hướng nhìn song song nhắm tới sự chia hệ thống thành các qui trình (process) và các bộ xử lý
(processor).  Khía  cạnh  này,  vốn  là  một  thuộc  tính  phi  chức  năng  của  hệ  thống,  cho  phép
chúng ta sử dụng một cách hữu hiệu các nguồn tài nguyên, thực thi song song, cũng như xử lý
các sự kiện không đồng bộ từ môi trường. Bên cạnh việc chia hệ thống thành các tiểu trình có thể được thực thi song song, hướng nhìn này cũng phải quan tâm đến vấn đề giao tiếp và đồng
bộ hóa các tiểu trình đó.
    Hướng nhìn song song giành cho nhà phát triển và người tích hợp hệ  thống, nó bao gồm các
biểu đồ  động (trạng thái, trình tự, tương tác và hoạt động) cùng các biểu đồ  thực thi (biểu đồ
thành phần và biểu đồ triển khai).
3.5- Hướng nhìn triển khai (Deployment View):
    Cuối cùng, hướng nhìn triển khai chỉ cho chúng ta sơ đồ triển khai về mặt vật lý của hệ thống,
ví dụ  như các máy tính cũng như các máy móc và sự  liên kết giữa chúng với nhau. Hướng
nhìn triển khai giành cho các nhà phát triển, người tích hợp cũng như người thử  nghiệm hệ
thống và được thể  hiện bằng các biểu đồ  triển khai. Hướng nhìn này cũng bao gồm sự  ánh xạ
các thành phần của hệ  thống vào cấu trúc vật lý; ví dụ  như chương trình nào hay đối tượng
nào sẽ được thực thi trên máy tính nào.
4- Biểu đồ (diagram)
    Biểu đồ  là các hình vẽ  bao gồm các ký hiệu phần tử  mô hình hóa được sắp xếp để  minh họa
một thành phần cụ  thể  hay một khía cạnh cụ  thể  của hệ  thống. Một mô hình hệ  thống thường
có nhiều loại biểu đồ, mỗi loại có nhiều biểu đồ  khác nhau. Một biểu đồ  là một thành phần
của  một  hướng  nhìn  cụ  thể;  và  khi  được  vẽ  ra, nó  thường  thường  cũng  được  xếp  vào  một
hướng nhìn. Mặt khác, một số  loại biểu đồ  có thể  là thành phần của nhiều hướng nhìn khác
nhau, tùy thuộc vào nội dung của biểu đồ.
    Phần sau miêu tả  các khái niệm căn bản nằm đằng sau mỗi loại biểu đồ. Tất cả  các chi tiết về
biểu đồ, ngữ  cảnh của chúng, ý nghĩa chính xác của chúng và sự  tương tác giữa chúng với
nhau được miêu tả  chi tiết trong các chương sau (mô hình đối tượng  –  mô hình động). Các
biểu đồ  lấy làm ví dụ  ở  đây được lấy ra từ  nhiều loại hệ  thống khác nhau để  chỉ  ra nét phong
phú và khả năng áp dụng rộng khắp của ULM.
4.1- Biểu đồ Use case (Use Case Diagram):
    Một biểu đồ  Use case chỉ  ra một số  lượng các tác nhân ngoại cảnh và mối liên kết của chúng
đối với Use case mà hệ  thống cung cấp (nhìn hình 3.2). Một Use case là một lời miêu tả  của
một chức năng mà hệ  thống cung cấp. Lời miêu tả  Use case thường là một văn bản tài liệu,
nhưng kèm theo đó cũng có thể  là một biểu đồ  hoạt động. Các Use case được miêu tả  duy
nhất theo hướng nhìn từ  ngoài vào của các tác nhân (hành vi của hệ  thống theo như sự  mong
đợi của người sử  dụng), không miêu tả  chức năng được cung cấp sẽ  hoạt động nội bộ  bên
trong  hệ  thống  ra  sao.  Các  Use  case  định  nghĩa  các  yêu  cầu  về  mặt  chức  năng  đối  với  hệ
thống. Các biểu đồ Use case sẽ được miêu tả chi tiết hơn trong bài sau (Use case).

Hình 2.2- Biểu đồ use case của một công ty bảo hiểm
4.2- Biểu đồ lớp (Class Diagram):
    Một biểu đồ lớp chỉ ra cấu trúc tĩnh của các lớp trong hệ thống (nhìn hình 3.3). Các lớp là đại
diện cho các “vật” được xử  lý trong hệ  thống. Các lớp có thể  quan hệ  với  nhau trong nhiều
dạng thức: liên kết (associated  -  được nối kết với nhau), phụ  thuộc (dependent  -  một lớp này
phụ  thuộc vào lớp khác), chuyên biệt hóa (specialized  -  một lớp này là một kết quả  chuyên
biệt hóa của lớp khác), hay đóng gói ( packaged -  hợp với nhau thành một đơn vị). Tất cả  các
mối quan hệ  đó đều được thể  hiện trong biểu đồ  lớp, đi kèm với cấu trúc bên trong của các
lớp theo khái niệm thuộc tính (attribute) và thủ  tục (operation). Biểu đồ  được coi là biểu đồ
tĩnh theo phương diện cấu trúc được miêu tả  ở  đây có hiệu lực tại bất kỳ  thời điểm nào trong
toàn bộ vòng đời hệ thống.
Một hệ  thống thường sẽ  có một loạt các biểu đồ  lớp  –  chẳng phải bao giờ  tất cả  các biểu đồ
lớp này cũng được nhập vào một biểu đồ  lớp tổng thể  duy nhất  –  và một lớp có thể  tham gia
vào nhiều biểu đồ lớp. Biểu đồ lớp được miêu tả chi tiết trong chương sau.
4.3- Biểu đồ đối tượng (Object Diagram):
    Một biểu đồ  đối tượng là một phiên bản của biểu đồ  lớp và thường cũng sử  dụng các ký hiệu 
như biểu đồ  lớp. Sự  khác biệt giữa hai loại biểu đồ  này nằm ở  chỗ  biểu đồ  đối tượng chỉ  ra 
một loạt các đối tượng thực thể  của lớp, thay vì các lớp. Một biểu đồ  đối tượng vì vậy là một 
ví dụ  của biểu đồ  lớp, chỉ  ra một bức tranh thực tế  có thể  xảy ra khi hệ  thống thực thi: bức 
tranh mà hệ  thống có thể  có tại một thời điểm nào đó. Biểu đồ  đối tượng sử  dụng chung các 
ký hiệu của biểu đồ  lớp,  chỉ  trừ  hai ngoại lệ: đối tượng được viết với tên được gạch dưới và 
tất cả các thực thể trong một mối quan hệ đều được chỉ ra (nhìn hình 3.4).
Biểu đồ  đối tượng không quan trọng bằng biểu đồ  lớp, chúng có thể  được sử  dụng để  ví dụ
hóa một biểu đồ lớp phức tạp, chỉ ra với những thực thể cụ thể và những mối quan hệ như thế
thì bức tranh toàn cảnh sẽ  ra sao. Một biểu đồ  đối tượng thường thường được sử  dụng làm 
một thành phần của một biểu đồ cộng tác (collaboration), chỉ ra lối ứng xử động giữa một loạt 
các đối tượng.
4.4- Biểu đồ trạng thái (State Diagram):
    Một biểu đồ  trạng thái thường là một sự  bổ  sung cho lời miêu tả một lớp. Nó chỉ  ra tất cả  các 
trạng thái mà đối tượng của lớp này có thể  có, và những sự  kiện (event) nào sẽ  gây ra sự  thay 
đổi trạng thái (hình 3.5). Một sự  kiện có thể  xảy ra khi một đối tượng tự  gửi thông điệp đến 
cho nó -  ví dụ  như để  thông báo rằng một khoảng thời gian được xác định đã qua đi  –  hay là 
một số  điều kiện nào đó đã được thỏa mãn. Một sự  thay đổi trạng thái được gọi là một sự
chuyển đổi trạng thái  (State Transition). Một chuyển đổi trạng thái cũng có thể  có một hành 
động liên quan, xác định điều gì phải được thực hiện khi sự chuyển đổi trạng thái này diễn ra. 
Biểu đồ  trạng thái không được vẽ  cho tất cả  các lớp, mà chỉ  riêng cho những lớp có một số
lượng các trạng thái được định nghĩa rõ ràng và hành vi của lớp bị ảnh hưởng và thay đổi qua 
các trạng thái khác nhau. Biểu đồ  trạng thái cũng có thể  được vẽ  cho hệ  thống tổng thể. Biểu 
đồ trạng thái được miêu tả chi tiết hơn trong chương sau (Mô hình động). 

2.5- Biểu đồ trình tự (Sequence Diagram):
    Một biểu đồ  trình tự  chỉ  ra một cộng tác động giữa một loạt các đối tượng (xem hình 3.6). 
Khía cạnh quan trọng của biểu đồ  này là chỉ  ra trình tự  các thông điệp (message) được gửi 
giữa các đối tượng. Nó cũng chỉ  ra trình tự  tương tác giữa các đối tượng, điều sẽ  xảy ra tại 
một thời điểm cụ  thể  nào đó trong trình tự  thực thi của hệ  thống. Các biểu đồ  trình tự  chứa 
một loạt các đối tượng được biểu diễn bằng các đường thẳng đứng. Trục thời gian có hướng 
từ  trên xuống dưới trong biểu đồ, và biểu đồ  chỉ  ra sự  trao đổi thông điệp giữa các đối tượng 
khi thời gian trôi qua. Các thông điệp được biểu diễn bằng các đường gạch ngang gắn liền với 
mũi tên (biểu thị  thông điệp) nối liền giữa những đường thẳng đứng thể  hiện đối tượng. Trục 
thời gian cùng những lời nhận xét khác thường sẽ được đưa vào phần lề của biểu đồ.
4.6- Biểu đồ cộng tác (Collaboration Diagram):
    Một  biểu  đồ  cộng  tác  chỉ  ra  một  sự  cộng  tác  động,  cũng  giống  như  một  biểu  đồ  trình  tự. 
    Thường người ta sẽ  chọn hoặc dùng biểu đồ  trình tự  hoặc dùng biểu đồ  cộng tác. Bên cạnh 
việc thể  hiện sự  trao đổi thông điệp (được gọi là  tương tác), biểu đồ  cộng tác chỉ  ra các đối 
tượng và quan hệ của chúng (nhiều khi được gọi là ngữ cảnh). Việc nên sử dụng biểu đồ trình 
tự  hay biểu đồ  cộng tác thường sẽ  được quyết định theo nguyên tắc chung sau: Nếu thời gian hay trình tự  là yếu tố  quan trọng nhất cần phải nhấn mạnh thì hãy chọn biểu đồ  trình tự; nếu 
ngữ cảnh là yếu tố quan trọng hơn, hãy chọn biểu đồ cộng tác. Trình tự tương tác giữa các đối 
tượng được thể hiện trong cả hai loại biểu đồ này.
    Biểu đồ  cộng tác được vẽ  theo dạng một biểu đồ  đối tượng, nơi một loạt các đối tượng được 
chỉ  ra cùng với mối quan hệ  giữa chúng với nhau (sử  dụng những ký hiệu như trong biểu đồ
lớp/ biểu đồ  đối tượng). Các mũi tên được vẽ  giữa các đối tượng để  chỉ  ra dòng chảy thông 
điệp giữa các đối tượng. Các thông điệp thường được đính kèm theo các nhãn (label), một 
trong những chức năng của nhãn là chỉ  ra thứ  tự  mà các thông điệp được gửi đi. Nó cũng có 
thể  chỉ  ra các điều kiện,  chỉ  ra những giá trị  được trả  về, v.v... Khi đã làm quen với cách viết 
nhãn, một nhà phát triển có thể  đọc biểu đồ  cộng tác và tuân thủ  theo dòng thực thi cũng như 
sự  trao  đổi  thông  điệp.  Một  biểu  đồ  cộng  tác  cũng  có  thể  chứa  cả  các  đối  tượng  tích  cực 
(active objects), hoạt động song song với các đối tượng tích cực khác (hình 3.7). Biểu đồ cộng 
tác được miêu tả chi tiết trong chương sau.
4.7- Biểu đồ hoạt động (Activity Diagram):
    Một biểu đồ  hoạt động chỉ  ra một trình tự  lần lượt của các hoạt động (activity) (hình 3.8). 
Biểu đồ  hoạt động thường được sử  dụng để  miêu tả  các hoạt động được thực hiện trong một 
thủ  tục, mặc dù nó cũng có thể  được sử  dụng để  miêu tả  các dòng chảy hoạt động khác, ví dụ
như trong một Use case hay trong một trình tự  tương tác. Biểu đồ  hoạt động bao gồm các 
trạng thái hành động, chứa đặc tả  của một hoạt động cần phải được thực hiện (một hành động 
-  action). Một trạng thái hành động sẽ  qua đi khi hành động được thực hiện xong (khác với 
biểu đồ  trạng thái: một trạng thái chỉ  chuyển sang trạng thái khác sau khi đã xảy ra một sự
kiện rõ ràng !). Dòng điều khiển  ở  đây chạy giữa các trạng thái hành động liên kết với nhau. 
Biểu đồ còn có thể chỉ ra các quyết định, các điều kiện, cũng như phần thực thi song song của 
các trạng thái hành động. Biểu đồ  ngoài ra còn có thể  chứa các loại đặc tả  cho các thông điệp 
được gửi đi hoặc được nhận về, trong tư cách là thành phần của hành động được thực hiện.
4.8- Biểu đồ thành phần (Component Diagram):
    Một biểu đồ  thành phần chỉ  ra cấu trúc vật lý của các dòng lệnh (code) theo khái niệm thành 
phần code. Một thành phần code có thể  là một tập tin source code, một thành phần nhị  phân 
(binary) hay một thành phần thực thi được (executable). Một thành phần chứa các thông tin về
các lớp logic hoặc các lớp mà nó thi hành, như thế  có nghĩa là nó tạo ra một ánh xạ  từ  hướng 
nhìn logic vào hướng nhìn thành phần. Biểu đồ  thành phần cũng chỉ  ra những sự  phụ  thuộc 
giữa các thành phần với nhau, trợ  giúp cho công việc phân tích hiệu  ứng mà một thành phần 
được thay đổi sẽ  gây ra đối với các thành phần khác. Thành phần cũng có thể  được miêu tả
với bất kỳ  loại giao diện nào mà chúng bộc lộ, ví dụ  như giao diện OLE/COM; và chúng có 
thể  được nhóm góp lại với nhau thành từng gói (package). Biểu đồ  thành phần được sử  dụng 
trong công việc lập trình cụ thể (xem hình 3.9).

4.9- Biểu đồ triển khai (Deployment Diagram):
    Biểu đồ  triển khai chỉ  ra kiến trúc vật lý của phần cứng cũng như phần mềm trong hệ  thống.
Bạn có thể  chỉ  ra từng máy tính cụ  thể  và từng trang thiết bị  cụ  thể  (node) đi kèm sự  nối kết
giữa chúng với nhau, bạn cũng có thể  chỉ  ra loại của các mối nối kết đó. Bên trong các nút
mạng (node), các thành phần thực thi được cũng như các đối tượng sẽ  được xác định vị  trí để
chỉ  ra những phần mềm nào sẽ  được thực thi tại những nút mạng nào.  Bạn cũng có thể  chỉ  ra
sự phụ thuộc giữa các thành phần.
    Biểu đồ  triển khai chỉ  ra hướng nhìn triển khai, miêu tả  kiến trúc vật lý thật sự  của hệ  thống.
    Đây là một hướng nhìn rất xa lối miêu tả  duy chức năng của hướng nhìn Use case. Mặc dù
vậy, trong một  mô hình tốt, người ta có thể  chỉ  tất cả  những con đường dẫn từ  một nút mạng
trong một kiến trúc vật lý cho tới những thành phần của nó, cho tới lớp mà nó thực thi, cho tới
những tương tác mà các đối tượng của lớp này tham gia để  rồi cuối cùng, tiến tới một  Use
case. Rất nhiều hướng nhìn khác nhau của hệ  thống được sử  dụng đồng thời để  tạo ra một lời
miêu tả thấu đáo đối với hệ thống trong sự tổng thể của nó.
5- Phần tử mô hình (model element):
    Các  khái  niệm  được  sử  dụng  trong  các  biểu  đồ  được  gọi  là  các  phần  tử  mô  hình  (model
element). Một phần tử  mô hình được định nghĩa với ngữ  nghĩa  (semantic), đó là một định
nghĩa về  bản chất phần tử  hay là một xác định ý nghĩa chính xác xem nó sẽ  thể  hiện điều gì
trong những lời khẳng định rõ ràng. Mỗi phần tử  mô hình còn có một sự  miêu tả  trực quan,
một ký hiệu hình học được sử  dụng để  miêu tả  phần tử  này trong biểu đồ. Một phần tử  có thể
tồn tại trong nhiều dạng biểu đồ  khác nhau, nhưng cũng có những nguyên tắc xác định loại
phần tử  nào có thể  được chỉ  ra trong loại biểu đồ  nào. Một vài ví dụ  cho phần tử  vô hình là
lớp, đối tượng, trạng thái, nút mạng, gói, thành phần (hình 3.11).
Hình 3.12 chỉ ra một vài ví dụ của mối quan hệ, đây cũng là một dạng phần tử mô hình, chúng
được sử dụng để nối các phần tử mô hình khác với nhau. Một vài loại quan hệ đáng chú ý:
  • Nối kết (Association): nối các phần tử và các thực thể nối (link).
  • Khái  quát  hóa  (Generalization):  còn  được  gọi  là  tính  thừa  kế,  có  ý nghĩa rằng một phần tử  này có thể  là một sự  chuyên biệt hóa của một phần tử khác.
  • Sự  phụ  thuộc  (Dependency):  chỉ  ra  rằng  một  phần  tử  này  phụ  thuộc trong một phương thức nào đó vào một phần tử khác.
  • Kết tập  (Aggregation): Một dạng của nối kết, trong đó một phần tử này chứa các phần tử khác.
    Ngoài ra còn có các phần tử  mô hình khác như thông điệp (Message), hành động (action) và
khuôn mẫu (stereotype). Tất cả  các phần tử  mô hình, ý nghĩa của chúng cũng như những ứng
dụng đều được giải thích kỹ lưỡng hơn trong các chương sau.
6- Cơ chế cung (General Mechanism): 
    UML thể hiện một số các cơ chế chung trong tất cả các biểu đồ nhằm mục đích cung cấp thêm
các thông tin bổ sung, thường đây là những thông tin không thể được thể hiện qua các chức
năng và khả năng cơ bản của các phần tử mô hình.
6.1- Trang trí (Adornment)
    Các sự  trang trí trực quan có thể  được sử  dụng kèm thêm vào các phần tử  mô hình trong biểu
đồ. Động tác trang trí bổ  sung thêm ngữ  nghĩa cho phần tử. Một ví dụ  là kỹ  thuật được sử
dụng để  phân biệt một loại thực thể  (lớp) và một thực thể. Khi thể  hiện một loại, tên phần tử
sẽ được in đậm. Khi cũng chính phần tử đó thể hiện chỉ một thực thể của loại này, tên phần tử
sẽ  được gạch dưới và có thể  được coi là cả  tên của thực thể  lẫn tên của loại đó. Một hình chữ
nhật thể  hiện lớp với tên được in đậm sẽ  thể  hiện một lớp và tên được gạch dưới sẽ  thể  hiện
một đối tượng, đây  là một ví dụ  tiêu biểu của adornment. Cũng nguyên tắc đó được áp dụng
cho các nút mạng, khi ký hiệu nút được in đậm là thể  hiện một loại nút, ví dụ  như máy in
(Printer), khi ký hiệu được gạch dưới là thể  hiện một thực thể  của lớp nút mạng này ví dụ
John’s  HP 5MP-printer. Các kiểu trang trí khác là các lời đặc tả  về  số  lượng trong quan hệ
(multiplicity), nơi số lượng là một số hay một khoảng số chỉ ra bao nhiêu thực thể của các loại



thực thể  được nối với nhau sẽ  có thể  tham gia trong một quan hệ. Kí hiệu trang trí được viết
gần phần tử mô hình được mà nó bổ sung thông tin (hình 3.13).
6.2- Ghi chú (Note)
    Cho dù một ngôn ngữ mô hình hóa có được mở rộng đến bao nhiêu chăng nữa, nó cũng không
thể  định nghĩa tất cả  mọi việc. Nhằm tạo điều kiện bổ  sung thêm cho một mô hình những
thông tin không thể  được thể  hiện bằng phần tử  mô hình, UML cung cấp khả  năng kèm theo
lời ghi chú. Một lời ghi chú có thể  được để  bất kỳ  nơi nào trong bất kỳ  biểu đồ  nào, và nó có thể  chứa bất kỳ  loại thông tin nào. Dạng thông tin của bản thân nó là chuỗi ký tự  (string),
không  được  UML  diễn  giải.  Lời  ghi  chú  thường  đi  kèm  theo  một  số  các  phần  tử  mô  hình
trong biểu đồ, được nối bằng một đường chấm chấm, chỉ ra phần tử mô hình nào được chi tiết
hóa hoặc được giải thích (hình 3.14).
Một lời ghi chú thường chứa lời nhận xét hoặc các câu hỏi của nhà tạo mô hình, ví dụ lời nhắc
nhở  cần phải xử  lý vấn đề  nào đó trong thời gian sau này. Lời ghi chú cũng có thể  chứa các
thông tin dạng khuôn mẫu (stereotype).
6.3- Đặc tả (Specification)
    Các phần tử  mô hình có thuộc tính (Property) chứa các giá trị  dữ  liệu về  phần tử  này. Một
thuộc tính được định nghĩa với một tên và một  giá trị  đính kèm  (tagged value), thường chúng
ở trong một dạng thông tin được xác định trước, ví dụ như số nguyên hay chuỗi kí tự. Có một
loạt  thuộc  tính  đã  được  định  nghĩa  trước,  ví  dụ  như  tài  liệu  (docement),  trách  nhiệm
(Responsibility), sự trường tồn (Persistence) và tính song song (Conccurency).
Thuộc tính được sử  dụng để  thêm các  đặc tả  bổ  sung về  một phần tử, những thông tin bình
thường ra không được thể hiện trong biểu đồ. Ví dụ tiêu biểu là một lớp sẽ được miêu tả bằng
một tài liệu văn bản nhất định, cung cấp nhiều thông tin hơn về  trách nhiệm cũng như khả
năng của lớp này. Loại đặc tả này bình thường ra không được chỉ ra trong các biểu đồ, nhưng
thường thì trong đa phần các công cụ  mô hình hóa chúng sẽ  có thể  được truy cập qua hành
động nhấp nút vào một phần tử nào đó, hiệu quả là một cửa sổ chứa đặc tả với tất cả các thuộc
tính sẽ được chỉ ra (Hình 3.15).
7- Mở rộng UML
    UML có thể  được mở  rộng hoặc có thể  được sửa  đổi để  phù hợp với một phương pháp đặc
biệt, một tổ  chức cụ  thể  hay một người dùng cụ  thể. Chúng ta sẽ  bàn luận sơ qua đến ba cơ
chế  mở  rộng  UML:  khuôn  mẫu  (stereotype),  giá  trị  đính  kèm  (tagged  value)  và  hạn  chế
(constraint).
7.1- Khuôn mẫu (Stereotype)
    Cơ chế  mở  rộng khuôn mẫu định nghĩa một loại phần tử  mô hình mới dựa trên một phần tử
mô hình đã tồn tại. Khuôn mẫu có thể được coi là "tương tự" như một phần tử đã có sẵn, cộng
thêm phần quy định ngữ  nghĩa (semantic) riêng biệt không có trong phần tử  gốc  kia. Khuôn
mẫu của một phần tử có thể được sử dụng trong cùng tình huống như phần tử căn bản. Khuôn
mẫu dựa trên tất cả các loại phần tử mô hình sẵn có - lớp, nút mạng, thành phần, cũng như các
mối quan hệ như liên kết, khái quát hóa, sự phụ thuộc. Ngôn ngữ UML có chứa một số lượng
lớn các khuôn mẫu được định nghĩa sẵn và chúng được sử  dụng để  sửa đổi các phần tử  mô
hình sẵn có, thay cho việc phải định nghĩa hoàn toàn mới. Cơ chế  này giúp gìn giữ  tính đơn
giản của nền tảng ngôn ngữ UML.
    Khuôn mẫu được miêu  tả  qua việc đưa tên của chúng vào trong một cặp ký tự  ngoặc nhọn
<<>>, theo như trong hình 3.16. Ký tự  ngoặc nhọn này được gọi là guillements. Khuôn mẫu
cũng có thể có kí hiệu hình học riêng. Một phần tử của một loại khuôn mẫu cụ thể có thể được thể hiện bởi tên khuôn mẫu đi kèm ký hiệu hình học mô tả phần tử  căn bản, hay là sự kết hợp
của cả  hai yếu tố  này. Bất kỳ  khi nào một phần tử  mô hình được nối kết với một tên hoặc kí
hiệu khuôn mẫu, ta sẽ  đọc "đây là một loại phần tử  thuộc loại khuôn mẫu...". Ví dụ,  một lớp
với <<Window>> sẽ  được gọi là "một lớp trong dạng khuôn mẫu cửa sổ", ý nghĩa của nó là
một dạng lớp cửa sổ. Những thuộc tính cụ  thể  mà một lớp cửa sổ  cần phải có sẽ  được định
nghĩa khi khuôn mẫu này được định nghĩa.
    Như đã nói, khuôn mẫu là một cơ  chế  mở  rộng xuất sắc, là một cơ chế  ngăn cho ngôn ngữ
UML không trở  nên quá phức tạp, mặc dù vẫn cho phép thực hiện sự mở  rộng và sửa đổi cần
thiết. Đa phần các phần tử  mô hình mới mà bạn cần đến đều có một khuôn mẫu nền tảng
trong ngôn ngữ  UML.  Một khuôn  mẫu sau đó có thể  được sử  dụng để  cộng thêm các ngữ
nghĩa cần thiết, nhằm mục đích định nghĩa nên các phần tử mô hình còn thiếu.
7.2- Giá trị đính kèm (Tagged Value)
     Như đã nói, các phần tử mô hình có thể có các thuộc tính chứa một cặp tên-giá trị về bản thân
chúng (hình 3.17). Các thuộc tính này cũng còn được gọi là các gía trị  đính kèm. UML có
chứa  một loạt các thuộc tính được định nghĩa trước, nhưng kể  cả  người sử  dụng cũng có thể
định nghĩa ra các thuộc tính mới để  chứa các thông tin bổ  sung về  các phần tử  mô hình. Mọi
hình  dạng  thông  tin  đều  có  thể  được  đính  kèm  vào  phần  tử:  các  thông  tin  chuyên  biệt  về
phương pháp, các thông tin của nhà quản trị  về  tiến trình mô hình hóa, các thông tin được sử
dụng bởi các công cụ khác, ví dụ như các công cụ tạo code, hay bất kỳ một loại thông tin nào
mà người sử dụng muốn đính kèm vào phần tử mô hình.
7.3- Hạn chế (Constraint)
    Một sự  hạn chế  là một sự  giới hạn về  sự  sử  dụng hoặc ý nghĩa của một phần tử. Sự  hạn chế
hoặc sẽ  được khai báo trong công cụ  và được sử  dụng nhiều lần trong rất nhiều biểu đồ  khác
nhau, hay được định nghĩa và sử dụng trong chỉ một biểu đồ, theo như nhu cầu.
Hình 3.18 chỉ  ra mối quan hệ  nối kết giữa nhóm các công dân lớn tuổi và lớp con người, chỉ
ra  rằng nhóm công dân  có thể  có nhiều người liên quan. Mặc dù vậy, để  miêu tả  rằng chỉ
những người nào lớn hơn 60 tuổi mới có thể tham gia vào nhóm này, người ta định nghĩa một
sự  hạn chế, hạn hẹp tiêu chuẩn tham gia đối với chỉ  những người nào mà thuộc tính  tuổi tác
có giá trị  lớn hơn 60. Định nghĩa này sẽ  hạn chế  số  lượng những người được sử  dụng trong
mối quan hệ. Nếu không có nó, người ta rất dễ hiểu lầm khi diễn tả biểu đồ. Trong trường hợp
tồi tệ, nó có thể dẫn đến sự thực thi sai trái của hệ thống.
Trong trường hợp này, hạn chế được định nghĩa và ứng dụng trực tiếp trong chính biểu đồ mà
nó được cần tới. Nhưng nhìn chung thì hạn chế  cũng có thể  được định nghĩa với tên cùng lời
đặc tả riêng, ví dụ như: "công dân già" và "người có tuổi lớn hơn 60", và hạn chế này sẽ được
sử  dụng trong nhiều biểu đồ  khác nhau. UML có chứa một loạt các hạn chế  được định nghĩa
sẵn, chúng được miêu tả chi tiết trong các chương sau.
(Bài 2 còn tiếp)

Post a Comment