DOCSLIB.ORG

Umple: Towards Combining Model Driven with Prototype Driven System Development

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Umple: Towards Combining Model Driven with Prototype Driven System Development PAPER IDENTIFICATION NUMBER: 40 Umple: Towards Combining Model Driven with Prototype Driven System Development Andrew Forward1, Omar Badreddin1, Timothy C. Lethbridge1 School of Information Technology and Engineering (SITE) University of Ottawa, K1N 6N5 Canada [email protected], [email protected], [email protected] Abstract—The emergence of model driven methodologies is text a tracer bullet [3]) is typically used whereby the proto- bringing new challenges for software prototyping. Models tend type evolves into the working production system. to focus on the design of the system, and are less concerned with, or less able to, support prototype qualities like re-use, Each prototype approach has advantages and disadvantages evolution, or weaving together independently designed parts. [4]. The decision to develop a specific type of prototype, or This paper presents a model-oriented prototyping tool called not to develop a prototype at all, is based on a number of Umple that supports model driven engineering and overcomes factors where cost of the prototype is critical [5]. Moreover, some of the challenges related to prototyping in a modeling it is not unusually for a throwaway prototype to be turned environment. Umple allows end users to quickly model class into an evolutionary prototype and later refined into a final and state machine models and to incrementally embed imple- deliverable product. mentation artifacts. At any point in the modeling process, users can quickly generate a fully functional prototype that exposes modeling implications on the user interface, and allows stakeholders to quickly get a feel of how the full system will II. EMERGENCE OF MODEL-DRIVEN PRACTICES behave. Model driven software development, while may still be Index Terms—Modeling, Prototyping, UML. lower than generally accepted to be a best practice [6], is on the rise. The software industry is increasingly adopting software modeling to generate parts of, or complete, sys- I. INTRODUCTION tems. Model-centric software development brings chal- ROTOTYPING in the software industry plays an indis- lenges to prototyping: P pensible role. “The majority of software projects used 1) Models are generally more concerned with internal some kind of prototype” [1]. In early development activi- system components and behavior, rather than system ties, a throw-away prototype (also known as a software user interface, look and feel. spike [2] ) may be used to help in defining the system UML, a widely adopted modeling notation, is more con- scope, assess feasibility, cerned with the internal system design and behavior. UML models put less or no emphasis on user interface. Manuscript received October 9, 2001. (Write the date on which you submitted your paper for review.) This work was supported in part by the 2) Models do not easily evolve into complete systems. U.S. Department of Commerce under Grant BS123456 (sponsor and fi- There are significant challenges in model driven develop- nancial support acknowledgment goes here). Paper titles should be written ment of software. One major challenge is synchronizing in uppercase and lowercase letters, not all uppercase. Avoid writing long formulas with subscripts in the title; short formulas that identify the ele- generated code with source models, a practice generally ments are fine (e.g., "Nd–Fe–B"). Do not write “(Invited)” in the title. Full referred to as round-tripping [7]. Annotating models with names of authors are preferred in the author field, but are not required. Put information to guide prototype generation involves the same a space between authors’ initials. hurdle. F. A. Author is with the National Institute of Standards and Technolo- gy, Boulder, CO 80305 USA (corresponding author to provide phone: 3) Software modeling notations do not reduce the need for 303-555-5555; fax: 303-555-5555; e-mail: author@ boulder.nist.gov). prototyping. S. B. Author, Jr., was with Rice University, Houston, TX 77005 USA. He is now with the Department of Physics, Colorado State University, Fort Whether they are throw-away or evolutionary, prototypes Collins, CO 80523 USA (e-mail: [email protected]). are used to brainstorm ideas related to the system, explore and estimate effort. In later stages, an evolutionary proto- different designs, and expose the look and feel of the system type (sometimes called model prototype, or in an agile con- early on in the development life cycle. Prototypes are par- PAPER IDENTIFICATION NUMBER: 40 ticularly useful for the business domain stakeholders who Throw-away prototypes are cost sensitive. They are an im- typically do not, and need not, understand software model- portant aspect of exploring a design alternative or new ing notations. Therefore, there is a need to generate tangi- technology, but they should be used sparingly. Stakeholders ble artifacts, whether they are screen mock-ups or executa- are generally unwilling to invest any significant amount of ble programs. Models, on their own, do not satisfy this effort into throw-away prototypes. Therefore, documenta- need. tion is even further minimized, increasing the risk of losing 4) Software modelers do not fully understand the conse- the lessons learned. quences of their models Evolutionary prototypes evolve into a final working prod- Our previous research indicates that modelers quite often uct. Stakeholders are more willing to invest effort and time create models that do not quite reflect how the system is into evolutionary prototypes as the effort is maintained intended to behave [8]. within the project. Lessons learned are better documented and maintained. This class of prototypes is becoming more 5) There are limitations in existing approaches to proto- attractive for the following reasons: type generation from UML models Existing prototyping approaches rely on one specific model- 1) Iterative development methodologies advocate the de- ing notation for code generation. However, in typical soft- velopment of small executable deliverables. These ware projects, there are more than one modeling notation to types of methodologies blend well with evolutionary describe the same system (e.g. a class diagram, an activity prototype-oriented methodologies. diagram and a state diagram). It is therefore desirable to 2) The technology needed to support evolutionary proto- generate prototypes from a number of related aspects of a typing is beginning to emerge [10] model. In addition, annotation of modeling artifacts specif- Because models, especially in iterative development metho- ically to support prototype generation is not desirable since dologies, are continuously updated and enhanced, it is im- models are continuously updated. Unless the annotations portant to be able to generate prototypes from incomplete are closely integrated into the modeling notations, mainten- models. Generating artifacts from an incomplete model will ance of such annotations quickly becomes time consuming. inevitably require some development intervention to fill in the gaps to produce a tangible artifact that can be used as a prototype. Such effort can be wasted if the underlying tools III. PROTOTYPING and development processes do not accommodate iterative development. The level of completeness in a prototype is a major factor of success. For example, Jones states “The fact that the proto- type was fully functional was critical to its success in elicit- ing requirements” [9]. However, the cost of developing a IV. UMPLE HIGH LEVEL APPROACH prototype and the level of completeness in a prototype are To support an environment for rapid development of model- proportional. Therefore, it is important to define what as- centric systems, it is essential to support the development of pects of the functionality of the prototype are most impor- high system aspects, as well as low level algorithmic speci- tant so that stakeholders can focus on them. fications at the same time. “Complete prototypes can sel- We consider the following properties of prototypes to be dom be produced exclusively with generators and reusable crucial: software. Highly complex parts still need to be written by 1) Accurate reflection of system components and data hand” [11]. This is the Umple approach. 2) Accurate reflection of current system design directions, Umple combines high level system abstractions and low and contribution to future design and implementation level specifications in the same development artifacts, mak- decisions. ing it possible to both design the system, and incrementally add developed components. In addition, Umple combines 3) Quick and cheap generation of a prototype, since the the modeling of class and state machine models and support cost (effort and time) associated with prototyping is a prototype generation from both modeling notations. major factor behind the level of completeness (fidelity) of a prototype. Umple’s complete syntax and grammar is maintained on- line. We also make available a light version of Umple to 4) Maximize potential of reuse and composition. illustrate the approach and concept [12]. 5) Support of different levels of abstraction 6) Support of incremental development of features A. Modeling and Prototyping Approach Creating models in a typical visual environment can be a demanding task, especially in cases of large models. PAPER IDENTIFICATION NUMBER: 40 Mouse-centric approaches require multiple fine tuning of tutes a key, or use the Umple defaults. Umple key syntax is lines and connections, and continuous dragging and moving as follows:
Load more

