Categories
Chia sẻ

Design Pattern – mẫu Abstract Factory – ví dụ Abstract Factory với PHP

Abstract Factory là một design pattern thuộc nhóm creational

Mục tiêu của Abstract Factory pattern:
– Cung cấp một giao diện lớp, có chức năng tạo ra một tập hợp các đối tượng liên quan hoặc phụ thuộc lẫn nhau mà không chỉ ra đó là những lớp cụ thể
– Đóng gói một nhóm những lớp đóng vai trò “sản xuất” (Factory) trong ứng dụng, đây là những lớp được dùng để tạo lập các đối tượng

Ví dụ với Abstract Factory pattern PHP

 

<?php

/**
 * Abstract Factory
 */
abstract class AbstractCarFactory {
    abstract function makeSedanCar();
    abstract function makeSuvCar();
}

/**
 * Concrete Factory
 */
class BmwCarFactory extends AbstractCarFactory {
    private $manufacturer = 'BMW';
    function makeSedanCar() {
        return new BmwSedanCar;
    }
    function makeSuvCar() {
        return new BmwSuvCar;
    }
}

class MercedesCarFactory extends AbstractCarFactory {
    private $manufacturer = 'Mercedes';
    function makeSedanCar() {
        return new MercedesSedanCar;
    }
    function makeSuvCar() {
        return new MercedesSuvCar;
    }
}

/**
 * Abstract Object
 */
abstract class AbstractCar {
    abstract function getName();
    abstract function getEngine();
}

abstract class AbstractSedanCar extends AbstractCar {
    protected $bodyType = 'Sedan';
}
abstract class AbstractSuvCar extends AbstractCar {
    protected $bodyType = 'Suv';
}

class BmwSedanCar extends AbstractSedanCar {
    private $name;
    private $engine;
    function __construct() {
        $this->name = 'Bmw 340';
        $this->engine = '382-hp, 3.0-liter I-6';
    }
    function getName() {
        return $this->name;
    }
    function getEngine() {
        return $this->engine;
    }
}

class BmwSuvCar extends AbstractSedanCar {
    private $name;
    private $engine;
    function __construct() {
        $this->name = 'Bmw X5';
        $this->engine = '335-hp, 3.0-liter I-6';
    }
    function getName() {
        return $this->name;
    }
    function getEngine() {
        return $this->engine;
    }
}

class MercedesSedanCar extends AbstractSedanCar {
    private $name;
    private $engine;
    function __construct() {
        $this->name = 'Mercedes E350';
        $this->engine = '255-hp, 2.0-liter I-4';
    }
    function getName() {
        return $this->name;
    }
    function getEngine() {
        return $this->engine;
    }
}

class MercedesSuvCar extends AbstractSedanCar {
    private $name;
    private $engine;
    function __construct() {
        $this->name = 'Mercedes GLC43';
        $this->engine = '385-hp, 3.0-liter V-6';
    }
    function getName() {
        return $this->name;
    }
    function getEngine() {
        return $this->engine;
    }
}

/**
 * Test
 */
echo '=== Begin testing abstract factory patterm ===';
echo '<br>';
echo '<br>';
echo '--- Testing BmwCarFactory ---';
echo '<br>';
$bmwCarFactory = new BmwCarFactory;
$bmwCar = $bmwCarFactory->makeSedanCar();
echo 'Bmw car name: '.$bmwCar->getName();
echo '<br>';
echo 'Bmw car engine: '.$bmwCar->getEngine();

Trong ví dụ trên ta có 1 abstract factory là AbstractCarFactory chỉ định 2 class AbstractSedanCar và AbstractSuvCar sẽ tạo bởi concrete factory
Concrete class BmwCarFactory kế thừa AbstractCarFactory, và có thể tạo class BmwSedanCar và BmwSuvCar, đó là các class đúng với nhà sản xuất BMW.

 

Categories
Chia sẻ

Design Pattern là gì ? Mẫu thiết kế giải pháp phần mềm?

Một design pattern là một giải pháp tổng thể cho các vấn đề chung trong thiết kế phần mềm.

