22730

Основи програмної інженерії, курс лекцій

Конспект

Информатика, кибернетика и программирование

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

Украинкский

2014-12-19

7.17 MB

13 чел.

МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ

НАЦІОНАЛЬНИЙ УНІВЕРСИТЕТ КОРАБЛЕБУДУВАННЯ

   імені адмірала Макарова

ХЕРСОНСЬКА  ФІЛІЯ

Кафедра інформаційних технологій

                                                                                                 

                                                                                  С.О. КАРПОВА

       

КОНСПЕКТ ЛЕКЦІЙ

з курсу

Основи програмної інженерії

 

Херсон  2014

МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ

НАЦІОНАЛЬНИЙ УНІВЕРСИТЕТ КОРАБЛЕБУДУВАННЯ

   імені адмірала Макарова

ХЕРСОНСЬКА  ФІЛІЯ

Кафедра інформаційних технологій

                                                                                                 

                                                                                  С.О. КАРПОВА

       

КОНСПЕКТ ЛЕКЦІЙ

з курсу

Основи програмної інженерії

Рекомендовано Методичною радою ХФ НУК

ББК 32.973

  Х 82

УДК 681.3

Карпова С.О. Конспект лекцій з курсу  “Основи програмної інженерії”. Херсон: ХФ НУК, 2014.- 285 с

Кафедра інформаційних технологій

Конспект лекцій призначений для студентів І курсу напряму підготовки 6.050103 “Програмна інженерія”, спеціальності 05010301 “Програмне забезпечення  систем” Херсонської філії НУК, а також може бути корисний для студентів усіх інших спеціальностей, що вивчають основи програмування та базові концепції програмної інженерії. Конспект може бути використаний як посібник при самостійному вивченні програмної інженерії.

Рецензенти:  к.т.н., доцент В.Ф.Тимошенко

            

                                   

                                                    С         С.О.Карпова

                       С     Національний університет  кораблебудування

                                           Херсонська філія, 2014

Содержание

[0.1] Предисловие

[1] Часть I. Инженерные основы программного обеспечения

[1.1] 1. Введение в программную инженерию

[1.1.1] 1.1. Вопросы и ответы об инженерии программного обеспечения

[1.1.2] 1.2. Профессиональные и этические требования к специалистам по программному обеспечению

[1.2] 2. Системотехника вычислительных систем

[1.2.1] 2.1. Интеграционные свойства систем

[1.2.2] 2.2. Система и ее окружение

[1.2.3] 2.3. Моделирование систем

[1.2.4] 2.4. Процесс создания систем

[1.2.5] 2.5. Приобретение систем

[1.3] 3. Процесс создания программного обеспечения

[1.3.1] 3.1. Модели процесса создания программного обеспечения

[1.3.2] 3.2. Итерационные модели разработки программного обеспечения

[1.3.3] 3.3. Спецификация программного обеспечения

[1.3.4] 3.4. Проектирование и реализация программного обеспечения

[1.3.5] 3.5. Эволюция программных систем

[1.3.6] 3.6. Автоматизированные средства разработки программного обеспечения

[1.4] 4. Технологии производства программного обеспечения

[2] Часть II. Требования к программному обеспечению

[2.1] 5. Требования к программному обеспечению

[2.1.1] 5.1. Функциональные и нефункциональные требования

[2.1.2] 5.2. Пользовательские требования

[2.1.3] 5.3. Системные требования

[2.1.4] 5.4. Документирование системных требований

[2.2] 6. Разработка требований

[2.2.1] 6.1. Анализ осуществимости

[2.2.2] 6.2. Формирование и анализ требований

[2.2.3] 6.3. Аттестация требований

[2.2.4] 6.4. Управление требованиям

[2.3] 7.  Матрица требований. Разработка матрицы требований

[3] Часть III. Моделирование программного обеспечения

[3.1] 8. Архитектурное проектирование

[3.1.1] 8.1. Структурирование системы

[3.1.2] 8.2. Модели управления

[3.1.3] 8.3. Модульная декомпозиция

[3.1.4] 8.4. Проблемно-зависимые архитектуры

[3.2] 9. Архитектура распределенных систем

[3.2.1] 9.1. Многопроцессорная архитектура

[3.2.2] 9.2. Архитектура клиент/сервер

[3.2.3] 9.3. Архитектура распределенных объектов

[3.2.4] 9.4. CORBA

[3.3] 10. Объектно-ориентированное проектирование

[3.3.1] 10.1. Объекты и классы объектов

[3.3.2] 10.2. Процесс объектно-ориентированного проектирования

[3.3.2.1] 10.2.1. Окружение системы и модели ее использования

[3.3.2.2] 10.2.2. Проектирование архитектуры

[3.3.2.3] 10.2.3. Определение объектов

[3.3.2.4] 10.2.4. Модели архитектуры

[3.3.2.5] 10.2.5. Специфицирование интерфейсов объектов

[3.3.3] 10.3. Модификация системной архитектуры

[3.4] 11. Проектирование систем реального времени

[3.4.1] 11.1. Проектирование систем реального времени

[3.4.2] 11.2. Управляющие программы

[3.4.3] 11.3. Системы наблюдения и управления

[3.4.4] 11.4. Системы сбора данных

[3.5] 12. Проектирование с повторным использованием компонентов

[3.5.1] 12.1. Покомпонентная разработка

[3.5.2] 12.2. Семейства приложений

[3.5.3] 12.3. Проектные паттерны

[3.6] 13. Проектирование интерфейса пользователя

[3.6.1] 13.1. Принципы проектирования интерфейсов пользователя

[3.6.2] 13.2. Взаимодействие с пользователем

[3.6.3] 13.3. Представление информации

[3.6.4] 13.4. Средства поддержки пользователя

[3.6.5] 13.5. Оценивание интерфейса

[4] Часть IV. Технологии разработки программного обеспечения

[4.1] 14. Жизненный цикл программного обеспечения: модели и их особенности

[4.1.1] 14.1. Каскадная модель жизненного цикла

[4.1.2] 14.2. Эволюционная модель жизненного цикла

[4.1.2.1] 14.2.1. Формальная разработка систем

[4.1.2.2] 14.2.2. Разработка программного обеспечения на основе

[4.1.2.3] ранее созданных компонентов

[4.1.3] 14.3. Итерационные модели жизненного цикла

[4.1.3.1] 14.3.1 Модель пошаговой разработки

[4.1.3.2] 14.3.2 Спиральная модель разработки

[4.2] 15. Методологические основы технологий разработки

[4.3] программного обеспечения  

[4.4] 16. Методы структурного анализа и проектирования

[4.5] программного обеспечения  

[4.6] 17. Методы объектно-ориентированного анализа и

[4.7] проектирования программного обеспечения. Язык моделирования UML  

[5] Часть V. Письменная коммуникация. Документирование проекта Программного обеспечения  

[5.1] 18. Документирование этапов разработки

[5.2] программного обеспечения  

[5.3] 19. Планирование проекта   

[5.3.1] 19.1 Уточнение содержания и состава работ

[5.3.2] 19.2 Планирование управления содержанием

[5.3.3] 19.3 Планирование организационной структуры

[5.3.4] 19.4 Планирование управления конфигурациями

[5.3.5] 19.5 Планирование управления качеством

[5.3.6] 19.6 Базовое расписание проекта

[5.4] 20. Верификация и аттестация программного обеспечения

[5.4.1] 20.1. Планирование верификации и аттестации

[5.4.2] 20.2. Инспектирование программных систем

[5.4.3] 20.3. Автоматический статический анализ программ

[5.4.4] 20.4. Метод "чистая комната"

[5.5] 21. Тестирование программного обеспечения  

[5.5.1] 21.1. Тестирование дефектов

[5.5.1.1] 21.1.1. Тестирование методом черного ящика

[5.5.1.2] 21.1.2. Области эквивалентности

[5.5.1.3] 21.1.3. Структурное тестирование

[5.5.1.4] 21.1.4. Тестирование ветвей

[5.5.2] 21.2. Тестирование сборки

[5.5.2.1] 21.2.1. Нисходящее и восходящее тестирование

[5.5.2.2] 21.2.2. Тестирование интерфейсов

[5.5.2.3] 21.2.3. Тестирование с нагрузкой

[5.5.3] 21.3. Тестирование объектно-ориентированных систем

[5.5.3.1] 21.3.1. Тестирование классов объектов

[5.5.3.2] 21.3.2. Интеграция объектов

[5.5.4] 21.4. Инструментальные средства тестирования

[6] Часть VI. Управление проектом программного обеспечения

[6.1] 22. Управление проектами  

[6.1.1] 22.1. Процессы управления

[6.1.2] 22.2. Планирование проекта

[6.1.3] 22.3. График работ

[6.1.4] 22.4. Управление рисками

[6.2] 23. Управление персоналом

[6.2.1] 23.1. Пределы мышления

[6.2.1.1] 23.1.1. Организация человеческой памяти

[6.2.1.2] 23.1.2. Решение задач

[6.2.1.3] 23.1.3. Мотивация

[6.2.2] 23.2. Групповая работа

[6.2.2.1] 23.2.1. Создание команды

[6.2.2.2] 23.2.2. Сплоченность команды

[6.2.2.3] 23.2.3. Общение в группе

[6.2.2.4] 23.2.4. Организация группы

[6.2.3] 23.3. Подбор и сохранение персонала

[6.2.3.1] 23.3.1. Рабочая среда

[6.2.4] 23.4. Модель оценки уровня развития персонала

[6.3] 24. Оценка стоимости программного продукта

[6.3.1] 24.1. Производительность

[6.3.2] 24.2. Методы оценивания

[6.3.3] 24.3. Алгоритмическое моделирование стоимости

[6.3.3.1] 24.3.1. Модель СОСОМО

[6.3.3.2] 24.3.2. Алгоритмические модели стоимости в планировании проекта

[6.3.4] 24.4. Продолжительность проекта и наем персонала

[6.4] 25. Управление качеством

[6.4.1] 25.1. Обеспечение качества и стандарты

[6.4.1.1] 25.1.1. Стандарты на техническую документацию

[6.4.1.2] 25.1.2. Качество процесса создания программного обеспечения

[6.4.1.3] и качество программного продукта

[6.4.2] 25.2. Планирование качества

[6.4.3] 25.3. Контроль качества

[6.4.3.1] 25.3.1. Проверки качества

[6.4.4] 25.4. Измерение показателей программного обеспечения

[6.4.4.1] 25.4.1. Процесс измерения

[6.4.4.2] 25.4.2. Показатели программного продукта

[6.5] 26. Надежность программного обеспечения

[6.5.1] 26.1. Обеспечение надежности программного обеспечения

[6.5.1.1] 26.1.1 Критические системы

[6.5.1.2] 26.1.2. Работоспособность и безотказность

[6.5.1.3] 26.1.3. Безопасность

[6.5.1.4] 26.1.4. Защищенность

[6.5.2] 26.2. Аттестация безотказности

[6.5.3] 26.3. Гарантии безопасности

[6.5.4] 26.4. Оценивание защищенности программного обеспечения

[6.6] 27. Совершенствование производства программного обеспечения

[6.6.1] 27.1. Качество продукта и производства

[6.6.2] 27.2. Анализ и моделирование производства

[6.6.2.1] 27.2.1. Исключения в процессе создания ПО

[6.6.3] 27.3. Измерение производственного процесса

[6.6.4] 27.4. Модель оценки уровня развития

[6.6.4.1] 27.4.1. Оценивание уровня развития

[6.6.5] 27.5. Классификация процессов совершенствования

Предисловие

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

Даже простые системы ПО обладают высокой степенью сложности, поэтому при их разработке приходится использовать весь арсенал технических и инженерных методов. Таким образом, инженерия программного обеспечения – это инженерная дисциплина, где разработчики ПО используют теорию и методы компьютерных наук для успешного решения различных нетривиальных задач (но, конечно, не каждый проект ПО в силу различных причин успешно завершается). Большинство современных программ предлагают пользователям большие сервисные возможности для работы с ними – нельзя не заметить реального прогресса в развитии технологии создания ПО за последние 30 лет.

Инженерия программного обеспечения развивается в основном в соответствии с постановкой новых задач построения больших пользовательских систем ПО для промышленности, правительства и оборонного ведомства. С другой стороны, в настоящее время сфера программного обеспечения чрезвычайно широка: от игр на специализированных игровых консолях, а также программных продуктов для персональных компьютеров и Web-ориентированных программных систем до очень больших масштабируемых распределенных систем. Хотя некоторые технологии, применяемые для построения пользовательских программных систем, универсальны (например, объектно-ориентированные методы), новые технологии создания программного обеспечения развиваются с учетом различных типов ПО. Невозможно охватить в одном конспекте все технологии создания ПО, поэтому сконцентрируем основное внимание не на методах разработки отдельных программных продуктов, а на универсальных технологиях и методах проектирования и построения больших масштабируемых программных систем.

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

Часть I. Инженерные основы программного обеспечения

1. Введение в программную инженерию

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

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

Инженерия программного обеспечения – сравнительно молодая научная дисциплина. Термин software engineering был впервые предложен в 1968 году на конференции, посвященной так называемому кризису программного обеспечения. Этот кризис был вызван появлением мощной (по меркам того времени) вычислительной техники третьего поколения. Новая техника позволяла воплотить в жизнь не реализуемые ранее программные приложения. В результате программное обеспечение достигло размеров и уровня сложности, намного превышающих аналогичные показатели у программных систем, реализованных на вычислительной технике предыдущих поколений.

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

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

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

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

Специалисты по программному обеспечению могут гордиться такими достижениями. Без современного сложного ПО было бы невозможно освоение космического пространства, не существовало бы Internet и современных телекоммуникаций, а все транспортные средства и виды транспортировки были бы более опасными и дорогостоящими. Инженерия программного обеспечения достигла многого за свою пока еще короткую жизнь, и ее значение как зрелой научной дисциплины еще более возрастет в XXI столетии.

