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ẻ

Kiểu CHAR và VARCHAR trong mysql. Độ dài khai báo kiểu varchar(1 – 255) có ý nghĩa thế nào

Khác biệt giữa VARCHAR và CHAR trong MySQL

Kiểu CHAR và VARCHAR trong mysql tương tự nhau cùng để lưu trữ dữ liệu dạng string, nhưng khác nhau về cách chúng được lưu trữ và truy xuất. Chúng cũng khác nhau về chiều dài tối đa và số lượng các khoảng trống được thêm vào bộ nhớ khi lưu trữ.

CHAR và VARCHAR được khai báo với độ dài cho biết số lượng ký tự tối đa bạn muốn lưu trữ. Ví dụ: CHAR (30) có thể chứa tối đa 30 ký tự.

Độ dài của cột CHAR được cố định với độ dài mà bạn khai báo khi bạn tạo bảng. Độ dài có thể là bất kỳ giá trị nào từ 0 đến 255. Khi các giá trị CHAR được lưu trữ, chúng được đệm bên phải với khoảng trắng theo chiều dài đã chỉ định. Với VARCHAR số lượng khoảng trắng được đệm thêm chỉ là 1.

Các giá trị trong các cột VARCHAR là các chuỗi có độ dài thay đổi. Có thể hiểu đơn giản theo nghĩa của từ VAR đừng trước CHAR để phân biệt bản chẩn của CHAR và VARCHAR.

Ví dụ sau đây minh họa sự khác biệt giữa CHAR và VARCHAR bằng cách hiển thị kết quả của việc lưu trữ các giá trị chuỗi khác nhau vào các cột CHAR (4) và VARCHAR (4) (giả sử rằng cột sử dụng bộ ký tự một byte như latin1).

Value CHAR(4) Storage Required VARCHAR(4) Storage Required
'' '    ' 4 bytes '' 1 byte
'ab' 'ab  ' 4 bytes 'ab' 3 bytes
'abcd' 'abcd' 4 bytes 'abcd' 5 bytes
'abcdefgh' 'abcd' 4 bytes 'abcd' 5 bytes

Như vậy nếu bạn dùng VARCHAR, số lượng ký tự quy định trong kiểu này ví dụ VARCHAR(255) chỉ quy định độ dài ký tự tối đa được phép lưu trữ mà không ảnh hưởng đến kích thước lưu trữ. Còn nếu bạn dùng CHAR, ví dụ CHAR(255) bộ nhỡ sẽ luôn lưu trữ 255 ký tự. Rõ ràng chúng ta nên dùng VARCHAR.

Ý nghĩa độ dài ký tự định nghĩa của kiểu VARCHAR

Câu hỏi tiếp theo đặt ra là khi dùng VARCHAR độ dài quy định có còn quan trong khi bạn lưu trữ các thông tin luôn có số lượng ký tự ít, ví dụ lưu tên người dùng thường chỉ có số lượng vài đến hơn chục ký tự, chúng ta có thể để VARCHAR(20) và VARCHAR(255) có khác gì ?

Câu trả lời là rất khác biệt, khi bạn truy vấn dữ liệu các trường VARCHAR sẽ được MySQL chuyển đổi thành CHAR để dễ dàng làm việc với các hàng có chiều rộng cố định. Vì vậy, các chuỗi trong bộ nhớ đệm lúc này sẽ theo chiều dài tối đa cột VARCHAR được khai báo.

Các truy vấn ngầm tạo ra các bảng trên bộ nhớ tạm, trong một số trường hợp như sắp xếp(ORDER BY) hoặc nhóm(GROUP BY) có thể sử dụng rất nhiều bộ nhớ khi quy định dữ liệu kiểu VARCHAR của bạn không sát với thực tế dữ liệu. Nếu bạn sử dụng nhiều trường VARCHAR(255) cho dữ liệu không cần dài như vậy, điều này có thể làm cho bảng tạm thời trở nên rất lớn, làm ảnh hưởng đến tốc độ fetch dữ liệu để đưa ra result, một số trượng hợp gây “out of memory” cho Ram.

Kết luận: Trường dữ liệu VARCHAR và các kiểu TEXT nói chung khi thiết kế CSDL chúng ta nên định nghĩa số lượng ký tự sát với thực tế lưu trữ cho một database tối ưu nhất.

Categories
Chia sẻ

Rclone – công cụ dòng lệnh giúp đồng bộ hóa các file và thư mục lưu trữ đám mây (cloud storage)

Rclone là một chương trình dòng lệnh để đồng bộ hóa các tệp và thư mục đến và từ các nhà cung cấp lưu trữ đám mây khác nhau.

Các nhà cung cấp và drive phổ biến có thể kể đến như: Google Drive, Amazon Drive, S3, Dropbox, Backblaze B2, One Drive, Swift, Hubic, Cloudfiles, Google Cloud Storage, Yandex Files … Ngoài ra còn rất nhiều nhà cung cấp khác. Các bạn có thể tham khảo tại trang chủ rclone

Rclone hỗ trợ đa dạng và đầy đủ các hệ điều hành và môi trường khác nhau như: Windows, macOS, Linux, .deb, .rpm, FreeBSD, NetBSD, OpenBSD, Plan9, Solaris

