Partitioning UML Models

With StP Model Management  

Mark Bell, Aonix

June 9, 2000

 

Introduction:  StP Model Management  is a feature of Aonix Software through Pictures (StP) that partitions and manages subsystems of a UML model.  It allows a UML model to be decomposed into subsystems, each of which can then be worked on separately whilst StP Model Management maintains the overall consistency of the model.  This means that an StP user can check a portion of a model out into a private workspace, work on it and check it back into the model in the safe knowledge that the overall integrity of the model is still intact. 

 

StP Model Management provides a means to check subsystems in and out of a version control or configuration management(CM) system.  It also provides for management of these subsystems by subsystem-ownership and control of the interfaces between subsystems. StP Model Management will automatically propagate logical ownership of subsystem constituents.  i.e. , in a Use Case diagram which has  a subsystem with Use Cases contained in it, then the scenarios attached to the Use Cases will also be owned by the subsystem . That is, when the subsystem is checked in or out the scenarios will be part of the subsystem.  On the other hand there may be diagrams whose logical ownership cannot be automatically determined. StP Model Management then allows you to individually select those diagrams and assign them to the desired subsystem.

This document describes the way in which StP supports  the creation, population and use of subsystems.

CONTENTS

1       Overview– Using Subsystems................................................................................................................ 2

2       Model Management Tree Browser.................................................................................................... 4

3       Defining a Subsystem.................................................................................................................................. 5

3.1        How the Subsystem Stereotype is Drawn.............................................................................. 6

1.1        Assign Model Elements to a Subsystem.................................................................................. 7

3.2................................................................................................................................................................................... 7

3.3        Automatic Propagation of Subsystem Ownership......................................................... 8

3.4        Manually Assigning Diagrams to Subsystems................................................................ 10

4       Subsystem Commands.............................................................................................................................. 11

4.1        Check Consistency of Subsystem............................................................................................... 11

4.2        Baseline of Subsystem...................................................................................................................... 13

4.3        Lock/Unlock of Subsystem............................................................................................................ 14

4.4        Restore of Subsystem....................................................................................................................... 14

4.5        Reconfigure Externals.................................................................................................................... 15

5       Known Issues and Limitations.......................................................................................................... 15

1        Overview– Using Subsystems

StP Model Management is a facility that allows a UML model to be partitioned into several pieces.  StP uses the subsystem construct (introduced in UML 1.3) to provide “containers” for these model partitions.  Subsystems are represented graphically by using the package symbol with a « subsystem» stereotype.  When one or more subsystems have been defined, several high-level actions can be performed:

·        export/baseline a subsystem into a CM tool.

This collects together all of the entities contained within a subsystem and any related elements in the wider model.

·        export a subsystem into a private workspace.

This is a similar operation to above, but misses out the CM tool.

·        restore a subsystem from either a private workspace or a CM tool into a “global” model.

This restores the subsystem into the main model releasing the locks and resolving all of the changes that have taken place since the subsystem was exported.

·        External elements can be locked (see definition below).

A subsystem can contain any UML model elements.  A subsystem includes those model elements that exist within the subsystem and the interfaces that the subsystem exports. Subsystems can contain any logical grouping of model elements, including other subsystems.

UML 1.3 does not specify how diagrams are associated with subsystems.  The grouping of model elements as defined by diagrams is not necessarily the same as the grouping by packages and/or subsystems.   As a subsystem is populated, some diagrams will be in logical groups based on scoping.  StP Model Management will bring those scoped diagrams into the subsystem automatically.  Others that need to be attached to a subsystem may be brought in manually.

Model Elements that are referenced in these manually assigned Diagrams and that belong to another subsystems are called 'External Model Elements'. These kind of Model Elements are normally used to describe the interface between subsystem.

There  are three steps to set up a subsystem:

Step 1:  Assign model elements such as Use Cases and classes to a subsystem by dropping the elements into the desired  «subsystem»  package.  This step uniquely defines which element belongs to which subsystem on a logical/ownership level.

