Giáo trình phân tích và thiết kế hướng đối tượng - Trương Ninh Thuận, Đặng Đức Hạnh

Tiêu đề tài liệu: Giáo trình phân tích và thiết kế hướng đối tượng Tác giả: Trương Ninh Thuận, Đặng Đức Hạnh Nhà xuất bản: Đại học Quốc gia Hà Nội Thời gian phát hành: 2016

MÔ HÌNH HÓA ĐỐI TƯỢNG

Các nguyên tắc cơ bản của hướng đối tượng

Dựa trên đặc điểm của phươnng pháp hướng đối tượng, người ta đưa ra 4 nguyên tắc chính của mô hình hướng hóa hướng đối tượng là: Sự trừu tượng hóa, tính đóng gói, tính mô-đun hóa, sự phân cấp

Trừu tượng hóa (Abstraction) là việc xây dựng một mô hình chỉ bao gồm các đặc điểm quan trọng, cần thiết và phân biệt với các đặc điểm của mô hình khác, mô hình này đã xóa bỏ các đặc tính chi tiết, ít quan trọng và không cần thiết để tạo thành một mô hình có các đặc tính riêng biệt

Trừu tượng hóa cho phép chúng ta quản lý sự phức tạp của mô hình bằng cách chỉ quan tâm đến các đặc điểm cần thiết của các thực thể để phân biệt với các thực thể khác trong mô hình Chúng ta cũng cần chú ý rằng trừu tượng hóa phụ thuộc vào ngữ cảnh, vì vậy những gì quan trọng ở trong ngữ cảnh này có thể không quan trọng trong ngữ cảnh khác

Trong lý thuyết về lập trình hướng đối tượng, trừu tượng hóa là các phương pháp để xây dựng các đối tượng đồng thời nó được xem như các tác nhân ảo có thể thực hiện các hành vi, tự thay đổi trạng thái của mình và có thể giao tiếp với các đối tượng khác trong hệ thống

Các ngôn ngữ lập trình hướng đối tượng thường cho phép trừu tượng hóa các thực thể tương tự nhau, vấn đề này nhằm mục đích hỗ trợ cho kỹ thuật đa hình (polymorphism) trong lập trình hướng đối tượng, là kỹ thuật cho phép thay thế kiểu của đối tượng bằng một kiểu khác có vai trò tương tự

