Post on 23-Dec-2015
COP 4009 5th Lecture October 3, 2005
COP 4009 COP 4009 Component-Based Software EngineeringComponent-Based Software Engineering
The Case for ComponentsThe Case for Components
Fall 2005Instructor: Masoud Sadjadi
http://www.cs.fiu.edu/~sadjadi/Teaching/
Fifth Lecture on October 3, 2005 2COP-4009: Component-Based Software Engineering
AcknowledgementsAcknowledgements
Dr. George T. Heineman – This course is based on the “CS 509 Design of Software Systems -
Spring 2005” by Dr. Heineman with some adjustments to become appropriate for undergraduate students. Dr. Heineman has generously offered his course material (including the slides) and his help during preparation of this course. I am very grateful to him.
– The original slides and the course material can be found at: http://www.cs.wpi.edu/~heineman/html/teaching_/CS509/index.html
Dr. William Councill and other authors of the main textbook
Dr. Clemens Szyperski
Drs. Betty Cheng, Peter Clarke, Bernd Bruegge, and Allen Dutoit
Fifth Lecture on October 3, 2005 3COP-4009: Component-Based Software Engineering
Why should you consider Why should you consider CBSE?CBSE?
It is an engineering approach to solving complex systems– It divides large projects into smaller subprojects.
It is language independent – So, it can easily be used with legacy systems.
Components are often the only answer – For example, for complex and mission critical systems.
Fifth Lecture on October 3, 2005 4COP-4009: Component-Based Software Engineering
AgendaAgenda
The Business Case for Components
COTs Myths
Common High-Risk Mistakes
Fifth Lecture on October 3, 2005 5COP-4009: Component-Based Software Engineering
Business CaseBusiness Case
“The financial impact of spending money. Rate of return, cash flow, length of payback period and other financial criteria are all part of the business case decision making process.” [GuruNet]
A well thought out business case – identifies the benefits and risks– calculates the costs and payback– provides the foundation for success
Fifth Lecture on October 3, 2005 6COP-4009: Component-Based Software Engineering
Business CaseBusiness Case
Component Types– GUI components– Service components– Domain components
Relationship between cost & complexity– Models build on one another
GUI ComponentsGUI Components
Service ComponentsService Components
Domain ComponentsDomain Components
Complexity
Cost
Fifth Lecture on October 3, 2005 7COP-4009: Component-Based Software Engineering
Key IssuesKey Issues
Business goals
Technical sophistication
Organizational readiness
Infrastructure support
Reuse
Fifth Lecture on October 3, 2005 8COP-4009: Component-Based Software Engineering
Key Issues: Business GoalsKey Issues: Business Goals
CBSE is suitable for complex, mission-critical systems.– Components are robust, scalable, and flexible.– If this is not true in your case, then non-component
bases tools may be quicker or cheaper to use.
You need to consider total cost of ownership (TCO)
CBSE provides a higher software quality.
Fifth Lecture on October 3, 2005 9COP-4009: Component-Based Software Engineering
Key Issues: Technical Key Issues: Technical SophisticationSophistication
Different components require different persuasive arguments– GUI components– Service components– Domain components
Using these categories, you can divide the business case into models that defer based on– Complexity– Cost– Organizational readiness
Fifth Lecture on October 3, 2005 10COP-4009: Component-Based Software Engineering
Key Issues: Organizational Key Issues: Organizational ReadinessReadiness
Organizational readiness encompasses– Existing development processes– Developer skill sets– Corporate culture
To gain the full benefits of component technology, you need a software engineering approach to – Development – Deployment
Don’t confuse “just enough” process with no process at all.
Usually a consulting organization can accelerate the rate of adopting CBSE.
Fifth Lecture on October 3, 2005 11COP-4009: Component-Based Software Engineering
Key Issues: Infrastructure SupportKey Issues: Infrastructure Support
When you move beyond using simple GUI components
Anytime you consider using components in layers lower than the GUI (in an n-tier architecture), you need to think about infrastructure support.– Additional hardware – Multiple application servers– The cost and personnel support for the application servers in
production– The cost of training the existing staff– The cost of hiring new staff with appropriate skill sets
Fifth Lecture on October 3, 2005 12COP-4009: Component-Based Software Engineering
Key Issues: ReuseKey Issues: Reuse
Reuse has significance impact on your business case
However, you need to consider both saving and costs in your planning.
Reuse programs can pay for themselves, but you cannot implement reuse without spending money to get there!
Remember that domain components usually have a high development or purchase cost.– Requires additional people, processes, and tools to initially.– The cost is higher, but the payback is substantial.
Fifth Lecture on October 3, 2005 13COP-4009: Component-Based Software Engineering
Key ProblemsKey Problems
Developing a business case for components vs. actually obtain the value you hope to achieve
You need to identify the areas of risk.
Wrong culture– hate additional up-front costs even if long-term benefits
Wrong goals– focus on building for today rather than future
Wrong purpose– use components improperly
Fifth Lecture on October 3, 2005 14COP-4009: Component-Based Software Engineering
Key Problems: Wrong CultureKey Problems: Wrong Culture
Some cultures can be narrowly focused– Time or cost pressure– In this case:
wait for a brief respite or bring it by stealth and declare victory
The lack of infrastructure– Budgetary constraints may derail the project– In this case:
Deploy new technology on a small scale
Corporate culture may inhibit reuse– Reward systems based on the amount of the code developed!– People work according to how they are measured and rewarded!
Fifth Lecture on October 3, 2005 15COP-4009: Component-Based Software Engineering
Key Problems: Wrong GoalsKey Problems: Wrong Goals
When you build reusable components, you are building for future.
What if you get it wrong?– It is difficult to anticipate future uses.– Business needs may change, even though the component is well-
designed.
GUI, Services, and Domain Components– GUI might be your best bet, but there are so many available
already– In dynamic markets
infrastructure services may remain more stable than the domain they serve!
Fifth Lecture on October 3, 2005 16COP-4009: Component-Based Software Engineering
Key Problems: Wrong PurposeKey Problems: Wrong Purpose
GUI, service, and domain components – They are different from each other – They have a different scope and purpose.– They have differing needs
Infrastructure support Developers skill sets
Do not use the same component for different purposes– Cause: poor analysis– Abstractions have mixed types of functionality– Can be avoided by good analysis and design
Fifth Lecture on October 3, 2005 17COP-4009: Component-Based Software Engineering
Building the Business CaseBuilding the Business Case
Understand the concepts behind each model Make sure you address the issues they raise Modify the models for your situation
For each model, come up with a buy and build scenario.
GUI (40% improvement) Service (150% improvement) Domain (1000% improvement)
Focus energies appropriately
Fifth Lecture on October 3, 2005 18COP-4009: Component-Based Software Engineering
Concluding RemarksConcluding Remarks
Component technology is clearly cost-effective.
Component reuse has a significant impact on your productivity.
Developing business case might be the only way to convince skeptics in your organization.
Watch out! This field is too immature to bet on any one approach to component development.
Use the three-level model and provide an incremental approach to building your business case.
Fifth Lecture on October 3, 2005 19COP-4009: Component-Based Software Engineering
AgendaAgenda
The Business Case for Components
COTs Myths
Common High-Risk Mistakes
Fifth Lecture on October 3, 2005 20COP-4009: Component-Based Software Engineering
COTSCOTS
“(Commercial Off-The-Shelf) Refers to ready-made merchandise that is available for sale.” [GuruNet]
Using COTS, we can rapidly create new applications today.
Key to success– Selection of the software component infrastructure.– Selection of the middleware or the glue that holds them together.
Key Issues– Volatility and flexibility of the requirements– The stability of component producers– The respective components the producers are supplying.
Fifth Lecture on October 3, 2005 21COP-4009: Component-Based Software Engineering
COTS termsCOTS terms
Customer– Pays for application to be built
Component consumer– Assembles application from components
COTS component producer– Supplies components – Provides support and upgrades
Fifth Lecture on October 3, 2005 22COP-4009: Component-Based Software Engineering
COTS MythsCOTS Myths
Lessons learned
Infrastructure Issues Managerial Issues Additional Issues
Fifth Lecture on October 3, 2005 23COP-4009: Component-Based Software Engineering
Component Myths: Infrastructure Component Myths: Infrastructure IssuesIssues
#1: components have many advantages– usage may be negative– What components can do to you instead of for you!
#2: component systems can be top-down– must be built bottom up
#3: OPEN systems solves interoperability– plug-and-play doesn’t always work
#4: no need to test purchased components– testing even more important
Fifth Lecture on October 3, 2005 24COP-4009: Component-Based Software Engineering
Component Myths: Infrastructure Component Myths: Infrastructure IssuesIssues
#5: Components are carefully selected– Arbitrary selections more common
#6: Components have adequate documentation– Documentation not relevant to selling components
#7: Easy to configure component-based system to meet your needs– Easier to match component capabilities– 80% of reqs can be assembled at 20% of cost– You may end up configuring your process rather than configuring
the components!
Fifth Lecture on October 3, 2005 25COP-4009: Component-Based Software Engineering
Component Myths: Managerial Component Myths: Managerial IssuesIssues
#8: components built with best-practice– producers just as market-driven as everyone else
#9: one can buy a component– buy the right to use a version of a component
#10: Producers will fix problems– producers may fix problems in next version
Fifth Lecture on October 3, 2005 26COP-4009: Component-Based Software Engineering
Component Myths: Managerial Component Myths: Managerial IssuesIssues
#11: Large customers can influence producers– Only market of supply-demand has influence
#12: component-based systems are best solution– expose weaknesses in system development– compresses development schedule– near-term success may lead to long-term failure
Fifth Lecture on October 3, 2005 27COP-4009: Component-Based Software Engineering
Rules of Thumb Rules of Thumb
#2: Maximum shelf-life of COTS component is two years
#3: Half-life of COTS component expertise is 6 months
#5: No COTS-based solutions is DMS– Diminishing Manufacturing Source
# 12: COTS-based system will never completely satisfy customer’s needs
Fifth Lecture on October 3, 2005 28COP-4009: Component-Based Software Engineering
Concluding RemarksConcluding Remarks
The Ultimate Solution– Setting up integrated product teams (IPTs)
Customers End-users Consumers COTS producers
A COTS-based system might not always be the “best” solution available.
A custom implementation may be more cost-effective over the life of the project.
Fifth Lecture on October 3, 2005 29COP-4009: Component-Based Software Engineering
AgendaAgenda
The Business Case for Components
COTs Myths
Common High-Risk Mistakes
Fifth Lecture on October 3, 2005 30COP-4009: Component-Based Software Engineering
Common High-Risk MistakesCommon High-Risk Mistakes
It is easy to write success stories
We tend to forget our mistakes and failed projects.
What should we do?
– Retrospection
– Reflection
We can then see the nuances and pitfalls of our own actions and those of others.
Fifth Lecture on October 3, 2005 31COP-4009: Component-Based Software Engineering
The PitfallsThe Pitfalls The lead architect role
– Application architect and component infrastructure lead designer.
Immature component Infrastructure– The required infrastructure should be one version ahead
Size and Packaging of Subcontracted Components– Do not subcontract too large or too small components.
Distributed Development is Not Synonymous with CBD– Try to avoid distributed development.
Achieving Unambiguous Communication– Use extensive component specifications.
Large-Scale Legacy Integration Difficulties– Large systems evolve as a combination of the old and new
systems
Collect Metrics Early– We can reliably size and cost the entire system.
Fifth Lecture on October 3, 2005 32COP-4009: Component-Based Software Engineering
What should we do?What should we do?
We can implement the following
A proven commercial component infrastructure integrated with good modeling and code development tools
A co-located organization – Avoid distributed organizations.
A mature organization that can follow complex development processes