Sesi 7 Class Diagram

Chapter 7 Structural Modeling

Dana Indra Sensuse ([email protected]) Indra Budi ([email protected]) Most slides are adopted from the textbook “Systems Analysis and Design with the Unified Modeling Language, Version 2.0” Alan Dennis, Barbara Wixom, and David Tegarden © 2005

Analysis and Design Information System – MTI Fasilkom 2007

Key Ideas  



Use-case models provide an external functional view of the system (what the system does) A structural or conceptual models describe the structure of the data that supports the business processes in an organization. The structure of data used in the system is represented through CRC cards, class diagrams, and object diagrams.

Analysis and Design Information System – MTI Fasilkom 2007

Purpose of Structural Models 



A structural model is a formal way of representing the objects (things, ideas, and concepts) that are used and created by a business system Reduce the “semantic gap” between the real world and the world of software 

 

The real world tends to be messy, whereas the world of software must be neat and logical

Create a vocabulary for analysts and users to communicate effectively Structural model also allow the representation of the relationships between the objects

Analysis and Design Information System – MTI Fasilkom 2007

Essential Elements of a UML Class Diagram Class  Attributes  Operations  Relationships 

 Associations  Generalization  Specialization  Aggregation Analysis and Design Information System – MTI Fasilkom 2007

Classes  

Templates for creating instances or objects Types of class  



Concrete (has objects) Abstract

Another types: the type of real-world thing that it represents 

Application domain, user interface, data structure, file structure, operating environment, document, and multimedia classes

Analysis and Design Information System – MTI Fasilkom 2007

Attributes 



units of information relevant to the description of the class include only those attributes that are relevant to the current application 



“size” for a TV object is not necessary if the application is concerned only with connections between TV and other objects

do not attempt to include every attribute at the beginning more attributes can be added when the model is iterated  iteration of the model occurs almost at all times, particularly for large projects 

Analysis and Design Information System – MTI Fasilkom 2007

Attributes (Cont) 

Avoid derivable attributes; instead, create a function to derive each such attribute  “age”

can be derived from “birthday” and “current-date”  “total” of all transactions can be dynamically computed when necessary, rather than storing it somewhere  “discount price” can be computed using current-price and discount factor

Analysis and Design Information System – MTI Fasilkom 2007

Operations The behavior of the class will be defined  Action that instances/objects can take  Focus on relevant problem-specific operations, instead of basic operation like create instance, delete instance, access individual attribute, so on.  Will be converted into methods in next phase 

Analysis and Design Information System – MTI Fasilkom 2007

Relationships 

Generalization  Enables

inheritance of attributes and operations

 Ex: A

CUSTOMER class and an EMPLOYEE class can be generalized into a PERSON class by extracting the attributes and operations in common

 It

is represented with the a-kind-of relationship

Analysis and Design Information System – MTI Fasilkom 2007

Cont..  Generalization

(bottom-up approach)  Motivated by identifying similarities and common features among classes  “Part-time

Instructor” derived from “Instructor” and “Student” while modeling a department  “User” derived from “Customer”, “Bank Manager” and “Teller” while modeling an ATM system  “Material” derived from “Book”, “Journal” and “Magazine” while modeling a library catalog system

Analysis and Design Information System – MTI Fasilkom 2007

Cont..  We

can use “specialization” (top-down approach) “Employee”

become “ Secretary”,

“Engineer” “ Student” become “Full-time Student”, “Part-time Student” “TV” become “Plasma TV”, “Flat Panel TV”

Analysis and Design Information System – MTI Fasilkom 2007

Relationships (Cont..) 

Aggregation  Relates

parts to wholes  A part of or has parts A

door is a part of a car  An employee is a-part of a department 

Association  Miscellaneous

relationships between classes  A patient – an appointment

Analysis and Design Information System – MTI Fasilkom 2007



Identify as association if it is not clear whether it is association or aggregation “Mail”

has “Address” “Mail” uses “Address” for delivery “Customer” has “Address” “Customer” resides at “Address” “TV” includes “Screen” “TV” sends information to “Screen” “Customer” is a “Users” Analysis and Design Information System – MTI Fasilkom 2007

Identify as association if it is not clear whether it is association or aggregation  “Mail”

has “Address” (aggregation)  “Mail” uses “Address” for delivery (association)  “Customer” has “Address” (aggregation)  “Customer” resides at “Address” (association)  “TV” includes “Screen” (aggregation)  “TV” sends information to “Screen” (association)  “Customer” is a “Users” (generalization/specialization)

Analysis and Design Information System – MTI Fasilkom 2007

Deriving components of a class diagram from a usecase diagram 

Actors are potential candidates for classes  Sometimes,

class



an actor may not be modeled as a

Generalization or specialization between actors will end up in generalization or specialization relationship between the corresponding classes

