Please enable JavaScript.

Coggle requires JavaScript to display documents.

1-4 - Coggle Diagram

- - - - Saves cost and time on design!
      - Architecture style represents
      - Once overall structure determined, rest are easy
    - - Depends on how quality attributes are satisfied.
      - Each architecture style has its advantages, disadvantages, and potential risks. Choosing the right style to satisfy required functions and quality attributes is very important.
      - Quality attributes are identified in the requirement analysis process.
      - Three categories
        
        Implementation attributes
        
        Runtime attributes
        
        Business attributes
  - - - Interoperability
      - Maintainability & Extensibility
      - Testability
      - Portability
      - Scalability
      - Flexibility
    - - Availability
      - Security
      - Performance
      - Usability
    - - Time to market
      - Cost
      - Lifetime
  - - - Highlights early design decisions
      - Shows how system is structured
      - Covers functional and non-functional requirements
      - Blueprint guideline for development
    - - System static partition and decomposition
      - Establishing dynamic control between subsystems
      - Considering and evaluating all alternative architectural styles
      - Analysis of trade-off on quality attributes
  - - - It also define the styles and design patterns used to achieve requirements.
      - Also the constraints that affects the way architecture can be implemented.
      - It defines the relationship between major structural elements
    - - 1.Think of What to Do before How to Do It
      - Think about abstract design before thinking about concrete design
      - Think of non-functional requirements early in design process
      - Think of reusability and extensibility!
      - High Cohesion and Loose Coupling
      - Tolerate refinement of design
      - Avoid ambiguous design and over-detailed design
    - - Poor design
        
        May result in deficient product (does not meet system requirements)
        
        Is not adaptive to future requirement changes
        
        Not reusable
        
        Exhibits unpredictable behaviour or perform badly
      - Good design!!
        
        reduces the risks associated with software production
        
        helps development team works together in an orderly fashion
        
        makes the system traceable for implementation and testing, and leads to software products that have higher quality attributes.
- - - - Trong một chương trình, các object của class con có thể thay thế class cha mà không làm thay đổi tính đúng đắn của chương trình
    - - Thay vì dùng 1 interface lớn, ta nên tách thành nhiều interface nhỏ, với nhiều mục đích cụ thể
    - - Có thể thoải mái mở rộng 1 class, nhưng không được sửa đổi bên trong class đó => Kế thừa
        (open for extension but closed for modification).
      - Theo nguyên lý này, mỗi khi ta muốn thêm chức năng,.. cho chương trình, chúng ta nên viết class mới mở rộng class cũ ( bằng cách kế thừa hoặc sở hữu class cũ) không nên sửa đổi class cũ.
    - - Các module cấp cao không nên phụ thuộc vào các modules cấp thấp. Cả 2 nên phụ thuộc vào abstraction.
      - Interface (abstraction) không nên phụ thuộc vào chi tiết, mà ngược lại.
        ( Các class giao tiếp với nhau thông qua interface,
        không phải thông qua implementation.)
    - - Một class chỉ nên giữ 1 trách nhiệm duy nhất
        (Chỉ có thể sửa đổi class với 1 lý do duy nhất)
  - - - The existing class is known as a base class or superclass.
      - The new class is known as a derived class or subclass.
      - Inheritance is the process by which one object can acquire and the use of properties of another object.
      - The derived class shares some of the properties of the base class. Therefore a code from a base class can be reused by a derived class.
    - - Multiple forms are known as polymorphism.
      - The different types of polymorphism are operator
      - The ability of an operator and function to take.
      - Function overloading, function overriding.
    - - The wrapping of data and function into a single unit is called data encapsulation.
      - Data encapsulation enables data hiding and information hiding.
    - - Data abstraction refers to the process of representing essential features without including background details or explanations.
      - Abstract class:
      - Interface: Khá giống với abstract class nhưng interface không phải là class, trong interface chỉ có khai báo những method/properties trống không có thực thi, thực thi sẽ được thể hiện trong các lớp kế thừa, interface giống như một cái khung mẫu để các lớp implement và follow.
    - - An object may represent a person, place or a table of data.
      - Each object is identified by a unique name. Each object must be a member of a particular class.
      - An object is a collection of data members and associated member functions.
      - Objects are basic building blocks for designing programs.
      - Example: chair, table, whiteboard are the objects of the class (class).
    - - Once the class is defined any number of objects of that class is created.
      - Classes are user-defined data types A class can hold both data and functions.
      - A class is a collection of objects that have identical properties, common behaviour and shared relationship.
      - For example planets, sun and moon are the members of the solar system class.
      - The objects can be made user-defined data types with the help of a class.
