RUP (Rational Unified Process) is a software development process. Rational Software corporation and its ideologists, the pillars of object-oriented analysis and design - Grady Booch, Ivar Jacobson and James Rumbaugh - created RUP as a set of practically tested principles, methods and processes providing quality and efficiency for software development projects. Physically, RUP is a knowledge base containing the descriptions of roles of all participants of the development process, as well as their activities, responsibilities, templates of documents used by process participants to communicate, model standards, and plenty of other vital information.

The main features of RUP are:

1. Unambiguous separation of developers' roles in the process. The following groups of developers are usually differentiated: analysts, developers, testers and managers. Separate roles are specified within each of these categories.
2. The following main groups of activities are determined: business modeling, requirements management, analysis and design (or simply design), implementation, testing, deployment, support, project management, change management and environment management.
3. The main development phases: inception, elaboration, construction and transition.
4. The iterative nature of the process: each phase can be split into several iterations, allowing more flexible process management;
5. Assigning performers for each activity;
6. Defining the mutual dependence of activities;
7. UML (Unified Modeling Language) as the common language for analysis and design;
8. Common modeling standards are defined in UML (within the RUP frame).

According to RUP, the software development process is composed of several basic processes which run in parallel and are constantly active. Moreover, it can be split into phases, which in turn can be split into iterations.

The diagram below sketches the time picture of process activities (according to phases):

Fig. 8. RUP phases and activities.

The development of a software product starts with the inception phase. At this stage the primary analysis of the customer's request is made and the draft of system architecture is elaborated. The most important activities at this stage are business modeling, requirements definition (requirements management), analysis and design, environment configuring.

Business modeling - building the model of business which the intended software system should automate. The business model consists of two parts: business use-cases model and business objects model. The first part describes the main scenarios or business processes and the activities performed within the given business. The second describes the structure and mutual relationships of objects and subjects participating in the business, the subject area and how the actions described in the business use-case model are actually performed. Both models are described in UML using object, use-case, state and activity diagrams. The business analysis also clarifies which scenarios and business objects will be automated as the result of implementing the software system.

The illustrations below provide examples of business object and business use-case diagrams:

Fig. 9. Business objects

Fig. 10. Business use-case

Requirements definition (or requirements management at later stages) - the activity aiming at developing an accurate specification of system requirements and at modifying this specification in respect to the changing conditions. At the inception stage the system functions are specified (the system functional requirements or the system use-cases) along with the set of requirements which are not system functions, but are essential to provide the customer's ability to use the system (non-functional requirements). The result of this stage is the document specifying the requirements to which the resulting system should conform - the software requirements specification, or SRS. The UML use-cases model (described by use-case diagrams) is a part of this document.

The next figure provides an example of a use-case diagram:

Fig. 11. System use-case diagram

Analysis and design is the activity aiming at developing the system architecture which would meet all the requirements and at modifying this architecture according to the changing requirements. The architectural model of the system is also based on UML and describes the details of the system internal organization which are essential for meeting all the requirements. The design stage details the architectural model, the internal structure and implementation particularities of all modules specified in the architectural model. If the design model is sufficiently accurate, it becomes possible to implement the system.

Environment configuration - the goal of this activity is to determine the components required for the development - both hardware (computers and other equipment) and software ones (developing environments, compilers, libraries, tools etc.).

The following two phases - elaboration and construction have much in similar. The goal of both is to create an operational product. Both can be split into several iterations resulting in presentation of intermediary results to the customer. But: the primary goal of the first phase is to detail system requirements and to guarantee that the customer's requirements were properly understood. Meanwhile, the second phase aims at developing the systems generally under the condition of fixed requirements. Sometimes both phases merge. The main activities at this stage are analysis and design, implementation and testing. The goal of implementation is to create individual software elements composing the system. The objective of testing is to verify the functionality of the whole system and its components and to check its accordance to the stated requirements, as well as checking for errors.

The last phase is the transition. This stage involves transferring the resulting system to the customer, installing, configuring and supporting it. Support may occur to be either a simple (e.g., assistance at program installation), or a tedious and time-consuming activity (for instance, constant analysis of changes in the client's business and customization of the system according to the changing requirements).

Apart from the already mentioned activities, there are also activities that are not clearly connected to specific phases. These activities keep going throughout the whole project lifecycle - configuration & change management and project management. The first implies the management of changes in the requirements and the related changes in the project architecture, design and environment; the second one deals with solving the arising managerial problems.

The main goal of developing the Zebra technology was to decrease the overall costs of software development and support. Another objective was to raise the competitive power of the products developed with this technology - thanks to greater flexibility and the ability to customize the product according to specific customer needs. Besides, the use of Zebra implies use of RUP or of a RUP-based development process.

These goals are achieved due to the following features of the product:

• Decrease of amount of manual coding in the project:
  The source code in Zebra is replaced with the source model. UML and Java are used to describe the internal structure and logic (Java is used mainly to describe elementary operations within the scenarios and objects described by UML). The advantage of this approach is that an essential amount of manual coding is replaced by correction of the original design model (which should be present in the project in any case). Moreover, this significantly accelerates prototyping of applications.
• Unambiguous separation of application software levels:
  Zebra architecture suggests to differentiate at least three application layers:
  • User Interface presentation layer, where the developer concentrates on visual presentation of user interface components;
  • UI logic layer, where main efforts are focused on implementing UI scenarios (the sequences of screens presented to the user), on interaction between UI components, flows of data and events between these components, data validation and translation of these data into data and events of the subsequent layer.
  • Business Logic layer, where scenarios and operations of the system subject area are implemented.
• Essential requirements to the application development cycle:
  Among the main stages of the development cycle which were described earlier, several are of special importance when using Zebra:
  • Phase of use-case analysis, when the system functional requirements and user roles are defined. These parameters are described by UML use-case diagrams composed of actors, use-cases and system usage scenarios.
  • Prototyping. At this stage (usually important for middle- and large-scale projects) functional prototypes and user interface prototypes are built. Zebra reduces the costs of both the current stage and the whole development process, since it allows to build prototypes more quickly, and then to re-use resulting UML models in further work on application development.
  • Implementation. If Zebra is used for the project, this stage will be tightly connected with the design stage. The design stage includes development of business scenarios and operations (Business Logic modeling) and of the user interface logic (UI logic modeling). Use of Zebra suggests visual development (using some kind of UML editor), which simplifies the understanding of the overall application logic by all team members, makes the application support easier and reduces the documenting costs (most parts of the model which will later on serve for code generation can be understood without detailed descriptions, which are usually required to make manually developed code more intelligible). Besides, automated code generation assures that all design solutions will be implemented exactly as originally planned.
• Simplified application support
  The costs of supporting the application are reduced due to:
  • Simplified training of new team members, since the application structure is always explicitly specified in UML (even when the documentation is missing);
  • Simplified debugging (less modifications made to the application) thanks to the requirements for modular design and layering imposed by Zebra on the development process.
  • Simplified application development under changing conditions (requirements).