Top 11 # Xem Nhiều Nhất Cách Vẽ Component Diagram Mới Nhất 2/2023 # Top Like | Techcombanktower.com

Thực Hành Xây Dựng Bản Vẽ Sequence Diagram

Trong bài trước chúng ta đã tìm hiểu về Sequence Diagram, các thành phần, cách xây dựng và ứng dụng của nó. Trong bài này, chúng ta sẽ bàn về cách ứng dụng sequence diagram để thiết kế cho hệ thống eCommerce mà chúng ta đã bàn ở bài 3 của chuyên mục này.

1. Xây dựng Sequence Diagram

Bước 1: Xác định các Use Case cần thiết kế

Tương tự như Activity Diagram, chúng ta cũng cần xác định các Use Case mà chúng ta cần sử dụng sequence Diagram để thiết kế chi tiết.

Xem xét bản vẽ Use Case Diagram chúng ta đã vẽ ở bài 3, chúng ta có thể thấy các Use Case sau cần thiết kế:

– Xem sản phẩm theo chủng loại

– Thêm sản phẩm theo nhà cung cấp

– Thêm giỏ hàng

– Chat

– Quản lý đơn hàng

– Thanh toán

– Theo dõi chuyển hàng

– Đăng nhập

Tiếp theo, chúng ta sẽ thiết kế cho chức năng ” Xem sản phẩm theo chủng loại “.

Bước 2: Xem Activity Diagram cho Use Case này chúng ta xác định các bước sau:

– Người dùng chọn loại sản phẩm

– Hệ thống sẽ lọc lấy loại sản phẩm tương ứng, sau đó lấy giá, lấy khuyến mãi và hiển thị lên màn hình.

– Người dùng xem sản phẩm

Bước 3: Đối chiếu với Class Diagram chúng ta xác định các đối tượng thực hiện như sau:

– Người dùng: chọn loại sản phẩm qua giao diện

– Giao diện: sẽ lấy danh sách sản phẩm tương ứng từ Products

– Giao diện: lấy giá của từng sản phẩm từ Class Prices và Promotion Amount từ lớp Promotions

– Giao diện: tổng hợp danh sách và hiển thị

– Người dùng: Xem sản phẩm

Bước 4: Vẽ sequence Diagram

– Xác định các lớp tham gia vào hệ thống gồm: người dùng (Guest), Giao diện (GUI System), Sản phẩm (Products), Giá (Prices), Khuyến mãi (Promotions). Trong đó GUI System để sử dụng chung cho giao diện, bạn có thể sử dụng cụ thể trang Web nào nếu bạn đã có Mockup (thiết kế chi tiết của giao diện).

– Guest gửi yêu cầu xem sản phẩm lên giao diện kèm theo chủng loại

– GUI system: gửi yêu cầu lấy danh sách các sản phẩm tương ứng với chủng loại cho lớp sản phẩm và nhận lại danh sách.

– GUI system: gửi yêu cầu lấy Giá cho từng sản phẩm từ Prices

– GUI system: gửi yêu cầu lấy khuyến mãi cho từng sản phẩm từ Promotions và nhận lại kết quả

– GUI system: ghép lại danh sách và hiển thị lên browser và trả về cho Guest

Thể hiện lên bản vẽ như sau:

Chúng ta nhận thấy để thực hiện được bản vẽ trên chúng ta cần bổ sung các phương thức cho các lớp như sau:

– Products class: bổ sung phương thức GetProductInfo(Product Type): trả về thông tin sản phẩm có loại được truyền vào. Việc này các đối tượng của lớp Products hoàn toàn làm được vì họ đã có thuộc tính ProductType nên họ có thể trả về được thông tin này.

– Prices: bổ sung phương thức GetPrice(ProductID): UnitPrice. Sau khi lấy được ProductID từ Products, GUI gọi phương thức này để lấy giá của sản phẩm từ lớp giá. Các đối tượng từ lớp Prices hoàn toàn đáp ứng điều này.

– Promotions: tương tự bổ sung phương thức GetPromotion(ProductID).

– GUI System(View Product Page): bổ sung phương thức DisplayProductList(List of product) để hiển thị danh sách lên sản phẩm. Ngoài ra, bạn cần có thêm một phương thức ViewProductbyType(ProductType) để mô tả chính hoạt động này khi người dùng kích chọn.

Như vậy, chúng ta thấy các phương thức trên đều thực hiện được trên các đối tượng của các lớp nên thiết kế của trên là khả thi. Bổ sung các phương thức trên vào các Class tương ứng chúng ta có bản vẽ Class Diagram như sau:

