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

ВВЕДЕНИЕ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

– освоить практические навыки работы с инструментом для разработки информационных систем 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). Ниже приведен полный список: