Старое ПППП / Лабораторная работа №1. UML / Лабораторная работа №1. UML

Практикум по промышленному программированию ­ 2015. Лабораторная работа №1

Безусловно, в этом примере можно сделать еще много уточнений и усовершенствований, прежде чем на основе полученной архитектуры можно будет сделать рабочий проект.

Создание диаграммы последовательностей

Создадим в этом же проекте (модуле) файл диаграммы последовательностей.

Имя диаграммы: LibrarySequenceDiagram. Так как это диаграмма последовательности, то с помощью её мы сможем показать, какова же последовательность действий в проектируемой системе. Иначе говоря, что же будет делать система при наступлении той или иной ситуации?

Разработаем две диаграммы последовательности: одну для сценария нахождения чего­либо в библиотеке по его имени (name), вторую для сценария удаления чего­либо из библиотеки по идентификатору (ID).

Полную информацию о спецификации PlantUML для диаграмм последовательностей можно посмотреть в файле PlantUML_Language_Reference_Guide или по адресу http://plantuml.sourceforge.net/sequence.html.

Сценарий нахождения чего-либо в библиотеке по имени

Сначала необходимо определить объекты, которые посылают друг другу сообщение (иначе говоря, вызывают или каким­либо образом используют друг друга). Когда в классе Library вызывается функция findEntityByName(), то эта функция будет брать список всех сущностей LibraryEntityList, хранящихся в библиотеке, и выполнять в нем поиск. Почему этот список сущностей не был указан в атрибутах в диаграмме классов? Потому что этот список там представлен в виде двусторонней ассоциации. Поэтому имя этого списка будет в диаграмме последовательности, но не будет в диаграмме классов.

Функция findEntityByName() будет вызываться классом­клиентом библиотеки LibraryClient, которого также не было на диаграмме классов. Таким образом, можно написать следующий код, отображающийся в

UML.

@startuml

LibraryClient ­> Library : findEntityByName(name : String) Library ­> LibraryEntityList : getEntity LibraryEntityList ­> Library: anEntity

@enduml

­31­

Практикум по промышленному программированию ­ 2015. Лабораторная работа №1

В диаграмме происходит следующее: LibraryClient вызывает у Library метод findEntityByName, Library запрашивает у списка LibraryEntityList одну сущность, и эта сущность передается библиотеке.

Так как при поиске необходимого элемента в библиотеке происходит перебор всех элементов, то в диаграмме необходимо отобразить, что этот процесс происходит в цикле. Также нужно указать, что каждый раз после возврата элемента из списка происходит проверка на соответствие поисковой строке.

@startuml

LibraryClient ­> Library : findEntityByName(name : String) loop all entities in list

Library ­> LibraryEntityList : getEntity LibraryEntityList ­> Library : anEntity alt anEntity.name == name

Library ­> LibraryClient : anEntity

end end @enduml

Однако по такой диаграмме последовательности становится понятно, что в LibraryClient будут “возвращаться” много элементов библиотеки, если они будут подходить под поисковый запрос. Значит, необходимо возвращать результаты запроса не отдельными элементами (классу­клиенту обрабатывать большое количество результатов неудобно), а отдельным классом ResultEntityList. Значит, каждый раз, когда полученный из списка anEntity будет удовлетворять запросу, он будет отправляться в ResultEntityList, а по завершении цикла, список результатов ResultEntityList будет возвращен клиенту

LibraryClient.

@startuml

LibraryClient ­> Library : findEntityByName(name : String) loop all entities in list

Library ­> LibraryEntityList : getEntity LibraryEntityList ­> Library : anEntity alt anEntity.name == name

Library ­> ResultEntityList : anEntity

end end

ResultEntityList ­> LibraryClient : resultList @enduml

­32­

Практикум по промышленному программированию ­ 2015. Лабораторная работа №1

Сценарий удаления чего-либо из библиотеки по идентификатору

Клиент библиотеки посылает библиотеке запрос на удаление элемента из библиотеки. Класс библиотеки просматривает весь список своих элементов и ищет такой элемент, ID которого совпадает с запрашиваемым. Если такой элемент находится (используется фрейм alt), то из списка этот элемент удаляется, а клиенту возвращается значение true (элемент на самом деле удален). Если же в списке не было найдено никакого подходящего элемента, то никакого элемента не было удалено, и клиенту возвращается значение false.

