System Architect study note _ Chapter 2 _ serialization

Chapter 2 ODP-based architect practices

14.1 ODP-based architecture development process

The system architecture reflects the distribution of functions in system components, infrastructure-related technologies, and architecture design patterns. It includes the principles and methods of the architecture, component relationships and constraints, it also supports superposition or incremental development.

The software architecture-centric development process is quality and risk-driven, and ultimately provides a stable and low-risk system architecture that meets customers' needs (including potential needs ).

The Reference Model (RM-ODP) of the Open Distributed Process is an ISO standard which defines the important properties of the distributed system:

Openness, integrity, flexibility, plasticity, union, operable management, high-quality services, security, and transparency.

5 points of view defined by RM-ODP:

1. enterprise perspective: business needs and strategies, scope and purpose of the system. It may affect enterprise-related information in the system, such as the organizational structure.

2. Information viewpoint.

3. compute the viewpoint.

4. engineering viewpoint.

5. technical point of view.

Each view has specific modeling objectives and system stakeholders.

The layered subsystem view provides a highly abstract view of all subsystems.

14.2 System Conception

14.2.1 definition of System Conception

The system concept is a common protocol between developers and users.

According to this protocol, developers need to complete the requirements of system users within a specific period of time, and the system concept must be short and important.

The core content of the Business architecture is highly summarized.

14.2.2 role of Architect

The concept of a system helps parties understand the goals and scope of the system.

Ensure that the planning and design phases of system development can be carried out in sequence.

In the system conception phase, architects can reasonably intervene in the following benefits:

1. It is helpful for the System Architect to have a more comprehensive and accurate view of the system.

2. Unify the system developers' views on the system.

3. correctly determine the priority of requirements.

4. Improve the customer's participation in the design process to the greatest extent, and better communicate with the customer.

14.2.3 challenges to System Conception

Architects are usually powerless on factors beyond their control capabilities, and these difficulties can be overcome through effective evaluation and close connections between senior managers and architects.

You must also deal with the following situations:

1. Many architects regard the architecture as their own creation and modify it as long as they think it is appropriate.

2. Some people are not senior managers with product line ideas, but they always decide who to hire as architects.

14.3 Requirement Analysis

14.3.1 architect's work

Requirements generally define the external behaviors, appearances, and user information of the system, instead of designing the internal structure of the system.

Requirements Analysis usually involves the following six aspects:

1. system scope object relationship diagram.

2. User Interface prototype: A Prototype of user operations.

3. The applicability of the requirement, the technical solution to be used, the performance, and whether the requirements overlap or conflict with other requirements. The demand analysis should pay attention to the practicality or applicability of the requirements, rather than the implementation.

4. determine the priority of the requirement.

5. Create a functional structure model, component diagram, and object diagram for the requirement.

6. Use Quality Function Deploymen (QFD) to discover hidden Quality requirements, establish relevant Quality scenarios, and predict demand risks in advance.

The effective method to capture behavior requirements is to analyze Use cases)

Use Cases include graphs and text descriptions. The symbols are simple and abstract, ensuring the simplicity and clarity of presentation requirements.

14.3.2 requirement analysis task

1. Purpose of Requirement Analysis

A complete and accurate description of the user's requirements for the system, tracking the changes in user requirements, and accurately reflecting the system architecture and design. The design is consistent with the user's requirements.

It has the role of decision-making, directionality, and strategy.

2. Requirements Analysis features

The pursuit of system requirement integrity, consistency, validation.

Keep in sync with user requirements,

Maintain consistency between different aspects of the requirement analysis,

Maintain synchronization between requirements and system design.

14.3.3 Requirement documents and architecture

Each use case has a text description of the relevant requirements. The definition use case should be carried out with the domain experts. Without the long-term participation of the domain experts, it can only be a "pseudo analysis ".

Use Cases provide a systematic domain behavior model for the definition architecture.

The appearance, functions, and navigation of the interface are closely linked with the use case. The effective method for defining the screen is Low-fidelity Prototyping, and field experts are always involved in screen definition.

The project vocabulary for requirement analysis will also be expanded in the architecture planning.

