Buổi 1: Phần mềm là gì ?

Thời kỳ đầu: Giai đoạn khủng hoảng phần mềm → Chất lượng phần mềm kém, không tương xứng với chi phí thực hiện như chưa rất nhiều lỗi và không đúng yêu cầu

Suy ra: Cần có những phương pháp nghiên cứu chuyên sâu về phát triển phần mềm → ra đời thuật ngữ công nghệ phần mềm

Định nghĩa: Công nghệ phần mềm là một lĩnh vực khoa học về phương pháp luận, kỹ thuật và công cụ tích hợp trong phát triển và vận hành phần mềm. Nhằm tạo ra PM với chất lượng mong muốn

Software​

is a collection of instructions, data, or computer programs that are used to run machines and carry out particular activities. It is the antithesis of hardware, which refers to a computer’s external components. A device’s running programs, scripts, and applications are collectively referred to as “software” in this context.

System Software	Application Software
It is designed to manage the resources of the computer system, like memory and process management, etc.	It is designed to fulfill the requirements of the user for performing specific tasks.
Written in a low-level language.	Written in a high-level language.
Less interactive for the users.	More interactive for the users.
System software plays vital role for the effective functioning of a system.	Application software is not so important for the functioning of the system, as it is task specific.
It is independent of the application software to run.	It needs system software to run.

Ví dụ về Use case​

Use Case Name: Custom Drone Order

Use Case Description: This use case describes the process of a customer ordering a custom-built drone based on their specific requirements.

Actors:

• Customer
• Drone Builder

Pre-conditions:

• The customer has identified the need for a custom drone.
• The drone builder has the necessary expertise and resources to build custom drones.

Post-conditions:

• The customer has placed an order for a custom drone.
• The drone builder has received the customer's order and is ready to start the build process.

Normal Flow:

1. The customer contacts the drone builder to express interest in a custom drone.
2. The drone builder discusses the customer's needs and requirements, gathering information about the desired features, specifications, and budget.
3. The drone builder provides a quote based on the customer's requirements.
4. The customer reviews the quote and decides whether to proceed with the order.
5. If the customer agrees to proceed, they provide the necessary payment information.
6. The drone builder confirms the order and begins the build process.

Alternative Flows:

• Customer requests modifications: If the customer requests changes to the original order, the drone builder assesses the feasibility and provides an updated quote.
• Build delays: If there are unexpected delays in the build process, the drone builder communicates with the customer and provides updates on the estimated completion time.
• Order cancellation: If the customer decides to cancel the order, the drone builder refunds any payments made and provides a reason for the cancellation.

Buổi 4: Tạo lược đồ Use - Case

Một công cụ phổ biến để biểu diễn yêu cầu của hệ thống và hiểu rõ các tác nhân, chức năng và tương tác của hệ thống là sơ đồ Use Case (Use Case Diagram). Sơ đồ Use Case cung cấp một cái nhìn tổng quan về các chức năng của hệ thống và cách các tác nhân (người dùng, hệ thống khác, v.v.) tương tác với hệ thống.

Sơ đồ Use Case bao gồm các phần tử chính như các Use Case (chức năng), các tác nhân (người dùng, hệ thống khác), và các quan hệ và tương tác giữa chúng. Use Case mô tả các hành vi của hệ thống từ góc nhìn người dùng hoặc tác nhân và giúp xác định các chức năng chính cần phát triển.

Trong quá trình phân tích thiết kế hệ thống, sơ đồ Use Case thường được kết hợp với các tài liệu khác như biểu đồ tuần tự (sequence diagram), biểu đồ lớp (class diagram) và biểu đồ hoạt động (activity diagram) để mô tả và phân tích chi tiết hơn về các tương tác và cấu trúc của hệ thống.

Nội dung bài học

1. Khái niệm về Actor và Use - Case
2. Các quan hệ trong lược đồ Use – Case: Quan hệ thổng quát hóa giữa Actor, quan hệ "<<include>>" và "<<extend>>".
3. Sơ đồ Use – Case hoàn chỉnh.
4. Đặc tả Use – Case.

Use-case diagram