Recommended publications
  • Xtuml: Current and Next State of a Modeling Dialect
    xtUML: Current and Next State of a Modeling Dialect Cortland Starrett [email protected] 2 Outline • Introduc)on • Background • Brief History • Key Players • Current State • Related Modeling Dialects • Next State • Conclusion [email protected] 3 Introduc)on [email protected] 4 Background • Shlaer-Mellor Method (xtUML) – subject maers, separaon of concerns – data, control, processing – BridgePoint • data modeling (Object Oriented Analysis (OOA)) • state machines • ac)on language • interpre)ve execu)on • model compilaon [email protected] 5 History • 1988, 1991 Shlaer-Mellor Method published by Stephen Mellor and Sally Shlaer. • 2002 Executable UML established as Shlaer-Mellor OOA using UML notation. • 2004 Commercial Corporate Proprietary Licensed. • 2013 BridgePoint xtUML Editor goes open source under Apache 2.0. • 2014 all of BridgePoint (including Verifier and model compilers) goes open source under Apache and Creative Commons. • 2015 Papyrus Industry Consortium and xtUML/BridgePoint contribution • 2015 OSS of alternate generator engine (community building) • 2016 Papyrus-xtUML (BridgePoint) Eclipse Foundation governance • 2016 OSS contributions from industry, university and individuals [email protected] 6 Key Players • Saab • UK Crown • Agilent • Ericsson • Fuji-Xerox • Academia [email protected] 7 Current State • body of IP • self-hosng • Papyrus (and Papyrus Industry Consor)um) [email protected] 8 Related Dialects • MASL • Alf • UML-RT [email protected]
    [Show full text]
  • VI. the Unified Modeling Language UML Diagrams
    Conceptual Modeling CSC2507 VI. The Unified Modeling Language Use Case Diagrams Class Diagrams Attributes, Operations and ConstraintsConstraints Generalization and Aggregation Sequence and Collaboration Diagrams State and Activity Diagrams 2004 John Mylopoulos UML -- 1 Conceptual Modeling CSC2507 UML Diagrams I UML was conceived as a language for modeling software. Since this includes requirements, UML supports world modeling (...at least to some extend). I UML offers a variety of diagrammatic notations for modeling static and dynamic aspects of an application. I The list of notations includes use case diagrams, class diagrams, interaction diagrams -- describe sequences of events, package diagrams, activity diagrams, state diagrams, …more... 2004 John Mylopoulos UML -- 2 Conceptual Modeling CSC2507 Use Case Diagrams I A use case [Jacobson92] represents “typical use scenaria” for an object being modeled. I Modeling objects in terms of use cases is consistent with Cognitive Science theories which claim that every object has obvious suggestive uses (or affordances) because of its shape or other properties. For example, Glass is for looking through (...or breaking) Cardboard is for writing on... Radio buttons are for pushing or turning… Icons are for clicking… Door handles are for pulling, bars are for pushing… I Use cases offer a notation for building a coarse-grain, first sketch model of an object, or a process. 2004 John Mylopoulos UML -- 3 Conceptual Modeling CSC2507 Use Cases for a Meeting Scheduling System Initiator Participant
    [Show full text]
  • A Dynamic Analysis Tool for Textually Modeled State Machines Using Umple
    UmpleRun: a Dynamic Analysis Tool for Textually Modeled State Machines using Umple Hamoud Aljamaan, Timothy Lethbridge, Miguel Garzón, Andrew Forward School of Electrical Engineering and Computer Science University of Ottawa Ottawa, Canada [email protected], [email protected], [email protected], [email protected] Lethbridge.book Page 299 Tuesday, November 16, 2004 12:22 PM Abstract— In this paper, we present a tool named UmpleRun 4 demonstrates the tool usage. Subsequent sections walk that allows modelers to run the textually specified state machines through an example of instrumenting our example system and under analysis with an execution scenario to validate the model's performing dynamic analysis. dynamic behavior. In addition, trace specification will output Section 8.2 State diagrams 299 execution traces that contain model construct links. This will permit analysis of behavior at the model level. II. EXAMPLE CAR TRANSMISSION MODEL TO BE EXECUTED In this section, we will present the car transmission model Keywords— UmpleRun; Umple; UML; MOTL; stateNested machine; substates that and will guard be conditions our motivating example through this paper. It will execution trace; analysis Aalso state be diagram used to can explain be nested Umple inside and a state.MOTL The syntax. states of The the innerCar diagram are calledtransmission substates model. was inspired by a similar model in I. INTRODUCTION LethbridgeFigure 8.18 and shows Lagani a stateère’s diagram book [4] of. anThe automatic model consists transmission; of at the top one class with car transmission behavior captured by the state Umple [1,2] is a model-oriented programming language level this has three states: ‘Neutral’, ‘Reverse’ and a driving state, which is not machine shown in Fig.
    [Show full text]
  • State and Activity Diagrams in UML Last Revised December 4, 2018 Objectives: 1
    CPS122 Lecture: State and Activity Diagrams in UML last revised December 4, 2018 Objectives: 1. To show how to create and read State Diagrams 2. To introduce UML Activity Diagrams Materials: 1. Answers to quick check questions from chapter 7 plus chapter 8 a, b, g 2. Demonstration of “Racers” program 3. Handout and Projectable on Web: State diagram for Session 4. Handout: Code for Session class performSession() method 5. Projectable of text figures 7.12, 7.13 6. Handout of Activity diagram for Racers 7. Projectable of text figure 8.10 I. Introduction A.Go over quick check questions chapter 7 + chapter 8 a, b, g only B. We have drawn a distinction between the static aspects of a system and its dynamic aspects. The static aspects of a system have to do with its component parts and how they are related to one another; the dynamic aspects of a system have to do with how the components interact with one another and/or change state internally over time. C. We have been looking at one aspect of the dynamic behavior of a system - the way various objects interact to carry out the various use cases. We have looked at two ways of describing this: 1. Sequence diagrams 2. Communication diagrams D.We now want to look two additional aspects of dynamic behavior !1 1. How an individual object changes state internally over time. a) Example: As part of doing the domain analysis of a traffic light system, it is important to note that individual signals go through a series of states in a prescribed order - modeled by the following state diagram: ! (Note: this is correct for the US but not for all countries in the world!) An important “business rule” that any traffic light system must obey is that the light must be yellow for a certain minimum period of time (related to vehicle speed in the intersection) between displaying green and displaying red.
    [Show full text]
  • Part I Environmental Diagrams
    Adaptive Software Engineering G22.3033-007 Session 3 – Sub-Topic Presentation 1 Use Case Modeling Dr. Jean-Claude Franchitti New York University Computer Science Department Courant Institute of Mathematical Sciences 1 Part I Environmental Diagrams 2 1 What it is • Environmental Diagram Rent Video Video Store Pay Information System Employees Clerk Customer Payroll Clerk 3 What it is • A picture containing all the important players (Actors) • Includes players both inside and outside of the system • Actors are a critical component • External events are a second critical component 4 2 Creating the Diagram • To create an environmental diagram • 1. Identify all the initiating actors • 2. Identify all the related external events associated with each actor 5 Why it is used • A diagram is needed to show the context or scope of the proposed system • At this time actors and external events are the critical components • It is helpful to include all the participants as well 6 3 Creating the Diagram • 3. Identify all the participating Actors • These actors may be inside (internal) or outside (external) to the system 7 Creating the Diagram • Examples of an internal actor – Clerk who enters the purchase into a Point of Sale terminal – Clerk who places paper in the printer – Accountant who audits report 8 4 Creating the Diagram • Examples of an external actor – Accountant who audits report – A credit authorizing service – A DMV check for renting a car 9 Creating the Diagram •4.Draw a cloud • 5. Then draw initiating actors on the left of the cloud • 6. Then draw participating external actors outside the cloud • 7.
    [Show full text]
  • Verification of UML State Diagrams Using a Model Checker
    Verification of UML State Diagrams using a Model Checker A Manuscript Submitted to the Department of Computer Science and the Faculty of the University of Wisconsin-La Crosse La Crosse, Wisconsin by Yiwei Zou in Partial Fulfillment of the Requirements for the Degree of Master of Software Engineering August, 2013 Verification of UML State Diagrams using a Model Checker By Yiwei Zou We recommend acceptance of this manuscript in partial fulfillment of this candidates re- quirements for the degree of Master of Software Engineering in Computer Science. The candidate has completed the oral examination requirement of the capstone project for the degree. Dr.Kasi Periyasamy Date Examination Committee Chairperson Dr.Mao Zheng Date Examination Committee Member Dr.Tom Gendreau Date Examination Committee Member ii Abstract Zou, Yiwei, Verification of UML State Diagrams using a Model Checker, Master of Software Engineering, August 2013. (Advisor: Kasi Periyasamy, Ph.D). This manuscript describes the process of verifying the UML state diagrams by using model checker. A UML state diagram describes the behavior of an object which includes a sequence of states that the object visits during its lifetime. Verification of UML state dia- gram is important because if one state diagram is incorrect, the object’s behavior will not be displayed correctly which leads to incorrect coding and eventually may lead to the possible failure of the system. However, it is hard to verify UML state diagram without the aid of other tools. Therefore, model checker is introduced to verify the UML state diagram. Since model checkers use different syntax, one needs to convert state diagrams from UML tools to the syntax used by the model checker.
    [Show full text]
  • Mastering the Unified Modeling Language -- State Transition Diagrams
    Mastering the Unified Modeling Language -- State Transition Diagrams -- © Josef Schiefer, IBM Watson Outline nested state diagrams States & Transitions Combinatorial Explosion concurrent state machines Solution: Statecharts Statecharts messages ... UML State Diagrams 12/7/2000 - v2 states Stubbed Transitions transitions Synchronization events Concurrency vs. Orthogonality Diagram Elements UML State Machines actions History Indicator guards Sending Messages conditions Compound Transitions UML State Machines 1 Introduction to State Diagrams Interaction diagrams are very good for communication – between clients and designers – between designers and other designers – between designers and implementors But they are not part of the constructive core – Constructive core means that part from which an actual implementation could be generated The constructive core of the UML is – class diagrams (for the static part) – state diagrams (for the dynamic part) State diagrams can bescribe very complex dynamic behavior UML State Machines Elements of State Diagrams The basic elements of state diagrams are – states – the state in which the object finds itself at any moment – transitions – take the object from one state to another – events – cause the transition from one state to another – actions – take place as a result of a transition In the UML, many other extensions have been added, such as: – generalization/Inheritance among events (i.e. a mouse click and keyboard input as subclasses of user interface events) – hierarchical diagrams for managing complexity (from StateCharts) – guards – conditions on transitions State Diagrams should only be used for objects with significant dynamic behavior UML State Machines 2 Types of Events ChangeEvent (i.e.: when(x>y)) – A change event models an event that occurs when an explicit boolean expression becomes true as a result of a change in value of one or more attributes or associations.
    [Show full text]
  • Activity Diagram in UML
    6. UML Activity Diagrams Page 1 of 5 Activity Diagram in UML In the previous article, we learned about State diagrams, the notations to be used in State diagrams, their significance, and how to build a State diagram for a specific scenario in our Courseware Management system. In this article, we will cover the next dynamic diagram—the Activity diagram. By the end of this article, you will know what an Activity diagram is, what its elements are, and you will be able to create Activity diagrams for your system. Basics The easiest way to visualize an Activity diagram is to think of a flowchart of a code. The flowchart is used to depict the business logic flow and the events that cause decisions and actions in the code to take place. Activity diagrams represent the business and operational workflows of a system. An Activity diagram is a dynamic diagram that shows the activity and the event that causes the object to be in the particular state. So, what is the importance of an Activity diagram, as opposed to a State diagram? A State diagram shows the different states an object is in during the lifecycle of its existence in the system, and the transitions in the states of the objects. These transitions depict the activities causing these transitions, shown by arrows. An Activity diagram talks more about these transitions and activities causing the changes in the object states. Defining an Activity diagram Let us take a look at the building blocks of an Activity diagram. Elements of an Activity diagram An Activity diagram consists of the following behavioral elements: Element and its description Symbol Initial Activity: This shows the starting point or first activity of the flow.
    [Show full text]
  • Capstone Software Engineering Students Can Develop a High-Quality Complex System: a Case Study with Umple
    Proceedings 2019 Canadian Engineering Education Association (CEEA-ACEG19) Conference CAPSTONE SOFTWARE ENGINEERING STUDENTS CAN DEVELOP A HIGH-QUALITY COMPLEX SYSTEM: A CASE STUDY WITH UMPLE Timothy C. Lethbridge University of Ottawa [email protected] Abstract – Umple is an open-source programming UmpLe can be run OnLine, in EcLipse, in VisuaL Studio technology developed almost entirely by students, the Code and in severaL other tooLs. It can aLso be used in a majority of whom were working on it as their capstone classic manner as a command-line tool. project through a program called UCOSP. We describe UmpLe is targeted for educators who teach modeling our development process for Umple that has provided a [3][4], for students, and for open source developers who rich educational experience for the students, while at the want to buiLd systems that require low coding effort. The same time continually improving Umple’s quality. We core idea is that the high-level abstractions reduce the also describe features of Umple that have been designed amount of boiLerplate (repetitive) code that needs to be to facilitate its use in teaching software engineering. written, whiLe at the same time enabLing deveLopers and students to think at a higher level and to visualize their Keywords: Capstone project, open source, software code. UmpLe is a textuaL Language, but its high-level engineering, colLaboration, modeL-driven development abstractions can also be rendered and edited as graphs. UmpLe’s online user manual [5], if printed, amounts to 1. INTRODUCTION 300 pages. The OpenHub code analysis system [6] points out that 102 people have contributed a miLLion Lines of We describe our approach that has enabled successive code to UmpLe and suggests they have spent 286 person- groups of students to engineer and evolve a complex, years of effort on it based on its apparent complexity.
    [Show full text]
  • UML UML (Unified Modeling Language)
    CS189A/172 UML UML (Unified Modeling Language) • Combines several visual specification techniques – use case diagrams, component diagrams, package diagrams, deployment diagrams, class diagrams, sequence diagrams, collaboration diagrams, state diagrams, activity diagrams • Based on object oriented principles and concepts – encapsulation, abstraction – classes, objects • Semi-formal – Precise syntax but no formal semantics – There are efforts in formalizing UML semantics • There are tools which support UML – Can be used for developing UML models and analyzing them Examples for UML Tool Support • IBM’s Rational Rose is a software development tool based on UML. It has code generation capability, configuration management etc. – http://www-01.ibm.com/software/awdtools/developer/rose/ • Microsoft Visio has support for UML shapes and can be used for basic UML diagram drawing. • ArgoUML is an open source tool for developing UML models – http://argouml.tigris.org/ • USE is an open source tool which supports UML class diagrams and Object Constraint Language – http://www.db.informatik.uni-bremen.de/projects/USE/ • yUML is an easy to use tool for drawing UML diagrams. Supports class, activity and use-case diagrams – http://yuml.me/ UML References • There are lots of books on UML. The ones I used are: – “UML Distilled,” Martin Fowler • The examples I use in this lecture are from this book – “Using UML,” Perdita Stevens – “UML Explained,” Kendall Scott – “UML User Guide,” Grady Booch, James Rumbaugh, Ivar Jacobson • The Object Management Group (OMG,
    [Show full text]
  • Important Java Programming Concepts
    Appendix A Important Java Programming Concepts This appendix provides a brief orientation through the concepts of object-oriented programming in Java that are critical for understanding the material in this book and that are not specifically introduced as part of the main content. It is not intended as a general Java programming primer, but rather as a refresher and orientation through the features of the language that play a major role in the design of software in Java. If necessary, this overview should be complemented by an introductory book on Java programming, or on the relevant sections in the Java Tutorial [10]. A.1 Variables and Types Variables store values. In Java, variables are typed and the type of the variable must be declared before the name of the variable. Java distinguishes between two major categories of types: primitive types and reference types. Primitive types are used to represent numbers and Boolean values. Variables of a primitive type store the actual data that represents the value. When the content of a variable of a primitive type is assigned to another variable, a copy of the data stored in the initial variable is created and stored in the destination variable. For example: int original = 10; int copy = original; In this case variable original of the primitive type int (short for “integer”) is assigned the integer literal value 10. In the second assignment, a copy of the value 10 is used to initialize the new variable copy. Reference types represent more complex arrangements of data as defined by classes (see Section A.2).
    [Show full text]
  • Systems, Views and Models of UML∗
    Systems, Views and Models of UML∗ Ruth Breu, Radu Grosu, Franz Huber, Bernhard Rumpe, Wolfgang Schwerin email: {breur,grosu,huberf,rumpe,schwerin} @informatik.tu-muenchen.de Technische Universit¨atM¨unchen Arcisstr. 21 D-80290 M¨unchen, Germany Abstract In this paper we show by using the example of UML, how a soft- ware engineering method can benefit from an integrative mathemat- ical foundation. The mathematical foundation is given by a mathe- matical system model. This model provides the basis both for inte- grating the various description techniques of UML and for implement- ing methodical support. After describing the basic concepts of the system model, we give a short overview of the UML description tech- niques. Then we show how they fit into the system model framework and sketch an approach to structure the UML development process such that it provides methodological guidance for developers. 1 Introduction – Why Formalization? “The nice thing about graphical description techniques is that everyone un- derstands them, the bad thing, however, is that everyone understands them in a different way.” This often heard quote captures a main property of mod- eling techniques using semi-formal, mostly graphical notations, beginning with the early structured modeling techniques and prevalent until today’s object-oriented methods. The diagrammatic notations used here seem easily comprehensible for everyone dealing with software development. Experience ∗ This paper originates from the SysLab project, which is supported by the DFG under the Leibnizprogramme and by Siemens-Nixdorf. [BGH+98b] R. Breu, R. Grosu, F. Huber, B. Rumpe, W. Schwerin. Systems, Views and Models of UML.
    [Show full text]