- Important points for this section:
- 1. Demand Analysis
- 2. Software architecture design
- 3. Software Design
- 4. Process management of software engineering (required)
- 5. Software testing and management (required)
- Six, four software integration technologies (required)
Important points for this section:
- demand analysis
- software test
- Software Quality Assurance and Evaluation
- software design
- Object-oriented and UML, etc.
- CMMI
1. Demand Analysis
1. Three levels
- Business requirements: reflect the customer's high-level target requirements for the system, usually from project investors, etc.; determine the project view and scope
- User needs: the specific goals of the user, the tasks that the user requires the system to complete
- System requirements: From a system perspective, including functional requirements, non-functional requirements, and design constraints
Including functional requirements, non-functional requirements, and design constraints
2. Quality Function Deployment
It is a technology that converts user requirements into software requirements, and its purpose is to maximize user satisfaction in software engineering. Divided into three categories:
- General requirements: the more users are realized, the more satisfied they are
- Desired needs: If not fulfilled, users will be dissatisfied
- Unexpected requirements: functionality or performance outside the scope of user requirements
3. Demand acquisition
Identify and understand the needs and constraints of different project stakeholders
4. Demand Analysis
It should have characteristics such as unambiguous, complete, consistent, testable, definite, traceable, correct, and necessary. Transform the messy user requirements and hopes into a user requirement specification.
5. Software Requirements Specification
(Software Requirement specification, SRS)
is the product of requirements development activities and one of the most important documents in the software development process. It should not be missing for software projects of any size and nature.
Should include the following:
- scope
- reference materials
- need
- eligibility requirements
- Requirements and Traceability
- unresolved issues
- annotation
- appendix
6. Requirements Verification
Mainly through requirements review and requirements testing to verify. In order to determine the following aspects:
- The SRS correctly describes the expected system behavior and characteristics that meet the needs of the project stakeholders
- Software requirements in the SRS are properly derived from system requirements, business specifications, and other sources
- Requirements are complete and high quality
- Representation of requirements is consistent everywhere
- Requirements provide an adequate basis for proceeding with system design, implementation, and testing
7. UML
The Unified Modeling Language (UML)
supports the whole process of software development starting from requirements analysis and
is independent of the development language. It is not a visual programming language, but a visual modeling language.
UML 2.0 includes 14 kinds of diagrams, which are listed as follows:
(1) Class diagram (class diagram): A class diagram describes a set of classes, interfaces, collaborations and the relationship between them. In the modeling of OO system, the most common diagram is the class diagram. Class diagrams give a static design view of the system, and class diagrams of activity classes give a static process view of the system.
(2) Object diagram (object diagram): An object diagram describes a set of objects and the relationship between them. Object diagrams describe static snapshots of instances of things created in class diagrams. Like class diagrams, these diagrams give a static design view or a static process view of the system, but they are built from the perspective of real or prototype cases.
(3) Component diagram (component diagram): The component diagram describes an encapsulated class and its interface, port, and internal structure composed of embedded components and connectors. Component diagrams are used to represent the static design implementation view of the system. Component diagrams are important for building large systems from small components. Component diagrams are a variant of class diagrams.
(4) Composite structure diagram: A composite structure diagram describes the internal structure of a structured class (eg, a component or class), including the points of interaction between the structured class and the rest of the system. Composite structure diagrams are used to draw the internal content of structured classes.
(5) Use case diagram (use case diagram): A use case diagram describes a set of use cases, participants and the relationship between them. A use case diagram gives a static use case view of the system. These diagrams are very important in organizing and modeling the behavior of the system.
(6) Sequence diagram (sequence diagram, also called sequence diagram): Sequence diagram is an interaction diagram (interaction diagram), which shows an interaction, which consists of a group of objects or participants and possible messages sent between them. message composition. Interaction diagrams focus on a dynamic view of the system. Sequence diagrams are interaction diagrams that emphasize the chronological order of messages.
(7) Communication diagram: Communication diagram is also a kind of interaction diagram, which emphasizes the organization of objects or participants who send and receive messages. The sequence diagram emphasizes timing, and the communication diagram emphasizes the organizational structure between objects.
(8) Timing diagram (timing diagram, also known as timing diagram): Timing diagram is also an interaction diagram, which emphasizes the actual time when messages span different objects or participants, not just the relative order of messages.
(9) State diagram (state diagram): A state diagram describes a state machine, which consists of states, transitions, events, and activities. A state diagram gives a dynamic view of an object. It is especially important for modeling the behavior of interfaces, classes, or collaborations, and its emphasis on object behavior resulting from events is very helpful for modeling reactive systems.
(10) Activity diagram (activity diagram): The activity diagram shows a process or other computing structure as a step-by-step control flow and data flow inside the calculation. Activity diagrams focus on the dynamic view of the system. It is especially important to the functional modeling and business process modeling of the system, and emphasizes the control process between objects.
(11) Deployment diagram (deployment diagram): The deployment diagram describes the configuration of the runtime processing nodes and the components that live in them. A deployment diagram gives a static deployment view of the architecture, usually a node contains one or more deployment diagrams.
(12) Artifact diagram: The artifact diagram describes the physical structure of a system in a computer. Artifacts include files, databases, and similar collections of physical bits. Artifact diagrams are often used together with deployment diagrams. Artifacts also give the classes and components that they implement.
(13) Package diagram: The package diagram describes the organizational units decomposed by the model itself, and the dependencies among them.
(14) Interaction overview diagram (interaction overview diagram): The interaction overview diagram is a mixture of activity diagrams and sequence diagrams.
Five Views of UML
| view | content | main user |
|---|---|---|
| logical view | Also known as the design view, it represents the architecturally significant parts of the design model, that is, a subset of classes, subsystems, packages, and use case realizations | Designers and Developers |
| process view | It is an execution instance of the logical view | Developers, System Integrators |
| Realize the view | Modeling based on the documentation and construction of the physical code of the system | Developer |
| deployment view | Deploys builds to a set of physical nodes, representing the software-to-hardware mapping and distribution structure | Developers, System Integrators, Testers |
| use case view | The most basic demand analysis model | demanders and users |
Mnemonic: progressive, practical
8. Object-Oriented Analysis
The basic task of OOA is to use OO methods to analyze and understand the problem domain, correctly understand the things in it and the relationship between them, find out the classes and objects needed to describe the problem domain and system functions, and define their attributes and responsibilities , and the various connections formed between them. Finally, an OOA model and its detailed description are produced that meet the needs of users and can directly reflect the problem domain and system functions.
The OOA model is independent of the specific implementation, that is, it does not consider the factors related to the specific implementation of the system, which is also the difference between OOA and OOD. The task of OOA is "what to do", while the task of OOD is "how to do it".
(1) Use-case model: The use-case approach is a requirement synthesis technique. In the OOA method, building a use case model generally needs to go through four stages, which are identifying participants, merging requirements to obtain use cases, refining use case descriptions and adjusting use case models, of which the first three stages are required.
The relationships between use cases mainly include inclusion, association, extension and generalization.
Inclusion relationship: For example, modifying, deleting, and viewing personal information all include finding personal information, because modification, deletion, and viewing are inclusion relationships. Extended relationship: For example, the system allows
users to export and print query results. Exporting, printing, and querying are relatively independent, and new behaviors are added to querying, so they can be described with extended relations.
Generalized relationship: There may be many things in the business that require approval by department leaders, such as salary approval and personnel approval. At this time, these approvals can be expressed as generalized relationships.
Description of use case relationship
Note: composition (non-separable) is tighter, aggregation (separable) is looser
main relationship between classes
(1) Association relationship. An association provides a structural relationship between objects of different classes, and it connects instances of multiple classes together over time. Associations reflect the relationship between object instances, not the relationship between two classes. The remaining relations concern descriptions of the classifiers themselves, not their instances. For the description of the relationship, you can use the relationship name, role, multiplicity and orientation to illustrate.
(2) Dependency. Two classes A and B, if a change in B may cause a change in A, then class A is said to depend on class B. Dependencies can arise for various reasons, for example, one class sends a message to another class, one class is a data member of another class, one class is a certain operation parameter of another class, etc.
(3) Generalization relationship. The generalization relationship describes the relationship between a general thing and a special category in that thing, that is, the relationship between a parent category and a child category. The inheritance relationship is the anti-relationship of the generalization relationship, that is, the subclass inherits the parent class, and the parent class is the generalization of the subclass.
(4) Shared aggregation. The shared aggregation relationship is usually referred to as the aggregation relationship for short, which represents the relationship between the whole and the part between classes, and its meaning is that a "part" may belong to multiple "wholes" at the same time. The life cycle of "part" and "whole" can be different. For example, a car and a wheel are an aggregation relationship. If the car is broken, the wheel can still be used; if the wheel is broken, it can be replaced with a new one.
(5) Combination aggregation. Composition-aggregation relationship is usually referred to as composition relationship for short, and it also represents the whole-part relationship between classes. The difference with the aggregation relationship is that the "part" in the composite relationship can only belong to one "whole" and the life cycle of the "whole" is the same. "Death and disappear. For example, a company contains multiple departments, and the relationship between them is a combination relationship. Once the company goes bankrupt, there will be no departments.
(6) Realize the relationship. A realization relationship links a specification with a realization. An interface is a description of behavior rather than an implementation, while a class contains the structure of the implementation. One or more classes can implement an interface, and each class implements the operations in the interface.
Supplementary knowledge points
Object-oriented basic concepts:
- Object: a package composed of data and its operations, a module used to describe objective things in the system, and the basic unit of the system. Consists of a set of properties and operations. Contains three basic elements, namely object identity, object state and object behavior.
- Class: A formal description of an entity in the real world, which encapsulates the entity's attributes (data) and operations (functions). The relationship between classes and objects can be understood as, an object is an instance of a class, and a class is a template for an object. If you compare an object to a house, then the class is the blueprint for the house.
- Abstraction: The process of forming concepts after extracting common features from specific examples. Abstraction is a simplistic description, emphasizing the characteristics related to the application and discarding irrelevant characteristics. An object is an abstraction of an entity in the real world, and a class is an abstraction of a group of objects.
- Encapsulation: Group related concepts into a unit module and refer to it by a name. Object-oriented encapsulation is to encapsulate data and data-based operations into an overall object, and access or modification of data can only be performed through the interface provided by the object.
- Inheritance: Represents the hierarchical relationship between classes (parent class and subclass). This relationship enables a certain type of object to inherit the characteristics of another type of object. Inheritance can be divided into single inheritance and multiple inheritance.
- Polymorphism: Allows the same operation or attribute name to be defined in multiple classes, and can have different implementations in each class
- Interface: Describes what an operation should do
- Message: reflects the interaction between objects, and requests operations by sending messages
- Component: Encapsulates the implementation of module functions, is cohesive, and has a relatively stable public interface
- Reuse: Use the effective components of existing software machines to construct new software or systems. Component technology is the key to the realization of software reuse
- Pattern: Describes a recurring problem, and a solution to that problem. It includes three components: specific environment, problem and solution. Applying design patterns can make it easier and more convenient to reuse successful software designs and architectures, thereby helping designers complete system designs faster and better.
2. Software architecture design
Software architecture provides a high-level abstraction of structure, behavior and attributes for software systems, and consists of component descriptions, component interactions (connectors), patterns guiding component integration, and constraints on these patterns. Software architecture not only specifies the organizational structure and topology of the system, but also shows the correspondence between system requirements and components, and provides some basic principles for design decisions.
The main content of software architecture research involves software architecture description, software architecture style, software architecture evaluation, and formal methods of software architecture. Solving the problems of software reuse, quality and maintenance is the fundamental purpose of studying software architecture.
Five software architectural styles
The core issue is whether software reuse at the architectural level can be achieved.
- Dataflow style: including batch sequences (sequential execution) and pipes/filters (input and output data flow)
- Call/return style: including main/subroutine, data abstraction and object orientation, and hierarchy
- Independent component style: including process communication (message passing, remote call) and event-driven (event-triggered call)
- Virtual machine style: including interpreter (interpretation engine) and rule-based (rule set)
- Warehouse style: database system (central shared data source), blackboard system (knowledge source, blackboard and shared data and control) and hypertext system (non-linear cross-reference)
3. Software Design
Divided into structured design (SD) and object-oriented design (OOD)
1. SD
The data flow-oriented method is based on documents such as DFD and data dictionary produced in the SRS and SA stages, and is a top-down, progressive refinement and modularization process. The basic idea of the SD method is to design the software as a structure composed of relatively independent modules with a single function, which is divided into two stages: outline design and detailed design.
In SD, a basic principle needs to be followed: high cohesion, low coupling
2. OOD
The main task is to design classes and objects, including class attributes, methods, and the relationship between classes. The result of OOD is the design model. For OOD, it is a crucial issue to improve software reusability while supporting maintainability. How to improve software maintainability and reusability at the same time is One of the core problems that OOD needs to solve.
3. Design Patterns
Design patterns include basic elements such as pattern names, problems, purposes, solutions, effects, example codes, and related design patterns.
Depending on the scope of processing, it can be divided into class mode (static relationship) and object mode (dynamic).
According to different purposes and uses, it can be divided into creation mode (creating objects), structural mode (processing classes or combinations of objects) and Behavioral patterns (describe the interaction and assignment of responsibilities of classes or objects)
4. Process management of software engineering (required)
CMMI --> Capability Maturity Model Integration Software Capability Maturity Integration Model is a process improvement method that provides basic elements for an organization's effective process, and its purpose is to help software companies manage and improve software engineering and enhance development and improvement capabilities , so that high-quality software can be developed on time and within budget.
CMMI inherits the stage representation of CMM and the continuous representation of EIS/IS731.
1. Continuous model
2. Staged Model
These two representations are logically equivalent, and the conclusions drawn should be the same.
The 5 stages of CMMI
Initial level
Repeatable level
Defined level
Managed level
Optimized level
5. Software testing and management (required)
1. Test method
Can be divided into static testing and dynamic testing
- Static testing: Do not run the program, but use manual detection and computer-aided static analysis to test the program. Using this method can effectively find 30%~70% of logic design and coding errors.
- Dynamic testing: actually run the program for software testing, generally using white box testing and black box testing methods.
1) White box testing: As a transparent box, fully understand the structure and processing of the program, and design test cases according to the internal logic.
2) Black box testing: also known as functional testing, through testing to detect whether each function can be used normally. The internal structure and internal characteristics of the program are not considered.
2. Test type
Divided into unit testing, integration testing, confirmation testing, system testing, configuration testing and regression testing.
- Unit testing: also called module testing, based on detailed software design instructions
- Integration test: Check the interface relationship between modules and between modules and integrated software, and verify whether the integrated software meets the design requirements. The technical basis is the software outline design document
- Confirmation test: Confirmation test is mainly used to verify whether the function, performance and other characteristics of the software are consistent with user requirements. Including the following types:
Internal confirmation test: internal testing by the software development organization in accordance with SRS
Alpha testing and Beta testing: Alpha testing refers to testing by users in the development environment; Beta testing refers to testing by users in the actual use environment, After the Beta test is passed, the product can be released or delivered to the user.
Acceptance test: refers to the user-centered test for SRS before delivery. The admission conditions should be met and the system test has been passed.
System test: In the real system working environment, verify whether the complete software configuration can be connected to the system correctly, and meet the requirements stipulated in the system/subsystem design documents and software development contract. The basis is user requirements or development contracts. The main content of system testing includes functional testing and robustness testing. Performance testing, user interface testing, security testing, installation and anti-installation testing.
Configuration item test: the purpose is to verify the consistency between software configuration items and SRS. Regression
test: the purpose is to test the correctness of the changed part and the compound type of the change requirements after the software is changed, as well as the original and correct functions, performance and functions of the software. The requirements of other regulations are not prejudiced.
Six, four software integration technologies (required)
Enterprise Application Integration: Enterprise Application Integration, EAI
Mnemonic: table number industry