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

Лекция 4. Анализ требований и определение спецификаций программного обеспечения при объектном подходе При подготовке лекции использовались источники: 1. Гради Буч, Джеймс Рамбо, Ивар Якобсон. Язык UML. Руководство пользователя. – М.: ДМК Пресс, 2006. – 496 с. 2. Иванова Г.С. Технология программирования: Учебник для вузов. - М.: Изд-во МГТУ им. Н.Э. Баумана, 2002. – 320 с. 3. https://prog-cpp.ru/uml-classes/ 4. https://ru.wikipedia.org/wiki/UML 1. UML - стандартный язык описания разработки программных продуктов с использованием объектного подхода Анализ требований и составление спецификаций является первым и важнейшим этапом проектирования программного обеспечения. На этом этапе уточняется поведение программного обеспечения и разрабатывается концептуальная модель предметной области с точки зрения поставленных задач. В основе объектного подхода к разработке программного обеспечения лежит объектная декомпозиция, т. е. представление разрабатываемого программного обеспечения в виде совокупности объектов. Однако при объектном подходе так же, как при структурном подходе, сразу можно выполнить декомпозицию только очень простого программного обеспечения. Поэтому на заре эпохи объектно-ориентированного программирования были предложены различные методы анализа и проектирования программного обеспечения в рамках объектного подхода, использующие различные модели и нотации. Длительный период времени продолжался спор о достоинствах и недостатках этих нотаций и моделей. Эта ситуация получила название «войны методов». Конец «войне методов» положило появление в 1995 г. первой версии языка UML (Unified Modeling Language - унифицированный язык моделирования), который в настоящее время фактически признан стандартным средством описания проектов, создаваемых с использованием объектно-ориентированного подхода. Его создателями являются ведущие специалисты в этой области: Гради Буч, Ивар Якобсон и Джеймс Рамбо, которые использовали в своем языке все лучшее, что появилось в подходах этих авторов во время «войны методов». Спецификация разрабатываемого программного обеспечения при использовании UML объединяет несколько моделей: использования, логическую, реализации, процессов, развертывания. Модель использования представляет собой описание функциональности программного обеспечения с точки зрения пользователя. Логическая модель описывает ключевые абстракции программного обеспечения (классы, интерфейсы и т. п.), т. е. средства, обеспечивающие требуемую функциональность. Модель реализации определяет реальную организацию программных модулей в среде разработки. Модель процессов отображает организацию вычислений и оперирует понятиями «процессы» и «нити». Она позволяет оценить производительность, масштабируемость и надежность программного обеспечения. Модель развертывания показывает особенности размещения программных компонентов на конкретном оборудовании. Таким образом, каждая из указанных моделей характеризует определенный аспект проектируемой системы, а все они вместе составляют относительно полную модель разрабатываемого программного обеспечения. UML является языком широкого профиля, это открытый стандарт, использующий графические обозначения для создания абстрактной модели системы. . UML не является языком программирования, но на основании UML-моделей возможна генерация кода, в том числе автоматическая, с помощью среды программирования. UML предлагает правила построения диаграмм различных типов. Эти диаграммы дополняют друг друга и могут использоваться для описания различных моделей. Все UML-диаграммы по возможности используют единую графическую нотацию, что облегчает их понимание. С развитием UML количество типов диаграмм постоянно расширяется. Ниже дан далеко неполный список часто используемых диаграмм: • диаграммы вариантов использования; • диаграммы классов; • диаграммы пакетов; • диаграммы последовательностей действий • диаграммы кооперации; • диаграммы деятельностей; • диаграммы состояний объектов; • диаграммы компонентов; • диаграммы размещения. Помимо диаграмм, как и при структурном подходе, спецификация обязательно включает словарь терминов, а также различного рода описания и текстовые спецификации. Конкретный набор документации определяется разработчиком. Диаграммы применяются не только для документирования и визуализации, но также для конструирования программного обеспечения посредством прямого или обратного проектирования. Прямое проектирование — это преобразование графической модели в исполняемый код на каком-либо языке программирования. Обратным проектированием называется процесс преобразования кода, написанного на каком-либо языке программирования, в графическую модель. В настоящее время существует много программных продуктов, поддерживающих UML-диаграммы. Среди коммерческих систем, возможно, наиболее популярными являются Rational Rose и MS Visual Studio (начиная с версии 2010). Эти среды не только позволяют строить UML-диаграммы, но и осуществлять прямое и обратное проектирование. В данной лекции будут рассмотрены 2 типа диаграмм: вариантов использования, классов. 2. Диаграммы вариантов использования Разработку спецификаций программного обеспечения начинают с анализа требований к функциональности, указанных в техническом задании. Диаграммы вариантов использования позволяют наглядно представить ожидаемое поведение и основные сценарии работы системы. Основными понятиями диаграмм вариантов использования являются: действующее лицо, вариант использования, связь. Действующее лицо - внешняя (по отношению к разрабатываемому программному обеспечению) сущность, которая взаимодействует с программным обеспечением с целью получения или предоставления какой-либо информации. Действующими лицами могут быть пользователи, другое программное обеспечение, технические средства, взаимодействующие с разрабатываемым программным обеспечением. Вариант использования (use case) - некоторая процедура, решающая конкретную задачу конкретного действующего лица. Варианты использования определяются по функциональным требованиям к проектируемой системе. Варианты использования также называют прецедентами. В зависимости от цели выполнения конкретной процедуры различают следующие варианты использования: • основные варианты обеспечивают требуемую функциональность разрабатываемого программного обеспечения; • второстепенные варианты обеспечивают выполнение необходимых настроек системы и ее обслуживание (например, архивирование информации и т. п.); • дополнительные варианты обеспечивают дополнительные удобства для пользователя (как правило, реализуются в том случае, если не требуют серьезных затрат каких-либо ресурсов ни при разработке, ни при эксплуатации). Связи показывают соответствие действующих лиц и вариантов использования, а также связи вариантов использования между собой. Поясним, как могут быть связаны между собой варианты использования. Возможно два вида связей: использование и расширение. Использование подразумевает, что существует некоторый фрагмент поведения разрабатываемого программного обеспечения, который повторяется в нескольких вариантах использования. Этот фрагмент оформляют, как отдельный вариант использования и указывают связь с ним типа «использование» для всех вариантов использования, содержащих этот фрагмент. Расширение применяют, если один вариант использования отличается от другого наличием некоторых дополнительных действий. В этом случае дополнительные действия определяют как отдельный вариант использования, который связан с основным вариантом связью типа «расширение». На рис. 1 приведены условные обозначения, которые применяют при изображении диаграмм вариантов использования. Рис. 1. Основные обозначения диаграммы вариантов использования: адействующее лицо, б – вариант использования, в – связь. Пример 1. Диаграмма вариантов использования для системы выполнения заданий и сохранения их в базе данных приведена на рис.2. У проектируемой системы одно действующее лицо — Пользователь. Он обращается к системе либо для выполнения нового задания, либо для просмотра результатов ранее выполненного задания. Вариант Выполнение задания включает несколько вариантов, различающихся способом определения данных (ввод с клавиатуры или чтение из базы) и сохранением введенных данных в базе. Эти варианты изображены на диаграмме как расширения основного варианта Выполнения задания. Помимо двух основных вариантов использования (Выполнение задания и Просмотр сохраненных результатов), система предусматривает вспомогательные прецеденты для удаления лишних данных и результатов из базы. Рис. 2. Диаграмма прецедентов для системы выполнения заданий и сохранения их результатов в базе данных Пример 2. Диаграмма вариантов использования для системы учета успеваемости студентов представлена на рис. 3. Действующими лицами системы являются Декан, Заместитель декана по курсу и Сотрудник деканата. Анализ вариантов использования показывает, что вариант получения сводки успеваемости по факультету включает в себя (использует) вариант получения сводки по курсу, что и представлено на диаграмме. Рис. 3. Диаграмма вариантов использования системы учета успеваемости студентов Диаграмму вариантов использования проектируемого программного обеспечения необходимо обсудить с заказчиком для определения как можно большего числа основных вариантов использования. Как правило, все варианты использования определить с первого раза не удается. Новые прецеденты добавляются постоянно, даже в процессе эксплуатации. Но, чем больше вариантов выявлено в процессе уточнения спецификаций, тем точнее полученная модель предметной области и меньше вероятность ее пересмотра. 3. Диаграммы классов 3.1. Назначение диаграмм классов Диаграмма классов (Static Structure diagram) показывает общую структуру иерархии классов системы, их атрибутов (полей), методов, коопераций, интерфейсов и взаимосвязей между ними. Понятие кооперации (collaboration) является одним из фундаментальных понятий в языке UML. Оно служит для обозначения множества объектов, взаимодействующих с определенной целью, в общем контексте моделируемой системы. Интерфейс (interface) — именованное множество операций, которые характеризуют поведение отдельного элемента модели. Интерфейс в контексте языка UML является специальным случаем класса, у которого имеются операции, но отсутствуют атрибуты. В нашем курсе представление коопераций и интерфейсов на uml-диаграммах классов не рассматривается UML предлагает использовать три уровня диаграмм классов в зависимости от степени их детализации: • уровень анализа (концептуальный уровень), на котором диаграммы классов демонстрируют связи между основными понятиями предметной области; • уровень проектирования (спецификаций), на котором диаграммы классов отображают связи классов предметной области; • уровень реализации, на котором диаграммы классов непосредственно показывают поля и методы конкретных классов в виде, наиболее удобном для реализации на выбранном языке программирования. Для моделей всех уровней используется одинаковая нотация построения диаграмм. 3.2. Некоторые элементы диаграммы классов На диаграмме классы представляются в виде прямоугольника, разделенного по вертикали на 3 части (см. рис. 4, на котором приведена диаграмма классов для примера 2 лекции 3). В первой (верхней) части пишется имя класса. Имя класса выравнивается по центру и оформляется полужирным шрифтом. Имя классов надо писать с заглавной буквы. Если класс абстрактный, то его имя пишется полужирным курсивом. Во второй части (посередине) располагаются поля (атрибуты) класса. Они выровнены по левому краю и начинаются с маленькой буквы. Третья (нижняя) часть содержит методы класса. Они также выровнены по левому краю и пишутся с маленькой буквы. В языке UML нет термина «виртуальный метод». Абстрактный метод в UML — это то же самое, что и виртуальный метод в Си++. Имена абстрактных методов оформляются курсивным шрифтом. Для задания уровня доступа (видимости) элементов класса перед именем элемента ставится один из символов: + для обозначения публичного (public) доступа, - для личного (private) доступа, # для защищенного (protected) доступа. Связи (отношения) между классами и объектами показываются линиями и стрелками, вид которых определяется типом связи. Pnt Crcl # x: int # y: int # color: int - r: int + Pnt(x: int, y: int, color: int) +move( dx:int, dy:int) + hide() + show() + Crcl(r: int) + hide() + show() Рис. 4. Пример диаграммы классов Отношение наследования показывается стрелкой с концом в виде пустого треугольника, идущей от производного класса к базовому классу (см. рис. 4 и рис. 5, а). Отношение наследования также называется отношением обобщения: класс-предок является более общим, чем класс-наследник. а г д б в 1..* 1..* е Рис. 5. Типы связей между классами: а обобщение (наследование); б – зависимость; в – ассоциация; г – агрегация; д – композиция; е – реализация. Рассмотрим другие связи между классами, существующие в языке UML. Связь зависимость представляет собой связь между двумя элементами модели, в которой изменение одного элемента (независимого) может привести к изменению семантики другого элемента (зависимого). Графически эта связь изображается пунктирной линией, иногда со стрелкой, направленной от зависимой сущности к определяющей (см. рис. 5, б). Зависимость – это связь использования, указывающая, что изменение спецификаций одной сущности может повлиять на другие сущности, которые используют ее. Отношение ассоциация показывает, что объекты одного класса связаны с объектами другой сущности таким образом, что можно перемещаться от объектов одного класса к объектам другого. Например, класс Ребенок и класс Школа имеют ассоциацию, так как ребенок может учиться в школе. Ассоциации можно присвоить имя, например, «учится в». Однонаправленная ассоциация изображается стрелкой, которая указывает направление ассоциации. Двусторонние ассоциации изображаются линией без стрелок. На концах линии ассоциации можно указать возможное количество связанных объектов. Количество объектов может быть указано так: 1 (один объект), 0..1 (ни одного или один объект), 0..* или просто * (любое количество объектов), 1..* (один или несколько), или любой диапазон целых чисел (2..5 – от двух до пяти включительно), или просто целое положительное число. Пример линии ассоциации представлен на рис. 5, в. Агрегация – особая разновидность ассоциации, представляющая структурную связь целого с его частями. Как тип ассоциации, агрегация может быть именованной. Причём, по умолчанию агрегацией называют агрегацию по ссылке, то есть когда время существования содержащихся классов не зависит от времени существования содержащего их класса. Если контейнер будет уничтожен, то его содержимое — нет. Графически агрегация представляется пустым ромбом на блоке класса «целое», и линией, идущей от этого ромба к классу «часть» (см. рис. 5, г ). Композиция представляет собой более строгий вариант агрегации. Ее также называют агрегацией по значению. Одно отношение агрегации не может включать более двух классов, как, например, контейнер и содержимое. Время жизни связанных классов в случае композиции совпадает. Если контейнер будет уничтожен, то всё его содержимое будет также уничтожено. Графически композиция представляется стрелкой с концом в виде закрашенного ромбика (см. рис. 5, д ). Отношение «реализация» – это семантическая связь между классами, когда один из них (поставщик) определяет соглашение, второй класс (клиент) обязан придерживаться этого соглашения. Отношение «реализация» используется для определения связи между интерфейсами и классами, которые реализуют эти интерфейсы. Поставщик, как правило, представлен абстрактным классом.