Explore chapters and articles related to this topic
Generation of Use Case UML Diagram from User Requirement Specifications
Published in Ibrahiem M. M. El Emary, Anna Brzozowska, Shaping the Future of ICT, 2017
Wahiba Ben Abdessalem, Eman H. Alkhammash
A use case diagram is a UML diagram used to capture functional requirements and model the dynamic aspects of the system. Use cases play important roles in the early stages of the development of the system. A use case diagram represents an abstract view of the systems and isolates details to better understand the portion of the system of concern (OMG, 2016b). UML use case diagrams consist of four main elements, which are system, actors, use cases, and relations. The actors, depicted by stickman icon, represent system/people that interact with the modeled system. The use cases, depicted by named ellipses, represent main functionalities provided by the system). The relations (association, dependency, and generalization) are used to indicate interactions between components. An association relationship is used between actors and uses cases. Generalization can be used between actors when they have the same roles. The common relationships used between use cases are generalization and dependencies. Generalization is used to show a parent–child relationship between use cases; thus it is used when two or more use cases have similar behaviors. Generalization is shown as a directed arrow with a triangle arrowhead. The child use case is connected at the base of the arrow, as shown in Figure 16.4. The two use cases PIN and Fingerprint are a “child” of the Customer Authentication use case.
From Cognitive Work Analysis to Software Engineering
Published in Neville A. Stanton, Paul M. Salmon, Guy H. Walker, Daniel P. Jenkins, Cognitive Work Analysis, 2017
In UML, the use case diagram graphically presents the behaviour of the system. It shows the relationship between actors in a system and the actions (use cases) that they are able to perform. In addition to representing the behaviour of the system, use case diagrams can also be used to imply the structure of the system, in terms of the associations between use cases and between actors. The concept of actors can be related directly to the SOCA-CAT and to the objects in the AH. Use cases can be considered in terms of object-related functions in the AH, and the relationships between elements come from the lower level of the AH. Thus, Figure 5.4 shows the collection of use cases that relate to the functional purpose of ‘listen to music’ (through headphones). If we wished to consider listening to music through hi-fi or in-car entertainment system or personal computer, then we just replace the ‘headphones’ actor. We have shaded the heads of some of the actors because these are all part of the iPod system (hence the border around these (Table 5.1).
Object-Oriented Models
Published in Paul C. Jorgensen, The Craft of Model-Based Testing, 2017
The use case diagram simply provides an overview of the connections among actors (sources and destinations of system level inputs and outputs) with individual use cases. In some ways, this is reminiscent of the Context Diagram of (Yourdon style) Structured Analysis. Activity diagrams are a blend of ordinary Petri nets and flowcharts. As such, they are intuitively obvious, easy to create, and easily understood. The state machine diagram of choice is a simplified version of Statecharts (see Chapter 7). Finally, there is the sequence diagram, which is one of the few models anywhere that directly combines the IS and DOES views.
A supportive situation awareness model for human-autonomy teaming in collaborative driving
Published in Theoretical Issues in Ergonomics Science, 2020
Rinta Kridalukmana, Hai Yan Lu, Mohsen Naderpour
In software development, one technique that can be used to model the relation between functions is a use case diagram (see Figure 6), which was introduced by Jacobson (1993). In this technique, a use case that represents a function could have three types of relationships: a generalized relationship (GR), a normal relationship (NR) and an extended relationship (ER) (Chanda et al. 2009). A GR is intended to relate functions and their sub-functions. An NR between two use cases means that the behaviour of a use case is explicitly incorporated by another use case incorporating it (Shen and Liu 2003). When the behaviour is extended to another use case in the case of a special event, it can be described as an ER. Furthermore, an agent performing functions or sub-functions in a use case diagram is referred to as an actor, which can be either a human or non-human agent. A line is used to connect actors to functions or sub-functions.
Privacy risk in contact tracing systems
Published in Behaviour & Information Technology, 2023
Conceptual diagrams do not depict specific technologies and thus are technology-neutral, intended to apply regardless of any technology used. Conceptual diagrams are commonly used by systems analysts to understand, analyse and communicate aspects of an information system (Burton-Jones and Meso 2006; Wand and Weber 2002), including information risk (Mead et al. 2017; Spears and Parrish 2013). A use case diagram is a conceptual model that depicts how actors (i.e. participants) interact with core system functions. Figure 1 depicts a technology-neutral contact tracing system that may be manually performed and/or include a smartphone app for automating certain functions. There are ten use cases (i.e. system functions, represented as ellipses) and six unique actors in Figure 1.
A system modeling process based on SysML to support data consistency across system requirement, function, and solution model layers
Published in Journal of Engineering Design, 2023
Yizhe Zhang, Georg Jacobs, Wei Yu, Gregor Hoepfner, Joerg Berroth
SysML provides system engineers with a visual modeling environment by using SysML diagrams. The critical system diagrams for modeling in this work are described as follows: Requirement diagram (req) – captures and presents document-based requirements with textual descriptions. It shows the relationships (e.g. derivation, satisfaction, verification, and refinement) among requirements and model elements that satisfy them.Use case diagram (uc) – shows communications among use cases and actors to accomplish a set of system objectives.Package diagram (pkg) – presents the organization of the model into packages that contain model elements. It facilitates model navigation and reuse, access, and change control.Block definition diagram (bdd) – presents system elements with their contents (e.g. properties, behaviours, constraints), Interfaces, and relationships. It shows the system hierarchy and classifications of system elements.Internal block diagram (ibd) – presents the internal structure of elements in terms of properties and ports between properties. It describes how the parts within the system are interconnected.Parametric diagram (par) – is a specialization of an ibd that enforces mathematical rules (i.e. constraints) defined by constraint blocks that are bound to properties of system elements. The par can be integrated with other engineering analysis models and tools to execute the detailed engineering analysis.