- vừa được xem lúc

Thiết kế Hướng Đối Tượng Hệ Thống Quản Lý Thư Viện

0 0 7

Người đăng: thavrith

Theo Viblo Asia

Problem definition

Hệ thống Quản lý Thư viện (Library Management System - LMS) được thiết kế nhằm tự động hóa các hoạt động của thư viện. Hệ thống này giúp chúng ta quản lý và duy trì hồ sơ của sách và hội viên một cách toàn diện và có tổ chức.

Với phần mềm này, thủ thư có thể dễ dàng theo dõi các thông tin như: danh sách các cuốn sách hiện có trong thư viện, sách đã được mượn và thời hạn trả, lịch sử mượn và trả sách của từng hội viên, tình trạng sẵn có của sách, và vị trí cụ thể của từng cuốn sách trong thư viện để hỗ trợ hội viên tìm và mượn sách một cách thuận tiện, v.v.

Tóm lại, hệ thống quản lý thư viện giúp tổ chức và truy xuất dữ liệu của thư viện một cách hiệu quả và nhanh chóng.

Hướng tiếp cận thiết kế (Design approach)

Chúng ta sẽ thiết kế Hệ thống Quản lý Thư viện theo phương pháp thiết kế "từ dưới lên" (bottom-up design). Quá trình này bao gồm các bước sau:

  • Trước tiên, xác định và thiết kế các thành phần nhỏ nhất của hệ thống.
  • Sau đó, sử dụng các thành phần nhỏ này để xây dựng thành phần lớn hơn.
  • Lặp lại quy trình này cho đến khi hoàn thành thiết kế của toàn bộ hệ thống.

Requirements đối với Hệ thống Quản lý Thư viện

Chúng ta sẽ liệt kê các yêu cầu (requirement) của LMS. Đây là một bước rất quan trọng vì các yêu cầu sẽ xác định phạm vi (scope) của vấn đề. Việc nắm bắt chính xác và hiểu rõ requirements sẽ giúp quá trình thiết kế diễn ra thuận lợi và hiệu quả.

Chúng ta sẽ sử dụng ký hiệu để đánh số các yêu cầu, mỗi yêu cầu sẽ được gắn nhãn “Rn,” trong đó “R” là viết tắt của Requirement (Yêu cầu) và “n” là một số tự nhiên.

Thu thập requirements

Lưu ý: requirements ở đây được dựa trên tác giả

Dưới đây là requirements cho hệ thống LMS:

R1: Hệ thống phải có khả năng lưu trữ thông tin về sách và thành viên của thư viện, bao gồm cả lịch sử mượn sách.

R2: Mỗi cuốn sách phải có một mã nhận dạng duy nhất và thông tin về vị trí kệ sách để giúp xác định vị trí thực tế của sách trong thư viện.

R3: Mỗi cuốn sách cần có một ISBN (hay Số tiêu chuẩn quốc tế cho sách) , tiêu đề, tên tác giả, chủ đề và ngày xuất bản.

R4: Thư viện có thể có nhiều bản sao của cùng một cuốn sách. Mỗi bản sao này được xem như một thực thể riêng biệt, có thể được theo dõi về tình trạng, vị trí, và tính khả dụng.

R5: Có hai loại người dùng (user): là thủ thư (librarian) và thành viên (member).

R6: Mỗi người dùng cần có thẻ thư viện với số thẻ duy nhất.

R7: Mỗi thành viên được phép mượn tối đa 10 cuốn sách cùng lúc (sau khi trả sách mới có thể mượn thêm).

R8: Thời gian mượn tối đa cho mỗi cuốn sách là 15 ngày.

R9: Mỗi cuốn sách chỉ có thể được đặt giữ bởi một thành viên tại một thời điểm.

R10: Hệ thống cần lưu trữ thông tin về người mượn hoặc đặt giữ sách, cùng với ngày mượn hoặc đặt giữ.

R11: Hệ thống phải cho phép thành viên gia hạn thời gian mượn sách đã đặt giữ.

R12: Hệ thống phải gửi thông báo nếu sách không được trả đúng hạn.

R13: Nếu sách không có sẵn, thành viên phải có khả năng đặt giữ sách cho đến khi nó có sẵn.

R14: Hệ thống phải cho phép người dùng tìm kiếm sách theo tiêu đề, tên tác giả, chủ đề hoặc ngày xuất bản.

Use Case Diagram cho Hệ thống Quản lý Thư viện

