art for chapter 10, software configuration management

Con

quer

ing

Com

plex

and

Cha

ngin

g S

yste

ms

Ob

ject

-Ori

ente

d S

oftw

are

En

gin

eeri

ng Art for

Chapter 10,Software Configuration Management

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 2

Figure 10-1. Configuration management concepts (UML class diagram).

Controlled item*

VersionCM Aggregate

*

Configuration item

ReleasePromotion

RepositoryWorkspace

*

*


Figure 10-2. An example of CM aggregates and configuration items (UML object diagram).

A320:CM Aggregate

Wing:CI

Fly-by-wire SW:CI Landing Gear:CM Aggregate

Fuselage:CI Tire:CI


Figure 10-3. Examples of baselines, revisions, and variants (UML object diagram). The A319, A320, and the A321 are all based on the same design. They vary mostly by the length of their fuselage.

A320-200:Revision

A319:Baseline

revised by

First release

A321:Baseline

derived from derived from

Improved versionincluding winglets

124 seat variant 185 seat variant

A320:Baseline


Figure 10-4. Three digit version identification scheme (BNF and UML object diagram).

MUE.1.0.0:Release

MUE.1.2.1:Release

MUE.2.0.3:Release

MUE.0.0.1:Release

First major release

Second minor releasewith bug fixes

Second major release with three series of bug fixes

Alpha test release

Three-digit version identification scheme<version> ::= <configuration item name>.<major>.<minor>.<revision><major> ::= <nonnegative integer><minor> ::= <nonnegative integer><revision> ::= <nonnegative integer>


revised by

revised by

Main trunk

revised by

Branch 1.2.1

derived from

merged with

released as

Figure 10-5. CVS version identification scheme (UML object diagram). Branches are identified with the version they were derived from followed by a unique number.

CVS version identification scheme<version> ::= <configuration item name>.<version identifier><version identifier> ::= <branch>.<revision><branch> ::= <version identifier>.<branch number> |

<branch number><branch number> ::= <nonnegative integer><revision> ::= <nonnegative integer>

MUE.1.1:Release

MUE.1.2:Release

MUE.1.3:Release 1.2.1.1:Release

1.2.1.2:Release

MUE.2.0:Release


Figure 10-6. Change set representation of the MUE release history (UML object diagram). dashedLineFix:ChangeSet and emptyClassFix:ChangeSet can be applied to the MUE.1.0:Release in arbitrary order because they do not overlap.

MUE.1.0:Release

emptyClassFix:ChangeSetdashedLineFix:ChangeSet

interactionDiagram:ChangeSet

MUE.1.1b:Release

MUE.1.2:Release

MUE.1.1a:Release

emptyClassFix:ChangeSet dashedLineFix:ChangeSet

applied to

results in

results in

applied to

results in

applied to applied to

applied to

results in

results in

MUE.2.0:Release


Figure 10-7. MyCarParts subsystem decomposition and hardware allocation (UML deployment diagram).

:NClient

:HomePC

:Server

:EClient:ServerHost

:DealerPC

The :ServerHost hosts the parts catalog server.

The :DealerPC is the machine used by a

dealer to order parts. The :DealerPC has often a higher bandwidth link

to the server.The :HomePC is the

machine used by a car owner to order parts.

The :HomePC is connected to the server

via a modem.

The :Server enables client to retrieve lists of parts by criteria and part

entries, to order parts, and to track client

activity.

The :EClient allows an expert user to find parts by part

identifier, vehicle make and year, and order history.

The :EClient is for high-volume clients, e.g., car repair shops.

The :NClient enables a novice user to find parts by description and, in subsequent releases, by

clicking on a vehicle map. The :NClient is for the occasional

client, e.g., a car hobbyist.


Data Schema:CI

Server:CM Aggregate

ODD:CM Aggregate

Server ODD:CI

EClient UM:CI

NClient UM:CI

NClient:CM Aggregate

EClient:CM Aggregate

Protocol:CI

NClient RAD:CI

Admin Manual:CI

EClient RAD:CI

NCLient ODD:CI

EClient ODD:CI

RAD:CM Aggregate

User Manual:CM Aggregate

SDD:CM Aggregate

Figure 10-8. Configuration items and CM aggregates for myCarParts (UML object diagram).


