ࡱ> Y bjbjWW Z==]  $rrrrPLrpYN$rZZZ5n !W$\VVVV7V4X47Y$\[P][Y%55%%[Y(ZZN(((%ZZV %V((-GQVZRrr& "Vt DOCPROPERTY "Project" \* MERGEFORMAT Template for IDA Project ( DOCPROPERTY "Proj Id" \* MERGEFORMAT Project Id)  DOCPROPERTY "Contract" \* MERGEFORMAT Template for specific development ( DOCPROPERTY "Contr Id" \* MERGEFORMAT Contract Id) title \* mergeformat Technical Design Document  DOCPROPERTY "Version" \* MERGEFORMAT Issue 1 TABLE OF CONTENTS  TOC \o "1-2" \t "Doc control first,1,Doc control other,1,Preface 1,1,Preface 2,2" 0 Preface  PAGEREF _Toc504386205 \h 1 0.1 Purpose of this document  PAGEREF _Toc504386206 \h 1 0.2 Use of this document  PAGEREF _Toc504386207 \h 1 0.3 Overview  PAGEREF _Toc504386208 \h 2 0.4 Basis of this Document  PAGEREF _Toc504386209 \h 2 0.5 A Reference Architecture for the IDA Programme  PAGEREF _Toc504386210 \h 3 0.6 Specific Design Considerations  PAGEREF _Toc504386211 \h 3 1 Introduction  PAGEREF _Toc504386212 \h 5 1.1 Purpose  PAGEREF _Toc504386213 \h 5 1.2 Scope  PAGEREF _Toc504386214 \h 5 1.3 Definitions, Acronyms and Abbreviations  PAGEREF _Toc504386215 \h 5 1.4 References  PAGEREF _Toc504386216 \h 6 1.5 Overview  PAGEREF _Toc504386217 \h 6 2 System Overview  PAGEREF _Toc504386218 \h 7 2.1 System Characteristics  PAGEREF _Toc504386219 \h 7 2.2 System Architecture  PAGEREF _Toc504386220 \h 7 2.3 Infrastructure Services  PAGEREF _Toc504386221 \h 9 3 System Context  PAGEREF _Toc504386222 \h 10 4 System Design  PAGEREF _Toc504386223 \h 11 4.1 Design Method and Standards  PAGEREF _Toc504386224 \h 11 4.2 Documentation Standards  PAGEREF _Toc504386225 \h 12 4.3 Naming conventions  PAGEREF _Toc504386226 \h 13 4.4 Programming Standards  PAGEREF _Toc504386227 \h 13 4.5 Software development tools  PAGEREF _Toc504386228 \h 13 4.6 Outstanding Issues  PAGEREF _Toc504386229 \h 14 4.7 Decomposition Description  PAGEREF _Toc504386230 \h 14 5 Component Description  PAGEREF _Toc504386231 \h 15 5.1 Component Identifier  PAGEREF _Toc504386232 \h 16 6 Software Requirements Traceability Matrix  PAGEREF _Toc504386233 \h 19 Document Control  PAGEREF _Toc504386234 \h 20 Document Signoff  PAGEREF _Toc504386235 \h 20 Document Change Record  PAGEREF _Toc504386236 \h 20  0 Preface 0.1 Purpose of this document This document is a generic title \* mergeformat Technical Design Document document for use by IDA Projects. It provides guidance and template material which is intended to assist the relevant management or technical staff, whether client or supplier, in producing a projectspecific title \* mergeformat Technical Design Document document. It is also useful background reading for anyone involved in developing or monitoring the IDA Management System (IDAMS). 0.2 Use of this document This Preface is addressed to the users of this generic document and is not meant to be retained in any projectspecific title \* mergeformat Technical Design Document documents based on it. The remaining sections (numbered 1, 2, 3,) constitute a template that should be used to construct the project-specific title \* mergeformat Technical Design Document document. Text in normal case is in the most part boilerplate that can be retained, amended or deleted in the document. Text in italics provides instructions on how to complete a section and should be removed once the section is written. The template should be used pragmatically, that is - where a section is not relevant it should be omitted. Conversely, the material contained in this document is not necessarily exhaustive; if there is a subject that is relevant to the IDA Project, but is not included in this document, it should still be included. This document has been prepared using MSWord97. The following variables are currently recorded as File Properties under MSWord. They may be modified by that means or overwritten directly at each occurrence in the document, at the discretion of the user. a. Summary PropertiesTitleType of document (i.e. title \* mergeformat Technical Design Document)AuthorAuthor(s) of documentKeywordsDocument reference (i.e.  KEYWORDS \* MERGEFORMAT IDA-MS-TD)b. Custom PropertiesProj IdShort mnemonic of IDA Project (set, in this document, to  DOCPROPERTY "Proj Id" \* MERGEFORMAT Project Id)ProjectFull name of IDA Project (set, in this document, to  DOCPROPERTY "Project" \* MERGEFORMAT Template for IDA Project)Contr IdShort identifier of contract (set, in this document, to  DOCPROPERTY "Contr Id" \* MERGEFORMAT Contract Id)ContractFull name of contract (set, in this document, to  DOCPROPERTY "Contract" \* MERGEFORMAT Template for specific development)VersionIssue number (currently  DOCPROPERTY "Version" \* MERGEFORMAT Issue 1)DateDate of document (currently  DOCPROPERTY "Date" \* MERGEFORMAT 17 January 2001)0.3 Overview This preface is for information only. This preface will therefore not be retained in the projectspecific document. The remaining sections (numbered 1, 2, 3,) constitute a template that should be used to construct the project-specific document. Text in normal case is in the most part boilerplate that can be retained, amended or deleted in the document. Text in italics provides instructions on how to complete a section and should be removed once the section is written. Text in blueitalics includes discussion and specific recommendations on the approach to Technical Design in the IDA context. The template should be used pragmatically, that is - where a section is not relevant it should be omitted. Conversely, the material contained in this document is not necessarily exhaustive; if there is a subject that is relevant to the project, but is not included in this document, it should still be included. 0.4 Basis of this Document This following introductory sections set out an approach to designing systems that may be developed under IDA. It attempts to set standards and create a consistent approach to the design and development of systems across the IDA Programme. It will enable the Programme to benefit from economies of scale and a consistency in the approach to building and deploying systems. Important issues that need to be considered include the architecture of systems, links to legacy systems, contemporary approaches to design (Object Oriented Design), aims for code re-use and the need to develop systems that will work on an operational basis over many years and the associated desire to make such systems easily supportable and affordable. A key point will be to build on the work already carried out in IDA and its predecessor programmes, where a large number of specific technical developments were undertaken looking at, for example, standards for data exchange, such as GESMES, and the introduction of contemporary technologies and infrastructures. The concept of a Reference Architecture is also introduced as part of the process of creating an interoperable environment which facilitates the exchange of information between administrations through setting out a number of standard building blocks around which solutions can be assembled. These building blocks or components reflect the emerging technologies that should form the technical basis of the IDA developments. These include the Common Object Request Broker Architecture (CORBA), Remote Method Invocation (RMI) and Enterprise JavaBeans (EJB) technologies that highlight code re-use, scalability and the creation of interoperable architectures around legacy environments. 0.5 A Reference Architecture for the IDA Programme One of the greatest difficulties facing the IDA Programme is how to create an interoperable architecture across European administrations whilst allowing individual projects to manage their own IDA developments with sub-delegated authority. Under sub-delegation, it would be possible for sectors seeking to be selected to build elements of the overall IDA Programme to propose their own solutions, or the solutions proposed by their selected suppliers, thereby exacerbating the existing heterogeneous environment, which is in direct conflict with the aim of creating an interoperable architecture. In practice the IDA Programme should seek to create what can be referred to as a Reference Architecture for systems in effect a series of established building blocks on which a variety of systems should be assembled. The Reference Architecture should then become part of the IDA Architecture Guidelines. The Reference Architecture would take an n-tier, client-server model as its basis, and state that the persistence layer would be implemented through a number of standard API calls to a particular database system. This use of a Reference Architecture would provide some guidelines to organisations tasked with developing individual elements of the IDA Programme and would, in time, move solutions towards a common homogeneous standard with all of its associated benefits. Recommendations could be made on the reporting tool that should be used in systems if one were required, the Web Browser could be standardised, as could any security features that needed to be built into the system. The Reference Architecture would facilitate re-use throughout the IDAProgramme as individual projects could be arranged to support the development of libraries of components that can be re-used. This will be one of the major potential benefits that could arise from the creation of a Reference Architecture. 0.6 Specific Design Considerations Perhaps one of the most crucial aspects of this is the level of concurrency that will be present in typical IDA projects. Thus far projects falling within the IDA Programme have tended generally not to involve large scale, transaction-based computing. The transmission of information from an MSA to the European Union, containing information on for example employment statistics, has focused on the need to create common approaches to the formatting of the data and to handling language issues. It is possible that future projects will involve more frequent updates from participating administrations. In this case attention in the Reference Architecture to the loading on computer systems will be necessary. OOD will also become increasingly used in the IDA Programme as developments seek to create systems that are more maintainable over their deployment lifetime. The knock on effect of this will be an increasing emphasis on the use of Commercial Off The Shelf (COTS) packages in the software architecture in areas such as the database, middleware, reporting tools and in the Graphical User Interface. IDA projects may well shift from a traditional waterfall development approach to the design and development of solutions towards Rapid Applications Development (RAD). This will have fundamental implications for the design process. IDA project leaders will need to consider the creation of Joint Applications Development (JAD) teams that are made up from software developers and people drawn from the user administrations with business experience of the application area in question. Staged development, through so-called timeboxes, offers many attractions to designers and developers of contemporary systems. IDA Project Leaders should give serious consideration to the adoption of this approach as a way of ensuring systems are delivered into operation that meet up-to-date user requirements. Specific attention will also have to be placed in the choice of language for the implementation of the system. Today various options exist, and it is necessary as part of the design process to give very careful consideration to a range of trade-offs that need to be factored into development of a consistent design for the architecture. Languages such as Java, C, C++ and emerging languages, such as PYTHON, each offer different benefits to the developer. Careful consideration has to be given to the choice of which language to implement the system to gain the appropriate long-term benefits through the full lifecycle of the system. IDA has much to gain from adopting a standard approach to these projects based on, for example, the Unified Modelling Language (UML) paradigm, which is rapidly becoming recognised as an industry standard in software development. In the medium term this offers the exciting potential of creating classes or objects that can be agreed as standards to facilitate the creation of the interoperable architecture that is one of the key technical goals of IDA. It is therefore recommended that the IDA Programme also standardise on a number of tools that support development and deployment of software in the projects associated with the programme. To implement systems based on UML, it is recommended that the IDA Programme adopt the Rational Rose development suite and that Java be adopted as the development standard for all non-real-time projects. Where the system characterisation work shows a need for real-time delivery, we recommend the use of C++ as the development language. These will then become part of the IDA Reference Architecture. Introduction This section should provide an overview of the entire document and a description of the scope of the system and its intended usage. The scope should also describe external interfaces to the system, external dependencies and provide a brief overview of the characteristics of the system, commenting on aspects such as real-time use, security considerations, concurrency of users etc. The operating system, development language to be used for the system development and any COTS packages that will be used, such as databases etc. should also be referred to in the introduction. This should be sufficient for the casual reader to gain a good appreciation of the key building blocks of the system. The reader should also be introduced to the security measures that need to be included within the system. Where strong authentication models are required this may need to show how aspects such as authentication of users may need to be implemented using PKI for example. Purpose This section should: describe the purpose of this document; specify the intended readership of this document. Scope This section should: identify the products to be produced; explain what the proposed system will do (and will not do, if necessary); define relevant benefits, objectives and goals as precisely as possible; define any security risks associated with the system; be consistent with similar statements in higher-level specifications, if they exist. Definitions, Acronyms and Abbreviations This section should define all terms, acronyms and abbreviations used in this document. Particular care should be taken to define terms that are specific to the application. Terms covering the development of software using the Unified Modelling Language (UML) approach which is recommended if an OOD view of the system is to be developed should be included for completeness. The following is a list of definitions for this template based on the UML approach to system design: Class DiagramDescribes the structure of a systemObject DiagramExpresses possible object combinations of a specific Class DiagramStatechart DiagramExpresses possible states of a class (or a system)Activity DiagramDescribes activities and actions taking place in a systemSequence DiagramShows one or several sequences of messages sent among a set of objectsCollaboration DiagramDescribes a complete collaboration among a set of objectsUse-case DiagramsIllustrates the relationships between use casesComponent DiagramA special case of a Class Diagram used to describe components within a software systemDeployment DiagramA special case of a Class Diagram used to describe hardware within the overall system architectureSystem Block diagramA diagram showing the major components of the system with its interconnections and external interfacesReferences This section should list all the applicable and reference documents, identified by title, author and date. Each document should be marked as applicable or reference. If appropriate, report number, journal name and publishing organisation should be included. The IDA Architecture Guidelines (incorporating, if developed, the IDA Reference Architecture), which should provide the starting point for the system architecture, should be referenced. The elements of the recommended architecture which are used should be described. There should also be a reference to the document, which states how changes to this document are controlled. It is recommended that one of the references highlight the system development model that is to be followed in developing the system, such as Waterfall, Vmodel or RAD. This may reference an internal document or an industry standard work on software development approaches. If an Object Oriented Design (OOD) approach is to be followed a reference to the guidelines to be adopted on developing the design should be provided. Num.Title (Applicability & Reference)AuthorDateIssueOverview Section 1 is the introduction and includes a description of the project, applicable and reference documents. Section 2 provides a system overview. Section 3 contains the system context. Section 4 describes the system design method, standards and conventions. Section 5 contains the component descriptions. Section 6 includes the Requirements Traceability Matrix. System Overview This section should briefly introduce the system context and design, and discuss the background to the project. This section may also summarise the costs and benefits of the selected architecture, and may refer to feasibility studies and prototyping exercises. This section should also describe how the design proposed aligns with the IDA Architecture Guidelines and makes use of the outputs of IDA Horizontal Actions and Measures (HAMs). System Characteristics The description of the system should be given in terms of the Architecture of the solution that is being implemented with high level data flows described to set the context of the system, i.e. to look at its external interfaces. This section should also set out to characterise the system describing aspects of its operation that indicate if the system has, inter alia: to operate in real-time or in bursts, linked to month-end reporting, for example the nature of the interface to the users of the system a large number of concurrent users to be highly resilient or fault tolerant to provide security features to protect data to be scaleable and easily maintainable in the future to have any special back-up facilities to protect important data. System Architecture This section should describe the Architecture of the system, based where feasible on the IDA Architecture Guidelines. The system under consideration will perhaps be based upon an n-tier, client-server architecture. It is possible that the architecture will have secure managed interfaces or proxies to isolate systems from illegal access. The Architecture may be a simple client-server system in which web technologies are used to provide forms from a simple server that can be filled in remotely by someone, for example, at a border post. With a simple requirement to collect basic information, which can be entered as it is captured by the user, this two-tier architecture may well be quite sufficient. The access layer (client) may have to cater for a range of terminals that may eventually need to access information. It is not impossible to foresee the day when WAP access to information may be required to allow the citizens of Europe direct access to certain pieces of information stored within the overall data systems operated by the European Union. With enlargement, IDA systems may have to handle a wide range of so-called client systems ranging from simple database applications (Access) to information being collected from large-scale mainframe applications. Given this likely wide range of means of access, the current emphasis in client-server architectures of breaking down the architecture into several layers will be factors that will have to be addressed in the course of defining solutions that can be rolled out across the increased European Union. The architecture proposed is a tried approach that, when implemented across the European Union, will provide the flexibility to support ever-changing business (often legislatively driven) requirements. Its key feature is that it separates out business logic, client access technology and centrally held data into discrete layers with standard, open interfaces. Today n-tier architectures can often be divided into several tiers as follows: client or access tier which facilitates access by both external and internal clients through technologies such as web browsers presentation tier the layer that accesses information from the other systems as required, and can contain its own business rules for simple processes business tier contains the business information layer persistence tier the database layer, which provides the facilities to store data. Depending upon the solution proposed for the system in question there may be a balance of functions placed into each of these layers. We believe that in the design process it is vital, however, to have a layered architecture as the basis of the solution to facilitate change and adaptation of the system in the future in other words to protect the investment that has been made in the system as technologies develop in the future. The degree of isolation afforded to elements of the system through adopting a layered approach is significant and can help immunise the project from having to be replaced in full in years to come some key elements will survive technological developments. Enlargement, both in the medium and long term, could be a crucial factor in the design of IDA systems. Scalability of the architecture could become an issue. With a layered approach the ability to scale to meet future requirements is relatively easy as additional server power can be deployed into the various layers of the system. It may be, for example, that with enlargement, solutions are devised with regional nodes which connect administrations not directly into a central server but into a Regional Centre of expertise in a subject area. Such ideas are already common place in current Community systems such as those connected with EIONET. Here regionally based centres of excellence in the processing of environmental data collect and process information prior to it being forwarded into the European Environmental Agency (EEA). This illustrates a key point in the design of the architecture of the systems. Depending upon where the data is going to be processed and analysed, different physical layouts of servers may be required to provide the levels of service required by the users of the system. It may be that there are local nodes that collect information in each administration, and it is then routed to a specialist node and, from there, onto a central repository which contains the master files where regional factors are considered in order to help establish policy in an effective way. Infrastructure Services Infrastructure Services should be provided to all applications with a view to reducing the time, cost and risks of development through re-use. To gain full advantage of infrastructure services the requirements of all current applications and the anticipated requirements from future applications should be analysed. These should be fed into the design of the services. The Infrastructure Services can be built incrementally, implementing the most common requirements first, followed by more specialised services. Topics covered in this section might include: Security Audit Performance monitoring and reporting Error Handling Debugging Logging. System Context This section should define all the external interfaces. This discussion should be based on a system block diagram or context diagram to illustrate the relationship between this system and other systems. The external interfaces should be defined in terms of: types of data and information flowing over the interfaces the form that data flow takes, e.g. a defined message format such as GESMES the physical medium of the interface, for example a X.25 link, TCP/IP link, a floppy disk, data entered by an operator etc. rates of information flow, covering the frequency of information being updated, the volume of information sent in a message block, how often the information is updated what can happen if the interface fails for some reason, such as the loss of a communications link. It is suggested that the reader give some serious thought to the use of the emerging XML standards to define external data flows into and out from the candidate system. The freedom XML offers in defining labels for data enable the user of the technology to create what is in effect their own data description language for the data that is encapsulated by the XML constructs. However, care should be taken to adhere to standards (de jure or de facto) where they exist make use of the IDA Reference Architecture and the output of IDA HAMs where relevant. System Design This and the following section should provide sufficient information for a developer to produce the system. The detailed content will depend upon the approach to the design process that is to be used. According to one source there are over 30 different object design methodologies and notations of which UML is perhaps the best known. If the project is to follow the traditional waterfall approach, its documentation will differ from a development approach based on RAD or DSDM. Moreover, an OOD based philosophy for the design using UML would be different from one based on another design methodology such as SSADM or Yourdon. Depending upon the approach to be taken the software may be produced using coding statements or it may be automatically generated by an application development tool or a mixture of both. For the example presented in the rest of this section we will assume that new IDA projects move towards the use of UML and OOD based methodologies. One goal of OOD is to create a collection of reusable software objects that can be reused across other IDA projects, in effect offering some significant savings in development costs. With the proposal to create a IDA Reference Architecture a central library of objects could be reused across projects that have similar aims and objectives to collect information but whose application areas (health, tourism, employment, environment, Customs, etc) vary. Design Method and Standards The design method used should be named and referenced. A brief description may be added to aid readers not familiar with the method. Any deviations and extensions of the method should be explained and justified. In this paper we give an example of how client-server technologies can be developed on the basis of a given design paradigm that enables web technologies to be applied to IDA projects offering ease of maintenance and savings in life cycle costs. The design standard might need to be different if more than one method or programming language is involved: for example, if some Javascript design and programming takes place in an HTML project. IDA projects are vulnerable to legislative and political change. For example, an agreement might be reached to focus upon a specific health issue across Europe where concerted action may be agreed but which requires the data being collected to change. A key feature of moving towards an OOD-based approach is that it facilitates system change. A key feature of the design process is to attempt to isolate the various layers that make up the overall architecture to ensure that changes in one layer have a minimal effect upon other layers in the system, such as for example in the business layer. In following an OOD-based approach it is vital that the design process is able to discriminate between objects and classes. An object is a specific instance, containing a set of data and the methods to process the data. A class is a generalised description of a group of objects that have the same data item(s) and method organisation. In designing objects there are four important cardinal points to be remembered. These are: attributes what the object knows methods what the object does states the changes that occur due to process flow events responses to the outside world. Object definitions should be annotated with these items. This will provide the beginnings of a detailed specification document. In addition, each object should be put into a UML diagram set, as this helps summarise the information into small, tight representations of each object in a standard format there are nine UML diagrams as referenced in Section1.3. In the course of the process the diagrams will be transformed into a class diagram that represents the relationship between the objects in effect a blueprint for the structure of the business objects. One area where careful attention to design can reap rewards in the longer term is in the interface between the client and the so-called presentation layer. From its earliest inception in projects using the Smalltalk language the Model View Controller (MVC) paradigm has been one of the most implemented solutions in client-server computing. In implementations based on web technologies, such as JavaServer Pages (JSP) there is much to be gained from separating out elements of the application server architecture. One approach to this is given in an implementation of the MVC paradigm using Servlets or JavaServer Pages. For example, a Servlet (a Java class that operates on the server side to generate output in response to a client request) could be viewed as a controller that is responsible for processing the request from the client we may assume this request arrives in HTTP or HTTP (S) format. The model is the representation of the data stored in the database or persistence store and the view is the code that decides what to display next in response to the output from the controller. This is described here to encourage readers to look at the MVC paradigm as an example of a way to break out the components of the client-server architecture into building blocks that can be easily modified and maintained, and gain the benefits from an OOD-based approach to the design of the system. Documentation Standards For a software implementation, this section should contain the standard module header (if necessary) and contain instructions for its completion. In addition this section should define or reference guidelines on the ration of lines of code to comment statements. It may be that these rules highlight specific areas of code where the commentary should be literally line-by-line, as this is a particularly difficult area. Other areas, which may be less difficult, could be commented on a ratio of five lines of code to one line of commentary. Naming conventions This section should explain all naming conventions used, and draw attention to any points a maintenance programmer would not expect. A table of the file types and the permitted names or extensions for each is recommended for quick reference. Conventions for naming files, programs, modules, and possibly other structures such as variables and messages, should all be documented here. Programming Standards This section should define the project programming standards. Whatever languages or standards are chosen, the aim should be to create a convenient and easily usable method for writing good-quality software. If an application development tool is used there may be other conventions that need to be defined, e.g. colour schemes. When programming in any new language, a standard for its use should be written to provide guidance for programmers. This standard may be referenced or included here. Where there are external interfaces, the programming standards for the interfaces required should be referenced. In general, the programming standard should define a consistent and uniform programming style. Specific points to cover are: modularity and structuring; headers and commenting; indenting and layout; library routines to be used; language constructs to use; language constructs to avoid. Software development tools This section should list the tools chosen to assist software development, including testing. The actual software chosen will be heavily dependent upon the language in which the system will be implemented. The list may include: an application development too; a configuration manager / builder; HTML authoring tools; a word processor for documentation; a tool for drawing diagrams; automated testing tools. Prototyping projects might make use of an interpretative tool, such as an incremental compiler/interpreter/debugger. External interfaces may require some of the modules to be pre-compiled. Outstanding Issues Provide details of any design issues that remain unresolved at the date of issue of this document. Explain options, pros and cons, and give an estimate of which option is most likely. Outline impact of each option on the rest of the design. Decomposition Description The software components should be summarised. This should be presented as structure charts or object diagrams showing the hierarchy, control flow and data flow between the components. If the UML paradigm is used then the decomposition description should make extensive use of the nine UML Diagrams that in effect define the operation of the system. Component Description For a software implementation, this and the previous section should provide sufficient information for a programmer to produce the software, and for a maintainer, who may not be the developer, to make subsequent changes. The detailed content will depend upon the software tool to be used. The software may be produced using coding statements written by an application programmer. In contrast, it may be automatically generated by an application development tool, or indeed a mixture of both. It is worth reflecting for a moment on the term component and giving some definition as to what a component might entail. The following definitions are offered to the reader: Client-Based Components User-centric graphical interface classes and widgets (e.g. Java Advanced Windowing Toolkit, Motif, Swing, Java Beans) implemented with automated tools like GUI builders and testers. Implementation Components General-purpose language libraries or bindings that aid in the implementation of a design in a particular language (e.g. JDK, container classes, middleware wrappers, data portability streams), implemented through tools like UML code generators and repositories. Infrastructure Components General-purpose processes built for a particular middleware architecture (e.g. CORBA, EJB, and TUXEDO) that can be customised for a specific task (e.g. logging, transactions, queuing), implemented through service and servant modelling tools (e.g. Rational Rose or BEA Webgain Studio). Architecture Components Reusable architectural and configuration concepts that are documented and ready for reapplication (e.g. publish/subscribe, Store & Forward, Push) implemented through automated tools like UML modelling tools. Component-based design offers a great economy of effort by encapsulating functionality at the right level. Application components offer re-use and can easily be enhanced. Re-useable components capture the repeated functionality of common system behaviour (such as infrastructure services). The descriptions of the components should be laid out hierarchically. There should be subsections dealing with the following aspects of each component: 5.n Component identifier 5.n.1 Type 5.n.2 Purpose 5.n.3 Function 5.n.4 Subordinates 5.n.5 Dependencies 5.n.6 Interfaces 5.n.7 Resources 5.n.8 References 5.n.9 Processing 5.n.10 Data The number 'n' should relate to the place of the component in the hierarchy. Component Identifier Each component should have a unique identifier. The identifiers to be used for components should be defined by the project and described elsewhere. Type This section should describe the type of component, e.g. task, subroutine, subprogram, package, file. The contents of some component description sections depend on the component type. For the purpose of this template the categories: executable, i.e. contains computer instructions, or non-executable, i.e. contains only data, are used. Purpose The purpose of a component should be defined by tracing it to the software requirements that it implements. Backwards traceability depends upon each component description explicitly referencing the requirements that justify its existence. Function The function of a component must be defined in this document. This should a short description of what the component does and will depend upon the component type e.g. it may be a description of the process or of the data to be stored or transmitted. More detail will be provided in Processing (see below). Subordinates This section should list the modules that are called by this component. The subordinates of a database could be the files that compose it. The subordinates of an object are the objects that are used by it. Dependencies The dependencies of a component should be defined by listing the constraints placed upon its use by other components. For example: what operations have to have taken place before this component is called? what operations are excluded when this operation is taking place? what components have to be executed after this one? Interfaces Both control flow and data flow aspects of an interface need to be specified. Data aspects of 'non-executable' components should be defined in Subsection 5.n.10. The control flow to and from a component should be defined in terms of how this component is to be executed, e.g. subroutine call, and how it is to be terminated, e.g. return. This may be implicit in the definition of the type of component, and a description may not be necessary. Control flows may also take place during execution, e.g. interrupt, and these should be defined, if they exist. The data flow input to and output from the component must be detailed. Data structures should be identified that: are associated with the control flow, e.g. call argument list; interface components through common data areas and files. If a component interfaces to components in the same system then the interface description should be defined. If a component interfaces to components in other systems, the interface description should be defined in an interface document. Resources The resources a component requires should be defined by itemising what the component needs from its environment to perform its function. Items that are part of the component interface are excluded. Examples of resources that might be needed by a component are displays, printers and buffers. References Explicit references should be inserted where a component description uses or implies material from another document. Processing The processing should be defined by summarising the control and data flow within it. For some kinds of component, e.g. files, there is no such flow. Techniques of process specification include Program Design Language, Pseudo Code and Flow Charts. Any specific algorithms to be used should be stated or referenced. Data The data internal to a component should be defined. The amount of detail required depends strongly on the type of component. The logical and physical data structure of files that interface major components should be defined in detail. Data structure definitions must include the: description of each element, e.g. name, type, dimension; relationships between the elements, i.e. the structure; range of possible values of each element; initial values of each element. Software Requirements Traceability Matrix This section should contain a table that summarises how each software requirement has been met in this document. The tabular format permits one-to-one and one-to-many relationships to be shown. System Req. NumberSystem Ref. ItemComponent IdentifierComponent ItemDocument Control Title: TITLE \* MERGEFORMAT Technical Design DocumentIssue: DOCPROPERTY "Version" \* MERGEFORMAT Issue 1Date: DOCPROPERTY "Date" \* MERGEFORMAT 17 January 2001 COMMENTS \* MERGEFORMAT Author: AUTHOR \* MERGEFORMAT Dr Dave SloggettDistribution:EC DG Enterprise Gavino Murgia Project TeamReference: KEYWORDS \* MERGEFORMAT IDA-MS-TDFilename: FILENAME \* MERGEFORMAT IDA-MS-TD-i1Control:Reissue as complete document onlyDocument Signoff Nature of SignoffPersonSignatureDateRoleAuthors  AUTHOR \* MERGEFORMAT Dr Dave SloggettProject MemberReviewers Mark PillattConsultantDocument Change Record DateVersionAuthorChange Details02 January 2001Issue 1 Draft 2Dave SloggettFirst complete draft08 January 2001Issue 1 Draft 3Mark PillattReview and update10 January 2001Issue 1 Draft 4Sue TurnerUpdating format17 January 2001Issue 1Mark PillattApply review comment and issue  The IDA Architecture Guidelines were developed in 1999 in co-operation with the TAG (Telematics for Administrations Group) Subgroup on Horizontal and Legal Issues, a group of experts from EU Member States and EEA states. They describe concepts and references for a well-defined, common architecture that supports network interoperability within and across different administrations. Article 4 of the IDA Interoperability Decision (No. 1720/1999/EC) defines the requirement to develop the Guidelines as one of the IDA Horizontal Actions and Measures. Article 5 of the IDA Guidelines Decision (No.1719/1999/EC) requires projects to make use of them. An update to the Guidelines is expected in early 2001.  API: Application Programming Interface  Note that the design MUST not contradict the IDA Architecture Guidelines  In typical IDA projects the external interfaces are communications links that enable MSAs to transmit information into a central facility or to other MSAs. It is the case that information flows can be infrequent, you do not update employment, health or environmental statistics each day for an area of Europe they occur monthly or less even less frequently. However some information flows, concerning for example Customs related data, may be required to move quickly between MSAs and, if required, to a central database. Time may be of concern if information is to be acted upon promptly. Page page \* mergeformat iititle \* mergeformat Technical Design Document KEYWORDS \* MERGEFORMAT IDA-MS-TD DOCPROPERTY "Version" \* MERGEFORMAT Issue 1 title \* mergeformat Technical Design DocumentPage page \* mergeformat 14 KEYWORDS \* MERGEFORMAT IDA-MS-TD  DOCPROPERTY "Version" \* MERGEFORMAT Issue 1  subject \* Mergeformat title \* Mergeformat Technical Design DocumentMDC/QMS/PROC/430 keywords \* Mergeformat IDA-MS-TDPage page i of numpages 22qw '(@ACDjkuvxy-./0VW^_rs)*+,-GHbcdeftujwUmHjUmHj}UmHjUmH jUmHmH5CJOJQJj5CJOJQJU jUFx/`r.g"e6e7 s  T   10/.-x/`r.g"e6e7 s  T  ? ~ > p  jP  !"+lmƿ *   *   ,  ,  *  *` * )( 10/.-I !EF`abcdtu12345EF`abcdrsjUmHj_UmHjUmHjeUmHjUmHjkUmHjUmHjqUmHmH jUmHjUmH=  2 3 4 5 6 S T n o p q r      3 4 N O P R S k l jA UmHj UmHjG UmHjUmHjMUmHjUmHjSUmHjUmHjYUmHmH jUmH=        9 : ; = > ] ^ x y z | }   8 9 : < = O P j k l n o jUmHj)UmHj UmHj/ UmHj UmHj5 UmHj UmHj; UmHj UmHmH jUmH=  ? ~ > p  jP<$,* & F`*)($    6 7 P Q #$:;TUjk,-CD]^ !DE_`ijlmq@Agh5CJ jCJU>*CJCJ6 jUj5CJOJQJUmH j#UmHmH jUmHM  !"+lm L|0l  $$l Sf#<$ $$l S#  9:Gn?% !!B$v%Q'_))L,-0s3:57x *   *   *   *d  *d  *c   *c   *c  *c  *b   *b  *b  *   ,   ,   ,   *a   *a  *a )  ,h=>ef&'679-94$$W%r%s%u%#&$&>>>  ,t  ,  ,  ,  ,$  ,u  *  7  7 *j         K2LiLLLLMZMnMM0PjRLUUiVVVY[\)_A_payaaaaa* & Fm+** & Fl,UiVVVY[\)_A_payaaaaaaab~pbTF>7 *n   +l   l+v   v+   +   +   +  *m d   d*  *  *  *  +   +   +   aaabc^ccdd~ffgggmhMjllmnUopq sfsss* & Fq* & Fp+ & Fo** & Fn+bc^ccdd~ffgggmhMjllmnUopʼuk_XND:*Tq  *q  *q   *q f  f*  *  *)   *p   + o   +Ho  H*  +C   C+   +h   h+   +  pq sfsssst:vx{{}~~ȺykdZLE;*t   *t    *s   *s     *r W   W*3  *  *  +   +   +    +C  C*q  *q  *q  sst:vx{{}~~wނ37Z* & Fu* & Ft* & Fs*$ & Fr$*+wނ37ZpĶ{oaSE7+   +   +   +   +  *   *u    +   +   +   +   +   +   *t  *t  Zpʄ?^юѐ,* & Fx* & Fw* & Fv*+ʄ?^юȺ|rh^TJ@6,T  ,_  ,x  *  *5  ,   ,Y  ,{  ,K  *   *x   *-w   *w    *v    *r  *  +g   gˡ̡DKLcd}~34DEGU£ܣݣ)W`ayzĤۤ[m̨ͨ@ACJhnH  j0JUmHmH  jUmH 5mH OJQJ CJOJQJ6B*Oѐ):F>CƕĺvhaWIB8*|   *|    *{   *{    *z   *z U  U *y s  s*  ,  ,  ,  ,  ,  ,"  ,5  ,E  ):F>Cƕӕ:Ɨ* & F~* & F}* & F|* & F{* & Fz* & Fy*,ƕӕ:Ɨ3 =Hȝtj\UG@2   * V   V *    *  +   +T  T*  *R   *    ,  ,%  ,o   *~    *}    3 =Hȝ #\ޠˡ̡$* & F*$ & F* & F* & F* & F* & F*+* & Fȝ #\ޠˡ̡ߡ !"#$%&'()*+,-./0123Dõ&  *   +F   F+p   p+   +  *   *   *   * 0̡ߡ !"#$%&'()$$k r"$$)*+,-./0123DKFGd $$kr#x$& & F@&$$k r"$$DKFGU);BLQVW`äĤۤ-BCScpϥץ̨@Dw¬  ' \GU);BLQVxx$' & F $$kr#x$VW`ZN$$k    r3Y#xx$N$$k    r3Y#      äĤۤ-B|C$$k    \3J ]#     >dxx$ dxx$' & F$$k    3Y#xx$ BCScpϥץ$$k     3J ]# >dxx$ dxx$C$$k    \3J ]#̨@ABCDw$$l4#$$$$d$$k     3J ]#ɫʫ 78?@BDE[\uv|}¬ì23LMbc|} CJ8OJQJCJmHCJ jCJU jU jUCJmHCJ jCJUQ¬$$l4<#$ !# $$l4#$hh$$$$$l4B#N_`ab$d$$l4  ]p#$d$ $Jd$hd$$$l4<#$$$ CJ80 0000;&P P. A!"#$%&000P. A!"#$%}DyK _Toc504386205}DyK _Toc504386206}DyK _Toc504386207}DyK _Toc504386208}DyK _Toc504386209}DyK _Toc504386210}DyK _Toc504386211}DyK _Toc504386212}DyK _Toc504386213}DyK _Toc504386214}DyK _Toc504386215}DyK _Toc504386216}DyK _Toc504386217}DyK _Toc504386218}DyK _Toc504386219}DyK _Toc504386220}DyK _Toc504386221}DyK _Toc504386222}DyK _Toc504386223}DyK _Toc504386224}DyK _Toc504386225}DyK _Toc504386226}DyK _Toc504386227}DyK _Toc504386228}DyK _Toc504386229}DyK _Toc504386230}DyK _Toc504386231}DyK _Toc504386232}DyK _Toc504386233}DyK _Toc504386234}DyK _Toc504386235}DyK _Toc504386236 Dd <  C Ab{ :o{p:ڌW nO :o{p:ڌPNG  IHDRTLgAMAPLTE)))BBBRRRccc{{{RJ֜΄cBs9k!ZsR{9]㣐bKGD pHYs  eRd IDATx\r8FB tbimIHxf۪냆(/~'9xɵx Ey(ῡ_[נ5~ʩet|UUoMGTPI)Ⱥ; 0U%1Oim7 7ICދQx1 U`,MmnBMl٨ڻIO}iq t{7!ZZsG3x к$|[,.pX:OYBT?HKx@o윣-$zGf(Yf{(A!\ h^r.L&jp|4.v5u*f|_ @>Tl7o<]~=zlsp^#ű lMYN>VǦ; #ʡ-f$mdf‰ !ǡl\ph 9H̎&c%crԿ3vecX8唢* @:yOn]=a ]wX,$W~oIlb>5Fn"< m^›)L:ҺFTj)S(Ꞷ1 y*{$e+~13̲M2U}po"faݧkbf"lc"AiLnp?@Z}Yw#'`9q&uU$ *(Biiv^ Hn9KGhT=|tg>vch=&Qx-۟ct=en+&a tE=f*&؉[r8PksW66% ;v=]p)9=|vl4a7KEEsJ3:oMx}9lZ;=vւY_ڰrw_8cX;3 ,؆-=*͝qCvJϒl7 yJ/OV֧hXCdfFղSFd7T7 A29kxFnpLu幾BR;x N$BA 4Np0b"IX"c)# uiGqn/ujwm]/H&4GYBds$E3 1,HcIeX {YOQ)/=6IԞ$T /X#AD(sdFqfg _|U{uV@biaLІ"!@^#0ՆP1F]Ub6 &r]>; M][W2Ƴ(qX7\gi) ȳ,n 5AfX-} .P eʽ_yCt%vtTv^+r6źT}}zeh~xކZxIou./ {ʦ>]c/wME^|)y_KliJ/+CΑaĤEl*hrvץkbO)x`#."_&#Hpʭ1TqLѹ䜊*QsNږgζsu-$`[iz&F+!G28Š$fYlS1 wN5ƈD9b(1$3J3hQa³1NaQL e!$2$bEI sVt QQ n AR]Icf3q@Ә S&6 AhSllC9|@m &(u~a:-i< T,4E,),Vp&NFL w9e`Rm8a/v C)Ôi l@RPJ3+QJ%2BqC \'<(J2߱ #}*SPW"5S"o'y/x7Ɠo)nXțA?Ca~[?$ཱྀ)x_M  yoBi/~_n#IENDB`4 [$@$NormalmH \@"\ Heading 1"$$ & F@& 5;CJOJQJmH >@R> Heading 2$ & F@& CJL@RL Heading 3$ & F@&5CJOJQJmH HRH Heading 4$ & F@&CJOJQJmH F@RF Heading 5$$ & $ F@&CJmH N@bN Heading 6"$$ $Qx@& CJmH 0ar0 Heading 7  & F@&FF Heading 8$$ & $ FRx@&CJmH 0 0 Heading 9 & FR@&<A@<Default Paragraph Font6B@6 Body Text CJmH 22TOC 8 C# CJmH 22TOC 7p C# CJmH 2"2TOC 6 C# CJmH 222TOC 5 C# CJmH 2B2TOC 48 C# CJmH 6R6TOC 3e C# 5CJmH >@b>TOC 2$50 C# 5CJmH H@rHTOC 1$0x< C# 5;CJmH **TOC 9@ C# **Term 566@6Header$ !CJmH 6 @6Footer$ !CJmH .@. Footnote Text8&@8Footnote ReferenceH*^^figtitle'$dO1$  95CJOJQJkH66 FirstPara$d1$CJQ Heading 5an & F@& >T h:a: Heading 6a! & FP@& 2"2w2 base3"$$CJmH .P2. Body Text 2#CJ<CB<Body Text Indent$CJDRRDBody Text Indent 2%6CJObDoc control firstc& & F@& >TOrDoc control otherj'$ & Fh@& >T@O@ Preface 1($5;CJOJQJmH .O. Preface 2)CJ>O> Preface 5 * & F 6CJmH 2Oa2 preface 6 + & F6:O: Preface 7 , & Fx6CJDODTitle1-$ $d056CJ$OJQJmH @O@Title2.$h$d056CJ$OJQJ@O@Title3/$dH56CJ4OJQJ@O@Title40$d56CJOJQJHOH Heading TOC1$$5CJOJQJ@R@App12$$5;CJOJQJmH (!2(App23$;CJr!#"F`;    ;;; 2                   `L(3=;DMZ]cmwޜ33    Y 7Bf*eegllllll  h]`abdgz <@ GKasZ̡)GVB^cehikmoqsvx|~7=?C%HUbpƕȝD_fjlnprtuwy{}'@Cjux-/V^r*,Gcet Eact24Eacr35Soq3ORk:=]y|9<Okn 6 P # : T j , C ] D_i@g=e&6Kc}3Dܟ`yUUUUU %T%T%T%T%T%T%T%T%T%T%T%T%T%T%T%T%T%T%T%T%T%T%T%T%T%T%T%T%T%T%T%T4UUUUUtUttUUtt 7QUpz~!+0W_l !U!U!8@0(  B S  ?V _Ref324734354 _Ref324734415 _Toc382804024 _Toc329071011 _Toc504386205 _Toc502116515 _Toc502128729 _Toc504386206 _Toc502116516 _Toc502128730 _Toc504386207 _Toc489699526 _Toc490463821 _Toc497459894 _Toc502116517 _Toc502128731 _Toc504386208 _Toc504386209 _Toc504386210 _Toc504386211 _Toc504386212 _Toc329071012 _Toc504386213 _Toc329071013 _Toc504386214 _Toc329071014 _Ref503278116 _Toc504386215 _Ref503278214 _Toc329071015 _Toc504386216 _Toc329071016 _Toc504386217 _Toc329071017 _Toc504386218 _Toc504386219 _Toc504386220 _Toc504386221 _Toc329071018 _Toc504386222 _Toc329071019 _Toc504386223 _Toc329071020 _Toc504386224 _Toc329071022 _Toc330289846 _Toc504386225 _Toc330289847 _Toc504386226 _Toc330289848 _Toc504386227 _Toc330289849 _Toc504386228 _Toc504386229 _Toc329071021 _Toc504386230 _Toc504386231 _Toc329071023 _Toc504386232 _Toc329071024 _Toc329071025 _Toc329071026 _Toc329071027 _Toc329071028 _Toc329071029 _Toc329071030 _Toc329071031 _Toc329071032 _Toc329071033 _Toc483812344 _Toc329071035 _Toc483812346 _Toc504386233 _Toc502116542 _Toc502128757 _Toc504386234 _Toc486239410 _Toc497459919 _Toc502116543 _Toc502128758 _Toc504386235 _Toc486239411 _Toc497459920 _Toc502116544 _Toc502128759 _Toc504386236 :_%34[777191919:>>CC"CDVFZI)[]]cchhjwwyy{{> =ޜޜޜ333ĠĠĠĠĠSTU  !"#$%&'(4)*+,-./012356789:;<=>?@ABCDEFGHIJKLMNOPQR   FFFFFF%33b7b777X9X9X9;;>>!C!CDDlFmI@[]]cchhwwzz{{22BƑGǙCCC(((((ڠڠڠڠڠR Z ;;OFSFbbbbeekkssttttttou$,\fإܥ#3Sk>]}=Oo!v!x!y!Y.Y.?o@@@@@EEE FUFUFII55XXnoȀȀ̤@ @Dv|¨Mb Mark Pillatt1C:\TEMP\AutoRecovery save of 01_Tech_des_i1d3.asd S G Turnero\\GSD_SERVER1\quality\Quality\Projects\EC IDA QA Framework\SA1\Deliverables\Technical Design\IDA-MS-TD-i1d4.DOC S G Turner/C:\TEMP\AutoRecovery save of IDA-MS-TD-i1d4.asd S G Turner/C:\TEMP\AutoRecovery save of IDA-MS-TD-i1d4.asd S G Turner/C:\TEMP\AutoRecovery save of IDA-MS-TD-i1d4.asd S G Turner/C:\TEMP\AutoRecovery save of IDA-MS-TD-i1d4.asd Mark Pillatt-C:\TEMP\AutoRecovery save of IDA-MS-TD-i1.asd Mark PillattD:\GMP\SA1\WIP\IDA-MS-TD-i1.DOC Mark Pillatt-C:\TEMP\AutoRecovery save of IDA-MS-TD-i1.asd Mark PillattD:\GMP\SA1\WIP\IDA-MS-TD-i1.DOC7|JR}&~>܏@n~h.^Dl&V3RވU zz N֫l  9:R  11t|$8T\, ?} N֫)~~%N֫KJ<+:([1C, M^,InYJ12]):~;b:N֫N= h=a >c@AzL+eA B2]XDN֫F:R'H:(ZI,kK`5ISP:(]QN֫%QTɜ:9@`:(+5c:({mc$n*igN֫Hj2];;l $Eo:(fpN֫.15v:(m`wN֫w:(Az Zc{2]hN֫.... OJQJo( OJQJo( OJQJo( OJQJo(hh. hhOJQJo(0.0.0..079;<B*H*S*TX/Q. QOJQJo() OJQJo(*hhB*CJOJQJo(hhCJOJQJo(q nbnOJQJo( hhOJQJo(0o(0o(.0o(..0o(... 88o( .... 88o( ..... `o( ...... `o(....... o(........nbn.88o(.0o(..0o(... o( .... o( ..... p`po( ...... p`po(.......   o(........ hhOJQJo(hhB*CJOJQJo(hhB*CJOJQJo(hhB*CJOJQJo( hhOJQJo(@n. nbnOJQJo(0o(hhB*CJOJQJo(nbn.@h OJQJo(@h.00.0..08...0/Q. QOJQJo() OJQJo( hhOJQJo( nbnOJQJo(hhB*CJOJQJo( nbnOJQJo(hhB*CJOJQJo( QOJQJo(@n.hhB*CJOJQJo(hhB*CJOJQJo(@n.hhB*CJOJQJo(hhB*CJOJQJo(0#hhB*CJOJQJo( nbnOJQJo(hh.hhB*CJOJQJo(hhB*CJOJQJo(hhB*CJOJQJo(hhB*CJOJQJo(hhB*CJOJQJo(0o(() nbnOJQJo(hhB*CJOJQJo(8m~}|l [1C,eAT\,m`w]QfpigXDhzz ?} )~~%;b:a >a >mkKkKm%Q%Q4nnM^,M^,n0o;;lt|$N=Azh=9FJ1BHjZc{):$Eo'H5ISPw+5c.15v9@`KJ<+ {mc@AZI@A@A@A@A@A@A{mcT{o{mc4{o{mc{o{mc{o{mc{o{mc{o{mcT {o{mc{o{mc8{o{mc {o{mcp{p{mc{mc{p{mc{p{mc {(p@AD {4p {mc{p{mc{p{mc{p{mc{p{mc {p{mc\{p{mc {p{mc {p{mc{p{mc` {{mc{{mcx{{mc{{mc{{mct{({mc{4{mc{@@AL {mcL{{mcx{{mc{@A@A@A@A@A@A@A{mc@AZI{mc< {Dm @ OJQJo(m`b@h.m`t@n.@n @n.n @ nOJQJo(n @n.DnIA[@]~bT U chw0z@{3CӑPJզș@ H7@\\GSD_SERVER1\HPLJet5SiNe00:winspoolHP LaserJet 5Si\\GSD_SERVER1\HPLJet5Sis XXA4!p(H''''(et\\GSD_SERVER1\HPLJet5Sis XXA4!p(H''''(et -`@GTimes New Roman5Symbol3& ArialM& AniteArial NarrowoNewCenturySchlbkCentury Schoolbook;"Helvetica;Wingdings"AhtRQf_Q9DQ&LghD $0dգ˝)Technical Design Document IDA-MS-TDDr Dave Sloggett Mark PillattOh+'0 , H T ` lxTechnical Design Document0echDr Dave SloggettDoc IDA-MS-TDogNormalT Mark Pillattett20kMicrosoft Word 8.0c@ @Cy@`z@BBRgh՜.+,D՜.+,h$x  nnPDգj Technical Design Document Title P%9]q _PID_GUIDProj IdProject Contr Id ContractVersionDateAN{63B74FA0-6507-11D2-85F9-444553540000} Project IdnTemplate for IDA Project7 J Contract Id"Template for specific development 2Issue 117 January 2001  !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~Root Entry F&`p RData 1Table]WordDocumentZSummaryInformation(DocumentSummaryInformation8CompObjjObjectPoolp Rp R  FMicrosoft Word Document MSWordDocWord.Document.89q