Лаврищева Е.М., Петрухин В.А. Методы и средства инженерии программного обеспечения

Подождите немного. Документ загружается.

касается отдельных объектов как базовых составляющих (компонентов) архитектуры

системы в целом.

Важным принципом объединения компонентов в систему является наличие у

компонентов общих событий, причем чаще всего один из компонентов порождает

событие, а другие на его реагируют. На этом принципе базируется способ

объединения отдельных объектов и компонентов в систему.

Программная система в

целом рассматривается как взаимодействие объектов с

помощью механизма обмена сообщениями (между объектами системы и внешними

объектами) для задания определенных событий и данных к ним. При этом считается,

что внешние события, которых система не запрашивает, приводят к запуску системы.

Внешние события, ожидание которых предусмотрено в системе, представляются в

виде сообщений, посылаемых системою внешним объектам, которые в ответ

направляют сообщение о наступлении или отсутствии событий.

Поскольку поведение отдельного объекта представлено диаграммой перехода

состояний, то поведение системы в целом представляется как схема взаимодействия

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

схеме овалом с этим названием. Овалы связаны между собою стрелками

, отвечающими

сообщениям о событиях, связывающих отдельные диаграммы перехода состояний. На

стрелке указывается метка события, а направление стрелки соответствует направлению

передачи сообщения. Внешние объекты обозначаются прямоугольниками с

названиями. Пример взаимодействия моделей поведения объектов приведен на рис. 4.2.

С5

С6

С1

ОПЕРАТОР

Модель состояний 1

Модель состояний 3

Модель состояний 4

Модель состояний 2

С3С2

С4

С7

С8

Рис. 4.2. Схема взаимодействия моделей поведения объектов

4.1.3. Модель процессов

Модель состояний объектов задает требования к поведению системы, предусматривает

определение действий, которые сопровождают изменение состояний объектов.

Действия – это алгоритмы, которые выполняются системой как реакции на события и

функции системы. Понимание требований к системе предусматривает и понимание

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

понимания действий используется декомпозиция их на отдельные составляющие,

названные процессами.

Последовательность выполняемых процессов образует поток управления. Процессы

обмениваются данными, образуя потоки данных. Два указанных выше типа потоков

предлагается использовать как модели алгоритмов действий системы. Для их

представления в данном методе предусмотрена специальная нотация, получившая

название диаграммы действий потоков данных.

В качестве источников данных могут быть:

– атрибуты объектов, которые продолжают существовать после завершения работы

системы;

– системные часы, как показатель времени;

таймеры;

– данные событий;

– сообщения внешних объектов (людей, операторов и т.п.).

Правила построения диаграмм действий потоков данных:

– каждой из диаграмм перехода состояний может отвечать только одна диаграмма

действий потоков данных;

– процесс изображается овалом, в середине которого указано содержание или

название процесса;

– потоки данных изображены стрелками, на которых указываются идентификаторы

данных, передаваемых от процесса к процессу; стрелка к овалу процесса указывает

на входные данные процесса, направление от овала процесса - на выходные данные;

– источники данных изображены как прямоугольники или рамками с открытыми

сторонами;

– данным, имеющим своими источниками архивные объекты, соответствуют потоки

с названиями атрибутов объектов, которые передаются потоками (при этом название

объекта может не указываться);

– потоки данных от таймера маркируются названием таймера;

– потоки данных от системных часов маркируются показателями времени (час,

минута, и т.п.);

– событие, сообщение о котором получает процесс, изображается как стрелка,

маркируемая названиями данных событий;

– процесс, породивший событие и процесс от приема сообщения о событии,

относятся к одной диаграмме действий потоков данных и связывается потоком;

– если событие, созданное процессом некоторой диаграммой действий потоков

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

данных, для первого из указанных выше процессов указывается стрелкой, ведущей от

процесса в "никуда", а для второго - стрелкой, ведущей к процессу из "ниоткуда",

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

