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 .
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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.
Q: Why did it surface?
Q: What was happening before?
Q: What wasn’t working?
Analytic, Repeatable, Describing what is, Have truth
Creative, Describing what will be,
No truth – it hasn’t been formed
Coupling & Cohesion
1974 – Stevens, Myers, Constantine“Structured Design”
1968 – McIlroy
“Mass Produced Component Software”
Use of term “component”!
1971 – Wirth
“Program Development by
1972 – Parnas
“On the criteria to be used in decomposing systems into modules”
- Uses hierarchy
- Uses hierarchy
- Class hierarchy
An instance of D can be used wherever an instance of B is expected.
Some languages are starting to provide support.
read (nBytes : int)
read (nBytes : long)
The problem is that we have a design time constraint with (traditional) OO approaches.
software package, or a module, that encapsulates a set of related functions (or data).
an independently deliverable set of reusable services
a unit of composition with contractually specified interfaces and explicit context dependencies that is independently deployable and subject to third party compositions
a software element that conforms to a component model and can be independently deployed and composed without modification according to a composition standard
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.
… need to be binary/executable?
… need to be part of a component model/composition standard?
… need explicit context dependencies?
Has a well-defined interface
Encapsulates well-defined behavior
Is independently deployable
Is third party composable
What enables business to be successful?
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
Reducing time invested in obtaining/installing apps is crucial
Leveraging components is a balancing act
Need to reuse in-house development 3 times on average to recoup costs.
Wallnau, Hissam, Seacord
“Building Systems from
Standards : Vertical vs. Horizontal markets
Domains = Market Niches
Cross domain = broad appeal