IST 421 : Components and Component Markets

1. IST 421 : Components and Component Markets

2. Did we all understand how inheritance in OO is a design dependency?

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

4. Reuse at the object level was too fine grained. • Dependencies – though better than FO – were intricate and difficult to identify • This has to do with a tendency to depend on states and identity rather than services.

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

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

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

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

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

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

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

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

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

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

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

16. Deciding what direction to go comes down to cost. component(s) 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 ? + development > + installation/ configuration maintenance + maintenance

17. We can abstract the idea of component and consider a “component spectrum”. • Components are complex and often captured in views: • Requirements • Interfaces • Behaviors • Packaging • Code • Libraries Concept Executable Chessman and Daniels : “UML Components” Krutchen : “The 4+1 View Model of Software Architecture”

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

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

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

21. To get the component benefit, we need customization. • Tools • Spotty. Some companies do a good job with their components (e.g., VxWorks) • Languages • No standard. XML-based ones have a lot of potential • The second edition was 2002 and identified this as lacking. Things aren’t that much better.

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

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

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