Здравствуйте, Mishka, Вы писали:

M>Это всё из области логической архитектуры приложений.
"Логическая архитектура приложения" — нигде не нашел такого термина или определения. Дайте пожалуйста ваше понятие для разъяснения.

M>Проблемы, которые ты перечислил, успешно решаются. Например при помощи SOA и BPM.
Спасибо, почитал.. Буду еще анализировать. Но на первый взгляд мне кажется, что это больше близко к уровню реализации, а не моделирования, проектирования, представления предметной области. Например, если представить уровни так: анализ предметной области — проектирование | моделирование — логическая | физическая реализация. Сразу говорю, что эти уровни в общем смысле несколько размыты.

M>Я имею в виду логическую архитектуру, а не физическую. Последняя всегда скатывается к вопросам web services, security и прочей технической лабуды, не имеющую никакого отношения к бизнесу. Сначала надо понять бизнес. Понять бизнес-сервисы (наприме, "Зарплата", "Бухгалтерия"), бизнес-процессы ("Начисления зарплаты", фантазия закончилась ), бизнесс-операции ("Расчёт зарплаты", "Выплат денег из кассы", "запуск ядерного реактора"). Если начать с бизнес-объектов, то там же вы и закончите (это принцип объектно-ориентированного анализа и архитектуры). Вот пример, в систему вводиться "Человек" как бизнес-объект (и это в реальном проекте, который кстати провалился). Зачем? Из ОО понятно, что это есть некое обобществление. С точки зрения бизнеса — это полный бред. Почему? Бизнес не имеет дела с человеком, он имеет дело с работниками, кандидатами на работу, провинившимися, покупателями, частными предпринимателями. Всё это бизнес-объекты. Увольняем Буча. Он не писал свою книгу во времена интеграции приложений и бизнес процессов. Он писал приложения, которые всегда были одни во вселенной и не должны были взаимодействовать с другими системами. Кроме того ОО требует чтобы все бизнес объекты были известны наперёд. Это возможно, но нельзя знать все бизнес процессы наперёд. Помещаем части бизнес-процесса в объекты и всё, систему можно выкидывать на свалку, поскольку процессы меняются часто и почти всегда различны в разных фирмах. Зарплату и ту везде по разному начисляют. 1С потому и хорош, что позволяет быстро адаптироваться под требования заказчиков, но это не есть правильное решение с точки зрения логической архитектуры.

M>Субъективности при моделировании можно избежать очень простым способом — не давать этим заниматься программистам, точнее тем, кто умеет писать код и знает хоть что-то про UML и ОО. Найдите бизнес-аналитика, да-да того самого, который знает бухгалтерию, финансы, кадры, или того кто знает устройство ядерного реактора и как он работает в деталях. То есть человека, который точно значет, что такое "покупатель", "бухгалтерский счёт" и пр. бизнес-объекты. Он всегда говорит на том-же языке, что и пользователи, и потому субъективности быть не может. Далее встаёт проблема взаимодействия бизнес-аналитика и программиста. "Покупатель" для бизнес-аналитика — это "человек, готовый заплатить деньги за услуги или товар", для программиста... что угодно... с вариациями, например C++ класс Customer, запись в Oracl-овой таблице Customer, web-service Customer (за это убивать надо, ну где вы видели, чтобы бизнес обеспечивал сервис под названием "Покупатель" ). Решением несоответствия между реальностью (точка зрения бизнес-аналитика) и "матрицей" (точка зрения программиста, где "покупатель" может прыгать и летать как Супермен ) должен заниматься человек, в задачу которого входит то, что на Западе называют "aligning IT to Business". То бишь заставляет IT смотреть на мир с точки зрения бизнеса (убирает субъективность, а заодно приводит к бизнес-ориентированной методологии разработки ПО, всё остальное — технические проблемы, и потому не интересные). Человек такой должен разбираться в технической архитектуре, а также в бизнес архитектуре. То есть нечто вроде бухгалтера-программиста. И такие люди есть. Да, и они не пишут код, поскольку это влияет на восприятие реальности.
M>Процесс обычно выглядит так: смортим что нужно закачику, определяем бизнес-процессы (если у вас есть желание их изменить, то вам нужно доказать, что то, как владелец фирмы делает бизнес сейчас — это неправильно, а вы готовы к этому?) и автоматизируем их Конечно для этого нужна инфраструктура, но это технические детали и потом не интересны (если очень хочется то смотрим WfMS, BPMS и пр.).
M>Да, "фазовые превращения" — это и есть бизнес процесс. "Запустили реактор" -> "Пустили козла в огород" -> "Пытаемся остановить цепную реакцию"
Все ваши примеры, ориентированные на "бизнес-процессы": зарплата, кадры, склады и т.п. А есть ведь и другие области: автоматика и механика, АСУТП и САПР, схемотехника и микроэлектроника, биология и химия, экология, эволюционные процессы, вы сами можете продолжить этот список. Везде здесь при использовании информационных систем тоже используется <моделирование>. И что-то я сомневаюсь, что тут помогут UML, SOA, BPM, ОО и т.п. Может тогда нужно ограничить область применения этих средств?

СВ>>Другой пример. Разработана огромная, сложная, система с "кучей" модулей-подмодулей, множеством средств хранения данных (базы данных, файлы различных форматов, распределенные данные в сети, контроллеры учета и регистрации и т.п.). Все это четко описано, регламентировано, стандартизировано, определены меры в случае изменения требований. Здесь виден динамический характер самой системы, а также динамический характер модели.
M>Система не должна быть сложной. Она должна быть модульной. Каждый модуль "владеет" своими данными и полностью не зависим от других модулей. В последнем предложении заменям модуль на сервис и приходим к SOA
А я и не говорил, что она не модульная. Она сложная, потому что там "много всего". "Полностью независим" — это в идеале, все равно есть случаи, когда при изменении какой-либо части не удается полностью добиться независимости. Вот тогда и начинается "подгонка" с нарушением всех правил "моделирования". А потом все это нарастает как снежный ком и приводит к провалу проекта. Иногда конечно спасает рефакторинг, но не всегда это возможно.

СВ>>Пока остановлюсь на этом, жду ваших мнений. Стоит ли это дальше обсуждать.
M>Зачем? Решение есть. Проблема только в том, что это решение в жизнь не так легко воплотить по одной простой причине — ни программисты, ни бизнес-аналитики, ни менеджеры не готовы к такому повороту дел. Менеджеры понимают, что так надо делать, но и их заносит в технические детали. С архитекторами другая проблема (из моего опыта) — они слишком технические ребята, им тяжело отделить бизнес проблемы от технических проблем. Потому каждая попытка внедрить такое решение скатывается сначала на web servic-ы, потом на недостатки XML, потом на то, что Microsoft не поддерживает транзакции для web-servic-ов. Господи!!! Какое мне дело до web-servic-ов или Microsoft??? SOA тут вообще ни причём!
И все-таки я думаю, исследовать это надо. И чем больше разносторонних и противоречащих взглядов будет, тем лучше. Это позволит взглянуть на проблему с разных сторон. И я надеюсь позволит выйти на новый уровень <моделирования>, не сочтите меня максималистом. Это как фундаментальные науки.