Please find below examples of some pages of the manual "Project Development with UML and Enterprise Architect"

UML is a standardised graphical display format for the visualisation, specification, design and documentation of (software) systems. It offers a set of standardised diagram types with which complex data, processes and systems can easily be arranged in a clear, intuitive manner.

UML is neither a procedure nor a process; rather, it provides a “dictionary” of symbols – each of which has a specific meaning. It offers diagram types for object-oriented analysis, design and programming, thereby ensuring a seamless transition from requirements placed on a system to final implementation. Structure and system behaviour are likewise shown, thereby offering clear reference points for solution optimisation.

One major aspect of UML is the ability to use diagrams as a part of project documentation. These can be utilised in various ways in the most diverse kinds of documents; for example, Use Case Diagrams used in describing functional requirements can be specified in the requirements definition. Classes or component diagrams can be used as software architecture in a design document. As a matter of principle, UML diagrams can be used in practically any technical documentation (e.g. test plans) while also serving as part of the user handbook.

Despite the fact that the idea of object orientation is more than 30 years old, and the development of object-oriented programming languages spans almost the same length of time, the first books on object-oriented analysis and design methods didn't appear until the early 1990's. The godfathers of this idea were Grady Booch, Ivar Jacobson and James Rumbaugh. Each of these three “veterans” had developed his own method, each one specialised in and limited to its own area of application.

In 1995 Booch und Rumbaugh began to merge their methods into a common Unified Method (UM) notation. The Unified Method was soon renamed as Unified Modeling Language (UML), a more adequate term since it is mostly concerned with the unification of the graphical presentation and semantics of modelling elements, and does not describe an actual method. Indeed, “modelling language” is basically just another term for notation.

A short time later Ivar Jacobson joined in the foray and his Use Cases were soon integrated. From that point on, these three pioneers called themselves the “Amigos”.

Although the methods of Booch, Rumbaugh and Jacobson were already very popular and held a large market share, the Unified Modeling Language (UML) became a quasi-standard. Finally, in 1997, UML Version 1.1 was submitted to the Object Management Group (OMG) for standardisation, and accepted. The versions 1.2 to 1.5 both contain several important corrections. In 2004, Version 2.0 was approved with many key modifications and extensions as the new standard. (Source: OOSE)

The use of UML as a “common language” leads to an improvement in cooperation between technical and non-technical competencies like project leaders, business analysts, software architects, designers and developers. It helps in the better understanding of systems, in revealing simplification and/or recoverability options, and in the easier recognition of possible risks. Through early detection of errors in the analysis and design phase of a project, costs can be reduced during the implementation phase. The advantages associated with Round-Trip Engineering offer developers the ability to save a great deal of time.

Although UML was initially developed for the modelling of software systems, it can also be implemented for any organisational project. By allowing processes to be visualised, they can subsequently be analysed and improved.
UML Standard
The official specification for UML 2.1 is a complex work of over one thousand pages (www.uml.org), arranged into the following sub-components:
• Infrastructure (Architectural Core, Profiles, Stereotypes),
• Superstructure (Static and Dynamic Modelling Elements),
• OCL (Object Constraint Language) and
• Diagram Interchange (UML Exchange Format)

The present book covers only the most important UML core elements and in no way constitutes a complete and comprehensive source of reference.

Enterprise Architect uses the extension mechanism (Profile) designated in UML to provide new elements – such as an element for Requirement – as well as additional diagram types. Likewise, extended properties – such as test windows, job orders, risks, etc. – can also be prepared. Thereby, a UML-based tool emerges which, together with a likewise integratable development platform, enables comprehensive project work including requirements management, operational documentation and more.

Officially, in UML there is no diagram overview or categorisation. Although UML models and the Repository behind the diagrams are defined in UML, diagrams - or special Repository views - can be relatively freely specified.

In UML, a diagram is actually more of a collection of notation elements. It is in this way, for example, that the package diagram describes the package symbol, the Merge relationship, etc. A Class diagram describes classes, associations, etc. Naturally, however, classes and packages may still be displayed together in one diagram.

A diagram is composed of a diagram space enclosed by a rectangle with a diagram header in the upper left corner. This diagram header shows the diagram type (optional), diagram name (obligatory) and parameter (optional).