Một design pattern (mẫu thiết kế) không phải là một thiết kế hoàn thiện để mà có thể được chuyển đổi trực tiếp thành code, nó chỉ là một mô tả hay là sườn (template) mô tả cách giải quyết một vấn đề mà có thể được dùng trong nhiều tình huống khác nhau.

Thiết kế theo mẫu thì sẽ giúp chúng ta có 1 ứng dụng có bố cục tốt, tổ chức linh hoạt, dễ hiểu, dễ bảo trì và nâng cấp.

 

Các mẫu xuất phát từ một ý niệm kiến trúc đưa ra bởi Christopher Alexander vào năm 1987, với phát biểu: “Mỗi pattern mô tả một vấn đề xảy ra lặp đi lặp lại, và trình bày trọng tâm của giải pháp cho vấn đề đó, theo cách mà bạn có thể dùng đi dùng lại hàng triệu lần mà không cần phải suy nghĩ.”

Năm 1994, bốn tác giả Erich Gamma, Richard Helm, Ralph Johnson và John Vlissides đã cho xuất bản một cuốn sách với tiêu đề Design Patterns – Elements of Reusable Object-Oriented Software, đây là khởi nguồn của khái niệm design pattern trong lập trình phần mềm. Bốn tác giả trên được biết đến rộng rãi dưới tên Gang of Four (bộ tứ). Theo quan điểm của bốn người, design pattern chủ yếu được dựa theo những quy tắc sau đây về thiết kế hướng đối tượng:

  • Lập trình cho interface chứ không phải để implement interface đó.
  • Ưu tiên object composition hơn là thừa kế.

 

Hệ thống các mẫu Design pattern hiện có 23 mẫu được định nghĩa trong cuốn “Design patterns – Elements of Reusable Object Oriented Software” và được chia thành 3 nhóm:

Creational Pattern (nhóm khởi tạo – 5 mẫu) gồm:

  • Abstract Factory
  • Builder
  • Factory Method
  • Prototype
  • Singleton

Những Design pattern loại này cung cấp một giải pháp để tạo ra các object và che giấu được logic của việc tạo ra nó, thay vì tạo ra object một cách trực tiếp bằng cách sử dụng method new. Điều này giúp cho chương trình trở nên mềm dẻo hơn trong việc quyết định object nào cần được tạo ra trong những tình huống được đưa ra.

Structural Pattern (nhóm cấu trúc – 7 mẫu) gồm:

  • Adapter
  • Bridge
  • Composite
  • Decorator
  • Facade
  • Flyweight
  • Proxy

Những Design pattern loại này liên quan tới class và các thành phần của object. Nó dùng để thiết lập, định nghĩa quan hệ giữa các đối tượng.

Behavioral Pattern (nhóm tương tác/ hành vi – 11 mẫu) gồm:

  • Interpreter
  • Template Method
  • Chain of Responsibility
  • Command
  • Iterator
  • Mediator
  • Memento
  • Observer
  • State
  • Strategy
  • Visitor

Nhóm này dùng trong thực hiện các hành vi của đối tượng, sự giao tiếp giữa các object với nhau.

 

Chú ý: Design Pattern được tạo ra để giải quyết vấn đề, chứ không phải để phức tạp hóa nó. Design Pattern có thể giải quyết vấn đề, cũng có thể làm vấn đề rắc rối phức tạp hơn.

 

 

 

 

 

Categories
Chia sẻ

Class Diagram – Bản vẽ về các lớp khi phân tích thiết kế hệ thống

Class Diagram là một loại sơ đồ cấu trúc tĩnh mô tả cấu trúc của hệ thống bằng cách hiển thị các lớp của hệ thống, thuộc tính, hoạt động của chúng và mối quan hệ giữa các đối tượng. Sơ đồ lớp là khối xây dựng chính của mô hình hướng đối tượng.

Vẽ biểu đồ Class để làm gì? Lợi ích mà biểu đồ Class mang lại

  • Hiểu cấu trúc của hệ thống
  • Thiết kế hệ thống
  • Sử dụng để phân tích chi tiết các chức năng (Sequence Diagram, State Diagram v.v…)
  • Sử dụng để cài đặt (coding)

Các thành phần trong bản vẽ Class

Classes (Các lớp)