1.1. Вопросы и ответы об инженерии программного обеспечения

Этот раздел построен в виде ответов на некоторые основные вопросы, касающиеся инженерии программного обеспечения. В данном разделе используется формат "списка FAQ" (Frequently Asked Questions – часто задаваемые вопросы). Такой формат обычно применяется в группах новостей Internet, предлагая новичкам ответы на часто задаваемые вопросы. Надеюсь, что подобный подход будет эффективен в качестве краткого введения в предмет инженерии программного обеспечения.

Вопросы и ответы, подробно рассматриваемые в этом разделе, компактно представлены в табл. 1.1.

Таблица 1.1. Часто задаваемые вопросы об инженерии программного обеспечения

Вопрос

Ответ

Что такое программное обеспечение (ПО)?

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

Что такое инженерия программного обеспечения?

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

В чем различие между инженерией программного обеспечения и компьютерной наукой?

Компьютерная наука – это теоретическая дисциплина, охватывающая все стороны вычислительных систем, включая аппаратные средства и программное обеспечение; инженерия программного обеспечения – практическая дисциплина создания и сопровождения программных систем

В чем различие между инженерией программного обеспечения и системотехникой?

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

Что такое технологический процесс создания ПО?

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

Что такое модель технологического процесса создания ПО?

Формализованное упрощенное представление технологического процесса создания ПО

Какова структура затрат на создание ПО?

Примерно 60% от общих затрат на создание ПО занимают затраты непосредственно на разработку ПО и 40% – на его тестирование и отладку. Для программных продуктов, разрабатываемых по заказу, стоимость тестирования и отладки часто превышает стоимость разработки продукта

Что такое методы инженерии программного обеспечения?

Это структурные решения, предназначенные для разработки ПО и включающие системные модели, формализованные нотацию и правила проектирования, а также способы управления процессом создания ПО

Что такое CASE (Computer-Aided Software Engineering – автоматизированное проектирование и создание ПО)?

Это программные системы, предназначенные для автоматизации процесса создания ПО. CASE-средства часто используются в качестве основы методов инженерии программного обеспечения

Каковы признаки качественного ПО?

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

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

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

1.2. Профессиональные и этические требования к специалистам по программному обеспечению

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

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

1.  Конфиденциальность. Специалист должен соблюдать конфиденциальность, т.е. не разглашать никаких сведений о работодателе и клиентах, независимо от того, подписывал он или нет какое-либо соглашение о соблюдении конфиденциальности.

2.  Компетентность. Специалист не должен скрывать (или ложно представлять) свой уровень компетенции и не должен браться за работу, которая этому уровню не соответствует.

3.  Защита прав интеллектуальной собственности. Специалист не должен нарушать соответствующее законодательство о защите авторских прав при использовании чужой интеллектуальной собственности (патентов и т.п.). Он также должен защищать интеллектуальную собственность работодателя и клиентов.

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

В разработке подобных этических обязательств большая роль принадлежит профессиональным обществам и институтам. Такие организации, как ACM (Association for Computing Machinery– Ассоциация по вычислительной технике), IEEE (Institute of Electrical and Electronics Engineers – Институт инженеров по электротехнике и электронике) и British Computer Society (Британское компьютерное общество), опубликовали кодекс профессионального поведения, или этический кодекс. Члены этих организаций принимают на себя обязательство следовать данному кодексу. Правила поведения из этого кодекса основаны на общечеловеческих этических нормах.

2. Системотехника вычислительных систем

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

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

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

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

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

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

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

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

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

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

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

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

2.1. Интеграционные свойства систем

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

Существует два типа интеграционных свойств.

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

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

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

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

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

2.  Безотказность программного обеспечения. Это показатель работы компонента ПО без сбоев и ошибок. Программные ошибки обычно не оказывают влияния на аппаратные средства системы. Поэтому система может продолжать функционировать даже тогда, когда ПО выдает некорректные результаты.

3.  Ошибки операторов. Операторы, эксплуатирующие систему, также могут допускать ошибки в своей деятельности.

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

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

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

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

2.2. Система и ее окружение

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

На рис. 2.1 показано несколько систем, объединенных в систему жизнеобеспечения офисного здания. Система отопления, электроэнергетическая система, система освещения, системы водоснабжения и канализации и система безопасности являются подсистемами строения, которое, в свою очередь, также можно рассматривать как систему. Здание расположено на улице, которая также является системой более высокого уровня. Улица будет подсистемой системы города и т.д. Таким образом, окружение какой-либо системы само является системой более высокого уровня. В общем случае окружение какой-либо системы – это композиция ее локального окружения и окружения системы более высокого уровня.

Рис. 2.1. Иерархия систем

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

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

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

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

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

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

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

2.  Фактор персонала. Может ли внедрение системы привести к снижению требований к квалификации персонала или коренным образом изменить способы его работы? Если это так, тогда персонал может попытаться противостоять внедрению системы в их организацию. Менеджеры среднего звена, руководящие проектами, часто подозревают, что их статус в организации понизится после внедрения компьютерных систем.

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

Эти человеческие, социальные и организационные факторы часто оказываются критическими при принятии решения о том, будет или нет внедряться система. К сожалению, предусмотреть эти факторы очень сложно, особенно если разработчики системы не обладают достаточным социальным и культурным опытом. Чтобы помочь предусмотреть различные эффекты от внедрения систем в организацию, разработаны специальные методологии, такие как социотехника Мамфорда (Mumford), методология программных систем Чекланда (Checkland).

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

2.3. Моделирование систем

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

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

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

2.4. Процесс создания систем

Этапы процесса создания системы показаны на рис. 2.4. Эти этапы оказывают большое влияние на процесс разработки программного обеспечения в соответствии с каскадной моделью.

Рис. 2.4. Процесс создания системы

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

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

2.  Небольшой масштаб повторных работ при разработке систем. После принятия решений в процессе разработки систем (например, об установке определенных типов радиолокаторов в системе управления полетами) внесение изменений в систему может оказаться весьма дорогостоящим. Перепроектирование системы часто просто невозможно. Это одна из причин широкого использования ПО при создании самых разнообразных систем – программные компоненты делают системы более гибкими и позволяют внести изменения в разрабатываемую систему в ответ на новые требования, предъявляемые к ней.

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

2.5. Приобретение систем

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

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

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

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

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

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

На рис. 2.7 показаны этапы процесса приобретения как готовых систем, так и разрабатываемых по заказу. Перечислим некоторые важные моменты процесса приобретения.

1.  Приобретаемые компоненты, как правило, не удовлетворяют в точности всем системным требованиям, вследствие чего необходима подгонка требований в соответствии с этими компонентами. Более того, обычно стоит нелегкая дилемма выбора между системными требованиями и свойствами приобретенной системы. Чаще всего "в жертву" приносятся системные требования. Это, в свою очередь, оказывает влияние на другие подсистемы.

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

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

Рис. 2.7. Процесс приобретения системы

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

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

3. Процесс создания программного обеспечения

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

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

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

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

1.  Разработка спецификации ПО. Это фундамент любой программной системы. Спецификация определяет все функции и действия, которые будет выполнять разрабатываемая система.

2.  Проектирование и реализация (производство) ПО. Это процесс непосредственного создания ПО на основе спецификации.

3.  Аттестация ПО. Разработанное программное обеспечение должно быть аттестовано на соответствие требованиям заказчика.

4.  Эволюция ПО. Любые программные системы должны модифицироваться в соответствии с изменениями требований заказчика.

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

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

3.1. Модели процесса создания программного обеспечения

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

Эти обобщенные модели не содержат точного описания всех стадий процесса создания ПО. Напротив, они являются полезными абстракциями, помогающими "приложить" различные подходы и технологии к процессу разработки. Кроме того, очевидно, что процесс создания больших систем не является единым, а состоит из множества различных процессов, ведущих к созданию отдельных частей большой системы. Модели создания программного обеспечения.

1.  Каскадная модель. Основные базовые виды деятельности, выполняемые в процессе создания ПО (такие, как разработка спецификации, проектирование и производство, аттестация и модернизация ПО), представляются как отдельные этапы этого процесса.

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

3.  Модель формальной разработки систем. Основана на разработке формальной математической спецификации программной системы и преобразовании этой спецификации посредством специальных математических методов в исполняемые программы. Проверка соответствия спецификации и системных компонентов также выполняется математическими методами.

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

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

3.2. Итерационные модели разработки программного обеспечения 

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

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

1.  Модель пошаговой разработки, где процессы специфицирования требований, проектирования и написания кода разбиваются на последовательность небольших шагов, которые ведут к созданию ПО.

2.  Спиральная модель разработки, в которой весь процесс создания ПО, от начального эскиза системы до ее конечной реализации, разворачивается по спирали.

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

3.3. Спецификация программного обеспечения

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

Схема процесса разработки требований показана на рис. 3.8. Результатом его выполнения является разработка документации, формализующей требования, предъявляемые к системе, т.е. создание системной спецификации. В этой документации требования обычно представлены на двух уровнях детализации. На самом верхнем уровне представлены требования, определяемые конечными пользователями или заказчиками ПО; но для разработчиков необходима более детализированная системная спецификация.

Рис. 3.8. Процесс разработки требований

Процесс разработки требований включает четыре основных этапа.

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

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

3.  Специфицирование требований. Осуществляется перевод всей совокупности информации, собранной на предыдущем этапе, в документ, определяющий множество требований. Этот документ обычно содержит два типа требований: пользовательские – обобщенные представления заказчиков и конечных пользователей о системе; системные – детальное описание функциональных показателей системы.

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

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

3.4. Проектирование и реализация программного обеспечения

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

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

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

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

Ниже перечислены отдельные этапы процесса проектирования.

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

2.  Обобщенная спецификация. Для каждой подсистемы разрабатывается обобщенная спецификация на ее сервисы и ограничения.

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

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

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

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

Рис. 3.9. Обобщенная схема процесса проектирования

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

3.5. Эволюция программных систем

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

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

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

Рис. 3.13. Эволюция систем

3.6. Автоматизированные средства разработки программного обеспечения 

Аббревиатура CASE (Computer-aided Software Engineering – автоматизированная разработка ПО) обозначает специальный тип программного обеспечения, предназначенного для поддержки таких процессов создания ПО, как разработка требований, проектирование, кодирование и тестирование программ. Поэтому к CASE-средствам относятся редакторы проектов, словари данных, компиляторы, отладчики, средства построения систем и т.п.

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

Приведем примеры тех процессов, которые можно автоматизировать с помощью CASE-средств.

1.  Разработка графических моделей системы на этапах создания спецификации и проектирования.

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

3.  Генерирование пользовательских интерфейсов на основе графического описания интерфейса, создаваемого в диалоговом режиме.

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

5.  Автоматическая трансляция программ, написанных на устаревших языках программирования (например, COBOL), в программы, написанные на современных языках.

В настоящее время подходящие CASE-технологии существуют для большинства процессов, выполняемых в ходе разработки ПО. Это ведет к определенному улучшению качества создаваемых программ и повышению производительности труда разработчиков программного обеспечения. Вместе с тем эти достижения значительно уступают тем ожиданиям, которые присутствовали при зарождении CASE-технологии. Тогда считалось, что стоит только внедрить CASE-средства – и можно получить весьма значительное повышение и качества программ, и производительности труда. Фактически это повышение составляет примерно 40% . Хотя и это повышение весьма значительно, CASE-технологии не совершили революции в инженерии программного обеспечения, как ожидалось.

Расширение применения CASE-технологии ограничивают два фактора.

1.  Создание ПО, особенно этап проектирования, во многом является творческим процессом. Существующие CASE-средства автоматизируют рутинные процессы, попытки привлечь их к решению интеллектуальных и творческих задач проектирования особым успехом не увенчались.

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

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

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

4. Технологии производства программного обеспечения

Технологии (с греческого: ремесло + наука) - совокупность знаний о способах и средствах проведении производственных процессов.

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

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

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

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

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

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

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

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

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

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

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

- Вести постоянный контроль и обеспечение качества программ.

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

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

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

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

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

- Работа пользователя должна обеспечиваться развитой информационно-справочной системой.

- Средства автоматизации технологии должны охватывать все этапы работы коллектива программистов.

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

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

Часть II. Требования к программному обеспечению 

5. Требования к программному обеспечению

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

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

Некоторые проблемы, возникающие в процессе разработки требований, порождены отсутствием четкого понимания различия между этими разными уровнями требований. Чтобы различить требования разных уровней, здесь используются термины пользовательские требования (user requirements) для обозначения высокоуровневых обобщенных требований и системные требования (system requirements) для детализированного описания выполняемых системой функций. Кроме требований этих двух уровней, применяется еще более детализированное описание системы – проектная системная спецификация (software design specification), которая может служить мостом между этапом разработки требований и этапом проектирования системы. Три перечисленных вида требований можно определить следующим образом.

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

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

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

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

5.1. Функциональные и нефункциональные требования

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

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

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

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

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

5.2. Пользовательские требования

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

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

1.  Отсутствие четкости изложения. Иногда нелегко изложить какую-либо мысль естественным языком четко и недвусмысленно, не сделав при этом текст многословным и трудночитаемым.

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

3.  Объединение требований. Несколько различных требований к системе могут описываться как единое пользовательское требование.

5.3. Системные требования

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

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

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

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

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

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

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

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

5.4. Документирование системных требований

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

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

•  Описывать только внешнее поведение системы.

•  Указывать ограничения, накладываемые на процесс реализации cистемы.

•  Предусматривать возможность внесения изменений в спецификацию.

•  Служить справочным средством в процессе сопровождения системы.

•  Отображать весь жизненный цикл системы.

•  Предусматривать реакцию системы и группы сопровождения на непредвиденные (нештатные) ситуации.

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

Многие организации, такие, как Министерство обороны США и Институт инженеров по электротехнике и радиоэлектронике IEEE, разработали собственные стандарты документирования спецификаций. В монографии описаны некоторые из этих стандартов, а также проведено их сравнение. Наиболее известный стандарт разработан IEEE и называется IEEE/ANSI 830-1993 .

