Алексей Алексеев и Николай Гребнев рассказали, как при разработке бизнес-приложений в модели Domain-driven design они предупреждают ошибки программиста с помощью статического анализа кода и доменной модели. А именно: возможности ORM-платформы по статическому анализу, преимущества широкого использования Linq, декларативных ограничений, модель состояний и формальной верификации элементов доменной модели.
В чем заключается удобство разработчика по использованию статического анализа и простота применения механизмов для задания формальных ограничений на модель предметной области. Интеграция средств статического анализа ORM в среду разработки, невозможность игнорирования ошибок, гарантия прохождения всех статических проверок до первого запуска программы.
Ограниченные возможности запросов Linq к модели предметной области по сравнению с Linq to Objects и пути их преодоления.
Как обстоят дела с аналогичными механизмами в других ORM-системах и почему они решили реализовать собственную платформу для поддержки разработки в рамках DDD.
Вопрос из зала: «То есть вы сделали костыли для LINQ на CLR-свойствах?»
На следующий день докладчик, рассказывавший про статический анализ, сказал, что мы не анализируем код, хотя пример с расширениями LINQ демонстрировал места, где мы влезаем и анализируем код.
Был правда человек, который много во что врубился, и задал много правильных вопросов, не зная ни C#, ни Model checking. Еще человек, не слушавший доклад, в коридоре попросил бегло повторить доклад).
Доклад вроде бы понравился нашим.
Итого: надо работать надо последовательностью изложения. Еще для выступления на SECR сделать попсовее, там-то точно не поймут.
Предупреждение ошибок программиста с помощью статического анализа кода и доменной модели (Алексей Алексеев и Николай Гребнев на ADD-2010)
Это был наш доклад. Выступили вроде хорошо.
Были прикольные вопросы типа перекрытия оператора равенства в linq-запросах или костылях на CLR-свойствах.
К SECR доклад надо будет упростить и оживить, поднапедалить туда побольше графиков и диаграмм, а также добавить обоснование эффективности использования специального фреймворка для DDD.
Предупреждение ошибок программиста с помощью статического анализа кода и доменной модели (Алексей Алексеев и Николай Гребнев на ADD-2010)
По сравнению с первым прогоном на нашей демонстрации прогресс был просто огромный. Доклад прошел практически без накладок. Единственное, что Леша забыл рассказать, как структура Крипке разворачивается в бесконечное дерево, поэтому дальше народ немного перестал понимать суть, но те кто понял — прониклись. Недостатком было, что рассказывали про абстрактный «наш фреймворк» без ссылок, где он выложен в OpenSource. К SECR-у если его уже не выложим, будет совсем глупо.
Предупреждение ошибок программиста с помощью статического анализа кода и доменной модели (Алексей Алексеев и Николай Гребнев на ADD-2010)
Доклад Леши Алексеева и Коли Гребнева про наш CIS Uni.Net. Ребята волновались, где-то затягивали изложение, где-то, наоборот, слишком ужимали. Ну, как говорится, первый блин комом, а дальше будет лучше.
В целом мне понравилась практика доклада вдвоем. Представление о предмете получается более объемное, один докладчик при случае может поддержать второго.
Что касается собственно фреймворка, то, кажется, люди не слишком хорошо поняли, что же он из себя представляет. Это не очень удивительно – с этим докладом мы зашли сильно «сбоку», фреймворка целиком не было видно. Зато людям немножко вынесли мозг структурами Крипке, формулами темпоральной логики, и они ходили под впечатлением: «Ух ты! У CUSTIS есть фреймворк для статической проверки кода!». Интересно еще узнать, что люди пишут (если пишут) в блогах по поводу этого докалада.
А может, так и делать? У меня даже возникла идея следующего доклада «сбоку» - про систему прав в CIS-Uni.Net на основе ролей и предикатов.
Предупреждение ошибок программиста с помощью статического анализа кода и доменной модели (Алексей Алексеев и Николай Гребнев на ADD-2010)
Рассказывали Алексей Алексеев и Николай Гребнев.
Докладчики говорили о роли человеческого фактора в разработке ПО и средствах для уменьшения стоимости исправления ошибок в коде. Были перечислены основные этапы жизненного цикла приложения в контексте стоимости исправления ошибок на каждом из них. Статическая верификация кода обеспечивает скорейшее выявление ошибок на этапе компиляции.
Далее докладчики рассказали о CustIS Uni.Net. Было продемонстрировано использование CustIS Uni.Net для построения domain model. Отдельно было сказано о возможности использования работы с объектами доменной модели при помощи LINQ.
После этого было продемонстрировано использование атрибутов для декларативного описания ограничений возможных состояния объекта доменной модели и переходов между состояниями.
Немного рассказали про Сomputation tree logic и возможности последней версии CustIS Uni.net, в частности возможность программной верификации метамодели с помощью CTL.
Общее впечатление — было интересно. Несмотря на то, что имею опыт работы с CustIS Uni.net, некоторые вещи были для меня в новинку (ограничения состояний, верификация метамодели с помощью CTL).
Сложилось впечатление, что доклад перегружен, Linq там было лишним. Вместо этого стоило четче рассказать про состояния и проверки: у слушателей сложились непонятки по поводу того, какие проверки compile-time, а какие run-time.
Предупреждение ошибок программиста с помощью статического анализа кода и доменной модели (Алексей Алексеев и Николай Гребнев на ADD-2010)
Алексей Алексеев, Николай Гребнев
Докладывались наши парни, по сути ничего не буду писать, можно их здесь опросить в любое время. По форме. Материал, на котором базировался доклад был очень достойный, чувствовалась реальная работа за плечами. В конце вопросов народ назадавал, как ни у кого другого. Но доклад был не самый зажигательный, чувствовался недостаток опыта у выступающих. Подслушал случайно одного из посетителей конференции на следующий день, про этот доклад он говорил так: «много кода, маленькие буквы, ничего не понятно».
Внимание! Данная статья выбрана для репликации во внешнюю базу знаний компании. Пожалуйста, не допускайте в этой статье публикацию конфиденциальной информации, ведения обсуждений в теле статьи, и более ответственно относитесь к качеству самой статьи — проверяйте орфографию, пишите по-русски, избегайте непроверенной вами информации.
