Русский
Русский
English
Авторизация
Ip-адрес
Восстановление пароля
Регистрация
Статистика
Реклама

Показатель

Исследование операций

16.06.2021 16:13:28 | Автор: admin
Cодержание

  1. Введение

  2. Основные понятия и термины

  3. Характеристика ИО как научной дисциплины

  4. Этапы операционного исследования

    • Постановка задачи

    • Построение математической модели

    • Нахождение решения с помощью математической модели

    • Проверка модели и решения

    • Построение процедуры подстройки и решения

    • Осуществление решения

  5. Предметные процессы ИО и задачи

    • Процессы обслуживания

    • Распределения

    • Управления запасами

    • Замены

    • Состязательные

  6. Модели процессов ИО и их логическая структура

    • Постановка задачи

    • Элементы задачи ИО

    • Взаимодействие исполнения и управления при ИО

  7. Литература

Введение

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

Начнем с рассмотрения типичной простой и понятной задачи. Пусть в пределах населенного пункта в точках (х0, х1) имеется n складов с товарами. На каждом складе припаркован под погрузку автоприцеп, который загружается товарами. В других точках (х0, х1) района (окрестности населенного пункта) размещаются заказчики (потребители товаров), которым необходимо эти товары доставить. В n точках (х0, х1) размещены n тягачей, которые должны доставить заказчикам загруженные товарами по их заявкам автоприцепы. Такая доставка связана с расходом топлива, с затратами времени и многими другими явлениями и событиями.

Владелец транспортных средств располагает матрицей:

С = [c_{ij}], i = 1(1)n, j = 1(1)n,

стоимости (затрат) топлива в операции перевозки.

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

Q(X[i,j]) = \sum_{i=1}^{n}\sum_{j=1}^{n}{c_{ij}x_{ij}} min.

Это соотношение называют целевой функцией (ЦФ). Неизвестными здесь являются переменные (xij) , т.е. куда тягач с номером (i) должен доставить груженый прицеп с номером (j). Ясно, что суммарные затраты будут определяться планом Х[i, j] перевозок или выбором переменных (xij) в совокупности. Постоянно будем иметь ввиду очевидное ограничивающее условие: один тягач везет один прицеп, каждый прицеп обслуживается одним тягачом. Из этого условия следует, что каждый элемент (xij), выбираемый для подстановки в ЦФ, не может быть дробным значением, а принимает одно из значений 0 или 1, т.е. (xij 0, i = 1(1)n, j = 1(1)n).Приведенное выше условие интерпретируется в модели как ограничения, накладываемые напеременные (xij).

(i = 1) х11 +х12 ++ х1j + + x1n = 1, j = 1(1)n;

(i = 2) х21 +х22 ++ х2j + + x2n = 1, j = 1(1)n;

(i = 3) х31 +х32 ++ х3j + + x3n = 1, j = 1(1)n;

.. .

(i = i) хi1 + хi2 + + хij + + x in = 1, j = 1(1)n;

. .. .. . . .. .

(i = n) хn1 +хn2 ++ хnj + + x nn = 1; j = 1(1)n.

Каждая (i-я) строка обозначает возможность прибытия на (j-й) склад любого (j-го) из (n) тягачей и представляется суммой, в которой будет выбран один единственный элемент (xij = 1). Относительно столбцов j = 1(1)n системы уравнений также составляются суммы, и каждая из таких сумм также равна единице. В столбцовых суммах также выбирается единственный элемент(xij = 1) Таким образом, будет выбрана таблица (0,1-матрица), заполненная единицами и нулями, но так, что в каждой строке и в каждом столбце оказывается единственная единица. Такие матрицы в математической статистике называются дважды стохастическими. Каждая матрица реализует план Х перевозок и ему соответствует определенное (после подстановки переменных плана в выражение целевой функции) значение ЦФ. Сколько же планов-решений Х можно построить? Это легко посчитать. Первый тягач можно направить в любой из n складов, но второму тягачу будут доступны только n1 складов, третьему n2 складов. Этим трем тягачам соответствует n(n1)(n2) количество планов равное произведению трех сомножителей. Далее число возможностей выбора склада будет сокращаться (для 4-го тягача только n3 выборов), а для последнего nго тягача останется единственная возможность, так как все остальные склады уже распределены между n1 тягачами, всего планов будет |Х[i, j]|= n! Например, если n = 20, то

|Х[i, j]| = 20! = 2 432 902 008 176 640000.

Это 20-ти значное число показывает, что простой перебор хоть и решает все задачи дискретного программирования, но жизни нескольких поколений не хватит, чтобы такой перебор выполнить. Хотя тягачей и складов всего по 20 штук, но самые совершенные компьютеры "повиснут" на подобных вычислениях. Подобная картина в настоящее время имеет место в криптографии. Путем подстановки пробного ключа в дешифратор на выходе можно в случае успеха получить исходный открытый текст. Но ожидать этого, право не стоит. Среди моих публикаций есть одна, где ключ шифра раскрывается за три шага. Но это скорее промах автора примера, который я использовал из пособия для подготовки криптографов, чем везение или мое уменье проводить атаку на шифр. По аналогии с диагональной матрицей (единицы расставлены на главной диагонали) все дважды стохастические матрицы называют диагональными.

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

Основные понятия и термины ИО

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

Цель это описание желаемого состояния или запланированного результата деятельности, на создание (получение) которого направлены ресурсы, усилия. Чаще всего цель или цели (дерево целей) оформляются в форме требуемых значений различных показателей (в ТТЗ на НИР, ОКР и др.)

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

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

Допустимые решения - те решения, которые удовлетворяют наложенным в задаче ограничениям.

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

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

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

Чтобы сравнивать между собой по эффективности разные системы, решения нужно выбрать, т.е. назначить в модели какой-то количественно измеряемый показатель, так называемый

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

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

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

Характеристика научной дисциплины ИО

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

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

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

Предметные процессы ИО и задачи

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

Процессы обслуживания

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

Для решения описанной задачи с ожиданиями применима теория очередей. Для задачи определения порядка обслуживания клиентов применима теория расписаний. Наконец, к задачам определения распределения и группировки каналов и других элементов процессов обслуживания в систему обслуживания применима теория балансирования линий.

Процессы распределения

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

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

Процессы управления запасами

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

Процессы замены

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

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

Состязательные процессы

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

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

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

Этапы операционного исследования

Как можно представить процесс, порядок операционного исследования? Принято в такое исследование включать следующие пункты.

  1. Постановка задачи.

  2. Построение математической модели изучаемой системы

  3. Нахождение решения с помощью модели.

  4. Проверка модели и получение с ее помощью решения.

  5. Построение процедуры подстройки решения.

  6. Осуществление решения.

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

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

Е = Аrgextr F(x,y, ui),

где Е показатель эффективности системы; х,у неуправляемые переменные, ui управляемые переменные, F(x,y, ui) - целевая функция модели. Ограничения, накладываемые на переменные модели, выражаются системами равенств или неравенств дополнительно к основному соотношению показателю эффективности модели, Аrgextr F(x,y, ui) критерий эффективности примененный к целевой функции. Следует заметить, что в публикациях авторы критерием эффективности называют показатель эффективности, а критерий вообще опускается из рассмотрения. КЭ, трактуемый как правило (руководство), не измеряется числом. К этим вопросам следует отнести и вопрос о существовании разных шкал для проведения измерений с учетом отношения, отвечающего той или иной шкале.

Таблица шкал измерений переменных и отношения (МО - метризованное отношение)Таблица шкал измерений переменных и отношения (МО - метризованное отношение)

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

Рисунок 1 Схема постановки задачи и получения логико-структурных решенийРисунок 1 Схема постановки задачи и получения логико-структурных решений

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

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

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

Методы реализации процессов ИО и их логическая структура

Рене Декарт, описывая развитый им метод научного исследования, формулирует четыре основных его правила [3].

  1. Разбиение сложной проблемы на более простые последовательно до тех пор, пока не будут найдены далее неразложимые компоненты.

  2. Нерешенные проблемы следует сводить к решенным. Этим путем находятся решения простых проблем.

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

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

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

Так проверка и корректировка гипотез производятся с помощью хорошо известных пяти методов индукции, создание и развитие которых связано с именами Ф. Бэкона и Дж. Милля [4, 5].

Рисунок 2 Логическая структура проверки гипотез и процесса логико-структурных решенийРисунок 2 Логическая структура проверки гипотез и процесса логико-структурных решений

Причинная связь явлений устанавливается методами единственного сходства (на основе фактов, полученных в наблюдении), единственного различия ( на основе фактов, полученных в эксперименте), объединенным методом (на основе совместно используемых фактов обоих видов). Метод остатков применяется при выявлении неизвестной причины изучаемого явления, а с помощью метода сопутствующих изменений анализируется динамика причинных зависимостей [6, 7 , 9].