1. Введение

1.1. Цели документа

1.2. Назначение программного продукта

1.3. Определения, акронимы и аббревиатуры

1.4. Список литературы и других источников

1.5. Обзор спецификации

2. Общее описание

2.1. Описание программного продукта

2.2. Функции программного продукта

2.3. Пользовательские характеристики

2.4. Общие ограничения

2.5. Обоснования, предположения и допущения

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

4. Приложения

5. Указатели

Хотя стандарт IEEE не идеален, он может служить отправной точкой при написании спецификации. Конечно, при ее написании необходимо также учитывать стандарты, принятые в организации - разработчике ПО. В табл. 5.4 описаны возможные разделы спецификации, построенной на основании стандарта IEEE.

Таблица 5. 4. Структура спецификации требований

Раздел

Описание

Предисловие

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

Введение

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

Глоссарий

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

Пользовательские требования

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

Системная архитектура

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

Системные требования

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

Системные модели

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

Эволюция системы

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

Приложения

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

Указатели

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

Конечно, информация, включаемая в спецификацию, зависит от типа разрабатываемого программного обеспечения и от выбранной технологии разработки. Например, если при разработке будет использоваться эволюционный подход, многие разделы спецификации, перечисленные в табл. 5.4, будут излишни. Если же разрабатываемое ПО является только частью большой системы, состоящей из взаимодействующих аппаратных и программных систем, тогда по необходимости требования будут очень подробными и детализированными. В этом случае спецификация может иметь значительный объем и будет содержать больше разделов, чем перечислено в табл. 5.4. Для больших документов необходимо делать оглавление и подробные указатели для поиска необходимой информации.

6. Разработка требований

Разработка требований - это процесс, включающий мероприятия, необходимые дня создания и утверждения документа, содержащего спецификацию системных требований. Различают четыре основных этапа процесса разработки требований: анализ технической осуществимости создания системы, формирование и анализ требований, специфицирование требований и создание соответствующей документации, а также аттестация этих требований. В этой главе рассмотрены все перечисленные этапы, за исключением специфицирования и документирования, которые описаны в главе 5. На рис. 6.1 показаны взаимосвязи между этими этапами и документы, сопровождающие каждый этап процесса разработки системных требований.

Рис. 6.1. Процесс разработки требований

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

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

6.1. Анализ осуществимости

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

1.  Отвечает ли система общим и бизнес-целям организации-заказчика и организации-разработчика?

2.  Можно ли реализовать систему, используя существующие на данный момент технологии и не выходя за пределы заданной стоимости?

3. Можно ли объединить систему с другими системами, которые уже эксплуатируются?

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

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

1. Что произойдет с организацией, если система не будет введена в эксплуатацию?

2. Какие текущие проблемы существуют в организации и как новая система поможет их решить?

3. Каким образом система будет способствовать целям бизнеса?

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

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

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

6.2. Формирование и анализ требований

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

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

Процесс формирования и анализа требований достаточно сложен по ряду причин.

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

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

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

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

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

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

Рис. 6.2. Процесс формирования и анализа требований

Процесс формирования и анализа требований проходит через ряд этапов.

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

2.  Сбор требований. Это процесс взаимодействия с лицами, формирующими требования. Во время этого процесса продолжается анализ предметной области.

3.  Классификация требований. На этом этапе бесформенный набор требований преобразуется в логически связанные группы требований.

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

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

6.  Проверка требований. На этом этапе определяется их полнота, последовательность и непротиворечивость.

Как показано на рис. 6.2, процесс формирования и анализа требований циклический, с обратной связью от одного этапа к другому. Цикл начинается с анализа предметной области и заканчивается проверкой требований. Понимание требований предметной области увеличивается в каждом цикле процесса формирования требований.

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

6.3. Аттестация требований

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

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

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

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

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

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

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

1.  Обзор требований. Требования системно анализируются рецензентами. Этот процесс обсуждается в следующем разделе.

2.  Прототипирование. На этом этапе прототип системы демонстрируется конечным пользователям и заказчику. Они могут экспериментировать с этим прототипом, чтобы убедиться, что он отвечает их потребностям.

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

4.  Автоматизированный анализ непротиворечивости. Если требования представлены в виде структурных или формальных системных моделей, можно использовать инструментальные CASE-средства для проверки непротиворечивости моделей. Этот процесс показан на рис. 6.3. Для автоматизированной проверки непротиворечивости необходимо построить базу данных требований и затем проверить все требования в этой базе данных. Анализатор требований готовит отчет обо всех обнаруженных противоречиях.

Рис. 6.3. Автоматизированный анализ непротиворечивости требований

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

6.4. Управление требованиям

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

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

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

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

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

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

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

Важно осознавать, что любой проект характеризуется тремя факторами:

- возможности создаваемого продукта;

- стоимость работ;

- сроки завершения.

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

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

- планированием;

- контролем за ходом выполнения работ;

- контролем над изменениями.

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

7.  Матрица требований. Разработка матрицы требований 

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

Фиксация требований (Requirement Capturing), с одной стороны, определяется желаниями заказчика в реализации того или иного свойства. С другой стороны в процессе сбора требований может обнаружиться ошибка, которая приведет к определенным последствиям, устранение которых заберет непредвиденные ресурсы –дополнительное кодирование, перепланирование.

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

Автоматизированная верификация требований может производиться лишь после спецификации или формализации требований.

Спецификация требований к ПО – процесс формализованного описания функциональных и нефункциональных требований, требований к характеристикам качества в соответствии со стандартом качества ISO/IEC 12119-94, которые будут учитываться при создании программного продукта на этапах ЖЦ ПО. В спецификации требований отражается структура ПО, требования к функциям, показателям качеству, которых необходимо достигнуть, и к документации. В спецификации задается в общих чертах архитектура системы и ПО, алгоритмы, логика управления и структура данных. Специфицируются также системные требования, нефункциональные требования и требования к взаимодействию с другими компонентами (БД, СУБД,протоколы сети и др.).

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

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

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

Полагая, что все требования четко идентифицированы и пронумерованы, можно сконструировать матрицу зависимостей требований (requirements dependency matrix) (или матрицу взаимодействия (interaction matrix требований)). В столбце и строке заголовка перечислены упорядоченные идентификаторы требований, как показано на рис. 7.1.

Требование

Т1

Т2

Т3

Т4

Т1

Х

Х

Х

Х

Т2

Конфликт

Х

Х

Х

Т4

Х

Х

Т4

Перекрытие

Перекрытие

Х

Рис. 7.1. Матрица зависимостей требований

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

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

Матрица соответствия требований - это двумерная таблица, содержащая соответсвие функциональных требований (functional requirements) продукта и подготовленных тестовых сценариев (test cases). В заголовках колонок таблицы расположены требования, а в заголовках строк - тестовые сценарии. На пересечении - отметка, означающая, что требование текущей колонки покрыто тестовым сценарием текущей строки.

Матрица соответсвия требований используется QA-инженерами для валидации покрытия продукта тестами (валидация – согласно стандарту ГОСТ Р ИСО 9000-2008 (соответствует ISO 9000:2005), валидация определена следующим образом: «Подтверждение на основе представления объективных свидетельств того, что требования, предназначенные для конкретного использования или применения, выполнены»).  Матрица соответсвия требований является неотъемлемой частью тест-плана.

Матрица трассировки (матрицы трассируемости) (traceability matrix) - если разбить слово трассируемость на составный станет легче понять и запомнить, трассируемость

(от англ. Traceability, Trace - хвост, abilityспособность). Прослеживаем зависимости (хвосты) между требованиями и тестами.

Матрица трассировки (матрицы трассируемости) - способ визуализации связей между элементами системы в форме таблицы.

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

- требования и тесты,

- заказчик и релизы (спринты)*,

- требования и подсистемы,

- требования и функциональные спецификации,

- функциональные и нефункциональные требования,

- требования и модели системы,

- варианты использования (Use Cases) и подсистемы,

- ошибки и тесты,

- ошибки и модули системы.

Примечание:*Спринт - итерация в скраме (скрам (Scrum) — это набор принципов, на которых строится процесс разработки, позволяющий в жёстко фиксированные и небольшие по времени итерации, называемые спринтами (sprints), предоставлять конечному пользователю работающее ПО с новыми возможностями, для которых определён наибольший приоритет. Возможности ПО к реализации в очередном спринте определяются в начале спринта на этапе планирования и не могут изменяться на всём его протяжении. При этом строго фиксированная небольшая длительность спринта придаёт процессу разработки предсказуемость и гибкость.), в ходе которой создаётся функциональный рост программного обеспечения. Жёстко фиксирован по времени. Длительность одного спринта от 2 до 4 недель. В отдельных случаях, к примеру согласно Scrum стандарту Nokia, длительность спринта должна быть не более 6 недель. Тем не менее, считается, что чем короче спринт, тем более гибким является процесс разработки, релизы выходят чаще, быстрее поступают отзывы от потребителя, меньше времени тратится на работу в неправильном направлении. С другой стороны, при более длительных спринтах команда имеет больше времени на решение возникших в процессе проблем, а владелец проекта уменьшает издержки на совещания, демонстрации продукта и т. п. Разные команды подбирают длину спринта согласно специфике своей работы, составу команд и требований, часто методом проб и ошибок. Для оценки объема работ в спринте можно использовать предварительную оценку, измеряемую в очках истории. Предварительная оценка фиксируется в бэклоге проекта. На протяжении спринта никто не имеет права менять список требований к работе, внесённых в бэклог спринта.

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

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

1) Выбираются элементы рассматриваемой системы для строк и столбцов.

2) При наличии связи требуемого типа между элементом  строки и элементом столбца в соответствующей ячейке ставится любой удобный символ.

Более сложные матрицы трассировки могут отражать не только факт наличия связи, но и ее атрибуты.

Рассмотрим простой и наглядный пример.

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

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

Рис. 7.2. Иллюстрация матрицы трассировки — табель посещаемости

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

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

Если из 10-12 человек нет троих, которые посещали все занятия, это означает, что у группы нет полного и достоверного конспекта. Это также приведет к сложностям на экзамене. А значит преподавателю необходимо планировать либо предупреждающие меры, либо потом бороться с последствиями увеличения нагрузки в сессию.

Если матрица сильно разрежена, необходимо срочно принимать меры и прежде всего необходимо понять по каким причинам группа не ходит — не интересно? Не успевают? Не сдали предыдущие работы? Нет мотивации? Вынуждены работать и пропускать занятия?

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

 Трассировка обеспечивает полноту тестирования и подготавливает основу для планирования тестов. Матрица трассировки может быть самостоятельным документом или может быть включена как часть документации по требованиям или часть плана тестирования.

Примеры картинок с трассировочными матрицами:

Пример 1:

Пример 2:

Пример 3:

Пример 4:

Рис. 7.3. Примеры матрицы трассировки

Инструкции:

В соответствии с лучшими практиками, бизнес-требования следует декомпозировать до мельчайших пакетов и нумеровать в соответствии со следующими правилами нумерации: BR001, BR002 и т.д. Для каждого бизнес-требования будет одно или несколько функциональных требований, которые должны соответствовать соглашению по нумерации для соответствующего бизнес-требования: FR001.01, FR001.02, FR001.03, FR002 и т.д. Функциональные требования должны быть декомпозированы до мельчайших пакетов.

Для каждого функционального требования будет существовать одна или несколько связанных технических спецификаций, которые должны соответствовать соглашению по нумерации для связанных функциональных требований: TS001.01.01, TS001.01.02, TS001.01.03 и т.д. Технические спецификации должны быть декомпозированы до мельчайших пакетов.

Часть III. Моделирование программного обеспечения

8. Архитектурное проектирование

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

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

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

1.  Структурирование системы. Программная система структурируется в виде совокупности относительно независимых подсистем. Также определяются взаимодействия между подсистемами.

2.  Моделирование управления. Разрабатывается базовая модель управления взаимоотношениями между частями системы.

3.  Модульная декомпозиция. Каждая определенная на первом этапе подсистема разбивается на отдельные модули. Здесь определяются типы модулей и типы их взаимосвязей.

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

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

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

2.  Модуль – это обычно компонент системы, который предоставляет один или несколько сервисов для других модулей. Модуль может использовать сервисы, поддерживаемые другими модулями. Как правило, модуль никогда не рассматривается как независимая система. Модули обычно состоят из ряда других, более простых компонентов.

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

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

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

3.  Интерфейсная модель, которая определяет сервисы, предоставляемые каждой подсистемой через общий интерфейс.

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

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

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

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

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

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

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

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

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

Очевидно, что некоторые из перечисленных архитектур противоречат друг другу. Например, для того чтобы повысить производительность, необходимо использовать крупномодульные компоненты, в то же время сопровождение системы намного упрощается, если она состоит из мелких структурных компонентов. Если необходимо учесть оба требования, следует искать компромиссное решение. Ранее уже было сказано, что один из способов решения подобных проблем состоит в применении различных архитектурных моделей для разных частей системы.

8.1. Структурирование системы

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

Бэсс (Bass) считает, что подобные блок-схемы являются бесполезными представлениями системной архитектуры, поскольку из них нельзя ничего узнать ни о природе взаимоотношений между компонентами системы, ни об их свойствах. С точки зрения разработчика программного обеспечения, это абсолютно верно. Однако такие модели оказываются эффективными на этапе предварительного проектирования системы. Эта модель не перегружена деталями, с ее помощью удобно представить структуру системы. В структурной модели определены все основные подсистемы, которые можно разрабатывать независимо от остальных подсистем, следовательно, руководитель проекта может распределить разработку этих подсистем между различными исполнителями.

8.2. Модели управления

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

Можно выделить два основных типа управления в программных системах.

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

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

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

8.3. Модульная декомпозиция

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

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

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

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

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

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

8.4. Проблемно-зависимые архитектуры

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

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

