написано что "основная проблема построения модели предметной области состоит в выделении концептуальных классов". Для идентификации концептуальных классов в этой же книжке предлагаются три стратегии:
1. Повторное использование или модификация существующих моделей. Это самый первый, наилучший и обычно, простейший подход, с которого автор всегда старается начать процесс выделения концептуальных классов. В литературе описаны модели многих предметных областей и модели данных, которые можно трансформировать в модели предметной области. Такие модели существуют для области финансов, здравоохранения и т.п.2. С использованием списка категорий концептуальных классов.3. На основе выделения существительных
Меня наиболее всего интересует метод 1. Но он в книге не описан ("ввиду его очевидности").
Я пункт 1 понимаю как то что (где-то) имеются ресурсы на которых лежат готовые модели из разных областей деятельности (финансов, здравоохранения, торговли, перевозок, образования, туризма и т.п.)
Т.е. основные сущности (понятия) и ассоциации. (идеально — с описанием типичных прецедентов)
Соответственно вопрос — имеются ли такого рода ресурсы и если имеются то по каким урлам или ISBN-ам ?
По моему скромному мнению разработка с нуля это здорово и интересно, но дорого. (если есть типичное решение на 80% коррелирующее с задачей почему бы не взять его).
Также наличие подобного рода моделей поможет быстрее "въехать" в предметную область и обратить внимание на подводные камни, оценить объем работ и представлять бизнес-логику и систему в целом не только со слов заказчика — т.е. снижается вероятность того что в одной из итераций заказчик вспомнит что есть
одна небольшая но важная деталь которую он запамятовал сразу изложить...
Мое мнение такое что архитектор должен разбираться в предметной области лучше заказчика
Hello, alexandrST!
You wrote on Sun, 28 Oct 2007 17:30:57 GMT:
a> Я пункт 1 понимаю как то что (где-то) имеются ресурсы на которых a> лежат готовые модели из разных областей деятельности (финансов, a> здравоохранения, торговли, перевозок, образования, туризма и т.п.) a> Т.е. основные сущности (понятия) и ассоциации. (идеально — с a> описанием типичных прецедентов) a> Соответственно вопрос — имеются ли такого рода ресурсы и если a> имеются то по каким урлам или ISBN-ам ?
alexandrST wrote: > По моему скромному мнению разработка с нуля это здорово и интересно, но > дорого. (если есть типичное решение на 80% коррелирующее с задачей > почему бы не взять его).
Это у Вас неверное представление. Единственная область, где это верно --
фискальный учет. Во всех остальных нужно в каждом конкретном случае
смотреть.
> Также наличие подобного рода моделей поможет быстрее "въехать" в
Нет таких моделей. Вообще. Проблема в другом -- в компаниях, которые
занимаются одним и тем же, модели могут отличаться весьма существенно.
Иногда модели вообще могут не совпадать. Я понимаю, что это звучит
странно, но такое встречается на очень "узких" рынках, на которых,
практически, нет типичных решений в силу их узости. Когда-то изучал
технологии от UPS и от DHL. Ничего общего в моделях.
> одна небольшая но важная деталь которую он запамятовал сразу изложить... > Мое мнение такое что архитектор должен разбираться в предметной области > лучше заказчика
Нет. Каждая компания имеет свое "конкурентное преимущество", которое
позволяет ей удерживаться на рынке. И модель строится именно от этого.
Так что от заказчика все равно никуда не деться. И будет лучше, если
архитектор будет лучше разбираться в программировании, чем в бизнесе
заказчика.
Posted via RSDN NNTP Server 2.1 beta
Всё, что нас не убивает, ещё горько об этом пожалеет.
Здравствуйте, alexandrST, Вы писали:
ST>По моему скромному мнению разработка с нуля это здорово и интересно, но дорого. (если есть типичное решение на 80% коррелирующее с задачей почему бы не взять его).
Такие решения существуют, в виде тиражируемых программных продуктов.
Можно скачать демо-версию и среверсить базу данных.
Здравствуйте, alexandrST, Вы писали:
ST>Меня наиболее всего интересует метод 1. Но он в книге не описан ("ввиду его очевидности"). ST>Я пункт 1 понимаю как то что (где-то) имеются ресурсы на которых лежат готовые модели из разных областей деятельности (финансов, здравоохранения, торговли, перевозок, образования, туризма и т.п.) ST>Т.е. основные сущности (понятия) и ассоциации. (идеально — с описанием типичных прецедентов) ST>Соответственно вопрос — имеются ли такого рода ресурсы и если имеются то по каким урлам или ISBN-ам ?
Да, встречал подобное на практике. Например US Department of Justice рекмендует использовать JXDM в качестве исходной бизнес модели.
ST>По моему скромному мнению разработка с нуля это здорово и интересно, но дорого. (если есть типичное решение на 80% коррелирующее с задачей почему бы не взять его).
По-моему опыту одного такого проекта, польза от готовой модели очень мала и компенсируеются проблемами, которые ваозникают при попытках следовать этой модели но со своими нюансами. А если учесть то что модель может вам изначально не подходить, но вы такие натянете на нее нужный функционал, то потом будет не так легко с него съехать. Так что анализ готовой модели на пригодность может быть ничуть не эффективнее дизайну новой модели. Хотя, конечно, посмотреть готовую модель перед тем как создать свою всегда полезно.
ST>Также наличие подобного рода моделей поможет быстрее "въехать" в предметную область и обратить внимание на подводные камни, оценить объем работ и представлять бизнес-логику и систему в целом не только со слов заказчика — т.е. снижается вероятность того что в одной из итераций заказчик вспомнит что есть одна небольшая но важная деталь которую он запамятовал сразу изложить...
Не факт. Дело в том, что новые проекты они обычно инновационные и старую модель использовать не всегда нужно. Но если есть старая модель и готовый анализ её проблем и преимуществ, то ими конечно грех не воспользоватся. Но сама по себе модель без анализа, не есть что-то сильно полезное.
ST>Мое мнение такое что архитектор должен разбираться в предметной области лучше заказчика
8))) Утверждение ни о чем. Если конкретно по ролям, то архитектор разбирается в дизайне системы, а заказчик в финансовой стороне проекта. А вто в предметной области разбирается эксперт предметной области. Архитектор не может всегда быть экспертом предметной области потому что он проектирует архитектуру под много разных областей. Быть экспертом во всём плюс арихитектуре мало у кого получится.
Здравствуйте, alexandrST, Вы писали:
ST>Т.е. основные сущности (понятия) и ассоциации. (идеально — с описанием типичных прецедентов) ST>Соответственно вопрос — имеются ли такого рода ресурсы и если имеются то по каким урлам или ISBN-ам ?
На ум приходит только Analysis Patterns: Reusable Object Models by Martin Fowler. Хотя данная книга описывает типичные паттерны, характерные для различных предметных областей.
Задавался таким же вопросом. Имею следующие мысли:
1. В принципе, за описание предметной области Заказчик обычно деньги должен платить, а разработчик требовать. Следовательно, описание предметной области это собственность. Выкладывать описание в свободное пользование – бросать деньги на ветер.
2. Берём нашу российскую действительность. Есть закон, на основе которого должен проводиться кадровый учёт. Это есть бизнес-процесс. В каждой организации он настраивается по-своему. Но есть общие требования. Они, реализованы, например, в 1С. Каждая организация добавляет свои требования. Видели где-нибудь в свободном доступе модель – я нет. Знакомые это делают для организации — деньги за это получают. Я им предлагаю – давай сделаем описание, и будем продавать – деньги будут. Но кто купит??? Каждый будет разрабатывать самостоятельно – экономить и зарабатывать деньги сам.
3. Медицина. Всё то же самое. Закон один – работающих систем в мед.учреждениях полно. Все разные, настроены (не, нифига – заточены hardcoded) по-разному. Всё зависит от того, кто заказывает, за что платит, и т.д. Другие люди делают системы для других учреждений. Предлагаю, описать, продать. Описание тоже продукт. Кто купит??? Никто. А просто так отдавать свой труд не хочется.
4. Производство – здесь вообще труба. Даже на подобных производствах изготавливающих одинаковые изделия. Различия настолько существенны. А общего ещё больше. Тут Я долго могу рассуждать.
5. Управление НИР, ОКРами, НИОКРами. Вроде всё должно быть одно и тоже. ГОСТ есть. А нифига – всё зависит от руководителей. Каждый по своему реализует им придуманную модель управления.
А возьмем пример с различными обучающими семинарами – это ведь тоже модель. Вам рассказывают модель чего-либо (управление теми же ОКР, закупками, …) а за это люди платят.
ИМХО по этим причинам особо и не распространены библиотеки моделей предметной области.
Что можно предложить – обмен. Обмен между небольшим сообществом аналитиков. Но это другая тема.
Автор(ы): Крэг Ларман
— т.е. снижается вероятность того что в одной из итераций заказчик вспомнит что есть
