Применение объектно-ориентированного подхода при проектировании информационной системы (Описание предметной области информационной системы оптовой базы)

Содержание:

ВВЕДЕНИЕ

Объектно-ориентированное проектирование-это построение программных систем в виде структурных коллекций, реализующих абстрактные типы данных.

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

Преимущества объектно-ориентированного метода:

- работать на более высоком уровне абстракции;

- нет "прыжков" между фазами;

- поддержка данных, которые, как правило, более стабильны, чем функции;

- поощрять и поддерживать классические достоинства хорошего программирования и дизайна;

- в сопровождении инструментов, поддерживающих повторное использование кода.

Объектно-ориентированный подход имеет два аспекта:

- объектно-ориентированная разработка программного обеспечения;

- объектно-ориентированная программная реализация.

Объектно-ориентированная разработка программного обеспечения связана с применением объектно-ориентированных моделей при разработке программных систем и их компонентов.

Объектно-ориентированная разработка включает:

- объектно-ориентированные технологии разработки программных систем;

- инструменты, поддерживающие эти технологии.

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

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

Целью данной курсовой работы является закрепление теоретических знаний по проектированию информационных систем и создание модели информационной системы оптовая база.

Цели курсовой работы:

- обобщение и обобщение знаний по проектированию информационных систем;

- изучение предметной области;

– проектирование информационной системы в соответствии с заданием;

– освоить практические навыки работы с инструментом для разработки информационных систем ModelMaker.

1. ОПИСАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ ИНФОРМАЦИОННОЙ СИСТЕМЫ ОПТОВАЯ БАЗА

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

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

В этом случае вносятся изменения в базу доступных товаров. Во втором случае формируется заявка на предприятие, которое производит данную продукцию.

Список производителей на основе имеющихся. Кроме того, заявки также подаются поставщикам, когда запас товаров этого типа заканчивается.

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

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

2. ПОСТРОЕНИЕ ДИАГРАММЫ МОДЕЛИ ИНФОРМАЦИОННОЙ СИСТЕМЫ ОПТОВОЙ БАЗЫ

2.1 Составление списка действующих лиц

Чтобы создать основную модельную схему информационной системы автошколы, необходимо выявить действующих лиц. Актер-это роль, которую пользователь играет по отношению к системе [2]. После анализа описания предметной области можно выделить следующие субъекты:

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

2. Поставщик (компания) – лицо, которое занимается доставкой товаров и продукции.

3. Покупатель-клиент распределительных центров, выбирает товар для покупки, если не будет доступен выбранный товар, подает заявку.

Теперь необходимо создать в ModelMaker главную диаграмму модели и диаграммы действующих лиц (рис. 1).

Рисунок 1 – Перечень действующих лиц в главной диаграмме модели

2.2 Составление перечня вариантов использования

Следующий шаг-Составить список вариантов использования.

Прецедент-это последовательность действий, выполняемых системой в ответ на событие, вызванное каким-либо внешним объектом (субъектом) [2].

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

- Заполните форму заявки на покупку. Действующее лицо "покупатель" заполняет форму заявки на покупку товара в оптовой базе данных, указав наименование и количество товара.

- Проанализируйте приложение. Система уведомляет администратора о поступившем запросе на покупку, а он, в свою очередь, анализирует его данные, делает запрос в систему о сроках продажи товара и оплаты за товар и сохраняет подтверждение заявки в системе, система уведомляет покупателя.

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

- Примите заказ клиента. Администратор утверждает принятие заказа поставщика, система рассылает цены заказчикам.

- Установите расписание. Система предоставляет администратору форму, в которой он указывает время доставки и адрес в базе данных sweat.

- Сделать обзор товаров, произведенных поставщиками. Составляются списки тех видов продукции, которые могут представлять интерес для потенциальных оптовых покупателей.

- Создание отчета за определенные периоды времени о работе.

