2010-11-03 4 views
1

Я создаю систему инвентаризации с Ruby on Rails в качестве сервера приложений и имея java-клиенты в качестве интерфейса.Создание диаграммы классов для моделирования приложения MVC

Часть проекта предусматривает создание интегрированной диаграммы классов (диаграммы классов, которая включает все классы и показывает отношения). Способ, которым был разработан класс, и то, чему мы учили раньше, было использовать шаблон Boundary-Entity-Controller (BCE) для создания соответствующих классов, однако, поскольку мы используем Rails, который использует архитектуру MVC, они прямо противоречие, поскольку между двумя шаблонами нет корреляции 1: 1, особенно учитывая, что «взгляды» в нашем случае - это просто XML, поэтому диаграмма классов для представлений не будет и . Граница разделяет вход контроллера и выход вид.

До сих пор наша диаграмма классов просто связана с классами, связанными с Rails (поскольку классы клиентов в основном представляют собой только пользовательский интерфейс). Вот результат того, что мы сделали до сих пор (игнорируем тот факт, что у нас есть миллион геттеров и сеттеров - это требование для проекта, которого мы фактически не будем реализовывать таким образом, мы будем использовать attr_accessor) : nothing to see here....

Итак, мы на правильном пути? Что-нибудь добавить/отредактировать/переместить? Как точно мы правильно моделируем встроенные методы проверки ActiveRecord, которые мы будем использовать (например, validates_numericality_of :price)?

Любая помощь очень ценится! Благодарю.

ответ

0

Кажется, что вам дано несколько ограничений. Если я правильно ее понимаю, вы использовали BCE в анализе и MVC для архитектуры. В RUP для этих целей есть две модели - модель анализа и модель проектирования - оба выражены через диаграммы классов. Поэтому, если вы хотите показать, что вы использовали подход BCE, а также архитектуру MVC на одной чудовищной диаграмме, вы можете рисовать границы, элементы управления и объекты из анализа и ваши классы решений на основе RoR для проектирования и связывать их с использованием зависимостей с помощью <<trace>> стереотип.

Я не совсем уверен, как методы проверки достоверности реализованы в RoR, по моему мнению, когда вы вызываете метод validates ... в определении класса модели, конкретный класс модели расширяется посредством метапрограммирования с помощью нового частного метода, который будет служить обратным вызовом для фазы проверки. Я действительно не уверен в этом, но если это правда, и есть метапрограммирование, у вас есть проблема. AFAIK, вы можете либо нарисовать диаграмму, которая покажет классы после добавления методов (что-то вроде диаграммы объектов на уровне класса ...), либо вы можете смоделировать метапрограмму через слияние пакетов, что тоже непросто.

Смежные вопросы