Component Design

1. Component Design Pedro Mejia Alvarez CINVESTAV-PN

2. Main Contents What is component design Basic design principles Modularity and Information hiding Component design process

3. 1. What is component design ——What is a Component? • OMG Unified Modeling Language Specification [OMG01] defines a component as • “… a modular, deployable, and replaceable part of a system that encapsulates implementation and exposes a set of interfaces.” • OO view: a component contains a set of collaborating classes • Conventional view: logic, the internal data structures that are required to implement the processing logic, and an interface that enables the component to be invoked and data to be passed to it.

4. 1. What is component design —— OO Component

5. 1. What is component design —— Conventional Component

6. 2. Basic Design Principles Class Design Principles Package Design Principles Package Coupling Principles

7. 2. Basic Design Principles——Class Design Principles • Single Responsibility Principle (SRP) • Open/Closed Principle (OCP) • Liskov Substitution Principle (LSP) • a.k.a. Design by Contract • Dependency Inversion Principle (DIP) • Interface Segregation Principle (ISP)

8. 2. Basic Design Principles—— Single Responsibility Principle (SRP) A class should have only one reason to change Robert Martin Related to and derived from cohesion, i.e. that elements in a module should be closely related in their function Responsibility of a class to perform a certain function is also a reason for the class to change

9. 2. Basic Design Principles—— SRP Example Separated responsibilities All-in-one wonder Always changes to 4vector Changes to rotations or boosts don't impact on 4vector

10. 2. Basic Design Principles—— SRP Summary • Class should have only one reason to change • Cohesion of its functions/responsibilities • Several responsibilities • mean several reasons for changes → more frequent changes • Sounds simple enough • Not so easy in real life • Tradeoffs with complexity, repetition, opacity

11. 2. Basic Design Principles—— Open/Closed Principle (OCP) Modules should be open for extension, but closed for modification Bertrand Meyer Object Oriented Software Construction Module: Class, Package, Function New functionality → new code, existing code remains unchanged "Abstraction is the key" → cast algorithms in abstract interfaces develop concrete implementations as needed

12. 2. Basic Design Principles—— Abstraction and OCP Client is closed to changes in implementation of Server Client is open for extension through new Server implementations Without AbsServer the Client is open to changes in Server

13. 2. Basic Design Principles—— Liskov Substitution Principle (LSP) All derived classes must be substituteable for their base class Barbara Liskov, 1988 The "Design-by-Contract" formulation: All derived classes must honor the contracts of their base classes Bertrand Meyer

14. 2. Basic Design Principles—— LSP:The Square-Rectangle Problem Clients (users) of Rectangle expect that setting height leaves width unchanged (and vice versa) Square does not fulfill this expectation Client algorithms can get confused

15. 2. Basic Design Principles—— Dependency Inversion Principle (DIP) Details should depend on abstractions. Abstractions should not depend on details. Robert Martin Why dependency inversion? In OO we have ways to invert the direction of dependencies, i.e. class inheritance and object polymorphism

16. 2. Basic Design Principles—— DIP Example Dependency changed from concrete to abstract ... The abstract class is unlikey to change ... at the price of a dependency here, but it is on an abstraction. Somewhere a dependency on concrete Server must exist, but we get to choose where.

17. 2. Basic Design Principles—— DIP and Procedural Design Procedural: Call more concrete routines Dependence on (reuseable) concrete modules In reality the dependencies are cyclic → need multipass link and a "dummy library" The BaBar Framework classes depend on interfaces Can e.g. change data store technology without disturbing the Framework classes

18. 2. Basic Design Principles—— ISP Explained • Multipurpose classes • Methods fall in different groups • Not all users use all methods • Can lead to unwanted dependencies • Clients using one aspect of a class also depend indirectly on the dependencies of the other aspects • ISP helps to solve the problem • Use several client-specific interfaces

19. 2. Basic Design Principles—— ISP Example: UIs The Server "collects" interfaces New UI → Server interface changes All other UIs recompile UIs are isolated from each other Can add a UI with changes in Server → other UIs not affected

20. 2. Basic Design Principles—— Three Package Design Principles Reuse-Release Equivalency Principle Common Closure Principle Common Reuse Principle

