System Architect study note _ Chapter 6 (ii) _ serialization

6.3 UML-based software development process

6.3.1 Development Process Overview

UML is independent of the software development process and can be used in almost any software development process. The iterative software development process consists of four stages: initial start, refinement, component, and deployment.

1. Initial launch

The project sponsor determines the main objectives and scope of the project, preliminary feasibility analysis and economic benefit analysis.

2. Refinement

The beginning of the Refinement phase marks the formal establishment of the project.

1. Initial Requirement Analysis: Important and risky use cases.

2. Preliminary high-level design: use cases, use case diagrams, classes, and class diagrams are classified into different packages based on the packet division method.

3. Part of the detailed design, according to the importance of software elements and risk level to establish the principle of priority refinement, risk identification and resolution cannot be delayed until the refinement stage.

4. prototype construction of some parts.

3. Build

In the construction phase, some use cases are implemented in each iteration. You can participate in the actual evaluation of the implemented use cases as soon as possible.

Principles:

1. Use cases that the user thinks are of great business value should be prioritized.

2. After evaluation, developers think that the case with high development risks is preferred.

In an iteration plan, determine the number of iterations, the time required for each iteration, And the use cases to be completed in each iteration.

6.3.2 UML-based Requirement Analysis

1. Generate Use Cases

If multiple users assume the same role, these users are represented by a single performer. If a user assumes multiple roles, multiple executors are required to represent the same user.

Use Cases mainly come from the classification and abstraction of scenarios by analysts. Similar scenarios are classified, so that a use case can cover multiple scenarios Through instantiation and parameter adjustment.

2. Use Case charts

3. Generate a use case diagram

There are two relationships between executors and use cases: trigger execution and information exchange.

The performer points to the use case to trigger execution and/or information exchange, and the use case to the performer to transmit the generated information to the performer.

4. Build a top-level architecture

The top-level architecture allows developers to focus on different parts of the system.

Model-View-Controller (Model, View, Controller, MVC) mode.

The model maintains and stores the data, and the view presents the data. The controller maps the action to the processing function and actually calls it.

The MVC mode is particularly suitable for distributed application software, especially web application systems.

Hierarchical mode reduces the Coupling Degree of software systems.

The following factors must be taken into account when establishing a top-level architecture:

The number of packages, architecture too early into the details, the possibility of rework is very high, but also unreasonably limit the free space for subsequent analysis and design activities.

Coupling between packages.

Software elements caused by instability are classified into a few packages to improve the maintainability of the software system.

The optional and required features are placed in different packages.

Based on the division of developers' expertise, each package can be allocated to the most appropriate developers, facilitating parallel development.

6.3.3 Object-Oriented Design Method

1. design case Implementation Scheme

1. Extract the boundary class and implement class and control class.

The boundary class is used to describe the interaction between the system and the external environment.
A. interface control.
B. external interface.
C. Environment isolation. Make the rest of the target software system as independent from the environment software as possible.

Boundary class, <boundary>.

The entity class "introverted convergence" feature provides only the necessary operations for reading/writing information as interfaces, and does not involve business logic processing. <entity>.

Control class, <control>.

The scope of the boundary class can go beyond a single use case.

2. Construct an interaction Diagram

The interaction diagram is used as a precise implementation solution.

The events in the event stream directly correspond to the messages in the interaction diagram. The order of the events is the sequence in the interaction diagram. The response to the Message constitutes the responsibility of the message receiver, this responsibility is defined as a class method.

Messages that pass through the control lifeline should not appear.

For ease of understanding, separated UML interaction diagrams should be used to represent the event stream and each alternative event stream.

In principle, each class should have an operation to respond to the message pointing to its object in the interaction diagram.

2. Design Technical Support Solutions

When user requirements change, the technical support solution should have good stability.

The Technical Support solution should be at a lower level in the hierarchy.

On the one hand, it depends on the demand, and on the software technical means to select me.

3. Design the user interface

1. Be familiar with users and classify them so as to take care of the reasonable requirements of all users as much as possible and give priority to certain privileged users.

2. analyze users' workflows and habits by user type, select a user representative from each type, and establish a questionnaire to determine users' requirements and preferences for the operation interface.