1.  Модели классов систем. Отображают классы реальных систем, вобрав в себя основные характеристики этих классов. Как правило, архитектурные модели классов встречаются в системах реального времени, например в системах сбора данных, мониторинга и т.д.

2.  Базовые модели. Более абстрактны и предоставляют разработчикам информацию по общей структуре какого-либо типа систем.

Конечно, четких различий между этими видами моделей нет. В некоторых случаях модели классов служат в качестве базовых. Здесь проводятся различие между ними, поскольку базовые модели можно напрямую повторно использовать в проекте. Базовые модели обычно используются в системах коммуникаций и при сравнении возможных системных архитектур. Различны также процессы разработки этих моделей. Модели классов разрабатываются как обобщение существующих систем "снизу вверх", в то время как разработка базовых моделей идет "сверху вниз".

9. Архитектура распределенных систем

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

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

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

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

2.  Встроенные системы, предназначенные для работы на одном процессоре либо на интегрированной группе процессоров. К ним относятся системы управления бытовыми устройствами, различными приборами и др.

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

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

Выделено шесть основных характеристик распределенных систем.

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

2.  Открытость. Это возможность расширять систему путем добавления новых ресурсов. Распределенные системы – это открытые системы, к которым подключают аппаратное и программное обеспечение от разных производителей.

3.  Параллельность. В распределенных системах несколько процессов могут одновременно выполняться на разных компьютерах в сети. Эти процессы могут (но не обязательно) взаимодействовать друг с другом во время их выполнения.

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

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

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

Разумеется, распределенным системам присущ ряд недостатков.

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

•  Безопасность. Обычно доступ к системе можно получить с нескольких разных машин, сообщения в сети могут просматриваться или перехватываться. Поэтому, в распределенной системе намного сложнее поддерживать безопасность.

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

•  Непредсказуемость. Как известно всем пользователям Web-сети, реакция распределенных систем на определенные события непредсказуема и зависит от полной загрузки системы, ее организации и сетевой нагрузки. Так как все эти параметры могут постоянно меняться, время, затраченное на выполнение запроса пользователя, в тот или иной момент может существенно различаться.

При обсуждении преимуществ и недостатков распределенных систем определяется ряд критических проблем проектирования таких систем (табл. 9.1).

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

Проблема проектирования

Описание

Идентификация ресурсов

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

Коммуникации

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

Качество системного сервиса

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

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

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

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

1.  Архитектура клиент/сервер. В этой модели систему можно представить как набор сервисов, предоставляемых серверами клиентам. В таких системах серверы и клиенты значительно отличаются друг от друга.

2.  Архитектура распределенных объектов. В этом случае между серверами и клиентами нет различий и систему можно представить как набор взаимодействующих объектов, местоположение которых не имеет особого значения. Между поставщиком сервисов и их пользователями не существует различий.

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

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

9.1. Многопроцессорная архитектура

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

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

Рис. 9.1. Многопроцессорная система управления движением транспорта

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

9.2. Архитектура клиент/сервер

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

Рис. 9.2. Система клиент/сервер

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

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

Самой простой архитектурой клиент/сервер является двухуровневая, в которой приложение состоит из сервера (или множества идентичных серверов) и группы клиентов. Существует два вида такой архитектуры (рис. 9.5).

1.  Модель тонкого клиента. В этой модели вся работа приложения и управление данными выполняются на сервере. На клиентской машине запускается только ПО уровня представления.

2.  Модель толстого клиента. В этой модели сервер только управляет данными. На клиентской машине реализована работа приложения и взаимодействие с пользователем системы.

Рис. 9.3. Компьютеры в сети клиент/сервер

Рис. 9.4. Уровни программного приложения

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

Рис. 9.5. Модели тонкого и толстого клиентов

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

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

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

Рис. 9.6. Система клиент/сервер для сети банкоматов

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

Появление языка Java и загружаемых аплетов позволили разрабатывать модели клиент/сервер, которые находятся где-то посередине между моделями тонкого и толстого клиента. Часть программ, составляющих приложение, можно загружать на клиентской машине как аплеты Java и тем самым разгрузить сервер. Интерфейс пользователя строится посредством Web-броузера, который запускает аплеты Java. Однако Web-броузеры от различных производителей и даже различные версии Web-броузеров от одного производителя не всегда выполняются одинаково. Более ранние версии броузеров на старых машинах не всегда могут запустить аплеты Java. Следовательно, такой подход можно использовать только тогда, когда вы уверены, что у всех пользователей системы установлены броузеры, совместимые с Java.

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

Рис. 9.7. Трехуровневая архитектура клиент/сервер

Архитектура ПО, построенная по трехуровневой модели клиент/сервер, не требует, чтобы в сеть были объединены три компьютерных системы. На одном компьютере-сервере можно запустить и выполнение приложения, и управление данными как отдельные логические серверы. В то же время, если требования к системе возрастут, можно будет относительно просто разделить выполнение приложения и управление данными и выполнять их на разных процессорах.

Банковскую систему, использующую Internet-сервисы, можно реализовать с помощью трехуровневой архитектуры клиент/сервер. База данных расчетов (обычно расположенная на главном компьютере) предоставляет сервисы управления данными, Web-сервер поддерживает сервисы приложения, например средства перевода денег, генерацию отчетов, оплату счетов и др. А компьютер пользователя с Internet-броузером является клиентом. Как показано на рис. 9.8, эта система масштабируема, так как в нее относительно просто добавить новые Web-серверы при увеличении количества клиентов.

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

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

Рис. 9.8. Распределенная архитектура банковской системы с использованием Internet-сервисов

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

Таблица 9.2. Применение разных типов архитектуры клиент/сервер

Архитектура

Приложения

Двухуровневая архитектура тонкого клиента

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

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

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

Двухуровневая архитектура толстого клиента

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

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

Трехуровневая и многоуровневая архитектуры клиент/сервер

Большие приложения с сотнями и тысячами клиентов. Приложения, в которых часто меняются и данные, и методы обработки.

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

9.3. Архитектура распределенных объектов

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

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

Рис. 9.9. Архитектура распределенных объектов

Объекты могут располагаться на разных компьютерах в сети и взаимодействовать посредством промежуточного ПО. По аналогии с системной шиной, которая позволяет подключать различные устройства и поддерживать взаимодействие между аппаратными средствами, промежуточное ПО можно рассматривать как шину программного обеспечения. Она предоставляет набор сервисов, позволяющий объектам взаимодействовать друг с другом, добавлять или удалять их из системы. Промежуточное ПО называют брокером запросов к объектам. Его задача – обеспечивать интерфейс между объектами. Брокеры запросов к объектам рассматриваются в разделе 9.4.

Ниже перечислены основные преимущества модели архитектуры распределенных объектов.

•  Разработчики системы могут не спешить с принятием решений относительно того, где и как будут предоставляться сервисы. Объекты, предоставляющие сервисы, могут выполняться в любом месте (узле) сети. Следовательно, различие между моделями толстого и тонкого клиентов становятся несущественными, так как нет необходимости заранее планировать размещение объектов для выполнения приложения.

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

•  Гибкость и масштабируемость системы. Для того чтобы справиться с системными нагрузками, можно создавать экземпляры системы с одинаковыми сервисами, которые будут предоставляться разными объектами или разными экземплярами (копиями) объектов. При увеличении нагрузки в систему можно добавить новые объекты, не прерывая при этом работу других ее объектов.

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

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

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

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

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

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

Рис. 9.10. Архитектура распределенной системы обработки данных

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

1.  В этих системах (в отличие, например, от системы банкоматов) нет одного поставщика сервиса, на котором были бы сосредоточены все сервисы управления данными.

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

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

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

9.4. CORBA

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

В настоящий момент для поддержки распределенных объектных вычислений существует два основных стандарта промежуточного ПО.

1.  CORBA (Common Object Request Broker Architecture– архитектура брокеров запросов к общим объектам). Это набор стандартов для промежуточного ПО, разработанный группой OMG (Object Management Group – группа по управлению объектами). OMG является консорциумом фирм-производителей программного и аппаратного обеспечения, в числе которых такие компании, как Sun, Hewlett-Packard и IBM. Стандарты CORBA определяют общий машинонезависимый подход к распределенным объектным вычислениям. Разными производителями разработано множество реализаций этого стандарта. Стандарты CORBA поддерживаются операционной системой Unix и операционными системами от Microsoft.

2.  DCOM (Distributed Component Object Model – объектная модель распределенных компонентов). DCOM представляет собой стандарт, разработанный и реализованный компанией Microsoft и интегрированный в ее операционные системы. Данная модель распределенных вычислений менее универсальна, чем CORBA и предлагает более ограниченные возможности сетевых взаимодействий. В настоящий момент использование DCOM ограничивается операционными системами Microsoft.

Стандарты CORBA определены группой OMG, которая объединяет более 500 компаний, поддерживающих объектно-ориентированные разработки. Роль OMG – создание стандартов для объектно-ориентированных разработок, а не обеспечение конкретных реализаций этих стандартов. Эти стандарты находятся в свободном доступе на Web-узле OMG. Группа занимается не только стандартами CORBA, но также определяет широкий диапазон других стандартов, включая язык моделирования UML.

Представление распределенных приложений в рамках CORBA показано на рис. 11.11. Это упрощенная схема архитектуры управления объектами. Предполагается, что распределенное приложение должно состоять из перечисленных ниже компонентов.

1.  Объекты приложения, которые созданы и разработаны для данного программного продукта.

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

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

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

Рис. 9.11. Структура распределенного приложения, основанного на стандартах CORBA

Стандарты CORBA описывают четыре основных элемента.

1.  Модель объектов, в которой объект CORBA инкапсулирует состояния посредством четкого описания на языке IDL (Interface Definition Language – язык описания интерфейсов).

2.  Брокер запросов к объектам (Object Request BrokerORB), который управляет запросами к сервисам объектов. ORB размещает объекты, предоставляющие сервисы, подготавливает их к получению запросов, передает запрос к сервису и возвращает результаты объекту, сделавшему запрос.

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

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

В модели CORBA объект инкапсулирует атрибуты и сервисы как обычный объект. Вместе с тем в объектах CORBA еще должно содержаться определение различных интерфейсов, описывающих глобальные атрибуты и операции объекта. Интерфейсы объектов CORBA определяются на стандартном универсальном языке описания интерфейсов IDL. Если один объект запрашивает сервисы, предоставляемые другими объектами, он получает доступ к этим сервисам через IDL-интерфейс. Объекты CORBA имеют уникальный идентификатор, называемый IOR (Interoperable Object Reference – ссылка на взаимодействующий объект). Когда один объект отправляет запросы к сервису, предоставляемому другим объектом, используется идентификатор IOR.

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

На рис. 9.12 показано, как объекты ol и о2 взаимодействуют посредством брокера запросов к объектам. Вызывающий объект (ol) связан с заглушкой (stub) IDL, которая определяет интерфейс объекта, предоставляющего сервис. Конструктор объекта ol при запросе к сервису внедряет вызовы в заглушку своей реализации объекта. Язык IDL является расширением C++, поэтому, если вы программируете на языках C++, С или Java, получить доступ к заглушке совсем просто. Перевод описания интерфейса объекта на IDL также возможен и для других языков, например Ada или COBOL. Но в этих случаях необходима соответствующая инструментальная поддержка.

Рис. 9.12. Взаимодействие объектов посредством брокера запросов к объектам

Объект, предоставляющий сервис, связан с остовом (skeleton) IDL, который связывает интерфейс с реализацией сервисов. Иными словами, когда сервис вызывается через интерфейс, остов IDL транслирует вызов к сервису независимо от того, какой язык использовался в реализации. После завершения метода или процедуры остов транслирует результаты в язык IDL, так что они становятся доступными вызывающему объекту. Если объект одновременно предоставляет сервисы другим объектам или использует сервисы, которые предоставлены еще где-то, ему требуются и остов IDL, и заглушка IDL. Последняя необходима всем используемым объектам.

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

Такая ситуация проиллюстрирована на рис. 9.13. В данном примере, если объект ol или о2 отправляет запросы к сервисам, предоставляемым объектами о3 или о4, то необходимо взаимодействие связанных с этими объектами брокеров. Стандарты CORBA поддерживают взаимодействие "брокер-брокер", которое обеспечивает брокерам доступ к описаниям интерфейсов IDL, и предлагают разработанный группой OMG стандарт обобщенного протокола взаимодействия брокеров GIOP (Generic Inter-ORB Protocol). Данный протокол определяет стандартные сообщения, которыми могут обмениваться брокеры при выполнении вызовов удаленного объекта и передаче информации. В сочетании с протоколом Internet низкого уровня TCP/IP этот протокол позволяет брокерам взаимодействовать через Internet.

Первые варианты CORBA были разработаны еще в 1980-х годах. Ранние версии CORBA просто были связаны с поддержкой распределенных объектов. Однако со временем стандарты развивались, становились более расширенными. Подобно механизмам взаимодействия распределенных объектов, стандарты CORBA сейчас определяют некоторые стандартные сервисы, которые можно использовать для поддержки объектно-ориентированных приложений.

Рис. 9.13. Взаимодействие между брокерами запросов к объектам

Сервисы CORBA являются средствами, которые необходимы во многих распределенных системах. Эти стандарты определяют примерно 15 общих служб (сервисов):

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

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

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

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

10. Объектно-ориентированное проектирование

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

Рис. 10.1. Система взаимодействующих объектов

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

•  Объектно-ориентированный анализ. Создание объектно-ориентированной модели предметной области приложения ПО. Здесь объекты отражают реальные объекты-сущности, также определяются операции, выполняемые объектами.

•  Объектно-ориентированное проектирование. Разработка объектно-ориентированной модели системы ПО (системной архитектуры) с учетом системных требований. В объектно-ориентированной модели определение всех объектов подчинено решению конкретной задачи.

•  Объектно-ориентированное программирование. Реализация архитектуры (модели) системы с помощью объектно-ориентированного языка программирования. Такие языки, например Java, непосредственно выполняют реализацию определенных объектов и предоставляют средства для определения классов объектов.

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

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

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

