Zebra technology: using UML in a system for automated development of large-scale software systems.

1. Introduction
2. Object-Oriented Analysis and Design
   1. Basic terms
3. UML
   1. Architecture and UML metamodels
   2. Basic terms
   3. UML Diagrams
4. RUP
5. Zebra
   1. Zebra architecture
   2. Zebra application
   3. Zebra language
   4. Example of creating an application with Zebra
6. Conclusions

This article is dealing with development of techniques for building large-scale software systems based on the object-orientation. The technology under discussion aims at using software based on UML and RUP in the development process. Its main objectives were to reduce software development costs and to improve the quality of the resulting products (middle- and large-scale software systems). The underlying ideas of this technology were to obtain operational code at all project phases (ideally, starting from the moment when the customer submits the system requirements) and to automate certain (ideally - all) stages of system development, particularly the coding stage.

Object-orientation is not a new concept. The first terms of object-oriented analysis and design (OOAD) appeared and evolved in the late sixties in the Simula67 language. Till present OOAD progressed in parallel with the general evolution of computers and computing technologies. OOAD provides better management of technological complications, which in turn allows to use incessantly raising levels of abstraction for system development - switching from objects to classes, then to class libraries and finally to sets of tools for rapid application development (RAD). OOAD increases the degree of code reuse, the resulting programs are more easily adapted to the changing conditions. Another advantage of OOAD is a more consistent model of software development process.

Another side of OOAD evolution is the development of techniques for modeling software (and not o.nly software) systems. The predecessors of object-oriented programming languages came into view in the middle of the seventies and continued to appear in the eighties, as long as the programmers and methodologists tested different approaches to OO analysis and design. In June 1996 the UML (Unified Modeling Language) specification v.0.9 was published, being a result of many years' efforts and the summary of prior expertise. UML proved to be of big interest and captured the attention of numerous organizations. The latter joined the consortium of UML partners established by Rational Software; the list of participants included HP, Microsoft, Oracle, Unisys and IBM. The result of interaction between these companies was the 1.0 version of UML - a strictly determined, expressive, powerful and widely applicable modeling language. Currently UML is widely used to model various systems in different fields (spanning from programming to business analysis).

When a large software (and not necessarily a software) system is created, not only the common language used to describe the system and its components is of importance, but also the proper efforts management and the interaction between the performers. Usually the arrangement of efforts is described in terms of processes - in our particular case, business processes. To avoid elaborating these processes each time from the scratch, the Rational Software corporation and its ideologists Grady Booch, Ivar Jacobson and James Rumbaugh created the RUP (Rational Unified Process) - a set of practically tested principles, methods and processes providing quality and efficient of efforts in software development projects. RUP uses UML terms to describe the standard set of roles, business processes, artifacts and other items required for software development.

This article describes the technology elaborated at Novosoft Inc. within the frame of the Zebra project. The target of the technology under consideration are the processes of developing large software products based on RUP, UML and Java. The main objectives of building this technology were to reduce overall development and support costs for middle- and large-scale software systems and to increase the competitive power of the resulting products due to greater flexibility and customization abilities.

One of ways to achieve this goal is the automation (either complete or partial) of certain stages of application development (at least for some application components). Currently the Zebra technology offers a tool for semi-automatic creation (generation) of Java code using the UML specification of the system to be developed.

Object-Oriented Analysis and Design (OOAD) is not a new concept. The first terms of OOAD appeared and evolved in late nineteen-sixties in the Simula67 language (developed by Kristen Nygaard and Ole-Johan Dahl at the Norway Computing Center). It is in Simula67 where the concepts of class, subclass and class procedure appeared for the very first time. In the middle of the seventies the Smalltalk language was created at Xerox research center in Palo Alto. It was the first complete and transparent OO language. All elements of the Smalltalk language were implemented as objects, the programming environment and culture were in accordance with the OO programming philosophy. Even at present Smalltalk is considered the most "pure" OO language.

Simula and Smalltalk gave birth to a new programming style, when data and procedures for processing these data are stored together, which significantly differs from the traditional procedural programming (as implemented in languages like C, Pascal, Fortran). Simula and Smalltalk were widely acknowledged by the academic audience, but rather not demanded by the majority of programmers, and OOP was not widely utilized for producing marketable systems. In the beginning of eighties, Bjarne Stroustrup (who worked at AT&T Bell Laboratories), created the C++ language - an object-oriented extension of the C language. It is after the commercial release of C++ that the object-oriented programming became widely recognized. At the end of the eighties OOP became a de-facto standard in the IT industry. Despite the advantages of the procedural programming for specific projects, we can generally state that OOP is currently the best technology for developing interactive user-oriented software systems - as well as for large- and middle-scale systems.

In the nineties and the beginning of 2000's the application developers need to satisfy the ever-growing complexity of requirements, to use ultimately complicate data structures and architectures, and to offer the services to greater amount of end-users. These reasons cause the developers to build more complex and large-scale systems. OOP provides better management of these technological difficulties. It allows to develop systems using constantly raising levels of abstraction - from objects to classes, then to class libraries, and finally to application development tools. OOP extends the degree of code reuse, the resulting programs are easily adapted to the changing conditions. Another advantage of OOP is a more consistent model of the software development process.

The main idea of OOP is the encapsulation of data along with the methods for processing these data within entities called objects. When we use this approach, the methods describe the behavior of these objects. The data are presented by the object's attributes - the object attributes are said to describe the object state.

Objects with identical behavior and with states described by the same set of attributes are grouped into classes. A class in this terms is the description of a group of objects.

The main features of object-orientation are encapsulation, messaging, inheritance and polymorphism.

