CS3773 Software Engineering Lecture 04 UML Class Diagram

UTSA CS  Objects are discrete entities with well defined boundaries and encapsulate – States – Behaviors  Classes represent types of objects that share a set of features: attributes, operations, and relations  Classes describe key concepts involved in the problem domain  Classes are basic building blocks of OO system Class and Object

UTSA CS  Elements of class diagram: – Class represented as a box containing three compartments Name Attributes Operations – Relation represented as a line between two classes Association Generalization Aggregation and composition UML Class Diagram Syntax

UTSA CS  UML class diagrams can be used in three distinct ways depending on the phase of system development: – Conceptual (Domain Models) Requirements phase The diagram represents the problem that the software should solve Classes are real-world concepts in the system's environment Not necessarily a direct mapping to how these will be implemented (although they may end up being classes in the software system) Class Diagram: Perspectives

UTSA CS – Design The diagram is complete: both attributes and operations The diagram depicts only the interfaces of software classes, but still avoids implementation details (information hiding) – Implementation The diagram depicts interfaces and implementations of classes Class Diagram: Perspectives

UTSA CS Class  Classes are entities from the problem domain – Actors that interact with system – Any information that the system stores, analyzes, transforms, displays, etc. – Transient objects e.g., business transactions, phone conversations, etc.  Classes are named, usually, by short singular nouns  Syntax: A box with three compartments for names, attributes, and operations respectively

UTSA CS Class Diagram – An Example

UTSA CS Identifying Class  Classes are usually derived from the use cases for the scenarios currently under development  Brainstorm about all the entities that are relevant to the system  Noun Phrases – Go through the use cases and find all the noun phrases – Watch out for ambiguities and redundant concepts

UTSA CS Attribute  Attributes are simple data associated with a class e.g., integer, sets, dates  Attributes are properties of a class  Attributes are information that distinguishes one instance of the class from another instance  They are distinguishing characteristics of the objects  Syntax: name: type = default value

UTSA CS Operation  Operations are the responsibilities/services of an object in the class  Operations query or transform values of object's attributes, change state  A class's attributes and operations document the purpose of the class --- what information it maintains, and how that information can be manipulated  Syntax: name (parameters) : return-type

UTSA CS Static Attribute and Operation  Static attributes model data values shared by all objects of the class e.g., number of objects  Static operations are class-related operations not offered by instances of the class e.g., “create ()”, “search ()”  Syntax: underlined attribute or operation

UTSA CS Association  An association is a relationship between classes  An association is a name, usually short verb – Some people name every association – Others name associations only when such names will improve understanding e.g., avoid names like “is related to”, and “has”  An association represents different types of relationships e.g., data flow, requests, parts of compound class

UTSA CS Association Syntax  An association may have – An association name – Multiplicity – Role names – Qualifier – Association class – Navigability

UTSA CS Multiplicity  Multiplicities on associations give lower and upper bound on the number of instances of the local class that can be linked to one instance of the remote class  Syntax: 1, *, etc. at the association end. Examples: – * (zero or more) – 1.. * (one or more) – (one to 40) – 5 (exactly 5) – If no multiplicity is specified, the default is 1

UTSA CS Multiplicity  Multiplicities on classes indicate how many instances of the class can be at run time  Multiplicities constrain the number of objects  Syntax: 1, *, etc. at the top right corner of class

UTSA CS Role Name  Is a part of association  Describes how the object at the association end is viewed by the associated object  Is useful for specifying the context of the class  Syntax: name at the association end

UTSA CS Qualified Association  Qualified association is an association key that identifies the object at the other end of the association  Qualifier is a key or index used to identify one or fewer objects from set of many objects  Qualifier is often an attribute of the class at the other end of the association, and the attribute is recognized as uniquely identifying one or fewer objects of the class.  Syntax: name in box at the end of an association

UTSA CS Association Class  Association class allows to add attributes, operations to an association  The association contains more information  Syntax: class connected to the association by a dashed line  Constraint: only one instance of association class between any two associated objects

UTSA CS Generalization  Indicates an “is-a” relationship  All instances of the subclass are instances of the super class  A subclass inherits all attributes, operations and associations of the parent  The common attributes and operations are placed in the superclass; subclasses extend the attributes, operations, and associations as they need them  Syntax: open triangle at the superclass end of the association

UTSA CS Aggregation  Indicates a loose “has-a” relationship  The compound class is made up of its component classes  Represents the “whole-part” relationship, in which one object consists of the associated objects – The whole controls the relationship – The part services requests from the whole  Syntax: hollow diamond at the compound class end of the association

UTSA CS Aggregation Semantics  Whole can exist independently of the parts  Part can exist independently of the whole  Whole is incomplete if some of the parts are missing  It is possible to have shared ownership of the parts by several wholes

UTSA CS Composition  Composition is a particular kind of aggregation  Component classes are physically part of the compound class e.g., a car is composed of an engine, wheels, etc.  The component class dies if the compound class dies  Syntax: filled diamond at the compound class end of the association

UTSA CS Composition Semantics  Component belong to exactly one compound at a time  Compound is responsible for the creation and destruction of all its components  Compound may also release its components to other compounds  If the compound is destroyed, it must either destroy all its components, or give responsibility for them over to some other classes

UTSA CS Review of Class Diagram  Class is a set of discrete entities that share the same features  Class encapsulates data (attributes) and functions (operations: queries of modifiers)  Multiplicity constrains the number of objects participating in a relationship at any point in time  Relationship represents connections between classes – Association: role name, qualifier, association class, navigability – Generalization – Aggregation and composition

UTSA CS UML Object Diagram  Object is an instance of some class  Object diagram is a snapshot of the objects in a system  Object diagram represents all the instances of classes (objects) and their associations (links) at a point of time  Object diagram gives better feeling of problem by showing examples

UTSA CS UML Object Diagram Syntax  Object is a box with two compartments: object name and attributes  Objects name is underlined – Class name alone – Object name alone – Object name concatenated with the class name, separated by a colon – Name convention: starting with a lowercase letter  Relations among objects are represented as links

UTSA CS UML Object Diagram – An Example Ann: Patron Jo: Patron Tom: Patron A: Book : Book1 : Book2 : Book

UTSA CS Reading Assignments  UML 2 and The Unified Process – Chapter 7, “Objects and classes” – Chapter 8, “Finding analysis classes” – Chapter 9, “Relationships” – Chapter 18, “Refining analysis relationships”