10.1. Объекты и классы объектов

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

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

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

10.2. Процесс объектно-ориентированного проектирования

В этом разделе процесс объектно-ориентированного проектирования показан на примере разработки структуры управляющей программной системы, встроенной в автоматизированную метеостанцию. Как отмечалось выше, есть несколько методов объектно-ориентированного проектирования, причем какого-либо предпочтительного метода или процесса проектирования не существует. Рассматриваемый здесь процесс является достаточно общим, т.е. состоит из операций, характерных для большинства процессов объектно-ориентированного проектирования. В этом отношении он сравним с процессом, предлагаемым языком UML.

Общий процесс объектно-ориентированного проектирования состоит из нескольких этапов.

1. Определение рабочего окружения системы и разработка моделей ее использования.

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

3. Определение основных объектов системы.

4. Разработка моделей архитектуры системы.

5. Определение интерфейсов объекта.

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

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

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

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

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

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

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

1.  Модель окружения системы – это статическая модель, которая описывает другие системы из окружения разрабатываемого ПО.

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

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

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

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

Рис. 10.2. Варианты использования метеостанции

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

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

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

10.2.2. Проектирование архитектуры

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

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

Рис. 10.2. Архитектура метеостанции

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

1.  Уровень интерфейсов, который занимается всеми взаимодействиями с другими частями системы и предоставлением внешних интерфейсов системы.

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

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

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

10.2.3. Определение объектов

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

Хотя этот раздел назван "Определение объектов", на самом деле на данном этапе проектирования определяются классы объектов. Структура системы описывается в терминах этих классов. Классы объектов, определенные ранее, неизбежно получают более детальное описание, поэтому иногда приходится возвращаться на данный этап проектирования для переопределения классов.

Существует множество подходов к определению классов объектов.

1.  Использование грамматического анализа естественного языкового описания системы. Объекты и атрибуты – это существительные, операции и сервисы – глаголы. Такой подход реализован в иерархическом методе объектно-ориентированного проектирования, который широко используется в аэрокосмической промышленности Европы.

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

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

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

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

10.2.4. Модели архитектуры

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

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

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

Существует два типа объектно-ориентированных моделей системной архитектуры.

1.  Статические модели, которые описывают статическую структуру системы в терминах классов объектов и взаимоотношений между ними. Основными взаимоотношениями, которые документируются на данном этапе, являются отношения обобщения, отношения "используют-используются" и структурные отношения.

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

В языке моделирования UML поддерживается огромное количество возможных статических и динамических моделей. Буч (Booch) предлагает девять различных типов схем для представления моделей. Чтобы показать все модели, не хватит места, да и не все из них пригодны для примера с метеостанцией. Здесь рассматриваются три типа моделей.

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

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

3.  Модели конечного автомата, которые показывают изменение состояния отдельных объектов в ответ на определенные события. В UML они представлены в виде диаграмм состояния. Модели конечного автомата являются динамическими.

Модель подсистем является одной из наиболее важных и полезных статических моделей, поскольку показывает, как можно организовать систему в виде логически связанных групп объектов. В UML пакеты являются структурами инкапсуляции и не отображаются непосредственно в объектах разрабатываемой системы. Однако они могут отображаться, например, в виде библиотек Java.

На рис. 10.3 показаны объекты подсистем метеостанции. В данной модели также представлены некоторые связи. Например, объект КонтроллерКоммуникаций связан с объектом Метеостанция, а объект Метеостанция связан с пакетом Сбор данных. Совместная модель пакетов и классов объектов позволяет показать логически сгруппированные системные элементы.

Рис. 10.3. Пакеты системы метеостанции

Модель последовательностей – одна из наиболее полезных и наглядных динамических моделей, которая в каждом узле взаимодействия документирует последовательность происходящих между объектами взаимодействий. Опишем основные свойства модели последовательности.

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

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

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

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

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

1.  Объект:КонтроллерКоммуникаций, являющийся экземпляром одноименного класса, получает внешний запрос "отправить отчет о погоде". Он подтверждает получение запроса. Половинная стрелка показывает, что, отправив сообщение, объект не ожидает ответа.

2.  Этот объект отправляет сообщение объекту, который является экземпляром класса Метеостанция, чтобы создать метеорологический отчет. Объект:КонтроллерКоммуникаций затем приостанавливает работу (его прямоугольник управления заканчивается). Используемый стиль стрелок показывает, что объекты:КонтроллерКоммуникаций и:Метеостанция могут выполняться параллельно.

3.  Объект, который является экземпляром класса Метеостанция, отправляет сообщение объекту:МетеоДанные, чтобы подвести итоги по метеорологическим данным. Здесь другой стиль стрелок указывает на то, что объект:Метеостанция ожидает ответа.

4.  После составления сводки, управление передается объекту:Метеостанция. Пунктирная стрелка обозначает возврат управления.

5.  Этот объект передает сообщение объекту:КонтроллерКоммуникаций, из которого был прислан запрос, чтобы передать данные в удаленную систему. Затем объект:Метеостанция приостанавливает работу.

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

Рис. 10.4. Последовательность операций во время сбора данных

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

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

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

На рис. 10.5 представлена диаграмма состояния объекта Метеостанция, которая показывает реакцию объекта на запросы от разных сервисов.

Рис. 10.5. Диаграмма состояний объекта Метеостанция

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

1.  Если объект находится в состоянии Останов, он может отреагировать только сообщением запуск(). Затем он переходит в состояние ожидания дальнейших сообщений. Немаркированная стрелка с черным кружком указывает на то, что это состояние является начальным.

2.  В состоянии Ожидание система ожидает дальнейших сообщений. При получении сообщения завершение() объект возвращается в состояние завершения работы Останов.

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

4.  Получив сообщение калибровать(), система последовательно проходит через состояния калибровки, тестирования, передачи и лишь после этого переходит в состояние ожидания. В случае получения сообщения тестировать(), система сразу переходит в состояние тестирования.

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

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

10.2.5. Специфицирование интерфейсов объектов

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

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

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

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

Листинг 10.1. Описание интерфейса метеостанции

interface Метеостанция {

public void Метеостанция();

public void запуск();

public void запуск (Прибор i);

public void завершение();

public void завершение(Прибор i) ;

public void отчетПогода();

public void тестировать();

public void тестировать(Прибор i);

public void калибровать(Прибор i);

public int получитьИдНомер();

}//Метеостанция

10.3. Модификация системной архитектуры

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

Рис. 10.13. Новые объекты для наблюдения за загрязнением воздуха

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

1.  Класс объектов, именуемый КачествоВоздуха следует вставить как часть объекта Метеостанция на одном уровне с объектом МетеоДанные.

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

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

На рис. 10.13 показан объект Метеостанция и новые объекты, добавленные в систему. За исключением самого верхнего уровня системы (объект Метеостанция) в имеющиеся объекты не потребовалось вносить изменений. Добавление в систему сбора данных о загрязнении воздуха не оказало никакого влияния на сбор метеорологических данных.

11. Проектирование систем реального времени

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

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

Система реального времени – это программная система, правильное функционирование которой зависит от результатов ее работы и от периода времени, в течение которого получен результат. "Мягкая" система реального времени – это система, в которой операции удаляются, если в течение определенного интервала времени не выдан результат. "Жесткая" система реального времени – это система, операции которой становятся некорректными, т.е. вырабатывается сигнал об ошибке, если в течение определенного интервала времени результат не выдан.

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

Входные сигналы делятся на два класса.

1.  Периодические сигналы, происходят через предопределенные интервалы времени. Например, система проверяет датчик каждые 50 миллисекунд, и предпринимает действия (реагирует) в зависимости от значений, полученных от датчика (стимула).

2.  Апериодические сигналы происходят нерегулярно. Обычно они "сообщают о себе" посредством механизма прерываний. Примером апериодического сигнала может быть прерывание, которое вырабатывается по завершении передачи вход/выход и размещения данных в буфере обмена.

В системах реального времени периодические входные сигналы обычно генерируются сенсорами (датчиками), взаимодействующими с системой. Они предоставляют информацию о состоянии внешнего окружения системы. Системные отклики (ответные сигналы) направляются группе исполнительных механизмов, управляющих аппаратными устройствами, которые затем воздействуют на окружение системы. Апериодические входные сигналы могут генерироваться и сенсорами, и исполнительными механизмами. Как правило, апериодические сигналы означают исключительные ситуации, например ошибки в работе аппаратуры. На рис. 11.1 показана модель "сенсор-система-исполнительный механизм" для встроенной системы реального времени.

Рис. 11.1. Общая модель системы реального времени

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

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

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

11.1. Проектирование систем реального времени

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

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

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

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

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

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

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

3.  Объединение процессов обработки входных и ответных сигналов в виде совокупности параллельных процессов. В корректной модели системной архитектуры каждый процесс связан с определенным классом входных и ответных сигналов (как показано на рис. 11.2).

4.  Разработка алгоритмов, выполняющих необходимые вычисления для всех входных и ответных сигналов. Чтобы получить представление об объемах вычислительных и временных затрат в процессе обработки сигналов, разработка алгоритмов обычно проводится на ранних этапах процесса проектирования.

5.  Разработка временного графика работы системы.

6.  Сборка системы, работающей под управлением диспетчера – управляющей программы.

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

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

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

11.2. Управляющие программы

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

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

1.  Часы реального времени периодически предоставляют информацию для планирования процессов.

2.  Обработчик прерываний управляет апериодическими запросами к сервисам.

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

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

5.  Диспетчер запускает на выполнение какой-либо процесс.

Рис. 11.4. Компоненты управляющей программы реального времени

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

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

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

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

1.  Уровень прерываний является наивысшим уровнем приоритетов. Он присваивается тем процессам, на которые необходимо быстро отреагировать. Примером такого процесса может быть процесс часов реального времени.

2.  Тактовый уровень приоритетов присваивается периодическим процессам.

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

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

11.3. Системы наблюдения и управления

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

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

Рассмотрим следующий пример.

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

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

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

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

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

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

На следующем шаге процесса проектирования определяются временные ограничения для каждого входного и ответного сигналов системы. В табл. 11.1 перечислены эти временные ограничения. К разным типам датчиков, генерирующих входные сигналы, предъявлены разные временные требования.

Таблица 11.1. Временные ограничения на входные и ответные сигналы системы

Сигнал

Временные ограничения

Отключение электропитания

Сигнализация на двери

Сигнализация на окнах

Датчик движения

Звуковой сигнал

Включение световой сигнализации

Связь

Синтезатор речи

Переключение на питание от батарей должно произойти в течение 50 мс

Каждый сигнальный датчик на дверях проверяется дважды в секунду

Каждый датчик на окне проверяется дважды в секунду

Каждый датчик движения опрашивается дважды в секунду

Звуковой сигнал должен прозвучать через полсекунды после сигнала датчика

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

Вызов в полицию должен начаться в течение 2 с после сигнала датчика

Синтезированное сообщение должно быть готово через 4 с после сигнала датчика

Рис. 11.6. Архитектура процессов системы охранной сигнализации

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

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

Частота выполнения процессов определяется количеством датчиков и временными требованиями, предъявляемыми системе. Предположим, что в системе имеется 30 дверных датчиков, которые требуется проверять два раза в секунду. Следовательно, связанный с дверным датчиком процесс должен выполняться 60 раз в секунду (частота 60 Гц). Также 400 раз в секунду выполняется процесс, контролирующий датчик движения.

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

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

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

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

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

Архитектура процессов такой системы показана на рис. 11.7; в общем виде она выглядит подобно системе сигнализации. Дальнейшее рассмотрение этого примера предлагается читателю в качестве упражнения.

Рис. 11.7. Архитектура процессов системы управления отоплением

11.4. Системы сбора данных

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

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

Рис. 11.8. Архитектура системы наблюдения за интенсивностью потока нейтронов

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

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

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

Рис. 11.9. Кольцевой буфер в системе сбора данных

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

В листинге 11.2 показана возможная реализация буфера данных как объекта Java. Значения в буфере имеют тип SensorRecord (запись данных датчика). Определены два метода– get и put: метод get берет элементы из буфера, метод put добавляет элемент в буфер. При объявлении типа CircularBuffer (кольцевой буфер) программный конструктор задает размер буфера.

12. Проектирование с повторным использованием компонентов

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

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

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

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

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

2.  Повторно используемые, компоненты. Можно повторно использовать компоненты приложений - от подсистем до отдельных объектов. Например, система распознавания текста, разработанная как часть системы обработки текстов, может повторно использоваться в системах управления базами данных.

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

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

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

Таблица 12.1. Преимущества повторного использования ПО

Преимущество

Описание

Повышение надежности

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

Уменьшение проектных рисков

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

Эффективное использование специалистов

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

Соблюдение стандартов

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

Ускорение разработки

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

Для успешного проектирования и разработки ПО с повторным использованием компонентов должны выполняться три основных условия:

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

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

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

Успешное использование компонентов в приложениях Visual Basic, Visual C++ и Java продемонстрировало важность повторного использования. Разработка ПО, основанная на повторном использовании компонентов, становится широко распространенным рентабельным подходом к разработке программных продуктов.

Вместе с тем подходу к разработке ПО с повторным использованием компонентов присущ ряд недостатков и проблем (табл. 12.2), которые препятствуют запланированному сокращению расходов на разработку проекта.

Таблица 12.2. Проблемы повторного использования

Проблема

Описание

Повышение стоимости сопровождения системы

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

Недостаточная инструментальная поддержка

CASE-средства не поддерживают разработку ПО с повторным использованием компонентов. Интегрирование этих средств с системой библиотек компонентов затруднительно или даже невозможно. Если процесс разработки ПО осуществляется с помощью CASE-средств, повторное использование компонентов можно полностью исключить

Синдром "изобретения велосипеда"

