1.Giới thiệu về Object-oriented Analysis and Design (OOAD)

OOAD là một kỹ thuật dùng để phân tích, thiết kế một ứng dụng, hệ thống. Nó dựa trên một bộ nguyên tắc chung, giúp chúng ta thiết kế ra một ứng dụng, hệ thống tốt hơn.

Mình giả định là bạn đã biết các khái niệm về thiết kế hướng đối tượng (object-oriented design hay OOD), phân tích hướng đối tượng (object-oriented analysis hay OOA) cũng như nắm các cú pháp của lập trình hướng đối tượng (object-oriented programming hay OOP) trong các ngôn ngữ như: Java, C++, C#, Python, JavaScript. Mình có viết về Object-oriented Programming trong Python, bạn có thể tham khảo nếu cần ôn lại nha.

1.1.Giới thiệu về OOA, OOD và UML

1.1.1.Object-oriented Analysis

Khi phát triển phần mềm, trong giai đoạn object-oriented analysis thì chúng ta sẽ xác định các yêu cầu hệ thống (system requirements), các classes và quan hệ giữa các class.

Sau đó sử dụng để tạo model bằng cách xác định vai trò của các objects có trong hệ thống và các công việc mà hệ thống sẽ phải thực hiện.

Giai đoạn phân tích thì không bao gồm phần triển khai chi tiết nào. Thay vào đó, chúng ta xác sẽ xác định các use cases ở đây.

1.1.2.Object-oriented Design

OOD là giai đoạn bắt đầu triển khai các yêu cầu đã xác định và các model được tạo trong giai đoạn OOA.

Trong bước này, các model được tinh chỉnh thêm bằng cách thêm các ràng buộc bổ sung. Các model này thường được xây dựng bằng cách sử dụng các sơ đồ ngôn ngữ mô hình hóa thống nhất (Unified Modeling Language hay UML) như sơ đồ lớp (class diagram) hay sơ đồ trình tự (sequence diagram).

1.1.3.Unified Modeling Language (UML)

UML được dùng để trực quan hóa (hay biểu diễn) hành vi (behavior) và cấu trúc (structure) của hệ thống. Nó được biết đến như một công cụ cung cấp cho các kỹ sư phần mềm và các nhà phát triển phần mềm khả năng phân tích, thiết kế và phát triển hệ thống.

Sơ đồ UML có thể được chia thành 2 loại:

• Sơ đồ cấu trúc UML (Structural UML diagrams)
• Sơ đồ hành vi UML (Behavioral UML diagrams)

Structural diagram phổ biến nhất trong phát triển phần mềm là sơ đồ lớp (class diagrams).
Các behavioral diagrams được sử dụng phổ biến nhất là use case diagrams, activity diagrams, và sequence diagrams.

Các diagrams trên cũng là những diagrams chúng ta sẽ tìm hiểu trong phạm vi bài viết này.

2.Use case diagram

Use case diagram miêu tả việc users tương tác với hệ thống. Những tương tác này gọi là use cases. Ở đây, use case sẽ được miêu tả từ góc độ của users với hệ thống. Sau khi hoàn thành use case diagram, ta có thể nắm được các chức năng mà hệ thống cần xây dựng dưới góc độ của users.

2.1.Các thành phần của use case diagram

• Actor: Users được gọi là actors. Actor có thể là con người, máy móc, phần cứng, hoặc các hệ thống khác. Có hai loại actors:

  • Primary actors (active actors): Đây là con người hoặc hệ thống bên ngoài tương tác với hệ thống, chúng được đặt bên trái trong use case diagram.
  • Secodary actors (passive actors): Những actor được hệ thống sử dụng để hỗ trợ các active actors trong use case diagram. Chúng được đặt bên phải trong use case diagram.

• Use case: Đây là chức năng đã được xác định của hệ thống mà actor sẽ sử dụng để thể hiện sự tương tác với hệ thống.

Actor và use case được biểu thị như sau:

2.2.Relationships trong use case diagram

Có bốn loại relationships trong use case diagram:

2.2.1.Association

Association: Cho thấy mối quan hệ giữa actor(s) và use case(s). Nó miêu tả cách actor thực hiện các chức năng nhất định. Tất cả các actors trong use case diagram bắt buộc có ít nhất một association với bất kỳ use case nào.

Association được biểu thị bằng một đường nét liền, như sau:

2.2.2.Generalization

Generalization: Mối quan hệ này còn được gọi là thừa kế (inheritance). Trong inheritance ở oop, chúng ta có parent classs và child classs.

Tương tự, trong use case diagram, chúng ta có parent use cases và child use cases cũng như parent actors và child actors. Child (use case/actor) sẽ thừa hưởng hành vi của parent (use) case/actor).

Generalization được biểu thị bằng một đường nét liền với một mũi tên chỉ từ child (use case/actor) đến parent (use case/actor) như sau:

2.2.3.Extend

Extend: Được sử dụng để mô tả mối quan hệ giữa hai use cases. Nó chỉ ra một use case (extended use case) extends hành vi của một use case khác (base use case). Nó được sử dụng để mở rộng chức năng của base use case. The extended use case không thực thi mọi lúc mà phụ thuộc vào những điều kiện nhất định.

Extend được biểu thị bằng đường nét đứt với mũi tên chỉ ở một bên (về phía base use case), và có dòng chữ <<extend>> phía trên đường này như sau:

2.2.4.Include

Include: Được sử dụng để miêu tả mối quan hệ giữa các use cases. Nó chỉ ra một use case bắt buộc phải bao gồm hành vi của một use case khác. The included use case sẽ chỉ thực hiện sau khi thực hiện base use case.

