Все технические форумы на одном сайте Удобный поиск информации с популярных форумов в одном месте
Вопрос: ER диаграммы или диаграммы классов?

Допустим есть какая то задача ну или User-story и мне надо провести системный анализ по ней. вот что лучше использовать в проектировании диаграммы классов или ER диаграммы? и как разобраться что именно выбрать (по каким критериям) тот или иной вид диаграммы.
Ответ:
982183
Вы можете показать некий пример?
Если позволяет кофиненциальность

Нет не могу из проектов выкладывать в интернет. :(
Могу сказать что я делаю:
1) Диаграммы классов
2) Диаграммы активности
3) Диаграммы состояний
4) Пользовательские интерфейсы
5) в erwin физическую модель БД (логическая считаю сложной и заморочно ее вести, поэтому она у меня она не прижилась (не исключаю того, что я "просто не умею их (кошек, логическую модель и т.д) готовить"). Вместо логической прекрасно подходит диаграмма классов.
Программисты понимают все это с одного взгляда. Кроме того это своего рода мыслительный инструмент для меня лично. Я визуал - мне нужно увидеть, поэтому я это широко использую.
Решение нужно рисовать диаграммы или не нужно, полезны они или бесполезны каждый принимает для себя, но мой опыт таков...
Вопрос: Бесплатные программы проектирования промышленных предприятий.

Есть какие нибудь программы, где бы можно было бы создать визуально здания и разместить различное оборудование, как оно у нас стоит? Но бесплатные(или очень бюджетные) и простые, компактные. в 3D или 2.5D.

Factory Design Suite
Ответ: Обучалки для архитекторов а вот раздел со списком фирм использующих блендер на их сайте пропал, хотя точно помню лет 5 назад был....
Вопрос: Проектирование баз данных. Алгоритм действий и инструменты

в продолжение обсуждения решил создать отдельную тему.

Мартин Грабер в Гл 19 "Проектирование баз данных" описывает два основных алгоритма создания баз данных, а именно:
1. На базе подхода ER-модели создаются ER-диаграммы, затем они преобразуются программистом в таблицы реляционной базы данных и проверяются на соответствие требованиям нормализации (то есть, фактически, не накосячил ли программист, ведь если все делать правильно, то из ER-диаграммы путем достаточно формальных процедур можно получить достаточно нормализованные таблицы).
2. Создается некая супертаблица (набор супертаблиц), то есть набор всех возможных атрибутов (столбцов) в одной куче, и затем путем её декомпозиции создаётся удобоваримый и в меру нормализованный набор таблиц - схема БД.

При это отмечается, что подход на базе ER-модели является предпочтительным и к тому же - более человечным, интуитивно более понятным (он менее формален, чем подход два).

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

P.S.
Есть конечно некий предварительный этап (очень важный и затратный по силам и времени), вплоть до разработки ТЗ, который может разниться в зависимости от рода задачи, а именно:
- Изучение предметной области
- Выявление и определение сущностей, атрибутов (столбцов), связей
и т.д.
Но это отдельная история.
Если говорить ещё и о проблеме разработки ТЗ, о проблеме общения с заказчиками и со специалистами предметной области - то это отдельная задача.
Кстати, проблемы этой задачи в чем-то общие и при разработке БД для заказчика и при разработке сайта. Особенно, если заказчик не является крупной структурой и у него нет специалистов-программистов, погруженных в предметную область и могущих компетентно разработать ТЗ.
То есть, есть проблема преодоления пропасти: программист не знает предметной области, а заказчик не понимает как поставить задачу программисту. Считаю, что для преодоления такой пропасти могло бы существовать специальное ПО. Но это постскриптум.
Ответ: titan4ik, Щас вот подумал и понял, что я просто зациклился на БД, а так к примеру у себя на работе, при проектировании принципиальных схем по автоматизации оборудования котельных, всегда сначала нарисую принципиальную электрическую схему схему с теми же реле, их контактами и прочими переключателями.
Правда не на листочке это делаю а на компе в экселе рисую, ибо можно изменить не черкая и не стирая.
типа к примеру так.
Если надо распечатать, очень даже удобно.
Возможно есть какие то и более продвинутые программы, но т. к. я старый пердун привык по старинке, мне так привычнее и тем более эксель есть на любом ПК.
Вопрос: Программа для проектирования ERD диаграмм?

Какие есть быстрые и бесплатные(или не дороже 100$) компактные программки для проектирования ERD диаграмм?

Мне достаточно только добавлять и двигать таблички, у таблички есть поле с названием и типом данных.

Вот как здесь например:
Ответ:
Data Modeler
Oracle SQL Developer Data Modeler
Кстати, классная программа. И официально бесплатная.
Вопрос: Проектирование БД "Баскетбол" (нужен совет)

Добрый день. Нужен совет по проектированию БД "Баскетбол". Есть таблицы Person (общая информация о человеке: имя, дата рождения и т.д.) и Player (информация об игроке: позиция, рост и т.д.) со связью один к одному. Сейчас добавил в БД таблицу Staff (сотрудники команды и их должности, чтобы хранить информацию, например, о тренере). Поэтому теперь связь один к одному между Person-Player мне не подходит. Как реализовать логично с учетом того, что бывший игрок может стать тренером?

Прикрепил диаграмму (Person, Player, Staff, Contract) и полную диаграмму всех таблиц в БД. Буду рад получить какие-то рекомендации по вопросу и по БД в целом.
Ответ: Спасибо за ваш ответ. БД разрабатываю в MS SQL Server, затем буду работать с Visual Studio на .NET и Entity Framework. Прикрепил диаграмму, потому что думаю, что основные принципы построения баз данных одинаковы, независимо от СУБД.
Вопрос: Agile и нигилизм в проектировании систем

В последнее время приходится часто наблюдать нигилистическое отношение к проектированию программно-аппаратных систем. Частично этому способствует широкое, но недостаточно осознанное распространение Agile методологий (см. ). Значение и обоснование роли проектирования приведено в статье «». Здесь я хочу добавить личный опыт, хотя для «нигилистов» это, наверное, не аргумент – каждый хочет учиться на своих ошибках.
В начале 90-х участвовал в комплексной разработке информационных систем для Объединения «ГЖЕЛЬ» (фарфор). Тогда это был большой и богатый производственный комплекс, объединяющей 12 заводов. Работал в Совместном Российско-Британском предприятии «Комплекс-Бродвей Компьютерс Сайенс Сервисез». Среда разработки была по тем временам очень высокоуровневая – Dbase 4. В те времена это был модный класс технологий-методологий, именуемый Rapid Development (звучит похоже на Agile – не правдо?). Действительно, программисты получали начальный набор требований к разработке (типа Back Log). Дальше разрабатывали системы, с частыми релизами, с показом Заказчику. Подобно я делал АРМ (автоматизированное рабочее место) «Сбыт» (сбыт продукции – архи важно и эффектно для компании). Я очень старался, делал быстро, показывал заказчику часто, и через 3 месяца сдал. Все хорошо, но через полгода Заказчик решил отказаться от технологии Dbase 4 – уж больно медленно все работало, и требовало много вычислительных ресурсов. Нам поручили переделать системы по более эффективной с точки зрения производительности, быстродействия систем, требований к вычислительным ресурсам. Использовали библиотеки CodeBase для С и С++ для работы с базами данных (DBF), разработки пользовательских интерфейсов и отчетов. Помня эпопею с разработкой подсистемы «Сбыт» на основе высокоуровневых средств (Dbase 4), боялся, что займет много времени (с использованием низкоуровневых средств).
Однако это заняло 2 недели – т. е. в 6-7 раз быстрее.
В чем разница? Разница в том, что этап проектирования был уже сделан.
Вывод – качественное проектирование может сократить время разработки в разы (даже во много раз).
В 1996-1997 годах работал программистом в Центральном Телеграфе РФ (это не телеграммы – это одна из крупнейших телекоммуникационных компаний РФ (по крайней мере на то время), предоставляющая сотни видов услуг, организациям и физическим лицам). В я пришел в августе, нам сообщили что на разработку новой комплексной билингвой системы дается 3 месяца (технология Oracle DB, Developer 2000, PL/SQL), затем 1-2 месяца опытная эксплуатация, затем ввод в промышленную эксплуатацию. Нас 4-5 программистов. Казалось это нереально. Но нас успокоили – компания ФОРС за последние месяцы провело детальное проектирование системы (с использованием средств Designer 2000). Мы действительно сделали все в срок. Система заработала на всю страну.
В конце 90х участвовал в проекте по разработке информационной системы Федерального Казначейства РФ (работал в компании Avicomp Services AG). Это была глобальная система масштаба страны, обеспечивающее распределение и доведение до потребителей бюджетных средств страны, имеющая 3-и уровня – центральный, региональный, муниципальный. Огромное количество системных требований, сложная архитектура, особенно в части объектов данных, требовали высокой координации всех участников разработки, четких интерфейсов между подсистемами, модулями, компонентами. К тому же четкие сроки сдачи и бюджет. Никакой Agile и «коленочной» разработки быть не могло. Достаточно высокий уровень проектирования на основе технологий и методологий Oracle CDM/PJM, комплексное проектирование средствами Designer 2000. Проект был сделан, хотя и с напрягом, но в срок. Система была сдана и заработала на всю страну.
В 1999 и 2000 годах работал в Германии (в Кельне) в компании Telesens AG. Разрабатывали билингвою систему для Deutsche Telecom. Конечно, существенное проектирование было проведено – это системный анализ (требования) и детально прописана архитектура системы. Без детального проектирования объединить работу команд в разработку единой системы, с едиными замыслами и идеями, обеспечивающими конкурентные преимущества, было просто невозможно. В качестве инструментальных средств проектирования немцы использовали Rational Rose (UML). Меня назначили руководителем группы разработки – 4-5 человек (Team 4, я назывался группен ляйтер). Таких групп было – 4-5. Разрабатывали на С++ под Sun Solaris, БД Oracle. На уровне команд разработки были некоторые вольности. Некоторые команды только кодировали на основе информации из архитектурных документов, включающих UML и описания. Некоторые проводили детальный дизайн (проектирование) классов и компонент C++. Я, в своей команде решил делать так (используя тот-же Rational Rose). Полностью занялся проектированием классов и компонент. Программисты получали описания классов, методов, алгоритмов, реализующих методы.
В итоге – команды, где часть разработчиков (1-2 человека) занималась проектированием разрабатывала модули быстрее, качественнее (по результатам тестирования), предсказуемее (меньше рисков по срокам), чем команды, в которых все программировали.
Дополнительные плюсы у команд с проектированием – когда поручили документировать разработку – у нас уже все было (генерируемая документация), высокая взаимозаменяемость разработчиков, быстрое вхождение, кроме разработчика информацию о классах, компонентах модулях имеет проектировщик (как устроен модуль, какие компоненты, классы, интерфейсы, алгоритмы, объекты данных).
Другие важные аспекты технологии – комплексное управление конфигурациями и изменениями (Rational Clear Case, Clear Quest).
Как результат, комплексная биллинговая система была сделана в срок.
Далее вернулся и работал в Москве в Британской компании Protek LLC – разработка биллинговых систем. Проектирование при разработке конкурентных систем- продуктов – самая важная вещь. Это и тщательный анализ требований (системный анализ) для выявления важных для потребителей инновационных возможностей. Это инновационная архитектура, покрывающая функциональные и нефункциональные требования. Итеративный подход к разработке (в том числе Agile методологии) требуют быструю демонстрацию результатов и обратную «связь» от потенциальных заказчиков и заинтересованных лиц. На начальных, но самых важных при разработке программно-аппаратных продуктов этапах, модели систем (модели бизнес-процессов, требований, архитектур) являются самыми важными результатами – по сути прототипами системы, наряду с программными прототипами. Проектные документы (включая модели) обсуждаются между аналитиками, архитекторами, потенциальными заказчиками (в части покрытия бизнес-процессов и новых возможностей). Доказывать эффективность тех или иных решений всем заинтересованным участникам проекта необходимо до начала разработки, т.к. сколько-нибудь показательная разработка займет много времени и ресурсов, с очень высоким риском выброса в «корзину» как не эффективное решение. Использовался весь комплекс проектирования и инфраструктуры разработки Rational (включая Rational Rose UML).
Следующий, показательный момент – начало работы в компании ОАО АТС (Росэнерго) – 2004 год. ОАО АТС – Все-Российская оптовая биржа электроэнергии. Запускалась основная – биржевая система. Разработчики от субподрядной компании очень торопились, работали прямо по Agile – быстрые итерации с показом Заказчику (АТС), разумеется без какого-либо проектирования. И, кстати, сдали вовремя, биржа заработала. Далее надо было перенять их разработку для сопровождения и развития собственными силами (ИТ департамент 150 человек, включая программистов, аналитиков, службу эксплуатации, ….). Мне, и еще 2-м программистам поручили разобраться и взять на сопровождение. Срок – 3 месяца. Тут я впервые столкнулся с результатом Agile. Сопровождать систему мог только один человек – автор системы (от субподрядчика). Это был очень гениальный и эффективный человек (без кавычек) – раз мог такое сопровождать и развивать. Полагаю он мог перемножать 10ти значные числа в уме за несколько секунд, брать корни логарифмы больших чисел, и.т.д. Архитектура была проста (не вдаваясь в технологию разработки) – по сути это был один гигантский модуль, даже, можно сказать, одна процедура. Передача управления между частями через операторы «go to», все переменные глобальные, система много поточная (multi thread), потоки начинались и заканчивались в произвольных местах программы. Короче – «ужас», не для «слабонервных». В будущем еще не раз похожие вещи встречал в Agile командах.
Я, с коллегами, начали реинжиниринг системы, включая вычленение логической структуры, модели процессов, модели данных, модели системных требований с взаимной привязкой всех элементов проектирования. Делалось в Rational Rose по многопользовательской технологии с версионированием. За 3 месяца мы выполнили реинжиниринг и, как результат были в состоянии сопровождать систему, еще в течение 2-х месяцев система полностью была передана на сопровождение в ОАО АТС. Вскоре ее заново спроектировали и реализовали – систематично, архитектурно – как надо.
Следующий, показательный момент из недавнего прошлого. Это ИТ подразделение одной из крупнейших телекоммуникационных компаний России (может самая крупная), часто в рекламе на ТВ. Разработка новой единой биллинговой системы компании. Большая разработка – порядка 3-4 лет, задействовано порядка 100 человек, ежегодная стоимость - миллиарды. Методология Agile на основе Scrum. Проектирование тоже имеет место, и существенное. Есть аналитики, архитекторы, интеграторы, …. Есть технология проектирования на основе Sparx Enterprise Architect.
Проблема – влияние Agile на проектирование и разработку системы. Agile не предполагает глубокого анализа требований и проектирования архитектуры. Сразу в «бой» по задачам из backlog. Ни аналитики, ни архитекторы не «осознали» системы в целом – начали решать текущие задачи в не осознанной, не оптимальной последовательности. Результат:
• Решение отдельных задач – программные «заплатки»;
• Очень низкая степень повторного использования кода – нет часто используемых общих компонент;
• Разные команды разработки (и проектирования) реализуют похожие задачи.
Результат – провал и закрытие проекта после нескольких лет работы.
Ответ: mad_nazgul,

Если схема уже отработана, и все знают, что они хотят, то всё просто. Разворачивается готовое решение, настраивается и всё. Если надо делать что-то не стандартное, то дело уже сложнее. Народ начинает чесать репу и что-то проектировать. Если что-то не стандартное настолько, что даже заказчик не понимает как оно должно работать, то тут уже ничего не поможет.
Вот, например, я делаю расчёты для жкх и тут изменение требований на ходу - это не какая-то придурь заказчика, а объективная реальность отечественного законодательства в которой приходится работать. Тут проектирование в принципе не работает. Сделаешь все по красоте, завтра придумают закон, который всё сломает.
Вопрос: Использование архитектурных шаблонов в проектировании систем

Существенной частью проектирования программно-аппаратных систем является архитектурное проектирование (наяду, например, с бизнес-анализом, системным-анализом, дизайном, …).
Наверное, для маленьких систем (на неделю-месяц человеко-дней) архитектурное проектирование не существенно. Также для небольших доработок существующих систем. Для средних и больших систем – только осознанная и проработанная архитектура дает шанс на успех проекта (примеры в статье о ). Архитектура программно-аппаратных систем – большая и сложная наука, много исследований, книг, публикаций. Множество серьезных комплексных методологий-стандартов (например, ), продвигаемых крупнейшими «игроками» в области разработки систем. Архитектура программно-аппаратных систем включает в себя множество аспектов (зачастую взаимосвязанных), включая моделирование, управление архитектурным репозиторием, обеспечение качества архитектуры, обеспечение повторного использования компонент и решений, использование архитектурных шаблонов и фреймворков, и.т.д.
В данной публикации хочу вкратце поделиться личным опытом и пониманием некоторых аспектов использования распространенных архитектурных шаблонов и фреймворков.
Конечно, начальные знания по архитектурным шаблонам отражены в публикациях по базовым (элементарным) архитектурным шаблонам (на основе элементарных шаблонов создается комплексные шаблоны и их реализации - фреймворки). Типичный и наиболее распространенный набор элементарных архитектурных шаблонов – шаблоны .
В публикации хочу обратить внимание не на базовые шаблоны, а на часто используемые шаблоны более высокого уровня, образующие инфраструктуру многих современных программно-аппаратных систем, такие как:
 Использование динамически расширяемых структур данных, основанных на метаданных (описаниях структур данных);
 Концепция сервисных шин (ESB – Enterprise Service Bus);
 Концепция сценариев выполнения (WFM – Work Flow Management);
 Концепция управления правилами обработки данных (Rule Based systems);
 Концепция встроенных бизнес и системно-ориентированных языков описания сценариев и правил обработки данных;
В перспективе:
 Использование технологий «искусственного» интеллекта;
 ETL;
 Другие

Использование динамически расширяемых структур данных, основанных на метаданных.

Есть два крайних противоречивых подхода в разработке и проектировании баз данных (на самом деле более чем два, но хочу обратить внимание на эти):
- Жесткая (статическая) структуризация данных (на основе реляционных БД, например Oracle DB, PostgreSQL);
- Динамические структуры данных при отсутствии каких-либо схем – описаний структур (базы данных неструктурированных документов, например, MongoDB, Influx)

Жесткая структуризация данных. Типично для разработчиков использующих реляционные базы данных. Основа подхода – все структуры, включая типы объектов, атрибуты типов объектов (с типами данных), связи между типами объектов. В принципе, неплохой подход, но имеет существенный недостаток - добавление или изменение типов объектов данных системы требует участия программистов-разработчиков. Это приводит к следующим проблемам:
 Удорожание и замедление процессов развития систем (любое добавление или изменение типов данных требует участия программистов разработчиков).
 Практически невозможно использовать такой подход если от системы требуется возможность для пользователей динамически создавать типы объектов данных.
Мое видение – для крупных и среднего масштаба систем использовать комбинацию статических структур данных (конечно, «квазистатических», изменяемых разработчиками), и динамических, основанных на мета описаниях, позволяющих вносить изменения в структуры администраторам системы, даже простым пользователям.
Такой подход часто используется в ИТ индустрии, хотя часто встречает жесткое сопротивление апологетов жесткого (статического) структурирования. Основные вопросы:
 Неуправляемая структура повышает риски сбоев системы;
 Существенное понижение производительности систем и времени реакции на действия пользователя из-за сложности динамической индексации новых типов данных.
Эти вопросы в большинстве случаев решаются на уровне логики системы и приемов быстрой работы с динамическими данными. Структура остается управляемой в связи с наличием описаний новых типов данных (метаданные).
Успешный пример – широко используемая система JIRA. В основе – динамические объекты. Пользователи могут создавать новые объекты данных, экранные формы ввода новых типов данных, правила обработки, сценарии обработки новых типов данных. Внутренняя структура динамических объектов – 4 таблицы реляционной БД: описание типов объектов, описание атрибутов типов объектов, экземпляров объектов, экземпляров (значений) атрибутов объектов. С учетом механизмов управления типами данных, заложенных в систему и механизмов обеспечения быстрой работы с динамическими объектами, система работает быстро и надежно (мне приходилось работать с ней на всех уровнях, включая программном).
Другие примеры из жизни (в ИТ) до сих подтверждали эффективность такого подхода.
Динамические структуры данных при отсутствии каких-либо схем (описаний структур) вызывают у меня большое опасение. Это очень похоже на «коленочную» быструю разработку – что-то «сбацать», а там трава не расти. Особенно в тех областях, где требуется точный результат. Примерный результат, типа может объект нашел по атрибутам, а может не нашел, а может атрибуты не так называются или еще что, не везде проходит, в большинстве случаев не годиться, хотя, возможно, применим при обработке BigData – надо подумать.

Концепция сервисных шин (ESB – Enterprise Service Bus)

В начале 2010х годов – модное направление, сейчас несколько стихло. Основная идея – унификация коммуникаций программно-аппаратных компонент внутри систем, а также между внутренними компонентами системы и внешними системами, компонентами, системными сервисами, также предоставления внешним системам (потребителям) сервисов на основе стабильных программных интерфейсов. Дополнительная возможность – обеспечение масштабируемости систем посредством балансировки нагрузки по экземплярам используемых сервисов.
Появились фреймворки, реализующие архитектурный шаблон ESB (IBM Integration Bus, Microsoft Azure Service Bus, Mule ESB, Oracle Enterprise Service Bus, …).
Сталкивался с использованием такого рода фреймворков в разработке системы для Министерства Финансов РФ компании ФОРС совместно с другими партнерами. В дальнейшем участвовал в подобных разработках в качестве одного из системных интеграторов в одной из крупнейших телекоммуникационных компаний РФ.
Основная проблема использования таких технологий с моей точки зрения - отсутствие системного подхода к разработке программных интерфейсов. Необходимо на начальных этапах проектирования и разработки систем прорабатывать унифицированные (минимизация и универсализация), гибкие и расширяемые программные интерфейсы. Отсутствие такой проработки часто это является следствием Agile подходов к разработке систем (см. ). В реальности часто получается, что для интеграции нового модуля с каким-либо сервисом, в среде фреймворка ESB разрабатывается новый интерфейс, по сути, новая программа. Часто в логику программы-интерфейса вносится бизнес логика самой системы, забывая, что назначение ESB – трансформация протоколов обмена данными и форматов данных (хочется вспомнить басню про обезьяну и очки). В итоге – большое количество интерфейсов, плохо контролируемые интерфейсы (что они делают, какую логику, в том числе бизнес-логику включают), удорожается и усложняется разработка системы в целом – дополнительный фреймворк, отдельные типы разработчиков, отдельный объект сопровождения.
Жаль, а идея ESB очень хорошая. В предоставляемых фреймворках (даже бесплатных, типа Mule ESB) заложено большое количество средств для трансформации протоколов, форматов, возможность настройки протоколов и форматов (а также внесения изменений) без программирования вообще (администраторами), подключения унифицированных «заглушек» и эмуляторов системных сервисов и компонент – все для снижения стоимости разработки систем, сокращению сроков выпусков, повышению гибкости, возможности динамического показа разных вариантов реализаций, включающих динамическое подключение разных видов и версий компонент и сервисов.

Концепция сценариев выполнения (WFM – Work Flow Management)

Модное направление с начала 2000х годов. Сейчас страсти утихают. Основная идея – вывести часто изменяемую часть процессов обработки данных в подсистему (фреймворк), позволяющую настраивать процессы без программирования, динамически, быстро вносить изменения в сценарии обработки данных с учетом часто меняющихся структур обрабатываемых объектов данных (учитывая, что сценарии обработки данных, бизнес транзакции могут иметь большую протяжённость по времени). Дополнительно фреймворки такого типа должны обеспечивать устойчивость работы системы в целом, быстрое восстановление после сбоев без «потерь», масштабирование систем, автоматическое журналирование процессов, возможность мониторинга процессов обработки данных.
Приходилось интенсивно использовать такой фреймворк в качестве интегратора в одной из крупнейших телекоммуникационных компаний РФ при разработке комплексной системы класса OSS/BSS (поддержка операций и бизнеса). Основные проблемы:
 Недостаточная проработка и унификация интерфейсов используемых в сценариях программных компонент и сервисов приводит к большим затратам труда разработчиков на сопряжение WFM фреймворка с компонентами и сервисами. Часто WFM берет на себя функции ESB. Возникает непонимание – где между ними граница.
 Непонимание – что надо делать в сценариях WFM, что в hardcoded программных компонентах.
 Процесс разработки сценариев WFM сильно заорганизован. В результате непонятно, что делать быстрее – разработать (или изменить) сценарий для WFM или «захардкодить» сценарий в программном компоненте (и вносить изменения в компонент).
Причина проблем, на мой взгляд, похожа на ситуацию с ESB – Agile подход (см. ) – сначала делай, потом думай.
Как результат – большой эффективности от применения WFM не было, скорее удорожало систему в целом, т.к. необходимо поддерживать еще один фреймворк и соответствующих специалистов.
Очень жаль. Фреймворк потенциально может принести очень большой эффект. Бизнес задач, для которых подходит данный фреймворк – очень много, если не большинство.

Концепция управления правилами обработки данных (Rule Based systems, BRMS)

В начале 2000х годов концепция стала активно развиваться, потом утихла. Основная идея – похожа на идею WFM - вывести часто изменяемые правила обработки данных в подсистему (фреймворк), позволяющую добавлять и изменять правила обработки данных без программирования, динамически, быстро вносить изменения в правила обработки данных с учетом часто меняющихся структур обрабатываемых объектов данных. В отличие от сценариев WFM правила выполняются не последовательно, а, в общем случае, в произвольном порядке. Система сама определяет, какие правила применять к объектам данных в зависимости от параметров объектов и параметрам других, логически связанных объектов. Подобные фреймворки часто называют экспертными системами, системами управления знаниями, а динамически расширяемые наборы правил – базами знаний. Часто такие системы относят к классу систем «искусственного» интеллекта, учитывая, что системы такого типа могут выполнять не только простые, одноступенчатые обработки данных, но и порождать новые объекты данных, к которым применяются другие правила, т.е цепочки выводов. Некоторые из них поддерживают и «обратные» цепочки выводов – когда по полученному «результирующему» объекту система (фреймворк), пытается применить правила в «обратном» порядке для определения, что же могло привести к такому результату.
Фреймворков такого типа много, например ILOG JRules, JBoss Drools
В начале 2000х в компании по разработке биллинговых систем для телекоммуникационных компаний Protek LLC (Британская компания в Москве), участвовал в попытке использовать ILOG Rules для ввода проектировщиками тарифных моделей правил обработки объектов данных по фактам предоставления телекоммуникационных услуг и далее использования этих правил для обработки входящих объектов данных. Не считаю, что это была хорошая идея, но такая тенденция была в то время в среде некоторых западных компаний-разработчиков биллинговых систем. По моим представлениям, обработка биллинговых объектов – скорее сценарий, чем набор правил.
Однако идея очень хорошая. К сожалению, в явном виде мало применяется, при том, что во многих, если не большинстве систем, с которыми приходилось сталкиваться, элементы такой функциональности используются (иногда очень существенно), но реализуются собственными силами разработчиков, без использования готовых, развитых, отработанных фреймворков.

Концепция встроенных бизнес и системно-ориентированных языков описания сценариев и правил обработки данных

Идея использования встроенных в систему бизнес ориентированных языков программирования используется давно и довольно успешно. Развитые системы, типа 1С, SAP R3 такой подход применяют.
Изначально предполагалось создавать высокоуровневые языки программирования для динамического расширения функциональности программных систем самими пользователями, которые могли добавлять свои сценарии и правила обработки данных. К сожалению, по моему мнению, со временем эти языки превратились из высокоуровневых бизнес ориентированных в полноценные языки практически общего назначения, с которыми уже не могут работать обычные бизнес пользователи, даже продвинутые, зато зародился отдельный класс программистов. Можно было не создавать новых языков программирования, а просто предоставить библиотеки процедур обработки бизнес данных для использования обычными программистами на обычных широко используемых языках программирования.
Хорошо если высокоуровневые языки программирования предоставляют пользовательский интерфейс для ввода сценариев обработки объектов данных и формул расчета, позволяющий создавать программы (скрипты) конечными пользователями без программирования. Затем эти скрипты сохраняются и используются (интерпретируются) системой при обработке объектов данных.
Я участвовал в такой разработке - биллинговая система для Deutche Telecom во время моей работы в компании Telesens AG в Германии (Кёльн 1999-2000г). Идея и реализация были очень успешными. Основные аспекты:
 Высокоуровневый язык описания тарифных планов, включающий формулы и условия (варианты - разветвления) по обработке первичной информации по предоставленным телекоммуникационным услугам;
 Экранные формы ввода элементов языковых конструкций, позволяющий бизнес пользователям самостоятельно разрабатывать тарифные планы без программирования (хотя язык программирования тоже был доступен);
 Использование автоматизированных средств генерации интерпретаторов и компиляторов языков по их формализованному описанию (например BNF – Бекусовские нормальные формы).
Кстати, проектирование бизнес ориентированных языков, создание интерпретаторов и компиляторов, что часто пугает разработчиков, на самом деле очень просто. Средства, которые мы тогда использовали типа YACC делала этот процесс очень простым. В последствии я использовал для этих целей JavaCC (для разработчиков на языке Java) – тоже очень просто, быстро и эффективно.
Пока все, надеюсь будет продолжение (если будет интерес).
Буду благодарен за замечания и предложения.
Ответ:
Дмитрий Морочко

Использование динамически расширяемых структур данных, основанных на метаданных.


Как оказалось, это надуманная проблема.
Т.к. что NoSQL, что SQL БД используют используют динамически расширяемые структуры данных.
Тут вопрос в стоит в "типизации". NoSQL предлагает динамическую типизацию, в то время как SQL статическую.
Отсюда все плюсы и минусы систем.
Но сейчас все склоняются что "статика" лучше "динамики" и происходит ренессанс SQL.

Дмитрий Морочко

Концепция сервисных шин (ESB – Enterprise Service Bus)


Мертворожденная концепция, взятая из электроники.
Проблема систем ESB в том, что оно не нужно.
Все функции которые декларирует ESB уже делает internet/intranet.
Причем это настолько унифицированно и стандартизировано, что никто ее не чувствует.
Грубо говоря мы сейчас можем подключить без проблем любое устройство и сервис и получать и принимать с него данные.
При этом "специального ПО" не нужно. Точнее, оно давно есть и работает.
Все внедренные ESB обычно "оказываются пятой ногой". Т.е. как бы есть и работает, но сильно мешает.
Усложняет систему и уменьшает надежность.
Сейчас все ориентируются на брокеры сообщений. Которые решают задачу асинхронной передачи данных.


Дмитрий Морочко

Концепция сценариев выполнения (WFM – Work Flow Management)


Обычно внедряются под лозунгом "программисты не нужны"...
Потом либо нанимается куча программистов, которые бы рисовали программы, либо выпиливаются за ненадобностью.


Дмитрий Морочко

Концепция управления правилами обработки данных (Rule Based systems, BRMS)


Аналогично выше. Программист нужен, а программистам проще писать на знакомом модном ЯП, чем изучать "птичий язык" с ограниченной применимостью.

Дмитрий Морочко

Концепция встроенных бизнес и системно-ориентированных языков описания сценариев и правил обработки данных


Худо-бедно работает, если этим озаботился вендор.
Но это накладывает кучу ограничений, в т.ч. монолитная архитектура и система как "любимец".
От монолитов сейчас стараются избавиться.
А писать свой DSL, по свою микросеврисную архитектуру - дорого.
Для этого нужны очень хорошие архитекторы-программисты.
Вопрос: Проектированием модели БД в ERWin

Доброго времени суток люди добрые =) Сделал я значит концептуальную модель БД для транспортной компании и чувствую, что то с ней не так. Есть моменты моменты которые не знаю как реализовать.
1. У нас есть клиенты юр. и физ лица. стоит их разделять по сущьностям или можно в одной всех поместить?
2. Есть каталок услуг. цены на услуги могут меняться.. и я так полагаю что при изменении в моей модели цены в каталоге то и изменится сумма выполненных заказов до изменения цены. Как это решить ?
Скрин диаграммы и сам файл. Очень прошу помочь!


