Технологии командной разработки программного обеспечения информационных систем

Моделирование функциональности и классов приложения

Показывать лекцию целиком

Продолжительность лабораторной работы - 2 академических часа.

Создание проекта моделирования программного приложения

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

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

Вначале создадим пустое приведено окно создания проекта.

(рис 12.1) Создание пустого решения Visual Studio

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

(рис 12.2) Диалоговое окно Добавление решения в систему управления версиями

В созданное решение ).

(рис 12.3) Добавление проекта моделирования

В обозревателе решений будет добавлен проект моделирования ).

(рис 12.4) Представление проекта моделирования в обозревателе решений

Инструментальные средства Visual Studio включают шаблоны для создания следующих UML-диаграмм:

  • Схема классов UML;
  • Схема последовательностей UML;
  • Схема вариантов использования UML;
  • Схема активности UML;
  • Схема компонентов UML;
  • Схема слоев.
    •

    Разработка схемы вариантов использования

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

    (рис 12.5) Добавление Схемы вариантов использования UML

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

    (рис 12.6) Дизайнер построения схемы вариантов использования

    Дизайнер построения схемы вариантов использования имеет набор элементов для создания схемы:

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

    Для разрабатываемого программного продукта в учебном проекте определены три субъекта:

  • методист учебного отдела;
  • методист факультета;
  • методист кафедры.
    •

    Функциональность проектируемой системы задана следующими пользовательскими требованиями, определенными в рабочем элементе Невыполненная работа по продукту:

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

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

    (рис 12.7) Схема вариантов использования проектируемой системы

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

    (рис 12.8) Диалоговое окно Связь с рабочими элементами

    При связывании с рабочими элементами на схеме рядом с вариантами использования появляются значки (рис 12.9).

    (рис 12.9) Схема вариантов использования со связями с рабочими элементами

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

    (рис 12.10) Рабочий элемент со ссылкой на модель

    Разработка схемы классов

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

    (рис 12.11) Добавление схемы классов UML

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

    (рис 12.12) Панель инструментов для построения схемы классов

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

  • Университет;
  • Факультет;
  • Кафедра;
  • Преподаватель;
  • Учебная нагрузка кафедры;
  • Учебная нагрузка преподавателя;
  • Учебный рабочий план направления подготовки;
  • Студенческая группа;
  • Нормы времени для расчета объема учебной работы.
    •

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

    (рис 12.13) Схема классов проектируемой системы

    Проект моделирования создавался в локальной папке. В обозревателе решений проект и созданные схемы помечены знаком , что отмечает не сохраненные в базе данных TFS элементы решений (рис 12.14).

    (рис 12.14) Схема классов проектируемой системы

    Для сохранения в базе данных TFS элементов решений необходимо щелкнуть правой кнопкой мыши на строке решения и из выпадающего меню выбрать пункт ).

    (рис 12.15) Диалоговое окно подтверждения сохранения элементов решения

    После подготовки возврата изменений в базу данных сервера TFS в командном обозревателе на вкладке ).

    (рис 12.16) Вкладка Ожидающие изменения командного обозревателя

    При выполнении возврата изменений выводится сообщение об успешно выполненной операции (рис 12.17).

    (рис 12.17) Сообщение об успешном возвращении изменений

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

    Задание

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