MODEL COMPONENT Pertemuan Matakuliah: M Analisis dan Perancangan Sistem Informasi Lanjut Tahun:

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 to other, private properties in the same class 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 Solution : BETTER IS GET A DESIGN 1 ( LOW COUPLING) Because Board has all responsibility to get Square

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 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 distributing work among objects. THIS PRICIPLE OF HIGH COHESION

HIGH COHESION Figure is another design of high cohesion because Make Payment from Register is Pass on Object Sale and Object Sale with responsible to create Payment Object

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 company

Coupling > >CKambing NamaHewan:String IHewan <Let>Nama(ByValue:StringBersuara()

Ckambing Class

Ihewan Class

Run

15 – 16 / 05 – 14 Cohesion 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 generalizations and aggregations Key operations can be carried out within the component

15 – 16 / 06– 14 Sub-Activities in designing the connection between components Connect classes Explore Pattern Evaluate Connection Class diagrams and Component specifications Class diagram and Component specification

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 > Function Account Management > Model account Connection by class aggregation

15 – 16 / 09– 14 Class Specialization Person W Session W > User Interface > UI Library Window Connection by class Specialization

15 – 16 / 10 – 14 Operation Call > Model > System Interface > Connection by calling an operation

15 – 16 / 11 – 14 Class Specialization Connection by class Specialization Person W Session W > User Interface > UI Library Window

15 – 16 / 12 – 14 A Sequence Diagram for the Observer Pattern

15 – 16 / 13 – 14 An Application of the Observer Pattern > Function > Model > subject observers > Function > Model > subject observers

15 – 16 / 14 – 14 A Review Checklist for Evaluating Connections CouplingCohesionRisks 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