@techreport {25331,
	title = {A Systematic Review on the Effects of UML during the Maintenance of Object-Oriented Software},
	year = {2009},
	publisher = {Simula Research Laboratory},
	author = {Dzidek, James and Arisholm, Erik and Lionel C. {Briand}}
}
@phdthesis {Simula.SE.581,
	title = {Empirical Evaluation of the Costs and Benefits of UML in Software Maintenance},
	year = {2008},
	month = {July},
	school = {Department of Informatics, University of Oslo},
	type = {phd},
	isbn = {1501-7710},
	author = {Dzidek, James}
}
@article {Simula.SE.120,
	title = {A Realistic Empirical Evaluation of the Costs and Benefits of UML in Software Maintenance},
	journal = {IEEE Transactions on Software Engineering},
	volume = {34},
	number = {3},
	year = {2008},
	month = {May},
	pages = {407-432},
	abstract = {The Unified Modeling Language (UML) is the de facto standard for object-oriented software analysis and design modeling. However, few empirical studies exist that investigate the costs and evaluate the benefits of using UML in realistic contexts. Such studies are needed so that the software industry can make informed decisions regarding the extent to which they should adopt UML in their development practices. This is the first controlled experiment that investigates the costs of maintaining and the benefits of using UML documentation during the maintenance and evolution of a real, non-trivial system, using professional developers as subjects, working with a state-of-the-art UML tool during an extended period of time. The subjects in the control group had no UML documentation. In this experiment, the subjects in the UML group had on average a practically and statistically significant 54\% increase in the functional correctness of changes (p=0.03), an insignificant 7\% overall improvement in design quality (p=0.22) - though a much larger improvement was observed on the first change task (56\%) - at the expense of an insignificant 14\% increase in development time caused by the overhead of updating the UML documentation (p=0.35).},
	doi = {10.1109/TSE.2008.15},
	author = {Dzidek, James and Arisholm, Erik and Briand, Lionel}
}
@techreport {Simula.SE.161,
	title = {A Realistic Empirical Evaluation of the Costs and Benefits of UML in Software Maintenance},
	number = {2007 - 04},
	year = {2007},
	month = {September},
	publisher = {Simula Research Laboratory},
	address = {Oslo, Norway},
	abstract = {The Unified Modeling Language (UML) is the de facto standard for object-oriented software analysis and design modeling. However, few empirical studies exist that investigate the costs and evaluate the benefits of using UML in realistic contexts. Such studies are needed so that the software industry can make informed decisions regarding the extent to which they should adopt UML in their development practices. This is the first controlled experiment that investigates the costs of maintaining and the benefits of using UML documentation during the maintenance and evolution of a real, non-trivial system, using professional developers as subjects, working with a state-of-the-art UML tool during an extended period of time. The subjects in the control group had no UML documentation. In this experiment, the subjects in the UML group had on average a practically and statistically significant 54\% increase in the functional correctness of changes (p=0.03), an insignificant 7\% overall improvement in design quality (p=0.22) - though a much larger improvement was observed on the first change task (56\%) - at the expense of an insignificant 14\% increase in development time caused by the overhead of updating the UML documentation (p=0.35).},
	author = {Dzidek, James and Arisholm, Erik and Briand, Lionel}
}
@inbook {Dzidek.2006.1,
	title = {Lessons Learned From Developing a Dynamic OCL Constraint Enforcement Tool for Java},
	booktitle = {Satellite Events at the MoDELS 2005 Conference: MoDELS 2005 International Workshops OCLWS, MoDeVA, MARTES, AOM, MTiP, WiSME, MODAUI, NfC, MDD, WUsCAM, Montego Bay, Jamaica, October 2-7, 2005, Revised Selected Papers},
	series = {Lecture Notes in Computer Science, Vol. 3844},
	year = {2006},
	month = {January},
	pages = {10-19},
	publisher = {Springer},
	organization = {Springer},
	abstract = {Analysis and design by contract allows the definition of a formal agreement between a class and its clients, expressing each party{\textquoteright}s rights and obligations. Contracts written in the Object Constraint Language (OCL) are known to be a useful technique to specify the precondition and postcondition of operations and class invariants in a UML context, making the definition of object-oriented analysis or design elements more precise while also helping in testing and debugging. In this article, we report on the experiences with the development of ocl2j, a tool that automatically instruments OCL constraints in Java programs using aspect-oriented programming (AOP). The approach strives for automatic and efficient generation of contract code, and a non-intrusive instrumentation technique. A summary of our approach is given along with the results of an initial case study, the discussion of encountered problems, and the necessary future work to resolve the encountered issues.},
	isbn = {3-540-31780-5},
	author = {Dzidek, James and Briand, Lionel and Labiche, Yvan},
	editor = {Bruel, Jean-Michel}
}
@inproceedings {Briand.2005.1,
	title = {Instrumenting Contracts With Aspect-Oriented Programming to Increase Observability and Support Debugging},
	journal = {21st IEEE International Conference on Software Maintenance (ICSM), Budapest, Hungary, September 25-30},
	year = {2005},
	note = {Use of the attached PDF is subject to the IEEE terms found here: http://www.computer.org/portal/pages/csdl/content/Terms.html},
	pages = {687-690},
	publisher = {IEEE},
	type = {Conference},
	abstract = {Analysis and design by contract allows the definition of a formal agreement between a class and its clients, expressing each party{\textquoteright}s rights and obligations. Operation contracts and class invariants are known to be a useful technique to specify the precondition and postcondition of operations and the legal states of class instances in an object-oriented context, making the definition of object-oriented analysis or design elements more precise. Furthermore, it is also useful to check such contracts and invariants at run time in order to help testing and debugging during corrective maintenance. Indeed, experiments report a substantial gain when relying on instrumented contracts during those two activities. However, the instrumentation of such contracts is a time consuming activity. In this paper we report on how Aspect-Oriented Programming (AOP), using AspectJ, can be employed to automatically and efficiently instrument contracts and invariants in Java. The paper focuses on (1) the AspectJ templates to instrument preconditions, postconditions, and class invariants, (2) the necessary instrumentation for compliance-checking to the Liskov Substitution Principle.},
	isbn = {0-7695-2368-4},
	author = {Briand, Lionel and Dzidek, James and Labiche, Yvan},
	editor = {IEEE Computer {Society}}
}
@misc {Dzidek.2005.2,
	title = {Visual Struts: Modeling Struts-Based Applications Using UML and Advanced Tool Support},
	howpublished = {JavaZone website},
	year = {2005},
	month = {September},
	abstract = {The Jakarta Struts framework is the de facto standard for web applications development in Java. Unfortunately, one of the primary difficulties with Struts-based development is that a lot of relationships are defined in a declarative manner, which leads to errors not being found at compilation-time. Furthermore, the system is developed in three different types of files: Java class files, Java ServerPages (JSPs), and XML configuration files. It is difficult to comprehend how these relationships interact, both, statically and dynamically (especially for a person not involved with the original development of a system). Modeling can greatly help in the understand of these relationships: (1) From a static point of view, page flow diagrams show how JSPs, user-defined classes, and Struts constructs (e.g. action mappings) relate (e.g. shows which JSP uses which action mapping); and (2) From a dynamic point of view, sequence diagrams show when/how specific action objects are invoked and when/how objects are placed in a scope. The technique discussed in this session has been discussed with over twenty professional Struts developers and actively used by ten on a real-word project. The talk will also cover the advantages and disadvantages of proprietary (non-UML based) Struts tools, mainly M7{\textquoteright}s NitroX for Eclipse.},
	author = {Dzidek, James}
}
@misc {Dzidek.2004.1,
	title = {Automated Contract Driven Development With UML{\textquoteright}s OCL},
	howpublished = {JavaZone website},
	year = {2004},
	month = {September},
	abstract = {Design by Contract (DbC) allows for more powerful assertions since with the DbC framework assertions take the form of preconditions, postconditions, and class invariants. Preconditions specify something that must be true before a specific method executes, postconditions specify something that must be true after a specific method executes, and class invariants state something that must be true within a context of a specific class before and after any public method belonging to class executes. For example, in a Person class we may want to specify the invariant that the age attribute is never negative. If this is ever broken we ask the system to let us know by, for example, throwing an unchecked exception. Developing software with such a framework allows for developers to build better software by organizing the communication between software elements through specifying, the mutual obligations and benefits that are involved in those communications, where the specifications are the contracts. The benefit of DbC is said to be better designed software with improved reliability where the documentation is better, the debugging is easier, and support for reuse is better. The DbC concept is taken further in UML via OCL as contracts are expressed in higher-order logic and the contracts can be specified during analysis.},
	author = {Dzidek, James}
}
@techreport {SE.7.Briand.2004,
	title = {Using Aspect-Oriented Programming to Instrument OCL Contracts in Java},
	number = {SCE-04-03},
	year = {2004},
	publisher = {Carleton University},
	abstract = {Analysis and design by contract allows the definitions of a formal agreement between a class and its clients, expressing each party{\textquoteright}s rights and obligations. Contracts written in the Object-Constraint Language (OCL) are known to be a useful technique to specify the precondition and postcondition of operations and class invariants in a UML context, making the definition of object-oriented analysis or design elements more precise. In this report, we introduce the ocl2j approach to automatically instrument OCL constraints in Java programs using aspect-oriented programming (AOP). One of the many possible applications of checking contract assertions at run time is to help testing and debugging. The approach strives for automatic, efficient generation of contract code and a nonintrusive instrumentation technique. It is assessed on a case study and initial results show that the approach is viable. We conclude by discussing strategies to optimize instrumentation so as to further decrease overhead.},
	author = {Briand, Lionel and Dzidek, James and Labiche, Yvan}
}
