2.1.7Измерение программных требований

Для обеспечения качества программных требований полезно иметь методы, определяющие «объем» требований для создаваемого программного продукта. Такая оценка полезна для исследования предполагаемых изменений в требованиях, оценки стоимостных характеристик разработки и поддержки программной системы, опосредовано – оценки продуктивности разработки и эффективности поддержки на этапах реализации требований и внесения изменений и т.п. [Орлик]

2.2Проектирование программных средств

Проектирование в основном рассматривается как двух-шаговый процесс [Орлик]:

• Архитектурное проектирование – декомпозиция структуры (статической) и организации (динамической) компонент;

• Детализация архитектуры – описывает специфическое поведение и характеристики отдельных компонент.

Выходом этого процесса является набор моделей и артефактов, содержащих результаты решений, принятых по способам реализации требований в программном коде.

2.2.1Принципы проектирования

В качестве основных принципов проектирования выделим следующие:

Абстракция

Абстракция – отвлечение в процессе познания от несущественных сторон, свойств, связей объекта (предмета или явления) с целью выделения их существенных, закономерных признаков; абстрагирование; теоретическое обобщение как результат такого отвлечения [википедия].

Абстракция – модель, упрощающая поставленную проблему до рамок, значимых для заданного контекста [орлик].

В контексте проектирования программных систем существует два механизма абстракции – параметризация и детализация. При этом, абстракция через детализацию может быть: процедурной (связанной с поведением), абстракцией данных (связанной с информацией) и абстракцией контроля (связанной с управлением системой и обрабатываемой ею информацией).

Связанность и соединение

Связанность – определяет силу взаимосвязи между модулями. Соединение – определяет взаимосвязь элементов внутри модуля, внутренние связи. 

Декомпозиция и разбиение на модули

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

Инкапсуляция 

Предполагает группировку и упаковку элементов и внутренних деталей абстракции в отношении реализации с тем, чтобы эти детали были недоступны пользователям элементов. В качестве «пользователя» одного компонента может выступать другой компонент. Более того, при использовании объектно-ориентированного подхода, наследники компонентов могут не иметь доступа ко внутренним деталям реализации компонента, который является их предком.

Разделение интерфейса и реализации

Данная техника предполагает отделение компонента через специфицирование интерфейса, известного и доступного клиентам (или другим компонентам), от непосредственных деталей реализации.

Достаточность, полнота и простота

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

2.2.2Структура и архитектура программного обеспечения

Архитектура программного обеспечения – описание подсистем, компонент программной системы и связей между ними. Архитектура задаёт способ, которым программная система организована.

На сегодняшний день сформировался взгляд на архитектуру, как на приложение общих принципов организации программных компонент, что привело к накоплению множества подходов и созданию различных архитектурных «фреймворков», то есть систематизированных комплексов методов, практик и инструментов, призванных формализовать имеющийся в индустрии опыт.

Фреймворк (англ. framework — каркас, структура) — структура программной системы; программное обеспечение, облегчающее разработку и объединение разных компонентов большого программного проекта. В отличие от библиотек, которые объединяют набор подпрограмм близкой функциональности, фреймворк содержит в себе большое количество разных по назначению библиотек. Употребляется также слово «каркас», а некоторые авторы используют его в качестве основного, в том числе не базируясь вообще на англоязычном аналоге. Можно также говорить о каркасном подходе^[3] как о подходе к построению программ, где любая конфигурация программы строится из двух частей: первая, постоянная часть — каркас, не меняющийся от конфигурации к конфигурации и несущий в себе гнезда, в которых размещается вторая, переменная часть — сменные модули (или точки расширения) [википедия].

Примеры такой систематизации в форме фреймворков:

TOGAF [TOGAF81, 2003] – The Open Group Architecture Framework (на момент первичного написания данной главы доступен в версии 8.1, впервые опубликованной в декабре 2003 года; в 2009 году вышла версия TOGAF 9)

Модель Захмана – Zachman Framework [Zachman]

Руководство по архитектуре электронного правительства E-Gov Enterprise Architecture Guidance [E-Gov, 2002]