The diagram type is, for example, sd for Sequence Diagram, or cd for Class Diagram. The Parameter field is important for customisable models.

To many who are new to UML, the question soon arises as to how these diagrams are actually associated with one another. This is a very legitimate question; however, UML itself does not give us a clear answer. It is primarily the software development methodology, or rather the background processes thereof, which can best answer this question. One possible approach concerning the order, or phases of a project, in which the diagrams can be implemented can be shown as follows: 

Use Case Diagram	Analysis Phase
which use cases are included in the application to be generated which actors are released by this use case what use case dependencies are interconnected, e.g. o   whether one use case is contained within another o   whether one use case represents a specialisation of another o   whether one existing use case is extended by a second
Activity Diagram	Analysis & Design Phase
which steps will be taken within a use case what state transition the involved objects experience when handling changes from one activity to another
Package Diagram	Analysis & Design Phase
into which packages the application can be subdivided which packages allow further subdivision what levels of communication must be realised between packages
Class Diagram	Analysis & Design Phase
which classes, components and packages are involved via what type of communication cooperation is to take place which methods and properties do the classes require what are the minimum and maximum numbers of objects to be linked which classes are responsible for multiple objects as a container
Sequence Diagram	Design Phase
which methods are responsible for communication between selected objects how the chronological cycle of method calls between selected objects is to occur which objects in a sequence are to be newly created or destroyed
Communication Diagram	Design Phase
how selected objects communicate with one another in which order the method calls are carried out which alternative method calls exist should they be required
State Diagram	Design Phase
what state transitions are released by which method call which condition will be assumed following object creation which methods destroy the object
Component Diagram	Design Phase
how are soft and/or hardware parts capsuled with defined function and defined interfaces which components have interfaces to one another what software parts create functionality in components
Deployment Diagram	Design Phase
which PCs in the application work together what application module will be run on which PC on which communication options should cooperation be based

If necessary, the order of diagram use may deviate from that shown in the table because, for example, the division of the work of multiple programmers cannot be managed. In such case, the package diagram can first be created with the class diagram. This order serves to show only one possibility of how you can realise a model of your application, and how the phase transitions can be formulated.

The area of application will also have an effect; the resulting diagram order of implemented diagrams for a business automation job will differ considerably from that of an embedded task job.

A project cycle can roughly be divided into five sections, independent of the user’s chosen project approach (from V-model to iterative prototyping, etc.):

• Analysis: Determination of current status, determination of the services to be performed and/or results to be reached, and the solutions to be brought about in functional terms.
• Design: Solution identification and solution specification in increasing detail.
• Implementation: Realisation of the solution
• Testing: Quality assurance
• Operation: Startup and continued operation

In practise, the subtasks are carried out more or less chronologically overlapped, depending upon project approach. In any case, “Perform Tests” appears overlapped chronologically.

The dark-gray “UML Basic Grammar” rectangle refers to 13 basic UML diagrams and the scope of UML basic elements. In the analysis phase, one notices that nearly all companies have ISO certification for their business processes - at least those companies that document their processes. This documentation utilises varied process designs, e.g. EPK or BPMN in the Anglo-American world, preferred to the possibly more puritanical UML Activity element set. BPMN has therefore been built into EA - the EPK symbols can be easily extended with a profile.

On the other side of the UML Basic Grammar rectangle, one notices that UML itself doesn’t reach any conclusions concerning reverse engineering. Therefore, the “Run Analysis“ and “Run Implementation“ use cases have been deliberately drawn over the edge of the UML Basic Grammar system border.

Enterprise Architect 7 addresses – based on UML profiles – the complete project cycle: Therefore, EA has supplemental symbols and diagram types.

Requirements Management has been included; this means EA can handle this topic without additional tools with full integration and traceability, while reconciliation with external Requirements Management Systems can be carried out, whether by XMI comparison or via the included Automation Interface. An integrative, importable extension to Doors® is also available.

Basic project management functionality is also included; it would make no real sense to record separate information on implementation status. There are also options here to establish a link to Gantt programs.

• Table of content
• Index 

Interested in a full version of our Book, you can order it online.

ISBN-10:3-9502692-1-5
ISBN-13:978-3-9502692-1-5