Главная страница
Навигация по странице:

  • 2.4 Альтернативные потоки

  • 3. Поток событий для прецедента «Учет поступления и выдачи комплектующих 3.1 Предусловия 3.2 Главный поток

  • 3.4 Альтернативные потоки

  • 4. Поток событий для прецедента «Сборка компьютеров» 4.1 Предусловия 4.2 Главный поток

  • 4.4 Альтернативные потоки

  • 5. Поток событий для прецедента «Требование необходимых комплектующих 5.1 Предусловия 5.2 Главный поток

  • 5.4 Альтернативные потоки

  • Лабораторная работа № 4 Создание диаграмм взаимодействия Цель работы: получить навыки построения диаграмм последовательности и кооперации. Задание

  • Пример выполнения работы.

  • Создание диаграммы последовательности для сценария "Добавить новый заказ" прецедента "Работа с заказом"

  • Номер сообщения Объект - отправитель сообщения Объект - получатель сообщения Название

  • Лабораторная работа № 5 Создание диаграммы классов Цель работы

  • Пример выполнения работы 1. Создание диаграммы классов для сценария "Добавить новый заказ" прецедента "Работа с заказом"

  • Модели и методы проектирования информационных


    Скачать 1.48 Mb.
    НазваниеМодели и методы проектирования информационных
    АнкорExt,ybr
    Дата20.10.2022
    Размер1.48 Mb.
    Формат файлаpdf
    Имя файлаMetodichka_Modeli_i_metody_proektirovaniya_informacionnyx_sistem.pdf
    ТипЛабораторная работа
    #743922
    страница4 из 5
    1   2   3   4   5
    2. Поток событий для прецедента «Управление информацией о
    клиенте»
    2.1 Предусловия
    2.2 Главный поток
    Прецедент начинает выполняться, когда менеджер подключается к системе и вводит свое имя и пароль. Система проверяет правильность пароля
    (Е-1) и выводит возможные варианты действий: добавить (Add), изменить
    (Change), удалить (Delete), просмотреть (View) или выйти (Exit).
    Если выбрана операция добавить
    (Add),
    S-1: выполняется поток добавить нового клиента (Add a New Client).

    47
    Если выбрана операция изменить
    (Change),
    S-2: выполняется поток изменить данные о клиенте (Change Client Data).
    Если выбрана операция удалить
    (Delete),
    S-3: выполняется поток удалить клиента (Delete Client).
    Если выбрана операция просмотреть (View),
    S-4: выполняется поток просмотреть данные о клиенте (View Client Data).\
    Если выбрана операция выйти (Exit) прецедент завершается.
    2.3 Под-потоки
    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). Система отображает информацию о выбранном клиенте. Когда менеджер просмотрит информацию, прецедент начнется сначала.

    48
    2.4 Альтернативные потоки
    Е-1: введено неправильное имя или пароль. Пользователь должен повторить ввод или завершить прецедент.
    Е-2: заполнены не все поля. Менеджер должен заполнить незаполненные поля или завершить прецедент.
    Е-3: введен неправильный номер клиента. Менеджер должен повторить ввод или завершить прецедент.
    Е-4: система не может удалить клиента. Информация сохраняется, система удалит клиента позже. Выполнение прецедента продолжается.
    3. Поток событий для прецедента «Учет поступления и выдачи
    комплектующих
    3.1 Предусловия
    3.2 Главный поток
    Прецедент начинает выполняться, когда завскладом подключается к системе и вводит свое имя и пароль. Система проверяет правильность пароля
    (Е-1) и выводит возможные варианты действий: добавить (Add), отметить
    (Mark) или выйти (Exit).
    Если выбрана операция добавить (Add), S-1: выполняется поток внести
    поступившие комплектующие (Add a New Components).
    Если выбрана операция отметить
    (Mark),
    S-2: выполняется поток сделать отметку о выдаче комплектующих (Mark
    Components).
    Если выбрана операция выйти (Exit) прецедент завершается.
    3.3 Под-потоки
    S-1: внести поступившие комплектующие (Add a New Components)
    Система отображает диалоговое окно, содержащее поля для ввода наименования комплектующих, их количества, поставщика. Завскладом заполняет указанные поля (Е-2). Система запоминает введенные данные. Затем прецедент начинается сначала.

    49
    S-2: сделать отметку о выдаче комплектующих (Change Order)
    Система отображает список комплектующих, находящихся на складе.
    Завскладом напротив нужных комплектующих вводит количество выданных
    (Е-3). Система запоминает введенные данные. Затем прецедент начинается сначала.
    3.4 Альтернативные потоки
    Е-1: введено неправильное имя или пароль. Пользователь должен повторить ввод или завершить прецедент.
    Е-2: заполнены не все поля. Пользователь должен заполнить пропущенные поля или завершить прецедент.
    Е-3: указано количество выданных комплектующих, превышающее их количество на складе. Пользователь должен повторить ввод или завершить прецедент.
    4. Поток событий для прецедента «Сборка компьютеров»
    4.1 Предусловия
    4.2 Главный поток
    Прецедент начинает выполняться, когда инженер по сборке подключается к системе и вводит свое имя и пароль. Система проверяет правильность пароля
    (Е-1) и выводит возможные варианты действий: просмотреть (View), отметить (Mark) или выйти (Exit).
    Если выбрана операция просмотреть
    (View),
    S-1: выполняется поток Просмотреть наряд на сборку компьютера (View an Make
    Computer Order).
    Если выбрана операция отметить
    (Mark),
    S-2: выполняется поток сделать отметку о статусе собираемого компьютера по
    наряду (Mark Computer).
    Если выбрана операция выйти (Exit) прецедент завершается.
    4.3 Под-потоки

    50
    S-1: Просмотреть наряд на сборку компьютера (View an Make Computer
    Order)
    Система отображает диалоговое окно, содержащее список нарядов и поле для ввода номера наряда. Инженер выбирает необходимый наряд из списка или вводит его номер в поле (Е-2). Система отображает информацию о выбранном наряде. Когда инженер просмотрит информацию, прецедент начнется сначала.
    S-2: сделать отметку о статусе собираемого компьютера (Mark
    Computer)
    Система отображает диалоговое окно, содержащее список нарядов. Возле необходимого наряда инженер делает отметку о статусе компьютера по данному наряду. Инженер сохраняет изменения. Затем прецедент начинается сначала.
    4.4 Альтернативные потоки
    Е-1: введено неправильное имя или пароль. Пользователь должен повторить ввод или завершить прецедент.
    Е-2: заполнены не все поля. Пользователь должен заполнить пропущенные поля или завершить прецедент.
    Е-3: введен неправильный номер наряда. Инженер должен повторить ввод или завершить прецедент.
    5. Поток событий для прецедента «Требование необходимых
    комплектующих
    5.1 Предусловия
    5.2 Главный поток
    Прецедент начинает выполняться, когда инженер по сборке подключается к системе и вводит свое имя и пароль. Система проверяет правильность пароля
    (Е-1) и выводит возможные варианты действий: просмотреть (View), затребовать (Order) или выйти (Exit).

    51
    Если выбрана операция просмотреть
    (View),
    S-1: выполняется поток просмотреть затребованные комплектующие на складе
    (View Ordered Components on Warehouse).
    Если выбрана операция затребовать
    (Order),
    S-2: выполняется поток затребовать необходимые комплектующие на складе
    (Order Required Components on Warehouse).
    Если выбрана операция выйти (Exit) прецедент завершается.
    5.3 Под-потоки
    S-1: Просмотреть затребованные комплектующие на складе (View
    Ordered Components on Warehouse)
    Система отображает следующую информацию обо всех сделанных заказах данным инженером по сборке: дата затребования, наименование комплектующих, их количество, заказ выполнен или нет. Когда инженер по сборке просмотрел список, он уведомляет систему. Прецедент начинается сначала.
    S-2: затребовать необходимые комплектующие на складе (Order
    Required Components on Warehouse)
    Система отображает диалоговое окно, содержащее поля для ввода списка необходимых комплектующих и их количества. Инженер по сборке заполняет его. Система запоминает введенные данные. Затем прецедент начинается сначала.
    5.4 Альтернативные потоки
    Е-1: введено неправильное имя или пароль. Пользователь должен повторить ввод или завершить прецедент.
    Описание потоков событий для прецедентов Управление информацией о
    поставщиках и Управление
    информацией
    о
    комплектующих аналогичноописанию для прецедента Управление
    информацией о клиенте; для прецедента Тестирование компьютеров - прецеденту Сборка компьютеров.

    52
    Лабораторная работа № 4
    Создание диаграмм взаимодействия
    Цель
    работы:
    получить навыки построения диаграмм последовательности и кооперации.
    Задание: создать диаграмму последовательности и кооперации для одного из сценариев любого прецедента, созданного в лабораторной работе № 2.
    Пример выполнения работы.
    Создавать диаграммы взаимодействия будем для сценария "Добавить новый заказ" прецедента "Работа с заказом". В этом сценарии кроме основного потока существуют еще и альтернативные потоки. Хотя стандарт языка UML допускает ветвления на диаграммах последовательности и кооперации, мы, чтобы не загромождать наши диаграммы, ограничимся рассмотрением только случая, когда пользователь правильно вводит свой пароль, правильно заполняет необходимые поля и введенные данные без ошибок сохраняются в базе данных.
    В случае необходимости альтернативные потоки можно показать на дополнительных диаграммах последовательности и кооперации.
    Диаграммы взаимодействия будем создавать в
    Логическом представлении браузера. Для того, чтобы отделить эти диаграммы от других
    (которые мы уже создали или создадим в дальнейшем), создадим вначале новый пакет в Логическом представлении - Диаграммы взаимодействия, в котором будут располагаться созданные далее диаграммы.
    Построение любой диаграммы взаимодействия начинается с определения перечня объектов, которые будут участвовать во взаимодействии. Для выбранного сценария в лабораторной работе № 3 была разработана диаграмма классов. Экземпляры классов этой диаграммы и будут участниками диаграмм взаимодействия.
    Примечание: Rational Rose позволяет, имея одну из двух типов диаграмм взаимодействия, создать вторую. Для этого необходимо открыть имеющуюся

    53 диаграмму взаимодействия и выбрать пункт меню Browse > Create Sequence
    (Collaboration) Diagram. Автоматически будет создана диаграмма второго типа с таким же именем, в том же пакете и с таким же содержимым, что и первая.
    Единственный недостаток этого приема - в созданной диаграмме элементы не будут автоматически выравниваться. Поэтому если исходная диаграмма достаточно большая, то в созданной диаграмме сложно будет разобраться, т.к. элементы могут налазить друг на друга.
    В данной работе мы оба типа диаграмм взаимодействия будем строить с ноля.
    Создание диаграммы последовательности для сценария "Добавить
    новый заказ" прецедента "Работа с заказом"
    Для создания диаграммы последовательности необходимо щелкнуть правой кнопкой мыши по пакету Диаграммы взаимодействия и в появившемся меню выбрать пункт New > Sequence Diagram, ввести ее имя, после чего дважды щелкнуть по ней в браузере, чтобы открыть ее (рис. 4.1).
    Рис. 4.1. Создание диаграммы последовательности

    54
    Построение диаграммы последовательности начинается с размещения на ней объектов, которые будут обмениваться сообщениями. Сначала необходимо разместить объекты, которые посылают сообщения, а потом объекты, получающие их.
    Инициатором взаимодействия выступает актер Менеджер по работе с клиентами. Поэтому на диаграмме он будет находится в левом углу. Далее размещаем (рис. 4.2):
    - объект класса OrderOptions (Параметры
    работы
    с
    заказом), отвечающий за выбор возможного действия с заказом в рассматриваемом прецеденте;
    - объект класса AddNewOrder (Добавление нового заказа), отвечающий за добавление заказа;
    - объект класса OrderManager (Менеджер по работе с заказами), отвечающий за обработку потока событий рассматриваемого прецедента;
    - объект класса Order (Заказ);
    - объект класса Client (Клиент);
    - объект класса ComponentPart (Комплектующее изделие).
    Рис. 4.2. Расположение объектов на диаграмме последовательности
    Теперь на диаграмме следует разместить сообщения, которыми будут обмениваться объекты (таблица 4.1, рис.4.3):

    55
    Таблица 4.1
    Номер
    сообщения
    Объект
    -
    отправитель
    сообщения
    Объект
    -
    получатель
    сообщения
    Название
    1
    Менеджер по работе с клиентами
    OrderOptions ввод пароля
    2
    OrderOptions
    OrderOptions проверка пароля
    3
    Менеджер по работе с клиентами
    OrderOptions выбор операции "добавить"
    4
    OrderOptions
    AddNewOrder отображение полей ввода
    5
    Менеджер по работе с клиентами
    AddNewOrder выбор типа компьютера
    6
    AddNewOrder
    OrderManager получение списка клиентов
    7
    OrderManager
    Client получение списка клиентов
    8
    Client
    AddNewOrder список клиентов
    9
    AddNewOrder
    AddNewOrder отображение списка клиентов
    10
    Менеджер по работе с клиентами
    AddNewOrder выбор клиента

    56 11
    AddNewOrder
    OrderManager получение списка комплектующих
    12
    OrderManager
    ComponentPart получение списка комплектующих
    13
    ComponentPart
    AddNewOrder список комплектующих
    14
    AddNewOrder
    AddNewOrder отображение списка комплектующих
    15
    Менеджер по работе с клиентами
    AddNewOrder
    * выбор необходимых комплектующих
    16
    Менеджер по работе с клиентами
    AddNewOrder сохранить заказ
    17
    AddNewOrder
    OrderManager передача управления
    18
    OrderManager
    Order сохранить

    57
    Рис. 4.3. Итоговая диаграмма последовательности
    Для отображения номера сообщения в Rational Rose необходимо в меню Tools
    > Options > вкладка Diagram поставить галочку возле надписи Sequence numbering.

    58
    Лабораторная работа № 5
    Создание диаграммы классов
    Цель работы: получить навыки построения диаграмм классов, создания пакетов и группировки классов в пакеты.
    Задание:
    1. создать диаграмму классов
    *
    для одного из сценарией диаграммы прецедентов, созданной в предыдущей лабораторной работе.
    Для каждого класса необходимо задать атрибуты и операции. Каждый класс должен быть подробно задокументирован - необходимо задать текстовое описание самого класса, описания его атрибутов и операций;
    2. создать пакеты для группировки классов, созданных в пункте
    1;
    3. сгруппировать классы из пункта 1 в пакеты;
    4. для каждого пакета создать свою диаграмму классов.
    5. разработать главную диаграмму классов.
    * Примечание: рассматривать диаграмму классов рекомендуется с
    концептуальной точки зрения, которая используется на начальных этапах
    моделирования и разработки.
    Содержание отчета:
    1. созданные диаграммы классов (для диаграммы классов из пункта 2 задания должен быть указан сценарий, для которого данная диаграмма построена);
    2. краткое описание каждого созданного класса и отношений между классами.
    Диаграммы классов (class diagram) используются для моделирования статического вида системы с точки зрения проектирования. Диаграмма
    классов - диаграмма, на которой показано множество классов, интерфейсов, коопераций и отношений между ними. Используется в следующих целях:

    59

    для моделирования словаря системы: предполагает принятие решения о том, какие абстракции являются частью системы, а какие - нет. С помощью диаграмм классов можно определить эти абстракции и их обязанности;

    для моделирования простых коопераций. Кооперация - это сообщество классов, интерфейсов и других элементов, работающих совместно для обеспечения некоторого кооперативного поведения;

    для моделирования логической схемы базы данных.
    Согласно Мартину Фаулеру существуют три различные точки зрения на построение диаграмм классов или любой другой модели:

    концептуальная точка зрения - диаграммы классов служат для представления понятий изучаемой предметной области. Эти понятия будут соответствовать реализующим их классам, но прямое соответствие может отсутствовать. Концептуальная модель может иметь слабое отношение или вообще не иметь никакого отношения к реализующему ее программному обеспечению, поэтому ее можно рассматривать без привязки к какому-то языку программирования;

    точка зрения спецификации - рассматривается программная система, при этом рассматривается только ее интерфейсы, но не реализация;

    точка зрения реализации - классы диаграммы соответствуют реальным классам программной системы.
    Пример выполнения работы
    1.
    Создание диаграммы классов для сценария "Добавить
    новый заказ" прецедента "Работа с заказом"
    Диаграммы классов будем рассматривать с концептуальной точки зрения.
    Для упрощения задачи и чтобы не загромождать диаграммы несущественными деталями методы setX, getX для каждого атрибута Х классов задавать не будем.

    60
    Создадим в Логическом представлении браузера новую диаграмму классов и назовем ее "Add New Order". В поле документации запишем для нее следующий текст: "Диаграмма классов для сценария "Добавить новый заказ" прецедента "Работа с заказом"
    Заполнение диаграммы начнем с определения классов-сущностей.
    Рассматриваемый сценарий состоит из:

    самого заказа;

    клиента, который делает заказ;

    комплектующих изделий, которые входят в заказ.
    Создадим классы-сущности Order
    (Заказ), Client
    (Клиент) и ComponentPart (Комплектующее изделие). Поскольку в один заказ может входить много разных комплектующих изделий, и одно комплектующее изделие может входить во много заказов, то введем еще один класс- сущность OrderItem (Состав заказа). Опишем каждый класс.
    1   2   3   4   5


    написать администратору сайта