Class là thành phần chính của bản vẽ Class Diagram. Class mô tả về một nhóm đối tượng có cùng tính chất, hành động trong hệ thống. Class được mô tả gồm tên Class, thuộc tính và phương thức.

Biểu diễn class trong bản vẽ
  • Class Name: là tên của lớp.
  • Attributes (thuộc tính): mô tả tính chất của các đối tượng.
  • Method (Phương thức): chỉ các hành động mà đối tượng này có thể thực hiện trong hệ thống. Nó thể hiện hành vi của các đối tượng do lớp này tạo ra.

Relationship (Quan hệ)

Relationship thể hiện mối quan hệ giữa các Class với nhau. Các quan hệ thường sử dụng như sau:

  • Association: là quan hệ giữa hai lớp với nhau, thể hiện chúng có liên quan với nhau. Association thể hiện qua các quan hệ như “has: có”, “Own: sở hữu” v.v… Ví dụ quan hệ trên thể hiện Khách hàng nắm giữ Tài khoản và Tài khoản được sở hữu bởi Khách hàng.
  • Aggregation: là một loại của quan hệ Association nhưng mạnh hơn. Nó có thể cùng thời gian sống (cùng sinh ra hoặc cùng chết đi). Ví dụ quan hệ trên thể hiện lớp Window(cửa sổ) được lắp trên Khung cửa hình chữ nhật. Nó có thể cùng sinh ra cùng lúc.
  • Composition: là một loại mạnh hơn của Aggregation thể hiện quan hệ class này là một phần của class kia nên dẫn đến cùng tạo ra hoặc cùng chết đi. Ví dụ trên class Mailing Address là một phần của class Customer nên chỉ khi nào có đối tượng Customer thì mới phát sinh đối tượng Mailing Address.
  • Generalization: là quan hệ thừa kế được sử dụng rộng rãi trong lập trình hướng đối tượng.

Cách xây dựng bản vẽ Class

Class Diagram là bản vẽ khó xây dựng nhất so với các bản vẽ khác trong OOAD và UML. Bạn phải hiểu được hệ thống một cách rõ ràng và có kinh nghiệm về lập trình hướng đối tượng mới có thể xây dựng thành công bản vẽ này.

Bước 1: Tìm các Classes dự kiến

Entity Classes(các lớp thực thể) là các thực thể có thật và hoạt động trong hệ thống, bạn dựa vào các nguồn sau để xác định chúng. Các nguồn thông tin có thể tìm Class dự kiến:

  • Requirement statement: Các yêu cầu. Chúng ta phân tích các “danh từ” trong các yêu cầu để tìm ra các thực thể.
  • Use Cases: Phân tích các Use Case sẽ cung cấp thêm các Classes dự kiến.
  • Previous và Similar System: Hệ thống trước đây đã sử dụng và các hệ thống tương tự có thể sẽ cung cấp thêm cho bạn các lớp dự kiến.
  • Application Experts: các chuyên gia ứng dụng cũng có thể giúp bạn.

Bước 2: Tìm các thuộc tính và phương thức cho lớp

Tìm thuộc tính: phân tích thông tin từ các form mẫu có sẵn, bạn sẽ tìm ra thuộc tính cho các đối tượng của lớp.

Tìm phương thức: phương thức là các hoạt động mà các đối tượng của lớp này có thể thực hiện. Chúng ta sẽ bổ sung phương thức đầy đủ cho các lớp khi phân tích Sequence Diagram sau này.

Bước 3: Xây dựng các quan hệ giữa các lớp và phát hiện các lớp phát sinh

Phân tích các quan hệ giữa các lớp và định nghĩa các lớp phát sinh do các quan hệ sinh ra.

Ví dụ thực tế xây dựng biểu đồ Class

Tiếp theo ví dụ về biểu đồ Use Case cho cộng đồng chia sẻ khuyến mại chanhtuoi trong bài trước, chúng ta sẽ follow các bước nêu ở phần trên và đưa ra bản vẽ class.

Bản vẽ class của cộng đồng chia sẻ khuyến mại chanhtuoi.com

