Практикум для выполнения лабораторных работ состоит из семнадцати лабораторных работ по дисциплинам Спецификация, архитектура и проектирование программных систем
 Скачать 2.9 Mb.
|
|
Основные элементы диаграммы классов Класс — служит для обозначения множества объектов, которые обладают одинаковой структурой, поведением и отношениями с объектами из других классов. Графически класс изображается в виде прямоугольника, который дополнительно может быть разделен горизонталь- ными линиями на секции. В этих секциях указываются имя класса, атрибуты (члены-данные) и операции (методы или член-функции). Обязательным элементов обозначения класса является его имя. На начальных этапах разработки диаграммы отдель- ные классы могут обозначаться простым прямоугольником с указанием только имени соответствующего класса. По мере проработки отдельных компонентов диаграммы, описания классов дополняются атрибутами и операциями. Ход работы Работа с классами в StarUML Для добавления нового класса на диаграмму классов ис- пользуйте инструмент «Класс» в панели инструментов ( рис. 9.2). Имя класса должно быть уникальным. 96 Рис. 9.2. Фрагмент панели инструментов. Инструмент «Класс» Обратите внимание, что все созданные классы добавля- ются в соответствующее представление модели (рис. 9.3). Если вы удалите класс на диаграмме, он останется в описании моде- ли. Это не позволит вам повторно создать класс с таким име- нем — возникнет ошибка конфликта имён («Name conflict»). Чтобы избежать этого, удалите «старый» класс из навигатора модели (воспользуйтесь контекстным меню). Рис. 9.3. Созданные классы и интерфейсы в навигаторе модели По умолчанию в классе показываются и операции и атри- буты. Чтобы изменить это и другие настройки внешнего вида классов воспользуйтесь меню Format (рис. 9.4). 97 Рис. 9.4. Меню Format В этом меню вы можете настроить шрифт, цвет линий и заливки (Font, Line Color, Fill Color), способ отображения сте- реотипа: в текстовом виде (например, «< Рис. 9.5. Способы отображения стереотипа Спрятать секцию операций можно с помощью пункта Suppress Operations, секцию атрибутов — с помощью пункта Suppress Attributes. Пункт Word Wrap Name позволяет писать имя класса в не- сколько строк. Пункт Show Parent Name добавляет имя родителя к имени класса (рис. 9.6). Это может быть полезно, например, для указания классов из других пакетов или представлений. ISimpleInterface ISimpleInterface < ISimpleInterface < 98 Рис. 9.6. Класс с составным именем Пункт Show Operation Signature переключает режим отображения сигнатуры операций (рис. 9.7). Рис. 9.7. Краткое и подробное отображение операций Пункт Show Properties управляет отображением характе- ристик (например, «{Frozen}»). Добавление атрибутов Добавить атрибуты классу можно несколькими спосо- бами (рис. 9.8): − нажать на пиктограмму во время редактирования име- ни класса; − редактировать коллекцию в менеджере свойств; − через контекстное меню Add. Атрибуты можно редактировать в текстовом или в визу- альном режиме. В текстовом режиме можно указывать свой- ства атрибутов (стереотип, видимость, тип, начальное значение) в формате отображения этих свойств. Например, «+Count:Integer = 0 {Frozen}» создаст публичный атрибут Count типа Integer с начальным значением 0. Визуальное редактирование осуществляется через мене- джер свойств (рис. 9.9). Каждому атрибуту можно назначить имя, стереотип, ви- димость, тип, начальное значение, характеристики: изменяе- мость, множественность, принадлежит ли атрибут классу или объекту. 99 а) б) в) Рис. 9.8. Добавление атрибутов и операций: а) пиктограммы во время редактирования имени; б) менеджер свойств; в) контекстное меню «Добавить» Добавление операций происходит аналогично. Свойства операций также можно редактировать либо в текстовом виде, либо через менеджер свойств. Кроме классов на диаграмме могут присутствовать ин- терфейсы и перечисления. Они создаются соответствующими инструментами на панели инструментов. По умолчанию ин- терфейс не показывает входящие в него операции, изменить это можно аналогично настройкам представления класса. Рис. 9.9. Менеджер свойств атрибута Связи и отношения. На диаграмме классов можно исполь- зовать следующие отношения (рис. 9.10): – ассоциация; – направленная ассоциация; – агрегация; – композиция; – обобщение; – зависимость; – реализация (связь между интерфейсом и классом); – связь между классом ассоциации и ассоциацией. Рис. 9. 10. Инструменты для создания связей Свойства связей нужно настраивать через менеджер свойств. В нём можно задать имя и стереотип связи, а также указать роли для каждого из участников, множественность, доступность и видимость ролей, добавить квалификаторы. Индивидуальные задания В соответствии с заданием лабораторной работы 3 раз- работать диаграмму классов для описания структуры выбран- ного решения. Контрольные вопросы 1. Что называют Визуальным моделированием? 2. Что такое модель? 3. Перечислите основные диаграммы UML. 4. Что такое StarUML? 5. Для чего применяются диаграммы классов? 6. Перечислите основные компоненты диаграммы классов. 101 Лабораторная работа 10. UML. Диаграммы объектов Цель работы Применить диаграмму объектов для описания структуры выбранного решения. Теоретические сведения Объект — экземпляр класса. Объект уникально идентифицируется значениями атрибу- тов, определяющими его состояние в данный момент времени. Объект, как и класс, обозначается прямоугольником, но его имя подчеркивается. Под словом «имя» здесь мы понимаем название объекта и наименование его класса, разделенные двоеточием. Для указания значений атрибутов объекта в его обозначении может быть предусмотрена специальная секция. Еще один нюанс состоит в том, что объект может быть ано- нимным: это нужно в том случае, если в данный момент не важно, какой именно объект данного класса принимает уча- стие во взаимодействии. Примеры объектов представлены на рис. 10.1. Рис. 10.1. Объекты Диаграммы объектов показывают множество объек- тов — экземпляров классов (изображенных на диаграмме классов) и отношений между ними в некоторый момент вре- мени. То есть диаграмма объектов — это своего рода снимок состояния системы в определенный момент времени, показы- вающий множество объектов, их состояния и отношения меж- ду ними в данный момент. Таким образом, диаграммы объектов представляют статический вид системы с точки зрения проектирования и процессов, являясь основой для сценариев, описываемых диа- граммами взаимодействия. 102 Диаграмма объектов используется для пояснения и дета- лизации диаграмм взаимодействия, например, диаграмм по- следовательностей. Примеры диаграммы объектов представлен на рис. 10.2 и рис. 10.3. Рис. 10.2. Диаграмма объектов «Продажи» Рис. 10. 3. Диаграмма объектов «Компания» На рис. 10.4 приведен пример диаграммы объектов учеб- ной среды «Робот» для Turbo Pascal. На диаграмме показано взаимодействие робота с окружающим миром, в который вхо- дят компоненты: элемент и две зоны. В свою очередь, компо- нент Зона содержит стены и дверь. Рис. 10.4. Диаграмма объектов учебной среды « Робот» для Turbo Pascal Индивидуальные задания В соответствии с заданием лабораторной работы 9 раз- работать диаграмму объектов для описания структуры вы- бранного решения. Контрольные вопросы 1. Что называют Визуальным моделированием? 2. Что такое модель? 3. Перечислите основные диаграммы UML. 4. Для чего применяются диаграммы объектов? 5. Перечислите основные компоненты диаграммы объ- ектов. 104 Лабораторная работа 11. UML. Диаграмма вариантов использования Цель работы Применить диаграмму вариантов использования для описания требований к разрабатываемой системе. Ознако- миться с инструментами, позволяющими строить UML диа- граммы. Теоретические сведения Общая информация. Визуальным моделированием (visual modeling) называется способ представления идей и проблем реального мира с помощью моделей. Модель — это абстракция, описывающая суть сложной проблемы или структуры без акцента на несущественных дета- лях, тем самым делая ее более понятной. Разработка программ- ного обеспечения — не исключение. При построении сложной системы строятся ее абстрактные визуальные модели. В настоящее время в области проектирования инфор- мационных систем с успехом применяется визуальное моделирование с помощью унифицированного языка моде- лирования UML. С помощью UML можно детально описать систему, начи- ная разработку с концептуальной модели с ее бизнес- функциями и процессами, а также описать особенности реали- зации системы, такие как классы программного обеспечения системы, схему базы данных. Моделирование с помощью UML осуществляется по- этапным построением ряда диаграмм, каждая из которых отражает какую-то часть или сторону системы либо ее за- мысла. Основные диаграммы UML: 1) вариантов использования (use case diagram); 2) классов (class diagram); 3) кооперации (collaboration diagram); 4) последовательности (sequence diagram); 5) состояний (statechart diagram); 6) деятельности (activity diagram); 105 7) компонентов (component diagram); 8) развертывания (deployment diagram). Для сопровождения процесса построения, анализа и до- кументирования модели, а также проверки модели и генера- ции программных кодов разработчики используют специально для этих целей созданные CASE-инструменты проектирования систем. CASE (Computer-Aided Software Engineering) — это набор инструментов и методов программной инженерии для проек- тирования программного обеспечения, цель которого — обес- печить высокое качество программ, отсутствие ошибок и простоту в обслуживании программных продуктов. Для выполнения лабораторных работ можно использо- вать любой графический редактор, поддерживающий нотацию UML, или специализированные CASE средства. Рекомендован- ным инструментом является свободное программное средство StarUML. Перед началом работы в StarUML Для того, чтобы избежать проблем с автоматическим по- строением диаграммы взаимодействия на основе диаграмм последовательности, перед началом работы (созданием проек- та) требуется установить в качестве используемого в системе разделителя целой и дробной части точку («.»). Изменить эту настройку можно в перейдя в Панель управления/Языки и региональные стандарты/Форматы/Дополнительные пара- метры/Разделитель целой и дробной части. Такое требование связано с неправильным использованием языковых стандар- тов разработчиками StarUML. Создание нового проекта. Основная структурная единица в StarUML — это проект. Проект сохраняется в одном файле в формате XML с расширением «.uml». Проект может содержать одну или несколько моделей. Структура модели (набор реко- мендованных диаграмм и их группировка) определяется вы- бранной методологией. StarUML поддерживает несколько распространённых методологий: 4+1 View Model, Методология Rational, UML Component и подход StarUML (рис. 11.1). Восполь- зуемся методологией Rational. 106 Главное окно StarUML В верхней части окна расположено главное меню, кнопки быстрого доступа. Слева расположена панель элементов (Toolbox) с изображениями элементов диаграммы. Набор иснтрументов зависит от выбранной диаграммы. В центре нахо- дится рабочее поле диаграммы — область для создания диа- граммы. Справа находится инспектор модели, на котором можно найти вкладки навигатора модели (Model Explorer), навигатора диаграмм (Diagram explorer), окно редактора свойств (Properties), окно документирования элементов модели (Documentation) и редактор вложений (Attachments) (рис. 11.2). Рис. 11.1. Окно выбора типа проекта В зависимости от выбранного подхода на навигаторе мо- дели будут отображены различные пакеты представлений модели. Каждый пакет представления будет содержать эле- менты моделей и диаграмм, которые мы создадим. Подход Rational предлагает нам следующие представле- ния модели: ‒ Use Case View — представление требований к системе, описывает, что система должна делать; ‒ Logical View — логическое представление системы, описывает, как система должна быть построена; 107 ‒ Component View — представление реализации, описы- вает зависимость между программными компонентами; ‒ Deployment View — представление развертывания, опи- сывает аппаратные элементы, устройства и программные компоненты и размещение компонентов. Рис. 11.2. Главное окно StarUML Диаграмма вариантов использования. Поведение системы (функции, которые она выполняет) описывают с помощью функ- циональной модели, которая отображает варианты использова- ния (use cases, системные прецеденты), системное окружение (действующих лиц, актеров, actors) и связи между ними. Диаграмма вариантов использования — это диаграмма, на которой изображаются отношения между актерами и вари- антами использования. С помощью этой диаграммы можно: – определить общие границы и контекст моделируемой предметной области на начальных этапах проектирования системы; – сформулировать общие требования к функционально- му поведению проектируемой системы; – разработать исходную концептуальную модель систе- мы для ее последующей детализации в форме логических и физических моделей; 108 – подготовить исходную документацию для взаимодей- ствия разработчиков системы с ее заказчиками и пользовате- лями. Диаграмма вариантов использования (прецедентов) представляет собой граф, в вершинах которого расположены актеры или прецеденты, связи между вершинами — это разно- го вида отношения. Актером(действующее лицо, actor) называется любой объект, субъект или система, взаимодействующая с моделиру- емой системой извне. Это может быть человек, техническое устройство, программа или любая другая система, которая служит источником воздействия на моделируемую систему так, как определит разработчик. На диаграммах вариантов использования актер изобра- жается в виде человечка, под которым записывается его имя ( рис. 11.3). Рис. 11. 3. Действующее лицо Вариант использования (прецедент, use case) — описание множества последовательности действий (включая варианты), выполняемых системой для того, чтобы актер мог получить определенный результат. Каждый вариант использования должен быть независи- мым в том смысле, что если он всегда выполняется совместно с другим вариантом использования, то, скорее всего, это один прецедент, а не два, либо они связаны отношением включения или расширения, о чем речь пойдет позже. Актер должен получить некоторый результат по завер- шению исполнения прецедента. Например, после исполнения прецедента в системе произойдут некоторые изменения: по- явятся новые данные, изменится поведение. Каждый вариант использования описывает законченный процесс, переводящий систему из состояния готовности в новое состояние готовности. Вариант использования не может Препод аватель 109 прерываться — он должен исполняться от начала до конца. По завершению одного варианта использования может начаться любой другой вариант использования (т. е. эта диаграмма не показывает порядок действий, только набор возможных пре- цедентов). Прецедент описывает, что делает система, но никак не уточняет, как она это делает. На диаграмме прецедент изображается в виде эллипса. Имя прецедента может состоять из нескольких слов и знаков препинания (за исключением двоеточия), как правило, имя выбирают в виде словосочетания или глагольного выражения ( рис. 11.4). Рис. 11.4. Варианты использования Одним из наиболее важных (и дорогостоящих) этапов проектирования информационных систем является этап опре- деления требований к системе. Если требования заказчика информационной системы разработчиками будут определены не корректно, то в итоге заказчик может получить совсем не ту систему, которую он ожидал. Моделирование прецедентов и актеров помогает нам лучше понять требования, предъявляемые к системе, и согла- совать их с заказчиком с помощью демонстрации и обсуждения диаграммы прецедентов. Прецеденты и актеры — это отраже- ние требований к системе, они показывают, кто и для чего будет использовать будущую систему. Рассмотрим пример. Требуется разработать комплекс «Автоматизированное рабочее место преподавателя». В зада- чи комплекса входит обеспечение следующих возможностей: – составление и редактирования графика лабораторных работ; – отмечание успешных и проваленных попыток сдачи ла- бораторных работ студентами; – указывать темы РГР, курсовых работ и проектов; Выд ать лабораторную работу Отметить прогресс сд ачи лаб.работы 110 – следить за текущей успеваемостью в разрезе группы, курса (для заведующего кафедрой) и факультета (для декана); – отмечать пропуски на лабораторных занятиях и лекциях; – запрашивать списки групп из автоматизированной си- стемы «Деканат». Проанализировав постановку задачи, приходим к выводу, что будет полезно выделить следующие действующие лица: – преподаватель — преподаватель, ведущий практиче- ские занятия и лабораторные; – лектор — преподаватель, ведущий лекции; – руководитель — заведующие кафедрами, деканы; – ассистент — ответственный за ввод данных в систему; – АС «Деканат» — сервис автоматизированной системы «Деканат». Обратите внимание, что актер — это роль, а не конкретный представитель этой роли. Например, в разное время заведующий кафедрой может выступать в роли лектора, преподавателя, ве- дущего практические занятия или руководителя. Теперь выделим варианты использования на основе пе- речисленных функциональных требований: – работа с графиком лабораторных работ; – отмечание успеваемости; – указание тем РГР, курсовых работ и проектов; – отмечание посещения лекций; – отмечание посещения лаб.работ; – загрузка списков групп; – создание лабораторных работ; – создание РГР, курсовых работ и проектов; – построение отчётов успеваемости и посещаемости. |