Data Flow Diagram in UML, use case diagram, class diagram, object diagram, role diagram, activity diagram, and sequence diagram

Class diagram, object diagram, role diagram:

I. Basic Graph categories in UML:

In UML 2, there are two basic graph categories: structure diagram and behavior diagram. Each UML diagram belongs to the two diagrams. The purpose of the structure diagram is to display the static structure of the modeling system. They include classes, components, and (or) object graphs. On the other hand, the behavior chart shows the dynamic behavior of objects in the system, including object methods, collaboration, and activities. An instance of a behavior diagram is an activity diagram, with an example diagram and a sequence diagram.

 

Ii. Class Diagrams in UML:

1. Class Diagram representation:

Class UML represents a rectangle, vertically divided into three areas, 1 shows. The class name is displayed in the top area. The middle area lists the attributes of the class. The bottom area lists the operations of the class. When you draw a class Element on a class chart, you must have a top area, the following two regions are optional (when the figure description is only used to show the high-level details of the relationship between classifiers, the following two regions are unnecessary ).

Description:

The class name is displayed in the top area. The middle area lists the attributes of the class. The bottom area lists the operations of the class. When you draw a class Element on a class chart, you must have a top area, the following two regions are optional (when the figure description is only used to show the high-level details of the relationship between classifiers, the following two regions are unnecessary ).

· Class Name: if it is an abstract class, italic words are used.

· Class attribute list:Name: attribute type For example, flightNumber: Integer, which is the most common expression

NAme: attribute type = default valueFor example Balance: Dollars = 0, which is an expression with a default value

· Class method list:Name (parameter list): type of value returned

Note:

In the business class diagram, the attribute type is usually consistent with the Unit, which may be meaningful to the readers of the diagram (for example, minute, dollar, and so on ). However, the class diagram used to generate Code requires that the class attribute types must be limited to the types provided by the program language, or included in the types of models implemented in the system.

2. inherited representation:

In order to model and inherit on a class chart, a closed, single-key (or triangular) solid line is pulled from the subclass (class to inherit behavior) and directed to the superclass.

The class name BankAccount and withdrawal operations use italics. This indicates that the BankAccount class is an abstract class, And the withdrawal method is an abstract operation. In other words, the BankAccount class uses withdrawal to specify abstract operations, and both the CheckingAccount and SavingsAccount sub-classes perform operations of their respective versions.

3. Interface representation:

A class is different from an interface: A class can have real instances of its form. However, an interface must have at least one class to implement it. In UML 2, an interface is considered as a special element of class modeling. Therefore, the interface is drawn like a class, but the top area of the rectangle also has the text "interface ".

Note: inheritance is represented by solid lines with arrows or triangles, and is represented by dotted lines with arrows or triangles.

4. Visibility:

In the object-oriented design, there is a mark for attributes and operation visibility. UML recognizes four types of visibility: public, protected, private, and package.

The UML specification does not require that attributes and operation visibility be displayed on the class diagram, but it requires that visibility be defined for each attribute and operation. To display visibility on a class chart, place the visibility sign before the name of an attribute or operation. Although UML specifies four visibility types, the actual programming language may increase additional visibility or do not support UML-defined visibility. Table 4 shows different visibility types supported by UML.

UML-supported visibility type flag

Flag	Visibility type
+	Public
#	Proteted
-	Private
~	Package

5. Associated representation:

·Bidirectional (standard) Association

An association is a join between two classes. Associations are always assumed to be two-way; this means that the two classes know the relationship between them unless you limit some other types of associations.