Include được biểu thị bằng một đường nét đứt với một mũi tên chỉ ở một bên (về phía base use case), và có dòng chữ <<include>> phía trên đường này như sau:

Với use case Transfer Fund, chúng ta thấy nó <<include>> một use case khác là Check Sufficient Fund. Nếu base use case là Check Sufficient Fund bị lỗi hay không thực hiện được, thì use case Transfer Fund xem như chưa hoàn thành.

2.3.Lợi ích của use case diagram:

• Giải thích về luồng hoạt động và mục đích của các use cases, giúp ta xác định bối cảnh và nhu cầu của hệ thống.
• Giải thích hành vi của hệ thống từ góc độ người dùng.

3.Class diagram

Biểu đồ lớp (class diagram) được sử dụng để mô tả cấu trúc tĩnh của hệ thống. Nó được sử dụng trong quá trình thiết kế để chỉ ra các vai trò (roles) và trách nhiệm (responsibilities) của hệ thống.

Class diagram được sử dụng rộng rãi trong việc mô hình hóa OOD vì nó có thể chuyển đổi trực tiếp sang các ngôn ngữ lập trình OOP.

Một class diagram được tạo thành từ:

• Tập hợp các classes
• Tập hợp các mối quan hệ giữa các classes.

3.1.Các notation phổ biến trong class diagram

• Class notation
• Interface, abstract class, và enumeration
• Access modifiers

3.1.1.Class notation

Hình dưới đây mô tả một class Movie kèm theo attributes và methods của nó.

• Section đầu tiên là tên class
• Section thứ hai là danh sách các attributes: mô tả tính chất của đối tượng, ví dụ như sinh viên thì sẽ có mã sinh viên, họ và tên, ngày tháng năm sinh, etc.
• Section cuối thì hiển thị methods: thể hiện các hành vi của các đối tượng.

3.1.2.Interface, abstract class, and enumeration

Chúng ta có thể khai báo một abstract class bằng cách sử dụng keyword abstract, tên class sẽ được in nghiêng, tương tự với interface, enumeration, annotation.

3.1.3.Access modifiers

Chúng ta cũng có thể biểu diễn private, public, protected data trong class diagram.

• Public: Thể hiện bằng dấu +
• Private: Thể hiện bằng dấu –
• Protected: Thể hiện bằng dấu #

3.2. Relationships trong class diagram

3.2.1.Generalization (inheritance) (“is a”)

Mối quan hệ này thể hiện 1 class kế thừa 1 class khác. Nó được biểu thị bằng đường nét liền dẫn từ child class đến parent class với đầu mũi tên rỗng thể hiện mối quan hệ kế thừa như sau:

3.2.2.Simple association (“has a”)

Đây là quan hệ giữa hai classes được thiết lập thông qua các đối tượng của chúng. Trong mối quan hệ này, không ai sở hữu ai, vòng đời của hai classes thì độc lập. Ví dụ một thành viên (member) tới đăng ký hội viên với người thủ thư (librarian) ở thư viện.

Mối quan hệ này được biểu diễn như sau:

3.2.3.Aggregation (“is part of”)

Aggregation mô tả mối quan hệ giữa container và object trong container. Các object trong container có thể tồn tại độc lập so với container. Như ở ví dụ dưới, các object Table, Bed, Chair vẫn có thể tồn tại ngoài Room. Aggregation được biểu diễn như sau:

Thêm một ví dụ là điện thoại và pin, khi pin (object) hư thì có thể thay pin khác vào điện thoại (container) để xài tiếp. Hay bánh xe và oto:

3.2.4.Composition (cấu thành – “is entirely made of”)

Một object có thể bao gồm nhiều objects nhỏ hơn, và quan hệ giữa “part” objects (part object có thể hiểu là những object này là part (một phần) của object hoàn chỉnh) và “whole” objects được gọi là composition. Vòng đời của “part” objects phụ thuộc vào vòng đời của “whole” objects.

Ở ví dụ dưới, ta có thể thấy, khi các object Leg, Seat, Arm được tạo, chúng phải được chỉ định thuộc về Chair nào, nếu không thì chúng vô nghĩa. Composition được biểu diễn như sau:

Thêm một ví dụ là Hotel thì chứa nhiều Room, khi Hotel bị hủy thì các Rooms cũng sẽ bị hủy.

3.2.5.Dependency (phụ thuộc)

Dependency chỉ ra rằng một class sẽ phụ thuộc vào (các) classes khác để triển khai.

Chúng ta có 2 classes: RegistrationManager và Student. Class RegistrationManager dựa vào class Student để thực hiện hành vi của nó vì object của class Student được truyền dưới dạng tham số cho một trong các method trong class RegistrationManager.

Khi class Student thay đổi có thể ảnh hưởng đến class RegistrationManager vì method addStudent có dựa vào object Student để hoàn thành. Dependency được biểu diễn như sau:

3.3. Multiplicity trong class diagram

Multiplicity chỉ ra có bao nhiêu đối tượng của mỗi classes tham gia vào các mối quan hệ và multiplicity có thể được diễn tả như sau:

Ví dụ

Mỗi customer phải có từ 1 đến 5 bank accounts. Mỗi bank account chỉ thuộc về 1 customer.

Một student có thể đăng ký nhiều courses, hoặc không đăng ký courses nào. Một courses có thể có nhiều student đăng ký, hoặc không có student nào đăng ký.

Một school có thể có 1 hoặc nhiều teacher, 1 teacher có thể dạy tại 1 school hoặc nhiều school. Một school phải có 1 toilet hoặc nhiều hơn.

Ở bài viết tiếp theo, chúng ta sẽ tìm hiểu về Sequence Diagram và Activity Diagram.