Tìm các Classes dự kiến

  • Users: thành viên đăng ký trên trang là một thực thể có thật
  • Posts: Các bài viết khuyến mại, mã giảm giá là một đối tượng thực thể
  • Blogs: Các bài blogs
  • Pages: Các trang tĩnh
  • Comments

Tìm các thuộc tính

Tìm các thuộc tính của các lớp đã xác định, ví dụ cho Users sẽ có các thuộc tính: ID định danh, tên đăng nhập, địa chỉ email, mật khẩu, tên hiển thị trên web, thông tin, ngày tham gia, cập nhật

Tìm các phương thức

Tìm các phương thức, ví dụ Users sẽ có các phương thức: đăng nhập, xem danh sách khuyến mại, comment, like …

Xây dựng các lớp phát sinh

Xây dựng các lớp phát sinh ví dụ như Badgess phát sinh khi nhu cầu đánh giá các thẻ của thành viên như biên tập viên, người chia sẻ, fan cứng …

Categories
Chia sẻ

Use Case Diagram – bản vẽ mô tả về ca sử dụng của hệ thống

Trong bài viết “Phân tích thiết kế hệ thống hướng đối tượng (OOAD) và ngôn ngữ mô hình hóa (UML)” chúng ta đã chỉ ra bản vẽ Use Case sẽ giúp chúng ta biết được ai sử dụng hệ thống, hệ thống có những chức năng gì, giúp chúng ta sẽ hiểu được yêu cầu của hệ thống cần xây dựng.

Vẽ biểu đồ Use Case để làm gì? Lợi ích mà biểu đồ Use Case mang lại

  • Phân tích và hiểu hệ thống.
  • Thiết kế hệ thống.
  • Làm cơ sở cho việc phát triển, kiểm tra các bản vẽ như Class Diagram, Activity Diagram, Sequence Diagram, Component Diagram.
  • Làm cơ sở để giao tiếp với khách hàng, các nhà đầu tư.
  • Giúp cho việc kiểm thử chức năng, kiểm thử chấp nhận.
  • Làm tài liệu cho hệ thống.

Các thành phần của bản vẽ Use Case

Actor

Actor là người dùng hoặc đối tượng tương tác với một hệ thống. Mỗi Actor có thể là một người, một tổ chức hoặc một hệ thống bên ngoài tương tác với ứng dụng hoặc hệ thống của bạn

Biểu diễn Actor

Use Case

Use Case là chức năng mà các Actor sẽ sử dụng trên hệ thống

Biểu diễn Use Case

Relationship – các quan hệ

Relationship hay còn gọi là conntector được sử dụng để kết nối giữa các đối tượng với nhau tạo nên bản vẽ Use Case.

Các loại quan hệ trong use case

Có các kiểu quan hệ cơ bản sau:

  • Association : thường được dùng để mô tả mối quan hệ giữa Actor và Use Case và giữa các Use Case với nhau.
  • Generalization: được sử dụng để thể hiện quan hệ thừa kế giữa các Actor hoặc giữa các Use Case với nhau.
  • Include: là quan hệ giữa các Use Case với nhau, nó mô tả việc một Use Case lớn được chia ra thành các Use Case nhỏ để dễ cài đặt (module hóa) hoặc thể hiện sự dùng lại.
  • Extend: dùng để mô tả quan hệ giữa 2 Use Case. Quan hệ Extend được sử dụng khi có một Use Case được tạo ra để bổ sung chức năng cho một Use Case có sẵn và được sử dụng trong một điều kiện nhất định nào đó.

System Boundary

System Boundary được sử dụng để xác định phạm vi của hệ thống mà chúng ta đang thiết kế. Các đối tượng nằm ngoài hệ thống này có tương tác với hệ thống được xem là các Actor. System Boundary sẽ giúp chúng ta dễ hiểu hơn khi chia hệ thống lớn thành các hệ thống con để phân tích, thiết kế.

Các bước xây dựng Use Case Diagram

Trước hết, để phân tích một hệ thống bạn phải có kiến thức và hiểu biết về chức năng, nghiệp vụ, quy trình hoạt động … của hệ thống đó

Bước 1: Tìm các Actor

Trả lời các câu hỏi sau để xác định Actor cho hệ thống:

  • Ai sử dụng hệ thống này?
  • Hệ thống nào tương tác với hệ thống này?

