Лучший способ смоделировать домен вместе с экспертом по домену

Question

Я провел немало анализа и использовал ряд инструментов для сбора требований: созданные пользователем раскадровки, варианты использования, чертежи графического интерфейса пользователя, прототипы графического интерфейса пользователя, пользовательские истории и сценарии, которые можно использовать в качестве критериев приемлемости и т. Д.*

Хотя у каждого из них есть более или менее достоинства, я думаю, что здесь упущен один важный бит.Эти методы могут точно определить, как пользователь взаимодействует с вашим приложением, но программист должен создать и разработать «модель», которая должна быть отражена в коде.

Я недавно читал DDD Эвана , и он предлагает что-то другое.Вам необходимо создать модель домена вместе с экспертом домена и поделиться им с ним.Чтобы поделиться идеями с пользователем, в книге он часто использует специальные рисунки, вдохновленные UML.

Интересно, это лучший способ поговорить о модели с экспертом по предметной области?Есть ли какие-либо другие инструменты, помимо диаграмм UML, которые вы могли бы использовать для сбора знаний о предметной области и их использования во время обсуждения предметной области с экспертом по предметной области?

Answer 1

Хотя окончательная абстракция в модель рабочего домена (и, в конечном счете, стабильную модель) принадлежит вам, работе разработчика, я согласен с тем, что даже набор вышеперечисленных инструментов может ограничивать и ограничивать вас или ваши сообщения только UMLможет сделать разговор эзотерическим для эксперта по домену.

Для системной анатомии попробуйте инструменты для обозначения блок-схемы в http://www.fmc -modeling.org / .

для белых/ blackboarding и mind-mapping попробуйте FreeMind

Для ассоциативной организации (и крутости) попробуйте TheBrain

Для более быстрого / совместного построения графиков (вроде нового) попробуйте LucidChart

ИКонечно, добрый старый словарь и тезаурус, чтобы всегда, всегда стремиться к лучшей терминологии.

Если они кажутся вам правильными, помните, что моделирование - это анализ левого мозга, выполненный однимпартия от имени двоих.Вы не получите столько же от чисто определенного линейного процесса, сколько от случая, когда он связан с пробным и безошибочным извлечением информации в свободном режиме.

Answer 2

Специалисты по доменам склонны понимать предложения лучше, чем что-либо еще. Вот почему мне нравится Object-Role Modeling . Большая часть разработки связана с графическими методами, но на практике я считаю, что лучше всего использовать просто структурированные предложения.

Answer 3

Существуют потери / т инструментов, которые вы можете использовать:

• Карта актера
• Актёрский стол
• Деловая политика
• Бизнес-правила
• Контекстная диаграмма
• Таблица решений или Дерево решений
• Модель домена
• Таблица событий
• Карта процесса
• Сценарии
• Диаграммы состояний
• Варианты использования
• Карты разума
• ..

Есть так много длинных и скучных книг о каждой из них. И некоторые инструменты работают в одном контексте «лучше» и «могут потерпеть неудачу» в других. Нет ничего лучше «ЛУЧШЕГО»: контекст имеет значение.

Но важна не сама техника : Важная вещь - как вы их применяете ... .

Хитрость заключается в том, как "сотрудничать" с экспертами в области клиентов и конечными пользователями. Совместные семинары, как правило, лучше всего подходят для многих случаев Следующая книга хорошо справляется с этой задачей.

Требования к сотрудничеству: семинары по определению потребностей, Эллен Gottesdiener

Чек http://ebgconsulting.com/facassets.php

Но будьте осторожны НЕ БУДЬТЕ ШАБЛОНОМ ЗОМБИ [что является общим заболеванием в области требований]

И вы можете использовать даже игры для улучшения совместной работы:

Инновационные игры: создание революционных продуктов с помощью совместной работы Play, Люк Хоман

Answer 4

Лучший способ - карандаш и бумага. UML и то, что не придет после этого. Начните с DSL (список словарного запаса, который используется при разговоре о домене). Затем вы можете использовать этот список, чтобы определить, что есть на самом деле (модель, агрегат, действие [глагол] и т. Д.), После чего вы можете делать ассоциации.

После всего этого сделайте ваши UML-диаграммы и обратитесь к эксперту по доменам. Если они это понимают, значит ты золотой.

Эта книга посвящена тому, что я делал. Я рекомендую хотя бы просмотреть эту книгу (на самом деле я не знаю, используете ли вы .NET). http://www.amazon.com/Professional-Refactoring-ASP-NET-Wrox-Programmer/dp/047043452X/ref=sr_1_1?s=books&ie=UTF8&qid=1306529986&sr=1-1