– Сформировать отчет по списку оптовых покупателей.

- Сформировать отчет по заявкам на товары.

- Создание отчета по анализу продаж.

Все варианты использования нужно добавить в главную диаграмму модели. Результат представлен на рисунке 2.

Рисунок 2 – Список вариантов использования информационной системы оптовой базы

3. ДИАГРАММА ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ ИНФОРМАЦИОННОЙ СИСТЕМЫ ОПТОВОЙ БАЗЫ

3.1 Построение диаграммы вариантов использования

Диаграмма вариантов использования описывает функциональные возможности системы и используется при взаимодействии разработчиков с пользователями и клиентами системы. На диаграмме вариантов использования показаны внешние субъекты и их связь с аспектами использования системы [2].

Необходимо добавить актеров и варианты использования из списков на диаграмму. Диаграмма вариантов использования показана на рис. 3. Необходимо также добавить контекст актеров.

Рисунок 3 – Диаграмма вариантов использования информационной системы оптовой базы

3.2 Описание вариантов использования

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

- Заполните форму заявки на покупку.

- Введите данные о продавце и товаре.

- Сформировать отчет по заявкам на товары.

- Заполните форму заявки на товар.

Краткое описание. Этот вариант использования описывает, как покупатель заполняет форму заявки на покупку.

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

Откройте форму заявки для заполнения списка товаров.

Введите количество, название оптового продукта.

Выберите ожидаемое время доставки.

Сохраните изменения в системе.

Уведомить администратора о полученной заявке (выполняемой системой).

Предварительное условие.

Клиент должен войти в систему до заполнения формы.

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

В случае успешного использования администратор анализирует полученный запрос и принимает решение о подтверждении. В противном случае состояние системы не изменяется.

4. АРХИТЕКТУРНЫЙ АНАЛИЗ ИНФОРМАЦИОННОЙ СИСТЕМЫ ОПТОВОЙ БАЗЫ

Перед построением диаграмм последовательностей необходимо выделить список классов для потоков событий прецедентов на основе системных требований. Имена классов должны быть даны на основании системных требований и знаний предметной области.

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

Граничные классы (Boundary) - служат посредниками при взаимодействии внешних объектов с системой.

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

Классы управления-обеспечивают координацию объектов в системе.

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

Первым событием в этом случае использования является событие "открыть форму заказа в базе данных". Для реализации этого события потребуется сообщение, источник сообщения и приемник сообщения. Источником сообщения станет актер "покупатель". Сообщение будет адресовано граничному классу с именем "RequestForm" (форма заявки на покупку). Эта форма является посредником во взаимодействии покупателя с системой.

Для реализации второго события "оформление количества и наименований продукции "необходимо добавить в model Manager класс" ControllerRecord " (контроллер записей), который будет координировать ввод данных в электронную базу данных. Поскольку система хранит данные клиента, содержащие список продуктов, название продукта, контакты, выбранную категорию, можно выбрать класс сущности "ListStudents" (список клиентов) – таблицу с данными клиента. Анализируя другие события и рассуждая аналогичным образом, можно выявить и другие классы, необходимые для реализации основного потока событий рассматриваемого прецедента.

Результатом этого варианта использования будет приложение, созданное системой, так как сами приложения не хранятся в системе, а только отправляются администратору для дальнейшего анализа, необходимо создать граничный класс: "запрос" (Application). Ниже приведен полный список:

Граничный класс RequestForm - это электронная форма заявки на продукт.

Класс Boundary запрашивает приложение для продукта.

Класс управления ControllerRecordRequest-контроллер записей персональных данных о покупателе в электронной базе данных.

Ниже приведены списки классов для этих вариантов использования.

Список классов для прецедента " создание отчета по заявкам на товары»:

Граничный класс EAReportForm-электронная форма для формирования отчета: введение данных о продукте.

Manager ControllerEAReport-события контроллера.

Class-entity InternalExamResults-таблица с результатами приложений.