Analysis and Design Information System – MTI Fasilkom 2007



Two actors will be related if they are connected through a series of use cases  The

classes corresponding to these actors will thus have an association  The ATM example – the actor “User” is related to “Account” because of the use cases “deposit” and “update account”

Analysis and Design Information System – MTI Fasilkom 2007

Your Turn 

What classes, attributes, and operations that would be required to describe a library system? 

An librarian name, birthdate, sex, etc  create_account, update, etc 

A

book

title, author, publisher, etc  loaned, lost, etc 



A catalogue

Analysis and Design Information System – MTI Fasilkom 2007

CLASS-RESPONSIBILITYCOLLABORATION CARDS

Analysis and Design Information System – MTI Fasilkom 2007

Responsibilities 

Knowing responsibilities are those things that an instance of a class must be capable of knowing.  An

instance of a class typically knows the values of its attributes and its relationship



Doing responsibilities are those things that an instance of a class must be capable of doing  An

instance of a class can execute its operations

Analysis and Design Information System – MTI Fasilkom 2007

Collaboration  

Objects working together to service a request Collaborations allow the analyst to think in terms of clients, servers, and contracts   



A client object is an instance of a class that sends a request to an instance of another class for an operation to be executed. A server object is the instance that receives the request from the client object. A contract formalizes the interactions between the client and server objects.

For example, a patient makes an appointment with a doctor. 

This sets up an obligation for both the patient and doctor to appear at the appointed time. Otherwise, consequences, such as billing the patient for the appointment regardless of whether the patient appears, can be dealt out. The contract should also spell out what the benefits of the contract will be, such as a treatment being prescribed for whatever ails the patient and a payment to the doctor for the services provided.

Analysis and Design Information System – MTI Fasilkom 2007

A CRC Card

Analysis and Design Information System – MTI Fasilkom 2007

Back of CRC Card

Analysis and Design Information System – MTI Fasilkom 2007

CLASS DIAGRAMS

Analysis and Design Information System – MTI Fasilkom 2007

Class diagram – basic syntax Class name

Association name

Attributes

Class name Attributes

Methods Component

aggregation Aggregate

Class name

specialization

Class name Attributes Methods Analysis and Design Information System – MTI Fasilkom 2007

This is a subclass

comments

Details of a class icon Account - Account number : Integer - Balance : Real - Overdraft : Boolean = true + GetAccountId () + public - private

# UpdateBalance (sign : Sign, amt : Integer)

# protected

- ChangeOverdraft ()

Analysis and Design Information System – MTI Fasilkom 2007

Initial value

Association –syntax Association label

Direction of association

uses

customer

User

Account

1

Manager

1

n cardinality

Account number Balance Overdraft Get accountID ()

Role names

Update balance()

es us

Unary association

{xor}

Return balance()

n Analysis and Design Information System – MTI Fasilkom 2007

Corporate Account

Association Class User

Account

Transaction

Job

Employee Salary

Analysis and Design Information System – MTI Fasilkom 2007

Association Class 

A piece of information that belongs to both classes in an association is put into a separate class called “association class”   

association class is a dependent class that depends on the other two classes in the association cannot exist independently object of an association class must refer to objects of the other two classes in the association 

Example: A “Transaction” object depends on a “User” object and on an “Account” object.

Analysis and Design Information System – MTI Fasilkom 2007

Example Class Diagram

Analysis and Design Information System – MTI Fasilkom 2007

Class Diagram Syntax A CLASS

Class 1 -attribute +operation ()

AN ATTRIBUTE AN OPERATION AN ASSOCIATION

Attribute name/ derived attribute name operation name () 1..* 0..1 ______verb phrase____

Analysis and Design Information System – MTI Fasilkom 2007

UML suggest for the class name Start with a capital letter  Be centered in the top compartment  Be written in a boldface font  Be written in italics if the class is abstract 

Analysis and Design Information System – MTI Fasilkom 2007

More on Attributes 

Derived attributes  /age,

for example can be calculated from birth date and current date



Visibility  Public

