GENERALIZATION IN USE CASE DIAGRAMS PASSWORD

In the include relationship, the base use case incorporates the include use case. It is somewhat similar to the include relationship but the direction of adding behaviour sequence to the base use case is opposite. The dashed arrow is always annotated by the keyword > to show the include relationship.Įxtend relationship adds up behavior sequence to the base use case. Like, in the above figure the arrow head is pointed towards the validate password. The arrow head is pointing towards the included use case. The include relationship is presented with a dashed arrow in UML diagram.

GENERALIZATION IN USE CASE DIAGRAMS PASSWORD

You can observe in the figure above that though use case validate password is repeatedly used by other use cases and it is modelled only once. So, the use cases secure session includes the use case ‘validate password’ and similarly make a trade use case also includes validate password use case. Now, whenever a user establishes a secure session it includes validation of passwords and whenever the user make a stock trade then also the passwords are validated. Now, consider an online stock brokerage system which involves several uses cases among which three would be secure session, make a trade and validate password. Let’s move on an example which would help us in understanding the include relationship among the use cases more clearly. The include use case may or may not appear as behavior sequence on its own. Include use case is similar to subroutines, as they are the set of instructions which are repeatedly used in the program, but this set of instructions is written only once and are called whenever required. The use cases that need to be described repeatedly for a complex or a large system are modelled once and included in the other uses cases when required. Include relationship is modelled between the use cases when a use case includes the behavior sequence of another use case. The kinds of relations that could be modelled between use cases are as follow: The independent use cases can represent a simple application but to represent the complex or large applications the system analyst needs to structure the complex relationship between the use cases.Įstablishing relationships between the use cases allow reusing those use case which needs to be defined repeatedly and this reduces the efforts of developers. A use case represents a bit of systems functionality and actors are the objects which interact with the system to get the work done from the system for which it is designed. A use case diagram has a set of ‘use cases’ and ‘actors’. In our previous content, we have discussed the use case diagram which represents the working of the system. We will also discuss the kind of relationship that can be structured between the use cases. In this section, we will discuss in brief about modelling the relationship between use cases to represent a large and complex system.

Generalization in use case diagrams