Техническое задание. Наименование и область применения

1. Структура домашнего задания

2. ТЕХНИЧЕСКОЕ ЗАДАНИЕ

1.
2.
3.
4.
5.
6.
7.
ТЕХНИЧЕСКОЕ ЗАДАНИЕ
В разделе "Наименование и область применения" указывают наименование, краткую характеристику
области применения программы или программного изделия и объекта, в котором используют программу
или программное изделие.
В разделе "Основание для разработки" должны быть указаны: документ (документы), на основании
которых ведется разработка; организация, утвердившая этот документ, и дата его утверждения;
наименование и (или) условное обозначение темы разработки.
В разделе " Назначение разработки" должно быть указано функциональное и эксплуатационное
назначение программы или программного изделия.
Раздел "Технические требования к программе или программному изделию" должен содержать
следующие подразделы:
требования к функциональным характеристикам; состав выполняемых функций, организации входных и
выходных данных, временные характеристики и т.п.
требования к надёжности (обеспечение устойчивого функционирования, контроль входной и выходной
информации, время восстановления после отказа и т.п.);
условия эксплуатации (интерфейс, а также вид обслуживания, необходимое количество и квалификация
персонала.)
требования к составу и параметрам технических средств; состав технических средств с указанием их
технических характеристик
требования к информационной и программной совместимости; (решения, исходные коды, языки
программирования)
требования к упаковке; требования к транспортированию и хранению; специальные требования.
В разделе "Технико-экономические показатели" должны быть указаны: экономическая эффективность,
предполагаемая годовая потребность, преимущества разработки по сравнению с аналогами.
В разделе "Стадии и этапы разработки" устанавливают необходимые стадии разработки, этапы и
содержание работ (перечень программных документов, которые должны быть разработаны, согласованы
и утверждены), а также, как правило, сроки разработки и определяют исполнителей.
В разделе "Порядок контроля и приёмки" должны быть указаны виды испытаний и общие требования к
приёмке работы.

3.

Этап 1. Анализ требований
Исходные данные: начальная постановка задачи (в
текстовом виде).
Требуется: построить диаграммы вариантов использования,
описывающие функциональность системы. Каждое
действующее лицо (actor) и вариант использования
сопровождается описанием. Все описания составляются на
русском языке. Описание действующего лица - короткое (12 строки). Описание варианта использования состоит из
пояснения, предусловия, потоков событий (основного и
альтернативных, если таковые есть) и постусловия.
Описания представляют собой либо присоединенные
текстовые файлы, либо текст, введенный в поле
Documentation спецификации соответствующего элемента
диаграммы.

4. Особенности изображения графического элементов диаграмм языка UML

5. Диаграмма вариантов использования (use case diagram)

диаграмма, на которой изображаются варианты использования
проектируемой системы, заключенные в границу системы, и
внешние актеры, а также определенные отношения между
актерами и вариантами использования
<<extend>>
Клиент Банка
Пополнить счет
Открыть счет
варианты использования
актеры
Кассир
<<extend>>
Операционист
ассоциации
Снять деньги со счета
Закрыть счет
зависимость с текстовым
стереотипом

6. Основные обозначения на диаграмме вариантов использования

7. Вариант использования (use case)

Вариант использования (use case)
• – представляет собой общую спецификацию
совокупности выполняемых системой действий с
целью предоставления некоторого наблюдаемого
результата, который имеет значение для одного или
нескольких актеров
• Отвечает на вопрос «Что должна выполнять
система?», не отвечая на вопрос «Как она должна
выполнять это?»
• Имена – отглагольное существительное или глагол в
неопределенной форме
<<use case>>
Формирование отчета по
выполненным заказам
Проверка состояния
текущего счета клиента
Формирование отчета по
выполненным заказам

8. Актер (actor)

