CASE TOOLS Questions

4,008 views
3,637 views

Published on

CASE TOOLS Questions

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
4,008
On SlideShare
0
From Embeds
0
Number of Embeds
7
Actions
Shares
0
Downloads
109
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

CASE TOOLS Questions

  1. 1. Object Type Questions Roy Antony Arnold G Teaching Associate Dept. of Computer Science & Engg. Arunai Engineering College Tiruvannamalai
  2. 2. <ul><li>SSD is a picture that shows for a particular scenario of a use case the events that external actors generate, their order and inter-system events. </li></ul><ul><li>SSDs are part of the Use-Case Model. </li></ul><ul><li>SSDs can also be used to illustrate collaborations between systems. </li></ul><ul><li>System events and their associated system operations can be expressed in terms of the physical input medium or interface widget level. </li></ul><ul><li>An SSD should be done for the main success scenario of the use case and frequent or complex alternative scenarios. </li></ul><ul><li>It is sometimes desirable to show at least fragments of the use case text for the scenario to enhance the two views </li></ul>
  3. 3. <ul><li>Interaction Diagrams </li></ul><ul><li>Activity Diagrams </li></ul><ul><li>Use Cases </li></ul><ul><li>State Diagrams </li></ul><ul><li>Class Diagrams </li></ul>
  4. 4. <ul><li>Interaction Diagrams </li></ul><ul><li>Activity Diagrams </li></ul><ul><li>Package Diagrams </li></ul><ul><li>State Diagrams </li></ul><ul><li>Class Diagrams </li></ul>
  5. 5. <ul><li>Interaction Diagrams </li></ul><ul><li>Activity Diagrams </li></ul><ul><li>Package Diagrams </li></ul><ul><li>State Diagrams </li></ul><ul><li>Class Diagrams </li></ul>
  6. 6. <ul><li>Analyzing a use case </li></ul><ul><li>Understanding workflow </li></ul><ul><li>Describing a complicated sequential algorithm </li></ul><ul><li>Dealing with multithreaded applications </li></ul><ul><li>Procedural flow of control </li></ul><ul><li>Representing complex conditional logic </li></ul>
  7. 7. <ul><li>Sequence Diagrams </li></ul><ul><li>Collaboration Diagrams </li></ul><ul><li>Deployment Diagrams </li></ul><ul><li>Package Diagrams </li></ul>
  8. 8. <ul><li>Coincidental Cohesion </li></ul><ul><li>Temporal Cohesion </li></ul><ul><li>Procedural Cohesion </li></ul><ul><li>Functional Cohesion </li></ul>
  9. 9. <ul><li>Interaction Diagrams </li></ul><ul><li>Activity Diagrams </li></ul><ul><li>Package Diagrams </li></ul><ul><li>State Diagrams </li></ul><ul><li>Class Diagrams </li></ul>
  10. 10. <ul><li>Activity Diagrams </li></ul><ul><li>Package Diagrams </li></ul><ul><li>State Diagrams </li></ul><ul><li>Class Diagrams </li></ul><ul><li>Sequence Diagrams </li></ul>
  11. 11. <ul><li>Activity Diagrams </li></ul><ul><li>Package Diagrams </li></ul><ul><li>State Diagrams </li></ul><ul><li>Class Diagrams </li></ul><ul><li>Sequence Diagrams </li></ul>
  12. 12. <ul><li>shows behavior with control structure </li></ul><ul><li>can show many objects over many uses </li></ul><ul><li>can show many objects in a single use case or implementation of method </li></ul><ul><li>encourages parallel behavior </li></ul><ul><li>All of the above </li></ul><ul><li>&quot;a&quot;, &quot;b&quot; and &quot;d&quot; only </li></ul>
  13. 13. <ul><li>Actions are associated with transition and are considered to be processes that occur quickly and are not interruptible. </li></ul><ul><li>Actions are associated with transition and are considered to be processes that occur quickly and are interruptible. </li></ul><ul><li>Activities are associated with states and can take longer. An activity may be interrupted by some event. </li></ul><ul><li>Activities are associated with transition that occur quickly and are not interruptible. </li></ul><ul><li>Activities are associated with states and can take longer. An activity cannot be interrupted by any event. </li></ul>
  14. 14. <ul><li>From nouns in a text description </li></ul><ul><li>Look for units of interaction </li></ul><ul><li>Look for places where things or objects come to rest </li></ul><ul><li>Interview Domain Experts. </li></ul><ul><li>All of the above </li></ul><ul><li>&quot;a&quot; , &quot;b&quot; and &quot;c&quot; only </li></ul><ul><li>&quot;a&quot; and &quot;c&quot; only </li></ul>
  15. 15. <ul><li>Model A </li></ul><ul><li>Model B </li></ul><ul><li>Model A or Model B </li></ul><ul><li>None of the above </li></ul>MODEL A DIAGRAM MODEL B
  16. 16. <ul><li>Model P1 </li></ul><ul><li>Model P2 </li></ul><ul><li>Model P3 </li></ul>MODEL P1 MODEL P2 MODEL P3
  17. 17. <ul><li>Female, Patient, Nurse </li></ul><ul><li>Male, Physiotherapist </li></ul><ul><li>Female, Patient </li></ul><ul><li>Female, Doctor, Surgeon </li></ul><ul><li>Patient, Doctor </li></ul><ul><li>Male, Doctor, Nurse </li></ul>
  18. 18. <ul><li>Use case driven </li></ul><ul><li>Data driven </li></ul><ul><li>Responsibility driven </li></ul><ul><li>All of the above </li></ul><ul><li>&quot;a&quot; and &quot;c&quot; only </li></ul><ul><li>&quot;b&quot; and &quot;c&quot; only </li></ul>
  19. 19. <ul><li>book, journal, copy (of book), library member, member of staff </li></ul><ul><li>item, copy (of book), library member, member of staff </li></ul><ul><li>item, library member, member of staff </li></ul><ul><li>system, rule, week, item, member </li></ul>
  20. 20. <ul><li>a list of classes </li></ul><ul><li>another Package diagram </li></ul><ul><li>class diagram </li></ul><ul><li>All of the above </li></ul><ul><li>&quot;b&quot; and &quot;c&quot; only </li></ul><ul><li>&quot;a&quot; and &quot;b&quot; only </li></ul>
  21. 21. <ul><li>Use case diagrams fulfill a specific purpose : to document the actors (everything outside the system scope), the use cases (everything inside the system scope), and their relationships. </li></ul><ul><li>Generalizations as well as other types of associations can be modelled between actors. </li></ul><ul><li>Includes, Extends and other types of associations can be drawn directly between two use cases. </li></ul><ul><li>Every use case must be initiated by an actor. The exception here is an includes or extends relationship. </li></ul>
  22. 22. <ul><li>Library, Library Member, Book, Video, Clerk, Checkout Transaction </li></ul><ul><li>Library Card, Book, Video, Clerk </li></ul><ul><li>Borrower, Member, Book, Video, Title </li></ul><ul><li>Library, Library Member, Book, Video, System </li></ul><ul><li>Library, Library Member, Book, Video, Author </li></ul>
  23. 23. <ul><li>This describes the System Dynamics of Bottom-Up Design approach. </li></ul><ul><li>This describes the System Dynamics of Top-Down Design approach. </li></ul>
  24. 24. <ul><li>Pareto Diagrams </li></ul><ul><li>Fishbone Diagrams </li></ul><ul><li>Mind mapping </li></ul><ul><li>Brainstorming </li></ul><ul><li>Event Analysis </li></ul><ul><li>Actor-Goal List </li></ul>
  25. 25. <ul><li>In Object Oriented Analysis, the dimension of decomposition is fundamentally by things or entities in the domain. </li></ul><ul><li>It is better to over-specify overspecify a domain model with lots of fine-grained conceptual classes, than to underspecify it. </li></ul><ul><li>It is better to oversimplify a domain model with lots of coarse-grained conceptual classes, than to underspecify it. </li></ul><ul><li>In Object Oriented Analysis, the dimension of decomposition is use cases. </li></ul>
  26. 26. <ul><li>A subsystem is a package that has separate specification and realization parts. </li></ul><ul><li>A subsystem is a discrete entity that has behavior and interfaces. </li></ul><ul><li>A subsystem can be identified by the stereotype <<subsystem>> </li></ul><ul><li>A subsystem is a package that has specification part only </li></ul>

×