UML и алгоритмы - PullRequest
       25

UML и алгоритмы

4 голосов
/ 17 июля 2010

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

Допустим, я хочу создать Use Case, который описывает, как User вводит набор значений, и мое приложение возвращает среднее из этих значений (конечно, это очень простой случай, но егоПроще объяснить это так).

1. The User tells the System he wants to calculate the average of a set of numbers.
2. The System asks the User for a number.
3. The User tells the System a number.
Repeat steps 2-3 until the User tells the System there are no more numbers left.
4. The System returns the average of all those numbers.

Теперь, где я должен указать алгоритм вычисления среднего числа?

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

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

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

Спасибо

Ответы [ 3 ]

3 голосов
/ 17 июля 2010

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

  1. Система запускается и обнуляет свои переменные итога и числа.
  2. Система получает номер.
  3. Добавляет число к сумме и увеличивает счет.
  4. Шаги 2 и 3 повторяются до тех пор, пока система не получит команду останавливаться.
  5. Когда приказано остановиться, система делит сумму на счет и возвращает результат.

Прочитайте отличную книгу Аластера Кокберна " Написание примеров эффективного использования ". Это объясняет наличие разных уровней варианта использования. Ваш первоначальный пример будет рассматриваться как вариант использования цели пользователя (или синего цвета), в то время как описанные выше действия будут частью варианта использования подфункции (или индиго) (он настолько прост, что его можно даже классифицировать как вариант использования черного цвета и просто объединить в его родителя).

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

EDIT

@ devoured elysium: В ответ на ваши комментарии я добавил еще несколько примечаний ниже:

Когда вы идентифицируете доменные объекты, иногда вам нужно подумать о неписанных объектах. Все зависит от того, как это было написано. Итак, в приведенном вами примере, возможно, «Система» - это «Калькулятор», переменная, используемая для сложения чисел, - это «Аккумулятор», возможно, есть «Очередь», которая получает число. Может быть, само число является объектом типа «Число», если оно может иметь различное поведение, такое как проверка диапазона или проверка синтаксиса ввода. Есть ли какой-нибудь объект «Display», который вам нужно рассмотреть?

Это зависит от того, что вы считаете находящимся в ограниченном контексте, с которым вы имеете дело. Возможно, с точки зрения пользователя, есть один контекст, который имеет дело только с «Калькуляторами», но с точки зрения Системы есть другой, который говорит о более низком уровне контекста с «Аккумуляторами», «ALUs», «Битами», «Словами», « Регистры »,« Часы »,« Защелки »и т. Д. Чем дальше вы переходите в иерархию вариантов использования, спрашивая« Как? » тем более технический язык станет. Вам нужно решить, какие из них являются объектами предметной области, а какие - просто объектами реализации, и это очень сильно зависит от того, что вы пытаетесь описать и построить (и, в значительной степени, от того, кто является вашей аудиторией - вездесущий язык и все такое). !). И наоборот, вы можете подняться в стеке, спросив "Почему?" функция выполняется.

Основной субъект варианта использования подфункции, как правило, является тем же субъектом, что и субъект использования более высокого уровня, который его вызывает. Однако для некоторых «технических» вариантов использования основным действующим лицом будет системный компонент / подсистема. Например, в прецеденте ведения журнала системных сообщений в качестве основного субъекта может использоваться вызывающая подсистема, т. Е. Объект, у которого была воля / необходимость инициировать действие, а не субъект, выполняющий задачу, из-за которой этот подсистема нуждался в регистрации. что-то.

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

Здесь нет жестких правил. Это стиль работы, который вы будете развивать со временем. Как уже говорили другие, убедитесь, что вы знакомы с другими формами диаграмм, чтобы вы могли выбрать правильный инструмент для работы. Помните, что, хотя картинка может стоить тысячи слов, иногда вам действительно нужны эти слова, поэтому не просто полагайтесь на диаграммы.

1 голос
/ 18 июля 2010

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

Этот мульти-диаграммный вид и сценарий использования с собственным свойством был действительно крут, потому что как только мой сценарий использования был сохранен в модели, его можно было использовать в другой диаграмме и, следовательно, описать то, что было невозможно на конкретной диаграмме. Очень очень мощная концепция, использующая метамодель в качестве базы данных xmi и редактор UML в качестве средства просмотра модели, а не самой модели. Теперь я могу делать то, что раньше было невозможно, и это намного мощнее. Это также более сложно, потому что вы должны смотреть на уровень диаграммы, а также на уровень метамодели, но как только я привык, это было замечательно :-) альтернативный текст http://www.forum -omondo.com / download / file.php? Id = 253 & mode = view

1 голос
/ 17 июля 2010

Вы неправильно используете вариант использования: сценарий использования является STATIC view :)

Для DYNAMIC View вы должны использовать диаграмму деятельности или диаграммы объекта / диаграммы последовательности.

...