NORMA ISO ISO CD ISO STANDARD září 2006 NORME ISO ISO NORM

Revize TR 14813-5:1999 jako ISO/CD 14813-5

NORMA ISO ISO STANDARD NORME ISO ISO NORM

ISO CD 14813-5 září 2006

ICS 03.220.01; 35.240.60

Návrh revize ISO TR 14813-5:1999

Informační a řídicí dopravní systémy – Model referenční architektury pro obor ITS – Část 5: Požadavky na popis architektury v normách ITS Transport information and control systems — Reference model architecture(s) for the ITS sector — Part 5: Requirements for architecture description in ITS standards Systèmes intelligents de transport – Architecture(s) de modèle de référence pour le secteur ITS – Partie 5:

Podle ustanovení Evropské Rady 15/1993 je tento dokument postoupen dále pouze v anglické verzi. Pro další distribuci je tento dokument postoupen v podobě, jež byla zaslána sekretariátem komise. Práce editačního charakteru a kompozice textu provedená Ústředním sekretariátem ISO bude provedena až ve stádiu publikace normy. Tento dokument ISO je návrhem mezinárodní normy a je chráněn vlastnickými právy ISO. Vyjma povolení za použití zákonů dané země uživatele nelze tento návrh ISO ani jeho část reprodukovat, ukládat do systému pro vyhledávání informací nebo přenášet v jakékoliv formě nebo jakýmikoliv prostředky, elektronicky, fotokopií, záznamem nebo jiným způsobem, bez předchozího obdržení písemného povolení. Se žádostí o povolení reprodukce se obraťte na ISO na níže uvedené adrese nebo na člena ISO v příslušném státu žadatele. ISO copyright office Case postale 56, CH –1211 Geneva 20 Tel. +41 22 749 01 11 Fax + 41 22 749 09 47 Email [email protected] Web www.iso.org Reprodukce může být předmětem vymáhání plateb nebo licenčního ujednání. Viníci budou potrestáni.

ISO Mezinárodní organizace pro normalizaci International Organization for Standardization Organisation international de normalisation Internazionale Organisation für Normung

1


Předmluva Mezinárodní organizace pro normalizaci (ISO) je světovou federací národních normalizačních institutů (členové ISO). Práce při přípravě mezinárodních norem je běžně prováděna technickými komisemi ISO. Každý člen se zájmem o předmět, pro nějž byla ustavena technická komise, má právo být v této komisi zastoupen. Mezinárodní organizace, vládní a nevládní, ve spolupráci s ISO se také této práce účastní. ISO úzce spolupracuje s Mezinárodní elektrotechnickou komisí (IEC) v oblasti elektrotechnické standardizace. Mezinárodní normy jsou navrženy podle daných pravidel uvedených ve Směrnici ISO/IEC, Část 2. Hlavním úkolem technických komisí je připravovat mezinárodní normy. Návrhy mezinárodních norem schválené technickými komisemi jsou postoupeny členům ISO k hlasování. Publikace typu mezinárodní normy vyžadují ke schválení nejméně 75 % hlasů příslušných členů. Dále se upozorňuje, že některé prvky tohoto dokumentu mohou být předmětem patentních práv. ISO není odpovědné za označení jakýchkoliv nebo všech patentních práv. ISO 14813-5 byla vypracována technickou komisí ISO/TC 204, Inteligentní dopravní systémy, pracovní skupinou WG 1. Druhé vydání ruší a nahrazuje první vydání (technickou zprávu TR). Dokument nebyl nějak významně upraven, ale byl revidován z technického hlediska, aby se zlepšila jeho srozumitelnost. ISO 14813 sestává z těchto částí pod souhrnným názvem Inteligentní dopravní systémy – Model referenční architektury pro obor ITS: – Část 1: Domény služeb, skupiny služeb a služby ITS – Část 2: Architektura systémů aktivní zóny ITS – Část 3: Ukázka zpracování – Část 4: Výukový referenční model – Část 5: Požadavky na popis architektury v normách ITS – Část 6: Prezentace dat v ASN.1

2


Obsah Strana Úvod ........................................................................................................................................................................ 4 1

Předmět normy................................................................................................................................................ 5

2

Shoda.............................................................................................................................................................. 5

3

Citované normativní dokumenty ...................................................................................................................... 5

4

Termíny a definice........................................................................................................................................... 7

5

Požadavky....................................................................................................................................................... 7

5.1

Obecné požadavky.......................................................................................................................................... 7

5.2

Další pokyny.................................................................................................................................................... 8

5.3

Prvky architektury ITS ..................................................................................................................................... 9

5.3.1 Obecné požadavky.......................................................................................................................................... 9 5.3.2 Referenční architektura ................................................................................................................................. 10 5.3.3 Logická architektura ...................................................................................................................................... 10 5.3.4 Fyzická architektura (nepovinná)................................................................................................................... 10 5.3.5 Architektura komunikací (nepovinná) ............................................................................................................ 10 5.3.6 Organizační architektura (nepovinná) ........................................................................................................... 10 5.4

Objektově orientovaná architektura............................................................................................................... 10

5.4.1 Všeobecně .................................................................................................................................................... 10 5.4.2 Specifické požadavky pro objektově orientovaný popis ................................................................................ 11 5.4.3 Vazby na domény služeb, skupiny služeb a služby ITS ................................................................................ 11 5.4.4 Řízení chování .............................................................................................................................................. 11 5.4.5 Vícero hledisek.............................................................................................................................................. 11 5.5

Procesně orientovaná architektura................................................................................................................ 11

5.5.1 Všeobecně .................................................................................................................................................... 11 5.5.2 Specifické požadavky pro procesně orientovaný popis ................................................................................. 11 5.6

Návrh architektury/implementace aplikace.................................................................................................... 13

5.7

Uspořádání popisu architektury v mezinárodních normách ITS, technických specifikacích a technických zprávách........................................................................................................................................................ 13

Příloha A (informativní) Normy pro specifické metodiky architektury....................................................................... 14 Příloha B (normativní) Glosář definicí architektury pro použití v normách ITS ........................................................ 15 B.1

Abecední glosář ............................................................................................................................................ 15

B.2

Glosář zkratek a akronymů ........................................................................................................................... 25

B.3

Číselné zápisy ............................................................................................................................................... 26

Bibliografie................................................................................................................................................................ 27

3


Úvod „Architekturu“ lze definovat jako „Design, způsob, jak složky k sobě patří“. („Glosář termínů interoperability Clearinghousu http://www.ichnet.org/glossary.htm). „Architektura“ je implicitně v jakékoliv konstrukci, i když se jedná o fyzickou entitu (budovu), provozní entitu (firma nebo organizace), systémovou entitu (softwarový systém), obchodní entitu (komerční obchodní provoz). Nicméně lze ustanovit, že každá entita má architekturu, že architektura může být explicitní konstrukcí jako výsledek dobře uváženého návrhového procesu nebo může být implicitně výsledkem neplánované série událostí a někdy kombinací obou. U fyzické konstrukce je všeobecně známo, že dobře uvážený proces návrhu vyprodukuje lepší a efektivnější stavbu; tam, kde skupina jednotlivců shromáždila nepřeberné stavební materiály, které byly opodál za účelem vytvoření přístřeší. Inteligentní dopravní systémy (ITS) jsou skupinou služeb (viz ISO 14813-1 Domény služeb ITS, skupiny služeb a služby), které lze zavést pro zlepšení dojmů při řízení, ale i bezpečnosti a pasivní bezpečnosti řidičů, cestujících a chodců. Inteligentní dopravní systémy mohou také pomáhat při pracovní, energetické, environmentální a nákladové efektivnosti dopravních systémů. To je znakem téměř všech systémů ITS, že jejich architektura zahrnuje sběr, použití a výměnu informací/dat v rámci a mezi softwarovými systémy, které ovlivňují nebo řídí chování fyzického vybavení, aby tak poskytovaly službu aktivním prvkům (aktorům) pracujícím v, nebo komunikujícím s dopravním sektorem. Pro maximalizaci účinnosti koexistujících systémů ITS a pro dosažení kompatibility a/nebo interoperability a pro omezení konfliktů potřebují systémy koexistovat a operovat v rámci známého a podpůrného architektonického rámce. Sektor ITS se stále mění a vyvíjí je stále blízko k zahájení jeho další evoluce a aplikace. Technologie se neustále vyvíjí a rychle se mění a služby ITS musely obecně provizorně reagovat nejenom v komunikaci k jiným službám, ale s migrací od jedné generace technologie k pozdějším verzím. Tato mezinárodní norma je navržena tak, aby zajistila, pro dosažení maximální interoperability, účinnosti a schopnosti migrace, že architektura je explicitním procesem ve vývoji a specifikace jsou definovány skrze mezinárodní normy ITS. Slovo „Architektura“ je používáno neformálním způsobem pro označení různých konceptů a ve formálním architektonickém designu existenci různých metodik a názorů na vhodnost použití v systému ITS a v návrhu norem. To snížilo efektivní komunikaci v sektoru ITS způsobujíc nejistotu s významem slova „Architektura“. Druhou funkcí této mezinárodní normy je poskytnout konzistentní terminologii, jež by se používala pro popis aspektů architektury norem ITS a poskytnout konzistentní formu popisu architektury ITS v normách sektoru ITS. Tato mezinárodní norma neupřednostňuje žádnou metodiku pro vývoj a popis architektury, požaduje pouze, že zvažování architektury je explicitním procesem, který bere v potaz vzájemné propojení a interoperabilitu systémů ITS a pro nějž je popis architektury poskytován v normách ITS. Tato norma požaduje, aby aspekty architektury v normách ITS byly popsány explicitně v každé normě ITS a aby všechny normy byly spojeny s (jednou nebo více) doménami služeb, skupinami služeb a službami ITS (ISO 14813-1), a fakt, že jsou navrženy jako pomůcka nebo podpora.

4


1 Předmět normy Architektura ITS je rámcem pro implementace ITS. Je to vysokoúrovňový popis hlavních prvků a jejich vzájemných vazeb. Obsahuje rámec, podle nějž lze definovat rozhraní, specifikace a podrobnosti systému ITS. Architektura ITS není návrhem výrobku, ani není podrobnou specifikací fyzické instalace a není vztažena k určitému místu. Název ‘Systémová architektura je snad nejbližší obecnou terminologií, ale tento termín je někdy příliš specifický, aby zahrnul konceptuální aspekty obsažené v ‘architektuře ITS’ a také často implikuje řešení pro konkrétní místo. Účelem architektury ITS je maximalizovat účinnost, interoperabilitu a multimodalitu více interaktivních systémů ITS v komplexním a vyvíjejícím se sektoru. Tato mezinárodní norma definuje: a) Terminologii používanou při dokumentaci nebo odkazování se na aspekty popisu architektury v normách ITS. b) Požadavek, aby aspekty systémové architektury byly dokumentovány a popsány v normách ITS. Při zpracování této normy autoři shrnuli současnou praxi systémového inženýrství. Tato praxe však není definována touto normou. POZNÁMKA Pomoc pro používání unifikovaného modelovacího jazyku je poskytnuta v ISO TR 17452 Používání UML (Unifikovaného jazyka) pro definování a dokumentaci rozhraní ITS, ISO TR 24529 Používání UML v normách ITS, a ISO TR XXXXX Pravidla a pokyny pro použití Procesně (funkčně) orientované metodiky v normách ITS, datových registrech a datových slovnících.