Logical ownership is propagated wherever it makes sense, e.g. if a package called “Interface” is part of the subsystem “MyLibrary”, all classes in the package “Interface” will automatically belong to the subsystem “MyLibrary”.

Step 2:  Manually assign diagrams which reference elements of a given subsystem to that subsystem. Essentially a diagram in that context is a view which is relevant for the user of that subsystem. The association of a diagram with a subsystem therefore does not redefine any existing association between elements and subsystems but just defines the graphical representation of the elements the user wants to see in a subsystem.

Step 3:  The  subsystem can now be baselined and then either checked  into a CM tool or just loaded  into a private workspace.

2        Model Management Tree Browser

All subsystems defined in StP will show up in the StP Desktop under 'Model Management View'. When a subsystem is selected, all 'Assigned Diagrams' will show up in the Objects Pane of the Desktop on the right hand side. Click on the + sign to see all the other assigned model elements like use cases and classes. An example of the Model Management View appears in Figure 1

Figure 1 :  Model management View

All  actions that can be performed on subsystems are available here. Select a subsystem and press the right mouse button to see the available commands. The details of these commands and how they work is described later in this document.

The folder 'Unassigned Diagrams' shows all diagrams that are not assigned to any of the defined subsystems.

3        Defining a Subsystem

Subsystems are represented using the package symbol with a «subsystem» stereotype.  As more detailed diagrams are created we may populate these diagrams [CL9]  with elements that should be in those subsystems.  Stereotypes are one of the standard extensibility mechanisms built into UML.  StP supports both predefined stereotypes e.g. type or utility  and also user defined stereotypes.  These user defined stereotypes are  intended to support specific requirements in a project.

Figure ...shows a simplified diagram [FM10]  of the overall system we wish to create and work with. It has three subsystems -- Trunk, Traffic Control and Subscription.  We will look at this model and see how it was constructed.  Then we will look in more detail at the model and see how a Use Case diagram for one of the subsystems could be constructed .

Figure 2:  Subsystem_View Diagram [MB11]  

The Title Bar displays the name of the diagram or table, followed by the system name and the name of the current editor. If the diagram or table has been modified but not saved, the diagram or table name appears within parentheses.

The word <unassigned> is shown only when there is already some assigned diagram in the model.  If the user starts in a very new StP-system, then there is no subsystem visible.

3.1        How the Subsystem Stereotype is Drawn.

The «subsystem» stereotype is created with the Properties pulldown menu.  In this example, select the class “Trunk” and then use the right mouse button to obtain the Properties sheet.  Click on Stereotype:  Choose… and the selection of predefined stereotypes comes up.  Select subsystem and hit OK on each of the property sheets.  Then the «subsystem» stereotype will appear on the class as shown previously in Figure 1.  (Notice that the figure below shows the Class Editor.  This procedure is identical for the Use Case Editor.)

Figure 3:  How the Subsystem Stereotype is Drawn.

3.2        Assign Model Elements to a Subsystem

Subsystems are containers for other Model Elements. All Model Elements that are part of the UML Notation are assigned to subsystems when they are drawn within the shape of the subsystem symbol. Figure 5 shows an example in a Use Case Diagram

Figure 4:  A Subsystem with Use Cases

In this example Use Cases are incorporated into the subsystem Traffic Control.

After this diagram is prepared scenario diagrams can then be created to elaborate [FM12]   the Use Cases. StP Model Management will automatically assign these sequence diagrams to the Traffic Control subsystem because they are scoped by their Use Cases which are contained within the Traffic Control subsystem.

3.3        Automatic Propagation of Subsystem Ownership

Logical ownership is propagated wherever it makes sense.  For example, if package “Interface” is part of subsystem “MyLibrary,”  all classes in package “Interface” automatically belong to subsystem “MyLibrary”.  All directly associated elements, such as a superstate for a class or a scenario for a Use Case also belong to the subsystem that the “scope element” itself belongs to.

