1 / 35

Basic Class Diagrams

Basic Class Diagrams. CS/SWE 421 Introduction to Software Engineering Dan Fleck (Slides adapted from Dr. Stephen Clyde with permission). UML class diagrams. Show the classes of a system Their interrelationships Inheritance Aggregation Association Attributes Operations. Class Syntax.

wallison
Télécharger la présentation

Basic 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. Basic Class Diagrams CS/SWE 421 Introduction to Software Engineering Dan Fleck (Slides adapted from Dr. Stephen Clyde with permission) Coming up: Class Syntax

  2. UML class diagrams Show the classes of a system Their interrelationships Inheritance Aggregation Association Attributes Operations

  3. Class Syntax Student • A box divided into compartments • Name • Attributes • Operations • Responsibilities (rarely seen) • Used-defined compartments (rarely seen) major: String gpa: Real standing: String add(Class Section) drop(Class Section) -- The set of students known to the registration system -- An exception occurs if gpa falls below 2.0 Coming up: Class Names

  4. Class Names • The name should be a noun or noun phrase • The name should be singular and description of each object in the class • The name should be meaningful from a problem-domain perspective • “Student” is better than “Student Data” or “S-record” or any other implementation driven name Coming up: Exercise – Class Identification

  5. Exercise – Class Identification • Identify meaningful classes in the Elevator System • http://www.web-feats.com/classes/dj/lessons/uml/elevator.htm • Answers (possible): • Elevator • Elevator controller • Door • Button • Elevator • Floor Coming up: Attributes

  6. Attributes • Attributes represent characteristics or properties of classes • They are place holders or slots that hold values • The values they hold are other objects (or primitive types) Coming up: Attributes from an Analysis Perspective

  7. Attribute Syntax • [visibility] name [multiplicity] [:type] [=initial-value] • [{property-string}] visibility: public “+”, protected “#”, or private “-” name: capitalize first letter of each word that makes up the name, except for the first multiplicity: number, range, or sequence of number or ranges. type: built-in type or any user-defined class initial-value: any constant and user-defined object property-string: e.g, changeable, addOnly, frozen Coming up: Operations

  8. Attributes from an Analysis Perspective • An attribute relates an object to some other object • It has the same semantics as an association joe: Student Is basically the same as ... name: String = “Joe Jones” name joe: Student Joe Jones : String 1 Coming up: Attribute Syntax

  9. Operation Syntax • [visibility] name [(parameter-list)] [:return-type] [{property-string}] visibility: “+”, “#”, “-” name: verb or verb phase, capitalize first letter of every word, except first parameter-list: coma separated list of parameters return-type: primitive type or user-defined type property-string: isQuery, sequential, guarded, concurrent Coming up: Type of Relationships in Class Diagrams

  10. Operations Student Class Section major: String GPA: Real standing: String name: String capacity: Integer takes> add(Student) drop(Student) checkPrerequisites(Students) add(Class Section) drop(Class Section) <has Course Prerequisite Coming up: Operation Syntax

  11. Type of Relationships in Class Diagrams A consolidated snippet of the UML Meta-model Relation Generalization Association Dependency Binary Association N-ary Association Aggregation Coming up: Associations

  12. Associations • An association is a structural relationship that specifies that objects of class may be connected to objects of another class • Associations typically represent “long-lived” relationships • e.g. In a library system a Person always has a name (association), but may infrequently have a book (dependency) Coming up: Associations

  13. Associations • Connect two classes • Have an optional label • Have multiplicities • Are directional • Have optional roles

  14. Association Names • Associations may be named (or labeled) • The names should communicate the meaning of the links • The names are typically verb phases • The name should include an arrow indicating the direction in which the name should be read • The direction on the name does NOT change navigability! Coming up: Navigation

  15. Associations is registered for> Student Semester takes> is held during> teaches> Class Section Instructor <works for is instance of> sponsors> Department Course Coming up: Association Names

  16. Navigation • The navigation of associations can be • uni-directional • bi-directional • unspecified • Navigation is specified by the arrow, not the label teaches> Class Section Instructor <works for is instance of> sponsors> Department Course Coming up: Navigation

  17. Navigation • The navigation of association without an arrowhead is assumed to be undefined • Navigation has less value when modeling from a conceptual perspective • Why? • Navigation is more important during specification and implementation perspectives • Why? Coming up: Generalization

  18. Generalization • Generalization is another kind of relationship in UML • In a Java implementation what is this? Graduate Student Person Student Coming up: Exercise – Simple Associations

  19. Exercise – Simple Associations • From an analysis perspective: • Identify meaningful associations and generalization/specializations among classes in the Elevator System Coming up: Class Diagrams

  20. Class Diagrams • Class Diagrams describe • the types of objects in a system • their properties (attributes and operations) • relationships between objects • They can also include • Grouping concepts like packages • Constraints • Various kinds of annotations Coming up: Multiplicity Constraints

  21. Multiplicity Constraints • A multiplicity constraint can be • a single number • a “*”, meaning an arbitrarily large number or simply “many” • a range, denoted by “min..max” • a sequence of single numbers and ranges 1..2,7,10-20 This is also called the cardinality constraint Coming up: Dependencies

  22. Multiplicity Constraints is registered for> Student Semester 1..* 0..* 1 takes> is held during> 0..8 1..* teaches> Class Section Instructor 1..3 0..6 1..* <works for is instance of> 1 sponsors> 1 1..* Department Course Coming up: Questions

  23. Questions • From the previous diagram • How many classes can a student take? • Do you have to be registered in any classes to be a student? • Do I need to teach this class to be an Instructor? Do I need to teach ANY classes? • Can a class have no students? Is that valid? Coming up: Multiplicity Constraints

  24. Dependencies A consolidated snippet of the UML Meta-model Relation Generalization Association Dependency Binary Association N-ary Association Aggregation Coming up: Dependency Relationship

  25. Dependency Relationship • It says that one modeling component “uses” another. • If the later changes then, the former may have to change as well Coming up: Dependencies

  26. Dependencies • Syntax: • a dashed link • arrowhead point to a component on which there is a dependency • Dependencies can be defined among: classes, notes, packages, and other types of components • Can dependencies go both ways? • Any problems with having lots of dependencies? Coming up: Aggregations (is part of)

  27. Aggregations (is part of) A consolidated snippet of the UML Meta-model Relation Generalization Association Dependency Binary Association N-ary Association Aggregation Coming up: Aggregation

  28. Aggregation • Aggregation: is a special kind of association that means “part of” • Aggregations should focus on single type of composition (physical, organization, etc.) Crust 1 1 1 1 * 1 Sauce Serving Order Pizza 1..3 1 1 Cheese Serving 4..* 0..9 1 Topping Serving Slice Coming up: Composition (very similar to aggregation)

  29. Composition (very similar to aggregation) • Think of composition as a stronger form of aggregation. Composition means something is a part of the whole, but cannot survive on it’s own. Room Building Coming up: Lets look at BookstoreExample4.jpg

  30. Lets look at BookstoreExample4.jpg • Does John McCain (who has 7 houses) have a problem using this system? • If Barack Obama decides to create a Federal sales tax, how would we change the system? • Why is there a display method in Item, Book, MusicCD and Software? • An ItemOrder is part of how many Orders? • Can you explain how a search works using this diagram? Coming up: Class Exercise

  31. Class Exercise • Lets create the WeGrow class diagram Coming up: Safety System Example

  32. Safety System Example • A safety software system for housing areas: • enables its owner to configure it during installation, • controls through its sensors the environmental areas against fire and burglary and • interacts with the owner through the keypad of the system control panel. • During installation, the system programming and configuration is carried out by using the numerical and functional keys of the control panel. Each sensor in the system is identified by a number and a type (fire or burglary). The system stores two passwords (each of them is up to six digits) used for the system activation/deactivation and a telephone number used for emergency calls when an alarm event arises. The system polls the fire sensors for M seconds, then disables them for other N seconds. After that, the system resumes the same cycle. The Ready indicator is lighting when the sensors are polled and is turned off when the sensors are disabled. When a sensor indicates an event, the system launches an alarm signal. After K seconds, the system calls the security forces office and provides it with information about the event nature and location. In order to log in, the owner enters the password and presses Enter. If any of the six digits is wrong the password is ignored by the system and the sensors’ state doesn’t change. The owner can cancel the password with the Clear key. If a sensor is activated, the system is armed and the Armed indicator on the control panel is turn on. In the case of the sensor deactivation, the Armed indicator is turn off. Moreover, the system logs all events. Each logged event is characterized by its type and the date and time of its occurrence. The event list can be delivered by pressing the MEM key. Example specification from: http://www.emis.de/journals/ASUO/mathematics/pdf3/bogdan.ps Coming up: Questions

  33. Questions • What’s the difference between an attribute and an association with another class? For example, should “grade” be an attribute or a link to another class called “Grade”? • When during the software engineering life cycle should you build classes diagrams? Coming up: More Questions

  34. More Questions • How do you know when a class diagram is complete? • How can you manage change control on all the class diagrams for project? • What do you do with class diagrams after a system has been built and delivered? Coming up: What’s important

  35. What’s important • Understanding the 3 main parts of the class box • Generalization/Specialization • Associations and multiplicity constraints • Aggregation (and composition) understand how to use them, but don’t worry about the differences between them – too subtle Coming up: Bonus Slide!

More Related