2 Shoda Neexistuje žádné konkrétní zkoušení shody stanovené touto mezinárodní normou nebo souvisejícími normami. Zpracovatelé mezinárodních norem jsou nicméně vystaveni požadavku popsat architekturu jejich systému v daných publikacích nebo učinit odkaz na jiné mezinárodní normy nebo veřejně dostupné dokumenty, které takový popis poskytují. Úroveň podrobnosti takového popisu nebo metodika používaná pro takový popis není stanovena a je ponechána na volbě zpracovatele takovýchto mezinárodních norem. Osoby pověřené zaváděním systémů ITS nejsou povinni učinit takováto opatření, ale je jim doporučeno, aby tak učinili v jejich plánech nebo dokumentech určených pro veřejné zakázky. Tato mezinárodní norma je tudíž navržena jako konzistentní odkaz pro návrháře systémů ITS.

3

Citované normativní dokumenty

Pro používání tohoto dokumentu jsou nezbytné dále uvedené referenční dokumenty. U datovaných odkazů platí pouze citovaná vydání. U nedatovaných odkazů platí poslední vydání referenčního dokumentu (včetně změn). ISO DIS 14813-1 Intelligent transport systems- Reference model architecture(s) for the ITS sector- Part 1- ITS service domains, service groups and services (Informační a řídicí systémy v dopravě – Model referenční architektury pro obor ITS – Část 1: Domény služeb, skupiny služeb a služby ITS) ISO TR 14813-2 Transport information and control systems- system architecture, taxonomy, terminology and data modelling -Core TICS Reference Architecture (Informační a řídicí systémy v dopravě – Model referenční architektury pro obor ITS – Část 2: Architektura systémů aktivní zóny ITS) ISO TR 14813-3 Transport information and control systems- system architecture, taxonomy, terminology and data modelling – Example Elaboration (Informační a řídicí systémy v dopravě – Model referenční architektury pro obor ITS – Část 3: Ukázka zpracování)

5


ISO TR 14813-4 Transport information and control systems- system architecture, taxonomy, terminology and data modelling -Reference model tutorial (Informační a řídicí systémy v dopravě – Model referenční architektury pro obor ITS – Část 4: Výukový referenční model) ISO 14813-6 Intelligent transport systems - system architecture, taxonomy, terminology and data modelling Data Presentation in ASN.1 (Informační a řídicí systémy v dopravě – Model referenční architektury pro obor ITS – Část 6: Prezentace dat v ASN.1) ISO 14817 Transport Information and Control Systems – Requirements for an ITS/TICS central data registry and ITS/TICS data dictionaries (Modelování dat pro sektor Informační a řídicí dopravní systémy (TICS) (datový slovník) - Datový registr) ISO TR 17452 Intelligent transport systems - system architecture, taxonomy, terminology and data modelling - Using UML (Unified Language) for defining and documenting ITS Interfaces (Používání UML (Unifikovaného jazyka) pro definování a dokumentaci rozhraní ITS) ISO IEC 19501 Information technology – Open Distributed Processing – Unified Modelling Language (UML) (Informační technologie – Otevřené distribuované zpracování – UML) ISO 24531 Intelligent transport systems - system architecture, taxonomy, terminology and data modelling - Using XML (eXtensible Mark up Language) in Intelligent Transport System Standards, Data Registries and Data Dictionaries (ITS – Architektura systémů, taxonomie a terminologie - Využití XML v normách ITS, datových registrech a datových slovnících) ISO TR 24532 Intelligent transport systems - system architecture, taxonomy, terminology and data modelling - Using CORBA (Common Object Request Broker Architecture) in Intelligent Transport System Standards, Data Registries and Data Dictionaries (ITS – Použití CORBA v normách ITS, datových registrech a datových slovnících) ISO TR 24529 Intelligent transport systems - system architecture, taxonomy, terminology and data modelling - Using UML in ITS Standards (Používání UML v normách ITS) ISO CD 24097 Intelligent transport systems - system architecture, taxonomy, terminology and data modelling - Using Web Services (machine-machine delivery) for ITS service delivery (Používání webových služeb (doručení stroj-stroj) pro ITS službu doručení) ISO TR 24098 Intelligent transport systems - system architecture, taxonomy, terminology and data modelling - Procedures for developing ITS deployment plans utilising ITS system architecture (Postupy pro vývoj plánů instalace ITS pomocí systémové architektury ITS) ISO TR XXXXX Rules and guidance for the use of process (functional) oriented methodology in ITS standards, data registries and data dictionaries (Pravidla a pokyny pro použití Procesně (funkčně) orientované metodiky v normách ITS, datových registrech a datových slovnících) POZNÁMKA Aktuální normy na ASN.1 jsou rozděleny do dvou částí, obecná syntaxe zápisu jedna (ASN.1) specifikace, X.680 , X.681 , X.682 a X.683, a pravidla kódování ASN.1, X.690 a X.691: (http://www.itu.int/ITU-T/studygroups/com17/languages/) X.680 ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002, Information Technology - Abstract Syntax Notation One (ASN.1): Specification of Basic Notation X.681 ITU-T Recommendation X.681 (2002) | ISO/IEC 8824-2:2002, Information Technology - Abstract Syntax Notation One (ASN.1): Information Object Specification X.682 ITU-T Recommendation X.682 (2002) | ISO/IEC 8824-3:2002, Information Technology - Abstract Syntax Notation One (ASN.1): Constraint Specification X.683 ITU-T Recommendation X.683 (2002) | ISO/IEC 8824-4:2002, Information Technology - Abstract Syntax Notation One (ASN.1): Parameterization of ASN.1 Specifications X.690 ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002, Information Technology - ASN.1 Encoding Rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER) 6


X.691 ITU-T Recommendation X.691 (2002) | ISO/IEC 8825-2:2002, Information Technology - ASN.1 Encoding Rules: Specification of Packed Encoding Rules (PER) X.692 ITU-T Recommendation X.692 (2002) | ISO/IEC 8825-3:2002, Information Technology - ASN.1 Encoding Rules: Specification of Encoding Control Notation (ECN) X.693 ITU-T Recommendation X.693 (2002) | ISO/IEC 8825-4:2002, Information Technology - ASN.1 Encoding Rules: XML Encoding Rules (XER) ISO/IEC 9834-1:1993 Information technology – Open Systems Interconnection – Procedures for the operation of OSI Registration Authorities: General Procedures (Informační technologie - Propojení otevřených systémů - Procedury pro činnost registračních orgánů OSI - Část 1: Všeobecné procedury) ITU Recommendation Z.100 Specification and Description Language (Doporučení ITU – Jazyk pro specifikaci a popis)

4

Termíny a definice

Pro účely této normy platí termíny, definice, značky a zkratky uvedené v normativní příloze A a tyto termíny a definice: architektura ITS (ITS architecture) návrh nespecifikovaného systému pro skupinu funkčně rozdílných systémů ITS, jež jsou propojeny za účelem společného fungování; jedná se o nespecifikovaný návrh systému pro různé skupiny nebo funkční systémy vzájemně propojené za účelem harmonického provozu. Architekturu ITS lze popsat z různých hledisek a z více hledisek koncepčními, logickými a/nebo fyzickými reprezentacemi. POZNÁMKA Architektura ITS se nevztahuje na konkrétní lokalizaci.

Mohou se vyskytnout dodatečné odkazy na termíny v jiných normách nebo odkazy na zdroj definice, jež je uveden explicitně.

5 Požadavky 5.1

Obecné požadavky

5.1.1 Normy ITS mají poskytovat popis architektury, a to buď vložením popisu do normy, a nebo odkazem na jiné příslušné normy. Popis architektury má zahrnovat informaci o plánu a požadovaném cíli, jež má být dosažen použitím dané normy, společně s popisem architektonických aspektů normy, uváděných v jedné z forem popsaných v této normě. Taková informace se může uvést buď v kapitole Předmět normy a nebo v kapitole Požadavky, podle uvážení příslušných zpracovatelů. 5.1.2 Všechny popisy architektury mají buď začít, nebo být jasně spojovány, s jednou nebo více doménami služeb, skupinami služeb nebo službami ITS (viz ISO 14813-1). 5.1.3 Je důležité, aby se normy ITS mohly porovnat ohledně jejich vzájemných vazeb, a proto existuje požadavek, aby se aplikovala následující metodika pro popis prvků architektury ve všech normách ITS. a) PŘEDMĚT ARCHITEKTURY Předmět architektury má být popsán odkazem na domény služeb, skupiny služeb nebo služby ITS (viz ISO 14813-1). POZNÁMKA 1 Určitě bude přínosné zaměřit vždy předmět podle kontextu případů užití architektury. POZNÁMKA 2 Při zavádění aplikací podle norem ISO ITS budou implementátoři obvykle potřebovat se ujistit, že provádějí návrh konzistentně s architekturou jejich podniku. Podnikové architektury nejsou běžnou součástí mezinárodních norem ITS.

