• If one or more components are impacted by the change case


• If one or more connection interfaces result changed through the change case


• If behaviours and information in the impacted components are not directly related to the change case

The evaluation is a change that may affect the whole architecture. However, because of the definitions of the components, none of the behaviours and none of the component interfaces appear to have any dependency on the platform or operating system. By itself, this implies that there should be no impact of changing the platform or the operating system on any of the main application components. To ensure that this is the case, we should specify that there can be no operating system calls in any of the application-level components. Operating system and computer platform dependencies should be limited to the device and virtual device components at the Software Site boundary. For components whose implementation uses operating-system tasks, the scheduling of the tasks is probably provided by the operating system. The application code inside the components should have little or no exposure to the scheduling functionality. If this constraint can be met, the system should support the Change Platform case quite well.

Change Database

Only the Storage Service component should be impacted. The Storage connection done not present messages which are dependent on the particular database used, so it should remain unchanged when the database is changed. Storage Service component should have no behaviours that are not connected with moving things between the database and the application. It can be conclude that this architecture adequately supports this change case.

Add capability for custom report definition

Defining reports at run-time requires that the user would be able to see all of the information that can be reported on. The subjects of the reports are expected not to change. To implement this change case, we propose to add a new functional component, called Define Reports. This component would have the needed access to all the data components.

First, let us consider whether there are any existing components that would be impacted by the addition of this new component. Without a behaviour definition for this use case, which would be a good idea to develop, it appears that defining reports would require a quite complex user dialogue. It would be expected that there should be a change to any dialogue component that offers report definition to its users. Also, it seems that there is already a repository for reports in the system. It would be very convenient if the form of the script for general reports were the same as the form for the custom reports. So the answer seems to be that only dialogue components will be impacted by the addition of the new functional component.

Second, let us consider if the existing interfaces hide the change case. Remember that the convention established in this design is to provide a separate connection on the dialogue components for each major operation. Following this convention would mean that adding a new capability would require a new connection for report definition on each dialogue component that offers the new capability.

Finally, Define Reports needs to manipulate the report scripts in the Reports component. The only connection available for Reports is Report Retrieval, which has messages to get titles and get report. These are not sufficient for creating and editing reports. As the aim is not to change data components or their connections when capabilities are added, it would be advisable to fix these connections to support this future requirement. We have two obvious choices for the fix: add more messages to the existing connection, or create a new connection. We could add more message due to there are not many new messages needed, but the idea of separating common operations from editing operations looks very appealing. So, the proposed solution will be to add a new connection called Edit Reports. As a first approach to message content, let us consider operations to get titles, get report, and add report. Now, it is necessary to return to the behaviour definition with these suggestions, and describe the interactions necessary to actually carry out the report definition.

The conclusion for this change case is that only the existing Reports component would need to be fixed to support the change. Additionally, when the change is made, it will require adding dialogue components and a new connection to one or more dialogue components. No changes should be necessary in any other component.

Jorge Luis Ortega Arjona.