Now that several scenario diagrams have been created, here is what one of them looks like.  This scenario describes use case 'Initiate_Call' and has been automatically assigned to the subsystem as shown in Figure 3 above.

Figure 5:  Scenario with Subsystem Membership

The title bar contains the complete name (Initiate_Call__1<TrafficControl>: SubII).      The diagram name itself, Initiate_Call__1, was chosen by the user.  The <Traffic Control> designation shows that this diagram belongs to that subsystem as shown in Figure 3.   SubII is the name of the system (that is, the StP model). 

Table 1 shows how decompositional elements are automatically assigned to subsystems.

 

3.4        Manually Assigning Diagrams to Subsystems

UML 1.3 does not specify how diagrams are associated with subsystems.  The grouping of model elements as defined by diagrams is not necessarily the same as the grouping by packages and/or subsystems. Diagrams that are not automatically assigned to subsystems need to be attached manually.

There are two ways one may manually assign diagrams to subsystems.  Shown below is the Assign File to Subsystem menu, accessed from the desktop.  This was obtained by right-clicking on the Unassigned File (in this case, Traffic_Control_Subsystem) and choosing Assign File to Subsystem.

Figure 6 -- Accessing the Assign File to Subsystem Menu

This Assign File to Subsystem submenu may also be accessed from any StP editor via Edit > Assign Diagram to Subsystem.   Once the submenu is shown, click on the desired subsystem and hit OK.

4        Subsystem Commands

Subsystems are the base concept for private workspaces and the interface to Version Control Systems. Several commands can be performed on subsystems defined in StP. These commands are available in the StP Desktop under

Tools -> Model Management

And in the 'Model Management View' of the tree browser.

These commands are explained in detail in the following sections

4.1        Check Consistency of Subsystem

The purpose of these checks is to guarantee subsystem consistency even if the subsystem is restored in a private workspace. Any links in a diagram assigned to a subsystem that will change model elements from external subsystems are not allowed.

Checking can be run from the Desktop or within the Editors.

The difference is, that except for some special errors, within the editor only errors caused by the current diagram are reported, in addition to that you should be able to navigate to the bad symbol if the check is started from the editor.

4.1.1       General Checks

-         At least one file containing the subsystem package has to be assigned to the subsystem.

-         A model element can not be assigned to more than one package..

4.1.2       Requirement Table

-          A requirement can not be referenced in a Table assigned to a different subsystem.

4.1.3       Use Case Diagram Checks

The following links are not allowed in diagrams assigned to a subsystem:

-         Communication link to a Use Case that belongs to a different subsystem

-         A Use Case can not extend a Use Case that belongs to a different subsystem

-         A Use Case can not be included by a Use Case that belongs to a different subsystem

-         A Use Case can not be the generalization of a Use Case that belongs to a different subsystem

4.1.4       Class Diagram Checks

The Following constructs are not allowed in diagrams assigned to a subsystem:

-         Generalization from external to local class

-         Dependency from external to local class

-         Dependency with Friend stereotype from and to a local class

-         Undirected Association between an external and local class

-         Directed Association from an external to a local class

-         A local class can not be the Aggregation/Composition of an external class

-         An Association Class cannot belong to a different subsystem than the class where the navigation starts

-         For an N-ary Association, all partner classes have to be in the same subsystem (The UML standard says that this navigation does not make any sense or would be too complicated).

-         An inner class can not be assigned to a different subsystem than the outer class.

4.1.5       Sequence Diagram Checks

The following constructs are not allowed in diagrams assigned to a subsystem:

-         Any message sent from an external to a local class except for return messages

Any message to an external class with no corresponding operation

4.1.6       Collaboration Diagram Checks

The Following constructs are not allowed in Diagrams assigned to a subsystem:

-         Same as Sequence Diagram

4.1.7       Activity Diagram Checks

