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>\u00a0Although 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>\u00a0combined with a traditional data flow diagram. Typical flowchart techniques lack constructs for expressing concurrency.<\/sup>\u00a0However, 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>\u00a0in 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>\u00a0These 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 In\u00a0software engineering<\/a>, a\u00a0class diagram<\/b>\u00a0in the\u00a0Unified Modeling Language<\/a>\u00a0(UML) is a type of static structure diagram that describes the structure of a system by showing the system’s\u00a0classes<\/a>, their attributes, operations (or methods), and the relationships among objects.<\/p>\n The class diagram is the main building block of\u00a0object-oriented<\/a>\u00a0modeling. It is used for general\u00a0conceptual modeling<\/a>\u00a0of the structure of the application, and for detailed modeling, translating the models into\u00a0programming code<\/a>. Class diagrams can also be used for\u00a0data modeling<\/a>. <\/sup>The classes in a class diagram represent both the main elements, interactions in the application, and the classes to be programmed.<\/p>\n In the diagram, classes are represented with boxes that contain three compartments:<\/p>\n In the design of a system, a number of classes are identified and grouped together in a class diagram that helps to determine the static relations between them. In detailed modeling, the classes of the conceptual design are often split into subclasses.<\/p>\n In order to further describe the behavior of systems, these class diagrams can be complemented by a\u00a0state diagram<\/a>\u00a0or\u00a0UML state machine<\/a>.<\/p>\n A\u00a0sequence diagram<\/b>\u00a0or\u00a0system sequence diagram<\/b>\u00a0(SSD) shows\u00a0process<\/a>\u00a0interactions arranged in time sequence in the field of\u00a0software engineering<\/a>. It depicts the processes involved and the sequence of messages exchanged between the processes needed to carry out the functionality. Sequence diagrams are typically associated with use case realizations in the\u00a04+1 architectural view model<\/a>\u00a0of the system under development. Sequence diagrams are sometimes called\u00a0event diagrams<\/b>\u00a0or\u00a0event scenarios<\/b>.<\/p>\n For a particular scenario of a\u00a0use case<\/a>, the diagrams show the events that external actors generate, their order, and possible inter-system events. <\/sup>All\u00a0systems<\/a>\u00a0are treated as a\u00a0black box<\/a>; the diagram places emphasis on events that cross the system boundary from actors to systems. A system sequence diagram should be done for the main success scenario of the\u00a0use case<\/a>, and frequent or complex alternative scenarios.<\/p>\n A sequence diagram shows, as parallel vertical lines (lifelines<\/i>), different processes or objects that live simultaneously, and, as horizontal arrows, the messages exchanged between them, in the order in which they occur. This allows the specification of simple runtime scenarios in a graphical manner.<\/p>\n A system sequence diagram should specify and show the following:<\/p>\nConstruction<\/span><\/h4>\n
\n
Class diagram<\/h3>\n
\n
Sequence diagram<\/h3>\n
Key elements<\/span><\/h4>\n
\n