Objects, Classes, and Basic Class Diagrams

1. Objects, Classes, andBasic Class Diagrams CS/SWE 421 Introduction to Software Engineering Dan Fleck (Slides adapted from Dr. Stephen Clyde with permission) Coming up: Introduction to Objects

2. Introduction to Objects • Objects are the fundamental building blocks of object-oriented systems • What is an object? • It represents any “thing” • It has a boundary in space and time • It is an abstraction • It encapsulates state and/or behavior • It has identity Coming up: Introduction to Objects

3. Introduction to Objects • What aren’t objects? • Events (sometimes) • Relationships between objects (most of the time) • Behavior (most of the time) • Constraints (most of the time) Coming up: Exercise - Object Hunt

4. Exercise - Object Hunt • Part 1 - List examples of objects in the Third National Bank Elevator System • Part 2 - List some concepts from this system that would not typically be modeled as objects Coming up: Introduction to Classes

5. Introduction to Classes • Classes are abstractions that allow us to deal with whole collections of objects that share some commonalties • Examples of classes in a Student Records Management System Course College Class Section Instructor Semester Student Department Class Grade Major Coming up: Three Perspectives

6. Three Perspectives • Objects and classes, as well as all other modeling components in UML, can be interpreted from different perspectives: • Three common perspectives: • Analysis - description of the problem domain • Specification - logical description of software system • Implementation - description of software components and their deployment Coming up: Classes from different Perspectives

7. Classes from different Perspectives • Meaning from three perspectives • Analysis: sets of objects • Specifications: interfaces to encapsulated software representations of objects • Implementations: abstract data types Analysis Specification Implementation Student Student Student {Joe, Sue, Mary, Frank, Tim, …} Interface Student {…} class Student {…} Coming up: Class Syntax

8. Class Syntax Student • A box divided into compartments • Name • Attributes • Operations • Responsibilities • Used-defined compartments 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

9. 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 • Avoid jargon in the names • Try to make the name descriptive of the class’s common properties Coming up: Class Name Syntax

10. Exercise – Class Identification • Identify meaningful classes in the Elevator System Coming up: Return to Objects – Object Syntax

11. Return to Objects – Object Syntax • Object syntax is similar to class syntax, except • the name identifies specific or generic object • the name includes the class that the object belongs to • Remember, individual objects are instances of classes joe: Student major: String = “CS” gpa: Real = 4.0 standing: String = “” add(Class Section) drop(Class Section) Coming up: Object Name Syntax

12. Attributes • Attributes represent characteristics or properties of objects • They are place holders or slots that hold values • The values they hold are other objects • The name of an attribute communicates its meaning • An attribute can be defined for individual objects or classes of objects • If defined for a class, then every object in the class has that attribute (place holder) Coming up: Attributes from an Analysis Perspective

13. 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: Attributes from a Specification Perspective

14. Attributes from a Specification Perspective • An attribute represents an obligation to provide or manage a certain (single) piece of information • For example, each Student object must be able to encapsulate a major, a GPA, and a standing Student major: String gpa: Real standing: String Coming up: Attributes from an Implementation Perspective

15. 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: build-in type or any user-defined class initial-value: any constant and user-defined object property-string: e.g, changeable, addOnly, frozen Coming up: Exercise – Attributes

16. Operations • Meaning from three perspectives • Analysis: Ways in which objects interaction • Specification: An obligation to provide a service • Implementation: A function member, a method Coming up: Operations

17. 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

18. Operation Syntax • [visibility] name [(parameter-list)] [:return-type] [{property-strong}] 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

19. 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

20. Associations • An association is a structural relationship that specifies that objects of class may be connected to objects of another class • Meaning from three perspectives • Analysis: Links between objects • Specification: Obligation to provide a connection between objects • Implementation: Object pointers, references, linking structures, etc. Coming up: Associations

21. 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

22. Association Names • Associations may be named • 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 Coming up: Navigation

23. Navigation • The navigation of associations can be • uni-directional • bi-directional • unspecified teaches> Class Section Instructor <works for is instance of> sponsors> Department Course Coming up: Navigation

24. Generalization • Generalization is another kind of relationship in UML – see Meta Model • From an analysis perspective, it is a pure generalization/specialization concept, i.e., the specialization is a subset of the generalization Graduate Student Person Student Coming up: Generalization

25. Generalization • From a specification/implementation perspective, generalization can represent sub-typing, inheritance, type capability, and substitutability (depends on the language) Student Person major: String GPA: Real standing: String name: String address: String add(Class Section) drop(Class Section) changeAddress(new_address) Coming up: Generalization

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

27. 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: Class Diagrams

28. 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: Multiplicity Constraints

29. 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?

30. 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 Coming up: Dependencies

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

32. Dependencies • A dependency is a type of relationship • It says that one modeling component “uses” another. • If the later changes then, the former may have to change as well Student Prerequisite add(Course) drop(Course) Coming up: Dependencies

33. Dependencies • Meaning from three perspectives • Analysis: physical or logical dependency between the connected classes • Specification: a “uses” relationship at an interface level • Implementation: a “uses” relationship at an implementation level. Just think: uses! Coming up: Dependencies

34. Dependencies • Syntax: • a dashed link with an straight-line 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)

35. 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

36. 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)

37. 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: Using a class diagram

38. 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?

39. Class Exercise • Lets create the WeGrow class diagram

40. Validating a class diagram • One of the most important, and often overlooked issues is how to validate a class diagram. (Usually best for an diagram at the implementation perspective) • Given a specification or a use-case, can you look at the class diagram and use attributes and methods to “execute” a use case? • Lets try it for the WeGrow class diagram Coming up: Questions

41. 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

42. 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: More Questions

43. Bonus Slide! • If you’re interested in Auto-generating UML, Netbeans has an option to do it. • Install the UML plugin • Right-click on a project • Choose “Reverse Engineer” • Go to the new UML project • Select a package and choose to generate a new UML diagram