System

System của chúng ta là một "library".

Actors

Tiếp theo, chúng ta sẽ define các actors:

Primary actors

  • Thành viên (Member): Thành viên có thể thực hiện các tác vụ như tìm kiếm, đặt giữ, gia hạn, trả sách và thay đổi thông tin tư cách thành viên của mình.
  • Thủ thư (Librarian): Thủ thư là người quản trị hệ thống thư viện, có thể thêm, xóa sách, thay đổi trạng thái của sách hoặc thành viên, cho mượn sách, v.v.

Secondary actors

  • Hệ thống (System): Hệ thống có khả năng tự động gửi các thông báo liên quan đến việc đặt giữ sách hoặc nhắc nhở khi sách bị trả muộn.

Use Cases

Trong phần này, chúng ta sẽ xác định các use cases cụ thể cho thư viện. Chúng ta liệt kê các use cases dựa trên các tương tác tương ứng của chúng với từng actor cụ thể.

Librarian

  • Add book: Thêm một cuốn sách mới vào thư viện.

  • Remove book: Xóa một cuốn sách hiện có khỏi thư viện.

  • Edit book: Sửa đổi thông tin của một cuốn sách.

  • Register new account: Đăng ký một thành viên mới cho thư viện.

  • Cancel membership: Hủy tư cách thành viên thư viện của một thành viên.

  • Register/Update account: Tạo mới hoặc cập nhật tài khoản.

  • Login/Logout: Đăng nhập hoặc đăng xuất tài khoản.

  • Issue book: Cấp phát sách cho một thành viên.

  • Remove reservation: Xóa đặt giữ sách.

  • Renew book: Gia hạn thời gian mượn sách.

  • Reserve book: Đặt giữ một cuốn sách hiện không có sẵn.

  • View account: Xem và truy cập tất cả thông tin của tài khoản.

Member

  • Search catalog: Tìm kiếm sách trong thư viện.

  • Cancel membership: Hủy tư cách thành viên thư viện của một thành viên.

  • Register/Update account: Tạo mới hoặc cập nhật tài khoản.

  • Login/Logout: Đăng nhập hoặc đăng xuất tài khoản.

  • Checkout book: Hoàn tất quá trình mượn sách.

  • Remove reservation: Xóa đặt giữ sách.

  • Renew book: Gia hạn thời gian mượn sách.

  • Reserve book: Đặt giữ một cuốn sách hiện không có sẵn.

  • View account: Xem và truy cập tất cả thông tin của tài khoản.

  • Return book: Trả sách cho thư viện.

System

  • Overdue notification: Gửi thông báo nếu sách không được trả đúng hạn.

  • Reservation available notification: Hệ thống tự động thông báo cho thành viên khi có một cuốn sách mà họ đã đưa vào danh sách đặt giữ đang có sẵn.

  • Reservation canceled notification: Gửi thông báo cho thành viên khi đặt chỗ cho một cuốn sách của họ đã bị hủy. Điều này có thể xảy ra do nhiều lý do như thành viên tự hủy đặt giữ sách hoặc sách bị xóa khỏi thư viện.

Một số use cases không trực tiếp liên quan đến bất kỳ actor nào. Chúng được mô tả dưới đây.

  • Add book item: Thêm mục sách vào danh mục.

  • Edit book item: Chỉnh sửa chi tiết của mục sách trong danh mục.

  • Remove book item: Xóa mục sách khỏi danh mục.

  • Update catalog: Cập nhật (thêm, sửa, hoặc xóa) một mục sách hoặc sách trong danh mục.

  • Issue library card: Cấp thẻ thư viện cho các thành viên mới để nhận dạng.

  • By subject name: Tìm sách trong danh mục theo chủ đề.

  • By book title: Tìm sách trong danh mục theo tiêu đề.

  • By author name: Tìm sách trong danh mục theo tên tác giả.

  • By publication date: Tìm sách trong danh mục theo ngày xuất bản.

  • Pay fine: Thanh toán tiền phạt nếu sách được trả quá hạn mượn.

Relationships

Phần này mô tả các mối quan hệ giữa actors và use cases của chúng.

Generalization

Chúng ta có thể tìm kiếm sách theo tiêu đề, tên chủ đề, tên tác giả, hoặc ngày xuất bản. "Search catalog" là một use case chung, và người dùng có thể thực hiện tìm kiếm dựa trên nhiều phương thức khác nhau như. Điều này cho thấy use case “Search catalog” có mối quan hệ generalization với các use cases “By subject name,” “By book title,” “By author name,” và “By publication date”.

