CSIS3600 Systems Analysis and Design Class Identification and Class Diagrams.

CSIS3600 Systems Analysis and Design

Class Identification and Class Diagrams

Objects

• In object oriented analysis, the world is modeled in objects.

• Objects are entities that have a well-defined role within the system.

• An object can be tangible or visible (i.e. person, place or thing) or a concept of event (department, registration, etc.) or an artifact of the design process (user interface, scheduler, etc.).

• Objects are nouns.

Object Properties

• Objects are described both by their properties (attributes and relationships) and by their behavior (how the object acts and reacts).

• Objects represent categories while an object instance is a specific occurrence of the object.

• To remove any confusion, some texts use the terminology object class to refer to the set of objects.

Object Defined

An object is an entity which has a state and a defined set of operations which operate on that state. The state is represented as a set of object attributes. The operations associated with the object provide services to other objects (clients) which request these services when some computation is required. Objects are created according to some object class definition. An object class definition serves as a template for objects. It includes declarations of all the attributes and services which should be associated with an object of that class.

Ian Summerville, Software Engineering, 2000

Object Encapsulation

• Object encapsulation is the term used to describe the representation of objects by their attributes and behavior.

• It is important to remember that an object is "solely responsible for carrying out any functions or behaviors that act on its own data."

• The internal workings of an object are private - other objects can see only the interface.

• You should also note that the attributes of an object can be other objects and the behavior of an object can use other objects.

Object Classification

Objects are represented by classification and class hierarchies. Several principles relate to this process. These include:

Class - an abstraction describing objects of the same kind.

Object - instance of a class. Objects contain attributes - data property of an object (variable, etc.) and methods - behavioral property of an object (operation, function, etc.) Methods are invoked by a call (message).

Object Classification continued

Inheritance - relationship between a more specialized class and its more generalized parent class.

Generalization/specialization - Abstracting common features (attributes and operations) among multiple classes into a more general class.

Supertype - class that stores attributes common to one or more class subtypes of the object.

• Subtype - a class who inherits some common attributes from a class supertype and adds attributes that are unique to the subtype.

Understanding Classes

A class is a collection of objects with a common structure, common behavior, common relationships and common semantics.

– class name: noun representing the class domain.

– attributes: characteristics of the class - identified by examining class definitions, problem requirements and domain knowledge - current attribute values define an object's state.

– behaviors: represents operations and functions and are found by examining object interactions

Object Identification

• Identifying objects is the most difficult part of object oriented design.

• There is no 'magic formula' for object identification. It relies on the skill, experience .and domain knowledge of system designers.

• Object identification is an iterative process. You are unlikely to get it right first time.

Example of Single Class Diagram(s)

Class Name

Attributes……

Methods……

Course

NameNumber of Credits

OpenAddStudent

Student

NameStudentIDYear...

Calc-age ()Calc-gpaRegister for (course)...

Classes are drawn as a rectangle with three compartments:

Object Instance Diagram

• An object diagram is also known as an instance diagram or a graph of instances that are compatible with a given class diagram.

UML Class and Object Diagrams

(a) Class Diagram Showing Two Classes

(b) Object Diagram with Two Instances

An office information system• The Office Information Retrieval System (OIRS) is

an automatic file clerk which can file documents under some name in one or more indexes, retrieve documents, display and maintain document indexes, archive documents and destroy documents. The system is activated by a request from the user and always returns a message to the user indicating the success or failure of the request.

FileRetrieveArchiveDestroy

Document

Name

DisplayDelete entryAdd entry

Index

Name

Get commandPut message

User Retrieval System

User commandUserID

Preliminary Object Identification


Document

Name


Index

Name


User Retrieval System

User commandUserID

• Nouns in the description give pointers to objects in the system.

• Verbs give pointers to operations associated with objects.

• Approach assumes that the designer has a common sense knowledge of the application domain as not all objects and services are likely to be mentioned in the description.

OperationsOperations are functions or services provided by all instances of a class (calc-gpa, delete, display, etc.).

There are three types of operations:– Constructor – creates a new instance of a class.

– Query – Accesses a state of an object but does not alter the state.

– Update – it alters the state of an object.


Document

Name


Index

Name


User Retrieval

User commandUserID

A Word on Attributes

• Visibility of attributes may be shown– Visibility relates to information hiding

• + public – not hidden from any other object

• # protected – hidden from all classes except its immediate subclass

• - private – hidden from all other classes


Document

Name


Index

Name


User Retrieval

User commandUserID+ +

The Class DiagramThe class diagram is a central modeling technique that runs through nearly all object-oriented methods.

This diagram describes the types of objects in the system and various kinds of static relationships which exist between them.

There are three principal kinds of relationships: – associations (a customer may rent a number of

videos)

