20-06-2014, 04:11 PM
SOFTWARE REUSE
1378293600-Reuse.ppt (Size: 823 KB / Downloads: 11)
Outline
What is software reuse?
Types of reuse
Where do we stand?
What to reuse?
Organization and process
Issues, dimension and tasks in reuse
Challenges in software reuse
Reuse benefits and problems
Reuse organizations, metrics and economics
Reuse costs and advantages
Reuse techniques
Age-old
Objects
Patterns
Frameworks
Components
Domain and product line engineering
Meta-programming and generator
Model-driven architecture
Aspects
Technique synergy and integration
What is software reuse?
Act: reuse of previously built software artifact/asset to fulfill need in new development task or sub-task
Field: study of methodologies, practices, processes, techniques, languages, frameworks, CASE tools that foster and facilitate reuse
Motivation:
Avoiding wasting time and money redoing same task over and over
Quality standard of previously completed task carries over to new occurrences of same need
Types of reuse
Horizontal reuse: Horizontal reuse to software components used across a wide variety of applications
Vertical reuse: Vertical Reuse the reuse of system functional areas, or domains, that can be used by a family of systems with similar functionality
Where do we stand?
Reuse is a general common-sense principle, pervasively applied in all human activities
In software engineering: still rare and far from systematic practice
High potential for software reuse remains untapped
Lanergan and Grasso 84: 60% of business applications can be standardized and reused
Gruman 88, McClure 92: range of achievable reuse rates [15%-85%]
Even though:
Old idea proposed in software engineering in 1968
Main focus of recent software engineering research
Consensus that reuse is THE key to most future productivity gains since time to market, development cost and software quality are the main parameters to trade-off during a development project
What to reuse?
A software asset:
Any artifact resulting from one stage in a development task
Any mapping from the artifact produced by one development stage to the artifact produced by the next
Assets can be at any level of abstraction and software process stage:
Domain/business analysis/model
Application requirements
Application architectures and generic architecture patterns
Application design/model and generic design patterns
Source code
Libraries, modules, packages
Classes, templates, idioms
Objects, functions, subroutines, data
Executable code: executable components, bytecode, binary code
Documentation and meta-data
Test suites and test generators
Any information, formalism or tool used during development can also be subject to reuse
Languages, CASE tools, IDE, processes
Requirements of reusable software artifacts
Common to special-purpose artifacts:
Usable: user-friendly
Reliable: conform to functional and non-functional requirements
Additional for reuse:
Pervasively useful:
Fulfills a need that recurs across projects, domains, applications, concerns or platforms
Adaptable:
Modular: useful by separable parts
Generic: useful as a whole in many different context
Understandable: documented,
Portable: platform independent
Organization and Process
Reusable components should be designed and built in a clearly defined, open way, with concise interface specifications,
understandable documentation, and an eye towards future use
Reuse issues and dimensions
Asset composition vs. asset mapping with meta-assets (generative)
ex. composing existing DLL vs. generating DLL from precise UML model
Transformations can be use for both
Asset abstraction level
Asset executability level:
ex, model, source code, bytecode, binary code
Asset granularity level
ex. package, class, method
Asset process stage
Asset visibility
Black-box, i.e. reuse “as is” based on specification vs.
White-box, i.e. reuse with modifications based on realization/implementation
Asset built with reuse x asset built for reuse
Asset reuse scope:
Across domains, across applications, within same application
Reuse sub-tasks
Define boundaries of reusable assets (knowledge units with reuse potential)
Organize and structure reusable assets together with descriptive and operational meta-data in searchable, persistent repositories
Retrieve reusable assets
Assemble/integrate reusable assets
Adapt/modify reusable assets
CHALLENGES IN SOFTWARE REUSE
Defining an organizational structure for maintaining the product line, including core assets and the customer specific products with special non-core functionality
Defining a process for producing a new member of the product line (or upgrading an old one) from the core assets with customer specific requirements
Defining a process for adding functionality to the core product line assets based on new customer requirements
Instituting a training program for reuse strategies in management, design, implementation, test-all phases of the development pro
Reuse benefits and problems
Benefits
Increased dependability
Reduced process risk
Effective use of specialists
Standards compliance
Accelerated development
Problems
Increased maintenance costs
Lack of tool support
Not-invented-here syndrome
Creating and maintaining a
component library
Finding, understanding and
adapting reusable components
Reuse metrics
Overcoming non-technical reuse inhibitors, especially economic ones, requires estimating the cost-benefit of:
Reuse an available asset in an application development project
Pro-actively develop reusable assets for current and future projects
Launch an organization-wide systematic reuse program
Pitfalls of the line of code metric:
Manually designed for reuse assets and automatically generated assets larger than manually design for one-shot use assets with equivalent functionalities for the application at hand
Versatile, multiple functionality components underused in any given application
Patterns
Modeling patterns:
Artifact view: abstract analysis/design template which instances recur across domains and applications
Mapping view: pair associating a set of requirements (generic design problem) to a analysis/design template known to satisfy it (generic design solution)
Capture know how of experienced analysts
Two granularity levels: architectural, design
Two complementary aspects: structural/static and behavioral/dynamic
Architectural patterns:
Template for decomposition of system into modules/components with names and roles together with their data flows, structural and behavioral relationships
Coarse-grained modeling patterns
Specified in special-purpose architectural languages or in UML
Design patterns (generally object-oriented):
Template for associated classes that together provide a given generic service
Finer grained modeling patterns
Programming patterns (idioms, styles):
Conventional, restricted use of programming language constructs to realize design pattern
Object-oriented frameworks
In contrast to patterns, frameworks are specific to a given domain, but independents of any particular application requirements
Two main elements:
Set of interrelated interfaces and abstract classes that represent a predefined software architecture skeleton
Set of interrelated concrete classes that provide as built-in the conceptual entities of the domain and the common services shared by most applications in the domain
Building an application with a framework consists of:
Reusing the concrete classes by calling their methods
Reusing the concrete classes by specializing them, with or without overriding
Reusing the abstract classes and interfaces by realizing them
All three guided by the application’s requirements
Reuse occurs massively at the domain engineering and design stages (almost entirely avoided) and partially at the implementation stage
Sometimes comes associated with:
A domain-specific development process/method
A domain-specific CASE tool and/or IDE
Components
What is a component?
No standard, universally accepted definition
In essence, any software unit that:
Is “independently” deployable
(albeit) reuses/requires a set of typed and constrained operations (typically provided by other components that its uses at servers)
To provide a set of typed and constrained operations
Executable by either:
Humans through a user interface (stand-alone deployment)
Other software through an calling interface (for which it then acts as a server)
Encapsulates:
Meta-data allowing the deployment platform or development environment to automatically assemble it with other components to provide complex services
Several related classes, routines, or functions
Component:
Independently deployable
Possesses user-interface for stand-alone deployment
Not necessarily object-oriented
Mid-size grained unit intermediate between objects and systems
At run time subject to service invocation
At deployment time subject to composition/assembly
Object:
But be wrapped inside a program to be executed
Only subject to method invocation
Component diversity
Component class vs. component instance
Component instance: run-time entity
Component class: subject to specialization, instantiation and inheritance
Distinction relevant mostly for components within OO paradigm
Deployment-only components:
UML 1, Java Beans, .Net DLL, Web Services
Packaging and assembly mechanisms for abstract services implemented by classes and objects
Full-life cycle components:
UML 2, KobrA
Encapsulates requirements, model, code, test suites
With composition/assembly meta-data at each stage/abstraction level
With traceability meta-data between each stage/abstraction level
Component-based architectures
Architectural and design patterns using components instead of objects as basic building blocks
Arbitrary assembly based on various relations between components:
At run-time between component instances
Composition
Clientship
At design-time between component types
Ownership/Nesting
Access
Specialization/Generalization
Domain engineering
The product portfolio of most software house can be structured in families/lines
All family members in same given domain, share common core conceptual entities and functionalities
Domain engineering: leverage distinction between common core and variable parts in a product family to foster reuse in the development process
Hardest issue: scoping domain
Too large, excessive overhead, not cost-effective
Too small, reuse potential poorly exploited
Separation of concern
Object-oriented design structures models and code solely based on the entity classes of the application and their relationships
This results into an non-isomorphic mapping between:
The N concerns of the software being developed, i.e., its functional and non-functional requirements and the functionalities/behaviors realizing them in the model and code
The M entity classes of the model and code
This makes adding or changing a single concern extremely costly for it requires:
Inspecting the entire OO model/code
Coherently modifying the many different classes in which it is scattered
It also prevents exploiting the high concern reuse potential:
Most concerns are conceptually orthogonal to one another and to the entity class structure of the application domain
Yet they end-up entangled together in its model and code
Aspect-Oriented Programming
Practice of:
Encapsulating orthogonal concerns in different aspects, to cleanly separate them from the core program and from one another
Link each aspect with the core program (that captures the dominant decomposition) through point-cuts
Automatically generate the complete source code by using AOP tools that weave together the aspects with the core program at the indicated point-cuts
Aspect-Oriented Development
Generalize aspect-oriented approach throughout the entire life-cycle at all level of abstraction and development stage
Aspects such as persistence, distribution, security, logging/tracing are largely orthogonal to the domain and functional requirement of any particular applications
Once modeled and implemented separately as aspects they can be reused
Even various ontological features of an application domain display a large extent of orthogonality than can be exploited using AOD:
ex, recurrent e-commerce functionalities such as item browsing, item search, general promotions, personalized recommendations, payment, authentication, gifts, shopping cart management, delivery method and tracking, customer complaints
Integration of reuse techniques
Most reuse techniques are complementary and can be combined in synergy
MDA/AOD synergy:
At the various MDA model levels (CIM, PIM, PSM)
Modeling aspect weaving can be implemented by generic model transformation
Separation between platform independent and platform dependent aspects further foster reuse
PLE/AOD synergy:
Many PLE variations correspond to inclusion/exclusion of different aspects
Recent reuse-oriented software engineering methods combined most of them:
ex, KobrA
Combines objects, patterns, frameworks, components, product lines, MDA.