Моделирование системы после определения варианта использования UML - PullRequest
1 голос
/ 30 апреля 2009

... что дальше?

После того, как вы определили, какие актеры делают какие действия, каким путем вы идете? Вы моделируете базу данных или предпочитаете начинать с классов?

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

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

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

Как вы справляетесь с этим? Когда вы решаете, стоит ли начинать с моделирования БД или классов, по вашему опыту, какой подход оказался естественным и чистым в реализации?

Заранее спасибо

Ответы [ 2 ]

2 голосов
/ 30 апреля 2009

Я успешно использовал Анализ надежности .

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

  1. Граничные объекты, которые актеры используют при общении с системой.
  2. Объекты Entity, которые обычно являются объектами из модели предметной области (предмет «Дизайн вождения: Проблемный домен ", январь 2001 г.).
  3. Объекты управления (которые мы обычно называем контроллерами, потому что они часто не являются реальными объектами), которые служить «клеем» между границей объекты и объекты сущности. Рисунок 1 показывает визуальные иконки для этих трех типы объектов.

Объекты-сущности - это те, которые (обычно) попадают в базу данных /

При отображении между классами и базой данных я бы порекомендовал Статья С.Лотта "Проблема ORM" (он также участник StackOverflow

1 голос
/ 30 апреля 2009

Если вы используете тестовую разработку, сначала напишите свои тесты. Ваши занятия будут обрисованы в общих чертах, как вы идете.

Вы можете разрабатывать свою бизнес-логику без базы данных (фиктивные или тупые объекты) или разрабатывать базу данных по мере проведения тестов.

Помните, что ваша база данных и модель домена не должны отображаться один на один.

...