System overview

The aim of the diagrams defined below, is not to impose a specific system- architecture but to give a general overview on the different subprojects, and to define the dependencies between these modules.

This definition would help in the strategic management of the project.

Indeed, the detailed study of all the requirements confirmed the fact that the suite would be a very complex system to implement and that a progressive approach had to be defined [DSA]. The aim of the following diagram is to define this approach by splitting the system according to the different needs identified in the use cases document [UC].

• Business view, Personalization view, application view:

These views represent the graphical user interfaces of the suite. These modules are of course important for the presentation of a prototype, but do not really affect the internal functionalities of the suite. In other words, the views are responsible for representing information and do not contribute to the intelligence of the tool.

• “General Needs”-Module

This module contains all the functionalities related to a powerful and professional system. This includes files management (transport for instance if the web aspect is integrated, storage…), reports manager (generation of business reports, customer approval forms…) and security manager (access conditions, log in process…). This module deals with important aspects of the project, which could however be, treated in future versions of the suite. • Sample Card generation

module however, depends on the components generating the script that would be used to make the sample cards.

• Online services

This module is only used for the sample cards generation and can be treated with a low priority.

• Kernel (Card Manager, Macros Manager, Script Generator…)

This component is the most important part of the Suite as far as the internal functionalities are concerned. Indeed, It contains all the intelligent and processing modules dealing with OS and business restrictions, macros logic and script generation.

Thus, the kernel has to be studied in details before any other component of the suite [DSA].

Application view Business

view _{Sample Card}

Generation Online Services General Needs Profiles Manager Security Manager Report Manager Personalization view

Card Manager / Macros Manager / Script

Generator

This arrow means that destination module is cumpolsory for the functionnality of the starting module

This arrow means that destination module is important to complete the functionnality of the starting module This arrow means that destination module is an optional functionnality provided for the starting module

The previous diagram gives an idea on the dependencies between the different components inside the suite. This approach however, does not give a real system overview explaining the high-level architecture of the suite.

The aim of the following diagram is to define this high-level architectural view. The main objective of course is the definition of a fully extensible architecture, which would really facilitate the integration of new operating system and business components in the suite, or even new functionalities.

Personalization Framework Visualization Framework

Perso developer view

Technical

support view Business view

Macros Manager OS Manager Script Generator Data Model Business Manager Model Plug in (new Card, new Application, new Business...) New Functional Plug in (ex: Data Processing) Online Services Profiles Manager Security Manager

First of all, it is important to explain why the term framework was chosen in the system overview.

The kernel component is perhaps the most important one but it has to be extensible for any new operating system or business. In other words, compiling the kernel of the suite, each time there is a new requirement, is not acceptable.

That is why the main challenge in the design part would be the definition of a framework-based architecture with an easy plug in system:

o The visual framework:

This framework defines the common set of functionalities for the different views of the suite (personalization developer, technical support, customer…). This set includes the communication process with the personalization framework (or kernel).

o The personalization framework (Kernel of the suite)

The kernel should also provide a common set of functionalities available for the internal process mechanism inside the tool.

There are for instance three different mechanisms at least, inside the kernel, that must be studied and for which technological solutions have to be found. These mechanisms are: The management of the XML profiles (transformation, modification, update…), the generation of the scripts and the validation of the profile according to the specific OS and business rules.

That means that each component is specialized by business and OS but that a common design concept has to be implemented.

o Plug in system

The Suite has at least to support three different plug-in mechanisms:

o Support new operating systems and new businesses (add new specific wizards in the visual part, add the new set of rules in the profile validation or the script generation)

o Easily add new functionalities inside the suite (web service for the online sample card generation, support other security mechanisms…)

o Add new concepts inside the suite (like the data processing view and the related mechanism inside the kernel)