It is a challenge to teach modeling to undergraduates. Primarily, the di culty is of teaching abstract concepts because it is hard for students to digest and appreciate abstractions. This paper is about developing a curriculum in which students can experience how models enable one to: nd solutions, verify solutions, and be able to experiment with possible solutions. In this paper we present two modeling topics covered in an undergraduate course taught at Iowa State University (ISU). These topics are chosen for their practical importance. Our primary goal is to enable students to learn how to apply modeling to solve practical problems of large software and be familiar with state-of-the-art modeling tools used in industry. Model-based problem solving makes it easier for students to appreciate and learn modeling.
Models help us understand how complex things work. Engineers use mathematics as a modeling tool to reason about complex systems. When Boeing designs a new jet, they model the airplane in software, where they run millions of simulations to understand how the shape of the fuselage, weight of the components, position of the cockpit, and numerous other variables a ect lift and fuel e ciency.
Models enable us to abstract and focus on essentials of a problem. The abstraction becomes the basis for designing an e cient and sound solution to an otherwise di cult problem. With modeling, we can nd a solution that works for not just one but a large number of seemingly di erent problems. The following two problems are seemingly very di erent but a common model works for both.
Problem 1: John is 3 years older than Jill. Together their ages add up to their mother's age. Their mother is 45 years old. How old are John and Jill?
Problem 2: A water tank holds 3 gallons of water more than another water tank. Together the two water tanks can hold 45 gallons of water. What is the capacity of each water tank?
The common model, a linear system of equations, suppresses irrelevant details. In general, a good model captures the essential core of the problem. There are other important points about models that make them useful and powerful. Models suggest generalizations applicable to a large class of problems. In the above example, the generalization is a linear system of equations with N variables instead of just 2 variables. Models serve as the foundation for developing e cient and accurate computational methods for solving complex problems. In this paper, we discuss how to e ectively bring out these modeling highlights in the context of software engineering.
The software engineering program at ISU was started in consultation with several companies. We interact with these companies and with companies that use EnSoft's products and services. Industry is interested in Model-Based Development (MBD) as a way to improve reliability of software and produce it e ciently. Industry is not interested in modeling that works only for toy problems. To be relevant to industry, modeling should be taught in the context of large real-world software. One topic, Uni ed Modeling Language (UML), is of great interest to industry. Since a number of textbooks already discuss UML at length, this paper focuses on other MBD topics which are often not taught in software engineering curricula but are of interest in industry.
It is a challenge to teach modeling to undergraduates. Primarily, the di culty is of teaching abstract concepts because it is hard for students to digest and appreciate abstractions. Teaching models in a software engineering course is especially di cult. Other engineering disciplines have well established modeling techniques and tools. For example, the nite element modeling is well established and routinely taught in mechanical engineering. Software engineering itself is a relatively new and evolving discipline and the modeling of software is more so.
We present a case study based on an elective course in our undergraduate software engineering degree program at Iowa State University. After introducing a few basic concepts, modeling is primarily taught by presenting a set of problems. The problems are chosen so that the students can understand and appreciate their importance in real-world software engineering but it is di cult for students to solve the problems without applying modeling. Then modeling techniques are introduced to solve the problems. We have not yet done a systematic assessment, but we have received numerous positive comments from students, impromptu as well as comments through course evaluation at the end of the semester. Based on the feedback, we believe that this problem-based teaching makes it easier for students to appreciate and learn modeling. We present two representative examples of problem-based teaching of software modeling. 2
While the goal remains the same, to improve reliability of software and produce it e ciently, modeling is a multi-faceted activity with di erent types of use cases. Modeling can bene t varied software engineering tasks including: { Gathering requirements { Estimating time and cost for software evolution and maintenance projects { Designing to meet real-time performance and resource constraints { Generating software from speci cations { Analyzing software nd defects, validate, and verify { Generating test cases to meet coverage requirements { Enabling e cient communication between clients, developers, managers, and QA personnel
In this paper we present two use cases of incorporating model-based development in a software engineering curriculum: (a)generating software from its model, and (b) model-based software analysis. We advocate these use cases because of their practical importance and two very di erent facets they represent of model-based software engineering.
Modeling paradigms di er depending on the use-cases. For example, The
Constructive Cost Model (COCOMO) [
One important modeling consideration is domain-speci city. The prime motivation is to make programming easy and reliable for a speci c domain of applications. A good model is an abstraction that is close to the semantic core of the problem - it could be an equation, a graph or something else. A model should not be just a notation (syntax) it should enable e cient semantic processing. Semantic processing implies the ability to: nd solutions, verify solutions, and be able to experiment with possible solutions. A domain is a class of problems that share a common semantic core. A generic abstraction may not be close enough to the core semantics of the domain and that necessitate the need for a domain speci c language (DSL). Excel-type spreadsheet is a good example of a widely used domain speci c programming environment.
We discuss Simulink models as domain-speci c programming environment.
Simulink is a mature modeling environment widely used in industry but rarely
presented to software engineering students. Simulink has an underlying
domainspeci c language (DSL) and a graphical programming interface. Simulink is used
speci cally to develop embedded control systems software in aerospace,
automotive and other companies. These companies are required to produce highly
reliable software because of the safety-critical nature of their applications. The role
of Simulink has shifted from a prototyping tool to a software production tool. In
this process, the Simulink models have grown reaching 100K-block models. The
number of lines of generated C code per Simulink block varies from one to about
hundred lines. Developing and maintaining large Simulink models intrinsically
requires software engineering principles and practices. The domain experts, the
control systems engineers, are not typically familiar with software engineering
practices to make e ective use of version control systems to facilitate team work
for developing large models. Companies need interdisciplinary teams of control
and software engineers. A software engineer can play an e ective role in such
teams if he or she is familiar with the nuances of Simulink models.
Our second use-case brings out domain-speci city in a di erent way. We use
Atlas, a generic program analysis platform from EnSoft. It o ers query-based
programming interface to write domain-speci c analysis programs. We use this
platform to teach students the idea of building domain-speci c analysis models.
This is possible because the analysis platform o ers a query language. Generic
program relationships are pre-computed by the platform and those relationships
can be accessed through the query language to build domain-speci c analysis
scripts, for example, analysis scripts to detect malware in Android apps.
Students learn and apply domain-speci c knowledge of Android Manifest [
Our case study involves two modeling tools: Simulink from MathWorks [
Executable models are created graphically using Simulink. Simulink CoderTM
(formerly Real-Time Workshop R ) generates and executes C and C++ code
from Simulink models [
There are two major classes of elements in Simulink: blocks and lines. Blocks are used to generate, modify, combine, output, and display signals. Lines are used to transfer signals from one block to another.
Blocks have zero to several input terminals and zero to several output terminals. Unused input terminals are indicated by a small open triangle. Unused output terminals are indicated by a small triangular point.
Lines transmit signals in the direction indicated by the arrow. Lines must always transmit signals from the output terminal of one block to the input terminal of another block. One exception to this is that a line can branch o of another line. This sends the original signal to each of two (or more) destination blocks. Lines can never inject a signal into another line; lines must be combined through the use of a block such as a summing junction. A signal can be either a scalar signal or a vector signal. The lines used to transmit scalar and vector signals are identical. The type of signal carried by a line is determined by the blocks on either end of the line.
Building a Simulink model is accomplished through a series of steps: 1. The necessary blocks are gathered from the Library Browser and placed in the model window. 2. The parameters of the blocks are then modi ed to correspond with the system we are modeling. 3. Finally, the blocks are connected with lines to complete the model.
Simulink models can be executed through an Interpreter. The user can go to
the Simulation menu and click on Start. With more complicated systems, the
user can see the progress of the simulation by observing its running time in the
lower box of the model window. Videos and Examples of Simulink are available
at [
Atlas is an analysis and visualization platform to build and study graphical models of software. It is available as an Eclipse plug-in. It has a graphical query language for constructing and analyzing graphical models of software. The queries can be executed through Scala Interpreter or they can be embedded in a program analysis script written in Java or Scala.
The Atlas platform builds a database of relationships between program artifacts. The user issues queries against this database and the results are shown as graphical models. The queries are composable. The result of a query can be stored in a variable which can be passed as input to another query. The Atlas platform has built-in graph algorithms that can be used through queries to transform and traverse graph models.
In Atlas, the program analysis is decoupled from its use for modeling a
particular class of applications. The advantage is that domain-speci c models can
be built easily. Currently, ISU and EnSoft have a joint research project funded
by the DARPA APAC program to build a Security Toolbox for detecting
malware in Android apps. The toolbox is being developed as a set of analysis scripts
that incorporate domain knowledge of Android. Our case study was focused on
operating systems so that students could use their domain knowledge to build
models for XINU [
The two examples are drawn from a course taught as an elective for the
undergraduate Software Engineering program at ISU. The third example covered
in the course, model-based testing, is not included here. We use the chapter
on model-based testing from the book [
We strive to teach modeling as a problem solving skill. We rst pose a problem and let the students make an attempt to solve the problem. We tell students to think of a model to solve the problem. Then, we teach a modeling concept relevant to the problem and build a model using one of the tools we have brie y described. To reinforce the modeling concept and the use of the tool, we give another similar but a bit more challenging problem as a modeling homework. To stay within page limits of the paper, the examples are not the complete exercises that students go through. The examples are meant to bring out how modeling can be taught through concrete problems that students can nd interesting and challenging. The problems are speci cally chosen so that students can appreciate the value of modeling to solve non-trivial problems.
To demonstrate how Simulink can be used to investigate a real-world system, we ask students to create a simpli ed, rst-order model of the motion of a car. If we assume the car to be travelling on a at road, then the horizontal forces on the car can be represented by: { v is the horizontal velocity of the car (units of m=s). { F is the force created by the car's engine to propel it forward (units of N ). { b is the damping coe cient for the car, dependent on wind resistance, wheel friction, etc. (units of N s=m) We have assumed the damping force to be proportional to the car's velocity.
{ M is the mass of the car (units of kg).
Writing Newton's Second Law for the horizontal direction thus gives:
To be able to successfully simulate the system, we specify an applied input, F . Let us assume the car is initially at rest, and that the engine applies a step input of F = 400N at t = 0. This is approximately equivalent to the car's driver quickly pushing down and holding the gas pedal in a steady position starting from a stoplight.
Note that the Simulation A does not appear to show the velocity approaching a steady-state value, as we would expect for the rst-order response to a step input. This result is due to the settling time of the system being greater than the 10 seconds the simulation was run. To observe the system reaching steady-state, we click Simulation, Parameters in the model window, and change the Stop Time to 150 seconds. Now, re-run the simulation and note the di erence in the velocity graph Output B in Figure 2. After engaging students in working with a couple of di erent Simulink models, we get into a broader discussion of following points: { Why domain speci city is important? { Graphical programming { Quick prototyping and simulation { Unifying programming and design { Simulink models vs. C programming
We present the device driver code (dswrite()) shown in Figure 3 from the Xinu operating system. It includes a getbuf() call to allocate memory but no freebuf() call to deallocate memory. We ask the students to check if it is a memory leak. Students quickly go to dskenq() because the pointer to the allocated memory is passed to it as a parameter. Soon they nd that they have to examine many functions. After examining a few functions they hit a barrier because the pointer to the memory is assigned to a global variable. Now they do not know which functions to examine because the global variable can be accessed by any function. It is time to introduce modeling to solve this problem.
We build a graphical model for solving the memory leak problem. The goal is to create a model to nd all relevant functions and their call relationships. Note that constructing a call graph of dswrite is not enough. A function that is not called directly or through a call chain can access the global variable that contains the address of the allocated memory and deallocate the memory. It can also happen that after getting the memory address the pointer may be passed through a call chain eventually to a function that calls freebuf to deallocate memory. So, our rst model is the reverse call graph (rcg) of getbuf and freebuf. This model gives a conservatively relevant subset of functions and their call relationships.
We can build a better model by incorporating another constraint. We note that the memory was allocated for a structure of type dreq. The rcg can have many functions that do not read or write to variables of type dreq, and hence these functions are not relevant to our memory leak problem. They should not be included in the model. Our re ned model can be an induced subgraph of the rcg that includes only the functions that read or write to variables of type dreq. It is easy to build this re ned model using a sequence of Atlas queries as follows: 1. #m1 = rcg(getbuf, freebuf) - rcg is stored in a variable #m1 2. #temp = ref(dreq) - temp captures the functions that read or write dreq 3. #m2 = #m1 intersection #temp - #m2 is the refined model 4. show(#m2) - the model is shown graphically By executing the above sequence of four queries, Atlas produces a graphical model shown in Figure 3.
A quick review of the model brings out a couple of important points. First, there is a call chain from dswrite to freebuf which means that at least on some execution paths the memory is deallocated. This model cannot tell us if the memory is deallocated on all execution paths, we need a di erent model to check that. The dsinter calls freebuf but not getbuf. That freebuf call can potentially account for missing deallocations on some of the paths. In fact, that happens to be the case in this example. We then get into other models that can facilitate such validations. We have done a project in class where students have used models to validate the Linux kernel 2.6.31 for a safe synchronization property which involves analysis quite similar to checking memory leaks. The models used for the Linux kernel validation were originally developed by two graduate students as a part of PhD research. At the end of the project the students write a report classifying all instances memory allocations according to the results of their analysis and for a few selected instances they provide a detailed description of: the analysis they performed, the relevance of the tool in performing the analysis, and the learning outcome.
We have developed a new teaching module to show how models suggest
generalizations applicable to a large class of problems. This module de nes a
notion of 2-event models and shows its broad applicability to a large class of
problems. We show that the model is applicable for analyzing memory leaks,
mismatches of mutex locks and unlocks, and interestingly to detecting malware
in Android apps. The applicability to detect Android malware is a research
project funded by DARPA APAC program [
The Figure 4 shows a model of malware and its correspondence to a model
extracted from the software. In this model, images captured by camera are rst
passed as exception objects, then as asynchronous messages using Android APIs,
and nally leaked to a suspicious URL. The software model is extracted using a
sequence of Atlas queries.
Three thematic groups of paper submissions were discussed in the Educators
Symposium of the MODELS conference in 2008 [
Pareto in [
Kramer in [
This paper advocates that modeling be taught as problem solving exercises so that students can get over the hump of abstraction and nd modeling interesting and useful. We present a case study that includes two very di erent facets of modeling. We believe rightly taught modeling can transcend software engineering and help students learn how to think clearly. While we have not done a formal assessment of e ectiveness of our approach to teach model-based software engineering, we have received many student comments through course and instructor evaluation forms indicating that they found the topics thought provoking and useful.
This work was partly supported by MathWorks curriculum development grant and a DARPA research grant under agreement number FA8750-12-2-0126. We thank the reviewers for careful reviews and many good suggestions.