SEKE 2012 Proceedings - Knowledge Systems Institute

Some tools may perform the needed functions, but
only in versions incompatible with the laboratory
set up. Thus, sufficient time must be allocated to
experiment and ensure each tool’s capabilities.
• Debugging: Subtle bugs can exist, such that the
tool works fine in one environment, but not the
needed environment. Open source tools may be
beneficial, should the need to debug arise.
• Incentivization: Students’ preferences for development
environments and collaborative styles may
be different than those planned for the course.
It is recommended to provide an incentive (grade
points) for the use of tools that are strongly preferred,
perhaps from the need to enforce consistency
and uniformity, or for the sake of efficiency.
Without incentivization, students can wander off
in unanticipated directions, giving them less of
the planned valuable experience and resulting in
a marginally satisfactory outcome.
• Exploratory assignments: The assignments
should expect students to go beyond what can
be easily and routinely accomplished by the tool.
Such creative assignments will teach them how to
explore and learn a tool, and gain insights into the
value of the abstraction implemented by the tool.
6 Contemporary Tools
This section surveys the approaches taken to select
tools to teach SE. Some institutions select tools that
are designed for the industry. An Internet examination
of the syllabi of SE courses suggests that many open
source, industrially relevant tools exist, and have been
found useful in instruction. These tools, each addressing
an important and interesting facet of SE, are so
numerous that one could imagine using a different one
each week of the semester, for example [22, 25]. Innovative
use of these tools occurs as well, for example
de Marcos et al. [7] report a combined informatics and
philosophy course using StarUML.
A completely different approach is to abjure tools
suitable for the industry because they take too long to
learn, or misdirect students’ focus, and instead develop
a lightweight tool set that supports the software development
process, and in doing so, help novices develop
an understanding and awareness of the principles and
practices as they work [1]. Yelmo et al. [35] adopt this
approach and use a tailored, lightweight version of the
IBM Rational Unified Process. They also develop a
web-based tool to adapt RUP to a specific project.
Our approach can be considered to be a hybrid of
the above two strategies. Because we lacked the resources
to develop a custom, lightweight tool set, we
sought to evaluate existing tools. Our search was narrowed
to open source tools, not only because it was the
theme of the course, but also because the availability
of the source code offered the potential to customize
the tools to meet our objectives. Finally, although
industrial relevance was not a significant selection or
evaluation criteria, the chosen tools were intended to
be used in the industry. This industrial relevance was
a plus because it can conceivably help students when
they seek employment as software engineers.
7. Conclusions and Future Directions
We reported our experiences and lessons in evaluating
open source tools to teach SE. Despite the myriad
of tools, this evaluation was cumbersome because
many tools did not deliver their promised functionality.
Moreover, those tools that do appear to work, can be
unpredictable when called upon. Thus, such evaluation
can require significant trial and error and preparedness
to tackle unexpected, subtle issues.
We want more for reverse engineering of sequence
diagrams, in particular the ability to restrict the sequence
diagrams to specific classes. For this purpose,
we might investigate the code of Diver, as well as continue
searching for more tools. Ultimately, we envision
a set of tools connected through Eclipse, allowing students
to learn, measure, and develop abstractions, so
that the software not only remains useful but can better
evolve with new requirements.
Acknowledgments
This work was supported in part by the National Science
Foundation under grants DUE-1044061 and CNS-
0643971. Any opinions, findings, and conclusions or
recommendations expressed in this material are those
of the authors and do not necessarily reflect those of
the National Science Foundation.
References
[1] K. Alfert, J. Pleumann, and J. Schroder. Software
engineering education needs adequate modeling
tools. In Proc. of 17th Conf. on Software
Engineering Education and Training, pages 72–77,
Mar. 2004.
[2] http://amateras.sourceforge.jp/cgibin/fswiki_en/wiki.cgi?page=AmaterasUML.
166