BC/NW 2009; №2 (15):3.2
МЕТОДИКА
ПРОЕКТИРОВАНИЯ НЕБОЛЬШИХ ПРОГРАММНЫХ ПРОДУКТОВ НА ОСНОВЕ ЯЗЫКА UML
Тихомирова Т.В.
(ГОУВПО
"Московский энергетический институт (технический университет)",
Россия)
ВВЕДЕНИЕ
Центральным элементом деятельности, ведущей к созданию первоклассного программного обеспечения, является моделирование. Модели позволяют нам наглядно продемонстрировать желаемую структуру и поведение системы. Они также необходимы для визуализации и управления ее архитектурой. Модели помогают добиться лучшего понимания создаваемой нами системы, что зачастую приводит к ее упрощению и возможности повторного использования. Наконец, модели нужны для минимизации риска.
Большая
часть существующих рекомендаций и методов проектирования программных продуктов
относится к сложным системам. Для разработки небольших программных продуктов
или самостоятельных частей сложных систем, которые программист способен
реализовать в одиночку, проектирование в подавляющем большинстве случаев не
применяется или применяется в зачаточной форме и неформальном виде. Целью
данной работы является показать, что и для небольших проектов, построенных по
объектно-ориентированной методологии, необходимо использовать упрощенный набор
диаграмм UML при разработке, что сильно
упрощает рабочие процессы и внесение изменений в проект.
ПОСТАНОВКА
ЗАДАЧИ
В
качестве демонстрационных примеров целесообразно выбрать наиболее часто
встречающиеся задачи. Для небольших проектов такими являются:
1.
Проект, реализующий обработку однотипных данных (база данных);
2.
Проект, реализующий некие математические алгоритмы;
3.
Проект, основной частью которого является диалог с
пользователем;
На
практике эти три класса задач могут комбинироваться различным образом.
Например, реализация пользовательского интерфейса входит и в базу данных, и в
алгоритмический проект, так как никакая задача не может решаться самостоятельно
без хотя бы простейшего диалога с пользователем.
В
качестве демонстрационных проектов были выбраны:
1.
Проект Cerebra – ПО для создания и поддержки базы данных товаров для
автоматизации работы составителя каталогов.
2.
Проект TextMining - ПО
для исследовательской работы в области классификации
текстовых документов.
ОСНОВНЫЕ
CASE-СРЕДСТВА
Для
проектирования и реализации демонстрационных проектов будут использоваться
следующие программные средства:
·
IBM Rational Rose
или Borland UML Modeler, входящий в состав BDS
2006 для моделирования верхнего уровня;
·
Borland ECO III,
входящий в состав BDS
2006 для проектирования и реализации базы данных;
·
Borland Developer Studio 2006 (Delphi 2007) для кодирования проектов.
МЕТОДИКА ПРОЕКТИРОВАНИЯ БАЗЫ ДАННЫХ
1.
Получение технического задания от заказчика (или составление
технического задания вместе с заказчиком);
2.
Разработка диаграммы вариантов использования и, при
необходимости, сценариев (диаграмм деятельности) на IBM Rational Rose:
2.1.
Выявление основных
актеров и функций (вариантов использования) системы;
2.2.
Структурирование
вариантов использования;
2.3.
Определение связей
актеров и вариантов использования;
2.4.
Построение диаграммы
вариантов использования;
2.5.
Дополнение наиболее
нетривиальных вариантов использования сценариями или диаграммами деятельности;
3. Разработка прототипа программного продукта на Borland Developer Studio 2006 (Чаще всего это набор визуальных форм проекта с основными визуальными компонентами (кнопки и поля ввода). Никакой функциональной наполненности прототипа не требуется. Строится для того, чтобы заказчик понял, что (не как!) будет делать конечный продукт.)
4.
Утверждение прототипа у заказчика (В случае недовольства
прототипом следует пересмотреть функциональную
наполненность системы, т. е. вернуться к п.2, а в случае крупных несоответствий
– к п. 1)
5.
Составление концептуальной модели предметной области
на IBM Rational Rose (Возможно вместе с заказчиком. Включает в себя разработку
контекстной диаграммы классов, которая в данном случае может быть похожа на
логическую модель базы данных в ER-нотации
(возможно во второй нормальной форме)
6.
Разработка схемы базы данных на Borland ECO III
(Используется концептуальная модель предметной области.)
6.1.
Выявление объектов хранения и их атрибутов
6.2.
Специфицирование связей между объектами: обобщение,
ассоциация, определение кратности концов ассоциаций
6.3.
Специфицирование ограничений на атрибуты объектов –
используется встроенный в BDS
2006 редактор OCL-выражений.
6.4.
Специфицирование методов обработки объектов.
6.5.
Если возможно, написание методов и формул для вычисляемых
полей на языке объектных ограничений OCL.
7.
Разработка визуальных форм для корректного ввода,
редактирования и удаления данных. (Используется WinForms для Delphi.NET в Borland Developer Studio 2006. Для этих
компонентов реализована связь с объектным пространством ECO, следовательно,
программирование тривиальных операций над данными сводится к настройке
компонентов DataGrid, кнопок, меню и дескрипторов ECO (ExpressionHandle, CurrencyManagerHandle и др.)
8.
При необходимости – разработка вспомогательной
диаграммы классов (Для реализации вариантов использования, связанных с базой
данных косвенно, например формирование отчетов. Эти
классы должны располагаться в пространстве имен, отличном от объектного
пространства ECO.)
9.
Уточнение диаграммы классов (Эти диаграммы строятся
для каждого из реализуемых вариантов использования. Для
построения диаграмм используется Borland UML Modeler,
встроенный в BDS 2006.)
9.1.
Построение диаграмм последовательности
9.2.
Построение диаграмм деятельности.
10.
Написание кода проекта
10.1.
Проектирование визуальных форм проекта (с учетом требований к
интерфейсу и прототипа проекта)
10.2.
Автоматическая генерация кода
10.3.
Завершение написания кода программы вручную или с помощью
дополнительных диаграмм деятельности и последовательности
11.
Тестирование проекта (Тестирование проводится встроенными
средствами BDS 2006.)
11.1.
Тестирование отдельных функций проекта (по вариантам
использования)
11.2.
Комплексное тестирование (часто проводится вместе с
заказчиком)
МЕТОДИКА ПРОЕКТИРОВАНИЯ АЛГОРИТМИЧЕСКОЙ ЗАДАЧИ
1.
Получение технического задания от заказчика (или составление
технического задания вместе с заказчиком).
2.
Разработка диаграммы вариантов использования и, при
необходимости, сценариев (диаграмм деятельности) на IBM Rational Rose.
1.1.
Выявление основных актеров и функций (вариантов
использования) системы;
1.2.
Структурирование вариантов использования;
1.3.
Определение связей актеров и вариантов использования;
1.4.
Построение диаграммы вариантов использования;
1.5.
Дополнение наиболее нетривиальных вариантов использования
сценариями или диаграммами деятельности;
1.6.
Специфицирование алгоритмов, используемых в проекте.
2.
Разработка прототипа программного продукта на Borland Developer Studio 2006. Чаще всего это набор
визуальных форм проекта с основными визуальными компонентами (кнопки и поля
ввода). Никакой функциональной наполненности прототипа
не требуется. Строится для того, чтобы заказчик понял, что (не как!) будет
делать конечный продукт.
3.
Утверждение прототипа у заказчика. В случае недовольства
прототипом следует пересмотреть функциональную
наполненность системы, т.е. вернуться к п.2, в случае крупных несоответствий –
к п.1.
4.
Составление концептуальной модели предметной области на IBM Rational Rose (Возможно вместе с
заказчиком).
5.
Разработка схем алгоритмов. Алгоритмы проектируются в общем
виде на IBM Rational Rose (диаграммы деятельности).
6.
Разработка диаграммы классов проекта:
6.1.
Специфицирование основных классов проекта и их отношений –
обобщение, ассоциация;
6.2.
Уточнение диаграммы классов с помощью построения диаграмм
последовательности, кооперации, деятельности;
6.3.
Разработка собственно методов и полей классов;
6.4.
Разработка диаграмм последовательности, кооперации,
деятельности, реализующих алгоритмы (если они еще не были построены в п.7.2);
6.5.
Верификация диаграммы классов.
Для
построения диаграмм используется Borland UML Modeler, встроенный в BDS 2006.
7.
Написание кода проекта:
7.1.
Проектирование визуальных форм проекта (с учетом требований к
интерфейсу и прототипа проекта);
7.2.
Автоматическая генерация кода;
7.3.
Завершение написания кода программы вручную или с помощью
дополнительных диаграмм деятельности и последовательности;
8.
Тестирование проекта:
8.1.
Тестирование отдельных функций проекта (по вариантам
использования);
8.2.
Комплексное тестирование (часто проводится вместе с
заказчиком);
Тестирование
проводится встроенными средствами BDS
2006.
ЗАКЛЮЧЕНИЕ
В процессе работы были изучены основные методики анализа предметной области, определения требований к программному продукту, проектирования сложных программных продуктов, а также наиболее популярные CASE-средства, реализующие эти методики. В процессе изучения выяснилось, что для небольших программных продуктов эти методологии не подходят или подходят в крайне ограниченном варианте, слепое следование большинству методов при разработке небольшого проекта приводят к выполнению бесполезной работы и запутыванию проектной документации. Выбраны наиболее популярные и универсальные CASE-средства, пригодные для разработки небольших проектов:
1.
IBM Rational Rose
как мощное средство анализа и проектирования на начальных этапах разработки
проекта:
2.
Borland Developer Studio 2006 для проектирования, реализации и тестирования проекта: Borland Together – для построения диаграмм этапа проектирования
3.
Borland ECO III – для разработки баз данных.
Выбраны
и реализованы 2 практические задачи: Cerebra и TextMining. На их основе составлены
методы проектирования и разработки базы данных и алгоритмического проекта. При
наличии практической задачи – комбинации этих двух классов можно легко
использовать эти методы вместе.
Описаны
основные диаграммы и методики, которые можно применять для разработки небольших
проектов.
Литература
1. Буч Г., Дж. Румбах, А. Джекобсон Язык UML. Руководство пользователя. М.: ДМК Пресс, 2004. 432 с.
2. Thomas A. Bruce "Designing
Quality Databases with IDEF1X Information Models".
3. Леоненков А. Самоучитель UML. СПб.: БХВ-Петербург. 2004г.
4. Дин Леффингуэлл, Дон Уидриг. Принципы работы с требованиями к программному обеспечению. Унифицированный подход. Williams, 2002г.
5. http://standards.ieee.org, IEEE Std 830-1998
IEEE Recommended Practice for Software Requirements Specifications –Description
6. J. Rumbaugh,
7. www.omg.org – Object Management
Group