Проектирование информационной системы на основе объектно – ориентированного подхода, средствами языка моделирования UML и CASE – инструмен

Автор работы: Пользователь скрыл имя, 12 Января 2013 в 12:50, курсовая работа

Описание работы

В данной курсовой работе перед нами стоит задача спроектировать модель информационной системы корпорации, которая занимается продажей товаров потребителям, при помощи Model Maker. Model Maker - система визуального проектирования структуры приложений. С помощью Model Maker можно заранее выявить недостающую информацию, которую требуется заложить в проект. Позволяет при проектировании информационной системы вести документирование объектов. [3]

Содержание работы

Введение 5
1. Создание главной диаграммы 6
1.1. Создание в главной диаграмме модели действующих лиц 6
1.2. Составление вариантов использования 7
1.3. Построение диаграммы вариантов использования 8
1.4. Описание вариантов использования 9
1.5. Анализ системы 14
1.6. Создание диаграмм последовательности 17
2. Диаграмма классов 22
2.1. Создание диаграммы классов 22
2.2. Программный код модуля, созданного средствами объектно-ориентированного проектирования и визуального моделирования с помощью Model Maker 27
3. Документирование работы 32
4. Глоссарий 34
Заключение 35
Литература 36

Файлы: 1 файл

курсовая ПИС.doc

— 427.50 Кб (Скачать файл)

 

Краткое описание.

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

Основной поток событий.

Данный вариант использования  начинает выполняться, когда администратор  захочет создать отчет.

  1. Запускается конструктор отчета
  2. Администратор выбирает требующиеся данные, задает условия
  3. Система предоставляет отчет

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

Альтернативные потоки отсутствуют.

Предусловие

Отсутствуют

Постусловие

Предоставление отчета

 

 

Вариант использования "Просмотреть отчеты"

 

Краткое описание.

Данный вариант использования  позволяет администрации просматривать  отчеты.

Основной поток событий.

Данный вариант использования начинает выполняться, когда администрация захочет просмотреть отчет.

  1. Запускается форма, на которой перечислены все отчеты
  2. Выбирается требуемый отчет
  3. Запускается отчет

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

Альтернативные потоки отсутствуют.

Предусловие

Отсутствуют

Постусловие

Предоставление отчета

 

Вариант использования "Обработать заказ"

 

Краткое описание.

Данный вариант использования  позволяет обработать заказы клиентов.

Основной поток событий.

Данный вариант использования  начинает выполняться, когда администратор захочет обработать заказ.

    1. Администратор открывает форму, на которой перечислены заказы клиентов
    2. Администратор выбирает определённый заказ для редактирования
    3. Система выводит на экран форму обработки заказа
    4. Администратор заполняет форму
    5. Новые данные о заказе сохраняются в каталог заказов

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

Неправильное заполнение формы обработки заказов. Если во время выполнения основного потока обнаруживается, что администратор  не правильно заполнил форму или  заполнил не все поля, система выдает предупреждение об ошибке. Администратор возвращается к форме, либо отказывается от обработки заказа.

Предусловия.

Перед началом выполнения данного варианта использования  клиент должен сделать заказ.

Постусловия.

Отсутствуют.

    1. Анализ системы

 

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

Как правило, в потоках  событий каждого варианта использования выявляются классы трех типов (Category):

Граничные классы (Boundary) – служат посредниками при взаимодействии внешних объектов с системой. Как правило, для каждой пары «действующее лицо – вариант использования»

Классы –  сущности (Entity) – представляют собой ключевые понятия создаваемой системы.

Управляющие классы (Control) – обеспечивают координацию объектов в системе. Могут отсутствовать в некоторых вариантах использования, ограничивающихся простыми манипуляциями с хранимыми данными. [3]

Имена классам будем задавать, исходя из требований к системе, знания предметной области и назначения класса.

 

