An Exercise on XP with Extended Use Cases

Tong-Chun Xu
Department of Computing Science, The Kings University College, 9125 – 50 Street, Edmonton, AB T6B 2H3
tong.xu@kingsu.ca
Phone: (780) 465 3500, ext. 8026
Fax: (780) 465 3534

Nathan Laan
New Media Solutions Inc. 2809 31 Street, Edmonton, AB T6T 1V1
nathan@newmediasolutions.ca
Phone: (780) 454-8742
Fax: (780) 440-0267

Lisa Teigen
Student Life Office, The Kings University College 9125 – 50 Street, Edmonton, AB T6B 2H3
lisa.teigen@kingsu.ca
Phone: (780) 465 3500, ext. 8009
Fax: (780) 465 3534

Contents

Extended Abstract
    1. Introduction
    2. Participation of Clients
    3. Extended Use Case
    4. Discussion

      5. References


Extended Abstract

CMPT320 (http://turing.kingsu.ca/cmpt320/) is an introductory software engineering course offered at the King’s University College. The object of the course is to give students a sound understanding of the latest software engineering techniques used in industry. In the present study, some new teaching techniques are introduced, which were used with substantial success in enhancing student learning by:

In order to provide students with maximum hands-on experience, the help of an industry member and an actual client were enlisted to provide students with two projects that simulated real-life software engineering problems. These projects entailed designing a job bank and student-housing registry for the college’s student services (the client). Each student took on a specific position, such as case engineer or architect, and became an "expert" in that particular area. The industry member was the creator of New Media Solutions Inc. who joined the team as a SME and participated in many in-class discussions. The company is also currently employing a student as an intern.

Before beginning the project, the students were expected to learn all necessary introductory material pertaining to software engineering. These included aspects of the unified software (SW) development process, UML, PHP, design pattern in PHP, extreme programming (XP), and the ethical issues associated with software engineering. In addition, in accordance with students’ learning styles, a variety of visual demonstrations were developed along with intensive laboratory training, including a series of eight labs on PHP, which provided additional hands on experiences.

A very important aspect of the project was the use of PHP as the predominant language for instruction and coding. Though PHP is widely recognized in industry as a valuable programming tool, it is rarely been used as a teaching tool. However, due to its popularity as a scripting language, suitability for web development and incorporation into HTML, short learning curve, short development period, and high performance in supporting for popular databases, such as MySQL, it was a logical choice.

In addition, PHP has many characteristics that made it an advantageous language for students to learn:

However, some drawbacks of PHP include: no threads are available, thus no animations can be made through PHP.

Students with different backgrounds in computing languages all reported that PHP was extremely useful for this course. Many students found it an exciting language to use and appreciated the fact that it is an industry favorite. So much interest was generated, in fact, that several students asked for more problems and assignments on PHP even after the term was over!

Use case (UC) also proved to be a very important concept for students to grasp during the design process. UC should be at the forefront of user-centered software design process, however, it is often quickly passed over with no documentation on the cases excluded. Throughout the term, with the aid of the industry member, the discussion of applications of UML Use Cases, in particular, non-Use Cases was incorporated into project.

The following includes some of the problem-based discussions that involved non-UC.

Non-UCs are classified into three categories: negative, constrained, and design. Associated graphical notations are:
 
 
Negative
Constrained
Design

The "Negative Non Use Cases" is explained by the example of a non-profit group maintained a list of secondary and post-secondary teaching resources. Originally, this group wanted to create a database-driven web application to manage the list of resources with the ability to add text-based annotations to the database by the teachers. However, the basic testing showed that:

  1. There was no mechanism to validate users, nor was there the time or funds to do so. This meant that any user could add an annotation to a resource. This in turn meant that the system was open to abuse. Publishers of a particular resource could easily add positive annotations to their own resource, and negative annotations to their competitors resources.
  2. Searches for resources with one or more annotations were significantly slower than that with no annotations.
Based on the above, it was determined that adding resource annotations has a negative impact on the system, and thus had to be excluded.

The information Management System designed for a research-oriented company is taken as the example of "Constrained Non Use Cases". Three levels of information are in the system: basic information, annotations for the basic information, and advanced information. As a marketing strategy, the company has decided to restrict clients access up to the first two levels of information so that the advanced level of information is constrained.

The "job bank" project in this course provided an example of "Design Non Use Cases". In design, the case of "posting resume" has been described in use case analysis. But due to time limitations, the developing team was unable to accomplish this case. In documentation, this case is thus defined as "Design Non Use Cases".

The exclusion of Non-UC leads to monolithic, "bloated" software. Therefore, the three forms of Non-UC (Negative, Constrained, and Design) should be included in a proper UML documentation for a SW system. Such an extension of use case will not only encourage further design and development, but also prevent excessive "feature creep".

The client’s role in the project was very important as the students learned about the non-technical side of software engineering. Throughout the term, the students worked very closely with the client and engaged in numerous open dialogues. As the client pointed out, the art of dealing with people is an extremely important aspect of SW development. Learning to communicate with someone who is not a programmer, listening to what the client wants, and trying to meet those expectations help ensure success of a product. XP allowed the client to trial the program right away and in turn allowed the programmer to make immediate corrections. Thus, an essential aspect of the project was to have the programmer work very closely with the client.

Students as primary software developers felt that the projects were "enjoyable, educational and an eye opener in the whole software development process." Many noted that they gained "the confidence to face a client and discuss the product in terms of the client’s perspective". A major contribution to their comfort in having discussions with the clients arises from a thorough understanding and constant analysis of the project, in other words, correctly and thoroughly establishing use cases.

Several students reported that the pressures of having to produce a real life product exciting and rewarding. Excitement mainly arose from the opportunity to apply their knowledge in a very practical manner while being able to create a real-life product that will be very useful. In addition, the students were rewarded by their new-found knowledge and the gratefulness of the client (who was very pleased with the results).

Keywords

Aliasing, Non Use Cases (Non-UC), constrained Non-UC, design Non-UC, design pattern, Extreme Programming (XP), feature creep, graphical notations, graphics, learning styles, loosely typed language, negative Non-UC, OO Programming, Personal Home Page (also Hypertext Preprocessor, PHP), recursion, software engineering (SW), subject matter expert (SME), Unified Modeling Language (UML), Use Case (UC)

topcontents 

1. Introduction

The introductory software engineering (SW) course CMPT320 at The King’s University College (http://turing.kingsu.ca/cmpt320/) aims to give students a sound understanding of the latest software engineering techniques and process used in industry. In the recent session of the course, Extreme Programming (XP) was practiced with advanced uses of use-case method in the requirement elicitation, which resulted in substantial success in enhancing student learning.

XP has become popular as a valuable and practical software programming process among industry programmers. It is especially effective for small and intermediate sized projects. Its core values are simplicity, communication, feedback, and courage. Its methodology emphasises teamwork: "Managers, customers, and developers are all part of a team dedicated to delivering quality software" (see: http://www.extremeprogramming.org/)

The students were predominantly visual learners, thus, visual demo, laboratory exercises, and practising of methodology using small projects were used to enhance students’ learning. In addition, Xu enlisted the help of an industry member (Laan) and an actual client (Teigen) to provide students with two projects that simulated real-life software engineering problems. The projects entailed designing a job bank and student-housing registry for the college’s student services (the client). Each student took on a specific position, such as case engineer or architect, and became an expert in that particular area. A representative from New Media Solutions Inc. (Laan) joined the team as a SME and participant in in-class discussions. The company is also currently employs a student as an intern thus providing additional practical experience.

Both projects use PHP as the predominant language for coding. Though PHP is widely recognised in industry as a valuable programming tool, it is rarely used as a teaching tool. However, due to its popularity as a scripting language, suitability for web development and incorporation into HTML, short learning curve, short development period, and high performance in supporting for popular databases, such as MySQL, it was a logical choice.

In addition, PHP has many characteristics that made it an advantageous language for students to learn:

However, some drawbacks of PHP include: no threads are available, thus no animations can be made through PHP.

Students with different backgrounds in computing languages all reported that PHP was extremely useful for this course. Many students found it an exciting language to use and appreciated the fact that it is an industry favourite. So much interest was generated, in fact, that several students asked for more works on PHP even after the term was over!
topcontents 

2. Participation of Clients

The client’s role in the project was very important as the students learned about the non-technical side of software engineering. Throughout the course, the students worked very closely with the client and engaged in numerous open dialogues. The art of dealing with people is an extremely important aspect of SW development. Programmers have to learn how to communicate with someone, who is not a programmer and speaking their language, opposed to "programmer language". Be careful not to use so much technical language that your client becomes intimidated. Offer them options and suggestions, because they may not know the expanse of their possibilities.

Listening to what the client wants, and trying to meet those expectations help ensure success of a product. XP allowed the client to trial the program right away and in turn allowed the programmer to make immediate corrections. One draw back with these projects is that there is no opportunity for the client to experiment with the software in it’s completed stage, and then receive follow up help. Regardless, there was much learned by both the student and the client.

Several students reported that the pressure of having to produce a real life product exciting and rewarding. Excitement mainly arose from the opportunity to apply their knowledge in a very practical manner through being able to create a real-life product that will be useful. In addition, the new knowledge the students gained and a client pleased with the results, rewarded the students on this endeavour.

Students as primary software developers felt that the projects were "enjoyable, educational and an eye opener in the whole software development process." Many noted that they gained "the confidence to face a client and discuss the product in terms of the client’s perspective." Having access to the client allowed students to attain a better understanding and constant analysis of the project at hand, allowing them to correctly and thoroughly establish use case.

topcontents 

3. Extended Use Case
3.1 Introduction to Non-Use Case

Software engineering, as Schach (2005) indicates, is "a discipline whose aim is the production of fault-free software, delivered on time and within budget, that satisfies the client’s needs". Software Engineering, as implemented using the UML (Rumbaugh et al. 1999), is the process of determining the requirements and the implementation details for a software system. The current state of the UML-centered software design process undervalues Use Cases. In other words, Use Cases are not used with sufficient frequency or emphasis. While Use Cases ought to be in the forefront of the UML-centered software design process, they are often quickly passed over as Software Engineers move on to what they consider the real "meat" of the software design process. The underlying problem with this strategy is that it can lead to monolithic, "bloated" software. Present study poses a possible solution to this issue by introducing an extension to UML Use Cases called Non-Use Cases.

A Non Use Case (NUC), in its simplest form, is a Use Case that will not be included in the functionality of the software. NUCs were conceived in an effort to help constrain the design and development of a software system, preventing what is commonly referred to as "feature creep". The "feature creep" is a situation, in which features not included in the original design of the system are added later, which invariably lead to problems. Non Use Cases developed out of a need to design software with specific constraints. These constraints were required to limit the increasing functionality of the software.

Non-Use Cases were evolved, across several enterprise and educational trials, from the simple Negative NUC to their current state of three forms over a period of two years. Non-Use Cases originally used by Laan as part of the Modular Approach to Physics (MAP) project under Dr. Martin of The Kings University College. At that stage, the Non-Use Cases were informal, and were not diagrammed using any real standards or conventions. Subsequent to this, Non-Use Cases were put into full use by Laan during a project for Educational Media Technologies, and at New Media Solutions Inc. It is during this time that Non-Use Cases developed into the three current forms.

Due to recent practice of XP and a series of presentations given at The Kings University College, Non-Use Cases were applied by Xu and his Software Engineering students. During this time, the current standard for diagramming the three forms of Non-Use Cases has been formalized. Currently, Non-Use Cases are in use by Laan in the Junior High Math project at the Learning Technologies Branch of Alberta Learning under Mike Olsson.

topcontents 

3.2 Three Primary Forms of Non Use Case
 A Non Use Case (NUC), in its simplest form, is a Use Case that will not be included in the functionality of the software. A Non Use Case exists in one of three primary forms: Negative NUC, Constrained NUC, and Design NUC. Each of these forms fills a unique role as a NUC, and includes a unique attribute. Associated graphical notations are shown in Table 1.

Table 1 The NUC circles containing different boldface signs
 
Negative
Constrained
Design
topcontents 

 
 

Negative NUC

A Negative NUC is a Use Case that would have a measurable negative impact on the system as a whole or in part if it were included in the design specifications. The Negative NUC was developed out of the need to constrain the development process and limit the feature set of a software system.

In practice, a Negative NUC emerges during the initial design stage of a software system. Typically, a Negative NUC emerges when a Use Case is being considered in the context of the architecture for the software system.
 
 

Figure 1: Negative Non-Use Case

 As shown in Fig. 1, a Negative NUC is drawn as a standard Use Case, with a circle over the line connecting the actor to the Use Case. The circle contains a boldface negative sign, and may have a note attached to it.

Both the Educational Media Technologies and the Junior High Math project of the Learning Technologies Branch at Alberta Learning are taken as examples of Negative Non-Use Case.

In the project "Educational Media Technologies" a non-profit group maintained a list of secondary and post-secondary teaching resources. Originally, this group wanted to create a database-driven web application to manage the list of resources with the ability to add text-based annotations to the database by the teachers. However, the basic testing showed that:

  1. There was no mechanism to validate users, nor was there the time or funds to do so. This meant that any user could add an annotation to a resource. This in turn meant that the system was open to abuse. Publishers of a particular resource could easily add positive annotations to their own resource, and negative annotations to their competitors resources.
  2. Searches for resources with one or more annotations were significantly slower than that with no annotations.
Based on the above, it was determined that adding resource annotations has a negative impact on the system, and thus had to be excluded.
 
 

Figure 2: Negative NUC

Figure 2 illustrates a Negative NUC created for Educational Media Technologies. The "Add Resource Annotations" Use Case was determined to be a Negative NUC because of both technical and human factors, as shown in this figure.
 
 
 
 
 
 

Figure 3: Negative NUC

Figure 3 illustrates a Negative NUC created for the Junior High Math project of the Learning Technologies Branch at Alberta Learning. This example illustrates a Negative NUC. This example is interesting in that the "View Print Activities Answers" Use Case is a valid Use Case for a Teacher actor, but is a Negative NUC for a Students actor. topcontents 
Constrained NUC
A Constrained NUC is a Use Case whose definition, underlying structure, or subsequent implications have some measurable implication (constraint) or set of implications (constraints) on the system as a whole or in part. Constrained NUCs may essentially be UCs that may be included in software at a later date, but if and only if a condition or set of conditions is met.

Constrained NUCs emerged out of a need to specify an NUC early on in the design process that must be avoided for the time being, but that may be added later in the design process. Typically, a Constrained NUC will become a Use Case later on in the design process, once the required conditions are satisfied.

Constrained NUCs are temporary in the sense that they must not exist beyond the design stage. Before the first design iteration is complete, each Constrained NUC in the system must be evaluated, and converted to either a Negative NUC, or a Design NUC, or a Use Case that will be implemented in the software.

Figure 4: Constrained Non-Use Case

As shown in Fig. 4, Constrained NUC is drawn as a standard Use Case, with a circle over the line connecting the actor to the Use Case. The circle contains a boldface yield sign, and must have a note attached to it. This note is used to list the constraint or set of constraints acting on the Constrained NUC.

The information Management System designed for a research-oriented company is taken as the example of Constrained Non Use Cases. Three levels of information are in the system: basic information, annotations for the basic information, and advanced information. As a marketing strategy, the company has decided to restrict clients access up to the first two levels of information so that the advanced level of information is constrained.

Figure 5: Constrained NUC

Figure 5 illustrates a Constrained NUC created for New Media Solutions Inc. In this particular case, a Trial System was not implemented, and this Constrained NUC became a Negative NUC. topcontents 
Design NUC
A Design NUC is a Use Case that will be accounted for in the system design, but will not be included in the system implementation. A Design NUC is a Use Case that would be useful or beneficial to the software, but which is impossible to complete given some external constraint or set of constraints.

A Design NUC is typically a Use Case that would consume too much development time or money to be worth developing immediately. However, a Design NUC should still be accounted for in the overall system architecture, as it may be implemented in a future release of the software.

Figure 6: Design Non-Use Case

As shown in Fig. 6, a Design NUC is drawn as a standard Use Case, with a circle over the line connecting the actor to the Use Case. The circle contains a boldface "plus" sign, and must have a note attached to it. This note is used to explain the reason or set of reasons for not including the Design NUC in the system.

 Three cases (New Media Solutions Inc., Junior High Math Project, and job bank project) explain the Design Non-Use Case as follows.

Figure 7: Design NUC for New Media Solutions Inc.

Figure 7 illustrates a Design NUC created for New Media Solutions Inc. as part of the FileShare web application project. This is a Design NUC because implementing it would present a number of complex User Interface issues. This Use Case was initially determined near the projects inception. However, initial prototyping determined that this Use Case presented UI issues which could not be overcome in the projects timeframe.

Figure 8: Design NUC for the Junior High Math Project

Figure 8 above illustrates a Design NUC created for the Junior High Math project of the Learning Technologies Branch at Alberta Learning. This NUC was created for a Grade 7 learning resource allowing users to explore the concept of the "order of operations". However, consultation with several Flash developers revealed that implementing this solution would be costly, and not necessarily worth the effort.

The "job bank" project in this course provided an example of "Design Non Use Cases" (Fig. 9). In design, the case of "posting resume" has been described in use case analysis. But due to time limitations, the developing team was unable to accomplish this case. In documentation, this case is thus defined as "Design Non Use Cases".

Figure 9: Job Bank Project is taken as an example of Design NUC

topcontents 

4. Discussion

Based on the trial use of Non-Use Cases, it is theorized that the application of Non-Use Cases will lead to the emergence of new Design Patterns. Applying Non-Use Cases allows the design of a software system to be more focused. Based on that assumption, it is logical to propose that a more focused design will lead to a more refined software system. Trials application of Non-Use Cases has confirmed this possibility. Applying Non-Use Cases to several projects assisted in focusing the designs to the point where general and specific structures become more obvious than they may have otherwise been without the application of Non-Use Cases.

Subjectively speaking, feature creep is not necessarily a bad thing. If time is taken to properly redesign (re-factor) the software to account for the additional functionality, feature creep can sometimes be a necessary part of the evolution of a software system. However, in the real world, software projects are constrained by time and money, and a complete proper re-factoring is not always possible. Non-Use Cases represent a method of assisting in the prevention of unwanted or unneeded features from being.

Acknowledge Authors thank anonymous reviewers, Dr. Rick Gee, and Dr. Anne Dawson for valuable feedback and comments.

topcontents 

References

Jacobson, I. Booch, G., Rumbaugh, J. 1999. The Unified Software Development Process. Addison Wesley Longman, Inc. pp. 463
Gumbaugh, J., Jacobson, I., Booch, G. 1999. The Unified Modeling Language ReferenceManual. pp. 550. Addison-Wesley. Toronto.
Schach,S.R. 2005. Object-Oriented and Classical Software engineering(6th Edition). pp581. Mc Graw Hill Higher education. Toronto.

topcontents