Всем добра!
Ответ:
Сообщение от Fason
Но в таком случае сущьность "Прайс-лист" никакой роли играть не будет, разве нет ?
Будет конечно: без него цену было бы неизвестно, какую ставить, пришлось бы вводить руками. А я вам предлагаю ее программно копировать. Пользователь выбирает товар - программа копирует цену их прайса. Но не просто отображает на экране, а именно делает копию.
Вопрос: Выбор программы для ER-диаграммы

Всем привет, можете подсказать хорошую программу для создания ER-диаграммы? Пока остановился на IBM Rational Software Architect.
Ответ:
Slant-shadow
хорошую программу для создания ER-диаграммы?


если просто диаграмму, то этот подойдет, а если еще надо скрипты для создания/изменения БД делать, то однозначно Power Designer или Erwin.
Вопрос: Невозможно создать диаграмму БД.

Добрый день!

В Management Studio (2014, 2016) не могу создать диаграмму для базы. Пишет: "Попытка чтения или записи в защищенную память. Это часто свидетельствует о том, что другая память повреждена. (Microsoft.VisualStudio.OLE.Interop)".

Как пытался чинить: восстановил m.studio 2014 (12.0.2269.0) - мимо, поставил SQL Server Management Studio 13.0.900.73 - тоже мимо. Тут на форуме нашёл аналогичный вопрос, но без ответа.(

Что делал до этого. Не поставилась V.Studio Community 2015, поставил 2013. (До этого диаграммы создавались)
Ну не сносить же.

Подскажите как починить. (на счёт повреждения памяти сильно сомневаюсь)
Спасибо.

Да, в тех.подробностях выдаёт следующее:
------------------------------
Расположение программы:

в Microsoft.VisualStudio.OLE.Interop.IOleCommandTarget.QueryStatus(Guid& pguidCmdGroup, UInt32 cCmds, OLECMD[] prgCmds, IntPtr pCmdText)
в Microsoft.VisualStudio.Platform.WindowManagement.DocumentObjectSite.QueryStatus(Guid& pguidCmdGroup, UInt32 cCmds, OLECMD[] prgCmds, IntPtr pCmdText)
в Microsoft.VisualStudio.Platform.WindowManagement.WindowFrame.QueryStatus(Guid& pguidCmdGroup, UInt32 cCmds, OLECMD[] prgCmds, IntPtr pCmdText)
в Microsoft.Internal.VisualStudio.Shell.Interop.IVsTrackSelectionExPrivate.Register()
в Microsoft.VisualStudio.Platform.WindowManagement.WindowFrame.ConnectSelectionContext()
в Microsoft.VisualStudio.Platform.WindowManagement.WindowFrame.Activate()
в Microsoft.VisualStudio.Platform.WindowManagement.WindowManagerService.viewManager_ActiveViewChanged(Object sender, ActiveViewChangedEventArgs e)
в System.EventHandler`1.Invoke(Object sender, TEventArgs e)
в Microsoft.VisualStudio.PlatformUI.ExtensionMethods.RaiseEvent[TEventArgs](EventHandler`1 eventHandler, Object source, TEventArgs args)
в Microsoft.VisualStudio.PlatformUI.Shell.ViewManager.SetActiveView(View view, ActivationType type)
в Microsoft.VisualStudio.Platform.WindowManagement.WindowFrame.ShowInternal(ShowFlags showFlags)
в Microsoft.VisualStudio.Platform.WindowManagement.WindowFrame.<Show>b__26()
в Microsoft.VisualStudio.ErrorHandler.CallWithCOMConvention(Func`1 method)
в Microsoft.VisualStudio.Platform.WindowManagement.WindowFrame.Show()
в Microsoft.VisualStudio.Platform.WindowManagement.WindowFrame.MarshalingWindowFrame.<Microsoft.VisualStudio.Shell.Interop.IVsWindowFrame.Show>b__7a()
в Microsoft.VisualStudio.Shell.ThreadHelper.Invoke[TResult](Func`1 method)
в Microsoft.VisualStudio.Platform.WindowManagement.WindowFrame.MarshalingWindowFrame.Microsoft.VisualStudio.Shell.Interop.IVsWindowFrame.Show()
в Microsoft.SqlServer.Management.UI.VSIntegration.Editors.VirtualProject.CreateDesigner(Urn origUrn, DocumentType editorType, DocumentOptions aeOptions, IManagedConnection con, String fileName)
в Microsoft.SqlServer.Management.UI.VSIntegration.Editors.VirtualProject.Microsoft.SqlServer.Management.UI.VSIntegration.Editors.ISqlVirtualProject.CreateDesigner(Urn origUrn, DocumentType editorType, DocumentOptions aeOptions, IManagedConnection con, String fileName)
в Microsoft.SqlServer.Management.UI.VSIntegration.Editors.ISqlVirtualProject.CreateDesigner(Urn origUrn, DocumentType editorType, DocumentOptions aeOptions, IManagedConnection con, String fileName)
в Microsoft.SqlServer.Management.UI.VSIntegration.Editors.VsDocumentMenuItem.CreateDesignerWindow(IManagedConnection mc, DocumentOptions options)
в Microsoft.SqlServer.Management.UI.VSIntegration.Editors.VsDocumentMenuItem.InvokeDesigner(IManagedConnection connection)
в Microsoft.SqlServer.Management.UI.VSIntegration.Editors.VsDocumentMenuItem.Invoke()
в Microsoft.SqlServer.Management.UI.VSIntegration.ObjectExplorer.ToolsMenuItemBase.MenuInvokedHandler(Object sender, EventArgs args)

Microsoft SQL Server Management Studio 12.0.2269.0
Клиентские средства служб Microsoft Analysis Services 12.0.2000.8
Компоненты доступа к данным (MDAC) 10.0.10586.0
Microsoft MSXML 3.0 4.0 6.0
Microsoft Internet Explorer 9.11.10586.0
Microsoft .NET Framework 4.0.30319.42000
Операционная система 6.3.10586
Ответ:
Владислав Колосов
Поставьте фильтр по системным представлениям базы на имя depend.


Спасибо, понял. Буду думать как этими представлениями лучше воспользоваться.
(по привычке хочется из них диаграмму сделать, а там ПКМ и добавить связанные.)