Trigger: -Things which makes use case starts through an actor is called Trigger. For example user starts the application. Pre-condition:-These are conditions in a use case to be considered as pre-requirements such as to book a air ticket we need to have server connection and also we have to validate in to the system then only the actor can book a ticket for the customer. Assumptions: - These are assumptions which we define for the system. Failed end conditions: -This state signifies when the use case will fail. For when User Id and Password is not proper id displayed on the Login screen it signifies login failed condition. Actions : - This is the basic action by which the main scenario of the use case starts such as login onto the system or to make booking of tickets we actually perform actions like click on Login----File----New----Booking menu which in return opens the page of booking section. Main scenario: -It describes the basic step which should be executed by the user. For instance below steps show the main scenario steps : - o Travel agent logs in to the system. o Travel agent goes to the ticket booking form. o He enters Ticket Number, Travel routes of the customer, details of the customer etc. o Finally he adds the ticket to the system and prints the ticket. Alternate scenario: - Alternate scenarios are steps which have a slight different flow other than the main scenario. The main scenario and the alternate scenario have many steps in common but with a slight difference. For instance below is the alternate scenario step which is different than the main scenario: - o Travel agent logs in to the system. o Travel agent goes to the ticket booking form and enters the ticket number. o Travel agent is then popped with all details regarding the ticket booking. o Travel agent makes changes to the existing information. o Once the changes are done the travel agent updates the information and prints out the ticket. Success scenario: -Success scenarios indicate when this use case is successful. For example the ticket is printed successfully, email is sent to the customer etc etc. Note and open issues: - Some pending task about the use case which the customer needs to make more clarification . For example from where does Page 29 of 215
exactly the booking of air tickets happens, is it directly from the customer itself or from the traveling agency. Figure 1.9:- Use Case template Note: - In every project we have use case documents as a part of requirement gathering. So once you go through those use case you will have good understanding of the same. Included and Extended use case In use cases we come across identical sequences between the actors and the system if such kind of common sequence is not identified in use case document it can lead to redundancy in the project. Because the requirement document trickles down to the technical document which can lead to lot of redundancy coding. Included and extended are the types of use cases which can be used to club together such common sequences. Included use case: -Below figure shows the included use case in an shoppingmall.com project and uses the Included use case in the form of “check credit cards” for customers. Let’s try to understand the following example of a customer where he orders the flowers, greeting cards and cassettes but the payment is always done through the credit card. So here flowers, greeting cards and cassettes always have to execute the check credit card (common use case). So we make the check credit card use case as an included use case. Page 30 of 215
Figure 1.10:- Included Use case in action This kind of common interaction can be put in a common use case and called whenever needed. Extended use case system:-While writing use case it is possible to have multiple version of the same use case. For instance you have to add a new customer and then you can also update a customer. So update customer use case is an Extension of add new customer use case. Figure 1.11: - Extended Use Case Page 31 of 215
Differentiate between Included use case and extended use cases? If you need to deliver the use case with the base use case then it will form an included use case type of relationship. But if use case can be delivered later and have steps in common then its base use case forms an Extended use case type of relationship. The one thing in common is that they have some common steps in sequence. Class diagram In this book for all projects the other diagram that will be extensively used is the class diagram.Class is basically prototype which helps us create objects. Class defines the static structure of the project. A class represents family of an object. By using Class we can create uniform objects. In the below figure you can see how the class diagram looks. Basically th ere are three important sections which are numbered as shown in the below. Let’s try to understand according to the numbering:- Class name: -This is the first section or top most section of the Class which represents the name of the Class (clsCustomer). Attributes: -This is the second section or the middle section of the class which represents the properties of the system. Methods: - This section carries operation or method to act on the attributes. Figure 1.12: - Three sections of the class In the previous section we have seen what basically the class is. Now in the next section we will have a look on Association relationship between these classes Associations in Class diagrams A single Class cannot represent the whole module in a project so we need one or more classes to represent a module. For instance, a module named ‘customer detail’ cannot be completed by customer class in order to complete the whole module we need customer class, address class, phone class in short there is relationship between the classes. So by grouping and relating between the classes we create module and these are termed as Association. In order to associate them we need to draw the arrowed lines between the classes as shown in the below figure. Page 32 of 215
In this figure, we can see Order class and the Payment class and arrowed line showing relationship that order class is paid using payment class in other words order class is going to be used by payment class to pay the order. The left to right marked arrow basically shows the flow that order class uses the payment class. In case payment class using the order class then the marked arrow should be right to left showing the direction of the flow. Figure 1.13:- Order is paid by Payments class There are four signs showing the flow: - Figure 1.14:- Direction signs in UML Multiplicity Multiplicity can be termed as classes having multiple associations or one class can be linked to instances of many other classes. If you look at the below figure the customer class is basically associated with the address class and also observes the notations (*, 0 and 1).If you look at the right hand side the (1….*) notation indicates that at least one or many instance of the address class can be present in the customer class. Now towards left hand side we have (0….*) notation indicating that address class can exist without or many customer class can link him. In order to represent multiplicity of classes we h ave to show notations like (1….*), (0….*) as shown in below figure. Note: ‘*’ means “many” where as ‘(0, 1)’ means “(zero or at least one)” respectively. Page 33 of 215
Figure 1.15: - Multiplicity in Classes Aggregation and composition In this Association there are two types mainly Aggregation Association and Composition Association. Aggregation Association signifies that the whole object can exist without the Aggregated Object. For example in the below figure we have three classes university class, department class and the Professor Class. The university cannot exist without department which means that university will be closed as the department is closed. In other words lifetime of the university depend on the lifetime of department. In the same figure we have defined second Association between the department and the Professor. In this case, if the professor leaves the department still the department continues in other words department is not dependent on the professor this is called as Composition Association. Note: - The filled diamond represents the aggregation and the empty diamond represents the composition. You can see the figure below for more details. Page 34 of 215
Figure 1.16: - Aggregation and composition in action Composite structure diagram When we try to show Aggregation and Composition in a complete project the diagram becomes very complicated so in order to keep it simple we can use Composite structure diagram. In the below figure we have shown two diagrams one is normal diagram other is Composite structure diagram and the simplicity can easily be identified. In the composite diagram the aggregated classes are self contained in the main class which makes it simpler to read. Figure 1.17: - Composite Structure diagram Page 35 of 215
exactly the booking of air tickets happens, is it directly from the customer itself or from the traveling agency. Figure 1.9:- Use Case template Note: - In every project we have use case documents as a part of requirement gathering. So once you go through those use case you will have good understanding of the same. Included and Extended use case In use cases we come across identical sequences between the actors and the system if such kind of common sequence is not identified in use case document it can lead to redundancy in the project. Because the requirement document trickles down to the technical document which can lead to lot of redundancy coding. Included and extended are the types of use cases which can be used to club together such common sequences. Included use case: -Below figure shows the included use case in an shoppingmall.com project and uses the Included use case in the form of “check credit cards” for customers. Let’s try to understand the following example of a customer where he orders the flowers, greeting cards and cassettes but the payment is always done through the credit card. So here flowers, greeting cards and cassettes always have to execute the check credit card (common use case). So we make the check credit card use case as an included use case. Page 30 of 215
Figure 1.10:- Included Use case in action This kind of common interaction can be put in a common use case and called whenever needed. Extended use case system:-While writing use case it is possible to have multiple version of the same use case. For instance you have to add a new customer and then you can also update a customer. So update customer use case is an Extension of add new customer use case. Figure 1.11: - Extended Use Case Page 31 of 215
Differentiate between Included use case and extended use cases? If you need to deliver the use case with the base use case then it will form an included use case type of relationship. But if use case can be delivered later and have steps in common then its base use case forms an Extended use case type of relationship. The one thing in common is that they have some common steps in sequence. Class diagram In this book for all projects the other diagram that will be extensively used is the class diagram.Class is basically prototype which helps us create objects. Class defines the static structure of the project. A class represents family of an object. By using Class we can create uniform objects. In the below figure you can see how the class diagram looks. Basically th ere are three important sections which are numbered as shown in the below. Let’s try to understand according to the numbering:- Class name: -This is the first section or top most section of the Class which represents the name of the Class (clsCustomer). Attributes: -This is the second section or the middle section of the class which represents the properties of the system. Methods: - This section carries operation or method to act on the attributes. Figure 1.12: - Three sections of the class In the previous section we have seen what basically the class is. Now in the next section we will have a look on Association relationship between these classes Associations in Class diagrams A single Class cannot represent the whole module in a project so we need one or more classes to represent a module. For instance, a module named ‘customer detail’ cannot be completed by customer class in order to complete the whole module we need customer class, address class, phone class in short there is relationship between the classes. So by grouping and relating between the classes we create module and these are termed as Association. In order to associate them we need to draw the arrowed lines between the classes as shown in the below figure. Page 32 of 215
In this figure, we can see Order class and the Payment class and arrowed line showing relationship that order class is paid using payment class in other words order class is going to be used by payment class to pay the order. The left to right marked arrow basically shows the flow that order class uses the payment class. In case payment class using the order class then the marked arrow should be right to left showing the direction of the flow. Figure 1.13:- Order is paid by Payments class There are four signs showing the flow: - Figure 1.14:- Direction signs in UML Multiplicity Multiplicity can be termed as classes having multiple associations or one class can be linked to instances of many other classes. If you look at the below figure the customer class is basically associated with the address class and also observes the notations (*, 0 and 1).If you look at the right hand side the (1….*) notation indicates that at least one or many instance of the address class can be present in the customer class. Now towards left hand side we have (0….*) notation indicating that address class can exist without or many customer class can link him. In order to represent multiplicity of classes we h ave to show notations like (1….*), (0….*) as shown in below figure. Note: ‘*’ means “many” where as ‘(0, 1)’ means “(zero or at least one)” respectively. Page 33 of 215
Figure 1.15: - Multiplicity in Classes Aggregation and composition In this Association there are two types mainly Aggregation Association and Composition Association. Aggregation Association signifies that the whole object can exist without the Aggregated Object. For example in the below figure we have three classes university class, department class and the Professor Class. The university cannot exist without department which means that university will be closed as the department is closed. In other words lifetime of the university depend on the lifetime of department. In the same figure we have defined second Association between the department and the Professor. In this case, if the professor leaves the department still the department continues in other words department is not dependent on the professor this is called as Composition Association. Note: - The filled diamond represents the aggregation and the empty diamond represents the composition. You can see the figure below for more details. Page 34 of 215
Figure 1.16: - Aggregation and composition in action Composite structure diagram When we try to show Aggregation and Composition in a complete project the diagram becomes very complicated so in order to keep it simple we can use Composite structure diagram. In the below figure we have shown two diagrams one is normal diagram other is Composite structure diagram and the simplicity can easily be identified. In the composite diagram the aggregated classes are self contained in the main class which makes it simpler to read. Figure 1.17: - Composite Structure diagram Page 35 of 215
ليست هناك تعليقات:
إرسال تعليق