Icon class icon_class fas fa-quote-left icon_class_computed fas fa-quote-left Related content UseCases - UML subject vs SysML Block Package, Model, or SysML Block as UseCase owner Webel: SysML for MBSE: The frequent recommendation that each UseCase have at least one "primary" scenario is a very useful and highly recommended CONVENTION (only). But it is not actually enforced by the SysML1.7 or UML2.5.1 metamodels or specifications. Webel: MBSE: SysMLv1: Prefer a custom «actor» extension of a Block (such as the non-normative External) over UML-style Actor for use as parts in IBDs and on allocation swimlanes. You can also have a Trace from a block-based «actor» to a UML-style Actor. SysMLv1: MagicDraw/Cameo: INTRINSIC GOTCHA: Care must be taken with ownership of Activities used as UseCase scenarios vs the ‘subject’ of the UseCase. Make sure you don’t get an Activity ‘context’ mismatch! It's up to you to manage it as intended. SysMLv1: MagicDraw/Cameo: Having a SystemContext as the 'subject' of each main UseCase plays nicely with the feature for automated creation of usage-level allocation swimlanes in SysML Activity Diagrams for part properties. But it's not the only way. SysMLv1: "Should" the 'subject' of a top-level UseCase be a System or (a particular) SystemContext? Answer: Which one would you like to be correct!? [WITH EXTERNAL LINKS] SysMLv1: A common misunderstanding: Just because a UseCase symbol appears inside the rectangle of a subject Classifier does NOT mean that it is owned by that Classifier and can only have that one Classifier as 'subject', and it does not imply ownership! Webel: SysMLv1: Overview of annotated Diagram Slides and Note pages related to UseCases and their combination with a System (of interest), SystemContext, and drill-down to scenario Sequence Diagrams (Interactions) and Activity Diagrams. Source Unified Modeling Language 2.5.1 Copyright information About Object Management Group copyright in text extracts quoted from OMG specifications for educational purposes Snippet kind INFO UML keywords UseCase UseCase::subject Classifier Behavior Actor Previous snippet Full quote A UseCase may apply to any number of subjects. When a UseCase applies to a subject, it specifies a set of behaviors performed by that subject, which yields an observable result that is of value for Actors or other stakeholders of the subject. Next snippet A UseCase is a kind of BehavioredClassifier that represents a declaration of a set of offered Behaviors. Each UseCase specifies some behavior that a subject can perform in collaboration with one or more Actors. Related snippets A subject for a set of UseCases (sometimes called a system boundary) may be shown as a rectangle with its name in the top-left corner, with the UseCase ellipses visually located inside this rectangle. Related snippets (backlinks) UseCases define the offered Behaviors of the subject without reference to its internal structure. These Behaviors, involving interactions between the Actors and the subject, may result in changes to the state of the subject and communications with its... A UseCase can include possible variations of its basic behavior, including exceptional behavior and error handling. A subject of a UseCase could be a system or any other element that may have behavior, such as a Component or Class. Each UseCase specifies a unit of useful functionality that the subject provides to its users (i.e., a specific way of interacting with the subject). This functionality must always be completed for the UseCase to complete. It is deemed complete if, after its execution, the subject will be in a state in which no further inputs or actions are expected and the UseCase can be initiated again, or in an error state. UseCases can be used both for specification of the (external) requirements on a subject and for the specification of the functionality offered by a subject. Moreover, the UseCases may also state the requirements the specified subject poses on its environment by defining how the Actors should interact with the subject so that it will be able to perform its services. The behaviors of a UseCase can be described by a set of Behaviors (through its ownedBehavior relationship), such as Interactions, Activities, and StateMachines, as well as by pre-conditions, post-conditions and natural language text where appropriate. It may also be described indirectly through a Collaboration that uses the UseCase and its Actors as the Classifiers that type its parts. UseCases may have associated Actors, which describe how an instance of the Classifier realizing the UseCase and a user playing one of the roles of the Actor interact. Two UseCases specifying the same subject cannot be associated as each of them individually describes a complete usage of the subject. A UseCase may be owned either by a Package or by a Classifier. Although the owning Classifier typically represents a subject to which the owned UseCases apply, this is not necessarily the case ... The use case diagram describes the usage of a system (subject) by its actors (environment) to achieve a goal, that is realized by the subject providing a set of services to selected actors. Visit also Visit also (backlinks) Flags