Для данной курсовой работы следует предложить следующие классы:

  1. Для диаграммы последовательности «Сделать заказ»
    1. Klient – представляет собой внешнюю сущность - клиентов корпорации, относится к классу Entity (сущность).
    2. Form_price – служит посредником при взаимодействии внешней сущности «Клиент» и системы, представляет собой форму на которой размещен прайс-лист, относится к классу Boundary (граничный класс).
    3. Form_zayavka – представляет собой форму заявки, с помощью которой генерируется заявка на товар, относится к классу Boundary (граничный класс).
    4. Control_error – обеспечивает проверку данных, относится к классу Control (управляющий класс).
    5. Form_zakaz – представляет собой форму оформления заказа, относится к классу Boundary (граничный класс).
    6. Table_zakaz – представляет собой таблицу для хранения данных о заказах клиентов, относится к классу Entity (сущность).
  2. Для диаграммы последовательности «Зарегистрироваться в системе»
    1. Klient – данный класс расписан выше.
    2. Form_New_Klient – представляет собой форму для регистрации клиентов в системе, относится к классу Boundary (граничный класс).
    3. Control_error – данный класс расписан выше.
    4. Table_klient- данный класс представляет собой каталог в котором храниться информация о зарегистрированных в системе клиентах относится к классу Entity (сущность).
  3. Для диаграммы последовательности «Сформировать отчеты»
    1. Administrator – данный класс представляет собой внешнюю сущность – администратора ИС, относится к классу (сущность).
    2. Constructor_report – данный класс представляет конструктор для генерации отчетов, относится к классу Boundary (граничный класс).
    3. Table_report - данный класс представляет собой каталог в котором хранятся готовые отчеты, относится к классу Entity (сущность).
  4. Для диаграммы последовательности «Обработать заказ»
    1. Administrator - данный класс расписан выше.
    2. F_spis_zakaz – данный класс представляет собой форму, на которой отображается список с перечисленными заказами клиентов, относится к классу Boundary (граничный класс).
    3. Form_obrabotka - представляет собой форму для обработки заказов, относится к классу Boundary (граничный класс).
    4. Control_error - данный класс расписан выше.
    5. Table_zakaz – данный класс расписан выше.

 

Создание в браузере списка классов на этапе анализа  модели

 

    1. На вкладке «Classes»  выполним команду контекстного меню «Add Class»;
    2. В появившемся диалоговом окне запишем имя «Administrator»
    3. Зададим тип создаваемого класса. Для этого через кнопку «+» раздела «Category» запишем название типа «Entity»
    4. Завершим диалог. В результате увидим в браузере созданный класс модели

Аналогично создадим остальные классы (рис. 4.).

 

Рис. 4. Отображение списка классов в окне браузера

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

 

  1. Добавим в браузер необходимое количество диаграмм последовательности (рис. 5.)

Рис.5. Отображение списка имен диаграмм последовательностей

 

  1. Сделаем активной в браузере диаграмму последовательности «ДП Сделать заказ» для варианта использования «Сделать заказ».
  2. Затем перейдём на вкладку «Classes», в левом верхнем углу. Перетащим в окно диаграммы последовательности классы, участвующие в создаваемом событии рассматриваемого варианта использования.
  3. На панели инструментов нажмем кнопку «Add Generic Message», и проведем линию мышью от линии жизни одного объекта к линии жизни другого объекта. Появится диалоговое окно создания сообщения, которое будет передаваться от одного объекта к другому.
  4. Далее на вкладке «Association» укажем номер сообщения и через двоеточие текст сообщения. В результате будет создано сообщение в виде стрелки с текстом. Аналогично сформируем остальные сообщения. В итоге получим диаграмму последовательности «Сделать заказ» (рис.6.)

 

 

Рис. 6. Диаграмма последовательности основного потока событий «ДП Сделать заказ» для варианта использования «Сделать заказ»

 

Аналогично создадим другие диаграммы последовательности (рис. 7, 8,9).

 

 

Рис. 7. Диаграмма последовательности основного потока событий «ДП Зарегистрироваться в системе» для варианта использования «Зарегистрироваться в системе»

 

 

 

Рис. 8. Диаграмма последовательности основного потока событий «ДП Сформировать отчеты» для варианта использования «Сформировать отчеты»

 

Рис. 9. Диаграмма последовательности основного потока событий «ДП  Обработать заказ» для варианта использования  «Обработать заказ»

 

  1. Диаграмма классов

    1. Создание диаграммы классов

 

Для создания диаграммы  классов модели требуется выполнить следующие действия:

  1. Маркируем в левом верхнем углу вкладку «Diagrams» и через кнопку «Add class diagram» создаем в главном окне новую диаграмму классов, имя которой будет «Диаграмма классов»
  2. Перетаскиваем мышью из браузера классы в окно диаграммы классов
  3. Затем выделим один из классов, например «Table_Klient». Далее, при помощи контекстного меню зайдем в свойство класса Diagram properties и перейдем на вкладку Symbol style. В раскрывающемся списке Member list style выберем значение Auto Member list..
  4. Кнопка Add Property открывает диалоговое окно создания в  классе нового свойства.

 

 

