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)

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

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)

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

5. Introduction to Classes • Most systems have large numbers of objects that come and go throughout the systems’ lifetimes • Humans naturally classify similar things by their observable properties • Watch how little children reference things • Classes are abstractions that allow us to deal with whole collections of objects that share some commonalties

6. Introduction to Classes • Examples of classes in a Student Records Management System Student Course College Class Section Instructor Semester Department Major Class Grade

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

8. 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 {…}

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

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

11. Class Name Syntax • A class name may be text consisting of any numbers, letters, and punctuation marks (except “:”) • Capitalize each word that makes up the name • A class name can include a path specification, if the class is part of a package. • “Records Management Package::Student” • More on packages later

12. Exercise – Class Identification • Identify meaningful classes in the Elevator System

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

14. Object Name Syntax • The name includes an the instance name and a class path, separated by a “:” • The instance name is typically lower case • The instance name be may blank, meaning an arbitrary object from the designated class • The class path name may include a path • The whole name is underlined

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

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

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

18. Attributes from an Implementation Perspective • Attributes from an implementation perspective are similar data members in C++ or Java • They are place holders with value semantics • Each object can have different values • Constraints can be placed on the attributes to restrict how and when the values can be changed

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

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

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

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

23. Type of Relationships in Class Diagrams A consolidated snippet of the UML Meta-model Relation Generalization Association Dependency Binary Association N-ary Association Aggregation

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

25. Associations is registered for> Student Semester takes> is held during> teaches> Class Section Instructor <works for is instance of> sponsors> Department Course

26. Association Names • Associations may be named • The names should communicate the meaning of the links • The names are typically verb phases • The words that make up the name are typically all lowercase • The name should include an arrow indicating the direction in which the name should be read • Some kinds of associations have implied names

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

28. Navigation • Bi-directional navigation means more than just being able to traverse the association in both directions Instructor If instructor x is associated with department y, then department y must be associated with instructor x <works for Department

29. Navigation • The navigation of association without an arrowhead is assumed to be undefined • Navigation has little value when modeling from a conceptual perspective • Why? • Navigation is more important from specification and implementation perspectives • Why?

30. N-ary Associations • Associations can connect more than one class • Notation: Student Advisor Major • How should we go about naming an n-ary association?

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

32. Generalization • From a specification perspective, generalization can represent sub-typing, interface inheritance, type capability, and substitutability Student Person major: String GPA: Real standing: String name: String address: String add(Class Section) drop(Class Section) changeAddress(new_address)

33. Generalization • From an implementation perspective, a generalization can represent implementation inheritance (depending on developing environment) Student Person major: String GPA: Real standing: String name: String address: String add(Class Section) drop(Class Section) changeAddress(new_address)

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

35. Class Diagrams • Class Diagrams describe • the types of objects in a system • their properties (attributes and operations) • relationships between objects • Class Diagrams are similar to entity-relationship (ER) data models, but show classes instead of data entities

36. Class Diagrams • Class diagrams are collections of • Classes and individual objects • Associations, generalizations, and other kinds of relationships • They can also include • Grouping concepts like packages • Constraints • Various kinds of annotations

37. Class Diagrams • Class Diagrams are like the paragraphs of a technical paper • each diagram should focus on a specific topic • a diagram provides supporting detail for the main concept(s) that it is trying to communicate • the level of the abstraction used in the diagrams should be consistent • Together, all the diagrams for a system comprise a “model” of that system

38. Class Diagrams • Pitfalls of Class Diagrams: • Using class diagrams alone can cause developers to focus too much on structure and ignore behavior • Using the wrong (or a mixed) perspective can lead to misunderstanding • Using the wrong level of abstraction can be confusing to the target audience • Using mixed levels of abstraction can reduce the usefulness of diagram

39. Multiplicity Constraints for Associations • Multiplicity constraints define how many objects a given object can be linked to for a given association • A multiplicity constraint is placed near the connection of an association to an object class

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

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

42. Dependencies A consolidated snippet of the UML Meta-model Relation Generalization Association Dependency Binary Association N-ary Association Aggregation

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

44. 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. • Some kinds of dependencies can be inferred if the component definitions are complete

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

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

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

48. Questions • What do classes and associations in class diagrams really mean? • 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”? • How can we show relationships involving more than two classes? • When during the software engineering life cycle should you build classes diagrams?

49. More Questions • How does one choose a level of abstraction for modeling the objects of a system? • How does one decide how to break up the responsibilities of a system into meaningful classes? • How do you know if you have identified the best classes for a system? • How do you know where in a class hierarchy a particular attribute or operation bests fit?

50. More Questions • How do you know when a class diagram is complete? • How can you make the information captured in a class diagram more understandable? maintainable? reusable? • 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?