2016-03-22 3 views
1

КонтекстКак создать диаграмму классов для SPA и REST API?

Я создал SPA (Single Application Page) вместе с REST API. Backbone.js использовался для разработки SPA, а Codeigniter использовался для реализации API REST на стороне сервера.

Вопрос

Для приложения MVC мы могли бы нарисовать единую диаграмму классов, как обычно. Но как создать диаграмму классов для системы с SPA и REST API? Создаете ли вы две отдельные диаграммы классов для каждого из приложений или одну диаграмму классов для обоих? Если есть одна диаграмма, какие отношения/ассоциации можно использовать для подключения API SPA и REST?

+0

Публикуйте три вопроса с тем же контекстом, пожалуйста. Включение нескольких вопросов в один из них считается очень плохой практикой. – Gangnus

+0

Если вы спрашиваете нас, как мы что-то делаем, вы пытались сделать это сами и иметь проблемы. Что вы пробовали? Какие проблемы у тебя? – Gangnus

+0

Привет @Gangnus Я создал две отдельные диаграммы классов для SPA и REST API, потому что я не мог найти правильную ассоциацию UML, чтобы показать соединение между этими двумя компонентами. . Модель BackBone Customer взаимодействует с CustomerController в codeigniter Поскольку между двумя вышеуказанными моделями нет прямой связи, и соединение происходит только через сетевой протокол, я думал оставить их отдельно. –

ответ

1

Как диаграммы классов для сервера и клиента могут быть организованы

  1. Диаграмма общий класс не имеет смысла, если компоненты не имеют общих классов.
  2. Очень вероятно, что у вас есть общие классы, потому что клиент и сервер работают с одними и теми же объектами реального мира и соответствующими классами, должны быть одинаковыми. И каждый такой класс должен иметь только одну реализацию кода. Поскольку эти общие классы будут принадлежать доменной зоне (методы, обычные для вашей темы), вы можете разделить их все на еще один пакет . Таким образом, у вас будут два пересекающихся компонента, но три непересекающихся пакета. Вы можете нарисовать эту примитивную диаграмму пакета.
  3. Если диаграммы классов компонентов большие, всегда делайте два (или более) из них, отмечая общие классы каким-то особым образом. (синий для классов, общих с компонентом A, красный для классов, общих с компонентом B ...).
  4. Диаграммы классов не предназначены для моделирования поведения, такого как вызов компонентов и вещей. Это был бы плохой стиль. Если вы все еще хотите написать о поведенческих деталях, важных для понимания, сделайте это в комментариях.
  5. Для моделирования поведенческих соединений компонентов используйте диаграммы связи или последовательности.
+0

Да, сопоставление клиентской модели с серверным контроллером, по-видимому, моделирует поведение в этом сценарии, что неверно на диаграмме классов. Спасибо. –

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