Xem xét một ví dụ về một chương trình viết bằng Java để biểu diễn một số con vật có cùng mức trừu tượng hóa Trong chương trình này, lớp Animal dùng để biểu diễn trạng thái của con vật và các hành vi của chúng public class Animal extends LivingThing { private Location loc; private double energyReserves; boolean isHungry() { return energyReserves < 2.5;

Với các định nghĩa trên, chúng ta có thể tạo ra các đối tượng với kiểu Animal và gọi các phương thức của chúng như sau: thePig = new Animal(); theCow = new Animal(); if (thePig.isHungry()) { thePig.eat(tableScraps);

} if(theCow.isHungry()) { theCow.eat(grass);

Trong ví dụ trên, lớp Animal là sự trừu tượng hóa sử dụng cho các con vật hiện tại, LivingThing được xem như sự trừu tượng hóa ở mức cao hơn của Animal, dùng để mô tả tất cả lớp các động thực vật có sự sống

Tính đóng gói (Encapsulation) là sự quy tụ các tính chất (các thuộc tính và các hành vi) vào trong một hộp đen của sự trừu tượng hóa, cho phép ẩn đi sự cải đặt ở phía sau các giao diện

Tính đóng gói thường được đề cập đến với khái niệm che giấu thông tin (Information hiding), cho phép sự truy cập đến các thành phần thông qua các giao diện mà không cần biết sự cài đặt của nó

Tính đóng gói loại bỏ sự phụ thuộc trực tiếp trong cải đặt giữa các thành phần

Vì thế có thể thay đổi sự cài đặt của thành phần mà không cần cập nhật các thành phần khác và giao điện cũng không thay đổi Sự thay đổi trong cài đặt của một thành phần không ảnh hưởng đến các thành phần khác vì vậy việc bảo trì dễ dàng và chỉ phi thấp hơn

Sự đóng gói cũng cho phép bảo vệ các trạng thái nội tại của đối tượng bởi các đối tượng bên ngoài và bảo vệ các đối tượng bên ngoài bởi sự thay đổi cài đặt của đối tượng này

Trong kỹ thuật đóng gói, dữ liệu được tổ chức sao cho các đối tượng ở lớp khác không truy nhập được vào những thuộc tỉnh riêng và chỉ cho phép các hàm trong cùng lớp hoặc trong những lớp có quan hệ kế thừa với nhau được quyền truy nhập đến vùng cho phép Vùng công khai của lớp thì cho phép mọi đối tượng được phép truy nhập Các hàm công khai của lớp đóng vai trò như là giao diện của các đối tượng với phần còn lại của hệ thống

Tính mô-đun hóa (Modularity) có thể được định nghĩa như là sự phân chia các khối vật thể lớn thành các nhóm nhỏ và cấu trúc đơn giản hơn

Các hệ thống phần mềm được phát triển thường rất phức tạp Để dễ dàng hiểu được hệ thống, chúng ta thường phân chia thành các thành phần nhỏ hơn và các thành phần này được quản lý một cách độc lập Sự phân chia hệ thống theo cách này gọi là tính mo - đun hóa Đó là công việc quan trọng để phát triển các hệ thống lớn và phức tạp

Khái niệm cơ bản về mô hình hướng đối tượng

Khái niệm đối tượng cho phép người phát triển phần mềm biểu diễn các khái niệm thế giới thực trong bản thiết kế phần mềm của họ Các khái niệm thế giới thực này có thể là một thực thể vật lý như người, xe tải, con chó, cái bàn, xe đạp Các đối tượng cũng có thể là các khái niệm về một tiến trình hóa học hoặc thuật toán

Các đối tượng thế giới thực có cùng 2 đặc điểm chung là các trạng thái và hành vi Con chó có các trạng thái (tên, màu sắc, no, đói) và hành vi (sủa, chạy, vẫy đuôi)

Xe đạp có trạng thái (nhịp bản đạp, tốc độ) và hành vi (thay đổi nhịp bàn đạp, phanh xe) Xác định trạng thái và hành vi của các đối tượng thế giới thực là một phương pháp để bắt đầu cách nghĩ về mô hình hóa hướng đối tượng

Với mỗi đối tượng trong thực tế, chúng ta có thể đặt hai câu hỏi: "Có những trạng thái nào của đối tượng?" và "Những hành vi nào đối tượng có thể thực hiện?" Hãy quan sát và viết ra những gì nhìn thấy được, chúng ta có thể thấy rằng, chiếc đèn bàn có thể có 2 trạng thái: bật (on) và tắt (off), có 2 hành vi bật đèn (turn on) và tắt đèn (turn off), nhưng chiếc radio có thể có thêm các trạng thái: bật (on), tắt (off), âm lượng hiện tại (current volume), kênh hiện tại (current station) và hành vi bật đài (turn on), tắt đài (turn off), tăng âm thanh (increase volume), giảm âm thanh (decrease volume), tim kênh (seek), dò kênh (scan), và chỉnh sóng (ture) Chúng ta cũng nhận thấy rằng, một số đối tượng chứa các đối tượng khác Những quan sát thế giới thực này đều được chuyển vào thế giới của lập trình hướng đối tượng

Các đối tượng phần mềm được mô hình tương tự các đối tượng thế giới thực: chúng gồm các trạng thái và hành vi Một đối tượng cất giữ các trạng thái của nó trong thuộc tỉnh (là biến trong một số ngôn ngữ lập trình) và thể hiện hành vi của nó qua các phương thức (là các hàm trong một số ngôn ngữ lập trình) Các phương thức dùng để thay đổi trạng thái của đối tượng, ngoài ra còn dùng để giao tiếp với các đối tượng khác Che giấu các trạng thái nội tại và yêu cầu tất cả sự tương tác được thực hiện thông qua phương thức của đối tượng là cơ chế Đóng gói dữ liệu

Hình 1.1 Mô hình hóa xe đạp

Xem xét ví dụ một chiếc xe đạp được mô hình hóa như một đổi tượng phần mềm (Hình 1.1) Chuyển các trạng thái vào thuộc tỉnh của đối tượng (tốc độ hiện tại (current speed), nhịp bàn đạp hiện tại (current pedal cadence), và trạng thái líp hiện tại (current gear)) và cung cấp các phương thức để thay đổi các trạng thái, đối tượng bảy giờ đã được sẵn sàng sử dụng bởi các đối tượng bên ngoài

Một lớp định nghĩa một khung chứa các cấu trúc và hành vi chung của các đối tượng Các đối tượng được tạo ra từ lớp được gọi là các thể hiện của lớp Lớp là sự mô tả tĩnh và đối tượng là các thế hiện khi chạy của lớp

Nhắc lại rằng, mô hình hóa là quá trình trừu tượng hóa các đối tượng của thế giới thực vào ngữ cảnh của hệ thống Sử dụng các đối tượng của thế giới thực, tiến hành quá trình loại bỏ và giữ lại các thông tin cần thiết Các lớp trong mô hình là kết quả của quá trình phân loại này

Một ví dụ trong thế giới thực mà chúng ta dễ dàng quan sát được là hàng nghìn xe đạp được sản xuất cùng hãng và cùng mô hình Mỗi chiếc xe được làm từ cùng một bản thiết kế và vì thế có cùng các thành phần Mỗi chiếc xe đạp được coi như một đối tượng của lớp xe đạp Lớp là một bản thiết kế mà từ đó các đối tượng riêng lẻ được tạo ra

Lớp xe đạp dưới đây là một cài đặt của bản thiết kế như trong Hình II: class Bicycle ( int cadence = 0; int speed = 0; int gear = 1; void changeCadence (int newValue) { cadence = newValue;

} void changeGear (int newValue) { gear = newValue;

} void speedUp(int increment) { speed = speed + increment;

} void applyBrakes(int decrement) { speed = speed – decrement;

System.out.println(“cadence: ” + cadence + “speed: ” + speed + “gear: ” + gear);

Lấy một ví dụ khác, lớp "Course" là một sự trừu tượng hóa của biểu diễn thế giới thực của một môn học ở trường đại học Lớp này gồm các thuộc tỉnh sau: tên (name), phòng học (location), số giờ tín chỉ (credit hours), thời gian bắt đầu (start time), và thời gian kết thúc (end time) Nó cũng có thể có các hành vi, như thêm hoặc xóa sinh viên của môn học, lấy thời khóa biểu, xác định xem môn học đã đăng ký đẩy chưa

1.2.3 Tổng quát hóa - Kế thừa Định nghĩa: Quan hệ chuyên biệt/tổng quát hỏa là quan hệ mà các đối tượng của các phần tử chuyên biệt (phần tử con) có thể được thay thế bởi các đối tượng của các phần tử tổng quát hóa (phần tử cha)

Các đặc điểm của tổng quát hóa:

- Các lớp con có thể được sử dụng ở những nơi mà lớp cha được sử dụng, nhưng ngược lại không đúng

Lớp con thừa kế các thuộc tỉnh và hành vi từ lớp cha

Tổng quát hóa là quá trình truyền ứng (transitive), nghĩa là lớp con sẽ có các tính chất của lớp mà lớp cha thừa kế Quan hệ tổng quát hóa giữa các đối tượng thường được mô tả theo tiếng Anh là "is a kind of”

- Từ khóa “Tổng quát hóa" và "Kế thừa" thông thường có thể được thay thế cho nhau Nếu muốn phân biệt các khái niệm này, tổng quát hóa là tên của quan hệ, kế thừa là cơ chế biểu diễn quan hệ tổng quát hóa trong mô hình

Hình 1.3 Ví dụ về thừa kế

Trong các mô hình hướng đối tượng, tồn tại hai kiểu kế thừa là kế thừa đơn và đa kế thừa Kế thừa đơn nghĩa là lớp con kế thừa từ một lớp cha Còn với đa kế thừa, một lớp con có thể kế thừa từ nhiều lớp cha

NGÔN NGỮ MÔ HÌNH HÓA UML

Giới thiệu

2.1.1 Lịch sử ra đời và các mục tiêu thiết kế

UML được phát triển từ nỗ lực đơn giản hóa và hợp nhất từ rất nhiều phương pháp phát triển hướng đối tượng đã được đề xuất bởi Slaer/Mellor trong, Coad/Yourdon trong, và Rumbaugh cùng nhóm tác giả trong Trong đó đáng kể nhất là nỗ lực hợp nhất từ các phương pháp OMT của Rumbaugh, phương pháp OOAD của Booch, và phương pháp phát triển hướng ca sử dụng của Jacobson Trên cơ sở đó, vào năm 1996 nhóm Object Management Group (OMG) đưa ra bản phác thảo nêu rõ các yêu cầu đặt ra cho mô hình hóa hướng đối tượng Phiên bản đề xuất về UML được gửi lên OMG một năm sau đó, đánh dấu sự ra đời của ngôn ngữ mô hình hóa UML như là một chuẩn về mô hình hóa hướng đối tượng cho ngành công nghiệp phần mềm Sau đó vài năm, kể từ khi UML được áp dụng rộng rãi trong thực tế, nhóm OMG đã tổng hợp và đề xuất các yêu cầu mới cho UML nhằm khắc phục các vấn đề phát sinh cũng như thêm các tính năng mới Năm 2004, UML phiên bản 2.0 ra đời và đến nay vẫn đang được phát triển

Thuật ngữ thống nhất trong UML bao hàm nhiều ý nghĩa Đô là sự thống nhất về phương pháp và Ký pháp đã được đề xuất trước đó UML có thể tái hiện bất kỳ mô hình nào được đề cập trong các phương pháp trước đó, thậm chí nó còn biểu diễn tốt hơn Sự thống nhất ở đây còn có nghĩa chỉ sự xuyên suốt trong vòng đời phát triển

UML được dùng để biểu diễn chế tác ở bất kỳ giai đoạn nào trong vòng đời phát triển, từ nắm bắt yêu cầu đến triển khai hệ thống Sự thống nhất còn có nghĩa nó có thể được dùng cho nhiều miền ứng dụng khác nhau UML được thiết kế để mô hình hóa hầu hết các miền ứng dụng với các tính chất như quy mô lớn, phức tạp, thời gian thực, phân tán và các tính chất khác UML thể hiện tính thống nhất giữa các ngôn ngữ cài đặt và các nền triển khai Các mô hình UML là độc lập có thể được hiện thực hóa bất kỳ nền triển khai và ngôn ngữ cài đặt nào Sự thống nhất còn thể hiện xuyên suốt các tiến trình phát triển UML là ngôn ngữ mô hình hóa hỗ trợ cho các tiến trình phát triển, không phải là sự mô tả chi tiết về một tiến trình phát triển cụ thể UML chứa đựng sự thống nhất xuyên suốt các khái niệm mô hình hóa cốt lõi để có được phạm vi áp dụng rộng rãi

UML được thiết kế để trở thành ngôn ngữ mô hình hóa phổ quát mà bất kỳ ai muốn mô hình hóa cũng có thể sử dụng UML được xây dựng dựa trên sự quy ước chung của cộng đồng, có thể diễn đạt được hầu hết các chế tác trong các phương pháp phát triển tiên tiến hiện thời Nó cũng được xây dựng để hưởng đến giải quyết các vấn đề trong phát triển phần mềm như quy mô lớn, tính phân tán, tương tranh, sử dụng lại và việc xây dựng đội phát triển

UML ra đời không phải để tạo ra một phương pháp phát triển đầy đủ Bản thân nó không chứa đựng các bước làm nên quy trình phát triển Chúng ta cần phân biệt ngôn ngữ UML với một tiến trình phát triển cụ thể biểu diễn bởi UML Tuy vậy, UML cung cấp các khái niệm hỗ trợ lược đồ phát triển tốt nhất hiện giờ Đó là lược đồ phát triển với các tính chất như tiến trình phát triển lập, lấy kiến trúc làm trung tâm và giải quyết các yêu cầu hướng ca sử dụng

Mục tiêu nửa trong thiết kế UML là tạo ra khả năng diễn đạt đủ mạnh để hỗ trợ các khái niệm phát sinh trong hệ thống phần mềm hiện đại như tính tương tranh và phân tán Đồng thời UML cần phải được thiết kế càng đơn giản càng tốt Tuy nhiên, một thực tế là UML liên tục phải được bổ sung để tăng khả năng diễn đạt, đáp lại sự tăng nhanh về độ phức tạp của các ứng dụng, các ngôn ngữ hiện đại và các hệ điều hành Thực tế này làm cho tính đơn giản ban đầu của nó đã nhanh chóng bị phá vỡ

Hiện nay, người ta đang tính đến giải pháp xây dựng các công cụ hỗ trợ để khắc phục những khó khăn này

UML có thể được sử dụng với các mục đích khác nhau Lưu ý là ngay cả khi nắm vững ngôn ngữ UML, không có gì đảm bảo cho một mô hình tốt Điều này tương tự như khi chúng ta sử dụng ngôn ngữ tự nhiên để viết văn Chất lượng đoạn văn phụ thuộc vào các khả năng khác của người viết chứ không chỉ sự hiểu biết về cú pháp và ngữ nghĩa của ngôn ngữ tự nhiên UML được thiết kế chủ yếu cho các hệ phần mềm với các miền như các hệ thống tin nghiệp vụ, các hệ dịch vụ tài chính ngân hàng, các hệ truyền thông hay các hệ dịch vụ Web phân tán Thực tế, UML không chỉ được dùng để mô hình hóa phần mềm, nó còn được dùng để mô hình hóa các hệ thống phi phần mềm như luồng công việc hay cho hoạt động thiết kế phần cứng

2.1.2.1 UML là ngôn ngữ mô hình hóa

UML là phương tiện để diễn đạt các mô hình hệ thống, đó là sự tổ hợp các từ vựng có sẵn của UML theo tập quy tắc nào đó Nói cách khác, mô hình diễn đạt bằng UML phải chính xác về mặt cũ pháp và ngữ nghĩa (truyền tải nghĩa nào đó để phản ánh hệ thống) Thông thường mô hình hệ thống được diễn đạt thông qua các khung nhìn Khung nhìn được tái hiện bằng các biểu đồ UML Từ vựng và quy tắc ngôn ngữ UML cung cấp cơ sở để xây dựng và đọc hiểu về mô hình, nhưng nó không chỉ rõ thời điểm và trình tự tạo mô hình Nhiệm vụ đó được xác định nhờ vào quy trình phát triển phan mem

2.1.2.2 UML là ngôn ngữ trực quan hóa để hiển thị

Các lập trình viên thường sử dụng trực tiếp ngôn ngữ lập trình (dạng văn bản) để diễn đạt giải pháp mà họ đang nghỉ trong đầu Văn bản là phương tiện quen thuộc để chúng ta diễn đạt trực tiếp các biểu thức và các thuật toán Trong những trường hợp đỗ, thường không có khoảng cách rõ rằng từ ý tưởng đến cải đặt mà chương trình Thực tế, người lập trình vẫn phải thực hiện một số hoạt động mô hình hóa

“trong đầu" Thậm chí trong một số trường hợp, họ phải phác thảo một số ý tưởng lên bảng hay bản về Tuy nhiên, cách này sẽ gặp phải những vấn đề sau Thứ nhất, sự giao tiếp các mô hình mức khái niệm sẽ gặp khó khăn, dễ phát sinh lỗi bởi vì những người liên quan thường không dùng chung loại ngôn ngữ diễn đạt đỏ, mỗi người sẽ có cách hiếu riêng khác nhau Thứ hai, với một số yếu tố trong hệ thống phần mềm để có thể hiểu được, chúng ta cần phải mô hình hóa chúng thay vì chỉ dùng các ngôn ngữ lập trình Chẳng hạn, hệ thống phân cấp các lớp có thể suy ra từ mã nguồn của các lớp, nhưng không thể nắm bắt một cách trực tiếp Thứ ba, nếu người phát triển không làm tài liệu các mô hình dạng hình dung thì thông tin đó sẽ bị mất đi hoặc chỉ được khôi phục một phần trong pha cài đặt khi mã nguồn tương ứng bị cắt bỏ

2.1.2.3 UML là ngôn ngữ để đặc tả

UML hướng đến hỗ trợ mô tả vấn đề một cách chính xác, không nhập nhằng và hoàn thiện UML phục vụ cho đặc tả thiết kế, phân tích và các giải pháp cài đặt trong vòng đời phát triển của hệ thống

2.1.2.4 UML là ngôn ngữ để xây dựng

Các mô hình biểu diễn dạng đồ họa trước đây thường được dùng như tài liệu để biểu diễn cho người dùng hiểu Các biểu đồ UML không chỉ đóng vai trò là tài liệu phát triển mà nó còn có thể được chuyển tự động sang các dạng biểu diễn khác, phục vụ cho quá trình phát triển, đặc biệt là việc chuyển về dạng mã nguồn Một số biểu đồ UML có thể chuyển sang các mã ngôn ngữ lập trình khác nhau như Java, C++ cũng như các lược đồ cơ sở dữ liệu Nó góp phần làm tăng tính tự động hóa trong quá trình phát triển phần mềm

2.1.2.5 UML là ngôn ngữ dễ làm tài liệu

Việc tổ chức phần mềm đạt được chất lượng cao chỉ khi có sự giảm sát tất cả các chế tác trong tất cả các pha, bao gồm cá mà thực thì Đó là các chế tác về yêu cầu phần mềm, kiến trúc, thiết kế, mà nguồn, kế hoạch dự án, kiểm thử, các bản mẫu, và các tài liệu chuyển giao Tùy thuộc vào “văn hóa” của đội phát triển mà một số chế tác được tạo bài bản hơn so với một số chế tác khác UML hỗ trợ tạo tài liệu kiến trúc hệ thống cùng các chi tiết của nó UML cho phép diễn đạt các yêu cầu và các kiểm thử Cuối cùng, UML cung cấp ngôn ngữ để mô hình hóa các hoạt động lập kế hoạch dự án cũng như việc quản lý chuyển giao phiên bản

2.1.3 Phần tử mô hình trong UML Để sử dụng UML có hiệu quả, nhìn chung, người mô hình hóa phải nắm được ba vấn đề: các phần tử cơ bản của mô hình UML, các quy tắc (luật) liên kết các phần tử mô hình, và một số cơ chế chung áp dụng cho ngôn ngữ Các khối hình thành mô hình UML gồm ba loại sau: phần tử, quan hệ và biểu đồ Phần tử là các trừu tượng hóa căn bản trong mô hình, các quan hệ gắn các phần tử này lại với nhau, và biểu đồ nhóm gộp tập các phần tử có mối quan hệ với nhau Trong UML có bốn loại phần tử mô hình: phần tử cấu trúc, phần tử hành vi, phần tử nhóm gộp, và phần tử chú thích

Các phần tử này là các khối xây dựng hướng đối tượng của UML

Phần tử cấu trúc tương ứng với các danh tử trong các mô hình UML Chúng chủ yếu là các phần tĩnh của một mô hình, là sự tái hiện cho các thực thể khái niệm hay vật lý Có bảy loại phần tử cấu trúc trong UML, được liệt kê như sau:

Biểu đồ ca sử dụng

Biểu đồ ca sử dụng được sử dụng để mô hình hóa các khía cạnh động của hệ thống Chủng định hướng cho việc mô hình hóa hành vi của hệ thống, hệ thống con hay một lớp Chúng diễn đạt một khung nhìn từ phía ngoài đối với hệ thống, chỉ ra cách mà hệ thống được sử dụng trong khung cảnh và làm rõ sự tương tác giữa hệ thống và môi trường Khung nhìn ca sử dụng phân chia chức năng hệ thống thành các giao dịch có nghĩa đối với các tác nhân (những người dùng được lý tưởng hóa của hệ thống, phản ánh vai trò của người dùng) Mỗi đơn vị chức năng tương tác đó được gọi là ca sử dụng Ca sử dụng mô tả sự tương tác với các tác nhân như là chuỗi các thông điệp giữa hệ thống với một hay nhiều tác nhân Biểu đồ ca sử dụng bao gồm tập các ca sử dụng, các tác nhân và quan hệ giữa chúng

2.2.1 Khái niệm cơ sở cho biểu đồ ca sử dụng

Tác nhân Tác nhân là khái niệm chỉ vai trò của một người, tiến trình hoặc một sự vật tương tác với hệ thống, hệ thống con hay một lớp Tác nhân làm rõ các tương tác mà một lớp người dùng có thể có với hệ thống Lúc hệ thống thực thi, cùng một tác nhân có thể ứng với nhiều người dùng khác nhau Một người dùng có thể tham gia với vai trò là một hay nhiều tác nhân của hệ thống Chẳng hạn, một người có thể vừa là khách hàng, vừa là thủ quỹ trong hệ thống quản lý kho Một tác nhân tham gia một hay nhiều ca sử dụng Tác nhân tương tác hệ thống bằng cách trao đổi các thông điệp Các tác nhân có thể được xác định trong các hệ thống cây kế thừa: Đặc điểm của một tác nhân trừu tượng có thể được kế thừa bởi các tác nhân cụ thể khác

Ký pháp cho tác nhân được minh họa như trong Hình 2.14

Ca sử dụng Ca sử dụng là đơn vị chức năng có thể quan sát từ bên ngoài, được cung cấp bởi một phân lớp (được gọi là chủ thể) và được diễn đạt bằng chuỗi các thông điệp được trao đổi giữa chủ thể và một hay nhiều tác nhân của chủ thể Tiêu chí để phân biệt ca sử dụng với chức năng hệ thống là kết thúc ca sử dụng, tác nhân phải thu được một giá trị có thể quan sát được Mục đích của ca sử dụng là để xác định một mô đun hành vi mà không cần biết cấu trúc bên trong của chủ thể Định nghĩa một ca sử dụng phải bao gồm tất cả hành vi nó đáp ứng Nó cần nêu rõ chuỗi kịch bản chính, các luồng thay thế và tất cả các điều kiện ngoại lệ cùng với các phân hồi tương ứng Ở mức mô hình, thực thi mỗi ca sử dụng là độc lập với nhau, mặc dù ở mức cài đặt các ca sử dụng có thể phụ thuộc không tưởng minh vào nhau khi chúng cùng chia sẻ các đối tượng Ký pháp ca sử dụng được minh họa như Hình 2.15

Quan hệ ca sử dụng Bên cạnh các quan hệ liên kết với các tác nhân, giữa các ca sử dụng có thể có các quan hệ bao gộp (include), mở rộng (extend) và tổng quát hóa (generalization), minh họa trong Hình 2.16 Mô tả của một ca sử dụng lớn có thể được tích hợp từ các ca sử dụng đơn giản hơn Điều này tương tự với cách mà một lớp có thể được định nghĩa bằng cách mô tả tăng dần từ các lớp cha Một ca sử dụng có thể tích hợp hành vi của các ca sử dụng khác như là các đoạn trong hành vi tổng thể của nó Quan hệ giữa các ca sử dụng trong trường hợp này gọi là quan hệ bao gộp

Một ca sử dụng cũng có thể được định nghĩa như là một sự mở rộng tăng dần của một lớp ca sử dụng cơ sở (base use case) Quan hệ này được gọi là quan hệ mở rộng

Mở rộng một lớp cơ sở có nghĩa là thêm ngữ nghĩa vào cho nó, chứ không tạo ra một ca sử dụng mới Các quan hệ bao gộp và mở rộng được biểu diễn bằng các ký pháp mũi tên đứt nét và các từ khóa nhăn và một cách tương ứng như minh họa trong Hình 2.15 Trong trường hợp một ca sử dụng được đặc biệt hóa thành một hay nhiều ca sử dụng con, chúng ta có quan hệ tổng quát hóa ca sử dụng Bất kỳ ca sử dụng con nào cũng có thể được sử dụng thay thế cho ca sử dụng cha trong các tỉnh huống mà ca sử dụng chủ đang được tham chiếu

2.2.2 Mô hình hóa với biểu đồ ca sử dụng

Biểu đồ ca sử dụng thường được sử dụng với hai mục đích chính: mô hình hóa khung cảnh của hệ thống và mô hình hóa yêu cầu của hệ thống

2.2.2.1 Mô hình hóa khung cảnh của hệ thống

Biểu đồ ca sử dụng cho phép chúng ta xác định được khung cảnh của hệ thống, làm rõ biên của hệ thống (gồm những thứ tồn tại bên trong hệ thống) và môi trường (những thứ tồn tại bên ngoài thống và tương tác với hệ thống) Cốt lõi ở đây là cần xác định được các tác nhân tương tác với hệ thống trong suốt vòng đời của hệ thống Để mô hình hóa khung cảnh hệ thống, chúng ta có thể tiến hành theo các bước sau:

- Để xác định các tác nhân bên ngoài hệ thống chúng ta xác định (1) các nhóm cần được trợ giúp từ hệ thống để thực hiện công việc của chúng; (2) các nhóm cần cho việc thực thi chức năng của hệ thống: (3) các nhóm tương tác với các phần tử hệ thống như các phần cứng bên ngoài hay các phần mềm hệ thống khác; và (4) các nhóm thực hiện các chức năng bổ sung cho việc quản trị và vận hành hệ thống

- Tổ chức các tác nhân trong các quan hệ kế thừa khi chúng có nhiều điểm tương đồng với nhau

- Cung cấp các kiểu mở rộng (stereotype) cho tác nhân khi điều đó làm tăng tính dễ hiểu

- Bổ sung các tác nhân vào biểu đồ ca sử dụng và đặc tả các đường giao tiếp từ mỗi tác nhân đến các ca sử dụng của hệ thống

2.2.2.2 Mô hình hóa yêu cầu của hệ thống

Yêu cầu hệ thống có thể được xem là bản cam kết về những gì mà hệ thống sẽ thực hiện trên cơ sở những giả định về những yếu tố bên ngoài hệ thống cũng như bản thân hệ thống Mục tiêu của mô hình hóa yêu cầu là để làm rõ những gì hệ thống sẽ làm, không cần quan tâm nó được thực hiện như thế nào

Yêu cầu hệ thống có thể được diễn đạt theo các cách khác nhau, từ diễn đạt không chính xác với các văn bản phi cấu trúc đến các diễn đạt chính xác cao sử dụng các ngôn ngữ hình thức Hầu hết các yêu cầu chức năng của hệ thống đều có thể được diễn đạt bằng các ca sử dụng Biểu đồ ca sử dụng UML trở thành phương tiện thiết yếu để quản lý các yêu cầu này Để mô hình hóa các yêu cầu của hệ thống, chúng ta có thể tiến hành theo các bước sau:

- Thiết lập khung cảnh của hệ thống bằng cách xác định các tác nhân hệ thống

- Với mỗi tác nhân, xem xét các hành vi mà tác nhân yêu cầu - hệ thống cung cấp và phản hồi Chuyển các hành vi chung đó thành các ca sử dụng tương ứng

- Tạo ra các ca sử dụng mới cung cấp các hành vi chung cho các ca sử dụng khác thông qua quan hệ bao gộp Mớ rộng ngữ nghĩa các ca sử dụng với các luồng sự kiện thay thế thông qua sử dụng các quan hệ mở rộng

- Mô hình hóa các ca sử dụng, các tác nhân và các quan hệ giữa chúng sử dụng biểu đồ ca sử dụng

- Bổ sung các chú thích diễn giải thêm cho các ca sử dụng đặc biệt là với các yêu cầu phi chức năng.

Các biểu đồ tương tác

Các đối tượng tương tác với nhau để thực hiện một kịch bản Nhìn chung, chúng ta có thể mô tả những tương tác như theo hai cách, hoặc tập trung vào từng đối tượng riêng lẻ hoặc tập trung vào khung cảnh mà trong đó một nhóm các đối tượng tương tác với nhau Lưu ý rằng cả hai cách được sử dụng bổ trợ cho nhau Với cách thứ nhất, điển hình là tiếp cận sử dụng các máy trạng thái, nó cung cấp một khung nhìn chi tiết về hành vi được phản ánh qua từng đối tượng riêng lẻ Các đặc tả đó thường đủ chính xác để chuyển trực tiếp sang mà thực thi Tuy nhiên, đặc tả đó không giúp ta nắm bắt được chức năng tổng thể của hệ thống, khi mà máy trạng thái tại một thời điểm, chỉ tập trung vào một đối tượng Để có thể xác định được hành vi tổng thể của hệ thống, chúng ta cần phải kết hợp các hiệu ứng của nhiều máy trạng thái với nhau

Ngược lại khung nhìn tương tác trong tiếp cận thứ hai sẽ cung cấp một khung nhìn tổng thể về hành vi của một tập các đối tượng Khung nhìn này được mô hình hóa bởi các tương tác trên các phân lớp có cấu trúc (structured classifiers) và các cộng tác (collaborations)

2.3.1 Khái niệm cơ sở cho biểu đồ tương tác

Phân lớp có cấu trúc Phân lớp có cấu trúc là một siêu lớp (metaclass) biểu diễn một phân lớp (classifier) mà hành vi của nó có thể được mô tả ở dạng cộng tác giữa các thể hiện

Tương tác (interaction) Hành vi có thể được mô tả bằng cách chỉ ra chuỗi thông điệp trao đổi giữa các đối tượng trong một khung cảnh tương tác được xác định bởi một phân lớp có cấu trúc hay một cộng tác Hành vi được mô tả theo cách đó được gọi là một tương tác Một thể hiện của tương tác sẽ tương ứng với một thể hiện của khung cảnh của nó, trong đó, các vai trò sẽ tương ứng với các đối tượng; các thông điệp giữa các vai trò qua các đường kết nối (connectors) sẽ trở thành các thông điệp trao đổi giữa các đối tượng thông qua các liên kết (links) Một phân lớp có cấu trúc hay một cộng tác có thể có nhiều tương tác Các tương tác thường được dùng để mô tả sự thực thi của các thao tác Các tham số của các thao tác đó sẽ trở thành các vai trò (roles) trong sự cộng tác tương ứng với sự thực thủ đô

Thông điệp Thông điệp là sự giao tiếp một chiều giữa hai đối tượng ở dạng luồng điều khiển cùng với các thông tin đính kèm từ người gửi đến người nhận

Thông điệp có thể có các tham số để truyền các giá trị từ người gửi đến người nhận

Thông điệp có thể là một tín hiệu (signal - được truyền không đồng bộ từ các đối tượng ngoài) hoặc một lời gọi (call - tương ứng với sự thực thi một thao tác) Sự tạo mới một đối tượng có thể được mô hình hóa bằng một thông điệp gửi từ đối tượng tạo đến chính nó Mỗi thông điệp thường được gắn với hai sự kiện, sự kiện gửi và sự kiện nhận Chuỗi các sự kiện và các thông điệp có thể được biểu diễn trong hai loại biểu đồ tương tác: biểu đồ tuần tự và biểu đồ giao tiếp

Biểu đồ tuần tự tập trung vào trình tự thời gian của các thông điệp Nó biểu diễn tương tác ở dạng biểu đồ hai chiều Chiều dọc là trục thời gian, tỉnh từ trên xuống

Chiều ngang chỉ ra các vai trò đối tượng tham gia cộng tác Mỗi vai trò được tái hiện bởi một cột dọc gồm hai phần, phần tiêu đề thường là phần khai báo thể hiện lớp và phần đường thẳng dọc gọi là đường chu kỳ sống (lifeline) Thời gian đối tượng tồn tại sẽ được biểu diễn bằng đường đứt nét Trong khoảng thời gian thực hiện của một thủ tục đối tượng, đường chu kỳ sống sẽ là đường nét đội

Một thông điệp được biểu diễn ở dạng đường mũi tên từ đường chu kỳ sống của một đối tượng gửi đến đối tượng nhận Các mũi tên này được sắp xếp theo trình tự thời gian từ trên xuống Khác với các thông điệp đồng bộ, các thông điệp không đồng bộ sẽ được biểu diễn đường mũi tên ở đầu không được tổ đặc Hình 2.16 minh họa cho biểu đồ tuần tự với các thông điệp không đồng bộ

Một đặc tả thực thi (activation) biểu diễn quá trình thực hiện của một thủ tục, bao gồm cả khoảng thời gian thực thi các tiến trinh con trong nó Như được đề cập ở trên, nó được biểu diễn bởi các đường nét đôi trong đường chu kỳ sống của đối tượng Một thông điệp lời gọi đồng bộ sẽ được biểu diễn bởi đường mũi tên có đầu là tam giác được tô Đường mũi tên đứt nét biểu diễn sự trả điều khiển từ một thông điệp lời gọi Một lời gọi đệ quy xảy ra khi luồng điều khiển quay lại và kích hoạt thao tác trên đối tượng lần nữa, những đặc tả thực thi cho lời gọi thứ hai này là phân tách với đặc tả trước đó Hình 2.17 minh họa cho đặc tả thực thì với các thông điệp đồng bộ

Với các luồng điều khiển phức tạp, chúng ta có thể dùng các phân đoạn (combined fragments), như minh họa trong Hình 2.18 Mỗi phân đoạn có một từ khóa và một hay nhiều các đoạn con (được gọi là các toán hạng tương tác – interaction operands)

Một tương tác có thể tham chiếu đến các tương tác khác thông qua đoạn tương tác nhãn ref Tương ứng với các cấu trúc điều khiển trong các ngôn ngữ lập trình như lập, rẽ nhánh, lựa chọn và song song chúng ta có các phân đoạn khác nhau với các nhân tương ứng là loop, alt, opt, và par

Khác với biểu đồ tuần tự, biểu đồ giao tiếp tập trung vào các quan hệ giữa các đối tượng tham gia cộng tác Biểu đồ giao tiếp biểu diễn một tương tác dựa vào khung cảnh được xác định bởi phân lớp cấu trúc tương ứng Các vai trò (roles) và các đường kết nối (connectors) sẽ mô tả cấu hình của các đối tượng và các liên kết giữa chúng cho các lẫn thực thi trong mỗi thể hiện của khung cảnh đó Với một thể hiện của khung cảnh, các đối tượng sẽ thay cho các vai trò và các liên kết đối tượng sẽ thay cho các đường kết nối

Thông điệp giữa các vai trò được biểu diễn bằng các mũi tên gán nhãn được gắn với các đường kết nối Mỗi thông điệp có số thứ tự, tên thông điệp, danh sách tham số và các trường tùy chọn như điều kiện cạnh hay giá trị trả về Trong một số trường hợp, số thứ tự thông điệp có thể gắn với tên của luồng xử lý Tất cả các thông điệp trong cùng luồng xử lý là được đánh số tuần tự Thông điệp trong các luồng khác nhau nhìn chung diễn ra đồng thời trừ khi có một sự phụ thuộc tường minh về trình tự Hình 2.19 minh họa cho biểu để giao tiếp

Biểu đồ giao tiếp và biểu đồ tuần tự đều biểu diễn các cộng tác nhưng chúng chú trọng vào các khía cạnh khác nhau Biểu đồ tuần tự chỉ rõ trình tự thời gian của các thông điệp, nhưng không làm rõ các quan hệ đối tượng Trong khi đó, biểu đồ giao tiếp chỉ rõ ràng buộc các quan hệ đối tượng, tuy nhiên, trình tự thời gian chỉ được suy ra từ các chỉ số thông điệp Biểu đồ tuần tự thường được dùng để biểu diễn các kịch bản; biểu đồ giao tiếp thường được dùng để biểu diễn thiết kế chi tiết cho các thủ tục Một khi cấu trúc thủ tục được xác định, biểu đồ tuần tự có thể được dùng để làm mịn các chỉ tiết điều khiển của các thủ tục

2.3.4 Mô hình hóa với biểu đồ tương tác

Biểu đồ tương tác được dùng để mô hình hóa các khía cạnh động của hệ thống

Biểu đồ lớp

Trong phần này chúng ta tập trung vào biểu đồ lớp như là một dạng biểu diễn khung nhìn tĩnh (static view) của hệ thống Khung nhìn tĩnh là nền tảng cơ bản của UML Các phần tử của khung nhìn tỉnh của mô hình là các khái niệm trong miền ứng dụng, bao gồm: các khái niệm thế giới thực, các khái niệm trừu tượng, các khái niệm cái đặt, các khái niệm máy tính, và nhìn chung, tất cả các khải niệm có trong hệ thống Chẳng hạn, hệ thống quản lý đăng ký khóa học có các khái niệm như sinh viên, giảng viên, môn học, khóa học, các thuật toán về thời khóa biểu, và các trang web để đăng ký Khung nhìn tĩnh phản ánh cấu trúc đối tượng của hệ thống Cấu trúc dữ liệu và các đặc điểm hành vi được thống nhất trong cấu trúc đối tượng Khung nhìn tĩnh mô tả các khai báo hành vi dưới dạng khai báo các thao tác Nó không mô tả chi tiết về hành vi động như các khung nhìn tương tác hay khung nhìn máy trạng thái Phần tử chính trong khung nhìn tĩnh là các phân lớp (chẳng hạn như lớp, giao diện và kiểu dữ liệu) và quan hệ giữa chúng (kết hợp, tổng quát hóa và quan hệ phụ thuộc) Trong khung nhìn này, mỗi đối tượng là một đơn vị cơ bản làm nền hệ thống và gói là đơn vị tổ chức chung để quản lý các nội dung của mô hình Hình 2 20 minh họa cho biểu đồ lớp

2.4.1 Khái niệm cơ sở cho khung nhìn tĩnh

Phân lớp Phân lớp biểu diễn một khái niệm rời rạc mô tả các sự vật, đối tượng có định danh, trạng thái, hành vi và quan hệ Các loại phân lớp bao gồm lớp, giao diện và kiểu dữ liệu Nó cũng bao gồm các khái niệm hành vi, các sự vật trong mỗi trường hoặc các cấu trúc cài đặt Phân lớp hành vi gồm có ca sử dụng, tác nhân, cộng tác, thành phần và các nút, cũng như vô số kiểu hành vi khác

Lớp Lớp tái hiện một khái niệm rời rạc trong ứng dụng được sử dụng để biểu diễn sự vật theo một loại nào đóc sự vật vật lý (như máy bay), sự vật nghiệp vụ (như phiếu đặt vẽ), sự vật login (như lịch trình bay), sự vật trong miền máy tính (như bảng băm) hoặc sự vật hành vi (như một công việc) Lớp mô tả một tập các đối tượng chung về cấu trúc, hành vi và các quan hệ Cấu trúc và đặc điểm của đối tượng được tái hiện bằng các giá trị thuộc tỉnh Hành vi đối tượng được tái hiện bằng các thao tác đối tượng Lớp cung cấp các khai báo thuộc tỉnh và thao tác của các đối tượng

Lớp xác định một tập các đối tượng có trạng thái và hành vi Trạng thái đối tượng được mô tả bởi các thuộc tỉnh và các liên kết Hành vi của lớp được mô tả bởi các thao tác mà hiện thực hóa của nó là các phương thức lớp

Giao diện Giao diện là sự mô tả hành vi của các đối tượng mà không đề cập đến phần cài đặt và trạng thái đối tượng Giao diện có thể được hiện thực hóa bởi một hay nhiều lớp hoặc thành phần Mỗi lớp cài đặt các thao tác được đề cập trong giao diện

Kiểu dữ liệu Kiểu dữ liệu nguyên thủy là sự mô tả các giá trị nguyên thủy mà bản thân nó không có định danh (tồn tại độc lập và không chứa hiệu ứng phụ) Kiểu dữ liệu nguyên thủy bao gồm các con số và các xấu Nó không có thuộc tỉnh nhưng có thể có các thao tác Các thao tác không sửa đổi giá trị dữ liệu mà chỉ trả lại giá trị kết quả Người dùng có thể tự định nghĩa các kiểu liệt kê Phần tử của kiểu liệt kê có thể được sử dụng như các giá trị

Cấp độ ngữ nghĩa Trong một mô hình, các lớp có thể tồn tại ở các cấp độ khác nhau về ngữ nghĩa như cấp độ phân tích, thiết kế, và cài đặt Lớp ở cấp độ phân tích phản ảnh một khái niệm logic của ứng dụng hay trong miền ứng dụng Mô hình phân tích thường tái hiện một cách cơ bản về hệ thống, vừa đủ để phản ảnh cốt lõi logic của hệ thống, bỏ qua các chi tiết cải đặt Trong khi đó, lớp ở cấp độ thiết kế tái hiện các quyết định về tổ chức nhóm góp các thông tin và các thao tác vào một đơn vị cấu trúc rời rạc Nó chứa dựng cả yếu tố thế giới thực lẫn các yếu tố của hệ thống máy tính Lớp ở cấp độ cái đặt có thể được ánh xạ trực tiếp vào mã nguồn của ngôn ngữ lập trình

2.4.2 Quan hệ trong khung nhìn tĩnh

Quan hệ giữa các phân lớp gồm có quan hệ kết hợp, tổng quát hóa và các quan hệ phụ thuộc như quan hệ hiện thực hóa và quan hệ sử dụng

Quan hệ kết hợp mô tả các kết nối ngữ nghĩa giữa các đối tượng Nó là cơ sở để các đối tượng thuộc các lớp khác nhau tương tác với nhau Thể hiện của một quan hệ kết hợp là một liên kết đối tượng (link) Điểm kết nối giữa một kết hợp và một lớp tham gia là một mẫu kết hợp (association end) Thông tin về kết hợp chủ gọi yếu được biểu diễn ở các mẫu kết hợp, gồm có tên vai trò (rolnames), lực lượng kết hợp (multiplicity), và phạm vi truy cập (visibility), như minh họa trong Hình 2.21

Quan hệ kết hợp có thể có các thuộc tính Sự phức hợp giữa một quan hệ kết hợp với một lớp được gọi là lớp kết hợp (association class), như minh họa trong Hình 2.22

Hình 2.23 biểu diễn các thuộc tỉnh thiết kế của các quan hệ kết hợp, bao gồm hướng có thể truyền thông điệp (navigability direction), phạm vi truy cập (visibility), tính có thứ tự (odering property) hay sự rằng buộc về khả năng thay đổi

(changeability constraint) Như đã trình bày trong mục 2.1.4, quan hệ tụ hợp và quan hệ hợp thành là các dạng quan hệ kết hợp đặc biệt, loại quan hệ giữa tổng thể và bộ phận (wholepart)

Tổng quát hóa là loại quan hệ đặc biệt hỏa tổng quát hóa trong đó các đối tượng của phần tử đặc biệt hóa là có thể được thay thế bởi các đối tượng của phần từ khái quát hóa Ký pháp tổng quát hóa được minh họa như Hình 2.24

2.4.2.3 Kế thừa và đa kế thừa (inheritance)

Kế thừa là một cơ chế cho phép mô tả các đối tượng của một lớp bằng cách kết hợp phần khai bảo của chính nó và các phần khai bảo từ các lớp cha của nó Cơ chế này cho phép tạo ra các phần chia sẻ giữa các lớp Khi một lớp kế thừa từ nhiều lớp, chúng ta gọi là đa kế thừa Về mặt biểu diễn, quan hệ kế thừa trùng với quan hệ tổng quát hóa Sự khác nhau ở đây là hướng của các quan hệ: kế thừa xem xét từ trên xuống và tổng quát hóa là từ dưới lên

Hiện thực hóa là quan hệ ngữ nghĩa giữa các phân lớp (classifiers), trong đó một phân lớp đặc tả cam kết mà phân lớp kia phải đảm bảo đáp ứng và thực thi Quan hệ hiện thực hóa mà chúng ta thường gặp là quan hệ giữa giao diện và thành phần thực thi, hoặc là quan hệ giữa ca sử dụng và cộng tác hiện thực hóa chúng Ký pháp đồ họa cho hiện thực hóa được minh họa trong Hình 2.25

Biểu đồ trạng thái

Khung nhìn biểu đồ trạng thái mô tả hành vi động của các đối tượng theo thời gian bằng cách mô hình hóa vòng đời của các đối tượng của lớp Mỗi đối tượng được xem như một thực thể độc lập giao tiếp với phần còn lại của thế giới thông qua các sự kiện Sự kiện (event) tái hiện các kiểu thay đổi mà đối tượng có thể phát hiện

Gồm có (1) sự tiếp nhận các lời gọi hay tin hiệu tưởng minh từ đối tượng gửi đến đối tượng khác, (2) sự thay đổi các giá trị, và (3) sự thay đổi về thời gian Bất kỳ cái gì có thể tác động đến đổi tượng đều được xem là một sự kiện Các diễn biến bên ngoài thể giới thực sẽ được mô hình như các tín hiệu được gửi từ thế giới bên ngoài đến hệ thống

Trạng thái (state) là một tập giá trị đối tượng của một lớp, có cùng một phản hồi định tính đến các sự kiện xảy ra Nói cách khác tất cả các đối tượng cùng một trạng thái sẽ phản ứng theo cùng một cách đối với một sự kiện Do đó, tất cả các đối tượng trong trạng thái đó sẽ thực hiện cùng một hành động hay hoạt động khi chúng tiếp nhận cùng sự kiện Một máy trạng thái mô tả các trạng thái mà một đối tượng có thể có Với mỗi trạng thái, máy trạng thái đặc tả các hệ quả của việc nhận các loại sự kiện, các hiệu ứng hoặc các thay đổi trước khi chuyển sang một trạng thái mới Máy trạng thái mô tả hành vi của lớp cũng như hình vi động của ca sử dụng, cộng tác hay phương thức

2.5.1 Khái niệm cơ sở cho biểu đồ trạng thái

Máy trạng thái Máy trạng thái là đô thị gồm các trạng thái và các chuyển trạng thái Thông thường một máy trạng thái được gắn với một lớp và mô tả phản hồi của thể hiện lớp với các sự kiện mà nó nhận Máy trạng thái cũng có thể được gắn với các hành vi, các ca sử dụng và các cộng tác để mô tả sự thực thi của chúng Máy trạng thái mô hình hóa tất cả lịch sử vòng đời có thể có của các đối tượng của lớp

Khi đối tượng phát hiện một sự kiện từ bên ngoài, tùy theo trạng thái hiện thời mà nó phản hồi theo các cách khác nhau Phản hồi ở đây bao gồm việc thực thì gây ra một hiệu ứng (trong một hoạt động hay hành động) và các thay đổi trước khi chuyển sang trạng thái mới

Sự kiện (event) Một sự kiện là một kiểu mà mỗi thể hiện của nó diễn đạt một sự xuất hiện (occurrence) tại một thời điểm nào đó Các sự kiện có thể có các tham số mô tả các thể hiện của nó, giống như trường hợp với các thuộc tỉnh của lớp Sau đây là một số loại sự kiện chúng ta thưởng gặp, sự kiện gọi (call event), sự kiện thay đãi (change event), sự kiện tín hiệu (signal event) hay sự kiện thời gian (time event)

Tín hiệu (Signal) Tín hiệu là một kiểu được dùng như là phương tiện giữa hai đối tượng, ở đây tiếp nhận tín hiệu là sự kiện gửi đến đối tượng nhận tín hiệu

Trạng thái (State) Máy trạng thái xác định các trạng thái được gần tên Một trạng thái có thể được mô tả trong ba cách khác nhau, bỗ trợ cho nhau: (1) Trạng thái là một tập các giá trị đối tượng, ở khía cạnh nào đó, tương tự nhau về mặt định tính;

(2) Trạng thái là giai đoạn thời gian mà đối tượng chờ một vài sự kiện nào đó diễn ra và (3) Trạng thái là giai đoạn thời gian mà đối tượng đang thực thi một hoạt động nào đó Trạng thái là đơn vị điều khiển để tạo nên máy trạng thái

Chuyển (Transition) Trong máy trạng thái, các trạng thái được kết nối với nhau thông qua các chuyển trạng thái Nhìn chung, một chuyển trạng thái gồm sự kiện kích hoạt (trigger), điều kiện canh (guard condition), các hiệu ứng, và trạng thái đích

Khi một chuyển diễn ra mà không có trạng thái đích, chúng ta gọi là các chuyển bên trong (internal transition) Khi chuyển trạng thái diễn ra và các hiệu ứng đã được hoàn thành, đối tượng sẽ chuyển sang trạng thái đích Quá trình này có thể kích hoạt hoạt động thoát (exit activity) hoặc hoạt động vào (entry activity) như minh họa trong Hình 2.29

Trạng thái phức hợp (composite state) Trạng thái phức hợp là trạng thái có thể được phân rã thành các vùng trong đó chứa một hay nhiều trạng thái con Các vùng có thể diễn ra đồng thời (được gọi là orthogonal state) hoặc diễn ra chỉ với một trong số các vùng (được gọi là nonorthogonal state) Ký pháp cho cấu trúc bên trong của trạng thái phức hợp được minh họa như trong Hình 2.30 và 2.31

2.5.2 Mô hình hóa biểu đồ trạng thái

Máy trạng thái chủ yếu được sử dụng để mô hình hóa vòng đời của các thể hiện của các lớp, các ca sử dụng và hệ thống Khi mô hình hóa vòng đời đối tượng, chúng ta tập trung đặc tả các sự kiện cũng như các phản hồi của hệ thống đối với các sự kiện Mô hình vòng đời đối tượng cũng liên quan đến việc xác định trình tự hóa đối tượng phản hồi các sự kiện, bắt đầu từ lúc nó được tạo cho đến khi nó bị hủy Chúng ta có thể tiến hành theo các bước sau:

- Thiết lập khung cảnh cho máy trạng thái, ở đó, đối tượng là thể hiện của lớp, ca sử dụng hay hệ thống Nếu khung cảnh ứng với một lớp hay ca sử dụng, xác định tất cả các lớp liên quan (có quan hệ kết hợp hay phụ thuộc), bao gồm cả các lớp cha của nó Các lớp này được tham chiếu trong các hành động hay các điều kiện liên quan đến chuyển Nếu khung cảnh là hệ thống, chúng ta cần thu hẹp tầm xem xét, chỉ tập trung vào một hành vi của hệ thống

- Thiết lập trạng thái khởi đầu và kết thúc của đối tượng Có thể chúng ta cần bổ sung các tiền và hậu điều kiện cho trạng thái khởi đầu và kết thúc một cách tương ứng

Biểu đồ hoạt động

Biểu đồ hoạt động (activity) là một đô thị gồm các nút và các luồng, tương ứng với luồng điều khiển xuyên suốt các bước tính toán Việc thực hiện này có thể vừa tuần tự và song song Một hoạt động liên quan đến cả các cấu trúc rẽ nhánh và đồng bộ Nó tương tự với sơ đồ khối, tuy nhiên khả năng diễn đạt của nó tốt hơn Sơ đồ khối chỉ hỗ trợ các cấu trúc tuần tự và rẽ nhánh

2.6.1 Khái niệm cơ sở cho biểu đồ hoạt động

Hoạt động (Activity) Biểu đồ hoạt động chứa các nút hoạt động Nút hoạt động tái hiện sự thực thi câu lệnh trong một thủ tục hoặc sự thực thi của một bước trong luồng công việc Các nút được kết nối bởi các luồng điều khiển và các luồng dữ liệu

Nút hoạt động thường bắt đầu thực hiện khi có các token (dấu hiệu hiện diện của sự điều khiển) trên mỗi luồng vào của nó Khi nút được thực hiện xong, sự thực thi sẽ tiếp tục với các nút kế tiếp theo các luồng ra của nó Các luồng hoạt động giống như các chuyển trạng thái trong máy trạng thái – chúng xảy ra chỉ khi sự thực thì đã hoàn thành — nhưng các hoạt động có thể rơi vào trạng thái chờ cho một số sự kiện đặc biệt nào đó

Biểu đồ hoạt động có thể chứa các nhánh cũng như có sự phân tách điều khiển thành các luồng song song Các hoạt động có thể được thực hiện đồng thời hoặc theo trình tự tùy ý Có một số nút điều khiển được định nghĩa trước để hỗ trợ các cấu trúc điều khiển khác nhau như các quyết định (rẽ nhánh) hay hợp nhất điều khiển (merge)

Các lá của đồ thị hoạt động là các hành động (action) Hành động là hoạt động cơ bản được định nghĩa trước, chẳng hạn như, tạo và hủy đổi tượng hay truy cập và sửa chữa thuộc tỉnh đối tượng Nút hoạt động được biểu diễn bởi một hình chữ nhật tròn góc, trong đó có phần mô tả hoạt động Luồng điều khiển được biểu diễn bởi một mũi tên Biểu đồ hoạt động cùng với các kỳ pháp của nó được minh họa như Hình 2.32

Phân vùng (partition) Chúng ta đôi khi cần phải nhóm góp các hoạt động trong một mô hình theo trách nhiệm, chẳng hạn, cần nhóm gộp các hoạt động trong một bộ phận phòng ban với nhau Chúng ta sử dụng ký pháp phân vùng để tổ chức các hoạt động theo các phân vùng khác nhau Chúng được phân tách bởi các đường thắng trong biểu đồ như minh họa trong Hình 2.33 Một phân vùng cũng thường được gọi là các làn bơi (swimlane)

Luồng đối tượng Biểu đồ hoạt động có thể chỉ ra luồng các giá trị đối tượng, cũng như luồng điều khiển Luồng đối tượng tái hiện một đối tượng là đầu vào hoặc ra của một hoạt động, như minh họa trong Hình 2.33

Hành động (action) UML định nghĩa một tập các hành động cơ bản để thao tác các đối tượng và các liên kết cũng như các tính toán và giao tiếp giữa chúng Các loại hành động được liệt kê theo các phân mục sau: (1) Liên quan đến tính toán, chúng ta có các hành động như tiếp nhận lời gọi, tiếp nhận sự kiện, đọc biển và ghi biến; (2) Liên quan đến điều kiển chúng ta có hành động bất đầu hành vi (startOwnedBehavior); (3) Các hành động tạo và hủy các đối tượng và liên kết (4) Các hành động đọc và ghi thông tin về liên kết đối tượng; (5) Các hành động liên quan thời gian như quan sát khoảng (durationObservation) hay quan sát thời gian (timeObservation)

2.6.2 Mô hình hóa biểu đồ hoạt động Đô thị hoạt động không nêu ra chi tiết đầy đủ của một tính toán Chủng biểu diễn luồng các hoạt động chứ không đề cập cách thức các đối tượng thực hiện các hoạt động đó Đồ thị hoạt động là điểm xuất phát cho thiết kế Để hoàn thành một thiết kế, mỗi hoạt động phải được cài đặt bởi một hay nhiều thao tác và mỗi thao tác sẽ được cài đặt theo một lớp cụ thể Theo cách đó, một cộng tác được thiết kế để cài đặt cho biểu để hoạt động Chúng ta sử dụng biểu đồ hoạt động để mô hình hóa một vài khía cạnh động của hệ thống Nhìn chung, khung cảnh áp dụng cho loại biểu đồ này có thể là một hệ thống, một hệ thống con, một thao tác hay một lớp Biểu đồ hoạt động còn được dùng để đặc tả các ca sử dụng và các cộng tác Mô hình hóa khía cạnh động của hệ thống với các biểu đồ hoạt động được tiến hành theo hai cách sau

2.6.2.1 Mô hình hóa luồng công việc (workflow)

Chúng ta tập trung vào các hoạt động được phản ánh bởi các tác nhân bên ngoài hệ thống Luồng công việc thường được dùng để trực quan hóa, đặc tả, xây dựng và làm tài liệu cho các tiến trình nghiệp vụ liên quan đến hệ thống Trong kỹ thuật này, mô hình hóa luồng đối tượng là đặc biệt quan trọng Chúng ta tiến hành theo các bước sau:

- Thiết lập cấp độ quan sát luồng công việc Đối với hầu hết các hệ thống, chúng ta thường không thể biểu diễn tất cả chỉ tiết của luồng công việc trên một biểu đồ

- Lựa chọn các đối tượng nghiệp vụ đóng vai trò chính trong luồng công việc Đó thường là các thực thể tương ứng với các từ vựng của hệ thống, hoặc có thể trừu tượng hơn Tạo các phân vùng (swimlane) cho mỗi đối tượng nghiệp vụ đó

- Xác định tiền điều kiện của trạng thái khởi đầu của luồng công việc và hậu điều kiện cho trạng thái kết thúc Việc này giúp chúng ta làm rõ biên của luồng công việc

- Bắt đầu với trạng thái khởi đầu, đặc tả các hoạt động và hành động diễn ra tiếp theo, biểu diễn ở dạng các trạng thái hoạt động hay hành động trong biểu đồ hoạt động

- Với các hành động phức tạp hoặc với các tập hành động xuất hiện nhiều lần, chúng ta có thể tách ra biểu diễn thành một biểu đồ hoạt động riêng

Biểu đồ thành phần

Thành phần tái hiện các mô đun của hệ thống logic hay vật lý theo cách các hành vi có thể quan sát từ bên ngoài của thành phần có thể được mô tả một cách cô đọng hơn so với bản cài đặt của nó Một thành phần không phụ thuộc trực tiếp vào các thành phần khác mà phụ thuộc vào các giao diện được cung cấp bởi các thành phần

Thành phần trong mô hình có thể được thay thế bởi các thành phần hỗ trợ cùng các giao diện của thành phần Thể hiện của thành phần trong một cấu hình hệ thống cũng có thể được thay thế bằng một thể hiện của các thành phần tương ứng

Thành phần có các giao diện cung cấp (provided interfaces) và các giao diện được yêu cầu từ các thành phần khác (required interfaces) Sử dụng các giao diện cho phép chúng ta tránh được sự phụ thuộc trực tiếp giữa các thành phần, dễ cho việc tích hợp và thay thế các thành phần mới Biểu đồ thành phần chỉ ra mạng các phụ thuộc giữa các thành phần Kỳ pháp thành phần được minh họa như Hình 2.35

Thành phần thường có các cổng Các thông điệp được nhận trên các công khác nhau là khác nhau và thưởng được triển khai theo các cách khác nhau Thành phần có thể chứa các thành phần khác như là phần cài đặt của chúng, xem Hình 2.36 Biểu đồ thành phần thường được sử dụng trong hai tỉnh huống sau

1 Mô hình hóa các thực thi được (executables) và các thư viện

Biểu đồ thành phần thường được dùng để mô hình hóa các đơn vị triển khai làm nên bản cải đặt của hệ thống Đó là các bản thực thi được và các thư viện đối tượng liên quan Mô hình hóa thành phần cho phép chúng ta trực quan hóa, đặc tả, xây dựng và đưa ra các quyết định về việc tạo hệ thống vật lý Mô hình hóa thành phần cũng giúp chúng ta quản lý cấu hình và bao tri hệ thống tốt hơn Để mô hình hóa các phần tử thực thi và các thư viện liên quan, chúng ta tiến hành theo các bước sau:

- Xác định sự phân chia của hệ thống vật lý Xem xét các yếu tổ liên quan đến quản lý cấu hình, ràng buộc kỹ thuật và vấn đề sử dụng lại

- Biểu diễn các thực thì được hay các thư viện ở dạng các thành phần

Trong một số trường hợp, chúng ta cần sử dụng kiểu mở rộng (stereotype) cho các thành phần có nghĩa chuyên biệt

- Xác định các giao diện thiết yếu mà các thành phần sử dụng hay hiện thực hóa

- Mô hình hóa các quan hệ giữa các thực thi được, các thư viện và các giao diện, đặc biệt là mối quan hệ phụ thuộc giữa chúng, xem Hình 2.37

2 Mô hình hóa các bảng, các tập và các tài liệu

Chúng ta có thể sử dụng biểu đồ thành phần để mô hình hóa các phần tử không thực thi được của hệ thống gọi là các thành phần phụ, như các bảng, các tập hay các tài liệu trợ giúp Đây là một phần nội dung quan trọng trong quản lý cấu hình Trong hoạt động này, chúng ta cần chỉ ra được quan hệ phụ thuộc giữa các thành phần thực thì và các thành phần phụ, như minh họa trong Hình 2.38

Ngoài ra biểu đồ thành phần còn có thể được dùng trong một số tình huống khác như mô hình hóa các giao diện lập trình ứng dụng (api) cũng như mã nguồn chương trình.

Biểu đồ triển khai

Khung nhìn triển khai (deployment view) phản ánh cách bài trí vật lý của các nút

Nút là một nguồn lực tài nguyên tính toán như máy tính hay các thiết bị khác Lúc thực thi, nút có thể chứa các chế tác, các thực thể vật lý như các tập Quan hệ hiện thân (manifestation relationship) chi mối liên hệ giữa các phần tử thiết kể (các thành phần và các chế tác hiện hữu trong hệ thống phần mềm) Khung nhìn triển khai giúp đánh giá hiệu năng thực thi của thống, làm rõ các trình diễn dẫn đến tắc nghẽn do cách phân bố các chế tác (sự hiện thân của các thành phần) trên các nút xử lý

Nút (node) Nút mô hình hóa một nguồn lực tính toán lúc thực thi, thường có ít nhất một bộ nhớ và các năng lực xử lý Nút có thể mở rộng với các nghĩa cụ thể (stereotypes) như CPU, các thiết bị hay các bộ nhớ Ký pháp của nút được minh họa như Hình 2.39 Quan hệ kết hợp giữa các nút thường tái hiện phương thức giao tiếp giữa các nút Giữa các nút có thể có các quan hệ tổng quát hóa Nút thường có quan hệ phụ thuộc lên các thành phần được phân bố trên nó

Chế tác (artifact) Chế tác biểu diễn một thực thể vật lý như tập, cơ sở dữ liệu, hay trang web Sự hiện diện của chế tác trên một núi được diễn đạt bằng cách gắn kỷ pháp chế tác () vào trong ký pháp nút

Chúng ta có thể sử dụng biểu đồ triển khai trong hai trường hợp sau

1 Mô hình hóa các bộ xử lý và các thiết bị

Chúng ta sử dụng cơ chế mở rộng của UML (stereotypes) để biểu diễn các bộ xử lý (processor) và các thiết bị (devices) ở dạng các nút, xem Hình 2.40 Nút xử lý có năng lực xử lý và khả năng thực thi các thành phần Nút thiết bị không có năng lực xử lý Nó thường tái hiện các sự vật thực hiện tương tác với thế giới thực qua các giao diện Để mô hình hóa bộ xử lý và các thiết bị, chúng ta tiến hành theo các bước sau:

- Xác định các phần tử tính toán của khung nhìn triển khai và biểu diễn chúng ở dạng các nút

- Sử dụng các stereotype để biểu diễn các phần tử tương ứng là bộ xử lý hay thiết bị

- Xem xét các thuộc tỉnh và thao tác được cài đặt trên các nút khi mô hình hóa lớp

2 Mô hình hóa sự phân tán của các thành phần Để mô hình hóa sự phân tán của các thiết bị trên các bộ xử lý và các thiết bị, chúng ta tiến hành theo các bước sau:

- Với mỗi thành phần của hệ thống, phân bố nó trên một nút xử lý

- Xem xét khả năng phân bố (sao chép) một thành phần trên nhiều vị trí Thường cùng một kiểu thành phần (như các tập thư viện), ít khi chúng được phân tách và lưu trú đồng thời trên nhiều nút

- Biểu diễn phân bố theo một trong ba cách: (1) Đưa vào phần đặc tả của nút thay vì biểu diễn trực quan sự phân bố đó; (2) Sử dụng các quan hệ phụ thuộc để kết nối mỗi nút với các thành phần triển khai trên nó; (3) Liệt kê các thành phần được triển khai trên một nút trong một ngăn mở rộng của kỳ pháp nút, như minh họa trong Hình 2.41.

TỔNG QUAN VỀ QUY TRÌNH PHÁT TRIỂN PHẦN MỀM HƯỚNG ĐỐI TƯỢNG

Quy trình phát triển hướng đối tượng

Các sản phẩm phần mềm được phát triển theo phương pháp truyền thống như phương pháp hướng chức năng thường có chất lượng kém, thiếu hụt các tiêu chí chất lượng quan trọng, đặc biệt là tính bảo trì được Qua thực tiễn công nghiệp phần mềm, người ta đã tổng hợp được các triệu chứng căn nguyên nhất của vấn đề phát triển phần mềm và đề xuất bộ kinh nghiệm thực hành với các khuyến cáo và chỉ dẫn để khắc phục các triệu chứng đó Đó là động cơ và tư tưởng cốt lõi cho sự ra đời của phương pháp luận hướng đối tượng Quy trình phát triển RUP (Rational Unified Process) là một trong những quy trình phát triển hướng đối tượng được đề xuất và áp dụng rộng rãi

3.1.1 Các triệu chứng của vấn đề phát triển phần mềm

Trong kỹ thuật phần mềm, chúng ta có thể hiểu triệu chứng (symptoms) là dấu hiệu về sự tồn tại các vấn đề xấu trong phần mềm Bằng cách xử lý những căn nguyên, chúng ta có thể hạn chế được những triệu chứng, bằng cách hạn chế những triệu chứng, chúng ta có thể phát triển phần mềm chất lượng cao theo định hưởng lập và dự đoán được

Chẳng hạn, như minh họa trong Hình 3.1, triệu chứng "Các mô dun không ghép nối được" thường bắt nguồn từ hai căn nguyên “Giao tiếp nhập nhằng” và “Tồn tại phí nhất quán" Và giải pháp khắc phục ở đây là “Mô hình hóa trực quan" và "Kiểm tra liên tục”

3.1.2 Bộ kinh nghiệm thực tiễn

Bộ kinh nghiệm thực tiễn ("Best Practices") là tập các phương pháp phát triển phần mềm đã được kiểm nghiệm bằng các phần mềm thương mại Tính đúng đắn của chúng đã được khẳng định thông qua quá trình được sử dụng thường xuyên và thành công trong công nghiệp và các tổ chức Bộ kinh nghiệm thu được từ hàng ngàn khách hàng thực hiện trên hàng ngàn dự án và từ các chuyên gia phần mềm

Với các nội dung của bộ kinh nghiệm, đảm bảo sự tổng thể tốt hơn bảo đảm từng phần Mỗi thành tố của bộ kinh nghiệm, trong một số trường hợp, có thể ảnh hưởng đến các thành tố khác Ví dụ, trong Hình 3.2, thành tổ “Phát triển phần mềm lập" hỗ trợ 5 thành tố còn lại và ngược lại Nếu quy trình lập được thực hiện mà không có quản lý yêu cầu phủ hợp có thể dẫn đến thất bại trong việc đưa ra một giải pháp tập trung Các yêu cầu hệ thống có thể thay đổi khi cần thiết nhưng người sử dụng có thể không đồng ý sự thay đổi này

Khi các yêu cầu được quản lý chặt chẽ, điều này ít khi xảy ra Thay đổi yêu cầu là dự đoán được, và có thể đánh giá ảnh hưởng của nó đến quy trình phát triển trước khi thay đổi được chấp nhận Sự ổn định của các yêu cầu được bảo đảm

Phát triển lập là một kỹ thuật được sử dụng để chuyển các chức năng của hệ thống vào một chuỗi liên tục các phiên bản hoàn thiện tăng dần Mỗi phiên bản được phát triển trong một khoảng thời gian cố định, gọi là vòng lặp Mỗi vòng lặp tập trung vào định nghĩa, phân tích, thiết kế, xây dựng và kiểm thử một tập các yêu cầu Các vòng lặp đầu tiên hưởng đến các rủi ro cao nhất Mỗi vòng lập bao gồm việc tích hợp, kiểm thử và đưa ra một phiên bản thực hiện được Vòng lặp giải quyết các vấn đề sau:

- Giải quyết các rủi ro lớn trước khi đầu tư - Sớm nhận được các phản hồi của người sử dụng

- Làm cho việc kiểm thử và tích hợp diễn ra liên tục

- Định nghĩa các mốc ngắn hạn cho dự án

- Làm cho việc cài đặt của một phần thực thi được sẵn sàng

Thay vì phát triển toàn bộ hệ thống trong một số bước cố định, sự tăng thêm (ví dụ một tập con các chức năng) được lựa chọn và phát triển, tiếp đó là các sự tăng thêm khác Sự lựa chọn của bước tăng thêm đầu tiên được phát triển dựa trên sự rủi ro, với mức độ ưu tiên cao nhất về rủi ro Nhằm hướng đến một số rủi ro, chúng ta thường chọn tập các ca sử dụng liên quan Phát triển một tập tối thiểu các ca sử dụng cho phép kiểm chứng (thông qua một tập kiếm thử thực hiện được) các nguy cơ được chọn Sau đó lựa chọn tiếp các sự tăng thêm hướng đến các rủi ro cao tiếp theo, và cứ tiếp tục như vậy

Theo ước lượng của các chuyên gia, chỉ một số ít các dự án phát triển phần mềm hoàn thành đúng hạn và kinh phí Trong đó, tỷ lệ thành công chỉ 20%, trong khi các dự án đối diện với các thách thức (chậm, chỉ quá kinh phí dự toán) là 50% Các dự án thất bại là 30% Các thất bại này bắt nguồn từ nguyên nhân định nghĩa yêu cầu phần mềm không chính xác và quản lý yêu cầu không tốt trong quá trình phát triển phần mềm Các khía cạnh của quản lý yêu cầu phần mềm bao gồm:

- Phân tích vấn đề - Hiểu sự mong đợi của người sử dụng - Định nghĩa hệ thống

- Quản lý phạm vi - Làm mịn định nghĩa hệ thống - Quản lý thay đổi yêu cầu

3.1.2.3 Sử dụng kiến trúc thành phần

Kiến trúc là một phần của thiết kế Nó bao gồm các quyết định làm thể nào hệ thống được xây dựng Kiến trúc của một hệ thống phần mềm là một khía cạnh quan trọng nhất, nó có thể được sử dụng dễ điều khiển quy trình phát triển lập và tăng thêm của trong suốt vòng đời phát triển

Tính chất quan trọng nhất của kiến trúc là khả năng đàn hồi và linh động với sự thay đổi Để đạt được tính chất này, những người kiến trúc phần mềm phải dự đoán trước sự tiến triển trong cả miền lĩnh vực và công nghệ cài đặt để đưa ra một bản thiết kế có thể tính đến sự thay đổi này Các kỹ thuật chính là trừu tượng hóa, đóng gỏi, và phân tích thiết kế hướng đối tượng Kết quả là ứng dụng về cơ bản có thể bảo trì và mở rộng được

3.1.2.4 Mô hình hóa trực quan

Mô hình là sự đơn giản hóa của hiện thực, cung cấp một sự mỗ tả đầy đủ của một hệ thống từ một góc nhìn nào đó Chúng ta xây dựng mô hình để hiểu hơn về hệ thống, đặc biệt là các hệ thống phức tạp vì chúng ta không thể hiểu hết những hệ thống như vậy

Mô hình hóa là một hoạt động quan trọng vì nó giúp nhóm phát triển hiển thị, đặc tả, xây dựng và tài liệu hóa cấu trúc và hành vì của kiến trúc của hệ thống Sử dụng ngôn ngữ mô hình hóa chuẩn như UML, các thành viên trong nhóm phát triển có thể trao đối các quyết định về hệ thống với nhau

Sử dụng các công cụ mô hình hóa giúp chúng ta dễ dàng quản lý các mô hình này, có thể ấn hoặc hiện các chi tiết của mô hình theo ý muốn Mô hình trực quan cũng giúp chúng ta bảo đảm sự đồng nhất giữa các chế tác của hệ thống: yêu cầu, thiết kế, và cài đặt Tóm lại, mô hình hóa trực quan giúp nhóm phát triển cải thiện khả năng quản lý sự phức tạp của hệ thống Trong xây dựng mô hình trực quan, nhiều biểu đồ khác nhau được sử dụng để biểu diễn những cách nhìn khác nhau

UML cung cấp các ký pháp phong phủ để trực quan hóa mô hình (Xem chương 2)

3.1.2.5 Kiểm tra chất lượng thường xuyên

Chất lượng được sử dụng trong quy trình RUP, được định nghĩa là “Đặc điểm của việc đạt được một sản phẩm đáp ứng hoặc vượt các yêu cầu, được đo bởi các phép đo và tiêu chuẩn thỏa thuận, và được phát triển bởi quy trình thỏa thuận” Đưa ra định nghĩa này, đạt được chất lượng không đơn giản chỉ “đáp ứng các yêu cầu" hoặc sản xuất một sản phẩm đáp ứng mong muốn người sử dụng Chất lượng cũng bao gồm các phép đo và tiêu chuẩn (để chứng minh chất lượng đạt được) và việc thực thi một quy trình để đảm bảo rằng sản phẩm thu được đạt đến mức chất lượng mong muốn Các hoạt động kiểm tra được minh họa như Hình 3.3

Mô hình hóa nghiệp vụ

Mô hình hóa nghiệp vụ là cách tiếp cận chính thống và hiệu quà để nắm bắt các yêu cầu cho việc xây dựng các công cụ và hệ thống hỗ trợ nghiệp vụ Nó giúp chúng ta hiểu chính xác về quy trình nghiệp vụ – cơ sở quan trọng để đảm bảo tính đúng đắn của hệ thống được xây dựng Trong nhiều trường hợp, các phần tử của mô hình nghiệp vụ cung cấp các yếu tố cơ bản để xây dựng hệ thống Hơn nữa, từ góc nhìn được phản ánh bởi mô hình nghiệp vụ, mô hình hệ thống thông tin cần xây dựng thường được hình dung và xác định một cách dễ dàng hơn Sau đây là các khía cạnh chính được xem xét khi mô hình hóa nghiệp vụ:

- Định lượng dựa trên hoạt động nghiệp vụ là phương pháp luận do chi phí các hoạt động, các tài nguyên và các đối tượng liên quan Ở đây chúng ta có các mối quan hệ: Tài nguyên được cung cấp cho các hoạt động và hoạt động được thực hiện với các đối tượng dựa vào công dụng của chúng

- Kiến trúc nghiệp vụ phản ánh quan hệ tổ chức giữa các phần từ dựa trên chức năng của chúng Trong đó, các phần từ kiến trúc sẽ biểu diễn cấu trúc hành vi hay cấu trúc tổ chức của hệ thống nghiệp vụ Kiến trúc nghiệp vụ tập trung làm rõ tiến trình nghiệp vụ, cấu trúc tổ chức, văn hóa tổ chức, khía cạnh nhân lực và các khía cạnh miền nghiệp vụ

- Quy mô của các tổ chức phản ánh sự khác nhau về độ lớn và tính phức tạp của các nghiệp vụ trong tổ chức Quy mô thường dựa vào sự phân bố sản phẩm, tổng số lượng theo từng loại sản phẩm Nói chung là dựa vào độ phức tạp của sản phẩm và sự phân tán của tổ chức

- Phạm vi của mô hình nghiệp vụ phản ánh mức độ mô hình hóa được thực hiện tùy thuộc vào khung cảnh và nhu cầu Ở mức đơn giản nhất, hoạt động này cung cấp sơ đồ tổ chức để hiểu tốt hơn các yêu cầu về ứng dụng cần xây dựng Ở mức hai, hoạt động này tạo ra mô hình miễn nghiệp vụ Ứng dụng được xây dựng thường chỉ để quản lý và trình diễn thông tin Yếu tố luồng công việc của nghiệp vụ chưa được xem xét Ở mức ba, hoạt động này cung cấp mô hình nghiệp vụ cho nhiều hệ thống Mô hình này giúp cho việc tìm ra các yêu cầu chức năng hệ thống, là đầu vào cho việc xây dựng kiến trúc của họ các ứng dụng Ở mức bốn, mô hình nghiệp vụ tổng quát được xây dựng Mô hình này đưa ra các hoạt động nghiệp vụ chung cho các tổ chức cũng như cung cấp các tùy chọn ứng với các đặc thù của từng tổ chức Ở mức độ năm, hoạt động này hỗ trợ việc xây dựng quy trình nghiệp vụ mới cũng như việc bổ sung nghiệp vụ mới của

3.2.1 Mục đích của mô hình hóa nghiệp vụ

Mô hình hóa nghiệp vụ hưởng đến các mục đích sau:

- Để hiểu được cấu trúc và khía cạnh động của tổ chức trong đó hệ thống được triển khai

- Để hiểu được vấn đề thực tại của tổ chức, xác định các cái tiến nhằm nâng cao hiệu quả của tổ chức

- Để đảm bảo cái hiểu thống nhất về tổ chức giữa khách hàng, người dùng cuối và người phát triển

- Để nắm bắt các yêu cầu hệ thống cần hỗ trợ cho tổ chức

Với các các mục đích này, RUP đề ra các nguyên lý mô hình hóa nghiệp vụ, mô tả làm thể nào để xây dựng cái nhìn tổng quan về tổ chức mới Để từ đó xác định được các tiến trình, vai trò và trách nhiệm của tổ chức và biểu diễn chúng bằng mô hình ca sứ dụng nghiệp vụ và mô hình đối tượng nghiệp vụ

3.2.2 Hoạt động mô hình hóa nghiệp vụ

Nhìn chung, mô hình hóa nghiệp vụ được thực hiện bởi hai hoạt động chính sau:

- Tìm tác nhân nghiệp vụ: Tác nhân nghiệp vụ là các cá nhân, các nhóm, các tổ chức, cơ quan, các hệ thống tương tác với nghiệp vụ đó Chẳng hạn: các khách hàng, các đối tác, các nhà cung cấp, cơ quan hành pháp, các chủ nhân, nhà đầu tư, các hệ thống thông tin ngoài nghiệp vụ đó

- Tìm các ca sử dụng nghiệp vụ: Để tìm các ca sử dụng nghiệp vụ, chúng ta xuất phát từ các tác nhân nghiệp vụ và phân tích các giá trị thu được của chúng từ các hoạt động nghiệp vụ Từ khía cạnh hỗ trợ nghiệp vụ, mỗi tiến trình được biểu diễn như là một ca sử dụng nghiệp vụ Chẳng hạn các hoạt động phát triển duy trì nhân sự sẽ tương ứng với một ca sử dụng nghiệp vụ Từ khía cạnh quản lý nghiệp mỗi tiến trình có thể được biểu diễn như là một ca sử dụng nghiệp vụ Chẳng hạn, chúng ta có các ca sử dụng nghiệp vụ, tương ứng với các hoạt động phát triển và cung cấp thông tin nghiệp vụ cho chủ nhân và các nhà đầu tư, hay các hoạt động thiết lập ngân sách dài hạn, tạo và điều khiển các tiến trình trong nghiệp vụ

3.2.3 Mô hình hóa nghiệp vụ với UML

Mô hình hóa nghiệp vụ là tập trung mô hình hóa về mặt nghiệp vụ, không về mặt hệ thống Chúng ta xây dựng các kiểu mở rộng (stereotype) với ngôn ngữ mô hình hóa UML để biểu diễn các mô hình nghiệp vụ Sau đây là bảng các kỷ pháp mở rộng để mô hình hóa nghiệp vụ:

3.2.4 Chuyển mô hình hóa nghiệp vụ sang mô hình ca sử dụng

Các mô hình nghiệp vụ xác định các đầu vào cho khung nhìn ca sử dụng và khung nhìn logic Chúng ta có thể đưa ra các nguyên lý chính để xây dựng mô hình phân tích:

- Mỗi ca sử dụng được hỗ trợ bởi hệ thống sẽ xác định một hệ thống con trong mô hình phân tích Hệ thống con này là trong tầng ứng dụng và được xem xét ngay trong lần phát triển lập đầu tiên

- Mỗi công nhân viên được hỗ trợ bởi hệ thống sẽ xác định các ca sử dụng được tự động hóa

- Mỗi thực thể nghiệp vụ được cung cấp bởi hệ thống sẽ xác định các lớp thực thể trong mô hình phân tích Một số trong chúng có thể xem xét như là các thực thể thành phần trong hệ thống

- Một nhóm các thực thể nghiệp vụ được sử dụng trong một ca sử dụng nghiệp vụ sẽ tạo ra một hệ thống trong tầng nghiệp vụ chuyên biệt

Chúng ta sẽ xác định các ca sử dụng của hệ thống thông tin dựa vào các công nhân viên trong mô hình đối tượng nghiệp vụ như minh họa trong Hình 3.5 Với mỗi công nhân viên, chúng ta thực hiện các bước sau:

- Xác định xem công nhân viên này sẽ sử dụng hệ thống thông tin hay không

- Nếu có thì sẽ xác định một tác nhân trong hệ thống thông tin

- Cho mỗi ca sử dụng nghiệp vụ và công nhân viên này tham gia sẽ xác định một hệ thống các ca sử dụng

- Lập lại các bước này cho tất cả các công nhân viên

Ví dụ, bằng cách phân tích công việc của công nhân viên “Nhân viên", như trong Hình 3.6, chúng ta xác định được tác nhân “Nhân viên" và ca sử dụng "Chuyển tiền 1" của hệ thống thông tin Hay từ công nhân viên "Thủ thư", chúng ta xác định được tác nhân “Thủ thư” và ca sử dụng "Chuyển tiền 2"

Trường hợp các công nhân viên được tự động hóa, nghĩa là chúng ta đang định hướng xây dựng một hệ thống mà các tiến trình nghiệp vụ được tự động hoàn toàn (chẳng hạn thương mại điện tử) thì các công nhân viên lúc này sẽ không chuyển thành tác nhân của hệ thống nữa mà lúc này chính các tác nhân nghiệp vụ sẽ là các tác nhân giao tiếp trực tiếp với hệ thống thông tin Khi đó trách nhiệm của công nhân viên được chuyển cho tác nhân nghiệp vụ, như minh hoa trong Hinh 3.7.

Nắm bắt yêu cầu

Nắm bắt yêu cầu là khâu diễn ra ngay trước hoạt động phân tích và thiết kế trong quá trình phát triển phần mềm Trong mục này, chúng ta sẽ tìm hiểu giao diện giữa hai khâu này Cụ thể, chúng ta sẽ tập trung vào các khái niệm chính về yêu cầu phần mềm, tác động của khâu nắm bắt yêu cầu đến hoạt động phân tích và thiết kế, và những chế tác được tạo ra trong khâu nắm bắt yêu cầu Qua đó chúng ta hiểu được các nguyên lý về nắm bắt yêu cầu, và có khả năng hiểu và diễn giải được các chế tác của khâu nằm bắt yêu cầu với tư cách là đầu vào cho phân tích và thiết kế trong từng dự án cụ thể

3.3.1 Mục đích của nắm bắt yêu cầu Để tìm ra giải pháp đúng cho một hệ thống phần mềm, chúng ta phải hiểu được vấn đề, cũng như những yêu cầu đặt ra cho hệ thống Câu hỏi đặt ra ở đây là “Để làm gi? (What to do?) Và bản chất của các hoạt động phát triển tiếp theo tử phân tích và thiết kế sang cài đặt và triển khai sẽ tìm ra giải pháp và những hiện thực hóa để trả lời cho những câu hỏi đỏ Làm như thể nào (How to do) Việc xác định và thu thập yêu cầu sai thường dẫn đến hệ thống được phát triển sai, không đáp ứng được mong đợi của khách hàng Do đó, nắm bắt yêu cầu là hoạt động rất quan trọng trong quá trình phát triển phần mềm

Thông thường nắm bắt yêu cầu được tiến hành ngay sau khẩu mô hình hóa nghiệp vụ, khi mà khung cảnh để tiến hành thu thập các yêu cầu hệ thống đã được phân tích và xác định Đối với các hệ thống không quá phức tạp thì khâu mô hình hóa nghiệp vụ thường được tiến hành ở dạng các tài liệu để mô tả nghiệp vụ và những thực trạng đặt ra Với các hệ phức tạp hơn, đòi hỏi phải xây dựng được các mô hình nghiệp vụ tường minh, hỗ trợ cho việc hiểu và phân tích hiện trạng của hệ thống Thứ tự tử mô hình hóa nghiệp vụ đến nắm bắt yêu cầu và chuyển qua phân tích thiết kế trong mỗi vòng đời hệ thống là được minh họa như Hình 3.4 Sau đây là những mục đích chính của khâu nắm bắt yêu cầu

- Nắm bắt yêu cầu để thiết lập và duy trì những thỏa thuận giữa khách hàng và các bên liên quan về những gì mà hệ thống nên làm

- Nắm bắt yêu cầu để cung cấp cho người phát triển một cái hiểu tốt hơn về các yêu cầu phần mềm

- Nắm bắt yêu cầu để xác định biên của hệ thống

- Nắm bắt yêu cầu để cung cấp một cơ sở cho việc lập kế hoạch những nội dung kỹ thuật trong các vòng lập của quá trình phát triển

- Nắm bắt yêu cầu là cơ sở cho việc đánh giá và ước lượng chi phi và thời gian phát triển hệ thống

- Nắm bắt yêu cầu định hình giao diện tương tác giữa người dùng và hệ thống, qua đó làm rõ được nhu cầu và mục tiêu của người dùng đối với hệ thống

Khâu phân tích và thiết kế nhận các chế tác đầu vào chính (mô hình ca sử dụng và từ điển thuật ngữ) được cung cấp từ khâu nấm bắt yêu cầu Các sai sót trong mô hình ca sử dụng có thể được tìm thấy trong khâu phân tích và thiết kế Theo đó các yêu cầu về thay đổi sẽ được tạo ra và cập nhật cho mô hình ca sử dụng

3.3.2 Chế tác cho mô hình yêu cầu

Phần này tập trung trình bày về các chế tác của khâu nắm bắt yêu cầu như là đầu vào định hướng cho khẩu phân tích và thiết kế hệ thống

Tài liệu phát biểu vấn đề là một phần của tài liệu tổng thế hệ thống Tài liệu này thường làm rõ thực trạng của hệ thống hiện thời, đặc biệt là các vấn đề và khó khăn đặt ra cho hệ thống hiện thời Qua đó, nó nêu ra được những lý do và động cơ chủ yếu để phát triển hệ thống mới Tài liệu này cũng bao gồm các ràng buộc khác nhau đặt ra cho hệ thống như các ràng buộc về kỹ thuật, thời gian hay nguồn lực

3.1.2.2 Mô hình ca sử dụng

Mô hình ca sử dụng mô tả những gì mà hệ thống sẽ làm Mô hình ca sử dụng chính là một sự cam kết giữa khách hàng, người dùng và người phát triển Một mặt nó cho phép khách hàng và người dùng kiểm tra xem hệ thống được xây dựng có đúng như mong đợi không Mặt khác nó cho phép người phát triển đảm bảo rằng hệ thống xây dựng là đúng với yêu cầu của khách hàng và người dùng Mô hình ca sử dụng bao gồm các ca sử dụng và các tác nhân, xem minh họa trong Hình 3.8 Mỗi ca sử dụng trong mô hình mô tả chi tiết về những gì mà hệ thống làm trong quá trình tương tác với tác nhân Nó phản ảnh chuỗi các sự kiện diễn ra trong từng kịch bản ca sử dụng Những mô tả này là được làm thành tài liệu, gọi là tài liệu đặc tả ca sử dụng (use case specification) Tài liệu này sẽ định hướng cho các hoạt động phân tích thiết kế về sau

Từ điển thuật ngữ bao gồm các thuật ngữ trong miền của hệ thống, được mô tả ở dạng văn bản và được dùng chung cho tất cả các mô hình của hệ thống Nó thưởng phát biểu định nghĩa các thuật ngữ quan trọng được sử dụng trong dự án Mục đích là cung cấp cho người phát triển một cách hiểu thống nhất để sử dụng chúng và tạo được sự thuận tiện trong giao tiếp

Từ điển thuật ngữ chủ yếu được tạo ra trong giai đoạn đầu của dự án, giai đoạn đòi hỏi sự thống nhất về các thuật ngữ được dùng Trong pha khởi đầu (Inception) và pha chi tiết (Elaboraton), các chuyên gia miền sẽ sử dụng từ điển thuật ngữ để giải thích các thuật ngữ chuyên ngành lĩnh vực của họ Nhờ đó, người phát triển mới có thể hiểu được chính xác các kịch bản trong ca sử dụng Ở pha chi tiết và pha xây dựng, từ điển thuật ngữ được sử dụng để diễn giải các thuật ngữ kỹ thuật trong các mô hình thiết kế

Người phân tích có trách nhiệm cập nhật và duy trì sự nhất quán trong tài liệu từ điển thuật ngữ Từ điển thuật ngữ thường được trình bày theo một định dạng riêng, tùy thuộc vào từng dự án

Tài liệu đặc tả bổ sung (Supplementary Specification) bao gồm các yêu cầu bổ sung quan trọng cho mô hình ca sử dụng, những yêu cầu không được đề cập trong mô hình ca sử dụng Tài liệu này củng với tài liệu ca sử dụng sẽ cung cấp thông tin đầy đủ cho một đặc tả yêu cầu về hệ thống

Các yêu cầu chức năng và phi chức năng trong tài liệu đặc tả bổ sung thường là các ràng buộc cho việc thực thi hệ thống Các rằng buộc có thể được phân lớp như sau

Ràng buộc chức năng: Gồm các yêu cầu chức năng được dùng chung và tham chiếu đến từ các ca sử dụng khác nhau

Tình có thể sử dụng được: Các yêu cầu liên quan đến khá năng có thể sử dụng được của hệ thống Chẳng hạn, các yêu cầu về tính dễ sử dụng hoặc các yêu cầu về đào tạo người dùng, trong đó chỉ rõ cách mà người dùng với tư cách là các tác nhân tương tác với hệ thống

Tinh có thể tin cậy được: Bao gồm bất cứ yêu cầu nào liên quan đến tính tin cậy của hệ thống Nó thường bao gồm các phát biểu về các độ đo, sự lượng hóa như thời gian trung bình giữa các lần thất bại hay số lỗi trên nghìn dòng lệnh

Phân tích và thiết kế

Phần này tập trung vào các khái niệm chính xuyên suốt hoạt động phân tích và thiết kế hệ thống Chi tiết của từng hoạt động phân tích và thiết kế sẽ được trình bày trong các mục tiếp theo Ở đây, chúng ta quan tâm đến khung cảnh chung cho những hoạt động này

3.4.1 Mục đích của hoạt động phân tích và thiết kế

Hoạt động phân tích và thiết kế được thực hiện cho ba mục dịch sau Thứ nhất, đây là hoạt động nhằm chuyển các yêu cầu thành một bản thiết kế hệ thống Thứ hai, phân tích và thiết kế là hoạt động để hình thành kiến trúc chắc chắn cho hệ thống

Thứ ba, phân tích thiết kế là hoạt động nhằm đưa ra giải pháp thiết kế thích ứng với môi trường cài đặt và các yếu tố ràng buộc về trình diễn và thực thi của hệ thống

3.4.2 Bước chuyển tiếp từ yêu cầu sang thực thi

Khâu phân tích và thiết kế được liên kết với các khâu còn lại trong tiến trình phát triển Đó là các khẩu, khẩu mô hình hóa nghiệp vụ cung cấp khung cảnh về mặt tổ chức của hệ thống Khâu nằm bắt yêu cầu cung cấp các đầu vào chính cho khâu phân tích và thiết kế Khâu kiểm thử đảm bảo hệ thống tuân thủ với thiết kế từ khâu phân tích và thiết kế Khâu môi trường phát triển và duy trì các chế tác nền tảng được sử dụng trong khâu phân tích và thiết kế Khâu quản lý lập kế hoạch dự án và các lần lập chuyển giao (được mô tả trong kế hoạch lập tăng dần)

Các chế tác đầu vào cho hoạt động phân tích gồm có mô hình ca sử dụng, từ điển dữ liệu và đặc tả bổ sung Kết quả của khẩu phân tích và thiết kế là mô hình thiết kế Đây là sự trừu tượng của mã nguồn, là bản phác thảo hướng dẫn để cấu trúc và tạo ra mà nguồn Mô hình thiết kế bao gồm các lớp thiết kế được cấu trúc trong các gói thiết kế Nó cũng chứa các mô tả về hiện thực hóa ca sử dụng thông qua các cộng tác đối tượng

3.4.3 Sự khác nhau giữa phân tích và thiết kế

Ranh giới giữa hoạt động phân tích và thiết kế là khá mờ nhạt Mục đích của hoạt động phân tích là để hiểu vấn đề và để bắt đầu tạo ra mô hình trực quan về hệ thống cần xây dựng Mô hình này thường được lý tưởng hóa và độc lập với công nghệ và môi trường thực thi Phân tích tập trung chuyển các yêu cầu chức năng thành các diễn đạt bằng các khái niệm phần mềm Ý tưởng chính ở đây là để hình thành một bản phác thảo mức cao về hệ thống Hành vi và cấu trúc của hệ thống sẽ được tái hiện thông qua sự cộng tác giữa các đối tượng Ở đó, hành vi và trách nhiệm của các đối tượng bước đầu được xác định Bước phân tích chi tiết này sẽ được chuyển tiếp sang khâu thiết kế cùng với các ràng buộc khác

Mục đích của hoạt động thiết kế là để làm mịn và chi tiết hóa mô hình phân tích (Analysis Model), để từ đó hình thành mô hình thiết kế (Design Model), tạo một bước chuyển liên tục sang phủ lập trình Đây là bước chuyển mô hình tiến sát với mã nguồn hơn, dễ diễn đạt bằng ngôn ngữ lập trình hơn Giải pháp để ra trong khẩu thiết kế phải thích ứng với môi trường thực thi và triển khai Mỗi trường thực thi (Implementation) là môi trường thuần túy cho “người phát triển” mà ở đó các ngôn ngữ lập trình, các công cụ tích hợp và định và các thiết bị phần cứng cho khâu triển khai (Deployment) được xác định và sử dụng

Trong mô hình hóa, chúng ta bắt đầu với mô hình đối tượng (Object Model) như là một sự phản ánh sát nhất về thế giới thực (-Analysis) Từ đó tìm ra các giải pháp tương ứng, trừu tượng hơn (và cơ bản hơn) cho một vấn đề được tổng quát hóa hơn (Design) Cốt lời của thiết kế phần mềm là nó cho phép chúng ta tạo ra các hình ảnh ẩn dụ (metaphors) về thế giới thực, làm thay đổi góc nhìn và bản chất của vấn đề và làm cho nó trở nên dễ được giải quyết hơn

3.4.4 Phân tích và thiết kế lấy kiến trúc làm trung tâm

Phân tích và thiết kế hướng đối tượng thường không diễn ra theo một chiều, không đơn thuần là phân rã từ trên xuống (top- dow) hay là tổng hợp từ dưới lên (bottom-up) Thực tế, chúng được định hưởng bởi các ca sử dụng Ca sử dụng mô tả cấu trúc và hành vi của hệ thống sẽ được xếp vào tầng giữa Từ tầng giữa này, các lớp phân tích được xác định Lớp phân tích có thể tương ứng với một hệ thống con và được chuyển dịch lên tầng trên Chúng cũng có thể tương ứng với các lớp thiết kế và được chuyển dịch xuống tầng dưới Như vậy, hoạt động phân tích diễn ra theo các chiều khác nhau, từ tầng trên xuống tầng giữa (top-to-middle), từ tầng giữa lên (middle-up), tử tầng giữa xuống dưới (middle-down) và từ tầng dưới lên tầng giữa

Nó cần được diễn ra theo tất cả các hướng này để thu được một hệ thống đúng

Các hoạt động phân tích và thiết kế thường lấy kiến trúc làm trung tâm Việc tạo ra và hợp lệ kiến trúc là mục tiêu chính trong các lần lập đầu của hoạt động phân tích và thiết kế Kiến trúc được tái hiện thông qua một số khung nhìn kiến trúc Mỗi khung nhìn chứa đựng các quyết định thiết kế chính Nói cách khác, các khung nhìn kiến trúc là sự trừu tượng hóa hay đơn giản hóa của thiết kế hệ thống, trong đó những đặc điểm quan trọng được làm rõ hơn bằng cách loại bỏ các yếu tố chi tiết Kiến trúc là một phương tiện quan trọng không chỉ cho phát triển một mô hình thiết kế tốt mà còn góp phần làm tăng chất lượng của bất kỳ mô hình nào được xây dựng trong quá trình phát triển hệ thống Kiến trúc hệ thống sẽ được mô tả trong tài liệu kiến trúc phần mềm Trong giáo trình này chúng ta sẽ không trình bày về cách tạo tài liệu kiến trúc Thay vào đó chúng ta sẽ thảo luận về những nội dung và ý nghĩa trong đó

Kiến trúc phần mềm là gì? Kiến trúc phần mềm chứa đựng một tập các quyết định thiết yếu về tổ chức hệ thống phần mềm Nó phản ảnh các khía cạnh cấu trúc (khía cạnh tĩnh), hành vi (khoa cạnh động) và cách tổ chức phân cấp trong hệ thống Về khía cạnh cấu trúc, kiến trúc phần mềm cho phép lựa chọn các phần tử cấu trúc và các giao diện tương tác giữa chúng để hình thành nên hệ thống Hành vi của hệ thống được mô tả thông qua các cộng tác giữa các phần tử cấu trúc đó Các phần tử cấu trúc và hành vi này có thể được nhóm gộp thành các hệ thống con của hệ thống

Thông thưởng cách tổ chức hệ thống đó được thực hiện theo kinh nghiệm thông qua các mẫu và kiểu kiến trúc có sẵn (Architecture Style d Patterns) Tóm lại, kiến trúc phần mềm được diễn đạt ở dạng biểu thức sau:

Kiến trúc = Các phần tử - Các khuôn dạng (forns) + Cơ sở hợp lý Ở đây, cơ sở hợp lý là thiết yếu cho việc đánh giá một kiến trúc tốt

Kiến trúc như là các ràng buộc cho khâu thiết kế và xây dựng Kiến trúc có thể xem như một tập các quyết định thiết yếu về thiết kế, là tập các ràng buộc bước đầu cho việc hình thành hệ thống Những ràng buộc này là rất quan trọng bởi vì chúng là các quyết định cơ sở, nền tảng cho thiết kế phần mềm Kiến trúc hình thành nên một khung công việc (framework) trên đó thiết kế phần mềm được hình thành Do đó, chúng ta có thể hiểu kiến trúc như là một dụng thiết kế mức cao, thiết kế chiến lược

Hoạt động của thiết kế kiến trúc sẽ là làm tăng tính xác định cho các hoạt động sau, những sáng tạo không cần thiết sẽ bị loại bỏ Thực tế khi mô hình phát triển chuyển dịch về sát mã nguồn thì các sáng tạo trở nên ít cần thiết hơn Đây là điều tốt bởi vì những nỗ lực sáng tạo khi đó sẽ được tập trung hơn cho hoạt động hiện thời

Chẳng hạn trong khâu thực thi, chúng ta cần sáng tạo để làm tăng chất lượng và cải thiện khả năng trình diễn của bản cài đặt

Kiến trúc phần mềm với mô hình "khung nhìn 4+1" (the "4+1 view" model) Kiến trúc là sự phức hợp của nhiều yếu tố được phân ảnh từ các bên liên quan khác nhau

PHÂN TÍCH HƯỚNG ĐỐI TƯỢNG

Phân tích kiến trúc

Tập trung vào kiến trúc phần mềm cho phép chúng ta hiểu cấu trúc của hệ thống (các thành phần và các gỏi) và phương thức mà các thành phần tích hợp và tương tác với nhau Phân tích kiến trúc là những bước đầu tiên để xác định các thành phần của hệ thống và quan hệ giữa chúng Hoạt động này tổ chức các thành phần này theo các tầng có quan hệ phụ thuộc với nhau, đặc biệt tập trung vào các tầng ở mức trên

Các tầng này sẽ được làm mịn và các tầng mức thấp hơn sẽ được xác định trong pha hợp nhất các phần tử thiết kể với nhau Chúng ta sẽ bắt đầu với khung cảnh và mục đích của phân tích kiến trúc Tiếp đó là phần trình bày các bước chính trong phân tích kiến trúc Bước đầu tiên là phần tim hiểu các khái niệm cơ bản cho phân tích kiến trúc Tiếp đó là phần xác định tổ chức mức cao cho các phân hệ, các cơ chế phân tích, và các khái niệm trừu tượng của hệ thống Và cuối cùng là phần xác định các hiện thục hóa ca sử dụng

4.1.1 Khung cảnh và mục đích của phân tích kiến trúc

Phân tích kiến trúc là một hoạt động trong luồng công việc xác định và lựa chọn kiến trúc cho hệ thống của bức tranh tổng quát về phân tích thiết kế Khung cảnh của hoạt động này được minh họa như trong Hình 4.1

Phân tích kiến trúc là cách đội dự án hay kiến trúc viên xác định kiến trúc mức cao của dự án Nó tập trung chủ yếu vào việc định giới hạn cho công việc phân tích bằng cách sử dụng các mẫu (patterns) và các chỉ dẫn (idioms), để làm giảm tái cho hoạt động phân tích, tránh sa vào các giải pháp cụ thể sớm Phân tích kiến trúc có thể xem như là việc định cấu hình cho phân tích ca sử dụng

Trong suốt quá trình phân tích kiến trúc, chúng ta tập trung vào các tầng mức cao của hệ thống, nhằm xác định sơ bộ các thành phần của hệ thống và quan hệ giữa chủng, tổ chức chủng theo các tầng và đặt trong các mối quan hệ giữa các tầng

Trong phân tích ca sử dụng, kiến trúc này sẽ được khai triển thông qua các lớp phân tích – những chế tác được xác định từ mô tả ca sử dụng Tiếp đó, kiến trúc ban đầu này sẽ được làm mịn và chỉ tiến hóa cũng như các tầng mức thấp hơn được xác định bằng cách tích hợp dẫn các phần tử thiết kế Việc làm mịn này được định hưởng theo môi trường triển khai và các ràng buộc triển khai khác Phân tích kiến trúc thường được thực hiện một lần từ giai đoạn đầu của phu chi tiết Hoạt động này được tiến hành bởi các kiến trúc phần mềm viên hoặc đội kiến trúc Trong trường hợp, rủi ro về kiến trúc là thấp thì hoạt động này có thể được bỏ qua

Phân tích kiến trúc hướng đến những mục đích sau Thứ nhất, phân tích kiến trúc là để xác định một kiến trúc tiêu biểu cho hệ thống dựa vào kinh nghiệm từ các hệ thống tương tự hay các miền vấn đề tương tự Thứ hai, phân tích kiến trúc là để xác định các mẫu kiến trúc, các cơ chế kiến trúc chính và các quy ước về mô hình hệ thống Thứ ba, phân tích kiến trúc là để xác định các chiến lược sử dụng lại Và mục đích nửa của phân tích kiến trúc là để cung cấp một phần đầu vào cho hoạt động lập kế hoạch dự án Đầu vào cho hoạt động phân tích kiến trúc, được minh họa trong Hình 4.2, gồm các chế tác sau: mô hình ca sử dụng, các độc tà bổ sung, từ điển thuật ngữ, mô hình thiết kế, các mô hình kiến trúc tham chiều, các tài liệu tổng thế hệ thống, các tài liệu hướng dẫn chuyển cho dự án, và các tài liệu kiến trúc hệ thống Đầu ra của hoạt động phân tích kiến trúc gồm các chế tác sau: các tài liệu kiến trúc hệ thống, mô hình thiết kế và mô hình triển khai

4.1.2 Khái niệm chính trong phân tích kiến trúc

Hoạt động phân tích kiến trúc liên quan đến những khái niệm cơ bản sau:

Kiến trúc mô hình “khung nhìn 4+1”, như đã giới thiệu trong mục 3.2.4, là một phương pháp để tái hiện kiến trúc phần mềm Mô hình này dùng để tổ chức, phản ánh hệ thống từ 4-1 khung nhìn khác nhau, trong đó, khung nhìn ca sử dụng định hướng và chi phối các khung nhìn còn lại Trong phân tích kiến trúc, chúng ta sẽ tập trung vào khung nhìn logic Các khung nhìn khác sẽ được giải quyết trong các khâu hoạt động sau Cụ thể khung nhìn logic sẽ được làm mịn trong khâu xác định các cơ chế thiết kế và khẩu xác định các mô đun thiết kế Khung nhìn tiến trình sẽ được biểu diễn trong khẩu mô tả kiến trúc thực thi Khung nhìn triển khai sẽ được xây dựng trong khâu mô tả sự phân tán Khung nhìn thực thi sẽ được phát triển trong khâu thực thi, và do đó sẽ nằm ngoài phạm vi của giáo trình phân tích và thiết kế này

Gói và các mối quan hệ gói, như đã giới thiệu trong Chương 2, được dùng để cung cấp một cơ chế để quản lý các chế tác mô hình Gỏi là cơ chế tổng quát để tổ chức các phần tử vào trong các gói Gối là một phần tử mô hình có thể chứa các phần tử khác Không những được dùng để tổ chức mô hình trong quá trình phát triển, gỏi còn được dùng như các đơn vị trong khẩu hoạt động quản lý cấu hình của dự án

Các gói có thể được liên hệ với các gói khác thông qua các mối quan hệ phụ thuộc Các phần tử trong gói phụ thuộc có thể đưa vào (import) các phần tử từ gói mà nó phụ thuộc vào Hay nói cách khúc, quan hệ phụ thuộc giữa các gói chỉ ra rằng những nội dung của gói cung cấp (phía bị phụ thuộc) có thể được tham chiều từ gói khách (phía phụ thuộc) Như ví dụ trong Hình 4.3, các lớp trong gói Khách có thể truy cập các lớp trong gói Cung cấp Từ quan hệ phụ thuộc gói chúng ta suy ra một số lưu ý sau: Thứ nhất, bất kỳ sự thay đối nào trong gói Cung cấp, gói Khách đều phải dịch lại và kiểm thứ lại Thứ hai, các gói Khách không được sử dụng lại một cách độc lập vi nó còn phụ thuộc vào gói Cung cấp,

Việc nhóm gộp các lớp vào trong các gói và biểu diễn quan hệ giữa chúng là có thể được thực hiện bất kỳ lúc nào trong quá trình phát triển, miễn là chúng ta xác định được một nhóm các lớp có quan hệ logic với nhau

Một ràng buộc trong hệ thống phân cấp gói là không nên có quan họ phụ thuộc chu trinh giữa các gói Lưu ý quan hệ phụ thuộc ở dây có tính chất bắc cầu: Gói A phụ thuộc gói B, gói B phụ thuộc gói C dẫn đến gói A phụ thuộc gói C Trong trường hợp này không có chu tri h nghĩa là không có quan hệ phụ thuộc từ gói C đến gói A

Tồn tại sự phụ thuộc chu trình sẽ ngăn cản việc sử dụng lại các gói một cả ch độc lập bởi vì các gói trong quan hệ phụ thuộc chu trinh sẽ phải luôn đi cùng với nhau

Phụ thuộc chu trình có thể được loại bỏ bằng cách tách một trong các gói thành các gói nhỏ hơn

4.1.3 Tổ chức mức cao cho các phân hệ

Trong giai đoạn sớm của vòng đời phát triển, việc đưa các quy tróc về mô hình hóa để tất cả mọi người trong dự án cũng sử dụng và có cách hiểu thống nhất là rất cần thiết Các quy ước về mô hình hóa sẽ đảm bảo sự nhất quán giữa các đội phát triển về sự tái hiện kiến trúc và thiết kế của hệ thống xuyên suốt qua các vòng lập hệ thống Đó là động lực cho việc tổ chức một cách hợp lý các cấu trúc mức cao cho hệ thống

4.1.3.1 Lựa chọn mẫu kiến trúc và khung công việc

Kinh nghiệm về việc tổ chức kiến trúc cho lớp các hệ thống tương tự nhau được phát biểu ở dạng các mẫu kiến trúc hay các khung công việc Tổ chức phân tầng mức cao của hệ thống thường phụ thuộc vào sự lựa chọn các mẫu và khung công việc đó

Một cách khái niệm, các thuật ngữ này được định nghĩa như sau

Phân tích ca sử dụng

Trọng tâm của khâu phân tích cà sử dụng là để xác định các lớp khởi đầu của hệ thống Cùng với việc xác định và gán trách nhiệm cho các lớp phân tích, ở bước này chúng ta cũng sẽ lưu ý về việc sử dụng các cơ chế kiến trúc liên quan Các lớp phân tích cùng với một số hiện thực hóa ca sử dụng khởi đầu sẽ là các phần tử mô hình chính được phát triển trong bước hoạt động này Chúng sẽ được làm mịn trong các hoạt động tiếp theo của khẩu phân tích và thiết kế

4.2.1 Tổng quan về phân tích ca sử dụng

Trong luồng công việc phân tích và thiết kế như được đề cập ở mục 3.2, hoạt động phân tích ca sử dụng là một phần chi tiết của hoạt động phân tích hành vi Đến thời điểm này, chúng ta đã dần hình thành kiến trúc của hệ thống Cụ thể, chúng ta đã xác định các tầng mức cao của kiến trúc, các trừu tượng chính, và các cơ chế phân tích Kiến trúc này cùng với các yêu cầu phần mềm được xác định trong khẩu nắm bắt yêu cầu sẽ định hướng và là đầu vào cho hoạt động phân tích ca sử dụng

Hoạt động phân tích ca sử dụng được thực hiện trên mỗi ca sử dụng và được tiến hành trong mỗi lần lập phát triển Tâm điểm cho hoạt động này là từng ca sử dụng cụ thể Trong phân tích ca sử dụng, chúng ta xác định các lớp phân tích và trách nhiệm của chúng, vai trò của các đối tượng đối với các cơ chế phân tích cũng được xem xét Các tầng kiến trúc cùng với các phụ thuộc sẽ chi phổi đến việc gắn trách nhiệm cho các lớp phân tích Sự phân bố trách nhiệm này sẽ được mô hình hóa trong các hiện thực hóa ca sử dụng dưới dụng các cộng tác giữa các đối tượng cho từng kịch bản của ca sử dụng Các hiện thực hóa ca sử dụng sẽ được làm mịn trong mô hình thiết kế ca sử dụng

Phân tích ca sử dụng được thực hiện bởi các thiết kế viên cho mỗi lần lập và trên mỗi hiện thực hóa ca sử dụng Từng luống sự kiện (tương ứng với từng kịch bản ca sử dụng) cũng như từng hiện thực hỏa ca sử dụng sẽ có các độ ưu tiên thực hiện khác nhau trong khâu phân tích ca sử dụng Phân tích cà sử dụng hướng đến các mục đích chính sau:

- Để xác định các lớp phân tích thực thi các luồng sự kiện của ca sử dụng

- Để phân bố các hành vi ca sử dụng cho các lớp này sử dụng các hiện thực hóa các ca sử dụng

- Để xác định các trách nhiệm, các thuộc tỉnh và các liên kết của các lớp phân tích,

- Để liên hệ các lớp phân tích đến từng cơ chế kiến trúc đã được xác định

Và như minh họa trong Hình 4.7, đầu vào cho hoạt động phân tích ca sử dụng gồm các chế tác sau: Từ điển thuật ngữ, Các đặc tả bổ sung, Ca sử dụng Mô hình ca sử dụng Hiện thực hóa ca sứ dụng Tài liệu kiến trúc phần mềm Các lớp phân tích

Mô hình phân tích và Các hướng dẫn đặc thù cho dự án Đầu ra của hoạt động phân tích cụ sử dụng gồm các chế tác sau: Các lớp phân tích, Mô hình phân tích, Các hiện thực hóa và sử dụng Lưu ý, đối với một số hệ thống không quá phức tạp thì chúng ta có thể bỏ qua việc xây dựng mô hình phân tích một cách độc lập

Hoạt động phân tích ca sử dụng thường trải qua các bước chính sau Thứ nhất, chúng phải thẩm định và sửa đổi các mô tả ca sử dụng đã được xác định trong khâu nắm bắt yêu cầu Các thay đổi ở đây chủ yếu là bổ sung các thông tin để chi tiết hóa các mô tả ca sử dụng, làm cơ sở cho việc xây dựng mô hình Tiếp đó, chúng ta khảo sát luồng kịch bản ca sử dụng xác định các lớp phân tích và phân bố các trách nhiệm ca sử dụng cho các lớp phân tích Dựa vào sự phân bố này cũng với các cộng tác lớp phân tích, chúng ta bắt đầu mô hình hóa mối quan hệ giữa các lớp phân tích Một khi các ca sử dụng đã được phân tích, chúng ta tiến hành tổng hợp kết quả phân tích, đảm bảo các lớp được làm tài liệu Tiếp đó, chúng ta cần phải đảm bảo tính nhất quán trong mô hình phân tích

4.2.2 Chi tiết hóa mô tả ca sử dụng

Mục đích của tài liệu đặc tả bổ sung ca sử dụng là để nắm bắt thêm các thông tin để hiểu được hành vi bên trong của hệ thống, những hành vi mà trong phần mô tả ca sử dụng viết cho khách hàng có thể không được đề cập Thông tin này được sử dụng như dầu vào cho các bước còn lại của hoạt động phân tích ca sử dụng Thông tin đó cũng là cơ sở cho việc gắn trách nhiệm cho các lớp phân tích Lưu ý, trong một vài trường hợp, chúng ta có thể thấy rằng, một vài yêu cầu là không chính xác hoặc không thể hiểu được Trong những trường hợp đó, luồng kịch bản các sự kiện của ca sử dụng cần phải được cập nhật, chẳng hạn, bằng cách lập quay lại khâu nắm bắt yêu cầu

Mô tả cho mỗi ca sử dụng không phải luôn luôn cung cấp đầy ưu thông tin cho việc xác định các lớp và các đối tượng phân tích, cho Mô tả ca sử dụng trong khẩu nắm bắt yêu cầu được viết hưởng đến khách hàng Trong những mô tả đó, có thể có các mô tả về hành vi bên trong của hệ thống, những thứ mà khách hàng không cần phải quan tâm Và do đó, chúng không nhất thiết phải được đưa vào trong mô tả ca sử dụng Khi đó, mô tả ca sử dụng được xem xét như bản mô tả hộp đen, những mô tả chi tiết bên trong bị bỏ qua Đế có thể xác định được các đối tượng thực thi ca sử dụng, chúng ta cần dạng mô tả hộp trắng, nêu rõ những gì mà hệ thống thực thị bên trong Chẳng hạn, trong trường hợp với hệ Course Registration, người dùng sinh viên có thể phát biểu theo cách "Hệ thống hiển thị danh sách các lớp học đang mở"

Với phát biểu này, người thiết kế sẽ khó có thể hình dung những gì đang diễn ra trong hệ thống Một phát biểu phù hợp hơn trong trường hợp này sẽ là "Hệ thống truy xuất danh sách các lớp học đang mở từ hệ cơ sở dữ liệu đã có về các lớp học "

Theo đó, người thiết kế biết chính xác thông tin nào được cần và ai sẽ cung cấp thông tin đó

4.2.3 Xác định lớp phân tích

Một khi các ca sử dụng được mô tả chi tiết hơn và dễ hiểu hơn so với dạng đặc tả ban đầu, chúng ta bắt đầu xác định các lớp phân tích cho hệ thống Mục đích của bước tìm các lớp từ hành vi ca sử dụng là để xác định tập các phần tử mô hình tiêu biểu (các lớp phân tích) để hiện thực hóa các hành vi được mô tả trong ca sử dụng

Hiện thực hóa ca sử dụng có thể được diễn đạt bằng các biểu đồ khác nhau: Biểu đồ tương tác được sử dụng để mô tả cách mà ca sử dụng được hiện thực hóa thông qua các cộng tác giữa các đối tượng Biểu đồ lớp được sử dụng để mô tả các lớp tham gia trong sự hiện thực hóa ca sử dụng cũng như các quan hệ liên kết giữa chúng

Biểu đồ này xác định khung cảnh cho hiện thực hóa ca sử dụng Trong khẩu phân tích ca sử dụng, các biểu đồ hiện thực hóa ca sử dụng được xây dựng ở mức phác thảo Các hoạt động thiết kế tiếp theo (khâu thiết kế ca sử dụng.), các biểu đồ này sẽ được làm mịn và được cập nhật ở dạng đủ chi tiết để diễn đạt được bằng các ngôn ngữ lập trình

4.2.3.1 Lớp phân tích - Bước đầu tiên cho các phần tử có thể thực thi

Tìm một tập ứng viên các vai trò là bước đầu tiên để chuyển hệ thống từ mô tả đơn thuần các hành vi được yêu cầu của hệ thống đến các đặc tả thực thi hệ thống

Các lớp phân tích hợp với nhau hình thành một mô hình khái niệm của hệ thống Mô hình khái niệm này sẽ tiến hóa nhanh chóng và bản thân nó chứa đựng các phác thảo cần được sửa đổi, bổ sung và chi tiết hóa Chúng ta thường không nên mất nhiều công sức để xây dựng một mô hình hệ thống đầy đủ và chính xác ở giai đoạn này

Thực tế các lớp phân tích hiếm khi được giữ nguyên khi chuyển sang khâu thiết kế

Nhiều lớp phân tích sẽ chuyển thành các cộng tác giữa các đối tượng và được bao gói bởi các hệ thống con

THIẾT KẾ HƯỚNG ĐỐI TƯỢNG

Xác định các phần tử thiết kế

Xác định các phần tử thiết kế là một hoạt động thuộc giai đoạn làm mịn kiến trúc của hệ thống (Refine the Architecture) Mục đích của nó là phân tích sự tương tác của các lớp phân tích để xác định các phần tử của Mô hình thiết kế

Các tài liệu đầu vào của hoạt động này bao gồm các bản đặc tả bổ sung, tài liệu kiến trúc phần mềm, các lớp phân tích và mô hình phân tích Các sản phẩm đầu ra của giai đoạn này là các phần tử của mô hình thiết kế gồm có các lớp thiết kế, các gói và các hệ thống con

5.1.1 Xác định các lớp và các hệ thống con

Xác định các phần tử thiết kế (Identify Design Elements) là quá trình làm mịn các lớp phân tích đã được xác định trong giai đoạn Phân tích ca sử dụng (ví dụ, các lớp hoặc các hệ thống con) Các lớp phân tích sử dụng chủ yếu các yêu cầu chức năng và mô hình đối tượng tử miễn bài toán của hệ thống; các phần tử thiết kế được xây dựng dựa trên các yêu cầu phi chức năng và mô hình đối tượng từ miền giải pháp của hệ thống

Chính trong quá trình xác định các phần từ thiết kế, chúng ta quyết định lớp phân tích nào thực sự là một lớp, lớp nào chuyển sang là hệ thống con, và lớp nào là các thành phần không cần thiết kế Mỗi khi các lớp thiết kế và các hệ thống con được tạo ra, chủng được đặt tên và được mô tả ngắn gọn Các trách nhiệm của lớp phân tích sẽ được chuyển sang lớp hoặc hệ thống con ở giai đoạn thiết kế Ngoài ra, các cơ chế thiết kế được kết nối đến đến các phần tử thiết kế

5.1.1.1 Xác định các lớp thiết kế

Nếu các lớp phân tích là đơn giản, biểu diễn một sự trừu tượng logic đơn nhất, thì nó được chuyển trực tiếp (một-một) thành các lớp thiết kế

Xuyên suốt các hoạt động thiết kế, các lớp phân tích được làm mịn thành các phần tử thiết kế (ví dụ: lớp thiết kế, gói, hệ thống con) Một số lớp phân tích có thể được chia ra, kết hợp lại, bị xóa, Thông thường, việc chuyển đổi này là một ảnh xạ nhiều nhiều giữa các lớp phân tích và các phần tử thiết kế Trong quá trình ánh xạ, một lớp phân tích có thể trở thành:

- Một lớp trong mô hình thiết kế

- Một phần của lớp trong mô hình thiết kế, - Một lớp toàn thể trong mô hình thiết kế (nghĩa là bộ phận của lớp này không được mô hình hóa trong mộ hình phân tích),

- Một nhóm các lớp thừa kế cùng một lớp trong mô hình thiết kế, - Một nhóm các lớp có chức năng liên quan trọng mô hình thiết kế (ví dụ: một gói),

- Một hệ thống con trong mô hình thiết kế, - Một quan hệ trong mô hình thiết kế

Chú ý rằng, một quan hệ giữa các lớp phân tích có thể trở thành một lớp trong mô hình thiết kế

5.1.1.2 Quan hệ giữa gái và hệ thống con

Khi xác định các lớp, để quản lý tổ chức và cấu hình, chúng ta nên nhóm chúng lại thành các gói Mô hình thiết kế có thể cấu trúc thành các đơn vị nhỏ để dễ hiểu hơn Bằng cách nhóm các phân tử của mô hình thiết kế thành các gói và hệ thống con, chúng ta xác định được quan hệ giữa các nhóm và vì thế cấu trúc chung của mô hình cũng rõ ràng hơn

Nguyên nhân dẫn tới việc phân bố mô hình thiết kế theo các gói hoặc hệ thống con là chúng ta sử dụng các gói và hệ thống con theo các đơn vị chuyển giao, theo cấu hình, theo thứ bậc khi hệ thống hoàn thành Hơn nữa việc cung cấp các tài nguyên và khá năng của các nhóm lập trình đòi hỏi dự án được phân chia theo các nhóm khác nhau Ngoài ra, các hệ thống con có thể được sử dụng để tổ chức mô hình thiết kế theo kiểu của người sử dụng Nhiều yêu cầu bị thay đổi bắt nguồn từ người dùng, các hệ thống con bảo đảm các thay đổi này chỉ ảnh hưởng đến phần của hệ thống tương ứng với phần của người sử dụng đó Các hệ thống con thường dùng để biểu diễn các sản phẩm đã tồn tại hoặc các dịch vụ mà hệ thống sử dụng

Hai chiến lược có thể được áp dụng khi phân bố các lớp biên đến các gói, việc lựa chọn chiến lược nào phụ thuộc vào các giao diện hệ thống có bị thay đổi trong tương lai hay không Nếu giao diện hệ thống có thể bị thay thế hoặc nhiều khả năng bị thay đổi, các lớp biên cần được tách biệt với phần còn lại của mô hình thiết kế

Khi giao diện người sử dụng bị thay đổi, chỉ những gói này bị ảnh hưởng

Nếu không có kế hoạch thay đổi giao diện, các chức năng hệ thống có thể thay đổi, các lớp biên cần được đặt vào cùng gói với các lớp điều khiển và lớp thực thể mà chúng có cùng quan hệ chức năng Bằng cách này, chúng ta có thể dễ dàng nhìn thấy lớp biến nào bị ảnh hưởng nếu một số lớp thực thể hoặc điều khiển bị thay đổi

Một gói nên được xác định dựa trên một nhóm các lớp có liên quan đến chức năng Các tiêu chỉ có thể áp dụng để đánh giả xem hai lớp có liên quan chức năng với nhau, được sắp xếp theo thứ tự tầm quan trọng giảm dần như sau:

- Nếu thay đổi hành vi hoặc cấu trúc của một lớp đòi hỏi thay đổi trong lớp khác

- Hai đối tượng có thể liên quan chức năng nếu chúng tương tác với nhau nhiều thông điệp

- Một lớp biên có thể quan hệ chức năng với một lớp thực thể nếu chức năng của lớp thực thể được giới thiệu lớp thực thể

- Hai lớp cùng được tương tác bởi một tác nhân

- Hai lớp có quan hệ với nhau (liên kết, tụ hợp, hoặc các quan hệ khác)

Trong phần phân tích kiến trúc, chúng ta đã thảo luận về sự phụ thuộc giữa các gói Chúng ta sẽ đi sâu tìm hiểu sự phụ thuộc này để xem xét khả năng nhận diện (visibility) giữa các gói

Khả năng nhận diện giữa các phần tử của các gói có thể được định nghĩa tương tự như các phương thức và thuộc tính của lớp Khả năng nhận diện cho phép chúng ta đặc tả sự truy cập giữa các gói

- Public (+): Lớp truy cập được từ bên ngoài gói

- Protected (#): Lớp truy cập được từ trong gói này và các gói thừa kế

- Private (-): Lớp chỉ có thể truy cập được từ các lớp trong cùng gói

Các cơ chế thiết kế

Nhắc lại rằng, các cơ chế phân tích cung cấp một tập khái niệm về dịch vụ sử dụng để phân tích các đối tượng Mục đích chính của cơ chế phân tích là cho phép lấy các yêu cầu dịch vụ sẽ được thiết kế của hệ thống Mục đích của cơ chế thiết kế là làm mịn các cơ chế phân tích dựa trên các ràng buộc của môi trường thực thi

Hoạt động này cũng thuộc vào giai đoạn làm mịn kiến trúc của hệ thống với các tài liệu đầu vào là các bản đặc tả bổ sung, tài liệu kiến trúc phần mềm, các lớp phân tích và mô hình thiết kế Các sản phẩm đầu ra của hoạt động là các phần tử mô hình thiết kế và tải liệu kiến trúc phần mềm

5.2.1 Phân loại khách của cơ chế phân tích

Mẫu (pattern) là khái niệm dùng để hệ thống hóa các kiến thức chuyên biệt dựa trên kinh nghiệm Các mẫu cung cấp các minh họa làm thế nào để đưa ra các mô hình tốt giải quyết các vấn đề thực tế, đó có thể là các mẫu do chính bạn nghĩ ra hoặc sử dụng mẫu của người khác

Khung làm việc (Frameworks) khác với mẫu phân tích và thiết kể về độ lớn và phạm vi Khung làm việc mô tả giải pháp khung cho một vấn đề riêng biệt Chi tiết có thể được hoàn thiện bằng cách áp dụng các mẫu phân tích và thiết kế khác nhau

Khung làm việc là một kiến trúc cung cấp một khuôn mẫu cho các ứng dụng ở một lĩnh vực chuyên biệt Kiến trúc khung làm việc cung cấp một ngữ cảnh để các thành phần hoạt động trong nó Chúng cung cấp một cơ sở hạ tầng cho phép các thành phần củng tồn tại và thực hiện theo kế hoạch đặt ra Các khung làm việc này có thể cung cấp các cơ chế truyền thông, cơ chế phân tán, các khá năng xử lý lỗi

Bảng 5.2 liệt kê một số ví dụ về các mẫu thường được sử dụng trong các ứng dụng phần mềm Chúng ta nghiên cứu chi tiết hơn vào một trong những mẫu thiết kế đặc trưng, mẫu Command Hãy tưởng tượng rằng chúng ta muốn xây dựng một thành phần về giao diện người sử dụng (GUI) mà có thể sử dụng lại Để đơn giản, chúng ta hạn chế sự cài đặt về thực đơn trên hệ thống Windows (sao cho có thể thêm các thực đơn lựa chọn mà không cần thay đổi thành phần GUI)

Các thành phần tham gia vào kịch bản thực hiện có thể có các lớp sau (Hình 5.6)

- Application: là lớp khách dùng để giả lập ứng dụng

- Menu: để đơn giản, giả sử ứng dụng chỉ có một thực đơn Menu

- MenuItem: Một thực đơn gồm nhiều MenuItem khác nhau

- Command: là một lớp trừu tượng gồm một thao tác gọi là Process Nó là một thao tác trừu tượng, nghĩa là nó phải được định nghĩa lại ở một lớp con của lớp Command

- Giả sử chúng ta định nghĩa trong lớp Menultem một thao tác gọi là Clicked được gọi tự động khi người sử dụng chọn thực đơn tương ứng trong thời gian chạy Phần mã trong Clicked là cmd.Process(); Để hoàn thiện biểu đồ lớp, cần phải có một quan hệ sử dụng (Uses) từ Application đến OpenCommand đề chỉ ra đối tượng của lớp này tạo ra đối tượng của lớp kia, và một quan hệ Uses từ lớp Menu đến lớp Command vì thao tác AddItem có một tham số có kiểu Command (Hình 5.7) Để mô tả các cơ chế phân tích cho các lớp trong hệ thống, chúng ta cần thực hiện các bước theo thứ tự sau:

- Liệt kê các cơ chế phân tích vào một danh sách,

- Xác định một ảnh xạ từ các lớp khách đến cơ chế phân tích (Bảng 5.3 là một ví dụ về bước này của Hệ thống đăng ký môn học)

- Xác định các đặc điểm của cơ chế phân tích

Chúng ta biết rằng, các cơ chế phân tích biểu diễn một mẫu bao gồm một giải pháp chung cho một vấn đề thông dụng (tương tự các mẫu thiết kế) Chúng có thể đưa ra các mẫu về cấu trúc, các mẫu về hành vi, hoặc cả hai Chúng được sử dụng trong quá trình phân tích để giảm độ phức tạp của phân tích và để cải tiến sự đồng nhất bằng cách cung cấp cho người thiết kế một sự biểu diễn ngắn gọn về các hành vi phức tạp

Mục đích của phân loại cơ chế phân tích là để làm mịn các thông tin ban đầu các cơ chế phân tích xác định được Các bước để phân loại bao gồm:

- Xác định lớp khách của mỗi cơ chế phân tích - Xác định các đặc điểm thông tin của mỗi cơ chế phân tích - Nhóm các lớp khách theo việc sử dụng của các đặc điểm thông tin

5.2.2 Tài liệu hóa cơ chế kiến trúc

Trong phân tích kiến trúc, chúng ta cần xác định các cơ chế kiến trúc cần để giải quyết vấn đề Bây giờ chúng ta đi sâu nghiên cứu việc tích hợp các quyết định trên phần cài đặt

Cơ chế thiết kế (Design mechanism) giả thiết một số chi tiết của môi trường thực thi, nhưng không quả gần với một sự cài đặt đặc biệt nào (như cơ chế thực thi)

Cơ chế thực thi (Implementation mechanisms) được sử dụng trong quá trình cài đặt Nó là sự làm mịn của cơ chế thiết kế, dùng để đặc tả chính xác sự cài đặt của cơ chế thiết kế Nó có thể bao gồm một số công nghệ, ngôn ngữ cái đặt, Một số ví dụ về các cơ chế cài đặt bao gồm ngôn ngữ lập trình, sản phẩm COTS, cơ sở dữ liệu (Oracle, Sybase), các công nghệ phân tán, tương tác giữa các tiến trình (COM/DCOM, CORBA)

Bảng 5.4 biểu diễn cơ chế kiến trúc cho mỗi ví dụ Với hệ thống quản trị CSDL quan hệ (RDBMS) dùng để truy cập dữ liệu đã tồn tại, JDBC được chọn Với hệ quản trị CSDL hướng đối tượng (OODBMS), ObjectStore được chọn, và với hệ thống phân tán, RMI được chọn.

Mô tả kiến trúc thực thi

Sự đồng thời là xu hưởng của các sự việc xảy ra tại một thời điểm trong hệ thống

Nó cũng là một hiện tượng tự nhiên trong thế giới thực cũng như trong bất kỷ hệ thống nào Khi đề cập đến khải niệm đồng thời trong hệ thống phần mềm, chúng ta cần xem xét hai vấn đề quan trọng sau

- Có thể phát hiện và trả lời các sự kiện bên ngoài hệ thống theo một thứ tự ngẫu nhiên

- Bảo đảm các sự kiện này phản ứng trong khoảng thời gian tối thiểu cho phép

Nếu các hoạt động đồng thời là song song độc lập (truly parallel), việc quản lý chủng là tương đối đơn giản, chúng ta chỉ cần tạo ra các chương trình riêng biệt cho mỗi hoạt động Tuy nhiên, thách thức của việc thiết kế các chương trình đồng thời chủ yếu do sự tương tranh dữ liệu của nhiều hoạt động (concurrency)

Tương tự như một hệ thống giao thông, nếu các con đường là một chiều, song song tách biệt thì các phương tiện ít va chạm, lưu thông dễ dàng Với những hệ thống song song một chiều nhưng trên cùng đường, chúng ta chỉ điều phối ít, với những hệ thống có giao cắt, việc điều phối với các hệ thống đèn giao thông là cần thiết

Khi các hệ điều hành cung cấp cơ chế đa nhiệm, đơn vị thông thương của sự đồng thời là các tiến trinh Một tiến trình là một thực thể được cung cấp, hỗ trợ, và quản lý bởi hệ điều hành Các tiến trình cung cấp một khoảng bộ nhớ dành riêng cho các chương trình ứng dụng của nó Nói chung, một tiến trình là một CPU ảo để thực hiện một mẫu chương trình thực hiện đồng thời của một ứng dụng

5.3.1 Phân tích yêu cầu thực hiện đồng thời

Yêu cầu thực hiện đồng thời định nghĩa một sự mở rộng trong đó việc thực hiện song song của các tác vụ là yêu cầu của hệ thống Các yêu cầu này giúp định dạng kiến trúc hệ thống

Một hệ thống gọi là phân tán nếu hành vi của nó phân bố trên nhiều bộ vi xử lý hoặc các nút thực hiện khác nhau đòi hỏi một kiến trúc nhiều tiến trình Để cung cấp một sự phản ứng tốt về thời gian, chúng ta nên đưa các hoạt động tính toán nhiều vào các tiến trình của nó, nhờ đó, hệ thống có khả năng trả lời người dùng trong khi sự tỉnh toán vẫn diễn ra, sử dụng ít tài nguyên hơn

Lấy ví dụ với hệ thống đăng ký môn học (Course Registration System), các yêu cầu thực hiện đồng thời bao gồm các yêu cầu người sử dụng và yêu cầu kiến trúc:

- Nhiều người sử dụng có thể thực hiện công việc đồng thời

- Nếu một môn học đã được đăng ký đầy đủ trong khi sinh viên xây dựng thời khóa biểu có thêm cả môn học này, sinh viên phải được thông báo,

- Các khuôn mẫu dựa trên rủi ro phát hiện ra rằng dữ liệu danh sách môn học đã tồn tại không đáp ứng được hiệu năng mong muốn nếu không sử dụng sức mạnh tớnh toỏn ở tồng trung gian

Các yêu cầu trên là loại trừ lẫn nhau và có thể gây ra xung đột Sắp xếp các yêu cầu dựa theo tiêu chí quan trọng của chúng có thể giải quyết được sự xung đột này

5.3.2 Xác định các tiến trình và luồng song song

Tiến trình (Process): là một không gian có địa chỉ duy nhất và có môi trường thực hiện trong đó các đối tượng của các lớp và hệ thống con hoạt động trên đó Môi trường thực hiện có thể chia ra một hoặc nhiều luồng điều khiển

Luồng (Thread): là một bộ phận tinh toàn độc lập có thể chạy được trong môi trường thực hiện và một không gian địa chỉ định nghĩa bởi tiến trình đi kèm

Sự khác nhau giữa tiến trình và luồng là ở không gian bộ nhớ trong đó nó thực hiện:

- Một tiến trình thực hiện trong không gian bộ nhớ, được đóng gói và bảo vệ cấu trúc nội tại Một tiến trình có thể được xem như một hệ thống của chính nó, được khởi tạo bởi một chương trình thực hiện được Một tiến trình có thể chứa nhiều luồng

- Một luồng thực hiện trong một không gian bộ nhớ ở đó nó có thể chia sẻ với các luồng khác

Chúng ta có thể sử dụng các lớp tích cực (active) để mô hình các tiến trình và luồng Một lớp tích cực là lớp sở hữu luồng thực hiện của chính nó và có thể khởi tạo hoạt động điều khiển, khác với các lớp bị động chỉ hoạt động khi được gọi đến

Các lớp tích cực có thể thực hiện song song (đồng thời) với các lớp tích cực khác

Các phần tử mô hình có thể được gán nhân các khuôn mẫu để chỉ ra nó có phải là các tiến trình (nhãn ) hoặc luồng (nhãn)

Chú ý: Khi chúng ta sử dụng các lớp tích cực để mô hình các tiến trình và luồng, chúng chỉ là các lớp ở mức siêu mô hình Chúng không phải cùng loại với các phần tử mô hình như các lớp Chúng là các phần tử siêu mô hình (metamodel) dùng để cung cấp một không gian bộ nhớ và một môi trường thực thi trong đó đối tượng của các lớp có thể thực hiện được

5.3.3 Xác định vòng đời tiến trình

Mô tả sự phân tán

Trước khi xem xét một số mẫu phân tán thường sử dụng chúng ta cần biết nguyên nhân tại sao phải phân tán một ứng dụng phần mềm Trong nhiều trường hợp, hệ thống không thể thực hiện được với chỉ một bộ vi xử lý do có các yêu cầu về tính toán lớn và tốc độ trả về kết quả Nhu cầu của sự phân tán cũng có thể đến từ yêu cầu trải rộng của hệ thống, ở đó một số lượng lớn người sử dụng hệ thống đồng thời được hỗ trợ bởi những bộ xử lý xung quanh Tóm lại, nguyên nhân có thể đến từ lý do kinh tế vì các bộ xử lý nhỏ, rẻ tiền không thể đáp ứng một mô hình lớn Với một số hệ thống, khả năng truy cập hệ thống từ những vị trí phân tán có nghĩa là hệ thống phải phân tán

Sự phân tán của các tiến trình vào hai hay nhiều nút đòi hỏi việc đối chiếu với các mẫu về tương tác giữa các tiến trình trong hệ thống Để các hệ thống đạt được lợi ích thật sự đòi hỏi chúng ta phải nghiên cứu và lên kế hoạch một cách cẩn thận

Nhiều mẫu phân tán trong các hệ thống đã được đề xuất, phụ thuộc vào chức năng của hệ thống và kiểu của ứng dụng Thông thường, mẫu phân tán được mô tả như là kiến trúc của hệ thống, mặc dù kiến trúc đầy đủ bao gồm cả mẫu và nhiều thứ khác

Trong kiến trúc Client/Server, có một mạng lưới các bộ xử lý client và server

Clients là các máy khách sử dụng dịch vụ cung cấp bởi các máy phục vụ (Servers)

Sự phân tán của chức năng hệ thống vào các client và server cho phép phân biệt các kiểu khác nhau của kiến trúc Client/Server (Hình 5.10)

3-tier: Các chức năng: được phân đều vào 3 phần ứng dụng nghiệp vụ và tập máy chủ

Fat client: Nhiều chức năng được đặt ở client

Fat server Nhiều chức năng được đặt ở server Ví dụ: Groupware và Web servers

Distributed client/server: Các ứng dụng, nghiệp vụ và dịch vụ dữ liệu được đặt trong các nút khác nhau, là một sự cài đặt đầy đủ ở cả ba tầng của kiến trúc

Trong kiến trúc ngang hàng (Peer-to-Peer), bất cứ một tiến trình hay nút nào trong hệ thống cũng có thể là client hoặc server Kiến trúc 3 lớp (Three-tier architecture) là một trường hợp đặc biệt của kiến trúc client/server trong đó chức năng hệ thống được chia làm 3 phần logic: các dịch vụ ứng dụng, các dịch vụ nghiệp vụ và các dịch vụ dữ liệu, các phần logic này có thể đặt ở trên 3 hoặc nhiều nút vật lý (Hình 5.11)

Các dịch vụ ứng dụng, chủ yếu liên quan các vấn đề trình diễn giao diện người sử dụng (GUI), hướng đến chạy trên một máy tính dành riêng với môi trường đồ họa Các dịch vụ dữ liệu sẽ được cài đặt sử dụng các công nghệ dữ liệu trên máy chủ, thường được thực hiện trên một hoặc nhiều trạm có hiệu năng cao, băng thông rộng và có thể phục vụ hàng nghìn người sử dụng kết nối qua mạng

Các dịch vụ nghiệp vụ thường được sử dụng bởi nhiều người vì vậy nó thường được đặt ở các máy chủ đặc biệt, mặc dù chúng có thể được cài đặt trong các nodes giống như dịch vụ dữ liệu

Trong kiến trúc ngang hàng (peer-to-peer), các tiến trình và các nút trong hệ thống có thể vừa là máy khách vừa là máy chủ (Hình 5.12) Sự phân bố chức năng đạt được thông qua việc nhóm dịch vụ liên quan lại với nhau để giảm thiểu giao thông trên các mạng đồng thời cực đại hóa các tài nguyên hệ thống sử dụng Những hệ thống như vậy thường phức tạp, dễ bị các lỗi khóa chết (deadlock), đôi tài nguyên (starvation) giữa các tiến trình

5.4.1 Định nghĩa cấu hình mạng

Cấu hình của mạng, các khả năng và đặc điểm của các bộ xử lý và thiết bị trong mạng xác định mức độ phân tán có thể của hệ thống

Các phần tử quan trọng của một biểu đồ cài đặt là các nút và các kết nối của nó

Một nút là một đối tượng vật lý thực hiện được chương trình phần mềm, ít nhất có bộ nhớ và khả năng xử lý dữ liệu

Môi trường thực hiện (Execution Environment) và thiết bị là các kiểu của nút trong mạng, UML 2 phân biệt chủng như sau:

- Các thiết bị có thể có các chế tác được cài đặt để thực hiện các phần mềm có thể điều khiển các chức năng của chính thiết bị (tài nguyên tính toán vật lý có khả năng xử lý dữ liệu) Các ví dụ bao gồm:, ,

, , etc Các thiết bị này có thể chứa các thiết bị khác

- Môi trường thực hiện biểu diễn một nền tảng thực hiện đặc biệt, như hệ điều hành (,