1 / 28

Chapter 7: Classes and Objects Chapter 8: Finding Analysis Classes

CS 426 Senior Projects in Computer Science. Chapter 7: Classes and Objects Chapter 8: Finding Analysis Classes. [ Arlow and Neustadt , 2005] . University of Nevada, Reno Department of Computer Science & Engineering. Outline. Objects UML Notation for Objects Classes

beau
Download Presentation

Chapter 7: Classes and Objects Chapter 8: Finding Analysis Classes

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. CS 426 Senior Projects in Computer Science Chapter 7: Classes and Objects Chapter 8: Finding Analysis Classes [Arlow and Neustadt, 2005] University of Nevada, Reno Department of Computer Science & Engineering

  2. Outline • Objects • UML Notation for Objects • Classes • UML Notation for Classes • UP Activity: Analyze Use Cases • Analysis Classes • Finding Analysis Classes

  3. Objects • Object = “A discrete entity with well-defined boundary that encapsulates state and behavior, an instance of a class” [J. Rumbaugh] • Properties of objects: • Identity • State • Behavior

  4. Objects: Encapsulation • Fig. 7.2 [Arlow & Neustadt, 2005]

  5. Objects: Messaging • Figure 7.3 [Arlow & Neustadt, 2005]

  6. Objects: UML Notation • Figure 7.4 [Arlow & Neustadt, 2005]

  7. Classes • Class = “The descriptor for a set of objects that share the same attributes, operations, methods, relationships, and behavior” [J. Rumbaugh] • Every object is an instance of exactly one class • Choosing the right classification scheme is a key factor in object-oriented analysis and design

  8. Classes: Classification of Objects • Figure 7.5 [Arlow & Neustadt, 2005] Classifying objects  determining classes

  9. Classes: Relationship with Objects. • Figure 7.6 [Arlow & Neustadt, 2005] <<instantiate>> relationship

  10. Classes: .Relationship with Objects • The <<instantiate>> relationship is a stereotype of the dependency relationship • Dependency: “A relationship between two elements in which a change to one element (the supplier) may affect or supply information needed by the other element (the client)”.

  11. Classes: UML Notation…… • Figure 7.7 [Arlow & Neustadt, 2005]

  12. Classes: .UML Notation….. • Figure 7.8 [Arlow & Neustadt, 2005] The attribute compartment

  13. Classes: ..UML Notation…. • Table 7.3 [Arlow & Neustadt, 2005]. Visibility types

  14. Classes: …UML Notation…

  15. Classes: ….UML Notation.. • Figure 7.10 [Arlow & Neustadt, 2005] Operations

  16. Classes: …..UML Notation. • Figure 7.14 [Arlow & Neustadt, 2005] Class stereotypes

  17. Classes: ……UML Notation • Figure 7.16 [Arlow & Neustadt, 2005] Constructors • Figure 7.15 [Arlow & Neustadt, 2005] Class Scope

  18. Analysis Classes • Figure 8.2 [Arlow & Neustadt, 2005]

  19. Analysis Classes [continued] • Figure 8.3 [Arlow and Neustadt, 2005] Example of Analysis Class

  20. Analysis Classes [continued] • What makes a good analysis class? • Its name reflects its intent • It is a crisp abstraction that models a specific aspect of the problem domain • It maps to a clearly identifiable feature of the problem domain • It has a small, well-defined set of responsibilities • It has high cohesion • It has low cohesion

  21. Analysis Classes [continued] • Analysis classes rules of thumb: • About 3-5 responsibilities per class • No class stands alone • Avoid: • Many very small classes • Very large classes • Functoids (procedural functions disguised as classes) • Omnipotent classes • Deep inheritance trees

  22. Finding Analysis Classes • Finding classes by using noun/verb analysis: • Nouns: candidates for classes or attributes • Verbs and verb phrases: candidates for operations or responsibilities • Beware of spurious and hidden classes • Sources of information • Requirements model • Use case model • Project glossary • Anything else (architecture, concept documents, etc.)

  23. Finding Analysis Classes [continued] • Finding classes by using CRC analysis • Phase 1 – Brainstorming • Phase 2: Analysis Figure 8.4 [Jim Arlow and IlaNeustadt, 2005]: Brainstorming, part of CRC analysis

  24. Finding Analysis Classes [continued] • Finding analysis classes by using RUP stereotypes:

  25. Boundary Classes • Used to model interactions between system and its actors and collect requirements on system’s boundaries • Look at user, system, and device interfaces • Often represent windows, screens, APIs [Kendall V. Scott]

  26. Control Classes • Used to encapsulate control related to a specific use case • Represent coordination, sequencing, transactions, and control of other objects [Kendall V. Scott]

  27. Entity Classes • Used to model long-lived/persistent information [Kendall V. Scott] • Cut across many use cases, are manipulated by control claasses, provide info to and accept info from boundary classes

  28. Finding Analysis Classes [continued] • Finding classes by from other sources: • Real world entities: • Physical objects (e.g., aircraft, people, hotel) • Paperwork (e.g., invoice, fill-in-form, bankbook) • Known interfaces such as screens, keyboards, peripherals • Conceptual entities such as LoyaltyProgramor RewardsCard • Archetype patterns, for example: • Inventory • Money • Order • Party • Product

More Related