Модели и методы проектирования информационных
 Скачать 1.48 Mb.
|
|
Класс Client: Параметр Значение Комментарий Класс, представляющий собой клиента фирмы Атрибуты name : String - наименование клиента address : String - адрес клиента phone : String - телефон клиента Все атрибуты имеют модификатор доступа - private Операции AddClient() - добавление нового клиента RemoveClient() - удаление существующего клиента GetInfo() - получить информацию о клиенте Все операции имеют модификатор доступа - public 61 Класс Order: Параметр Значение Комментарий Класс, представляющий собой заказ, который делает клиент Атрибуты orderNumber : Integer - номер заказа orderDate : Date - дата оформления заказа orderComplete : Date - дата выполнения заказа Все атрибуты имеют модификатор доступа - private Операции Create() - создание нового заказа SetInfo() - занести информацию о заказе GetInfo() - получить информацию о заказе Все операции имеют модификатор доступа - public Класс OrderItem: Параметр Значение Комментарий Класс, представляющий собой пункт заказа, который делает клиент Атрибуты itemNumber : Integer - номер пункта заказа quantity : Integer - количество комплектующих изделий price : Double - цена за единицу Все атрибуты имеют модификатор доступа - private Операции Create() - создание новой строки заказа SetInfo() - занести информацию о строке заказа GetInfo() - получить информацию о строке заказа Все операции имеют модификатор доступа - public 62 Класс ComponentPart: Параметр Значение Комментарий Класс, представляющий собой комплектующие изделия Атрибуты name : String - наименование manufacturer : String - производитель price : Double - цена за единицу description - описание Все атрибуты имеют модификатор доступа - private Операции AddComponent() - добавление нового комплектующего изделия RemoveComponent() - удаление комплектующего изделия GetInfo() - получить информацию о комплектующем изделии Все операции имеют модификатор доступа - public Результат создания классов-сущностей показан на рис. 5.1: Рис. 5.1. Созданные классы-сущности Добавим отношения между классами (рис. 5.2): 63 класс Client и Order - отношение ассоциации, поскольку данные два класса просто связаны друг с другом и никакие другие типы связей здесь применить нельзя. Один клиент может сделать несколько заказов, каждый заказ поступает только от одного клиента, поэтому кратность связи со стороны класса Client - 1, со стороны Order - 1..n; класс Order и OrderItem - отношение композиции, поскольку строка заказа является частью заказа, и без него существовать не может. В один заказ может входить несколько строк заказа, строка заказа относится только к одному заказу, поэтому кратность связи со стороны Order - 1, со стороны OrderItem - 1..n; класс OrderItem и ComponentPart - отношение агрегации, поскольку комплектующие изделия являются частями строки заказа, но и те, и другие, явлюятся самостоятельными классами. Одно комплектующее изделие может входить во много строк заказа, в одну строку заказа входит только одно комплектующее изделие, поэтому кратность связи со стороны ComponentPart - 1, со стороны OrderItem - 1..n. 64 Рис. 5.2. Классы-сущности и отношения между ними Добавим теперь на диаграмму граничные и управляющие классы (рис. 5.3). Рассматриваемый сценарий - это только одно из действий, которые обеспечивает прецедент "Работа с заказом". Прецедент также позволяет просмотреть, отредактировать или удалить заказ. Это означает, что необходимо предусмотреть механизм, который позволяет выбирать необходимое действие. Создадим для этого граничный класс OrderOptions (Параметры работы с заказом) с комментарием "Класс, обеспечивающий механизм работы с заказами". Также создадим граничный класс AddNewOrder (Добавление нового заказа), который будет служить для добавления новых заказов (комментарий - "Класс служит для добавления новых заказов"). Отношение между этими классами - агрегация, поскольку в данном случае класс AddNewOrder рассматривается как часть класса OrderOptions, 65 частями которого также будут классы для просмотра, редактирования и удаления заказов. Кратность связи 1 к 1, поскольку в состав класса OrderOptions входит только один класс AddNewOrder. Перейдем теперь к управляющим классам. Добавим управляющий класс OrderManager (Менеджер по работе с заказами) с комментарием "Управляющий класс для обработки потока событий прецедента "Работа с заказами"", который будет обеспечивать обработку потока событий для рассматриваемого прецедента. Данный класс будет связан с классами AddNewOrder и Order. Отношение между классами AddNewOrder и OrderManager - однонаправленная ассоциация с кратностью связи 1 к 1, поскольку один экземпляр класса AddNewOrder взаимодействует только с одним экземпляром класса OrderManager. Отношение между классами OrderManager и Order - однонаправленная ассоциация с кратностью связи 1 к 1..n, поскольку один класс OrderManager может взаимодействовать с несколькими классами Order. Окончательный вариант диаграммы классов показан на рис. 5.3: 66 Рис. 5.3. Итоговая диаграмма классов 2. Создание пакетов Пакеты предназначены для группировки элементов в группы по определенным критериям. В простейшем случае классы можно группировать по их стереотипам. Создадим три пакета: Entities (классы- сущности), Boundaries (граничные классы) и Control (управляющие классы). Для этого необходимо щелкнуть правой кнопкой мыши на Логическом представлении браузера (Logical View), в появившемся контекстном меню выбрать пункт New > Package (Создать > Пакет), и ввести имя пакета. Результат создания пакетов показан на рис.5.4: 67 Рис. 5.4. Созданные пакеты В поле документации (Documentation) для каждого пакета зададим комментарий: для пакета Entities комментарий: пакет содержит классы- сущности; для пакета Boundaries комментарий: пакет содержит граничные классы; для пакета Control комментарий: пакет содержит управляющие классы. 3. Группировка классов в пакеты Группировка классов в пакеты осуществляется путем перетаскивания в Логическом представлении браузера соответствующего класса в соответствующий пакет. Группировать созданные классы будем следующим образом: классы Client, Order, OrderItem и ComponentPart перенесем в пакет Entities; классы OrderOptions и AddNewOrder перенесем в пакет Boundary; класс OrderManager перенесем в пакет Control. 68 Итоговой результат приведен на рис. 5.5. Рис. 5.5. Классы и пакеты для сценария "Добавление нового заказа" 4. Добавление диаграммы классов для каждого пакета Для добавления диаграммы к пакету следует щелкнуть правой кнопкой мыши по пакету, в появившемся контекстном меню выбрать пункт New > Class Diagram (Создать > Диаграмма Классов), ввести имя класса Main (Главная), далее открыть диаграмму, дважды щелкнув по ней, и перенести на нее нужные классы. Отношения между классами, принадлежащие одному пакету, будут перенесены автоматически. Результат создания диаграммы класов для пакета Boundaries показан на рис.5.6, для пакета Control - на рис.5.7, для пакета Entities - на рис. 5.8. 69 Рис. 5.6. Диаграмма классов пакета Boundaries Рис. 5.7. Диаграмма классов пакета Control 70 Рис. 5.8. Диаграмма классов пакета Entities 5. Создание главной диаграммы классов Главная диаграмма в логическом представлении модели обычно отображает пакеты системы. По умолчанию в Логическом представлении браузера уже существует главная диаграмма классов (Main). Для ее заполнения необходимо открыть ее, дважды щелкнув по ней в Логическом представлении браузера, и перетащить на нее три созданные нами пакеты (рис.5.9): 71 Рис. 5.9. Главная диаграмма классов 72 Лабораторная работа № 6 Создание диаграмм деятельности Цель работы: получить навыки построения диаграмм деятельности. Задание: 1. создать диаграмму деятельности, описывающую один из бизнес-процессов выбранной предметной области; 2. создать диаграмму деятельности, описывающую поток событий одного из вариантов использования, созданного в лабораторной работе № 2. Содержание отчета: созданные диаграммы деятельности с указанием того, какой бизнес-процесс и поток событий какого варианта использования они описывают. Пример выполнения работы 1. Создание диаграммы деятельности для бизнес-процесса предприятия по сборке компьютеров Рассмотрим целом, что происходит на предприятии от момента оформления заказа на сборку компьютера до выдачи готового компьютера. После оформления заказа менеджер по работе с клиентами передает его менеджеру по сборке, который прежде чем начать сборку заказывает необходимые комплектующие со склада. На складе заведующий подбирает необходимые комплектующие (в случае их отсутствия заказывает их у менеджера по снабжению) и передает их инженеру по сборке. После получения комплектующих менеджер по сборке осуществляет сборку компьютера и передает его инженеру по тестированию. Если компьютер не прошел тестирование, он возвращается для повторной сборки. При успешном завершении тестирования компьютер передается на склад на хранение. Со склада компьютер по требованию передается инженеру по работе с клиентами, который оформляет на него документы и выдает клиенту. 73 Для создания диаграммы действий необходимо щелкнуть правой кнопкой мыши по Представлению Вариантов Использования и в появившемся меню выбрать пункт New > Activity Diagram, ввести ее имя, после чего дважды щелкнуть по ней в браузере, чтобы открыть ее. Результат построения диаграммы показан на рис. 6.1: Рис. 6.1. Диаграмма деятельности бизнес-процесса 2. Создание диаграммы деятельности потока события варианта использования "Работа с заказом" Поток событий варианта использования "Работа с заказом" состоит из главное потока, под-потоков и альтернативных потоков. Чтобы не загромождать диаграмму покажем поток событий на нескольких диаграммах деятельности. На первой из них (условно назовем ее главной) 74 покажем действия для основного потока и связанный с ним альтернативный поток (рис. 6.2). Под-потоки можно будет показать путем декомпозиции соответствующего действия главной диаграммы. Рис. 6.2. Диаграмма деятельности для потока событий прецедента "Работа с заказом" Для декомпозиции действия диаграммы деятельности следует щелкнуть по ней правой кнопкой мыши и в появившемся меню выбрать пункт Sub Diagrams > New Activity Diagram. Пример декомпозиции действия На рис. 6.3 показана диаграмма деятельности для под-потока "Добавить заказ", которая является декомпозицией действия "Добавить заказ" главной диаграммы деятельности. 75 Рис. 6.3. Диаграмма деятельности для действия "Добавить заказ" 76 СПИСОК ЛИТЕРАТУРЫ 1. Коцюба И.Ю. Основы проектирования информационных систем [Элек-тронный ресурс]: учебное пособие / И.Ю. Коцюба, А.В. Чунаев, А.Н. Шиков – СПб: Университет ИТМО, 2015. – 206 с. // Режим доступа: https://books.ifmo.ru/file/pdf/1705.pdf 2. Щеглов, А.Ю. Математические модели и методы формального проекти-рования систем защиты информационных систем [Электронный ресурс]: учебное пособие / А.Ю. Щеглов, К.А. Щеглов. — Электрон. дан. — Санкт-Петербург: НИУ ИТМО, 2015. — 93 с. // Режим доступа: https://books.ifmo.ru/file/pdf/1763.pdf |