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

“Его пример другим наука”

Предисловие

Это грустная история о неуспехе проекта, который я считал потенциально успешным на все 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-объектов из базы данных.

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

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. Специфика объекта отображается в специфичных таблицах.

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

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

Он имеет дело только с 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: при создании новой формы, может показаться, что ее не нужно наследовать от базовой формы. Поначалу все O’k и экономятся ресурсы. Но потом от формы может потребоваться выполнение общей функции форм, которая уже реализована на уровне общей формы, но ее нет в частной форме. Значит, форму нужно будет доделывать, дублируя то, что уже сделано в общей форме.
Адекватность (неизбыточность, но полнота) отображения(Принцип минимальной избыточности).

Любое отображение должно быть настроено на контекст – учитывать все уже заданные параметры. Так если клиент является физлицом, то в эксплорере нужно отображать только счета физлиц; Если речь идет о кредитах, то в эксплорере счетов должны отображаться только ссудные счета. Это относится не только к ouput- элементам интeрфейса, но и к input-элементам: комбобоксам, листбоксам – поставщикам данных.

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

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

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

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

Слоение

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

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

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

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

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

Один класс – один модуль.

Общее правило: один класс – один модуль. Во всяком случае, в одном модуле могут быть только сильно связанные объекты

Связь с БД

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

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

Каждой форме сопоставляется рабочий объект. Создает рабочий объект только терминальная форма. Объект может передаваться форме извне. Форма может передавать его другой форме. Каждая форма имеет методы 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-проекты.

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

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

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

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

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

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# на современный, более высокоуровневый подход к событиям. Во-вторых, можно было подумать о возможности асинхронной обработки.

Заканчивая и, думая нажать ли кнопку «Опубликовать», начинаю терзаться смутными сомнениями “А кому это нужно? И что тебе надобно, старичина?” А потом решил не отвечать на этот вопрос…

Всем желаю никогда не встречаться с обломом любимых проектов. Успехов!

Автор: MirAleAnu

Источник