Пример ДКР. ПримерДКР. 1 Описание предметной области для проектирования ис "Предприятие по сборке и продаже компьютеров"
 Скачать 370.32 Kb.
|
|
Пример выполнения работы 1 Описание предметной области для проектирования ИС "Предприятие по сборке и продаже компьютеров" ………. 2 Разработка технического задания Текст разделов ТЗ 3 Разработка диаграммы вариантов использования Для предметной области выделим следующих актеров:
Возможности, которые должна предоставлять система: актер Менеджер по работе с клиентами использует систему для оформления, редактирования заказов и управления информацией о клиентах предприятия; актер Менеджер по снабжению использует систему для просмотра перечня необходимых для закупки комплектующих и ведения информации о снабжении; актер Инженер по сборке настольных компьютеров использует систему для просмотра нарядов на сборку персональных компьютеров, для заказа комплектующих со склада и отметке о ходе выполнения работы; актер Инженер по сборке ноутбуков использует систему для просмотра нарядов на сборку ноутбуков, для заказа комплектующих со склада и отметки о ходе выполнения работы; актер Инженер по тестированию использует систему для просмотра нарядов на тестирование собранной продукции и отметки о ходе выполнения работы; актер Завскладом использует систему для учета поступления и выдачи комплектующих. На основании вышеизложенного можно выделить следующие прецеденты:
Главная диаграмма прецедентов показана на рисунке 1.  Рисунок 1 – Главная диаграмма прецедентов Отношения между актерами и прецедентами Все актеры связаны с прецедентами отношением Unidirectional Association (однонаправленная ассоциативная связь). Для прецедента Сборка компьютеров не имеет значение, какой именно актер будет с ним взаимодействовать ‒ Инженер по сборке настольных компьютеров или Инженер по сборке ноутбуков. Поэтому введен еще один актер - Инженер по сборке, с которым связали первых двух актеров отношением обобщения (Generalization). Отношение между прецедентами Работа с заказом и Управление информацией о клиенте - отношение расширения, поскольку, когда актер Менеджер по работе с клиентами работает с заказом (оформляет, меняет и т.д.), то не всегда при этом он управляет информацией о клиентах. Отношение между прецедентами Сборка компьютеров и Требование необходимых комплектующих - отношение включения, поскольку для сборки компьютеров обязательно нужно заказывать необходимые комплектующие со склада. Поток событий для прецедентов главной диаграммы прецедентов Спецификация потоков событий прецедента «Работа с заказом» Предусловия Если заказ оформляется для нового клиента, то под-поток добавить нового клиента (Add a New Client) прецедента Управление информацией о клиенте должен быть выполнен перед его началом. Основной поток Прецедент начинает выполняться, когда менеджер подключается к системе и вводит свое имя и пароль. Система проверяет правильность пароля (Е-1) и выводит возможные варианты действий: добавить (Add), изменить (Change), удалить (Delete), просмотреть (View) или выйти (Exit). Если выбрана операция добавить (Add), S-1: выполняется поток добавить новый заказ (Add a New Order). Если выбрана операция изменить (Change), S-2: выполняется поток изменить заказ (Change Order). Если выбрана операция удалить (Delete), S-3: выполняется поток удалить заказ (Delete Order). Если выбрана операция просмотреть (View), S-4: выполняется поток просмотреть заказ (View Order). Если выбрана операция выйти (Exit) прецедент завершается. Подпотоки S-1: добавить новый заказ (Add a New Order) Система отображает диалоговое окно, содержащее поле, в котором менеджер должен выбрать тип компьютера (настольный или ноутбук). Пользователь выбирает необходимый тип. Система отображает поле для выбора клиента и список возможных комплектующих для выбранного типа компьютера, в котором менеджер отмечает выбранные клиентом комплектующие. Менеджер заполняет поля (E-2). Система запоминает введенные данные и распечатывает счет для оплаты. Затем прецедент начинается сначала. S-2: изменить заказ (Change Order) Система отображает диалоговое окно, содержащее список заказов и поле для ввода номера заказа. Менеджер выбирает необходимый заказ из списка или вводит номер заказа в поле (Е-3). Система отображает информацию о данном заказе. Менеджер делает необходимые изменения (Е-2). Система запоминает введенные данные. Затем прецедент начинается сначала. S-3: удалить заказ (Delete Order) Система отображает диалоговое окно, содержащее список заказов и поле для ввода номера заказа. Менеджер выбирает необходимый заказ из списка или вводит номер заказа в поле (Е-3). Система удаляет выбранный заказ (Е-4). Затем прецедент начинается сначала. S-4: просмотреть заказ (View Order) Система отображает диалоговое окно, содержащее список заказов и поле для ввода номера заказа. Менеджер выбирает необходимый заказ из списка или вводит номер заказа в поле (Е-3). Система отображает информацию о выбранном заказе. Когда менеджер просмотрит информацию, прецедент начнется сначала. Альтернативные потоки Е-1: введено неправильное имя или пароль. Пользователь должен повторить ввод или завершить прецедент. Е-2: выбраны не все комплектующие, необходимые для сборки компьютера или комплектующих нет в наличии. Менеджер должен изменить состав компьютера или завершить прецедент. Е-3: введен неправильный номер заказа. Менеджер должен повторить ввод или завершить прецедент. Е-4: система не может удалить заказ. Информация сохраняется, система удалит заказ позже. Выполнение прецедента продолжается. Поток событий для прецедента «Управление информацией о клиенте» 2.1 Основной поток Прецедент начинает выполняться, когда менеджер подключается к системе и вводит свое имя и пароль. Система проверяет правильность пароля Система проверяет правильность пароля (Е-1) и выводит возможные варианты действий: добавить (Add), изменить (Change), удалить (Delete), просмотреть (View) или выйти (Exit). Если выбрана операция добавить (Add), S-1: выполняется поток добавить нового клиента (Add a New Client). Если выбрана операция изменить (Change), S-2: выполняется поток изменить данные о клиенте (Change Client Data). Если выбрана операция удалить (Delete), S-3: выполняется поток удалить клиента (Delete Client). Если выбрана операция просмотреть (View), S-4: выполняется поток просмотреть данные о клиенте (View Client Data). Если выбрана операция выйти (Exit) прецедент завершается. 2.2 Подпотоки S-1: добавить нового клиента (Add a New Client) Система отображает диалоговое окно, содержащее поля для ввода данных о новом клиенте. Пользователь заполняет поля (Е-2). Система запоминает введенные данные. Затем прецедент начинается сначала. S-2: изменить данные о клиенте (Change Client Data) Система отображает диалоговое окно, содержащее список клиентов и поле для ввода номера клиента. Менеджер выбирает необходимого клиента из списка или вводит его номер в поле (Е-3). Система отображает информацию о данном клиенте. Менеджер делает необходимые изменения (Е-2). Система запоминает введенные данные. Затем прецедент начинается сначала. S-3: удалить клиента (Delete Client) Система отображает диалоговое окно, содержащее список клиентов и поле для ввода номера клиента. Менеджер выбирает необходимого клиента из списка или вводит его номер в поле (Е-2). Система удаляет выбранного клиента (Е-4). Затем прецедент начинается сначала. S-4: просмотреть данные о клиенте (View Client Data) Система отображает диалоговое окно, содержащее список клиентов и поле для ввода номера клиента. Менеджер выбирает необходимого клиента из списка или вводит его номер в поле (Е-3). Система отображает информацию о выбранном клиенте. Когда менеджер просмотрит информацию, прецедент начнется сначала. 2.3 Альтернативные потоки Е-1: введено неправильное имя или пароль. Пользователь должен повторить ввод или завершить прецедент. Е-2: заполнены не все поля. Менеджер должен заполнить незаполненные поля или завершить прецедент. Е-3: введен неправильный номер клиента. Менеджер должен повторить ввод или завершить прецедент. Е-4: система не может удалить клиента. Информация сохраняется, система удалит клиента позже. Выполнение прецедента продолжается. Поток событий для прецедента «Учет поступления и выдачи комплектующих 3.1 Главный поток Прецедент начинает выполняться, когда завскладом подключается к системе и вводит свое имя и пароль. Система проверяет правильность пароля (Е-1) и выводит возможные варианты действий: добавить (Add), отметить (Mark) или выйти (Exit). Если выбрана операция добавить (Add), S-1: выполняется поток внести поступившие комплектующие (Add a New Components). Если выбрана операция отметить (Mark), S-2: выполняется поток сделать отметку о выдаче комплектующих (Mark Components). Если выбрана операция выйти (Exit) прецедент завершается. 3.2 Подпотоки S-1: внести поступившие комплектующие (Add a New Components) Система отображает диалоговое окно, содержащее поля для ввода наименования комплектующих, их количества, поставщика. Завскладом заполняет указанные поля (Е-2). Система запоминает введенные данные. Затем прецедент начинается сначала. S-2: сделать отметку о выдаче комплектующих (Change Order) Система отображает список комплектующих, находящихся на складе. Завскладом напротив нужных комплектующих вводит количество выданных (Е-3). Система запоминает введенные данные. Затем прецедент начинается сначала. 3.3 Альтернативные потоки Е-1: введено неправильное имя или пароль. Пользователь должен повторить ввод или завершить прецедент. Е-2: заполнены не все поля. Пользователь должен заполнить пропущенные поля или завершить прецедент. Е-3: указано количество выданных комплектующих, превышающее их количество на складе. Пользователь должен повторить ввод или завершить прецедент. Поток событий для прецедента «Сборка компьютеров» 4.1 Основной поток Прецедент начинает выполняться, когда завскладом подключается к системе и вводит свое имя и пароль. Система проверяет правильность пароля (Е-1). Система выводит возможные варианты действий: просмотреть (View), отметить (Mark) или выйти (Exit). Если выбрана операция просмотреть (View), S-1: выполняется поток Просмотреть наряд на сборку компьютера (View an Make Computer Order). Если выбрана операция отметить (Mark), S-2: выполняется поток сделать отметку о статусе собираемого компьютера по наряду (Mark Computer). Если выбрана операция выйти (Exit) прецедент завершается. 4.2 Подпотоки S-1: Просмотреть наряд на сборку компьютера (View an Make Computer Order) Система отображает диалоговое окно, содержащее список нарядов и поле для ввода номера наряда. Инженер выбирает необходимый наряд из списка или вводит его номер в поле (Е-2). Система отображает информацию о выбранном наряде. Когда инженер просмотрит информацию, прецедент начнется сначала. S-2: сделать отметку о статусе собираемого компьютера (Mark Computer) Система отображает диалоговое окно, содержащее список нарядов. Возле необходимого наряда инженер делает отметку о статусе компьютера по данному наряду. Инженер сохраняет изменения. Затем прецедент начинается сначала. 4.3 Альтернативные потоки Е-1: введено неправильное имя или пароль. Пользователь должен повторить ввод или завершить прецедент. Е-2: заполнены не все поля. Пользователь должен заполнить пропущенные поля или завершить прецедент. Е-3: введен неправильный номер наряда. Инженер должен повторить ввод или завершить прецедент. Поток событий для прецедента «Требование необходимых комплектующих» 5.1 Главный поток Прецедент начинает выполняться, когда завскладом подключается к системе и вводит свое имя и пароль. Система проверяет правильность пароля (Е-1). Прецедент начинает выполняться, когда инженер по сборке подключается к системе и вводит свое имя и пароль. Система проверяет правильность пароля (Е-1) и выводит возможные варианты действий: просмотреть (View), затребовать (Order) или выйти (Exit). Если выбрана операция просмотреть (View), S-1: выполняется поток просмотреть затребованные комплектующие на складе (View Ordered Components on Warehouse). Если выбрана операция затребовать (Order), S-2: выполняется поток затребовать необходимые комплектующие на складе (Order Required Components on Warehouse). Если выбрана операция выйти (Exit) прецедент завершается. 5.2 Подпотоки S-1: Просмотреть затребованные комплектующие на складе (View Ordered Components on Warehouse) Система отображает следующую информацию обо всех сделанных заказах данным инженером по сборке: дата затребования, наименование комплектующих, их количество, заказ выполнен или нет. Когда инженер по сборке просмотрел список, он уведомляет систему. Прецедент начинается сначала. S-2: затребовать необходимые комплектующие на складе (Order Required Components on Warehouse) Система отображает диалоговое окно, содержащее поля для ввода списка необходимых комплектующих и их количества. Инженер по сборке заполняет его. Система запоминает введенные данные. Затем прецедент начинается сначала. 5.3 Альтернативные потоки Е-1: введено неправильное имя или пароль. Пользователь должен повторить ввод или завершить прецедент. Описание потоков событий для прецедентов Управление информацией о поставщиках и Управление информацией о комплектующих аналогичноописанию для прецедента Управление информацией о клиенте; для прецедента Тестирование компьютеров ‒ прецеденту Сборка компьютеров. Создание дополнительной диаграммы прецедентов Как видно из описания потока событий для всех прецедентов каждый из них включает проверку пользователя. Проверка осуществляется единообразно для любого прецедента. Поэтому ее можно представить в виде отдельного прецедента Аутентификация пользователя, связанного отношением включения со всеми остальными. Результат создания диаграммы показан на рисунке 2.  Рисунок 2 – Дополнительная диаграмма прецедентов Создание диаграммы деятельности для бизнес-процесса предприятия по сборке компьютеров Рассмотрим в целом, что происходит на предприятии от момента оформления заказа на сборку компьютера до выдачи готового компьютера. После оформления заказа менеджер по работе с клиентами передает его менеджеру по сборке, который прежде чем начать сборку заказывает необходимые комплектующие со склада. На складе заведующий подбирает необходимые комплектующие (в случае их отсутствия заказывает их у менеджера по снабжению) и передает их инженеру по сборке. После получения комплектующих менеджер по сборке осуществляет сборку компьютера и передает его инженеру по тестированию. Если компьютер не прошел тестирование, он возвращается для повторной сборки. При успешном завершении тестирования компьютер передается на склад на хранение. Со склада компьютер по требованию передается инженеру по работе с клиентами, который оформляет на него документы и выдает клиенту. Результат построения диаграммы показан на рисунке 3.  Рисунок 3 – Диаграмма деятельности бизнес-процесса Создание диаграммы деятельности потока события варианта использования «Работа с заказом» Поток событий варианта использования «Работа с заказом» состоит из основного потока, под-потоков и альтернативных потоков. Чтобы не загромождать диаграмму покажем поток событий на нескольких диаграммах деятельности. На первой из них (условно назовем ее главной) покажем действия для основного потока и связанного с ним альтернативного потока. Под-потоки можно будет показать путем декомпозиции соответствующего действия главной диаграммы.  Рисунок 4 – Диаграмма деятельности для потока событий прецедента «Работа с заказом» Пример декомпозиции действия На рисунке 5 показана диаграмма деятельности для под-потока «Добавить заказ», которая является декомпозицией действия «Добавить заказ» главной диаграммы деятельности.  Рисунок 5. Диаграмма деятельности для под-потока «Добавить заказ» Таким же образом создаются диаграммы действий для под-потоков Изменить заказ, Посмотреть заказ и Удалить заказ. Далее необходимо создать диаграммы деятельности для других вариантов использования (потоков событий), их под-потоков и альтернативных потоков, описанных в спецификации. Создание диаграммы последовательности для сценария "Добавить новый заказ" прецедента "Работа с заказом" Сначала необходимо разместить объекты, которые посылают сообщения, а потом объекты, получающие их. Инициатором взаимодействия выступает актер Менеджер по работе с клиентами. Далее размещаем на диаграмме последовательности: объект класса OrderOptions (Параметры работы с заказом), отвечающий за выбор возможного действия с заказом в рассматриваемом прецеденте; объект класса AddNewOrder (Добавление нового заказа), отвечающий за добавление заказа; объект класса OrderManager (Менеджер по работе с заказами), отвечающий за обработку потока событий рассматриваемого прецедента; объект класса Order (Заказ); объект класса Client (Клиент); объект класса ComponentPart (Комплектующее изделие). Таблица 1 – Сообщения, которыми будут обмениваться объекты
 Рисунок 6. Диаграмма последовательности для сценария "Добавить новый заказ" прецедента "Работа с заказом" Диаграммы деятельности разрабатываются для всех потоков. Создание диаграммы классов для сценария "Добавить новый заказ" прецедента "Работа с заказом" Диаграммы классов будем рассматривать с концептуальной точки зрения. Создадим новую диаграмму классов и назовем ее "Add New Order". Заполнение диаграммы начнем с определения классов-сущностей. Рассматриваемый сценарий состоит из: самого заказа; клиента, который делает заказ; комплектующих изделий, которые входят в заказ. Создадим классы-сущности Order (Заказ), Client (Клиент) и ComponentPart (Комплектующее изделие). Поскольку в один заказ может входить много разных комплектующих изделий, и одно комплектующее изделие может входить во много заказов, то введем еще один класс-сущность OrderItem (Состав заказа). Опишем каждый класс. Таблица 2 – КлассClient