Постановка задачи

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

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

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

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

Элементы задачи ИО

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

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

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

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

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

  1. Уточнить перечень целей, определенных на первом этапе постановки задачи.

  2. Уточнить перечень различных стратегий достижения целей.

  3. Определить меру (показатель и критерий) эффективности исследуемой системы.

Взаимодействие исполнения и управления при ИО

Планирующая система связывает объект управления с управляющими органами. В процессе деятельности объекта (рис. 3) происходит преобразование одного состояния объекта в другое (10), что зависит от изменения внешних обстоятельств (9) и предписаний (8), вырабатываемых органами управления на основании плановых представлений объекта (5) и оценок текущего состояния объекта управления (7). Оценки вырабатываются на основании показателей и критериев эффективности (5) и информации (6) от объекта управления. Вся эта цепочка определяет один такт в преобразовании объекта из одного состояния в другое. Для каждого такта необходима своя часть плана. Поэтому после выполнения одного такта в самом плане управление передается следующей его части, что обозначается стрелкой (2) на рис. 3.

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

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

Рисунок 3 План и его связи с частями объектаРисунок 3 План и его связи с частями объекта

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

Литература

1.Азгальдов Г. С., Райхман Э. П. О квалиметрии. М.: Изд. Стандартов, 1973.172 с.

2.Ваулин А. Е. Методы цифровой обработки данных. СПб.: ВИККИ им. А. Ф. Можайского, 1993. 106 с.

3. Декарт Р. Рассуждения о методе с приложениями (Диоптрика, Метеоры, Геометрия) М.: Изд-во АН СССР, 1953.с.9-66.

4.Бэкон Ф. Новый органон. М.: Соцэкгиз,1938. 244 с.

5.Гэри М., Джонсон Д. Вычислительные машины и трудно решаемые задачи. М.: Мир, 1982.

6. Джини К. Логика в статистике. М.: Статистика,1973. 127 с.

7. Квейд Э. Анализ сложных систем. М.: Советское радио,1969.519 с.

8.Квейд Э. Методы системного анализа // Новое в теории и практике управления производством в США.М.: Прогресс, 1971. с.78-99.

9. Корбут А.А., Финкельштейн Ю. Ю. Дискретное программирование М. Наука. Гл. ред. физ.-мат. лит. 1969.

10.Клыков Ю. И. Ситуационное управление большими системами. М.: Энергия,1974.135 с.

11. Макаров И. М. и др. Теория выбора и принятия решений. М.: Наука, 1982. 328 с.

12.ПфанцагльИ. Теория измерений. М.: Наука, 1988.384 с.

13. Таха Х. А. Введение в исследование операций. 7-е изд. М.: Изд. дом Вильямс, 2005.

14.Фишберн П. С. Теория полезности для принятия решений. М.: Наука,1978. 352 с.

Подробнее..
Категории: Информационная безопасность , Научно-популярное , Алгоритмы , Математика , Криптография , Решение , Показатель , Операция , Неравенства , Критерии оценки

Облом, или как провалился любимый ИТ-проект

20.07.2020 20:10:45 | Автор: admin
Его пример другим наука

Предисловие


Это грустная история о неуспехе проекта, который я считал потенциально успешным на все 100 процентов. И почему все кончилось обломом, я до сих пор толком не понимаю.

За свою жизнь айтишника я участвовал в разработке многих успешных проектов. Большинство из них были сравнительно простыми по идее и посредственными по реализации. Справедливости ради, упомяну об исключении выдающемся, на мой взгляд, проекте. Он был совершенно неординарным по замыслу(замысел был со стороны высокопоставленного банковского экономиста) и хороший по реализации. Реализовали его мы на ассемблере. Базой данных служили файлы прямого и последовательного доступа. Проект успешно эксплуатировался.
Однажды, участвуя в очередной посредственной разработке операционного дня банка, я столкнулся с необходимостью вычисления некоторых показателей, значения которых регламентировалось национальным банком. Это уже выходило за рамки дебета и кредита бухгалтерского учета. А я к этому времени прочитал книги Экономикс(автор Кэмпбелл и др.) и Деньги( автор Долан), и приступил к книге Микроэкономика(автора не помню, но зарубежный). Все это и послужило рождению идеи аналитики, как некоего аналога медицинской аналитики. Должны быть определены все показатели, достаточно полно отображающие состояние бизнеса. Это значит должны быть заданы точные правила вычисления показателей и реализован механизм их вычисления и использования. В идеале так и виделись работники с экранами, на которых отображалось текущее и прогнозное состояние дел, за которые отвечает работник. А работник задает вопросы типа:
  • А почему такой скачок у такого-то показателя?
  • А кто совершил такую-то операцию?
  • А что будет с состоянием, если совершить такую-то операцию?
  • А что будет с состоянием, если изменить такие-то показатели на такие-то значения?

И т.д.
И работник на основании всего этого принимает решения. Неужели кто-то откажется от таких перспектив? Ведь это настоящее современное рабочее место для творческого экономиста и менеджера.
В конце концов проект был реализован. И я наивно думал, что пройдет он на ура. Ведь кончилось время директивного управления, и значит нужен механизм, позволяющий держать руку на пульсе бизнеса(Я даже думал дать проекту название Бизнес-Пульс). А что случилось, увидим далее.
Я влюбился в проект и был в спокойной уверенности в его успехе. Но, увы Надеюсь, что, хотя-бы для начинающих разработчиков, иcтория будет полезной.

История проекта


Скоро сказка сказывается, да не скоро дело делается
Все названия фирм и банков не настоящие.

Фирма М. Начало


В М я участвовал в проекте валютного операционного дня банка(ОДБ). И тут я столкнулся с началами аналитики. Пришли нормативные документы, в которых определялись разнообразные нормативы деятельности коммерческого банка и регламент их применения. Нормативы определяли рамки риска для деятельности банка. И тут у меня, вдохновленного переводными книгами по экономике(упаси боже, было читать советские книги по экономике), забрезжила идея Аналитики проекта, позволяющего пользователю определять и рассчитывать любые экономические показатели и контролировать их на соблюдение нормативных или других ограничений. Я поговорил с руководителями(а это были три дамы: президент, председатель, директор!!!), но не убедил их в нужности самостоятельного проекта. И я фактически оказался не у дел и мне стало и скучно и грустно. Но тут мне предложили подработать на стороне разработать проект мультивалютного операционного дня банка(ОДБ) для фирмы НП. Я стал работать и в конце концов перешел в НП на постоянную основу разрабатывать проект мультивалютного ОДБ. Но задумка аналитики осталась в душе.

Фирма НП. Скромное продолжение


Итак, в НП я разрабатываю мультивалютный ОДБ. Помня о нормативах, упомянутых в предыдущем пункте, я их реализовал и подцепил к справке, которая выдавала определение показателя, формулу его вычисления и текущее значение. Все это было реализовано в лоб без всякой унификации и глубокой системы. Вот в Москве проходит очередная выставка банковских продуктов. И мы выставляемся. Подходит к нам одна банкирша и начинает знакомиться с нашим продуктом. Скоро звучит вопрос: А как у вас дела с нормативами?. Я ей показываю таблицу текущих значений нормативов, она нажимает F1 и тут появляется определение норматива и формула его вычисления. Она была безмерно приятно удивлена, заявив, что ни у кого похожего не видела. И тут я укрепился в идее об аналитике. Если уж решение в лоб для нескольких показателей приятно удивило клиента, то что будет, если ему дать настоящую продвинутую бизнес-аналитику. В общем, я еще более воодушевился.

Банк БСБ. Личное систематическое начало


Как-то я демонстрировал в банке БСБ свой проект валютного операционного дня. Автоматизацией в БСБ ведал мой бывший шеф из банка ПСБ. Он посмотрел проект, попил со мною пару раз кофе и пригласил на работу к себе. А мы уже внедряли проект в одном из банков. А я, увы, внедрять был не очень охоч. И я согласился на переход. И вот я в БСБ. С работой справлялся быстро и было много свободного времени. Начал осваивать Delphi. Ознакомился с эксплуатируемыми задачами в банке. Оказался целый конгломерат разнотипных задач. Каждая автономна и со своим подходом. Я еще раз понял, что нужна единая банковская аналитика. Работаю над ней по собственной инициативе. Набросал концепции и начала техпроекта и обращаюсь с задумкой к шефу. Но как раз шеф набирает кадры из вычислительного центра ПСБ и они показывают некие зачатки банковской аналитики, которой они пользовались в ПСБ. Все реализовано на Oracle Discovery. А шеф сам выходец из ПСБ и айтишники из ПСБ и все они знакомы. И шеф решил пользоваться тем, что принесут ребята из ПСБ и не рисковать новыми подходами. Итак, меня прокатили. Но я продолжаю разрабатывать проект самостоятельно. Времени хватало. Я самообразовываюсь читаю толстые книги: Управление финансами в коммерческих банках(автор Синки), Банковский менеджмент(автор Роуз), Финансовое управление фирмой(автор Смит и др. ). И еще больше укрепляюсь в своей идее.
Когда я уже ушел из БСБ, то узнал, что БСБ склоняется к мысле приобрести SAP, что в итоге и сделали. Потом несколько лет внедряли, и я уже не знаю внедрили ли. Да, было модно обращаться к западным продуктам. Объяснение простое: ведь это означало систематические зарубежные командировки за счет банка.
Меня продолжает вередить зуд аналитики. И вот я решил продвинуть ее на частном примере кредитования. Кратко о сути задачи. Есть портфель кредитных заявок. В общем случае весь портфель удовлетворить нельзя: может не хватить обеспечивающих ресурсов. Плюс ко всему есть набор нормативов, которым должно удовлетворять состояние банка. Значит есть проблемы выбора. А где есть несколько вариантов выбора, там возникает задача оптимального выбора. Критерий оптимизации может быть разным, например:
  • Интегральная процентная прибыль за некоторый период
  • Чистая приведенная стоимость выбора за тот же период

