SlideShare a Scribd company logo
1 of 10
Lecture 06

 The UML allows us to extend and reuse already
defined use cases by defining the relationship among
them. Use cases can be reused and extended in two
different fashions: extends and uses.
Relationship among Use Cases

Reuse and Extension
An Example

Extended User
An Example

 An elaborated use case has the following components:
 Priority: the relative implementation priority of the use case.
 Actors: names of the actors that use this use case.
 Summary: a brief description of the use case.
 Precondition: the condition that must be met before the use case can be
invoked.
 Post-Condition: the state of the system after completion of the use case.
 Extend: the use case it extends, if any.
 Includes: the use case it uses, if any.
 Normal Course of Events: sequence of actions in the case of normal
use.
 Alternative Path: deviations from the normal course.
 Exception: course of action in the case of some exceptional condition.
 Assumption: all the assumptions that have been taken for this use
case.
Describing a Use Cases

 Use Case Name: Delete Information
 Priority: 3
 Actors: User
 Summary: Deleting information allows the user to permanently remove
information from the system. Deleting information is only possible when
the information has not been used in the system.
Use Case Example
Delete Information
 Preconditions: Information was previously saved to the system and a user needs to
permanently delete the information.
 Post-Conditions: The information is no longer available anywhere in the system.
 Includes: Record Transactions, Cancel Action
 Extends: None
 Normal Course of Events:
1. The use case starts when the user wants to delete an entire set of information such as
a user, commission plan, or group.
2. The user selects the set of information that he/she would like to delete and directs
the system to delete the information. Exception 1, 2
3. The system responds by asking the user to confirm deleting the information.
4. The user confirms deletion.
Alternative Path: Cancel Action
5. A system responds by deleting the information and notifying the user that the
information was deleted from the system.
6. Uses: Record Transaction
7. This use case ends.
Use Case Example
Delete Information

 Alternative Path - The user does not confirm Deletion
1. If the user does not confirm deletion, the information does not delete.
2. Uses: Cancel Action
 Exceptions:
1. The system will not allow a user to delete information that is being
used in the system.
2. The system will not allow a user to delete another user that has
subordinates.
 Assumptions:
1. Deleting information covers a permanent deletion of an entire set of
data such as a commission plan, user, group etc. Deleting a portion
of an entire set constitutes modifying the set of data.
2. Deleted information is not retained in the system.
3. A user can only delete information that has not been used in the
system.
Use Case Example
Delete Information

Activity Diagram

 Usability
 Color blind people should not have any difficulty in using the system – color
coding should take care of common forms of color blindness.
 Reliability
 The system needs to support 7 x 24 operation
 Performance
 Authorization should be completed within 1 minute 90% of the time.
 Average authorization confirmation time should not exceed 30 seconds.
 Portability
 The system should run on Windows 98 and above as well as Sun Solaris 7.0 and
above.
 Access
 System should be accessible over the internet – hidden requirement – security
 Because of this shortcoming, use cases must be augmented by additional
information.
Limitations of Use Cases

More Related Content

Viewers also liked

Lecture 05
Lecture 05Lecture 05
Lecture 05Rana Ali
 
Lecture 01
Lecture 01Lecture 01
Lecture 01Rana Ali
 
Lecture 13
Lecture 13Lecture 13
Lecture 13Rana Ali
 
Lecture 04
Lecture 04Lecture 04
Lecture 04Rana Ali
 
Lecture 10
Lecture 10Lecture 10
Lecture 10Rana Ali
 
Lecture 14
Lecture 14Lecture 14
Lecture 14Rana Ali
 
Software Engineering - Lecture 02
Software Engineering - Lecture 02Software Engineering - Lecture 02
Software Engineering - Lecture 02Asifuzzaman Hridoy
 
Software engineering lecture notes
Software engineering   lecture notesSoftware engineering   lecture notes
Software engineering lecture notesAmmar Shafiq
 
CSC426 - Software Engineering Lecture Note
CSC426   - Software Engineering Lecture NoteCSC426   - Software Engineering Lecture Note
CSC426 - Software Engineering Lecture NoteBro Shola Ajayi
 
Software engineering lecture notes
Software engineering lecture notesSoftware engineering lecture notes
Software engineering lecture notesSiva Ayyakutti
 

Viewers also liked (11)

Lecture 05
Lecture 05Lecture 05
Lecture 05
 
Lecture 01
Lecture 01Lecture 01
Lecture 01
 