Далее нужно создать список классов в ModelMaker. Он представлен на рисунке 5.

Рисунок 5 – Перечень классов модели информационной системы оптовой базы

4.1 Диаграммы последовательности

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

На основе диаграммы вариантов использования после анализа каждого варианта использования в отдельности необходимо создать диаграмму последовательности вариантов использования.

Схема последовательности действий " заполните форму заявки на товар»

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

TRequestForm-электронная форма заявки на товар, граничный класс (граница).

TRequest-приложение для товаров, граничный класс (Boundary).

TControllerRecordRequest-контроллер записей персональных данных о покупателе в электронной базе данных, класс управления (Control).

Актер-покупатель.

После анализа описания варианта использования можно добавить следующие сообщения на эту схему последовательностей:

От действующего лица " покупатель "к граничному классу" TRequestForm " передается сообщение: 1. Форма запроса "заявка".

От граничного класса " TRequestForm "к актеру" Buyer " передается сообщение: 2. Подача формы "заявление".

От актера "покупатель" отправляет сообщение самоделегирование: 3. Ввод персональных данных.

От актера " покупатель "к классу управления" TControllerRecordRequest " передается сообщение: 4. Сохранять изменения.

Менеджеру класса "TControllerRecordRequest" отправляется сообщение на самоделегирование: 5. Подать заявление.

Диспетчеру класса "TControllerRecordRequest" в граничный класс TRequest отправляется сообщение: 6.Отправить запрос.

От действующего лица " покупатель "к граничному классу" TRequestForm " передается сообщение: 7.Закрытие формы заявки».

Созданная диаграмма последовательности для данного варианта использования представлена далее на рисунке 6.

Рисунок 6 – Диаграмма последовательности для варианта использования «Заполнить форму заявки на товар»

Таким же образом создаются схемы последовательностей для случаев использования "ввод данных о назначенном поставщике" и "формирование отчета о допуске к экзамену ГИБДД".

Схема последовательности действий для "введите данные о назначенном поставщике»

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

TDataLearnerForm-электронная форма для ввода данных Заказчика, класс границы (Boundary).

TListCarInstructor-таблица записей сущности класса товаров (Entity).

Тлеарнер соответствует актеру "заказчик", класс-сущность.

TInstructor-соответствует действующему лицу "поставщик", класс-сущность.

Актер-администратор.

После анализа описания варианта использования можно добавить следующие сообщения на эту схему последовательностей:

От администратора актера к граничному классу "TDataLearnerForm" передается сообщение: 1. Форма запроса "данные клиента".

От актера " администратор "к классу управления" TControllerRecordLearner " передается сообщение: 2. Запрос данных.

Диспетчер класса "TControllerRecordLearner" класс-сущность "TListCarInstructor" передал сообщение: 3. Запрос информации о продукте.

Менеджеру класса "TControllerRecordLearner" отправляется сообщение на самоделегирование: 4. Формирование запроса.

От актера "администратор" отправляет сообщение самоделегирование: 5. Определите продукт.

От администратора актера к граничному классу "TDataLearnerForm" передается сообщение: 6. Ввод данных.

От актера " администратор "в класс управления" TControllerRecordLearner " отправляется сообщение: 7. Сохраните изменения в системе.

Диспетчер класса "TControllerRecordLearner" класс-сущность" TLearner " передал сообщение: 8. Отправьте информацию покупателю.

Диспетчер класса "TControllerRecordLearner" класс-сущность" TInstructor " передал сообщение: 9. Сообщите поставщику.

Созданная диаграмма последовательности для данного варианта использования представлена далее на рисунке 7.

Рисунок 7 – Диаграмма последовательности для варианта использования «Внести данные о назначенном товаре»

4.2 Диаграмма классов

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

Диаграммы классов также показывают атрибуты классов, операции классов и ограничения, накладываемые на отношения между объектами.