21. 2. Basic Design Principles—— Reuse-Release Equivalency Principle (REP) The unit of reuse is the unit of release Bob Martin It is about reusing software Reuseable software is external software, you use it but somebody else maintains it. There is no difference between commercial and non-commercial external software for reuse.

22. 2. Basic Design Principles—— REP Summary • Group components (classes) for reusers • Single classes are usually not reuseable • Several collaborating classes make up a package • Classes in a package should form a reuseable and releaseable module • Module provides coherent functionality • Dependencies on other packages controlled • Requirements on other packages specified • Reduces work for the reuser

23. 2. Basic Design Principles—— Common Closure Principle (CCP) Classes which change together belong together Bob Martin Minimise the impact of change for the programmer. When a change is needed, it is good for the programmer if the change affects as few packages as possible, because of compile and link time and revalidation

24. 2. Basic Design Principles—— CCP Summary • Group classes with similar closure together • package closed for anticipated changes • Confines changes to a few packages • Reduces package release frequency • Reduces work for the programmer

25. 2. Basic Design Principles—— Commom Reuse Principle (CRP) Classes in packages should be reused together Bob Martin Packages should be focused, users should use all classes from a package CRP for packages is analogous to SRP for classes

26. 2. Basic Design Principles—— CRP Summary • Group classes according to common reuse • avoid unneccessary dependencies for users • Following the CRP often leads to splitting packages • Get more, smaller and more focused packages • Reduces work for the reuser

27. 2. Basic Design Principles—— Three more package design principles Acyclic Dependencies principles Stable Dependencies principles Stable Abstractions principles

28. 2. Basic Design Principles—— The Acyclic Dependencies Principle (ACP) The dependency structure for packages must be a Directed Acyclic Graph (DAG) Stabilise and release a project in pieces Avoid interfering developers Morning after syndrome Organise package dependencies in a top-down hierarchy

29. 2. Basic Design Principles—— Dependencies are a DAG It may look complicated, but it is a DAG (Directed Acyclic Graph) Can exchange ObjyIO and RootIO

30. 2. Basic Design Principles—— Dependency Cycles A cycle between Framework and ObjyIO Must develop together May need multipass link

31. 2. Basic Design Principles——Stable Dependencies Principle (SDP) Dependencies should point in the direction of stability Robert Martin Stability: corresponds to effort required to change a package stable package  hard to change within the project Stability can be quantified

32. 2. Basic Design Principles—— SDP Example Good Bad A is responsible for B, C and D. It depends on E, → irresponsible A is responsible for B, C, D and E. It will be hard to change E depends on F, G and H. A depends on it. E is responsible and irresponsible. E depends on A, F, G and H. It is irresponsible and will be easy to modify.

33. 2. Basic Design Principles—— SDP Summary • Organise package dependencies in the direction of stability • Dependence on stable packages corresponds to DIP for classes • Classes should depend upon (stable) abstractions or interfaces • These can be stable (hard to change)

34. 2. Basic Design Principles—— Stable Abstractions Principle (SAP) Stable packages should be abstract packages. Unstable packages should be concrete packages. Robert Martin Stable packages contain high level design. Making them abstract opens them for extension but closes them for modifications (OCP). Some flexibility is left in the stable hard-to-change packages.

35. 3. Modularity and Information hiding——Modularity • Computer systems are not monolithic: • they are usually composed of multiple, interacting modules. • Modularity has long been seen as a key to cheap, high quality software. • The goal of system design is to decide: • – what the modules are; • – what the modules should be; • – how the modules interact with one-another.

36. 3. Modularity and Information hiding—— What is a module? • Common view: a piece of code. Too limited. • Compilation unit, including related declarations and interface • David Parnas: a unit of work. • Collection of programming units (procedures, classes, etc.) • with a well-defined interface and purpose within the entire system, • that can be independently assigned to a developer