b) POPIS/DEFINICE SYSTÉMU ITS V případě, že se používají schémata, musí to být zřetelně chápané diagramy vysokoúrovňového popisu případů užití nebo mají být vyjádřeny formou procesních nebo objektových modulů.

7


c) POPIS/DEFINICE PROTOKOLU Ve většině případů nejsou popisy protokolů vyžadovány v normě na architekturu. Pokud se popisy protokolu požadují, musí být napsány v obecně přijímaném a standardizovaném formátově popisném jazyce. (např. SDL, XML, ASN.1). d) POPIS/DEFINICE DAT Datové koncepty, pokud se popisují, a jak požaduje ISO 14813-6, mají být popsány pomocí ASN.1 podle ISO 14813-6, ISO/IEC 8824 a ISO/IEC 8825. POZNÁMKA 1 Tento požadavek slouží k maximalizaci interoperability a znovupoužití dat. Aktuální data lze definovat a použít pomocí jiných formátů, jako je SDL, XML apod., ale mají být popsány jako XML/SDL apod. moduly v rámci definování dat formátem ASN.1. ISO 14813-6 uvádí příklady, jak tohoto dosáhnout. POZNÁMKA 2 Neexistuje požadavek, že by architektura měla být zpracována v takové úrovni podrobnosti, že je potřeba definice dat a běžně tak definice uváděna není. Nicméně tam, kde se definice dat požaduje, musí se provést způsobem konzistentním s požadavky ISO 14813-6.

e) Kde již daná oblast používá stávající standardní zápis (např. EDIFACT, X12), je takové použití povoleno do té míry, že obsah zprávy, struktura a prvky pro přenos jsou definovány zřetelně a odděleně. Obvykle se tak stane odkazem na jinou normu (např. normu Výboru EDIFACT). Pokud existují nějaké limity atributu (např. rozsah číselných hodnot) v rámci normy ITS (např. kde se uvádí omezení doby/velikosti bezdrátového přenosu), takové limity atributu se musí stanovit. 5.2

Další pokyny

Další pokyny a asistence v popisu a zpracování architektury systému lze nalézt v těchto publikacích: ISO 14813-1 Intelligent transport systems- Reference model architecture(s) for the ITS sector- Part 1ITS service domains, service groups and services (Informační a řídicí systémy v dopravě – Model referenční architektury pro obor ITS – Část 1: Domény služeb, skupiny služeb a služby ITS) ISO TR 14813-2 Transport information and control systems- system architecture, taxonomy, terminology and data modelling -Core TICS Reference Architecture (Informační a řídicí systémy v dopravě – Model referenční architektury pro obor ITS – Část 2: Architektura systémů aktivní zóny ITS) ISO TR 14813-3 Transport information and control systems- system architecture, taxonomy, terminology and data modelling – Example Elaboration (Informační a řídicí systémy v dopravě – Model referenční architektury pro obor ITS – Část 3: Ukázka zpracování) ISO TR 14813-4 Transport information and control systems- system architecture, taxonomy, terminology and data modelling -Reference model tutorial (Informační a řídicí systémy v dopravě – Model referenční architektury pro obor ITS – Část 4: Výukový referenční model) ISO 14813-6 Intelligent transport systems - system architecture, taxonomy, terminology and data modelling Data Presentation in ASN.1 (Informační a řídicí systémy v dopravě – Model referenční architektury pro obor ITS – Část 6: Prezentace dat v ASN.1) ISO TR 17452 Intelligent transport systems - system architecture, taxonomy, terminology and data modelling - Using UML (Unified Language) for defining and documenting ITS Interfaces (Používání UML (Unifikovaného jazyka) pro definování a dokumentaci rozhraní ITS) ISO IEC 19501 Information technology – Open Distributed Processing – Unified Modelling Language (UML) (Informační technologie – Otevřené distribuované zpracování – UML) ISO TR 24529 Intelligent transport systems - system architecture, taxonomy, terminology and data modelling - Using UML in ITS Standards (Používání UML v normách ITS) ISO 24531 Intelligent transport systems – system architecture, taxonomy, terminology and data modelling – Using XML (eXtensible Mark up Language) in Intelligent Transport System Standards, Data Registries and Data Dictionaries (ITS – Architektura systémů, taxonomie a terminologie - Využití XML v normách ITS, datových registrech a datových slovnících)

8


ISO TR XXXXX Rules and guidance for the use of process (functional) oriented methodology in ITS standards, data registries and data dictionaries (Pravidla a pokyny pro použití Procesně (funkčně) orientované metodiky v normách ITS, datových registrech a datových slovnících) 5.3 5.3.1

Prvky architektury ITS Obecné požadavky

Architektura ITS je „návrh nespecifikovaného systému pro skupinu funkčně rozdílných systémů ITS, jež jsou propojeny za účelem společného fungování“. Mezinárodní normy ITS mají obsahovat popis aspektů jejich architektury, a to buď procesně orientované nebo objektově orientované analýzy, nicméně hloubka takového popisu se různí podle relevance publikace. Kde se připravuje specifická norma (např. zaměřená jen na stanovení protokolů), stačí uvést jednoduchý odkaz na tuto normu v rámci celé architektury. Architektura systémů identifikuje hlavní aktivní členy (aktory), případy užití, rozhraní a komponenty a poskytuje základ pro pochopení všech jejich vzájemných vztahů a vazeb. Jak naznačuje již název, objektově orientovaná architektura začíná s objekty a entitami, které jsou zahrnuty v systému, charakterizuje je a definuje jejich vazby s jinými objekty/entitami/aktory/výstupními rozhraními (exit interfaces). Procesně orientovaná architektura naopak začíná procesy a pracemi směrem k objektům/entitám/aktorům/výstupním rozhraním. Oba tyto přístupy mají své výhody a nevýhody a není účelem této mezinárodní normy jeden z nich preferovat. Existují některá hlediska/aspekty, které by měly být posouzeny bez ohledu na metodiku, ale alespoň shrnující vysvětlení těchto aspektů by mělo být uvedeno v příslušném článku o architektuře v rámci jakékoliv mezinárodní normy ITS. Následující ustanovení této mezinárodní normy popisují požadavky na dokumentaci každého z těchto aspektů: a) Konceptuální (nebo referenční) architektura (odkud začíná, k čemu se váže, jedna nebo více konkrétních domén služeb, skupin služeb a služeb ITS (ISO 14813-1) b) Logická (někdy nazývaná funkční) architektura c) Fyzická architektura d) Komunikační architektura e) Organizační architektura Tato mezinárodní norma rozpoznává, že v obecné praxi může existovat několik hledisek potřebných pro úplné pochopení architektonického modelu a tato možnost je dostupná těm, kteří uvádí popis architektury v mezinárodních normách ITS. Nejdůležitějším je fakt, že popis celé skladby vyhovuje všem uživatelským požadavkům a požadavkům na rozhraní, všem ne-funkčním požadavkům a poskytuje pevný základ nejen pro počáteční návrh, ale také pro další vývoj systému, jak se postupně vyvíjí a jak reaguje novými způsoby na své prostředí. Architektury lze popsat a definovat mnoha různými způsoby; lze v těchto popisech použít různé formáty popisu a zápisu, ale zápis, který je přijímán obecně a nejrychleji je unifikovaný modelovací jazyk (UML) (ISO IEC 19501). Nicméně je používáno mnoho forem procesně orientované metodiky již po dlouhou dobu a jsou již obecně známy a chápány. Tato mezinárodní norma velmi doporučuje, ale nepožaduje, aby se při popisech architektury používaly spíše diagramy/popisy „případů užití“ znázorněné pomocí obrázku než systém modelujícím softwarem, aby se vysvětlil kontext této mezinárodní normy v raném stádiu popisu architektury, aby se umožnilo odborníkům z jiných oborů, než je architektura, pochopit předmět a kontext popisu architektury. Podrobnost, ve které je potřeba architekturu definovat v určité mezinárodní normě, technické specifikaci nebo soupisu podkladů (TOR), se bude lišit od jednoduchého ustanovení v rozmezí jednoho nebo dvou odstavců, a může to být obrázek nebo tabulka, až po specifikaci se všemi podrobnostmi, kterou lze použít jako základ pro vývoj podrobného softwaru. Tato mezinárodní norma ponechává míru podrobnosti na posouzení zpracovatele norem, systému nebo TOR, nicméně následující články uvádí podrobnosti o dohledných perspektivách, že některé normy budou vyžadovat určitý popis.

9


5.3.2

Referenční architektura