14.4 System Architecture Design

The system architecture communicates a huge semantic gap between requirements and software.

The first task of system architecture is to define the ing between these two extremes.

Open Distributed Processing (ODP) includes enterprise, logical information, computing interfaces, Distributed engineering, and technical options.

For each view, it is important to confirm the consistency of architecture requirements.

14.4.1 Enterprise Business Architecture

From the IT perspective, the Enterprise Business Architecture sorts out and defines the enterprise business structure, enterprise organization, business relationship, internal relationship, and external organization relationship.

Includes the following content:

1. Business and strategic objectives of the enterprise, including the short-term, medium-term, and long-term goals.

2. Organizational structure of an enterprise.

3. Business Classification.

4. Relationships between various businesses.

5. Relationship between the organization and business.

6. Relationship between the enterprise and external organizations.

These business object models identify critical system constraints, including system objectives and important system policies.

The policy contains three types of explicit expressions:

Responsibility: what the business object must do.

License: What can a Business Object do.

Prohibited: Business Objects cannot do anything.

When analyzing business problems, you must consider the development of your business, such as the launch of new services or products, and the change of your organization.

All these possible changes (easy-to-change scenarios) should be presented to the Enterprise Business architecture.

By defining the business architecture of an enterprise, clearly understand the natural chunks and the boundary relationship between each chunks of the IT system due to the business characteristics, business process characteristics, and organization of the enterprise.

Maintenance of Enterprise Business architecture is a long-term and repetitive task.

Test Results Reporting System (TRRS ).

Object Constraint Language (OCL) is used to define these policies (such as permission, prohibition, and obligation) of Enterprise activists ).

14.4.2 Logical Information Architecture

The logical information architecture (Information viewpoint) identifies what the system must know.

Emphasize the attributes that define the system status.

Open Distributed Processing is an object-oriented method. The model contains key information processing, such as traditional Object concepts.

The software architecture object is not a programming object, it represents the constraints and dependencies on the system, these constraints can eliminate the need to translate into a lot of speculative work in the software process.

Architects should focus their modeling on key aspects with high risks, high complexity, and ambiguity.

14.4.3 computing Interface Architecture

The computing interface is very helpful to the system architecture, but it is often ignored by architects.

Eliminate major design disputes between developers and groups. The architecture control of these interfaces is very important for a stable system structure that supports change and control complexity.

The Interface Definition Language (IDL) is completely independent of the programming language and operating system.

14.4.4 distributed engineering Architecture

The Distributed Engineering Architecture defines the requirements of the underlying structure. It is independent of the selected technology and solves the most complex system policies, including physical location, system scale variability, and communication service quality.

One of the biggest advantages of ODP is separation of concerns.

14.4.5 Technical Selection Architecture

Most architectures are independent.

Based on the initial selection of candidates, project factors such as product prices, training requirements, and maintenance risks are repeated.

14.5 Implementation Model

End users and architects should review and use cases together to verify the effectiveness of requirements.

Accurately evaluates and demonstrates the feasibility of product design.

14.6 architecture prototype

Architecture prototype is a good requirement verification tool. It is used as a means to improve the design and ensure that it is consistent with engineering constraints.

The following are some questions that architects can ask in the architecture prototype:

1. are the main components well defined? Is it appropriate?

2. Is the collaboration between main components well defined?

3. Is coupling always satisfactory?

4. can we determine the potential sources of reuse?

5. Are interface definitions and constraints acceptable?

6. Can each module access the required data?

After two or three iterations, the architecture becomes stable. The main abstract objects have been found, subsystems and processes have been completed, and all interfaces have been clearly defined.

The architecture prototype has the following advantages:

1. Allow team members to express their opinions freely before implementation.

2. unify ideas and opinions between teams to improve the success rate of system development.

3. The system's internal structure analysis and design are also helpful.

14.7 Project Planning

Project planning is to track and control projects, action plans and resource allocation based on approved formal documents, and guide project implementation.

The primary role is to save the assumptions for the specified plan and the baseline that determines the approval scope, cost, and progress with formal document records.