– subtypes (a nurse is a kind of person)

– aggregation (an engine is part of an aircraft).

(note:one class can be part of many class diagrams.)

Example Class Diagram

Perspectives of Class Diagrams

There are three perspectives you can use in drawing class diagrams

Conceptual: In this case you are drawing a diagram that represents the concepts in the domain under study. These concepts will naturally relate to the classes that implement them, but it is often not a direct mapping. Indeed the model is drawn with little or no regard for the software that

might implement it. Specification: In this case, you are looking at software, but you are

looking at the interfaces of the software, not the implementation. We are thus looking at types rather than classes.

Implementation: In this view we really do have classes and we are laying the implementation base. This is probably the most often used perspective in the design phase of systems development, but in many ways the specification perspective is often a better one to take.

Perspective continued

• Understanding the perspective is crucial to drawing and reading the class diagram.

• The perspective determines its use.Remember OOAD is iterative.The conceptual diagram is refined for specification and implementation.

Basic Elements of Class Diagrams

On a class diagram, it is recommended that only the most often needed elements be listed These include

Class Relationship:

Generalization Associations Multiplicity

Symbols of the Class Diagram

• Box – Represents the class.Broken down into 3 parts – Name, attributes and operations

• Line – represents association with number representing multiplicity.Line with an arrow represents navigation

• Connecting lines with arrows – represent generalization of superclass – subclass

• {} - constraints or rules – provided for major constraints only

• open diamond – shows aggregation (closed diamond shows composition)

• Box with flipped edge depicts notes

Representing Notes (business rules)

Class Relationships

• Relationships between classes are discovered by examining interactions between objects.

• If two objects must 'talk,' there must be a pathway for communication.

Types of RelationshipsThere are three primary types of relationships

Generalization – enables inheritance of attributes and operations. Shown as connecting lines with arrows

Association - a bi-directional connection between classes. Shown as a line connecting related classes.

Aggregation - stronger from of relationship between a whole and its parts. Shown as a line connecting the related classes with a hollow diamond next to the class representing the whole.

Dependency - weaker form of relationship showing a relationship between a client and a supplier where the client does not have a semantic knowledge of the supplier. Shown as a dashed line pointing from the client to the supplier.

Association Naming on Class Diagrams

• Associations are named - use verbs that have meaning – ie is-contained

• Sometimes they imply messages to be sent

• Roles (each end of the association) are named if needed or if the association is between objects of the same class

Diagram role naming

Derived Attributes, Associations and Roles

• Derived attribute, association or role is one that can be computed or derived from other attribute, associations and roles.

• A derived element is shown by placing a slash / before the name of the element

Derived Attribute, Association, and Role

• Age is derived attribute of student – calculated from date of birth and current date – shown in braces.

• Takes is derived because it can be inferred from the other relationships Registers-for and Schedule-for

• Participants is derived because it can be derived from other roles.

Relationship Attributes/Operations

• Some relationships have attributes and operations.

• They are added as an association class and depicted with a dashed line.

• The association class does not exist without the original association.

Performer Performance

PerformanceContract

Relationship Association Example

Customer

nameaddressscredit cardarea codephone no.

Purchase

/ totalservice chargedelivery chargefacility chargesales tax

calculate total()sum purchase price()receive payment ()claculate change()add item()

Charge

exiration dateaccount numberissuer

authorize credit ()

Aggregation

Aggregation - stronger from of relationship between a whole and its parts. Shown as a line connecting the related classes with a hollow diamond next to the class representing the whole.

a stronger form of aggregation is composition (depicted with a solid diamond). Composition is used when a part object belongs t only one whole object and lives and dies with the whole object – room in a building.

Aggregation and Composition

(a) Class Diagram

(b) Object Diagram

Adding Inheritance

• Inheritance is a relationship between a superclass and its subclasses.

• There are two ways to find inheritance - generalization and specialization.

• Inheritance identifies common attributes, operations and/or relationships and places them at the highest level in the hierarchy.

• Inheritance reduces redundancy and improves efficiency.

Abstract

• An abstract class is a class that has no direct instances(Concrete class is a class that has direct instances).– Examples include university students who must

be identified by their standing.The abstract class is student but student does not have any direct instances. Student descendants – Graduate and Undergraduate have instances.

• Abstract classes are shown in italics or {abstract} with the word abstract in braces.

Adding Multiplicity

• Multiplicity is also shown between class relationships (as is done with cardinality in ER diagrams).

• Multiplicity defines how many objects participate in a relationship. Multiplicity is bi-directional - one for each end of the relationship. When thinking of multiplicity, you define it as the number of instances of one class related to the ONE instance of the other class.

