2. MODEL COMPONENT Pertemuan 19-20 Matakuliah: M0126 - Analisis dan Perancangan Sistem Informasi Lanjut Tahun: 2009 - 2010

3. Learning Outcomes Pada akhir pertemuan ini, diharapkan mahasiswa akan mampu : Mahasiswa dapat membuat diagram / skema model component (C4)

4. Outline Materi Mahasiswa dapat membuat diagram / skema component architecture class

5. 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

6. 15 – 16 / 03 – 14 Connecting Component (Cont’d) Principles –Highly cohesion classes and loosely coupled components Results A class diagram of the involved components

7. 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

8. 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

9. 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

10. 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

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

12. 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 create Payment Object

13. 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

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

15. Ckambing Class

16. Ihewan Class

17. Run

18. 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

19. 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

20. 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

21. 15 – 16 / 08– 14 Class Aggregation > Function Account Management > Model account Connection by class aggregation

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

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

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

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

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

27. 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