Bước 2: Tìm các Use Case

Trả lời câu hỏi các Actor sử dụng chức năng gì trong hệ thống? chúng ta sẽ xác định được các Use Case cần thiết cho hệ thống.

Bước 3: Xác định các quan hệ

Phân tích và các định các quan loại hệ giữa các Actor và Use Case, giữa các Actor với nhau, giữa các Use Case với nhau sau đó nối chúng lại chúng ta sẽ được bản vẽ Use Case.

Ví dụ thực tế xây dựng biểu đồ Use Case

Xây dựng biểu đồ Use Case cho cộng đồng chia sẻ khuyến mại chanhtuoi mà tôi đã thực hiện trước đây. (Thực tế hiện tại qua thời gian phát triển, tính năng của chanhtuoi đã thay đổi nhiều so với thiết kế ban đầu)

Trả lời các câu hỏi ai sử dụng hệ thống? và hệ thống nào tương tác với chanhtuoi ta xác định được 3 Actor: khách truy cập vãng lai (Guest), thành viên đã đăng ký (Registered User), quản trị viên (Administrator)

Tìm các chức năng mà các Actor vừa tìm được sử dụng:

Guest: đăng nhập, đăng ký, đăng nhập bằng mạng xã hội, nhận hướng dẫn sau đăng ký, đăng ký email nhận tin, xem danh sách khuyến mại theo các tiêu chỉ nổi bật, danh mục, thương hiệu, địa điểm, tác giả, xem chi tiết deal, hành động like share mạng xã hội, gửi phản hồi, tìm kiếm khuyến mại, xem blogs, xem các trang thông tin như giới thiệu, chính sách

Registered User: đăng ký email nhận tin, xem danh sách khuyến mại theo các tiêu chỉ nổi bật, danh mục, thương hiệu, địa điểm, tác giả, xem chi tiết deal, hành động like share mạng xã hội, gửi phản hồi, tìm kiếm khuyến mại, xem blogs, xem các trang thông tin như giới thiệu, chính sách, xem trang cá nhân, theo dõi thành viên khách, quản lý hồ sơ cá nhân, đăng khuyến mại, chỉnh sửa khuyến mại của mình, bình chọn cho khuyến mại, bình luận, like bình luận, tích điểm

Administrator: Đăng nhập, thay đổi ngôn ngữ quản trị, quản lý seo, quản lý thành viên, quản lý trang, khuyến mại, kiểu khuyến mại, bình luận, cấu hình trang web, xem các báo cáo, quản lý tài khoản quản trị khác.

Kết luận

Use Case Diagram có một vai trò đặc biệt quan trọng trong quá trình phân tích, thiết kế và phát triển hệ thống. Hi vọng qua bài viết sẽ giúp chúng ta hiểu hơn và sử dụng bản vẽ Use Case trong việc phân tích các hệ thống một cách hiệu quả.

Categories
Chia sẻ

Phân tích thiết kế hệ thống hướng đối tượng (OOAD) và ngôn ngữ mô hình hóa (UML)

Khi thực hiện các dự án phần mềm, ứng dụng tôi có thói quen chia đôi thời gian thực hiện, một nửa dành cho việc tìm hiểu nghiệp vụ, phân tích tính năng và thiết kế database, một nửa thời gian còn lại dành cho việc code. Trong thời đại mở của các nền tảng kỹ thuật chúng ta hoàn toàn có thể áp dụng những công nghệ tốt nhất cho hiệu suất ứng dụng của mình, lúc này việc ứng dụng hoạt động ổn định, đúng nghiệp vụ, dễ dàng mở rộng theo yêu cầu thay đổi của tình hình thực tế lại là điều quan trọng hơn.

Phân tích và thiết kế hướng đối tượng OOAD (Object Oriented Analysis and Design) và ngôn ngữ mô hình hóa UML (Unified Modeling Language) phổ biến và được đưa vào các trường đào tạo ngành CNTT tuy nhiên để áp dụng thực tế với sinh viên vẫn còn tương đối khó khăn. Trong bài này chúng ta sẽ tiếp cận bằng cách đơn giản những kiến thức về Phân tích và thiết kế hướng đối tượng và UML để cùng hiểu và áp dụng vào thực tế.