Associations

Bảng dưới đây cho thấy mối quan hệ associations giữa actors và use cases của chúng.

Librarian Member System
Add book Search catalog Overdue notification
Remove book Cancel membership Reservation available notification
Edit book Register/Update account Reservation canceled notification
Register new account Login/Logout
Cancel membership Checkout book
Register/Update account Remove reservation
Login/Logout Renew book
Issue book Reserve book
Remove reservation View account
Renew book Return book
Reserve book
View account

Include

  • Để thêm một cuốn sách mới, chúng ta cần thêm các bản sao của nó (các mục sách), vì vậy use case "Add Book" có mối quan hệ include với use case "Add book item".
  • Để chỉnh sửa một cuốn sách, chúng ta cần chỉnh sửa các bản sao của nó, do đó use case "Edit Book" có mối quan hệ include với use case "Edit book item".
  • Xóa một cuốn sách khỏi thư viện, chúng ta cần xóa các bản sao của nó, vì vậy use case "Remove Book" có mối quan hệ include với use case "Remove book item".
  • Bất kỳ khi nào một mục sách được thêm, chỉnh sửa, hoặc xóa, danh mục sách cần được cập nhật. Vì vậy" Update catalog" có mối quan hệ include với các use case "Add book item", "Edit book item", và "Remove book item".
  • Để cấp phát một cuốn sách, chúng ta cần hoàn tất quy trình mượn sách, vì vậy use case "Issue book" có mối quan hệ include với use case "Checkout book".
  • Mỗi khi chúng ta hoàn tất quy trình mượn sách, yêu cầu đặt giữ sách sẽ bị xóa vì sách đã được cấp phát. Do đó, use case "Checkout book" có mối quan hệ include với use case "Remove reservation".
  • Khi một thành viên mới được đăng ký, thẻ thư viện sẽ được cấp. Vì vậy, use case "Register new member" có mối quan hệ include với use case "Issue library card".

Extend

  • Mỗi khi một thành viên trả sách, thủ thư sẽ kiểm tra xem việc trả sách có muộn hay không và yêu cầu thành viên thanh toán tiền phạt nếu có, vì vậy use case "Return book" có mối quan hệ extend với use case "Pay fine" .

Use case diagram của Hệ thống Quản lý Thư viện

Class Diagram cho Hệ thống Quản lý Thư viện

Dưới đây, chúng ta sẽ xây dựng class diagram cho hệ thống của chúng ta dựa trên các requirements đã thu thập trước đó. Trong class diagram, chúng ta sẽ thiết kế/tạo các classes, abstract classes và interfaces cho hệ thống, sau đó xác định các mối quan hệ giữa các classes theo tất cả các requirements của hệ thống quản lý thư viện.

Components của một Hệ thống Quản lý Thư viện

Trong phần này, chúng ta sẽ define các classes cho hệ thống quản lý thư viện (LMS). Vì chúng ta đang theo phương pháp bottom-up design, nên trước tiên chúng ta sẽ tạo các classes của các components nhỏ. Sau đó, chúng ta sẽ tích hợp các components đó và tạo class diagram cho toàn bộ hệ thống quản lý thư viện.

Book và book item

Class Book đại diện cho bản chất khái niệm của một cuốn sách. Lớp này lưu trữ các thông tin chung về cuốn sách, dùng để đại diện cho sách một cách tổng quát mà không liên quan đến các bản sao cụ thể.

Class BookItemđại diện cho một mục sách vật lý hoặc kỹ thuật số cụ thể của một cuốn sách trong bộ sưu tập của thư viện. Class này giúp quản lý và theo dõi tình trạng của các bản sao cụ thể trong hệ thống thư viện.

Rack

Class Rack (Kệ sách) được sử dụng để xác định vị trí vật lý của bất kỳ mục sách nào trong thư viện. Mỗi rack có một số rack cụ thể được gán cho nó và một định danh vị trí để biểu thị vị trí chính xác của bản sao sách trong thư viện. giúp quản lý và theo dõi vị trí của các mục sách trong thư viện, đảm bảo rằng mỗi mục sách có thể được tìm thấy dễ dàng.

Person và author

Class Person lưu trữ thông tin cá nhân (tên, email, số điện thoại) và bao gồm một đối tượng Address để chỉ chi tiết vị trí của cá nhân đó.