Таблица 3 – КлассOrder
Таблица 4 – КлассOrderItem
Таблица 5 – КлассComponentPart
Добавим отношения между классами. Класс Client и Order ‒ отношение ассоциации, поскольку данные два класса просто связаны друг с другом и никакие другие типы связей здесь применить нельзя. Один клиент может сделать несколько заказов, каждый заказ поступает только от одного клиента, поэтому кратность связи со стороны класса Client ‒ 1, со стороны Order ‒1..n. Класс Order и OrderItem ‒ отношение композиции, поскольку строка заказа является частью заказа, и без него существовать не может. В один заказ может входить несколько строк заказа, строка заказа относится только к одному заказу, поэтому кратность связи со стороны Order ‒ 1, со стороны OrderItem ‒ 1..n. Класс OrderItem и ComponentPart ‒ отношение агрегации, поскольку комплектующие изделия являются частями строки заказа, но и те, и другие, явлюятся самостоятельными классами. Одно комплектующее изделие может входить во много строк заказа, в одну строку заказа входит только одно комплектующее изделие, поэтому кратность связи со стороны ComponentPart ‒ 1, со стороны OrderItem ‒ 1..n.  Рисунок 7 – Диаграмма классов-сущностей  Рисунок 8 – Диаграмма классов предметной области "Предприятие по сборке и продаже компьютеров" Диаграмма кооперации сценария "Добавить новый заказ" прецедента "Работа с заказом" Диаграммы кооперации содержат все те же элементы, что и диаграммы последовательности: объекты, действующие лица, связи между ними и сообщения, которыми они обмениваются, но они уже не упорядочены во времени.  Диаграммы кооперации создаются на основании каждой диаграммы деятельности. Представлены основные диаграммы UML для моделирования ИС. Все другие диаграммы будут рассмотрены в следующем семестре. |