Методы и средства разработки И. Томский политехнический университет р. В. Ковин, Е. А. Мирошниченко
 Скачать 2.85 Mb.
|
|
компонентов Существует большое количество инструментальных средств для создания диаграммы UML 3 . По целевой платформе их можно разделить на настольные приложения и онлайн-редакторы. Среди настольных приложений выделим, конечно, Microsoft Visio. Однако эта система является платной. Многие онлайн-редакторы имеют бесплатный тариф, возможностей которого зачастую достаточно для создания диаграмм. Например, в редакторе Visual Paradigm Online Diagrams 3 См. List of Unified Modeling Language tools // https://en.wikipedia.org/wiki/List_of_Unified_Modeling_Language_tools 34 ( https://online.visual-paradigm.com/ ) можно создавать разные типы диаграмм UML, включая диаграмму компонентов (рис. 4.5). Однако в бесплатной версии системы при экспорте результатов в файл или буфер обмена добавляются водяные знаки о бесплатном тарифе. Рис. 4.5. Онлайн-редактор Visual Paradigm Online Diagrams Созданные диаграммы компонентов могут добавляться в различные технические документы, такие как эскизный и технический проекты в виде изображений. При этом важно добавлять диаграммы с высоким качеством. Рекомендуется использовать векторный формат изображений. 4.2. ПРАКТИЧЕСКАЯ ЧАСТЬ 4.2.1. Практическое задание В качестве практического задания необходимо создать диаграмму компонентов для системы, создаваемой студентом в рамках индивидуального задания на дисциплину. 4.2.2. Список контрольных вопросов для самопроверки 1. Для чего создается диаграмма компонентов? 35 2. С помощью каких элементов на диаграмме можно показать классы объектов? 3. Как на диаграмме можно показать экземпляры классов объектов? 4.3. ТРЕБОВАНИЯ К ОТЧЕТУ Отчет должен содержать следующие разделы: 1. Титульный лист, оформленный согласно утвержденному образцу. 2. Цели и задачи выполняемой лабораторной работы. 3. Пошаговое описание выполняемых заданий лабораторной работы: 4. Ответы на контрольные вопросы. 5. Заключение. 36 5. ЛАБОРАТОРНАЯ РАБОТА №5. Диаграммы UML. Диаграмма последовательности ЦЕЛЬ РАБОТЫ Изучение и получение навыков создания диаграммы последовательности. Введение Диаграмма последовательности (англ. sequence diagram) — диаграмма в языке UML, на которой для некоторого набора объектов на единой временной оси показан жизненный цикл какого-либо определённого объекта и взаимодействие акторов ИС в рамках какого-либо определённого прецедента. Диаграмма взаимодействия предназначена для моделирования отношений между объектами (ролями, классами, компонентами) системы в рамках одного прецедента (ВИ). Данный вид диаграмм отражает следующие аспекты проектируемой системы: • обмен сообщениями между объектами (в том числе в рамках обмена сообщениями со сторонними системами); • ограничения, накладываемые на взаимодействие объектов; • события, инициирующие взаимодействия объектов. 5.1. ТЕОРЕТИЧЕСКАЯ ЧАСТЬ Диаграмма последовательности является одной из разновидности диаграмм взаимодействия и предназначена для моделирования взаимодействия объектов Системы во времени, а также обмена сообщениями между ними. Одним из основных принципов ООП является способ информационного обмена между элементами системы, выражающийся в отправке и получении сообщений друг от друга. Таким образом, основные понятия диаграммы последовательности связаны с понятием Объект и Сообщение. 5.1.1. Объекты На диаграмме последовательности объекты в основном представляю экземпляры класса или сущности, обладающие поведением. В качестве объектов 37 могут выступать пользователи, инициирующие взаимодействие, классы, обладающие поведением в системе или программные компоненты, а иногда и системы в целом. Если объект представляется на уровне типа, то в качестве его имени записывается только имя типа с заглавной буквы. Если же компонент представляется на уровне экземпляра (instance), то в качестве его имени записывается <имя компонента ':' имя типа>. При этом вся строка имени подчеркивается. Объекты располагаются слева направо таким образом, чтобы крайним слева был тот объект, который инициирует взаимодействие. Неотъемлемой частью объекта на диаграмме последовательности является линия жизни объекта. Линия жизни показывает время, в течение которого объект существует в системе. Периоды активности объекта в момент взаимодействия показываются с помощью фокуса управления. Временнáя шкала на диаграмме направлена сверху вниз (рис. 5.1). Рис. 5.1. Диаграмма последовательности Объекты могут быть созданы в процессе взаимодействия. Их время жизни начинается с получения сообщения create, направленного к прямоугольнику объекта в начале жизненного пути. Равным образом в процессе взаимодействия объекты 38 могут уничтожаться. Их линия жизни заканчивается при получении сообщения destroy, что графически отмечено большим символом X (рис. 5.1). Если взаимодействие отражает историю конкретных объектов, то символ объекта с подчеркнутым именем размещается в начале линии жизни. 5.1.2. Сообщения Основное содержимое диаграммы последовательности — сообщения. Они изображаются стрелками, направленными от одной линии жизни к другой. Стрелка указывает на приемник сообщения. Если сообщение асинхронно, то стрелка рисуется «уголком», а если синхронно (вызов), то закрашенным треугольником. Ответ на синхронное сообщение (возврат из вызова) показывается пунктирной стрелкой «уголком» (рис. 5.1.. Существуют и другие виды сообщений. 5.1.3. Рекомендации по построению диаграммы последовательности Подробнее о построении диаграммы последовательности можно прочитать по ссылке https://www.omg.org/spec/UML/2.1.2/Superstructure/PDF и в книге Гради Буч, Джеймс Рамбо, Ивар Якобсон. Язык UML. Руководство пользователя. 5.1.4. Инструментальные средства для создания диаграммы последовательности Существует большое количество инструментальных средств для создания диаграмм UML 4 . По целевой платформе их можно разделить на настольные приложения и онлайн-редакторы. Среди настольных приложений выделим, конечно, Microsoft Visio. Однако эта система является платной. Многие онлайн-редакторы имеют бесплатный тариф, возможностей которого зачастую достаточно для создания диаграмм. Например, в редакторе Visual Paradigm Online Diagrams ( https://online.visual-paradigm.com/ ) можно создавать разные типы диаграмм UML, 4 См. List of Unified Modeling Language tools // https://en.wikipedia.org/wiki/List_of_Unified_Modeling_Language_tools 39 включая диаграмму последовательности (рис. 5.2). Однако в бесплатной версии системы при экспорте результатов в файл или буфер обмена добавляются водяные знаки о бесплатном тарифе. Рис. 5.2. Онлайн-редактор Visual Paradigm Online Diagrams Созданные диаграммы последовательности могут добавляться в различные технические документы, такие как эскизный и технический проекты в виде изображений. При этом важно добавлять диаграммы с высоким качеством. Рекомендуется использовать векторный формат изображений. 5.2. ПРАКТИЧЕСКАЯ ЧАСТЬ 5.2.1. Практическое задание В качестве практического задания необходимо создать диаграммы последовательностей для ключевых вариантов использования (прецендентов) системы, создаваемой студентом в рамках индивидуального задания на дисциплину. Список ключевых вариантов использования должен быть согласован с преподавателем. 40 5.2.2. Список контрольных вопросов для самопроверки 1. Для чего создается диаграмма последовательности? 2. Скольким вариантам использования соответствует диаграмма последовательности? 3. Что может выступать в качестве объектов на диаграмме последовательности? 5.3. ТРЕБОВАНИЯ К ОТЧЕТУ Отчет должен содержать следующие разделы: 1. Титульный лист, оформленный согласно утвержденному образцу. 2. Цели и задачи выполняемой лабораторной работы. 3. Пошаговое описание выполняемых заданий лабораторной работы: 4. Ответы на контрольные вопросы. 5. Заключение. 41 6. ЛАБОРАТОРНАЯ РАБОТА №6. Проектирование БД. ER-модель ЦЕЛЬ РАБОТЫ Изучение и получение навыков проектирования баз данных. Введение Проектирование баз данных — процесс создания схемы базы данных и определения необходимых ограничений целостности. В данной лабораторной работе рассматриваются основные этапы проектирования БД, основные нотации, используемые для описания моделей БД. 6.1. ТЕОРЕТИЧЕСКАЯ ЧАСТЬ 6.1.1. Понятие базы данных База данных — совокупность данных, хранимых в соответствии со схемой данных, манипулирование которыми выполняют в соответствии с правилами средств моделирования данных (ГОСТ Р ИСО МЭК ТО 10032-2007: Эталонная модель управления данными = ISO/IEC TR 10032:2003 Information technology — Reference model of data management). База данных — совокупность данных, организованных в соответствии с концептуальной структурой, описывающей характеристики этих данных и взаимоотношения между ними, причём такое собрание данных, которое поддерживает одну или более областей применения (ISO/IEC 2382:2015 Information technology —Vocabulary). Постоянные данные в среде базы данных включают в себя схему и базу данных. Схема включает в себя описания содержания, структуры и ограничений целостности, используемые для создания и поддержки базы данных. База данных включает в себя набор постоянных данных, определённых с помощью схемы. (ISO/IEC TR 10032:2003). БД классифицируют по различным критериям: по модели данных, по среде постоянного хранения, по содержимому и др. Система управления базами данных (СУБД, англ. DBMS) — совокупность программных и лингвистических средств общего или специального назначения, 42 обеспечивающих управление созданием и использованием баз данных (ISO/IEC TR 10032:2003). Важно понимать, что СУБД — это та часть информационной системы, которая скрывает детали физического хранения на носителях, позволяя работать с БД на уровне логических концепций (модели данных). 6.1.2. Этапы проектирования модели БД При проектировании БД используются следующие уровни абстракции: • Описание предметной области (текст, спецификации, «на пальцах»). • Формальная модель предметной области (семантическая/концептуальная схема/модель). • Конкретная схема в рамках выбранной модели данных (логическая схема/модель). • Конкретная схема в рамках выбранной СУБД (физическая схема/модель). • БД как то, к чему адресуются запросы (БД на уровне представления, на логическом уровне). • БД как файлы, байты (БД на уровне реализации, на физическом уровне). • БД как материальный объект (уровень носителя: жёсткий диск, флэш-карта). На начальном этапе проектирования БД производится описание предметной области. Обычно это осуществляется в произвольной текстовой форме, нередко со слов заказчика: Хочу создать базу данных «кулинарная книга». В неё буду вносить точные рецепты (чего и сколько), и чтобы их можно было распределять по категориям (салаты, напитки и т.п.). Да, и чтобы я могла сделать что-то вроде: «Выдай-ка мне все рецепты, в которых используется сельдерей». Выделяют следующие этапы проектирования модели БД: 1. Формальная модель предметной области (семантическая/ концептуальная схема/модель). 43 2. Конкретная схема в рамках выбранной модели данных (логическая схема/модель). 3. Конкретная схема в рамках выбранной СУБД (физическая схема/модель). Для уточнения концептуальной схемы/модели БД нужно: • формализовать «язык» моделирования (средство), которым описывать модель БД (результат); • нужна графическая нотация, чтобы рисовать. Примеры семантических моделей (средств моделирования): • Модель «сущность — связь», Entity-Relationship Model, ER-Model, ER-Модель. • Модель UML (Unified Modeling Language). 6.1.3. ER- модель ER-модель в 1976 г. предложил Петер Пин-Шен Чен (Peter Pin-Shan Chen). Модель стала наиболее популярным средством формального описания концептуальных схем БД. Основные элементы: • сущность (entity); • атрибут, свойство (property); • связь (relationship). Сущность (entity) Сущность — это некоторый различимый тип объекта. Например: рецепт, категория, ингредиент, количество. Сущность имеет свойства. Например: название блюда, значение, единица измерения. Сущность потенциально состоит из множества экземпляров. Например: рецепт салата «Оливье», рецепт торта «Наполеон». Атрибут, свойство (property) • Имеет название. • Имеет тип (data type, domain). • У экземпляра сущности имеет значение (value). • Имеет признак обязательности значения (mandatory). 44 • Может иметь правила (ограничения на значения, ограничения целостности). • Может иметь значение по умолчанию (default value). • Может быть идентификатором или входить в составной идентификатор: o основной (первичный) идентификатор (primary identifier) o неосновной (альтернативный) идентификатор (alternative identifier). Связь (relationship) Связь — это нечто, что связывает две или более сущностей: поставщик—товар, работник—отдел, супруг—супруга, студент— предмет—семестр… В отличие от сущности связь не имеет собственных свойств. Тип (мощность) связи характеризует, сколько может быть экземпляров сущностей — участников связи: • один к одному (1:1); • один ко многим (1:N) или многие к одному (N:1); • многие ко многим (N:M). Обязательность связи данной сущности характеризует, должен ли в неё обязательно входить хотя бы один экземпляр этой сущности. Сильные (обычные) и слабые сущности Сильная (обычная) сущность имеет естественный идентификатор, который однозначно отличает её экземпляры. Слабая (зависимая) сущность не имеет такого естественного идентификатора, и её экземпляры уникальны только вместе со связью с экземпляром сильной сущности (или нескольких) и не могут существовать без связи с экземпляром сильной сущности (или нескольких). Пример: Сущность Дом (Город, Улица, Номер, Материал, Количество_этажей) Сущность Квартира (Номер, Этаж, Количество_комнат, Общая площадь) Связь Дом—Квартира Здесь Дом — сильная сущность, Квартира — слабая сущность. Идентифицирующая связь Неидентифицирующая (обычная) связь связывает независимые (обычные) сущности. Идентифицирующая связь связывает слабую сущность с нужной её сильной. 45 6.1.4. ER- модель: нотации Существую разные нотации ER-модели: • Нотация Чена; • Нотация Crow’s Foot; • UML; • и др. Нотация Чена В нотации Чена Множества сущность изображается в виде прямоугольника, отношение между сущностями изображается в виде ромба. Если сущности участвует в отношении, они связаны линией. Если отношение не является обязательным, то линия пунктирная. Мощность отношения подписывается у концов линии. Атрибуты изображаются в виде овалов и связываются линией с одним отношением или с одной сущностью (рис. 6.1). Рис. 6.1. Нотация Чена Нотация Crow’s Foot В этой нотации сущность изображается в виде прямоугольника, содержащего её имя, выражаемое существительным. Имя сущности должно быть уникальным в 46 рамках одной модели. При этом имя сущности — это имя типа, а не конкретного экземпляра данного типа. Связь изображается линией, которая связывает две сущности, участвующие в отношении. Мощность конца связи указывается графически, множественность связи изображается в виде «вилки» на конце связи. Модальность (обязательность) связи также изображается графически: необязательность связи помечается кружком на конце связи, обязательность — вертикальной черточкой. Атрибуты сущности записываются внутри прямоугольника, изображающего сущность, и выражаются существительным в единственном числе (рис. 6.2). Рис. 6.2. Нотация Crow’s Foot 6.1.5. Инструменты проектирования БД Существует большое количество инструментов проектирования БД. Выделим некоторые часто упоминаемые: • PowerDesigner (SAP); • Toad Data Modeler (Quest Software) ( https://www.toadworld.com/download/toad- data-modeler/freeware ); • ERwin Data Modeler (erwin, Inc.). 47 Список современных инструментов проектирования БД и сравнение их функциональности можно увидеть в статье «Comparison of data modeling tools» ( https://en.wikipedia.org/wiki/Comparison_of_data_modeling_tools ). 6.2. ПРАКТИЧЕСКАЯ ЧАСТЬ 6.2.1. Практическое задание В качестве практического задания необходимо создать ER-диаграмму в нотации Чена, отражающую модель «сущность-связь» предметной области, для которой предназначена разрабатываемая студентом система. Для рисования можно использовать как встроенный векторный редактор в Microsoft Word, так и специализированные редакторы (см. п. 6.1.5). При выполнении задания использовать результаты лабораторных работ № 1—3. 6.2.2. Список контрольных вопросов для самопроверки 1. Какие могут быть источники для описания предметной области? 2. Чем отличаются представления модели на логическом и физическом уровнях? 3. Что характеризует обязательность связи сущности? 6.3. ТРЕБОВАНИЯ К ОТЧЕТУ Отчет должен содержать следующие разделы: 1. Титульный лист, оформленный согласно утвержденному образцу. 2. Цели и задачи выполняемой лабораторной работы. 3. Пошаговое описание выполняемых заданий лабораторной работы: 4. Ответы на контрольные вопросы. 5. Заключение. |