An Introduction to Component reuse: conceptual foundations and its applications in the metamodelling

1
An Introduction toComponent reuse conceptual
foundations and its applications in the
metamodelling based system analysis and design
environment

• Zheying Zhang
• Research seminar on Software Business
• 5/2/2003

2
Outline

• Introduction
• Background and terminologies
• Current situation of the reuse support in ISD
• Research questions
• Research methodology
• Thesis structure and a short summary of each
  chapter
• Conclusion and discussions

3
Introduction

• Zheying Zhang
• Researcher in metaPHOR research group since 1997
• Researcher in RAMSES project (1/1999-4/2000)
• Licentiate thesis accepted in 9/2001
• Researcher in SB program since 11/2001
• Research
• Dissertation is going to be ready in 2003
• Assistant professor since 1/2003
• Teaching
• Thesis supervising
• Research and dissertation work

4
MetaPHOR research group

• Metamodeling, Principles, Hypertext, Objects and
  Repositories (http//metaphor.it.jyu.fi)
• Two experimental and commercial metaCASE tools
  MetaEdit MetaEdit
• Research topics
• Application principles, tool architectures and
  technical solutions for configurable metaCASE
  environments
• Investigate, analyze and understand the evolution
  of knowledge and knowledge representations
• Hypertext and traceability support in systems
  development, process support and enactment
  environments
• Reuse of software and design artifacts both at
  the design and metadesign levels
• Visual and 3D user interfaces and their modeling
  in CASE

5
RAMSES project

• RAMSES stands for Reuse in Advanced Method
  Support EnvironmentS.
• Goals
• Building theoretical background on component
  reuse
• Engineering the principles for component
  definition, search, management and retrieval
• Building the automated tools support for
  component reuse and field testing
• Founded by Tekes, National Technology Agency,
  metaCASE consulting, and Nokia Mobile Phone.

6
Licentiate Thesis - Research questions

• Title Component-based reuse in a metaCASE
  environment
• Theoretical foundation of RAMSES project
• Research questions
• Q1 How can we define a conceptual framework that
  supports systematic reuse in a metaCASE
  environment?
• Q2 What is the generic model of reusable
  components in a metaCASE environment?
• Q3 What is the needed functionality of an
  integrated metaCASE environment that supports
  systematic reuse?

7
Licentiate Thesis - Contents

• Chp1 Introduction -- Q1
• Chp2 Conceptual frameworks for systematic reuse
  in a metaCASE environment -- Q1
• A framework for component reuse in a
  metamodelling based system development -- REJ
  6(2), 2001
• Chp3 Component 3C model expanded from (Tracz
  1990) Q2
• Defining components in a metacase environment
  CAiSE00
• Chp4 Prototype of component 3C model and its
  application in system analysis and design Q23
• Using component for system analysis and design in
  a metaCASE environment -- working paper
• Chp5 prototype of component search tool in
  MetaEdit -- Q3
• Enhance component reuse by using search
  techniques -- IRIS23

8
Dissertation - Plan

• Further study the component model
• Specifying the context aspect of the component
  model
• Empirically study
• The usability and influence of the component
  functionality on the system analysis and design
  phases of the product development life cycle
• Validate and refine the concept and content
  aspects of the component model on component
  functionality in MetaEdit

9
Dissertation - Title
Component Reuse Conceptual Foundations and its
Applications in the Metamodelling based System
Analysis and Design Environment
10
Licentiate thesis requirements

• Capability to formulate and solve a scientific
  problem
• Communicate it in a style which is acceptable
• Length 80-200 pages
• normally three articles and an introduction

-- Licentiate seminar 1998, Kalle Lyytinen
11
PhD thesis requirements

• Sufficient scholarly contribution to the
  scientific knowledge
• Authors skills in using scientific research
  methods
• Communicate the results in a manner which is
  acceptable within the scientific community
• Size 4-6 articles or 120-300 pages
• Capability to show independent contribution
• Some articles must be written alone (minimum 2)
• Unified theme
• Committee proof by refereed publications

-- Licentiate seminar 1998, Kalle Lyytinen
12
PhD thesis work

• Management of PhD work through Thesis Proposal
• Guides your own work
• Communicates others what you want to achieve
  (sponsors, colleagues, supervisor)
• Serves as a contract between you and your
  supervisor

-- Licentiate seminar 1998, Kalle Lyytinen
13
PhD proposal

• Incremental refinement, proposal must be finished
  within the first 2-3 years
• Continually revised
• Not the same as starting from scratch several
  times
• Good proposal is your best help in achieving your
  goal

-- Licentiate seminar 1998, Kalle Lyytinen
14
PhD proposal structure (Davis Parker)

• Summary
• Problem, hypothesis or question
• Importance of the topic
• Prior research to the topic
• Research approach / methodology
• Limitations / key assumptions
• Expected contribution to knowledge
• Content outline

-- Licentiate seminar 1998, Kalle Lyytinen
15
Outline

• Introduction
• Background and terminologies
• Current situation of the reuse support in ISD
• Research questions
• Research methodology
• Thesis structure and a short summary of each
  chapter
• Conclusion and discussions

16
Basic Concepts

• Information system development (ISD)
• CASE and metaCASE tools
• Component based systems engineering (CBSE)
• Reuse in ISD

17
How can we think of systems development?

• It is the change process covering
• the real world field of phenomena
• conceptualizations of the real world conceptual
  structure
• descriptions of the conceptualizations a
  description language
• in order to represent
• target systems in a complete and unambiguous way.

18
How can we think of systems development? (Cont.)

• Notion
• Reality
• Conceptual structure
• Description language
• Target systems

• Example
• A real XYZ inventory system
• Ideas of material flows, information flows and
  their interactions
• Work-flow notation (or ER, DFD, UML notation)
• Representation of XYZ inventory system in a
  work-flow notation

19
Information Systems Development (ISD)

• Information system development is a change
  process taken with respect to a number of object
  systems in set of environments by a development
  group to achieve or maintain some objectives held
  by some stakeholders.

-- (Lyytinen 1987)
20

• Object systems
• Identify a target of change
• Arbitrary boundary set by purpose and objectives

• Change process
• A set of development activities
• A procedure, possibly with a prescribed notation,
  perform the change process (development activity)
  (Brinkkemper 1996)
• Combined techniques form an approach to
  performing an ISD project, called a method

• Environment
• A web of conditions and factors which surround
  development processes and affect the development
  group and its change process, including labor,
  economy, technology/infrastracture, normative,
  stakeholders

• Development group
• Formally organized group with mutual
  expectations, punishments and rewards, positions,
  roles, authority, or responsibility

21

• Objectives
• intensions in systems development What is good,
  how one should behave

• Stakeholders
• can set claims about the object systems and their
  properties
• driven by specific interests and goals
• can be grouped as
• Internal stakeholders (users, management,
  organizational units)
• External stakeholders (clients, government
  bodies, professional associations, computer
  manufactures, software house, etc.)

22
Information systems development method

• Definition
• Information systems development method is an
  organized collection of concepts, beliefs,
  values, and normative principles (knowledge)
  supported by material resources to carry out
  changes in object systems in an effective and
  systematic manner (Lyytinen 1987).
• Purpose
• To enable / support change processes
• Achieve some process goals or product goals set
  by the stakeholders

23
Use of methods and ISD life-cycle

• Business process re-engineering and development
• business modeling, process modeling, work flow
  modeling, task structure
• Requirements engineering
• brain-storming, interviews, requirements analysis
  methods, requirements review methods
• System analysis and design
• data modeling, structured analysis and design, OO
  analysis and design
• Construction
• mapping from high level language to machine
  language, version control
• Operation and maintenance
• Version control, configuration management,
  reverse engineering

24
Basic Concepts

• Information system development (ISD)
• CASE and metaCASE tools
• Component based systems engineering (CBSE)
• Reuse in ISD

25
CASE - an acronym with many interpretations ...
Engineering

• Computer

Assisted Aided Automated
Software Software System Information
Systems
CASE is use of computer-based support in the
software development process (SEI, 1996)
26
What is a CASE tool?

• CASE tool supports several fixed conceptual
  structures (system description languages) (and
  associated processes and validity criteria)
• A CASE tool is a software environment that
  assists systems analysts and designers in
  specifying, analyzing, designing and maintaining
  an information system. (Loucopoulos, 1992)

27
The emergence of CASE technology

• CASE tool is
• a stand-alone tool to help automate program
  diagramming and documentation (early 80s)
• including automatic checks of designs (mid 80s)
• an integrated environment for a model editor, a
  document generator, a code generator, and
  repository
• CASE tool automates time-consuming aspect of the
  systems development process including
• drawing diagrams
• cross-checking of concepts across the system
  models
• generating system documents, code structure, and
  database schemas

28
Tool support for models
29
Models and visual modeling

• A model is a representation of the
  conceptualization of the real world
• A model is a representation of your problem
  domain and software system
• A model contains classes, logical packages,
  objects, operations, component packages,
  components, processors, devices, and the
  relationships between them
• A model also contains diagrams and specifications
• Visual modeling gives you a graphical
  representation of the structure and
  interrelationships of a system by constructing
  models of your design

30
Example CASE tool

• MetaEdit offers CASE tool support for the
  defined method. It provides diagramming editors,
  browsers, generators, multi-user support, etc

31
CASE tool Use

• Organizations in a rapid changing market requires
  CASE tools can
• flexibly create and modify the conceptual
  structure
• Hardly any project applies OMT as Rumbaugh et al.
  originally defined
• In practice 88 methods are always customized for
  local needs (Hardy et al.)
• be used in specific application domains
• When the conceptual structures can be modified
  easily we talk of metaCASE tool

32
Meta-

• Meta (Greek), X about x X behind x
• meta-level techniques support abstract principles
  behind certain phenomena

MetaCASE

• MetaCASE is an area of CASE, in which information
  system development method support is generated
  from metamodels

33
What is a metaCASE tool?

• A metaCASE tool is software tool that supports
  the design and generation of CASE tools
• A metaCASE tool facilitates the design and
  specification of a method whose full and formal
  definition is not readily available.
• Design and specification of a method method
  engineering

34
Tool support for metamodels

• Metamodels are conceptual models of methods
  (Brinkkemper 1990)
• Metamodels can be roughly divided into process
  and product models
• Meta-process model conceptualization,
  formalization and abstraction of modelling
  process
• e.g. DFD, AD
• Meta-data model conceptualization, formalization
  and abstraction of representations or concepts
  involved in methods
• e.g. ERD, CD

35
Metamodelling

• Metamodelling is the process of specifying a
  metamodel using a metamodelling language
• Method engineering is a metamodelling process to
  specify and integrate a method into a metamodel
  from the perspectives of concepts, properties,
  rules, and generators.

36
Model and metamodel
37
Modeling and metamodeling
Metamodelling language
Modelling language
Metamodelling and modeling in a metaCASE
environment (after (Brinkkemper 1990))
38
What is a metaCASE tool? - Example
MetaEdit Method workbench is a tool for
designing your method its concepts, rules,
notations and generators. The method definition
is stored as a metamodel to the MetaEdit
repository. 
39
What is a metaCASE environment?
MetaEdit metaCASE tool allows you to design your
method and use it.
MetaCASE environment is a system which supports
metamodeling in the same environment as
modelling, and itself produces the metamodel and
inputs it to the metaCASE tools.
40
Basic Concepts

• Information system development (ISD)
• CASE and metaCASE tools
• Component based systems engineering (CBSE)
• Reuse in ISD

41
Why component?

• Essential techniques for managing system
  complexity - modularity and separation of
  concerns
• Increased understanding and awareness of
  distributed computing and movement from
  mainframe-based systems toward client/server
  computing have fuelled that ISD is a set of
  separable, interacting sub-systems development
  rather than monolithic

42
Why component? business objectives

• Changes in business requirements
• Make the most of what you have
• Integrated business processes
• Exploit new opportunities
• Electronic commerce, E-business
• Build for change
• Flexible information systems

43
Why component? technology trends

• Systems are not build from scratch or standalone
• Application assembly and extension
• New technology are appearing all the time
• Technology independency
• Systems are constructed from many pieces
• Component design focus
• The resulting distributed systems are complex
• Architecture visualization
• Advance in application architecture
• Mainframe ? client/server ? internet/network ?
  

44
What is a component?

• A constituent part Merriam-Webster online
• A software component is a unit of composition
  with contractually specified interfaces and
  explicit context dependencies only. A software
  component can be deployed independently and is
  subject to composition by third parties. --
  (Szyperski, 1998)

45
Characteristics of component

• Packaging perspective - reuse
• A component as the unit of packaging,
  distribution, or delivery
• Service perspective - interface
• A component as the provider of services
• Integrity perspective - replacement
• A component as a data integrity or encapsulation
  boundary

-- Sterling software (Short 1997)
46
Component based development

• Emerged in 1990 as a reuse-based approach
• Motivation OO development had not led to
  extensive reuse as originally suggested
• Component based development
• A software development approach where all aspects
  and phases of the development lifecycle,
  including requirements analysis, architecture,
  design, construction, testing, deployment, the
  supporting technical infrastructure, and the
  project management are based on components.

47
CBD Activities and Artifacts
48
Scope of component-based design and techniques
(Sterling Software, 1999)
49
Component based systems engineering (CBSE)

• CBSE is a process that emphasizes the design and
  construction of systems using reusable components
• CBSE is changing the way large systems are
  developed.
• CBSE embodies the buy, do not build philosophy
  espoused by some engineers
• CBSE shifts the emphasis from programming to
  composing IS
• Implementation has given way to integration as
  the focus
• The foundation of CBSE is the assumption that
  there is sufficient commonality in many large IS
  to justify developing reusable components to
  exploit and satisfy that commonality

50
Basic Concepts

• Information system development (ISD)
• CASE and metaCASE tools
• Component based systems engineering (CBSE)
• Reuse in ISD

51
Software reuse

• In most engineering disciplines, systems are
  designed by composing existing components that
  have been used in other systems
• Software engineering has been more focused on
  original development but it is now recognized
  that to achieve better software, more quickly and
  at lower cost, we need to adapt a design process
  that is based on systematic reuse

52
Reuse past and present

• Reuse is both an old and a new idea. Programmers
  have reused ideas, abstractions and processes
  since the earliest days of computing
• First introduced by McIlroy in 1968 to solve the
  problem of software crisis (McIlroy 1969)
  (Krueger 1992)
• The early approach to reuse is ad hoc.
• Today, complex, high quality information systems
  must be built in very short time periods. This
  mitigates towards a more organized approach to
  reuse.

53
What is reuse?

• Reuse use again after processing -Webster
• Reuse in ISD starts from software reuse, which
  applies existing software and design artifacts to
  deliver new applications, or to maintain the old
  ones
• Reusable asset A collection of related software
  work products that may be reused from one
  application to another

54
Features of reuse

• Is a long-term strategy
• Is driven by business decisions
• Must be integrated in the software/system
  development process
• reuse adoption is part of process improvement
• Is an investment
• Strongly depends on organization structure and,
  ultimately on people
• Is more effective within a domain

55
Benefits of reuse

• Increased reliability
• Components exercised in working systems
• Reduce process risk
• Less uncertainty in development costs
• Effective use of specialists
• Reuse components instead of people
• Standards compliance
• Embed standards in reusable components
• Accelerated development
• Avoid original development and hence speed-up
  production

56
Type of reuse

• Ad-hoc reuse
• No plan, no defined process
• Opportunistic reuse
• No standard process
• The software developer identifies the need and
  browse the repository to find the needed assets
• Systematic reuse
• Well-planned, cost-effective, and productive
• The purposeful creation, management, support, and
  reuse of assets (Jacobson et al. 1997)
• Requires long-term management support and years
  of investment

57
Levels of reuse

• Specification
• e.g. Spec. documents, project plans
• Design
• e.g. design patterns, domain models
• Less implementation, portable and reusable,
  provide greater savings
• Code
• e.g. class libraries, functional units performing
  business tasks
• Test
• e.g. test cases and data
• Results in more reliable system

58
Reusable assets

• Off-the-shelf (COTS)
• Assets identified as being of potential interest,
  which may come from a variety of local and remote
  sources, selected or concerned at the
  requirements analysis stage
• Qualified
• Assets assessed by software engineers to ensure
  that not only functionality, but also
  performance, reliability, usability, and other
  quality factors conform to the requirements of
  the system/product to be built
• Adapted
• Assets adapted to modify (wrapping) unwanted or
  undesired characteristics

59
Reusable assets (Cont.)

• Assembled
• Assets integrated into an architectural style and
  interconnected with an appropriate system
  infrastructure that allows the assets to be
  coordinated and managed effectively.
• Updated
• Replacing existing software as new versions of
  assets become available

60
Outline

• Introduction
• Background and terminologies
• Current situation of the reuse support in ISD
• Research questions
• Research methodology
• Thesis structure and a short summary of each
  chapter
• Conclusion and discussions

61
Current situation, related research and research
problems

• Reuse technology current reuse support in ISD
• Current tools support for component reuse
• Research problems

62
Current reuse support in ISD

• A technique supporting reuse may consist of both
  developing for reuse and developing with reuse
• e.g. product line engineering
• Reuse techniques
• Object oriented techniques
• Design patterns
• Application frameworks
• Agent-based systems
• Architectures
• Domain-specific modeling
• Component-based development

63
Comparison of reuse techniques (part)
-- (Ezran, 1998)
64
Domain-specific modeling (DSM)

• Domain - a problem space for a family of
  applications with similar requirements, a set of
  related systems with commonality
• DSM - the process to understand the customers
  requirements within the domain and represent the
  requirements in the form of logical models (Sodhi
  and Sodhi 1998)
• DSM allows developers to concentrate on the
  required functionality and shift the focus from
  code to design

65
DSM environment

• DSM environment consists of
• Domain-specific modeling language
• operates on domain concepts, not on code
• limited variation space
• Domain-specific code generator
• generates products described by the models
• variation for output formats
• Domain framework
• supports code generation
• primitive services and components on top of the
  platform

66
Benefits of DSM

• Captures domain knowledge (as opposed to code)
• Uses domain abstractions
• Applies domain concepts and rules as modeling
  constructs
• Narrow down the design space
• Focus on single range of products
• Benefits
• Apply familiar terminology
• Solve the RIGHT problems!
• Solve problems only ONCE! model-driven reuse

Faster development of quality products!
--- MetaCASE Consulting, 2001
67
Modeling domain vs. modeling code
DomainIdea
FinishedProduct
Solve problem in domain terms
--- MetaCASE Consulting, 2001
68
Summary of DSM

• Expected benefits
• make a product family explicit
• leverage the knowledge of the family to help
  developers
• substantially increase the speed of variant
  creation
• ensure that the family approach is followed de
  facto
• The amount of expert resources needed to build
  and maintain a DSM does not grow with the size of
  product family and/or number of developers
• Problems
• Organizational changes (introduction, diffusion)

69
Component-based development

• A software development approach where all
  aspects and phases of the development lifecycle,
  including requirements analysis, architecture,
  design, construction, testing, deployment, the
  supporting technical infrastructure, and the
  project management are based on components.

70
Why component based development

• Reuse
• Deal with change
• Manage complexity
• Create commerce in component

-- (SEI, 2002)
71
Why component based development - Reuse

• Expected benefits
• The rewards of theft over honest toil (Will
  Tracz)
• Problems
• It is not as easy as it sounds
• Planned component reuse never seems to happen
• Cost of developing reusable components requires
  an asset be reused 2.5 times to recover the added
  cost
• Sound modest, but it was not happening
• Lots of organizational/cultural resistance
• We know what we want, we can do it better
• Well spend all our time trying to figure out how
  to use it

-- (SEI, 2002)
72
Why component based development - Dealing with
change

• Expected benefits
• Component leads to linear cost of change i.e.,
  requirements become modular by virtue of
  components
• Problems
• It is not as easy as it sounds
• Component are not as modular as they seem they
  interact i.e. are co-dependent
• Interface languages are not expressive enough to
  hide all the properties that might be sources of
  dependency

-- (SEI, 2002)
73
Why component based development - Managing
complexity

• Expected benefits
• Components hide complexity for distribution (i.e.
  black boxes)
• Problems
• It is not as easy as it sounds
• Complex component functionality
  (feature-richness) still leads to complex
  interfaces
• Interface languages are not expressive enough, so
  hidden properties accumulate and lead to
  unanticipated interactions

-- (SEI, 2002)
74
Why component based development - Commerce of
components

• Expected benefits
• Shorten design-to-production cycles
• Provide current technology solutions
• Problems
• Be careful for what you wish
• The market yields components that are
• Complex
• Idiosyncratic
• Unstable
• See previous two slides

-- (SEI, 2002)
75
Systematic reuse obstacles - nontechnical

• Organizational
• One project at a time
• Managerial
• Attitude fear and mistrust
• Lack of knowledge
• Business
• Reuse takes capital and founding
• Psychological
• Cognitive barriers
• Notations and representations

76
Systematic reuse obstacles - technical

• Engineering
• Lack of suitable component
• Lack of flexibility in potentially reusable
  components
• Lack of tools
• Lack of standard
• Cognitive barriers
• Process support

77
Current situation, related research and research
problems

• Reuse technology current reuse support in ISD
• Current tools support for component reuse
• Research problem definition

78
Reuse supported tools

• Many tools on the market with slogans to support
  CBD and thereby reuse
• Most of the tools support enterprise modeling,
  code generation, and round-trip engineering
• We analyze 6 typical commercial tools in COMBO
  project MetaEdit, ObjectiF, Paradigm Plus, Rose
  98, Select Family, Together Solo

79
Results of tool survey

• We can obtain some insights into the various ways
  in which technologies support reuse
• But it still lacks an integrated reuse
  environment and an approach to systematic reuse
• Limited understanding of reusable
  assets/components
• Insufficient support for systematic reuse
• Limited modeling technique support

80
Result 1 Limited understanding of reusable
assets/components

• Most tools regard only code as a reusable asset
• Reusing design artifacts at stages earlier than
  implementation has greater potential leverage
  because of their greater expressive power
• Reusing design artifacts at stages earlier than
  implementation can further trigger code reuse

81
Result 2 Insufficient support for systematic
reuse

• Current reuse support tools are mainly subject to
  ad hoc/opportunistic reuse
• Most tools support CBD which can bring benefits
  to reuse, but none takes reuse as their mission
• The supporting tools should have a generic
  framework to guide the systematic reuse process
• Reusable assets creation process
• domain analysis and modeling, component
  development, and asset evolution
• Reusable assets management process
• asset acquisition, asset cataloging, asset
  metrics collection, and library operations such
  as library support procedures, library access
  control, configuration management, as well as
  reuse promotion
• Reusable assets utilization process
• asset requirement determination, asset selection,
  adaptation, and integration

82
Result 3 Limited modeling technique support

• Most tools lacks method engineering support and
  only provide limited notations (e.g. UML) for
  system modeling
• 88 (Hardy, Thompson et al. 1995 Russo and
  Wynekoop 1995) of the organizations adapt the
  method-in-house, and 38 (Hardy, Thompson et al.
  1995) of organizations have developed their own
  method
• Lacks data transmission support between tools

83
Summary of tool survey

• Most tools cannot provide an ideal environment
  that facilitates systematic reuse processes
  throughout the ISD lifecycle, and lack flexible
  support for various system development methods
• One solution is to expand the functionality of
  current metaCASE environments by adding
  systematic reuse support
• The metaCASE environment can be further tailored
  for a specific application domain to support
  reuse in a product family

84
Current situation, related research and research
problems

• Reuse technology current reuse support in ISD
• Current tools support for component reuse
• Research problem definition

85
Research problems

• The dissertation aims towards a metaCASE
  environment, which would support systematic reuse
  in both the method engineering and systems
  engineering process.
• Q1 How can we utilize different reuse techniques
  and define a conceptual framework that supports
  systematic reuse in a metaCASE environment?
• Q2 What is the generic model of reusable
  components in a metaCASE environment?
• Q3 What is the needed functionality of an
  integrated metaCASE environment that supports
  systematic reuse?

86
Research environment

• MetaEdit - an industry strength metaCASE
  environment
• MetaEdit provides tools for
• environment management
• model editing
• repository browser
• and method workbench
• Systematic reuse support is insufficient in
  MetaEdit
• Component is not clearly defined in both
  metamodelling level and model level, which
  hinders systematic reuse.

87
Outline

• Introduction
• Background and terminologies
• Current situation of the reuse support in ISD
• Research questions
• Research methodology
• Thesis structure and a short summary of each
  chapter
• Conclusion and discussions

88
Multi-methodological research approach

• Theory building
• development of new ideas and concepts, and
  construction of conceptual frameworks, new
  methods, or models
• Experimentation
• research strategies such as laboratory and field
  experiments
• Observation
• empirical methodologies such as case studies,
  field studies, and sample surveys that are
  unobtrusive research tasks
• System development
• constructive process consisting of stages like
  concept design, constructing the architecture of
  the system, prototyping, product development, and
  technology transfer

-- (Nunamaker and Chen 1991)
89
Theory building Conceptual frameworks Mathematic
models Methods
System Development Prototyping, Product
development, Technology Transfer
Observation Case studies, Survey studies, Field
studies
Experimentation Field experiments Lab experiments
-- A Multi-Methodological Approach to Research
Work (Nunamaker and Chen 1991)
90
Observation

• Provides an overview of the state of the art
• Interviews by RAMSES project
• Survey of (meta)CASE Tools by COMBO student
  project

91
Theory building

• A systematic reuse architecture in the metaCASE
  environment
• studies the reuse possibilities and types of
  reuse from both metamodelling (method
  construction) and modeling (system development)
  aspects
• A complete reuse activities in a reuse framework
• A 3C component model

92
Systems development

• Prototype of component construction
• Component definition tool
• Prototype of component retrieval
• Component search tool
• Component library
• Prototype of component integration
• Component integrated into a domain specific
  design architecture (defined in experiment case)

93
Experiments

• A laboratory experiment has been carried out to
  study the usability of components in
  metamodelling supported system analysis and
  design environment
• Testing case user interface design of certain
  functions of a mobile phone
• The experimental metaCASE environment is
  MetaEdit

94
Experiments (Cont.)
95
Outline

• Introduction
• Background and terminologies
• Current situation of the reuse support in ISD
• Research questions
• Research methodology
• Thesis structure and a short summary of each
  chapter
• Conclusion and discussions

96
Dissertation

• Component Reuse -- Conceptual Foundations and its
  Applications in the Metamodelling based System
  Analysis and Design Environment
• made up of 6 separate papers published or
  submitted for publication

97
Thesis structure - table of contents

• Chp1 Introduction
• Chp2 A Framework for Component Reuse in a
  Metamodelling Based Software Development (REJ,
  6(2) 2001)
• Chp3 Defining Components in a MetaCASE
  Environment (CAiSE00)
• Chp4 Component modeling for system analysis and
  design (ICSR7 2002 Workshop on Component-based
  Software Development Processes)
• Chp5 Component Context Specification and
  Representation in a MetaCASE Environment
  (submitting to REJ)
• Chp6 Component analysis in the metamodelling
  based information systems development (OOPSLA2001
  workshop on DSVL)
• Chp7 Implementation and Evaluation of Component
  Reuse in Metamodelling Supported System Analysis
  and Design (Working paper)

98
Thesis structure - Summary of the research
questions and their handling
99
Chapter 2 Abstract (A Framework for Component
Reuse in a Metamodelling Based Software
Development )

• This chapter aims at suggesting a component
  reusability framework that can address issues
  related to design artifact and method component
  reuse in the lifecycle of systems development. In
  particular, it seeks to demonstrate how reuse
  ideas can be implemented in an industry
  strength environment called MetaEdit. Our
  strategy to meet these goals is the following. We
  first develop a general framework for
  metamodelling based component reuse. This
  framework considers reuse from the perspectives
  of a systems development lifecycle, modeling
  levels, reuse situation types, component
  granularity, and reuse activities. The framework
  is then used to analyze support functionality
  within a metaCASE environment, and to suggest how
  reuse activities can be integrated into method
  engineering processes and associated tasks of
  defining development processes and their
  technical facilitation.

100
General architecture for reuse
101
Reuse Framework
102
Chapter 3 Abstract (Defining Components in a
MetaCASE Environment )

• This chapter suggests component based approach
  helps unify design artefacts into components with
  explicit interfaces and meaningful context
  descriptions. We describe a method artifact from
  three perspectives concept, content, and
  context. We create a component concept by using a
  hierarchical facet-based schema, and represent
  contextual relationship types by using
  definitional and reuse dependency, usage context,
  and implementation context links. This is the
  first attempt to explicitly define components
  into a metaCASE environment.

103
Component model and its presentation in UML
notation
104
Chapter 4 Abstract (Component modeling for
system analysis and design)

• Taking into account the features of components
  and its involved metaCASE environment, This
  chapter improves the concept and text aspect of
  the component model by adding more supplementary
  information and offering more flexibility in its
  interface description. Such a component model and
  the associated functionality for component
  classification and retrieval greatly enhance the
  possibilities of incorporating reuse and
  components into the early phases of systems
  development practice.

105
3C Component model
106
Chapter 5 Abstract (Component Context
Specification and Representation in a MetaCASE
Environment)

• This chapter specifies the context aspect of the
  component model. It presenting and exemplifying
  the frameworks of component context and its
  hypertext representation in MetaEdit. It
  addresses the possible linking of contextual
  knowledge to components, including the conceptual
  dependencies of component construction, reuse,
  and implementation, as well as the reasoning and
  rationale behind design and reuse processes.
  Furthermore, it illustrates the hypertext
  approach to contextual knowledge representation,
  which provides ways for users to express,
  explore, recognize, and negotiate their shared
  context.

107
Chapter 6 Abstract (Component analysis in the
metamodelling based information systems
development)

• This chapter presents the component taxonomy in
  the metamodelling based systems development
  environments, such as MetaEdit. It elaborates on
  the aspects of structure, functionality,
  supporting environment, and reusability to
  analysis and compare between code component,
  model component, and metamodel component. Through
  comparison, it presents the current state of
  component based development in metaCASE
  environments, and reveals the difficulties and
  research directions in further research of
  component based metaCASE environment.

108
Chapter 7 Abstract (Implementation and
Evaluation of Component Reuse in Metamodelling
Supported System Analysis and Design)

• The last chapter presents an empirical study of
  component-based reuse in systems analysis and
  design. Based on the conceptual framework and 3C
  component model built in the prior chapters, a
  testing case is developed and the laboratory
  experiment is designed to study the usability of
  components in system analysis and design and the
  supporting functionality provided by a metaCASE
  environment. MetaEdit is used in the experiment.

109
Conclusions

• Contribution and limitations

110
Interesting research topics - Reuse and agile
approach

• Will reuse be a suitable strategy for project
  teams taking an agile approach to software
  development?
• A lot of work has been done in the context of
  software reuse on heavyweight domain engineering
  method however, there are also approaches such
  as Extreme Programming (XP), agile modelling,
  domain specific language that put emphasize on
  evolution, flexibility, and responsiveness rather
  than proactive and preplanned generalization.
  These approaches have been useful at either
  creating reusable components or at least made it
  so that systems can quickly evolve and adapt to
  changing user requirements.

111
Interesting research topics Requirements reuse

• How to apply a reuse based approach to the early
  phases of systems development, reusing
  requirements? (http//giro.infor.uva.es/docpub/Doc
  -Workshop.pdf)
• Framework?
• Process?
• Techniques?

112
Interesting research topics

• More are coming