Hoàn tất sequence diagram cho tất cả các Use Case chúng ta sẽ hoàn thành việc thiết kế, đồng thời cũng hoàn tất bản vẽ Class Diagram.

2. Kết luận

Bản vẽ Squence Diagram có vai trò quan trọng trong việc thiết kế hệ thống. Đồng thời giúp chúng ta kiểm tra lại quá trình phân tích, thiết kế trước đây cũng như hoàn thành bản vẽ Class Diagram. Việc sử dụng thành thạo bản vẽ này giúp các bạn rất nhiều trong việc phân tích và thiết kế phần mềm.

Trong bài tiếp theo chúng ta sẽ bàn về Component Diagram và Deployment Diagram, những bản vẽ cuối cùng cho việc phân tích và thiết kế hướng đối tượng sử dụng UML. Mời các bạn đọc tiếp.

Bài tiếp: Bản vẽ Component Diagram

Bài trước: Bản vẽ Sequence Diagram

Bản Vẽ Use Case (Use Case Diagram)

Trong bài trước chúng ta đã biết vai trò của bản vẽ Use Case là rất quan trọng, nó giúp chúng ta hiểu yêu cầu, kiến trúc chức năng của hệ thống và chi phối tất cả các bản vẽ còn lại. Trong bài này chúng ta sẽ tìm hiểu về các thành phần cấu tạo nên bản vẽ này, cách xây dựng và sử dụng nó.

1. Các thành phần trong bản vẽ Use Case

Đầu tiên, chúng ta xem một ví dụ về Use Case Diagarm.

Bây giờ chúng ta sẽ tìm hiểu kỹ hơn về các thành phần của bản vẽ.

1.1 Actor

Actor được dùng để chỉ người sử dụng hoặc một đối tượng nào đó bên ngoài tương tác với hệ thống chúng ta đang xem xét. Lưu ý, chúng ta hay bỏ quên đối tượng tương tác với hệ thống, ví dụ như Bank ở trên.

Actor được biểu diễn như sau:

Use Case là chức năng mà các Actor sẽ sử dụng. Nó được ký hiệu như sau:

