CHAPTER 4

System Implementation &Configuration

Management
4.1 Packages and interfaces: Distinguishing between
classes/interfaces, Exposing class and package
interfaces

4.2 Mapping model to code , Mapping Object Model to

Database Schema
4.3 Component and deployment diagrams: Describing
dependencies
4.4 Managing and controlling Changes

4.5 Managing and controlling version

 Version Control
• Version control combines procedures and
tools to manage different versions of
configuration objects that are created during
the software process.

• A version control system implements four

major capabilities:

(1) a project database that stores all relevant

configuration objects
 Version Control
(2) a version management capability that stores
all versions of a configuration object.

(3) a make facility that enables construct a

specific version of the software.

(4) version control and change control systems

often implement an issues tracking (also
called bug tracking) capability
 Version Control
• A number of version control systems establish a
change set—a collection of all changes that are
required to create a specific version of the
software.

• named change sets can be identified for an

application or system.

• construct a version of the software by specifying

the change sets (by name)
 Version Control
• Modeling approach for building new versions
contains:
1. Template for building version
2. Construction rules
3. Verification rules
 Change Control
• Too much change control and we create
problems.

• large software project, uncontrolled change

rapidly leads to chaos.

• For large projects change control combines

human procedures and automated tools to
provide a mechanism for the control of change.
 Change Control
• engineering change order (ECO).

• elements of change management:

1. Access Control
• Access control governs which software
engineers have the authority to access and
modify a particular configuration object.
 Change Control
2. Synchronization Control.
• Synchronization control helps to ensure that
parallel changes, performed by two different
people, don’t overwrite one another.

• Informal Change Control

• Developer makes changes in project
 Change Control
• project level change control
• developer must gain approval from the project
manager to makes changes.

• formal change control

• is instituted when the software product is
released to customers
 Component diagram
• Component diagram shows components,
provided and required interfaces, ports, and
relationships between them.

• It does not describe the functionality of the

system but it describes the components used
to make those functionalities.

• Component diagrams can also be described as

a static implementation view of a system.
 Component diagram
• The component diagram's main purpose is to
show the structural relationships between the
components of a system.
Component diagram
Component diagram
 Component diagram
• The assembly connector bridges component’s
required interface (Component1) with the
provided interface of another component
(Component2); this allows one component to
provide the services that another component
requires.
 Component diagram
• Port
• Ports are represented using a square along the
edge of the system or a component. A port is
often used to help expose required and
provided interfaces of a component.
 Component diagram
• This component's inner structure is composed
of other components
 Component diagram
• Online Shopping UML
Component Diagram Example

• Online shopping UML component

diagram example with three
related subsystems - WebStore,
Warehouses, and Accounting.
 Deployment Diagram
• A deployment diagram is used to show the
allocation of artifacts to nodes in the physical
design of a system.

• Deployment Diagrams are made up of a graph

of nodes connected by communication
associations to show the physical
configuration of the software and hardware.
 Deployment Diagram
• Essential elements of deployment diagram
1. Artifacts
• Artifact is a physical item that implements a
portion of software design.
• It can be an source file , document or another
item related to code.
• Notation of artifact consists of class rectangle
name of artifact and label <<artifact>>
 Deployment Diagram
2. Nodes
• A node is computational resource containing
memory and processing on which artifacts are
deployed for execution.

• Notation of node three dimensional cube.

• Nodes denote hardware, not software

entities.
 Deployment Diagram
3. Connections
• Nodes communicate via messages and signals , through
communication path indicated by solid line.

• Communication paths are usually considered to be

bidirectional, for unidirectional, an arrow may be added to
show the direction

• Each communication path may include an optional keyword

label, such as «http» or «TCP/IP», that provides information
about the connection.

• multiplicity for each of the nodes connected via a

communication path.
 Mapping Models to Code
• A transformation aims at improving one
aspect of the model (e.g., its modularity)
while preserving all of its other properties
(e.g., its functionality).

• Transformation Activities:
1. Optimization
• This activity addresses the performance
requirements of the system model.
 Mapping Models to Code
• Examples
• Reducing multiplicities
• adding redundant associations for efficiency,
• adding derived attributes to improve the access
time to objects.
2. Realizing associations
• map associations to source code constructs,
• Example
• references and collections of references.
 Mapping Models to Code
