System Analyst High Frequency Mistakes Set 1

Requirements Engineering---Requirements Classification:

Quality Function Deployment (QFD) is a technique for translating customer requirements into software technical requirements. The purpose of QFD is to maximize customer satisfaction from the software engineering process. To this end, QFD identifies three categories of needs:

1. regular demand
2. Desired requirements: Those implicit in a product or system, perhaps so fundamental that users do not explicitly state them.
3. unexpected demand

Requirements Engineering --- Overview of Requirements Engineering

Requirements development can be divided into four stages: situation acquisition, analysis, and specification writing and review. These items include all activities such as requirements gathering, evaluation, and document writing in software products. Requirements development activities include the following aspects:

1. Identify the desired user categories for the product
2. Get the requirements for each user class
3. Understand actual user tasks and goals and the business needs supported by those tasks
4. Analyze user-derived information to differentiate user task requirements, functional requirements, business rules, instruction attributes, suggested solutions, and attachment information
5. Divide system-level requirements into subsystems and assign some of the requirements to software components
6. Understand the importance of relevant quality attributes
7. Discuss implementation priorities
8. Write collected user requirements into documents and models

Requirements Analysis --- Requirements Classification:

Software requirements include three different levels: business requirements, user requirements and functional requirements.

1. Business requirements reflect the organization's or customers' high-level purpose requirements for the system and product, and they are described in the project view and scope documents.
2. User requirements describe the tasks that users must complete to use the product, which is described in use case documents or scenario script descriptions.
3. Functional requirements define the software functions that developers must implement to enable users to complete their tasks, thus satisfying business needs.

Analysis: "Users can effectively correct spelling errors in documents" is a business requirement, because the cover of the product box may indicate that this is a spell checker that meets the requirements;

"Finds misspellings in a document and optionally replaces the misspelled word with a provided list of replacements". is the user's needs;

"The spelling checker also has many functional requirements, such as the operation of finding and highlighting wrong words" is a functional requirement.

Requirements Engineering---UML

UML uses five system views to describe the organizational structure of the system, including the components of the system decomposition, as well as their associations, interaction mechanisms and guiding principles, etc. to provide information for system design.

1. The use case view is the most basic requirement analysis model.
2. The logical view represents the architecturally significant parts of the reference model, namely subsets of classes, subsystems, packages, and use case realizations.
3. The process view is the modeling of executable threads and processes as active classes.
4. The implementation view models the files that make up the system-based physical code.
5. The deployment view deploys components to a set of physical nodes, representing the software-to-hardware mapping and distribution structure

Requirements Engineering --- Requirements Analysis

The basic task of the system analysis stage is that system analysis is based on fully understanding the needs of users, and expressing the understanding of the system to be built by both parties as a system requirement specification.

Requirement pattern---UML

Command mode (Command) is a behavioral mode of objects, similar to the callback mechanism in the traditional programming method, it encapsulates a request as an object, so that different requests can be used to parameterize the client; request queuing Or record request logs, and support undoable operations. The encapsulation of commands by the command mode separates the responsibility of issuing commands from the responsibility of executing commands, and delegates them to different objects, so as to realize the complete decoupling of sender and receiver, and provide greater flexibility and scalability.

The structure of the Command mode is shown in the figure below

in:

Class Command declares the interface for performing operations;

ConcreteCommand binds a receiver object to an action, and calls the corresponding operation of the receiver to implement the execute method

Class Client creates a ConcreteCommand object and sets its receiver;

Class invoke asks Command to execute this request;

The class Receiver knows how to implement the operations associated with performing a request, and any class may act as a receiver.

In the example of "a la carte", the order is the binding between the chef (Cook) and the action (processing according to the order). The chef accepts the order and is responsible for it. So in this example, the class corresponding to the Command class is "Order", and the class corresponding to Receiver is "Cook"

Requirements Engineering---Requirements Classification:

Basic knowledge of system performance evaluation: After the application system has been running for a period of time, some performance problems usually occur, and it is necessary to consider adjusting the system performance. If the performance of some aspects is not fully considered during the system development design and development phase (for example: the number of concurrent users greatly increases the performance); The performance of the system may be greatly reduced; after a period of operation, a lot of operating data has been accumulated, and the bottleneck of the system performance has been analyzed. These factors are the reasons for adjusting the system performance.

