8(495)909-90-01
8(964)644-46-00
pro@sio.su
Главная
Системы видеонаблюдения
Охранная сигнализация
Пожарная сигнализация
Система пожаротушения
Система контроля удаленного доступа
Оповещение и эвакуация
Контроль периметра
Система домофонии
Парковочные системы
Проектирование слаботочных сетей
Аварийный
контроль
Раздел: Документация

0 ... 5 6 7 8 9 10 11 ... 117

In each class a figure describing the family hierarchy similar to Figure 2.4, is provided. In Figure 2.4. the first family, Family 1, contains three hierarchical components, where component 2 and component 3 can both be used to satisfy dependencies on component 1. Component 3 is hierarchical to component 2 and can also be used to satisfy dependencies on component 2.

Figure 2.4 - Sample class decomposition diagram

In Family 2 there are three components not all of which are hierarchical. Components 1 and 2 are hierarchical to no other components. Component 3 is hierarchical to component 2, and can be used to satisfy dependencies on component 2, but not to satisfy dependencies on component 1.

In Family 3, components 2, 3, and 4 are hierarchical to component 1. Components 2 and 3 are both hierarchical to component 1, but non-comparable. Component 4 is hierarchical to both component 2 and component 3.

These diagrams are meant to complement the text of the families and make identification of the relationships easier. They do not replace the "Hierarchical to:" note in each component that is the mandatory claim of hierarchy for each component.

2.2.1 Component changes highlighting

The relationship between components within a family is highlighted using a bolding convention. This bolding convention calls for the bolding of all new requirements. For hierarchical components, requirements and/or dependencies are bolded when they are enhanced or modified beyond the requirements of the previous component. In addition, any new or enhanced permitted operations beyond the previous component are also highlighted using bold type.



3 Class FAU: Security audit

Security auditing involves recognising, recording, storing, and analysing information related to security relevant activities (i.e. activities controlled by the TSP). The resulting audit records can be examined to determine which security relevant activities took place and whom (which user) is responsible for them.

Security audit

FAU ARP Security audit automatic response

FAU GEN Security audit data generation

FAU SAA Security audit analysis

FAU SAR Security audit review

1

1

2

2

1

1

2

З

FAU SEL Security audit event selection\-\ 1

FAU STG Security audit event storage

Figure 3.1 - Security audit class decomposition



0 ... 5 6 7 8 9 10 11 ... 117