2920

УДК 681.3

Воробьев Э.И. Использование UML и технологии COM при разработке программного обеспечения: учеб. пособие [Электронный ресурс]. – Электрон. текстовые и граф. данные (2,48 Мб) / Э.И. Воробьев. - Воронеж: ФГБОУ ВПО «Воронежский государственный технический университет», 2014. – 1 электрон. опт. диск (CD-ROM): цв. – Систем.

требования: ПК 500 и выше; 256 Мб ОЗУ; Windows XP; SVGA с разрешением 1024x768; Adobe Acrobat; CD-ROM дисковод;

мышь. – Загл. с экрана. – Диск и сопровод. материал помещены в контейнер 12х14 см.

В учебном пособии рассматриваются теоретические и практические сведения для изучения основных возможностей применения UML, Rational Rose и COM при проектировании и разработке ПО, а также приведен лабораторный практикум.

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

Табл. 6. Ил. 89. Библиогр.: 8 назв.

Научный редактор д-р техн. наук, проф. Я.Е. Львович Рецензенты: кафедра инфокоммуникационных систем

и технологий Воронежского института МВД России (зав. кафедрой д-р техн. наук, проф. О.И. Бокова); д-р техн. наук, проф. О.Ю. Макаров

©Воробьев Э.И., 2014

©Оформление. ФГБОУ ВПО

«Воронежский государственный технический университет», 2014

ВВЕДЕНИЕ

Проектирование программного обеспечения — процесс создания проекта программного обеспечения (ПО), а также

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

Первоначально программа рассматривается как чёрный ящик. Ход процесса проектирования и его результаты зависят не только от состава требований, но и выбранной модели процесса, опыта проектировщика. Модель предметной области накладывает ограничения на бизнес-логику и структуры данных.

В зависимости от класса создаваемого ПО, процесс проектирования может обеспечиваться как «ручным» проектированием, так и различными средствами его автоматизации. В процессе проектирования ПО для выражения его характеристик используются различные нотации — блоксхемы, ER-диаграммы, UML-диаграммы, DFD-диаграммы, а также макеты.

Проектированию обычно подлежат: Архитектура ПО; Устройство компонентов ПО; Пользовательские интерфейсы.

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

Для проектирования программного обеспечения применяются различные CASE -средства.

3

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

Типичными CASE инструментами являются:

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

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

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

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

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

инструменты рефакторинга кода;

генераторы кода;

инструменты для построения UML-диаграмм.

Примеры CASE – программ: Umbrello, Dia, Rational

Software, ERwin.

В данном учебном пособии подробно рассмотрены средства проектирования RationalSoftware и IDL.

4

1. ОБЩИЕ СВЕДЕНИЯ О РАЗРАБОТКЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

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

математики, инженерии и других областей знания.

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

Разработка программного обеспечения может быть разделена на несколько разделов. Это:

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

Проектирование программного обеспечения:

Обеспечения (CASE) и стандарты формата описаний, такие как Унифицированный Язык Моделирования (UML), использую различные подходы: проблемно-ориентированное проектирование и т.д..

Инженерия программного обеспечения: создание программного обеспечения с помощью языков программирования.

Тестирование программного обеспечения: поиск и исправление ошибок в программе.

5

Обслуживание программного обеспечения: программные системы часто имеют проблемы совместимости

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

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

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

Процесс разработки программного обеспечения: процесс построения программного обеспечения горячо обсуждается среди практиков, основными парадигмами считаются agile или waterfall.

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

Качество программного обеспечения: методика оценки критериев качества программного продукта и требований к надёжности.

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

1.1. Проблемы, возникающие при разработке ПО

Наиболее распространёнными проблемами, возникающими в процессе разработки ПО, считаются:

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

6

программный продукт и оценить степень его завершенности. Без жесткого руководства проектом разработка ПО будет завершена на 90% при условии использования отведенного времени на 90%. Политика Управления Конфигурациями (УК) и Управления Изменениями (УИ), определение модели менеджмента конфигурации ПО при разработке продукта – все элементы конфигурации, компоненты и подкомпоненты мгновенно становятся видимыми для версий и релизов.

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

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

7

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

Недостаток мониторинга – без трассировки и «прозрачности» сложно осуществить мониторинг программных проектов. Руководство не может принять компетентные решения, поэтому графики продолжают срываться, а затраты продолжают превышать установленный бюджет. Невозможно выполнить мониторинг проекта, если у менеджера проекта нет инструментальных средств чтобы следить за фактической разработкой продукта в пределах проекта. В ходе осуществления процесса УК и УИ реализуется обеспечение инструментальными средствами, которые позволяют осуществить разносторонний мониторинг процесса. При наличии УК и УИ, трассировки и «прозрачности», мониторинг программных проектов становится простой частью общей задачи управления проектом. С помощью мониторинга, доступного благодаря инструментальным средствам УК и УИ и возможностям CCB*, менеджеры проектов принимают взвешенные решения, не выбиваясь из графика работ и не превышая бюджет.

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

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

8

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

Множественность версий – совершенствование базового продукта приводит к выпуску дополнительных версий с самыми последними изменениями. Несмотря на наличие последней модернизированной версии программного продукта, часть пользователей продолжает работать с более ранней версией. Продукт УК и УИ позволяет контролировать все версии. Если в программе обнаружены ошибки, то изменения необходимо сделать во всех версиях. Как только в продукте появляются новые свойства, они должны быть доступны для всех пользователей независимо от времени выпуска версии продукта.

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

9

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

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

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

10