[UML] UML Tutorial-Part II

In the first part, we have established the understanding that UML is a language used to develop the components of software systems and the standard of interactive methods. UML involves 6 major aspects-from use-case models, dynamic and logical models, to final physical deployment models, and extension mechanisms that allow special annotations to be added to models.

So, how do you use UML?

Generally, UML, as part of the software development process, is used to define the requirements, interactions, and elements of the developed system, with the support of a specific case tool. The exact nature of the development process depends on the development method used. A typical development process is generally as follows:

1.	Establish a business process model. A business process model is used to define high-level business activities and business processes that occur within an enterprise or organization, and is the basis for building use-case models. The business process model is generally more achievable than a software system (for example, a business model includes human and other processes).
2.	Map the use case model to the business process model to precisely define the functionality you want to provide and to be considered by the business user. Each time a use case is added, a traceable link from the appropriate business process to the use case is created (for example, an implementation link). This mapping clearly expresses what functionality the new system will provide to meet the business requirements described in the business process. This mapping also ensures that each use case in the system is useful.
3.	Refine use cases-including requirements, constraints, complexity, annotations, and situations. This information clearly describes what the use case does, how to do it, and the constraints associated with execution. This process ensures that the use case always satisfies the needs of the business process, including the system test definition for each use case, which defines the acceptance criteria for the use case. Also includes some user-acceptable test scripts that define the criteria for how users will test and receive tests.
4.	With the input and output of the business process model and details of the use cases, you can start building domain models (advanced business Objects), sequence diagrams, collaboration diagrams, and user interface models. These diagrams describe the features in the new system and the interfaces between those features and the various scenarios that are required for the user to execute the use case.
5.	Based on domain model, user interface model and case diagram, the object class model is established. This is a clear specification of the objects in the system: data, attributes, behaviors, and operations. Using the inheritance mechanism, you can abstract a domain object into a class hierarchy. Messages that handle various situations are generally mapped to the operations of the class. If you use an existing frame or design pattern, you might import elements of the existing model into the new system. Define unit tests, integration tests, and system tests for each class. Test Purpose: 1) whether the function of the class is as expected, as defined, 2) if the class interacts with other classes and components.
6.	When you develop a class model, you may want to break it down into packages and components. A component represents a piece of software that can be used, a combination of data and behavior for a class or multiple classes, and a strict definition of an interface that provides services externally. So, from the perspective of the class model, the construction component model is the logical package that defines the class. For each component, the integration test needs to be defined to verify that the interface of the component meets the specification requirements, that is, the relationship to other software elements.
7.	When you do this, you need to get some additional requirements and document them. For example: Non-functional requirements, performance requirements, security requirements, obligation requirements, release plans and so on. These requirements are consolidated within the model and updated with the model's progress.
8.	The deployment model defines the physical architecture of the system. This work can be started early in order to understand the physical structure of the system-what hardware, operating system, network size, interface and support software are used to form the new system, and the parameters used in system recovery, system reliability, system backup and support in the event of a catastrophic failure. With the development of the model, the physical system model should be updated to reflect the actual situation of the developed system.
9.	Construction system: Assigns the dispersion module of the model to one or more developers. If a use case-driven approach is used to construct the system, it would mean assigning a use case to the development team, allowing them to construct user interfaces, business objects, database tables, and related components necessary to execute the use case. When you construct each use case, you should complete unit tests, integration tests, and system tests at the same time. If you are building a system with a component-driven approach, you need to assign individual components to the development team.
10.	Track the defects in the test phase against the elements in the model. For example: Review system test flaws for use cases, view unit test flaws for object classes, and so on, and track changes to related model elements to prevent scope spread.
11.	As the work progresses constantly updating and perfecting the model-each time the model is modified or perfected, it is necessary to evaluate the changes or improvements to the impact of the subsequent work. Use iterative working methods in module design, review current constructed modules, new arrivals requirements, and any problems found in the development process.
12.	The complete and tested software is sent to the test production stage. If phased delivery is used, the software production process needs to be repeated from test to production to finalize the entire project.

Note: The process described above is only a brief overview of what the project has to experience, and a lot of it is not mentioned. It's not about telling you how to work or not following the methods you've adopted. It only gives an example of how UML can be used to support software development projects.

[UML] UML Tutorial-Part II