Use Case Diagrams provide a good view of a system. The arrow points to the included use case.ĭistribution of Use Cases on Different Diagrams The include relationship is represented in a use case diagram by a dashed arrow and the include caption. In contrast to generalisation, no properties are inherited.Descriptions can be used as often as desired by include relationships.Detailing in included use cases should be avoided. Primary and secondary use cases should be described at similar levels of abstraction.An included use case can also be executed separately.However, the time of execution cannot be specified in the diagram the specification is suitable for this. An included use case is ALWAYS executed when the included use case is executed.There are five aspects to include relationships: In practice, secondary use cases are often marked with the stereotype “secondary”, even if this is not provided for in UML. It is useful to model an include relationship if parts of use cases occur in several use cases. The include relationship links a primary or base use case with one or more secondary use cases. All modeled elements are documented in a specification, ideally also with alternative procedures and the behavior description in case of an error. A Use Case Diagram thus represents a sketch of the system, which indicates the purpose of the planned system including boundaries and interfaces. The individual cases are recorded and visualised as use cases. The system analysis determines what a system should achieve from the user’s point of view. Implementation details, such as the system architecture or the programming language to be used, are not yet important in this phase and can be discussed in subsequent steps. They are well suited for communication and analysis of system behavior because they can be used to define the functionality of the system from the user’s point of view. They can be used to record requirements for a system – consisting of software and/or hardware. Use Case Diagrams are often used in the context of a requirements analysis or in the process of requirements engineering.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |