Для модальных окон есть более естественная реализация через селектор :target — пример. Кстати, через :target можно сделать и все остальные примеры кроме меню. Причём, при выборе вкладки или при открытии модального окна соответствующим образом изменяется адрес страницы: добавляется #dialog, #tab1, #tab2. И, соответственно, при обновлении страницы откроется та же самая вкладка или то же самое диалоговое окно. В этом преимущество по сравнению с checkbox. Плюс CSS-стили выглядят гораздо проще.
Наверное было бы интересно, если бы вы сделали всё то же самое, но через :target. Единственная проблема это что при закрытии диалогового окна вы переходите по адресу # и перескакиваете в начало страницы. Тут приходится уже использоваться JavaScript:
document.getElementById('close-button').addEventListener('click', function (e) {
e.preventDefault(); history.go(-1); });
Есть прямо противоположная служба — антиплагиат. Причём, алгоритмы в обоих случаях наверное схожие. До какого-то предела «плагиат» — это хорошо, мы можем понять, что статья написана действительно на английском языке. Можем определить уровень языка по количеству слов, словосочетаний, идиом в статье, которые обычно используются в хороших статьях этой тематики. Так же мы можем понять, что статья написана на определенную тематику. Можем определить, что она опирается на другие статьи в данной области, если есть пересечения с ними. Но если совпадений становится слишком много, то это уже плагиат. Интересный парадокс, получается, «плагиат» до какой-то степени — это хорошо.
Прежде чем написать статью я просматриваю не 4+, а 100+ источников по этой теме. С терминами у меня дела на порядок лучше, чем у профессиональных переводчиков. Иногда после них приходится править практически все технические термины, потому что они переводят их дословно. Например, «сформировать исходный код» они переводят как «to form a source code» вместо «to generate ...». «Ключевые компоненты» переводят как «key components» вместо «core components». «Реализацию» переводят как «realization» вместо «implementation» и т.д. Бывало, что в 10-страничной статье пришлось порядка 20 терминов править после переводчика.
Я конечно пробовал пару раз переводить сам. Но если в статье есть хотя бы несколько ошибок или необычных для английского языка оборотов, то рецензенты предлагают дать её на вычитку носителю языка. Если вам хватает знания языка для общения на форумах, написания блога, писем или для живого общения, то совершенно не факт, что этого будет достаточно для написания научной статьи, которую будет приятно читать.
Не спорю, что предпочтительней публиковаться на английском и что нужно его учить. Но нужен уровень существенно выше среднего. Прокачать английский до такого уровня общаясь на форумах или пытаясь написать статью и отправляя её на рецензирование, на мой взгляд, не получится. На форумах на ошибки просто не обращают внимание, а рецензенты ничего исправлять не будут, просто скажут, что статью читать тяжело.
Вот, кстати, идея для стартапа :) Служба, которая оценивает общеупотребительность словосочетаний и соответствующим образом раскрашивает текст. Если такие словосочетания встречаются в статьях по данной тематике часто, то отмечаем их зеленым цветом, иначе — красным, плюс полутона. Вроде реализация не выглядит слишком сложной, где бы найти время на все идеи…
Блог мне не осилить ни на каком языке :) А на форумах на неправильное употребление этого артикля или на построенные фразы странно никто обратит внимание. Кажется, я нашел, что искал. Есть ещё подобные сайты.
Есть РИНЦ. Там считаются показатели и для журналов, и для авторов. Я бы хотел выучить английский до такого уровня, чтобы писать на нём научные статьи. Я читаю по-английски на порядок больше, чем по-русски. Слушаю технические лекции на курсере без субтитров. Но для написания статей английский всё-равно очень слабый. Если кто-нибудь знает как выучить письменный английский до уровня носителя языка, был бы очень благодарен за совет.
На чужую самореализацию или подтверждение каких-то идей никто деньги не даст…
Я несколько лет работал в академической среде. Мы придумывали очень клёвые штуки, что-то реализовывали (в сфере здравоохранения), идей огромное количество. Но было слишком мало людей, мизерные зарплаты. В определённый момент я просто устал работать на энтузиазме и ушёл в коммерческую ИТ-контору. По-началу я 99% времени конечно тратил на рутину, а не на науку. Но меня всегда тянуло к исследовательской работе. В итоге я и в коммерческой конторе стал придумывать какие-то штуки, писать статьи. Причём, всё это коррелирует с основными задачами на работе.
На мой взгляд, такой вариант более жизнеспособный, чем поиск какого-то внешнего финансирования. Перед тобой стоят совершенно конкретные прикладные задачи, за решение которых заказчик готов платить. А ты можешь добавить во всё это немного науки. Таким образом ты самореализуешься, причём, в востребованном направлении.
Или другой вариант, это когда ты придумываешь какую-нибудь наукоёмкую штуку и можешь на её основе сделать коммерческий продукт. Типа того же Google, много и более мелких примеров.
Наверное, в ИТ научные исследования не могут быть сугубо теоретическими. Они должны быть привязаны к какому-нибудь коммерческому продукту. Иначе, это просто зарабатывание на получении грантов. Хотя, с другой стороны, более фундаментальные области типа физики наверное должно финансировать государство. Большая разница о какой науке идёт речь…
Вообще, конечно, интересно узнать, что в целом происходит в науке… Какие есть крупные проекты, финансируемые государством. Есть ли какая-то польза от грантов.
Я думаю, независимо от страны это могу себе позволить только относительно крупные компании, которых, в принципе, мало. Недавно была статья про то, сколько денег на это тратит Google. Причём, зачастую, деньги уходили в никуда. У нас есть коммерческие компании, которые занимаются прикладными исследованиями. Тот же Яндекс.
Государственное же финансирование научных исследований и все эти грантовые фонды в том виде в каком они сейчас существуют, на мой взгляд, это зло. Грантополучатели, главным образом, занимаются оформлением заявок на гранты, потом формально отчитываются по типа проделанной работе, но реальные результаты нулевые. А грантодатели отчитываются какие они молодцы, типа двигают вперед науку. Но всё это выглядит как разновидность благотворительности.
Скорее, они даже наносят вред науке, потому что ставят перед исследователями ложные цели. Если человек получает финансирование от кого-то, то зачем ему напрягаться, развивать какие-то идеи, придумывать что-то, что потенциально может приносить прибыль. Он уже получил финансирование, уже заработал, остаётся только отчитаться и получить следующий грант. С такой бизнес-моделью никакой науки не будет.
Завидую вашей скорости ;) У меня на любую статью, в т.ч. и не очень плюсабельную, в среднем уходит месяц, не считая предварительных 1-2 лет работы в этой тематике.
Меня статья наоборот воодушевила, я вспомнил зачем пошел работать в ИТ. Люди занимаются интересными вещами, поиском и реализацией идей. Лично я отвлекся от мыслей как заработать несколько десятков тысяч рублей и задумался на что потратил бы лишний миллиард долларов.
Модель, которая охватывает всю моделируюмую область безотносительно конкретных сценариев использования.
Это и есть концептуальная модель. Или в терминологии OMG — это Computation-Independent Model (CIM), а в терминологии Патриджа — это бизнес-модель из 4-мерных бизнес-объектов. Другие авторы называют такие модели онтологиями. UN/CEFACT называет такую модель вообще библиотекой ключевых компонентов.
Везде разные названия, разная специфика, разные акценты, но фактически имеется в виду именно то, что вы написали.
А что вы имеете в виду под нормальной унифицированной прикладной моделью? Вы не сможете в ней зафиксировать обязательность атрибутов и связей. Потому что в одном документе нужны одни атрибуты и связи, а в другом — обязательны другие. Поэтому единственный способ сделать единую модель — это описать в ней все возможные сущности со всеми возможными атрибутами и связями. Причём, всё они будут опциональные, потому что в разных документах/процессах нужны разные.
На все случаи в жизни не реально. Но, скажем, взять десяток бумажных документов в какой-нибудь конкретной предметной области, посмотреть какие сведения о физ. лице в них указываются и сделать единую модель вполне реально.
Модель на schema.org безусловно не идеальна. Например, у человека может быть несколько jobTitle в разных организациях и в разные периоды времени. Возможно, есть смысл определить отдельную роль «Работник», у которого будет jobTitle, период времени, в течении которого человек играл эту роль, привязка к организации и т.п. И соответственно в разные моменты времени человек может играть роли разных работников.
В этом и проблема. Не всегда ясно делать ли jobTitle атрибутом человека или выносить отдельно. Однозначного, универсального ответа нет. Но Патридж в книге про бизнес-объекты предлагает один из возможных вариантов. В книге как-раз есть примеры про должности.
Эмм, я, возможно, сейчас задам глупый вопрос, но зачем мне эта концептуальная модель?
Вы сами ответили на этот вопрос:
Ну так — в РФ, по крайней мере — ИТ-шная составляющая долго была подчинена бюрократической. Если в законе (или подзаконном акте) описан состав данных для конкретного учета, то ИТ-шная часть вынуждена его отражать, даже если этот состав данных давно устарел и бессмысленнен вне бумаги.
Если как есть перевести бумажные документы в электронную форму, то в них будут бессмысленные поля. Например, полное наименование страны вместо указания кода. Но это ерунда по сравнению с тем, что количество форм бумажных документов в некоторых областях исчисляется сотнями. Причем, сведения во всех этих документах передаются примерно обо одних и тех же объектах реального мира. Только в одном документе обязательны одни атрибуты, а в другом — другие. И если из этой сотни бумажных форм сделать сотню электронных форм, то жизнь у законодателей и бизнеса станет немного лучше, но не так как хотелось бы. А хотелось бы превратить эту условную сотню бумажных документов в единую концептуальную модель данных, в которой описаны все реальные объекты, о которых передаются сведения в документах. А потом, имея эту единую КМ, просто отмечать, что в этом процессе или сценарии мне нужны такие-то свойства таких-то объектов, а в этом процессе — такие-то.
Я понимаю, что перевод бумажных документов в электронную форму сам по себе безусловно даёт преимущества. Не нужно стоять в очередях, быстрее всё будет обрабатываться. В качестве первого шага — это замечательно. Но документо-ориентированный подход порочен сам по себе и неважно бумажный он или электронный. Я всё время возвращаюсь к книге Патриджа про бизнес-объекты. Он ровно про это и пишет. Что тысячелетиями мы придумывали новые формы документов, но сейчас настало время полностью отказаться от этого подхода.
А в этой модели и не нужно отмечать, что у заявителя ФИО обязательно. В одном случае оно обязательно, а в другом случае обязателен какой-нибудь ИНН, а ФИО наоборот нельзя указывать.
Мы говорим о разных моделях. Я о концептуальных, для которых требуется максимальный охват и минимум ограничений. А вы — о логических, где появляются все эти ограничения на обязательность заполнения атрибутов и т.п. В одном сценарии/процессе ограничения будут одни, в другом — другие. А концептуальная модель во всех случаях единая.
Добавить в модель связь между юр.лицом и заявителем дешевле, чем переименовывать ФИО в «название» и переносить дату рождения в какой-то другой класс. Переименовывания, переносы и прочие изменения уже существующего обходятся безусловно дороже, чем добавление нового.
Я согласен с тем, что сделать идеальную модель на все случаи в жизни невозможно. Если юр.лица или, скажем, марсиане :) в принципе не могут выступать в качестве заявителя, то наверное такие ситуации и не стоит рассматривать. Если есть какой-то документ, в котором уже всё описано, что может быть, чего не может быть, тогда и моделировать особо нечего, нужно просто реализовать как написано.
Представьте, что вы находитесь по другую сторону законодательства. Кто-то же придумывает все эти структуры документов, схемы данных для предоставления отчетности. Я имею в виду ИТшную составляющую, а не бюрократическую. Если вы вдруг скажете, ой, вот, тут мы в схеме данных что-то не учли, давайте переделаем. Представляете какие это расходы для бизнеса. Для вас сейчас (по эту сторону) это конечно доходы, вам платят за изменение моделей и кода в соответствии с изменениями законодательства. Но для бизнеса-то — это расходы и «законодателей» за частые и существенные изменения могут и премии лишить.
Физ. лицо — это класс объектов. Заявитель — это роль, которую может играть физ. лицо. У физ. лица есть свойства ФИО, дата рождения и т.д. У заявителя не могу придумать свойства, пусть будет связь с заявлением.
Например, в будущем в качестве заявителя может выступать ещё и юр. лицо. В этом случае мы ничего не перелопачиваем, а просто добавляем новый класс юр. лицо и отмечаем, что его экземпляры могут играть роль заявителя.
Если в будущем нам понадобятся роли водитель, перевозчик и т.п., то мы просто их добавим в модель, не ломая того, что уже есть.
А, вот, если бы мы сделали ФИО и дату рождения атрибутом заявителя. То появление заявителей-юр.лиц потребовало бы существенных изменений модели.
Это сейчас. В долгосрочной перспективе во многих областях единые модели постепенно заменяют ad hoc решения. Правда появляются новые ad hoc решения. Не знаю придём ли мы когда-нибудь к единой модели всего, такой, что ad hoc модели уже не понадобятся.
в конкретной прикладной задаче, которую я решаю сейчас, стоимость любого изменения модели все равно меньше, чем потери, которые я несу от задержки выпуска первой версии
Я последние несколько лет тоже решаю совершенно конкретные прикладные задачи. Но опыт прямо противоположный: быстрые ad hoc решения потом дорого обходятся. Хотя истина где-то посередине: за сверх-гениальную модель, первая версия которой будет сделана через 10 лет, тоже уже не заплатят.
Вот, примеры моделей, которые делаются из расчета, что они будут использоваться десятилетия без революционных изменений, любые изменения в этих областях влекут большие расходы:
1) ISO 20022, можно её скачать в Ecore-формате, в ней определены сотни сущностей, сведения о которых передаются в этих сообщениях.
2) NIEM тоже можно скачать, это относительно большая модель. Безусловно в неё вносятся изменения, но это требует обоснований, согласований. Переход на новую версию модели тоже влечет расходы.
4) Но по сравнению с ISO 15926 все эти модели — просто детский сад. Она основана на 4-мерных бизнес-объектах Патриджа.
Бизнесу нужны только структуры сообщений. Верхний уровень, описывающий реальность им не нужен. Особенно верхний уровень ISO 15926 настолько далек от потребностей бизнеса, что наверное мало кто вообще понимает что там и зачем. Но чтобы структуры сообщений не менялись по каждому чиху, чтобы бизнес не тратил деньги на эти изменения, приходится привязывать модели к реальности, потому что она более устойчивая и надежная чем структуры документов или ещё какие-то частности.
Это две разные модели: 1) модель, где есть сущность «физ. лицо» с в двумя ролями «заявитель» и «пользователь» и 2) схема данных в РСУБД.
Допустим, сейчас у пользователей указывается только display name. А в будущем понадобится указывать ФИО, дату рождения, пол, адрес электронной почты, телефонный номер и т.д. Причём, аналогичные поля могут быть и у заявителя. Вполне возможна ситуация, что сейчас атрибуты пользователей и заявителей практически не пересекаются, а в будущем они будут пересекаться очень сильно. Вполне возможно, что даже в этом случае из соображений производительности, безопасности или ещё каких-то в РСУБД сведения о пользователях и заявителях должны храниться в разных таблицах. Это не проблема.
Проблема в том, что фамилия пользователя может храниться в поле LastName и дата рождения в поле BirthDate, а у заявителя эти же поля могут называться соответственно FamilyName и DateOfBirth. На логическом уровне, на уровне РСУБД в зависимости от требований можно хранить все эти сведения и в 1 таблице, и в 2, и в 3, и в большем количестве таблиц (отдельно обычные заявители, отдельно — vip). Но если над логической моделью нет концептуальной модели (или Computation-Independent Model (CIM), модели бизнес-объектов и т.д. — можно по-разному их называть), т.е. модели, которая не завязана на технические детали (типа AD, РСУБД и т.п.), то неизбежно 1) будет возникать подобное дублирование, расхождения и 2) возможны существенные изменения модели (вчера считали пользователя и заявителя отдельными сущностями, а завтра наследуем их от физ. лица).
На концептуальном уровне хочется модель, которую один раз согласовали, утвердили и дальше только дополняем, без существенных переделок. В обсуждаемой книге как-раз и предлагается способ построения таких моделей. Будет класс «физ. лицо». Физ. лица могут играть роли пользователей, заявителей и т.п. В будущем могут появляться новые роли, могут появляться новые атрибуты. Но каких-то существенных изменений в физ. лицах, заявителях и пользователях уже не будет. Уже невозможна ситуация, при которой мы будем перелопачивать какие-то иерархии, ломать уже утвержденные классы и т.п.
Безусловно, разрабатывать такую полностью «правильную» концептуальную модель на десятилетия вперед очень дорого. Более того, как говорит Патридж (автор книги про бизнес-объекты), в терминах сущностей, атрибутов и связей такую модель невозможно построить в принципе. Значит, нужны методологи, которые прочитают Патриджа и другие книги, выберут из множества подходов оптимальный, как-то адаптируют его, разработают ядро будущей концептуальной модели, напишут методику, как эта модель должна дорабатываться. Это не пустые слова, я видел такие проекты. Всё это не то, что дорого, а очень дорого. Но если этого не делать, то расходы на перелопачивание модели, на переписывание кода будут ещё больше.
Короче, всё зависит от проекта, от требований. Часто можно сразу делать схему РБД и не заморачиваться с «объектами реального мира» и т.п. Но есть проекты, где никак не обойтись без «реального мира». Например, проекты, в которых используются ISO 15926, UN/CEFACT CCTS, ISO 20022 и др.
Вопрос в том, что дороже: 1) вносить изменения в модель и код или 2) изначально делать максимально «правильную» модель, которая в будущем будет только дополняться.
Это вопрос терминологии и определений. Например, тут пишут, что концептуальная модель состоит из концептов (понятий), как вы и говорите, но потом:
Entity-relationship modeling (ERM) is a conceptual modeling technique used primarily for software system representation. Entity-relationship diagrams, which are a product of executing the ERM technique, are normally used to represent database models and information systems. The main components of the diagram are the entities and relationships.
Ну, т.е. они пишут просто «сущность» и «отношение», а не «концепт сущности» или «концепт отношения».
Блин, короче тут вообще путаница. Сначала они говорят, что концептуальные модели обычно про реальный мир:
Conceptual models are often abstractions of things in the real world whether physical or social.
А потом говорят, что ER-модели концептуальные, но про информационные системы, а не реальный мир (см. первую цитату).
Огромное количество разных подходов к моделированию. Они вроде про одно и то же, но везде разная терминология.
Согласен с Вами и Михаилом, что дело не в людях, которые моделируют, а в требованиях.
Вообще эта идея не нова. Есть деление на концептуальный, логический, физический уровни. В архитектуре, управляемой моделями, деление на CIM, PIM, PSM — очень рекомендую прочитать документ по ссылке тем, кто интересуется моделированием. В какой-нибудь модели Захмана уже другие уровни. Но идея везде одна — на верхнем уровне моделируем реальность, независимо от технических деталей, от того как именно будет реализована ИС. На следующих уровнях моделируем уже саму ИС.
В BPMN, кстати, основная идея такая же (у Makhinko был вопрос по моделированию процессов). Если вы сомневаетесь правильно ли спроектировали процесс, то представьте, что он будет выполняться не с помощью разрабатываемой программы, а посредством бумажных документов или вручную. Или представьте, что он выполняется 100 лет назад или спустя 100 лет при совершенно других технических возможностях. Если процесс при этом не нужно перерисовывать, если вы не указали в нём лишние технические детали (типа нажать на кнопку, отправить сообщение и т.п.), значит процесс спроектирован нормально. Иначе кнопку заменят на ссылку, отправку текстового сообщения — на голосовое управление, и модель процесса станет уже не актуальной. Лишние технические детали и усложняют понимание моделируемого процесса, и ограничивают людей, которые будут разрабатывать под него ИС.
Короче, в обсуждаемой книге накомпилировано много разных идей про разницу между моделированием объектов реального мира и моделированием ИС. 4-мерное пространство-время они взяли у физиков. То, что модели сущность-связь имеют ограничения тоже придумано не ими — есть объектно-ролевое моделирование, позже появились всякие RDF, OWL.
В вузе нас учили, что логические модели отличаются от концептуальных только степенью детализации. Типа на концептуальном уровне мы выделяем сущности, определяем отношения между ними. А на логическом уровне добавляем атрибуты, указываем ключи и т.п. Разница между концептуальными моделями и логическими была какая-то мутная. Скажем, почему атрибуты нельзя указать сразу на концептуальном уровне? И зачем вообще такое деление? Чтобы не грузить заказчика лишними деталями? А если ему важны эти детали? Короче, в вузе я это не понимал.
А в этой книге говорится, что на концептуальном и логическом уровнях (можно эти уровни называть иначе) моделируются в принципе разные вещи. На верхнем уровне моделируется, скажем, человек, автомобиль. А на уровне ИС моделируются сведения об этих объектах, представленные в виде каких-нибудь документов (паспорт, технический паспорт и т.п.). Т.е. ты должен чётко понимать моделируешь ты объект или документы и т.п.
Кстати, я писал на эту тему статью, там наверное много наивных вещей и заблуждений, но может кому-то будет интересно. Там приводится пример про перевозку креветок. Есть три стороны, которые задействованы в этом процессе — производитель, перевозчик, таможня. Каждая из сторон смотрит на одни и те же креветки (объект реального мира) через призму своих документов (таможенная декларация, транспортные документы и т.п.). Идея в том, что если мы моделируем креветок как они есть, абстрагируясь от документов и ИС (в которых будут учитываться сведения о креветках), то модель будет более универсальная, более устойчивая. Скажем, если изменится структура таможенной декларации, то такую модель это либо вообще не затронет, либо модель будет просто немного дополнена. Каких-то кардинальных изменений в ней не будет.
Наверное было бы интересно, если бы вы сделали всё то же самое, но через :target. Единственная проблема это что при закрытии диалогового окна вы переходите по адресу # и перескакиваете в начало страницы. Тут приходится уже использоваться JavaScript:
Я конечно пробовал пару раз переводить сам. Но если в статье есть хотя бы несколько ошибок или необычных для английского языка оборотов, то рецензенты предлагают дать её на вычитку носителю языка. Если вам хватает знания языка для общения на форумах, написания блога, писем или для живого общения, то совершенно не факт, что этого будет достаточно для написания научной статьи, которую будет приятно читать.
Не спорю, что предпочтительней публиковаться на английском и что нужно его учить. Но нужен уровень существенно выше среднего. Прокачать английский до такого уровня общаясь на форумах или пытаясь написать статью и отправляя её на рецензирование, на мой взгляд, не получится. На форумах на ошибки просто не обращают внимание, а рецензенты ничего исправлять не будут, просто скажут, что статью читать тяжело.
Вот, кстати, идея для стартапа :) Служба, которая оценивает общеупотребительность словосочетаний и соответствующим образом раскрашивает текст. Если такие словосочетания встречаются в статьях по данной тематике часто, то отмечаем их зеленым цветом, иначе — красным, плюс полутона. Вроде реализация не выглядит слишком сложной, где бы найти время на все идеи…
Я несколько лет работал в академической среде. Мы придумывали очень клёвые штуки, что-то реализовывали (в сфере здравоохранения), идей огромное количество. Но было слишком мало людей, мизерные зарплаты. В определённый момент я просто устал работать на энтузиазме и ушёл в коммерческую ИТ-контору. По-началу я 99% времени конечно тратил на рутину, а не на науку. Но меня всегда тянуло к исследовательской работе. В итоге я и в коммерческой конторе стал придумывать какие-то штуки, писать статьи. Причём, всё это коррелирует с основными задачами на работе.
На мой взгляд, такой вариант более жизнеспособный, чем поиск какого-то внешнего финансирования. Перед тобой стоят совершенно конкретные прикладные задачи, за решение которых заказчик готов платить. А ты можешь добавить во всё это немного науки. Таким образом ты самореализуешься, причём, в востребованном направлении.
Или другой вариант, это когда ты придумываешь какую-нибудь наукоёмкую штуку и можешь на её основе сделать коммерческий продукт. Типа того же Google, много и более мелких примеров.
Наверное, в ИТ научные исследования не могут быть сугубо теоретическими. Они должны быть привязаны к какому-нибудь коммерческому продукту. Иначе, это просто зарабатывание на получении грантов. Хотя, с другой стороны, более фундаментальные области типа физики наверное должно финансировать государство. Большая разница о какой науке идёт речь…
Вообще, конечно, интересно узнать, что в целом происходит в науке… Какие есть крупные проекты, финансируемые государством. Есть ли какая-то польза от грантов.
Государственное же финансирование научных исследований и все эти грантовые фонды в том виде в каком они сейчас существуют, на мой взгляд, это зло. Грантополучатели, главным образом, занимаются оформлением заявок на гранты, потом формально отчитываются по типа проделанной работе, но реальные результаты нулевые. А грантодатели отчитываются какие они молодцы, типа двигают вперед науку. Но всё это выглядит как разновидность благотворительности.
Скорее, они даже наносят вред науке, потому что ставят перед исследователями ложные цели. Если человек получает финансирование от кого-то, то зачем ему напрягаться, развивать какие-то идеи, придумывать что-то, что потенциально может приносить прибыль. Он уже получил финансирование, уже заработал, остаётся только отчитаться и получить следующий грант. С такой бизнес-моделью никакой науки не будет.
Везде разные названия, разная специфика, разные акценты, но фактически имеется в виду именно то, что вы написали.
Модель на schema.org безусловно не идеальна. Например, у человека может быть несколько jobTitle в разных организациях и в разные периоды времени. Возможно, есть смысл определить отдельную роль «Работник», у которого будет jobTitle, период времени, в течении которого человек играл эту роль, привязка к организации и т.п. И соответственно в разные моменты времени человек может играть роли разных работников.
В этом и проблема. Не всегда ясно делать ли jobTitle атрибутом человека или выносить отдельно. Однозначного, универсального ответа нет. Но Патридж в книге про бизнес-объекты предлагает один из возможных вариантов. В книге как-раз есть примеры про должности.
Вы сами ответили на этот вопрос:
Если как есть перевести бумажные документы в электронную форму, то в них будут бессмысленные поля. Например, полное наименование страны вместо указания кода. Но это ерунда по сравнению с тем, что количество форм бумажных документов в некоторых областях исчисляется сотнями. Причем, сведения во всех этих документах передаются примерно обо одних и тех же объектах реального мира. Только в одном документе обязательны одни атрибуты, а в другом — другие. И если из этой сотни бумажных форм сделать сотню электронных форм, то жизнь у законодателей и бизнеса станет немного лучше, но не так как хотелось бы. А хотелось бы превратить эту условную сотню бумажных документов в единую концептуальную модель данных, в которой описаны все реальные объекты, о которых передаются сведения в документах. А потом, имея эту единую КМ, просто отмечать, что в этом процессе или сценарии мне нужны такие-то свойства таких-то объектов, а в этом процессе — такие-то.
Я понимаю, что перевод бумажных документов в электронную форму сам по себе безусловно даёт преимущества. Не нужно стоять в очередях, быстрее всё будет обрабатываться. В качестве первого шага — это замечательно. Но документо-ориентированный подход порочен сам по себе и неважно бумажный он или электронный. Я всё время возвращаюсь к книге Патриджа про бизнес-объекты. Он ровно про это и пишет. Что тысячелетиями мы придумывали новые формы документов, но сейчас настало время полностью отказаться от этого подхода.
Мы говорим о разных моделях. Я о концептуальных, для которых требуется максимальный охват и минимум ограничений. А вы — о логических, где появляются все эти ограничения на обязательность заполнения атрибутов и т.п. В одном сценарии/процессе ограничения будут одни, в другом — другие. А концептуальная модель во всех случаях единая.
Добавить в модель связь между юр.лицом и заявителем дешевле, чем переименовывать ФИО в «название» и переносить дату рождения в какой-то другой класс. Переименовывания, переносы и прочие изменения уже существующего обходятся безусловно дороже, чем добавление нового.
Я согласен с тем, что сделать идеальную модель на все случаи в жизни невозможно. Если юр.лица или, скажем, марсиане :) в принципе не могут выступать в качестве заявителя, то наверное такие ситуации и не стоит рассматривать. Если есть какой-то документ, в котором уже всё описано, что может быть, чего не может быть, тогда и моделировать особо нечего, нужно просто реализовать как написано.
Представьте, что вы находитесь по другую сторону законодательства. Кто-то же придумывает все эти структуры документов, схемы данных для предоставления отчетности. Я имею в виду ИТшную составляющую, а не бюрократическую. Если вы вдруг скажете, ой, вот, тут мы в схеме данных что-то не учли, давайте переделаем. Представляете какие это расходы для бизнеса. Для вас сейчас (по эту сторону) это конечно доходы, вам платят за изменение моделей и кода в соответствии с изменениями законодательства. Но для бизнеса-то — это расходы и «законодателей» за частые и существенные изменения могут и премии лишить.
Например, в будущем в качестве заявителя может выступать ещё и юр. лицо. В этом случае мы ничего не перелопачиваем, а просто добавляем новый класс юр. лицо и отмечаем, что его экземпляры могут играть роль заявителя.
Если в будущем нам понадобятся роли водитель, перевозчик и т.п., то мы просто их добавим в модель, не ломая того, что уже есть.
А, вот, если бы мы сделали ФИО и дату рождения атрибутом заявителя. То появление заявителей-юр.лиц потребовало бы существенных изменений модели.
Я последние несколько лет тоже решаю совершенно конкретные прикладные задачи. Но опыт прямо противоположный: быстрые ad hoc решения потом дорого обходятся. Хотя истина где-то посередине: за сверх-гениальную модель, первая версия которой будет сделана через 10 лет, тоже уже не заплатят.
1) ISO 20022, можно её скачать в Ecore-формате, в ней определены сотни сущностей, сведения о которых передаются в этих сообщениях.
2) NIEM тоже можно скачать, это относительно большая модель. Безусловно в неё вносятся изменения, но это требует обоснований, согласований. Переход на новую версию модели тоже влечет расходы.
3) UN/CCL можно скачать.
4) Но по сравнению с ISO 15926 все эти модели — просто детский сад. Она основана на 4-мерных бизнес-объектах Патриджа.
Бизнесу нужны только структуры сообщений. Верхний уровень, описывающий реальность им не нужен. Особенно верхний уровень ISO 15926 настолько далек от потребностей бизнеса, что наверное мало кто вообще понимает что там и зачем. Но чтобы структуры сообщений не менялись по каждому чиху, чтобы бизнес не тратил деньги на эти изменения, приходится привязывать модели к реальности, потому что она более устойчивая и надежная чем структуры документов или ещё какие-то частности.
Допустим, сейчас у пользователей указывается только display name. А в будущем понадобится указывать ФИО, дату рождения, пол, адрес электронной почты, телефонный номер и т.д. Причём, аналогичные поля могут быть и у заявителя. Вполне возможна ситуация, что сейчас атрибуты пользователей и заявителей практически не пересекаются, а в будущем они будут пересекаться очень сильно. Вполне возможно, что даже в этом случае из соображений производительности, безопасности или ещё каких-то в РСУБД сведения о пользователях и заявителях должны храниться в разных таблицах. Это не проблема.
Проблема в том, что фамилия пользователя может храниться в поле LastName и дата рождения в поле BirthDate, а у заявителя эти же поля могут называться соответственно FamilyName и DateOfBirth. На логическом уровне, на уровне РСУБД в зависимости от требований можно хранить все эти сведения и в 1 таблице, и в 2, и в 3, и в большем количестве таблиц (отдельно обычные заявители, отдельно — vip). Но если над логической моделью нет концептуальной модели (или Computation-Independent Model (CIM), модели бизнес-объектов и т.д. — можно по-разному их называть), т.е. модели, которая не завязана на технические детали (типа AD, РСУБД и т.п.), то неизбежно 1) будет возникать подобное дублирование, расхождения и 2) возможны существенные изменения модели (вчера считали пользователя и заявителя отдельными сущностями, а завтра наследуем их от физ. лица).
На концептуальном уровне хочется модель, которую один раз согласовали, утвердили и дальше только дополняем, без существенных переделок. В обсуждаемой книге как-раз и предлагается способ построения таких моделей. Будет класс «физ. лицо». Физ. лица могут играть роли пользователей, заявителей и т.п. В будущем могут появляться новые роли, могут появляться новые атрибуты. Но каких-то существенных изменений в физ. лицах, заявителях и пользователях уже не будет. Уже невозможна ситуация, при которой мы будем перелопачивать какие-то иерархии, ломать уже утвержденные классы и т.п.
Безусловно, разрабатывать такую полностью «правильную» концептуальную модель на десятилетия вперед очень дорого. Более того, как говорит Патридж (автор книги про бизнес-объекты), в терминах сущностей, атрибутов и связей такую модель невозможно построить в принципе. Значит, нужны методологи, которые прочитают Патриджа и другие книги, выберут из множества подходов оптимальный, как-то адаптируют его, разработают ядро будущей концептуальной модели, напишут методику, как эта модель должна дорабатываться. Это не пустые слова, я видел такие проекты. Всё это не то, что дорого, а очень дорого. Но если этого не делать, то расходы на перелопачивание модели, на переписывание кода будут ещё больше.
Короче, всё зависит от проекта, от требований. Часто можно сразу делать схему РБД и не заморачиваться с «объектами реального мира» и т.п. Но есть проекты, где никак не обойтись без «реального мира». Например, проекты, в которых используются ISO 15926, UN/CEFACT CCTS, ISO 20022 и др.
Вопрос в том, что дороже: 1) вносить изменения в модель и код или 2) изначально делать максимально «правильную» модель, которая в будущем будет только дополняться.
Ну, т.е. они пишут просто «сущность» и «отношение», а не «концепт сущности» или «концепт отношения».
Блин, короче тут вообще путаница. Сначала они говорят, что концептуальные модели обычно про реальный мир:
А потом говорят, что ER-модели концептуальные, но про информационные системы, а не реальный мир (см. первую цитату).
Огромное количество разных подходов к моделированию. Они вроде про одно и то же, но везде разная терминология.
Вообще эта идея не нова. Есть деление на концептуальный, логический, физический уровни. В архитектуре, управляемой моделями, деление на CIM, PIM, PSM — очень рекомендую прочитать документ по ссылке тем, кто интересуется моделированием. В какой-нибудь модели Захмана уже другие уровни. Но идея везде одна — на верхнем уровне моделируем реальность, независимо от технических деталей, от того как именно будет реализована ИС. На следующих уровнях моделируем уже саму ИС.
В BPMN, кстати, основная идея такая же (у Makhinko был вопрос по моделированию процессов). Если вы сомневаетесь правильно ли спроектировали процесс, то представьте, что он будет выполняться не с помощью разрабатываемой программы, а посредством бумажных документов или вручную. Или представьте, что он выполняется 100 лет назад или спустя 100 лет при совершенно других технических возможностях. Если процесс при этом не нужно перерисовывать, если вы не указали в нём лишние технические детали (типа нажать на кнопку, отправить сообщение и т.п.), значит процесс спроектирован нормально. Иначе кнопку заменят на ссылку, отправку текстового сообщения — на голосовое управление, и модель процесса станет уже не актуальной. Лишние технические детали и усложняют понимание моделируемого процесса, и ограничивают людей, которые будут разрабатывать под него ИС.
Короче, в обсуждаемой книге накомпилировано много разных идей про разницу между моделированием объектов реального мира и моделированием ИС. 4-мерное пространство-время они взяли у физиков. То, что модели сущность-связь имеют ограничения тоже придумано не ими — есть объектно-ролевое моделирование, позже появились всякие RDF, OWL.
В вузе нас учили, что логические модели отличаются от концептуальных только степенью детализации. Типа на концептуальном уровне мы выделяем сущности, определяем отношения между ними. А на логическом уровне добавляем атрибуты, указываем ключи и т.п. Разница между концептуальными моделями и логическими была какая-то мутная. Скажем, почему атрибуты нельзя указать сразу на концептуальном уровне? И зачем вообще такое деление? Чтобы не грузить заказчика лишними деталями? А если ему важны эти детали? Короче, в вузе я это не понимал.
А в этой книге говорится, что на концептуальном и логическом уровнях (можно эти уровни называть иначе) моделируются в принципе разные вещи. На верхнем уровне моделируется, скажем, человек, автомобиль. А на уровне ИС моделируются сведения об этих объектах, представленные в виде каких-нибудь документов (паспорт, технический паспорт и т.п.). Т.е. ты должен чётко понимать моделируешь ты объект или документы и т.п.
Кстати, я писал на эту тему статью, там наверное много наивных вещей и заблуждений, но может кому-то будет интересно. Там приводится пример про перевозку креветок. Есть три стороны, которые задействованы в этом процессе — производитель, перевозчик, таможня. Каждая из сторон смотрит на одни и те же креветки (объект реального мира) через призму своих документов (таможенная декларация, транспортные документы и т.п.). Идея в том, что если мы моделируем креветок как они есть, абстрагируясь от документов и ИС (в которых будут учитываться сведения о креветках), то модель будет более универсальная, более устойчивая. Скажем, если изменится структура таможенной декларации, то такую модель это либо вообще не затронет, либо модель будет просто немного дополнена. Каких-то кардинальных изменений в ней не будет.