|
Definitions are given below for the parts of the Functional Viewpoint accessible through the Indexes on the HOME Page of the Browsing Tool, or on the Query window at the top of the screen.
More detailed definitions can be found in the Framework Architecture documents D3.1 (Functional Viewpoint) and D2.2 (User Needs), which can be viewed or downloaded from the 'LIBRARY' page of the FRAME Web Site.
User Needs
User Needs provide a formalised description of the Services that will be provided through the deployment of the results from the creation of an ITS Architecture. What the Stakeholders themselves want should be expressed in their own words in the Stakeholder Aspirations. The Aspirations are “mapped” to the User Needs so that a particular ITS Architecture can be created from the Framework Architecture. The resulting ITS Architecture is then used to plan the deployment of what is needed to deliver the Services identified by the Stakeholders.
The User Needs are divided up according to the area in which the Services operate. Hence there are User Needs for: traffic management, freight movement, fleet operation, and public transport, plus facilities for electronic payment, law enforcement, security and incident response, links between vehicle and roadside, and traveller assistance.
Most User Needs are served by one or more Functions. The relationship between User Needs and Functions is shown in the Trace Tab les which indicate: a) the Functions that serve each User Need and b) the User Needs that are served by each Function. The first form of the Trace Tab les will be found in the ' User Needs against Functions ' page. User Needs that have no Functions listed in the Trace Tab les relate to physical or communications requirements connected with the provision of the services. The User Needs that are served by each Low-level Function are listed at the end of their descriptions.
Top
Terminators
A Terminator is an entity that represents a part of the outside world with which the Framework Architecture interacts through an interface. It may be a person, or a system with which data can be exchanged, or a physical entity from which data can be obtained, such as the atmosphere, or road surface. Terminators provide the definitions of what the Architecture expects the outside World to do so that data can be exchanged. Persons can be End Users such as Travellers, or they may be part of organisations or public authorities that contribute in some way to the provision of ITS services. Systems may also be part of these organisations, or can be another instance of an ITS deployment. A rigorous definition for each Terminator can be accessed using its name in the list in the ' Terminators ' page, or from the ‘ Org-Units Tree' in the navigation window.
Top
Functional Areas
At its highest level, the Functional Viewpoint consists of a number of Functional Areas, each of which contains the functionality that is responsible for a specific area of operations. This functionality is provided by a set of Functions and their related Data Stores. Each Functional Area has been given a specific number and a name identifying the area of responsibility involved. Thus the Area called “Manage Public Transport Operations” contains all the functionality required for that purpose.
The description of each Area can be accessed by selecting its name from the ' Functional Areas ' page, or from its entry in the navigation window. The Functions and Data Stores in each Area are linked by Data Flows. The interface between Functional Areas is provided through Data Flows that appear in the ' Functional Area Diagram (DFD0) '. There are separate Index Pages for ' Functions ', ' Data Flows ' and ' Data Stores ' – see below.
Top
Functions
The functionality in each Functional Area is decomposed into several Functions that form a hierarchical set of High-level and Low-level Functions.
Low-level Functions contain simple (un-complex) functionality which is easy to describe, and thus contain the lowest level of functionality in each Functional Area. Their descriptions consist of an Overview, lists of input and output Data Flows, detailed Functional Requirements and a list of User Needs served by that Function. The Functional Requirements provide details of what the Functions actually do with the data that they receive in order to produce the data that they send out.
High-level Functions are groups of Low-level Functions. They are used to represent these Low-level Functions at higher levels in the hierarchy in order to make it easier to understand the overall functionality within a Functional Area. Each High-level Function description contains an Overview plus a list of its constituent Functions.
Each Function has a number and name. The numbers are used to identify the position of each Function in the hierarchy within each Functional Area, whilst the names are a simplified expression of what the Function does. A description of each Function can be found in a number of ways, e.g. by selecting its number and name from the list in the ' Functions ' page, or Functional Area description, or by selecting it from the navigation window to the left of this page, or from its representation in a Data Flow Diagram (DFD) – see below.
Top
Data Flows
The Data Flows link the Functions to each other, to Terminators and Data Stores. They enable data to be moved around within the Architecture and are of the following three types.
- Functional Data Flows – carry data from one Function to another, or to/from the Data Stores.
- Terminator Data Flows – carry data to/from Terminators.
- Inter-Functional Area Data Flows – carry data from Functions in one Functional Area to those in another Functional Area.
All Data Flows have names that start with letter codes that define either the Functional Area in which they reside, the Terminator with which they are associated, or the Functional Areas that they link. A summary of these codes can be found in the ‘Acronym Definition' page (see also below), and a detailed explanation of this naming convention can be found in the Functional Viewpoint document (D3.1).
The description of each Data Flow can be found in a number of ways, e.g. by selecting its name from the list in the ' Data Flows ' page, or in a Function description, or from its representation in a Data Flow Diagram (DFD) – see below.
Top
Data Stores
The Data Stores are used to hold data that is used by two or more Functions within a Functional Area. Each has its own unique number and name. The first digit of the number is the Functional Area in which the Data Store resides. The name indicates the type of data that the Store contains.
The description of each Data Store contains details of what data is held in the Store. It is not intended to imply the use of any particular physical design or storage methodology. Taken together, the Data Store descriptions provide the Information Viewpoint representation of the Framework Architecture.
The description of each Data Store can be found in a number of ways, e.g. by selecting its number and name from the list in the ' Data Stores ' page, or in a Function description, or from its representation in a Data Flow Diagram (DFD) – see below.
Top
Data Flow Diagrams (DFDs)
Data Flow Diagrams (DFDs) illustrate the way that the functionality within each Functional Area is organised into a hierarchy of High-level and Low-level Functions. They also show how the Functions are linked to each other, and to the Terminators and Data Stores through Data Flows. There is one DFD for each Functional Area, and within them, one DFD for each High-level Function. Each DFD is numbered and named. The first digit of the number identifies the Functional Area. Any second and subsequent digits correspond to the High-level Function that the DFD represents. The name of each DFD is either that of the Functional Area or High-level Function that each DFD represents
The DFDs contain rectangular shapes, representing the Functions, and (sometimes) cylindrical shapes representing Data Stores. Data Flows are represented by lines with an arrow indicating the direction of the flow of data. The name of the Data Flow is written within the line. The sizes of the rectang les and cylindrical shapes vary from one DFD to another and have no special significance. In each DFD all shapes (rectang les , cylinders and lines) are “active” and can be used as links to the page containing the description of the particular item.
The description of each DFD can be found in a number of ways, e.g. by selecting its number and name from the list in the ' Data Flow Diagrams ' page, or from the navigation window. The DFD in which each Function, Data Store and Data Flow appears is also identified in the pages containing their descriptions and can be selected from that page.
Top
Acronyms
The Acronyms provide a concise way of identifying a Terminator or Functional Area and are used in the Data Flow naming convention. They utilise the initial letter, or letters, of the name of the Terminator or Functional Area concerned. Acronyms have also been created for the Actors that are associated with some of the Terminators. These are in two parts, the first being the acronym of the relevant Terminator and the second the initial letters of the Actor's name. The objective is to provide consistency in the use of names across all Data Flow Diagrams (DFDs) and in the descriptions for Functions, Data Flows and Data Stores.
A list of Acronyms and their definitions is provided in the ' Acronym Definitions ' page.
Top
Selection Tool
The Browsing Tool is intended to provide a convenient way of navigating around the Framework Architecture and of viewing its contents. When the Framework Architecture is to be used as the basis for creating a particular ITS Architecture then it is necessary to select some (or possibly all) of the contents of the Framework Architecture. A Selection Tool has been created to facilitate the tasks that need to be done, and it can be downloaded from the FRAME web site.
Top |