Учебное пособие 1877
.pdfФГБОУ ВПО «Воронежский государственный технический университет»
Э.И. Воробьёв
ИСПОЛЬЗОВАНИЕ UML И ТЕХНОЛОГИИ
COM ПРИ РАЗРАБОТКЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Утверждено Редакционно-издательским советом университета в качестве учебного пособия
Воронеж 2014
УДК 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