(+)  Protected (#)  Private (-)

Analysis and Design Information System – MTI Fasilkom 2007

More on Operations 

Constructor  Creates



Query  Makes



object

information about state available

Update  Changes

values of some or all attributes

Analysis and Design Information System – MTI Fasilkom 2007

More on Relationships  

Mean the relationship between one class with another Multiplicity of relationship      



exactly one: zero or more: one or more: zero or one: specified range: multiple disjoint ranges:

Association class

Analysis and Design Information System – MTI Fasilkom 2007

1 0..* 1..* 0..1 2..4 1..5,7

Multiplicity of relationship

Analysis and Design Information System – MTI Fasilkom 2007

Simplifying Class Diagrams 



When a class diagram is fully populated with all of the classes and relationships, it become very complex and difficult to interpret The view mechanism shows a subset of information  





View based on a particular use case View based on the relationship only or a particular relationship only (such as association) View based on subset of information such as class name only, attributes only, or operations only

Packages show aggregations of classes (or any elements in UML)

Analysis and Design Information System – MTI Fasilkom 2007

Object Diagrams

Analysis and Design Information System – MTI Fasilkom 2007

CREATING CRC CARDS AND CLASS DIAGRAMS

Analysis and Design Information System – MTI Fasilkom 2007

Object Identification 1. Textual analysis of use-case information  Nouns suggest classes  Verbs suggest operations  To identify:    



Object Attribute Operation Relationship

Creates a rough first cut

Analysis and Design Information System – MTI Fasilkom 2007

Textual Analysis Guideline

Analysis and Design Information System – MTI Fasilkom 2007

Object Identification 2. Common object list  Physical/tangible

(books, chairs)  Incidents (meetings, flight)  Roles (doctor, nurse)  Interactions (sales transaction)

Analysis and Design Information System – MTI Fasilkom 2007

Object Identification 

Pattern  Useful

groupings of classes that recur in various situations  Transactions Transaction class Transaction line item class Item class Location class Participant class Analysis and Design Information System – MTI Fasilkom 2007

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 classe attributes, operations, and relationships. 6. Incorporate useful patterns. 7. Review the structural model. Analysis and Design Information System – MTI Fasilkom 2007

Application Example:

Analysis and Design Information System – MTI Fasilkom 2007

Step 1. Create CRC cards by performing textual analysis on the use-cases Textual Analysis: Nouns suggest classes

Analysis and Design Information System – MTI Fasilkom 2007

Step 1. Create CRC cards by performing textual analysis on the use-cases Textual Analysis: Nouns suggest classes • Textual Analysis Results: Identified potential classes Customer  Search Request  CD  CD List  Review (i.e., CD review information) If further analyse the Maintain Order and Checkout use cases, further potential classes will be identified such as  Order  Order Item  Credit card centre  etc 

Analysis and Design Information System – MTI Fasilkom 2007

Step 1. Create CRC cards by performing textual analysis on the use-cases Textual Analysis: Verbs suggest operations: •

For each identified class, check the related verbs to identify the operations as well as the relationships with other classes

Analysis and Design Information System – MTI Fasilkom 2007

Step 1. Create CRC cards by performing textual analysis on the use-cases Textual Analysis: Verbs suggest operations: •

Textual Analysis Result: For Customer Class, the identified operations (i.e., Responsibilities) and the relationship with other classes (i.e., Collaborators) are Make Search

Search

request Place Order Get Credit Card

request Order Credit Card Centre

Info Exit Select CD for Info

CD List Not include as it can be included in Search request

This forms the front of “Customer class” CRC Card Analysis and Design Information System – MTI Fasilkom 2007

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

Textual Analysis Result: Combine “nouns and verbs” analysis, the back of “Customer class” CRC Card can be

Order; Search request; Credit Card Centre Analysis and Design Information System – MTI Fasilkom 2007

Step 2 and 3. Examine Common Object Lists and Role-play the CRC Cards 1. Brainstorm additional candidate classes, attributes, operations, and relationships by using the common object list approach. 2. Role-play each use-case using the CRC cards. Possible outcomes: Search request class need having 3 sub-classes: Title Search, Artist Search and Category Search

Analysis and Design Information System – MTI Fasilkom 2007

Step 4. Create the Class Diagram based on the CRC Cards • Exercise. Suppose the CRC card of Customer class is given as before, create the class diagram based on it. • For customer class, assume that all attributes are private type whereas all operations are public type • For other associate classes, only the class names and the relationships with the customer class need to be given

Analysis and Design Information System – MTI Fasilkom 2007

Step 4. Create the Class Diagram based on the CRC Cards

• Solution:

Credit Card Centre

Order Customer

0..* Check ->

0..*

-First name -Middle initial -Last name -…… +Make search req() +Place order() +Get credit info() +Exit() 0..*

1

place ->

Make ->

Analysis and Design Information System – MTI Fasilkom 2007

0..*

Search Reg 0..*

Step 5, 6 and 7: Review Classes Diagrams, Incorporate Patterns, and Review the Model 1. Review the class diagrams and structural model for any missing and/or redundancy 2. Incorporate useful patterns. • One possible pattern

3. Review the structural model. Analysis and Design Information System – MTI Fasilkom 2007

Summary  



CRC cards capture the essential elements of a class. Class and object diagrams show the underlying structure of an object-oriented system. Constructing the structural model is an iterative process involving: textual analysis, brainstorming objects, role playing, creating the diagrams, and incorporating useful patterns.

Analysis and Design Information System – MTI Fasilkom 2007