1 / 48

Design Paradigms, FOP, and OOP

Design Paradigms, FOP, and OOP. 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?. Design paradigms have, and continue to, evolve. Function- Oriented . Object-Oriented .

dacian
Download Presentation

Design Paradigms, FOP, and OOP

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

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

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

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

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

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

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

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

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

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

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

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

More Related