Reading Notes of UML and model application (2)

Part 4 refine iteration 2 more modes

1. in projects that are skilled in using UP, the requirements selected for early iterations are organized based on risks and high business value, so that high-risk problems can be identified and solved as soon as possible.

2. The last four GRASP modes:

Polymorphism)

When the related selection or behavior varies with the type (class), use the polymorphism operation to assign responsibility for the changed behavior type. Do not test the object type or use conditional logic to perform different types-based selection.

Unless there is a default behavior in the superclass, declare the polymorphism method in the superclass as {abstract }.

Polymorphism means that abstract superclass or interfaces must be used in most OO languages. When should I consider using interfaces? The general answer is that you can use interfaces when you want to support polymorphism but do not want to constrain a specific class hierarchy. If an abstract super-class AC is used instead of an interface, any new polymorphism scheme must be a subclass of the AC, which is very limited for a single inheritance language such as Java and C. Experience: if there is a class hierarchy with abstract super Class C1, you can consider defining interface I1 corresponding to the common method feature mark in C1, and then declare C1 to implement interface i1.

Indirection)

Assign responsibilities to intermediary objects as media between other components or services to avoid direct coupling between them. The mediation implements indirection between other components ).

"Most Problems in computer science can be solved by adding an indirect layer", which is especially applicable to object-oriented design.

Pure Fabrication)

Assign a group of high cohesion responsibilities to human-created classes, which do not represent the concept of the problem domain-fictitious things, to support high cohesion, low coupling and reuse. Note: It is usually used as a helper or help class.

Protected Variation)

Identifies expected or unstable changes and assigns responsibilities to create a stable interface beyond these changes.

Fortunately, it will appear after planning. -Branch Rickey)

Part 5 refined iteration 3 intermediate topic

1. a uml activity diagram represents multiple sequential activities and parallel activities in a process. These activity diagrams help to model business processes, workflows, data streams, and complex algorithms.

Basic UML activity diagram representations include:

• Action-it completes some things. An automatic conversion exists when it is completed.
• Partition-indicates different participants in the process.
• Fork (fork)-one input conversion, and parallel conversion or object stream of multiple outputs.
• Join: Multiple Input transformations or object streams. One output transformation occurs only when all inputs arrive.
• Object node: the object generated or used by an action. This allows us to model data streams or object streams.
• Decision-any branch that is mutually exclusive.
• Merge-continuation of any input.

2. the following guidelines are provided for modeling an activity diagram:

• The activity diagram is usually valuable for business process modeling that involves a large number of participants. Use Case text is sufficient for simple business processes.
• During business process modeling, you can use the rake symbol and subactivity diagram.
• Related to the previous one is to keep the abstract level of all action nodes in the same graph consistent.

3. Same as the activity diagram, the UML state diagram is a dynamic view. UML contains the representation of events and states that can be used to describe transactions (transactions, use cases, and people. The state machine divisor (UML) diagram describes the state and events of an object and the actions of the object in response to the event. Transition is represented by an arrow that marks an event. State is represented by a rectangle of the rounded corner. Generally, an initial pseudo State is included. When an instance is created, it is automatically converted from the initial pseudo State to another State.

4. The status chart shows the lifecycle of an object: The events that the object has experienced, the conversion of the object, and the status of the object between these events. The status chart does not need to describe all possible events. If the event is not shown in the figure, it does not affect the content of the State Machine Chart.

5. Use Cases may be related to each other:

• Include link-some of the same behaviors exist in multiple use cases. Instead of repeating the text description, separate these interactions into separate sub-function use cases and use the include link to indicate them. Fowler provides a simple and practical guide on when to use the inclusion relationship: when there are duplicates in two or more independent use cases, and you want to avoid such redundancy, you can use the inclusion relationship.
• Extension relationship-create an extension or additional use case, and describe in it: where and under which conditions the use case extends the behavior of a basic use case.

6. The essence of Architecture Analysis is to identify factors that affect the architecture, understand the variability and priority of these factors, and solve these problems. The difficulty is to know what kinds of questions should be asked, weigh the advantages and disadvantages, and understand various methods to deal with an important architectural factor.

7. Architecture analysis is an activity that identifies and processes non-functional requirements of the system in the context of functional requirements.

Note: Read the examples in Chapter 36th and Chapter 37 in detail, and you will surely get a lot of results.

Example: NextGen POS

1. One of the requirements is that when remote service access fails (for example, when the product database (temporarily) cannot be accessed), it will be restored to some extent.

This feature can be indirectly achieved using the adapter and factory mode:

• ServiceFactory always returns the adapter of the local product information service.
• The local product "adapter" does not actually adapt to other components. It will implement local services on its own.
• Use the reference of the actual remote product service adapter to initialize the local service.
• If the local service finds data in the cache, the data is returned; otherwise, the request is forwarded to the external service.

Product Information Service initialization:

2. Use the local service through the proxy (GoF) for Fault Tolerance

By adding a local service to the front end of an external service, Local Service Fault Tolerance of product information is achieved. Local services are always given priority in use. However, this design scheme is not applicable to all services. Sometimes you need to first try the external service and then the local service. For example, record sales in the accounting service. In terms of business, we hope that this process will be faster and better, so that we can track store and terminal activities in real time.

In this case, the GoF Proxy mode can solve this problem. The Proxy used in the NextGen case is the Redirection Proxy variant, also known as the redundant Proxy (Failover Proxy ).

The proxy is only an object that implements the same interface as the proxy object. It stores the reference to the proxy object and is used to control access to the proxy object.

Part 6 Other topics

1. There are many ways to plan an iteration. Below is a typical method:

• The first step is to determine the iteration time length. The common time length is 2 ~ 6 weeks. Generally, it is better to be shorter. Factors that extend the iteration cycle include frequent discovery and changes in early work, large development teams, and distributed development. Once the iteration End Time is determined, it should not be changed-this is the practice of time quantification. However, the end time can be satisfied by reducing the scope of work of this iteration.
• The second step is to convene an iteration plan meeting. This is usually done when the previous iteration is completed (for example, Friday) and the next iteration (for example, Monday) is not started yet. Ideally, customers (marketing personnel, end users), developers, chief architects, and project managers should all be involved.
• List the potential objectives of this iteration (new features, use cases, defects, etc.), and mark the priority. The target list is usually determined by the customer (business goals) and the Chief Architect (technical goals.
• Each member of the team should prepare a personal voluntary budget (in the unit of disappearance or day) for this iteration, and all resource budgets should be summarized.
• A specific objective (such as a use case) is described in detail in the plan and its corresponding problems are decomposed. Then, participants (especially developers) will brainstorm on a group of more detailed tasks related to the goal and make rough estimates.
• Repeat the fifth step until enough work is identified: the total tasks in the iteration stage should match the total resource budget. The meeting can be closed if the workload is basically matched under the specified resource budget and Time Quantitative deadline.

2. One of the important ideas of iterative development is to continuously improve based on feedback, rather than trying to predict and plan the entire project in detail.