Activity diagrams<\/b>\u00a0are graphical representations of\u00a0workflows<\/a> of stepwise activities and actions\u00a0<\/sup>with support for choice, iteration and concurrency. In the\u00a0Unified Modeling Language<\/a>, activity diagrams are intended to model both computational and organizational processes (i.e., workflows), as well as the data flows intersecting with the related activities.<\/sup><\/sup> Although activity diagrams primarily show the overall flow of control, they can also include elements showing the flow of data between activities through one or more data stores.<\/p>\n Activity diagrams are constructed from a limited number of shapes, connected with arrows. <\/sup>The most important shape types:<\/p>\n Arrows run from the start towards the end and represent the order in which activities happen.<\/p>\n Activity diagrams can be regarded as a form of a structured\u00a0flowchart<\/a> combined with a traditional data flow diagram. Typical flowchart techniques lack constructs for expressing concurrency.\u00a0<\/sup>However, the join and split symbols in activity diagrams only resolve this for simple cases; the meaning of the model is not clear when they are arbitrarily combined with decisions or loops.<\/p>\n While in UML 1.x, activity diagrams were a specialized form of state diagrams, <\/sup>in UML 2.x, the activity diagrams were reformalized to be based on\u00a0Petri net<\/a>-like semantics, increasing the scope of situations that can be modeled using activity diagrams. <\/sup>These changes cause many UML 1.x activity diagrams to be interpreted differently in UML 2.x.<\/p>\n UML activity diagrams in version 2.x can be used in various domains, e.g. in design of embedded systems. It is possible to verify such a specification using model checking technique.<\/p>\n A\u00a0use case diagram<\/b>\u00a0is a graphical depiction of a user’s possible interactions with a system. A use case diagram shows various use cases and different types of users the system has and will often be accompanied by other types of diagrams as well. The use cases are represented by either circles or ellipses. The actors are often shown as stick figures.<\/p>\n While a\u00a0use case<\/a>\u00a0itself might drill into a lot of detail about every possibility, a use-case diagram can help provide a higher-level view of the system. It has been said before that “Use case diagrams are the blueprints for your system”.<\/sup><\/p>\n Due to their simplistic nature, use case diagrams can be a good communication tool for\u00a0stakeholders<\/a>. The drawings attempt to mimic the real world and provide a view for the\u00a0stakeholder<\/a>\u00a0to understand how the system is going to be designed. Siau and Lee conducted research to determine if there was a valid situation for use case diagrams at all or if they were unnecessary. What was found was that the use case diagrams conveyed the intent of the system in a more simplified manner to\u00a0stakeholders<\/a>\u00a0and that they were “interpreted more completely than class diagrams”.<\/p>\n","protected":false},"excerpt":{"rendered":"Construction<\/span><\/h3>\n
\n
Use case diagram<\/h2>\n
Application<\/span><\/h3>\n