Форум Сообщества Аналитиков
Общий раздел => Примеры => Тема начата: PerpetuumMobile от 20 Сентября 2008, 12:35:25
-
Здравствуйте!
Вникаю в UML :) Придумал для себя проект "Прайс-лист", который и попытаюсь смоделировать.
Буду понемногу выкладывать свои попытки здесь.
Пожалуйста, покритикуйте :)
Начну с USE CASE:
-
Немного изменил диаграмму
-
Хочу уточнить... Я попытался изобразить СВИ :)
-
Еще подправил...
-
немного не понятно, что должен увидеть пользователь после входа в вистему?
-
"Увидеть ..." (после входа в систему) это цель пользователя?
не понял я Вас.
Я так полагаю, что в диаграммах Activity и Sequence вполне можно показать что должен увидеть пользователь :)
-
На вашей последней (исправленной) диаграмме видно только, что пользователь может произвести вход в систему, тогда я думаю стоит еще добавить вариант "посмотреть прайс".
-
"Увидеть прайс" в данном случае "Получить отпускные цены на товары". Или Вы подразумеваете кейс "Найти позицию", "Обозреть позиции" ?
-
Посмотреть прайс мне не очень нравится :)
-
"Увидеть ..." (после входа в систему) это цель пользователя?
1.В принципе да. Для начала нужно определиться с целью. Например в вашем случае "посмотреть прайс-лист",а потом уже играть именно от этого.
Я так полагаю, что в диаграммах Activity и Sequence вполне можно показать что должен увидеть пользователь
2.Тогда зачем использовать ДВИ? Что вы ей хотите показать?
3.Не совсем понятны стрелки, идущие от менеджера, руководителя и снабженца к пользователю.
4.Не совсем понятно зачем нужен снабженец, если руководитель выполняет такую же функцию.
-
Чтобы не было неправильного толкования нужно немного расписать каждый ВИ, что он в общем делает и для чего предназначен. В лучшем случае конечно хотелось увидеть сценарии ВИ.
-
На первый взгляд не очень удачные названия ВИ. Я бы назвал так:
Добавить товар (позицию) в прийс-лист
Посмотреть отпускные цены на товары
И еще - включения и расширения здесь показать можно, но если у Вас проект большой, то лучше их убирать с Д. А ВИ вообще не имеет смысла показывать если ВИ не включается в несколько ВИ
-
3.Не совсем понятны стрелки, идущие от менеджера, руководителя и снабженца к пользователю.
4.Не совсем понятно зачем нужен снабженец, если руководитель выполняет такую же функцию.
3. generalization... это. А что не правильно использую?
4. Снабженец ДОЛЖЕН а руководитель МОЖЕТ.
-
На первый взгляд не очень удачные названия ВИ. Я бы назвал так:
Добавить товар (позицию) в прийс-лист
Посмотреть отпускные цены на товары
И еще - включения и расширения здесь показать можно, но если у Вас проект большой, то лучше их убирать с Д. А ВИ вообще не имеет смысла показывать если ВИ не включается в несколько ВИ
Вечером напишу сценарии...
Я побоялся сделать ВИ "Добавить", "Удалить", "Править" потому что это натурально функции...
ВИ "А", включенный в ВИ "Б", но не включенный в другие ВИ не нужно отображать?
ВИ "Г", расширяющий ВИ "В", но не расширяющий другие ВИ не нужно отображать?
-
Руководитель может больше, чем снабженец.
Например снабженцу не обязательно смотреть отпускные цены.
Снабженец не может устанавливать и менять наценку на товар в позиции, удалять позицию...
-
Диаграмма №4.
-
Привет.
Несколько вопросов по 4 диаграмме.
1. К одному ВИ установлены ассоциации от разных акторов. Выполняют ли акторы ВИ одинаково, те одна ли у них цель? Если цель одна и делают они все одинакого, ассоциация одна от родительского актора. Если действия выполняются по разному каждым актором, то связей несколько.
2. ВИ "Войти" - предлагаю добавить ясности, написать куда нужно войти, например "Войти в систему". Не понятно также актор просто входит (запускает приложение) или аутентифицируется (логин/пароль)?
3. ВИ "Найти позицию" пожет ли вызываться из просмотра. Те можем ли мы найти, чтобы посмотреть? Может быть поиск сделать отдельным ВИ - это зависит уже от предполагаемой логики работы в приложении.
4. Для каждого актора один ВИ будет расписываться отдельным сценарием. Может следует сделать обобщение, чтобы кажый актор инициировал наследника (для каждого свой), а не все к одному.
-
Добавить, редактировать и удалить позицию - это CRUD (Create, Refresh, Update, Delete) ВИ, его следует показывать в виде одного ВИ, с названием, например, "Редактировать позицию". ВИ "Найти позицию" м.б. включением (расширением) в "Редактировать позицию" и "Просмотреть позиции".
-
Привет.
Несколько вопросов по 4 диаграмме.
1. К одному ВИ установлены ассоциации от разных акторов. Выполняют ли акторы ВИ одинаково, те одна ли у них цель? Если цель одна и делают они все одинакого, ассоциация одна от родительского актора. Если действия выполняются по разному каждым актором, то связей несколько.
2. ВИ "Войти" - предлагаю добавить ясности, написать куда нужно войти, например "Войти в систему". Не понятно также актор просто входит (запускает приложение) или аутентифицируется (логин/пароль)?
3. ВИ "Найти позицию" пожет ли вызываться из просмотра. Те можем ли мы найти, чтобы посмотреть? Может быть поиск сделать отдельным ВИ - это зависит уже от предполагаемой логики работы в приложении.
4. Для каждого актора один ВИ будет расписываться отдельным сценарием. Может следует сделать обобщение, чтобы кажый актор инициировал наследника (для каждого свой), а не все к одному.
Привет!
1. В контексте каждого ВИ планируется использовать общий интерфейс для всех акторов ВИ, но работа контроллера с атрибутами индувидуальна для каждого актора.
Собственно цель у них одна (для общего ВИ), но способ ее достижения зависит от роли.
Например добавить позицию может руководитель и снабженец, но снабженцу, в отличии от рук. доступна для записи только часть атрибутов.
2. Напишу "Авторизоваться"-это более конкретно.
3. Можно найти, чтобы посмотреть. Согласен, отдельный ВИ.
4. На счет отдельных сценариев - понятно. Дальше не очень. Это сколько тогда акторов будет нарисовано? Семь:)?
-
4. На счет отдельных сценариев - понятно. Дальше не очень. Это сколько тогда акторов будет нарисовано? Семь:)?
Я имел ввиду не обобщение акторов, а обобщение ВИ.
-
Диаграмма №5
-
Не знаю не знаю. Я бы обобщения ВИ не показывал на Д, а описал это бы в сценариях (основных и альтернативных потоках) ВИ
-
Диаграмма №6
-
А разделение Пользование на роли??
-
А разделение Пользование на роли??
Подобный случай был в дипломной работе, тоже рассматривалась ситуация "входа в ситему", а затем по введеным авторизационным данным присваивались полномочия. Использовала IDEF0. Получилось просто и понятно.
-
А разделение Пользование на роли??
Сорри, имел в виду - разделение Пользователей на роли
-
Сорри, имел в виду - разделение Пользователей на роли
А правильно будет добавить пользователю атрибуты "Имя" и "Роль"? Чтобы не усложнять диаграмму?
-
А зачем пользователю имя? На СДВИ показываются роли Пользователей.
-
С атрибутами я погорячился :)
-
Интересно бы посмотреть сценарии ВИ, в которых в зависимости от роли, будут выполняться разные действия.
Здесь либо куча ограничений и проверок, либо разные сценарии на каждую роль. На диаграмме мы не видим ролей, видим только пользователя. Возможно тогда стоит разделить Авторизацию на 2 ВИ. Первый - аутенитфикация (Вход в систему)
Второй - авторизация (установление прав в соответствии с ролью). В таком случае перед инициализацией каждого ВИ идет ВИ - Проверить права. И в зависимости от прав уже описывать сценарии.
ИМХО, сначала лучше накидать драфт сценариев и потом уже ДВИ приводить в какой- то конечный вид.
-
С атрибутами я погорячился :)
Не правильно совсем. Отдельные функции это не ВИ. Опиши это на ДД или ввиде сценария. Роль не выбирается обычно при авторизации. Она привязана к учетной записи (логину). Сначала проверяется есть ли учетная запись и правильный ли пароль (аутентификация), потом если учетная запись существует определяется роль - Менеджер, Сотрудник и тд (авторизация). Роль это набор прав и ограничений. Для каждой роли одна и та же функциональность может выполняться по разному.
Посмотри blueprint "Access Control" в книге Use Cases Patterns and Blueprints
By Gunnar Övergaard, Karin Palmkvist. Если книги нет то могу выслать.
-
Спасибо большое :).
Книгу нашел на местном файловом архиве.
Пошел RTFM.
-
Диаграмма №7
-
Вот теперь более удобоваримое.
1. Только непонятно что это за актер - Роль, скорее у Пользователя есть атрибут - роль.
2. Я бы не стал обобщения ВИ указывать на диаграмме, а описал бы это текстом
3. Я бы назвал ВИ - "Войти в систему под определенной ролью", вместо "Получить роль".
-
Вот теперь более удобоваримое.
1. Только непонятно что это за актер - Роль, скорее у Пользователя есть атрибут - роль.
2. Я бы не стал обобщения ВИ указывать на диаграмме, а описал бы это текстом
3. Я бы назвал ВИ - "Войти в систему под определенной ролью", вместо "Получить роль".
+ 1
-
Я бы сделал вот так.
Теперь немного пояснения.
Пользователь должен войти в систему под определенной ролью.
После входа, он работает в системе под определенной ролью. Каждая роль выполняет действия по разному, но цель одна и та же. Когда пользователь инициирует вариант использования, система проверяет его права и в зависимости от роли либо запрещает использвоать какой то функционал, либо просто не показывает этот функционал.
Здесь я применил 3 паттерна: Multiple actors: Distinct role, Multiple actors: Common role, CRUD: и 1 blueprint: Access control: Explicit Check
-
А если все ВИ будут зависеть от прав??
Лучше тогда не так. Есть ВИ - Войти в Систему под определенной ролью - это Авторизация и Аутентификация. Во всех других ВИ мы указываем ВИ "Войти в Систему под определенной ролью" как предусловие.
-
А если все ВИ будут зависеть от прав??
Лучше тогда не так. Есть ВИ - Войти в Систему под определенной ролью - это Авторизация и Аутентификация. Во всех других ВИ мы указываем ВИ "Войти в Систему под определенной ролью" как предусловие.
Можно по-всякому. Единственного правильного варианта решения нет. Смотря какая цель моделирования. Я, например, полностью поддерживаю Коберна, который говорит, что вся суть в сценарии. Нужно сначала понять, что делает пользователь и описать все сценарии, а потом уже их можно оптимизировать. Часть вынести отдельно, часть объединить. Имхо, определение прав в данном случае, в дальнейшем при проектировании можно описать как формирование разных GUI для разных ролей, например динамическое сокрытие менюшек, иконок и тп.
Саша, если делать так предлагаешь ты, то в предусловии лучше писать не ВИ "авторизация и аутентификация", что по сути является тем же инклудом, а например уже результат этого ВИ - Пользователь имеет соответствующие (необходимые) права.