When the user's functional requirements change, it is often necessary to perform comprehensive maintenance on the system instead of adjusting the performance of the system.

Transactions in UML are also referred to as modeling elements, including structural things, behavioral transactions, behavioral things, grouping things, and annotational things. These transactions are the most basic in UML models OO building blocks.

1. Structural transactions: Structural transactions are the static part of the model, representing conceptual or physical elements. UML has seven kinds of structural affairs, which are class, interface, collaboration, user, activity class, component and node.
2. A class is a collection of objects that describe the same attributes, methods, relationships, and semantics, and a class implements one or more interfaces;
3. Interface refers to a set of operations that a class or component provides a specific service, and the interface describes the externally visible actions of the class or component;
4. Collaboration defines the operation of interaction, some characters and other things work together to provide some cooperative actions, which are greater than the sum of things;
5. A user is a description of a sequence of actions that produces a valuable result. Use cases are often used to organize behavioral things in a model.
6. Use cases are realized through collaboration;
7. Objects of the Activity class have one or more processes or threads. The activity class is very similar to the class, except that the behavior of the thing represented by its object and other things exist at the same time;
8. A component is a physical or replaceable part of a system that implements a set of interfaces;
9. A node is a physical element that exists at runtime and represents a computational resource, usually occupying some memory and having processing power.
10. A collection of components is generally located at a node, but may be transferred from one node to another;

Behavioral Thing: Behavioral Thing is a dynamic part in a UML model that represents actions in time and space. There are two main behavioral things in UML.

1. The first is interaction (internal activity): interaction is an action consisting of a series of message exchanges between a group of objects in a specific context to achieve a specific purpose. The objects that make up the actions in the interaction must be listed in detail for each operation, including messages, action sequences (actions generated by messages), and connections (connections between objects);
2. The second is a state machine: a state machine consists of a series of object states

Grouping things: Grouping things are organized parts of a UML model. They can be thought of as boxes in which the model can be decomposed. UNL has only one type of group transaction, called a package. Packages are a mechanism for grouping organized elements. Different from components, packages are purely a conceptual thing that only exists in the development phase, while components can exist in the running phase of the system.

Annotation things: Annotation things are annotation parts of UML models;

Requirements Engineering---Requirements Analysis:

Understanding and mastery of the modeling tool of business flow chart:

Business Flow Diagram (TFD) is a graphical representation of business process survey results, which reflects the business processing process of each department in the existing system and the division of labor and connection between them, as well as the transfer and flow relationship of the information flow connecting each department, reflecting the current situation. There are system boundaries, environments, inputs, outputs, and data storage.

Requirements Engineering---UML

Dependency (Dependency) Dependency is a semantic relationship between two things, where a change in one thing will affect the semantics of the other thing.

From the essence of UML thing relationship, containment relationship and extension relationship belong to dependency relationship. For the containment relationship, the event flow in the abstract use case must be inserted into the basic use case, and there is only one insertion point.

The event flow of the extended use case can often be abstracted as an alternative event flow of the basic use case. In the extended relationship, it can be decided whether to insert the event flow of the extended use case into the event flow of the basic use case according to certain conditions, and the insertion point can have Multiple. In practical applications, the generalization relationship is rarely used, and the special behavior of the sub-use case can exist as an alternative event flow in the parent use case.

The process view models executable threads and processes as active classes, and describes concurrency and synchronization structures. Activity diagrams in UML can be used to express process views

Operating system---segment page storage

In a high-level language program, the location of the stored data is abstracted, and the virtual address is used. Address conversion is performed when the program is running, which is divided into internal address conversion and external address conversion. The virtual storage system converts the virtual address into the physical address of the main memory according to the address mapping method, which is called internal address translation. If the instruction or data to be accessed is already in the main memory, hit it and directly access it. Otherwise, a page failure occurs. At this time, the external address conversion is performed, that is, the virtual address is converted into the physical address of the auxiliary storage.

System Design---Processing Process Design