A bidirectional Association is represented by a solid line between two classes. At any end of the line, you place a role name and multiple values. Figure 6 shows that Flight is associated with a specific Plane, and the Flight class knows this association. Because the role name is represented by the Plane class, Plane assumes the "assignedPlane" role in the association. The multi-value description 0 following the Plane class... 1 indicates that when a Flight object exists, there can be one or no Plane associated with it (that is, Plane may not be allocated ). Figure 6 also shows that Plane knows its association with the Flight class. In this association, Flight assumes the "assignedFlights" role. The figure in Figure 6 shows that Plane entities can not be associated with flight (for example, it is a brand new aircraft) or associated with an unlimited flight (for example, an airplane that has been in service for 5 years.

Note: The associated object is located at the top of the straight line, the number of associated objects is located at the bottom of the same-side line, and the other is opposite. 

 

Multiple values and their representation

Possible multi-value descriptions
Indicates	Description
0 .. 1	0 or 1
1	Only one
0 ..*	0 or more
*	0 or more
1 ..*	One or more
3	Only three
0 .. 5	0 to 5
5. 15	5 to 15

· Unidirectional Association

In a one-way Association, two classes are related, but only one class knows the existence of this association.

A unidirectional Association is a solid line with an open arrow pointing to a known class (an unclosed arrow or triangle for flag inheritance. As with standard associations, one-way associations include a role name and a multi-value description. However, if they are different from standard bidirectional associations, one-way associations only contain the role names and multi-value descriptions of known classes.

In short, OverdrawAccountReport contains the BankAccount attribute, while BankAccount does not need to contain the OverdrawnAccountsReport object.

6. Aggregate representation:

Aggregation is a special type of association used to describe the relationship between "population and local. In the basic aggregation relationship, the lifecycle of a partial classification is independent of that of the entire class.

For example, we can imagine that a car is a whole entity, and a wheel tire is a part of a whole car. Tires can be manufactured and placed in warehouses a few weeks before they are placed in the vehicle. In this instance, the Wheel class instance clearly exists independently of the Car class instance. However, in some cases, the life cycles of some classes are not independent of the life cycles of the entire class-this is called synthesis aggregation. For example, consider the relationship between the company and the Department. Both the company and department are modeled as classes. Before the company exists, the Department cannot exist. Here, the Department class instance depends on the Company class instance.

Let's further explore basic aggregation and composite aggregation.

Note: The difference between aggregation and normal association is that normal association may be a simple "include, reference" relationship, the logical concepts of associations and associated classes are not necessarily closely related. Aggregation is different. It indicates the concept of a close, interdependent, and inclusive internal relationship, one part is an indispensable component that forms another part.

· Basic aggregation

An association with an aggregation relationship indicates that a class is part of another class. In an aggregation relationship, the subclass instance can be longer than the parent class. To express an aggregation relationship, you draw a solid line from the parent class to the partial classification, and draw an unfilled prism at the end of the parent class association.

The figure clearly shows that a Car-like object contains four instances of another type of Wheel. The two instances are conceptually inseparable. One class is the composition of another class. The diamond represents "include", the arrow represents the object to be included, and the number 4 represents the number of included objects.

· Combination Aggregation

A combination of aggregation relationships is another form of aggregation relationships, but the lifecycle of a subclass instance depends on the lifecycle of the parent instance.

Note: The composite relationship is drawn like an aggregate link, but this time the diamond is filled.

7. Reflection associated representation:

Class can also be associated with it Using Reflection Association. At first, this may be meaningless, but remember that classes are abstract. When a class is associated with itself, this does not mean that the instance of the class is related to itself, but an instance of the class is related to another instance of the class.

The relationship depicted in the figure indicates that one Employee instance may be the manager of another Employee instance. However, because the "manages" relationship role has a Multiple Description of 0 .. *, an employee may not be managed by any other employee.

3. object diagrams in UML:

The instance mark is the same as the class, but it replaces the only class name in the top area. Its name is spliced:

Instance Name: Class Name such as Donald: Person

Because the purpose of displaying instances is to display noteworthy or related information, it is not necessary to include the entire object attribute and operation in your model. On the contrary, it is entirely appropriate to only display the attributes of interest and their values.

UML 2 also allows relational/associated modeling at the Entity layer. The same rule is used to draw associations with general class relationships. In addition to modeling associations, there is an additional requirement. The additional restriction is that the association relationship must be consistent with the class diagram, and the associated role name must also be consistent with the class diagram.

4. Role diagram in UML:

The instance of the modeling class is sometimes more detailed than expected. Sometimes, you may just want to create a class relationship model at a higher level. In this case, you should useRoleMark. Role tags are similar to instance tags. To create a role model for a class, you can draw a square and place the role name and Class Name of the class inside as the entity mark, but in this case, you cannot underline it.

Note: A significant difference between a role diagram and an object diagram is that each object name in an object diagram is underlined, while a role diagram does not

The following is a sequence diagram:

A Sequence Chart is used to display the interaction between objects in a series of order of interaction. Like a class chart, developers generally think that a sequence chart is only meaningful to them. However, the business personnel of an organization will find that the sequence diagram shows how different Business Objects interact, which is useful for communicating with the current business. In addition to recording the current events of an organization, a business-level sequence chart can be used as a requirement file to meet future system transfer requirements. In the project demand phase, analysts can bring the use cases to the next level by providing a more formal expression. In that case, use cases are often subdivided into one or more sequence diagrams.

The technical staff of the Organization can find that sequence diagrams are very useful in recording how a future system behave. In the design phase, architects and developers can use graphs to explore the interaction between system objects, so as to enrich the entire system design.

One of the main purposes of a sequence chart is to transform the Needs of the use case expression into further and more formal levels of fine expression. Use Cases are often divided into one or more sequence diagrams. In addition to the purpose of designing a new system, sequence diagrams can also be used to record how objects in an existing system (called a legacy) interact with each other. This document is useful when you hand over the system to another person or organization.

Java applications are composed of many classes and are the core of implementing object-oriented applications in Java. Class Diagrams mainly describe the static relationships between various types of Java applications, such as class inheritance, abstraction, interfaces, and various associations. To use UML to design Java applications, we only need to use class diagrams to describe these static relationships. Using visual tools, we need to implement automatic generation of Java application code. We must also describe the cooperative and dynamic relationships among various types, such as the interactions in time series. The UML sequence diagram describes how a method call process (or message sending) between a class and a class is implemented.

I. New Elements in UML-framework:

In UML 2, frame elements are used as a basis for many other graph elements, but most people first come into contact with frame elements as graphical boundaries of graphs. When a graphic border is provided for a graph, a frame element provides a consistent position for the labels of the graph. In the UML diagram, the framework components are selectable.

In addition to providing a graphical border, framework components used in graphs also have important functions to describe interactions, such as sequence diagrams. In a sequence diagram, a sequence receives and sends messages (also known as interactions). A model can be established by connecting the message and the Framework Element Boundary (see figure 2 ).

For a sequence chart, the label of the chart starts with the text "sd. When you use a frame element to close a graph, the label of the graph must follow the format below: Graph type graph name.

UML specifications provide specific text values for graph types. (For example, sd represents a sequence diagram, activity represents an activity diagram, and use case represents a use case diagram ).

Ii. Sequence diagram in UML:

A Sequence Chart is used to display the interaction between objects in a series of order of interaction.

In the project demand phase, analysts can bring the use cases to the next level by providing a more formal expression. In that case, use cases are often subdivided into one or more sequence diagrams.

One of the main purposes of a sequence chart is to transform the Needs of the use case expression into further and more formal levels of fine expression. Use Cases are often divided into one or more sequence diagrams. In addition to the purpose of designing a new system, sequence diagrams can also be used to record how objects in an existing system (called a legacy) interact with each other.

The main purpose of a sequence chart is to define the Event Sequence and generate expected output. The focus is not on the message itself, but on the order in which messages are generated. However, most sequence diagrams indicate what messages are transmitted between System Objects and the order in which they occur. The image transmits information in the horizontal and vertical dimensions: the vertical dimension indicates the time sequence of the message/call occurrence from top to bottom, and the horizontal dimension indicates the object instance to which the message is sent from left to right.

1. Lifeline:

The lifeline painting is a square, with a dotted line from top to bottom passing through the center of the bottom boundary (Figure 3 ). The lifeline name is placed in the square.

The lifeline Naming Standard of UML follows the following format: entity name: Class Name

The lifeline name is underlined. When an underline is used, it means that the lifeline in a sequence diagram represents a specific entity of a class, not a specific entity of a specific type (for example, a role ). The instance name of the sequence chart is underlined, but the role name is not.

A lifeline can be used to represent an anonymous or unnamed entity. When a sequence chart is modeled for an unnamed instance, the name of the lifeline follows the same pattern as that of a named instance. However, the location of the lifeline name remains blank, rather than providing an example chart name.
 

2. Message Body:

To display an object (for example, a lifeline) and send a message to another object, you draw a line pointing to the receiving object, including a solid arrow (for a synchronous call operation) or a stick arrow (if it is an asynchronous signal ). The message/method name is placed on the line with an arrow. The message being passed to the receiving object, indicating an operation/method implemented by the class of the receiving object.

The return message is optional. A return message is drawn with a dotted line with an open arrow pointing back to the lifeline of the source. On this dotted line, you place the return value of the operation. To draw a call object, such as what you do at ordinary times, draw a message, but not connect it to another object, but connect the message to the object itself.

Iii. Constraints in UML:

The constraint symbol is very simple; format: [Boolean Test]

4. New Elements in UML-combined fragments (variant schemes, selection items, and loops ):

A combined Shard is used to combine a set of messages and display the condition branches in a sequence diagram.

1. variants:

A variant is used to specify the mutex selection between two or more message sequences. The combined fragment element of a variant is drawn using a frame. The word "alt" is placed in the namebox of the framework. Then the larger rectangle is divided into the operation elements referred to as UML 2. The operating elements are separated by dotted lines. Each operator element has a constraint for testing, which is placed on the left upper part of the operator element at the top of the lifeline. If the constraint of the Operation element is "true", then the operation element is the operation element to be executed.

Figure 8 shows how the sequence starts from the top, that is, the bank object gets the Check amount and account balance. In this case, the variant combinations in the sequence diagram take over. Because of the constraint "[balance> = amount]", if the balance exceeds or is equal to the amount, the bank object will be delivered with the addDebitTransaction and storePhotoOfCheck messages to the account object in sequence. However, if the balance does not exceed or equal to the amount, the sequential process is that the bank sends the addInsuffientFundFee and noteReturnedCheck messages to the account object, and the returnCheck message to itself. Because of the "else" constraint, when the balance is not greater than or equal to the amount, the second sequence is called. The "else" constraint is not required in the combination fragment of variants. If an operator element does not have a definite constraint on it, the "else" constraint is assumed.

2. select items:

A selection item is used to model a simple "if then" expression. (For example, if there are fewer than five circles on the shelf, make two more circles ).

The selected item Combination fragment symbol is similar to the variant combination fragment, except that it has only one operating element and never has an "else" constraint (it does so and has no reason ). You need to draw a selection item Combination and draw a frame. The text "opt" is the text that is placed in the namebox of the framework. In the content area of the framework, the constraints of the selection items are placed in the upper left corner of the top corner of the lifeline. Then, the message sequence of the selected item is placed in the rest of the content area of the framework.

Note: variants are used to model if then else. The selection item is used to model if then. Because there is only one branch, [else] cannot appear.

3. Loop:

The circular composite fragment surface is very similar to the selected item composite fragment. You can draw a framework and place the text "loop" in the namebox of the framework ". In the content area of the framework, the cycle constraint is placed at the top left corner of a lifeline. Then, the cyclic message sequence is placed in the rest of the framework content area. In a loop, apart from standard Boolean tests, one constraint can test two specific conditional statements. The specific constraint condition is the minimum number of cycles for writing "minint = [the number]" (for example, "minint = 1, or write the maximum number of cycles for "maxint = [the number]" (for example, "maxint = 5. Through the minimum cycle test, the cycle must run at least a specified number of times, and the number of cycles cannot reach the maximum number of cycles specified by the constraint.

The following is an example:

The use case diagram is mainly used to illustrate the main event process of the system. It is mainly used to describe the customer's needs, that is, the user wants the system to complete certain functional actions, the general understanding of use cases is the functional module of the software, so it is the starting point of the design system analysis phase. The designer creates and explains the use case diagram based on the customer's needs, it is used to describe the functional modules that the software should possess and the call relationship between these modules. The use case diagram contains the use cases and participants, use Cases are connected with each other to reflect the entire structure and functions of the system to non-technical personnel (usually software users). This corresponds to the software structure and functional decomposition.

A use case is a behavior visible outside the system and is a complete service provided by the system for one or more actors. In principle, use cases are independent and parallel, and there is no subordination between them. However, in order to reflect the business relationship between some use cases and improve maintainability and consistency, the use cases can abstract several relations, including, extend, and generalization.

Commonalities: the common information is extracted from the existing use cases. As a separate use case, different methods are used to reuse this public use case, to reduce the workload of model maintenance.

1. include)

 

Inclusion relationship: Use Inclusion cases to encapsulate a group of similar actions (behavior fragments) that span multiple use cases, so that multiple Base use cases can be reused. The relationship between the basic case control and the contained case, and whether the event stream of the included case will be inserted into the event stream of the base case. The base use case can depend on the result of the execution of the use case, but neither party can access the attributes of the other party.

The inclusion relationship is reused for a typical application, that is, the scenario described in the definition. However, when an event in a use case flows through a complex process, we can abstract an event stream into an included use case to simplify the description of the use case. On the contrary, when the use cases are too detailed, a basic use case can be abstracted to include these fine-grained use cases. This is similar to encapsulating an algorithm of a program into a sub-process in a process design language, and then calling this sub-process from the main program.

For example, the service always has the function of maintaining XX information. If you use this function as a use case, it is too complicated to describe, edit, and modify the information in the use case details; if it is divided into new use cases, edit use cases, and delete use cases, the Division is too detailed. The contained relationship can be used to clarify the relationship.

2. Extended)

Extensioning: encapsulate a relatively independent and optional action in the base case with the Extension case, and then let it claim the Extension Point from the base case) to make the basic use case behavior more concise and more concentrated. Add new behaviors for the extended use case. The extended use case can access the attributes of the base use case. Therefore, it can determine whether to execute itself based on the current status of the extension points in the base use case. However, the extended use case is invisible to the base use case.

