Wrapper-Based Framework for Domain-Specific Software Reuse

1
Wrapper-Based Framework for Domain-Specific
Software Reuse

• Presented by Chin-Yi Tsai

2
Outline

• Introduction
• Atomic Domain Methodology
• The General Model Design
• Proof of Concept Model
• Conclusions

3
Introduction

• Component-Based Software Engineering (CBSE)
• Time, cost, quality, maintenance
• Component-reuse
• The implementation of CBSE ranges
• from the use of more isolated solutions
• such as new languages,
• wrapping legacy components,
• refactoring,
• program mining,
• implementing product populations,
• product line technologies,
• and various domain analyses
• to the use of industry standards
• such as OMGs CORBA Component Model,
• Microsofts Component Object Model, COM, .NET,
• and Suns Enterprise Java Beans

4
Introduction (Contd)

• The complexity of managing and maintaining
  reusable artifacts increase with large systems.
• A Wrapper-Based Framework that promotes and
  facilities the design and development of
  domain-specific reusable software components.
• The framework is based on the concept of Atomic
  Domain methodology that signifies a reusable
  subsystem, which intelligently manages a
  collection of highly reusable components in the
  application domain of interest.
• This methodology largely reduces cost of
  component maintenance and the overhead associated
  with standard reuse libraries.

5
Introduction (Contd)

• Implementing CBSE as local model based on two
  promises
• The first promise defines the component as the
  source code of a module, class, or function.
• The second promise defines the components domain
  as atomic.

6
Introduction (Contd)
The concept of atomic domains
Proposes a wrapper-based framework for
domain-specific software reuse.
Domain Engineering
7
Atomic Domain Methodology

• Component-level reuse
• Domain-level reuse
• In order to overcome challenges brought by both
  component-based and domain-level reuse, we
  propose a novel atomic domain methodology to
  promote multiple-component reuse at the domain
  level.

8
Atomic Domain

• Domain analysis and design activities are
  intended to facilitate software component reuse.
• Each reusable component is considered independent
  and self-contained item with limited
  relationships to other related components that
  share some common behavior.
• The Atomic-Domain methodology is centered around
  the idea of grouping related reusable software
  components into atomic domains.
• At the domain-level, related artifacts (including
  source code, compiled objects, documentation,
  procedures, and policies) are grouped and treated
  as a single unit (atomic domain)
• The atomic domain is embedded within a wrapper
  that acts as intelligent interface between atomic
  domain and its clients.
• The wrapper handles communication and management
  aspects between the internal artifacts and the
  outside world.

9
Definition of Atomic Domain

• An atomic domain is an aggregate of reusable
  artifacts that possess properties associated with
  a group of related domains. Properties of the
  artifacts cannot be substantially decomposed
  without altering the primary properties of the
  domains.
• The atomic domain exhibits the following
  properties
• High-level of cohesion among components.
• A common wrapper to support multiple-component
  reuse and management.

10
The Wrapper

• The main role of the wrapper is to support reuse
  of components (or artifacts in the general sense)
  encapsulated in the atomic domain.
• The wrapper
• control and management functions to exhibit
  information about the atomic domain content
• provide the appropriate services to the atomic
  domain clients.
• Wrapper acts as an intelligent interface between
  the user applications and the atomic domain
• The wrapper components support domain analysis
  and design by improving the cohesiveness of the
  atomic domain

11
Definition of Wrapper

• The wrapper is a collection of mechanisms that
  exhibit the atomic domain content to the outside
  world, control the interactions between the
  atomic domain and its clients, and manage the use
  of artifacts in the atomic domain.
• The wrapper consists of five components described
  as follows
• Taxonomy
• Application Programmer Interface (API)
• Manager
• Communication Mechanism
• Control Mechanism

12
Atomic Domain Creation Rules

• During domain analysis, domain experts identify
  reusable artifacts that belong to the problem
  domain, such as specification source code
  object code test cases results of requirements,
  analysis, and design policies, plans,
  guidelines, and metrics and applications or
  parts of applications.
• A key descriptive characteristic of the atomic
  domain is the irreducibility of its components.

13
The general steps for defining new atomic domains

• The domain expert group reusable artifacts into
  new categories and extract common characteristics
  for each of them
