Является ли этот прецедент правильным или правильным в соответствии с UML? если нет, пожалуйста, дайте некоторый вклад, чтобы улучшить его.Является ли этот прецедент правильным и правильным в соответствии с uml?
Пути, которые мы можем рассматривать как граничное значение «Использовать случаи», можно охарактеризовать как «Release Phase 1»?
Модуль Writer Module/Reader должен быть правильным Ator?
alt text http://img190.imageshack.us/img190/6708/usecaseh.jpg
Эта диаграмма говорит мне, что есть что-то внешним по отношению к системе вы разрабатываете называется «Writer Модуль». Писателю нужны три варианта использования, например Инициализация.
Аналогично, для другого участника требуется проверка состояния и стека.
Если это то, что вы намеревались сказать, то эта диаграмма работает. Вы действительно это имеете в виду? Только модуль Writer Инициализирует систему? Или система сама инициализируется? Может ли читатель проверить, была ли система инициализирована, до того, как она была инициализирована? Есть ли другой вариант использования?
Небольшое улучшение: укажите имена используемых случаев в своих частях речи. Инициализация - это «Вещь», «Проверить статус» - «Действие». Возможно, Инициализация системы может быть лучше? «Stack Up» не «StackUp», быть последовательным.
Также все usecases должны быть ориентированными на цель. –
Чтобы выбрать пример: на этой диаграмме указано, что Check Status - это сценарий с двумя участниками, Writer и Reader. Это то, что вы хотите сказать?
Кроме того, я не помню, чтобы видеть коробки вокруг (множества) Использовать Случаи вообще.
Обычно причина, по которой вы группируете прецеденты с помощью ящика, заключается в том, чтобы показать, какая система помогает встретиться или реализовать прецедент. Это формально известна как системная граница («Система, которую вы строите»). Обычно системы, модули и т. Д., Которые являются актерами, более черного ящика, существующие или используются только. Если есть много новых или модифицированных систем, это определение путается .
другие комментарии семантика, что вы показываете, но не sytax, по-прежнему важно.
Страница 103 Мартина Фаулера имеет диаграмму и Discription, которая использует концепции и системы системы boundry актеров.
Случаи использования призваны показать, как кто-то использует систему, чтобы получить что-то ценное. Актеры всегда представляют людей в смысле который имеет цели и способен искать что-то ценное.
Актеры представлены одним из нескольких способов, либо непосредственно по имени, либо путем включения через роль, либо посредством прокси в виде агента, действующего от имени человека или роли («системный» актер). Независимо от формы, актер всегда независим и всегда способен «воздействовать» на систему, чтобы достичь своих целей.
Диаграмма, которую вы здесь, не является диаграммой использования. «Модули» не являются независимыми, целевыми объектами, они кажутся просто компонентами некоторой системы. Они не способны «искать» что угодно, они просто детали реализации.
Диаграмма, которую вы, вероятно, ищете, представляет собой диаграмму развертывания (если вы хотите смоделировать, как конкретные компоненты связаны друг с другом), диаграмму активности (если вы хотите моделировать логику приложения) или диаграмму класса (если вы хотите для моделирования формальных отношений между компонентами).
Да Michael i добавил изображение .. –
на каком основании граница использования должна быть определена, так как мы использовали «USE CASES», можно использовать здесь как «Проверка состояния» –
Внутри bondary есть возможности системы, которые вы строят. Актеры - это люди и существующие системы, которые используют эти возможности. Если вы строите Writer Module, это не актер и не должен быть на этой диаграмме. Я не понимаю, что вы подразумеваете под «как мы использовали» USE CASES », можно использовать здесь как« Проверка состояния »' – djna