UNIT 6 SYSTEMS MODELING Flashcards
Briefly describe what is the UML.
The unified modeling language (UML) was developed with the aim of modeling, documenting, and visualizing complex systems in an unambiguous manner, regardless of their subject and area of implementation. The maintenance of this standard was taken over by the Object Management Group (OMG). UML provides the notation elements for the static and dynamic models of analysis, design, and architecture, and supports object-oriented approaches. By integrating extensible markup language (XML) into UML, a textual notation of equal power was added to the modeling language, which had previously comprised only graphical elements, and which enables the transfer of models from one modeling software to another.
What are UML diagrams and UML models, and what is their relationship?
There are different diagrams for modeling the structure and behavior of the systems. Structure diagrams are used to represent the structure, elements, composition, and system interfaces. In simple terms, structure diagrams are used to model the elements of a system. Conversely, behavior diagrams are used to show what happens in a system and at its interfaces. Interaction diagrams aswer how the communication works inside the systems.
A UML diagram represents a very specific view of a system or an issue. For example, a class diagram models business objects and their properties, while an activity diagram models internal processes of the system. However, both diagrams are part of a UML model. This means that a UML model can be described by several UML diagrams, while a UML diagram always belongs to exactly one UML model. The type of relationship is thus one to many (1..*).
Describe the separation of meaning and representation in UML.
UML is used for graphical modeling, in which each graphical model element has a specific
meaning. The UML standard specifies the set of possible terms that can be used when creating a UML model. Furthermore, the UML specifies, for each diagram type, which of the
terms available in the UML can be used in the respective diagram type, and which graphical representation should be used for this purpose. This means that the set of allowed
model elements depends on the concrete UML diagram, and the graphical representation of the same term may differ depending on the diagram, but the meaning remains the same.
From this, the meaning is independent of the graphical representation, which enables, for
example, the automatic transformation of UML models into other model types or directly into program code. In addition, the consistent separation of meaning and representation also enables a project- or company-specific extension or restriction of the UML.
In terms of language or information theory, however, UML elements do not have a fixed
representation, but only have to fulfill the rules of the UML metamodel, i.e., the abstract
syntax of the element. Other representations of a UML model are also possible in the form
of XML-compliant structures as a code file (e.g., for classes), as an abstract syntax tree of
the UML metamodel, or in the form of a natural language. More about UML principles can be found in the OMG Human Usable Text Notation.
The set of UML elements that the modeler assembles in a model is stored in a repository. This is usually a tool-dependent repository (e.g., a database or multiple files) that provides additional management services for team support, validations, tracing, etc.
UML therefore provides a set of possible terms and their graphical symbols for modeling a UML model and specifies rules for constructing these diagrams. For each element, it is specified with which other elements it may be connected and in what way, as well as what this connection means in concrete terms. This is analogous to the connections between the shapes in BPM. For example, classes in a UML class diagram are never directly connected; they are connected to each other via associations or inheritance.
What is a UML Use Case Diagram and which are its main notation elements?
A use case diagram is a list of actions or event
steps defining interactions within a role. The use case diagram is used to represent the most important functions of a system and
its interfaces in the system environment, providing an overview of the system and its
direct environment. Use case diagrams are used to determine and document the system context and to identify necessary interfaces of the system. The behavior of the system from the user’s point of view, or from the point of view of the peripheral systems connected via technical interfaces, is depicted on a very abstract level. However, the use case diagram does not show the sequence of single steps, but rather shows the principal relationships through communication or data structures.
The most important notation elements are:
* Use case: the main function of a system that must be executed in order to achieve a certain result.
* System frame: the object of consideration. The functional scope of a system is defined by the system boundary and the use case it contains. All elements outside the system boundary are also outside the system.
* Actor: a role or another system that interacts with the system under consideration. It can be a trigger for use cases that can achieve a certain result with the system. They may be required to achieve the result, but not be the trigger itself. Always outside the system boundary.
When would it be appropriate to have a Use Case Diagram?
The use case diagram (UCD) is suitable for the simple representation of the system’s functions to the outside world. Since the UCD does not contain any details about the system, it can be used, for example, to communicate with the user or management. It is also suitable as a form of documentation for the system overview and for determining the system context. In practice, it is often difficult to identify the right level at which use cases can be described. Thus, too few or too many use cases are often documented. As a rule, a use case is a task that is completed in several steps with which the actor wants to achieve a certain result. The use case should cover some activities and decisions made about events or status. When naming a use case, care should be taken to ensure that it is always an activity described with a full verb.
What is the UML Activity Diagram and which are its notation elements?
The UML activity diagram is a behavioral diagram used to model flows. The activity diagram is used when tasks must be broken down into their individual steps. While
no sequences or conditions are explicitly modeled in the use case diagram, the main task of the activity diagram is to visualize detailed processes with conditions, loops, and branches.
Notation elements include:
* Action: invocation or execution of a certain behaviour.
* Activities: complex actions that can be further detailed are modeled as activities. The details of an activity can be modeled in a separate activity slide.
* Starting point: of an activity, where the control flow starts.
* End point: of an activity, where the activity ends.
* Control flow: directed edge with an arrowhead that specifies the logical flow between the actions of an activity.
Notation elements for branching and merging:
* Condition/Status: the control flow is only considered if the condition is met or the status is like the one noted here. If not fulfilled, the flow stops here.
* Decision node: Processing will split based on a decision. The given condition that is met will be shown on the outgoing flow line [equivalent to the XOR gateway in BPMN]
* Merge node: this brings multiple process flows back into a single flow. Processing will only have occurred on one of the incoming flows.
* Parallelization/Fork: forks the incoming flow into different parallel flows. [corresponds to logical AND, or a logical OR as the outgoing flows are provided with conditions]
* Synchronization/Join: merges incoming flows into a commonn flow, it waits until all incoming flows have arrived [an AND join].
When is a UML Activity Diagram recommended?
The UML activity diagram is used in requirements engineering to refine and detail use cases. It is suitable for the representation of processes in interaction with business execution conditions. In particular, the activity diagram can also be used to describe required actions that are important in the event of an error or in exceptional situations. In principle, processes can also be modeled with BPMN or EPC instead of activity diagrams.
What is a UML Class Diagram and which are its notation elements?
The UML class diagram is a structure diagram that can be used to model business objects and systems. This diagram type is used at the overview level to represent general relationships, and at a system-oriented level to specify or document the attributes and methods for classes in object-oriented systems. In requirements engineering, especially with the focus on business requirements, only a basic form of the class diagram is used. Implementation-related information, such as visibility or technical data type, is deliberately omitted.
In particular, when documenting business objects, other domain-oriented entities, and
their properties and relationships to one another, the modeling of details (such as methods and data types) is deliberately omitted from the class diagram.
The class diagram is one of the most frequently used documentation forms in object-oriented system development. In principle, it can be used for the analysis and documentation of technical aspects, without a resulting object-oriented system at the end.
Notation elements include:
* Class: corresponds to a business entity or a business object.
* Class with properties/attributes: the properties relevant to a class are modeled as attributes in a rectangle under the class name.
* “Has/Knows” relationship: expresses that one class is related to the other class
* “Consists of/Is a” relationship: expresses that a class is a component of another class. It is used when a class is a larger construct whose elements cannot be described by simple attributes.
In order to graphically represent the relationships between classes, attributes, and methods, UML uses lines or arrows called associations, although this term has a different meaning than our previous use of the word. The simplest way to create relationships is to connect two classes with a solid line.
Explain the graphical representations of relations between classes.
- Straight solid line: a relationship is declared, but it is not explained in detail.
- Straight solid line with label: the relationship is declared and the association is explained by the label.
- Straight solid line with an open arrowhead with a label: a navigation direction is given by the arrowhead, this means that the first class knows where the item is stored in the second class but this class doesn’t know about the first class.
- Multiplicities at the end of association: can be used to specify quantities for relations. These specifications are noted at the end and at the top of a relation.
- Straight solid line with hollow arrowhead: the class pointed to by the arrowhead inherits all attributes of the class at the other end of the relationship.
Make some examples of multiplicities/cardinalities in Class Diagrams.
- 0..1: optional association
- 1: mandatory association
- 0..*: optional arbitrary
- 1..*: arbitrary, but 1 as a minimum
- n..m: minimum m and maximum n
When would it be appropriate to use a UML Class Diagram?
In the requirements engineering environment, the class diagram is used to documentvstatic concepts of an application area. This includes business objects; business entities (industry-specific things in the real world that are to be managed with information systems); people; objects; and systems and their relevant properties, relationships, and dependencies to each other. The primary goal is to document, understand, and communicate the domain-oriented problem. This means that the classes in the class diagram are regarded as concepts of the domain-oriented environment and not as elements of a system. A UML class corresponds to a domain-oriented concept, i.e., a set of objects with the same properties, such as customer, article, or order. The class diagram is not suitable for representing behavior or processes.
What is the UML State Diagram and which are its notation elements?
The UML state diagram is a behavioral diagram that can be used to document the functional states of objects or systems. In contrast to actions and processes, which are modeled in the activity diagram, the state diagram specifies which states an object or a system can assume, which dependencies or sequences exist between the states, and when they can be reached.
Notation elements include:
* State: certain technical situation of an object or a system, from which technical statements or necessary activities can be derived.
* Start state: starting point in the state diagram. All direct successor states of this start state are possible first domain-oriented states.
* End state: end point in the state diagram. All direct predecessor states of the final state are possible last states of the object or system.
* State transition: determines the order of the states
* Decision/Split: allows us to select the next transition dependent on a current result.
* Join: allows us to combine several transitions if the successor state is identical in each case.
When is a UML State Diagram appropriate?
State diagrams are used in requirements engineering to document life cycles or specific states of business objects and business entities. Since state diagrams do not model activities, but rather their effects on the business state, it is possible, for example, to use a state diagram to document which activities are permitted in which states. Since domain-oriented state transitions can be used to represent the entire life cycle of a business object in a very compact form, they are suitable as a supplement to an overview of the complex process or flow diagrams. Another use case for state diagrams is modeling call sequences of screen masks.
