Автоматизированное рабочее место "Логистика" ЗАО "Приосколье" (стр. 4 из 11)

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

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

Как видно из контекстной диаграммы (рисунок 2), управляющая информация входит в блок сверху (Лицензия на занятие торговлей), в то время как входная информация (Бланк заявки поставщику, Бланк заказа клиента, Список о количестве запасов на складе), которая подвергается обработке, показана с левой стороны блока, а результаты (выход) показаны с правой стороны блока (Заполненный и заверенный бланк заявки, Договора, контрольные документы). Механизм (Работники отдела склада, Работники отдела продаж), который осуществляет операцию, предоставляется дугой, входящий в блок снизу.

Рисунок 2. Контекстная диаграмма.

Далее блок «Автоматизированная система управления складом» разбивается на три процесса, которые представлены на диаграмме декомпозиции процесса (рисунок 3):

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

Формирование заказа клиента;

Оформление договора на продажу.

Рисунок 3. Диаграмма декомпозиции процесса.

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

Основными задачами системы являются:

повышение оперативности и достоверности информации о состоянии предприятия;

повышение контроля выполнения управленческих решений и планов;

снижение риска злоупотреблений со стороны персонала;

оптимизация использования финансовых, трудовых и материальных ресурсов;

разработка и внедрение новых информационных технологий, PR-акции, реклама;

планирование и проведение специальных мероприятий;

продвижение товара;

ценообразование;

оценка эффективности управления.

Основные функции системы:

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

- ведение БД клиентов и товаров;

- составление и оформление заказов клиентов;

составление и оформление заявок поставщикам;

- предоставление необходимой информации клиентам;

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

- осуществление мероприятий по разработке стратегии продаж;

- мотивация сотрудников;

- предложение новых товаров;

- эффективность управления.

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

Генеральный директор;

Работники отдела сбыта, главная функция которых состоит в работе и связи с клиентами;

Работники склада: их главная задача – обеспечение и контролирование товаров.

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

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

Таблица 2

Средства	Rational Rose Enterprise Edition	BPWin 4.0	EasyCase 3.1	Вес критерия
Критерии
цена/доступность	10	10	9	5
объектный подход	10	0	0	5
Функциональный подход	0	10	7	5
требования к ресурсам	7	8	10	3
Техническая поддержка	10	10	1	4
Совместимость с установленным ПО	10	10	2	4
Итого	201	204	122

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

Rational Rose - CASE-средство фирмы Rational Software Corporation (США) - предназначено для автоматизации этапов анализа и проектирования ПО, а также для генерации кодов на различных языках и выпуска проектной документации.

Структура и функции

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

Средства автоматической генерации кодов программ на языке С++, используя информацию, содержащуюся в логической и физической моделях проекта, формируют файлы заголовков и файлы описаний классов и объектов. Создаваемый таким образом скелет программы может быть уточнен путем прямого программирования на языке С++. Анализатор кодов С++ реализован в виде отдельного программного модуля. Его назначение состоит в том, чтобы создавать модули проектов в форме Rational Rose на основе информации, содержащейся в определяемых пользователем исходных текстах на С++. В процессе работы анализатор осуществляет контроль правильности исходных текстов и диагностику ошибок. Модель, полученная в результате его работы, может целиком или фрагментарно использоваться в различных проектах. Анализатор обладает широкими возможностями настройки по входу и выходу. Например, можно определить типы исходных файлов, базовый компилятор, задать, какая информация должна быть включена в формируемую модель и какие элементы выходной модели следует выводить на экран. Таким образом, Rational Rose/С++ обеспечивает возможность повторного использования программных компонент.

В результате разработки проекта с помощью CASE-средства Rational Rose формируются следующие документы:

диаграммы классов;

диаграммы состояний;

диаграммы сценариев;

диаграммы модулей;

диаграммы процессов;

спецификации классов, объектов, атрибутов и операций

заготовки текстов программ;

модель разрабатываемой программной системы.

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

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

Взаимодействие с другими средствами и организация групповой работы

Rational Rose интегрируется со средством PVCS для организации групповой работы и управления проектом и со средством SoDA - для документирования проектов. Интеграция Rational Rose и SoDA обеспечивается средствами SoDA.

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

Для управляемой подмодели предусмотрены операции:

загрузка подмодели в память;

выгрузка подмодели из памяти;

сохранение подмодели на диске в виде отдельного файла;

установка защиты от модификации;

замена подмодели в памяти на новую.

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

2.4 Постановка задач по подсистемам

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

Использование диаграммы UseCase (рисунок 4)– это возможность увидеть систему с ее функциями и подфункциям с точки зрения пользователя.

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