Введение
Данная статья посвящена задачи реализации модуля закупок, автоматизирующий процесс заказа материалов.В последнее время, вследствие бурного развития промышленного производства, появилось множество факторов, потребовавших совершенствования методологии и технологии управления. Такие факторы, как:
• ужесточение конкурентной борьбы;
• переход от рынка производителя, когда производственники диктовали количество, сроки и качество выпускаемой продукции, к рынку покупателя, когда заказчик из множества производителей выбирает наиболее ему подходящего;
• внедрение новых технологий и материалов;
• повсеместное внедрение информационных систем;
• удорожание материальных и трудовых ресурсов;
• необходимость в кратчайшие сроки перестраивать производство с целью расширения и замещения номенклатуры выпускаемых изделий.
Возникла необходимость, с одной стороны, систематизировать подходы к управлению производством, а с другой стороны, ускорить решение стоящих перед предприятием задач. Их возросшая сложность диктовала необходимость снять с человека рутинные расчетные функции, задействовав потенциал вычислительной техники и позволив тем самым человеку сконцентрироваться на принятии управленческих решений. Таким образом, были объединены две тенденции: методологическое решение задач управления и применение вычислительной техники для поддержки решения этих задач.
В рамках этой статьи нам необходимо разработать модуль “Заказ” комплексной системы автоматизации производственной фирмы.
Для решения поставленной задачи необходимо рассмотреть следующие вопросы:
· Анализ требований и разработка технического задания
· Разработка информационной и функциональной структуры системы
· Разработка программных моделей
· Тестирование разработанного программного обеспечения
Техническое задание
Необходимо разработать модуль, автоматизирующий закупку, позволяющий оптимизировать заказ на основе данных об остатках и способный ранжировать материалы, для определения необходимости заблаговременного заказа.Перечень подсистем, их назначение и основные характеристики
В состав системы входят следующие подсистемы:· Подсистема хранения данных;
· Подсистема управления данными о продукте;
· Подсистема управления остатками;
· Подсистема управления заказами;
Подсистема хранения данных предназначена для хранения данных системы.
Подсистема управления данными о продукте содержит справочную информацию, свойства продукта. Данные используются для анализа заказываемых материалов в момент оформления заказа и позволяют автоматически подстраиваться под существующие остатки.
Подсистема управления остатками хранит данные об имеющихся остатках. Подсистема служит для определения категорий материалов и позволяет определить необходимость предзаказа.
Подсистема управления заказами автоматизирует работу по управлению заказом.
Требования к квалификации пользователей
Пользователю достаточно обладать базовыми навыками работы в ОС Windows.Требования к целевой платформе
Целевая платформа должна отвечать следующим условиям· Для работы серверной части необходима ОС Windows XP/Vista/Seven с установленным IIS(5.1,6,7).
· Если операционная система, на которой запускается серверная часть, это Windows XP, то должен быть установлен .Net Framework версии 3.5.
· Для работы с клиентской частью необходим браузер.
Спецификация подсистем
1. Подсистема хранения даны1.1. Подсистема строится на базе MSSqlServer 2005
2. Подсистема управления данными о продукте.
2.1. Позволяет добавлять/удалять/редактировать данные о продуктах.
2.2. Позволяет добавлять/удалять/редактировать данные о материалах.
2.3. Позволяет добавлять/удалять/редактировать данные о спецификациях.
2.4. Позволяет назначать продукту спецификацию.
2.5. Позволяет определять между материалами связь «аналог».
3. Подсистема управления остатками.
3.1. Позволяет заносить в систему данные об остатках.
4. Подсистема управления заказами.
4.1. Позволяет добавлять/удалять/редактировать данные о заказе.
4.2. Жизненный цикл заказа включает: прогноз, план, заказ, производство.
Жизненный цикл заказа
1. Создание прогноза1.1. Прогноз создается за 5-6 месяцев до непосредственного производства.
1.2. Менеджер получает необходимую информацию от клиента.
1.3. Менеджер создает прогноз, указывая компонент, на который предполагается заказ и количество.
2. Создание плана
2.1. План создается на основе прогноза за 3-4 месяца до непосредственного производства
2.2. Менеджер распределяет требуемые компоненты по поставщикам, устанавливая время доставки.
3. Создание заказа
3.1. Заказ создается на основе плана за 2 месяца до непосредственного производства.
3.2. Устанавливаются спецификация для компонентов.
3.3. Система производит анализ остатков и производит пересчет необходимых для закупки компонентов.
4. Производство
Разработка архитектуры системы
При разработке архитектуры за основу возьмем трехслойную архитектуру, состоящую из источника данных, домена и представления. Концепция слоев - одна из общеупотребительных моделей, используемых разработчиками программного обеспечения для разделения сложных систем на более простые части.Слой представления охватывает все, что имеет отношение к общению пользователя с системой. Он может быть настолько простым, как командная строка или текстовое меню, но сегодня пользователю, вероятнее всего, придется иметь дело с графическим интерфейсом, оформленным в стиле толстого клиента (Windows, Swing и т.п.) или основанным на HTML. К главным функциям слоя представления относятся отображение информации и интерпретация вводимых пользователем команд с преобразованием их в соответствующие операции в контексте домена (бизнес-логики) и источника данных.
Источник данных — это подмножество функций, обеспечивающих взаимодействие со сторонними системами, которые выполняют задания в интересах приложения. Код этой категории несет ответственность за мониторинг транзакций, управление другими приложениями, обмен сообщениями и т.д. Для большинства корпоративных приложений основная часть логики источника данных сосредоточена в коде СУБД.
Логика домена описывает основные функции приложения, предназначенные для достижения поставленной перед ним цели. К таким функциям относятся вычисления на основе вводимых и хранимых данных, проверка всех элементов данных и обработка команд, поступающих от слоя представления, а также передача информации слою источника данных.
Для более детального проектирования каждого слоя воспользуемся паттернами. Паттерн – описание взаимодействия объектов и классов, адаптированных для решения общей задачи проектирования в конкретном контексте. Паттерны позволяют создавать дизайн с одной стороны, соответствующий решаемой задачи, с другой – настолько общий, что бы удалось учесть все требования, которые могут возникнуть в будущем.
Уровень доступа к данным
Рассмотри паттерны, относящиеся к источнику данных. Основными паттернами являются шлюз записи данных, шлюз таблицы данных и преобразователь данных.Шлюз записи данных представляет собой модель, естественным образом отображающую объектно-ориентированный стиль восприятия реляционных данных:
Рис 1. Шлюз записи данных
Для работы с множеством записей используется шлюз таблицы данных:
Рис 2. Шлюз таблицы данных
Это типовое решение следует иметь в виду и при работе с хранимыми процедурами. Нередко предпочтительно осуществлять доступ к базе данных только при посредничестве хранимых процедур, а не с помощью прямых обращений. В подобной ситуации, определяя шлюз таблицы данных для каждой таблицы, следует предусмотреть и коллекцию соответствующих хранимых процедур.
По мере усложнения бизнес-логики и возрастания значимости модели предметной области простые решения типа активная запись начинают сдавать свои позиции. При разнесении бизнес-логики по все более мелким классам взаимно однозначное соответствие между классами домена и таблицами базы данных постепенно теряется. Реляционные базы данных не поддерживают механизм наследования, что затрудняет применение стратегий и других развитых объектно-ориентированных паттернов.
С усложнением модели предметной области все эти обстоятельства вынуждают создавать промежуточные функциональные уровни. Так, решение типа шлюза способно устранить некоторые проблемы, но оно все еще оставляет нас с моделью предметной области, тесно привязанной к схеме базы данных. В результате при переходе от полей шлюза к полям объектов домена приходится выполнять определенные преобразования, которые приводят к усложнению объектов домена. Более удачный вариант состоит в том, чтобы изолировать модель предметной области от базы данных, возложив на промежуточный слой всю полноту ответственности за отображение объектов домена в таблицы базы данных. Подобный преобразователь данных обслуживает все операции загрузки и сохранения информации, инициируемые бизнес-логикой, и позволяет независимо варьировать как модель предметной области, так и схему базы данных. Это наиболее сложное из архитектурных решений, обеспечивающих соответствие между объектами приложения и реляционными структурами, но его неоспоримое преимущество заключается в полном обособлении двух слоев.
Рис 3. Преобразователь данных
Мы будем пользоваться преобразователем данных для сложных сущностей системы. Для простых сущностей, которых можно один-к-одному соотнести с таблицей базы данных будем пользоваться – шлюзом таблицы данных. Для обеспечения безопасности и стабильности некоторые проверки будут вынесены на сторону сервера базы данных и использоваться через хранимые процедуры.
Уровень бизнес-логики
Рассмотрим паттерны относящиеся к домену. Основными паттернами являются сценарий транзакции, модель предметной области и модуль таблицы.Простейший подход к описанию бизнес-логики связан с использованием сценария транзакции — процедуры, которая получает на вход информацию от слоя представления, обрабатывает ее, проводя необходимые проверки и вычисления, сохраняет в базе данных и активизирует операции других систем. Затем процедура возвращает слою представления определенные данные, возможно, осуществляя вспомогательные операции для форматирования содержимого результата. Бизнес-логика в этом случае описывается набором процедур, по одной на каждую (составную) операцию, которую способно выполнять приложение. Типовое решение сценарий транзакции, таким образом, можно трактовать как сценарий действия, или бизнес-транзакцию.
Рис 4. Сценарий транзакции
С возрастанием уровня сложности бизнес-логики паттерн сценарий транзакции демонстрирует и ряд недостатков. Если нескольким транзакциям необходимо осуществлять схожие функции, возникает опасность дублирования фрагментов кода. С этим явлением удается частично справиться за счет вынесения общих подпрограмм "за скобки", но даже в этом случае большая часть дубликатов остается на месте. В итоге приложение может выглядеть как беспорядочная мешанина без отчетливой структуры.
Выбор модели предметной области позволит избежать роста сложности кода с ростом сложности бизнес-логики. Вместо использования одной подпрограммы, несущей в себе всю логику, которая соответствует некоторому действию пользователя, каждый объект наделяется только функциями, отвечающими его природе.
Рис 5. Модель предметной области
Для определения зачтенного дохода от продажи каждого продукта в рамках заданного контракта алгоритм вычислений зависит от типа продукта. С увеличением количества алгоритмов расчета дохода для паттерна сценарий транзакции придется добавлять в метод дополнительные условия, а для паттерна модель предметной области достаточно создать новый объект "Стратегия определения зачтенного дохода".
Рис 6. Модуль таблицы
Существует и третий вариант структуризации бизнес-логики - модуль таблицы. Этот паттерн очень похож на модель предметной области: в обоих случаях создаются отдельные классы, представляющие контракт, продукт и зачтенный доход. Принципиальное различие заключается в том, что модель предметной области содержит по одному объекту контракта для каждого контракта, зафиксированного в базе данных, а модуль таблицы является единственным объектом. Модуль таблицы при меняется совместно с паттерном множество записей. Посылая запросы к базе данных, пользователь прежде всего формирует объект множество записей, а затем создает объект контракта, передавая ему множество записей в качестве аргумента. Если потребуется выполнять операции над отдельным контрактом, следует сообщить объекту соответствующий идентификатор (ID).
Уровень представления
Рассмотри паттерны, относящиеся к представлению. Основными паттернами являются представление с преобразованием, представление по шаблону и двухэтапное представление.Представление по шаблону позволяет оформлять представление в соответствии со структурой страницы и вставлять в нее специальные маркеры, отмечающие позиции фрагментов динамического содержимого. Представление по шаблону поддерживается целым рядом популярных платформ, многие из которых основаны на модели страниц сервера и позволяют внедрять в текст страницы код на полнофункциональном языке программирования. Такое решение отличается мощностью и гибкостью; если код сложен и запутан, задача сопровождения системы чрезвычайно затрудняется. Поэтому использование технологий страниц сервера требует аккуратности и последовательности в обособлении логики кода от структуры страницы, которое зачастую достигается при посредничестве вспомогательного объекта.
Рис 7. Представление по шаблону
Примером реализации представления с преобразованием может служить XSLT. Эта технология оказывается весьма эффективной, если данные домена сохраняются в формате XML или допускают быстрое преобразование в XML. Входной контроллер выбирает подходящую таблицу стилей XSLT и применяет ее к XML-коду, описывающему модель.
Рис 8. представление с преобразованием
Двухэтапное представление является расширением любого из двух паттернов рассмотренных выше. Двухэтапное представление разделяет процесс на две стадии: на первой на основе данных домена формируется логический экран, который на второй стадии трансформируется в код HTML Для каждого экрана существует одно представление первого этапа, но для приложения в целом — только одно представление второго этапа.
Рис 9. Двухэтапное представление
Достоинство двухэтапного представления заключается в том, что решение о варианте преобразования в HTML принимается в одном месте. Это существенно облегчает задачу внесения глобальных изменений, поскольку для модификации каждого экрана достаточно отредактировать данные единственного объекта. Разумеется, воспользоваться таким преимуществом удастся только в том случае, когда логическое представление остается постоянным, т.е. различные экраны компонуются по одному принципу. Сайты, спроектированные по излишне сложным схемам, единообразием логической структуры обычно не отличаются.
Мы будем использовать представление по шаблону, т.к. оно нативно поддерживается ASP.Net, что снизит затраты на разработку. Для двухэтапного представления у нас, предположительно, будет излишне сложная схема, что приведет к неоправданным сложностям. Также нужно заметить, что благодаря поддержки разделения кода и HTML-разметки страницы, вспомогательные объекты нам не понадобятся.
В следующей статье мы рассмотрим уже непосредственно реализацию нашей системы.
Комментариев нет:
Отправить комментарий