LOUISIANA TECH UNIVERSITY ABSTRACT: Agile modeling (AM) is a practice-based methodology for effective modeling and documentation of software-based systems. It is a collection of values, principles and practices for modeling software that can be applied on a software development project in an effective and light weight manner. In this paper we have discussed the goals and the scope of Agile Modeling. But our main emphasis in this paper is on the two approaches to software development namely, Agile Model-Driven Development (AMDD) and Test-Driven Development (TDD). A brief introduction of Test-Driven Database Development is also given. We have also presented the steps involved in both the software development approaches and compared them. Keywords: Agile Modeling, Agile Model-Driven Development, Test-Driven Development, Test-Driven Database Development.
Introduction: Agile modeling is not a perspective process; instead it provides advice of how to be effective as a modeler. A model is an abstraction that describes one or more aspects of a problem or a potential solution addressing a problem. An agile model is a model that is just barely good enough. The two fundamental reasons to create a model may be to understand an issue or to communicate what your team is doing. Agile models are understandable, sufficiently accurate, consistent, detailed, as simple as possible and fulfill their purpose. AM is a supplement to existing methods, it is not complete. To the success of our modeling efforts Active stakeholder participation is critical because they know what they want and provide you with the right feedback. AM is a way to work together effectively to meet the needs of project stakeholders.
Values: The agile modeling adopts and extends the values of extreme programming. Its values include communication, simplicity, feedback, courage and humility. The key factors for modeling success include proper communication between the customers and the software developers. This will lead to the proper understanding of the requirements of customers in the requirements modeling phase. This should also lead to the simplest possible solution that meets to the needs of all stakeholders. We should obtain regular feedback on the work we do and should have courage to make and stick to the decision made. We should also admit with humility that we may not everything and let others add value to our project efforts.
Assume simplicity while modeling.
Embrace changes while you are working as requirements do change over time.
Incrementally change your system to enable agility.
Obtain rapid feedback to ensure that your work reflects the need of project stakeholders.
Model with a purpose and need multiple models for your development to be effective.
Content is more important than representation
To be an effective modeler you need to know your tools and know your models.
To be an effective teammate work with people’s instincts and for effective teamwork open and honest communication is often the best policy.
To define and show how to put into practice, the collection of values, principles and practices, pertaining to effective and light weight agile modeling.
To address the issue of how to apply modeling techniques on a software projects taking an agile approach such as eXtreme Programming (XP), Dynamic Systems Development Method (DSDM), or SCRUM.
To address the issue of how to model effectively on a Unified Process (UP) project, common instantiations of which include the Rational Unified Process (RUP) and Enterprise Unified Process (EUP).
The Scope of Agile Modeling: Agile modeling is not a complete software process; it focuses only on effective modeling and documentation. It does not include programming activities and testing activities although, it tell us to prove our models and to consider testability as we model. It also doesn’t cover project management, system deployment, system operations, system support, or a myriad of other issues. Therefore AM focuses only on a portion of the overall software process and we need to use it with another, full fledged process such as XP, DSDM, SCRUM, or UP as indicated by the goals of AM. As shown in the figure 1 we start with a base process, such as XP or UP or perhaps any of our existing process, and then tailor it with AM (hope fully adopting all of AM) as well as other techniques as appropriate to form our own process that reflects our unique needs.
Figure1. AM enhances other software processes.
Agile Model-Driven Development (AMDD): An approach to software development where extensive models are created before source code is written is called Model Driven Development (MDD). An example of MDD is the Object Management Group (OMG)’s Model Driven Architecture (MDA) standard. It often takes a serial approach to development and is quiet popular with traditionalists, although as the RUP/EUP shows that it is possible to take an iterative approach with MDD.
The agile version of MDD is called Agile Model Driven Development (AMDD). The difference with AMDD is that in this instead of creating extensive models before writing the source code we create agile models that are simple and barely good enough.
Now let us see the high-level life cycle for AMDD for the release of a system. As shown in figure 2 each box represents a development activity. The initial modeling activity includes two main sub-activities, initial requirement modeling and initial architecture modeling. These are done during cycle-0, cycle being another term for iteration. Cycle-0 is an XP term which indicate the first iteration before we start into development cycles, where there are iterations one and beyond. The other activities of AMDD life cycle include detailed modeling, reviews and implementation. Potentially these activities occur during any cycle or during cycle-0. The length of an average session of each activity is included in each box by time.
Figure2: The AMDD lifecycle.
Initial Modeling: The initial modeling effort is typically performed in the first week of our project and do not invest much time in this phase as this may lead to the danger of over modeling and of modeling something that contains too many problems. For the first release of a system we need to identify some high-level requirements and the scope of the release. Our main goal is to get a good idea of what our project is all about. Depending on our underlying process-RUP, XP, or FDD we may decide to represent our systems requirements as a collection of essential use cases, or user stories, or perhaps collection of features respectively. The goal of initial architectural modeling is to try to identify an architecture that has good chances of working and in later cases both the initial requirement and architect models can evolve or shorten as we learn more, or even removed if the situation demands.
In this process explore the requirements or design in a more detailed manner. Using evolutionary approach typically work on a handful of requirements in each development cycle. To analyze the requirements we are currently working, discuss about them with the stakeholder or with several other developers and sketch out an approach to implement a requirement. Our initial requirements and architecture models will evolve only through detailed modeling and implementation efforts.
Implementation: Implementation is where most of the time is spent. During development after completion of detailed modeling, coding is performed following common coding practices such as Test-Driven Design (TDD) and refactoring. During detailed modeling we think through larger, cross-entity issues whereas with TDD we think through much focused issues that are typically pertinent to a single entity at a time. With refactoring we evolve with a design via small steps that ensure that our work is of high quality. So in a development team we need people who are equally skilled in more specialties as well as those who have general skills in the entire life cycle, who can both code and model as well.
How is AMDD different? From the design point of view AMDD approach is different from the traditional approach where we first create a design model and then code from it. With AMDD approach we do a little bit of modeling and then a lot of coding, iterating back when you need to. So the design efforts are now spread out between the modeling and coding activities, with the majority of design being done as part of our implementation efforts. But in many ways this was also true for many traditional projects.
AMDD doesn’t specify the type of model(s) to create so it is different from techniques such as FDD or the use case driven development (UCDD) styles of EUP and ICONIX. AMDD suggests applying the right artifact but it doesn’t insist on what that artifact is. For example FDD insists that features are our primary requirements artifact whereas UCDD insists that use cases are. AMDD works well with both an FDD and a UCDD approach because the messages are similar. On the whole all the three approaches say that it’s a good idea to model before coding.
Test –Driven Development (TDD): Test–driven development is also known as test-first programming or test-first development. It is an evolutionary approach to development where you first write a test that fails before you write new functional code. There are many views regarding the goal of TDD, one view is that TDD is specification and not validation, another view is that it is a programming technique and other says that its goal is to write a clean code that works. Test-driven development (TDD) is a development technique where you must first write a test that fails before you write new functional code. TDD is being quickly adopted by agile software developers for development of application source code and may soon be adopted by Agile DBAs for database development.
As shown in figure 3 the various steps in TDD are overviewed using UML activity diagram. The first step is to quickly add a test that has basically enough code to fail. Next step is to run our tests, often we do only a subset though we can perform completely to ensure that the new test does in fact fail. Then we update our functional code and make it such that it passes the new tests. The fourth step is to run our tests again. If the test fails then we need to update our functional code and retest else if the tests pass the next step is to start over.
Figure 3. Steps of TDD.
TDD is quiet opposite to traditional development where we write our functional code and then write our test code. But in TDD we write our test code before functional code and moreover we do this in small steps with one test and a small bit of corresponding functional code at a time. A programmer using this TDD approach will never add a new function unless there is a test that fails just because of the absence of this function. In fact addition of single line of code is not accepted unless there is a test for it. An underlying assumption of TDD is that we have a unit-testing framework available.
Kent Beck is the person who popularized TDD in eXtreme Programming and he defines two simple rules for TDD. First is to write a new business code only when an automated test has failed and the second is to eliminate any duplication that we find.
Test-Driven Database Development: Within the agile community an important question that arises in this topic is that “can TDD work for data –oriented development”. But if you look at the process as shown in fig-3 there is no step that specifies object programming languages, such as java or c#,
even though TDD is usually used in these environments. Then why couldn’t we test before making a change in database scheme? Or why couldn’t we make a change, run the test and refactor the schema as required.
It is assumed that in near future TDD database wont work as smoothly as application TDD. The first challenge in this is tool support. Although unit testing tools such as DBunit are available they are still emerging techniques. Even though DB analysts are improving the quality of testing, there are very less cases where a TDD approach is used in database development. One challenge is that unit testing tools are still not well accepted with in data community, although it is changing and database TDD is expected to grow in near future. Second the concept of evolutionary development is new to many database programmers and there is a little motivation to take TDD approach. Third, most people who perform data-oriented work seem to prefer a model-driven and not a test-driven approach.
Comparision of TDD and Agile Model-Driven Development (AMDD):
TDD shortens the programming feedback loop whereas AMDD shortens the modeling feedback loop.
TDD provides detailed specification (tests) whereas AMDD can provide traditional specifications (data models).
TDD promotes the development of high-quality code whereas AMDD promotes high-quality communication with your stakeholders and other developers.
TDD provides concrete evidence that your software works whereas AMDD supports your team, including stakeholders, in working toward a common understanding.
TDD “speaks” to programmers whereas AMDD speaks to data professionals.
TDD helps to ensure that your design is clean by focusing on creation of operations that are callable and testable whereas AMDD provides an opportunity to think through larger design/architectural issues before you code.
TDD is non-visually oriented whereas AMDD is visually oriented.
Both techniques are new to traditional developers and therefore may be threatening to them.
Both techniques support evolutionary development.
People who are primarily visual thinkers use AMDD approach and others who are primarily text oriented or non-visual prefer a TDD approach. But we can use both the techniques together to gain the advantages of both. AMDD should be used to create models with your project stakeholders to help explore their requirements and then to explore those requirements sufficiently in architectural and design models. TDD should be used as a critical part of your build efforts to ensure that you develop clean, working code. The end result is that you will have a high-quality, working system that meets the actual needs of your project stakeholders.
By the study of AMDD and TDD, comparison of them concludes that TDD should be seen as complementary to Agile Model-Driven Development (AMDD) approaches and the two can and should be used together. TDD does not replace traditional testing, instead it defines a proven way to ensure effective unit testing. A side effect of TDD is that the resulting tests are working examples for invoking the code, thereby providing a working specification for the code. TDD works incredibly well in practice and it is something that all agile software developers should consider adopting. And from the design point of view AMDD is different from traditional development approaches but still leads to an effective modeling approach.
An essay by Scott Ambler from the Object Primer 3rd edition: Agile Modeling Driven Development with UML2. http://www.agilemodeling.com/ essays/amdd.htm,. http://www.osellus.com/seminar/1a.pdf
By RobinF.Goldsmith and DorothyGraham October 2002http://www.gopromanagement.com/PDF/10sd.Gold52-53.pdf,
XP with Acceptance-Test Driven Development: A rewrite project for a resource optimization system Johan Andersson, Geoff Bache, and Peter Sutton Carmen Systems
http:/ Agile Development Tools for Test-DrivenDevelopment with Java Dr. Armin R¨ohrlStefanSchmiedl a ¡ s ¢ @approximity.com http://www.approximity.com November2002...www.approximity.com/public/papers/tddwjax.pdf
Christel, M.G. & Kang, K.C. (1992). Issues in Requirements Elicitation. Software Engineering Institute (SEI) Technical Report CMU/SEI-92-TR-12. www.sei.cmu.edu , http://www.sei.cmu.edu/pub/documents/sei.documents.pdf
Agile Alliance (2001b). Principles: The Agile Alliance. www.agilealliance.org/principles.html
2nd OOPSLA Workshop on Generative Techniques in the context of
Model Driven Architecture http://www.softmetaware.com/oopsla2003/melia.pdf