Overview

Setting up for a project means laying the foundation that enables team members to work on the same model at the same time. Developing complex systems requires that groups of analysts, architects, and developers have the ability see and access the "big picture" at the same time as they are working on their own portion of that picture-simultaneously. Successfully managing an environment in which multiple team members have different kinds of access to the same model requires:

• formulating a working strategy for managing team activity
• having the tools that can support that strategy

In the guidance that follows, these terms will be used:

Project refers to a file system location that is known to the Eclipse workspace and is used to store the Eclipse resources that are the work products of a development effort

Conceptual models are models that express abstract concepts like use cases, analysis classes, and design components. They are not tightly bound to implementation code. They are stored in files with .emx extensions. They are distinct from implementation models, which consist of implementation code itself, plus diagrams of the code that are stored in files with .dnx extensions. (You can think of an implementation model as equivalent to the project that contains the code and code diagrams.)

The following basic steps lay this foundation:

• Establishing the Role of Conceptual Modeling and the Modeling Work Breakdown
• Tailor Templates and Defaults (optional)
• Determine Model Partitioning Strategy
• Create Modeling Projects and Models

Establishing the Role of Conceptual Modeling and the Modeling Work Breakdown

Part of laying the foundation is determining how conceptual models will be used in the development effort. Will they drive development, or will they be used more retrospectively (e.g. as a form of documentation)?

If models will drive development, determine:

• What types of models (such as Use Case, Analysis, and Enterprise IT Design) will be used.
• The makeup (size and skill sets) of the conceptual modeling team.
• The anticipated scope of the conceptual modeling effort.
• How conceptual modeling work assignments will be apportioned among the team members.
• How likely it is that multiple members of the team will have to work concurrently in the same areas of the conceptual models.
• What configuration management tool will be used for storing and versioning conceptual model assets, and what the typical CM activities will be.

Another consideration is what kinds of conceptual models will be used. The tool provides a handful of model templates that can be used to instantiate new conceptual models of specific types such as Use Case Model, Analysis Model, and Enterprise IT Design Model. The templates typically provide a basic UML package structure, and some example content. They may also have certain UML2 profiles pre-applied.

Tailor Templates and Defaults (optional)

In the steps that follow, you create models using standard templates, that include a basic packaging structure that follows the Model Structure Guidelines for RSx.

You can optionally create your own specialized templates. In this way you can preset properties and options such as default fonts, colors, line styles, file storage options, the ways in which stereotypes and other information are presented. You can also define your own standard package structures and seed content, and have UML profiles of your choice (including profiles you create) pre-applied.

For more information, refer to Setting Up and Working with Models and Modeling Projects.

Determine Model Partitioning Strategy

Taking into account the modeling work breakdown you identified in the previous steps, and factoring in some other considerations that are discussed in the Team Development sections of online Help, determine a strategy for allocating conceptual models to physical modeling files.

The tool supports two main approaches for how to break logical model instances:

• a planned approach wherein you decompose the models at the outset, by creating multiple modeling files per model.
• an ad-hoc approach, based on model refactoring.

In the real world, a mix of these two approaches is more probable: even if the partitioning strategy has been planned in advance, there will be occasions when a model refactoring is necessary for improving team activities. For a detailed discussion about this topic, see the Model Structure Guidelines for RSx.

For more information, refer to Working in a Team Environment.

Create Modeling Projects and Models

The following describes the process for establishing a set of conceptual models for a development effort. Note that you will not necessarily create all of the projects and models at the outset - you may introduce them incrementally at various stages of the development effort.

• Create a UML Project. Give it a name that reflects the development tasks and work products it will support (e.g. "Timesheet Management System Models" or perhaps "Timesheet Management System Use Case Modeling Files")
• When you create the project you will be asked to choose a type of conceptual modeling file to be created in the project:
  • If your plan is to use a UML project per conceptual model type, then at this point you should select the desired model type for the project.
  • If your plan is to use a UML project to house more than one type of conceptual model, then the model you select at this point can be any of those types that you ultimately plan to house in the project.
  • Either way, choose a meaningful name for the new modeling file. The name should reflect the name of the solution being developed and the type of the model (e.g. "Timesheet Management System Use Case Model" or "Timesheet Management System Analysis Model"). If you plan to allocate the logical content of one conceptual model to multiple modeling files, the name of each modeling file should also reflect the subset of the logical content that is being housed in the file (e.g. "Timesheet Management System Employee Management Use Cases" or "Timesheet Management System Project Management Use Cases").
• Add additional modeling files to the project as needed
• Continue adding UML projects and adding additional modeling files to those projects until you have the set of UML projects and modeling files you need.

For a mapping between the RUP models and the tool specific ones and for a detailed description of the project types, see the Model Structure Guidelines for RSx.

For more information, refer to Setting Up and Working with Models and Modeling Projects.