Chapter 6 UML modeling and architecture docalization

Section 6.3 UML-based software development process

 

Based on the author's ideas, sort out the following:

 

UML-based software development process:
1. Initial launch
2. Refinement
A) initial requirement analysis
B) preliminary high-level design
C) Detailed Design
D) prototype construction
3. Build
4. Deployment

UML-based Requirement Analysis
1. Generate Use Cases
2. Use an activity diagram to describe the use case
3. Generate a use case diagram
4. Build a top-level architecture
A) UML package diagram
B) Top-layer architecture design (some modes can be considered, such as process processing mode, customer/Server mode, hierarchical architecture, and MVC Architecture)
5. Create a conceptual model

 

 

 

Object-Oriented Design Method
1. design case Implementation Scheme
A) extract boundary class, control class, and entity class
B) construct an interaction Diagram
C) Refined image based on interactive Images
2. Design Technical Support Solutions
A) Persistence
B) security and exception Control
C) concurrency and Synchronization Control
D) distributed communication and transactions
3. Design the user interface
A) be familiar with and classify users
B) analyze workflow and habits by user type
C) design the Command System
D) Design User Interface Details
4. Refined Design Model

 

 

 

Documented System Architecture
1. Model Overview
A) Logical View, an object model designed.
I. Mainly class diagrams, object diagrams, sequence diagrams, communication diagrams, sequence diagrams, InterAction diagrams, composite diagrams, and state diagrams.
Ii. The logical view mainly describes functional requirements. The logical view abstracts and describes the main classes.
B) process View, capturing Design Concurrency and synchronization features.
I. There are mainly activity diagrams.
Ii. The process view mainly considers non-functional requirements, such as performance and availability. It mainly solves the problems of concurrency, distribution, system integrity, and fault tolerance, and how the main abstraction of the logical view can be combined with the process structure.
C) The physical View (physicl View) describes the ing between software and hardware, reflecting the distribution characteristics.
I. There are mainly deployment diagrams.
Ii. The physical view focuses on non-functional requirements of the system, such as availability, reliability (fault tolerance), performance (throughput), and scalability.
D) development View, which describes the static structure of the software in the development environment.
I. Mainly component charts and package charts.
Ii. development architecture focuses on the organization of actual modules in the software development environment. For example, a software is divided into modules (subsystems). subsystems can organize Component layer structures and interfaces defined on each layer. The development view generally reflects the relationship between input and output. The complete development view can be described only when all software elements are identified. However, you can list the rules that control the development view: blocks, groups, and visibility.
E. use cases and scenarios ).
I. the elements of the four views can work seamlessly in a group of scenarios with a relatively small number of elements (more commonly, use cases, we describe the corresponding scripts for the scenario (the interaction sequence between objects and processes ). In a sense, scenarios are the most important requirement abstraction. Their designs are represented by object scenario diagrams and object interaction diagrams.
Ii. This view is redundant for other views (SO + 1), but it plays two roles:
1. As a driver to discover architectural elements in the architecture design process.
2. As a verification and description function after the architecture design is completed, both view-based and prototype-based architecture testing is started.

 

2. Iteration Process
Scenario-driven method:
A) start stage
I. Select some scenarios for an iteration based on risks and importance. Scenarios may be summarized as abstract requirements of several users.
Ii. Form a "scarecrow-like architecture ". Then describe the scenario to identify the main abstraction (class, mechanism, process, subsystem ).
Iii. The elements found are distributed to four blueprints, namely, logical blueprint, Process Blueprint, development blueprint, and deployment blueprint.
Iv. Then the architecture is implemented, tested, and measured. This analysis may detect enhanced requirements for some shortcomings and potential.
V. capture lessons learned.
B) Cycle Stage
I. the next iteration starts.
Ii. reevaluate risks.
Iii. Scenarios for expansion considerations.
Iv. Select a small number of additional scenarios that can mitigate risks or improve structural coverage.
V. Then try to describe these scenarios in the original architecture.
Vi. Discover additional Architecture elements, or sometimes you need to identify the important architecture changes needed to adapt to these scenarios.
Vii. Update the 4 view.

Viii. Fix existing scenarios based on changes.
Ix. Upgrade implementation tools (architecture prototype) to support new and extended scenarios.
X. Test. If possible, perform tests in the actual target environment and load.
Xi. Then review these 4 + 1 views to detect potential problems of simplicity, reusability, and versatility.
Xii. Follow the new design principles and basic principles.
Xiii. capture lessons learned.
Xiv. Terminate the loop.

 

 

 

 

 

 

 

/*

In my team, I used an object-oriented design method.

1. domain experts and requirement analysts conduct domain analysis and modeling, search for domain objects from the original requirements, establish domain models, and clarify the relationships between domain objects.

2. Describe domain objects and output the data dictionary. (Glossary, important domain conventions, and coarse-grained Use Cases)

3. Search for the status of the domain and describe the cause of the status change.

4. Use an activity diagram to describe the process of a complex domain. For a complex interaction, use a sequence diagram to describe the interaction. This step is optional.

At this moment, the domain analysis is complete and application analysis is started.

5. Search for boundaries based on the domain analysis model and relevant analysis documents, determine users, search for operations, and determine functional requirements. Output use case diagram and use case activity diagram.

6. Search for domain collaboration relationships based on the above documents, draw a domain collaboration diagram, and clarify all important operations between fields.

7. For details about section 6, refer to other relevant documents to find the boundary class, control class, and entity class, specify the attributes and methods of the class, and enter the application analysis class model.

8. Draw the user interface according to 6, 7.

At this moment, the application analysis is complete and the architecture design begins.

9. Based on the characteristics of the system (customer distribution and business rules), a high-level architecture is implemented, mainly considering the hierarchical architecture model (horizontal and vertical segmentation) table mode, domain model mode, and MPs queue.

10. Design of components such as exception handling, security, communication, and persistence based on the characteristics of the system.

11. Design important and representative functions in detail to serve as a template for the designer's work.

12. Complete the implementation of frameworks and components in 9 and 10.

Now the architecture design is complete and enters the detailed design stage.

13. Use the analysis mode and architecture design model to analyze the selected iteration functions and obtain the class diagram, sequence diagram, and important or difficult algorithm description.

14. For complex calls, use an object diagram to describe the object's organization. This step is optional.

At this moment, the detailed design is complete and the implementation phase begins.

15. coding and self-testing

......

The entire development process is driven by UML and 4 + 1 views.

 

There are still many improvements in the development process. For example:

1. At the initial stage of domain analysis, you should add an interactive model, such as a business activity diagram.

2. In the initial stage of application analysis, you should add the use case overview diagram. (The hateful EA does not support the entire graph. It must be replaced by other methods)

3. In the implementation phase, you should first write unit test code for important functions.

 

Compared with the process on the teaching material, we put the content that can be confirmed with the user in front, and put the content that we have worked hard on at the end of the architecture design.

*/