Reading Notes of UML and model application (1)

Part 1 Introduction

1. In OO development, a vital capability is to skillfully assign responsibilities to software objects. I personally think the ability to abstract objects is also very important.

2. analysis emphasizes the investigation and research of problems and needs, rather than solutions; design) it emphasizes conceptual solutions (in terms of software and hardware) that meet the needs, rather than implementation.

Useful analysis and design can be summarized as: Doing the right thing (analysis) and doing the right thing (design ).

3. Requirement analysis may include how people use the plot or scenario of an application. These plots or scenarios can be written into use cases ).

4. object-oriented analysis focuses on creating domain descriptions from the perspective of objects. object-oriented analysis needs to identify important concepts, attributes, and associations. The results of object-oriented analysis can be expressed as domain models, which display important domain concepts or objects.

5. object-oriented design focuses on the definition of software objects-their responsibilities and collaboration.

6. The domain model represents the real world class, and the design class diagram represents the software class.

7. agile modeling emphasizes UML as a sketch method, which is also a common method applicable to UML, and usually has a high return on time investment (generally takes a short time ).

8. iterative development is a key practice in UP and most other modern methods. In this life cycle method, development is organized into a series of fixed short-term (such as three weeks) small projects, called iteration ), each iteration generates a tested, integrated, and executable local system. Each iteration has its own needs analysis, design, implementation, and testing activities.

9. Advantages of iterative development include:

• Reduce the possibility of project failure, increase productivity, and reduce the defect rate.
• Mitigate high risks (technology, demand, goals, availability, and so on) at an early stage ).
• Early visible progress.
• Early feedback, user participation, and adjustments will produce a refined system that is closer to the real needs of the stakeholders.
• Controllable complexity; the team will not be overwhelmed by "analysis paralysis" or long-term and complex steps.
• The experience in one iteration can be systematically used to improve the development process itself and continue so repeatedly.

10. Feedback and adjustment are key elements of success in complex and change systems (such as most software projects.

11. How to perform iterative and Evolutionary Analysis and Design:

1) before 1st iterations, hold the first quantitative demand work meeting, for example, to define exactly two days, and business and development personnel (including the Chief Architect) need to attend.

• On the morning of the first day, conduct high-level requirement analysis, such as determining only the names of Use Cases and features, and key non-functional requirements. This analysis cannot be perfect.
• By consulting the chief architect and business personnel, you can select the 10% list items from the high-level list. These projects have the following three properties: 1. They have important architectural significance; 2. They have high business value; 3. high risk.
• In the remaining one and a half days, the functional and non-functional requirements of the three use cases are analyzed in detail. After this process is completed, 10% is analyzed in depth, and 90% is analyzed in higher order.

2) Hold an iteration plan meeting before 1st iterations, select a subset of the above three use cases, and design, construct, and test within a specific period of time (for example, four weeks of quantitative iteration.

3) Complete 1st iterations in three to four weeks (select time quantification and strictly observe the time ):

• In the first two days, developers and other member groups are responsible for modeling and design. Under the guidance and guidance of the Chief Architect, they are on the whiteboards of the public war room, draw a sketch of UML (and its model ).
• Then, the developer removes the "modeling hats" and puts on the "programming hats" to start programming, testing, and integration work, and the rest of the time is used to complete the work.
• Conducts a large number of tests, including unit tests, acceptance tests, load tests, and availability tests.
• In the week before the end, check whether the initial iteration target can be completed. If not, narrow down the iteration scope and set the secondary objectives back to the task list.
• The code is frozen on Tuesday of the last week. All code must be checked, integrated, and tested to establish an iterative baseline.
• On the morning of Wednesday, the local system was presented to external stakeholders, showing early visual progress and asking for feedback.

4) at the end of 1st iterations (such as the Wednesday and Thursday of the last week), the second demand work meeting will be held to review and refine all the materials of the previous meeting, then, select another 10% to 15% use cases with significant architectural significance and high business value, and analyze them in detail within one or two days.

5) the next iteration plan meeting will be held on Friday morning.

6) perform 2nd iterations in the same step.

7) carry out four iterations and five requirement work meetings repeatedly, so that at the end of 4th iterations, the requirements of about 80%-90% may have been recorded in detail.

8) We pushed around 20% of the entire project process. At this time, we can estimate the workload and time required for these refined and high-quality demands. Because the investigation, feedback, and early programming and testing are based on the actual results, it is more reliable to estimate what can be done and how long the results will take.

9) since then, it is generally not necessary to hold a demand work meeting; the demand has stabilized (although the demand will never be frozen ). Next is a series of three-week iterations. At the iteration plan meeting held on the last Friday, we will choose the appropriate next step. Each iteration will repeatedly ask: "as far as we know, what are the most critical technologies and business features that should be completed in the next three weeks?"

