Проекты трассировки - экран для отслеживания базы данных

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

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

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

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

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

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

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

По сути, моя рекомендация такая же, как и то, что уже предлагал Джон Сондерс: рассмотреть возможность использования 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 и множество других).

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

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

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

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

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

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

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

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

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

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

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