1. Generalizable Element Namespace Model Element name visibility isSpecification Classifier isRoot Constraint Body Objects, Classes, and Basic Class Diagrams CS/SWE 421 Introduction to Software Engineering Dan Fleck (Slides adapted from Dr. Stephen Clyde with permission)

2. Introduction to Objects n Objects are the fundamental building blocks of object-oriented systems n 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 n 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 n Part 1 - List examples of objects in the Third National Bank Elevator System n Part 2 - List some concepts from this system that would not typically be modeled as objects

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

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

7. Three Perspectives n Objects and classes, as well as all other modeling components in UML, can be interpreted from different perspectives: n 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 n Meaning from three perspectives –Analysis: sets of objects –Specifications: interfaces to encapsulated software representations of objects –Implementations: abstract data types Student AnalysisSpecification Student {Joe, Sue, Mary, Frank, Tim, …} Interface Student {…} Implementation class Student {…} Student

9. Class Syntax n A box divided into compartments –Name –Attributes –Operations –Responsibilities –Used-defined compartments Student 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 n The name should be a noun or noun phrase n The name should be singular and description of each object in the class n 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 n Avoid jargon in the names n Try to make the name descriptive of the class’s common properties

11. Class Name Syntax n A class name may be text consisting of any numbers, letters, and punctuation marks (except “:”) n Capitalize each word that makes up the name n 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 n Identify meaningful classes in the Elevator System

13. Return to Objects – Object Syntax n 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 n 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 n The name includes an the instance name and a class path, separated by a “:” n The instance name is typically lower case n The instance name be may blank, meaning an arbitrary object from the designated class n The class path name may include a path n The whole name is underlined

15. Attributes n Attributes represent characteristics or properties of objects n They are place holders or slots that hold values n The values they hold are other objects n The name of an attribute communicates its meaning n 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 n An attribute relates an object to some other object n It has the same semantics as an association joe: Student name: String = “Joe Jones” joe: Student Joe Jones : String Is basically the same as... name 1

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

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

19. Attribute Syntax 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 [visibility] name [multiplicity] [:type] [=initial-value] [{property-string}]

20. Exercise – Attributes n Describe meaningful attributes for the key classes in the Elevator System

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

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

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

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

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

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

27. Association Names n 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 n Some kinds of associations have implied names

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

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

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

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

32. Generalization n Generalization is another kind of relationship in UML – see Meta Model n From an analysis perspective, it is a pure generalization/specialization concept, i.e., the specialization is a subset of the generalization StudentPerson Graduate Student

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

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

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

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

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

38. Class Diagrams n 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 n Together, all the diagrams for a system comprise a “model” of that system

39. Class Diagrams n 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

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

41. Multiplicity Constraints Student Class Section Course Semester Instructor Department takes> is registered for> teaches> sponsors> <works for is instance of> is held during> 1..* 1 1 1 0..8 0..* 0..61..3

42. Multiplicity Constraints n 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

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

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

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

46. Dependencies n Syntax: –a dashed link with an straight-line arrowhead point to a component on which there is a dependency n Dependencies can be defined among: classes, notes, packages, and other types of components n Can dependencies go both ways? n Any problems with having lots of dependencies?

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

48. Aggregation n Aggregation: is a special kind of association that means “part of” n Aggregations should focus on single type of composition (physical, organization, etc.) 1 1 * 4..* 1 1 1 1 1..3 1 0..91 Pizza Order Slice Crust Sauce Serving Cheese Serving Topping Serving

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

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

51. More Questions n How do you know when a class diagram is complete? n How can you make the information captured in a class diagram more understandable? maintainable? reusable? n How can you manage change control on all the class diagrams for project? n What do you do with class diagrams after a system has been built and delivered?