37. 3.Modularity and Information hiding—— Why modularize a system? • Management: Partition the overall development effort • – Divide and conquer • Evolution: Decouple parts of a system so that changes to one part are isolated from changes to other parts • Principle of directness (clear allocation of requirements to modules, ideally one requirement (or more) maps to one module) • – Principle of continuity/locality (small change in requirements triggers a change to one module only) • Understanding: Permit system to be understood • as composition of mind-sized chunks, e.g., the 7±2 Rule • with one issue at a time, e.g., principles of locality, encapsulation, separation of concerns • Key issue: what criteria to use for modularization?

38. 3. Modularity and Information hiding—— Information hiding • Hide secrets. OK, what’s a “secret”? • Representation of data • Properties of a device, other than required properties • Implementation of world models • Mechanisms that support policies • Try to localize future change • Hide system details likely to change independently • Separate parts that are likely to have a different rate of change • Expose in interfaces assumptions unlikely to change

39. 3. Modularity and Information hiding—— Interface vs. Implementation Users and implementers of a module have different views of it. Interface: user’s view of a module. • describes only what a user needs to know to use the module • makes it easier to understand and use • describes what services the module provides, but not how it’s able to provide them

40. 3. Modularity and Information hiding—— What Is an Interface? • Interface as a contract - whatever is published by a module that • Provided interface: clients of the module can depend on and • Required interface: the module can depend on from other modules • Syntactic interfaces • How to call operations • List of operation signatures • Sometimes also valid orders of calling operations • Semantic interfaces • What the operations do, e.g., • Pre- and post-conditions • Use cases

41. 3. Modularity and Information hiding—— Further Principles • Explicit interfaces • Make all dependencies between modules explicit (no hidden coupling) • Low coupling - few interfaces • Minimize the amount of dependencies between modules • Small interfaces • Keep the interfaces narrow • Combine many parameters into structs/objects • Divide large interfaces into several interfaces • High cohesion • A module should encapsulate some well-defined, coherent piece of functionality (more on that later)

42. 3. Modularity and Information hiding—— Coupling and Cohesion Cohesion is a measure of the coherence of a module amongst the pieces of that module. Coupling is the degree of interaction between modules. You want high cohesion and low coupling.

43. 3. Modularity and Information hiding—— Degrees of Cohesion

44. 3. Modularity and Information hiding—— Coincidental cohesion • The result of randomly breaking the project intomodules to gain the benefits of having multiple smaller files/modules to work on • Inflexible enforcement of rules such as: “every function/module shall be between 40 and 80 lines in length” can result in coincidental coherence • Usually worse than no modularization • Confuses the reader that may infer dependencies that are not there

45. 3. Modularity and Information hiding—— Logical cohesion • A “template” implementation of a number of quite different operations that share some basic course of action • variation is achieved through parameters • “logic” - here: the internal workings of a module • Problems: • Results in hard to understand modules with complicated logic • Undesirable coupling between operations • Usually should be refactored to separate the different operations

46. 3. Modularity and Information hiding—— Example of Logical Cohesion

47. 3. Modularity and Information hiding—— Temporal Cohesion • Temporal cohesion concerns a module organized to contain all those operations which occur at a similar point in time. • Consider a product performing the following major steps: • Initialization, get user input, run calculations, perform appropriate output, cleanup. • Temporal cohesion would lead to five modules named initialize, input, calculate, output and cleanup. • This division will most probably lead to code duplication across the modules, e.g., • Each module may have code that manipulates one of the major data structures used in the program.

48. 3. Modularity and Information hiding—— Procedural Cohesion A module has procedural cohesion if all the operations it performs are related to a sequence of steps performed in the program. For example, if one of the sequence of operations in the program was “read input from the keyboard, validate it, and store the answers in global variables”, that would be procedural cohesion. Procedural cohesion is essentially temporal cohesion with the added restriction that all the parts of the module correspond to a related action sequence in the program. It also leads to code duplication in a similar way.

49. 3. Modularity and Information hiding—— Procedural Cohesion

50. 3. Modularity and Information hiding—— Communicational Cohesion Communicational cohesion occurs when a module performs operations related to a sequence of steps performed in the program (see procedural cohesion) AND all the actions performed by the module are performed on the same data. Communicational cohesion is an improvement on procedural cohesion because all the operations are performed on the same data.