Chỉ mô tả chủ yếu các thông tin liên quan đến việc thực hiện các nghiệp vụ trong thế giới thực, chưa thể hiện rõ nét việc thực hiện các nghiệp vụ trên máy tính.

Mô tả thông quá các văn bản dễ gây ra nhầm lẫn và không trực quan.

Actor

Usecase

Relationship

Quan hệ bao gồm (<<include>>)

Quan hệ mở rộng (<<extend>>)

Sơ đồ use-case đầy đủ

Đặc tả use-case

Đặc tả Use Case là một tài liệu mô tả chi tiết hành vi của hệ thống từ góc nhìn của người dùng. Nó bao gồm các trường hợp sử dụng (Use Case) chính của hệ thống, các bước thực hiện, các ràng buộc và điều kiện tiên quyết cho mỗi trường hợp sử dụng.

Cấu trúc của một đặc tả Use Case:

• Tên Use Case: Mô tả ngắn gọn chức năng của Use Case.
• Mô tả: Mô tả chi tiết hành vi của Use Case.
• Diễn viên (Actor): Mô tả các đối tượng sử dụng Use Case.
• Bước thực hiện: Mô tả các bước thực hiện Use Case.
• Ràng buộc: Mô tả các ràng buộc đối với Use Case.
• Điều kiện tiên quyết: Mô tả các điều kiện cần phải được đáp ứng trước khi thực hiện Use Case.
• Luồng nghiệp vụ (Workflow): Mô tả trình tự các bước thực hiện Use Case.

Buổi 5: Tạo lược đồ Activity (Activities diagram)

Activity Diagram là một mô hình logic dùng để mô hình hoá các hoạt động trong một quy trình nghiệp vụ. Hay có thể hiểu. Activity Diagram là sơ đồ luồng xử lý của hệ thống. Bao gồm luồng đi của dòng dữ liệu, dòng sự kiện.

Activity Diagram dùng để mô tả các hoạt động trong một chức năng của hệ thống (mô tả luồng xử lý của một Use – Case)

Các thành phần của Activity - Diagram​

Start

Activity

Nên đặt tên là động từ. Và mô tả đủ ý nghĩa tổng thể của hoạt động nhất có thể.

Transition

Từ hoạt động này tới hoạt động khác cần có Transition biểu thị đường đi. Lưu ý Transition có mũi tên biểu thị chiều của luồng xử lý.

Condition

Có thể hiểu đây là ký hiệu biểu thị nút điều kiện chuyển hướng. Tùy theo trường hợp đúng hay sai của kết quả biểu thức logic bên trong ký hiệu mà có hướng di chuyển tiếp theo tương ứng.

Synchronization bar

Có thể hiểu đơn giản. Có các trường hợp cần hội tụ đủ nhiều luông điều khiển một lúc để gộp thành một luồng xử lý thì cần dùng Join.

Và đôi khi cần phải tách một luồng điều khiển ra hai hoặc nhiều luồng khác biệt nhau thì cần Fork. Và mỗi luồng của Fork hoàn toàn không lệ thuộc nhau

End

Ánh xạ từ sơ đồ Use-case qua Activities diagrams

Bài tập buổi 5:

1. Vẽ sơ đồ activities diagram cho use-case đăng ký / đăng nhập
2. Vẽ sơ đồ activities diagram cho use-case mua hàng / thanh toán cho hệ thống thương mại điện tử
3. Vẽ sơ đồ activities diagram cho use-case tìm kiếm và lọc chuyến đi cho hệ thống đặt vé xe khách

Buổi 6: Giới thiệu về ER Diagram

ER-Diagram (Entity-Relationship Diagram) là một công cụ được sử dụng trong thiết kế cơ sở dữ liệu để biểu diễn các mối quan hệ giữa các thực thể (entities). Nó được giới thiệu bởi Peter Chen vào năm 1976 và trở thành một phương pháp phổ biến để mô hình hóa dữ liệu.