- - - - Run-time Structure
        
        Multiplicity
        
        Distance and connection media
        
        Media can be:
        
        Copper/optical
        
        Wired/wireless LAN
        
        Universal invocable
        
        Self-descriptive
      - Management structure (or Deployment structure)
        
        Can be used for resource allocation
        
        Example: dynamic website for online shopping:
        Web page designers
        Business Logic researchers
        Designer/Programmer Webmaste.
        Database Admin
      - Static Structure
        
        A software project is typically implemented in multiple files
        
        Executable files
        
        Library files
        
        Binary software component modules
        
        Deployment descriptors
        
        Others resources files
        
        At software development time
        
        The main software elements are source code files
        
        Each modules has assigned functional and nonfunctional attributes
        
        API defined for modules separates module’s interface and implementation
        
        The connectors at this level are in the form of module dependency
        
        Static connectors may exhibit some attributes
        
        Direction
        
        Synchronization
        
        Sequence
        
        At deployment time
        
        The elements are binary versions of the project modules and files.
        
        Several source code modules may be packaged into the same deployment unit
        
        The connectors in the deployment structures are basically the same as those for the source module structures
        
        Managing Static Structural Representations
        
        The software static structure
        
        Refers to the organization of physical software modules and their interrelations
        
        This structure play a critical roles in software architecture design
        
        Static structure affects the architecture's clarity, construction strategy, maintenance, reengineering, reusability…
        
        It plays a crucial role in the management of large software systems because it deals with the packaging of software modules in order to facilitate system construction and maintenance through a clear portrayal of intermodule relations.
        
        Managing static structures involves layers of
        
        Abstraction for encapsulation
        
        Refinement showing visibil
        
        Two kinds of static hierarchical relation
        
        A linear client-server relation is formed when a component provides primitive abstractions to another component
        
        A tree-like hierarchy of refinement relations is formed when an abstraction is implemented, and recursively divides into subcomponents. A refinement relation specifies how a module (parent) is decomposed into a refinement module (child).
    - - Rule 1: Reentrant
        
        Reentrant describes a computer program or routine that is written so that the same copy in memory can be shared by multiple users.
        
        A computer program or subroutine is called reentrant if it can be interrupted in the middle of its execution and then safely called again ("re-entered") before its previous invocations complete executing.
        
        A programmer writes a reentrant program by making sure that no instruction modify the contents of variable values in other instructions within the program.
        
        Commonly required in operating systems and in applications intended to be shared in multi-use systems.
        
        This is an example of a swap() function which fails to be reentrant (as well as thread-safe). As such, it should not have been used in the interrupt service routine isr():
        
        swap() could be made thread-safe by making t thread-local. It still fails to be reentrant and this will continue to cause problems if isr() is called in the same context as a thread already executing swap().
      - Rule 2: Handle Bottle-Neck First
        
        Treat bottle-neck functionality using the following approaches
        
        (1) Wrap it as a separate and highly independent module
        
        (2) Improving its efficiency by replication
        
        (3) Depending on computing needs, allocate cluster or multi-CPU computers for bottle-neck modules in deployment
        
        Example
        
        If an element has high multiplicity and its performance is important to the global system performance, an application server should be used for its implementation
        
        If there are heavy computations in the elements for deployment at a particular location, a cluster of processors should be considered for added CPU data processing power
      - Rule 3: Make Things Simple
        
        If a module is too large
        
        Split it into smaller ones
        
        Vertical Layers
        
        Horizontal Layers
  - - - Efficiency
      - Reliability
      - Availability
      - Security
    - - Based on Synchronization
        
        Blocking: A blocking connector allows one of its incident elements to send a request to another and wait for a response
        
        Non-blocking: A non-blocking connector allows one of its incident elements to send a request to another and continues its execution without waiting for a response.
      - Initiator
        
        One Initiator: It only allows one of the two connected elements initiates the request, but not another way around
        
        Two Initiator: either of the two elements can make the request
    - - Signature based
        
        Usually method invocation
        
        Signature: the method name plus the list of parameter types
        
        Method parameter indicates operation type
      - Protocol based: A protocol-based connector can implement multiple operation types with a single binding signature
    - - Based on connector’s active time
        
        Programmed (A method call will be made at a time specified at programming time)
        
        Event-driven
        
        One element will function as an event source
        
        All elements that need be notified of the event will register as listeners of the event source
        
        When the event happens, all the registered listener elements will be notified for potential reaction
    - - Depending on connector span
        
        Local
        
        Network
      - Typical examples
        
        Local method invocation, function call (local)
        
        Distributed Remote Method Invocation (RMI)
        
        Remote Procedure Call (RPC)
      - Network Connectors need more efforts
        
        Invocation semantics (tricky)
        
        Reliability (hard)
        
        Security (problematic, e.g. RPC)
        
        However, desperately needed by distributed computing environments.
  - - - Traditional Water-Fall Approach
        Big gap between(Requirement specification
        vs Software Architecture)
      - Iterative Refinement: Refine designs based on changing requirement
