1 / 19

Object and Class Diagrams

Object and Class Diagrams. CSE301 University of Sunderland. Purpose. Describes the static structure of a system, not how it behaves. The objects/classes you choose to show should be the important ones — those in the use case and behavioural diagrams (later).

kenley
Télécharger la présentation

Object and Class Diagrams

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. Object and Class Diagrams CSE301 University of Sunderland

  2. Purpose • Describes the static structure of a system, not how it behaves. • The objects/classes you choose to show should be the important ones—those in the use case and behavioural diagrams (later). • Class diagrams show the long-term structure. • Use separate diagrams for associations and inheritance. • Object diagrams then show the structure at a specific time. Should show only links, not inheritance. • May be high- or low-level.

  3. Class Diagram Notation Simple. Made up of: • Classes (or subsystems) • Associations

  4. Technique for Construction • Identify the classes (Object diagrams can be used to explore class relationships. Eventually you replace the whole mess with a class diagram.) • Identify the associations • Refine and elaborate. • Keep it simple (silly!)

  5. Sample Class Diagram Association Class (optional) Skill * Class Resource-Skill * Association Resource Inheritance Professional Hourly (Note that this should be two diagrams, not one.)

  6. Class • Abstract classes have a name in italics. • May have interfaces • May be active (Runnable/Thread) or passive ClassName (reqd) Attributes (opt) Operations (opt) Other Elements (opt)

  7. Attributes and Operations • Public (+), protected (#), and private (-) are usually all you need to indicate. • Default values for attributes can be specified (=value) • Return types (: type) and arguments (args) can be specified for operations. • Underline to indicate class or static scope.

  8. Association • May relate two or more classes. • Paths lie between class symbols • May be a class in its own right, with attributes and operations • May be recursive from the class back to itself. • May have role names. • May have multiplicity. (Collections are usually required to implement multiplicity.)

  9. Object Diagram Notation • Objects (instances of classes) • Links (instances of associations) • In other words, an object diagram instantiates a class diagram. • You don’t show inheritance in object diagrams.

  10. Sample Object Diagram Programming:Skill Object Link Programmer:Resource EntryLevel:Professional Maintainer:Hourly

  11. Object • Unique and has identity. • May be active or passive. InstanceName:Class Attribute values

  12. Link • Is an instance of an association. • Shown as paths between objects • Can be objects in their own right.

  13. Some Added Class Stereotypes • Boundary (input and output) • Entity (business object) • Control (applications model) • You can use these instead of: or inside the box:

  14. Using Class Diagrams • Issues: • The layout of a GUI does not usually match the structure of the applications model or business objects. It can, but it need not. (It is a good idea for the GUI to be designed by a GUI specialist.) • The rules (business logic) in an applications model are often arcane and volatile. Hence the applications model should not be tightly coupled with the GUI or business objects. • Business objects (external interfaces and database tables) tend to be very rigid and should be separate from the GUI and business logic.

  15. A Posting on comp.object Hi It seems generally accepted in Java that Swing GUI builders are not the best way of constructing your GUI, IOW hand-coding seems to be the best practice. Two reasons for this seem to be 1. the type of code that is automatically generated from a GUI builder is not so nice; and 2. using a GUI builder can encourage the developer to write business logic code into the GUI. Now I just wondered if this is the general case for most OO languages or do other languages provide better GUI building facilities? Regards Shane

  16. A Response (edit’d) It is not the case for all GUI builders but it is common. The Borland Delphi/Kylix IDE is a case in point. While it is perfectly possible to separate out business logic the newbie Delphi programmer almost invariably puts it in with the GUI - because the tool encourages that style. VB is the same and so are the various Visual C GUI tools. (Note: this is not a rant against Delphi - I've been using it for most of my Windows GUI work since Version 2) Many open-source tools are based on the same ideas as Delphi etc (GLade being an example) and thus lead to similar problems. …<cut> My experiences, FWIW, Alan G.

  17. Bob Martin’s Comments (edit’d) >Hi >It seems generally accepted in Java that Swing GUI builders are not the best >way of constructing your GUI, IOW handcoding seems to be the best practice. I hold out high hopes for the new IntelliJ 4.0 GUI builder. I haven't tried it yet, but from what I've heard it's intriguing. If it's as good as the rest of IntelliJ, then it'll be pretty good. >Two reasons for this seem to be 1. the type of code that is automatically >generated from a GUI builder is not so nice; and 2. using a GUI builder can >encourage the developer to write business logic code into the GUI. Most GUI builders I have worked with leave the programmer hanging. They provide a lot of assistance for simple GUIs, but less and less as the GUI's get more interesting. There comes a point where the builder ceases to be useful, and the poor programmer is left with a mass of opaque generated code, and without the practice to manipulate it properly.

  18. Think About This for a Minute • Take a piece of paper and write down what this seems to be telling you…

  19. So How Do You Use Class Diagrams Professionally? • Make sure you model your GUI, applications model, database tables, and external interfaces separately. • It is OK to use a GUI-builder, but you must separate your GUI from your applications model. • Learn how to handle events and how to set up the Observer/Observable pattern.

More Related