@startuml

LibraryClient ­> Library : deleteEntity(id : long) loop all elements in list

Library ­> LibraryEntityList : getEntity LibraryEntityList ­> Library : anEntity alt anEntity.id == id

Library ­> LibraryEntityList : deleteFromList(entity : LibraryEntity) Library ­> LibraryClient : true

end end

Library ­> LibraryClient : false @enduml

­33­

Практикум по промышленному программированию ­ 2015. Лабораторная работа №1

Коррекция диаграммы классов

После создания диаграмм последовательностей, стало ясно, что диаграмма классов нуждается в доработке: появился класс LibraryClient, который связан отношением зависимости с классом Library. Изменились возвращаемые значения в операциях поиска в классе Library.

@startuml

skinparam classAttributeIconSize 0

interface LibraryEntity { +getID() : long +getName() : String

}

abstract class AbstractBook { ­ID : long

­name : String

}

class Book { ­ISBN : String

­author : String [1..*] ­year : int

}

class Magazine { ­datePublication: LocalDate ­publisher : String

}

note right: LocalDate is from DateTime API in Java 8

class Library { ­numberOfEntities : long ­name : String

+findEntityByName(name : String) : ResultEntityList +findEntityByID(id : long) : ResultEntityList +addNewEntity(entity : LibraryEntity) : boolean +deleteEntity(id : long) : boolean

}

class LibraryClient

LibraryEntity "0..*" <­­> "1" Library

LibraryEntity <|.. AbstractBook

AbstractBook <|­­ Book

AbstractBook <|­­ Magazine

LibraryClient ..> Library @enduml

­34­

Практикум по промышленному программированию ­ 2015. Лабораторная работа №1

Задания для самостоятельной работы

В каждом варианте необходимо разработать начальную архитектуру проекта. Архитектура должна быть представлена в виде диаграммы классов и двух диаграмм последовательности, представляющих наиболее сложные к пониманию взаимодействия составляющих проект сущностей.

Вариант №1, 16

Проект “Управление магазином сладостей”.

Вариант №2, 17

Проект “Расписание железнодорожной станции”.

Вариант №3, 18

Проект “Рисование геометрических фигур”.

Вариант №4, 19

Проект “Редактирование видеофайлов”.

Вариант №5, 20

Проект “Электронная зачетная книжка”.

Вариант №6, 21

Проект “Хранитель паролей”.

Вариант №7, 22

Проект “Расчет скидок” для магазина электронной техники.

Вариант №8, 23

Проект “Управление установленными приложениями”.

Вариант №9, 24

Проект “Модель Солнечной системы”.

­35­

Практикум по промышленному программированию ­ 2015. Лабораторная работа №1

Вариант №10, 25

Проект “Магазин электронных книг”.

Вариант №11, 26

Проект “Расписание школьных уроков”.

Вариант №12, 27

Проект “Электронный школьный дневник”.

Вариант №13, 28

Проект “Текстовый редактор”.

Вариант №14, 29

Проект “Справочник болезней”.

Вариант №15, 30

Проект “Управление закладками”.

Литература, ссылки

1.Фаулер M. UML. Основы, 3е издание. – Пер. с англ. – СПб: СимволПлюс, 2004. – 192 с., ил.

2.Иванов Д. Ю., Новиков Ф. А. Основы моделирования на UML: Учеб. пособие. – СПб.: Изд­во Политехн. ун­та, 2010. – 249с.

3.https://ru.wikipedia.org/wiki/UML

4.https://ru.wikipedia.org/wiki/%C4%E8%E0%E3%F0%E0%EC%EC%E0_%EA%EB%E0%F1%F1% EE%E2

5.https://ru.wikipedia.org/wiki/IntelliJ_IDEA

6.http://blog.gelin.ru/2014/02/plantuml.html

7.http://plantuml.sourceforge.net/PlantUML_Language_Reference_Guide.pdf

­36­