Estimation is the core of project planning.

As the project progresses, estimates are constantly corrected and gradually approaching the reality.

The Project Manager constantly optimizes and updates the planning policies based on the differences between the planning and planning, so that the project can be implemented according to the planning requirements. The planned changes are manageable and controllable.

The plan includes:

1. the purpose, scope, goal, and object of the project.

2. software life cycle selection.

3. Selected procedures, methods, and standards.

4. Software work products to be developed.

5. Scale Estimation, software project workload and cost estimation.

6. Estimation of key computer resources and milestones of the project.

7. risk identification and evaluation.

8. project implementation and support tool plan.

The goals of the software project plan are: Software estimates are documented, activities and agreements form documents, and the affected groups and individuals agree with the software project plan.

14.8 Concurrent Development

14.8.1 content and significance of concurrent Software Development

Improve software productivity, improve software quality, and effectively organize reusable resources.

The main contents of parallel development research are as follows:

1. Software Process and model.

2. Parallel division.

3. Parallel Control.

4. supported environments.

5. Interaction Mechanism and integration technology.

14.8.2 parallel development process

The development process of the software system is divided into several parallel components, which are called subdevelopment processes.

Sub-development process = Development Team + software object + development activities on software objects.

A parallel development activity is called a parallel development system. An entity is a development group. An entity attribute is a software object to be developed, and a behavior is an activity to develop software objects.

Division of behavior modules is the core issue in parallel development, and module independence is the key to measuring the quality of software design.

System division method:

1. Dynamic Partitioning Method Based on the Petri net system model.

2. script-based system partitioning method.

Parallel Control of software processes is a very important issue.

It is to use the correct method to schedule parallel operations to avoid inconsistency, so that the execution of an operation is not affected by other systems.

Consistency, compatibility, correctness, and reliability are ensured. Locking, timestamps, processes, Petri Net, and PV operations are supported.

Inheritance and testing are divided into two phases. If the integration of hardware or software is not considered, there is no obvious boundary between the two phases. Therefore, the main problem of software integration is the integration test technology.

14.9 System Conversion

System Conversion refers to the process of replacing the old system with a new system, that is, the transformation of system equipment, data, and personnel.

14.9.1 prepare for System Conversion

Be prepared carefully before conversion.

Test Run is also required.

Note the following two problems:

1. Representative of the system trial run.

2. Correction of Errors During system trial run.

14.9.2 System Conversion Method

Direct conversion, parallel conversion, segmented conversion, and batch conversion.

14.9.3 precautions for System Conversion

1. If a large amount of basic data is input and the input workload is heavy, it should be prepared as soon as possible.

2. Personnel training should be completed in advance.

3. Some local problems should be well prepared and recorded. If a fatal problem occurs, design it again.

14.10 Operations and Maintenance

14.10.1 operation and maintenance content

Data management and maintenance.

Device management and maintenance.

Software management and maintenance.

14.10.2 system maintenance and architecture

The system architecture is good or bad, and maintainability is an important aspect. Maintenance personnel should participate in the architecture review.

Maintainability can be defined as the difficulty level for maintenance personnel to understand, correct, modify, and improve.

Maintainability has the following evaluation indicators:

Understandable.

Testability.

It can be modified.

System maintenance can be divided into the following four types:

Corrective maintenance.

Adaptive maintenance.

Excellent maintenance.

Preventive Maintenance.

The maintenance personnel must first understand the system to be maintained, and then establish a maintenance solution.

Since a modification may affect other module programs, it is important to consider the impact scope and the ripple size of the modification.

It must be emphasized that maintenance is for the entire system and all documents involved must be modified at the same time.

14.11 system Transplantation

14.11.1 system porting

Do not modify the existing software.

Modify the software.

Re-compile the software.

14.11.2 division of the working phase of system Transplantation

Planning phase.

Prepare the materials required for conversion.

Conversion phase.

Test phase.

Verification phase.

Standardize system transplantation and automate tools.

14.11.3 system migration tool

Serialization, standardization, and docization allow anyone to work in the same order to improve efficiency.