Nlp
NlpNlp
Nlp
 
Lecture 13
Lecture 13Lecture 13
Lecture 13
 
Lecture 04
Lecture 04Lecture 04
Lecture 04
 
Lecture 10
Lecture 10Lecture 10
Lecture 10
 
Lecture 14
Lecture 14Lecture 14
Lecture 14
 
Software Engineering - Lecture 02
Software Engineering - Lecture 02Software Engineering - Lecture 02
Software Engineering - Lecture 02
 
Software engineering lecture notes
Software engineering   lecture notesSoftware engineering   lecture notes
Software engineering lecture notes
 
CSC426 - Software Engineering Lecture Note
CSC426   - Software Engineering Lecture NoteCSC426   - Software Engineering Lecture Note
CSC426 - Software Engineering Lecture Note
 
Software engineering lecture notes
Software engineering lecture notesSoftware engineering lecture notes
Software engineering lecture notes
 

Similar to Lecture 06

Use Case Model with components in software.ppt
Use Case Model with components in software.pptUse Case Model with components in software.ppt
Use Case Model with components in software.pptTalhaTajammal1
 
SE_Lec 08_UML Use Cases
SE_Lec 08_UML Use CasesSE_Lec 08_UML Use Cases
SE_Lec 08_UML Use CasesAmr E. Mohamed
 
Requirement engineering.pptx
Requirement engineering.pptxRequirement engineering.pptx
Requirement engineering.pptxkeerthanakarthi
 
Operating System- INTERPROCESS COMMUNICATION.docx
Operating System- INTERPROCESS COMMUNICATION.docxOperating System- INTERPROCESS COMMUNICATION.docx
Operating System- INTERPROCESS COMMUNICATION.docxminaltmv
 
StructureofUseCases.ppt
StructureofUseCases.pptStructureofUseCases.ppt
StructureofUseCases.pptssuser28dc54
 
System Specification Report.
System Specification Report.System Specification Report.
System Specification Report.Shivakant Dubey
 
SOLUTION MANUAL OF OPERATING SYSTEM CONCEPTS BY ABRAHAM SILBERSCHATZ, PETER B...
SOLUTION MANUAL OF OPERATING SYSTEM CONCEPTS BY ABRAHAM SILBERSCHATZ, PETER B...SOLUTION MANUAL OF OPERATING SYSTEM CONCEPTS BY ABRAHAM SILBERSCHATZ, PETER B...
SOLUTION MANUAL OF OPERATING SYSTEM CONCEPTS BY ABRAHAM SILBERSCHATZ, PETER B...vtunotesbysree
 
ChrisGarrisonFeatherweightArchitecture-DetailDesign
ChrisGarrisonFeatherweightArchitecture-DetailDesignChrisGarrisonFeatherweightArchitecture-DetailDesign
ChrisGarrisonFeatherweightArchitecture-DetailDesignChris Garrison
 
Oruta privacy preserving public auditing for shared data in the cloud
Oruta privacy preserving public auditing for shared data in the cloudOruta privacy preserving public auditing for shared data in the cloud
Oruta privacy preserving public auditing for shared data in the cloudNexgen Technology
 

Similar to Lecture 06 (20)

2.1 usecase diagram
2.1 usecase diagram2.1 usecase diagram
2.1 usecase diagram
 
Use Case Model with components in software.ppt
Use Case Model with components in software.pptUse Case Model with components in software.ppt
Use Case Model with components in software.ppt
 
Usecase
UsecaseUsecase
Usecase
 
Lec-9.ppt
Lec-9.pptLec-9.ppt
Lec-9.ppt
 
Use case Diagram
Use case DiagramUse case Diagram
Use case Diagram
 
Google android Activity lifecycle
Google android Activity lifecycle Google android Activity lifecycle
Google android Activity lifecycle
 
Use case diagrams
Use case diagramsUse case diagrams
Use case diagrams
 
Use case diagrams
Use case diagramsUse case diagrams
Use case diagrams
 
SE_Lec 08_UML Use Cases
SE_Lec 08_UML Use CasesSE_Lec 08_UML Use Cases
SE_Lec 08_UML Use Cases
 
Requirement engineering.pptx
Requirement engineering.pptxRequirement engineering.pptx
Requirement engineering.pptx
 
Operating System- INTERPROCESS COMMUNICATION.docx
Operating System- INTERPROCESS COMMUNICATION.docxOperating System- INTERPROCESS COMMUNICATION.docx
Operating System- INTERPROCESS COMMUNICATION.docx
 
