=Paper=
{{Paper
|id=Vol-2019/edusymp_1
|storemode=property
|title=Modeling in Agile Project Courses
|pdfUrl=https://ceur-ws.org/Vol-2019/edusymp_1.pdf
|volume=Vol-2019
|authors=Lukas Alperowitz,Jan Ole Johanssen,Dora Dzvonyar,Bernd Bruegge
|dblpUrl=https://dblp.org/rec/conf/models/AlperowitzJDB17
}}
==Modeling in Agile Project Courses==
https://ceur-ws.org/Vol-2019/edusymp_1.pdf
Modeling in Agile Project Courses
Lukas Alperowitz∗ , Jan Ole Johanssen† , Dora Dzvonyar‡ , and Bernd Bruegge§
Department of Informatics, Technical University of Munich, Germany
∗ lukas.alperowitz@tum.de, † jan.johanssen@tum.de, ‡ dora.dzvoynar@tum.de, § bruegge@in.tum.de
Abstract—Teaching software engineering in an applied setting perspective modeling approach by describing the models, their
with projects provided by clients from industry creates a real- perspective on the system at hand, and the transition between
world learning experience for students. While clients are domain each of these models. We provide an approach for teaching
experts well-aware of the system’s requirements, they often lack
technical knowledge required to make decisions regarding the the models in Section IV. Advantages and disadvantages are
system architecture or the technologies involved in the project. discussed in Section V. Section VI concludes the paper and
Therefore, it is challenging for students to maintain a common describes starting points for future work.
language of understanding.
To overcome this obstacle, we suggest a four-perspective
modeling approach that allows students to create models as a II. R ELATED W ORK
basis for communicating with clients that don’t have a technical
background. The student teams apply these models to clarify
requirements as well as to discuss architectural considerations Lemma et al. present a tablet-based approach utilizing
and technological decisions. Each modeling perspective focuses touch gestures for creating and managing object-oriented
on different aspects of the system to be developed. We teach this software models [8]. Wüest et al. propose a similar tablet-
approach using a methodology that integrates modeling into agile based approach, allowing multiple developers to collaborate
software engineering project courses.
on thoughts and ideas while deviating from standards such
I. I NTRODUCTION as UML [11]. Both approaches demonstrate the benefits of
Applied software engineering project courses should involve informal modeling, but they focus on software engineers as
industry partners and their real-world problems to provide the target user group. To the best of our knowledge, an
more relevance and prepare students for their later careers educational method for informal models of software systems
[2], [6], [9]. We regularly conduct such courses with 100 that allows students in agile projects to communicate their
students developing applications in 10-12 projects in which we ideas and thoughts to a non-technical audience has not yet
refer to the industry partners as clients [5]. While universities been addressed in previous research.
aim to teach their students in a real-world setting, industry URML, a language to model requirements knowledge relies
partners want to benefit in terms of creative uses of technology on visual notation to make models understandable by various
and innovative product ideas. Therefore, the role of the client stakeholders and extends UML in its capability to describe the
in such a course goes beyond stating requirements upfront complex requirements of a system [10]. URML replaces some
at the beginning of a project; they need to understand and UML class boxes with icons to ”enhance the vividness of the
take decisions regarding technical details of the future system diagrams” [3]. With our four-perspective approach, we adopt
throughout the whole lifespan of the project. the idea of replacing elements of formal models with visual
In our course, the clients are often domain experts who representations and extend it to more diagram types.
are highly familiar with the problem at hand, but they rarely In our previous work, we presented how we use informal
possess knowledge that is necessary to understand different models in our capstone course [7]. The four-perspective mod-
implementation-specific alternatives, nor to express and com- eling approach builds upon this work, further structures our
municate their needs concerning technological aspects of the teaching method, and describes our latest experiences.
project. The lack of a common basis of communication poses
a challenge for students to discuss architectural considerations
and technical details with their clients. III. F OUR -P ERSPECTIVE M ODELING
In this paper, we describe a four-perspective modeling
approach which we use to overcome this obstacle. Aside from In this section, we describe our approach in detail by first
being easily learnable for students, its main goal is to establish explaining the rationale behind each model and specifying its
a common terminology which is utilized for discussions with target audience. Moreover, we give a brief overview of the
clients who are not familiar with software modeling languages benefits and weaknesses of each model and discuss when it
such as UML. Each perspective of the modeling approach puts is best applied to communicate a particular perspective of a
a different aspect of the system into focus and presents it using software system. We also explain how transitions between the
an appropriate level of abstraction. models support their understanding and thereby facilitate their
The remainder of this paper is structured as follows. In Sec- communication. Several of the models of our four-perspective
tion II, we outline related work. Section III introduces the four- approach are described in detail in [4].
Fitness & Nutrition Data
Bloo
dG ion
luco lizat
Fitn se D aS eria
ess
&N
ata Dat
Health Trackers Health Data Repository utrit Share with App
ion
Dat
a
Visualization
Smartwatch App
ings Con
ead duc
t Su
eR
lucos rvey
s
Blood Glucose Test dG Patie
Bloo Smartphone App nt D
ata
Blood Test Strips Blood Glucose Reader Medical Res. Framework
Fig. 1: Top-Level Design of a system for mobile blood glucose level tracking.
To illustrate the different perspectives, we describe a system The Analysis Object Model should not cover every entity
that allows users to track their blood glucose level using their of the system: it depicts a high-level overview of the problem
smartphone in a mobile context1 . domain instead of the exact objects used for implementation.
Adding visionary entities, in particular entities that are never
A. Top-Level Design
implemented but are common in the system’s problem domain,
The Top-Level Design expresses the overall architecture can support the model’s comprehension. The same holds
of a system by highlighting its subsystems and the data true for the relationships between objects: they are modeled
exchanged between them as shown in Fig. 1. The notation only if they provide further guidance for the audience. With
does not follow strict rules, but conforms to conventions: each an Analysis Object Model, the students should address the
subsystem is depicted with an icon and labeled with a textual following questions:
description. Arrows and a short textual description describe
• What are the system’s core entities and their relation-
the data that is exchanged between the subsystems. Due to its
ships?
limited complexity, a Top-Level Design is especially useful to
• How can we align them with the client’s domain of
explain and discuss software architectures with non-technical
knowledge?
stakeholders of a software project.
The Top-Level Design models the problem domain for
C. Subsystem Decomposition
technology-independent discussions to keep the focus on the
system’s overall architecture [1]. Therefore, our example in For providing a more technical overview of the system that
Fig. 1 shows a Smartphone App rather than an Apple iPhone, should be developed, we leverage the notation of a UML
Calorie Trackers instead of concrete application names and a component diagram. The Subsystem Decomposition offers a
Health Data Repository without mentioning its actual imple- view beyond the subsystems previously introduced in the Top-
mentation. Determining the right level of abstraction is key Level Design in terms of components and their interfaces.
when creating a Top-Level Design. During the creation of Similar to the previously described models, the key when
a Top-Level Design, students should focus on answering the creating or extending this diagram is to find the right level of
following two questions: abstraction by visualizing the key interaction points between
• What parts of the system are relevant for the client? the subsystems and their environment.
• What can we omit to avoid unnecessary complexity and In order to make the model understandable for a non-
distraction? technical audience, students start by showing an iconized
version as visualized on the right side of Fig. 3. Then, the inner
B. Analysis Object Model structure of each subsystem on a component level is revealed
The Analysis Object Model describes the static structure of step by step. Finally, the entities of the Analysis Object
the system: objects with attributes and their associations. As Model can be used to explain the data flow. This becomes
illustrated in the example in Fig. 2, the notation of the Analysis more expressive when the data flow is animated with colored
Object Model is similar to an iconized version of a conceptual lines, serving as an entity’s trace through the system. The
UML class diagram. An Analysis Object Model supports the Subsystem Decomposition allows students to provide details
establishment of a common terminology. This is relevant when on components and answer the following questions:
discussing parts of the system within the development team or • How are objects processed by the system’s individual
with non-technical stakeholders. components?
1 The icons used for the models are retrieved from http://www.flaticon.com • How does the data flow between the subsystems and
and are licensed under the Creative Commons BY 3.0 license. components?
use use
Patient Recommendations
Therapy Human Generated
Recommendations Patterns
Plan Recommendations
create provide use find
use use
Data Sample
Medical Professional Recommender
BG Values Insulin Injections Carbs Health Labels Locations Activities
Fig. 2: Iconized Analysis Object Model visualizing important entities.
D. Hardware-Software Mapping which cover topics relevant for all projects, such as modeling
The Hardware-Software Mapping shows the distribution of or release management.
a system’s components on actual hardware and software nodes. At the beginning of the course, each project team receives
As opposed to the other perspectives, the use of concrete a problem statement describing the purpose and requirements
instances and solution domain terminology is encouraged here. of the system from their client. We precede the development
For instance, iOS is proposed as an actual mobile operating sprints with a period of 2-3 weeks in which the students
system, or iPhone as an implementation of a smartphone. focus on understanding the requirements and transforming the
We recommend using a UML deployment diagram for problem statement into a prioritized product backlog. In this
the Hardware-Software Mapping, while still working with so-called Sprint 0, we encourage students to create initial
icons to preserve the model’s understandability for a non- informal models to communicate their ideas concerning the
technical audience. The previously introduced components in problem domain and the system architecture to their fellow
the Subsystem Decomposition can be detached from the over- team members and the client [7]. This allows the team to estab-
all diagram and placed within the actual hardware components, lish a shared mental model of the system they will develop and
as shown in the presentation recording of the blood glucose creates a mutual understanding of possible technologies in-
tracking system2 . Using this perspective, the students can volved. The project teams typically create a Top-Level Design
answer the following question: as well as a Analysis Object Model during this Sprint 0. Most
teams choose to use Gliffy3 as a modeling tool because it is
• On which hardware or software node are the components
well-integrated into the existing knowledge management tools
deployed on? used during the course and offers a mix of semi-formal and
• What are the specific protocols used for communication
informal templates. Together with the modeling cross-project
between the nodes? team members, we review these two models in a feedback
meeting, in which one representative from each team presents
IV. T EACHING A PPROACH their models and the corresponding high-level architectural
We teach our four-perspective approach with a methodology decisions. In subsequent sprints the teams continuously refine
involving multiple roles and feedback rounds and concentrates these models every time new requirements arise or existing
not only on the creation of models for each perspective, but requirements change.
also on their effective communication. In this section, we We introduce the remaining two perspectives of our model-
explain how we teach the approach in the iPraktikum, a multi- ing approach as well as techniques on how to present the mod-
project capstone course conducted at the Technical University els in a course-wide lecture held four weeks into the course.
of Munich. In this course, 100 students develop systems in the As their project becomes more concrete in terms of system
context of mobile applications over the course of one semester components that are needed to fulfil the required functionality,
based on an agile process model called Rugby optimized for the teams refine their two initial models and iteratively develop
part-time developers [5]. their Subsystem Decomposition. When they make decisions
Each project team works with a client from industry and is concerning concrete technologies, protocols, and hardware
led by a project leader who is a doctoral candidate. Further- used, they create their Hardware-Software Mapping, which
more, the organizational structure includes cross-project roles completes the four-perspective approach.
2 https://youtu.be/sNVMtK8CcbM 3 https://www.gliffy.com
Watch App
Glucose Insulin
Sensor Pen
Fig. 3: Subsystem Decomposition containing icons for the visualization of data flow.
After further peer-to-peer feedback rounds with their project Firstly, using a modeling approach that diverges from known
leader and experienced students who are familiar with our standards most students are already familiar with (such as
approach, each team presents their relevant models in a course- UML) certainly involves additional teaching effort from the
wide presentation which we call Design Review two months instructors’ side, as well as added learning effort for the
into the course. For this presentation, we teach the students students. We go through several feedback cycles before the
to tell a story along with the models and to transform each Design Review to support the teams in preparing their models.
model from the four-perspective approach into one another. This is perceived as additional workload by students which
For instance, the students present the relevant objects of the they do not always see as necessary, especially in the first
problem domain and their relations in the Analysis Object month of the course. As they begin using the models for com-
Model, and animate the same objects through their Subsystem munication with their client, they start to see the usefulness
Decomposition diagram to show the data flow. While preparing of the modeling approach for communicating their system
their presentation, students switch from modeling tools to architecture. Students’ perception improves even further as
presentation software such as Apple Keynote4 to integrate the Design Review approaches and they start preparing their
high-resolution icons and transitions. Keynote allows for a presentations. While we allow the students to decide which
seamless integration with other content, such as requirements models to present, most teams choose to show three or even
descriptions or status updates. We provide an example of all four models in their presentation, transitioning from each
presenting the above-mentioned models as an online video.5 perspective to show a different view of their system.
At the end of the course we ask each team to document their Our experience shows that clients welcome the graphical
results using the four models created. For each model they cre- models and they use the Analysis Object Model to arrive
ate navigational text that describes the key elements and their at a shared understanding of the problem domain early in
relationships. This document in combination with the other the project. Seeing how the students understood the problem
artifacts created during the course, such as the actual source gives them the opportunity to correct assumptions or clarify
code repositories, setup instructions for the infrastructure, or questions with their extensive domain knowledge. The Top-
videos of the teams’ presentations, are delivered to the clients. Level Design and Subsystem Decomposition are used to dis-
The delivery marks the end of the course. cuss architectural decisions. The Hardware-Software mapping
is used internally by the team to discuss the deployment of
V. D ISCUSSION the components, but rarely shown to the customer due to its
comparably high level of technical detail.
We have been teaching the four-perspective modeling ap-
proach in our project courses for over 5 years during which it One may argue that the applied modeling techniques do
has been applied in over 100 student projects. In this section, not conform to the requirements of (semi-)formal modeling.
we reflect on the experiences we made. While we provide a basic set of notations for each model, we
encourage the students to integrate creative ideas that help to
4 https://www.apple.com/keynote/ understand the models’ content and to make adjustments to
5 https://youtu.be/sNVMtK8CcbM the models’ syntax during discussions with customers.
While some models do break syntactic rules of UML, we In the future, we plan to further structure and evaluate how
think that they make up for it in understandability and their development teams work with the four-perspective modeling
suitability to express the requirements of a wide range of approach. In particular, we want to identify which aspects
projects. By removing strict modeling rules, we reduce initial help the most to transport key elements of a software system.
hurdles faced by clients with a non-technical background and Another interest of ours is the influence of modeling on
thus allow them to be involved in discussions about system learning outcomes in terms of an enhanced understanding of
design decisions. Furthermore, the use of informal models en- software architecture and technologies.
courages involved discussion partners to focus on the relevant
R EFERENCES
parts of the system rather than syntactic details of the model
[7]. We also encourage students to strictly distinguish between [1] L. Alperowitz, C. Scheuermann, and N. von Frankenberg. From
storyboards to code: Visual product backlogs in agile project courses. In
technology-independent and platform-specific representations Tagungsband des 15. Workshops ”Software Engineering im Unterricht
to focus on the problem domain rather than getting lost in der Hochschulen” 2017, Hannover, Deutschland, pages 69–72, 2017.
discussion about the solution domain. The results of each [2] C. Bastarrica, D. Perovich, and M. M. Samary. What can Students
Get from a Software Engineering Capstone Course? International
perspective can subsequently serve as a basis for additional Conference on Software Engineering, 2017.
iterations that fully comply with UML specifications. [3] B. Berenbach, F. Schneider, and H. Naughton. The use of a requirements
The anecdotal evidence we gathered during the past years modeling language for industrial applications. In 2012 20th IEEE
International Requirements Engineering Conference (RE), pages 285–
indicates that while modeling is perceived as additional effort 290. IEEE, Sept 2012.
at the beginning of the course, both students and clients see the [4] B. Bruegge and A. H. Dutoit. Object Oriented Software Engineering
advantages of the approach and rely on it in their presentations Using UML, Patterns, and Java. Prentice Hall, 2010.
[5] B. Bruegge, S. Krusche, and L. Alperowitz. Software engineering
and their regular communication. project courses with industrial clients. ACM Transactions on Computing
Education (TOCE), 15(4):17, 2015.
VI. C ONCLUSION AND F UTURE W ORK [6] R. Chatley and T. Field. Lean Learning - Applying Lean Techniques to
In this paper, we described a four-perspective modeling ap- Improve Software Engineering Education. 39th International Conference
on Software Engineering, 2017.
proach to overcome the challenge of enabling audiences with [7] D. Dzvonyar, S. Krusche, and L. Alperowitz. Real projects with informal
limited technical knowledge to understand the architecture and models. In Proceedings of the MODELS Educators Symposium co-
inner workings of a software system. The approach consists located with the ACM/IEEE 17th International Conference on Model
Driven Engineering Languages and Systems (MODELS 2014), Valencia,
of a Top-Level Design, Analysis Object Model, Subsystem Spain, September 29, 2014., pages 39–45, 2014.
Decomposition and Hardware-Software Mapping. [8] R. Lemma, M. Lanza, and F. Olivero. CEL: Modeling everywhere.
It emphasizes the fast creation of models towards a com- In International Conference on Software Engineering ’13, pages 1323–
1326, USA, 2013. IEEE Press.
monly shared understanding of the system at hand. In addition, [9] M. Paasivaara, J. Vanhanen, V. T. Heikkil, C. Lassenius, J. Itkonen, and
we outlined a teaching method for iteratively creating the E. Laukkanen. Do High and Low Performing Student Teams Use Scrum
model for each perspective which includes multiple roles and Differently in Capstone Projects ? International Conference on Software
Engineering, 2017.
responsibilities, feedback rounds and presentations. In the last [10] F. Schneider. URML: Towards Visual Negotiation of Complex System
five years, we used the four-perspective modeling approach in Requirements. Dissertation, Technische Universität München, München,
over 100 student projects with industry partners in the context 2016.
[11] D. Wüest, N. Seyff, and M. Glinz. FlexiSketch team: Collaborative
of a large capstone course. The feedback we received from sketching and notation creation on the fly. In International Conference
students, project leaders and clients as well as the successful on Software Engineering ’15, pages 685–688, USA, 2015. IEEE Press.
implementation of the projects validate the usefulness of the
four-perspective modeling approach on an anecdotal level.