• – любая внешняя по отношению к проектируемой
системе сущность, которая взаимодействует с
системой и использует ее функциональные
возможности для достижения определенных целей
или решения частных задач
• Примеры актеров: кассир, клиент банка, банковский
служащий, президент, продавец магазина, менеджер
отдела продаж, пассажир авиарейса, водитель
автомобиля, администратор гостиницы, сотовый
телефон
Клиент банка
<<actor>>
Посетитель
Интернет-магазина
Удаленный
пользователь

9. Вопросы для идентификации актеров в системе

• Какие организации или лица будут использовать
систему
• Кто будет получать пользу от использования системы
• Кто будет использовать информацию от системы
• Будет ли использовать система внешние ресурсы
• Может ли один пользователь играть несколько ролей
при взаимодействии с системой
• Могут ли различные пользователи играть одну роль
при взаимодействии с системой
• Будет ли система взаимодействовать с
законодательными, исполнительными, налоговыми
или другими органами

10. Отношение ассоциации

• Ассоциация (association) является одним из
фундаментальных понятий в языке UML 2.х и может
использоваться на различных канонических
диаграммах при построении визуальных моделей
• Применительно к диаграммам вариантов
использования отношение ассоциации может
служить только для обозначения взаимодействия
актера с вариантом использования.
Просмотр списка
представленных товаров
Посетитель
Интернет-магазина

11. Отношение включения

• Отношение зависимости (dependency) определяется как
форма взаимосвязи между двумя элементами модели,
предназначенная для спецификации того обстоятельства,
что изменение одного элемента модели приводит к
изменению некоторого другого элемента
• Отношение включения (include) специфицирует тот факт,
что некоторый вариант использования содержит
поведение, определенное в другом варианте
использования
Оформление Заказа в
Интернет-магазине
вариант использования А
<<include>>
Регистрация
покупателя
вариант использования Б

12. Отношение расширения

• Отношение расширения (extend) определяет
взаимосвязь одного варианта использования с
некоторым другим вариантом использования,
функциональность или поведение которого
задействуется первым не всегда, а только при
выполнении некоторых дополнительных условий.
Оформление Заказа в
Интернет-магазине
вариант использования А
<<extend>>
Предоставление бонусной
скидки постоянному
покупателю
вариант использования Б

13. Изображение отношения расширения с условием выполнения

Условие: {клиент имеет бонусную карточку}
extention point:Скидка
Оформление Заказа в
Интернет-магазине
extention point
Скидка
<<extend>>
Предоставление бонусной
скидки постоянному
покупателю

14. Отношение обобщения

• Отношение обобщения (generalization relationship)
предназначено для спецификации того факта, что
один элемент модели является специальным или
частным случаем другого элемента модели
Оплата выбранного в
Интернет-магазине товара
Оплата товара по
кредитной карточке
вариант использования А
вариант использования Б
Посетитель
Интернет-магазина
Покупатель
(актер А)
(актер Б)

15. Пример диаграммы ВИ для системы продажи товаров в Интернет-магазине

Система продажи товаров в Интернет-магазине
Просмотр списка
товаров
Изменение списка
товаров
Посетитель
Интернетмагазина
Изменение содержания
корзины
Оформление Заказа
на покупку товаров
<<include>>
<<extend>>
Менеджер
Регистрация
покупателя
Предоставление
бонусной скидки
Покупатель
Оплата выбранного
товара
Бухгалтер
Оплата товара
наличными
Оплата товара по
кредитной карточке

16. Спецификация ВИ с помощью текстовых сценариев

• Сценарий (scenario) – специально
написанный текст, который описывает
поведение моделируемой системы в
форме последовательности
выполняемых действий актеров и
самой системы.

17. Типичные ошибки при разработке диаграмм вариантов использования

• Превращение диаграммы вариантов использования в
диаграмму деятельности за счет желания отразить все
функциональные действия
• Инициатором действий является разрабатываемая система
• Спецификация атрибутов и операций классов до того, как
сформулированы все варианты использования
• Задание слишком кратких имен вариантам использования
• Описание вариантов использования в терминологии,
непонятной пользователям системы или заказчику
• Отсутствие описаний альтернативных
последовательностей действий
• Тратится слишком много времени на решение вопросов о
том, какие стереотипы и ассоциации использовать на
диаграмме