Answer 5

Для меня это зависит от эксперта домена.

Для некоторых это вопрос рисования пользовательского интерфейса на доске, показывающий, как он будет выглядеть на экране, а затем вопросы типа: «Может ли этот существовать без этого?», «У вас есть ситуации?, где этот впервые добавляется позже, или они всегда там "," Какой порядок вы бы предпочли, чтобы они были выполнены? "," Кому нужно знать, что с этого экрана? "... Обычно,Визуальная помощь помогает им попасть в ситуацию, когда они действительно могут очень точно ответить на ваши вопросы.

Другие, я могу использовать наивный UML (показывая агрегаты, значения типов, свойства и коллекции), и они в порядке с этим.

Действительно, для меня это довольно просто, я начинаю с простого - продолжайте добавлять технические вещи, пока они не исчезнут в их глазах - затем сделайте один шаг назад.И всегда иметь какую-то исходную позицию, чтобы творческие соки текли.Если вы застряли, просто посмотрите, как они работают - «Подожди-ка, почему ты не записал эту информацию?», «Ух ты, что ты там делал?»- для меня, инструменты существуют только для того, чтобы помочь мне, они редко помогают эксперту в области.

В основном, знания разбираются практически без инструментов, кроме ручки и бумаги (и доски, если возможно).

Answer 6

Есть много хороших предложений для инструментов.Попробуйте их и используйте те, которые вам нравятся, но ключом к успеху является итерация между кодом и диалогом ... то, что Эванс называет хрущем знания .Чем больше вы слушаете экспертов по предметной области, моделируете то, что слышите в коде, затем показываете им программное обеспечение, получаете отзывы и настраиваете модель, тем ближе вы подходите к программному обеспечению, которое решает проблему под рукой.

Answer 7

Лично я нахожу наиболее продуктивный способ просто сидеть и писать модель домена на лету, часто задавая вопросы да / нет эксперту по домену, который сидит рядом со мной. это работает, только если вы достаточно быстро работаете с кодированием.

---

Также - хорошо построенные (деревья должны читаться как предложения) карты разума на вездесущем языке - отличный способ общения. Легко создавать, делиться и понимать тоже.

Пример из реального мира:

Payment
    comments
        can be edited
            if user is authorized
                with role [Role]
    can be approved
        if user is authorized
        if payment is initiated
        if payment is not paid yet
        if amount does not exceed allowed budget
    when approved
        remembers that
        saves approving date
    can be rejected
        if something something...
    when rejected
        forgets planned pay date
        resets amount to be paid

(скопируйте с здесь , если вы хотите увидеть его в text2mindmap tool)

Это означает:

public class Payment{
    public virtual void EditComments(string comments){
        Authorize<EditPaymentComments>();
        CommentsEntered=true;
        CommentsEditedBy=User;
        CommentsEditedOn=SysDateTime.Now();
        Comments=comments;
    }
    public virtual void Approve(){
        EnsureCanBeApproved();
        IsApproved=true;
        ApprovedOn=SysDateTime.Now();
        Raise(new Approved(this));
    }
    protected virtual void EnsureCanBeApproved(){
        Authorize<AcceptPayments>();
        ThrowIf(!IsInitiated,
            "Payment is not initiated.");
        ThrowIf(IsPaid,
            "Payment is already paid.");
        ThrowIf(ExceedsAllowedBudget(ToBePaid),
            "Amount to be paid exceeds allowed budget.");
    }
    public virtual void Reject(){
        EnsureCanReject();
        ForgetPlannedPayDate();
        ToBePaid=0;
        IsInitiated=false;
        IsRejected=true;
        Raise(new Rejected(this));
    }
    private void ForgetPlannedPayDate(){
        Deadline=DateTime.MinValue;
        DeadlineKnown=false;
    }
}

Answer 8

Что я делаю, так это создаю диаграммы вариантов использования для требований.Я могу сохранить всю необходимую информацию на уровне модели.Моя диаграмма вариантов использования может спасти почти всю сложную необходимую систему, которую я должен смоделировать.

Я также могу повторно использовать один и тот же вариант использования в более чем одной диаграмме и при этом сохранить ее свойство.Действительно превосходная технология.

Относительно домена с UML я использую элемент case и диаграмму классов на одной и той же диаграмме, и все они добавляют профиль базы данных, который позволяет мне добавлять постоянство в мою диаграмму классов.Поэтому это объектное моделирование с использованием спецификаций базы данных.

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

Я пользуюсь им ежедневно и очень люблю это.Надеюсь, что это поможет.