Unit 3


Published on

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Unit 3

  1. 1. Unit 3 Object Oriented analysis process2. Identifying use cases3. Classification4. Identifying object relationships,attributes and methods
  2. 2. Identifying use cases: Objective• Use case modeling and analysis• Identifying actors• Identifying use cases• Developing effective documentation
  3. 3. Identifying use cases• Introduction• Objective of analysis – To capture complete, unambiguous , consistent picture of requirements of system – Separating system’s behavior from behavior implementation • What the system must do to satisfy users requirement and needs • Wont specify how to do it • Requires to view the system from users perspective
  4. 4. Cont.. Of introduction• Transformation 1 – users need to problem statement and requirement• Tools to extract information about a system – examination of existing system documentation – Interviews – Questionnaire – observation
  5. 5. Why analysis is a difficult activity• Analysis activity involves understanding – problem – Associated constraints – Methods to overcome this constraints• Iterative process
  6. 6. Cont..• Sources that makes analysis difficult – Fuzzy descriptions • Bcs of interpretation problem – Incomplete requirements • Due to users forgetting to identify them, High cost, politics – Unnecessary features
  7. 7. Business object analysis: understanding the business layer• Process of – understanding sys requirement • Developing use case – Discussing uses and objectives with users – Understanding expected inputs, desired response • Prototype – Helps to understand how the system ’ll be used – Establishing goals• Outcome of this process – Identifying classes – Relationship
  8. 8. Use case driven object oriented analysis: the unified approach Identify Develop Develop classes , Refineactors usecase & interaction relationships, & activity diagram attributes, iterate diagram methods Build prototype
  9. 9. Business process modelling• Not necessary for all project• When required business process and requirements can be modelled to any level of detail• Activity diagram support this modelling• disadv – Time consuming process• Adv – familiarity
  10. 10. yes yes Go to yes Go to counter and counter and check out return the booksReturn booksbook? yes yes Interlibrary loan borrow no book? no Search for book yes Do Do search research on topics no yes Read news Read news paper and paper? no magazine Acivty diagram –library system
  11. 11. Use case model• Senarios for understanding the system• Interaction bw user and system• Captures users goal and systems responsibility• Used to discover classes and relationship• Developed by talking to users• Use case model – Provides external view of the system• Object model (UML class diagram) – Provides internal view
  12. 12. Use cases and microscope• A use case is a sequence of transaction in a system whose task is to yield results of measurable value to an individual actor of the system• Actor – Role played by the user with respect to the system – Single actor may perform many use cases – Can be external system – Can be one get value from the system, or just participate in the use case
  13. 13. Borrow books uses Check library card extends uses Get an interlibrary loan uses Return booksmember Circulation clerk Do research Read books and news paper Purchase supplies supplier
  14. 14. Uses and extends association• Uses – common sub flows are extracted and separate use case is created – Relationship bw usecase and extracted one is called uses relationships• Extends – Used when use case is similar to other, but do bit more or more speciliazed
  15. 15. • Abstract use case – No initiating actor – Used by concrete use cases• concrete use cases – Interacts with actors
  16. 16. Identifying actors• Actor – Role played by the user• Actors found thru answers of following question – Who is using the system – Who is affected by the system – Which group needs help from the system – Who affects the system, which user groups are needed by the system to perform it functions – Which external h/w or other systems use the system to perform tasks – What prob does this application solve and for whom – How do users use the system(ie use case), and what they are doing with the system• Accounts need not be human. It is an external system
  17. 17. Identifying actor (cont..)• Two-three rule – Used to identify the actors – Start with naming at least 2 or 3 , people who could serve as the actor in the system.other actor can be identified in the subsequent iteration
  18. 18. Guideline for finding use cases• For each actor, find the tasks and function that the actor should be able to perform or that the system needs the actor to perform (use case)• Name the use cases• Describe the use cases briefly by applying terms with which the user is familiar (to make less ambiguous)• Each use case has only one main actor – Isolate users from actor – Isolate actors from other actors(separate responsibilities) – Isolate use cases that have different initiating actors
  19. 19. How detailed must a use case be? When tostop decomposing it and when to continue• Develop system use case diag• Draw package – to represent business domains of the system . for each package create child use case diagram• Prepare at lest one senario for each use case – Each scenario shows different sequence of interaction , with all decisions definite• When the lowest use case level is arrived, which can’t be broken further, sequence and collaboration diagram is drawn
  20. 20. Dividing use case into package• Whole system is divided into many packages• Each package encompasses multiple use cases
  21. 21. Developing effective documentation• Effective document provides – Reference point – Form of communication – Reveals issues and gaps in the analysis and design
  22. 22. Guidelines for developing effective document• Common cover – Identify document – Current version – Individuals responsible for doc• 80-20 rule – 80% of work can be done with the 20% of doc. – 20% -easily accessible, 80%-only who needs can access• Familiar vocabulary• Make the doc as short as possible• Organize the document