ER-Diagram sử dụng các khái niệm cơ bản như thực thể (entity), mối quan hệ (relationship) và thuộc tính (attribute) để biểu diễn cấu trúc dữ liệu. Thực thể là các đối tượng trong thế giới thực, chẳng hạn như người, đồ vật hoặc sự kiện. Mối quan hệ biểu thị các mối liên kết giữa các thực thể, trong đó có thể có mối quan hệ một một (one-to-one), một nhiều (one-to-many) hoặc nhiều nhiều (many-to-many). Thuộc tính là các đặc điểm của thực thể, ví dụ như tên, tuổi, địa chỉ.

Năm 1988, ANSI (American National Standards Institute) công nhận ER-Diagram là mô hình chuẩn trong thiết kế cơ sở dữ liệu. Việc công nhận này đã tạo ra một sự nhất quán trong việc sử dụng ER-Diagram và giúp nó trở thành một công cụ phổ biến trong lĩnh vực này.

Các thành phần của ER - Diagram​

1. Thực thể (Entity): Thực thể là một đối tượng hoặc một tập hợp các đối tượng trong thế giới thực có ý nghĩa độc lập và được lưu trữ trong cơ sở dữ liệu. Ví dụ, trong một hệ thống quản lý sinh viên, "Sinh viên" có thể là một thực thể.
2. Mối quan hệ (Relationship): Mối quan hệ biểu thị sự kết nối hoặc liên kết giữa các thực thể. Nó biểu thị cách mà các thực thể liên quan đến nhau trong cơ sở dữ liệu. Ví dụ, trong hệ thống quản lý sinh viên, một mối quan hệ có thể là "Sinh viên học trong Lớp học".

1. Thuộc tính (Attribute): Thuộc tính là các đặc điểm hoặc thông tin liên quan đến mỗi thực thể. Nó mô tả các thuộc tính của thực thể và giúp xác định các đặc điểm riêng của mỗi thực thể. Ví dụ, trong thực thể "Sinh viên", các thuộc tính có thể là "Họ và tên", "Ngày sinh", "Địa chỉ" và "Email".
2. Bảng số: Ràng buộc là các quy tắc hoặc điều kiện áp dụng cho mô hình ERD. Nó xác định các quy định về tính chất, quan hệ, và giới hạn của dữ liệu trong cơ sở dữ liệu. Ví dụ, một ràng buộc có thể là "Một sinh viên chỉ có thể tham gia một lớp học vào cùng một thời điểm".

Thực thể (Entity)​

Mối liên kết (Relationship)​

Bảng số​

Thuộc tính

Bài tập buổi 6: Xây dựng sơ đồ ERD cho hệ thống sau gồm nhân viên, phòng ban và đề án​

Yêu cầu: hoàn thành bảng bên dưới bằng cách bổ sung mối quan hệ, thuộc tính và bảng số

1. Mỗi phòng ban phụ trách không hoặc nhiều đề án - Mỗi đề án được phụ trách bởi duy nhất 1 phòng ban
2. Mỗi nhân viên được thực hiện không hoặc nhiều đề án - mỗi đề án được phân công cho 1 hoặc nhiều nhân viên

Bài tập số 1:

So sánh các mô hình phát triển phần mềm​

Mô hình	Đặc điểm	Ưu điểm	Nhược điểm	Trường hợp áp dụng
Thác nước
Chế thử
Gia tăng
Xoắn ốc
RAD

Bài 7: Data flow diagram

The Food Ordering System Example​

Context DFD​

A context diagram is a data flow diagram chỉ hiển thị cấp độ cao nhất, còn được gọi là Cấp độ 0. Ở cấp độ này, chỉ có một nút xử lý hiển thị đại diện cho các chức năng của một hệ thống hoàn chỉnh liên quan đến cách nó tương tác với các thực thể bên ngoài. Một số lợi ích của Biểu đồ Ngữ cảnh bao gồm:

1. Hiển thị tổng quan về ranh giới của một hệ thống
2. Không cần kiến thức kỹ thuật để hiểu với ký hiệu đơn giản
3. Dễ vẽ, sửa đổi và mở rộng vì các ký hiệu hạn chế của nó