For an extension case, there are several extension points on the base case.

For example, you can export and print the query results in the system. For queries, whether or not the query can be exported or printed is the same, and export and printing are invisible. Imports, prints, and queries are relatively independent, and new behaviors are added for queries. Therefore, you can use the extended relationship to describe:

4. generalization)

 

General relationship: the child case is similar to the parent case, but shows more special behavior. The child case inherits all structures, behaviors, and relationships of the parent case. A child use case can use a behavior of the parent use case or reload it. The parent case is usually abstract. Generalization is rarely used in practical applications. Special behaviors in subcases can be used as alternative streams in the parent case.

For example, there may be many tasks that require approval from department leaders in the business, but the approval process is very similar. In this case, the general relationship can be expressed as follows:

The above is an article I have referenced. I think the difference between the three relations is very clear. Based on this, I will combine my own system to explain the project (Online Shopping System) as a whole.

**************************************** *************************

(1) overall system use case diagram

(Product use case diagram)

(Purchase information use case)

(User Data Use Cases)

Follow the overall use case first, and then the subsystem use case to describe it. You are welcome to make good suggestions!

Transformation: differences between extension and generalization in UML

Generalized representation is similar to the OO term "inheritance" or "polymorphism ". The Use Case generalization process in UML abstracts the merged parts of different Use cases into independent parent Use cases, and separately merges the unmerged parts into their respective subuse cases; the process of inclusion and extension is similar to that of generalization, but the optimization focus on the relationship between use cases is different. As follows:
● Generalization focuses on the mutual exclusion between subcases;
● Include focuses on the indirect nature of included use cases to provide services to Actor;
● Extension focuses on the trigger uncertainty of the extension case. The details are as follows:

