The FUJABA environment

  • Authors:
  • Ulrich Nickel;Jörg Niere;Albert Zündorf

  • Affiliations:
  • Computer Science Dep., University of Paderborn, Warburger Str. 100, 33098 Paderborn, Germany;Computer Science Dep., University of Paderborn, Warburger Str. 100, 33098 Paderborn, Germany;Computer Science Dep., University of Paderborn, Warburger Str. 100, 33098 Paderborn, Germany

  • Venue:
  • Proceedings of the 22nd international conference on Software engineering
  • Year:
  • 2000

Quantified Score

Hi-index 0.00

Visualization

Abstract

However, a single collaboration diagram is usually not expressive enough to model complex operations performing several modifications at different parts of the overall object structure. Such series of modifications need several collaboration diagrams to be modeled. In addition, there may be different situations where certain collaboration diagrams should be executed and others not. Thus, we need additional control structures to control the execution of collaboration diagrams. In our approach we combine collaboration diagrams with statecharts and activity diagrams for this purpose. This means, instead of just pseudo code, any state or activity may contain a collaboration diagram modeling the do-action of this step.Figure 1 illustrates the main concepts of Fujaba. Fujaba uses a combination of statecharts and collaboration diagrams to model the behavior of active classes. A combination of activity diagrams and collaboration diagrams models the bodies of complex methods. This integration of class diagrams and UML behavior diagrams enables Fujaba to perform a lot of static analysis work facilitating the creation of a consistent overall specification. In addition, it turns these UML diagrams into a powerful visual programming language and allows to cover the generation of complete application code. During testing and maintenance the code of an application may be changed on the fly, e.g. to fix small problems. Some application parts like the graphical user interface or complex mathematical computations may be developed with other tools. In cooperative (distributed) software development projects some developers may want to use Fujaba, others may not. Code of different developers may be merged by a version management tool. There might already exist a large application and one wants to use Fujaba only for new parts. One may want to do a global search-and-replace to change some text phrases. One may temporarily violate syntactic code structures while she or he restructures some code. For all these reasons, Fujaba aims to provide not just code generation but also the recovery of UML diagrams from Java code. One may analyse (parts of) the application code, recover the corresponding UML diagram (parts), modify these diagram (parts), and generate new code (into the remaining application code). So far, this works reasonable for class diagrams and to some extend for the combination of activity and collaboration diagrams. For statecharts this is under development.The next chapters outline the (forward engineering) capabilities of Fujaba with the help of an example session.