Диаграмма классов включает набор классов моделей и описание каждого класса.

Обязательные атрибуты и методы классов определяются на основе анализа диаграмм последовательности. Чтобы включить их в класс, используйте функцию add Property.

На основе диаграмм последовательности "для ввода данных о назначенном продукте" можно добавить в класс "TListCarInstructor" следующие свойства:

- "Полное имя".

– Автомобиль.

- "QuantityLearner".

Далее необходимо указать видимость свойства.

Общественность (В Целом). Это значение предполагает, что атрибут будет виден всем остальным классам. Любой класс может просмотреть или изменить значение атрибута.

Частная (закрытая). Соответствующий атрибут не виден другим классам.

Защищенный (protected). Этот атрибут доступен только классу и его потомкам.

В этом случае все атрибуты являются общедоступными.

Далее необходимо определить операцию. Для атрибута "FullName"в группе чтения значение атрибута задается методом. Система ModelMaker автоматически генерирует имя: GetFullName. В группе Write Access также необходимо выбрать метод. Система создает имя метода SetFullName. В качестве параметра указывается любое имя. В данном случае, значение. Аналогично, аксессоры создаются для других атрибутов этого класса.

Необходимо подготовить программную реализацию методов (GetFullName, SetFullName). На странице реализация необходимо прописать следующий код для строк:

Для getfullname: Result:=FFullName.

Для setfullname: FFullName:=значение.

Следующий этап-создание данного класса операций, реализация которого выполняет бизнес-функцию. Они также идентифицируются на основе анализа диаграммы последовательности.

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

Для включения в класс операции реализации следует использовать функцию Add Metods. Таким образом, для этого класса можно выделить следующие операции реализации:

AddRecord-добавление новой записи в класс.

DeleteRecord-удаление записи из класса.

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

Атрибуты и методы устанавливаются аналогично другим классам.

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

Класс «InternalExamResults»:

– «NameLearner».

– «PracticeResult».

– «TheoryResult».

Класс «TInstructor»:

– «FullName».

– «DOB».

– «PassportData».

– «Address».

– «Education».

– «DrivingExperience».

Для электронных форм можно выделить две операции:

– «OpenForm» (открыть форму).

– «CloseForm» (закрыть форму).

Операции класса ExamAdmissionReport:

– «CreateReport» (Создать отчет).

– «DestroyReport» (Удалить отчет).

– «PrintReport» (Отправить отчет на печать).

Созданная диаграмма классов представлена на рисунке 9.

Рисунок 9 – Диаграмма классов информационной системы оптовой базы

4.3 Модуль проекта

Следующим этапом проектирования информационной системы оптовой базы данных является создание нового модуля, в котором будут представлены созданные классы моделей. Чтобы создать новый модуль, перейдите на панель "единицы измерения" и используйте функцию "Добавить" (Add module). Необходимо указать расположение исходного файла (относительное имя файла единицы), указать подходящее имя файла и путь, а также добавить классы для включения в модуль. После завершения диалога появится сгенерированный шаблон будущего модуля.

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

Далее представлен модуль проекта информационной системы оптовой базы.

Листинг файла modul.pas

unit modul;

interface

uses

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

Forms, Dialogs;

type

TRequestForm = class (TObject)

public

procedure CloseForm;

procedure OpenForm;

end;

TRequest = class (TObject)

public

procedure CreateRequest;

procedure SendRequest;

end;

TQueryListCI = class (TObject)

end;

TListCarInstructor = class (TObject)

private

FCar: string;

FFullName: string;

FQuantityLearner: Integer;

public

procedure AddRecord;

procedure DeleteRecord;

function GetCar: string;

function GetFullName: string;

function GetQuantityLearner: Integer;

procedure SetCar(Value: string);

procedure SetFullName(Value: string);

procedure SetQuantityLearner(Value: Integer);

property Car: string read GetCar write SetCar;