Figure 10-9. Snapshot of the workspaces used by myCarParts developers (UML object diagram). The Novice Workspace, the Tech Writer Workspace, and the Server Workspace contain promotions related to the navigation map functionality. The Expert Workspace, however, contains older and more stable versions. For all configuration items, version numbers of the form 1.x refer to the promotions without navigation maps functionality whereas version numbers of the form 2.x refer to the promotions containing partial or complete implementations of the navigation maps.

NClient UM.2.0:Promotion

Tech Writer Workspace

NClient RAD.2.0: Promotion

Server.2.3:Promotion

Server Workspace

Data schema.2.1: Promotion

Protocol.2.0:Promotion


Server.2.2:Promotion

NClient.2.3:Promotion

Novice Workspace



Server 1.4:Promotion

EClient.1.5:Promotion

Expert Workspace

EClient RAD.1.2: Promotion



Figure 10-10. Release process for the navigation map functionality of myCarParts.2.0 (UML activity diagram). :P denotes a promotion, :R denotes a release. (continued on next slide)

Novice Client Team Server Team Quality Control Documentation

Team Team

Repair

Test newfunctionality

Repair

NClient.2.4:P

NClient.2.5:P

Test manual

NClientRAD.2.0:P

NClientUM.2.0:P

NclientUM.2.1:P

Server.2.3:P


Figure 10-10 (continued from previous slide). Release process for the navigation map functionality of myCarParts.2.0 (UML activity diagram). :P denotes a promotion, :R denotes a release.

Novice Client Team Server Team Quality Control DocumentationTeam Team

Repair Repair

Retest & Release

Beta test

NClient.2.6:P Server.2.4:P

NClientUM.2.1:P

myCarParts.2.0:R


Server.1.5:P

Main trunk

Server.1.5.1.1:P

Response time branch

Server.2.4:P

Server.1.5.1.7:P

Server.2.5:P

Server.2.6:P

...

...

myCarParts.2.0:R

myCarParts.2.1:R

Server.2.5Navigation map functionality

Server.2.6Improved response time

Server.2.4Navigation map release

and improved responsetime for part retrieval

for navigation map

Figure 10-11. An example of branch (UML object diagram, some promotions were omitted for brevity, :P denotes a promotion, :R denotes a release). On the main trunk, developers add the navigation map functionality to myCarParts. On a concurrent branch, developers improve the response time of the server by integrating a cache between the server and the database. The response time improvement is completed after the release of the navigation map functionality and made available as a patch.


DBInterface.2.4

processPartReq()processMapReq()

DBInterface.1.5.1.7

processPartReq()

DBInterface.2.6


DBInterface.1.5

processPartReq()

DBInterface.2.5


Server.1.5.1.7this method is changed to

access a cache insteadof direct DB accesses

Server.2.4this method is added toprocess map requests

Server.2.5processPartReq() is taken from 1.5.1.7processMapReq() is taken from 2.6

Server.1.5Common promotion

Server.2.6processMapReq() is changed to accessthe cache instead of the DB directly.

revises revises

revises

is merged into is merged into

cache

cache

cache

Figure 10-12. An example of merge for the DBInterface class of the myCarParts system (UML class diagram).


Figure 10-13. Examples of redundant variants (UML object diagram). In the redundant team organization, the myCarParts NClients for the Macintosh and the PC are realized independently. (continued on next slide)

Redundant team organization

PC NClient:Variant

PC GUI:CI

PC Server Interface:CI

PC Parts Catalog:CI

Mac NClient:Variant

Mac GUI:CI

Mac Server Interface:CI

Mac Parts Catalog:CI


Figure 10-13 (continued from previous slide). Example of variants sharing configuration items (UML object diagram). In the single project organization, the myCarParts NClients for the Macintosh and the PC differ in their UI.

Single project organization

PC NClient:VariantMac NClient:Variant

Server Interface:CI

Parts Catalog:CI

Mac GUI:CI

Mac TCP:CI PC TCP:CI

Windows GUI:CI


Figure 10-14. An example of change management process (UML activity diagram).

Request change

Assess request

Approve request

Reject request

Assign change

Implement change

Validate change

Anybody Control Board Developer Quality Control

[inconsistent with goals] [consistent with goals]

Team

art for chapter 10, software configuration management

Documents