Различаются следующие типы процессов:

– аксессор, осуществляющий доступ к архивам;

– генератор событий;

– преобразователь данных (вычисления);

– проверки условий.

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

пунктирными стрелками. Если процесс представляет собой проверку определенного

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

процессу, то соответствующий поток управления изображается перечеркнутой

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

4.3.

не равен 0 равен 0

Счетчик полосканий

Отнять 1 от д

счетчика

Проверить,

счетчик = 0

П6. Включить сушку

П7. Включить подачу воды

Рис. 4.3. Пример диаграммы действий потоков данных

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

процессов, которое входят в ее состав. Для описания подробностей действий

процессов нотация не регламентируется.

После завершения описания диаграммы действий потоков данных для всех объектов

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

– идентификатор процесса;

– тип процесса;

– название процесса;

– название состояния, для которого определен процесс;

– название действия состояния.

Такая таблица дает возможность проверить: непротиворечивость названий и

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

генерируются или обрабатываются соответствующим процессом. Кроме того, наличие

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

или состояний и унифицировать их.

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

процессов или по модели состояний или по типу процесса.

Результатами метода инженерии требований С.Шлаер и С.Меллора являются три

модели.

1. Информационная модель системы, состоящая из:

– диаграммы сущность – связь;

– описания объектов и их атрибутов (неформальное);

– описания связей между объектами (неформальное).

2. Модель поведения объектов системы, представленная в виде:

– диаграммы переходов в состояния диаграмм перехода состояний или таблицы

перехода состояний;

– неформальное описания действий диаграммами перехода состояний;

– неформальное описания событий диаграммами перехода состояний.

3. Модель процессов состояний объектов, представленная в виде:

– диаграмм действий потоков данных;

– таблицы процессов состояний;

– неформальное описание процессов.

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

проектирования системы.

4.2. Методы проектирования архитектуры ПО

Проектирование ПО – это процесс разработки, следующий за этапом анализа и

формирования требований. Задачей проектирования является преобразование

требований к системе в проектные решения, требования к ПО и построение

архитектуры системы.

Проектирование архитектуры системы проводится разными методами, основанными

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

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

включая соответствующие им конструктивные элементы и методы задания структуры

моделей (концептуальной, объектной и др.) системы. Среди методов проектирования

наиболее часто использовался стандартный, процессы и задачи которого

регламентированы стандартом.

При проектировании используется объектно-ориентированная парадигма, по которой

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

подпроцессы проектирования будем рассматривать относительно тех объектов,

требования к которым определены на этапе инженерии требований.

4.2.1. Стандартный подход к проектированию системы

Разработка автоматизированных систем (АС) выполнялась и выполняется на основе

положений, представленных в стандарте ГОСТ 34.601-90 (см. Приложение 2). Он

состоит из стадий и этапов разработки АС, которые, в зависимости от особенностей

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

в процесс разработки. Основанием для разработки АС является договор между

разработчиком системы и ее заказчиком.

Этапами стандарта, ориентированным на разработку архитектуры АС, являются:

формирование требований к АС, разработка концепции АС и проектирование

технического проекта, в котором на основе сформулированных требований и

концепций их реализации задаются конкретные задачи системы и пути их решения.

Эти этапы заканчивается созданием и утверждением отчета о научно-

исследовательской работе, в которой дается оценка необходимых для реализации АС

ресурсов, вариантов разработки АС и порядка проведения оценки качества системы.

На этапе разработки эскизного проекта используются проектные решения ко всей

системе или ее части и определяется перечень задач системы, концепция

информационной базы, функции и параметры основных программных компонентов

системы, а также основные алгоритмы обработки информации.

Этап разработки технического проекта предусматривает разработку проектных

решений относительно системы и ее частей, разработку документации на АС и

комплектацию АС, а также определение технических требований на систему и

проектирование задач для смежных частей проекта.

