Design Paradigms, FOP, and OOP

1. Design Paradigms, FOP, and OOP

2. To understand component-orientation means we need to understand how components came about. Q: Why did it surface? Q: What was happening before? Q: What wasn’t working?

3. Design paradigms have, and continue to, evolve. Function- Oriented Object-Oriented Component-Oriented

4. A design is the specification of a solution to a specific problem.

5. Is design a science? Scientific Process Design Process Observations Requirements Hypothesis Design refine refine Experiment Verify Accepted Theory Accepted Design Analytic, Repeatable, Describing what is, Have truth Creative, Describing what will be, No truth – it hasn’t been formed

6. Design is a wicked problem. • Hard to define problems • No stopping rules • Good vs. Bad, not True vs. False • Solution space is not well-ordered • Solution is “one-shot”

7. A design method is a way of capturing and communicating a design. Requirements Representation Process Heuristics Design Constraints Design Methodology Implementer Domain Knowledge Designer

8. Design methodologies come into play when we think about systems. Function-Orientation Object-Orientation Component-Orientation Batch Reactive Concurrent

9. Function-orientation can be characterized as… • Basic building block : function • Action driven • Static binding • Great at modeling data processing • Weak at control modeling • Heavy use of global data • Functions logically, not physically, bound to data they operate

10. Key ideas identified in the late 60s/early 70s that function-orientation didn’t address. 1940s 1970 1980 2000 Coupling & Cohesion 1974 – Stevens, Myers, Constantine“Structured Design” Reuse 1968 – McIlroy “Mass Produced Component Software” Use of term “component”! Stepwise Refinement 1971 – Wirth “Program Development by Stepwise Refinement” Information Hiding 1972 – Parnas “On the criteria to be used in decomposing systems into modules”

11. Function-oriented techniques evolved but they didn’t naturally address all ideas. • Stepwise Refinement • This was okay • Information Hiding • Forward declarations of hidden structures difficult to manage and extend • Coupling/Cohesion • Alone, functions could be loosely coupled / highly cohesive : + • Functions + data considered together poorly coupled/not cohesive : - • Reuse difficult at best • Too fine grain.

12. Object-based approaches emerged to tackle the reuse, info. hiding, coupling/cohesion in a natural way. • Physically coupled functions and data • Viewed as a collection of interacting things • Things protected their data, enabled behavior via interface • Virtually no global data data interface

13. unification of data and functions object = state + behavior + identity necessary since two objects may look identical (have same state) but be different things Example: Two physical books represented in a system

14. The object model adds a framework to the object concept. (G. Booch) • Abstraction : describing external view • Encapsulation : information hiding • Modularity : packaging/interfacing • Hierarchy • Structure : class : inheritance! • Interdependency : uses

15. We can then describe the difference between object-based and object-oriented. • Object Based • Abstraction • Encapsulation • Modularity • Uses hierarchy • Object-Oriented • Abstraction • Encapsulation • Modularity • Uses + class hierarchy

16. Designing object-oriented systems is a tension between the dual notions of “class” and “object”.

17. Inheritance and polymorphism are (in some sense) dual concepts. • Inheritance • Design time • Establishes a “substitution policy” • Polymorphism • Run time • Performs the substitution • Ensures type correctness

18. Inheritance used alone is just a design convenience. A B A d : D d D 1

19. Polymorphism is powerful juju. b A B A : D 1 ! D An instance of D can be used wherever an instance of B is expected.

20. Polymorphism enables dynamic binding. • Static binding : compiler “glues” references to objects • Dynamic binding : runtime “glues” references to objects • Flexibility is achieved by delaying binding as long as possible.

21. Taking advantage of polymorphism in the design enables easier evolution of the system. b b DiskUser DiskDrive DiskUser DiskDrive 1 1 CDRW CDRW USB

22. So, object-oriented approaches have improved things but have not solved all the problems. b DiskDrive DiskUser 1 Can’t do! Type widening Some languages are starting to provide support. read (nBytes : int) DVD read (nBytes : long) The problem is that we have a design time constraint with (traditional) OO approaches.

23. While OO improved reuse, it still fell short. • The model is class based, not service based. • Component orientation tries to solve this problem • Constraints on polymorphism are even further relaxed • OO languages not always sufficient to implement CO • Can do it on some level - like FO can mimic OO • CO languages exist but aren’t mainstream