Tento článek uvádí všeobecný provozní popis systému ITS zahrnujícího požadavky na provozní koncepty a požadavky uživatele spolu se známými vazbami s jinými systémy. Popis referenční architektury musí vždy použít jednu nebo více „domén služeb, skupin služeb nebo službu ITS“ jako startovní bod nebo jeho předmět bude jasně spojen s naplněním jedné nebo více specifikovaných domén služeb, skupin služeb nebo služeb. 5.3.2.1 Tento přehled lze popsat prostřednictvím ustanovení průběžného cíle/konečného cíle (vision/mission) popisující objektivní výsledek aplikace normy a metoda, kterou se cílu dosáhne, se musí uvést. 5.3.2.2 To je obvykle doprovázeno jednoduchým digramem/popisem případu užití nebo hierarchickou tabulkou nebo síťovým diagramem (např. referenční model) a/nebo celkový popis zaobírající se pouze všeobecnými systémovými koncepty a vztahy a referenčními body, a kde je to vhodné, shrnutím obchodního případu. 5.3.3

Logická architektura

Tento článek má popsat povahu systému založeného na informacích, řízení nebo funkcích a popisuje vzájemné vztahy těchto aspektů; logická architektura je nezávislá na jakémkoliv hardwaru nebo softwaru. Logickou architekturu lze popsat buď objektově orientovanou nebo procesně orientovanou architekturou. Je na pracovní skupině zpracovávající normy, jakou metodiku zvolí. 5.3.4

Fyzická architektura (nepovinná)

Po vysvětlení logické architektury má tento popis obecným způsobem přiřadit logickou architekturu fyzickým entitám (ne však k implementaci zařízení). POZNÁMKA Fyzická architektura, i když popisuje fyzické nastavení v systému, není vázána na konkrétní oblast.

5.3.5

Komunikační architektura (nepovinná)

Tento článek má poskytnout vysokoúrovňový popis média a norem média a protokolů používaných pro podporu a komunikaci v systému. 5.3.6

Organizační architektura (nepovinná)

Tento článek má identifikovat způsob, jakým se splní požadavky na konkrétní organizaci. Proces vývoje musí zahrnovat rozpoznání závislostí a hranic pro funkce. POZNÁMKA Specifikace nebo technická zpráva může vzít v potaz existující produkty na trhu, ale toto řešení není vhodné pro mezinárodní normu.

5.4

Objektově orientovaná architektura

Tento článek se vztahuje na případy, kde je používán návrh popisu/systému objektově orientované architektury. 5.4.1

Všeobecně

UML se používá ve světě stále více pro popis statického a dynamického logického návrhu a chování celých systémů, protože de facto univerzálně popisuje softwarově intenzivní systémy způsobem, který je pochopitelný všemi kulturami, společnostmi a zvyky. UML poskytuje propojení požadavků uživatelů, aplikovaných do případů užití, s jinými požadavky jiných případů užití a také jinými UML artefakty (kdy jsou použity vhodné pomocné nástroje pro softwarové inženýrství (CASE). Nicméně není nezbytné vyjadřovat případy užití pomocí UML, aby byly smysluplné a jednoznačné a toto je také řešeno podrobněji v ISO TR 24529 (Používání UML v normách ITS); a ISO TR 17452 (Používání UML (Unifikovaného jazyka) pro definování a dokumentaci rozhraní ITS). Veškerý popis architektury velmi závisí na konceptu abstrakce. V definici objektově orientované architektury je použití abstrakce velmi důležité jako přístup k návrhu na každé úrovni, zejména na úrovni návrhu architektury.

10


5.4.2

Specifické požadavky pro objektově orientovaný popis

Pokud objektově orientovaný přístup je použit pro popis logické architektury, musí obsahovat integrovaný popis v rozsahu od identifikace tříd, jejich atributů, metod a zpráv a asociací. Pro dosažení konzistence přístupu a pro umožnění křížového odkazování mezi publikacemi musí symboly objektové analýzy pocházet z unifikovaného modelovacího jazyku (UML) (ISO/IEC 19501:2004 a musí být praktické, používat „hlediska“ UML modelu, které jsou vhodné. Nicméně neexistuje žádný požadavek, aby se „hlediska“ UML musely vždy použít. 5.4.3

Vazby na domény služeb, skupiny služeb a služby ITS

V objektově orientované analýze architektonických aspektů normy ITS mají být popisované „třídy“ nejvyšší úrovně (abstrakce) vždy spojeny s opatřením jedné nebo více domén služeb, skupin služeb nebo služeb ITS, jak je definováno v ISO 14813-1. 5.4.4

Řízení chování

Tento článek obsahuje popis řízení chování prvků architektury ITS pro přechod z jednoho stavu (podmínky) na jiný (řízení stavového přechodu). 5.4.5

Vícero hledisek

Potřeba více hledisek v modelech architektury již byla podrobně prozkoumána a objektově orientovaná architektura musí popisovat více hledisek. Vhodnost určitých hledisek je ponechána na výběru zpracovatele dané publikace. 5.5

Procesně orientovaná architektura

5.5.1

Všeobecně

Procesně orientovaná (funkční) dekompozice logické architektury je reprezentována funkční, řídicí a informační architekturou. Pokud se použije v publikaci procesně orientovaný přístup, musí se splnit požadavky uvedené v 5.4.2. Existují tři základní typy procesně orientované metodiky pro architekturu ITS: –

Rámcová;

–

Definovaná;

–

Specifická.

Hlavní rozdíly mezi těmito přístupy závisí na a) Jaké z „hledisek“ je vytvořeno; b) Jaký z „výstupů“ je vytvořen; c) A jakým způsobem jsou hlediska a výstupy používány. 5.5.2 5.5.2.1

Specifické požadavky pro procesně orientovaný popis Rámec architektury ITS

Rámcová architektura ITS obsahuje nejobecnější a flexibilní přístup a ukazuje funkcionalitu potřebnou pro konkrétní sadu požadavků investora. Rámcová architektura ITS musí zahrnovat identifikaci potřeb investora a funkční hledisko. Může také dle volby zpracovatele publikace zahrnovat návody pro vytvoření jiných výstupů. Rámcová architektura ITS musí obsahovat vysokoúrovňovou definici ITS architektury, která poskytne popis způsobu, jakým bude ITS vyvíjen a popíše alespoň: 1. Potřeby investora 2. Funkční hledisko 3. Fyzické hledisko 4. Komunikační hledisko 11


Rámcová architektura ITS by se měla snažit dosáhnout možnosti řádné kontroly výstupů, zejména obsahy fyzického a komunikačního hlediska. Z jednoho rámce architektury lze vytvořit několik definovaných architektur. Využití nástrojů architektury není pro vývoj rámcové architektury požadováno, nicméně komplexnost a vzájemná odvislost většiny systémů ITS znamená, že jsou obvykle velmi žádané a často je jejich použití nutností. Rámcová architektura ITS musí být jednoznačnou: jasnou a pouze s jedním možným výkladem. Rámcová architektura musí být nezávislá na technologii a musí identifikovat data, která probíhají mezi funkcemi a „věci“, které intereagují s identifikovanými funkcemi. 5.5.2.2

Kontextový diagram

Kontextový diagram musí být zhotoven tak, aby ukazoval vztah mezi určitým systémem a těmi částmi jeho prostředí, se kterými intereaguje. POZNÁMKA Tyto části se nazývají „Terminátory“.

Kontextový diagram musí identifikovat hranice systému pomocí „Terminátorů“. „Terminátorem“ může být osoba, organizace, nebo jiný systém a musí mít popis a identifikovat, co se od „Terminátora“ očekává. 5.5.2.3

Diagram datových toků

–

Diagramy datových toků musí zahrnovat:

–

Funkce (které „provádí“ věci v rámci systému, aby splnily potřeby uživatele)

–

Úložiště dat (která obsahují data, jež jsou používána jednou nebo více funkcemi)

–

Datové toky (které identifikují přenos dat mezi funkcemi, mezi úložišti dat a funkcemi a přenos dat mezi funkcemi a terminátory) a

–

Spouštěče datových toků (které jsou zasílány jednou funkcí, aby spustila jinou)

5.5.2.4

Funkční dekompozice

Je nutné vypracovat funkční dekompozici. Funkční oblasti pro dekompozici musí být svázány a odkazovány na domény služeb, skupiny služeb a služby ITS (ISO 14813-1). Funkce mohou existovat pouze v jedné oblasti a budou vykazovat výsledné datové toky. POZNÁMKA Mezi funkčními oblastmi a potřebami uživatele neexistuje přímá vazba, ale to není problém, což by se na první pohled mohlo zdát.

Každá funkce, která zahrnuje funkce nižší úrovně, má svůj vlastní „diagram datových toků“ (DFD) a musí také poskytovat popis funkcí, což udává přehled, co která funkce dělá, a dává spojnici na digram obsahující danou funkci, a musí identifikovat datové toky (které by měly být pojmenovány) na vstupu i výstupu dané funkce a seznam potřeb uživatele, které podle návrhu funkce splní. Terminátory musí být pojmenovány a terminátor datových toků nejvyšší úrovně identifikován. POZNÁMKA

Fyzické datové toky typicky zahrnují funkční datové toky, kterými data procházejí.

–

Subsystém – subsystém;

–

Modul – modul;

–

Modul – subsystém;

–

Subsystém – terminátor;

–

Modul – terminátor.

Kde je to vhodné, použijí se pro podporu popisů diagramy.

12


5.5.2.5

Komunikační hledisko

Zpracuje se analýza fyzických datových toků, aby se identifikovaly charakteristiky fyzických linků, které budou přenášet data. PŘÍKLAD –