BPR-based information system planning must break through the limitations of the current functional management model, starting from the value chain of suppliers, enterprises, and customers, determine the long-term goals of enterprise informatization, and choose the core business process as the breakthrough point for implementation. On the basis of innovation and standardization, carry out information system planning. The main steps of BPR-based information system planning are as follows:

1. Strategic planning: mainly to clarify the strategic goals of the enterprise, recognize the development direction of the enterprise, and understand the operating mode of the enterprise; investigate the business process, determine the success factors for the successful implementation of the enterprise strategy, and define the business process on this basis and formulate the information system Strategic planning, which aligns information system objectives with enterprise objectives, and provides strategic guidance for business process implementation.
2. Process planning: Business process planning is the basis of data planning and function planning. The main task is to select core business processes, conduct process analysis to identify key business processes and business processes that need to be improved, and draw an improved business flow chart.
3. Data planning: On the basis of business process planning, identify the data generated, controlled and used by the process, and classify the data accordingly; first define the data class, and then plan the data, and divide the data into historical data according to the length of time Data, annual report data, quarterly data, monthly data, daily data, etc.; according to whether the data is shared, it can be divided into shared data and internal dedicated data; according to the use of data, it can be divided into system data u, basic data and comprehensive data, etc.;
4. Function planning: On the basis of understanding the data class and business process, the CU matrix of data class and process can be established, their relationship can be synthesized, and the subsystem can be identified through the CU matrix to further plan the overall logical structure of the system, namely Functional planning, identifying functional modules.
5. Implementation planning: This phase includes two activities, namely determining the system development sequence and formulating the project development plan. Under the current limited resource situation of the enterprise, it is necessary to determine the priority of the development of various information systems to ensure that the most critical information systems can be developed first. At the same time, it is necessary to formulate plans for the development of various information systems to ensure that the information system strategy can be implemented in an orderly manner.

System Design --- Design Patterns

1. Adapter mode (Adapter): The adapter mode converts one interface into another interface that the client wants, so that those classes with incompatible interfaces can work together. The Adapter pattern can be used both as a class-structural pattern and as an object-structural pattern. In the adapter pattern, the adapter is adapted to the target interface by using a concrete class; in the object adapter pattern, an adapter can adapt multiple different adapters to the same target;
2. Decorator mode (Decorator): Decorator mode is an object structural mode that can dynamically add some additional responsibilities to an object. In terms of adding object functions, the decoration mode is more flexible than generating subclasses. Through the decoration mode, you can add responsibilities to a single object in a dynamic and transparent manner without affecting other objects; when you need to dynamically add functions to an object, you can use the decoration mode when these functions can be revoked dynamically; when The decorator pattern can also be used when extending by subclassing is not possible.
3. Proxy mode (Proxy): The proxy mode is an object structural model that can provide a proxy for an object, and the proxy object controls the reference to the original object. The proxy mode can coordinate the caller and the callee, and can reduce the coupling of the system to a certain extent. The disadvantage is that the processing speed of the request will be slower, and the implementation of the proxy mode requires additional work.

System Design --- Design Patterns

Parsing the sentence "In order to save memory space, it is required that the same files with the same attributes (for example: the same type, extension, and icon) cannot be regarded as different objects" means: the same files with the same attributes, even if they exist Different directories should be treated as one object. That is, an object is created to be shared and used in multiple places, so the Flyweight mode is used

System Design --- Design Patterns

1. Find the keyword of the pattern from the graph. If found, the probability of this pattern is high (70%). There are many patterns, and their UML diagrams are exactly the same, but they are used in different scenarios and have different purposes. At this time, it is impossible to judge if the pattern is not marked.
2. It is necessary to make a horizontal comparison from the options, so we need to analyze the main characteristics of each mode in the options? In this question, the visitor has appeared in the picture, and at the same time, the standard function accept in the visitor mode appears, so the visitor has the highest probability.

1. 1. stragegy mode: strategy mode, mainly to facilitate the selection and change of strategies;
   2. Observer mode: mainly to establish an observation relationship, once the observed person changes, quickly notify the observer for linkage processing
   3. State mode: mainly focus on state changes, which do not conform to the expression in the figure