Using this method, after several iterations of early exploratory development, the team will be able to answer "what, how, and when" more accurately ".

12. Modeling (Building UML sketch ......) The main purpose is to understand rather than document.

Part 2 initial stage

1. Summarize the initial stage in one sentence: predict the scope, vision, and business case of the project. Summarize the main problems to be solved in the initial stage in one sentence: whether the stakeholders have basically reached an agreement on the project concept, and whether the project is worth further research.

2. The biggest challenge of demand analysis is to find, communicate, and remember (usually records) what is really needed and clearly explain it to customers and development team members.

3. In the Unified Process, the requirements are classified according to the "FURPS +" model. This is an effective memory method and its meaning is as follows:

• Funcational: features, functions, and security.
• Availability: human factors, help, and documentation.
• Reliability: Fault frequency, recoverability, and predictability.
• Performance: response time, throughput, accuracy, validity, and resource utilization.
• Supportability: applicability, maintainability, internationalization, and configurability.

"+" In "FURPS +" refers to auxiliary and secondary factors, such:

• Implementation: idle resources, languages and tools, and hardware.
• Interface: Constraints Imposed on external system interfaces.
• Operation: System Management for its Operation settings.
• Packaging: for example, a weak Packaging box.
• Authorization (Legal): license or other methods.

If you want to get something from your life, the first step is to decide what you want. -Ben. Stan (Ben Stein)

4. Use Cases are case descriptions in text format and are widely used in requirement discovery and recording.

5. Use Cases are an excellent method, which makes it possible for a domain expert or requirement provider to write (or participate in writing) Use Cases by themselves and makes the work more difficult.

Part 3 refine the foundation of iteration 1

1. elaboration is the first series of iterations in a general project, including:

• Program and test the core and risky software architecture.
• Discover and stabilize the main part of the requirement.
• Avoid major risks.

The Refinement phase is the first series of iterations at which the team conducts a thorough investigation, implements (programming and testing) The core architecture, clarifies the majority of requirements, and responds to high-risk issues.

2. Some key ideas and best practices that may arise during the Refinement phase include:

• Implement short-term quantitative and risk-driven iteration.
• Start programming early.
• Adaptive design, implementation, and testing of the core and risk components of the architecture.
• Early, frequent, and practical testing.
• Adjustments are made based on feedback from tests, users, and developers.
• The majority of use cases and other requirements are detailed through a series of seminars, and each refined iteration is held once.

3. The relationship between conceptual classes is expressed by association rather than attribute.

4. There is no correct domain model. All models are an approximation of the domain we are trying to understand. Domain Models are mainly tools used to understand and communicate with specific groups.

5. Objects in the same layer should be closely related to their responsibilities. The responsibilities of objects in different layers should not be confused.

6. What objects are needed, how they collaborate through messages and methods, and how to implement these accurate and detailed conclusions through Dynamic Object Modeling (for example, drawing a sequence chart.

7. The time should be spent on the Interaction diagram (sequence diagram or communication diagram), not just the class diagram.

8. Any Sequence Chart can be surrounded by an sd frame and named. When you want to reference the sd frame of the corresponding name, you can use the ref frame.

9. In the class diagram, use the dependency line to describe the dependencies of global variables, parameter variables, local variables, and static methods (called for static methods of other classes) between objects.

10. GRASP is short for General Responsibility Assignment Software Patterns. The nine GRASP modes are as follows:

Creator)

If one of the following conditions (the more the better) is true, the responsibility for creating A class A instance is assigned to Class B:

• B "contains" or composite.
• B records.
• B directly uses.
• B has the initialization data of A and passes the data to A when creating. Therefore, for the creation of A, B is an expert.
• B is the creator of object.

Note: Object creation is often quite complex. The best way to do this is to delegate the creation responsibility to a helper class called a Concrete Factory or Abstract Factory, instead of using the class recommended by the Creator mode.

Information Expert)

Assign responsibilities to information experts who have the information necessary to achieve this responsibility. Responsibilities should be clearly described.

Note: In some cases, the solution recommended by the expert mode is not suitable due to coupling and cohesion issues.

Low Coupling)

Assign responsibilities to minimize coupling. Use this principle to evaluate options.

Controller)

The Controller is the first object on the UI Layer. It is responsible for receiving and processing system operation messages.

High Cohesion)

Cohesion (or more specifically, functional cohesion) is a measure of the correlation and concentration of element responsibilities.

Polymorphism)

Pure Fabrication)

Indirection)

Protected Variations)