Typy dat, jež budou přenášena;

–

Fyzický způsob datového přenosu;

–

Jakékoliv bezpečnostní požadavky;

–

Požadovaná přenosová kapacita.

5.6

Návrh architektury/implementace aplikace

Konkrétní návrh implementace popisuje aktuální instalaci zařízení v jedné nebo více konkrétních oblastech, navržené k dosažení architektur aplikace. Architektura implementace není považována pro standardizaci za vhodnou a nesmí se zahrnout v mezinárodní normě ITS. Pokud se považuje za užitečné, aby toto bylo v publikaci pro snadnější chápání uvedeno, může informativní příloha uvést příklad návrhu implementace, který používá architekturu definovanou v dané publikaci. 5.7 Uspořádání popisu architektury v mezinárodních normách ITS, technických specifikacích a technických zprávách 5.7.1 Jakmile jsou požadavky na definici a popis v jistých článcích každé normy ITS splněny, mají autoři publikací ITS svobodu v popisu aspektů jejich systémové architektury způsobem, který nejlépe popisuje jejich architekturu nezainteresované osobě. 5.7.2 Použití termínů uvedených v normativní příloze B této mezinárodní normy není povinné, ale kde se použije, musí být jejich definice podle této normativní přílohy. Pro vyhnutí se zmatkům NESMÍ popis architektury v publikaci ITS použít standardizovanou terminologii jiným způsobem, než je zde uváděná standardizovaná definice. 5.7.3 Jiné termíny a definice lze také použít v definici architektury, ale kde se použijí, je nutné uvést i jejich definici v rámci dané normy a musí být jednoznačná nebo uvést odkaz na veřejný zdroj termínu. 5.7.4 Publikace popisující architekturu musí jinak používat jasné vyjadřování v popisu architektury a, jak jen to lze, vyhnout se žargonu. 5.7.5 Návrh implementace nesmí tvořit součást popisu architektury, ani nesmí být částí jakéhokoliv normativního ustanovení normy ISO nebo CEN pro sektor ITS. Kde je potřebné uvést příklad návrhu implementace pro snadnější pochopení popisu architektury v dané normě ITS, musí být uveden jako informativní příloha a musí být zřetelně stanoveno, že příloha uvádí pouze informativní příklad. 5.7.6 Pokud se považuje za vhodné technickou komisí ISO TC 204 nebo CEN TC 278 a pokud se považuje za důležité pro poskytování interoperability, mohou být technická řešení (ne však návrhy implementací v konkrétních oblastech) zahrnuta jako informativní přílohy k dané mezinárodní normě. V takových případech normativní tělo normy zřetelně stanoví a definuje všechny normativní požadavky, jež je nutné splnit, a jakákoliv informativní příloha má jednoduše poskytnout příklady řešení, jež tyto požadavky splňují. POZNÁMKA Vždy existuje možnost doplnění dodatečných informativních příloh do mezinárodní normy prostřednictvím běžného procesu revize normy.

5.7.7 Kde je to známo a vhodné, jiné vztahy a vzájemné vazby s jinými existujícími nebo plánovanými mezinárodními normami ITS musí být popsány na vhodném místě v popisu architektury dané mezinárodní normy, i když tyto odkazy nesmí zavést žádná omezení předmětu nebo použití jiných mezinárodních norem.

13


Příloha A (informativní) Normy pro specifické metodiky architektury ISO 14813-5 obsahuje požadavky a návod na netechnické specifické úrovni. Pro návod s ohledem na specifickou metodiku architektury v kontextu ITS je čtenář odkazován na: ISO TR 24529 Použití UML v normách ITS ISO TR 17452 Používání UML (Unifikovaného jazyka) pro definování a dokumentaci rozhraní ITS ISO TR XXXXX Pravidla a pokyny pro použití Procesně (funkčně) orientované metodiky v normách ITS, datových registrech a datových slovnících

14


Příloha B (normativní) Glosář definicí architektury pro použití v normách ITS Použití následujících termínů není povinné, ani nejsou všechny tyto termíny v této normě použity, ale kde se použije, musí být jejich definice podle této normativní přílohy. Jiné termíny a definice lze také použít v definici architektury, ale kde se použijí, je nutné uvést i jejich definici v rámci dané normy a musí být jednoznačná nebo uvést odkaz na veřejný zdroj termínu. B.1 Abecední glosář abstrakce (abstraction) hlavní charakteristika entity, která ji odlišuje od všech entit jiného druhu {ISO/IEC 19501:2004(E)} POZNÁMKA Abstrakce definuje hranice spojené s perspektivou pozorovatele. POZNÁMKA Abstrakce je snad nejmocnějším nástrojem pro softwarového inženýra. Abstrakce má za cíl snížit úroveň podrobnosti a udělat danou věc, která je předmětem abstrakce, jednodušší pro manipulaci… Abstrakce obvykle staví na nízkoúrovňových abstrakcích vedoucích k vrstevnatému hierarchickému návrhu. (Szyperski 1998) akce (action) specifikace zpracovatelného ustanovení, které implementuje postup {ISO/IEC 19501:2004(E)} sekvence akce (action sequence) série akcí v předem nastavené sekvenci aktivace (activation) vykonání akce {ISO/IEC 19501:2004(E)} aktivní člen, aktor (actor) koherentní sada rolí, které uživatelé zastávají při interakci agregát [třída] (aggregate [class]) třída, kterou lze rozdělit na podtřídy agregace (aggregation) speciální forma asociace, která specifikuje veškeré vztahy mezi agregátem (celkem) a komponentou (částí) {ISO/IEC 19501:2004(E)} analýza (analysis) část procesu vývoje softwaru, jejíž primární účel je formulovat model určité domény {ISO/IEC 19501:2004(E)} POZNÁMKA Analýza se zaměřuje na předmět činnosti (co dělat), návrh se zaměřuje na způsob (jak to dělat). Porovnej s návrhem. aplikační architektura (application architecture) sada funkcí kombinovaných pro vytvoření návrhu vysokoúrovňového systému architektura (architecture) organizační struktura a související chování systému {ISO/IEC 19501:2004(E)} (viz také architektura ITS) POZNÁMKA Architektura může být zpětně rozložena na části, které interagují přes rozhraní, vazby, které spojují části a překážky pro sestavení částí. Části, které interagují přes rozhraní, zahrnují třídy, komponenty a subsystémy. prvek architektury (architecture element) definovatelný prvek systému, který tvoří část komponenty nebo systému, ale nemá nezbytnou nezávislou provozní funkcionalitu artefakt (artefakt) fyzický objekt materiálu nebo fyzická část informace nebo systému nebo subsystému, která je používána v určitém systému ITS ASN.1 (ASN.1) abstraktní syntaxní zápis jedna {ISO/IEC 8824-1:2002}

15


typ ASN.1 (ASN.1 type) datový typ (nebo zkráceně typ), který formálně reprezentuje třídu informací (např. číselné, textové, statické obrazy nebo video informace); reprezentace odpovídá definici normy ISO/IEC 8824-1 asociovaný typ ASN.1 (associated ASN.1 type) typ ASN.1 používaný k reprezentaci typu, který není typem ASN.1 v modulu ASN.1 asociace (association) sémantický vztah mezi dvěma nebo více klasifikátory, který stanovuje spojitosti mezi jejich instancemi {ISO/IEC 19501:2004(E)} atribut (attribute) abstrakce vlastností a hodnot patřících do, nebo charakteristik, určité entity základní kódovací pravidla (basic encoding rules) standardizované kódování dat odpovídající ISO/IEC 8824 ASN.1; kódování BER je definováno v ISO/IEC 8825; je nutno zmínit, že existují další kódovací pravidla, např. PER (viz Packed Encoding Rules). chování (behaviour/behavior) pozorovatelné účinky určité operace nebo události, včetně jejich výsledků binární asociace (binary association) spojení mezi dvěma třídami {ISO/IEC 19501:2004(E)} datový typ boolean (boolean) vyčíslení, jaké hodnoty jsou true a jaké false {ISO/IEC 19501:2004(E)} POZNÁMKA Pole matematické logiky vyvinuté v 19. století anglickým matematikem Georgem Boolem, která umožňuje databázovému vyhledávači kombinovat koncepty vyhledávání pomocí klíčových slov pomocí tří příkazů (následně rozšířeny na 4 příkazy, také nazývané „operátory“: TRUE/YES, FALSE/NO, AND, OR (různé instanciace vztahu mohou použít různé podoby)).

logický výraz boolean (boolean expression) výraz, který se převede na hodnotu boolean {ISO/IEC 19501:2004(E)} kardinální číslo (kardinality) počet prvků v sadě nebo skupině (považuje se za vlastnictví dané skupiny) { wordnet.princeton.edu} dítě (child) ve vztahu generalizace se jedná o specializaci jiného prvku, rodiče. Viz: podtřída, podtyp. Protiklad: rodič. {ISO/IEC 19501:2004(E)} třída (class) popis množiny objektů, které sdílí stejné atributy, provozní činnosti, metody, vazby a sémantiku klasifikátor (classifier) mechanismus, který popisuje znaky chování a struktury. {ISO/IEC 19501:2004(E)} POZNÁMKA Klasifikátory zahrnují rozhraní, třídy, datové typy a komponenty. klasifikace (classification) přiřazení objektu k určitému klasifikátoru {ISO/IEC 19501:2004(E)} diagram tříd (class diagram) diagram zobrazující soubor deklarativních (statických) prvků modelu, jako jsou třídy, typy a jejich obsahy a vnitřní vazby {ISO/IEC 19501:2004(E)} spolupráce (collaboration) interakce mezi entitami kompatibilita (compatibility) schopnost systému vzájemně působit na jiný (sub) systém na základě skupiny stanovených pravidel ve formě specifikace rozhraní a vymezení protokolu komponenta (component) modulární, instalovatelná a vyměnitelná část systému, která zahrnuje implementaci a vytváří řadu rozhraní {ISO/IEC 19501:2004(E)} souběžnost (concurrency) výskyt dvou nebo více aktivit během stejného časového intervalu {ISO/IEC 19501:2004(E)} 16