24. OO evolved from FO to help support key practices. • Information hiding • Coupling/Cohesion • Natural modeling of systems of interacting things • Changeability • Reusability

25. Reuse at the object level was too fine grained. • Dependencies were intricate and difficult to identify • Has to do with a tendency to depend on states and identity rather than services.

26. Changeability limited by environment and often code in hand. • Extending systems requires some amount of code to extend • Have to work in a similar environment when doing the extensions • Changing elements of the system may require balancing delicate interactions – elements assume specifics of other elements.

27. The component definitions are varied but all generally agree on some level. Wikipedia Brown/Short software package, or a module, that encapsulates a set of related functions (or data). an independently deliverable set of reusable services Szyperski a unit of composition with contractually specified interfaces and explicit context dependencies that is independently deployable and subject to third party compositions Heinemann/Councill a software element that conforms to a component model and can be independently deployed and composed without modification according to a composition standard Wallnau/Hissam/Seacord a unit of software implementation that is produced by a vendor who sells/license its use to profit from that transaction; is released by its vendor in binary form; provides an interface that supports third-party integration with other components.

28. Do components … … need to be binary/executable? … need to be part of a component model/composition standard? … need explicit context dependencies?

29. A component is a unit of construction that… Has a well-defined interface Encapsulates well-defined behavior Is independently deployable Is third party composable

30. We are trying to understand/improve the reusability of components and changeability of our systems. New System Existing System A D B ? C E

31. We are going to see some changes happening. • Less focus on development of full systems • Planning is crucial – and at different levels of abstraction • Documenting/describing the environment is now important.

32. With the shift away from development, components must be coming from somewhere. • Economy • A system of production, distribution and consumption • Market • A social arrangement to enable buyers and sellers to discover and exchange goods and services

33. Component Software is about the “component market” • Components exist in a market • Leads to necessary market factors • Describes change system life cycle • Discusses the technical factors that motivate/enable/prohibit market factors

34. While we need to understand the market to an extent, we care more about… • Component philosophy • Technical considerations • Management of this complex space

35. Let’s talk a bit about the “component market”. What enables business to be successful? Competitive advantage Reduced time to market Focusing on what they do well

38. Let’s talk a bit about the “component market”. What enables business to be successful? Competitive advantage Reduced time to market Focusing on what they do well How do components help? Component philosophy: reuse! Businesses want to buy when it’s cheaper Want customization Reducing time invested in obtaining/installing apps is crucial

39. Organizations gain a competitive edge when they have something useful others do not. Cost Efficiency Flexibility Custom COTS Leveraging components is a balancing act

40. Deciding what direction to go comes down to cost. Need to reuse in-house development 3 times on average to recoup costs. http://www.sei.cmu.edu/library/abstracts/news-at-sei/productlines4q03.cfm components ? + development > + installation/ configuration maintenance + maintenance

41. We can abstract the idea of component and consider a “component spectrum”. • Components are complex • Captured in views: • Requirements • Interfaces • Behaviors • Packaging • Code • Libraries Concept Executable

42. The process of creating a COTS component-based system involves different activities than development. • Define Requirements • Shop • Configure/Extend • Establish Deployment Infrastructure • Deploy in Test Environment • Put into production • Monitor vendor activities and roadmaps and continuously perform trade-offs

43. To get the component benefit, we need a market. • Buyers = demand  got this • Sellers = supply  still not there • Obstacles: • Components need to be general but useful • Independence from context • Requires a common problem • Advertising / Discovery (componentsource.com) • Documentation

44. What kind of components are there? How do we classify them? Framework-based Application Custom COTS Infrastructure OS-based Wallnau, Hissam, Seacord “Building Systems from Commercial Components”

45. To get the component benefit, we need customization. • Tools • Spotty. • Some companies do a good job (e.g., VxWorks) • Languages • No standard. • XML-based ones have a lot of potential

46. To get the component benefit, we need the infrastructure. • Technologies for dynamic development and management • Some vendors are good in their space (.Net, J2EE) • Not universal which means homogenous solutions • Includes Quality of Service, testing, security • Late binding

47. To get the component benefit, we need the infrastructure. • Standards : Vertical vs. Horizontal markets Domains = Market Niches Cross domain = broad appeal

48. Standardization is hard in vertical and horizontal markets. • Horizontal • A lot of players • Long wish lists • Difficult to find compromise • Vertical • Highly specialized • Differences are the business advantage • Potentially volatile