Since the use case is a UML representation of the system to provide services, the process of service is inevitable in all use case scenarios. However, the occurrence conditions can be divided into the following two situations:
Condition occurs unconditionally: Yes;
Conditional occurrence of a token: It may not occur, and the occurrence or failure depends on the system status;

Therefore, for the three relationships of use cases, combined with system status considerations, generalization and inclusion of use cases are unconditional use cases, and extension is conditional use cases. Furthermore, the use cases provide services for Actor, but the use cases provide services in two ways: indirect and direct. Based on this, the generalized sub-cases provide direct services, the included use cases provide indirect services. Similarly, extended use cases provide direct services, but the occurrence of extended use cases is conditional.

In addition, the subuse cases in generalization and the extended use cases in extension can be used as the backup selection stream of basic Use Case events.

 

Activity diagram:

The UML activity diagram records the logic of a single operation or method, a single user case, or a single business flow. In many ways,Activity diagramIt is the object-oriented equivalent of a flowchart and a data flowchart (DFD) in structured development. To create a UML activity diagram, you must perform the following steps repeatedly.

Step 1: define the scope of the activity diagram. First, define the modeling target. Individual user case? Part of a user case? A business process that contains multiple user cases? A single method of a class? Once you define the scope of your drawing, you should add a label at the top of the graph to indicate the title and unique identifier of the graph. You may also want to include the time of the graph or the author name.