1.3 Relationship(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ác kiểu quan hệ cơ bản sau:

– Association

– Generalization

– Include

– Extend

1.4 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.

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

Chúng ta đã nắm được các ký hiệu của bản vẽ Use Case, bây giờ là lúc chúng ta tìm cách lắp chúng lại để tạo nên bản vẽ hoàn chỉnh. Thực hiện các bước sau để xây dựng một bản vẽ Use Case:

+ 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?

Xem xét ví dụ về ATM ở trên chúng ta thấy:

Như vậy có 03 Actor: Customer, ATM Technician và Bank

+ Bước 2: Tìm các Actor

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.

Xem xét ví dụ ở trên ta thấy:

Customer sử dụng các chức năng: Check Balance, Deposit, Withdraw và Transfer

ATM technician sử dụng: Maintenance và Repair

Bank tương tác với tất cả các chức năng trên.

Tóm lại, chúng ta phải xây dựng hệ thống có các chức năng: Check Balance, Deposit, Withdraw, Transfer, Maintenance và Repair để đáp ứng được cho người sử dụng và các hệ thống tương tác.

+ 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.

Nhìn vào bản vẽ trên chúng ta nhận biết hệ thống cần những chức năng gì và ai sử dụng. Tuy nhiên, chúng ta chưa biết được chúng vận hành ra sao? Sử dụng chúng như thế nào? Để hiểu rõ hơn hệ thống chúng ta cần phải đặc tả các Use Case.

Có 2 cách để đặc tả Use Case.

Cách 1: Viết đặc tả cho các Use Case

Chúng ta có thể viết đặc tả Use Case theo mẫu sau:

Tên Use Case

Mã số Use Case

Mô tả tóm tắt// Hiển thị thông tin chi tiết của Account

Các bước thực hiện

Điều kiện thoát

Yêu cầu đặc biệt// Ghi rõ nếu có

Yêu cầu trước khi thực hiện// Phải đăng nhập

Điều kiện sau khi thực hiện

Cách 2: Sử dụng các bản vẽ để đặc tả

Chúng ta có thể dùng các bản vẽ như Activity Diagram, Sequence Diagram để đặc tả Use case. Các bản vẽ này chúng ta sẽ bàn ở những bài tiếp theo.

4. Sử dụng UseCase Diagram

– 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.

5. Kết luận

Đến đây, chúng ta đã tìm hiểu được bản vẽ đầu tiên và rất quan trọng (use case diagram), các bạn cần tiếp tục thực hành để nắm rõ hơn về bản vẽ này cũng như cách xây dựng và sử dụng chúng trong quá trình phát triển sản phẩm phần mềm.

Để giúp các bạn hiểu rõ hơn về bản vẽ Use Case trong bài tiếp theo chúng ta sẽ thực hiện qua từng bước bài thực hành xây dựng Use Case Diagram.

Bài tiếp: Thực hành xây dựng bản vẽ Use Case

Bài trước: Cơ bản về phân tích và thiết kế hướng đối tượng

Uml Deployment Diagrams Overview, Common Types Of Deployment Diagrams

Deployment diagram is a structure diagram which shows architecture of the system as deployment (distribution) of software artifacts to deployment targets.

Artifacts represent concrete elements in the physical world that are the result of a development process. Examples of artifacts are executable files, libraries, archives, database schemas, configuration files, etc.

Deployment target is usually represented by a node which is either hardware device or some software execution environment. Nodes could be connected through communication paths to create networked systems of arbitrary complexity.

Note, that components were directly deployed to nodes in UML 1.x deployment diagrams. In UML 2.x artifacts are deployed to nodes, and artifacts could manifest (implement) components. Components are deployed to nodes indirectly through artifacts.

Deployment diagrams could describe architecture at specification level (also called type level) or at instance level (similar to class diagrams and object diagrams).

Specification level deployment diagram shows some overview of deployment of artifacts to deployment targets, without referencing specific instances of artifacts or nodes.

Instance level deployment diagram shows deployment of instances of artifacts to specific instances of deployment targets. It could be used for example to show differences in deployments to development, staging or production environments with the names/ids of specific build or deployment servers or devices.

Some common types of deployment diagrams are:

Manifestation of Components by Artifacts

While component diagrams show components and relationships between components and classifiers, and deployment diagrams – deployments of artifacts to deployment targets, some missing intermediate diagram is manifestation diagram to be used to show manifestation (implementation) of components by artifacts and internal structure of artifacts.

Because manifestation diagrams are not defined by UML 2.4 specification, manifestation of components by artifacts could be shown using either component diagrams or deployment diagrams.

Manifestation of components by artifacts.

Specification Level Deployment Diagram

Specification level (also called type level) deployment diagram shows some overview of deployment of artifacts to deployment targets, without referencing specific instances of artifacts or nodes.

Specification level deployment diagram – web application deployed to Tomcat JSP server and database schemas – to database system.

Instance Level Deployment Diagram

Instance level deployment diagram shows deployment of instances of artifacts to specific instances of deployment targets. It could be used for example to show differences in deployments to development, staging or production environments with the names/ids of specific deployment servers or devices.

In the example below, web application is deployed to the application server wsrv-01 and several database schemas – to the database server dbsrv-14.

Instance level deployment diagram – web application deployed to Tomcat JSP server and database schemas – to database system.

Specification Level Network Architecture

Deployment diagrams could be used to show logical or physical network architecture of the system. Network architecture diagram could show no artifacts or deployments at all or only the major ones.

Network architecture diagrams

How To Draw Activity Diagram?

How to Draw Activity Diagram?

Activity diagram is a kind of UML diagram that shows flow of control from activity to activity. It shows concurrency, branch, control flow and object flow. Furthermore, swimlane is used for partitioning actions based on the participants involved.

Creating activity diagram

Perform the steps below to create a UML activity diagram in Visual Paradigm.

In the New Diagram window, select Activity Diagram.

Enter the diagram name and description. The Location field enables you to select a model to store the diagram.

Creating swimlane

Inserting partition to swimlane

A partition is inserted.

Creating initial node

Creating action

Move your mouse pointer over the source shape.

Press on the Resource Catalog button and drag it out.

Release the mouse button at the place where you want the action to be created.

A new action will be created and is connected to the source shape with a control flow. Enter its name and press Enter to confirm editing.

Working with scenario

A scenario is a diagram formed by the internal interaction of a sequence of action, modeled by their sub-diagrams. With scenario, you can produce a diagram which presents an overview of an execution path in activity diagram, so as to know how user and system communicate with each other in order to complete the flow.

Producing scenario from activity diagram

NOTE: A path is a continuous flow of actions in the diagram, with an initial node placed at the beginning of the actions. Multiple paths are obtained by determining the existence of decision nodes within the flow.

Name the scenario. Add description if necessary.

The actions being involved in the flow are listed in the Path table. For actions that have sub-diagram(s), pick up the sub-diagram in Diagram column or just create a new one. You may, however, leave it unspecified which cause that action to be ignored when producing scenario.

Updating scenario

Related Resources

The following resources may help you to learn more about the topic discussed in this page.