property FullName: string read GetFullName write SetFullName;

property QuantityLearner: Integer read GetQuantityLearner write

SetQuantityLearner;

end;

TLearner = class (TObject)

end;

TInternalExamResults = class (TObject)

private

FNameLearner: string;

FPracticeResult: string;

public

procedure AddRecord;

procedure DeleteRecord;

function GetNameLearner: string;

function GetPracticeResult: string;

function GetTheoryResult: string;

procedure SetNameLearner(const Value: string);

procedure SetPracticeResult(Value: string);

procedure SetTheoryResult(Value: string);

property NameLearner: string read GetNameLearner write SetNameLearner;

property PracticeResult: string read GetPracticeResult write

SetPracticeResult;

property TheoryResult: string read GetTheoryResult write SetTheoryResult;

end;

TInstructor = class (TObject)

private

FAddress: string;

FDOB: string;

FDrivingExperience: string;

FEducation: string;

FFullName: string;

FPassportData: TPassportData;

public

function GetAddress: string;

function GetDOB: string;

function GetDrivingExperience: string;

function GetEducation: string;

function GetFullName: string;

function GetPassportData: TPassportData;

procedure SetAddress(Value: string);

procedure SetDOB(Value: string);

procedure SetDrivingExperience(Value: string);

procedure SetEducation(Value: string);

procedure SetFullName(Value: string);

procedure SetPassportData(Value: TPassportData);

property Address: string read GetAddress write SetAddress;

property DOB: string read GetDOB write SetDOB;

property DrivingExperience: string read GetDrivingExperience write

SetDrivingExperience;

property Education: string read GetEducation write SetEducation;

property FullName: string read GetFullName write SetFullName;

property PassportData: TPassportData read GetPassportData write

SetPassportData;

end;

информационный оптовый рascal

TExamAdmissionReport = class (TObject)

public

procedure CreateReport;

procedure DestroyReport;

procedure PrintReport;

end;

TEAReportForm = class (TObject)

public

procedure CloseForm;

procedure OpenForm;

end;

TDataLearnerForm = class (TObject)

public

procedure CloseForm;

procedure OpenForm;

end;

TControllerRecordRequest = class (TObject)

end;

TControllerRecordLearner = class (TObject)

end;

TControllerEAReport = class (TObject)

end;

procedure Register;

implementation

procedure Register;

begin

end;

{

********************************* TRequestForm *********************************

}

procedure TRequestForm.CloseForm;

begin

end;

procedure TRequestForm.OpenForm;

begin

end;

{

*********************************** TRequest ***********************************

}

procedure TRequest.CreateRequest;

begin

end;

procedure TRequest.SendRequest;

begin

end;

{

****************************** TListCarInstructor ******************************

}

procedure TListCarInstructor.AddRecord;

begin

end;

procedure TListCarInstructor.DeleteRecord;

begin

end;

function TListCarInstructor.GetCar: string;

begin

Result:=FCar

end;

function TListCarInstructor.GetFullName: string;

begin

Result:=FFullName

end;

function TListCarInstructor.GetQuantityLearner: Integer;

begin

Result:=FQuantityLearner

end;

procedure TListCarInstructor.SetCar(Value: string);

begin

FCar:=value

end;

procedure TListCarInstructor.SetFullName(Value: string);

begin

FFullName:=value

end;

procedure TListCarInstructor.SetQuantityLearner(Value: Integer);

begin

FQuantityLearner:=value

end;

{

***************************** TInternalExamResults *****************************

}

procedure TInternalExamResults.AddRecord;

begin

end;

procedure TInternalExamResults.DeleteRecord;

begin

end;

function TInternalExamResults.GetNameLearner: string;

begin

end;

function TInternalExamResults.GetPracticeResult: string;

begin

end;

function TInternalExamResults.GetTheoryResult: string;

begin

end;

procedure TInternalExamResults.SetNameLearner(const Value: string);

