Методы и средства разработки И. Томский политехнический университет р. В. Ковин, Е. А. Мирошниченко
 Скачать 2.85 Mb.
|
|
последовательность поведения другого варианта использования. Отношение отображаются штриховой стрелкой и помечена стереотипом «include» (англ. включает). (рис. 2.5). Не следует путать это отношение с зависимостью одного ВИ от другого через начальное состояние. 18 Рис. 2.5. Пример отношения включения Отношение расширения определяет потенциальную возможность включения поведения одного варианта использования в состав другого. Т. е. дочерний вариант использования может как вызываться, так и не вызываться родительским. Стрелка расширения должна быть направлена от расширяющего варианта к базовому (рис. 2.6) и помечена стереотипом «extend» (англ. расширяет). Рис. 2.6. Пример отношения расширения Данное отношение также может быть описано в расширяющем ВИ в разделе «Начальное состояние». Это может быть указание на то, что базовый ВИ запущен (если расширение возможно во время выполнения базового ВИ) или выполнен (если расширение возможно после окончания ВИ). Более подробно почитать о диаграмме ВИ можно по ссылке https://www.uml- diagrams.org/use-case-diagrams.html 19 2.1.3. Инструментальные средства для создания диаграммы Для создания диаграммы можно использовать специализированные векторные редакторы. Например, в бесплатном настольном редакторе yEd ( https://www.yworks.com/products/yed ) имеются готовые фигуры для создания диаграммы ВИ (рис. 2.8). Рис. 2.8. Главное окно yEd Созданные диаграммы ВИ могут добавляться в различные технические документы, такие как эскизный и технический проекты в виде изображений. При этом важно добавлять диаграммы с высоким качеством. Рекомендуется использовать векторный формат изображений. 2.2. ПРАКТИЧЕСКАЯ ЧАСТЬ 2.2.1. Практическое задание В качестве практического задания необходимо создать диаграмму вариантов использования на основе ВИ, описанных в лабораторной работе №1. 20 2.2.2. Список контрольных вопросов для самопроверки 1. Из каких элементов состоит диаграмма ВИ? 2. В чем отличие отношений ВИ «Включение» и «Расширение»? 3. Как вы считаете почему для создания диаграмм ВИ желательно использовать специализированные редакторы? 2.3. ТРЕБОВАНИЯ К ОТЧЕТУ Отчет должен содержать следующие разделы: 1. Титульный лист, оформленный согласно утвержденному образцу. 2. Цели и задачи выполняемой лабораторной работы. 3. Пошаговое описание выполняемых заданий лабораторной работы: 4. Ответы на контрольные вопросы. 5. Заключение. 21 3. ЛАБОРАТОРНАЯ РАБОТА №3. Техническое задание ЦЕЛЬ РАБОТЫ Изучение и получение навыков создания технического задания. Введение Техническое задание (ТЗ, техзадание) — основной документ, содержащий требования заказчика к системе, в соответствии с которыми осуществляется создание и разработка конечного продукта. Техническое задание позволяет: • исполнителю — понять суть задачи, показать заказчику «технический облик» будущего изделия, программного изделия или автоматизированной системы; • заказчику — осознать, что именно ему нужно; • обеим сторонам — представить готовый продукт; • исполнителю — спланировать выполнение проекта и работать по намеченному плану; • заказчику — требовать от исполнителя соответствия продукта всем условиям, оговорённым в ТЗ; • исполнителю — отказаться от выполнения работ, не указанных в ТЗ; • заказчику и исполнителю — выполнить проверку готового продукта; • избежать ошибок, связанных с изменением требований. 3.1. ТЕОРЕТИЧЕСКАЯ ЧАСТЬ 3.1.1. Основные работы при разработке требований При разработке ТЗ необходимо выполнить следующие работы. 1. Исходная постановка задачи. 2. Идентификация и вовлечение стейкхолдеров. 3. Сбор и исследование информации: • данные о предметной области в целом; • данные о существующих аналогах, конкурирующих продуктах; • истории успехов, истории провалов; 22 • данные о специфике заказчика, например: • специфика бизнес-процессов организации; • данные об унаследованном ПО (legacy software); • используемое аппаратное обеспечение; • политика безопасности организации; • уровень квалификации персонала. 4. Выбор приоритетных критериев качества. 5. Формализация требований, их описание. 3.1.2. Понятие требования Требование — утверждение, которое передаёт или выражает некоторую потребность и связанные с ней ограничения и условия (ISO/IEC/IEEE 29148-2011). Важно понимать, что выражение некоторой потребности должно соответствовать определенным характеристикам. Характеристики правильного требования: • Необходимость. Транслирует (описывает) реальную потребность стейкхолдеров. • Атомарность. Не является механическим объединением разных требований. • Понятность. Из описания всё понятно, нет необходимости обращаться за толкованием к заказчику. • Независимость от реализации. Не накладывает преждевременные и ненужные технические ограничения. • Проверяемость. Можно объективно проверить, выполнено ли требование. • Правдоподобность (реалистичность, выполнимость). Требование должно быть выполнимо в рамках существующих ограничений, таких как текущий уровень технологий, законодательство, время, деньги и доступные ресурсы. Не только отдельные требования должны иметь перечисленные характеристики, но и наборы требований должно соответствовать определенным характеристикам. Характеристики хорошего набора требований: • Полнота. Описывает всё, что нужно для определения системы, без значимых упущений. 23 • Непротиворечивость. Одни требования не противоречат другим. Часто требования к функциональности несовместимы с требованиями к производительности; удобство для пользователя несовместимо с информационной безопасностью и т.д. • Идентифицируемость. На каждое требование можно ссылаться, его можно отслеживать, трассировать и т.д. 3.1.3. Идентификация требований Возможны следующие подходы к идентификации (кодификации) требований: • никакой; • нумерация абзацев, как в юридических документах; • мнемонические идентификаторы (буквенно-цифровые). Система кодирования требований преследует следующие цели: • уникальность идентификаторов; • однозначность ссылок (независимость от словоформ и опечаток); • компактность ссылок; • простота поиска; • исключение потребности в перенумерации требований при изменении нумерации разделов. В качестве примера рассмотрим вариант мнемонических идентификаторов. В этом примере формат идентификатора имеет вид [А][ББ].[ВВ].[ГГ], где: • А — префикс • ББ, ВВ, ГГ — двузначное число от 00 до 99 • ББ — код первого уровня • ВВ — код второго уровня • ГГ — код третьего уровня Префикс Тип требования A Архитектурное требование C Требование к аппаратной или программной совместимости 24 D Требование к структуре данных F Функциональное требование R Требование к надёжности S Требование к информационной безопасности T Требование к передаче результата (сдача/приёмка, внедрение) U Требование к пользовательскому интерфейсу С требованиями связано понятие стейкхолдера. В техническом задании требования выражают те или иные потребности стейкхолдеров. 3.1.4. Понятие стейкхолдера Есть разные синонимы/переводы этого термина: «заинтересованная сторона», «причастная сторона», «участник работ», «правообладатель». Под стейкхолдером понимают: • Физическое лицо или организация, имеющая права, долю, требования или интересы относительно системы или её свойств, удовлетворяющих их потребностям и ожиданиям (ISO/IEC 15288, ISO/IEC 29148). • Физическое лицо, команда, организация или их классы, имеющие интерес в системе (ISO/IEC 42010). • Физическое лицо, группа лиц или организация, которые могут влиять на систему или на которых может повлиять система (OMG Essence). Важно: стейкхолдеры — это и роли, и люди в этих ролях. 3.1.5. Государственные и международные стандарты для разработки ТЗ При разработке технического задания следует руководствоваться следующими государственными и международными стандартами: • ГОСТ 19.201-78. Единая система программной документации. Техническое задание. Требования к содержанию и оформлению. • ГОСТ 34.602-89 Информационная технология. Техническое задание на создание автоматизированной системы. 25 Стандарт ISO/IEC/IEEE 29148-2011 определяет: • Stakeholder requirements specification (StRS); • System requirements specification (SyRS); • Software requirements specification (SRS). 3.1.6. Структура ТЗ по ГОСТ 19.201-78 В ГОСТ 19.201-78 «Единая система программной документации. Техническое задание. Требования к содержанию и оформлению» в техническом задании предусмотрены следующие разделы: • Наименование и область применения • Основание для разработки • Назначение разработки • Технические требования • Требования к функциональным характеристикам • Требования к надёжности • Условия эксплуатации • Требования к составу и параметрам технических средств • Требования к информационной и программной совместимости • Требования к маркировке и упаковке • Требования к транспортированию и хранению • Специальные требования • Технико-экономические показатели • Стадии и этапы разработки • Порядок контроля и приёмки • Приложения 3.1.7. Структура ТЗ по ГОСТ 34.602-89 В ГОСТ 34.602-89 «Информационная технология. Техническое задание на создание автоматизированной системы» в техническом задании предусмотрены следующие разделы: • Общие сведения 26 • Назначение и цели создания (развития) системы • Характеристика объектов автоматизации • Требования к системе o Требования к системе в целом o Требования к функциям (задачам), выполняемым системой o Требования к видам обеспечения • Состав и содержание работ по созданию системы • Порядок контроля и приемки системы • Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие • Требования к документированию • Источники разработки 3.2. ПРАКТИЧЕСКАЯ ЧАСТЬ 3.2.1. Практическое задание В качестве практического задания необходимо написать документ «Техническое задание» для системы, создаваемой студентом в рамках индивидуального задания на дисциплину. Особое внимание уделить описанию функциональных требований. 3.2.2. Список контрольных вопросов для самопроверки 1. Почему программисту необходимо уметь составлять техническое задание? 2. Почему требования должны соответствовать определенным характеристикам? 3. Какая польза от идентификации требований? 3.3. ТРЕБОВАНИЯ К ОТЧЕТУ Отчет должен содержать следующие разделы: 1. Титульный лист, оформленный согласно утвержденному образцу. 2. Цели и задачи выполняемой лабораторной работы. 27 3. Пошаговое описание выполняемых заданий лабораторной работы: 4. Ответы на контрольные вопросы. 5. Заключение. 28 4. ЛАБОРАТОРНАЯ РАБОТА №4. Диаграммы UML. Диаграмма компонентов ЦЕЛЬ РАБОТЫ Изучение и получение навыков создания диаграммы компонентов. Введение Диаграмма компонентов (англ. Component diagram) — элемент языка моделирования UML, статическая структурная диаграмма, которая показывает разбиение программной системы на структурные компоненты и связи (зависимости) между компонентами. В качестве физических компонентов могут выступать файлы, библиотеки, модули, исполняемые файлы, пакеты и т. п. Диаграмма компонентов разрабатывается для следующих целей: • визуализация общей структуры исходного кода программной системы. • спецификация исполнимого варианта программной системы. • обеспечение многократного использования отдельных фрагментов программного кода. • представление концептуальной и физической схем баз данных. Диаграмма компонентов отражает общие зависимости между компонентами, рассматривая последние в качестве классификаторов. 4.1. ТЕОРЕТИЧЕСКАЯ ЧАСТЬ 4.1.1. Базовые понятия Интерфейс — это набор операций, которые специфицируют сервис, предоставляемый либо требуемый классом или компонентом. Компонент — замещаемая часть системы, которая соответствует набору интерфейсов и обеспечивает его реализацию. Порт — специфическое «окно» в инкапсулированный компонент, принимающее сообщения для компонента и от него в соответствии с заданным интерфейсом. 29 Внутренняя структура — реализация компонента, представленная набором частей, соединенных друг с другом конкретным способом. Часть — спецификация роли, составляющей часть реализации компонента. В экземпляре компонента присутствует экземпляр, соответствующий части. Коннектор — связь коммуникации между двумя частями или портами в контексте компонента. 4.1.2. Компоненты и интерфейсы Компонент (англ. component) — это специальный термин в языке UML, предназначенный для представления физических сущностей. Компонент реализует некоторый набор интерфейсов и служит для общего обозначения элементов физического представления модели. На рис. 4.1 показана типичное графическое представление компонента. Внутри прямоугольника записывается имя компонента и при необходимости, дополнительная информация. Имя компонента подчиняется общим правилам именования элементов модели в языке UML и может состоять из любого числа букв, цифр и некоторых знаков препинания. Отдельный компонент может быть представлен • уровне типа; • на уровне экземпляра. Хотя его графическое изображение в обоих случаях схожее, правила записи имени компонента отличаются. Если компонент представляется на уровне типа, то в качестве его имени записывается только имя типа с заглавной буквы. Если же компонент представляется на уровне экземпляра (instance), то в качестве его имени записывается <имя компонента ':' имя типа>. При этом вся строка имени подчеркивается. Интерфейс — набор операций, используемый для спецификации сервиса класса или компонента. Связь между компонентом и интерфейсом имеет важное значение. Все основанные на компонентах средства операционных систем используют интерфейсы в качестве элементов, связывающих компоненты друг с другом. Интерфейс, который реализован компонентом, называется предоставляемым (то есть данный компонент предоставляет интерфейс в виде сервиса другим компонентам). 30 Компонент может декларировать множество предоставляемых интерфейсов. Интерфейс, который он использует, называется требуемым: ему соответствует данный компонент, когда запрашивает сервисы от других компонентов. Компонент может соответствовать множеству требуемых интерфейсов. Бывают компоненты, которые одновременно предоставляют и требуют интерфейсы. Рис. 4.1. Компоненты и интерфейсы 4.1.3. Порты Порт (англ. port) — это своеобразное «окно» в инкапсулированный компонент. Все взаимодействие с таким компонентом на входе и на выходе происходит через порты. Один компонент может взаимодействовать с другим через определенный порт. Порт схематически представлен маленьким квадратом на боковой грани компонента — это отверстие в границе инкапсуляции компонента (рис. 4.2). Как предоставляемый, так и требуемый интерфейс может быть соединен с символом порта. Предоставляемый интерфейс изображает сервис, который может быть запрошен извне через данный порт, а требуемый интерфейс – сервис, который порт должен получить от какого-либо другого компонента. У каждого порта есть имя, а следовательно, он может быть идентифицирован по компоненту и имени. 31 Рис. 4.2. Порты компонента 4.1.4. Части компонента Компонент может быть реализован как единый фрагмент кода, но в больших системах желательно иметь возможность строить крупные компоненты из малых, которые используются в качестве строительных блоков. Внутренняя структура компонента содержит части, которые вкупе с соединениями между ними составляют его реализацию. Часть — это не то же самое, что класс. Каждая часть идентифицируется по ее имени так же, как в классе различаются атрибуты. Допустимо наличие нескольких частей одного и того же типа, но их можно различать по именам и они предположительно выполняют разные функции внутри компонента. 32 Рис. 4.3. Части компонента 4.1.5. Коннекторы «Проводок» между двумя портами называется коннектором. В экземпляре охватывающего компонента он представляет просто ссылку (link) или временную ссылку (transient link). Простая ссылка – это экземпляр обычной ассоциации. Временная ссылка представляет связь использования между двумя компонентами. Коннекторы изображаются двумя способами (рис. 4.4). Если два компонента явно связаны друг с другом (либо напрямую, либо через порты), достаточно провести линию между ними или их портами. Если же два компонента подключены друг к другу, потому что имеют совместимые интерфейсы, можно использовать нотацию «шарик–гнездо», чтобы показать, что между этими компонентами не существует постоянной связи, хотя они и соединены внутри объемлющего компонента. 33 Рис. 4.4. Коннекторы 4.1.6. Рекомендации по построению диаграммы компонентов Подробнее о построении диаграммы компонентов можно прочитать по ссылке https://www.omg.org/spec/UML/2.1.2/Superstructure/PDF и в книге Гради Буч, Джеймс Рамбо, Ивар Якобсон. Язык UML. Руководство пользователя. 4.1.7. Инструментальные средства для создания диаграммы |