komunikační architektura (communications architecture) popis média a jeho standardů a protokolů používaných k podpoře a komunikaci v rámci systému referenční architektura (conceptual architecture) architektura vysokoúrovňové abstrakce, která definuje souhrnné podmínky a cíle systému nebo entity, která poskytuje souhrnný popis systému zahrnující provozní koncepty a požadavky uživatelů spolu s jeho známými vzájemnými vazbami na další systémy POZNÁMKA Referenční architektura je často vyjádřena/podpořena pomocí průběžných/cílových stavů, jednoduchým schématem hierarchie nebo síťovým diagramem (např. referenčním modelem) jednajícím pouze s celkovými koncepty, vazbami a referenčními body. Referenční architektura není místně stanovena.

omezení (constraint) sémantická podmínka nebo omezení {ISO/IEC 19501:2004(E)} architektura řízení (control architecture) popisuje chování řízení prvků architektury ITS při změně z jednoho stavu (podmínky) do druhého stavu (řízení stavového přechodu) POZNÁMKA Architektura řízení není místně stanovena.

datová struktura (data construct) skupina jednoho nebo více datových prvků používaná pro reprezentaci stavu nebo informace datový prvek (data element) jeden ze skupiny základních dat {ISO/IEC 8824-1:2002} datový model (data model) vztah mezi částmi dat (než zvláštností jednotlivých záznamů); modelování dat závisí na abstrakci základní data (data primitive) datový prvek, který nemůže být dále smysluplně rozdělen v kontextu ASN.1 {ISO/IEC 8824-1:2002} datový typ (data type) sada hodnot pod určitým názvem [ISO/IEC 8824-1:2002, 3.8.63] datatyp (datatype) řetězec sady hodnot, které postrádají identitu a jejichž operace nemají vedlejší efekty POZNÁMKA Datatypy zahrnují základní předdefinované typy a uživatelem definovatelné typy. Předdefinované typy zahrnují čísla, řetězec a dobu. Uživatelem definovatelné typy zahrnují výpočty.

závislost (dependency) vztah dvou modelových prvků, ve kterém změna jednoho modelového prvku (nezávislého prvku) ovlivní ten druhý modelový prvek (závislý prvek) {ISO/IEC 19501:2004(E)} návrh rozmístění/implementace (deployment design/implementation design) fyzická specifikace pro instanciaci jedné aktuální fyzické manifestace/implementace systému pro dosažení cílů aplikační architektury POZNÁMKA Návrh rozmístění se nepovažuje za vhodný pro standardizaci. Návrh rozmístění se někdy nesprávně vztahuje k „fyzické architektuře“. Návrh rozmístění (aplikační) je však specifikován místně a velmi často i časově na rozdíl od architektury ITS.

implementace ITS (deployment of ITS) konkrétní vybavení ITS, software, příslušenství, zařízení atd. na určitém místě v určitou dobu odvozený prvek (derived element) modelový prvek, který lze vypočítat z jiného prvku, ale je uveden kvůli srozumitelnosti nebo je zahrnut pro účely návrhu, i když nepřidává žádnou sémantickou informaci {ISO/IEC 19501:2004(E)} návrh (design) způsob, v němž jsou části nebo složky dávány do vtahu k organizovanému celku (Webster); včetně specifikace struktury, organizace, vzhledu apod. systému nebo entity diagram (diagram) grafické vyjádření souboru modelových prvků, nejčastěji v podobě spojitého grafu vztahů s jinými modelovými prvky 17


doména (domain) třída všech entit stejné skupiny a společných vlastností elektronická výměna dat (EDI) (Electronic Data Interchange) přenos datové zprávy nebo skupiny zpráv mezi počítači a/nebo mezi různými softwarovými systémy (např. EDIFACT) POZNÁMKA V této souvislosti je zpráva EDI obvykle kompatibilní s formou popsanou v ISO/IEC 9897 (CEDEX).

elektronický přenos dat (EDT) (electronic data transfer EDT) přenos skupiny dat, obsahující ucelené zprávy, z jednoho počítače nebo softwarového systému na druhý, elektronická výměna dat pro administraci, obchod a dopravu (EDIFACT) specifický formát pro sektor přichází v úvahu, jak je uvedeno v ISO 9735 EN (EN) evropská norma prvek (element) atomická složka modelu vstupní krok (entry action) akce vykonaná při vstupu do stavu stavového stroje bez ohledu na přechod potřebný k dosažení tohoto stavu výpočet (enumeration) seznam pojmenovaných hodnot použitých jako rozmezí určitého typu atributu, např. RGB barva = {červená, zelená, modrá} {ISO/IEC 19501:2004(E)} událost (event) specifikace důležitého výskytu, který má svou polohu v čase a prostoru {ISO/IEC 19501:2004(E)} POZNÁMKA V kontextu stavových diagramů je událost výskyt, který může spustit přechod.

výraz (expression) řetězec, který nastaví hodnotu na určitý typ PŘÍKLAD Výraz “(7 + 5 * 3)” nastaví na určitou hodnotu typu číslo.

znak (feature) vlastnost, jako je operace nebo atribut, která je zahrnuta do klasifikátoru, jako je rozhraní, třída, nebo datový typ {ISO/IEC 19501:2004(E)} rámec (framework) stereotypní balík, který obsahuje modelové prvky, jenž specifikují znovupoužitelnou architekturu pro celý nebo část systému POZNÁMKA Rámce typicky zahrnují třídy, vzory nebo formuláře. Když jsou rámce specializovány na aplikační doménu, občas se na ně odkazuje jako na aplikační rámce. Viz vzor

funkční architektura (functional architecture) aspekt „logické“, „procesně orientované“ dekompozice celkové architektury ITS (viz procesně orientovaná logická architektura) funkční architektura poskytuje seřazení funkcí a jejich podfunkcí a rozhraní (interní i externí), které definuje sekvenci provádění, podmínky pro řízení nebo datové toky a požadavky na funkční charakteristiky pro splnění základních požadavků. {IEEE 1220} POZNÁMKA Funkční architektura se nevztahuje na konkrétní lokalizaci.

generalizace (generalization) taxonomický vztah mezi obecnějším prvkem a konkrétnějším prvkem, kde konkrétnější prvek je plně konzistentní s obecnějším prvkem a obsahuje dodatečné informace. {ISO/IEC 19501:2004(E)} POZNÁMKA Instance konkrétnějšího prvku lze použít tam, kde je povolen obecnější prvek. Viz dědičnost {ISO/IEC 19501:2004(E)}

návrh implementace (implementation design) viz návrh rozmístění 18


informační architektura (information architecture) s ohledem na procesně orientovanou dekompozici definuje informační architektura entity a vztah informací (datový model) a důležité datové struktury včetně strukturálního návrhu sdílených informačních prvků, organizaci datových sites, webových sites apod. POZNÁMKA Procesně orientovaná dekompozice informace, která se odkazuje na modelování dat a analýzu a návrh informace v systému, se zaměřuje na entity a jejich vzájemné závislosti, což je velmi blízké k objektově orientované architektuře. Hlavní rozdíl je ten, že procesní dekompozice je výsledkem logické analýzy, zatímco objektově orientovaná architektura je základem pro logickou analýzu. POZNÁMKA Informační architektura se nevztahuje na konkrétní lokalizaci.

informační objekt (information object) instance určité třídy informačního objektu, která se skládá z množiny polí, jež tvoří specifikaci třídy {ISO/IEC 8824-2 :2002, 3.4.7] třída informačního objektu (information object class) množina polí tvořící formulář pro definici potenciálně nespjaté sbírky informačních objektů, instanci dané třídy {ISO/IEC 8824-2: 2002, 3.4.8} organizační architektura (institutional architecture) architektura založená na rozdělení politické nebo administrativní infrastruktury a rozdělení odpovědností (spíše než funkcí) interoperabilita (interoperability) schopnost systému poskytovat služby dalším systémům a akceptovat tyto služby těmito systémy tak, že systémy mohou efektivně spolupracovat a vyměňovat si služby dědičnost (inheritance) mechanismus, kterým konkrétní prvky zahrnou strukturu a chování obecnějších prvků, jež se podobně chovají {ISO/IEC 19501:2004(E)} instance (instance) entita, která má jedinečnou identitu, sadu operací, které lze na ni aplikovat, a stav, který sleduje účinky těchto operací {ISO/IEC 19501:2004(E)} instanciace (instantiation) jednotlivá aktuální fyzická manifestace/implementace systému nebo entity interakce (interaction) zkušenost zpětné reakce, ve které oba aktivní činitelé, aktor a reagující, mají zkušenost ze vzájemného působení (Nathan) diagram interakce (interaction diagram) diagramy, které popisují interakce objektů rozhraní (interface) jmenovitá řada operací, která charakterizuje chování mezi dvěma nebo více stranami architektura ITS (ITS architecture) návrh nespecifikovaného systému pro skupinu funkčně rozdílných systémů ITS, jež jsou propojeny za účelem společného fungování; jedná se o nespecifikovaný návrh systému pro různé skupiny nebo funkční systémy vzájemně propojené za účelem harmonického provozu POZNÁMKA Architekturu ITS lze popsat z různých hledisek a z více hledisek koncepčními, logickými a/nebo fyzickými reprezentacemi (viz také referenční architektura, funkční architektura, logická architektura, návrh rozmístění). POZNÁMKA Architektura ITS se nevztahuje na konkrétní lokalizaci.

