<sub-group><component>1.01Draft | FinalATLAS-TDAQ-2002-XXXLast modification dateCERN

ATLAS TDAQ <sub-group>

<component> Architectural Analysis and Design

Document Version:	1.0

Document ID:	ATLAS-TDAQ-2002-XXX

Document Date:	Last modification date

Document Status:	Draft | Final

Abstract

Abstract text for the Architectural and Design document.

Institutes and Authors:

Institute 1: A. Author, B. Author, C. Author

Institute 2: A. Author

Institute 3: A. Author, B. Author

etc…

Table 1 Document Change Record

Title:	ATLAS TDAQ <sub-group> <component> Architectural Analysis and Design
ID:	ATLAS-TDAQ-2002-XXX
Version	Issue	Date	Comment
1	1
[For insertion of diagrams, use Insert, Object… and insert a file or other object as necessary.

For more details please consult the Connect Forum WEB pages, http://atlas‑connect‑forum.web.cern.ch/Atlas-connect-forum/, in particular, the ‘Recipes’ and ‘Guidelines for Software Architecture and Design Document’]

Introduction

[The introduction provides and overview of the entire document. It includes the purpose, scope, definitions, acronyms, abbreviations, references, and overview of the document.]

Purpose

This document provides a comprehensive architectural overview of the system, using a number of different architectural views to depict different aspects of the system. It is intended to capture and convey the significant architectural decisions which have been made about the system.

[This section defines the role or purpose of the Software Architecture Document, in the overall project documentation, and briefly describes the structure of the document. The specific audience for the document si identified, with an indication of how they are expected to use the document.]

Scope

[A brief description of what the Software Architecture Document applies to; what is affected or influenced by this document.]

Glossary

[This subsection provides the definitions of all terms. This information may be provided by reference to the project’s Glossary.]

For long descriptions use a pair of Dfn1Part1Term/Dfn1Part2Desc paragraph formats.

Example: Farm

A set of computing node linked by a network or bus

Acronyms and Abbreviations

For short descriptions use a pair of Dfn1Part1TermR1H/Dfn1Part2Desc paragraph formats:

CERN	European Laboratory for Particle Physics

ASA	Another Silly Acronym

References

[This subsection provides a complete list of all documents referenced elsewhere in the Software Architecture Document. Identify each document by title, report number (if applicable), date, and publishing organisation. Specify the sources from which the references can be obtained. This information may be provided by reference to an appendix or to another document.]

List all external documents referenced in this document

1

2

3

4

5

Overview

[This subsection describes what the rest of the document contains and explains how the document is organized.]

Architectural Representation

[This section describes the software architecture of the current system and its representation using views. Of the available views; Use-Case, Logical, Process, Deployment and Implementation, enumerate those that are necessary. Explain for each view what types of model elements it contains.]

Architectural Goals and Constraints

[This section describes the software requirements and objectives that have some significant impact on the architecture; for example, safety, security, privacy, use of an off-the-shelf product, portability, distribution, and reuse. It also captures the special constraints that may apply: design and implementation strategy, development tools, team structure, schedule, legacy code, and so on.]

Logical View (mandatory)

[This section describes the architecturally significant parts of the design model, such as its decomposition into subsystems and packages. And for each significant package, its decomposition into classes and class utilities. You should introduce architecturally significant classes and describe their responsibilities, as well as a few very important relationships, operations, and attributes.]

Overview

[This subsection describes the overall decomposition of the design model in terms of its package hierarchy and layers.]

Architecturally Significant Design Packages

[For each significant package, include a subsection with its name, its brief description, and a diagram with all significant classes and packages contained within the package.

For each significant class in the package, include its name, brief description, and, optionally, a description of some of its major responsibilities, operations, and attributes.]

Use-Case View (mandatory)

[This section lists use-cases or scenarios from the use-case model if they represent some significant central functionality of the final system, or if they have a large architectural coverage, they exercise many architectural elements or if they stress or illustrate a specific, delicate point of the architecture.]

Use-Case Realizations

[This section illustrates how the software actually works by giving a few selected use-case (or scenario) realizations, and explains how the various design model elements contribute to their functionality.]

Process View (optional)

[This section describes the system’s decomposition into lightweight processes (single threads of control) and heavyweight processes (groupings of lightweight processes). Organise the section by groups of processes that communicate or interact. Describe the main modes of communication between processes, such as message passing, interrupts, and rendezvous.]

Deployment View (optional)

[This section describes one or more physical network (hardware) configurations on which the software is deployed and run. It is a view of the Deployment Model. As a minimum for each configuration it should indicate the physical nodes (computers, CPUs) that execute the software and their interconnections (bus, LAN, point-to-point, and so on). Also include a mapping of the processes of the Process View onto the physical nodes.]

Implementation View (optional)

[This section describes the overall structure of the implementation model, the decomposition of the software into layers and subsystems in the implementation model, and any architecturally significant components.]

Overview

[This subsection names and defines the various layers and their contents, the rules that govern the inclusion of a given layer, and the boundaries between layers. Include a component diagram that shows the relations between layers.]

Layers

[For each layer, include a subsection with its name, an enumeration of the subsystems located in the layer, and a component diagram.]

Data View (optional)

[A description of the persistent data storage perspective of the system. This section is optional if there is little or no persistent data, or the translation between the Design Model and the Data Model is trivial.]

Size and Performance

[A description of the major dimensioning characteristics of the software that impact the architecture, as well as the target performance constraints.]

Quality

[A description of how the software architecture contributes to all capabilities (other than functionality) of the system: extensibility, reliability, portability, and so on. If these characteristics have special significance, such as safety, security or privacy implications, they must be clearly delineated.]

This template has been prepared using the SDLT Single File Template that have been prepared by the IPT Group (Information, Process and Technology), IT Division, CERN (The European Laboratory for Particle Physics) and then converted to MS Word. For more information, go to http://framemaker.cern.ch/.

The content of this document has been derived from the RUP( templates and its use if therefore restricted by the CERN license agreement to CERN/LHC related activities. Please consult http://sdt.cern.ch/RUP/ for further information.

ATLAS

page 4	Draft | Final

ATLAS TDAQ <sub-group> <component> Requirements

Draft | Final	page 1

ATLAS TDAQ <sub-group> <component> Architectural Analysis and Design

ATLAS TDAQ <sub-group>	<component> Architectural Analysis and Design

Version/Issue: 1.0/1

<component> Requirements	ATLAS TDAQ <sub-group>

Report Template

SEA

2003-03-06

Jim Cook

SEA