ГОСТ Р ИСО/МЭК 18045—2013
реализации при выполнении анализа в других шагах оценивания. Поэтому поощряется выполнение
выборки представления реализации ОО из областей 00. которые будут представлять наибольший ин
терес во время проведения анализа, выполняемого в рамках шагов оценивания других семейств (на
пример ATE IND. AVA_VAN иADVJNT).
10.5.1.4 Действие ADVJMP.1.1E
ИСО/МЭК 15408-3 ADVJMP.1.1C: Представление реализации должно определить ФБО на таком
уровне детализации, что ФБО могут быть созданы без дополнительных проектныхрешений.
10.5.1.4.1 Шаг оценивания ADVJMP.1-1
Оценщик должен проверить представление реализации, чтобы сделать заключение, определе
ны ли однозначно в нем ФБО на таком уровне детализации, что ФБО могут быть сгенерированы без ка
ких бы то ни было дальнейших проектных решений.
Исходный код или диаграммы аппаратных средств и/или программный код модели интеграль
ных схем или размещения данных, которые используются для построения фактических аппаратных
средств, являются примерами частей представления реализации. Оценщик оценивает выборку пред
ставления реализации, чтобы приобрести уверенность в том. что этот уровень является приемлемым,
а не, например псевдокодовым представлением, которое требует дополнительных проектных решений.
Поощряется выполнение быстрой проверки, сначала проанализировав представление реализации,
чтобы удостовериться, что разработчик находится на верном пути. Однако поощряется также выполне
ние большей части этой проверки при работе на других шагах оценивания, на которых необходимо ис
следовать представление реализации: это поможет удостовериться в том. что выборка, исследованная
во время этого шага оценивания, является релевантной.
ИСО/МЭК 15408-3 ADVJMP.1.2С: Представление реализации должно быть изложено в том виде,
какой используется персоналом, занимающимся разработкой.
10.5.1.4.2 Шаг оценивания ADVJMP.1-2
Оценщикдолжен проверить, что представление реализации изложено в виде, используемом пер
соналом разработки.
Представление реализации выполняется разработчиком таким образом, чтобы потом была воз
можность превращения этого представления в фактическую реализацию. Например, разработчик мо
жет работать с файлами, содержащими исходный текст программ, который потом будет скомпилирован и
станет частью ФБО. Разработчик делает доступным представление реализации в той форме, в ка кой
он его использует, благодаря чему оценщик может применять методы автоматизированного анали за.
Это также увеличивает уверенность в том. что оцениваемое представление реализации является
именно тем, которое используется при производстве ФБО (в отличие от того случая, когда оно сопро
вождается альтернативным форматом представления, например документом текстового процессора).
Следует отметить, что разработчик может использовать различные формы представления реализации;
они также должны прилагаться. Основная цель — снабдить оценщика такой информацией, которая по
зволила бы максимизировать эффективность его усилий по анализу.
Оценщик исследует выборку представления реализации, чтобы приобрести уверенность в том,
что оцениваемая версия является приемлемой для использования разработчиком. Выборка должна
быть такой, чтобы у оценщика имелось доверие к тому, что все области представления реализации
удовлетворяют требованию; однако не требуется проводить полное исследование всего представления
реализации.
Соглашения в некоторых формах представления реализации могут затруднить или сделать не
возможным только по представлению реализации сделать заключение о том. каким будет фактический
результат компиляции или интерпретации при запуске. Например, директивы компилятора на языке Си
приведут к тому, что компилятор исключит или включит целые части программного кода.
Для некоторых форм представления реализации требуется дополнительная информация, по
скольку их довольно сложно понять и проанализировать. В качестве примера можно привести «скры
тый» или каким-либо образом запутанный фрагмент исходного текста программы, который сложно
понять и/или проанализировать. Подобные формы представления реализации чаще всего возника ют.
когда разработчик ОО применяет к некоторой версии представления реализации некие программы по
сокрытию или запутыванию кода. Хотя представление со скрытыми участками кода является именно тем.
что будет в дальнейшем подвергнуто компиляции, а потому может быть даже ближе к реализации (по
структуре), чем оригинальная версия, но предоставление оценщику запутанного программного кода
может привести к тому, что анализ рисков, связанных сданным представлением реализации, потребует
значительно больше времени. При создании подобных форм представления в компонентах данного
77