One: Dynamic View---> Dynamic view is a description of the dynamic behavior of things. ---> Note that a dynamic view cannot exist independently, it must refer to a static view of a live uml element, explaining their dynamic behavior under the structure of things defined by static views. ---> Dynamic view: Activity diagram, state diagram, timing diagram, collaboration diagramII: Activity diagram---> Activity diagrams describe the activities that need to be done to accomplish a particular goal and the order in which they are executed. There are two levels of activity diagrams in the--->uml, one for describing use case scenarios called [use case activity diagrams] and another for describing object interactions called [object activity diagrams]. ---> In object-oriented eyes there is no such thing as business process, so-called process is simply a process of interacting with an object under the impetus of an external force, it is just "instantaneous". If you describe your business from the perspective of an activity diagram, you cannot actually see directly how the object works. This can easily lead to the destruction of object independence in concept. Because object-oriented requires an object to be more independent, the better the package, the more pure the object, the more difficult it is for us to understand what these objects will do. The so-called God can do anything, but in fact it does nothing. So we face a contradiction that we should maintain the independence of object in object-oriented view and keep the process description of business objective in the real world. The introduction of activity diagram solves the process description of business objective, but also causes confusion to object analysis. Therefore, when using the activity diagram, to keep a clear mind, the activity diagram is just the process we use to describe the business goals, and to find the tools of the object. He is not our analytical goal, nor is it the basis of programming, it is just one of the object's application scenarios. We use activity diagrams to describe use case scenarios, help us understand problem areas, identify key objects from problem areas, and then focus on the characteristics of key objects by forgetting the processes in the activity diagram.Three: Use case activity diagram
---> Use case activity diagrams are most frequently used. Use Cases Express one goal of the participants. ---> Start point: Marks the beginning of a business process. An activity diagram, alive saying that a business process has and has only one starting point. ---> Activity: is an execution unit in a business process---> judgment: Determine the decision based on a condition, and execute a different branch of the process. ---> Synchronization: Synchronization is divided into synchronous start and synchronous convergence. A synchronous start indicates that it begins parallel execution of multiple tributaries. Synchronous convergence means that multiple tributaries arrive at the same time and then perform subsequent activities. ---> End point: Represents the termination of a business process. An activity diagram alive says a business process that can have one or more end points. ---> Basic flow: Represents the primary, most frequently used, default business process branch. ---> Tributary: Represents an infrequently used, non-default business process branch that is triggered by a condition. ---> Exception flow: Represents an unhealthy, not a business-goal-expected, fault-tolerant, business process branching---> composition activity that handles unexpected situations: it can be represented by nested activities. However, this approach can cause the activity diagram to be too complex to be clear and not recommended for use.four: Object activity diagram
---> Object activity diagrams are used to show the interaction of objects. ---> Draw an object activity diagram based on the object interaction process of querying the product. ---> It is not so clear how the object activity diagram describes object interaction. There is no reason to use it in real work, there are better tools to draw objects almost to the diagram. For example: State diagram, time series diagram, collaboration diagram.Five: Swimlane---> As the name implies, it's like a swimmer playing in only one lane. An object can only assume one (or a category) of responsibilities in one business journey. A swimlane represents the area of responsibility for a particular class, person, department, hierarchy, and the set of activities that the objects are responsible for executing in the business process to synthesize their responsibilities. ---> Resolves a regret that an activity diagram cannot describe an object's responsibilities.V: Modeling Business Scenarios---> Business scenario modeling is to use the customer representative as a swimlane to get business use cases from the business lead as activities to orchestrate the activity diagram. This activity diagram helps us to get the right business use case. (1) Help Discover business use cases(2) Help check the granularity of business use cases(3) Help check business lead(4) Help check business use casesVI: Use case scenario modeling---> Get business use cases, we get the business goals of our participants, and we illustrate how to achieve our business goals through use case scenarios. ---> We often use business leads and business workers as swimlane, and work units as activities to orchestrate activity diagrams to describe use case scenarios. ---> This activity diagram is very helpful for us to get conceptual use cases, roles and business objects (business entities). (1) Help to discover conceptual use cases (unit of work). If you find that a similar unit of work in multiple use case scenarios often appears, consider abstracting her. To use inclusion, extension, or generalization relationships to connect them to basic use cases (i.e., the business use cases they contribute) (2) to help discover roles as a general rule, a swimlane (business lead live worker) can define a role. However, if multiple use case scenarios find the same or same class of work units (activities) in different lanes, which are used by different business protagonists or business workers, you should consider abstracting higher-level roles for the business lead workers who use the same activity. (3) to help discover business entities such as, we will find that all activities have the same naming rules: verb + noun. These nouns are the source of good business entities (objects). Such as: ticket, boarding pass. (4) Help to build a domain model. The domain model describes which business objects are important to the business, and if a noun recurs in different activities in the same or multiple use-case scenarios. Then the noun should be paid attention to. It is likely to be a key business object. The state of the business object in different activities and the relationship between it and other nouns in the activity diagram are likely to determine the structure of the business. The domain model can be obtained by drawing this structure.
< 15 activity diagram of >UML core view Dynamic View