Дело осложняется тем, что каждый клиент характеризуется некоторым риском. Значит критерий должен взвешиваться по вероятности возврата кредита. Мне удалось свести задачу к задаче линейного программирования. Риск по клиенту задавался моделью эмпирического риска, которую пришлось разработать самому. Сложность представляли нормативные ограничения, которые задавались нелинейными формулами. Оказались, что они только по форме нелинейные и тождественными простыми преобразованиями их можно свести к линейным. Риск можно было задавать и априорно.
Итак, постановка сделана. Нужно получить в банке одобрение проекта. Иду к руководству. Руководство не может само оценить предложенные идеи и меня посылают в какой-то полунаучный отдел(забыл точное название) и я попадаю на консультацию к кандидату экономических наук, бывшему нархозовцу(институт народного хозяйства). Не знаю почему, но тот сразу ополчился против и понеслись фразы типа i,j все писать умеют. В подтексте слышится: Пришли тут неостепененные и Суди дружок не выше сапога. И никак ему не втолковать, что проект не претендует на науку, а предлагает конкретную разработку и алгоритм под неё, так что можно приступать к программированию. Но это никак не втолковать. В итоге никаких рекомендаций я не получил. Ну и фиг с вами. Пусть все будет как есть. Это был второй раз, когда я встретился с отраслевой наукой и второй раз я попал к ней на рога.

Фирма МРЦ. Личное систематическое продолжение


Шеф уходит возглавлять МРЦ. Он забирает меня с собой. Фирма денежная и может финансировать несколько проектов. Я начинаю зондировать разработку проекта бизнес-аналитики. Продолжаю делать наброски технического проекта. Разрабатываю средствами CASE структуру БД. И тут мне опять представился случай проявить инициативу. Полным ходом идет разработка системы RTGS(Real Time Gross Settlement) реализации в реальном времени крупных платежей. Проект курируется Европой. Регулярно приезжают холеные европейские консультанты, которых мы угощаем растворимым кофе из нехоленых ржавых банок. Регулярно в Европу ездит наше руководство. Обслуживает руководство переводчики из моего управления. И у меня в управлении стоит целый книжный шкаф ценных переводов по банковской проблематике. Большинство из них я не могу уразуметь, то ли из-за сложности тематики, то ли из-за качества перевода. Ну хорошо, разрабатывается RTGS. А что делать с мелкими платежами? Предполагается, что они будут реализовываться в режиме клиринга. На клиринг нет ни постановки, ни вразумительной терминологии. И вот я берусь самостоятельно разрабатывать проект Клиринг. Разрабатываю словарь терминов и приступаю к техническому проекту. Словарь даю на обозрение широкой публике. Энтузиазм из меня так и прет.
Но тут наступают новые политические времена. Арестовывают Винникову, председателя Нацбанка РБ. А мой шеф возглавил МРЦ по представлению Винниковой. И вот началось выдавливание всех, кто прямо или косвенно был связан с Винниковой. Шеф увольняется. И меня начинают прессовать. Даже сослали в дальнюю от моего управления маленькую комнатку. Приходит новый начальник. Я ему несу на рассмотрение свой проект клиринга. Начальник держит проект у себя около месяца. Я ждал, ждал и обращаюсь к нему. А в ответ услышал: Разработка проекта не входит в Ваши прямые должностные обязанности. Вот вам и инициатива. Я прошу вернуть проект. Начальник мнется, мнется, но все-таки возвращает проект мне и проект до сих пор пылится у меня на балконе. Да, кстати, по теме клиринга я написал в отраслевой журнал статью. В ней предлагалась модель, определяющая временной лаг клиринга, оптимизирующий использование ресурсов клиринга. Статью приняли и напечатали без всяких препонов. Воодушевленный я развил идею дальше и понес в журнал вторую статью. И тут по поведению редактора я понял, что канал перекрыт. И мне стало ясно, что пора сваливать самому, не ожидая пока попросят. Обращаюсь к фирме СК и предлагаю проект аналитики. Тут же получаю приглашение на работу. Значит, я на правильном пути.

Фирма СК. Начало венчурного финансирования


Итак, я в СК и руководитель проекта Zero. Это проект банковской аналитики. Кроме руководителя пока нет никого. Пока один. Начинаю реализацию на Дельфи. Проходит месяца три и меня вызывает технический директор и просит ознакомить его с состоянием проекта. Знакомлю. Уже кое-что есть. А директор говорит: А почему бы не перейти на самоокупаемость продавать проект по частям, которые уже реализованы? Я опешил. Начинаю возражать, что мол МАЗ не продает колеса, а продает самосвалы. Попикировались и разошлись.
Начинаю чувствовать пристальное внимание со стороны главного инженера. Это был мой непосредственный начальник. Вся проектная идеология исходила от него. Человек талантливый и с жесткими взглядами на управление и с мягкими пряниками похвалы. Он все время зондирует мои дела и однажды объяснился. Он разработал интерпретатор подмножества Паскаля и все банковские отчеты главного продукта фирмы делались на скриптах этого интерпретатора. Скрипты назывались ОПР, не помню почему. Так вот, сказал он проект нужно делать на ОПР и вся аналитика должна сводиться к отчетам, написанными на ОПР. Это был еще не приказ(а он, конечно, имел право приказать). Мы начали дискутировать. Я как плюсы своего подхода приводил объектный подход и гораздо более систематический подход к показателям вплоть до их кодирования и подход к аналитике не как к отчетам, а как к моделированию экономических ситуаций и анализу последствий моделирования. В общем была приятная нормальная дискуссия. Такие дискуссии продолжались несколько раз. Это хорошо, это правильно. Но, однако, ни он ни я не меняем свою точку зрения. Тогда босс предлагает организовать публичный диспут, в котором каждая из сторон представит свой список аргументов. Отлично. Но в день дискуссии я узнаю, что босс вмещался в мой список и скорректировал его на свой вкус с позиции начальства и представил исправленный список публике. Это меня шокировало. Ведь ты как начальник мог приказать мне работать так как ты считаешь нужным и я, или должен принять это, или уволиться. Но если свободная дискуссия, то не затыкай мне рот. Мы на равных. В общем диспут я проиграл, хоть и не с разгромным счетом. Бодался теленок с дубом. Я получил хороший урок корпоративной этики и стал искать новую фирму. И нашел АТЛ.

Фирма АТЛ. Конец венчурного финансирования


