12.1 Structural Analysis and Design
DFD: Data Flow Diagram
12.1 .1 Requirements Description
12.1.2 Structural Analysis
End result: data flow diagrams, data dictionaries and processing descriptions.
12.1.3 Overall Design
Give the call relationship between modules after each processing in the data flow diagram is converted into modules.
12.1.4 Detailed Design
Detailed flowchart of each module
12.2 Database Analysis and Design
12.2.1 Strategies and procedures for database design
1. Strategy: top-down and bottom-up
2. Design steps:
(1) User needs analysis
(2) Conceptual design
(3) Logical design
(4) Physical design
12.2.2 Requirements Analysis
1. Tasks, goals and methods
of requirements analysis 2. Documents in the requirements analysis stage
Products of the requirements analysis stage: data flow diagram, data dictionary, and requirements specification.
12.2.3 Conceptual structure design
1. Conceptual structure design strategies and methods
Strategies: top-down, bottom-up, gradual expansion and mixed strategies.
Methodology: Entity-Relationship Diagram (ER Diagram)
2. Establish a conceptual model with the ER method
Conflicts in ER diagrams
12.2.4 Logic structure design
1. Conversion of ER diagram relationship mode
Principles of converting ER diagrams to relational models
1. Each entity type is converted to a relational model
2. Contacts are converted to relational models:
(1) There are two ways to convert one-to-one contacts.
Independent relational mode: Incorporate the primary keys at both ends and the attributes of the relationship itself. (Primary key: primary key at either end) Merge (either end): Merge the primary key at the other end and contact its own attributes. (Primary key: remain unchanged)
(2) There are two ways to convert one-to-many relationships. Independent relational mode: Incorporate the primary keys at both ends and the attributes of the relationship itself. (Primary key: multi-terminal primary key)
merge (multi-terminal): merge into the primary key of the other end and contact its own attributes. (Primary key: remain unchanged)
(3) There is only one way to convert the many-to-many relationship.
Independent relationship mode: incorporate the primary keys at both ends and the attributes of the relationship itself. (Primary key: composite key of primary keys at both ends)
2. Standardization of relational schema
(1) Determination of data dependence
(2) Determination of paradigm
(3) Decomposition of relational schema
(4) Evaluation and correction of relational schema
3. Determine integrity constraints
Entity integrity: It is stipulated that its main attribute cannot be null.
Referential integrity (also known as referential integrity): It is stipulated that its foreign key is the primary key value of the reference table or a null value.
User-defined integrity: Refers to the user's constraints on a specific relational database, reflecting the
requirements that the data involved in a specific application must meet. It is determined by the application environment. For example, age is defined as a
positive integer ranging from 0 to 150 .
Trigger: A complex integrity constraint.
4. Determination of user view
12.2.5 Physical Design of the Database
1. Determine the data distribution
2. Determine the data storage structure
3. Determine the data access method
12.2.6 Database implementation and maintenance
1. Database implementation
1) Establish the actual database structure
Structure, database schema, integrity description, security description, physical storage parameter description
2) Data loading
Manual input, using data conversion tools
3) Trial operation and evaluation of the database
2. Database maintenance
(1) Performance monitoring and improvement
(2) Database backup and failure recovery
(3) Database reorganization and reconstruction
12.3 Object-Oriented Analysis and Design
12.3.1 Steps in Object-Oriented Analysis and Design
(1) Modeling system functions
(2) Define domain model
(3) Define interaction, behavior and state
(4) Define design class diagram
12.3.2 Requirements Description
12.3.3 Modeling Use Cases
12.3.4 Modeling activities
Use use case diagram:
relationship between use cases:
inclusion relationship : the extracted public use case is called abstract use case, and the original use case is called basic use case or basic use case: when it can be extracted from two or more use cases When public behaviors are used, they should be expressed using containment relationships.
Extended relationship : If a use case obviously mixes two or more different scenarios, that is, multiple branches may occur according to the situation, this use case can be divided into a basic use case and one or more extended use cases, so that the description Could be more clear.
Generalization relationship : When multiple use cases share a similar structure and behavior, their commonality can be abstracted as a parent use case, and other use cases can be used as sub-use cases in the generalization relationship. In the generalization relationship of use cases, the sub-use case is a special form of the parent use case, and the sub-use case inherits all the structures, behaviors and relationships of the parent use case.
12.3.5 Design Class Diagram
Class Diagram: A class diagram describes a set of classes, interfaces, collaborations, and the relationships between them. In
modeling OO systems, 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.
12.3.6 Modeled object state
An object's state represents the condition of an object at a certain point in its life, and events that modify one or more values of properties cause the object's state to change.
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.
12.3.7 Modeling interactions
Sequence diagram (sequence diagram, sequence diagram). A sequence diagram is an interaction
diagram that shows an interaction consisting of a set of objects or actors and the messages that may be sent between them. Interaction diagrams focus on a dynamic view of the system. Sequence diagrams are interaction diagrams that emphasize the chronological order of messages.
12.4 Algorithm Analysis and Design
12.4.1 C Programming Language and Implementation
[This module note is meaningless, you still have to learn from the code. 】
1. Pointer type
2. Pointer and data structure
12.4.2 Algorithm Design and Implementation
A common measure of the time required for algorithm execution :
O(1)<O(log2n)<O(n)<O(nlog2n)<O(n2)<O(n3)<O(2n)
Sorting Algorithm
12.5 Object-Oriented Programming and Implementation
This knowledge point is usually the last question in the afternoon exam. Fill in the code according to the design pattern, pay attention to the context, grammar, etc. Generally, people with some code foundation will not have much problem.
For answering methods, please refer to my article: Case analysis and question-making skills