Рис. 8. Панель просмотрщика интерфейса классов

 

  1. Добавим в класс «Table_Klient» новое свойство.
  2. В названии типа свойства выбираем значение User Defined (Определяемое пользователем);

 

  1. Далее необходимо указать имя свойства например Fio и его видимость (Visibility). В данном случае выбираем published.
  2. В группе Read Access (чтение значения атрибута) выберем Method (Метод). В ответ система автоматически сгенерирует название метода GetFio, предназначенного для доступа к значению свойства.
  3. Выберем также в группе Write Access создаваемого свойства значение Method. Система создаст название метода SetFio, предназначенного для записи значения свойства. Параметр метода задается в списке Write parametr. Укажем любое имя, например, value
  4. Чтобы иметь доступ к данному полю внутри класса включим флажок State Field (Статическое поле);
  5. После завершения диалога получим новое свойство Fio, статическое свойство FFio и два метода (GetFio и SetFio). Статическое свойство FFio является внутренней переменной данного свойства, первым символом имени всегда является F. Эта переменная используется для сохранения значения свойства (рис. 9.).

 

 

Рис. 10. Диалоговое окно «Свойство класса Table_Klient»

 

 

  1. Далее подготовим программную реализацию двух методов. Для этого маркируем один из методов и переходим со страницы Diagram Editor на страницу Implementation. Сначала выбираем, затем переходим в правую часть окна и набираем оператор. Затем кнопкой Save code вводим текст. Так, для метода GetFio запишем команду: Result:=FFio; для метода SetFio запишем: Ffio:=Avalue

 

 

Рис. 11. Вкладка Implementation, ввод оператора

 

  1. Далее создадим для данного класса операции реализации, выполняющие бизнес-функции. Для включения в класс операции реализации следует щелкнуть по кнопке Add Metods, задать имя операции, например для класса «Klient» укажем имя «Registr» - данный метод означает регистрацию клиента в системе. Далее выполним диалог по аналогии с предыдущими пунктами (рис. 12).

 

 

Рис. 12. Диалоговое окно «Метод класса Klient»

 

После добавления классам всех требующихся атрибутов и методов диаграмма классов имеет вид (рис. 13.)

 

 

Рис. 13. Отображение диаграммы классов

 

  1. Теперь сгенерируем новый модуль, в котором будут представлены созданные классы модели. Для создания нового модуля перейдем на панель Units Просмотрщика классов и нажмем кнопку Add. В поле, где задается местоположение исходного файла (Relative Unit file name), укажем имя файла и путь. В нижней части окна переместим в правую часть названия классов, включаемых в модуль. После окончания диалога появится сгенерированный модуль.
  2. Для генерации конечного кода модуля следует щелкнуть по кнопке Unlock, затем нажать кнопку Generation. Далее необходимо запустить Delphi, затем вернуться к ModelMaker и нажать кнопку Locate In Delphi. В результате получим шаблон  модуля, который мы создали средствами объектно-ориентированного проектирования и визуального моделирования с помощью CASE – системы ModelMaker.

 

Созданный модуль можно добавить в разрабатываемый проект. В нем описаны все классы, представленные на диаграмме классов, а также шаблоны заявленных процедур и функций.

 

    1. Программный код модуля, созданного средствами объектно-ориентированного проектирования и визуального моделирования с помощью Model Maker

 

unit module_delf;

interface

uses

  SysUtils, Windows, Messages, Classes, Graphics, Controls,

  Forms, Dialogs;

type

  Administrator = class (TObject)         //  класс Администратор

  public

    procedure redactirovanie_inf;    // Процедура редактирование информации     

  published

    procedure Formirovanie_report; // Процедура формирования отчетов

  end;

  Constructor_report = class (TObject) // Класс Конструктор отчетов

  private

    FForma_otcheta: TForma_otcheta;

function GetForma_otcheta: TForma_otcheta;  // метод для доступа к значению свойства

 

procedure SetForma_otcheta(Value: TForma_otcheta); // метод для записи значения свойства

  published     

    procedure Generaciya_otcheta;

    property Forma_otcheta: TForma_otcheta read GetForma_otcheta write

Информация о работе Проектирование информационной системы на основе объектно – ориентированного подхода, средствами языка моделирования UML и CASE – инструмен