Контракты на эксплуатацию системы Лармана - пример CRUD

Question

У меня есть некоторая путаница с применением системных контрактов операций Лармана (OO Analysis из книги «Применение UML и шаблонов») к CRUD-подобным операциям. Точнее, я запутался с постусловием.

Например, если у меня есть операции системы CRUD, выглядящие следующим образом:

createEmployee(employee:Employee), 
readEmployee(employeeId:int), 
updateEmployee(employee:Employee), 
deleteEmployee(employeeId:int)

каково будет постусловие, например, readEmployee системная операция или какая-либо другая операция, например searchEmployees и т. Д.?

Например: для операции чтения система должна прочитать запись из базы данных, создать экземпляр объекта домена, установить значения атрибутов для объекта домена (также установить отношения) и все. Означает ли это, что выше были упомянуты постусловия - создание экземпляра, изменения атрибутов и т. Д. Или операция чтения не имеет постусловия. Ничто из этого не звучит логично для меня.

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

Answer 1

Моя интерпретация контрактов Лармана всегда связана с моделью предметной области.Ларман четко заявляет, что существует только 5 типов почтовых условий:

1. Создание экземпляра
2. Удаление экземпляра
3. Изменение атрибута значения.
4. Сформированы ассоциации.
5. Связи прерваны.

Следовательно, операция чтения (или поиска) будет иметь без условий публикации , по крайней мере, не для читаемых элементовили искал.Например, если 10 000 пользователей выполнили операции чтения / поиска за один день, но никогда не выполняли другие операции (C, U, D), объекты в домене не изменились бы.

Существуетисключение из этого, однако, в доменах, где запоминается поиск / чтение.Например, Google наверняка отслеживает поиски.В этом случае выполнение поиска имеет постусловие создания нового объекта в их доменной модели, например, Был создан экземпляр поиска s (создание экземпляра) .

Answer 2

Смущает форма упоминания отношения модели данных в шаблоне контракта, которое Ларман предоставил как:

Contract CO2: enterItem
Operation: enterItem(itemID : ItemID, quantity : integer)
...
sli was associated with a ProductSpecification, based on itemID match (association formed).

Подробные ссылочные свойства базы данных не должны упоминаться в договоре на эксплуатацию. Лучше оставить это как: "sli был связан с ProductSpecification".

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

Answer 3

Постусловие определяет, какое состояние вашего приложения (или объекта, в зависимости от уровня абстракции) должно быть после операции, чтобы оно считалось успешным.Например, для операции readEmployee постусловие будет следующим:

• создается новый экземпляр Employee.
• экземпляр Employee содержит соответствующие атрибутызначения базы данных.
• соединение с базой данных закрыто.

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

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

Интересно, что если вы подумаете об обратном DbC, вы поймете, что для определения того, какие операции должно предоставлять ваше приложение (или объект)это просто вопрос перечисления, какие состояния он может иметь и как он переходит между этими состояниями.Действия, которые вам нужно предпринять, чтобы сделать эти переходы, затем становятся вашими операциями, и вам не нужно беспокоиться о выполнении операций, которые не приводят к каким-либо желаемым состояниям.Так, например, вам, вероятно, нужны следующие состояния для вашего приложения.

• Добавлены данные сотрудника (S1)
• Загружены данные сотрудника (S2)
• Данные сотрудникаобновлено (S3)
• Данные сотрудника удалены (S4)

Возможны следующие изменения состояния.

• S1 -> S3 (добавить нового сотрудника,обновить данные)
• S1 -> S4 (добавить нового сотрудника, удалить сотрудника)
• S2 -> S3 (загрузить данные сотрудника, обновить данные сотрудника)
• S2 -> S4 (загрузить данные сотрудника, удалить сотрудника)
• S4 -> S1 (удалить сотрудника, добавить нового сотрудника)
• S2 -> S1 (загрузить данные сотрудника, добавить нового сотрудника)
• S3 -> S1 (обновить данные сотрудника, добавить нового сотрудника)
• S3 -> S2 (обновить данные сотрудника, загрузить данные сотрудника)

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

Невозможные переходы состояний:

• S4 -> S2 (невозможно удалить сотрудника, затем загрузить его данные)
• S4 -> S3 (не удается удалить сотрудника,затем обновите их данные)

Моделирование состояний, вероятно, является наиболее важной частью проектирования объектов, поэтому вы задаете правильные вопросы.Если вам нужен хороший ресурс по моделированию состояний, получите Объектные жизненные циклы моделирования мира в состояниях от Салли Шлаер / Стивена Меллора.Это довольно старая книга и почти ничего не стоит на Amazon, но принципы, которые она вводит, составляют основу современного UML - кстати, обозначения, используемые в книге, не похожи на UML.

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

Надеюсь, это было полезно.