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

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 – 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

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 ReuseConceptual 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 • 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

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. Mapping TS Implementation Reverse Conceptulization FOD 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. 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 How can we think of systems development? (Cont.)

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 ... Computer Engineering 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 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

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