И тут, наконец, я получаю карт-бланш для любых фаз разработки. И разрешение на набор команды. Но когда я еще один работал, босс уже пригласил потенциальных клиентов на просмотр продукта. И вот банкир из Казахстана изъявляет желание приобрести проект. Хорошо, что босс спросил у меня готов ли я. Я отказался от внедрения: cамому разрабатывать и самому внедрять не слишком ли. И я стал набирать команду. Больше 8 человек в бригаде никогда не было. Каждому человеку давался приличный самостоятельный кусок проекта. Я составлял на него ТЗ и вперед. Через месяц, два становилось очевидным годится ли человек.
Итак, проект стал развиваться быстрыми темпами. Некоторые функции подсказывали потенциальные клиенты. Например, я демонстрирую проект французам. Дошел до графиков динамических рядов. И тут один француз спрашивает: А вы не скажете, почему в прибыли тут такой скачок?. И тут же мелькает мысль: Как это я, дурак, сам не додумался задать себе такой вопрос?. В результате появилась операционная декомпозиция набор всех операций, изменяющих заданный показатель в заданное время. А с операции можно выйти и на ее исполнителя.
Хранение и обработка динамических рядов, сценарное моделирование, виртуальные показатели, статистическая проверка гипотез, регрессии, поиск наилучших регрессий, обработка портфеля финансовых инструментов, разного рода декомпозиции значений показателей, разного рода компараторы все реализовывалось на мой взгляд быстро. Проект становился все солиднее. Я попробовал ради интереса реализовать Web-интерфейсы для создания Web-служб. Это оказалось несложным, но далее web-тематику мы не развивали.
Начали выставляться на ИТ-выставках. Я демонстрировал не презентацию, а реальную работу продукта. Позже я от этого отказался, так как это слишком большой стресс. У меня даже руки стали дрожать, когда нужно было реально продемонстрировать требуемое свойство. Интерес к продукту был и немаленький. Из одного солидного банка пришло ИТ-руководство. На следующий день пришла целая бригада из ИТ-департамента. Потом пришла бригада банкиров. А мне все показывай им. Ну думаю, дело на мази. Увы. А в большинстве приходили ИТ-шники. И до того дотошно расспрашивали, что однажды я прямо спросил: Так вы намереваетесь брать или просто так интересуетесь? А в ответ: Да нет, брать мы не будем, мы просто тоже делаем что-то подобное и поэтому интересуемся как дела у других. Я взял и напросился посмотреть их проект. Не отказали. Проект был реализован на java. Он имел дело только с генерацией показателей. И эта генерация занимала на мой взгляд слишком много времени. И, поэтому, генерация шла в ночное время.
Однажды прекрасным весенним выходным днем меня вызывают на работу. Нужно показать проект важному банкиру из Питера. Проект банкиру очень понравился и он попросил приехать в Питер и показать проект широкой публике. Едем. Присутствует весь менеджмент банка. Нас представили и тут до представления начались бурные дискуссии между менеджерами. Одна партия за существующий там проект, а вторая за нас. Мы слушали, слушали и попросили прервать дебаты. Мол, мы покажем проект, а потом дебатируйте. Так и сделали. В итоге решили, что мы переведем всю БД нашего проекта на питерский Progress, сохранив то, что уже есть в нем и дополнительно в рамках нашего проекта реализуем несколько новых функций. Потом все это мы покажем и далее решится судьба проекта. Мы реализовали то, что требуется и собираемся в командировку в Питер. И вот пришло время ехать. И тут шеф дает отбой. Что и почему, я так и не узнал, так как не был посвящен в бизнес-интриги. И Питер обломился.
Были посетители и из Парижа. Глава делегации был какой-то потомок русских эмигрантов. Русский он знал неплохо. Судя по всему, проект ему понравился и он в знак уважения(?) подарил мне ноутбук от IBM., правда не совсем последней модели. Ноутбук и сейчас работает. Вскоре шеф приказывает мне готовить проект для Парижа. Вот это да! Перевели на французский всю документацию. Локализовали проект. Обмениваемся данными с банком в Париже. Готовимся к командировке. И тут шеф говорит, что наш покровитель переходит на повышение в другую фирму, не связанную с нашей тематикой И все затихло.
Мой бывший шеф по МРЦ возглавил в банке ПСБ департамент стратегических исследований. И он разрешил мне поставить проект на апробацию. И что я вам скажу? Никогда не пробуйте эксплуатировать у заказчика сырой проект. Только навредите репутации. Так и случилось. После пары сбоев прохлада со стороны банкиров. Да и вид у всех типа Кому нужно дополнительная работа без дополнительной оплаты. В конце концов мой знакомый при очередной встрече за рюмкой и обсуждению текущего политического момента произнес сакраментальную фразу При такой политике не нужно аналитики.

Векселя


И тут представилась возможность реализовать маленькое подмножество аналитики на примере обработки векселей. Работа с субъектами полностью была взята из аналитики. Ну, и несколько показателей пригодились также. Быстро реализуем проект Векселя. Проект внедрен. Идет сопровождение. И тут грянул гром. В контрольные органы поступила кляуза, что на проекте отмыты деньги, а проект не делает то что нужно(Похоже дело было в том, что у нас работал сын заказчика проекта Векселя). И вот мы разработчики должны продемонстрировать проект ревизору. Хорошо, что мы детально изложили ТЗ и четко реализовали все пункты ТЗ в проекте. Продемонстрировали ревизору работу проекта по всем пунктам ТЗ. Придраться было не к чему. А проект стоил мизерные деньги и как на нем можно было нажиться не представляю. По крайней мере мы на нем не нажились.
Проект был спасен и мы уже подумывали о его развитии. Но тут президент запретил вексельную форму расчетов. И хотя нас просили сохранить всю инфраструктуру проекта(работа с субъектами хозяйствования), но о деньгах речь не шла и нам не было резона трудиться.

Поиск криминала


А тут подвернулся еще один проект, который можно и нужно было связать с аналитикой. Объявился интересный потенциальный заказчик. Он описывает нам предмет автоматизации примерно так. Есть множество субъектов и множество отношений между ними. Нужно определить прямые и производные атрибуты, которые характеризуют степень финансовой криминальности субъекта и на основании атрибутов криминальности выявлять подозрительных субъектов и отслеживать их. Предполагаемый заказчик говорил только, что нужно вести досье и дело на каждого клиента, а также собирать сведения о всех отношениях субъекта. Основные поставщики данных: МВД, банки, налоговые органы, собес, таможня, интерпол
Начались дебаты разрабатывать ли самим или брать покупной продукт. Заказчик склонялся к покупному варианту. Оно и понятно: зарубежные командировки, красивая реклама продуктов(сами продукты не имели демоверсий и их нельзя было реально пощупать), а деньги бюджетные, чего их считать. Я начал разрабатывать ТЗ. Скоро понял, что вряд ли оно будет завершено. Дело в том, что мой новый шеф пытался добиться того чтобы все документы, структуры, файлы были определены на стадии ТЗ. Фактически он хотел втиснуть в ТЗ техпроект. Вдобавок, каждое решение должно было протоколироваться за подписью заказчика и разработчика. Поэтому по каждому пункту ТЗ собирались совещания с заказчиком. Я высказал свои сомнения в успехе подобного подхода и стал параллельно по собственной инициативе разрабатывать самостоятельный проект на Дельфи. Мне было просто интересно. Основная информационная структура ориентированный нагруженный граф отношений. Узлы графа субъекты, ребра графа отношения, нагруженные типом, размером, датой начала отношений, датой активации отношения В графе могут быть различные поиски: цепочки однородных отношений, цепочки неоднородных отношений, цепочки заданной длины, циклы, цепочки отношений, с размерами превышающими заданный лимит и т.д. и т.п. Разработал соответствующие классы и сравнительно быстро реализовал проект. Я продемонстрировал его руководителю предполагаемого проекта поиска криминала. На нескольких десятках тысяч субъектов, сотен тысяч отношений, десятка полтора типов отношений, любая цепочка находилась примерно за секунду. А буквально на следующий день руководитель сказал, что заказчик прекратил с нами отношения. Как и следовало ожидать, дальше ТЗ дело не пошло. А прошло около года. Мораль: не нужно слишком взнуздывать заказчика. А может шеф и не хотел этого проекта. Дело в том, что он был ответственен и за проект ERP для КГБ, а проект горел
А я, работая с отношениями, заинтересовался языком Prolog, точнее Visual Prolog. Начал пробовать. И удивительно, если в Дельфи реализация поиска цепочек требовала немалых усилий и размера программ, в Прологе это делалось компактной декларацией. Вот что значит заточенность языка на проблему и его декларативность. Описание предметной области декларативно и поэтому оно сравнительно легко ложилось в декларации Пролога.
Но не очень понравились возможности Visual Prolog по выводу форм. И у меня забрезжила мысль, что каждой специфичной проблеме нужен свой язык. Язык проектирования и генерации отчетов, язык проектирования ввода данных, язык проектирования вывода данных, язык коммуникаций, язык обработки отношений, язык обработки списков, язык описания данных, язык бизнес-аналитики, язык размещения сервисов и управления ими, язык бухучета, Короче, нужны не универсальные, а предметно-ориентированные языки. Дело только в стандартизации интерфейсов между получаемыми модулями. Зачем мне вся мощь C# с Visual Studio, если я, например, разрабатываю только формы, или только отчеты, или только обмен с БД,
Проект был включен в аналитику в подсистему Отношения.

Отступление о технических писателях


Когда я стал работать с вышеозначенным руководителем(он также бывший физик), тот стал жаловаться, что никто из его молодых подчиненных не в состоянии толком написать документацию. Я вполне с ним согласился и всю документацию по своим проектам писал сам. Вплоть до презентаций на Powerpoint.
Теперь мне кажется, что проблема технического писательства еще более обострилась. Люди стали мало читать, а пишут только интернет-комментарии, которые иногда стыдно читать.
Какой язык самый главный? твой родной. Его нужно знать в первую очередь.

Попытка интеграции