Проектные решения определяют организационную структуру, функции персонала АС,

структуру технических средств, языка программирования, СУБД, общие

характеристики ПО, систему классификации и кодирования, а также варианты ведения

информационной базы системы.

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

– концептуальное проектирование, которое состоит в уточнении и согласовании

деталей требований;

– архитектурное проектирование, которое состоит в определении главных

структурных особенностей создаваемой системы;

– техническое проектирование, которое состоит в отображении требований на cреду

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

– детальное проектирование, которое состоит в определении алгоритмов задач,

построения БД и программного обеспечения системы.

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

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

достоверность;

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

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

– интерфейсы с потенциальными пользователями системы на ранних стадиях ЖЦ

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

функций системы;

– правила взаимодействия пользователя и системы с точки зрения понимания,

эффективности и

скорости реакции системы.

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

определение которых предшествует проектированию конкретных экранов и форматов

обмена данными, в частности:

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

понятными и распространенные в домене;

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

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

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

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

системы.

При архитектурном проектировании системы принимаются во внимание конкретные

интерфейсы, учитывающие такие аспекты, как традиции, обычаи, особенности домена

и присущие ему действующие лица. В частности, пользователю определенный

психологический комфорт предоставляют языковых форматы в меню и иконах

интерфейсов, а также метрические показатели систем измерений и др.

При желании сделать будущую систему "поликультурной", то есть способной

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

культурной среде элементы, которые предполагают замену стандартных икон, введения

новых текстов и др. Количество выдаваемых знаков в текстах определяется

лаконизмом избранного языка общения (английский наиболее лаконичней). Длина

текстовых сообщений и окон ввода текстов должна определяться как параметр

настройки будущей системы.

Правила навигации должны учитывать традиции чтения слева - направо или наоборот.

Таким образом, общей рекомендацией концепций проектирования является построение

полностью всех экранных форм системы и "проигрывание" с пользователем для выбора

разных вариантов, отвечающих его вкусам. Такой выбор часто входит в в

противоречие с заданными характеристиками интерфейса (например, удобство доступа

и обеспечение конфиденциальности, быстродействие и сложность обработки и др.).

Для построения интерфейсов существует широкий выбор методов и средств.

Большинство из них базируется на фиксации определенных классов объектов

интерфейса (выбор из меню, заполнение экранных форм и др.) и средствах

монтирования их в программную систему в виде интегрированных блоков или

автономных подсистем интерфейса с пользователем.

При техническом проектировании системы на основе модели представления

требований и понятий объектно–ориентированного подхода проводится уточнение

состава и содержания функций, присущих им операций (методов), а также схем

взаимодействия объектов.

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

помощью диаграмм потоков данных (см. тема 3.).

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

которые они выполняют соответствующие операции и изменяют свое состояние, или

посылают сообщения другим объектам.

Для уточнения поведения объектов можно использовать ряд диаграмм,

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

в состав метода UML.

Все уточнения, которые делаются относительно данных, интерфейсов и поведения

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

требований и даже состава объектов. Изменения надо начинать с продуктов этапа

инженерии требований, а именно модели анализа требований и др. Трудозатраты на

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

применении метода трассирования требований.

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

структурой организации системы или среды использования. К отдельным

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

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

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

роль и место в прикладных приложениях системы. Для них разработано немало

национальных, корпоративных и ведомственных стандартов, которые фиксируют

правила обеспечения защиты данных, безопасности системы и др.

Результатом формирования нефункциональных требований может быть расширение

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

выполняющими требования взаимодействия, безопасности, защиты данных и др.

4.2.2. Общесистемный подход к проектированию архитектуры системы

Одним из путей архитектурного проектирования является определение структуры

создаваемой системы, состав компонентов, способов их представления и объединения.

Фактически строится архитектура, которая состоит из четырех уровней, для каждого из

которых определен набор компонентов, выполняюших определенную прикладную

или общесистемную функции в системе (рис.4.4.).