Khái niệm OOAD (Object Oriented Analysis and Design)

Phân tích và thiết kế hướng đối tượng là một kỹ thuật tiếp cận phổ biến dùng để phân tích, thiết kế một ứng dụng, hệ thống. Nó dựa trên bộ các nguyên tắc chung, đó là một tập các hướng dẫn để giúp chúng ta tránh khỏi một thiết kế xấu. 5 nguyên tắc SOLID trong thiết kế hướng đối tượng:

  1. Một lớp chỉ nên có một lý do để thay đổi, tức là một lớp chỉ nên xử lý một chức năng đơn lẻ, duy nhất thôi. Nếu đặt nhiều chức năng vào trong một lớp sẽ dẫn đến sự phụ thuộc giữa các chức năng với nhau và mặc dù sau đó ta chỉ thay đổi ở một chức năng thì cũng phá vỡ các chức năng còn lại.
  2. Các lớp, module, chức năng nên dễ dàng Mở (Open) cho việc mở rộng (thêm chức năng mới) và Đóng (Close) cho việc thay đổi.
  3. Lớp dẫn xuất phải có khả năng thay thế được lớp cha của nó.
  4. Chương trình không nên buộc phải cài đặt một interface mà nó không sử dụng đến.
  5. Các module cấp cao không nên phụ thuộc vào các module cấp thấp. Cả hai nên phụ thuộc thông qua lớp trừu tượng. Lớp trừu tượng không nên phụ thuộc vào chi tiết. Chi tiết nên phụ thuộc vào trừu tượng

Khái niệm UML

UML là ngôn ngữ mô hình hóa hợp nhất dùng để biểu diễn hệ thống. Nói một cách đơn giản là nó dùng để tạo ra các bản vẽ nhằm mô tả thiết kế hệ thống. Các bản vẽ này được sử dụng để các nhóm thiết kế trao đổi với nhau cũng như dùng để thi công hệ thống (phát triển), thuyết phục khách hàng, các nhà đầu tư v.v..

Tại sao lại là OOAD và UML?

OOAD cần các bản vẽ để mô tả hệ thống được thiết kế, còn UML là ngôn ngữ mô tả các bản vẽ nên cần nội dung thể hiện. Do vậy, chúng ta phân tích và thiết kế theo hướng đối tượng và sử dụng UML để biểu diễn các thiết kế đó nên chúng thường đi đôi với nhau.

OOAD sử dụng UML

UML sử dụng để vẽ cho nhiều lĩnh vực khác nhau như phần mềm, cơ khí, xây dựng v… trong phạm vi các bài viết này chúng ta chỉ nghiên cứu cách sử dụng UML cho phân tích và thiết kế hướng đối tượng trong ngành phần mềm. OOAD sử dụng UML bao gồm các thành phần sau:

  • View (góc nhìn)
  • Diagram (bản vẽ)
  • Notations (ký hiệu)
  • Mechanisms (qui tắc, cơ chế)

Chúng ta sẽ tìm hiểu kỹ hơn các thành phần trên.

View (góc nhìn)

Mỗi góc nhìn như thầy bói xem voi, nó không thể hiện hết hệ thống nhưng thể hiện rõ hệ thống ở một khía cạnh. Chính vì thế trong xây dựng có bản vẽ kiến trúc (nhìn về mặt kiến trúc), bản vẽ kết cấu (nhìn về mặt kết cấu), bản vẽ thi công (nhìn về mặt thi công). Trong phần mềm cũng như vậy, OOAD sử dụng UML có các góc nhìn sau:

Trong đó,

  • Use Case View: cung cấp góc nhìn về các ca sử dụng giúp chúng ta hiểu hệ thống có gì? ai dùng và dùng nó như thế nào.
  • Logical View: cung cấp góc nhìn về cấu trúc hệ thống, xem nó được tổ chức như thế nào. Bên trong nó có gì.
  • Process View: cung cấp góc nhìn động về hệ thống, xem các thành phần trong hệ thống tương tác với nhau như thế nào.
  • Component View: Cũng là một góc nhìn về cấu trúc giúp chúng ta hiểu cách phân bổ và sử dụng lại các thành phần trong hệ thống ra sao.
  • Deployment View: cung cấp góc nhìn về triển khai hệ thống, nó cũng ảnh hưởng lớn đến kiến trúc hệ thống.