Cách cài đặt và sử dụng rclone trên windows

  • Download phiên bản phù hợp với hệ điều hành tại đây
  • Giải nén file tải về ra thư mục (đây chính là thư mục làm việc với rclone)
  • Mở Command Prompt tại thư mục giải nén ở trên để làm việc với rclone

Cấu hình Rclone

Dùng lệnh rclone config đề cài đặt remote của bạn. Chương trình sẽ hiện ra các yêu cầu với các input để bạn nhập vào rất dễ hiểu. Chú ý nếu muốn chọn máy tính của mình như 1 remote thì type chính là “local”. Lúc này thư mục gốc chính là thư mục rclone

Các lệnh cơ bản hay sử dụng với rclone

  • rclone lsd – Liệt kê tất cả directories/containers/buckets
  • rclone size – Đưa ra thông tin size của directories/containers/buckets
  • rclone copy – Coppy file từ nguồn tới đích. VD: rclone copy local:abc s3:abc/images
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ẻ

Các công cụ sử dụng để xây dựng bản vẽ UML. Giới thiệu công cụ StarUML

Before you start to take it Tell your doctor if: You have any allergies https://vgrsingapore.net/brand-cialis-singapore.html to any other medicines or any other substances such as foods, preservatives or dyes You have any other heart or blood vessel problems You have previously had sudden loss of eyesight in one or both eyes. Prescribing antibiotic the doctor must appraise indication and contra-indication.

Các công cụ xây dựng bản vẽ UML phổ biến

Hiện nay có rất nhiều công cụ được sử dụng để vẽ các bản vẽ UML rất chuyên nghiệp như Gliffy, Microsoft Visio, ArgoUML, MagicDraw, StarUML … và rất nhiều các công cụ phần mềm nguồn mở miễn phí có thể sử dụng tốt.

Các công cụ có cách sử dụng khá giống nhau và ký hiệu của các bạn vẽ trên UML cũng đã thống nhất nên việc nắm bắt một công cụ khi chuyển sang làm việc với một công cụ khá không quá khó khăn.

Bài viết này sẽ giới thiệu công cụ StarUML trên môi trường Windows tương đối đầy đủ tính năng và dễ sử dụng.

Giới thiệu về StarUML

Bạn có thể download phần mềm StarUML tại trang chủ. Sau khi download các bước cài đặt bình thường trên máy tính của bạn.

Nhìn vào cửa sổ giao diện của StarUML chúng ta sẽ thấy các thành phần:

  • Board làm việc chính – khung máu trắng ở chính giữa với các ô đơn vị được kẻ sẵn giúp dễ dàng căn chỉnh đối tượng
  • Model Explorer: Chứa các thông tin và cấu trúc của project đang làm việc ở góc phải trên
  • Working Diagrams: Thông tin về các bản vẽ đang làm việc ở góc trái trên
  • Toolbox: Các công cụ tương ứng với bản vẽ đang làm việc ở góc trái dưới
  • Editors: Các properties của đối tượng khi làm việc ở góc phải dưới

Cách tạo các Diagram

Để tạo bản vẽ mới, chúng ta chuột phải vào model muốn tạo bản vẽ rồi chọn Add Diagram, trong menu đổ ra chọn tiếp bản vẽ mong muốn để tạo.

Cách tạo ra một bản vẽ

Sau khi chọn bản vẽ, cửa sổ bên trái sẽ hiển thị thanh công cụ chứa các ký hiệu tương ứng của bản vẽ để bạn có thể vẽ được các bản vẽ một các dễ dàng.

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.

Categories
Chia sẻ

Xem lại truy vấn (query) gần nhất và lịch sử truy vấn trên MySql >= 5.1.12

Tùy chọn options lưu lại lịch sử queries một cách global bằng các bước:

  1. Execute: SET GLOBAL log_output = ‘TABLE’;
  2. Execute: SET GLOBAL general_log = ‘ON’;
  3. Lịch sử sẽ lưu ở bảng trong database mysql bảng general_log

Nếu bạn muốn xuất ra một tệp thay vì bảng:

  1. SET GLOBAL log_output = “FILE”;
  2. SET GLOBAL general_log_file = “/path/to/your/logfile.log”;
  3. SET GLOBAL general_log = ‘ON’;

 

Với các phiên bản trước ta có thể sửa file my.cnf , vd: /etc/mysql/my.cnf

[mysqld]
log = /var/log/mysql/mysql.log

Khởi động lại mysql để nhận thay đổi, bây giờ bạn có thể

tail -f /var/log/mysql/mysql.log

 

Xem thêm chi tiết tham khảo tại: MySQL 5.1 Reference Manual – Server System Variables – general_log

Categories
Chia sẻ

Cài Supervisor và cấu hình để chạy queue cho Laravel trên CentOs 7

Cài Supervisor trên CentOs 7 step by step:

easy_install supervisor

 

yum install supervisor

 

Sửa file cấu hình để chạy queue:

vi /etc/supervisord.conf

Cấu hình:

[program:laravel-worker]
process_name=%(program_name)s_%(process_num)02d
command=php /path/to/app.com/public_html/artisan queue:work --sleep=1 --tries=3 --timeout=120
autostart=true
autorestart=true
user=nginx
numprocs=8
redirect_stderr=true
stdout_logfile=/path/to/app.com/public_html/worker.log

 

Cho nó start cùng sv:

systemctl enable supervisord

 

Restart service:

systemctl restart supervisord