• While associations and aggregation are bi-directional by default, is often desirable to restrict navigation to one direction. If this is done, an arrowhead is added to indicate the direction of the navigation.

Examples of Association Relationships of Different Degrees

Object Diagrams

• A method used to quickly identify relationships is the Object Diagram.

• In its simplest form, an Object Diagram depicts classes and their relationships to other classes without adding detail.

• The object diagram is used as a tool upon which the Class Diagram can be built.

Example Object Diagram

Once Again – Rules on Modeling

Class diagrams are the backbone of OO methods soused quite frequently. The trouble is that they are so rich that they can be overwhelming. Here are a few tips to remember:

Don't try to use all the various notations. Start with the simple: classes, associations, attributes, and generalization. Introduce other notations only when you need them.

Don't draw models for everything, concentrate on the key areas. It is better to have a few diagrams that you use and keep up-to-date than many forgotten, out-of-date models.

Rules continued

• Modeling is iterative.

• Sort out which perspective you are drawing the models from. – If you are in analysis draw conceptual models.– When working with software concentrate on

specification models. – Draw implementation models only when you

are illustrating a particular implementation technique.

Identifying Classes

• Identifying objects/classes is the most difficult part of OOAD.

• There is no magic formula.

• It relies on skill, experiences and knowledge of the system domain.

• It is an iterative process.

• Objects/classes can be identified throughout the OOAD process.

Suggested Approaches to Object Identification

• Use a grammatical approach based on a natural language description of the system.

• Base the identification on tangible things in the application domain.

• Use a behavioral approach and identify objects based on what participates in what behavior

• Use a scenario-based analysis (use case descriptions).

Object Identification• Textual analysis of use-case information

– Nouns suggest classes– Verbs suggest operations

• Creates a rough first cut• Common object list• Incidents• Roles

PowerPoint Presentation for Dennis, Wixom & Tegardem Systems Analysis and Design

Copyright 2001 © John Wiley & Sons, Inc. All rights reserved.



Patterns• Useful groupings of classes that recur in various

situations• Transactions

– Transaction class– Transaction line item class– Item class– Location class– Participant class

Other ideas for Classes

• Templates for creating instances or objects– Concrete

– Abstract

• Typical examples:– Application domain

– user interface

– data structure

– file structure

– operating environment

– Document

– and multimedia classes



• A good place to start the identification of system classes and objects is by analyzing use cases. You can begin by simply finding all the nouns and then assessing whether they really are an object or simply an attribute.

• Another commonly used technique relies on 'role-play' to act out use cases. A class of objects is identified and then what the class does and whom it does it with are identified. The results are reported on a Class Responsibility Collaboration (CRC) card.

Approaches to identification

Steps for Object Identification and Structural Modeling

1. Create CRC cards by performing textual analysis on the use-cases.

2. Brainstorm additional candidate classes, attributes, operations, and relationships by using the common object list approach.

3. Role-play each use-case using the CRC cards.

4. Create the class diagram based on the CRC cards.

5. Review the structural model for missing and/or unnecessary classes, attributes, operations, and relationships.

6. Incorporate useful patterns.

7. Review the structural model.



Example CRC Card

CLASS [class name]

Responsibilities Collaborators

List of things class mustknow and do

List of other classeswhich help thisclass fulfill itsresponsibilities

Course Registration System

CLASS [Student]


Remember name andmajor

Remember the selectedCourse Offerings

Course Offerings

Course Registration System Example

CLASS [Registration Form]


Display Student Info

Display available courses

Display chosen courses

Registrar

RegistrationManager

A CRC Card

Front: Class name: ID: Type:

Description:

Responsibilities : Collaborators:

Back:

Attributes:

Relationships:

Generalization (a-kind-of):

Aggregation (has-parts):

Other Associations: PowerPoint Presentation for Dennis, Wixom & Tegardem Systems Analysis and Design


• For a description of how to play the CRC game visit http://members.aol.com/humansandt/techniques/crc.htm

• CRC Tutorial:

http://www.csc.calpoly.edu/~dbutler/tutorials/winter96/crc_b/

http://ftp.ics.uci.edu/pub/arch/uml/tours/bdClassDiagram.html

CRC Resources

http://members.aol.com/humansandt/techniques/crc.htm
















Quote of the Week:

It is difficult to introduce both novice and experienced procedural programmers to the anthropomorphic perspective necessary for object-oriented.We introduce CRC cards, which characterize objects by class name, responsibilities and collaborators, as a way of giving learners a direct experience of objects.

Kent Beck and Ward Cunningham, inventors of the CRC card approach.

CSIS3600 Systems Analysis and Design Class Identification and Class Diagrams.

Documents

Transcript of CSIS3600 Systems Analysis and Design Class Identification and Class Diagrams.