18.

Этап 2. Реализация вариантов использования
Исходные данные: начальная постановка задачи (в текстовом виде) и
диаграммы вариантов использования.
Требуется: выделить прототипные объекты системы и построить
диаграммы взаимодействия между объектами (последовательности и
кооперативные), соответствующие потокам событий вариантов
использования. Для анализа нескольких вариантов использования можно
использовать диаграммы деятельности. Названия диаграмм должны
совпадать с названиями соответствующих вариантов использования. Все
необходимые пояснения должны содержаться в примечаниях диаграмм.
На этом этапе проектируются диаграммы взаимодействия в начальном
приближении, объекты не соотносятся с классами, сообщения не
соотносятся с операциями.

19. Диаграмма деятельности (activity diagram)

• – диаграмма, которая изображает поведение объекта
или системы с использованием моделей потока данных
и потока управления
• Деятельность (activity) является спецификацией
параметризованного поведения в форме
координируемой последовательности подчиненных
единиц, индивидуальными элементами которых
являются действия
• Элементами, из которых состоят деятельности, являются
действия
• Действие (action) представляет собой элементарную
единицу спецификации поведения, которая не может
быть далее декомпозирована в форме деятельности

20. Узел деятельности (activity node)

• - является абстрактным классом для отдельных
точек в потоке деятельности, соединенных
дугами
И мя
дейст в ия
И мя
деят ельност и
И мя
объект а
• Дуга деятельности (activity edge) является
абстрактным классом для направленных
соединений между двумя узлами деятельности
имя
n
n

21. Поток управления (control flow)

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

22. Поток объектов (object flow)

• - представляется в форме дуги деятельности, по
которой передаются только маркеры объектов или
данных
• При этом все маркеры, предлагаемые узлом
источником, предлагаются для узла цели с учетом
ограничений, которые могут быть дополнительно
специфицированы с помощью веса дуги
• Узлы объектов, соединенные потоком объектов с
необязательными промежуточными узлами
действий или управления, должны иметь
совместимые типы
Оплат ит ь
заказ
Заказ
От грузит ь
заказ

23. Варианты нотация для деятельности

И мя деят ельност и «precondition»
И мя парамет ра : Тип «postcondition»
...
...
«activity»
И мя деят ельност и
ат рибут : тип
ат рибут : тип
операция (парамет ры)
операция (парамет ры)
...

24. Семантика деятельности

• Семантика деятельности в языке UML 2.х основывается на
потоке маркеров
• Маркер (token) – элемент модели, предназначенный для
представления некоторого объекта, данных или управления
и существующий на диаграмме деятельности в отдельном
узле
• Каждый маркер отличается от любого другого, даже если он
содержит то же значение, что и другой
• Любой узел деятельности может начать свое выполнение,
только если удовлетворены специфицированные условия
для его входных маркеров, причем эти условия зависят от
вида узла
• Когда узел начинает свое выполнение, маркеры
принимаются из некоторых или всех его входных дуг, а
специальный маркер размещается в этом узле
• Когда узел завершает выполнение, специальный маркер
удаляется из этого узла, а другие маркеры предлагаются в
некоторых или всех его выходных дугах

25. Семантика действия

• Выполнение действия становится возможным, когда
удовлетворены предварительные условия для его потоков
управления и объектов
• Выполнение действия поглощает входные маркеры управления и
маркеры объектов и удаляет их из источников дуг управления и из
входных контактов
• Если на одной дуге являются доступными несколько маркеров
управления, то они все поглощаются
• Действие продолжает выполнение до тех пор, пока оно не будет
завершено
• После завершения действия оно предлагает маркеры объектов во
все его выходные контакты, а маркеры управления во все
выходящие из него дуги управления, и на этом формально оно
заканчивается
• После окончания выполнения действия с помощью некоторой
реализации должны быть восстановлены его ресурсы