A context Data Flow Diagram được vẽ cho một "Hệ thống đặt đồ ăn online". Thể hiện bên tham gia sẽ tương tác với hệ thống, được gọi là các thực thể bên ngoài. Trong ví dụ này, Nhà cung cấp, Nhà bếp, Quản lý và Khách hàng là các thực thể sẽ tương tác với hệ thống. Giữa quy trình và các thực thể bên ngoài, có luồng dữ liệu (các kết nối) chỉ ra sự tồn tại của việc trao đổi thông tin giữa các thực thể và hệ thống.

Context DFD là đầu vào của mô hình dữ liệu, nó chỉ thể hiện quy trình, không chưa bất kỳ dữ liệu nào

Level 1 DFD​

Data flow diagram Cấp độ 1, đó là sự phân rã (tức là phân chia) của quy trình "Hệ thống đặt đồ ăn online" được hiển thị trong Context diagram.

Lấy ví dụ "Hệ thống đặt đồ ăn online" chứa ba quy trình, bốn thực thể bên ngoài và hai kho dữ liệu.

Các quy trình

Khách hàng có thể đặt một Đơn hàng. Quy trình Đặt món nhận Đơn hàng, chuyển tiếp nó đến Nhà bếp, lưu trữ nó trong kho dữ liệu Đơn hàng, và lưu trữ thông tin cập nhật về Chi tiết hàng tồn trong kho dữ liệu Hàng tồn. Quy trình cũng gửi một Hóa đơn đến Khách hàng.

Quản lý có thể nhận Báo cáo thông qua quy trình Tạo báo cáo, quy trình này nhận Chi tiết hàng tồn và Đơn hàng như đầu vào từ kho dữ liệu Hàng tồn và Đơn hàng tương ứng.

Quản lý cũng có thể khởi tạo quy trình Đặt hàng hàng tồn bằng cách cung cấp Đơn hàng hàng tồn. Quy trình chuyển tiếp Đơn hàng hàng tồn đến Nhà cung cấp và lưu trữ thông tin cập nhật về Chi tiết hàng tồn trong kho dữ liệu Hàng tồn.

Data Flow Diagram Tips and Cautions​

1. Nhãn các quy trình (Process) nên là cụm từ động từ; các kho dữ liệu được đại diện bằng danh từ
2. Một kho dữ liệu phải được liên kết ít nhất với một quy trình
3. Một thực thể bên ngoài phải được liên kết ít nhất với một quy trình
4. Các số không nhất thiết chỉ ra trình tự, nó hữu ích trong việc xác định các quy trình khi thảo luận với người dùng
5. Kho dữ liệu (Data store) không nên được kết nối với một thực thể bên ngoài, nếu không, điều đó có nghĩa là bạn đang cho một thực thể bên ngoài truy cập trực tiếp vào các tệp dữ liệu của bạn
6. Luồng dữ liệu không nên tồn tại giữa 2 thực thể bên ngoài mà không thông qua một quy trình
7. Một quy trình có đầu vào nhưng không có đầu ra được coi là một quy trình hố đen

BÀI TẬP LỚN

Tuần 1: Phân tích yêu cầu và thiết kế hệ thống​

Phân tích chi tiết các yêu cầu chức năng và phi chức năng - dựa vào yêu cầu bài toán:

• Xác định rõ các tính năng cốt lõi và tính năng nâng cao.
• Đánh giá mức độ ưu tiên của từng tính năng.
• Xác định các ràng buộc về hiệu năng, bảo mật và khả năng mở rộng.

Lập mô hình Use Case:

• Mô tả các hành vi của người dùng khi tương tác với hệ thống.
• Xác định các actor và các use case chính.

Lập sơ đồ activities diagram

• Trình bày lược đồ hoạt động của tất cả các usecase

Thiết kế giao diện người dùng (UI):

• Tạo wireframe cho các màn hình chính của ứng dụng.
• Xác định các thành phần giao diện và bố cục.
• Chọn màu sắc, font chữ phù hợp với giao diện hiện đại và tươi sáng.

Lựa chọn công nghệ:

• Nghiên cứu và lựa chọn các công cụ, framework phù hợp để phát triển ứng dụng (ví dụ: React Native, Flutter, ...).
• Xác định cơ sở dữ liệu để lưu trữ dữ liệu người dùng (ví dụ: SQLite, Firebase).
• Nêu lí do tại sao lại sử dụng những công nghệ này ?