Прикладные программные системы

Специфические для бизнеса компоненты

Общесистемные компоненты

Интерфейс с универсальными системами

программной инженерии

Системные компоненты

Интерфейс с оборудованием

Рис.4.4. Поуровневая архитектура системы

Первый уровень – системные компоненты. Они осуществляют взаимодействие с

периферийными устройствами оснащения компьютеров (принтеры, клавиатура,

сканеры, манипуляторы и и т.п.), используются при построении операционных систем

и не попадают в поле зрения разработчиков приложений.

Ко второму уровню относятся общесистемные компоненты. Они обеспечивают

взаимодействие с универсальными сервисными

системами, такими, как операционные

системы, системы баз данных и знаний, системы управления сетями и т.п. Компоненты

данного слоя используются во многих приложениях как их составляющие.

К третьему уровню относятся специфические компоненты определенной

проблемной области. Они являются составляющими программных систем,

предназначенных для решения ее задач (бизнес-задач). Их еще называют семейством

программных систем.

И, наконец, к четвертому слою относятся прикладные программные системы,

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

информации (офисные системы, системы бухгалтерского учета и др.) Они могут

использовать компоненты упомянутых нижних уровней.

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

уровне или на более верхнем. Для каждого уровня определен соответствующий набор

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

использования его компонент, Этот набор определяет соответствующее разделение

профессионалов в программной инженерии (системщики, прикладники, программисты

и др.).

На уровне архитектурного проектирования система рассматривается как композиция

компонент третьего уровня, имеющая доступ до компонентов первого и второго

уровней.

Т.е. архитектурное проектирование – это разработка компонентов третьего уровня,

определение входных и выходных данных, слоев иерархии компонентов и их связей.

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

системы, являются распределенная, клиент-сервер и многоуровневая.

Распределенная схема обеспечивает взаимодействие компонентов системы,

расположенных на разных компьютерах через стандартные интерфейсы и механизмы

вызова, выполняемые промежуточными средами (COM/DCOM, CORBA, OLE, Java и

др.): RPC (Remote Procedure Calls), RMI (Remote Method Invocation), tuple spaces,

aplets и др.

В трехуровневой архитектурной схеме типа клиент/сервер сервер или брокеры

объектных запросов (ORB) предоставляют общесистемный сервис и различные

ресурсы, а также управляют распределенными объектами (компонентами).

Архитектура такой системы может быть многоуровневой, если объекты

предоставляют услуги и сами пользуются услугами других объектов, расположенных

на разных уровнях этой схемы. Данная архитектурная схема отображает объектный

стиль проектирования ПО, стиль моделирования проблемы с помощью UML и

унифицированного процесса RUP [13, 14].

Объектный стиль проектирования ПО заключается в представлении объектной модели,

абстрагировании ее сущностей объектами и в иерархической организации объектов с

инкапсуляцией отдельных их возможностей.

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

подсистемы (пакеты), каждая из которых отвечает проектным решениям и

функциональным (и нефункциональным) требованиям и построении модели

предметной области. Определяются носители интересов (акторов) и возможных

прецедентов - последовательности действий акторов для получения результатов. В

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

возможности и представление требований. Разрабатываются варианты использования,

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

определяются их структурные особенности – атрибуты и ассоциации, представляемые в

диаграммах классов. Поведенческие аспекты системы отражаются диаграммами

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

во времени, правила перехода от состояния к состоянию (диаграммы состояний) и к

действию (диаграммы действий). Особенности кооперативного поведения объектов

отражаются диаграммами кооперации.

Объекты проблемы и соответствующие им диаграммы использования задают общую

архитектурную схему проблемы, в рамках которой осуществляется описание ее

структуры и специфики поведения компонентов, для понимания того, как построена

архитектура системы.

Стиль проектирования архитектуры в рамках унифицированного процесса RUP

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

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

способных охватить систему, определить ее структуру и поведение в нотации UML.