Проектом интересуются, но проект не покупается. Я заволновался и стал искать причины. А в то время главным банковским ИТ-продуктом на рынке был операционный день банка(ОДБ). И я решаю расширить рамки проекта и сделать интегрированный проект, включающий в себя: ОДБ, кадры, депозиты, кредиты, натуральный учет, операционный учет. Шефа долго не пришлось уговаривать. С ОДБ дела пошли удовлетворительно. А вот с кредитами и депозитами получился конфуз. Дело в том, что кадры на эти проекты мне не пришлось набирать самому, а пришлось ограничиться людьми из одного перспективного, но неудавшегося проекта. Ребята молодые, бойкие, склонные к системному программированию. Так и слышно: сокеты, TCP/IP, Internet, паттерны Проходит месяц а, а прогресса никакого. Но каждое утро ребята бурно обсуждают Формула-1. Так и слышится А Шумахер то, а Алонсо то. После обсуждения формулы-1 переключались на алгоритм деления трафика интернета между сотрудниками. Да, был такой социалистический реликт справедливого дележа трафика между сотрудниками. Дело кончилось тем, что я предложил депозитникам и кредитникам уволиться. Что и произошло.
А тут начались новые времена. Фирмой владел и руководил приятный бизнесмен. Очень религиозный человек. И в фирме была толстая прослойка из его единоверцев. И все шло более-менее спокойно. А тут вдруг, я не знаю почему, появляется новый руководитель свежеиспеченный пенсионер КГБ высокого чина. Скоро мы получаем заказ на проектирование ERP для КГБ. С течением времени проект стал заваливаться и требовалось срочно укреплять группу разработки ERP. А мой проект был венчурным и работали в нем неплохие ребята. И вот начали выдергивать из моего проекта людей. И возразить нельзя: ведь мы сидим на шее других проектов. Так я вскоре опять остался один. А в фирме все росла прослойка КГБ. Начался проект по разработке аппаратуры шифрации-дешифрации.

Финал


В конце-концов, я остался один на проекте Аналитика. Подбросили сторонний заказ для управления МВД доработать ASP-проект. Доработал. И тут оказывается, что фирма банкротится. Это, кажется, был хитрый бизнес-ход: параллельно с процессом банкротизации возникла новая фирма с людьми из нашей банкротящейся фирмы и которые были целиком завязаны на КГБ- разработку криптографической аппаратуры. А старая фирма обанкротилась. И моя аналитика стала домашним проектом. Но по инерции интерес к проекту еще некоторое время не угасал. Пришла пора .Net. Я понял, что уже сравнительно легко перейти к SOA-архитектуре. Перевел почти всю бизнес-логику с Delphi на C#. Познакомился с WCF. Выделил сервисы. Определил интерфейсы. Реализовал шлюзы сервис-клиент. И вот она SOA-архитектура. Была задумка реализовать простую оркестровку сервисов, но, кажется, в этом уже нет необходимости. Эта функция стала системной.
Однажды звонит телефон. Звонили айтишники, которые задумали разработать бизнес-аналитику. Они обратились к владельцу портала tut.by у которого я когда-то разработал проект валютного ОДБ. Мой бывший шеф(царство ему небесное) всегда подходил ко мне на выставках и я ему рассказывал о своих успехах. Он высказал несколько дельных маркетинг-замечаний, которые заставили меня призадуматься. Так вот он направил ребят ко мне. Они рассказали о своих планах. Я им сказал, что их задумки уже давно реализованы, но положены на полку. И я им продемонстрировал проект. Они поняли, что это весьма трудоемкое дело и предложили выступить в роли толкателей моего проекта в банки. А я уже вступил в стадию пессимизма перспектив толкания в банки. Но ребята упросили меня попробовать. Я им дерзайте. Снабдил их рекламными материалами, письмом в банки и они пошли толкать. Результат оказался предсказуемым.
Я до сих пор не могу определить причины неуспеха.
Я попробовал отдать проект в EPAM. Там резонно ответили, что разрабатывают только под заказ, а венчурными разработками не занимаются. Есть у нас в Минске Парк Высоких Технологий ПВТ, работающий под покровительством президента республики. И в нем есть отделение Бизнес-инкубатор. Я послал туда предложение передать бесплатно им свой проект. Никакого ответа не последовало. Я посмотрел в интернете что такое инкубатор и нашел вот что. инкубатор (от лат. incubare, здесь высиживаю птенцов) аппарат для искусственного вывода молодняка сельскохозяйственной птицы из яиц. Он дает жирных, но неприспособленных для неинкубаторской, реальной жизни особей. Похоже на правду.

Описание проекта


Не все золото, что блестит
А теперь более детально о многострадальном проекте. Это чтобы было оценить обоснованы ли были мои ожидания и стоит ли о них переживать. Это не реклама проекта. Проект мертв. Я готов бесплатно отдать его в хорошие руки. Если кого-то заинтересуют некоторые детали проекта, то смотрите. Старый первоначальный вариант описания(поэтому возможно более интересный) вот здесь.

Принципы


  • SOA
    Под сервисом понимается автономное приложение коллективного пользования, функции которого предоставляются через анонсированный разработчиком API. Сервис можно размещать на любом компьютере сети. В архитектуре клиент-сервер сервис был один СУБД. В SOA сервисов может быть сколько угодно и размещаться они могут на разных компьютерах сети.
  • WCF связь клиент-сервис и сервис-сервис.
  • СУБД
    В БД никаких хранимых бизнес-процедур. СУБД достаточно загружена стандартными запросами сохранения, обновления и извлечения данных. Отсутствие хранимых бизнес-процедур сильно облегчает смену СУБД. Особенно если еще стараться ограничиваться стандартом SQL.
    А если обнаружится, что сервер БД слабо загружен, то на нем можно разместить сервис работы с показателями, например.
  • Отчеты
    В отчетах не должно быть никаких бизнес-функций. Отчет просто отображение группы показателей в заданную форму. А сами показатели должны рассчитываться в бизнес-слое сервисом машины показателей.
  • Интерфейсы
    Любое обращение к сервису должно быть только через интерфейсы.
  • Группы
    Однотипные объекты(показатели, субъекты, операции) могут объединяться по любому допустимому логическому критерию. Групп может быть сколько угодно.
  • Эксплореры
    Иерархические структуры должны отображаться в едином эксплорере


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


  • Ведение субъектов и их отношений. Поиск по отношениям. Ведение групп субъектов.
  • Ведение показателей и их динамических рядов. Ведение групп показателей. Значения показателей могут быть числовыми, текстовыми, логическими, календарными. Правило вычисления показателя любая композиция стандартных математических функций и агрегатных функций. Примеры агрегатных функций: максимум по субъектам, среднее по времени, минимум по времени. Значения показателя представляются в нескольких измерениях реальности: факт, план, прогноз индивидуальный, прогноз статистический, прогноз сценарный. Удивительно, но нигде в литературе я не нашел систематизированного перечня бизнес-показателей с их определениями, кодами, наименованиями и правилами вычисления.
  • Статистический анализ динамических рядов. Проверка статистических гипотез. Нахождение статистических параметров.
  • Регрессионный анализ. Нахождение наилучших регрессий.
  • Ведение портфеля. Получение платежного календаря.
  • Прогнозирование. Прогнозирование линейными трендами. Прогнозирование по портфелю фининструментов. Прогнозирование с учетом статистического отклонения прогноза от реальности.
  • Сценарное моделирование. Различные типы сценариев: операционный, портфельный, индикаторный.
  • Анализ. Различного рода анализаторы(декомпозиторы): разложение по показателям, по субъектам, по валюте, по исполнителям, по операциям.
  • Сравнения. Различного рода компараторы: сравнение по времени, по субъектам, по показателям.
  • Отображение в реальном времени. На каждого пользователя заводится табло своего типа, в котором отображается группа показателей.
  • Ведение плана счетов, иерархии объектов учета, иерархии бизнес-операций и их отображения на проводки.
  • Элементы бюджетирования: игра с распределением ресурсов.


Основные технологии


  • ETL. Это неунифицированный модуль перекачки данных от подсистем источников первичной информации. Основной источник бухгалтерский учет.
  • Эксплорер как универсальное отображение иерархических структур. Унифицированно отображаются иерархии показателей, субъектов, отчетов, запросов, объектов учета, операции.
  • Группы как наборы объектов, объединенные некоей общей внешней семантикой. Например, отчет группа показателей, отображаемая по заданной форме.
  • События. Монитор событий отслеживает рождение событий. Событие специфицируется логической функцией. Типы событий: внутреннее бизнес-событие, внешнее бизнес-событие, календарное событие. Монитор общий для всех сервисов. В каждом адресном пространстве работает свой оповещатель событий. Он извещается монитором событий. На события приложение подписывается.
  • Динамические формы. Пользователь может конструировать экранные формы таких типов: списочные, матричные(=табличные), иерархические.
  • Элементы объектооборота.
  • Сервисы.


