Download
1 / 21
210 likes | 341 Views
Chapter 3 Class Diagrams: The Essentials. Terms and Concepts. A class is ... The most important building block of any object-oriented system. A description of a set of objects that share the same attributes and behaviors. A blueprint for creating an object.
E N D
Terms and Concepts • A class is ... • The most important building block of any object-oriented system. • A description of a set of objects that share the same attributes and behaviors. • A blueprint for creating an object. • An abstraction (simplification) of reality. • A representation of a software thing, a hardware thing, or even a conceptual thing. • Graphically represented as a rectangle.
Terms and Concepts • All classes have … • Names - Used to distinguish one class from another. A class must have a name. • Attributes - Member data • Operations (behaviors) - Member functions (C++) or methods (Java) • Responsibilities • Class names are … • extracted from the problem domain (statement) • nouns or noun phrases • concise and descriptive
Terms and Concepts • Class attributes are … • usually nouns or noun phrases. • extracted or inferred from the problem statement. • used to represent properties of the enclosing class. • determine the state of an object • usually notated using the format • visibility name: type multiplicity = default {property string} • example: - firstName: String = ‘Bob’ {read only} • optionally notated as associations
Terms and Concepts • Class operations (behaviors) are … • named using a verb or verb phrases. • inferred from the problem statement. • Provide a requested service. • usually notated using the format • visibility name (parameter-list) : return-type {property-string} • example: +printFirstName( ) : void • Class responsibility… • Is a contract or obligation of a class to the users of the class. • Maps directly to the Responsibility field of a CRC card. • CRC - Class Responsibility Collaboration
Common Modeling Techniques • Identify the classes that are to be included in the design. • Formulate a problem statement. The problem statement may be scenarios associated with use cases. • Identify the nouns in the problem statement. • Use CRC (Class, Responsibility, Collaboration) cards or use-cases to isolate each class. • Determine the responsibilities of each class. • Even out the work load between classes. • A class with too much responsibility should be broken up into multiple classes. • A class with too little responsibility should be absorbed into another class.
Common Modeling Techniques • Classes should exhibit high cohesion and low coupling. • A class should have a single well-defined purpose. • This promotes software reusability • A class should interact with a limited number of other classes. • This simplifies modifications to the program. • Feel free to model abstract (non-software) things (such as people) that are outside of the system boundaries.
Associations • An association is … • a type of relationship that can exist between one or more classes. • used to show a ‘knows-a’ relationship. • either unidirectional or bidirectional. • graphically represented by a solid line which may optionally be labeled and have a name direction indicator or navigability arrows. • an alternative notation for a class attribute • Association names are verbs or verb phrases. • The same class can be on both ends of an association.
Associations • Associations may optionally have role names and multiplicity symbols on either end of the association line (next to the class icon). • Role • The face that a class on one end of an association presents to the class on the other end of the association. • A class can participate in many associations and thus have multiple (different) roles. • Role names are nouns. • Role names are usually used in place of association names.
Multiplicity • Multiplicity • Indicates how many object may be connected across an instance of an association. • Commonly used multiplicities • 1 • 0..1 • * • The default multiplicity of an attribute is ‘1’
Generalization • Generalization is … • a type of relationship that can exist between two classes. One of the classes is the base (or parent) class; the other class is the derived (or child) class. • used to show a ‘kind-of’ relationship. • another name for inheritance. • graphically represented by a solid line with an open triangular arrowhead on the base class end. • The parent class has no knowledge of the child class. • All OO programming languages support single inheritance; some (C++) also support multiple inheritance.
Common Modeling Techniques • Modeling inheritance (generalization) • Make it a priority to look for possible inheritance relationships. This will reduce code redundancy. • Use the “ClassA ‘is-a-kind-of’ ClassB” test. • Do not model relationships using multiple inheritance unless the implementation language supports multiple inheritance. This will save programmers having to develop messy work-arounds. • Look for classes that have similar attributes and behaviors and then factor those attributes and behaviors into a common base class.
Notes and Comments • Use notes to embed comments into UML diagrams. • The comment may contain links to other documents. • A note may stand alone or be attached to a graphical element. • A dashed line is customarily used as the connector • Use notes when a picture is not enough.
Dependency • A dependency is ... • A type of relationship that can exist between two classes. • An indication that one class ‘uses’ another class. • If the ‘used’ class changes it can have an impact on the ‘using’ class. • Graphically represented as a dashed line with an open arrowhead on one end. • Rarely labeled. • The ‘used’ class is frequently an argument to one of the member functions of the ‘using’ class. • The “used” class has no knowledge of the “using” class.