В зависимости от модели проектирования ПО (каскадная, спиральная, иерархическая и

др.) созданная на начальном этапе архитектура ПО может расширяться и уточняться

итеративно (например, при изменении требований заказчиком) на последующих этапах,

что способствует получению полной и

надежной архитектуры.

Результат проектирования – архитектура, т.е ее каркас и архитектурная

инфраструктура, содержащая набор компонентов, из которых можно формировать

некоторый конкретный вид архитектурной схемы для конкретной среды выполнения

системы. Заканчивается проектирование описанием архитектуры ПО, в котором

отображены зафиксированные проектные решения, принятые в ходе работы

архитекторов системы, в том числе описание логической

и физической структуры и

данных, а также способов взаимодействия ее объектов.

В состав архитектура системы входят статические и динамические объекты, их связи

и интерфейс между компонентами других архитектурных уровней. В ней

представлены результаты анализа, декомпозиции системы на отдельные подсистемы и

компоненты, а также набор справочников, словарей и т.д. Описание архитектуры

имеет множество представлений, отражающих отдельные аспекты реализации

системы. Каждое представление детализирует проблему и отдельные ее части, а также

их связи и интерфейсы

Современные программные системы являются довольно сложными композициями

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

готовые программные продукты, которые могут быть включены в любые программные

системы

для выполнения соответствующих им функций. При этом примитивные

функции могут составлять композиции, которые выполняют определенные

обобщенные функции. Они могут связываться в новые композиции и т.п. Для того,

чтобы совокупность современных готовых к использованию средств можно было

обозреть, введена определенная послойная их структуризация, суть которой состоит в

следующем

На этапе

инженерии требований создается совокупность объектов, которые

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

этом сценарии.

В сложных программных системах количество выделенных объектов может

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

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

дополнительный анализ для их отождествления.

Основными рекомендациями для декомпозиции сложной системы на компоненты или

модули являются:

100

– четкое определение цели и возможность проверки их выполнимости;

– обязательное определение входные и выходные данных;

– задание иерархии, каждый уровень которой отвечает уровню абстракции системы и

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

Такая пошаговая детализация принятия решений не только сводит решение сложной

задачи к нескольким более простым, но и сосредоточиться на решении общих задач

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

инструментальных средств, влияющих на эффективное их функционирование. При

этом интерфейсы между компонентами должны быть согласованными для интеграции

их в единую структуру.

Полученные совокупности объектов объединяются в подсистемы с учетом таких

требований:

1) каждая создаваемая подсистема должна ассоциироваться с определенными

элементами продукта инженерии требований (как, например, актер, сценарий, объект и

т.п.);

2) необязательные функции или часто изменяемые функции выделятся в подсистемы

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

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

3) интерфейс подсистемы понятен и имеет взаимосвязи с другими подсистемами.

Каждая подсистема должна выполнять минимум услуг или функций и иметь

фиксированное множество параметров интерфейса.

После отделения изменяемых и производных подсистемы проводится анализ связей и

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

внутренними связями и прозрачными внешними интерфейсами.

К способам объединения объектов в подсистему можно отнести:

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

– логическое объединение объектов в подсистему, которые являются функционально

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

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

как ввод данных для дисков и порта сети);

– объединение по времени, т.е. сборка объектов в подсистему, которые

активизируются в общий промежуток времени;

– коммуникативное объединение, т.е. собираются объекты, которые имеют общий

источник данных;

– процедурное объединение, т.е. в подсистему собираются объекты, которые

последовательно передают друг другу управление;

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

выполняет часть работ для выполнения общей функции, которую выполняет

подсистема.

Анализ приведенных выше способов объединения объектов в подсистемы с точки

зрения стойкости к изменениям, показывает, что каждое изменение требует

соответствующей корректировки минимального количества архитектурных компонент.

Отсюда можно сделать вывод, что все способы не отличаются легкостью модификации