1 / 23

OO Design Notations

OO Design Notations. Original version by B.Rogers/M.Utting. Notations. There are a large number of OO and other design notations (text or diagram) Serve two main purposes helping express ideas during design documenting the final structure of a system Informal (personal)

dena
Télécharger la présentation

OO Design Notations

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. OO Design Notations Original version by B.Rogers/M.Utting

  2. Notations • There are a large number of OO and other design notations (text or diagram) • Serve two main purposes • helping express ideas during design • documenting the final structure of a system • Informal (personal) • allow free expression of ideas • Formal (standard) • may admit proof of correctness • permits development of tools (Rat Rose) • communication to others

  3. Notations • Ad Hoc notations • widget relationships • UML • class diagrams • (activity diagrams) • CRC cards • Class, Responsibility and Collaboration • Use Cases

  4. Widget Organisation window lcd quit button square button paper circle button trianglebutton

  5. Organisation of Widgets window (QWidget) lcd(QLCDNumber) quitbutton(QPushButton) paper (Canvas) squarebutton (QPushButton) circlebutton (QPushButton) trianglebutton(QPushButton)

  6. Widgets emphasising links desktop window lcd quit paper square circle triangle

  7. Unified Modelling Language • Facetiously called Union of all MLs • (UML) Grady Booch, Jim Rumbaugh, and Ivar Jacobson • Unifies and standardises a number of notations developed over the 80 and 90’s • A (mainly) graphical language used to express object oriented designs. • use case diagrams; class diagrams; interaction diagrams; package diagrams; state, collaboration, sequence, activity diagrams; deployment diagrams.

  8. Class Diagram • Can be used at different stages of development: from modeling the kinds of objects in a system through to detailed implementation • Classes may be implemented as Java classes or not, may just be kinds of items in a system • A class is shown as a box: NAME Attributes Operations

  9. Examples • Name in italics for an abstract class Canvas NAME Shape current_shape Graphic picture Attributes mouse down, move, up repaint set shape Operations graphic int atx, aty drawresize

  10. Class Diagram • Association • what uses, has, contains, is related to ... • Multiplicity • how many of each kind of object are related • Navigability • what pointers are present • Generalization • sub/super class relationships • Other constraints

  11. MAIN Canvas four buttons lcd display Shape current_shape Graphic picture mouse down, move, up repaint set shape graphic int atx, aty draw resize

  12. MAIN Canvas four buttons lcd display Shape current_shape Graphic picture 1 1 mouse down, move, up repaint set shape 1 * graphic int atx, aty draw resize

  13. MAIN Canvas four buttons lcd display Shape current_shape Graphic picture 1 1 mouse down, move, up repaint set shape 1 * graphic int atx, aty draw resize

  14. MAIN Canvas four buttons lcd display Shape current_shape Graphic picture 1 1 mouse down, move, up repaint set shape 1 * graphic int atx, aty draw resize Square Triangle Circle int size int width, height int radius

  15. CRC Cards • Class, Responsibility and Collaboration • Cunningham and Beck from Tektronix labs in Portland, Oregon. (Smalltalk) • Used 15 by 10cm index cards • Attempt to encourage a high level description of the purpose of a class • Avoid details of methods and attributes • Small card limits the number of responsibilities and amount of detail

  16. Name graphic knowing where on the display Canvassurface it should be drawn drawing itself Canvas(delegated to subclasses) resizing, given new extent Canvas(delegated to subclasses) Responsibilities Collaborators

  17. graphic knowing where on the display Canvassurface it should be drawn drawing itself Canvas(delegated to subclasses) resizing, given new extent Canvas(delegated to subclasses) Canvas responding to mouse events Graphic(+)by drawing a graphic knowing which kind of graphic MAINto draw next (buttons) maintaining a list of graphics Graphic which have been drawn repainting the screen Canvas

  18. square circle triangle square MAIN Canvas responding to mouse events Graphic(+)by drawing a graphic knowing which kind of graphic MAINto draw next (buttons) maintaining a list of graphics Graphic which have been drawn graphic knowing where on the display Canvassurface it should be drawn drawing itself Canvas(delegated to subclasses) resizing, given new extent Canvas(delegated to subclasses)

  19. Use cases 1 • What is a use case? • Identify user goal’s, not system functions • E.g. for a word processor: • Build an index • Insert a picture • Ensure consistent formatting. • Describe external view, interactions with the outside world.

  20. Use cases 2 Express requirements at a high level • The first step in software analysis is to develop a sufficient set of use cases. (but will also useful later on for system testing) • Each use case (business task) has: • A name: • An actor: a role that a user takes when using the system. Actors are usually human. • A description: of interaction with system.

  21. Description should tell us: • What are the main tasks done by the actor? • What inputs/outputs will the actor give/get? • Does the actor have to inform the system about changes in the external environment? • What information does the actor want from the system? • Does the actor wish to be informed about unexpected changes?

  22. Use Case Diagrams Use Case Name Actor Name <<uses>> <<uses>> <<extends>> (special cases/exceptions)

  23. Use Case Diagrams 2 Analyze risk Trader <<uses>> Valuation Price deal <<uses>> Capture deal <<extends>> Customer Limit exceeded

More Related