A Model of bCMS Using the Umple Model-Oriented Programming Approach Timothy Lethbridge Electrical Engineering and Computer Science University of Ottawa, K1N 6N5 Canada +1 613 562-5800 x6685 [email protected] ABSTRACT unnecessary and strongly discouraged, since any needed In this paper we present a model developed using the Umple editing can be done in the original source. model-oriented programming technology. We have modeled the • The processes of modeling and programming are also unified: bCMS crisis management system, which has been set as a Programming is seen simply as development at a lower level common modeling challenge for the Comparing Modeling of abstraction, while modeling is seen as development at a Approaches workshop. We demonstrate modeling of the class higher level of abstraction. We will refer to the people who do structure of the system and the state machine used to co-ordinate the modeling/programming task as developers, to be generic the crisis management effort. This model captures some of the • A program developed using model-oriented programming at benefits of model-oriented programming: The model looks like a any level of abstraction can be ‘partial’, resulting in a sketch, program, so it can be extensively documented inline using or incomplete system. However, as long as it is syntactically comments, and easily edited. The textual model is designed to be and semantically correct, even a partial model-oriented highly readable, but if desired can also be viewed and edited as a program can be compiled; an incomplete model would diagram. Mixin and product-line capabilities of Umple are also generate an API, for example. used. • The types of modeling constructs are not limited by the approach. Currently implemented examples include class diagrams, state diagrams, constructs for databases (keys), and General Terms various design patterns. Design, Language • A visualization of the model/program may be available. In such a case, the text and diagrams are views of the same Keywords underlying model/program. Umple, Model-Oriented Programming, UML. • A developer can create a ‘pure’ model that has only modeling constructs. When doing this he or she is modeling textually. 1. INTRODUCTION On the other hand a developer might start with a program in a standard programming language, and convert it to a model, by We present a model of the bCMS system [1] developed using the transforming parts of the code into modeling elements with a Umple model-oriented programming technology. higher level of abstraction. Doing so would typically reduce We start with an overview of what we mean by model-oriented the volume of code substantially (by between 10% and 90% programming and a few facts about Umple and the modeling depending on the case [2]). approach in this paper. The remainder of the paper shows the model. 1.2 Umple: An Example of a Model-Oriented Programming Technology 1.1 Model-Oriented Programming We have been developing Umple [3][4][5] since 2007 as a Model-oriented programming is a modeling approach that has the technology to explore the ideas of model-oriented programming. following properties: Umple has support for UML class diagrams and state machines, plus aspect-orientation and certain design patterns. Various other • Model and code are a unified textual artifact that can be features are under development, particularly extensions for UML version controlled, edited in a text editor, and operated on by component diagrams and real-time profiles. any standard tool that works with text. The textual notation is designed to be as readable by humans as possible, as such Umple supports product lines and feature-driven development in XML, the basis for many textual modeling languages, has two ways: It has a mix-in capability that allows constructing a been avoided. system from different configurations of parts. This capability • Modeling constructs are added as first-class entities and as applies to the base language (e.g. Java) too, so for example parsimoniously as possible to existing programming different Java methods can be mixed in to give a different version languages, such as Java, PHP, C++ etc. of the same class for two different members of a product line. • All modeling constructs result in high-quality generated code Umple also has an implementation of VML (Variability Modeling when compiled, in the same manner as the existing language Language) [6] that can be used to put together different constructs generate bytecode or machine code. So-called configurations of features; it leverages the mixin capability. ‘round trip engineering’ (editing of generated code with Umple has been used to create a wide variety of systems, propagation of changes to the source) is conceptually including the Umple compiler itself. There is an online tool [7] that allows concurrent editing of graphical and textual views of a 2. THE MODEL system. Umple is also used in the classroom [8] and has proved We present the model as several submodels. For the most part we effective at helping students learn UML present the models using Umple source code. We have omitted the parts of the system that would be written in Java, since this 1.3 Modeling Approach exercise is about pure modeling. The model shows names of When using Model-Oriented Programming starting with a set of methods as method calls in state machine actions, but the requirements (as opposed to a legacy system), with the intent of algorithms for doing such things as planning the routes are creating a new system, the following is an extremely brief sketch omitted. of the suggested approach, and the approach used in developing the model presented in this paper. 2.1 Submodel for Routes and Locations • Develop use cases if they are not already present. In order to enable the system to compute routes and assign them • Start by marking up the requirements and use cases, to vehicles, among other capabilities, bCMS needs a minimal identifying the modeling elements such as classes, geographic information system (GIS) capability. We have associations, generalizations and states. This is as described modeled this first. by Lethbridge and Laganière [9]. Figure 1 shows the class diagram. This has been drawn by • In an agile manner, build versions of the model/program using UmpleOnline [7] from the Umple model/code shown Umple, starting with the central core of the system. At each subsequently. iteration, it should be possible to compile the system, and to execute test cases and skeleton front-ends to render it executable (for this paper we compiled the model to partially validate it, but omitted testing, since the volume of material would be too great to present here). For the work presented in this paper, we were given a reasonable set of requirements including sketches of use cases. We converted the pdf file to Word, and then marked up the Word document with different coloured highlighting as we scanned it for modeling constructs. In particular we focused on finding classes, associations, attributes, states, events and generalizations. We also took note of the variants required. We identified logical subsystems and worked on them independently. Then we worked on some variants. If the paper is selected for inclusion in the workshop we will perform additional iterations to improve it. 1.4 Classification of the Approach As required by the call for contributions, we present the categorization of our approach: Classification of the approach as either aspect-oriented, feature-oriented, object-oriented, subject-oriented, or any other paradigm: The approach is fundamentally ‘model-oriented programming’, which is at its base object oriented, but also incorporates feature- oriented and aspect-oriented capabilities. Fig. 1. Class diagram of the Routes and Locations submodel. Statement classifying the approach in terms of its software development phases: The Umple source of this model is as follows. The file itself has been incorporated as an example in the Umple user manual at The model includes a ‘system domain model’ (as defined in [9], http://www.umple.org/RoutesAndLocations.html and with a small amount of added code in state machine transitions. UmpleOnline using the following URL: The approach itself can be used for high-level design, low-level http://try.umple.org?example=RoutesAndLocations. design, implementation and evolution, since the same artifact is used throughout, with additional details added at each step. To understand the syntax or semantics readers are urged to consult the user manual at http://manual.umple.org. Description of what is modeled: // RoutesAndLocations.ump We have focused on modeling the core system, and have // demonstrated how we can model some of the variants as mixins. // Author: Timothy C. Lethbridge Since the approach can be continued until the system is fully implemented, we have left various details incomplete. For namespace routesAndLocations; example we have not modeled the SOAP communication protocol. Umple is being extended to generate code for inter- /* * This file describes reusable model elements component communication. * that are used in the bCMS Crisis Management * System. It is necessary to have a rudimentary * Graphical Information System such as described 1 -> * Turn illegalTurns; * in this submodel as part of bCMS in order to // Impossible turns , e.g. because of barriers, * plan routes and to track where crises are. // turning radius * This file has the necessary classes. 1 -> * Turn impossibleTurns; */ } /* /* * A CityMap contains the precompiled streets and * Turns are used to model illegal turns, e.g. * landmarks * turning left when there is 'no left turn' * This must be read in from the database on * allowed, or 'no U turn' allowed. * system initialization */ */ class Turn { class CityMap { RoadSegment turnFrom; singleton; RoadSegment turnTo; 1 -> * Landmark fireStn; } 1 -> * Landmark policeStn; 1 -> * Landmark otherLm; /* 1 -> * NamedRoad; * A named road might have the name of a street, } * the number of a highway, etc.