Элементы формализации описания логики развития модели предприятия.
Уменьшение стоимости и улучшения качества систем автоматизации управления предприятиями и их поддержки является важной задачей на сегодняшний день. В частности мировой рынок ERP систем в 2006 году составил 18 млрд и по прогнозам ARC Advisory Group в ближайшие несколько лет он будет демонстрировать среднегодовой рост 6,7% и к 2011 году достигнет отметки 25 млрд. долл. Рынок же корпоративных приложений, частью которого является ERP, будет расти еще быстрее: аналитики оценивают темпы его роста на уровне 8,3% в год.
На рынке представлено большое количество стандартных информационных систем. Все они предлагают решения автоматизации различных областей деятельности предприятий: бухгалтерский учет, управление кадрами, управление финансами и др. Кроме того, подобные решения изначально проектируются и разрабатываются под определенные области рынка, что должно максимально приблизить информационную систему к требованиям, выставляемым конкретным предприятием.
При этом большинство решений требует значительных ресурсов и времени для внедрения. Причем, чем больше функций автоматизирует программное решение, тем сложнее проходит его внедрение. Для особенно сложных систем происходит не просто настройка программной системы на требования предприятия, а также и обратный процесс перестройки предприятия под внедряемое решение.
Не всегда мы можем быть удовлетворенны готовым программным решением, даже учитывая, что платформа является открытой и позволяет модифицировать решение. Довольно часто возникают специфические аспекты деятельности предприятия, которые не учитываются в существующих программных решениях, и приведение решений к удовлетворению требований, выливается в большие сложности. Эта проблема может возникать, как на этапе внедрения решения, так и в ходе эксплуатации системы.
Несмотря на то, что многие программные решения являются открытыми, возникает необходимость разработки системы с нуля для автоматизации определенных аспектов деятельности предприятия, которые не могут быть удовлетворены предложенными на рынке решениями. Разработка системы с нуля часто предполагает более высокую стоимость разработки, чем при внедрении готовой информационной системы.
Не менее важным вопросом является моделирование деятельности предприятия. Такое моделирование позволяет четко устанавливать регламенты работ, функциональные обязанности, а, кроме того, показывает слабые места, и дает возможность скорректировать структуру и функционирование предприятия таким образом, чтобы повысить общую эффективность его деятельности. Здесь нужно учесть то, что средства моделирования деятельности предприятия на сегодняшний день слабо связаны со средствами разработки информационных систем. Это приводит к возникновению дорогостоящего цикла разработки и модификации решений автоматизации управления предприятием.
В связи с этим, мы видим необходимость в разработке средств позволяющих всесторонне описывать деятельность предприятия для автоматического построения на основе такого описания информационной системы.
Эти средства позволят сократить стоимость разработки информационной системы и поддержки ее в актуальном состоянии, через сокращение и упрощения цикла моделирования, разработки и модификации системы.
Возникает необходимость в создании строго формализованных принципов описания бизнес модели и разработки алгоритмов построения информационной системы на основе этой модели.
Кратко сформулируем основные требования:
1. Строгий способ описания бизнес модели, но достаточно простой, чтобы им смог овладеть аналитик, описывающий бизнес модель.
2. Механизм обеспечения непротиворечивости бизнес модели.
3. Механизм выявления неполноты бизнес модели, позволяющий расширять множество принимаемых решений, при этом, не требуя изначально закладывать всю полноту логики развития бизнес модели.
4. Возможность для конечного пользователя описывать свои решения достаточно свободно, с целью расширения множества возможных ситуаций, без изменения описания бизнес модели.
Определим, что модель автоматизации управления предприятием формируется на основе вносимых в нее фактов и правил допустимого развития модели.
Пусть f – факт. Множество F – множество всех известных фактов о предприятии. Множество известных фактов на данный момент времени будем называть состоянием модели. S - множество всех возможных состояний модели. Множество допустимых отображений φ:S->S будем называть логикой развития модели.
В виду того, что применение правил преобразования зависит от множества событий инициируемых внешними пользователями и в тоже время с точки зрения развития модели представляется одним интерактивным шагом, целесообразно представлять отображение как:
φ = φos* φr* φso,
где φso - правило формирования объектов в некотором состоянии, φr - правила преобразования объектов, φos – правило формирования нового состояния из имеющихся объектов.
Предлагаемый метод позволяет представлять имеющиеся факты в удобном виде для реакции модели на вновь возникающие события, за счет формирования объектов определенного вида, а правила преобразования объектов удобно представлять, как совокупность тривиальных действий и условий их применения, что значительно повышает гибкость описания.
Не каждый новый факт согласуется с текущим состоянием модели. Новый факт может быть принят только в случае подбора сочетающейся группы правил. В случае необходимости данная ситуация может быть разрешена только при расширении модели.
Таким образом, формулирования необходимого решения сводиться к выбору композиции преобразований φ.
При описании модели в качестве инструмента имеем три подмножества множества преобразований φ:{φios}, {φjr}, {φkso}.
В отдельных случаях конечному пользователю может быть предоставлена возможность самому определять как новые типы объектов, так и правилах их преобразования.
Таким образом, мы предлагаем рассмотреть описание модели предприятия в виде тройки < F, O, Φ >, где
F – множество всех фактов,
O – множество объектов, средствами которых пользователь может описывать возможное развитие модели предприятия,
Φ – множество правил преобразования относящихся к любым из трех подмножеств преобразований.
При построении модели выделяются объекты, а также их атрибуты. Все атрибуты собираются в совокупность. К этой совокупности добавляются особые атрибуты, конкретизирующие принадлежность объекта к тому или иному типу.
На основе данной совокупности строится модель фактов.
Факты не описывают множество допустимых значений по своим атрибутам. Допустимые множества значения для атрибутов будут определяться блоком правил Φ.
Считаем, что множество фактов F – есть множество n-мерных векторов, где n – количество всех атрибутов.
Для определения того, каким образом можно описать поведения объектов в предметной области существует набор правил, который ограничивает возможные преобразования объектов и функции Φ, которые за основу берут правила ограничений.
Выбрать объект или определить функцию φso не всегда является тривиальным указанием, так называемого, типа объекта. Выбор объекта означает показать те ограничения, которые мы накладываем на атрибуты. А функция φso должна вернуть объект с подмножеством атрибутов, для которых определены множества допустимых значений.
С выбранным объектом предполагается совершить некоторые преобразования. Для этого подбираются функции φr. По умолчанию множество таких функций позволяет производить тривиальные преобразования с объектами, не противоречащими правилам ограничения модели. А именно, каждая такая функция изменяет значение одного атрибута объекта. При этом может изменяться и множество допустимых атрибутов, если изменяются множества допустимых значений по ним.
Из тривиальных функций φr возможно составлять композиции, которые определяют более сложные преобразования.
Рассмотрим пример. В качестве примера рассмотрим задачу кадрового учета в вузе.
Пусть имеется множество персон. Каждая персона имеет атрибуты: ФИО, дата рождения, пол. Пусть имеется множество студентов. Каждый студент является персоной и имеет статус обучения. Статус обучения может принимать одно из следующих значений: обучается, отчислен. Кроме того, для обучающегося студента определен курс и учебный план. Множество курсов, на которых может обучаться студент, зависит от допустимого множества курсов учебного плана, на котором студент обучается. Учебный план также имеет наименование. Студент, если он обучается, может быть переведен с одного учебного плана на другой и/или с курса на курс. Наконец, обучающийся студент может быть отчислен. А отчисленный студент восстановлен.
В примере имеем множества объектов: персона, студент, курс, учебный план. Для персоны заданы атрибуты: ФИО, дата рождения, пол. Для студента помимо атрибутов персоны задан также и статус обучения. Причем если студент имеет статус – обучающийся, то для студента также заданы и атрибуты курс и учебный план. Для учебного плана заданы: наименование и множество допустимых курсов.
Можем разложить пример на множество атрибутов:
Признак персона, ФИО, Дата рождения, Пол, Признак студент, Статус обучения, Курс обучения, Учебный план обучения, Признак учебный план, Множество допустимых курсов учебного плана, Название учебного плана.
Для нашего примера можем показать правила, которые выстраиваются из установленных требований.
∀x x∈F & признак_персона(x)=true ↔ фио(x) ∈ множество_строк & дата_рождения(x) ∈ множество_дат & пол(x) ∈ {'мужчина','женщина'}
∀x x∈F & признак_студент(x)=true →признак_персона(x)=true &статус_обучения(x)∈{'обучается','отчислен'}
∀x x∈F & статус_обучения(x) ='обучается' ↔курс_обучения(x) ∈ множество_допустимых_курсов учебного_плана(учебный_план_обучения(x)) &учебный_план_обучения(x) ∈ {f∶ f∈F & признак_учебный_план(f)=true}
∀x x∈F & признак_учебный_план(x)=true ↔название_учебного_плана(x) ∈ множество_строк &множество_допустимых_курсов_учебного плана(x) ⊂ множество_целых_чисел
Здесь функция(x) – есть функция возвращающая значение по соответствующему атрибуту для объекта x.
Этими 4 правилами мы задали все известные нам ограничения для примера.
Может потребоваться выбрать из обучающихся студентов 3его курса, тогда условием выбора будет:
{x∶x∈F & статус_обучения(x) = 'обучается' & курс_обучения(x)=3}
Для выбранного подмножества F определены множества значений только для атрибутов: признак персона, ФИО, дата рождения, пол, признак студент, статус обучения, курс обучения, учебный план обучения.
Рассмотрим определение операции перевода студента с изменением учебного плана:
φr1 – изменение учебного плана обучения,
φr2 – изменение курса обучения,
а композицию φr = φr2*φr1 назовем переводом студента с учебного плана на учебный план со сменой курса.
Очевидна применимость данной операции – только на студенте обучающемся, так как только на нем определены изменяемые атрибуты. Также очевидно, что при изменении курса происходит проверка, удовлетворяет ли курс учебному плану, поэтому определение курса идет вторым. В противном случае выбор искомого учебного плана был бы не всегда возможен в случае, если у исходного и выбранного учебного плана не пересекаются множества допустимых курсов.
