Форум Сообщества Аналитиков
Общий раздел => Теория моделирования и нотации => UML SysML и пр. => Тема начата: egor от 29 Ноября 2007, 16:42:18
-
Добрый день.
Есть такая задача, сделать три UML диаграммы для почтового клиента.
Варианты использования, диаграммы классов и состояний.
В начале про варианты использования.
Я себе предстваляю это так. Один или два актера(отправитель и получатель), которые взаимодействуют с блоками использования. Один человек с этого форума уже подсказал, что кол-во актеров зависит от бизнес или системной дигараммы(если я правельно полнял). Допустим диаграмма будет системной. Из этого следует, что актер будет один — отправитель или пользователь.
(*нарисовал человечка на листе бумаги*)
Теперь нужно определить цели актера. Эти цели — написать письмо, отправить его, получить почту и тп? Правельно? Что еще тут может быть?
Раньше с этим языком никогда не сталкивался, по этому нужны советы знающих людей.
Скажите пожалуйста правельный ли у меня ход мыслей и все такое?
Спасибо за раннее!
ЗЫ: Я так понимаю что вы рисуете диагараммы в спец. программе? Есть ли такие для Mac OS X?
-
USE CASE
Кажется фигня какая то плучилось))
Но эт пока не окончательный вариант. Жду коментов.
-
USE CASE
Кажется фигня какая то плучилось))
Но эт пока не окончательный вариант. Жду коментов.
USE CASE-диаграммы сами по себе не очень информативны, а а дополняют связный текст как то:
Действующие лица: пользователь, ...
Цели пользователя: получить почту, отправить почту, ....
Предусловия: наличие Интернета, ....
Основной (благоприятный) сценарий:
1. Пользователь загружает почтового клиента...
2.
Отказы:
...
10. Письмо не отправляется:
а) сохранить в папку НЕ ОТРАВЛЕННЫЕ
б) повторить попытку
...
-
egor, помоему получилось все нормально. Поскольку вы описываете задачи пользователя, то вполне нормально изложили их.
Конечно, можно сказать, что скорее всего не все возможности вы указали. Но Вы выделили главные.
Я бы, конечно, сделал несколько иначе.
Попробуйте уловить мои рассуждения.
Итак, что мы имеем.
Пользователь
1. Написать новое письмо
2. Получить почту
3. Ответить на письмо
4. Переслать письмо
5. Переадресовать письмо
6. Удалить (вероятно письмо)
К каждому ВИ следует поставить вопрос: А зачем?
Внимательно отвечая, можно прийти к таким более общим задачам как:
В1. Написать письмо
В2. Ответить на письмо
В3. Переслать письмо
В4. Удалить письмо
В1 Подразумевает создание либо нового письма либо ответа
В2 Подразумевает набор действий, среди которых вызывается В1 и 2
B3 Подразумевает выполнение 2 (который может быть расширен еще Прочитать письмо). Ваши 4 и 5 как мы видим аналогичны
При этом B4 может входить в общий вариант Управлять письмами, куда могут быть включены и Получить письмо и Прочитать письмо и Переадресовать письмо и Переместить письмо и Пометить письмо
Естественно все это можно рассматривать совершенно отдельно либо как экземпляр сценария базового ВИ.
Поэтому лучше для начала описать все, что хотел бы иметь пользователь от Вашего почтового клиента. Ведь фактически это и будут функции системы или свойства системы. Сюда могут быть включены и вопросы администрирования почтового клиента: создание ящика, формирование и настройка последнего, вклчение и отключение всяких свойств. Но... Вы стремитесь в начале выделить самое главное (Вам это практически удалось), далее анализируете, что следует делать вначале, а что можно реализовать позже. То что Вы выделили главным (а это 10-20% Ваших ВИ), описываете подробно и детально. Именно описываете. Диаграмма ВИ - это простой контекст, содержание задач пользователя в самомо общем виде, без излишних деталей.
Когда часть ВИ будет детально описана (базовый поток, альтернативные потоки, расширения и исключения) будет понятно как структурировать ДВИ, если это вообще потребуется.
Однако в любом случае нужно четко определится с целью проекта и потребностями пользователей. Хотя как я понимаю задача чисто учебная. Тгда скурпулезная точность не нужна. Достаточно лишь перечислить наиболее важные ВИ.
Далее по каждому ВИ можно сделать модель классов-участников ВИ, так называемую реализацию ВИ.
Обычно она делается по принципу MVC (модель предстваление управляющий класс)
Т.е. В данном контексте например для ВИ Получить почту, это может быть:
Актор - Форма получения почты - КонтролерПолучитьПочту - Письмо и возможно Папка входящих
Совокупность всех диаграмок классов дасть общую модель классов системы на концептуальном уровне
Диаграммы состояний будете делать для классов, которые действительно меняют состояния: например Письмо (Получено, Прочитано, Удалено). Либо для состояния какого-то управляющего класса.
Можно конечно отсановиться на общем концептуальном уровне и определить модель классов предметной области, модель состояний для нужных классов, модель взаимодействий объектов
-
2 Galogen
К сожелению не очч хорошо улавливаю выши рассуждения, т.к. uml и программирования для меня темный лес :)
Вы угадали, задача дествительно учебная и строить "подробные" диаграммы мне пока не к чему.
Я так понял, что можно построить ДВИ так:
Пользователь — ВИ управления письмами — расширения написать,...,...,..
— ВИ администрирование — расширения настройки,...,...,..
Так будет лучше?
-
egor, в принципе да. Хотя можно в данном случае оставить как есть, только убрать повторяющиеся ВИ.
Вообще очень странно, что Вас заставялют делать то, что для Вас темный лес. Может Вы все-таки огласите задание, как оно было Вам выдано? Т.е. список всех требований к проекту?
Вы должны сечас понять одно. ДВИ как таковые ничего не значат. Они показывают лишь общий контекст, в данном случае ЧТО хочет пользователь от системы почтового клиента. Потому про администрирование можно и забыть, а оставить только важные цели пользователя:
Получить - просмотреть почту (в первом случае посчтовый клиентведь может это делать автоматом), а вот просмотреть почту - это набор действий - и получение новой почты, и просмотрт имеющейся еще не прочитанной, просто ревизия своего почтовго ящика
Ответить на письмо (это и написать письмо и отослать письмо и возможно переслать письмо)
Переслать в приницпе можно оставить
Удалить письма можно оставить
Я бы правдв еще добавли что-то типа создание почтовго аккаунта или управление почтовым аккаунтом. А то как то непонятно как пользователь пользуется системой
Далее стройте диаграмму классов, уж какого уровня сказать не могу, но начните с концептуального, т.е. с классов предметной области (пользователь, аккаунт или почтовый ящик - письмо)
По идее вы можете учесть и адресную книгу (то есть ведение адресной книги)
Вариантов много :-)
Просто посмотрите на свой любимый почтовый клиент. определите самые важные функции которые нужны для выполнения ваших задач- наверное этого будет достаточно
-
Я бы пошел немного по другому пути.
У нас есть ф-ции:
1. Написать новое письмо
2. Получить почту
3. Ответить на письмо
4. Переслать письмо
5. Переадресовать письмо
6. Удалить (вероятно письмо)
Берем:
1. Написать новое письмо
Зачем пользователю просто писать письмо? Чтобы положить в черновики?? Нет. Ему надо "отправить письмо" и это цель. В процессе отправления письма пользоветель должен написать письмо.
2. Получить почту
Вот это больше похоже. Вот это уже цель, но только, если говорим о письмах, то и получить письмо/письма
3. Ответить на письмо
А это не похоже на обобщение написния письма?
4. Переслать письмо
А это не похоже на обобщение написния письма?
5. Переадресовать письмо
А это не похоже на обобщение написния письма?
6. Удалить (вероятно письмо)
А это наверное расширение получить письмо
А еще можно задаться целью настроить почту.
-
2 BAS
Это тоже учту :)
Тыкс с use case все понятно.
Помогите теперь разобраться с диаграммой классов :)
Какие могу быть классы у почтового клиента? Пользователь, почтовый сервер, письмо, аккаунт? Или что то другое?
Какие есть у классов расширения?
Читаю описание этих диаграмм, вообще нифига не понятно(((
-
Тыкс с use case все понятно.
У братец, как у вас быстро :)
Помогите теперь разобраться с диаграммой классов :)
Какие могу быть классы у почтового клиента? Пользователь, почтовый сервер, письмо, аккаунт? Или что то другое?
Какие есть у классов расширения?
Читаю описание этих диаграмм, вообще нифига не понятно(((
Ну так напишите ВИ в виде сценариев. Потом из них выявите существительные (сущности), потом попробуйте связать. Если есть вопросы по связям (что где используется), то спрашивайте.
-
bas, я думаю тут не надо так уж строго.
По идее - тут главное выделить системные события. Хотя ты прав, цели пользователя достаточно очевидны -
получить/просмотреть почту,
ответить (но не всегда, только ответить, можно ведь и просто написать новое письмо - например для установления контакта, послать запрос и т.п.), так что ответить может дополнять расширять - написать письмо
ну и управлять списком писем. это к тому, что удаление вовсе необязательно сопутствует ответу, хотя можно и так на это посмотреть
-
Помогите теперь разобраться с диаграммой классов :)
Сначала бы составить словарь предметной области... А дальше все само пойдет.