![](bg6.png)
Figure 8: Component model of the evolved parking lot man-
agement system.
In the analysis phase, KAMP automatically calcu-
lates the expected structural changes and their prop-
agation, while transferring the base architecture into
the target architecture. First the delta between the ini-
tial architectural model and the evolved architectural
model is determined automatically by a model diff.
Each delta results in a change request to the system,
which is the starting point of the change propagation
in KAMP (Rostami et al., 2015).
In step 1, changes are propagated through the sys-
tem along the interfaces between the components.
The result of the change propagation is a task list of
detailed maintenance tasks for each change request,
directly derived from the architecture. See the middle
columns of Table 3.
In step 2, annotations to the components—test
cases, built scripts, and deployment information—are
applied to extend the task list for additional main-
tenance tasks. For example, three test cases must
be added for the new Reservations component, one
for each of the operations reserve, unreserve, and
isReserved. Moreover, a build script and the deploy-
ment of the new component must be specified. The
test cases for the operations of the parking compo-
nent must be modified, as the new parking functional-
ity in the evolved systems uses the Reservations com-
ponent. Furthermore, the registry component in the
evolved system provides functionality for guest park-
ing. Thus, existing test cases may be modified, and
new test cases must be added. The task list is extended
by the corresponding tasks, as shown in excerpts of
test cases for the reservation functionality in Table 3.
Finally, in the interpretation phase, change efforts
are estimated by software developers based on the
task list identified by KAMP. To illustrate, we pro-
vide hypothetical cost estimates for each task. These
estimates are not a part of KAMP; however, they are
important for determining if we can implement the
changes within the given budget. We have determined
the costs by considering the effort it takes to imple-
ment not only the functionality but also the user inter-
face, testing, optimization, etc. In our estimates it is
more expensive to add a new component compared to
incorporating the functionality into the existing com-
ponents. This reflects the fact that in order to create
a more modular and reusable system we must often
invest more time and effort upfront (hopefully reap-
ing the rewards in the future). We use these estimates
to illustrate the approach; however one may come up
with different estimates, in which case the decisions
may be different, but the approach remains the same.
Table 3 shows an excerpt of the maintenance tasks
and costs. The budget provided for the tasks in the
table is limited to 9 Man/Months. On the left side
we list the cost of adding a new Reservations com-
ponent and on the right we list the cost of incorpo-
rating the new functionality into the existing compo-
nents. Unfortunately, the maintainability analysis re-
veals that the cost of decomposing the system accord-
ing to the original functional analysis is too high (11
Man/Months). That is, in this case, it is not possible to
implement the more modular design within the given
budget (9 Man/Months).
This result demonstrates a typical situation in the
engineering of complex systems. We cannot use a
greedy approach to solve the problem, as optimizing
one aspect (functional decomposition) without regard
for others (implementation cost) may result in a bad
solution. In this case it will cost too much to im-
plement. Instead, we must find a compromise that
results in a good overall solution. That is, a sys-
tem with good modularity that can be implemented
within the given budget. One reasonable compromise
is to merge the Reservations and the Registry com-
ponents. The result can be seen in Fig. 10. Whereas
merging the two components reduces the cohesion of
the Registry component, it also lowers the develop-
ment cost to an acceptable level. We replace the four
Man/Month units of work that went into the devel-
opment of a new Reservations component with one
Man/Month of work for adding the reservation func-
tionality to the existing Registry component. The rest
of the work has not changed. As a result the total cost
is reduced to 9 Man/Months, exactly as allowed by
the budget.
7 RELATED WORK
Vanya et-al. (Vanya et al., 2013) suggest to assess the
current decomposition by considering its past evolu-
MODELSWARD 2017 - 5th International Conference on Model-Driven Engineering and Software Development
440