26. Узлы управления

• Начальный узел (initial node) является узлом управления, в
котором начинается поток при вызове деятельности
• Узел финала деятельности (activity final node) является
узлом управления, который прекращает или останавливает
все потоки в деятельности
• Узел финала потока (flow final node) является финальным
узлом, который завершает отдельный поток управления или
поток объектов, не завершая содержащей его деятельности
Получить
заказ
Закрыть
заказ
Достав ить
заказ

27. Узел решения (decision node)

• - является узлом управления, который выбирает между
выходящими потоками
• Если для узла решения при оценивании оказываются
справедливыми более одного сторожевого условия, то
семантика такого поведения в языке UML 2.х не
определена, поскольку среди выходящих дуг возникает
состязание за прием маркера
• При отсутствии дополнительной спецификации это
может привести к несостоятельной (ill-formed) модели
• Чтобы гарантировать выполнение только одного
сторожевого условия, иногда удобно использовать
процедуру проверки до первого истинного условия

28. Варианты изображения узла решения

...
...
...
[обычная дост ав ка]
Получит ь
заказ
[срочная дост ав ка]
Оформить
обычную
дост ав ку
Оформить
срочную
дост ав ку

29. Узел слияния (merge node)

• - является узлом управления, который соединяет
вместе несколько альтернативных потоков
...
Купит ь т ов ар
И згот ов ит ь
т ов ар
Достав ит ь
т ов ар

30. Пример последовательного ветвления

31. Узел разделения (fork node)

...
...
...
• - является узлом управления, который расщепляет
поток на несколько параллельных потоков
• Дуги, выходящие из узла разделения, дополнительно
могут иметь сторожевые условия, при невыполнении
которых могут возникать паузы с передачей
маркеров по этим дугам
• В данном случае предполагается, что никакие из
находящихся далее узлов соединения не зависят от
прохода маркеров, передающихся через дугу со
сторожевым условием
• Если этого исключить нельзя, то необходимо ввести
узел решения с последующим узлом слияния
Принят ь
заказ
Заполнит ь
заказ
Послат ь
счет

32. Узел соединения (join node)

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

33. Примеры изображения узла соединения

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

34. Примеры изображения узла соединения с дополнительной спецификацией

{joinSpec = ...}
А
...
Выбрат ь
напит ок
Опуст ит ь
монет ы
В
{joinSpec = А and В and общая сумма
опущенных монет >= цена напит ка}
Выдат ь
напит ок

35. Пример условно-параллельных деятельностей

Пример
условнопараллельных
деятельностей
• Дуги, выходящие из
узла разделения,
дополнительно могут
иметь сторожевые
условия, при
невыполнении
которых могут
возникать паузы с
передачей
управления по этим
дугам

36. Пример деятельности с входным параметром

Обработка заказа
«precondition» Заказ пост упил
Поступив ший заказ : Заказ «postcondition» Заказ закрыт
[заказ от клонен]
Поступив ший
заказ
Принят ь
заказ
Заполнить
заказ
От грузит ь
заказ
[заказ принят ]
Послат ь
счет
Осущест в ит ь
оплат у
Счет
Принят ь
оплат у
Закрыт ь
заказ

37.

Этап 3. Проектирование
Исходные данные: начальная постановка задачи (в текстовом виде) и
диаграммы вариантов использования, диаграммы взаимодействия.
Требуется: создать иерархию классов системы, разместить классы по
пакетам (использовать деление: пользовательский интерфейс управление - данные; или другое в зависимости от постановки задачи),
связать объекты с классами, сообщения - с операциями (второй этап
разработки диаграмм взаимодействия). Каждый класс снабдить
описанием. Оно должно включать в себя краткое описание ответственность класса; описание атрибутов в виде таблицы из 3-х
столбцов: имя, описание, тип; таблицу с описанием операций (имя,
описание, сигнатура). Для классов указать стереотипы. Построить
диаграммы классов системы, отображающие связи между классами.
Для описания поведения экземпляров отдельных классов использовать
диаграммы состояний.

