1 / 39

Software Requirements Analysis using UML

Learn how to model requirements using UML diagrams such as use case, class, activity, sequence, collaboration, object, state, deployment, and component diagrams. Understand the advantages of the Use Case technique and when it should be used.

whorton
Télécharger la présentation

Software Requirements Analysis using UML

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. تحليل متطلبات البرمجياتSoftware Requirements AnalysisITSE 311Requirements Analysis using UMLchapter 8د.حنانالداقيزh.dagez@uot.edu.ly

  2. model the requirement

  3. Model for requirements analysis : • Analysis model is a diagram that represents requirements visually. • Models can expose incorrect, inconsistent, and missing requirements. Such models include data flow diagrams, entity-relationship diagrams,, use cases diagram, class diagram and others.

  4. These models are useful for elaborating and exploring the requirements, as well as for designing software solutions. Whether you are using them for analysis or for design depends on the timing and the intent of the modeling. • The analysis modeling techniques described in this chapter are UML tools. Used for requirements analysis, these diagrams let you create conceptual representations of the new system.

  5. UML • UML stands for Unified Modelling Language. • UML is a standard language for specifying, visualizing, constructing, and documenting the artifacts of software systems. • UML is not a programming language, it is different from the other common programming languages like C++, Java, COBOL etc.

  6. UML diagrams are not only made for developers but also for business users, common people and anybody interested to understand the system. • It is an important part for the development of object-orientation systems UML Diagrams: UML diagrams are the final output of the entire discussion. All the elements, relationships are used to make a complete UML diagram and the diagram represents a system.

  7. UML consists of the following diagrams:- • 1. Use case diagram • 2. Class diagram • 3. Activity diagram • 4. Sequence diagram • 5. Collaboration diagram • 6. Object diagram • 7. State diagram • 8. Deployment diagram • 9. Component diagram

  8. Use case Diagrams • Use Case Diagram(UCD) An analysis tool used to show the functional requirements of the system. • Use case diagrams, used to show the relationships between actors external to the system and the use cases with which they interact. • UCD is a combination of use cases (functions) and actors (users or external systems) interacting together to perform the transactions of the system.

  9. Advantages of the Use Case technique • Use cases are easy to write • Use cases are written in the language of the users • Use cases link requirements activities to design and implementation • The graphical representation of use cases improves understandability of complex systems

  10. When should the Use Case technique be used • When the system is functionally oriented • Full of functionality and there are many types of system users • When the project team implementing the system using UML and the OO methods. • Use cases are most appropriate when the system is rich in functionality and must support different types of users.

  11. When Use Cases are not the best choice? • In systems with few or no users and minimal interface: take for example embedded systems, virus scanning systems, and compilers.

  12. A step-by-step procedure of defining a use-case • Actor: someone/something that interacts with our systems (person, organization or an external system) • Define the actor (s): • Define exactly who is to interact with the system • In many systems look for the humans who will use the system. • In some systems we look for other systems that interact with the system • It is helpful to keep a list of actors

  13. A step-by-step procedure of defining a use-case (Cont.) • Define the Use Case by Naming it • Each use case should have a unique name • The name indicates what is achieved by the user interaction. • A use case name usually starts by an action verb.

  14. A step-by-step procedure of defining a use-case (Cont.) • Write a brief description • The description of the use case should reflect its role and purpose. • When writing use cases refer to the actors. • The description is an informal overview of functionality.

  15. A step-by-step procedure of defining a use-case (Cont.) • Define a flow of events • This is the heart of the use case. • It is a textual description of user action and system responses. • The flow of events can be a basic flow or alternative flow. • Basic flow shows the event when the action is successful • The alternative flow show what happens if something goes wrong.

  16. A step-by-step procedure of defining a use-case (Cont.) • Identify pre-and post-conditions • Pre-conditions are those condition that should be true for the action to take place. • Post-conditions shows what happened after initiating the use case. • Use them only when necessary.

  17. Example: use-case from the Library system (identify problems)

  18. Example: use-case from the Library system (identify problems)

  19. The general form of use case diagram is Use Case Use Case Actor actor Boundary

  20. Symbols of use case diagram • Actor • An actor is a role that a user , or an external system plays with the proposed system. • Examples: salesman, customer, Manager, Billing system. Actor

  21. Use Case • It is a procedure by which the actors interact with the system. use case is simply a transaction or function. • The shape of use case is an oval as follows: • The procedure to be implemented in this use case is written inside this oval shape as following examples: Check Item Make order

  22. Boundary It defines the scope (limits) of the system. in the diagram it is represented by a line (rectangle) surrounding the system and separating it from its environment. Use Case Boundary Use Case

  23. Relationships • There are 3 types of relationships: • A relationship between actor and use case, called association • A relationship between a use case and another, called extendand include • A relationship between actors or between use cases, called generalization

  24. Association Relationship: • It is a line linking an actor with use case(s) to show that an actor performs the use cases(s) association Example: in the following figure, a salesman performs many use cases: Check Credit and Prepare invoice.

  25. Check Credit Prepare invoice Salesman Example2: View Grade Teacher Student

  26. Extend / Include Relationship: • a use case can also be related to another use case. there are two types of relationships between use cases. • Include Relationship • Use case include is a directed relationship between two use cases which is used to show that behavior of included use case(the addition) is inserted into the behavior of including (the base) use case.

  27. An include relationship is used to show that one use case called base includes the tasks described by another use case or cases. Example 1: Make Order include include include enter order detail prepare invoice arrange payments

  28. Example2:

  29. 2. Extend Relationship. • Extended use case is meaningful on its own, it is independent of the extending use case. Extending use case typically defines optional behavior that is not necessarily meaningful by itself. Example 1: Pay bill extend extend pay in check pay in cash

  30. Example2: extend Example 3: Check balance Deposit money

  31. Generalization Relationship • Generalization is an inheritance relationship. there are two of Generalization relationships: • Actor to Actor • Use Case to Use Case Example of an actor to actor generalization : draw a UCD foruniversity registration system. where there are two type of students who do not citizen students who do not pay fees and foreign students who should pay fees.

  32. Enroll student pay fees foreign citizen Example of a use case to use case generalization : when paying fees, you may pay in cash or by a check.

  33. Pay fees pay by cash pay by check Note: use case to use case generalization is very similar to extend relationship.

  34. Use Case Description • Use Case Description is a sequence of events (steps) needed to perform a transaction or a function of a system. • this description takes the form of a scenario that represent what happens when someone ( actor) interacts with the system.

  35. Example, a Use Case Description:

  36. Project Requirements part2 • Using UML diagrams (use case) to represent your project requrenents

  37. Thanks …. Any questions?

More Related