Tập hợp các góc nhìn này sẽ giúp chúng ta hiểu rõ hệ thống cần phân tích, thiết kế. Trong hình trên chúng ta thấy góc nhìn Use Case View nằm ở giữa và chi phối tất cả các góc nhìn còn lại. Chính vì thế chúng ta thường thấy các tài liệu nói về 4 view + 1 chứ không phải 5 view nhằm nhấn mạnh vai trò của Use Case View.

Diagram (Bản vẽ)

Diagram chúng ta có thể dịch là sơ đồ. Tuy nhiên ở đây chúng ta sử dụng từ bản vẽ cho dễ hình dung. Các bản vẽ được dùng để thể hiện các góc nhìn của hệ thống.

Trong đó,

  • Use Case Diagram: bản vẽ mô tả về ca sử dụng của hệ thống. Bản vẽ này sẽ giúp chúng ta biết được ai sử dụng hệ thống, hệ thống có những chức năng gì. Lập được bản vẽ này chúng ta sẽ hiểu được yêu cầu của hệ thống cần xây dựng.
  • Class Diagram: bản vẽ này mô tả cấu trúc của hệ thống, tức hệ thống được cấu tạo từ những thành phần nào. Nó mô tả khía cạnh tĩnh của hệ thống.
  • Object Diagram: Tương tự như Class Diagram nhưng nó mô tả đến đối tượng thay vì lớp (Class).
  • Sequence Diagram: là bản vẽ mô tả sự tương tác của các đối tượng trong hệ thống với nhau được mô tả tuần tự các bước tương tác theo thời gian.
  • Collaboration Diagram: tương tự như sequence Diagram nhưng nhấn mạnh về sự tương tác thay vì tuần tự theo thời gian.
  • State Diagram: bản vẽ mô tả sự thay đổi trạng thái của một đối tượng. Nó được dùng để theo dõi các đối tượng có trạng thái thay đổi nhiều trong hệ thống.
  • Activity Diagram: bản vẽ mô tả các hoạt động của đối tượng, thường được sử dụng để hiểu về nghiệp vụ của hệ thống.
  • Component Diagram: bản vẽ mô tả về việc bố trí các thành phần của hệ thống cũng như việc sử dụng các thành phần đó.
  • Deployment Diagram: bản vẽ mô tả việc triển khai của hệ thống như việc kết nối, cài đặt, hiệu năng của hệ thống v.v…

Notations (các ký hiệu)

Notations là các ký hiệu để vẽ, nó như từ vựng trong ngôn ngữ tự nhiên. Chúng ta phải biết từ vựng thì mới ghép thành câu, thành bài được. Chúng ta sẽ tìm hiểu kỹ các notations trong từng bản vẽ sau này. Dưới đây là vài ví dụ về notation.

Hình trên là ví dụ về ký hiệu của Use Case, Class, Actor, ngoài ra còn rất nhiều các ký hiệu khác

Mechanisms (Rules)

Mechanisms là các qui tắc để lập nên bản vẽ, mỗi bản vẽ có qui tắc riêng và chúng ta phải nắm được để tạo nên các bản vẽ thiết kế đúng. Các qui tắc này chúng ta sẽ bàn kỹ trong các bài về các bản vẽ.

Tổng kết

Nguyên tắc phân tích, thiết kế một hệ thống phần mềm cũng không khác việc xây dựng một cái nhà trong xây dựng. Chúng ta nên nhớ cách tiếp cận này để dễ hiểu hơn trong việc phân tích và thiết kế hệ thống. Hãy giữ mọi thứ cho thật đơn giản để dễ hiểu và dễ áp dụng.

Trong thực tế, tùy vào độ phức tạp của dự án mà chúng ta có thể lược bỏ đi một số bản vẽ không cần thiết (bản vẽ cho các phần đơn giản, không phức tạp). Tôi thường vẽ Use Case Diagram, Class Diagram như hai bản bắt buộc và Activity Diagram cho một số tính năng phức tạp.