Функциональные сервисы


  • Бизнес-ядро. По запросу клиента предоставляет ему для использования бизнес-объект и забирает объект от клиента. Кэширует объекты. Управляет связью между бизнес-уровнем и уровнем хранения данных.
  • Текущее состояние субъекта. Это набор показателей субъекта на текущую дату.
  • Симуляционное состояние. Это набор прогнозных показателей субъекта на заданную дату при заданном активном сценарии развития.
  • Статистика. Позволяет находить статистические зависимости.
  • Анализ показателей. Статистический и графический анализ реальных и виртуальных показателей.
  • Субъекты. Ведение субъектов и навигация по их множеству.
  • Отношения. Позволяет анализировать сколь угодно сложные цепочки отношений.
  • Бухгалтерские проводки. Подсказывает бухгалтерские проводки для заданной хозоперации.
  • Бизнес-табло реального времени. В заданном темпе отражаются текущие значения показателей. Отображение табличное и графическое.
  • Портфель финансовых инструментов. Ведение фининструментов, навигация по их множеству, отработка сценария пассивной эволюции, определение платежного календаря.
  • Бюджетирование, точечное или распределенное во времени.


Технологические сервисы


  • Идентификация и аутентификация. Для новых бизнес-объектов генерятся идентификаторы. При вхождении пользователя в приложение проверяется его пароль в приложении.
  • Доступ. Реализовано два типа доступа: по разрешению, и по запрещению. Уровни доступа: тип, метод типа, экземпляр.
  • Машина показателей. Вычисляет значения производных показателей и сохраняет эти значения в БД. Показатели загружаются из БД.
  • Монитор событий. Отслеживается сформированный пользователем набор событий. О наступившем событии сообщается оповещателю, находящемуся в адресном пространстве приложения
  • Оповещатель. Приложение оповещается о наступившем событии. Оповещатель генерирует идентичное событие. На событие клиент подписывается сам или его подписывает технолог.
  • Объектооборот. Бизнес-объекты прогоняются по технологическому конвейеру.
  • OLAP. Особенность: базисом для OLAP-кубов служит не столько сырые данные OLTP-систем, сколько слой рассчитанных показателей над OLTP-системами. Это делает OLAP-разработки простыми и более производительными, чем непосредственно на оперативных данных. Размерность пространства измерений можно увеличить, подцепляя к показателю, соответствующий субъект и делая его характеристики размерностями куба.


Объекты


Все объекты делятся на:
  • D-объекты. Это голые данные без бизнес-функций.
  • B-объекты. Это бизнес-объекты, содержащие D-объекты и бизнес-функции.
  • P-объекты. Это объекты представления, содержащие D-объекты с атрибутами их отображения.
  • C-объекты. Это коммуникационные объекты, служащие для передачи D-объектов между разными адресными пространствами.
  • DB-объекты. Это объекты для отображения D-объектов на базу данных и получения D-объектов из базы данных.


Взаимодействие объектов:

image


D-объект объект данных


Предназначен для хранения данных. D-объект это B-объект без бизнес-функций. Объект данных содержит только данные и не содержит бизнес функции. Имя: <имя>D. Пример: HomoD.
Все объекты данных образуют D-дерево. Корень TopD
D-объекты содержат не бизнес-методы:
  • CopyTo
  • CopyFrom
  • Clone
  • GenId
  • GenParentId
  • ToString


Об идентификации
TypeId идентификатор типа. В таблице Tip каждому типу соответствует запись с Id=TypeId. В пределах типа может быть сколько угодно экземпляров. Их различают атрибутом Code.
Code идентификатор экземпляра в пределах типа. Значит, пара TypeId и Code дают идентификатор экземпляра. Однако разные поставщики данных могут поставлять однотипные экземпляры. Например, платежных поручений может быть сколь угодно. Чтобы провести идентификацию на этот уровень задействуем ещё экземплярный уточнитель IQ, который уникален в пределах всех экземпляров на все время жизни решения. Тогда тройка TypeId, Code, IQ и есть идентификатор в поле Tip. Можно было обойтись одним IQ, но это неудобно для ручной работы с БД.

B-объект бизнес-объект


Это все сущности, являющиеся элементами прикладной области, которая представляется как взаимодействие бизнес-объектов. Предназначен для хранения бизнес функций. Пример бизнес-объектов: человек, счет, платеж. Пример не бизнес-объектов: все виджеты(=контролы).
Бизнес-объект содержит объект-данные и бизнес функции. Имя: <имя>. Пример: Homo
Каноническое соответствие: <имя>D <--> <имя>. Каждый B-объект имеет методы:
  • Сохранить
  • Извлечь
  • Удалить


Все бизнес-объекты образуют иерархию. Корень TopB

C-объект коммуникационный объект


Предназначен для передачи данных. Он содержит данные в в форматек, пригодном для передачи данных между разными адресными пространствами. Имя: <имя>С. Пример: HomoC
Каноническое соответствие: <имя>С <--> <имя>D.
Все коммуникационные объекты образуют иерархию. Корень TopC
Методы C-объекта:
  • CopyToD. Копировать себя в D-объект
  • CopyFromD. Копировать на себя из D-объекта


P-объект представляемый объект


Предназначен для отображения данных на визуальные формы. Содержит объект данных и параметры визуального отображения.
Имя: <тип объекта>P. Пример: HomoP
Все объекты представления образуют иерархию. Корень TopP. Каноническое соответствие: <имя>D <--> <имя>P. Многие P-объекты совпадают с D-объектами, так как не нуждаются в параметрах визуализации.

F-объект форма


Служат для визуального представления объектов данных.
Имя: <тип объекта>F. Пример: HomoF
Все формы образуют иерархию. Корень TopF. Каноническое соответствие: <имя>F <--> <имя>P.
Все функциональные формы наследуются от TopF. Основные свойства и методы:
Каждая форма имеет методы:
  • Получить объект
  • Отобразить объект на поля формы
  • Сформировать объект из данных формы
  • Сохранить объект
  • Удалить объект

С каждой формой соотносится свой контекст выполнения UserContext, прописанный в TopF.
Все grid-таблицы на формах могут выдаваться в Exсel. Этот метод реализован в TopF. В графе Exсel можно вводить любой код показателя или допустимое правило вычисления.
Тракт обработки: вводимые атрибуты на форме --> экземпляр D-объекта --> экземпляр B-объекта --> бизнес-функция --> экземпляр D-объекта --> экземпляр DB-объекта --> кортежи таблиц в БД.
Тракт отображения: кортежи таблиц в БД --> экземпляр DB-объекта --> экземпляр D-объекта --> экземпляр P-объекта --> отображаемые атрибуты объекта на форме.
Единообразность поведения форм обеспечивается общим корнем форм. Альтернативный метод использование интерфейсов. Достаточно реализовать в компоненте интерфейс, а вызывающей программе проверить его наличие. Такая реализация предотвращает перегруженность корневой формы.

DB-объект объект базы данных


Предназначен для общения с БД: сохранение объекта данных в БД и извлечение из БД объекта данных.
Имя: <имя>DB. Пример: HomoDB
Каноническое соответствие: <имя>.D<><имя>.DB.
Все DB-объекты образуют иерархию. Корень TopDB
Все бизнес-объекты регистрируются в таблице Tip с уникальным Id. Специфика объекта отображается в специфичных таблицах.

Архитектурная схема


image



Уровень данных


Он имеет дело только с D-объектами. Они образуют D-дерево. Вершина D-дерева объект TopD. Назначение объекта TopD обеспечить одинаковое поведение всех D-объектов.

Уровень хранимых данных


Он имеет дело только с D-объектами и DB-объектами. DB-объекты образуют DB-дерево.
Функции:
  • Извлечение из внешней памяти объектов данных
  • Сохранение во внешней памяти объектов данных
  • Кэширование объектов данных

Посредством DB-объекта D-Объект может отображаться в несколько кортежей и в несколько таблиц БД.
В БД нет никакой бизнес-логики. СУБД хватает забот по SQL-запросам. При желании можно разместить бизнес-сервис на сервере СУБД. При желании можно разместить все на одном компьютере.
Для доступа к БД используется ADO.Net. Уровень имеет дело с двумя потоками данных:
От БД к уровню логики. Уровень данных извлекает из БД нужные данные и формирует из них бизнес-данные, которые на уровне бизнес-логики войдут в бизнес-объект.
От бизнес-уровня к БД. Уровень данных получает бизнес-данные от уровня бизнес-логики и кладет их в БД.
Есть возможность кэширования данных. Кэширование сохранение объекта в оперативной памяти, если объект часто используется. Так в банковских расчетах постоянно нужен корреспондентский счет. Скэшировав его, не нужно будет часто обращаться к БД он будет браться из кэша.
DB-объект имеет функции:
  • Взять данные из бизнес-объекта
  • Передать данные в бизнес-объект
  • Сохранить данные в БД
  • Извлечь данные из БД
  • Обновить данные в БД
  • Удалить данные из БД

