63

Реализация такой системы не элементарна и требует решения ряда проблем, одна из которых – своевременная синхронизация данных.

Сервис-ориентированная архитектура обеспечивает реализацию модуль-

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

Рис. 4.8 – Сервис-ориентированная архитектура

4.3.3 Процессы проектирования программных продуктов

· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·

Процесс проектирования архитектурного или высокоуровневого дизайна включает следующие виды деятельности:

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

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

разработку и документальное оформление проекта верхнего уровня для базы данных;

64

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

определение и документирование требований к предварительному тестированию и графику работ по комплексированию про-

граммных компонентов и программного продукта в целом.

· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·

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

исопровождения ПП.

Кключевым вопросам детализированного проектирования относятся декомпозиция архитектуры на функциональные компоненты для независимого и параллельного их выполнения, принципы и механизмы их взаимодействия между собой, обеспечения качества и живучести программного обеспечения в целом. Один из вариантов декомпозиции описан в ГОСТ 34.003–90 «Информационная технология. Автоматизированные системы. Термины и определения», где предлагается выделять и описывать следующие элементы программного продукта:

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

2)программный продукт – совокупность программных компонент, реализующих конкретный бизнес-процесс;

3)сложный программный компонент – совокупность программных ко-

дов, реализующих сложную функцию бизнес-процесса;

4)программный компонент – совокупность программных кодов, реализующих элементарную функцию бизнес-процесса.

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

65

4.3.4 Моделирование процессов разработки архитектуры программной системы управления и контроля работы скорой помощи

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

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

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

Машины скорой помощи

Рис. 4.9 – Контекстная диаграмма для системы управления и контроля скорой помощи

· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·

Другие возможные внешние сущности системы, представленные на диаграмме, тоже обязательны, но для простоты в данном примере не будут далее рассматриваться.

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

67

Звонящие

Переговоры со звонящими

Машины скорой помощи

Рис. 4.11 – Детализированная модель системы управления и контроля работы скорой помощи

· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·

· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·

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

ровать в следующем виде: «Диспетчер скорой помощи должен иметь возможность получать и отрабатывать информацию от зво-

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

· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·

68

Пример системного требования ко времени реакции на звонок может быть представлено в следующем виде: «Система должна обеспечить диспетчеру по-

лучение информации от звонящего до назначения машины скорой помощи в течение T минут» (рис. 4.12).

Рис. 4.12 – Архитектура ПП «Управление и контроль работы скорой помощи»

· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·

Таким образом, использование при моделировании диаграммы потоков данных позволяет разработчикам:

отобразить потоки данных и функциональность системы;

определить функции, потоки и хранилища данных;

определить интерфейсы между функциями;

реализовать процедуры получения системных требований;

приступить непосредственно к разработке программного обеспечения.