• Encapsulation is the technique that hides the implementation details from the user by clearly separating the object's internal structure from its external presentation. This makes the final program insensitive to minor implementation changes. Encapsulation also implies combining the description of data structure with the description of behavior of objects and classes, thus making the system more transparent. E.g., in an OO system we can describe the Currency class which represents the amount of currency. The methods allowing to increase (add(Currency)), and to decrease (subtract(Currency))the amount of currency are defined for this class. If your system is properly designed, then the change of currency or accounting rules in your country (e.g. when you start using dollars and cents instead of only dollars in your reports) will affect only the implementation of the Currency class (for this particular example, the internal presentation of Currency by an integer should be replaced by a floating-point one).
• Messaging is the only method of interaction between objects in OOP. Calling a function which is a part of an object (i.e., an object method in OOP terms) is actually sending a message to an object. In the example above calling the add method for an object of the Currency class can be considered as sending the add message with a parameter (which is another object of the Currency class) to the object of the Currency class. This finally results in adding the value presented by the second object to the value presented by the first object (i.e., the value of the first object will be augmented).
• Inheritance allows to develop hierarchical systems of classes starting from the most generalized definitions and ending with the most detailed definitions. In other words, this provides the ability to re-use existing definitions when you create new ones. New classes can be regarded as subsets of objects determined by existing classes. Moreover, it also allows to separate data and functionality between the linked objects, thus avoiding repetitive implementation of identical functions. E.g., a Person class (describing an employee of the company) can be defined in your system. This class can have the attributes (birth_date, acceptance_date, salary) and methods (employ, dismiss, calculate_salary) which are common for all employees. Besides, there is always a Director which is, from one hand, a regular employee, but, from the other hand, (s)he also has some specific features-attributes (subordinates_list) and functions-methods (hire_new_employee). You could try to duplicate all the attributes and methods of the Person class in the Director class, but it is much easier (and more correct) to declare the Director class as the child of the Person class and to describe only its class-specific attributes and methods.
• Polymorphism allows to create structures that can be used with different, but similar types. Using this feature a designer can create common methods able to work with super-classes and at the same time usable for subclasses, thus making the code more flexible and extensible. The system will apply the proper method automatically, using the information about the method's operand type. Thus, in the previous example calculation of salary for a regular employee and for the Director can be implemented by different procedures (e.g. the employee's salary is fixed while the Director's salary depends upon the company profit). In this case, the calculate_salary method will be redefined in the Director class, and the process of calculation will be just calling this method for all objects of the Person class - including the object of a Director class.

Another aspect of OOP evolution was the development of techniques for modeling of software and other systems. The predecessors of OO modeling languages started to emerge in the middle of the seventies, and continued to appear in the eighties - as the programmers and the methodologists tested different approaches to object-oriented analysis and design. From 1989 till 1994 the amount of existing modeling languages increased from less then a dozen to over 50. Such a plenty of alternatives meant only that the majority of OO technique users were unable to select a language that would perfectly meet their requirements. In the middle of nineties, new OO modeling techniques combining the abilities and features of many of their predecessors were created: Booch'93 (named after its creator, Grady Booch), OMT-2 (Object Modeling Technique, created by Object Management Group) and OOSE (Object-Oriented Software Engineering, developed by "Objectory" in Sweden). Each of these solutions offered specific advantages: OOSE aimed at "use-cases " and was suitable for developing and modeling business processes, OMT-2 allowed to easily analyze and develop systems with complicated and intensive data flows, Booch'93 suited perfectly for the design and implementation phases of software development.

In October 1994 Grady Booch and Jim Rumbaugh at Rational Software Corporation started merging Booch and OMT. In October 1995 they presented a preliminary version of the "Unified Method" technique. At the same time, significant efforts were applied to elaborate an industry standard for the modeling languages market. In the beginning of 1995 Ivar Jacobson (at that time - CTO of Objectory) and Richard Soley (CTO of Object Management Group) coordinated common activities in the field of standardization at the OO techniques market. The first wide-scale agreement on elaborating the methodological standard was achieved in June 1995 at the meeting of chief methodologists held by OMG. OOSE became a part of Unified Method when the developer company ("Objectory") was acquired by Rational Software. Ivar Jacobson, the former owner of "Objectory", joined Booch and Rumbaugh in their unification efforts (later, this trio was nicknamed "Amigos"). The main reasons for creating the unified modeling language - UML - were the following:

• Obviously, the three existing techniques were independently evolving towards each other, so it would make sense to eliminate insignificant and disincentive differences;
• The unification of the three techniques would stabilize the OO methodologies market, thus allowing the developers to concentrate on finalizing the elements of an existing language -rather than dissipating efforts on creating new languages;
• The unified technique was supposed to circumvent the disadvantages of its predecessors and to bring together their benefits.

The main goals were also stated. The future language should allow:

1. To model systems (not only software ones) using object-oriented concepts;
2. To establish explicit relationships between both conceptual and executable artifacts (development process objects);
3. To handle scaling problems, which are natural for complex systems;
4. To be used by both humans and machines.

In June 1996 Booch, Rumbaugh and Jacobson published the UML specification v.0.9 and encouraged the community of programmers and methodologists to participate in discussing the language.

UML was of big interest and captured the attention of numerous organizations, which finally joined the UML partners consortium established by Rational Software. The list of participants included HP, Microsoft, Oracle, Unisys and IBM. The result of interaction between these companies was the 1.0 version of UML - a strictly determined, expressive, powerful and widely applicable modeling language. The standard was presented by OMG in January 1997. At the same time the additions presented by IBM, ObjecTime, Platinum Technology, Ptech, Taskon, Reich Technologies and Softeam were incorporated in the standard. This resulted in releasing the 1.1 version of UML (with more clearly stated semantics). These additions provided more exact descriptions of different language aspects - such as business modeling, constraints description language,