2016.05.26-2016.06.02 Work hours and content this week

What to learn this week: This week is the same as usual, we studied in class for three hours, the teacher told the use case diagram, class diagram, sequence diagram, State diagram. We learned about use-case diagrams, which are diagrams of the protagonists, use cases, and the relationships between them, as use cases diagram. The diagram illustrates the relationships in the use-case model. Class diagrams (classes diagram) consist of many (statically) descriptive model elements, such as classes, packages, and their relationships, which are interconnected with their contents. Class diagrams can be organized in (and belong to) packages, showing only relevant content in a specific package. Class diagram is the most commonly used UML diagram, showing classes, interfaces, and their static structures and relationships, which are used to describe the structural design of a system. Sequence diagrams (Sequence Diagram) have multiple meanings and usages. Sequence diagram may refer to the genetic material on the nucleotide sequence physical map abbreviation, is the human genome project of the most basic work, the human genome at the molecular level of the most detailed physical map, the determination of a total length of 1M, composed of about 3 billion nucleotide nucleotide genome DNA sequence. A state diagram (Statechart Diagram) is a dynamic behavior that describes an entity's response based on an event, showing how the entity responds to different events based on the state in which it is currently located. A UML state diagram is typically created for the purpose of studying the complex behavior of classes, roles, subsystems, or components. State machines are made up of States, and each state is linked by a transfer. A state is a condition when an object executes an activity or waits for an event. A transition is a relationship between two states that is triggered by an event and then performs a specific action or evaluation and results in a specific end state. We use the teacher sent down the software to draw a use case diagram, at first , we all tube participants called the villain, then the teacher corrected our mistakes, feel special funny, also very happy.

What to read this week:

Use case diagrams are primarily used to describe the relationship between users, requirements, and system functional units. It shows a system function model diagram that external users can observe. Use case diagrams are used in the static modeling phase (primarily business modeling and requirements modeling) to help development teams understand the functional requirements of the system in a visual way. The use case diagram is analyzed and understood in each section below.

Participant (actor)

A person or thing that interacts directly with the system outside the system; The following two points need to be noted:

1. A participant is a role rather than a specific person, and it represents the role that the participant plays in the process of dealing with the system. Therefore, in the actual operation of the system, an actual user may correspond to multiple participants in the system. Different users can also correspond to only one participant, thereby representing different instances of the same participant.
2. The actor interacts with the system as an external user (rather than as an internal) and is its main feature.

In UML, the actor uses a villain that says:

Use cases

A system function unit that is visible outside the system. The function of the system is provided by the system unit and is expressed through a series of system units exchanged with one or more participants. With ellipses, the text in the ellipse outlines the functions of the system:

Subsystem (SUBSYSTEM)

Used to show a part of the system function, this part of the function is closely related.

Relationship (Relationship)

The relationships involved in the use case diagram are:

1. Association
2. Generalization
3. Contains
4. Extended

Association (Association)

Represents an interaction between a participant and a use case, a communication route, in which either party can send or receive messages.
Arrow point to: Point to the message receiver.

Generalization (inheritance)

In programming, generalization is a very important relationship, and we are everywhere.
Generalized relationships are general and special relationships, which are commonly understood inheritance relationships, where child use cases are similar to parent use cases, but behave more specifically, and child use cases inherit all the structures, behaviors, and relationships of the parent use case. A child use case can use a section of the parent use case, or it can be overloaded. The parent use case is usually abstract.
Arrow pointing (requires special attention): points to the parent use case.

Includes (include)

The include relationship is used to break down the functionality represented by a more complex use case into smaller steps. It is necessary to include a use case, and if the inclusion use case is missing, the base use case is incomplete; the containing use case must be executed.
Arrow pointing to: A function use case that points to decomposition.

Extension (Extend)

An extension relationship is an extension of a use case feature, which is equivalent to providing an additional function for the underlying use case. An extension use case is optional, and if an extension use case is missing, the integrity of the base use case is not affected.
Arrow pointing (requires special attention): pointing to the base use case

Provide a complete system of use case diagrams that give everyone a sense of a holistic understanding.

Summarize

Although the use case diagram as a part of the UML, give team members an image of the system expression, but, use case diagram also by its own shortcomings, use case diagram is usually given in the requirements analysis stage, sometimes for the needs of the system, and can not be very good expression, for people without UML background, is a kind of pain and torture, However, again, as a software developer, there is no UML background is justified, sometimes we need use case diagram to explain the system to the customer, and let the customer to understand the use case diagram is very difficult.
Although the type of relationship in the use case diagram is not many, it is not very complex, but the representation of the UML is really confusing, other good, especially the extension (Extend) and the inclusion (include), the expression is the same, only by the above description to distinguish, in a complex system, It is easy to see the wrong, and thus understand the error, at the same time, the extension (Extend) in the arrow point has always been confusing to me, why need to let the arrows point to the base case?
In view of the use case diagram sometimes does not clearly express the functional requirements, the development of people usually use use case description table to supplement some difficult to express use cases, please refer to:

2016.05.26-2016.06.02 Work hours and content this week