COP 4009 5 th Lecture October 3, 2005 COP 4009 Component-Based Software Engineering The Case for Components Fall 2005 Instructor: Masoud Sadjadi sadjadi/Teaching

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


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.


AgendaAgenda

The Business Case for Components

COTs Myths

Common High-Risk Mistakes


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


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


Key IssuesKey Issues

Business goals

Technical sophistication

Organizational readiness

Infrastructure support

Reuse


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.


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


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.


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


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.


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


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!


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!


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


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


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.


AgendaAgenda


COTs Myths



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.


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


COTS MythsCOTS Myths

Lessons learned

Infrastructure Issues Managerial Issues Additional Issues


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


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!


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


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


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


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.


AgendaAgenda


COTs Myths



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.


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.


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

Documents

COP 4009 5 th Lecture October 3, 2005 COP 4009 Component-Based Software Engineering The Case for Components Fall 2005 Instructor: Masoud Sadjadi sadjadi/Teaching