In the File Validator component, the abstract use case is “Validate XML File”. Generally speaking, the extend relationship shows that the use case at the origin of the extend arrow decorates the extending use case somehow, with some sort of specific implementation. Extend Relationships: The extend relationship shows a relationship from a concrete use case, normally to an abstract use case that is used to show that the concrete use case provides the functionality of the abstract use case in an implementation specific way. It should be marked with an ">" stereotype. The include relationship is shown by a dashed arrow from one use case to the other use case the first will use. Include Relationships: The include relationship defines a relationship between two use cases where one use case uses the functionality in another use case as part of its processing. The generalization relationship isn’t used very often, and is not covered in the sample Use Case diagrams given by TopCoder for designers. There is a third available (a generalization relationship) that is very similar to an extend relationship, with some minor differences. Relationships: There are two main relationships that are normally used - include and extend. In this case a “Validate XML file” abstract use case should be used to group the two separate, concrete use cases. Both of these validation types perform the same type of operation, but their implementations are different. In the File Validator component, we have two different XML validation schemes, DTD and XSD validation. For instance, if we have two use cases that have similar functionality, but different implementations, they can be grouped with an abstract use case. Instead, it defines common functionality that is shared between multiple use cases. Abstract Use Case: An abstract (or sometimes called aggregate) use case doesn’t describe functionality that can get called by the user. A concrete use case is used directly by the actor to perform some sort of operation.Ĥ. Normally, concrete use cases directly map to a part of the API in the component that the user can call to perform some operation. Use Cases: A use case describes the actual functionality that can be performed with the component, like “Validate file,” or “Format code,” or “Convert a value from one unit to another.” There are two main types of use cases, concrete and abstract use cases.Ĭoncrete Use Case: A concrete use case defines functionality that the actor can use directly. Sometimes though, there could be other actors, possibly the “User.” The “User” is often seen as an actor in web components that the user directly interacts with, like the Calendar Tag component. Normally, for TopCoder components, the main actor is just an “Application”, as the components are normally libraries that use the component we are designing. It should describe, in simple terms, all major functionality that can be accomplished with a component Use Case ItemsĪ use case is made up of the following items:Īctors: Actors describe the item that uses the functionality of the component. Use Case DiagramsĪ use case diagram is a simple diagram that describes what can be done with the component. Throughout this tutorial we will focus on the File Validator component, using that component to show the right and wrong ways to create the use case and sequence diagrams. This article will cover the standard parts of each diagram and how they fit together, at the proper level, to create a diagram that will help developers and users. The goal of this article is to provide a good understanding of what use case and sequence diagrams are, how they are properly created, and how they can influence a design.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |