Tracing Designs - прослеживаемость от экрана к базе данных

Question

Это неопределенно связано с:

Должен ли я сначала разработать приложение или модель (базу данных)?

Проектирование от базы данных сначала до пользовательского интерфейса или наоборот?

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

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

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

В небольших проектах (нас всего 10 человек, но я часто работаю в командах из 3 или менее), я создал свои собственные пользовательские диаграммы, чтобы показать эту часть дизайна. Сортировка экрана, UML и таблицы базы данных, выполненная в Visio без ссылки на реальный код или SQL. Я не уверен, что это сработает для большой команды, так как она очень ручная, чтобы быть в курсе, и она не генерирует код автоматически, как это делает наш инструмент моделирования баз данных.

Есть какие-нибудь рекомендации? Есть ли общепринятый механизм для этого?

К вашему сведению - мы симпатичный водопад, который не изменится в ближайшее время. И мы любим артефакты ... Сказать «переключиться на гибкую» не является жизнеспособным решением для нашей группы.

Answer 1

Я не могу сказать по вашему вопросу, насколько детализированы ваши варианты использования. У меня складывается впечатление, что это могут быть случаи использования высокого уровня, не разбитые на подробные варианты использования (возможно, через включают или расширение отношений.

В любом случае, я предпочитаю начинать с Требований и отслеживать их для использования. В то время как я пишу сценарии использования и диаграммы вариантов использования, я также создаю модель предметной области (диаграмма классов высокого уровня). Это главным образом для того, чтобы дать мне кое-что обсудить с заинтересованными сторонами («Я правильно понял?»).

Когда варианты использования и модель предметной области закончены, можно начать работу над дизайном экрана, а также, возможно, и над моделью деятельности, если между экранами существуют сложные взаимодействия. Я бы относился к экранам как к классам с пользовательским интерфейсом - экран мог бы иметь атрибут FirstName, который я бы отметил как связанный с атрибутом FirstName сущности Person в моей модели домена. Тем не менее, атрибут FirstName может быть представлен на этом экране в виде текстового поля.

В то же время может происходить физическое проектирование базы данных. Это приведет к диаграмме класса или ER с возможностью отслеживания до модели предметной области. В конце концов, вы можете обнаружить, что некоторые из ваших атрибутов экрана или моделирования деятельности относятся к вещам, которые являются частью физической модели базы данных, которых нет в модели домена. Можно связать атрибут «PersonalName» экрана с вычисляемым столбцом PersonalName в таблице Person в схеме People.

Инструмент, который я использую для такого рода вещей, Sparx Enterprise Architect . Это отличный инструмент, и он может делать все это и даже больше, даже в профессиональной версии.

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

Answer 2

Я не уверен, что четко понимаю ваш вопрос, но постараюсь ответить на основании некоторых разумных предположений ...

По сути, моя рекомендация такая же, как и то, что Джон Сондерс уже предлагал: рассмотреть возможность использования UML вместе с хорошим инструментом UML. Но я хотел бы добавить несколько моментов, которые могут быть важны в вашей конкретной ситуации.

Прежде всего, я не думаю, что UML "слишком ориентирован на код". Наоборот, его можно использовать для моделирования практически любого аспекта программной системы, практически на любом уровне абстракции. С хорошим инструментом под рукой (например, Sparx EA), прелесть UML в том, что вы действительно получаете четко определенную модель под капотом (в отличие от просто набора несвязанных чертежей / диаграмм). В результате, даже если сам инструмент не дает вам функции, которую вы ищете (например, возможность отслеживания из БД в случаях использования) ... ну, по крайней мере, у вас есть возможность автоматизировать (или, по крайней мере, полуавтоматизировать) Задача самостоятельно: например, вы можете экспортировать свою модель UML в XMI (стандарт!) и затем извлечь из нее всю необходимую информацию о трассируемости (например, используя XSL или любую XML-библиотеку для вашего любимого языка программирования / скриптинга) , Я не говорю, что это было бы легко сделать (особенно если вы хотите прослеживаемость на уровне отдельных столбцов БД 8-), но это возможно, и очень вероятно, что он превзойдет любой ручной метод, если он будет масштабироваться по размеру проект.

Кстати, говоря о Sparx EA ... Я еще не знаю всех его возможностей, но их так много, что я бы не удивился, если бы он позволил вам выбрать класс (или даже атрибут класса). ) и покажет вам другие элементы модели, которые каким-то образом зависят от нее. Вы можете проверить это.

Сказав все это, я понимаю, что у вас могут быть по крайней мере следующие две важные проблемы относительно UML:

1. Может потребоваться слишком много деталей моделирования, чтобы получить желаемое.
2. Как и любой «универсальный инструмент», он может существенно уступать специализированным инструментам моделирования, которые вы уже используете.

Относительно проблемы # 1: Опять же, с хорошим инструментом UML под рукой, вы можете сделать столько ярлыков, сколько захотите. Например, вместо построения очень подробной и точной модели действий для варианта использования, вы могли бы сосредоточиться только на классах, включенных в вариант использования (достаточно, чтобы включить отслеживание классов обратно для вариантов использования). То же самое относится и к пользовательскому интерфейсу, конечно.

По вопросу № 2: я не знаю, какие именно инструменты вы используете сейчас для моделирования вариантов использования, пользовательского интерфейса и схемы БД. Таким образом, теоретически возможно, что все они настолько превосходят UML, что вы не захотите отказываться от них в обмен на более легкую отслеживаемость. Однако кое-что говорит мне, что ваш инструмент моделирования БД (с его возможностями генерации кода) может быть единственным, который действительно необходим. Если это так, то я все равно рекомендую рассмотреть использование UML: вы просто не моделируете до уровня схемы БД и не «останавливаетесь» на уровне модели предметной области (даже если у вас его нет в приложении!). На этом этапе инструмент UML предоставит вам возможность отслеживания от элементов модели домена (сущностей, их атрибутов и их отношений) до вариантов использования и элементов пользовательского интерфейса, а сопоставления между вашей моделью домена и схемой БД можно оставить «в воздухе» потому что, в подавляющем большинстве случаев, они должны быть достаточно простыми, чтобы отследить, ничего не рисуя. Это может не дать вам 100% того, что вы хотите, но это может дать вам 80%, что будет достаточно для решения большинства ваших проблем.

Итог: если вы используете три разных инструмента / технологии для моделирования трех разных аспектов вашей системы ... ну, очевидно, что любая прослеживаемость между этими тремя аспектами остается во власти этих трех инструментов: вы можете автоматизировать только настолько, насколько позволяют эти инструменты (что, вероятно, означает, что вы застрянете с большим количеством трудоемких ручных задач). На сегодняшний день UML является единственным четко определенным и широко поддерживаемым языком общения, который может помочь вам подключить ваши модели и позволить автоматизировать значительную часть вашей аналитической деятельности. Просто убедитесь, что вы отличаете UML "инструменты для рисования" (как и большинство надстроек и шаблонов Visio) от настоящих инструментов моделирования UML (таких как Sparx EA и многие другие).

Answer 3

База данных должна моделировать ваш проблемный домен. Он должен полностью смоделировать его, чтобы вы могли извлечь из него решения - истины. Плохой дизайн, по сути, «лжет» базе данных (допускает возможность неверных данных или отношений), и когда вы «врете» своей базе данных, она «лжет» вам, когда вы задаете ей вопросы.

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

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

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

Answer 4

Ваши варианты использования - хорошее место для начала.

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

• Чем меньше частей работы вы можно определить и проверить, тем более крепкий вы сможете построить Ваша заявка.

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

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

Как разработчик, найдите методы, инструменты и процессы, которые помогут вам выполнить свою работу наилучшим образом. Не судите их по их происхождению. Оцените их ценность, сделав вас лучшим разработчиком.

Некоторые предметы из проворного мира, безусловно, сильно повлияли на качество и производительность моей работы. Для этого не нужно выбрасывать корзину с яблоками и приводить в замешательство опытную команду водопада.