CS6201: Project description (Jan 2010)
Last changed: Sunday, December 06, 2009
This document provides hints for selecting your course project. It describes problems we address with XVCL, and a lifecycle for a typical project (i.e., analysis/development steps involved in a project). It also provides some more details for possible projects on .NET and JEE platforms.
In the project, you will do a case study in applying XVCL to support a small software Product Line (SPL). XVCL is a variation mechanism that helps you build SPL core assets that are then reused when developing custom products. You can also apply XVCL to eliminate clones in a single software product. Such non-redundant XVCL-based product representation simplifies maintenance. Finally, you can apply XVCL to manage variants in any kind of artifact (software or non-software) that is represented as text (e.g., WORD documents).
XVCL is an open source software developed at the Software Engineering Lab, NUS, available at http://xvcl.comp.nus.edu.sg . Be sure that you use XVCL Workbench, the download instructions are at the course home page.
It is up to you to define and scope the project. You are free to choose a problem, programming language, application domain, and define your own objectives for applying the XVCL. You can define your project based on one of the project types listed below, discussed in lectures or you can define yet another project. The best if you choose an application domain you are already familiar with or an easy one so that you spend minimum time on learning about the problem and maximum time on developing an XVCL solution for the problem and evaluating the results of your experiment. You can base your project on an existing program such as class library, public domain software (you must have access to the source code).
SPL: Software Product Line, a family of similar software products managed from a common set of reusable core assets
SPL core assets: all software artifacts that we reuse: code components, architecture, documentation, test cases
PLA: Product Line Architecture
SCM: Software Configuration Management
FRS: Facility Reservation System
It is important to understand how we position XVCL in the sea of development technologies available today (and more are coming all the time). Many technologies primarily focus on the development phase: standardized architectures and pattern-driven development (e.g., JEE, .NET) facilitate reuse of common service components; IDEs generate code from GUI. However, reuse of application domain-specific code and maintenance are usually poorly supported. XVCL comes to the picture as a technique complementing conventional OO and component-based technologies (therefore term mixed-strategy). XVCL makes it possible to position software components for reuse and long-term evolution. In our projects, we identify strengths and weaknesses of various technologies in respect to reuse and maintenance, and build mixed-strategy solutions to address weak areas.
Most of the projects with XVCL are comparative studies in which we (1) develop a software system (prototype) X using conventional techniques T, (2) convert X into a mixed-strategy solution T/XVCL (conventional technique enhanced with XVCL), and (3) evaluate engineering merits of each software solution.
The evaluation (3) is best done in both quantitative way,
using some metrics (size, complexity), and qualitative way. In qualitative
evaluation, we discuss problems that are caused/avoided by each of the
solutions. It is good to conduct a small experiment to evaluate, for example,
the effort to change each of the two software solutions.
No matter what platform, language and application domain you focus on, watch for the situations described in the following sub-sections. These situations usually complicate reuse and maintenance. Some of the problems can be rectified by applying XVCL on top of the programming technology you use.
Similar software structures (e.g., components/classes or configurations of them) arise in software for variety of reasons. If they cannot be unified to form generic representation using conventional techniques – you may try XVCL to do the job. Of course, you target at big enough and important software structures whose unification is beneficial.
We often observe explosion of similar classes in class libraries. Check Buffer library case study (on XVCL Web site and described in publications) to see why OO is not effective in avoiding the problem and how mixed-strategy solution with XVCL can solve the problem.
We often observe explosion of similar structures in a single program. For example, any Web Portal will contain many groups of similar pages.
In reuse-based development and long-term evolution, we
support many similar software systems that satisfy similar – but also somewhat
different- requirements. These similar systems are built of components that are
also similar to each other (they satisfy similar – but also somewhat different-
requirements). Despite much similarity among such multiple component versions,
current OO and component-based development technologies force developers to
create and maintain many similar versions of components.
Watch for situations when any kind similarity patterns arise, for whatever reason, as that’s often an opportunity to design generic, adaptable components with XVCL for ease of reuse.
Typically, XVCL generic component representation reduces complexity of programs by 60%. Sometimes – much more.
Another problem that creates a good opportunity for XVCL is fragmentation of application domain-specific functionality that hinders reuse and maintenance.
Modern platforms (such as .NET or J2EE, and web frameworks such as WebSphere on Ruby on Rails) encourage organizing software around standard architectures which allows programmers to reuse common services/components. Pattern-driven development style even further standardizes software structure. Not surprisingly, software developed in that way displays much similarity. For example, we found 61% of code contained in similar program structures replicated many times in variant forms in J2EE Web Portals, 60% in JEE database access layer and 60%-90% in ASP Web Portals.
Despite benefits during development, pattern-driven design may add complexity to future maintenance. It may also complicate reuse of the application domain-specific functionality. This is due to the following reasons: (1) patterns remain implicit in code - we may not know the exact location of pattern instances in a program, and how pattern instances are similar and different from each other, (2) when the pattern-related code is to be changed, it is not clear which of the pattern’s instances should be changed and how, and (3) application of patterns scatters code related to application-level functionality across many components (classes), which magnifies well-known problems of tracing requirements to code, and the impact of change, in general.
One important concept and construct is missing to fully exploit the benefit of design standardization. The missing concept is a strong enough mechanism for generic design that would allow us to represent and maintain similar program structures spawning from patterns in a generic, customizable form. Such generic representation should contain formal links to enable one to trace all its instances in a subject program, along with a detailed record of differences of each instance in respect to its generic representation. For complex patterns, one should be able to abstract similarities and structure a generic representation at as many levels of as it is required. It will further boost reuse levels and development/maintenance productivity if the process of injecting pattern instances into a program is automated. The mixed-strategy approach with XVCL is based on a mechanism for generic design that plays the above role in the context of programming languages and modern software platforms.
IDEs (Interactive Development Environment) are central in
most of today’s software development strategies. It is generally believed that
much productivity gains can come from improved IDEs. IDEs can save much development effort by generating code from WYSIWYG
editors. IDE’s automate routine development tasks and generators facilitate
reuse of code components of the underlying platform. IDEs are loved by
developers. Very successful solutions have been built with IDE’s and generators
in specific application domains. IDEs are very effective in rapid development
of small-medium size software. However, the history so far shows difficulties
to scale IDE approach as a general-purpose programming method. In particular,
IDEs poorly address reuse of application domain-specific code managed by
developers, and issues of long-term maintenance. Application-level
functionality gets scattered across the generated code and IDEs do not have
mechanisms to abstract such functionality for reuse. This fragmentation of code
makes future changes tedious as the impact of change propagates across many
components. Sooner or later, you modify generated code and once you disconnect
code from IDE – any further maintenance is done manually. Generated code is
often more difficult to maintain than hand-written code.
In the past, we have
done a study of JBuilder (a popular IDE for JEE). A student developed an
environment in which generic components were managed by XVCL and JBuilder was
used to work with custom components produced by the XVCL Processor. Other
students integrated XVCL into VS 2005.
You can bring in IDEs to your projects. You can focus the whole project on methodological aspects of using IDE and XVCL together. Below are pointers to free IDEs (from Sun Tech Days seminar):
A definite trend towards visual (code-less, drag and drop) programming: NetBeans (Sun's IDE that's competing with Eclipse), Java Studio Creator (IDE for Web UI programming), Java Studio Enterprise (IDE for enterprise applications) all have elements of visual programming. Oracle and SAP too have similar IDEs. Sun stressed that code we usually 'copy paste' are now automatically generated by these IDEs. However, they admitted that these tools do not solve the problem of maintaining such code (e.g., the problem of update anomalies is still there).
The remaining part of this document describes project types, typical project lifecycles, and project report contents.
Project Objective: to compare an existing program P/Original developed using conventional programming/design technique T (e.g., Java, C, C++, with application of OO inheritance, generics, design patterns, J2EE, .NET, etc.), and XVCL solution to the same problem, with respect to qualities such as genericity (non-redundancy), reusability or maintainability.
Typical steps in this project are as follows (these steps are further refined in Section on component platforms .NET, JEE etc., please refer to this Section later)
1. select a program (or part- of it) – an existing program (implemented by you or public domain) or a program that can be easily implemented
2. set up objective for creating mixed-strategy solution such as:
a) to create generic, reusable structures,
b) to unify clones for better maintainability,
c) to create understandable, changeable and maintainable structures (not necessarily via clone unification)
3. conduct the experiment
4. conduct comparative study between the P/Original and P/XVCL solution
5. document the results and lessons learned.
The purpose here is to build an XVCL mixed-strategy solution that is non-redundant, easier to maintain than equivalent program written in one of the existing programming languages.
Emulate the case study on the Buffer library or STL (see code solution at XVCL web site).
For example, an experiment on the Buffer library shows how XVCL can simplify design of class libraries. It also shows how XVCL can be effectively applied on top of OO techniques, enhancing program maintainability and reusability.
In class libraries we find much redundant code among classes that, in essence, differ very little. Such redundancies lead to overly complex and big classes, creating well-known problems for program maintenance. In this experiment, we analyzed redundant code in the Java Buffer class library. We designed an x-framework for the Buffer library in which we isolated redundant code fragments into proper x-frames. Our Buffer x-framework comprises 32% of code we find in the original Buffer library, taking into account both Java code and XVCL commands in x-frames.
You can choose another class library (written in any programming language - Java, C++, Eiffel, etc.) or any program that is available to you (e.g., a program that you wrote or public domain software). You can also develop a simple prototype for the problem that you feel will expose similarity patterns that can be simplified with XVCL. Then, develop an XVCL solution to generate the same program from a smaller and simpler base of code (x-framework). Be sure that you set up clear goals to be achieved by the XVCL solution.
It may be interesting to look into .NET Systems.Collections Library http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemcollections.asp
released by Microsoft (Check IEEE Computer November 2003 "Uncovering hidden contracts: the .NET example").
There may be many variants of this project, depending on the library/program you choose and on the objectives to be achieved. For example, in the Buffer library case study, we generate Buffer classes in their original form from the x-framework. We could also built an x-framework to generate optimized classes providing exactly the same functionalities as original Buffer classes, but implemented in different way, for example, without inheritance.
Software Configuration Management (SCM) systems are traditionally used to mange changes in software. SCMs are also used to support product lines. In this project, you will compare SCM and XVCL approaches to supporting product lines.
Consider Facility Reservation System (FRS) product line,
FRS-SPL and its architecture, FRS-PLA. FRS-SPL members differ in variant
features. For example, some FRSes allow users to
Traditionally, industry uses
Unlike SCM, XVCL can represent traces of changes penetrating the affected software in the form of explicit, operational and replicable change plans. Rather than storing many versions of source code files like SCM does, XVCL allows us to re-generate required versions on demand. Therefore, SCM and XVCL are two different approaches.
In this project, you will compare SCM and XVCL approaches. You will work out PLA for a problem of your choice (such as FRS) using SCM (one of the public domain tools such as CVS), and XVCL. You will analyze strengths and weaknesses of each solution, in respect to some of the problems summarized in SPL Problems. You will explore the overlap and synergy between SCM and XVCL, in areas of change management and collaborative work.
References for this project:
You may consider this tool for the project: RCE (a Window version of RCS: http://www.aicas.com/rce.html)
Template engines such as JET or Velocity contain capabilities overlapping with XVCL. In this project, you develop the same solution with XVCL and a selected template engine and compare the result, using certain quality criteria.
The following are the main activities in this type of a project:
1. Select the library/program you chose for the project.
2. State the objectives to be achieved by the XVCL solution, such as elimination of redundant code, reusability, ease of maintenance, ease of understanding, etc.
3. Work out initial project plan. You will work towards the solution in iterations, starting with small subset of the library/program you chose for the project. Sketch the general plan for the whole project and detailed plan for the first iteration.
4. X-framework development iterations:
a) In the first iteration, you frame a small subset of classes/program. For example, in the Buffer library, we created an x-framework to generate 7 Buffer classes at level 1.
b) For each subsequent iteration, extend the x-framework built so far. Make your iterations small and carefully select new classes (features) covered by extended x-framework.
c) An x-framework developed in each iteration must be properly tested – you should generate a program from the x-framework and run it.
d) An x-framework developed in each iteration must be properly documented.
5. Analysis of results
a) clarify evaluation criteria and evaluation method (metrics and qualitative analysis)
b) discuss strengths and weaknesses of P-Original and P-XVCL
c) point to inefficiencies in each solution (if any) as compared to the other solution, for example:
i) a type of redundancy that occurs in P-Original but need not occur in P-XVCL
ii) a problem that impedes understanding P-XVCL but does not occur in P-Original, etc.
6. Write the Final Project Report
1. Project objective and scope. Describe the library/program you chose for the project.
2. Objectives to be achieved by the XVCL solution, such as elimination of redundant code, reusability, ease of maintenance, ease of understanding, etc.
3. Initial project plan and schedule
4. Project lifecycle: describe the major development activities
a) for each development iteration (including the final x-framework you developed):
i) describe classes (or program subset) you can generate from the x-framework
ii) write technical documentation of the x-framework. This should include statistics such as the number of x-frames, LOC written in the base language, total number of XVCL commands embedded in x-frames, etc.
iii) compare the original classes/program with the XVCL solution (see the Buffer library case study for examples how this can be done)
5. Summary of project experiences, lessons learned
Students who chose this project should be already familiar with the platform.
The project should focus on applying XVCL in synergy with the mechanisms offered by the platform. here are examples of goals to be achieved by the “mixed strategy solution” :
1. using XVCL to design “generic components”
2. using XVCL to simplify pattern-driven development.
The first goal is similar to case studies on Buffer library, STL and Web Portals in which similar program structures (components) have been unified with generic meta-level structures.
Below, I elaborate more on applying XVCL in the context of pattern-driven development.
Enterprise patterns in .NET: http://www.microsoft.com/downloads/details.aspx?FamilyId=3C81C38E-ABFC-484F-A076-CF99B3485754&displaylang=en
Enterprise patterns
in J2EE: http://java.sun.com/blueprints/corej2eepatterns/Patterns/index.html
(go to Core J2EE Patterns Catalog link). There is a copy of this book in the science library. Core J2EE Patterns: Best Practices and Design Strategies Deepak Alur, John Crupi and Dan Malks Publisher: Prentice Hall / Sun Microsystems Press ISBN:0130648841; 1st edition (June 26, 2001)
The objective of this project is to explore the many ways XVCL can be used in synergy with .NET, JEE or other platform (or IDE available on a given platform), e.g., to further improve benefits of patter-driven development.
Different students can do this project on different platforms (.NET, J2EE, Ruby on Rails, PHP, etc.), or even on the same platform but addressing different aspects of pattern-drive development/maintenance.
Past research on Web Applications (WA) and other conventional software (class libraries and applications developed using a range of languages such as Java, C++, C#) has shown high rates of repetitions in software: On average, 60% of code was contained in clones, that is similar program structures (references in sections I and II describe empirical results and their analytical interpretations).
These similar program structures ranged from similar code fragments (so-called simple clones) to large program formations comprising patterns of collaborating classes/components (so-called structural clones). Structural clones are of our prime interest in these projects.
Similarity inherent in the semantics of an application domain is one reason why we see so much similarity patterns in software. Design patterns – standard solutions to design problems, a standard way of organizing software - further magnifies the amount of repetitions at all granularity levels, from simple clones to patterns comprising large parts of code and forming meaningful units of design (architectural patterns). Examples of patterns that are useful in OO design are described in Gang of Four (GoF) book and many other design pattern books. GoF design patterns have mainly educational value - describe proven, good design solutions, or how to organize software at the architecture level, e.g., MVC - but they are difficult to automate as these patterns are very abstract: There is so much variation in how the same design pattern must be instantiated in different program contexts, that defining such patterns in generic, reusable form is hardly possible. There is not enough similarity across pattern instances to talk about automation of pattern application or pattern reuse.
Modern development platforms such as .NET, J2EE, Ruby on Rails, etc. offer standardized architectures and libraries of enterprise patterns. Enterprise patterns are platform-specific and involve both concrete classes/components provided by the platform and abstract classes that must be customized to a context of a given program. Development platforms provide mechanisms (e.g., IDE’s such as VS2005 in .NET or scripts in Ruby on Rails) to help programmers apply patterns during software development. Many such patterns allow programmers to reuse standard functions. Enterprise patterns provide more reuse opportunity and benefit than general GoF patterns.
Benefits of pattern-driven development is that you need not develop solutions from scratch. Programs developed in patter-driven way are simpler: as solutions to similar problems are designed in a similar way, so it is easier to understand them. By applying patterns, we can increase productivity and also achieve uniformity and standardization of design. Pattern-driven development is a promising trend, opening new ways of thinking about software development.
By standardizing solutions, patterns inevitably further increase the amount of recurring similarity patterns in software. Indeed, much structural clones is found in software developed on component platforms such as .NET, J2EE, and using Web technologies such as PHP.
No doubt, pattern-driven development can improve productivity, and leads to desirable standardization and uniformity of software design. At the same time, pattern-driven practice is bound to result in software full of similarity patterns.
1) Patterns represent concepts or design solutions of different type and granularity.
2) Patterns must be customized to create pattern instances that fit given program situations in which pattern is applied.
3) Pattern instances may differ one from another in arbitrary ways: sometime the difference maybe small and required customization simple (e.g., small changes in method implementation across pattern instances); sometimes the difference may be big and require much customization (e.g., classes involved in pattern instances may be different).
4) Pattern instances may functionally or structurally dependent one on another:
a) functional dependency: the way we customize one pattern may affect required customizations of other patterns
b) structural dependency: one pattern instance may be contained in another pattern instance or pattern instances may overlap each other.
5) Suppose we have customized a given pattern X in many different ways creating pattern instances: X1, …, X10. When we create a new instance X11, it may be that X11 is very similar to, e.g., X6, or is a combination of X4 and X7: how do we maintain this knowledge to make future customizations as easy as possible? How do we maintain the knowledge of similarities and differences across pattern instances?
The VS2005 .NET (and other tools) supports some level of pattern automation – does it address the above problems? As XVCL could address some of the above problems, we can look for improvements as follows:
1) study how programmers apply patterns during development and how IDEs (e.g., VS2005 for .NET) and other tools help programmers apply patterns
2) identify strengths and weaknesses of the above
3) use XVCL to automate application of patterns during software development
a) wrap patterns in XVCL x-frames for ease of customization: define patterns in “generic form” (i.e., patterns wrapped into XVCL structures) and provide a mechanism to instantiate patterns in the many specific forms needed in systems we build.
b) wrap pattern combinations in x-frames for ease of customization
4) experiment with the above using VS2005 enhanced with XVCL (by Anup)
While patter-driven development can boost productivity during development and also leads to standardized design and code, it does not avoid old problems haunting software maintenance. Changes (triggered by bug fixes or enhancements) affect different parts of the program. To implement change, we may need modify different instances of the same pattern in different ways. However, the knowledge of where pattern instances are located in a program (for some patterns), and how pattern instances differ one from each other is implicit. Traceability of information is poor. In particular, to trace the impact of change a programmer must repeatedly analyze design and code and recover the same program information all over again. While application of patterns standardizes code, it also leads to bigger code size that hinders the process of manual program analysis. To implement a change in requirements, a programmer may need modify many program points and trace the impact of change.
Question: To what extend IDE’s and other tools of modern platforms (.NET, J2EE, Ruby on Rails) can help in maintenance of software developed in pattern-driven way?
XVCL solution to the above problem is a mixed-strategy solution. We try to represent patterns in generic form as XVCL meta-structures (x-frames). Each instantiation of a pattern in a program is recorded as a meta-structure, showing exact differences (deltas) of a pattern instance from the generic pattern. As patterns are instated during the development, the meta-structures show the exact locations of instances and similarities/differences among them.
All the future maintenance is done via mixed-strategy solution that is formed by meta-structures and code.
1. Select the platform understand basic mechanisms, architecture, design patterns.
2. Select application for experimentation.
3. Decide about objective for your project, that is specific aspect of patter-driven development to study.
4. Perform experiment
a) Assess pattern-driven development as supported by platform/IDE of your choice.
b) Propose XVCL extensions.
c) Develop the same (small) application using the platform/IDE mechanisms only (called ORG) and with XVCL extensions (called ORG-XVCL)
5. Evaluate the proposed solution by comparing ORG vs. ORG-XVCL in respect to simplicity, changeability, genericity (non-redundancy), and reusability, in the following ways:
a) compare product qualities using metrics (e.g., size, complexity)
b) compare process qualities (e.g., development and maintenance effort)
c) e.g., set up an experiment to enhance a ORG and ORG-XVCL in the same way. Based on that estimate the effort to accomplish the task in each of the two representations. Compare the number of modifications and the difficulty to implement them in each of the two representations. Based on that estimate the effort to accomplish the task in each of the two representations.
d) as the focus of the project is on patter-driven development, we’ll see what kind of evaluations are appropriate once the essence of experiment is better understood.
The number of variant requirements and their legal combinations may be huge, giving raise to many similar SPL members. The role of the PLA is to allow developers to derive all the SPL members in a fast and easy way (see SPL Problems for a list of practical problems a PLA must address). The challenge in PLA design is to understand the impact of changes triggered by different variants.
If you want to do project of this type but cannot come up with your own problem definition - you can develop an x-framework for FRS. Just scope your project definition based on the Lecture Notes and FRS Description). Warning - FRS project is not likely to win you the highest grade.
Typical steps in this project are as follows:
1. Domain analysis: Analyze and model common and variant requirements for the product line.
2. Scope the product line: decide which common and variant requirements you will implement within the x-framework
3. Write an initial project plan and schedule
4. Define the scope of a default system and develop a prototype for a (subset of the) default system. The default system should contain common and some of the variant requirements that occur in most of the product line members.
5. Develop an x-framework for the product line incrementally.
a) In the first iteration, you frame the default system to cater for some variants.
b) In each subsequent iteration, you extend the x-framework developed so far by implementing more functionality into it (that is extending the default system) and/or by addressing some new variants.
c) An x-framework developed in each iteration must be properly tested – you should generate a couple of product line members with various combinations of variants, compile and run generated systems.
d) An x-framework developed in each iteration must be properly documented – describe what common and variant requirements the x-framework developed so far caters for.
6. Write the Final Project Report
1. Project objective and scope
2. initial project plan and schedule
3. Domain model
a) describe common and variant requirements in the domain of your choice. Try to use diagrams (e.g., UML) and conventions explained in the class.
b) your domain model may be a superset of requirements that you actually implemented in the x-framework. Indicate which common and variant requirements you actually implemented in your x-framework for the product line.
4. The default system
a) describe common and variant requirements in your default system
5. Project lifecycle: describe the major development activities
a) building a prototype and default system (in case they are different)
b) for each development iteration (including the final x-framework you developed):
i) describe common and variant requirements implemented in the x-framework; characterize systems - product line members – that you can generate from the x-framework
ii) write technical documentation of the x-framework. This should include statistics such as the number of x-frames, LOC written in the base language, total number of XVCL commands embedded in x-frames, etc.
iii) list systems - product line members – that you actually generated from the x-framework to test the x-framework
6. Summary of project experiences, lessons learned
You are free to define a project on your own. I will be happy to discuss with you initial ideas in case you wanted to use XVCL in an innovative way.
1. Download XVCL processor and XVCL Specifications from XVCL web site. This site also contains XVCL specs, examples, demos, case studies, white papers, etc.
2. Download XVCL Workbench (instructions on the course home page).
3. Read XVCL Tutorial. I will conduct XVCL briefing during initial lectures.
4. Browse through the XVCL Web site
5. Go through Case Studies (Web site), especially Buffer library study shows steps to develop XVCL/Java mixed-strategy solution in a sequence of tutorial-like steps.
6. Read relevant chapters from Effective Software Maintenance and Evolution , some chapters you can download from “Readings for the course” provided on the course Web site.