komponenta ITS (ITS component) subsystém systému ITS, sestava nebo jiné hlavní prvky systému, které nemají samy o sobě nezávislou provozní funkcionalitu systém ITS (ITS systém) množina propojených komponentů, které spolu navzájem reagují organizovaným způsobem, aby poskytly nezávislou provozní funkcionalitu POZNÁMKA Toto je definice IEEE systému kvalifikovaného fází „Nezávislé provozní funkcionality“.

19


jednotka ITS (ITS unit) minimální komponenta schopná nezávislé funkcionality vrstva (layer) organizace klasifikátorů nebo balíků na stejné úrovni abstrakce {ISO/IEC 19501:2004(E)} link (link) sémantické spojení mezi více objekty. Instance asociace {ISO/IEC 19501:2004(E)} logická architektura (logical architecture) popisuje povahu systému založeného na informaci, řízení nebo funkcích a popisuje vzájemné vazby mezi těmito aspekty; logická architektura je nezávislá na hardwaru a softwaru {www.sectra.cl/its/glosario/terminos.htm} POZNÁMKA Logickou architekturu lze popsat buď objektově orientovanou nebo procesně orientovanou architekturou (viz objektově orientovaná a procesně orientovaná). POZNÁMKA V objektově orientované perspektivě zpracovává logická architektura koncepční chování a tím definuje některé podrobnosti objektu. POZNÁMKA V procesně orientované perspektivě stanovuje logická architektura povahu systému, který je založen na informacích a funkcích a popisuje vzájemné vazby těchto aspektů. POZNÁMKA Logická architektura je nezávislá na hardwaru a softwaru.

udržovatelnost (maintainability) schopnost zařízení být udržováno nebo obnovováno dle specifikovaných podmínek v dané časovém intervalu zpráva (message) (1) v nejobecnější rovině je objektem komunikace (2) v softwaru, množina dat seskupených dohromady pro přenos, který se provede podle pravidel daného protokolu takovým způsobem, že je čitelný odesílajícím i přijímajícím softwarem (San Diego State University) POZNÁMKA V závislosti na kontextu se termín může vztahovat jak na obsahy informací, tak na jejich aktuální prezentaci. POZNÁMKA V softwarových systémech se obvykle očekává, že aktivita bude následovat jako výsledek přijetí zprávy.

metatřída (metaclass) třída, jejímiž instancemi jsou třídy {ISO/IEC 19501:2004(E)} metadata (metadata) data vysoké úrovně, které definují a popisují charakteristiky datových prvků (jiných dat), například obsah, kvalitu, podmínky a jiné charakteristiky dat metamodel (metamodel) model, který objasňuje množinu souvisejících modelů definováním jazyku pro vyjádření takových modelů {ISO/IEC 19501:2004(E)} metodika (metodology) specifická sada prostředků a postupů používaných pro dosažení cíle metoda (method) prostředky provedení operace průběžný stav (mission statement) stav částí výsledku (dílčí výsledky), které mají být standardizovány, a postup, jak dosáhnout cíle (viz cílový stav) model (model) abstrakce fyzického systému s určitým účelem aspekt modelu (model aspect) dimenze modelování, která charakterizuje určitou kvalitu metamodelu {ISO/IEC 19501:2004(E)} zpracování modelu (model elaboration) proces generování repository z publikovaného modelu

20

Revize TR 14813-5:1999 jako ISO/CD 14813-5 POZNÁMKA Zahrnuje generování rozhraní a implementací, které umožňují repository, aby byl instanciovány a rozšiřovány na základě a v souladu se zpracovaným modelem {ISO/IEC 19501:2004(E)}.

prvek modelu (model element) prvek, který je charakterizován abstrakcí získanou ze systému, jenž je modelován {ISO/IEC 19501:2004(E)} modul (module) jakýkoliv počet různých, ale propojených jednotek, ze kterých lze postavit program nebo jakými lze analyzovat komplexní aktivitu {OED} identifikátor modulu (module identifier) instance identifikátoru objektu, který souvisí s přidruženým modulem vícenásobná dědičnost (multiple inheritance) sémantická variace generalizace, ve které jeden typ může mít více než jeden supertyp {ISO/IEC 19501:2004(E)} název (name) termín použitý člověkem jako nástroj identifikace datového prvku a dalších datových konceptů {OED} místo názvu (namespace) část modelu, ve které lze názvy definovat a používat POZNÁMKA V rámci místa názvu má každý název jednoznačný význam; viz název.

uzel (node) bod křížení nebo ukončení, kde lze očekávat akce nebo výsledky POZNÁMKA V softwaru se často klasifikátor, jenž reprezentuje výpočetní zdroj pro dobu provozu (run-time), má běžně alespoň paměť a často také určitou kapacitu proces zpracovat. Objekty doby provozu a komponenty se mohou nacházet na uzlech.

typ Non-ASN.1 (non-ASN.1 type) typ neshodný s ISO/IEC 8824 nespecifikovaný návrh (non specified design) obecný návrh založený spíše na požadavcích než na určité identifikaci zpřesňující zařízení nebo identifikaci výrobce objekt (object) entita s velmi dobře definovanými hranicemi a identita, která zahrnuje stav a chování, kde stav je reprezentován atributy a vazbami a chování je reprezentováno operacemi, metodami a stavovými stroji; v softwaru je objekt instancí určité třídy {ISO/IEC 19501:2004(E)} objektově orientovaná metodika (object oriented metodology) metodika založená na objektech, třídách a zprávách mezi objekty diagram objektu (object diagram) diagram, který znázorňuje objekty a jejich vztahy z hlediska času {ISO/IEC 19501:2004(E)} identifikátor objektu (object identifier) hodnota (rozlišitelná od všech ostatních), která je spojena s určitým objektem {ISO/IEC 8824-1: 2002, 3.8.46} typ identifikátoru objektu (object identifier type) jednoduchý typ, jehož významnou hodnotou je soubor všech identifikátorů objektu rozdělených podle směrnic ISO/lEC 9834-1 a ISO 14813-6 {ISO/IEC 8824-1: 2002, 3.8.36} POZNÁMKA Směrnice ISO/IEC 8824-1:2002 povolují široké škále orgánů, aby nezávisle asociovaly identifikátory s objekty.

operace (operation) služba, kterou si může instance třídy vyžádat, aby byla provedena; má svůj název a seznam souvisejících příkazů {ISO/IEC 19501:2004(E)} organizační architektura (organisational architecture) popis, kterým se označí, jak se dosáhnou požadavky příslušné organizace

21

Revize TR 14813-5:1999 jako ISO/CD 14813-5 POZNÁMKA Proces vývoje musí zahrnovat rozpoznání závislostí a hranic funkcí.

model OSI (OSI model) mezinárodní organizace pro normalizaci vyvinula referenční model – model propojení otevřených systémů (OSI) pro umožnění komunikace rozdílných nebo podobných systémů s dalšími POZNÁMKA Tento model stanoví referenční rámec pro popis výměny dat; je popsán v sedmi „vrstvách“.

soubor (package) obecný účelový mechanismus pro organizaci prvků do skupin {ISO/IEC 19501:2004(E)} POZNÁMKA Soubory mohou být uloženy v rámci jiných souborů.

parametr (parameter) specifikace proměnné, která se může změnit, uplynout nebo obnovit {ISO/IEC 19501:2004(E)} POZNÁMKA Parametr může typicky zahrnovat název, typ a směr. Parametry se používají pro operace, zprávy a události.

parametrizovaný prvek (parameterized element) deskriptor pro určitou třídu s jedním nebo více nespjatých parametrů {ISO/IEC 19501:2004(E)} rodič (parent) v obecném vztahu se jedná o generalizaci jiného prvku, dítěte {ISO/IEC 19501:2004(E)} účastnit se (participate) spojení modelového prvku ke vztahu nebo upravenému vztahu. Například určitá třída se účastní na asociaci, aktor se účastní určitého případu užití fyzická (aplikační) architektura (physical (application) architecture) přidělení logické architektury fyzickým entitám, ale bez vztahu k rozmístění zařízení POZNÁMKA Fyzická architektura, i když popisuje fyzické konfigurace v systémovém pojetí, se nevztahuje na konkrétní lokalizaci.

procesně orientovaná metodika (process oriented metodology) metodika založená na dekompozici referenční architektury na architekturu řízení, funkční a informační následná podmínka (postcondition) omezení, které musí být splněno při dokončení operace {ISO/IEC 19501:2004(E)} předběžná podmínka (precondition) omezení, které musí být splněno při spuštění operace {ISO/IEC 19501:2004(E)} základní typ (primitive type) předefinovaný základní datatyp bez jakékoliv substruktury, jako je celé číslo nebo řetězec {ISO/IEC 19501:2004(E)} proces (process) 1) Zásadní jednotka souběžnosti a výkonná složka provozovaného systému; 2) proces vývoje softwaru – kroky a návody, jimiž se vyvíjí systém; 3) Provést algoritmus nebo jinak provést něco dynamicky. {ISO/IEC 19501:2004(E)} profil (profile) stereotypní soubor, který obsahuje modelové prvky, jež byly přizpůsobeny určité doméně nebo účelu pomocí extenzivních mechanismů, jakými jsou stereotypy, definování tagem a omezení. POZNÁMKA Profil může také specifikovat modelové knihovny, na kterých závisí, a metamodelovou podmnožinu, kterou se rozšiřuje.