Некоторые разработчики ПО предпочитают переписать компоненты, так как полагают, что смогут при этом их усовершенствовать. Кроме того, многие считают, что создание программ "с нуля" перспективнее и "благороднее" повторного использования написанных другими программ

Содержание библиотеки компонентов

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

Поиск и адаптация компонентов

Компоненты ПО нужно найти в библиотеке, изучить и адаптировать к работе в новых условиях, что "не укладывается" в обычный процесс разработки ПО

Из перечисленного выше следует, что повторное использование компонентов должно быть систематическим, плановым и включенным во все организационные программы организации-разработчика. В Японии повторное использование известно много лет и является неотъемлемой частью "японского" метода разработки ПО. Альтернативой повторному использованию программных компонентов является применение программных генераторов. Согласно этому подходу информация, необходимая для повторного использования, записывается в систему генератора программ с учетом знаний о той предметной области, где будет эксплуатироваться разрабатываемая система. В данном случае в системной спецификации должно быть точно указано, какие именно компоненты выбраны для повторного использования, а также описаны их интерфейсы и то, как они должны компоноваться. На основе такой информации генерируется система ПО (рис. 12.1).

Рис. 12.1. Генерирование программ

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

1.  Генераторы приложений для обработки экономических данных. На входе генератора – описание приложения на языке четвертого поколения или диалоговая система, где пользователь определяет экранные формы и способы обработки данных. На выходе – программа на каком-либо языке программирования, например COBOL или SQL.

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

3.  Генераторы кодов CASE-средств. На входе генераторов – архитектура ПО, а на выходе - программная реализация проектируемой системы.

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

12.1. Покомпонентная разработка

Метод покомпонентной разработки ПО с повторным использованием компонентов появился в конце 1990-х годов как альтернатива объектно-ориентированному подходу к разработке систем, который не привел к повсеместному повторному использованию программных компонентов, как предполагалось изначально. Отдельные классы объектов оказались слишком детализированными и специфическими: их требовалось связывать с приложением либо во время компиляции, либо при компоновке системы. Использование классов обычно предполагает наличие детальных данных о классах, что делает доступным исходный код, но для коммерческих продуктов исходный код открыт очень редко. Несмотря на ранние оптимистические прогнозы, значительное развитие рынка отдельных программных объектов и компонентов так и не состоялось.

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

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

1.  Компонент – это независимо выполняемый программный объект. Исходный код компонента может быть недоступен, поэтому такой компонент не компилируется совместно с другими компонентами системы.

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

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

•  Интерфейс поставщика сервисов, который определяет сервисы, предоставляемые компонентом.

•  Интерфейс запросов, который определяет, какие сервисы доступны компоненту из системы, использующей этот компонент.

Рис. 12.2. Интерфейсы компонента

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

Рис. 12.3. Компонент службы печати

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

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

2.  Бессистемная группировка. В данном случае компонент – это набор слабо связанных между собой программных объектов и подпрограмм, например объявлений данных, функций и т.п. Интерфейс поставщика сервисов состоит из названий всех объектов в группировке.

3.  Абстракции данных. Компонент является абстракцией данных или классом, описанным на объектно-ориентированном языке. Интерфейс поставщика сервисов состоит из методов (операций), обеспечивающих создание, изменение и получение доступа к абстракции данных.

4.  Абстракции кластеров. Здесь компонент – это группа связанных классов, работающих совместно. Такие компоненты иногда называют структурой. Интерфейс поставщика сервисов является композицией всех интерфейсов объектов, составляющих структуру (см. раздел 12.1.1).

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

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

Рис. 12.4. Интеграция повторного использования компонентов в процесс разработки ПО

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

Рис. 12.5. Процесс проектирования с повторным использованием компонентов

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

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

Первым языком сценариев, разработанным для интеграции повторно используемых компонентов, был Unix shell. После него разработано множество других языков сценариев, например Visual Basic и TCL/TK. Пожалуй, главной проблемой, связанной с покомпонентной разработкой систем, является их сопровождение и модернизация. При изменении требований к системе часто в компоненты необходимо внести изменения, соответствующие новым требованиям, однако в большинстве случаев это невозможно, поскольку исходный код компонентов недоступен. Также, как правило, не подходит альтернативный вариант: замена одного компонента другим. Таким образом, необходима дополнительная работа по адаптации повторно используемых компонентов, что приводит к повышению стоимости обслуживания системы. Однако, поскольку разработка с повторным использованием компонентов позволяет быстрее создавать ПО, организации согласны оплачивать дополнительные расходы на сопровождение и модернизацию систем.

12.2. Семейства приложений

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

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

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

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

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

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

Рис. 12.7. Обобщенная система управления ресурсами

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

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

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

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

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

Рис. 12.8. Библиотечная система

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

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

Обобщенный процесс создания нового приложения состоит из следующих этапов:

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

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

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

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

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

Рис. 12.9. Процесс разработки нового члена семейства приложений

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

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

12.3. Проектные паттерны

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

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

Проектные паттерны (design patterns) появились из идей, выдвинутых Кристофером Александером (Alexander), который предложил удобные и эффективные обобщенные паттерны разработки конкретных проектов. Паттерн – это описание проблемы и метода ее решения, позволяющее в дальнейшем использовать это решение в разных условиях. Паттерн не является детальной спецификацией. Скорее, он представляет собой описание, в котором аккумулированы знания и опыт. Паттерн – гарантированное решение общей проблемы.

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

Существует четыре основных элемента проектного паттерна.

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

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

3.  Описание решений с отдельным описанием различных частей решения и их взаимоотношений. Это не описание конкретного проекта, а шаблон проектных решений, который можно использовать различными способами. В описании решений часто используются графические представления, которые показывают взаимоотношения между объектами и классами объектов в данном решении.

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

13. Проектирование интерфейса пользователя

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

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

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

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

Таблица 13.1. Элементы графических интерфейсов пользователя

Элементы

Описание

Окна

Позволяют отображать на экране информацию разного рода

Пиктограммы

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

Меню

Ввод команд заменяется выбором команд из меню

Указатели

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

Графические элементы

Могут использоваться совместно с текстовыми

Графические интерфейсы обладают рядом преимуществ:

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

2.  Каждая программа выполняется в своем окне (экране). Можно переключаться из одной программы в другую, не теряя при этом данные, полученные в ходе выполнения программ.

3.  Режим полноэкранного отображения окон дает возможность прямого доступа к любому месту экрана.

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

Рис. 13.1. Процесс проектирования интерфейса пользователя

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

13.1. Принципы проектирования интерфейсов пользователя

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

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

Таблица 13.2. Принципы проектирования интерфейсов пользователя

Принцип

Описание

Учет знаний пользователя

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

Согласованность

Интерфейс должен быть согласованным в том смысле, что однотипные (но различные) операции должны выполняться одним и тем же способом

Минимум неожиданностей

Поведение системы должно быть прогнозируемым

Способность к восстановлению

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

Руководство пользователя

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

Учет разнородности пользователей

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

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

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

В данном случае речь идет о согласованности низкого уровня. И создатели интерфейса всегда должны стремиться к нему. Однако желательна согласованность и более высокого уровня. Например, удобно, когда для всех типов объектов системы поддерживаются одинаковые методы (такие, как печать, копирование и т.п.). Однако полная согласованность невозможна и даже нежелательна. Например, операцию удаления объектов рабочего стола целесообразно реализовать посредством их перетаскивания в корзину. Но в текстовом редакторе такой способ удаления фрагментов текста кажется неестественным.

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

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

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

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

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

Принцип учета разнородности пользователей предполагает, что с системой могут работать разные их типы. Часть пользователей работает с системой нерегулярно, время от времени. Но существует и другой тип– "опытные пользователи", которые работают с приложением каждый день по несколько часов. Случайные пользователи нуждаются в таком интерфейсе, который "руководил" бы их работой с системой, в то время как опытным пользователям требуется интерфейс, который позволил бы им максимально быстро взаимодействовать с системой. Кроме того, поскольку некоторые пользователи могут иметь разные физические недостатки, в интерфейсе должны быть средства, которые помогли бы им перенастроить интерфейс под себя. Это могут быть средства, позволяющие отображать увеличенный текст, замещать звук текстом, создавать кнопки больших размеров и т.п.

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

13.2. Взаимодействие с пользователем

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

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

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

2.  Выбор из меню. Пользователь выбирает команду из списка пунктов меню. Очень часто выбранная команда воздействует только на тот объект, который выделен (выбран) на экране. При таком подходе для удаления файла пользователь сначала выбирает файл, а затем команду на удаление.

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

4.  Командный язык. Пользователь вводит конкретную команду с параметрами, чтобы указать системе, что она должна дальше делать. Чтобы удалить файл, пользователь вводит команду удаления с именем файла в качестве параметра этой команды.

5.  Естественный язык. Пользователь вводит команду на естественном языке. Чтобы удалить файл, пользователь может ввести команду "удалить файл с именем XXX".

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

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

Таблица 13.3. Преимущества и недостатки стилей взаимодействия пользователя с системой

Стиль взаимодействия

Основные преимущества

Основные недостатки

Примеры приложений

Прямое манипулирование

Быстрое и интуитивно понятное взаимодействие.

Легок в изучении

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

Видеоигры; системы автоматического проектирования

Выбор из меню

Сокращение количества ошибок пользователя.

Ввод с клавиатуры минимальный

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

Главным образом системы общего назначения

Заполнение форм

Простой ввод данных.

Легок в изучении

Занимает пространство на экране

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

Командный язык

Мощный и гибкий

Труден в изучении. Сложно предотвратить ошибки ввода

Операционные системы; библиотечные системы

Естественный язык

Подходит неопытным пользователям.

Легко настраивается

Требует большого ручного набора

Системы расписания; системы хранения данных WWW

Пользовательские интерфейсы приложений World Wide Web базируются на средствах, предоставляемых языком HTML (язык разметки Web-страниц) вместе с другими языками, например Java, который связывает программы с компонентами Web-страниц. В основном интерфейсы Web-страниц проектируются для случайных пользователей и представляют собой интерфейсы в виде форм. В Web-приложениях можно создавать интерфейсы, в которых применялся бы стиль прямого манипулирования, однако к моменту написания книги проектирование таких интерфейсов представляло достаточно сложную в аспекте программирования задачу.

В принципе необходимо применять различные стили взаимодействия для управления разными системными объектами. Данный принцип составляет основу модели Сихейма (Seeheim) пользовательских интерфейсов. В этой модели разделяются представление информации, управление диалоговыми средствами и управление приложением. На самом деле такая модель является скорее идеальной, чем практической, однако почти всегда есть возможность разделить интерфейсы для разных классов пользователей (например, начинающих и опытных). На рис. 13.2 изображена подобная модель с разделенными интерфейсом командного языка и графическим интерфейсом, лежащая в основе некоторых операционных систем, в частности Linux.

Рис. 13.2. Множественный интерфейс

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

13.3. Представление информации

В любой интерактивной системе должны быть средства для представления данных пользователям. Данные в системе могут отображаться по-разному: например, вводимая информация может отображаться непосредственно на дисплее (как, скажем, текст в текстовом редакторе) или преобразовываться в графическую форму. Хорошим тоном при проектировании систем считается отделение представления данных от самих данных. До некоторой степени разработка такого ПО противоречит объектно-ориентированному подходу, при котором методы, выполняемые над данными, должны быть определены самими данными. Однако предполагается, что разработчик объектов всегда знает наилучший способ представления данных; хотя это, конечно, не всегда так. Часто определить наилучший способ представления данных конкретного типа довольно трудно, в таком случае объектные структуры не должны быть "жесткими".

После того как представление данных в системе отделено от самих данных, изменения в представлении данных на экране пользователя происходят без изменения самой системы (рис. 13.3).

Рис. 13.3. Представление данных

Подход "модель-представление-контроллер" (МПК), представленный на рис. 13.4, получил первоначальное применение в языке Smalltalk как эффективный способ поддержки различных представлений данных. Пользователь может взаимодействовать с каждым типом представления. Отображаемые данные инкапсулированы в объекты модели. Каждый объект модели может иметь несколько отдельных объектов представлений, где каждое представление – это разные отображения модели. Этот подход был иллюстрирован  в предыдущей главе, где рассматривались объектно-ориентированные структуры приложений.

Рис. 13.4. Модель МПК взаимодействия с пользователем

Каждое представление имеет связанный с ним объект контроллера, который обрабатывает введенные пользователем данные и обеспечивает взаимодействие с устройствами. Такая модель может представить числовые данные, например, в виде диаграмм или таблиц. Модель можно редактировать, изменяя значения в таблице или параметры диаграммы.

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

1.  Что нужно пользователю – точные значения данных или соотношения между значениями?

2.  Насколько быстро будут происходить изменения значений данных? Нужно ли немедленно показывать пользователю изменение значений?

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

4.  Нужно ли пользователю взаимодействовать с отображаемой информацией посредством интерфейса с прямым манипулированием?

5.  Информация должна отображаться в текстовом (описательно) или числовом формате? Важны ли относительные значения элементов данных?

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

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

В качестве примера рассмотрим систему, которая помесячно записывает и подбивает итоги по данным продаж некой компании. На рис. 13.5 видно, что одни и те же данные можно представить в виде текста и в графическом виде.

Рис. 13.5. Альтернативные представления данных

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

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

Непрерывные аналоговые отображения помогают наблюдателю оценить относительные значения данных. На рис. 13.7 числовые значения температуры и давления приблизительно одинаковы. Но при графическом отображении видно, что значение температуры близко к максимальному, в то время как значение давления не достигло даже 25% от максимума. Обычно, кроме текущего значения, наблюдателю требуется знать максимальные (или минимальные) возможные значения. Он должен в уме вычислять относительное состояние считываемых данных. Дополнительное время, необходимое для расчетов, может привести к ошибкам оператора в стрессовых ситуациях, когда возникают проблемы и на дисплее отображаются аномальные данные.

Рис. 13.6. Способы представления динамически изменяющихся числовых данных