3. Mapping contracts to exceptions
• describe the behavior of operations when contracts are
broken.

• This includes raising exceptions when violations are

detected.

4. Mapping class models to a storage schema

• selected a persistent storage strategy, such as a database
management system, a set of flat files, or a combination of
both.

• map the class model to a storage schema, such as a

relational database schema.
 Mapping Models to Code
• Four types of transformations:
1. Model transformations
• A model transformation is applied to an object
model and results in another object model.

• purpose of object model transformation is to bringing

it into closer compliance with all requirements.

• A transformation may add, remove, or rename

classes, operations, associations, or attributes.
 Mapping Models to Code
2. Refactoring
• A refactoring is a transformation of the source
code that improves its readability or modifiability
without changing the behavior of the system.

• Refactoring aims at improving the design of a

working system.

• the refactoring is done in small incremental steps

that are interleaved with tests.
 Mapping Models to Code
• the object model transformation of Figure
shown corresponds to a sequence of three
refactorings.
 Mapping Models to Code
• The first one, Pull Up Field, moves the email
field from the subclasses to the superclass
User.
Mapping Models to Code
 Mapping Models to Code
• The second one, Pull Up Constructor Body,
moves the initialization code from the
subclasses to the superclass.
 Mapping Models to Code
• The third and final one, Pull Up Method,
moves the methods manipulating the email
field from the subclasses to the superclass.
 Mapping Models to Code
• Applying these three refactorings effectively
transforms the ARENA source code in the
same way the object model transformation
 Mapping Models to Code
3. Forward Engineering
• Forward engineering is applied to a set of model
elements and results in a set of corresponding
source code statements, such as a class
declaration, a Java expression, or a database
schema.

• Purpose of forward engineering is to maintain a

strong correspondence between the object
design model and the code, and to reduce
implementation errors.
 Mapping Models to Code
4. Reverse Engineering
• Reverse engineering is applied to a set of source
code elements and results in a set of model
elements.

• purpose - to recreate the model for an existing

system, either because the model was lost or
never created, or because it became out of sync
with the source code.

• Reverse engineering is essentially an inverse

transformation of forward engineering.
 Mapping Models to Code
• Transformation Principles
A transformation aims at improving the design
of the system with respect to some criterion.

• To avoid introducing new errors, all

transformations should follow certain
principles:
 Mapping Models to Code
1. Each transformation must address a single
criteria.

2. Each transformation must be local. A

transformation should change only a few methods
or a few classes at once.

3. Each transformation must be applied in

isolation to other changes.

4. Each transformation must be followed by a

validation step.
 Mapping Models to Code
• Mapping Associations to Collections
1. Unidirectional one-to-one associations.
 Mapping Models to Code
2. Bidirectional one-to-one associations.
 Mapping Models to Code
3. One-to-many associations.
 Mapping Models to Code
4. Many-to-many associations.
 Mapping Models to Code
• Mapping Contracts to Exceptions
1. Checking preconditions.
• Preconditions should be checked at the beginning of
the method, before any processing is done.

• There should be a test that checks if the precondition is

true and raises an exception otherwise.

• Each precondition corresponds to a different exception

 Mapping Models to Code
2. Checking post conditions.
• Post conditions should be checked at the end
of the method, after all the work has been
accomplished and the state changes are
finalized.

• Post condition corresponds to a Boolean

expression in an if statement that raises an
exception if the contract is violated.
 Mapping Models to Code
3. Checking invariants.
• When treating each operation contract
individually, invariants are checked at the
same time as post conditions.
4. Dealing with inheritance.
• The checking code for preconditions and post
conditions should be encapsulated into
separate methods that can be called from
subclasses.
 Mapping Models to Code
5. Coding effort.
• In many cases, the code required for checking
preconditions and post conditions is longer
and more complex than the code
accomplishing the real work.
6. Increased opportunities for defects.
• Checking code can also include errors,
increasing testing effort.
 Mapping Models to Code
7. Performances drawback.
Checking systematically all contracts can
significantly slow down the code, sometimes by
an order of magnitude. Although correctness is
always a design goal, response time and
throughput design goals would not be met.