3. first, the order of commands should be considered. Generally, Common commands should first be consistent with the user's work habits. Second, the corresponding commands should be organized according to the aggregation relationship between external services; then, taking into full consideration the limitations of human memory, it is best to organize it into a two-layer multi-tree; Provide a shortcut for operation.

5. Use Quick prototype demonstration to improve the interface design. And judge whether the system is complete, convenient, and easy to use.

4. Refined Design Model

The model improvement activities can be divided into two types: Refinement and merging. Generally, it starts with refinement. A well-designed coarse-grained component should only provide one function, which is the main distinction between it and the subsystem.

Coarse-grained components have a wide range of scopes and are difficult to reuse. coarse-grained components have persistent behaviors and business logic, and must be supported by the presentation layer.

You can divide the requirement into several functional groups to obtain the corresponding coarse-grained components.

If the range is too small, coarse-grained components are not easy to use. You need to understand the complex relationships between different coarse-grained components.

If possible, defining individual associations between coarse-grained components can effectively reduce coupling between components.

Simplify the relationship between components as much as possible.

We need to identify key entities from the target field of the software, or terms in the field. Then decide which coarse-grained components they should belong.

There are repeated elements between the two components, from which the common parts can be extracted to form a new component.

6.4 docized System Architecture

6.4.1 model Overview

Assemble several structural elements in a carefully selected form.

Software Architecture = {elements, forms, relationships/constraints}

The logical view object model.
Process view concurrency and synchronization features.
The physical view is distributed.
Development view static organizational structure.
Scenario.
Rational 4.1 view model.

The Perry & Wolf Software Architecture formula is applied independently in each view.

Select a specific architectural style for each view ).

6.4.2 Logical Structure

The logical architecture mainly supports functional requirements. The system is decomposed into a series of key abstractions, most of which come from the problem domain and are represented in the form of objects or object classes.

Abstract, encapsulate, and inherit.

For applications with high data-driven levels, you can use other forms of logical views, such as E-R diagrams, instead of object-oriented methods.

1. Logic view Style

Using the object-oriented style, we try to maintain a single and consistent object model throughout the system.

6.4.3 process Architecture

The process architecture considers non-functional requirements, concurrency, distribution, system integrity, fault tolerance, and how the main abstraction of the logical view works with the process structure.

A process is a group of executable unit tasks.

Major secondary tasks: the primary task is the architectural element that can be processed uniquely, and the secondary task is a local additional task introduced for implementation reasons.

6.4.4 development architecture

The development architecture focuses on the organization of actual modules in the software development environment.

The development architecture is expressed in a module and subsystem diagram, showing the relationship between "output" and "input.

Considerations: Development difficulty, software management, reusability, versatility, restrictions imposed by tool sets and languages.

The development view is the basis for establishing a product line.

We recommend that you use a layered style with well-defined responsibilities for each layer. Subsystems of a certain layer depend on subsystems of the same layer or lower layer, minimizing the development of networks with complex module dependencies.

6.4.5 physical architecture

The physical architecture focuses on the non-functional requirements of the system, including availability, reliability (fault tolerance), performance (throughput), and scalability.

Software-to-node ing requires high flexibility and minimal impact on source code.

6.4.6 scenario

The elements of the four views work seamlessly in a group of important scenarios (more commonly, use cases) with a relatively small number of elements, we describe the corresponding scripts for the scenario (the interaction sequence between objects and processes ).

In a sense, a scenario is the most important abstract requirement.

4 + 1 + 1 plays two roles:

As a driver to discover architectural elements in the architectural design process.

As the starting point of architecture prototype testing.

The scenario representation is very similar to the component logic view, but it uses the connector of the process view to represent the interaction between objects.

6.4.7 iteration process

During docization, we advocate a more iterative method-architecture first prototyping, testing, estimation, and analysis, and then refined in a series of iterations.

In addition to reducing risks, there are also other advantages: Teamwork, training, deep understanding of the architecture, deep procedures and tools. Refined and mature requirements.

Most of the key functions of the system are captured in the form of scenarios. The key means: The most important functions, reasons for the existence of the system, the most frequently used functions, and some important technical risks that must be mitigated.