begin

end;

procedure TInternalExamResults.SetPracticeResult(Value: string);

begin

end;

procedure TInternalExamResults.SetTheoryResult(Value: string);

begin

end;

{

********************************* TInstructor **********************************

}

function TInstructor.GetAddress: string;

begin

end;

function TInstructor.GetDOB: string;

begin

end;

function TInstructor.GetDrivingExperience: string;

begin

end;

function TInstructor.GetEducation: string;

begin

end;

function TInstructor.GetFullName: string;

begin

end;

function TInstructor.GetPassportData: TPassportData;

begin

end;

procedure TInstructor.SetAddress(Value: string);

begin

end;

procedure TInstructor.SetDOB(Value: string);

begin

end;

procedure TInstructor.SetDrivingExperience(Value: string);

begin

end;

procedure TInstructor.SetEducation(Value: string);

begin

end;

procedure TInstructor.SetFullName(Value: string);

begin

end;

procedure TInstructor.SetPassportData(Value: TPassportData);

begin

end;

{

***************************** TExamAdmissionReport *****************************

}

procedure TExamAdmissionReport.CreateReport;

begin

end;

procedure TExamAdmissionReport.DestroyReport;

begin

end;

procedure TExamAdmissionReport.PrintReport;

begin

end;

{

******************************** TEAReportForm *********************************

}

procedure TEAReportForm.CloseForm;

begin

end;

procedure TEAReportForm.OpenForm;

begin

end;

{

******************************* TDataLearnerForm *******************************

}

procedure TDataLearnerForm.CloseForm;

begin

end;

procedure TDataLearnerForm.OpenForm;

begin

end;

end.

5. ДОКУМЕНТИРОВАНИЕ ПРОЕКТА ИНФОРМАЦИОННОЙ СИСТЕМЫ ОТПОВОЙ БАЗЫ

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

Создание документации осуществляется с помощью мастера (рис. 10). В диалоговом режиме мастера создания нормативной документации на английском языке по заявленной элементов (свойств, методов и т. д.).

Рисунок 10 – Документирование свойства «Address»

Поскольку ModelMaker не был локализован, русская кодировка не учитывается в созданном RTF файле, поэтому при необходимости необходимо вручную изменить кодировку в созданном файле или использовать передачу текстовых фрагментов (через буфер обмена) в полученный RTF файл. Предварительно русские комментарии должны быть сформированы на вкладках документов созданных элементов.

Затем необходимо создать файл справки с помощью команды файл справки на панели документация. Система создаст файл справки в формате RTF (рис. 11).

Рисунок 11 – Окно файла справки help.rtf

ЗАКЛЮЧЕНИЕ

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

В процессе проектирования были определены субъекты ("администратор", "заказчик", "поставщик"), варианты использования ("заполнить форму заявки на покупку", "проанализировать заявку", "ввести данные о продавце и товаре", "принять заказ покупателя", "установить график", "сделать обзор данных о товарах, произведенных поставщиками", "сформировать отчет за определенные периоды времени о работе", "Сформировать отчет по списку оптовых покупателей"," сформировать отчет по заявкам на товары","сформировать отчет по анализу продаж"). Проведено краткое описание вариантов использования, построены диаграммы последовательностей, определены классы, их операции и атрибуты, построена диаграмма классов.

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

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

1. Проектирование информационных систем: Методические указания к выполнению курсовой работы для студентов специальности 351400 «Прикладная информатика в экономике» / Сост. П.В. Минеев. Красноярск, КГТУ, 2014. 36 с.

2. Проектирование информационных систем: учеб. пособие / П. В. Минеев ; Сиб. федер. ун-т, ХТИ – филиал СФУ. – Абакан : РИСектор ХТИ – филиала СФУ, 2016.

3. Дубаков А.А. Проектирование информационных систем: Учебное пособие. Томск.: Изд. ТПУ, 2016.