Class Author chứa dữ liệu cụ thể cho một tác giả (tên, mô tả) và được sử dụng trong class Book để đại diện cho thông tin về tác giả.

User, librarian, và library member

Trong Hệ thống Quản lý Thư viện (LMS), class User là một class trừu tượng (abstract class) dành cho người dùng hệ thống, với hai loại người dùng cụ thể: Thủ thư và Thành viên thư viện.

Class Librarian, kế thừa từ class User, quản lý việc thêm sách và quyền truy cập của thành viên.

Class Member, cũng là một class con (child class) của User, theo dõi số lượng sách đã mượn và hỗ trợ các hoạt động đặt giữ, trả sách và gia hạn sách.

Cấu trúc phân cấp của các classes này được minh họa trong một class diagram, cho thấy mối quan hệ giữa các class User, Librarian, và Member.

Library card

Để quản lý thông tin thẻ thư viện của từng người dùng, chúng ta có một class LibraryCard. Mỗi thẻ thư viện có một số nhận dạng, ngày phát hành, và thông tin về việc thẻ đó có đang hoạt động hay không. Biểu diễn class của class LibraryCard như sau:

Book reservation

Đặt giữ sách là một trong những yêu cầu quan trọng nhất của hệ thống quản lý thư viện. Để thực hiện chức năng này, chúng ta có một class tên là BookReservation. Class này chịu trách nhiệm quản lý trạng thái đặt giữ của các mục sách.

Book lending

Tương tự như đặt giữ sách, việc cho mượn sách cũng là một phần của hệ thống, vì class BookLending quản lý quy trình mượn các mục sách. Thông tin như ngày mượn sách, ngày đến hạn, ngày trả sách, v.v., được xử lý trong class này.

Notification

Notification là một class trừu tượng. Nếu sách không được trả đúng hạn, thì class Notification chịu trách nhiệm thông báo cho các thành viên thư viện bằng cách gửi một thông báo. Mỗi thông báo có một ID, ngày tạo, và nội dung. Thông báo có thể là thông báo qua bưu điện hoặc thông báo qua email.

Class PostalNotification yêu cầu địa chỉ của thành viên thư viện để gửi thông báo, trong khi EmailNotification cần địa chỉ email của thành viên thư viện để gửi thông báo.

Sơ đồ mối quan hệ của các class này được hiển thị dưới đây:

Search và catalog

Tìm kiếm là một trong những chức năng quan trọng nhất của hệ thống. Search là interface cho phép người dùng tìm kiếm bất kỳ cuốn sách nào và trả về danh sách các sách dựa trên các phương pháp tìm kiếm sau:

  • Tìm kiếm sách theo tiêu đề.
  • Tìm kiếm sách theo tên tác giả.
  • Tìm kiếm sách theo chủ đề.
  • Tìm kiếm sách theo ngày xuất bản.

Catalog là một class nơi chức năng tìm kiếm được triển khai. Trong catalog, các sách được sắp xếp theo một trong những kỹ thuật tìm kiếm được cung cấp, tức là dựa trên tiêu đề sách, tác giả, chủ đề, hoặc ngày xuất bản.

Sơ đồ UML sau đây cho thấy mối quan hệ này:

Library

Class Library là class cơ sở (base class) của hệ thống, được sử dụng để đại diện cho thư viện.

Enumerations

Enumeration thường là một kiểu dữ liệu trong đó chỉ có thể lưu trữ một tập hợp các hằng số (constants) cụ thể. Dưới đây là danh sách các enumerations cần thiết trong hệ thống quản lý thư viện (LMS):

  • BookFormat: Mô tả rằng một cuốn sách chỉ có thể thuộc một trong các định dạng được chỉ định. Nó có thể là sách bìa cứng, sách bìa mềm, sách nói, sách điện tử, báo, tạp chí, nhật ký.

  • BookStatus: Mô tả trạng thái của một mục sách cụ thể đối với người dùng, chẳng hạn như có sẵn, đã đặt giữ, đang cho mượn, hoặc bị mất.

  • ReservationStatus: Cho biết trạng thái đặt giữ của bất kỳ mục sách nào, chẳng hạn như đang chờ, đang xử lý, đã hủy, hoặc không thuộc bất kỳ trạng thái nào trong số đó.

  • AccountStatus: Cho biết trạng thái tài khoản người dùng, chẳng hạn như đang hoạt động, đã đóng, đã hủy, bị đưa vào danh sách đen, hoặc không thuộc trạng thái nào trong số đó.