• Develop an abstract behavior model for each
  atomic domain.
• Identify constraints within the each atomic
  domain
• Analyze the dimensionality of each atomic
  domain.
• Define the boundary of each atomic domain.
• Define the scope of the services of the atomic
  domain.
• Define the interface of the atomic domain.
• Define a wrapper for the atomic domain.
• Embed the atomic domain in a wrapper

14
The General Model Design

• General model
• IDE
• Compiler
• Template for atomic domain and wrapper

15
The General Model Design (Contd)

• Each atomic domain is based on related context.
• All reusable and irreducible components related
  to the context are placed in the same atomic
  domain.
• (components) Linked via the wrapper manager

16
Proof of Concept Model

• A proof of concept prototype model, using
  Microsoft Access version 2002 automated by Visual
  Basic for Applications (VBA), has been developed
  to illustrate the framework implementation in the
  database application domains
• The steps of using the framework for developing
  the prototype model
• Source code analysis
• Domain formation
• Wrapper definition
• Domain integration
• Domain utilization

17

• Source code analysis
• Domain formation
• Wrapper definition
• Domain integration
• Domain utilization

18
Conclusions

• To facilitate the design and development of
  component reuse in specific domains of
  applications
• Reuse, integration, and domain management are key
  investigation issues
• Adding existing reusable components to the atomic
  domain (rather than creating them from scratch)
• The wrapper manager virtually links those
  components together and select the best candidate
  based on the specification provided by client
  application.

19
Appendix

• Software reuse??????????????????????????????,?????
  ??????????,?????reuse????????,??Software
  reuse??????Domain engineering?????????????????????
  ?????????,????????????????????
• ??????????????????????????,???????????????????????
  ?????????????,????????????????????????????????????
  ?????????,???????????????
• Software reuse is an important field in software
  engineering research. How to properly identify
  and organize reusable information to easily reuse
  it in software development is an important but
  difficult topic in software reuse. Domain
  engineering is the process establishing
  fundamental capability and necessary basis for
  the application engineering of a group of similar
  systems. It covers all the activities to build
  reusable software components.
• Domain engineering helps to solve the
  identification, organization and utilization of
  reusable information, so it provides powerful
  support for software reuse. Domain engineering
  promises to produce component with higher
  reusability, and defines chances and contexts of
  reuse by defining architecture. All of these
  eventually support developers to reuse these
  components, and make reuse formal, systematic and
  efficient.

20
Appendix

• ??????????????,?????????,???????????,?????????????
  ?????????????????????,????????,????????????????/??
  ????????????????????
• ???????????????,????????????????,?????????????????
  ???,??????,???????????????????????(??????????,???D
  SSA)?????,??????????????????? Prieto
  90???,?????????????,????????,??????????,?????????
  ??????????,?????????????????,????????
• ???????????,???????????????,????????????(Developme
  nt for Reuse),?????????????(Development with
  Reuse)???????????????????????????????,???????????,
  ??????????,?????????????????,?????????????????
• ??????????????????????????????????????????????????
  ??,?????????????,?????????????????????????????????
  ?????????????,?????????????,???????????????
• ??????????????? Prieto 93,???????????,?????????(
  Compositional)???????(Generative)??????????????,?
  ??????(Black-box)?????(White-box)???

21
Appendix

• ???????????????,????????????????????
• ??????????????????????????
• ????????????????????????????,?????????????????????
  ,????????????,??????????????????,???????????????,?
  ??????????????,???????????
• ??????????????????????????????????????????,???????
  ????????????????????????????????????????????????,?
  ????????????????????????????????????????????,?????
  ????????????,?????????????????????????
• ????????????????????????????????????????????????,?
  ????????????????????????????
• ????
• ????
• ????
• ????????????????????????????????????????

22
Appendix

• Domain engineering
• Systematic approach to construct reusable assets
  in a given problem domain
• Activity of
• collecting, organizing and storing past
  experience in building (parts of) systems
• in a particular domain
• in the form of reusable assets
• as well as providing means for resuing these
  assets (retrieve, adapt, assemble, ...)
• when building new systems
• Application engineering
• Use the assets to build specialized software
  systems in the given domain.