Рис. 13.7. Графическое представление данных, показывающее значения по отношению к максимальным

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

Рис. 13.8. Выделение буквенно-цифровых данных

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

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

1.  Отображение метеорологических данных, собранных из разных источников, в виде метеорологических карт с изобарами, воздушными фронтами и т.п.

2.  Графическое отображение состояния телефонной сети в виде связанного множества узлов.

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

4.  Модель молекулы и манипулирование ею в трехмерном пространстве посредством системы виртуальной реальности.

5.  Отображение множества Web-страниц в виде дерева гипертекстовых ссылок.

13.4. Средства поддержки пользователя

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

• сообщения, генерируемые системой в ответ на действия пользователя;

• диалоговая справочная система;

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

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

Таблица 13.4. Факторы проектирования текстовых сообщений

Фактор

Описание

Содержание

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

Опыт пользователя

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

Профессиональный уровень пользователя

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

Стиль сообщений

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

Культура

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

13.5. Оценивание интерфейса

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

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

Таблица 13.5. Показатели удобства использования интерфейса

Показатель

Описание

Изучаемость

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

Скорость работы

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

Устойчивость

Устойчивость системы к ошибкам пользователя

Восстанавливаемость

Способность системы восстанавливаться после ошибок пользователя

Адаптируемость

Способность системы "подстраиваться" к разным стилям работы пользователей

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

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

1.  Анкеты, в которых пользователь дает оценку интерфейсу.

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

3.  Видеонаблюдения типичного использования системы.

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

Анкетирование пользователей – относительно дешевый способ оценки интерфейса. Вопросы должны быть точными, а не общими. Не следует использовать вопросы типа "Пожалуйста, прокомментируйте практичность системы", так как ответы, вероятно, будут существенно различаться. Лучше задавать конкретные вопросы, например: "Оцените понятность сообщений об ошибках по шкале от 1 до 5. Оценка 1 означает полностью понятное сообщение, 5 – малопонятное". На такие вопросы легче ответить и более вероятно получить в результате полезную для улучшения интерфейса информацию.

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

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

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

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

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

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

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

Часть IV. Технологии разработки программного обеспечения

14. Жизненный цикл программного обеспечения: модели и их особенности 

За десятилетия опыта построения программных систем был наработан ряд типичных схем последовательности выполнения работ при проектировании и разработки. Такие схемы получили название моделей ЖЦ.

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

В эту схему работ включают:

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

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

– программирование или рабочее проектирование,

– пробную эксплуатацию,

– сопровождение и улучшение,

– снятие с эксплуатации.

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

При выборе общей схемы модели ЖЦ для конкретной предметной области, решаются вопросы включения или невключения отдельных работ, очень важных для создаваемого вида продукта. На сегодня основой формирования новой модели ЖЦ для конкретной прикладной системы является стандарт ISO/IEC 12207, который включает полный набор процессов (более 40), охватывающий все возможные виды работ и задач, связанных с построением программных систем.

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

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

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

Процессы модели ЖЦ ориентированы на разработчика системы. Он может выполнять один или несколько процессов и процесс может быть выполнен одним или несколькими разработчиками, при этом один из них является ответственным за один процесс или за все на модели, даже если отдельные работы выполняет другой разработчик.

Создаваемая модель ЖЦ увязывается с конкретными методиками разработки систем

соответствующими стандартами в области программной инженерии. Иными словами каждый процесс ЖЦ подкрепляется выбранными для реализации задач средств и методов.

Важную роль при формировании модели ЖЦ имеют организационные аспекты:

– Планирование последовательности работ и сроков их исполнения.

– Подбор и подготовка ресурсов (людских, программных и технических) для выполнения работ.

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

Внедрение модели ЖЦ в практическую деятельность по созданию программного продукта позволяет упорядочить взаимоотношения между субъектами процесса разработки ПС и учитывать динамику модификации требований к проектам и системе.

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

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

Стандарт ГОСТ Р ИСО/МЭК 12207-2010 не предлагает конкретную модель жизненного цикла. Его положения являются общими для любых моделей жизненного цикла, методов и технологий создания ИС. Он описывает структуру процессов жизненного цикла, не конкретизируя, как реализовать или выполнить действия и задачи, включенные в эти процессы. Модель ЖЦ ПО включает в себя:

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

- Результаты выполнения работ на каждой стадии;

- Ключевые события — точки завершения работ и принятия решений.

14.1. Каскадная модель жизненного цикла

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

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

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

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

3.  Кодирование и тестирование программных модулей. На этой стадии архитектура ПО реализуется в виде множества программ или программных модулей. Тестирование каждого модуля включает проверку его соответствия требованиям к данному модулю.

4.  Сборка и тестирование системы. Отдельные программы и программные модули интегрируются и тестируются в виде целостной системы. Проверяется, соответствует ли система своей спецификации.

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

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

Рис. 14.1. Каскадная модель жизненного цикла

При таком подходе необходимо учитывать следующие факторы риска:

– требования недостаточно хорошо представлены;

– система слишком большая по объему, чтобы быть реализованной в целом;

– быстрые изменения в технологии и в требованиях;

– ограниченные ресурсы (людские, программные и др.);

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

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

– все возможности системы реализуются одновременно;

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

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

14.2. Эволюционная модель жизненного цикла

Эта модель основана на следующей идее: разрабатывается первоначальная версия программного продукта, которая передается на испытание пользователям, затем она дорабатывается с учетом мнения пользователей, получается промежуточная версия продукта, которая также проходит "испытание пользователем", снова дорабатывается и так несколько раз, пока не будет получен необходимый программный продукт (рис. 14.2.).

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

Различают два подхода к реализации эволюционного метода разработки.

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

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

Рис. 14.2. Эволюционная модель жизненного цикла

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

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

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

2.  Система часто получается плохо структурированной. Постоянные изменения в требованиях приводят к ошибкам и упущениям в структуре ПО. Со временем внесение изменений в систему становится все более сложным и затратным.

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

Эволюционный подход наиболее приемлем для разработки небольших программных систем (до 100 000 строк кода) и систем среднего размера (до 500 000 строк кода) с относительно коротким сроком жизни. На больших долгоживущих системах слишком заметно проявляются недостатки этого подхода. Для таких систем рекомендуют смешанный подход к созданию ПО. При таком смешанном подходе для прояснения "темных мест" в системной спецификации можно использовать прототипирование. Часть системных компонентов, для которых полностью определены требования, может создаваться на основе каскадной модели. Другие системные компоненты, которые трудно поддаются специфицированию, например пользовательский интерфейс, могут разрабатываться с использованием прототипирования.

14.2.1. Формальная разработка систем

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

Рис. 14.3. Модель формальной разработки ПО

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

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

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

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

Наиболее известным примером метода формальных преобразований является метод "чистой комнаты" (Cleanroom), разработанный компанией IBM. Этот метод предполагает пошаговую разработку ПО, когда на каждом шаге применяется формальные преобразования. Это позволяет отказаться от тестирования отдельных программных модулей, а тестирование всей системы происходит после ее сборки.

14.2.2. Разработка программного обеспечения на основе 

ранее созданных компонентов

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

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

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

1.  Анализ компонентов. Имея спецификацию требований, на этом этапе осуществляется поиск компонентов, которые могли бы удовлетворить сформулированным требованиям.

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

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

4.  Разработка и сборка системы. Это этап непосредственного создания системы. В рамках рассматриваемого подхода сборка системы является скорее частью разработки системы, чем отдельным этапом.

Рис. 14.4. Разработка ПО с повторным использованием

ранее созданных компонентов

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

14.3. Итерационные модели жизненного цикла

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

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

1.  Модель пошаговой разработки, где процессы специфицирования требований, проектирования и написания кода разбиваются на последовательность небольших шагов, которые ведут к созданию ПО.

2.  Спиральная модель разработки, в которой весь процесс создания ПО, от начального эскиза системы до ее конечной реализации, разворачивается по спирали.

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

14.3.1 Модель пошаговой разработки

Модель пошаговой разработки объединяет достоинства каскадной и эволюционной модели. Эта модель (рис. 14.5) была предложена Миллсом (Mills) как попытка уменьшить количество повторно выполняемых работ в процессе создания ПО и увеличить для заказчика временной период окончательного принятия решения обо всех деталях системных требований.

Рис. 14.5. Модель пошаговой разработки

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

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

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

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

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

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

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

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

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

Вместе с тем при реализации пошаговой разработки могут возникнуть определенные проблемы. Компоненты, получаемые на каждом шаге разработки, имеют относительно небольшой размер (обычно не более 20 000 строк кода), но должны реализовать какую-либо системную функцию. Отобразить множество системных требований к компонентам нужного размера довольно сложно. Более того, многие системы должны обладать набором базовых системных свойств, которые реализуются совместно различными частями системы. Поскольку требования детально не определены до тех пор, пока не будут разработаны все компоненты, бывает весьма сложно распределить общесистемные функции по компонентам.

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

14.3.2 Спиральная модель разработки

Спиральная модель - это процесс создания ПО (рис. 14.6) представлена в виде последовательности отдельных процессов с возможной обратной связью между ними, (процесс разработки представлен в виде спирали). Каждый виток спирали соответствует одной стадии (итерации) процесса создания ПО. Так, самый внутренний виток спирали соответствует стадии принятия решения о создании ПО, на следующем витке определяются системные требования, далее следует стадия (виток спирали) проектирования системы и т.д.

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

1.  Определение целей. Определяются цели каждой итерации проекта. Кроме того, устанавливаются ограничения на процесс создания ПО и на сам программный продукт, уточняются планы производства компонентов. Определяются проектные риски (например, риск превышения сроков или риск превышения стоимости проекта). В зависимости от "проявленных" рисков, могут планироваться альтернативные стратегии разработки ПО.

2.  Оценка и разрешение рисков. Для каждого определенного проектного риска проводится его детальный анализ. Планируются мероприятия для уменьшения (разрешения) рисков. Например, если существует риск, что системные требования определены неверно, планируется разработать прототип системы.

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

4.  Планирование. Здесь пересматривается проект и принимается решение о том, начинать ли следующий виток спирали. Если принимается решение о продолжении проекта, разрабатывается план на следующую стадию проекта.

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

Рис. 14.6. Спиральная модель создания ПО

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

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

15. Методологические основы технологий разработки 

программного обеспечения  

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

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

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

- сложности проектируемой системы;

- необходимой полноты ее описания;

- знаний и навыков участников проекта;

-времени, отведенного на проектирование.

Визуальное моделирование оказало большое влияние на развитие технологии создания программного обеспечения вообще и CASE-средств в частности. CASE (Computer Aided Software Engineering) - технология представляет собой совокупность методов проектирования ПО, а также набор инструментальных средств, позволяющих в наглядной форме моделировать предметную область, анализировать эту модель на всех стадиях разработки и сопровождения ПО и разрабатывать приложения в соответствии с информационными потребностями пользователей. Большинство существующих CASE-средств основано на методах структурного или объектно-ориентированного анализа и проектирования, использующих спецификации в виде диаграмм или текстов для описания внешних требований, связей между моделями системы, динамики поведения системы и архитектуры программных средств.

16. Методы структурного анализа и проектирования 

программного обеспечения  

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

- функциональную структуру системы;

- последовательность выполняемых действий;

- передачу информации между функциональными процессами;

- отношения между данными.

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

- функциональная модель SADT (Structured Analysis and Design Technique);

- модель IDEF3;

- DFD (Data Flow Diagrams) - диаграммы потоков данных.

Метод SADT  представляет собой совокупность правил и процедур, предназначенных для построения функциональной модели объекта какой-либо предметной области. Функциональная модель SADT отображает функциональную структуру объекта, т.е. производимые им действия и связи между этими действиями. Метод SADT разработан Дугласом Россом (SoftTech, Inc.) в 1969 г. для моделирования искусственных систем средней сложности. Данный метод успешно использовался в военных, промышленных и коммерческих организациях США для решения широкого круга задач, таких, как долгосрочное и стратегическое планирование, автоматизированное производство и проектирование, разработка ПО для оборонных систем, управление финансами и материально-техническим снабжением и др. Метод SADT поддерживается Министерством обороны США, которое было инициатором разработки семейства стандартов IDEF (Icam DEFinition), являющегося основной частью программы ICAM (интегрированная компьютеризация производства), проводимой по инициативе ВВС США. Метод SADT реализован в одном стандартов этого семейства - IDEF0, который был утвержден в качестве федерального стандарта США в 1993 г., его подробные спецификации можно найти на сайте http://www.idef.com.

Модели SADT (IDEF0) традиционно используются для моделирования организационных систем (бизнес-процессов). Следует отметить, что метод SADT успешно работает только при описании хорошо специфицированных и стандартизованных бизнес-процессов в зарубежных корпорациях, поэтому он и принят в США в качестве типового.

Достоинствами применения моделей SADT для описания бизнес-процессов являются:

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

- жесткие требования метода, обеспечивающих получение моделей стандартного вида;

- соответствие подхода к описанию процессов стандартам ISO 9000.

Метод моделирования IDEF3, являющийся частью семейства стандартов IDEF, был разработан в конце 1980-х годов для закрытого проекта ВВС США. Этот метод предназначен для таких моделей процессов, в которых важно понять последовательность выполнения действий и взаимозависимости между ними. Хотя IDEF3 и не достиг статуса федерального стандарта США, он приобрел широкое распространение среди системных аналитиков как дополнение к методу функционального моделирования IDEF0 (модели IDEF3 могут использоваться для детализации функциональных блоков IDEF0, не имеющих диаграмм декомпозиции). Основой модели IDEF3 служит так называемый сценарий процесса, который выделяет последовательность действий и подпроцессов анализируемой системы.

Диаграммы потоков данных (Data Flow Diagrams - DFD)  представляют собой иерархию функциональных процессов, связанных потоками данных. Цель такого представления - продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами.

