sb program university of jyväskylä 1 an introduction to component reuse: conceptual foundations...
Post on 21-Dec-2015
214 Views
Preview:
TRANSCRIPT
SB Program
University of Jyväskylä 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
SB Program
University of Jyväskylä 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
SB Program
University of Jyväskylä 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
SB Program
University of Jyväskylä 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
SB Program
University of Jyväskylä 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.
SB Program
University of Jyväskylä 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?
SB Program
University of Jyväskylä 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 – CAiSE*00 Chp4 Prototype of component 3C model and its application in system
analysis and design – Q2&3– 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
SB Program
University of Jyväskylä 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+
SB Program
University of Jyväskylä 9
Dissertation - Title
Component Reuse
Conceptual Foundations and its Applications in the Metamodelling based System Analysis and Design Environment
SB Program
University of Jyväskylä 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
SB Program
University of Jyväskylä 11
PhD thesis requirements
Sufficient scholarly contribution to the scientific knowledge Author’s 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
SB Program
University of Jyväskylä 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
SB Program
University of Jyväskylä 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
SB Program
University of Jyväskylä 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
SB Program
University of Jyväskylä 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
SB Program
University of Jyväskylä 16
Basic Concepts
Information system development (ISD) CASE and metaCASE tools Component based systems engineering (CBSE) Reuse in ISD
SB Program
University of Jyväskylä 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.
FOD
TS Implementation
Mapping
Reverse
Conceptulization
SB Program
University of Jyväskylä 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
SB Program
University of Jyväskylä 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)
SB Program
University of Jyväskylä 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
SB Program
University of Jyväskylä 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.)
SB Program
University of Jyväskylä 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
SB Program
University of Jyväskylä 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
SB Program
University of Jyväskylä 24
Basic Concepts
Information system development (ISD) CASE and metaCASE tools Component based systems engineering (CBSE) Reuse in ISD
SB Program
University of Jyväskylä 25
CASE - an acronym with many interpretations ...
Computer EngineeringSoftware[Software] System[Information] Systems
AssistedAidedAutomated
“CASE is use of computer-based support in the software development process” (SEI, 1996)
SB Program
University of Jyväskylä 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)
SB Program
University of Jyväskylä 27
The emergence of CASE technology
CASE tool is– a stand-alone tool to help automate program diagramming and
documentation (early 80’s)– including automatic checks of designs (mid 80’s)– 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
SB Program
University of Jyväskylä 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
SB Program
University of Jyväskylä 30
Example – CASE tool
MetaEdit+ offers CASE tool support for the defined method. It provides diagramming editors, browsers, generators, multi-user support, etc
SB Program
University of Jyväskylä 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
SB Program
University of Jyväskylä 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
SB Program
University of Jyväskylä 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
SB Program
University of Jyväskylä 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
SB Program
University of Jyväskylä 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.
SB Program
University of Jyväskylä 37
Modeling and metamodeling
Metamodelling and modeling in a metaCASE environment (after (Brinkkemper 1990))
Metamodelling language
Modelling language
SB Program
University of Jyväskylä 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.
SB Program
University of Jyväskylä 39
What is a metaCASE environment?
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.
MetaEdit+ metaCASE tool allows you to design your method and use it.
SB Program
University of Jyväskylä 40
Basic Concepts
Information system development (ISD) CASE and metaCASE tools Component based systems engineering (CBSE) Reuse in ISD
SB Program
University of Jyväskylä 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
SB Program
University of Jyväskylä 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
SB Program
University of Jyväskylä 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 … …
SB Program
University of Jyväskylä 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)
SB Program
University of Jyväskylä 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)
SB Program
University of Jyväskylä 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.
SB Program
University of Jyväskylä 48
Scope of component-based design and techniques
(Sterling Software, 1999)
SB Program
University of Jyväskylä 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
SB Program
University of Jyväskylä 50
Basic Concepts
Information system development (ISD) CASE and metaCASE tools Component based systems engineering (CBSE) Reuse in ISD
SB Program
University of Jyväskylä 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
SB Program
University of Jyväskylä 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.
SB Program
University of Jyväskylä 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
SB Program
University of Jyväskylä 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
SB Program
University of Jyväskylä 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
SB Program
University of Jyväskylä 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
SB Program
University of Jyväskylä 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
SB Program
University of Jyväskylä 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
SB Program
University of Jyväskylä 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
SB Program
University of Jyväskylä 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
SB Program
University of Jyväskylä 61
Current situation, related research and research problems
Reuse technology – current reuse support in ISD Current tools support for component reuse Research problems
SB Program
University of Jyväskylä 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
SB Program
University of Jyväskylä 63
Comparison of reuse techniques (part)
Strength Weakness
OOT Enhances modularity and information hiding
Requires significant modeling effort
Design patterns
Facilitate retrieval of design solutions, provide guidelines for the development process
Implementation from scratch
Frameworks Domain specific semi-complete applications to be customized
Requires high expertise and deep understanding of the framework design
Software Agents
Highly customizable and adaptable, allow easy reconfiguration of complex system
Not yet mature and consolidated technology
Architectures Allow formal verification of structural properties. Simplify the reuse of technical and business objects
No guidance for choosing the right architecture
-- (Ezran, 1998)
SB Program
University of Jyväskylä 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 customer’s 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
SB Program
University of Jyväskylä 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
SB Program
University of Jyväskylä 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
BenefitsApply familiar terminologySolve the RIGHT problems!Solve problems only ONCE! – model-driven reuse
--- MetaCASE Consulting, 2001
Faster development of quality products!
SB Program
University of Jyväskylä 67
Modeling domain vs. modeling codeDomain
IdeaFinishedProduct
Sol
ve p
robl
em in
dom
ain
term
sAssembler
Map to code, implement
UML ModelMap to UML
Generate,Add bodies
ComponentsDomainModel
Generate callsto components
No map!
CodeMap to code, implement
--- MetaCASE Consulting, 2001
SB Program
University of Jyväskylä 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)
SB Program
University of Jyväskylä 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.
SB Program
University of Jyväskylä 70
Why component based development
Reuse Deal with change Manage complexity Create commerce in component
-- (SEI, 2002)
SB Program
University of Jyväskylä 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– We’ll spend all our time trying to figure out how to use it
-- (SEI, 2002)
SB Program
University of Jyväskylä 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)
SB Program
University of Jyväskylä 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)
SB Program
University of Jyväskylä 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)
SB Program
University of Jyväskylä 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
SB Program
University of Jyväskylä 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
SB Program
University of Jyväskylä 77
Current situation, related research and research problems
Reuse technology – current reuse support in ISD Current tools support for component reuse Research problem definition
SB Program
University of Jyväskylä 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
SB Program
University of Jyväskylä 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
SB Program
University of Jyväskylä 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
SB Program
University of Jyväskylä 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
SB Program
University of Jyväskylä 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
SB Program
University of Jyväskylä 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
SB Program
University of Jyväskylä 84
Current situation, related research and research problems
Reuse technology – current reuse support in ISD Current tools support for component reuse Research problem definition
SB Program
University of Jyväskylä 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?
SB Program
University of Jyväskylä 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.
SB Program
University of Jyväskylä 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
SB Program
University of Jyväskylä 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)
SB Program
University of Jyväskylä 89
ObservationCase studies,
Survey studies,Field studies
ExperimentationField experimentsLab experiments
Theory buildingConceptual frameworks
Mathematic modelsMethods
System DevelopmentPrototyping,
Product development,Technology Transfer
-- A Multi-Methodological Approach to Research Work (Nunamaker and Chen 1991)
SB Program
University of Jyväskylä 90
Observation
Provides an overview of the state of the art– Interviews – by RAMSES project– Survey of (meta)CASE Tools – by COMBO student project
SB Program
University of Jyväskylä 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
SB Program
University of Jyväskylä 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)
SB Program
University of Jyväskylä 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+
SB Program
University of Jyväskylä 94
Experiments (Cont.)
Selecting a tool and a testing case
Preparing for a testing case
Designing the experiment
Conducting the experiment
Developing the testing case by using the selected tool
Experiment design
Pilot study
Recruiting and training participants
Conducting the experiment and analyzing data
SB Program
University of Jyväskylä 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
SB Program
University of Jyväskylä 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
SB Program
University of Jyväskylä 97
Thesis structure - table of contents
Chp1 IntroductionChp2 A Framework for Component Reuse in a Metamodelling Based
Software Development (REJ, 6(2) 2001)Chp3 Defining Components in a MetaCASE Environment (CAiSE*00)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)
SB Program
University of Jyväskylä 98
Thesis structure - Summary of the research questions and their handling
Research Question Research Methodology
Chapter
Q1: Conceptual framework
Observation and Theory building
Chp 1 & 2
Q2: Component model Theory building, Prototyping, Laboratory experiment
Chp 1, 3, 4, 5, 6 & 7
Q3: Needed facilities Prototyping, Laboratory experiment
Chp 1, 5 & 7
SB Program
University of Jyväskylä 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.
SB Program
University of Jyväskylä 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.
SB Program
University of Jyväskylä 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.
SB Program
University of Jyväskylä 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.
SB Program
University of Jyväskylä 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.
SB Program
University of Jyväskylä 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.
SB Program
University of Jyväskylä 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.
SB Program
University of Jyväskylä 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? … …
top related