Custom data type

Address là một kiểu dữ liệu tùy chỉnh (custom data type), được sử dụng để lưu trữ địa chỉ của thư viện và người dùng thư viện.

Relationship giữa các classe

Bây giờ, chúng ta sẽ thảo luận về mối quan hệ giữa các class mà chúng ta đã định nghĩa ở trên trong hệ thống quản lý thư viện của mình.

Association

Dành cho ai bối rối thì Association là sự liên kết giữa 2 classes khi mà không ai sở hữu ai. Vòng đời các thể hiện của các classes thì độc lập nhau và không có mối quan hệ sở hữu nào ở đây cả.

Class diagram có các mối quan hệ association sau đây:

Liên kết một chiều (One-way association)

  • Class User có mối liên kết một chiều với BookItemBookReservation.
  • Cả BookReservationBookLending đều có liên kết một chiều với BookItem.

Hình ảnh dưới đây minh họa mối quan hệ liên kết một chiều giữa các class:

Liên kết hai chiều (Two-way association)

  • Class Author có mối liên kết hai chiều với Book.
  • Cả RackLibrarian đều có mối liên kết hai chiều với BookItem.
  • Class Notification có mối liên kết hai chiều với BookLendingBookReservation.
  • Class BookLending có mối liên kết hai chiều với BookReservationUser.

Composition

  • LibraryCard không thể tồn tại mà thiếu User.
  • BookItem không thể tồn tại mà thiếu Library.

Dành cho ai bối rối thì Composition tương tự như Aggregation nhưng khác là vòng đời của thằng part sẽ bị thụ thuộc vào thằng whole. Có nghĩa là các BookItem không thể tồn tại độc lập nếu Library bị xóa. Tương tự LibraryCard sẽ bị hủy nếu User bị hủy.

Aggregation

Dành cho ai bối rối thì Aggregation cũng giống như Association, nhưng khác là Aggregation có mối quan hệ sở hữu (ownership) giữa các instance. Vòng đời của part không phụ thuộc vào whole. Có nghĩa là các Book vẫn có thể tồn tại ngay cả khi Catalog bị xóa.

Inheritance

  • Class LibrarianMember đều extends từ class User.
  • Class EmailNotificationPostalNotification đều extends từ class Notification.
  • Class BookItem extends từ class Book.
  • Class Catalog implements interface Search.

Class diagram của Hệ Thống Quản Lý Thư Viện

Sequence Diagram cho Hệ Thống Quản Lý Thư Viện

Sơ đồ tuần tự (Sequence diagrams) là một cách tuyệt vời để hiểu các tương tác giữa các thực thể (entities) và đối tượng (objects) khác nhau trong hệ thống. Chúng ta có thể tạo ra các sơ đồ tuần tự khác nhau cho hệ thống quản lý thư viện của mình. Vì bài viết khá dài nên mình chỉ làm một sequence diagram: Thành viên yêu cầu thủ thư cho mượn sách.

Mượn sách

Các Actor và Object

Sơ đồ tuần tự để cấp phát sách sẽ bao gồm các actor và object sau đây tương tác với nhau:

  • Actors: MemberLibrarian
  • Object: Book

Các bước trong quy trình:

Dưới đây là các bước trong tuần tự để cấp phát sách:

  1. Yêu cầu mượn sách:
  • Thành viên gửi yêu cầu mượn một cuốn sách tới thủ thư.
  1. Xác minh hạn mức mượn sách:
  • Thủ thư nhận yêu cầu và tiến hành kiểm tra hạn mức mượn sách của thành viên .
  • Sau khi kiểm tra, có hai trường hợp xảy ra:
    • Nếu hạn mức mượn sách đã đạt mức tối đa:
      • Thủ thư trả về thông báo rằng thành viên đã đạt đến hạn mức tối đa và không thể mượn thêm sách.
    • Nếu hạn mức mượn sách nhỏ hơn mức tối đa:
      • Thủ thư tiếp tục quy trình bằng cách kiểm tra trạng thái của cuốn sách.
  1. Kiểm tra trạng thái sách:
  • Thủ thư yêu cầu thông tin về trạng thái của cuốn sách.
  • Cuốn sách trả về trạng thái hiện tại, có thể là có sẵn (available) hoặc đã được đặt giữ (reserved).
  1. Quyết định cấp phát sách:
  • Nếu sách có sẵn):
    • Thủ thư tiến hành cấp phát sách cho thành viên.
  • Nếu sách đã được đặt giữ:
    • Yêu cầu cấp phát sách của thành viên sẽ bị hủy bỏ.