Use Cases
Use CasesUse Cases
Use Cases
 
Use Cases
Use CasesUse Cases
Use Cases
 
StructureofUseCases.ppt
StructureofUseCases.pptStructureofUseCases.ppt
StructureofUseCases.ppt
 
System Specification Report.
System Specification Report.System Specification Report.
System Specification Report.
 
Use case modeling
Use case modelingUse case modeling
Use case modeling
 
SOLUTION MANUAL OF OPERATING SYSTEM CONCEPTS BY ABRAHAM SILBERSCHATZ, PETER B...
SOLUTION MANUAL OF OPERATING SYSTEM CONCEPTS BY ABRAHAM SILBERSCHATZ, PETER B...SOLUTION MANUAL OF OPERATING SYSTEM CONCEPTS BY ABRAHAM SILBERSCHATZ, PETER B...
SOLUTION MANUAL OF OPERATING SYSTEM CONCEPTS BY ABRAHAM SILBERSCHATZ, PETER B...
 
ChrisGarrisonFeatherweightArchitecture-DetailDesign
ChrisGarrisonFeatherweightArchitecture-DetailDesignChrisGarrisonFeatherweightArchitecture-DetailDesign
ChrisGarrisonFeatherweightArchitecture-DetailDesign
 
Oruta privacy preserving public auditing for shared data in the cloud
Oruta privacy preserving public auditing for shared data in the cloudOruta privacy preserving public auditing for shared data in the cloud
Oruta privacy preserving public auditing for shared data in the cloud
 
Crime
CrimeCrime
Crime
 

Lecture 06

  • 2.   The UML allows us to extend and reuse already defined use cases by defining the relationship among them. Use cases can be reused and extended in two different fashions: extends and uses. Relationship among Use Cases
  • 5.   An elaborated use case has the following components:  Priority: the relative implementation priority of the use case.  Actors: names of the actors that use this use case.  Summary: a brief description of the use case.  Precondition: the condition that must be met before the use case can be invoked.  Post-Condition: the state of the system after completion of the use case.  Extend: the use case it extends, if any.  Includes: the use case it uses, if any.  Normal Course of Events: sequence of actions in the case of normal use.  Alternative Path: deviations from the normal course.  Exception: course of action in the case of some exceptional condition.  Assumption: all the assumptions that have been taken for this use case. Describing a Use Cases
  • 6.   Use Case Name: Delete Information  Priority: 3  Actors: User  Summary: Deleting information allows the user to permanently remove information from the system. Deleting information is only possible when the information has not been used in the system. Use Case Example Delete Information
  • 7.  Preconditions: Information was previously saved to the system and a user needs to permanently delete the information.  Post-Conditions: The information is no longer available anywhere in the system.  Includes: Record Transactions, Cancel Action  Extends: None  Normal Course of Events: 1. The use case starts when the user wants to delete an entire set of information such as a user, commission plan, or group. 2. The user selects the set of information that he/she would like to delete and directs the system to delete the information. Exception 1, 2 3. The system responds by asking the user to confirm deleting the information. 4. The user confirms deletion. Alternative Path: Cancel Action 5. A system responds by deleting the information and notifying the user that the information was deleted from the system. 6. Uses: Record Transaction 7. This use case ends. Use Case Example Delete Information
  • 8.   Alternative Path - The user does not confirm Deletion 1. If the user does not confirm deletion, the information does not delete. 2. Uses: Cancel Action  Exceptions: 1. The system will not allow a user to delete information that is being used in the system. 2. The system will not allow a user to delete another user that has subordinates.  Assumptions: 1. Deleting information covers a permanent deletion of an entire set of data such as a commission plan, user, group etc. Deleting a portion of an entire set constitutes modifying the set of data. 2. Deleted information is not retained in the system. 3. A user can only delete information that has not been used in the system. Use Case Example Delete Information
  • 10.   Usability  Color blind people should not have any difficulty in using the system – color coding should take care of common forms of color blindness.  Reliability  The system needs to support 7 x 24 operation  Performance  Authorization should be completed within 1 minute 90% of the time.  Average authorization confirmation time should not exceed 30 seconds.  Portability  The system should run on Windows 98 and above as well as Sun Solaris 7.0 and above.  Access  System should be accessible over the internet – hidden requirement – security  Because of this shortcoming, use cases must be augmented by additional information. Limitations of Use Cases