38. Диаграмма классов — основная логическая модель проектируемой системы

• Диаграмма классов (class diagram) — диаграмма,
предназначенная для представления модели
статической структуры программной системы в
терминологии классов объектно-ориентированного
программирования
• Диаграмма классов представляет собой граф,
вершинами или узлами которого являются
элементы типа “классификатор”, которые связаны
различными типами структурных отношений
• Классификатор (classifier) – специальное понятие,
предназначенное для классификации экземпляров,
которые имеют общие характеристики

39. Характеристики классификатора

• Характеристика (feature) – понятие, предназначенное
для спецификации особенностей структуры и поведения
экземпляров классификаторов
• Структурная характеристика (structural feature)
является типизированной характеристикой
классификатора, которая специфицирует структуру его
экземпляров
• Характеристика поведения (behavioral feature) является
характеристикой классификатора, которая специфицирует
некоторый аспект поведения его экземпляров
• Класс (class) – элемент модели, который описывает
множество объектов, имеющих одинаковые
спецификации характеристик, ограничений и семантики

40. Основные обозначения на диаграмме классов

Класс
Компания
Кратность
Имя
ассоциации
Композиция
1..*
1..*
*
Отдел
0..1
1
название : String
*
*
Местоположение
*
Ассоциация
*
адрес : String
телефон :
Number
Ограничение
{subset}
Сотрудник
Офис
Менеджер
Обобщение
1
1..*
Сотрудник
имя : String
фамилия : String
должность : String
getPhoto(p:Photo)
getContactInform()
getPersonalRecords()
Имя конца
ассоциации
Атрибуты
Операции
Контактная
Информация
адрес : String
телефон :
Number
Зависимость
Штаб-квартира
Интерфейс
Персональное Дело
историяРаботы : String
зарплата : Curency
ISecureInformation

41. Варианты графического изображения класса на диаграмме классов

Имя класса
Имя класса
Имя класса
атрибуты класса
Имя класса
операции класса
операции класса
Видимость
Shape
+origin : Point
+move(p:Point)
+resize(s:Scale)
+disply()
#invalidateRegion()
Responsibilities
- - manage shape state
- - handle basic shape
transformations
Имя класса
Атрибуты
Операции
Сигнатура
операции
Дополнительная
секция

42. Разновидности классов

• Абстрактный (abstract) класс не имеет экземпляров или
объектов, для обозначения его имени используется
наклонный шрифт (курсив)
• Активный класс (active class) – класс, каждый экземпляр
которого имеет свою собственную нить управления
• Пассивный класс (passive class) – класс, каждый экземпляр
которого выполняется в контексте некоторого другого
объекта
• Квалифицированное имя (qualified name) используется для
того, чтобы явно указать, к какому пакету относится тот или
иной класс. Для этого применяется специальный символ в
качестве разделителя имени – двойное двоеточие “::”
• Имя класса без символа разделителя называется простым
именем класса

43. Вид видимости

+ public (общедоступный). Общедоступный элемент является
видимым всеми элементами, который имеют доступ к
содержимому пространства имен, который им владеет.
- private (закрытый). Закрытый элемент является видимым
только внутри пространства имен, который им владеет.
# protected (защищенный). Защищенный элемент является
видимым для элементов, которые имеют отношение
обобщения с пространством имен, который им владеет.
~ package (пакет). Элемент, помеченный как имеющий
пакетную видимость, является видимым всеми элементами в
ближайшем охватывающем пакете в предположении. За
пределами ближайшего охватывающего пакета элемент,
помеченный как имеющий пакетную видимость, не является
видимым.