Sơ đồ tuần tự này mô tả một quy trình cấp phát sách từ khi thành viên gửi yêu cầu đến khi quyết định cấp phát hoặc hủy bỏ yêu cầu. Quy trình bao gồm các bước kiểm tra hạn mức mượn sách của thành viên và trạng thái hiện tại của cuốn sách.

Activity Diagram cho Hệ Thống Quản Lý Thư Viện

Sơ đồ hoạt động (Activity diagrams) là một cách tuyệt vời để trực quan hóa flow của các messages từ một hoạt động đến hoạt động khác trong hệ thống. Chúng ta có thể tạo ra các sơ đồ hoạt động khác nhau cho hệ thống quản lý thư viện (LMS).

Trong bài viết này, chúng ta sẽ tạo sơ đồ hoạt động cho hoạt động mượn sách từ thư viện.

Mượn sách từ thư viện

Trạng thái

Initial state: Thành viên chọn sách và bắt đầu quá trình mượn sách.

Final state: Có hai final states trong sơ đồ hoạt động này, được mô tả như sau:

  • Thành viên hoàn tất quá trình mượn sách thành công, và sách sẽ được cấp phát cho thành viên.
  • Có lỗi xảy ra trong quá trình mượn sách do sách không có sẵn hoặc vượt quá giới hạn mượn sách.

Hành động

Thành viên chọn một cuốn sách và nhập ID. Hệ thống sẽ thực hiện một số kiểm tra như tình trạng sẵn có của sách, giới hạn mượn tối đa của thành viên, và các yêu cầu đặt giữ sách. Nếu tất cả các kiểm tra đều thông qua, cuốn sách sẽ được cấp phát. Ngược lại, hệ thống sẽ hiển thị thông báo lỗi.

Activity diagram Mượn sách từ thư viện:

Vậy là bài viết về thiết kế hướng đối tượng hệ thống quản lý thư viện đã kết thúc. Đây là lần đầu tiên em/mình viết về chủ đề này, mong mọi người góp ý và cùng chỉnh sửa để chúng ta có thể hoàn thiện hơn và đóng góp nhiều hơn cho cộng đồng. Cảm ơn mọi người đã dành thời gian đọc bài viết!

Bình luận

Bài viết tương tự

- vừa được xem lúc

4 đặc tính của lập trình hướng đối tượng (Object oriented program)

Lập trình hướng đối tượng quá quen thuộc rồi bạn nào học lập trình đều phải học, đi phỏng vấn cũng vậy hỏi suốt(chắc cái này tùy vào vị trí tuyển dụng chủ yếu junior chắc chắn sẽ hỏi).nó là nền tảng cho hầu hết các design pattern hiện nay.

0 0 46

- vừa được xem lúc

Khác nhau giữa abstract class và interface khi nào dùng chúng

Nhắc đến Interface và abstract class hãy nhớ 2 từ này khá clear rồi, Khi sử dụng Interface là bạn Implement còn sử dụng abstract class là bạn extend. . Interface:. .

0 0 41

- vừa được xem lúc

So sánh Interface và Abstract trong lập trình hướng đối tượng.

Tổng quan. Interface và Abstract class là 2 khái niệm cơ bản trong lập trình OOP.

0 0 63

- vừa được xem lúc

Áp Dụng Nguyên Tắc SOLID Trong Lập Trình

Giới Thiệu. 1. SOLID là gì. SOLID là viết tắt của 5 chữ cái đầu trong 5 nguyên tắc:.

0 0 36

- vừa được xem lúc

Kỹ thuật giải quyết bài toàn về policy và công thức tính toán động cho sản phẩm phần mềm

Dạo này tôi có một mối duyên rất tình cờ với việc làm các phần mềm thuộc lĩnh vực tài chính và ngân hàng. Một số bài toán trong lĩnh vực này làm tôi nhớ đến những ngày đầu làm việc với phần mềm Trinet

0 0 34

- vừa được xem lúc

Object Relational Mapping

Trong cách phát triển ứng dụng web hiện nay chắc hẳn các bạn đã quen với với từ khóa ORM(Object Relational Mapping). Khi mà thời đại của các framework ứng với các ngôn ngữ đang lên ngôi một cách mạnh

0 0 39