Редактор UML action диаграмм

1. ВОЛГОГРАДСКИЙ ГОСУДАРСТВЕННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ КУРСОВОЙ ПРОЕКТ Редактор UML action диаграмм Исполнители: Гусев А.П. [Главный программист] Шатеев И.В. [Архитектор] Меркулов А.А. [Прожект-менеджер] (ИВТ-461)

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

3. Распределение ролей

4. Функциональные требования Главная функция • Создание UMLaction диаграммы Основные функции • Сохранение action диаграммы в файл • Загрузка action диаграммы из файла • Редактирование диаграммы: добавление, удаление, перемещение элементов диаграммы • Редактирование свойств компонентов • Экспорт диаграммы в картинку (формата jpg)

5. Нефункциональные требования • Собственный формат файла для хранения сцены диаграммы • Установщик, позволяющий запуск программы на «чистой» ОС • Редактор должен работать под управлением ОС Windows XP и выше • Сроки: I-й релиз - 02.11.11, II-й релиз - 10.12.11; • Адекватный интерфейс • Технология разработки – объектно-ориентированная • Безотказность системы при неадекватных действиях адекватного пользователя

6. Выбор технологии Разработка ведется на языке высокого уровня С++ в среде Visual Studio 2008. Используется платформа .NET. Выбор языка и платформы обусловлен: • Легкостью разработки, • Малой требовательностью, • Отказоустойчивостью, • Нехваткой времени для проведения углубленного анализа. Средства командной разработки: Mercurial Для согласованности работы используется репозиторий (code.google.com). Тестирование проводятся вручную по заданиям на тестирование. Средства коммуникации: Skype, Qip.

7. Основные решения при разработке Составление плана работ. В организационной части важным пунктом было составление плана работ. Он оформлялся в виде таблицы с задачами, сроками и исполнителями выполнения. Разработка структуры программы. Для разработки была спроектирована структура программного продукта в виде UML диаграмм.

8. Проектные решения:use-case диаграмма

9. Проектные решения:диаграмма классов

10. Интерфейс программы

11. Тестирование Тестирование проводилось тремя способами: 1. Общее тестирование после очередного обновления. 2. Тестирование по заданиям. Составлялись задания на тестирование. Тестирование мог выполнить любой участник команды. 3. Тестирование сторонними лицами. Редактор тестировался участниками других команд. Результаты Результаты тестирования заносились в репозиторий.

12. Внедрение • Установка • Редактор был установлен на несколько машин, в том числе и с чистой ОС Windows. • Проверка • Была произведена проверка на: • Надежность • Проводились тесты на полный цикл программы и на отдельные функции. Дефекты не обнаружены. • Функциональность • Функционал программы соответствуетзаявленному в документации (для I-го релиза). • Удобство • Есть недостатки из-за некоторых ограничений (описанных в документации) • Эффективность • В редакторе можно быстро создать диаграмму классов, но с некоторыми ограничениями (обусловленными заданием и рамками ограничений проекта)

13. Вклад в командную разработку Гусев А.П. Разработка программного продукта, основного функционала. Шатеев И.В. Разработка и тестирование интерфейса программного продукта. Меркулов А.А. Разработка документации тестирование программного продукта.

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

15. Перспективы расширения программного продукта • На следующий релиз планируется расширить функционал программы: • Масштабирование рабочей области • Операция "копирование« • Операция "вставить« • Динамическое изменение размеров элементов диаграммы • Также планируется повысить информативность интерфейса, улучшить дизайн. • По мере возможности также могут быть реализованы следующие дополнения: • Отмена и повтор действия

16. Общий план работ Основные решения при разработке

17. Общий план работ Основные решения при разработке

18. Общий план работ Основные решения при разработке