Студопедия

КАТЕГОРИИ:


Архитектура-(3434)Астрономия-(809)Биология-(7483)Биотехнологии-(1457)Военное дело-(14632)Высокие технологии-(1363)География-(913)Геология-(1438)Государство-(451)Демография-(1065)Дом-(47672)Журналистика и СМИ-(912)Изобретательство-(14524)Иностранные языки-(4268)Информатика-(17799)Искусство-(1338)История-(13644)Компьютеры-(11121)Косметика-(55)Кулинария-(373)Культура-(8427)Лингвистика-(374)Литература-(1642)Маркетинг-(23702)Математика-(16968)Машиностроение-(1700)Медицина-(12668)Менеджмент-(24684)Механика-(15423)Науковедение-(506)Образование-(11852)Охрана труда-(3308)Педагогика-(5571)Полиграфия-(1312)Политика-(7869)Право-(5454)Приборостроение-(1369)Программирование-(2801)Производство-(97182)Промышленность-(8706)Психология-(18388)Религия-(3217)Связь-(10668)Сельское хозяйство-(299)Социология-(6455)Спорт-(42831)Строительство-(4793)Торговля-(5050)Транспорт-(2929)Туризм-(1568)Физика-(3942)Философия-(17015)Финансы-(26596)Химия-(22929)Экология-(12095)Экономика-(9961)Электроника-(8441)Электротехника-(4623)Энергетика-(12629)Юриспруденция-(1492)Ядерная техника-(1748)

A.4.1 Подсистемы

A.3.2 Сложность процедурно-ориентированного программного обеспечения

Сложность является мерой точек принятия решений и логических ветвей исполнения кода. Техническая литература по разработке программного обеспечения определяет сложность как отрицательную характеристику программного обеспечения, поскольку она препятствует пониманию логики и выполнения кода. Другим препятствием для понимания кода является наличие кода, который не является необходимым, в том смысле, что он не используется или является избыточным.

Использование слоев для разделения уровней абстракции и минимизации циклических зависимостей дополнительно позволяют улучшить понимание ФБО, обеспечивая большее доверие к тому, что функциональные требования безопасности ОО точно и полно представлены в реализации.

Уменьшение сложности также включает в себя снижение или устранение взаимной зависимости, которая относится как к модулям одного слоя, так и к модулям различных слоев. Модули, зависимые друг от друга, могут полагаться на друг друга, чтобы получить единственный результат, который может привести к тупиковому состоянию, или, что еще хуже, к состоянию гонок (например, отношение времени проверки против ее заданного времени), где окончательный вывод может быть неопределенным и зависеть от вычислительной среды в данный момент времени.

Минимизация сложности проекта - ключевая характеристика механизма проверки обращений, цель которой прийти к ФБО, которые легко понять, чтобы их можно было полностью проанализировать (Существуют и другие важные характеристики механизма проверки обращений, такие как самозащита ФБО и невозможность их обхода; эти другие характеристики рассматриваются в требованиях семейства ADV_ARC).

A.4 ADV_TDS: Подсистемы и модули

Этот подраздел содержит дополнительные указания по семейству ADV_TDS, и использованию в нем терминов "подсистема" и "модуль". Они следуют после обсуждения того, как при наличии более глубокой детализации, снижаются требования к меньшей детализации.

Рисунок А.3 показывает, что, в зависимости от сложности ФБО, проект может быть описан в терминах подсистем и модулей (где подсистемы находятся на более высоком уровне абстракции, чем модули); или он может быть описан в терминах одного уровня абстракции (например, подсистем на более низком уровне доверия, а модули на более высоких уровнях). В случаях, когда представляется более низкий уровень абстракции (модули), требования, предъявляемые к более высокому уровню абстракции (подсистемы), по существу, выполняются по умолчанию. Эта концепция развивается далее в обсуждении подсистем и модулей.

 
 

 


Рисунок А.3 - Подсистемы и модули

 

 

Предполагается, что разработчик должен описать проект ОО в терминах подсистем. Термин "подсистемы" был специально выбран неопределенным, чтобы можно было сослаться на компоненты, соответствующие ОО (например, подсистемы, модули). Подсистемы могут быть даже неравномерными по объему, пока требования к описанию подсистем не будут выполнены.

Первое применение подсистем состоит в определении границ ФБО; то есть частей ОО, которые составляют ФБО. Обычно, подсистема является частью ФБО, если она имеет возможность (либо по проекту, либо по реализации) влиять на правильность выполнения любого из ФТБ. Например, для программного обеспечения, зависимого от различных режимов работы аппаратных средств, чтобы обеспечить разделение доменов (см. А.1), где код, обеспечивающий выполнение ФТБ, выполняется в одном домене, тогда подсистемы, которые выполняются в этом домене, будут рассматриваться как часть ФБО. Аналогично, если сервер за пределами данного домена реализует ФТБ (например, осуществляет политику управления доступом над объектами, которыми управляет), то он тоже будет считаться частью ФБО.

Второе применение подсистем состоит в предоставлении структуры для описания ФБО на уровне описания, при котором, описание того, как работают ФБО, не обязательно должно содержать низкоуровневые подробности реализации, имеющиеся в описаниях модулей найденные в описании модулей (рассматривается ниже). Подсистемы описываются либо на высоком уровне (без избытка подробностей реализации) или на подробном уровне (предоставляя большее ознакомление с реализацией). Уровень описания, предоставляемый для подсистем, определяется тем, в какой степени подсистема отвечает за реализацию ФТБ.

Подсистема, обеспечивающая выполнение ФТБ, является подсистемой, которая предоставляет механизмы для обеспечения выполнения какого-либо элемента любого ФТБ, или непосредственно поддерживает подсистему, которая несет ответственность за обеспечение выполнения ФТБ. Если подсистема предоставляет (реализует) ИФБО, обеспечивающие выполнение ФТБ, то она является подсистемой, обеспечивающей выполнение ФТБ.

Подсистемы также могут быть определены как способствующие выполнению ФТБ и не влияющие на выполнение ФТБ. Подсистема, способствующая выполнению ФТБ, является зависимой от подсистемы, обеспечивающей выполнение ФТБ, чтобы реализовать ФТБ, но не играет такой непосредственной роли, как подсистема, обеспечивающая выполнение ФТБ. Подсистема, не влияющая на выполнение ФТБ, является независимой ни от способствующей выполнению, ни от обеспечивающей выполнение роли в реализации ФТБ.

<== предыдущая лекция | следующая лекция ==>
A.3.1.2 Соединение | A.4.2 Модули
Поделиться с друзьями:


Дата добавления: 2014-01-15; Просмотров: 2564; Нарушение авторских прав?; Мы поможем в написании вашей работы!


Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет



studopedia.su - Студопедия (2013 - 2024) год. Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав! Последнее добавление




Генерация страницы за: 0.01 сек.