Step 2: Add start points and end points. Each activity chart has a start point and end point. Therefore, you must add them immediately. In UML essence (UML Distilled) (see references), Fowler and Scott consider the end point to be optional. Sometimes an activity is just a simple end. In this case, it is harmless to indicate that the only change is to an end point. As a result, when someone else reads your chart, he or she knows that you have considered how to exit these activities.

Step 3: add an activity if you are modeling a User case, introduce an activity to the main steps that each role (actor) sends (this activity may include the start step, add any steps for the system response to the start step ). If you are modeling a high-level business process, introduce an activity for each major process, typically a User case or user case package. Finally, if you are modeling a method, it is common to introduce this activity.

Step 4: change between adding activities my style should always exit an activity, even if it is switched to an end point. Once there are multiple transformations in an activity, you must mark each transformation accordingly.

Step 5: Add a decision point. Sometimes, you need to make a decision for the logic you are modeling. Some transactions may need to be checked or compared. Note that the use of decision points is optional.

Step 6: Find out where parallel activities are available. When there is no direct connection between the two activities and they must all end before the start of the third activity, they can run in parallel.

 

The followingActivity diagramDescribes the business logic of how university freshmen apply for admission for the first time.

• Solid circleActivity diagramIs actually a placeholder. A solid circle with a border indicates the end point.
• The rounded rectangle indicates the execution process or activity. In this figure, although you will notice that the "Registration Seminar" use case will call the "Registration Seminar" activity multiple times, these activities are quite closely mapped to the use case. Activities can be much more detailed, especially when you choose to record method logic rather than advanced business processes.
• Diamond indicates the judgment point. Although there are only two possible results for the determination point in this example, it is equally easy even if there are more possible results.
• Arrows indicate the conversion between activities and the flow order between activities.
• The text on the arrow indicates the conditions that must be met for further conversion. The format is always described in [condition. I guess, inUMLIn future versions, we will see thatUMLCondition of the record in the constraint notation (for example, "{condition.
• The rough lines indicate the beginning and end of the process that may be performed in parallel. After successfully enrolled in a university, you must attend the specified profile and register at least one cram school and pay part of the tuition fee.

　

There may be several ways to exit the activity, as you can see in the "fill in admission form" activity. If the form is entered correctly, you can continue with the university admission procedures. However, if the form is incorrect, you must obtain help (possibly from the Registrar) to enter them correctly.

Figure 1. First entryUML Activity diagram

ThisActivity diagramIt is very interesting because it saves the logic of several use cases identified in Figure 2. It is a good thing that the case model does not properly express the processing sequence. For example, although the use case diagram shown in Figure 2 clearly describes the function types executed by the system, it does not clearly express the sequence in which these cases may occur. HoweverActivity diagramThis is done. In short, the advantages and disadvantages of different models are different.

The logic of several use cases identified in. It is a good thing that the case model does not properly express the processing sequence. For example, although the use case diagram shown in clearly describes the function types executed by the system, it does not clearly express the sequence in which these cases may occur. HoweverActivity diagramThis is done. In short, the advantages and disadvantages of different models are different.

Figure 2. Examples of Universities

Swimming Lane
It is usually useful to organize activities in the model according to their responsibilities. For example, you can organize all activities handled by a business organization. This allocation can be expressed by organizing activities into different areas separated by lines. Because of their appearance, these areas are called swimming channels. Figure 7-2 shows the swimming track.

Figure 7-2 swimming channels and object streams

· 2. Object stream

Activity diagramIndicates the value stream and control flow of an object. The object stream status indicates the input or output objects in the activity. For the output value, the dotted arrow points from the activity to the object stream status. For the input value, the dotted arrow points from the object stream status to activity. If an activity has multiple output values or a subsequent control flow, the arrows return to the forks. Similarly, multiple input arrows point to the combination symbol.

Figure 7-2 shows that the status of an activity and object stream are allocated to the swimming pool.Activity diagram.

· Activity and other diagrams

Activity diagramNo details are displayed during the computing process. They indicate the process of the activity but do not indicate the objects of the activity.Activity diagramIs the starting point of design. To complete the design, each activity must be subdivided into one or more operations, and each operation is specified to a specific class. The result of this allocation leads to the implementationActivity diagram.

Below is the data flow diagram DFD:

I have studied DFD:

Structured Analysis is an effective method for data stream-oriented demand analysis. Generally, the requirements of the system are defined using the top-down, layer-by-layer analysis of romance, that is, the analysis object is first abstracted into a system, and then the top-down layer decomposition, the complex system is divided into several subsystems that can be clearly understood and expressed, as shown in 1 (layer-by-layer data flow chart. In this way, you can understand every detail, sequence, and relationship of the system, and find out the data interfaces between each part. The tools used in structured analysis include data flowchart (DFD), Data Dictionary (DD), structured language, decision tree, and decision table.

The core of structured analysis is the data flow chart, which graphically expresses the process of information transformation and transmission in the problem. It regards the system as a combination of various concepts associated with data streams, uses decomposition and abstraction to control the complexity of demand analysis, and uses hierarchical data flowcharts to represent a complex system.

Data Flow Diagram: DFD is a graphic representation of the system's logical functions, the logical flow of data within the system, and the logical transformation process, it is the main expression tool of the structured system analysis method and a graphical method used to represent the software model.

 

A computer-based information processing system consists of data streams and a series of processes that process input data streams as output data streams.

 

Data Flow diagram description data flow and Processing

 

A Data Flow Chart uses graphical symbols to represent data streams, processing, data sources, and external entities.

 

A Data Flow chart has a hierarchical structure and supports problem breakdown and progressive refinement analysis methods.

 

A data-driven data flow diagram can represent both computer-based systems and software.

 

A data flow diagram can be used to abstract systems or software. From the perspective of information transmission and processing, it graphically depicts the process of moving data streams from input to output, at the same time, you can use top-down and gradual decomposition to show the increasing data streams and functional details of the content. Therefore, a data flow diagram provides both a function modeling mechanism and a information flow modeling mechanism to establish a functional model of a system or software.

 

The meaning of the basic symbol of the data flow diagram:

 

1. A rectangle indicates the external entity of the data;

 

2. The rectangle of the rounded corner indicates the processing logic of the transformed data;

 

3. Less right edges and rectangles indicate data storage;

 

4. Arrows indicate data streams.

The data flow chart has the following main elements:
→: Data stream. Data Stream is the path where data is transmitted in the system. Therefore, data streams are composed of fixed data. For example, a ticket consists of a passenger's name, age, unit, ID card number, date, destination, and other data items. Because a data stream is a flow of data, it must have a flow direction. In addition to the data stream between the data stream and the data storage, the data stream should be named by a noun or a noun phrase.
□: Data source (endpoint ). Represents entities outside the system, which can be people, things, or other software systems.
○: Data processing ). Processing is a unit for processing data. It receives a certain amount of data input, processes it, and generates output.
Children: data storage. Static storage of information, which can represent a part of a file, a part of a file, and database elements.