vlastnost (property) jmenovitá hodnota popisující charakteristiku určitého prvku, která má sémantický dopad

22


fyzický systém (physical system) instanciace systému, který může zahrnovat hardware, software, hardware a osoby, které jsou organizovány pro dosažení určitého účelu POZNÁMKA Fyzický systém lze popsat z jednoho i více hledisek.

přijetí (zprávy) (receive [a message]) naložení s podnětem, který přišel od instance odesílatele {ISO/IEC 19501:2004(E)} příjemce (objektu) (receiver [object]) objekt nakládající s podnětem, který přišel od odesílatele objektu {ISO/IEC 19501:2004(E)} referenční bod (reference point) identifikátor komponenty architektury indikující, že daná komponenta musí být zapracována do následné architektury registr (registry) nástroj pro záznam a uložení objektových modelů, rozhraní a datových konceptů v organizovaném a řízeném prostředí vazba (relationship) sémantické spojení mezi prvky modelu {ISO/IEC 19501:2004(E)} POZNÁMKA Příklady vazeb zahrnují asociace a generalizace.

spolehlivost (reliability) schopnost zařízení plnit určenou funkci za daných podmínek v daném časovém intervalu (nebo počtu cyklů) repository (repository) fyzický nástroj pro ukládání objektových modelů, rozhraní a implementací {ISO/IEC 19501:2004(E)} požadavek (requirement) něco žádaného nebo vyžadovaného, podmínka, která musí být splněna {OED} znovuužití (reuse) druhé nebo další použití určitého předem existujícího artefaktu role (role) jmenovité specifické chování určité entity účastnící se konkrétního kontextu {ISO/IEC 19501:2004(E)} POZNÁMKA Role může být statická (např. konec asociace) nebo dynamická (např. role spolupráce).

doba provozu (run time) časový úsek, během něhož počítačový program pracuje {ISO/IEC 19501:2004(E)} scénář (scenario) specifická sekvence akcí, která znázorňuje chování {ISO/IEC 19501:2004(E)} POZNÁMKA Scénář lze použít pro znázornění vykonání instance případu užití.

poslat (zprávu) (send [a message]) průchod podnětu od instance odesilatele k instanci příjemce {ISO/IEC 19501:2004(E)} odesílatel (objektu) (sender [object]) objekt, jenž vyšle podnět k objektu příjemce {ISO/IEC 19501:2004(E)} časový diagram A (sequence diagram A) termín užívaný v objektově orientovaném popisu pro diagram, který znázorňuje interakce objektu upravené do časové posloupnosti; konkrétně se objekty na interakci podílejí svou životností a zprávy, které si vyměňují, jsou uspořádány do časových posloupností POZNÁMKA Na rozdíl od diagramu spolupráce obsahuje časový diagram časové úseky, ale neukazuje asociaci mezi objekty. Časový diagram může existovat v obecné formě (popisuje všechny možné scénáře) a v momentální formě (popisuje jeden aktuální scénář). Časové diagramy a diagramy spolupráce vyjadřují podobné informace, ale zobrazují je odlišnými způsoby.

23


signál (signal) specifikace asynchronního podnětu komunikovaného mezi instancemi POZNÁMKA Signály mohou mít parametry.

podpis (signature) název a parametry použité pro identifikaci znaku chování POZNÁMKA Podpis může zahrnovat nepovinné navrácené jednoduché (datové) typy, definované přímo nastavením sady jeho hodnot. {ISO/IEC 8824-1: 2002, 3.8.49}

jednonásobná dědičnost (single inheritance) sémantická variace generalizace, ve které určitý typ může mít pouze jeden supertyp {ISO/IEC 19501:2004(E)} software (software) množina pokynů, také nazývaných programy, které řídí použití počítače {ISO/IEC 19501:2004(E)} softwarový modul (software module) softwarová jednotka pro ukládání a manipulaci. Moduly zahrnují moduly zdrojových kódů, moduly binárních kódů a module spouštěcích kódů {ISO/IEC 19501:2004(E)} specifikace (specification) deklarovaný popis něčeho, co je nebo dělá, včetně prostředků, jak dosáhnout daných cílů {ISO/IEC 19501:2004(E)} specifikovaný návrh (specified design) přesná specifikace zařízení nebo označení výrobce v souvislosti s implementací stav (state) podmínka nebo situace během životnosti objektu, během které splňuje dané podmínky, provádí dané aktivity nebo čeká na nějakou událost {ISO/IEC 19501:2004(E)} diagram stavové tabulky (statechart diagram) diagram, který ukazuje stavový stroj {ISO/IEC 19501:2004(E)} stavový stroj (state machine) chování, které specifikuje sekvence stavů, jimiž prochází určitý objekt nebo interakce během své životnosti jako odezva na události, společně se svými odezvami a akcemi {ISO/IEC 19501:2004(E)} stereotyp (stereotype) modelový prvek, který rozšiřuje sémantiku metamodelu {ISO/IEC 19501:2004(E)} POZNÁMKA Stereotypy se musí zakládat na jistých existujících typech nebo třídách metamodelu. Stereotypy mohou rozšířit danou sémantiku, ale ne strukturu předem existujících typů a tříd.

podnět (stimulus) výsledek průchodu informace od jedné instance ke druhé, jako je vysílání signálu nebo spuštění operace {ISO/IEC 19501:2004(E)} POZNÁMKA Přijetí signálu se běžně považuje za událost.

řetězec (string) řada textových znaků {ISO/IEC 19501:2004(E)} podtřída (subclass) ve vazbě generalizace se jedná o specifikaci jiné třídy; supertřída {ISO/IEC 19501:2004(E)} subsystém (subsystem) seskupování modelových prvků, které reprezentuje jednotku chování v určitém fyzickém systému POZNÁMKA Subsystém nabízí rozhraní a má operace. Navíc mohou být prvky modelu daného subsystému rozděleny do prvků specifikace a realizace.

podtyp (subtype) ve vazbě generalizace se jedná o specifikaci jiného typu; supertyp {ISO/IEC 19501:2004(E)}

24


supertřída (superclass) ve vazbě generalizace se jedná o generalizaci jiné třídy; podtřída {ISO/IEC 19501:2004(E)} supertyp (supertype) ve vazbě generalizace se jedná o generalizaci jiného typu; podtypu {ISO/IEC 19501:2004(E)} kontinuita (řízení) (thread [of control]) jeden způsob provedení pomocí programu, dynamický model, nebo nějaká jiná reprezentace toku řízení {ISO/IEC 19501:2004(E)} typ (type) stereotypní třída, která specifikuje určitou doménu objektů společně s danými operacemi aplikovanými na tyto objekty, bez definice fyzické implementace těchto objektů {ISO/IEC 19501:2004(E)} POZNÁMKA Typ nemůže obsahovat žádné metody, udržovat svoji kontinuitu řízení nebo být vložen. Nicméně může mít atributy a asociace.

třída případu užití (use case [class]) specifikace sekvence akcí, včetně variant, kterou systém (nebo jiná entita) může provést s interakcí s aktory daného systému {ISO/IEC 19501:2004(E)} diagram případu užití (use case diagram) grafický model vyjadřující vazby mezi aktory a případy užití {ISO/IEC 19501:2004(E)} instance případu užití (use case instance) funkční charakteristiky sekvence akcí, které jsou specifikovány v případu užití; instance případu užití {ISO/IEC 19501:2004(E)} model případu užití (use case model) model, který popisuje požadavky na funkce systému v termínech případů užití (viz: třída případu užití) uživatel (user) hlavní příjemce systému ITS POZNÁMKA Uživatel může být koncovým uživatelem (např. řidič vozidla) nebo poskytovatelem systému (např. manager dopravního systému) nebo jiný prostředník, který systém užívá.

pohled/hledisko (View/ viewpoint) projekce modelu, který je nahlížen z dané perspektivy nebo výhodné pozice a který vynechává entity, jež nejsou relevantní k této perspektivě {ISO/IEC 19501:2004(E)} konečný stav (vision statement) stav sumarizující celkový koncept a cíle, kterých se norma snaží dosáhnout B.2

Glosář zkratek a akronymů

Tento glosář zkratek se musí použít při popisu aspektů architektury ITS v normách ITS. BER Základní kódovací pravidla (ISO\IEC 8825, re ASN.1) DFD diagram datového toku IEEE Institut elektrických a elektrotechnických inženýrů ITS Inteligentní dopravní systémy OMG Normalizační komise pro management objektu RTTT Telematika silniční přepravy a provozu (starý evropský název pro ITS) 25


TICS systémy dopravních informací a řídicí systémy (starý název pro inteligentní dopravní systémy) TC Technická komise TOR Soupis podkladů (referenční dokumenty) TR Technická zpráva WG Pracovní skupina B.3 Číselné zápisy Pro účely této mezinárodní normy a pro mezinárodní normy CEN a ISO v sektoru ITS platí tato ustanovení. Číselné zápisy jsou reprezentovány takto: Desetinný („běžný") zápis nesmí mít žádné indexy, např.:

127

Šestnáctková soustava se musí zapsat indexem 16, např.:

7F16

Binární čísla se musí zapsat indexem 2, např.:

011111112

26


Bibliografie UML odkaz na URL: http://www.omg.org/library/schedule/Technology_Adoptions.htm#UML_Specification. Architektury lze popsat a definovat mnoha způsoby, například RM-ODP (ISO IEC 10746) od (Putman 2001), (Hofmeister 2000) nebo (Clements 2003) pro SEI.

27

NORMA ISO ISO CD ISO STANDARD září 2006 NORME ISO ISO NORM

Recommend Documents