Правильно отрабатывать многообъектную транзакцию(не делать самому Commit и RollBack)
Один из параметров вызова DB-объекта DB-connection

Каждому типу объектов сопоставлена таблица в БД с именем типа объекта. Все объекты имеют уникальный Id и представлены в таблице Tip. В этой таблице есть атрибуты, являющиеся общими для всех объектов:
  • Id
  • PId
  • TypeId
  • Code
  • Name
  • CreatedOn
  • Description
  • StateCode
  • Author

Все объекты в этой таблице образуют иерархию, которая есть иерархия типов. Это значит, что каждый тип представлен записью, а все экземпляры типа подчинены этой записи(PId экземапляра = Id типа).
Для типа его Id это TypeId; Code есть идентификатор в пределах типа.

Детали объектов представлены в таблицах, соответствующих типу. Например, атрибуты объекта Homo представлены в таблице Homo.
Все атрибуты типа содержатся в сцепке таблицы Tip и таблицы, соответствующей типу. Соответствующее представление именуется как <тип>_v. Например, Homo_V.

Вершина DB-дерева объект TopDB. Назначение объекта TopDB обеспечить одинаковое поведение всех DB-объектов.

Бизнес-уровень


Он имеет дело только с B-объектами. B-объекты образуют B-дерево.
Функции:
  • Реализация бизнес-функций
  • Предоставление бизнес-интерфейсов
  • Предоставление бизнес-служб(приложение коллективного пользования):
  • WCF-службы
  • Web-службы

Вершина B-дерева TopB. Назначение объекта TopB обеспечить одинаковое поведение всех B-объектов.

Уровень представления


Он имеет дело только с P-объектами и F-объектами.
Функции:
  • Запрос данных к бизнес-уровню и получение от него объектов данных
  • Отображение данных в формы и отчеты
  • Формирование объектов данных и передача их на бизнес-уровень

В форме визуально отображается во время выполнения экземпляр объекта. Вызов и завершение каждой функции пользовательского объекта вызывает отметку этого события в регистрационном журнале .Log. Вся бизнес-логика должна находиться в методах бизнес-объектов. В форме эти методы должны вызываться, но сама форма не должна вычислять, например, проценты по кредиту, срок погашения и т.д. На форме не должно быть никакой бизнес-логики, а только логика интерфейса пользователя. К логике интерфейса пользователя относятся:
  • Управление видимостью интерфейсных элементов
  • Управление группами связанных кнопок
  • Тип шрифта
  • Цвет и т.д.


F-объекты образуют F-дерево. Вершина TopF.
Назначение объекта TopF обеспечить одинаковое поведение всех F-объектов.

Обязательные принципы


Минимизация энтропии


Всякий разработанный проект подчиняется некоей термодинамике: любой проект обладает энтропией. Возрастание энтропии есть стремление к разрушению стройности структуры(=порядок), стремление к беспорядку. Стремление к минимальной энтропия требует единообразия. Пусть даже безобразно, но единообразно. Всякое разнообразие должно быть осознанным и преследовать явную функциональную цель, а не эстетики, оригинальности и т.д. Никакого необоснованного разнообразия это лишняя энтропия. Борьба с энтропией самое главное. У некоторых программеров уже один модуль содержит тьму энтропии. Примеры необоснованного разнообразия:
  • Разные имена одной сущности в разных модулях
  • Разная дисциплина компоновки кода
  • Разные рисунки для кнопок одинакового назначения
  • Разные подсказки для кнопок одинакового назначения
  • Разный стиль программирования. Так иногда цикл по списку начинают с 0 до Сount-1, а в другом месте с 1 до Count.
  • Разный стиль именования
  • Разный стиль комментариев иногда до кода {а сейчас будет представлен }, а иногда после кода {это был описан }


Приоритет глобальных целей над локальными


Под локальным уровнем понимается уровень модуля, а не приложения или уровень приложения, а не группы однородных приложений. Так стремление к локальной оптимизации может привести к глобальной неоптимальности, стремление к локальной изящности к глобальной неуклюжести. Пример 1: стремление уйти от глобальных переменных может утяжелить систему, требуя создать заново объект, который мог быть передан через глобальную переменную. Пример 2: при создании новой формы, может показаться, что ее не нужно наследовать от базовой формы. Поначалу все Ok и экономятся ресурсы. Но потом от формы может потребоваться выполнение общей функции форм, которая уже реализована на уровне общей формы, но ее нет в частной форме. Значит, форму нужно будет доделывать, дублируя то, что уже сделано в общей форме.
Адекватность(неизбыточность, но полнота) отображения(Принцип минимальной избыточности). Любое отображение должно быть настроено на контекст учитывать все уже заданные параметры. Так если клиент является физлицом, то в эксплорере нужно отображать только счета физлиц; Если речь идет о кредитах, то в эксплорере счетов должны отображаться только ссудные счета. Это относится не только к ouput- элементам интeрфейса, но и к input-элементам: комбобоксам, листбоксам поставщикам данных.

Ковариантность при смене базового субъекта.


Сейчас многие Query содержат начальные значения параметров привязанные к текущему базовому субъекту. Это удобно для просмотра в DesignTime, но это может привести к непереносимости проекта. Чтобы этого не случилось, нужно в RunTime всегда устанавливать значение параметра запроса.

Никакого видимого мусора


Мусор то, что не используется. Неиспользуемые элементы интерфейса должны быть невидимыми.

Слоение


Функций отображения не должно быть в бизнес-объекте.
Реализация бизнес- класса не должна использовать объекты и методы уровня представления.
Функций связи с БД не должно быть в бизнес-объекте
Реализация бизнес-класса не должна использовать объекты и методы уровня хранения.

Слабая внешняя связность


Условие слабой связности класса(внешняя связность) мера использования в классе других классов этой же предметной области. Желательно иметь слабо связанные классы. Это свойство называется изолированностью.Объект не должен в своих методах использовать как параметр объект класса, расположенного в дереве ниже по уровню или использующего объект как элемент агрегации. Пусть B наследник A и в A есть метод A.Do(prA:B). Тогда его нужно убрать из A в B: B.Do(prA:A).

Сильная внутренняя связность


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

Связь с БД


За связь с БД отвечают специальные объекты брокер БД.

Связь Форма-объект


image


Каждой форме сопоставляется рабочий объект. Создает рабочий объект только терминальная форма. Объект может передаваться форме извне. Форма может передавать его другой форме. Каждая форма имеет методы ShowOnObject, GetObjectFromForm. Это виртуальные методы.

Локальность


Если форма вызывается из модуля, то она, как объект, должна быть локальной. Это предотвратит возможную коллизию параллельного использования одной формы.

Исключения


Все прерывания фиксируются в регистрационном журнале и передаются клиенту.

Кодификация


Все кодификации, которые потенциально изменяемы реализуются как кодификаторы структуры {код, имя}. Постоянные кодификации(дни недели, например) реализуются как перечислимые типы.

Реализация

Отображение дерева объектов в информационную базу
В таблице Tip прописываются все объекты одинаковым образом независимо от типа. В таблице Movement отображается движение объекта (смена состояний и выполнение методов) одинаковым для всех объектов образом.
Объекту TopB сопоставляется таблица Tip(Top обычно зарезервированное слово в СУБД, поэтому имя Top таблицы оказалась неудобным), а каждому конкретному бизнес-классу сопоставляется конкретная таблица в БД: объект Homo<>таблица Homo и т.д.
Отношения между субъектами фиксируются в таблице Relation.
При создании объектов, входящих в иерархию наследования должно соблюдаться вот что: не может быть терминальной записи без головной. Это нужно иметь в виду при ручном формировании базы импорте таблицы Банки, например. Чтобы добавить сущность Банк, нужно чтобы была сущность Предприятие. Чтобы добавить сущность Предприятие, нужно чтобы была сущность Субъект. Чтобы добавить сущность Субъект, нужно чтобы была сущность TopD.
На общем(независящем от типа) уровне реализованы эксплорер объектов, операция, продвижка объектов. Эксплорер объектов работает одинаково для всех типов объектов. На конкретном уровне работают формы специфичные для каждого объекта.

Эксплорер объектов


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

Двигатели состояний


Это формы, позволяющие продвинуть состояние

Операции


Работа с операцией унифицирована формой fOperation.
Из этой формы можно выйти на спецификацию объектов операции и на платеж операции. Пример выхода на платеж по кнопке Специфицировать платеж операции:

Эксплорер операций


Аналогичен эксплореру объектов.
Конкретную операцию можно выдернуть из эксплорера и посмотреть по кнопке Индивидуализировать.

Доступ