-         No checks are needed here

4.1.8       State Diagram Checks

-         No checks are needed here

4.1.9       Component Diagram Checks

-         Any symbol referenced in a diagram assigned to a subsystem cannot be referenced in another diagram assigned to a different subsystem.

4.1.10  Deployment Diagram Checks

-         Same as Component Diagram

4.1.11  Stereotype Diagram Checks

Same as Component Diagram

4.2        Baseline of Subsystem

The Baseline of a Subsystem can be used to create a private workspace for a user or to check in a baseline to a version control system. This is accomplished by using the baseline command in the desktop:

Tools->Baseline->Baseline Current System

Figure 7: Baseline Properties [FM14]  

Create Baseline Subsystem Properties

Property	Description
SubSystem	Name of the selected subsystem.
Save directory	Specifies the name of the directory where to create the baseline file.
Overwrite existing baseline file	If selected an existing baseline file for the selected subsystem will be overwritten.
Create directory if it doesn't exist	If selected the output directory will be created if it doesn't exist.
Ignore locks	If selected existing lock will be ignored.
Lock subsystem after baselining	If selected the subsystem will be locked after the baseline file is created.

The command creates a file in the specified directory MM-Global_Sub1.zip (<system-name>_<subsystem-name.zip), if you have set up a CM integration it will also perform the subsequent check-in sequence with the CM tool.

4.3        Lock/Unlock of Subsystem

A defined subsystem can be manually Locked and Unlocked. This can be done by selecting

Tools->Model Management -> Lock Subsystem

and

Tools->Model Management -> Unlock Subsystem

A locked subsystem can no longer be changed and no baseline can be created. A baseline is also locked if the appropriate check box is selected when the baseline is created.

All the locks can be removed with the Unlock Subsystem command.

4.4        Restore of Subsystem

Baselines of subsystems as created above can be restored to create a private workspace or to load a different version. All the information will restored from a selected zip file into the current StP system. This command can be run by calling

Tools->Baseline->Restore Selected Baseline.

The behavior and the actions that are performed during the restore depends on the existing information in the system.

4.4.1       Restore to an empty system

This is the easiest case and no checks are necessary. All information in the zip file is restored and lock all restored external model elements to prevent them from changing.

4.4.2       Restore to a system with other subsystems

In this case the StP system contains legal model elements. Therefore StP has to check for name clashes first. A name clash means that there are existing model elements in the StP system with the same name as model elements in the baseline, but they belong to different subsystems. Name clashes need to be resolved by the user first.

External model elements that already exist in the current system will not be restored. This is to avoid the current version being overwritten.

All external model elements will be locked to prevent them from changing.

4.4.3       Restore in a system where this subsystem exists

This is the case if a subsystem from a previous version or a subsystem from a private workspace is restored.

First name clashes have to be resolved as described above.  Then StP checks if there are the same model elements in the baseline and in the current system but with different names. In this case the model elements will be renamed in the current system to ensure that a consistent model exists after the restore.

All external model elements will be locked to prevent them from changing.

4.5        Reconfigure Externals

This command allows you to update all external model elements in your current private workspace model with the current version of the elements from the main model. E.g. you are working on MyLibrary in your private workspace and you learn that BaseClass (and many others which are not “owned” by you have changed), you need to re-import the external model elements into your private model.  This is done by putting the external subsystems into a path and then using the  Tools->Baseline->Reconfigure Externals to update your model with all the changes from the external elements.

5        Known Issues and Limitations

When in any of the Model Management screens which have a Reset button, it is necessary to hit that button to be able to see any recent changes or additions to subsystems.  For example, if a new subsystem is added it will not be visible in the   Tools > Model Management > Baseline Subsystem window until Reset has been pressed.  Likewise, if a file is moved into a subsystem as described in Section 9, the Model Management View on the Desktop will not show it until a refresh has taken place (i.e.  <right-mouse>  Refresh Tree on Model Management View).