Sesi 7 Class Diagram

Chapter 7
Structural Modeling
Dana Indra Sensuse (dana@cs.ui.ac.id)

Indra Budi (indra@cs.ui.ac.id)
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.
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
Essential Elements of a UML
Class Diagram
 Class
 Attributes
 Operations
 Relationships
 Associations
 Generalization
 Specialization
 Aggregation
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
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
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
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
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
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
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”
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
 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”
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)
Deriving components of a class
diagram from a usecase diagram
 Actors are potential candidates for classes
 Sometimes, an actor may not be modeled as a
class
 Generalization or specialization between
actors will end up in generalization or
specialization relationship between the
corresponding classes
 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”
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
CLASS-RESPONSIBILITY-
COLLABORATION CARDS
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
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.
A CRC Card
Back of CRC Card
CLASS DIAGRAMS
Class diagram – basic syntax
Association Class name
Class name
name
Attributes Attributes
Methods
aggregation Component
Aggregate Class name

specialization
Class name
This is a
Attributes subclass
Methods
comments
Details of a class icon
Account
Initial value
- Account number : Integer
- Balance : Real
- Overdraft : Boolean = true
+ GetAccountId ()
+ public # UpdateBalance (sign : Sign, amt :
- private Integer)
# protected - ChangeOverdraft ()
Association –syntax
Association label Direction of association
customer uses
User Account
1 Account number
n
Manager Balance
1
cardinality Overdraft
Get accountID ()
Role names
Update balance()
{xor} Return balance()
us
Unary association
es
Corporate Account
n
Association Class
User Account
Transaction
Employee Job
Salary
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.
Example Class Diagram
Class Diagram Syntax
A CLASS Class 1
-attribute
+operation ()
AN ATTRIBUTE Attribute name/

derived attribute name
AN OPERATION
operation name ()
AN ASSOCIATION
1..* 0..1
______verb phrase____
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
More on Attributes
 Derived attributes
 /age, for example can be calculated from birth
date and current date
 Visibility
 Public (+)
 Protected (#)
 Private (-)
More on Operations
 Constructor
 Creates object
 Query
 Makes information about state available
 Update
 Changes values of some or all attributes
More on Relationships
 Mean the relationship between one class with
another
 Multiplicity of relationship
 exactly one: 1
 zero or more: 0..*
 one or more: 1..*
 zero or one: 0..1
 specified range: 2..4
 multiple disjoint ranges: 1..5,7
 Association class
Multiplicity of relationship
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)
Object Diagrams
CREATING CRC CARDS AND
CLASS DIAGRAMS
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
Textual Analysis Guideline
2. Common object list
 Physical/tangible (books, chairs)
 Incidents (meetings, flight)
 Roles (doctor, nurse)
 Interactions (sales transaction)
 Pattern
 Useful groupings of classes that recur in
various situations
 Transactions
Transaction class
Transaction line item class
Item class
Location class
Participant class
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.
Application
Example:
Step 1. Create CRC cards by performing
textual analysis on the use-cases
Textual Analysis: Nouns suggest classes
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
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
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 request
Order
Get Credit Card
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
• Textual Analysis Result: Combine “nouns and verbs” analysis, the
back of “Customer class” CRC Card can be
Order; Search request; Credit Card Centre

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
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
Step 4. Create the Class Diagram based
on the CRC Cards
• Solution:
Credit Card Centre
Order
Customer 0..*
1
-First name
0..* place ->
-Middle initial
Check -> 0..* -Last name
-……
+Make search req()
+Place order()
+Get credit info() Search Reg
+Exit()
0..* 0..*
Make ->
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.

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.

Sesi 7 Class Diagram

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Sesi 7 Class Diagram

Hochgeladen von

Copyright:

Verfügbare Formate

Chapter 7

Dana Indra Sensuse (dana@cs.ui.ac.id)

 Focus on relevant problem-specific

 “Customer” has “Address” (aggregation)

 “Customer” resides at “Address” (association)

 “TV” includes “Screen” (aggregation)

 “TV” sends information to “Screen” (association)

Aggregate Class name

AN ATTRIBUTE Attribute name/

 Be written in a boldface font

 Be written in italics if the class is abstract

 Roles (doctor, nurse)

 Interactions (sales transaction)

Transaction line item class

2. Brainstorm additional candidate classes, attributes, operations, and

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

6. Incorporate useful patterns.

7. Review the structural model.

Make Search Search

Order; Search request; Credit Card Centre

1. Brainstorm additional candidate classes,

Possible outcomes: Search request class need

• Exercise. Suppose the CRC card of Customer

3. Review the structural model.

Das könnte Ihnen auch gefallen