Управление доступом к бизнес-объектам делается на бизнес-уровне. Доступ может быть по разрешению или по запрещению. Доступ может быть:
  • К типам бизнес-объектов (Запрещен или разрешен доступ ко всем экземплярам указываемого типа и всем методам объекта этого типа)
  • К методам типа (Запрещен или разрешен доступ к указанным методам всех экземпляров данного типа)
  • К экземплярам (Запрещен или разрешен доступ к специфицируемым экземплярам указываемого типа и всем методам объекта этого типа)
  • К методам экземпляров (Запрещен или разрешен доступ к специфицируемым экземплярам указываемого типа и специфицируемым методам объекта этого типа)
  • К формам


Структура решения


Решение есть совокупность проектов(терминология Visual Studio). В решении около 200 проектов. Все проекты кучкуются так:
  • Data-проекты. Каждому D-типу соответствует D-модуль.
  • Business-проекты. Каждому B-типу соответствует B-модуль.
  • Communication-проекты. Каждому C-типу соответствует C-модуль.
  • Presentation-проекты. Каждому P-типу соответствует Р-модуль.
  • Interface-проекты. Модули содержат описания интерфейсов.
  • Technology-проекты. Содержат утилиты.
  • Infra-проекты. Содержат инфраструктуру решения.
  • Resource-проекты. Содержат ресурсы проектов.
  • Service-проекты. Реализуются сервисы.
  • Gate-проекты. Выполняют роль шлюза между сервисом и приложениями. В одноадресном варианте шлюз не нужен.
  • Application-проекты. Содержат конкретные приложения.
  • Test-проекты.
  • Delivery-проекты.
  • Site-проекты.
  • Addin-проекты.

Отображение структуры решения в каталог ОС: каталог ОС решения повторяет структуру решения.

Структура приложения



image


Старт-программа


Головная программа аутентифицирует пользователя. В головном модуле создаются все интерфейсы. Т.е. головная программа склеивает реализацию и объявление интерфейсов. Создаётся диспетчер приложения. Интерфейсы передаются диспетчеру приложения. Диспетчер создаёт формы и передаёт им соответствующие интерфейсы.

Реализация распределенной обработки


WCF-сервис


Некоторые наборы функций можно реализовать как сервисы приложения коллективного пользования с четким API. В итоге получается приложение, работающее в нескольких адресных пространства. Эти пространства могут размещаться на любых компьютерах сети. Связь между пространствами реализуют модули-шлюзы. Они размещаются в клиентском приложении.
Задачи шлюза:
  • Обработка трафика от сервиса к клиенту:
  • Принять С-объект по API с сервисом
  • Преобразовать С-объект в D-объект
  • Передать D-объект клиенту
  • Обработка трафика от клиента к сервису:
  • Принять D-объект от клиента
  • Преобразовать D-объект в C-объект
  • Передать C-объект сервису по API c сервисом

Задача сервиса:
  • Обработка трафика от клиента
  • Принять C-объект
  • Преобразовать его в D-объект
  • Передать D-объект функциональной части по локальному API
  • Обработка трафика к клиенту
  • Принять D-объект от функциональной части по локальному API
  • Преобразовать его в С-объект
  • Передать клиенту C-объект


Web-службы


Все как и для WCF с заменой WCF-сервиса на WEB-сервис. Последний есть клиент над WCF-сервисом, с тем, чтобы остальные WCF-клиенты не замечали WEB-сервис.

Специфика


Объекты учета


Счета бухгалтерского учета основной источник аналитики. Основной объект аналитики показатель. В его описание входит код объекта учета, которому соответствует показатель. Поэтому чрезвычайно важно хорошо построить множество кодов объектов учета.
Объекты учета образуют дерево объектов учета. Его ведение доступно пользователю.

Дерево типов


Все типы решения образуют дерево. Это дерево отображается в таблицу Tip. Id записи TypeId типа. Все объекты представлены в Tip записями, подчинёнными записи типа объекта. Например, записи объекта Homo подчинены записи типа Homo записи с Id=Homo.TypeId. Такое решение позволяет создать универсальный эксплорер объектов, отображающий иерархию типов.

Движение


Движение экземпляра объекта есть смена состояний. Движения всех объектов определяются одинаково объектом Movement и хранятся в таблице Movement.

Отношения


Явные отношения те, которые поддерживаются информационной моделью. Например, отношение подчинения между субъектами.
Все неявные отношения между объектами фиксируются в таблице Relation при установлении отношения. При заключении кредитного договора должно фиксироваться отношение кредитования. При появлении изменений к плану счетов между документом План счетов и изменениями к нему устанавливается отношение Изменение. Оно явно не присутствует в модели. Выделение каждого отношения в явное отношение перегрузит модель.
Отношение можно специфицировать, вызвав форму Отношение.

Транзакции и целостность


Все экземпляры любых объектов(в том числе и субъектов) имеют уникальный идентификатор. Сфера действия уникальности БД на все времена работы проекта.
Все экземпляры сценариев имеют уникальный идентификатор идентификатор сценария. Сценарий последовательность воображаемых операций. Все экземпляры любых операции имеют уникальный идентификатор идентификатор транзакции. Сфера действия уникальности все таблицы на все времена работы решения. Операция может породить другие операции, которые без первичной, начальной операции не имеют смысла. Если отменяется начальная операция, то отменяются все порожденные операции. Такая цепочка операций рассматривается как одна транзакция и все операции цепочки получают одинаковый идентификатор транзакции. Пример цепочки: Открытие счета Заключение договора на открытие счета Оплата открытия счета. Этой цепочкой связываются три объекта: счет, договор, платеж. Отмена открытия счета отменяет и договор и платеж.
Каждая операция оформляется как часть транзакции. Каждая операция начинается и заканчивается регистрацией в журнале регистрации.
Объект может иметь связанные, присоединенные к нему объекты в списке CoObjects. Эта связка хранится в БД.

Базовый субъект


Это субъект, который является владельцем эксплуатируемой системы.
Если в двустороннем отношении или функции неясно с кого начинать, то начинать нужно с базового субъекта. Примеры:
  • Операция Купить. Покупает базовый субъект, а продает его контрагент.
  • Операция Продать. Продает базовый субъект, а покупает его контрагент.
  • Отношение Договор. Первая сторона, субъект это базовый субъект. Вторая сторона договора, контрагент это контрагент базового субъекта.


Доступ и регистрация


Любая функция начинает с отметки в журнале регистраций и завершает отметкой в журнале регистраций.
Доступ дифференцируется так:
  • Доступ к типам
  • Доступ к методам типа
  • Доступ к экземплярам типа

Условие доступа может интерпретироваться двояко:
  • На разрешение (что не разрешено, то запрещено). Пример: Id=1 доступ только к объекту с Id=1
  • На запрещение(что не запрещено, то разрешено). Пример: Id=1 доступ только к объекту с sysId<>1


Хотелось бы


  • Применить машинное обучение. Например, определение кредитоспособности клиента, определение степени надежности бизнеса. Но где взять достаточно большой массив реальных примеров для обучения?
  • Заложить в базу знаний, помимо правил вычисления показателей, какие-нибудь экономические теории микроэкономики. Это, конечно, динамические теории. Т.е. это что-то типа:


Так в чем же причина облома?


Попытаюсь классифицировать возможные причины неудачи:
  • Это идея-фикс? Это не мне судить.
  • Невостребованность?
  • В невостребованность не верю. Востребованность почти очевидна. Не будем же мы дискутировать о невостребованности давления, пульса, РОЕ в медицине. Например, в последнее время на слуху ССП- сбалансированная система показателей. А это подмножество аналитики.
  • Отсталость по сравнению с аналогичными проектами?
  • Плохая архитектура?
  • Инструментарий?
  • Сверхученость?
  • Маркетинг?
  • За спиной не стояла крупная фирма, имеющая историческую репутацию?


Я склоняюсь к совокупности последних трех причин.
И последнее, чтобы не посчитать статью за рекламу проекта, я готов бесплатно отдать весь проект в хорошие руки. Это около 20 Мб исходников. Конечно, там будет над чем и посмеяться: это был мой первый проект на C#. Многими из современных свойств C# там и не пахнет. В первую очередь, я бы изменил событийный подход первых выпусков C# на современный, более высокоуровневый подход к событиям. Во-вторых, можно было подумать о возможности асинхронной обработки.
Заканчивая и, думая нажать ли кнопку Опубликовать, начинаю терзаться смутными сомнениями А кому это нужно? И что тебе надобно, старичина? А потом решил не отвечать на этот вопрос

Всем желаю никогда не встречаться с обломом любимых проектов. Успехов!
Подробнее..
Категории: Анализ и проектирование систем , Развитие стартапа , Моделирование , Архитектура , Показатель , Бизнес-аналитика , Прогнозирование , Сценарий

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru