Файл: Проектирование и реализация операций бизнес-процесса «Ежедневный складской учет».pdf

К настоящему времени наибольшее распространение получили следующие две основные модели ЖЦ:

- каскадная модель (70-85 г.г.);

- спиральная модель (86-90 г.г.).

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

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

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

- выполняемые в логичной последовательности этапы работ позволяют планировать сроки завершения всех работ и соответствующие затраты (рис.3).

Рис. - 3. Каскадная схема разработки

Каскадный подход хорошо зарекомендовал себя при построении ИС, для которых в самом начале разработки можно достаточно точно и полно сформулировать все требования, с тем чтобы предоставить разработчикам свободу реализовать их как можно лучше с технической точки зрения. В эту категорию попадают сложные расчетные системы, системы реального времени и другие подобные задачи. Однако, в процессе использования этого подхода обнаружился ряд его недостатков, вызванных прежде всего тем, что реальный процесс создания ИС никогда полностью не укладывался в такую жесткую схему. В процессе создания ИС постоянно возникала потребность в возврате к предыдущим этапам и уточнении или пересмотре ранее принятых решений. В результате реальный процесс создания ИС принял следующий вид (рис. 4):

Рис. 4 - Реальный процесс разработки ПО по каскадной схеме

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

Для преодоления перечисленных проблем была предложена спиральная модель ЖЦ (рис. 5), делающая упор на начальные этапы ЖЦ: анализ и проектирование. На этих этапах реализуемость технических решений проверяется путем создания прототипов. Каждый виток спирали соответствует созданию фрагмента или версии ИС, на нем уточняются цели и характеристики проекта, определяется его качество и планируются работы следующего витка спирали. Таким образом углубляются и последовательно конкретизируются детали проекта и в результате выбирается обоснованный вариант, который доводится до реализации.

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

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

Рис 5 - Спиральная модель ЖЦ

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

2.3 База данных информационной системы

На этапе концептуального моделирования базы данных используем полученные на предыдущем этапе перечень объектов. Уточняем характеристики каждого объекта (атрибуты) и устанавливаем связь между объектами. Строим ERD - диаграмму.

При разработке ER-моделей мы должны получить следующую информацию о предметной области:

- список сущностей предметной области.

- список атрибутов сущностей.

- описание взаимосвязей между сущностями.

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

Возьмем из предыдущего раздела (2.1) необходимые данные - это будут потенциальные кандидаты на сущности и атрибуты, и проанализируем их.

Покупатель, Накладная, Товар - явные кандидаты на сущность.

Склад- под вопросом. Выясняем сколько складов имеет фирма. Если несколько, то это будет кандидатом на новую сущность.

Наличие товара– это атрибут, но атрибут какой сущности?

Сразу возникает очевидная связь между сущностями - "покупатели могут покупать много товаров" и "товары могут продаваться многим покупателям". Первый вариант диаграммы выглядит так на рис.6:

Рис. 6 - Первый вариант диаграммы

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

Как связаны эти сущности между собой и с сущностями "Покупатель" и "Товар"? Покупатели покупают товары, получая при этом накладные, в которые внесены данные о количестве и цене купленного товара. Каждый покупатель может получить несколько накладных. Каждая накладная обязана выписываться на одного покупателя. Каждая накладная обязана содержать несколько товаров (не бывает пустых накладных). Каждый товар, в свою очередь, может быть продан нескольким покупателям через несколько накладных. Кроме того, каждая накладная должна быть выписана с определенного склада, и с любого склада может быть выписано много накладных. Таким образом, после уточнения, диаграмма будет выглядеть следующим образом на рис. 7:

Рис. 7 – Уточненная диаграмма

Беседуя с сотрудниками фирмы, выясняем следующее:

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

- каждый товар имеет наименование, цену, а также характеризуется единицами измерения;

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

- каждый склад имеет свое наименование.

Снова выписываем все существительные, которые будут потенциальными атрибутами, и проанализируем их:

- юридическое лицо – мы работаем только с юридическими лицами.

- наименование покупателя - явная характеристика покупателя.

- адрес - явная характеристика покупателя.

- банковские реквизиты - явная характеристика покупателя.

- наименование товара - явная характеристика товара.

- цена товара - характеристика товара. Отличается ли эта характеристика от цены в накладной?

- единица измерения - явная характеристика товара.

- номер накладной - явная уникальная характеристика накладной.

- дата накладной - явная характеристика накладной.

- список товаров в накладной - список не может быть атрибутом. Вероятно, нужно выделить этот список в отдельную сущность.

- количество товара в накладной - это явная характеристика не просто "товара", а "товара в накладной".

- цена товара в накладной - характеристика товара в накладной. Но цена товара уже встречалась выше - это одно и то же?

- сумма накладной - явная характеристика накладной. Эта характеристика не является независимой. Сумма накладной равна сумме стоимостей всех товаров, входящих в накладную.

- наименование склада - явная характеристика склада.

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

С возникающим понятием "Список товаров в накладной" все довольно ясно. Сущности "Накладная" и "Товар" связаны друг с другом отношением типа много-ко-многим. Такая связь, должна быть расщеплена на две связи типа один-ко-многим. Для этого требуется дополнительная сущность. Этой сущностью и будет сущность "Список товаров в накладной". Связь ее с сущностями "Накладная" и "Товар" характеризуется следующими фразами - "каждая накладная обязана иметь несколько записей из списка товаров в накладной", "каждая запись из списка товаров в накладной обязана включаться ровно в одну накладную", "каждый товар может включаться в несколько записей из списка товаров в накладной", " каждая запись из списка товаров в накладной обязана быть связана ровно с одним товаром". Атрибуты "Количество товара в накладной" и "Цена товара в накладной" являются атрибутами сущности " Список товаров в накладной".

Точно также поступим со связью, соединяющей сущности "Склад" и "Товар". Введем дополнительную сущность "Товар на складе". Атрибутом этой сущности будет "Количество товара на складе". Таким образом, товар будет числиться на любом складе и количество его на каждом складе будет свое.

Теперь можно внести все это в окончательную диаграмму рис.8:

Рис. 8 – Окончательная диаграмма

Для получения физической ERD – модели (полученная диаграмма не учитывает особенности конкретной СУБД). По данной концептуальной диаграмме можно построить физическую диаграмму, которая уже будут учитываться такие особенности СУБД, как допустимые типы и наименования полей и таблиц, ограничения целостности и т.п. Физический вариант диаграммы, приведен на рис.9.

Рис. 9 – ERD-диаграмма с описанием типов данных

На данной диаграмме каждая сущность представляет собой таблицу базы данных, каждый атрибут становится колонкой соответствующей таблицы. Обращаем внимание на то, что во многих таблицах, например, "CUST_DETAIL" и "PROD_IN_SKLAD", соответствующих сущностям "Запись списка накладной" и "Товар на складе", появились новые атрибуты, которых не было в концептуальной модели - это ключевые атрибуты родительских таблиц, перешедшие в дочерние таблицы для того, чтобы обеспечить связь между таблицами посредством внешних ключей.

2.4 Функциональные возможности

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

Функциональная модель SADT отображает функциональную структуру объекта, т.е. производимые им действия и связи между этими действиями.

Управляющая информация входит в блок сверху, в то время как информация, которая подвергается обработке, показана с левой стороны блока, а результаты выхода показаны с правой стороны. Механизм (человек или автоматизированная система), который осуществляет операцию, представляется дугой, входящей в блок снизу. На рис.10 SADT-диаграмма с декомпозицией.

Магазин

А-0

Покупатель

Накладная

Склад

Товар

1

2

3

4

А-1

Товар на складе

Выписка с

Запись списка

41

42

43

А-2

Рис.10 – SADT-диаграмма с декомпозицией.

2.5 Категории пользователи

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