The powerful argument for reuse of information, notably program code for
the software that drives our computers and the Internet, but also the
documentation that explains how to use every modern device.
Software reuse grew out of the standard subroutine libraries of the 1960's.
It is the main principle of today's object-oriented programming. Instead of
constantly reinventing software wheels, programming languages like C++,
Java, and others are building vast collections of reusable software objects
and components.
Reuse is closely related to the concept of single source publishing in which
text written once is output to multiple publishing channels like print, the
web, mobile devices, and online help. Reuse of information always has a
single source, but not all single-sourced information is reused in multiple
different contexts.
Reuse of information has a tremendous return on investment for organizations
whose documentation is translated into many languages. Translation memory
systems can store text that has already been translated into dozens of
languages for retrieval and reuse.
Architectural and design patterns are among the reusability concept too.
As Frank Buschmann. Et al., stated in their book, PATTERN-ORIENTED SOFTWARE
ARCHITECTURE:
"Reusability is currently one of the most discussed topics in software
engineering. It promises a reduction of both cost and development time for
software systems, as well as better software quality. Adele Goldberg once
defined reuse as 'the act of achieving what is desired with the help of what
already exists' [Go19 11. Reusability has two major aspects-software
development with reuse and software development for reuse:
- Software development with reuse means reusing existing components and
results from previous projects or commercial libraries, design analyses,
design specifications or code components. These reusable artifacts are
integrated into the application under development, either as they are or
with modifications. Practicing software development with reuse requires the
construction of software architectures that allow you to 'plug in'
prefabricated structures and code components. Software development with
reuse aims to support software composition, which means composing an
application out of existing components by adapting them to the needs of the
development and implementing 'glue' components to connect them.
(coarse-grained)
Software development for reuse focuses on producing components that
are potentially reusable in future projects as part of the
current software development. This requires software
architectures that
allow self-contained parts to be taken from the application under
development and reused in other systems without significant
modification, Although
patterns do not address reusability explicitly, almost every pattern that
supports changeability also supports reusability. For example, the
Model-View-Controller pattern supports the exchange of views and
controllers and the reusability of the model.
Some non-functional properties require similar architectural techniques for
their achievement, for example design reusability and changeability. Others
serve a similar overall purpose: for example, design portability and
interoperability deal with the integration of a software system into its
environment, while reliability and efficiency deal with its general
usability [Bal85].
Non-functional properties may contradict as well as complement each other.
For example, when replicating the functionality of an application to achieve
fault tolerance, the resulting structure is usually less efficient and more
expensive than a structure without such redundancy. When specifying
non-functional requirements for a software architecture, you need explicitly
to consider the interdependencies and trade-offs that exist between them.
You also
need to specify an ordering priority between different non-functional
requirements, to define a preference of one requirement against
another in case of conflict.
Although non-functional properties are very important in software
architecture, their achievement is hard to measure. The detailed criteria a
software architecture must satisfy has only been specified for a few such
properties, for example reusability and changeability (Kar951."
For this reason, estimating the degree to which a software architecture
achieves a given non-functional property(i.e. reusability) is still mainly
based on the experience of software engineers.
I think the problem for not achieving high level of reusbaility realted to
us as human who do not allow the brain storming to work for them.
All teh best
Ashraf Galal
On Sat, Sep 27, 2008 at 9:37 AM, Rob Eamon <[EMAIL PROTECTED]> wrote:
> --- In
> [email protected]<service-orientated-architecture%40yahoogroups.com>,
> Gervas
> Douglas <[EMAIL PROTECTED]> wrote:
>
> > Schulte: Probably the biggest disappointment is the low level of
> > reuse or sharing that they're getting. I had one CIO from state
> > government tell me, "We're getting less than 10 percent reuse."
> > You know, the best we ever see is 40 percent reuse. We consider
> > success anything between 10 and 40 percent.
>
> So many people on this forum and elsewhere have said reuse/sharing
> isn't the primary goal. Why is the view that SOA is *about* reuse
> still so prevalent?
>
> > business function cares about it. Some of these, like product data,
> > customer data, employee data -- these are going to be reused a lot.
>
> Ack. There's that data focus again.
>
> > Yes, you will get that, but the more universal benefit from SOA is
> > the modularity, the ability to swap out a module and replace it
> > with a new version of it.
>
> IMO, that's a variation of reuse. And I've not seen a real swap out
> of a meaningful component without some heavy lifting. The notion
> of "swap and play" is more elusive than reuse/sharing, IME.
>
> > going to have interfaces among the components. And if you're not
> > doing SOA, you're going to have informal, ad-hoc interfaces between
> > the components.
>
> That seems to be a big assumption. Approaches other than SOA are
> always informal and ad-hoc? Hmmm.
>
> > One of my colleagues does a presentation on SOA horror stories and
> > most of them are organizational. You have several different groups
> > doing SOA independently and they try to coordinate after the fact.
> > You can do it, but it's really hard. You're trying to glue together
> > things that weren't designed to work together, so you're into
> > adapters and all sorts of gateways and stuff. By then you've done
> > the services, so you've got customer information in five, 10, 15
> > different services. So it's very hard, where if you had done it up
> > front, you'd be in better shape.
>
> In other words, most seem to focus on project-oriented approaches
> rather take an enterprise view? They do lots of invidual application
> or integration architectures and ignore the enterprise architecture?
>
> What are other peoples' experience here? Are you seeing lots of
> piecemeal work as well?
>
> -Rob
>
>
>