Для построения DFD традиционно используются две различные нотации, соответствующие методам Йордона-ДеМарко и Гейна-Сэрсона. Эти нотации незначительно отличаются друг от друга графическим изображением символов. В соответствии с данными методами модель системы определяется как иерархия диаграмм потоков данных, описывающих асинхронный процесс преобразования информации от ее ввода в систему до выдачи потребителю. Практически любой класс систем успешно моделируется при помощи DFD-ориентированных методов. Они с самого начала создавались как средство проектирования информационных систем (тогда как SADT - как средство моделирования систем вообще) и имеют более богатый набор элементов, отражающих специфику таких систем (например, хранилища данных являются прообразами файлов или баз данных, внешние сущности отражают взаимодействие моделируемой системы с внешним миром).

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

Наиболее распространенным средством моделирования данных (предметной области) является модель "сущность-связь" (Entity-Relationship Model - ERМ). Она была впервые введена Питером Ченом в 1976 г. Эта модель традиционно используется в структурном анализе и проектировании, однако, по существу, представляет собой подмножество объектной модели предметной области. Одна из разновидностей модели "сущность-связь" используется в методе IDEF1Х, входящем в семейство стандартов IDEF и реализованном в ряде распространенных CASE-средств (в частности, AllFusion ERwin Data Modeler).

17. Методы объектно-ориентированного анализа и

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

Концептуальной основой объектно-ориентированного анализа и проектирования ПО (ООАП) является объектная модель. Ее основные принципы (абстрагирование, инкапсуляция, модульность и иерархия) и понятия (объект, класс, атрибут, операция, интерфейс и др.)

Большинство современных методов ООАП основаны на использовании языка UML. Унифицированный язык моделирования UML (Unified Modeling Language) представляет собой язык для определения, представления, проектирования и документирования программных систем, организационно-экономических систем, технических систем и других систем различной природы. UML содержит стандартный набор диаграмм и нотаций самых разнообразных видов.

Создание UML фактически началось в конце 1994 г., когда Гради Буч и Джеймс Рамбо начали работу по объединению их методов Booch и OMT (Object Modeling Technique) под эгидой компании Rational Software. К концу 1995 г. они создали первую спецификацию объединенного метода, названного ими Unified Method, версия 0.8. Тогда же в 1995 г. к ним присоединился создатель метода OOSE (Object-Oriented Software Engineering) И. Якобсон. Таким образом, UML является прямым объединением и унификацией методов Буча, Рамбо и Якобсона, однако дополняет их новыми возможностями.

Главными в разработке UML были следующие цели:

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

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

- обеспечить независимость от конкретных языков программирования и процессов разработки.

- обеспечить формальную основу для понимания этого языка моделирования (язык должен быть одновременно точным и доступным для понимания, без лишнего формализма);

- стимулировать рост рынка объектно-ориентированных инструментальных средств;

- интегрировать лучший практический опыт.

UML находится в процессе стандартизации, проводимом OMG (Object Management Group) - организацией по стандартизации в области объектно-ориентированных методов и технологий, в настоящее время принят в качестве стандартного языка моделирования и получил широкую поддержку в индустрии ПО. UML принят на вооружение практически всеми крупнейшими компаниями - производителями ПО (Microsoft, Oracle, IBM, Hewlett-Packard, Sybase и др.). Кроме того, практически все мировые производители CASE-средств, помимо IBM Rational Software, поддерживают UML в своих продуктах (Oracle Designer, Together Control Center (Borland), AllFusion Component Modeler (Computer Associates), Microsoft Visual Modeler и др.).

Стандарт UML версии 1.1, принятый OMG в 1997 г., содержит следующий набор диаграмм:

1. Структурные (structural) модели:

- диаграммы классов (class diagrams) - для моделирования статической структуры классов системы и связей между ними;

- диаграммы компонентов (component diagrams) - для моделирования иерархии компонентов (подсистем) системы;

- диаграммы развертывания (deployment diagrams) - для моделирования физической архитектуры системы.

2. Модели поведения (behavioral):

- диаграммы вариантов использования (use case diagrams) - для моделирования функциональных требований к системе (в виде сценариев взаимодействия пользователей с системой);

- диаграммы взаимодействия (interaction diagrams):

- диаграммы последовательности (sequence diagrams) и диаграммы кооперации  (collaboration diagrams) - для моделирования процесса обмена сообщениями между объектами;

- диаграммы состояний (statechart diagrams) - для моделирования поведения объектов системы при переходе из одного состояния в другое;

- диаграммы деятельности (activity diagrams) - для моделирования поведения системы в рамках различных вариантов использования, или потоков управления.

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

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

Диаграмма вариантов использования является самым общим представлением функциональных требований к системе. Для последующего проектирования системы требуются более конкретные детали, которые описываются в документе, называемом "сценарием варианта использования" или "потоком событий" (flow of events). Сценарий подробно документирует процесс взаимодействия действующего лица с системой, реализуемого в рамках варианта использования. Основной поток событий описывает нормальный ход событий (при отсутствии ошибок). Альтернативные потоки описывают отклонения от нормального хода событий (ошибочные ситуации) и их обработку.

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

- определяет пользователей и границы системы;

- определяет системный интерфейс;

- удобна для общения пользователей с разработчиками;

- используется для написания тестов;

- является основой для написания пользовательской документации;

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

Диаграммы взаимодействия описывают поведение взаимодействующих групп объектов (в рамках варианта использования или некоторой операции класса). Как правило, диаграмма взаимодействия охватывает поведение объектов в рамках только одного потока событий варианта использования. На такой диаграмме отображается ряд объектов и те сообщения, которыми они обмениваются между собой. Существует два вида диаграмм взаимодействия: диаграммы последовательности и кооперативные диаграммы.

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

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

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

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

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

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

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

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

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

Диаграмма развертывания показывает физическое расположение сети и местонахождение в ней различных компонентов. Ее основными элементами являются узел (вычислительный ресурс) и соединение - канал взаимодействия узлов (сеть).

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

UML обладает механизмами расширения, предназначенными для того, чтобы разработчики могли адаптировать язык моделирования к своим конкретным нуждам, не меняя при этом его метамодель. Наличие механизмов расширения принципиально отличает UML от таких средств моделирования, как IDEF0, IDEF1X, IDEF3, DFD и ERM. Перечисленные языки моделирования можно определить как сильно типизированные (по аналогии с языками программирования), поскольку они не допускают произвольной интерпретации семантики элементов моделей. UML, допуская такую интерпретацию (в основном за счет стереотипов), является слабо типизированным языком.

К его механизмам расширения относятся:

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

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

- Ограничения (это семантическое ограничение, имеющее вид текстового выражения на естественном или формальном языке (OCL - Object Constraint Language), которое невозможно выразить с помощью нотации UML).

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

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

Буч отметил также ряд следующих преимуществ ООП:

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

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

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

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

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

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

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

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

Другой формой проявления взаимосвязи можно считать интеграцию объектной и реляционной технологий. Реляционные СУБД (система управления базами данных) являются на сегодняшний день основным средством реализации крупномасштабных баз данных и хранилищ данных. Причины этого достаточно очевидны: реляционная технология используется достаточно долго, освоена огромным количеством пользователей и разработчиков, стала промышленным стандартом, в нее вложены значительные средства и создано множество корпоративных БД в самых различных отраслях, реляционная модель проста и имеет строгое математическое основание; существует большое разнообразие промышленных средств проектирования, реализации и эксплуатации реляционных БД. Вследствие этого реляционные БД в основном используются для хранения и поиска объектов в так называемых объектно-реляционных системах.

Часть V. Письменная коммуникация. Документирование проекта Программного обеспечения  

18. Документирование этапов разработки 

программного обеспечения  

Когда программист-разработчик получает в той или иной форме задание на программирование, перед ним, перед руководителем проекта и перед всей проектной группой встают вопросы: что должно быть сделано, кроме собственно программы? что и как должно быть оформлено в виде документации? что передавать пользователям, а что — службе сопровождения? как управлять всем этим процессом? Кроме упомянутых вопросов есть и другие, например, что должно входить в само задание на программирование?

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

Документирование программного обеспечения включает в себя:

- Техническое задание.

- Внешние и внутренние языки спецификации.

- Руководство пользователя.

- Руководство программиста.

 

Техническое задание

  

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

 

Техническое задание на разработку ПО должно включать следующие разделы:

- введение;

- основания для разработки;

- назначение разработки;

- требования к программе;

- требования к программной документации;

- технико-экономические показатели;

- стадии и этапы разработки;

- порядок контроля и приемки;

-приложения.

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

В разделе “Введение” указывается наименование, краткая характеристика области применения ПО.

В разделе “Основания для разработки” указывается:

- документ (документы), на основание которых ведется разработка;

- организация, утвердившая документ, и дата утверждения;

- наименование (условное обозначение) темы разработки.

 В разделе “Назначение разработки” должно быть указано функциональное и эксплуатационное назначение ПО. Например, UML – как универсальный язык моделирования. Может использоваться и для постановки технического задания.

 

Внешние и внутренние языки спецификации

  

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

- Соглашение о требованиях;

- Внешняя спецификация;

- Внутренняя спецификация.

 

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

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

 

Ниже приведена общая структура документа “Внешняя спецификация”, с развернутыми комментариями в тех пунктах, которые касаются технической стороны дела

1. ОПИСАНИЕ ПРОГРАММНОГО ИЗДЕЛИЯ

1.1. Наименование и шифры ПО (полное наименование, сокращенные наименования, шифры ПО и проекта).

1.2. Краткое описание ПО (включая сведения об авторском праве, иерархию документов, с указанием документов вышестоящих уровней).

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

2. ЦЕЛИ

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

3. СТРАТЕГИЯ

3.1. Соглашения относительно представления материала.

3.1.1. Обозначения (определяются все обозначения, используемые в требованиях: например, если применяются индексы, то дается пример их использования и определяется принцип индексации).

3.1.2. Терминология (особенно специфическая для данного изделия).

3.1.3. Синтаксис (приводятся, если необходимо, синтаксические правила для дальнейшего описания требований).

3.2. Генерируемое программное обеспечение (классифицируется как вспомогательное и порождаемое описываемым изделием).

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

Примечание. Причина такой расстановки пунктов состоит в том, что при правильном проектировании сверху вниз генерируемое программное обеспечение является основной целью проектирования и должно быть описано раньше, чем его генератор. Другими словами, структура генерируемых программ должна определять структуру генератора, а не наоборот. Если все ПО является основным, то в п.3.2. делается пометка не используется и опускаются все его подпункты. Структура подпунктов п.п. 3.2 и 3.3 полностью дублируется и далее для простоты используется нумерация только п.п. 3.3.

3.3.n. Общие характеристики функции n. Если технически затруднительно и неестественно рассматривать ПО как один большой функциональный модуль, то следует привести его функциональную декомпозицию, показав связи между функциями (функциональными модулями) и присвоив каждой функции некоторое уникальное имя n. Затем для каждой функции отводится подраздел раздела 3.3 (т.е. 3.3.1, 3.3.2 и т.д.), в заглавии которого используется слово функция с последующим именем функционального модуля. Такая функциональная декомпозиция не указывает, как именно ПО будет фактически разбито на программные модули (это составляет содержание документа Внутренняя спецификация). Для удобства работы, конечно, полезно иметь некоторое соответствие функционального и фактического разбиения, но это не является требованием и не должно уводить с правильного пути проектирования изделия.

3.3.n.1. Внешние ограничения.

3.3.n.1.1. Стандарты (список используемых промышленных стандартов и собственных стандартов предприятия).

3.3.n.1.2. Ограничения на совместимость. Необходимо рассматривать несколько аспектов совместимости:

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

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

- изделиями-компаньонами (т.е. относящимися к той же группе средств и являющимися альтернативой);

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

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

3.3.n.1.4. Аппаратные ограничения. Приводится перечень устройств, необходимых для работы ПО (с указанием минимальной, оптимальной и максимальной конфигурации). Указываются все действующие ограничения на оборудование, например, физические характеристики терминала или требование запрещения использования звукового сигнального устройства.

3.3.n.2. Внешние характеристики.

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

3.3.n.2.1. Результаты. Описываются все выходные данные ПО с точки зрения их функционального содержания и назначения (например, файлы, сообщения, программно устанавливаемые сигналы и прерывания). При этом должны быть рассмотрены все возможные в системе носители и средства отображения информации. Указываются тип, структура, формат, объем, расположение и диапазон изменения. Для всех выходных данных, читаемых людьми (сообщения и отчеты) должны быть приведены образцы.

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

3.3.n.2.3. Входы. Описание подобно п. 3.3.2.1

3.3.n.3. Эргономические характеристики.

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

В разделе “Надежность” (это свойство программы понимается здесь как способность к восстановлению нормальной работы при ошибках и сбоях в работе оборудования) рассматриваются следующие вопросы:

- защита данных пользователя;

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

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

3.3.n.4. Внутренние характеристики (этот раздел полностью расширяется в документе “Внутренняя Спецификация”, однако частично может быть заполнен с целью полного описания соответствующих внешних свойств).

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

4. ИСПОЛЬЗУЕМЫЕ МАТЕРИАЛЫ (в т.ч. справочные)

5. ПЕРЕДАЧА ЗАКАЗЧИКУ И ВВОД В ДЕЙСТВИЕ

 

Руководство пользователя

 

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

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

В связи с этим следует различать две категории пользователей: ординарных пользователей программы и администраторов. Ординарный пользователь программы (end-user) использует программу для решения своих задач (в своей предметной области). Это может быть инженер, проектирующий техническое устройство, или кассир, продающий железнодорожные билеты с помощью данной программы. Он может и не знать многих деталей работы компьютера или принципов программирования. Администратор программны (system administrator) управляет использованием программы ординарными пользователями и осуществляет сопровождение программного средства, не связанное с модификацией программ. Например, он может регулировать права доступа к программе между ординарными пользователями, поддерживать связь с поставщиками программы или выполнять определенные действия, чтобы поддерживать программу в рабочем состоянии, если оно включено как часть в другую систему.

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