- - - - Software architecture specifies a high-level of abstraction of a software system
      - Lines in the box-and-line diagrams indicate the relationship among components
      - Box-and-line diagrams are often used to describe the business concepts and processes during the analysis phase of the software development lifecycle.
      - The 4+1 view model is another way to show the functional and nonfunctional requirements of a software project. There are five views in
        the model: the logical view, the process view, the development view, the physical view, and the user interface view
  - - - Component: Describes all components in a system, their interrelationships, interactions, and the interface of the system. It is an
        outline of the composition structure of components or modules
        
        Component Diagram là bản vẽ cho biết cấu trúc của hệ thống theo thành phần phần mềm
        
        Các thành phần của Component Diagram
        
        Component là một thành phần phần mềm được đóng gói độc lập, nó có thể được triển khai độc lập trên hệ thống và có khả năng tương tác với các thành phần khác khi thực hiện các chức năng của hệ thống.
        
        Component Dependence thể hiện quan hệ giữa các thành phần với nhau. Các thành phần phần mềm luôn cần sử dụng một số chức năng ở các thành phần khác trong hệ thống nên quan hệ Dependence được sử dụng thường xuyên.
        
        Xây dựng Component Diagram
        
        Chia hệ thống thành những SubSystem
        
        Xác định các thành phần và vẽ
        
        Ứng dụng của Component Diagram
        
        – Thể hiện cấu trúc của hệ thống
        
        – Cung cấp đầu vào cho bản vẽ Deployment
        
        – Hỗ trợ cho việc thiết kế kiến trúc phần mềm
        
        Kết luận: Component Diagram là một bản vẽ đơn giản nhưng có ảnh hưởng lớn đến việc thiết kế chi tiết của hệ thống phần mềm và cách thức tổ chức phát triển sản phẩm. Do vậy, các bạn nên dành thời gian cho bản vẽ này để đảm bảo hiểu và dùng được nó sẽ có lợi về sau.
      - Composite
        structure: Describes the inner structure of a component including all classes within the component, interface of the
        component, etc.
      - Package: Describes the package structure and organization. It covers classes in the package and packages within another
        package. https://www.lucidchart.com/pages/uml-package-diagram
        
        Sơ đồ gói là sơ đồ cấu trúc được sử dụng để thể hiện tổ chức và sắp xếp của các phần tử mô hình khác nhau dưới dạng gói
        
        A package is a grouping of related UML elements, such as diagrams, documents, classes, or even other packages
        
        Package diagrams được sử dụng phổ biến nhất để cung cấp một tổ chức trực quan của kiến trúc phân lớp trong bất kỳ trình phân loại UML nào, chẳng hạn như hệ thống phần mềm.
        
        Benefits of a package diagram thiết kế tốt cung cấp nhiều lợi ích cho những người muốn tạo ra hình ảnh trực quan về hệ thống hoặc dự án UML của họ.
        
        Chúng cung cấp một cái nhìn rõ ràng về cấu trúc phân cấp của các phần tử UML khác nhau trong một hệ thống nhất định.
        
        Các sơ đồ này có thể đơn giản hóa các sơ đồ lớp phức tạp thành các hình ảnh trực quan có thứ tự tốt.
        
        Họ cung cấp khả năng hiển thị cấp cao có giá trị vào các dự án và hệ thống quy mô lớn
        
        Sơ đồ gói có thể được sử dụng để làm rõ một cách trực quan nhiều loại dự án và hệ thống.
        
        Những hình ảnh trực quan này có thể dễ dàng cập nhật các hệ thống và các dự án phát triển
        
        Basic components of a package diagram Cấu trúc của một sơ đồ gói tương đối đơn giản. Mỗi sơ đồ chỉ bao gồm hai ký hiệu:
        
        Package Nhóm các yếu tố chung dựa trên dữ liệu, hành vi hoặc tương tác của người dùng
        
        Dependency Mô tả mối quan hệ giữa một phần tử (gói, phần tử được đặt tên, v.v.) và một phần tử khác
        
        Các ký hiệu này có thể được sử dụng theo nhiều cách khác nhau để biểu diễn các lần lặp khác nhau của các gói, phần phụ thuộc và các phần tử khác trong một hệ thống.
        
        Packageable element: Một phần tử được đặt tên, có thể thuộc sở hữu trực tiếp của một gói. Chúng có thể bao gồm các sự kiện, thành phần, ca sử dụng và chính các gói. Các phần tử có thể đóng gói cũng có thể được hiển thị dưới dạng hình chữ nhật trong một gói, được gắn nhãn với tên thích hợp.
        
        Dependencies: Trình bày trực quan về cách một yếu tố (hoặc tập hợp các yếu tố) phụ thuộc hoặc ảnh hưởng đến yếu tố khác. Các phần phụ thuộc được chia thành hai nhóm: phần phụ thuộc truy cập và nhập. (Xem phần tiếp theo để biết thêm thông tin.)
        
        Package: Một không gian tên được sử dụng để nhóm các phần tử có liên quan với nhau một cách hợp lý trong một hệ thống. Mỗi phần tử có trong gói phải là một phần tử có thể đóng gói và có một tên duy nhất.
        
        Element import: Mối quan hệ được định hướng giữa không gian tên nhập và phần tử có thể đóng gói được nhập. Điều này được sử dụng để nhập các phần tử riêng lẻ được chọn mà không cần dùng đến nhập gói và không công khai nó trong không gian tên.
        
        Package import: mối quan hệ có hướng giữa và nhập không gian tên và một gói đã nhập. Loại mối quan hệ có hướng dẫn này thêm tên của các thành viên của gói được nhập vào vùng tên riêng của nó
        
        Package merge: Một mối quan hệ có hướng trong đó nội dung của một gói được mở rộng bởi nội dung của gói khác. Về cơ bản, nội dung của hai gói được kết hợp để tạo ra một gói mới.
      - Object: Objects and their relationship at runtime. An overview of particular instances of a class diagram at a point of time
        for a specific case. It is based on the class diagram.
      - Deployment: Describes system hardware, software, and network connections for distributed computing. It covers server
        configuration and network connections between server nodes in real-world setting.https://iviettech.vn/blog/1627-deployment-diagram-ban-ve-trien-khai.html
        
        Deployment Diagram thể hiện rõ kiến trúc triển khai nên nó sẽ ảnh hưởng đến sự thiết kế, phát triển, hiệu năng, khả năng mở rộng của hệ thống v.v…
        
        Các thành phần của Deployment Diagram
        
        Node là một thành phần vật lý, nó có thể là thiết bị phần cứng hoặc một môi trường nào đó mà các thành phần phần mềm được thực hiện.
        
        Relationship:Deployment Diagram sử dụng quan hệ Association và Dependence để thể hiện mối quan hệ giữa các node với nhau. Các ký hiệu của chúng như sau:
        
        Xây dựng Deployment Diagram
        
        Xác định các thành phần để triển khai lên các Node
        
        Xác định các quan hệ và hoàn tất bản vẽ
        
        Xác định các thành phần phần cứng sẽ tham gia vào việc triển khai hệ thống
        
        Ứng dụng của Deployment Diagram
        
        Làm tài liệu để triển khai hệ thống.
        
        Sử dụng trong thiết kế kiến trúc cho hệ thống.
        
        Dùng trong giao tiếp với khách hàng, các nhà đầu tư.
        
        Cũng như Component Diagram, deployment diagram là một bản vẽ khá đơn giản và dễ xây dựng nhưng có ảnh hưởng rất lớn đến quá trình phát triển, triển khai và kinh phí xây dựng dự án
      - Class: An overview of classes for modeling and design. It shows how classes are statically related, but not how classes
        dynamically interact with each other.
        
        It is the foundation diagram of the system design and it is the most frequently used UML diagram as well.
        
        Class diagrams can be derived from use case diagrams or derived from text analysis on the given problem domain.
        
        This diagram provides a static view of the system. It captures the vocabulary of the designed system.
        
        A class diagram is generated by system analysts and system designers and will be iteratively refined in the subsequent phases during the software development life cycle.
        
        Class diagrams describe each individual class with its type, interface, properties, and methods.
        
        The accessibility (visibility) of each attribute and operation can also be specified.
        
        Popular accessibility modifiers include private, public, protected, and default.
        
        One important part of a class diagram is the interface of each class.
        
        A class interface provides the behavioral contracts that the class must support.
        
        There are three main different relationships among classes’ these are inheritance, aggregation, and association.
        
        They all can be represented graphically in a class diagram.
        
        For each relationship, multiplicities between classes can be denoted.
        
        Typical multiplicity types include one to one, one to many, and many to many mappings.
        
        In UML multiplicity notations, 1 stands for one instance, 0 stands for no instance, 0..1 stands for zero or one instance, and 1..* stands for at least one instance.
    - - Sequence: Describes time sequence of messages passed among objects in a timeline.
        
        Sequence Diagarm là bản vẽ mô tả sự tương tác của các đối tượng để tạo nên các chức năng của hệ thống. Bản vẽ này mô tả sự tương tác theo thời gian nên rất phù hợp với việc sử dụng để thiết kế và cài đặt chức năng cho hệ thống phần mềm.
        
        Các thành phần của Sequence Diagram
        
        Object mô tả một đối tượng trong hệ thống. Để phân biệt với Class, Object có dấu “:” phía trước tên của nó.Đường gạch chấm bên dưới đối tượng thể hiện thời gian sống của đối tượng.Xử lí bên trong đối tượng người sử dụng (màn biểu diễn bằng các đoạn hình chữ nhật rỗng nối với những con đường đời đối tượng)
        
        Stimulus (message) thể hiện thông điệp từ một đối tượng này tương tác với một đối tượng khác.
        
        Thông điệp đồng bộ (Synchronous Message)
        Thông điệp nhất quán cần có một request trước hành động tiếp theo.
        
        Thông điệp ko đồng bộ(Asynchronous Message)
        Thông điệp không đồng bộ ko cần phải có một request trước hành vi tiếp sau.
        
        Thông điệp chính mình (Self Message)
        Là thông điệp nhưng đối tượng gửi cho thiết yếu nó nhằm thực hiện các hàm nội trên.
        
        Thông điệp vấn đáp hoặc trả về (Reply or Return Message)
        Là thông điệp vấn đáp lại lúc tất cả request hoặc sau khoản thời gian kiểm tra tính đúng chuẩn của một ĐK như thế nào kia. ví dụ như thông điệp loại này hệt như lời nhắn trả về là success hoặc fail
        
        Thông điệp tạo new (Create Message)
        Là thông điệp được trả về khi chế tạo new một đối tượng người sử dụng.
        
        Thông điệp xóa (Delete Message)Là thông điệp được trả về lúc xóa một đối tượng người dùng.
        
        Axes : Trục tọa độ, trục ngang thể hiện các đối tượng, trục đứng thể hiện thời gian.Chúng ta, dễ dàng nhận thấy các đối tượng tương tác với nhau theo tuần tự các bước để hình thành nên chức năng của hệ thống.
        
        Xây dựng Sequence Diagram
        
        Bước 1: Xác định chức năng cần thiết kế. Bạn dựa vào Use Case Diagram để xác định xem chức năng nào cần thiết kế.
        
        Bước 2: Dựa vào Activity Diagram để xác định các bước thực hiện theo nghiệp vụ.
        
        Bước 3: Đối chiếu với Class Diagram để xác định lớp trong hệ thống tham gia vào nghiệp vụ.
        
        Bước 4: Vẽ Sequence Diagarm
        
        Bước 5: Cập nhật lại bản vẽ Class Diagram
        
        Ứng dụng Sequence Diagram
        
        – Thiết kế các chức năng
        
        – Kiểm chứng và bổ sung method cho các Class
        
        – Sử dụng trong việc coding các chức năng
      - Interaction Overview: Combines activity and sequence diagrams to provide control flow overview of the system and business process.
      - State machine: Describes the life cycle of objects using a finite state machine. The diagram consists of states and the transitions between states. Transitions are usually caused by external stimuli or events. They can also represent internal moves by the object. Tham khao detail
        
        State Machine Diagram mô hình behaviour của single object, chỉ rõ tuần tự các events mà object đi qua trong thời gian sống của nó, trả lời các events.
        
        Các thành phần cấu tạo
        
        Trạng thái ban đầu (initial state): Biểu tượng trạng thái ban đầu được sử dụng để chỉ ra sự bắt đầu của biểu đồ trạng thái.
        
        Hộp trạng thái (state-box):Đó là một thời điểm cụ thể trong vòng đời của một đối tượng được định nghĩa bằng cách sử dụng một số điều kiện hoặc một câu lệnh trong phần thân trình phân loại.Nó được biểu thị bằng cách sử dụng một hình chữ nhật với các góc tròn. Tên của một trạng thái được viết bên trong hình chữ nhật tròn hoặc cũng có thể được đặt bên ngoài hình chữ nhật
        
        Hộp quyết định (decision-box): Nó chứa một điều kiện. Tùy thuộc vào kết quả của một điều kiện bảo vệ đã đánh giá, một đường dẫn mới được thực hiện để thực hiện chương trình.
        
        Trạng thái kết thúc (final-state): Biểu tượng này được sử dụng để chỉ ra kết thúc của một biểu đồ trạng thái.
        
        chuyển tiếp (transition):Quá trình chuyển đổi là sự thay đổi trạng thái này sang trạng thái khác xảy ra do một số sự kiện. Quá trình chuyển đổi gây ra sự thay đổi trạng thái của một đối tượng.
        
        Cách vẽ biểu đồ trạng thái trong UML
        
        Bước 1: Xác định trạng thái ban đầu và trạng thái kết thúc cuối cùng.
        
        Bước 2: Xác định các trạng thái khả dĩ mà đối tượng có thể tồn tại (các giá trị biên tương ứng với các thuộc tính khác nhau hướng dẫn chúng ta xác định các trạng thái khác nhau).
        
        Bước 3: Gắn nhãn các sự kiện kích hoạt các chuyển đổi này.
      - Communication: Describes the sequence of message passing among objects in the system. Equivalent to sequence diagram, except that it focuses on the object—s role. Each communication link is associated with a sequence order number plus the passed messages.
      - Activity: Outline of activity—s data and control flow among related objects. An activity is an action for a system operation or a business process, such as those outlined in the use-case diagram. It also covers decision points and threads of complex operation processes. It describes how activities are orchestrated to achieve the
        required functionality
        
        Activity Diagram là bản vẽ tập trung vào mô tả các hoạt động, luồng xử lý bên trong hệ thống. Nó có thể được sử dụng để mô tả các qui trình nghiệp vụ trong hệ thống, các luồng của một chức năng hoặc các hoạt động của một đối tượng.
        
        Ký hiệu
        
        Swimlance được ùng để xác định đối tượng nào tham gia hoạt động nào trong một qui trình
        
        Nút Start, End
        Start thể hiện điểm bắt đầu qui trình, End thể hiện điểm kết thúc qui trình.
        
        Activity mô tả một hoạt động trong hệ thống. Các hoạt động này do các đối tượng thực hiện.
        
        Branch thể hiện rẽ nhánh trong mệnh đề điều kiện.
        
        Fork thể hiện cho trường hợp thực hiện xong một hoạt động rồi sẽ rẽ nhánh tthực hiện nhiều hoạt động tiếp theo.
        
        Join Cùng ký hiệu với Fork nhưng thể hiện trường hợp phải thực hiện hai hay nhiều hành động trước rồi mới thực hiện hành động tiếp theo.
        
        Cách xây dựng Activity Diagram
        
        Bước 1: Xác định các nghiệp vụ cần mô tả
        
        Bước 2: Xác định trạng thái đầu tiên và trạng thái kết thúc
        
        Bước 3: Xác định các hoạt động tiếp theo
        
        Sử dụng bản vẽ Activity Diagram
        
        – Phân tích nghiệp vụ để hiểu rõ hệ thống
        
        – Phân tích Use Case
        
        – Cung cấp thông tin để thiết kế bản vẽ Sequence Diagram
      - Time sequence: Describes the changes by messages in state, condition, and events
      - Use case: 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.
        
        Dinh nghia: 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 bạn sẽ hiểu được yêu cầu của hệ thống cần xây dựng.
        
        Các thành phần trong bản vẽ Use Case
        
        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.
        
        Use Case là chức năng mà các Actor sẽ sử dụng.
        
        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
        
        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 đượ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. 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
        
        Tìm các Actor
        
        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?
        
        Xác định Use Case: Trả lời câu hỏi các Actor sử dụng chức năng gì trong hệ thống?
        
        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.
        
        Đặc tả Use Case
        
        Cách 1: Viết đặc tả cho các Use Case
        
        Cách 2: Sử dụng các bản vẽ để đặc tả
        
        Sử dụng UseCase 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
        
        – 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.
  - - - This view addresses the sub-system decomposition and organizational issue.
      - In this view, the software is packaged and partitioned into small units such as program libraries or sub-systems that are developed by many teams of developers.
      - Modules such as namespaces, class library, sub-system, or packages are building blocks that group classes for further development and implementation.
      - Each package has its own visibility and accessibility as package or default scope visibility (see static structure discussion above).
      - It is derived from the logical view.
      - The development view maps software component elements to actual physical directories, files in the development environment.
      - The development view describes the software static organization of the system modules.
      - UML diagrams such as package diagrams and component diagrams are often used to support this view.
      - The stakeholders of this view can be programmers and software project manager.
    - - How to organize all execution units at runtime is presented in this view.
      - The quality attributes such as performance, scalability, concurrency, synchronization, distribution, and system throughput are addressed here.
      - A software system can be decomposed into many such units.
      - This view maps functions, activities, and interactions onto runtime implementation with a focus on non-functional requirements as well as the implementation of the functional requirements.
      - A process is a runtime execution unit
      - The process view takes care of the concurrency and synchronization issues between sub-systems in the system.
      - The process view is a coordination view of the system's processes and the communications between them.
      - It can be described from several levels of abstraction, starting from independently executing logical networks of communicating programs to basic tasks running within the same processing node
      - It contributes to many non-functional requirements and quality attributes such as scalability and performance requirements.
      - The non-functional requirements are also important issues the process view must address such as multi-threading, synchronous and asynchronous communications for performance and availability.
      - This view is an abstraction of processes or threads dealing with process synchronization and concurrency.
      - The UML activity diagrams and interaction overview diagram support this view.
      - This view is also derived from logical view
      - The stakeholders of this view are the developers and integrators.
      - The process view focuses on the dynamic aspects of the system, i.e., its execution time behavior.
      - Many architectural styles such as pipe & filter, multi-tier, and others can be applied in the process view
    - - It focuses on functional requirements and the main building blocks and key abstractions decomposing of the system.
      - The view basically is an abstraction of the system's functional requirements.
      - The logical view is based on application domain entities necessary to implement the functional requirements.
      - It is typically used for object-oriented modeling from where the static and dynamic system structures emerge
      - The logical view is typically supported by UML static diagrams such as: class/object diagram and UML dynamic diagrams such as interaction overall diagram, sequence diagram, communication diagram, state diagram, and activity diagram
      - The logical view specifies system decomposition into conceptual entities (such as objects), and connection between them (such as associations).
      - This view helps to understand the interactions between entities in the problem space domain of the application and their potential variation
      - The stakeholders of the logical view are the end-user, analysts, and designers. We can apply an object-oriented design methodology in the logical view design since the view itself is object oriented.
    - - It is particularly of interest in distributed or parallel systems.
      - The components are hardware entities (processors), and the links are communication pathways; these together specify how the various elements such as communication protocols and middleware servers found in the logical, process, and development views are mapped onto the various “nodes” in the runtime environment.
      - The physical view shows the mapping of software onto hardware.
      - A physical view also takes into account the system's nonfunctional requirements such as system availability, reliability (fault-tolerance), throughput performance, scalability performance, and security.
      - It concerns itself with how to deliver the deployable system.
      - For example, software can be delivered in different hardware and networking layouts which will result in significant differences in terms of these quality attributes.
      - The physical view describes installation, configuration, and deployment of the software application.
      - The stakeholders of this view are system installers, system administrators, system engineers, and operators.
      - This deployment diagram shows that the order processing system is deployed on two servers.
    - - The scenario view describes the functionality of the system, i.e., how user will use the system and how the system provides services to the users.
      - It helps designers discover architectural elements during design and helps to validate the architectural design afterward.
      - This view provides a foundation for other 4 views and lets them work together seamlessly and coherently.
      - the scenario view helps to make the software architecture consistent and validated against functional and non-functional requirements
    - - This view may be provided as a series of screen snapshots or a dynamic, interactive prototype demo.
      - Any modification on this view will have direct impact on the scenarios view.
      - An extended view from scenarios view is the user interface (UI) view giving user-computer clear interface view while hiding implementation details.
    - - Each view provides a window for the different aspects of the system.
      - It covers all aspects of a software architecture for all stakeholders.
      - The view is an architecture verification technique for studying and documenting software architectural design.
      - The views are interconnected; thus, based on the scenarios view, we can start with logical view, and then move to development or process view and, finally go to physical view.
      - The user interface view is also established during this process.