Matakuliah : M0126 - Analisis dan Perancangan Sistem
Informasi Lanjut
Tahun
: 2009 - 2010
MODEL COMPONENT
Pertemuan 19-20
Learning Outcomes
Pada akhir pertemuan ini, diharapkan mahasiswa
akan mampu :
• Mahasiswa dapat membuat diagram / skema model
component (C4)
Outline Materi
• Mahasiswa dapat membuat diagram / skema component
architecture class
15 – 16 / 02 – 14
Connecting Components
Purpose
To connect system components
Concepts
– Coupling : A measure of how closely two
classes or components are connected
– Cohesion : A measure of how well a class or
component is tied together
15 – 16 / 03 – 14
Connecting Component (Cont’d)
Principles
– Highly cohesion classes and loosely
coupled components
Results
A class diagram of the involved
components
15 – 16 / 04 – 14
Coupling
•Outside coupling : A class or component refers directly to the public property of
another class or component
•Inside Coupling : An operation refers directly
in the same class
to
other, private properties
•Coupling from below : A specialized class refers directly to private properties in the
super class
•Sideways coupling : A class refers directly to
private properties in another class
Low Coupling
• Coupling is a measure of how strongly one element is
connected to, has knowledge of or relies on other
element.
• An element with low coupling is not dependent on too
many other elements ”too many” is context dependent
• BEST SOLUTION IS : LOW COUPLING:
Assign a responsibility so that coupling remain low
Design 1
In this figure Assign a responsibility to the class that has
the information needed to fulfill it, for example Board
Need information of Square, so getSquare has to
assign to BOARD
Design 2
•In this design a Board object has many Squares but an Object Dog has to
sent getAllSquares to Board Object and also it sent get(name) to Map Object
that probably has a needed square.
•Design 2 is Poor Design because it has High Coupling because to get Square
Dog has function getSquare to Board and Square and also Board has
getAllSquare
HIGH COHESION
Bad Cohesion (low cohesion) just imply an object does work only by itself,
indeed a low cohesion object has 2000 Line of Code that maybe has many
collaboration with other objects.
Figure 17.11 the left-hand version of Monopoly game has worse cohesion then
right-hand version because since the left-hand version is making the
Monopolygame Object itseft do all the work, rather then delegating and
HIGH COHESION
Figure 17.27 is another design of high cohesion because Make Payment
from Register is Pass on Object Sale and Object Sale with responsible to
Types of Cohesion
• Very Low cohesion: A Class is solely responsible for
many things in very different functional areas
• Low Cohesion: A Class has sole responsibility for a
complex task in one functional area
• High Cohesion: A Class has moderate responsibilities in
one functional area and collaborates with other classes
to fulfill tasks
• Moderate Cohesion: A Class has lightweight and sole
responsibility in a few different areas that are logically
related to the class concept but not to each other for
example Assume the existence of a class called
company that is completely responsible for (a) knowing
its employees and (b) knowing to financial information.
These two areas are not strongly related to each other,
although both are logically related to the concept of
Coupling
<<Class Module>>
IHewan
<Let>Nama(ByValue:String
Bersuara()
<<Class Module>>
CKambing
NamaHewan:String
Ckambing Class
Ihewan Class
Run
Cohesion
15 – 16 / 05 – 14
• Operation constitute a functional whole
• Attributes and object structure describe objects with well-
defined states
• Operation use each other
The following features point to cohesion
Components:
• Component classes are conceptually related
• Structural relations among classes are primarily
aggregations
• Key operations can be carried out within the component
generalizations and
15 – 16 / 06– 14
Sub-Activities in designing the connection between components
Class diagrams and
Component
specifications
Class diagram and
Component
specification
Connect
classes
Explore Pattern
Evaluate
Connection
15 – 16 / 07– 14
Connect Classes
There are three forms of connection:
 Aggregating another component’s class
 Specializing another component’s public class
 Calling public operation in another component’s objects
15 – 16 / 08– 14
Class Aggregation
<<Component>>
Function
Account
Management
<<Component>>
Model
account
Connection by class aggregation
15 – 16 / 09– 14
Class Specialization
<<Component>>
User Interface
Person W
Session W
<<Component>>
UI Library
Window
Connection by class Specialization
15 – 16 / 10 – 14
Operation Call
<<Component>>
System Interface
<<Component>>
Model
<<call>>
Connection by calling an operation
15 – 16 / 11 – 14
Class Specialization
<<Component>>
User Interface
Person W
Session W
<<Component>>
UI Library
Window
Connection by class Specialization
A Sequence Diagram for the
Observer Pattern
15 – 16 / 12 – 14
An Application of the Observer Pattern
15 – 16 / 13 – 14
<<component>>
<<component>>
Function
Function
<<call>>
<<call>>
<<component>>
<<component>>
Model
Model
subject
subject
observers
observers
15 – 16 / 14 – 14
A Review Checklist for Evaluating Connections
Coupling
Cohesion
Risks
Class Aggregation
Low : coupling from outside
Medium, if exagerated as more properties
are embedded
Loss of cohesion in the aggregates
Class Specialization
Medium, if private properties are
used
Medium, if exagerated as more properties
are added
Loss of cohesion in the subclasses and
possibility of increased level of coupling
Operation Call
Low : coupling from outside
High, if concerns are separated
Many classes and objects with
distributed responsibilities can become
too complex