Académique Documents
Professionnel Documents
Culture Documents
Program
An Introduction to Component 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
University of Jyvskyl
SB
Program
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
University of Jyvskyl
SB
Program
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
3
University of Jyvskyl
SB
Program
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
University of Jyvskyl
SB
Program
RAMSES project
Founded by Tekes, National Technology Agency, metaCASE consulting, and Nokia Mobile Phone.
University of Jyvskyl
SB
Program
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?
University of Jyvskyl
SB
Program
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
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
University of Jyvskyl
SB
Program
Dissertation - Plan
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+
University of Jyvskyl
SB
Program
Dissertation - Title
Component Reuse
Conceptual Foundations and its Applications in the Metamodelling based System Analysis and Design Environment
University of Jyvskyl
SB
Program
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
University of Jyvskyl
10
SB
Program
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
University of Jyvskyl
11
SB
Program
University of Jyvskyl
12
SB
Program
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
University of Jyvskyl
13
SB
Program
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
14
University of Jyvskyl
SB
Program
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
University of Jyvskyl
15
SB
Program
Basic Concepts
Information system development (ISD) CASE and metaCASE tools Component based systems engineering (CBSE) Reuse in ISD
University of Jyvskyl
16
SB
Program
TS
Mapping
Implementation
Reverse
Conceptulization
in order to represent
target systems in a complete and unambiguous way.
FOD
University of Jyvskyl
17
SB
Program
Notion
Reality Conceptual structure
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
Description language
Target systems
University of Jyvskyl
18
SB
Program
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)
University of Jyvskyl
19
SB
Program
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
University of Jyvskyl
20
SB
Program
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.)
University of Jyvskyl
21
SB
Program
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
University of Jyvskyl
22
SB
Program
Requirements engineering
brain-storming, interviews, requirements analysis methods, requirements review methods
Construction
mapping from high level language to machine language, version control
University of Jyvskyl
23
SB
Program
Basic Concepts
Information system development (ISD) CASE and metaCASE tools Component based systems engineering (CBSE) Reuse in ISD
University of Jyvskyl
24
SB
Program
CASE is use of computer-based support in the software development process (SEI, 1996)
University of Jyvskyl
25
SB
Program
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)
University of Jyvskyl
26
SB
Program
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
University of Jyvskyl
27
SB
Program
University of Jyvskyl
28
SB
Program
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
University of Jyvskyl
29
SB
Program
MetaEdit+ offers CASE tool support for the defined method. It provides diagramming editors, browsers, generators, multi-user support, etc
University of Jyvskyl
30
SB
Program
When the conceptual structures can be modified easily we talk of metaCASE tool
University of Jyvskyl
31
SB
Program
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
University of Jyvskyl
32
SB
Program
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
University of Jyvskyl
33
SB
Program
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
University of Jyvskyl
34
SB
Program
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.
University of Jyvskyl
35
SB
Program
University of Jyvskyl
36
SB
Program
Metamodellin g language
Modelling language
University of Jyvskyl
37
SB
Program
University of Jyvskyl
38
SB
Program
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.
University of Jyvskyl
39
SB
Program
Basic Concepts
Information system development (ISD) CASE and metaCASE tools Component based systems engineering (CBSE) Reuse in ISD
University of Jyvskyl
40
SB
Program
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
University of Jyvskyl
41
SB
Program
University of Jyvskyl
42
SB
Program
University of Jyvskyl
43
SB
Program
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)
University of Jyvskyl
44
SB
Program
Characteristics of component
University of Jyvskyl
45
SB
Program
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.
University of Jyvskyl
46
SB
Program
University of Jyvskyl
47
SB
Program
SB
Program
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
University of Jyvskyl
49
SB
Program
Basic Concepts
Information system development (ISD) CASE and metaCASE tools Component based systems engineering (CBSE) Reuse in ISD
University of Jyvskyl
50
SB
Program
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
University of Jyvskyl
51
SB
Program
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.
University of Jyvskyl
52
SB
Program
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
University of Jyvskyl
53
SB
Program
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
University of Jyvskyl
54
SB
Program
Benefits of reuse
Increased reliability
Components exercised in working systems
Standards compliance
Embed standards in reusable components
Accelerated development
Avoid original development and hence speed-up production
University of Jyvskyl
55
SB
Program
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
University of Jyvskyl
56
SB
Program
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
University of Jyvskyl
57
SB
Program
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
University of Jyvskyl
58
SB
Program
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
University of Jyvskyl
59
SB
Program
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
University of Jyvskyl
60
SB
Program
Reuse technology current reuse support in ISD Current tools support for component reuse Research problems
University of Jyvskyl
61
SB
Program
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
62
University of Jyvskyl
SB
Program
Weakness
Requires significant modeling effort Implementation from scratch
Requires high expertise and deep understanding of the framework design Not yet mature and consolidated technology No guidance for choosing the right architecture
Software Agents
-- (Ezran, 1998)
University of Jyvskyl
63
SB
Program
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
University of Jyvskyl
64
SB
Program
DSM environment
University of Jyvskyl
65
SB
Program
Benefits of DSM
Benefits
Apply familiar terminology Solve the RIGHT problems! Solve problems only ONCE! model-driven reuse
SB
Program
Finished Product
Code
UML Model
No map!
Domain Model
Components
University of Jyvskyl
SB
Program
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)
University of Jyvskyl
68
SB
Program
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.
University of Jyvskyl
69
SB
Program
University of Jyvskyl
70
SB
Program
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)
University of Jyvskyl
71
SB
Program
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)
University of Jyvskyl
72
SB
Program
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)
University of Jyvskyl
73
SB
Program
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 -- (SEI, 2002) See previous two slides
University of Jyvskyl
74
SB
Program
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
University of Jyvskyl
75
SB
Program
Engineering
Lack of suitable component Lack of flexibility in potentially reusable components Lack of tools Lack of standard Cognitive barriers
Process support
University of Jyvskyl
76
SB
Program
Reuse technology current reuse support in ISD Current tools support for component reuse Research problem definition
University of Jyvskyl
77
SB
Program
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
University of Jyvskyl
78
SB
Program
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
University of Jyvskyl
79
SB
Program
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
University of Jyvskyl
80
SB
Program
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
University of Jyvskyl
81
SB
Program
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 methodin-house, and 38% (Hardy, Thompson et al. 1995) of organizations have developed their own method Lacks data transmission support between tools
University of Jyvskyl
82
SB
Program
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
University of Jyvskyl
83
SB
Program
Reuse technology current reuse support in ISD Current tools support for component reuse Research problem definition
University of Jyvskyl
84
SB
Program
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?
University of Jyvskyl
85
SB
Program
Research environment
Systematic reuse support is insufficient in MetaEdit+ Component is not clearly defined in both metamodelling level and model level, which hinders systematic reuse.
University of Jyvskyl
86
SB
Program
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
University of Jyvskyl
87
SB
Program
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)
University of Jyvskyl
88
SB
Theory building
Conceptual frameworks Mathematic models Methods
Program
System Development
Prototyping, Product development, Technology Transfer
Observation
Case studies, Survey studies, Field studies
Experimentation
Field experiments Lab experiments
SB
Program
Observation
University of Jyvskyl
90
SB
Program
Theory building
University of Jyvskyl
91
SB
Program
Systems development
University of Jyvskyl
92
SB
Program
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+
University of Jyvskyl
93
SB
Program
Experiments (Cont.)
Selecting a tool and a testing case Developing the testing case by using the selected tool
Preparing for a testing case
Experiment design
Pilot study
Designing the experiment
University of Jyvskyl
94
SB
Program
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
University of Jyvskyl
95
SB
Program
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
University of Jyvskyl
96
SB
Program
SB
Program
Q2: Component model Theory building, Chp 1, 3, 4, 5, 6 & 7 Prototyping, Laboratory experiment Q3: Needed facilities Prototyping, Chp 1, 5 & 7 Laboratory experiment
University of Jyvskyl
98
SB
Program
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.
University of Jyvskyl
99
SB
Program
SB
Program
Reuse Framework
101
University of Jyvskyl
SB
Program
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.
University of Jyvskyl
102
SB
Program
University of Jyvskyl
103
SB
Program
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.
University of Jyvskyl
104
SB
Program
3C Component model
University of Jyvskyl
105
SB
Program
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.
106
University of Jyvskyl
SB
Program
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.
University of Jyvskyl
107
SB
Program
The last chapter presents an empirical study of componentbased 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.
University of Jyvskyl
108
SB
Program
Conclusions
University of Jyvskyl
109
SB
Program
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.
110
University of Jyvskyl
SB
Program
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?
University of Jyvskyl
111
SB
Program
University of Jyvskyl
112