5. Структурний підхід до проектування

Разработка автоматизированных систем (АС) выполнялась и выполняется на основе положений, представленных в стандарте ГОСТ 34.601-90. Он состоит из стадий и этапов разработки АС, которые, в зависимости от особенностей автоматизируемой системы, можно объединять друг с другом или вообще не включать в процесс разработки. Основанием для разработки АС является договор между разработчиком системы и ее заказчиком.

Этапами стандарта, ориентированным на разработку архитектуры АС, являются: формирование требований к АС, разработка концепции АС и проектирование технического проекта, в котором на основе сформулированных требований и концепций их реализации задаются конкретные задачи системы и пути их решения.

Эти этапы заканчивается созданием и утверждением отчета о научно-исследовательской работе, в которой дается оценка необходимых для реализации АС ресурсов, вариантов разработки АС и порядка проведения оценки качества системы.

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

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

Проектные решения определяют организационную структуру, функции персонала АС, структуру технических средств, языка программирования, СУБД, общие характеристики ПО, систему классификации и кодирования, а также варианты ведения информационной базы системы.

Таким образом, данный стандарт обеспечивает:

- концептуальное проектирование, которое состоит в уточнении и согласовании деталей требований;

- архитектурное проектирование, которое состоит в определении главных структурных особенностей создаваемой системы;

• техническое проектирование, которое состоит в отображении требований на среду функционирования системы и определении задач и принципов их реализации;

• детальное проектирование, которое состоит в определении алгоритмов задач, построения БД и программного обеспечения системы.

При концептуальном проектировании определяются:

• источники поступления данных от заказчика, который несет ответственность за их достоверность;

• объекты системы и их атрибуты;

• способы материализации связей между объектами и виды организации данных.

• интерфейсы с потенциальными пользователями системы на ранних стадиях ЖЦ цикла разработки системы для оказания им помощи при формулировки целей и функций системы;

- правила взаимодействия пользователя и системы с точки зрения понимания, эффективности и скорости реакции системы.

Организация интерфейсов базируется на определенных ключевых элементах, определение которых предшествует проектированию конкретных экранов и форматов обмена данными, в частности:

1) значащие термины, образы и понятия, которые являются для пользователя понятными и распространенные в домене;

2. ментальная модель организации и представления данных, функций и ролей;

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

4. визуальные приемы демонстрации пользователю элементов системы;

5. методы взаимодействия, которые отвечают требованиям пользователей будущей системы.

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

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

Для построения интерфейсов существует широкий выбор методов и средств. Большинство из них базируется на фиксации определенных классов объектов интерфейса (выбор из меню, заполнение экранных форм и др.) и средствах монтирования их в программную систему в виде интегрированных блоков или автономных подсистем интерфейса с пользователем.

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

Содержание операций, которые способны выполнять объекты, может быть раскрыто с помощью диаграмм потоков данных.

Взаимодействие объектов организовывается путем обмена сообщений, в ответ на которые они выполняют соответствующие операции и изменяют свое состояние, или посылают сообщения другим объектам.

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

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

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

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

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

В основу структурного подхода положены такие общие принципы:

- разбивка системы на множество независимых задач, легких для понимания и решения;

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

В основе этих принципов лежат операции:

• абстрагирования, т.е. выделения существенных аспектов системы и отвлечения от несущественных;

• формализации, т.е строгое методологическое решение проблемы;

• непротиворечивости, состоящей в обосновании и согласовании элементов системы;

• структуризации данных (т.е. данные должны быть структурированы и иерархически организованы).

При структурном анализе применяются в основном три вида наиболее распространённых моделей проектирования ПС:

SADT (Structured Analysis and Design Technique) модель и соответствующие функциональные диаграммы;

SSADM (Structured Systems Analysis and Design Method) - метод структурного анализа и проектирования;

IDEF0 (Integrated Definition Functions) метод создания функциональной модели, IDEF1 - информационной модели, IDEF2 - динамической модели и др.

На стадии проектирования эти модели расширяются, уточняются и дополняются диаграммами, отражающими структуру программного обеспечения: архитектуру ПО, структурные схемы программ и диаграммы экранных форм.