Форум Сообщества Аналитиков
Общий раздел => Теория моделирования и нотации => UML SysML и пр. => Тема начата: StUtk от 25 Декабря 2008, 11:35:30
-
И ещё хотел бы обратить внимание на картинку на сайте - FAQ - Use Cases (Варианты Использования) (http://www.uml2.ru/index.php?option=com_content&task=category§ionid=3&id=31&Itemid=51).
Там изображён пользователь и два ВИ(логин и регистрация), между которыми установлено отношение расширения (extend). По-моему, это далеко не отношение расширения, это отношение включения, то есть один ВИ (логин) зависит от поведения второго ВИ (регистрация). А отношение расширения - это дополнительный функционал в зависимости от условий, объявленных в перовм ВИ.
Это замечание актуально, конечно, если, корректность картинки принципиальна. =)
-
И ещё хотел бы обратить внимание на картинку на сайте - FAQ - Use Cases (Варианты Использования).
Там изображён пользователь и два ВИ(логин и регистрация), между которыми установлено отношение расширения (extend). По-моему, это далеко не отношение расширения, это отношение включения, то есть один ВИ (логин) зависит от поведения второго ВИ (регистрация). А отношение расширения - это дополнительный функционал в зависимости от условий, объявленных в перовм ВИ.
Это замечание актуально, конечно, если, корректность картинки принципиальна. =)
Не соглашусь.
Пользователь инициирует ВИ "Логин" и понимает, что нут у него учетки :). Тогда он запускает ВИ "Регистрация" или завершает данный. Если учетка есть, то регистрация нам не нужна.
В данном случае Регистрация будет являться точкой расширения в ВИ "Логин"
С другой стороны, пользователь может не логиниться, а сразу запустить регистрацию. Включение не покатит, имхо.
Включение можно использовать только в том случае, если после регистрации мы снова возвращаемся в ВИ "Логин" и используем регистрационные данные для входа в систему. Если же после того, как мы зарегистрировались нужно снова запускать ВИ "Логин", то расширение. Все зависит от сценария и логики работы приложения. Нужно описание того и другого ВИ, а тогда уже думать о модели :)
-
Не соглашусь.
Пользователь инициирует ВИ "Логин" и понимает, что нут у него учетки :). Тогда он запускает ВИ "Регистрация" или завершает данный. Если учетка есть, то регистрация нам не нужна.
В данном случае Регистрация будет являться точкой расширения в ВИ "Логин"
С другой стороны, пользователь может не логиниться, а сразу запустить регистрацию. Включение не покатит, имхо.
Что такое ВИ? ВИ - это некий функционал, предоставляемой системой. ВИ "Логин" - авторизация пользователя, то есть это ВИ позволяет пользователю войти, если он ввёл правильный(известный системе) логин/пароль. Без регистрации залогиниться ну никак не получится, а это значит, что выполнение одного ВИ зависит от другого ВИ. А отношение расширения - это лишь дополнительный функционал, выполняемый при определённом условии, однако, без выполненного ВИ "Регистрация" залогиниться не получится, то есть не будет работать ВИ "Логин". ИМХО =)
Включение можно использовать только в том случае, если после регистрации мы снова возвращаемся в ВИ "Логин" и используем регистрационные данные для входа в систему. Если же после того, как мы зарегистрировались нужно снова запускать ВИ "Логин", то расширение. Все зависит от сценария и логики работы приложения. Нужно описание того и другого ВИ, а тогда уже думать о модели
Опаньки...) а ведь мы тут рассматриваем Use Case, в котором важна функциональность системы, а последовательность действий - это уже другое. Тут рассматривается статика, только то, что предоставляет система - функия авторизации, функция регистрации, функция оформления заказа и т.д.. имхо...)
-
Что такое ВИ? ВИ - это некий функционал, предоставляемой системой. ВИ "Логин" - авторизация пользователя, то есть это ВИ позволяет пользователю войти, если он ввёл правильный(известный системе) логин/пароль. Без регистрации залогиниться ну никак не получится, а это значит, что выполнение одного ВИ зависит от другого ВИ. А отношение расширения - это лишь дополнительный функционал, выполняемый при определённом условии, однако, без выполненного ВИ "Регистрация" залогиниться не получится, то есть не будет работать ВИ "Логин". ИМХО =)
А что есть функционал? Я такого термина не понимаю.
ВИ - это способ описания того, что ДОЛЖНА сделать система, чтобы ДОСТИЧЬ цели пользователя. Т.е. ВИ содержит некую поступательную (в смысле движения к цели) сововкупность действия как системы, так и пользователя. Как говорит Коберн некое соглашение, контракт. Контракт часто используемый термин в иностранной литературе
Опаньки...) а ведь мы тут рассматриваем Use Case, в котором важна функциональность системы, а последовательность действий - это уже другое. Тут рассматривается статика, только то, что предоставляет система - функия авторизации, функция регистрации, функция оформления заказа и т.д.. имхо...)
Включение, как Вам объяснили - это обязательный акт. По Вашему, регистрация включается в код авторизации всегда - действительно ли пользователь существует или нет.
Но на деле, авторизация включает только проверку: есть ли пользователь с данными характеристиками или нет. Если результат проверки положительный - обеспечивается доступ, нет сообщается о необходимости регистрации или каких-то других действий. Ведь регистрация может быть и не автоматической, а например нужно написать письмо администратору, позвонить ему по телефону, прийти лично - много вариантов
-
... Без регистрации залогиниться ну никак не получится, а это значит, что выполнение одного ВИ зависит от другого ВИ. ...
Не надо путать предусловия и связь вариантов использования. То что, перед логином пользователь должен быть зарегистрирован, это показывается либо предусловием, либо проверкой в теле самого варианта использования.
Связь dependency ("зависит") и use, которые показывают, что один элемент зависит от другого между вариантами использования не ставятся.
-
Опаньки...) а ведь мы тут рассматриваем Use Case, в котором важна функциональность системы, а последовательность действий - это уже другое. Тут рассматривается статика, только то, что предоставляет система - функия авторизации, функция регистрации, функция оформления заказа и т.д.. имхо...)
По-моему. Вы абсолютно не верно трактуете ВИ (возможно я ошибаюсь :)). ВИ в первую очередь это описание последовательности действий пользователя и откликов системы. Если вы используете диаграмму ВИ для того, чтобы описать функции системы ("статику"), без описания поведения, то я бы Вам посоветовал избавляться от подобной практики.
-
А что есть функционал? Я такого термина не понимаю.
ВИ - это способ описания того, что ДОЛЖНА сделать система, чтобы ДОСТИЧЬ цели пользователя. Т.е. ВИ содержит некую поступательную (в смысле движения к цели) сововкупность действия как системы, так и пользователя. Как говорит Коберн некое соглашение, контракт.
Всё же, позволю с Вами не согласиться...) Как я понимаю, ВИ - это не способ описания того, что должна делать система, чтобы достичь цели пользователя. ВИ - это и есть в общем то, что должна делать система, чтобы достичь цели пользователя (это я и вкладывал в понятие функционал). Да, пускай это некая последовательность действий, шагов, поступатльная совокупность действий, но, как мне кажется, на уровне конкретного use case'а поступательность непринципиальна, и рассматривается исключительно совокупность выполняемых действий как единое целое для предоставления пользователю конкретного результата (ака регистрация, авторизация, поиск и т.д..).
Включение, как Вам объяснили - это обязательный акт. По Вашему, регистрация включается в код авторизации всегда - действительно ли пользователь существует или нет.
Ну при чём тут код? С точки зрения ДВИ, важно только то, что должна делать система для достижение цели пользователя. Почему такое действие не может быть авторизацией? а так же регистрацией? Мне кажется, Вы погружаетесь в конкретику.
Включение специфицирует тот факт, что некоторый ВИ содержит поведение другого ВИ. То есть поведение одного ВИ зависит от другого.
Но на деле, авторизация включает только проверку: есть ли пользователь с данными характеристиками или нет. Если результат проверки положительный - обеспечивается доступ, нет сообщается о необходимости регистрации или каких-то других действий.
А по-моему, авторизация (логин) - это не проверка пользователя, а предоставление определённого доступа к ресурсам сайта, например.
Ведь регистрация может быть и не автоматической, а например нужно написать письмо администратору, позвонить ему по телефону, прийти лично - много вариантов
Да кто же спорит то? =) Но и здесь ведь важен не способ, а суть. Главное - регистрация, то есть конкретное действие, которое должна выполнить система для получения результата пользоватлем. =)
ПС.
Я не настаиваю на исключительности своей точки зрения и на своей правоте. Я всецело допускаю, что я могу ошибаться. Просто, если я неправ, хочется, чтобы вопрос был до конца ясен. :)
-
По-моему. Вы абсолютно не верно трактуете ВИ.
Вполне возможно =)
ВИ в первую очередь это описание последовательности действий пользователя и откликов системы.
Категорически не согласен. Дабы не быть голословным, я попозже приведу доводы и аргументы, надо обратиться к первоисточникам и авторитетным изданиям. ;)
Да, возможно я неправ...)
-
StUtk,
ВИ описывает действия Системы и ПОЛЬЗОВАТЕЛЯ (Актера), чтобы достичь цель последнего. Так что хотя бы поэтому, ВИ - это НЕ функционал ИС, функционала там только 50%. ВИ - это ПОЛЬЗОВАТЕЛЬСКИЕ Тр., а НЕ "функциональные" по классификации Вигерса.
Чтобы спорить прошу Вас описать сценарии этих 2ух ВИ (хотябы кратко), только после этого можно будет понять "кто прав, а кто виноват"
-
StUtk,
ВИ описывает действия Системы и ПОЛЬЗОВАТЕЛЯ (Актера), чтобы достичь цель последнего. Так что хотя бы поэтому, ВИ - это НЕ функционал ИС, функционала там только 50%. ВИ - это ПОЛЬЗОВАТЕЛЬСКИЕ Тр., а НЕ "функциональные" по классификации Вигерса.
По-моему началась путаница из-за слова функционал. ВИ - это некое действие системы приводящее к какому-то результату для актёра. Эта формулировка верна? Для ВИ важно ЧТО делает система, а не КАК она это делает. Правильно?
И ещё, очень интересны мнения по ниже приведённым высказываниям:
- "Функциональные требования определяют действия, которые должна выполнять система, без рассмотрения физических особенностей их реализации."
- "Тем самым функциональные требования определяют внешнее поведение системы."
- "Лучше всего они описываются в форме модели ВИ."
Всё познаётся в сравнении. Вот есть отношение расширения и отношение включения. К примеру, есть ВИ, то есть действие системы, которая считает пользователю в инет-магазине сумму заказанного товара. Пользователь(актёр) получает эту сумму(число). Далее, система может предоставить пользователю скидку. Предоставление скидки - чем не действие системы? Пускай будет ещё один ВИ "предоставление скидки постоянным клиентам". Здесь, как я понимаю, между двумя ВИ ("рассчитать сумму заказа" и "предоставление скидки постоянным клиентам") отношение расширения. То есть при каком-то условии (постоянный клиент) будет выполняться ВИ, предоставляющий скидку. Но в любом случае, сумма то посчитается, то есть первый ВИ всё равно будет выполнен - сумма товара будет посчитана, со скидкой или без. В случае с регистрацией и авторизацией другая ситуация, то есть система не сможет произвести действие "авторизация" никак, если не была выполнена регистрация. Здесь очевидна зависимость одного действия системы (авторизация) от результатов второго действия (регистрация).
Где мои рассуждения ошибочны? (если я вам ещё не надоел :) )
Чтобы спорить прошу Вас описать сценарии этих 2ух ВИ (хотябы кратко), только после этого можно будет понять "кто прав, а кто виноват"
1. ВИ "авторизация"
цель:
- получения доступа к ресурсам сайта
краткое описание:
- пользователь запрашивает форму авторизации
- система предлагает ввести логин/пароль
- пользователь вводит данные
- система обрабатывает данные и предоставляет или отказывает в доступе
2. ВИ "регистрация"
цель:
- возможность авторизоваться
краткое описание:
- пользователь запрашивает форму регистрации
- система предоставляет форму
- пользователь вводит данные
- система регистрирует пользователя
-
По-моему началась путаница из-за слова функционал. ВИ - это некое действие системы приводящее к какому-то результату для актёра. Эта формулировка верна? Для ВИ важно ЧТО делает система, а не КАК она это делает. Правильно?
"Для ВИ важно ЧТО делает система,а не КАК она это делает." - это правильно. Но ВИ - это действия и Пользователя и Системы, ВИ - это НЕ только действия системы.
И ещё, очень интересны мнения по ниже приведённым высказываниям:
- "Функциональные требования определяют действия, которые должна выполнять система, без рассмотрения физических особенностей их реализации."
- "Тем самым функциональные требования определяют внешнее поведение системы."
- "Лучше всего они описываются в форме модели ВИ."
1. Ну допустим
2. Не только. ФТ описывают и то что происходит внутри Системы без привязке к физ. реализации.
3. А вот тут путаница. Не знаю почему у Вигерса так сделано, но у него все Тр. делятся на класс ФТ и НеФТ, но есть разные уровни Тр. (БТр, ПТр, ФТр), причем в уровень ФТр входят экземпляр опять же ФТр, Ограничений и Внешних Интерфейсов. См. картинку по классификации Тр (http://sehlhorst.smugmug.com/photos/51101899-M.jpg). Но Вы в любом случае не правы в Вашем последнем высказывании :) Еще раз скажу, что ВИ - это ПТ по уровням Тр. Вигерса.
1. ВИ "авторизация"
цель:
- получения доступа к ресурсам сайта
краткое описание:
1. пользователь запрашивает форму авторизации
2. система предлагает ввести логин/пароль
3. пользователь вводит данные
4. система обрабатывает данные и предоставляет или отказывает в доступе
А представим, что альтернативным потоком на шаге 4. будет Регистрация, если Пользователь не может авторизоваться?! Так, например, сделано на всех практически сайтах.
-
"Для ВИ важно ЧТО делает система,а не КАК она это делает." - это правильно. Но ВИ - это действия и Пользователя и Системы, ВИ - это НЕ только действия системы.
По-моему, ВИ - это обобщённое понятие нечто того, что делает система (в документации встречалось выражение unit of functionality, функциональность то бишь по-русски, вроде), а уж детали, грубо говоря в каком поле пользователь вводит логин и пароль - это уже не важно на уровне ВИ, главно, что идёт процесс авторизации. Бесспорно, что выполнение ВИ инициирует актёр.
3. А вот тут путаница. Не знаю почему у Вигерса так сделано, но у него все Тр. делятся на класс ФТ и НеФТ, но есть разные уровни Тр. (БТр, ПТр, ФТр), причем в уровень ФТр входят экземпляр опять же ФТр, Ограничений и Внешних Интерфейсов. См. картинку по классификации Тр (http://sehlhorst.smugmug.com/photos/51101899-M.jpg). Но Вы в любом случае не правы в Вашем последнем высказывании :) Еще раз скажу, что ВИ - это ПТ по уровням Тр. Вигерса.
А кто такой Вигерс? И вообще, кого можно считать носителем истины о UML? Я тут не пытаюсь навязать своё мировоззрение семантики языка, просто пытаюсь как-то скореллировать то, что вижу здесь, со знаниями, полученными в других источниках.
И ещё, эти три высказывания не мои, это цитаты...)
А представим, что альтернативным потоком на шаге 4. будет Регистрация, если Пользователь не может авторизоваться?! Так, например, сделано на всех практически сайтах.
Хорошо.
А можно тогда пример отношения включения?
-
Уууууууууууууууууууууу Батенька читаем Вигерса и Коберна для начала.
А можно тогда пример отношения включения?
Отношение включения имеет смысл только тогда, когда ВИ включается в несколько ВИ. Если ВИ включается только в один ВИ, то он описывается внутри второго ВИ.
Пример, хм ....
Не совсем корректный пример но все же:
Есть ВИ - "Открыть позицию" и "Закрыть Позицию" Трейдером на рынке ЦБ. Есть ВИ "Исполнить Заявку", вот этот ВИ включается и в ВИ "Открыть позицию" и в ВИ "Закрыть Позицию".
-
Уууууууууууууууууууууу Батенька читаем Вигерса и Коберна для начала.
Всё остальное злобная ересь?
-
Всё остальное злобная ересь?
Смотря что. Но Вигерс (http://www.uml2.ru/index.php?option=com_remository&Itemid=28&func=fileinfo&id=77) с Кобероном (http://www.uml2.ru/index.php?option=com_remository&Itemid=28&func=fileinfo&id=65) - это то что должно быть прочтено обязательно и в начале.
-
А можно тогда пример отношения включения?
Самы распространенный пример: "Проверить пин код" :) включен в большое количество ВИ банкомата, например, в "Просмотреть счет", "Снять наличные"...
Отношение включения имеет смысл только тогда, когда ВИ включается в несколько ВИ.
Не всегда....
Также используется в случаях, когда один ВИ включается в другой, но включенный можно запустить отдельно от включаемого.
-
Смотря что. Но Вигерс (http://www.uml2.ru/index.php?option=com_remository&Itemid=28&func=fileinfo&id=77) с Кобероном (http://www.uml2.ru/index.php?option=com_remository&Itemid=28&func=fileinfo&id=65) - это то что должно быть прочтено обязательно и в начале.
Вот я лезу в раздел FAQ на сайте, смотрю книги... и вижу разделы "Наиболее интересные книги по UML:", "Наиболее интересные книги по Требованиям:"... Вигерс и Коберн как раз во втором разделе, и что, значит все остальные книги по UML уже не книги? Или UML от книги становится другим? Семантика то не должна меняться в зависимости от книги, даже из того списка, который выложен на сайте! Неужели я неправ? К примеру, я читаю книгу Леоненкова, в соответствии с этим и пишу здесь, а оказывается, это неправильная книга, то есть не книга по Требованиям и тем более не книга Вигерса и Коберна?
Извините, накипело.
Наверное тогда не имеет смысла продолжать эту ветку, я не читал книгу Вигерса.
-
Наверное тогда не имеет смысла продолжать эту ветку, я не читал книгу Вигерса.
StUtk, к сожалению в литературе по uml приведена только нотация ВИ, в них никогда толком не рассказывают, что такое варианты использования и с чем их нужно "есть". Основная часть ВИ (об этом кстати немного заикаются) это его описание (текст или диаграмма деятельности). На ДВИ выносят ВИ лишь для того, чтобы структурировать их и показать первое видение модели ВИ и функциональности системы.
Если вы хотите более подробно узнать о ВИ почитайте Коберна. Он рассматривает их исключительно как текстовое описание, изредка обращаясь к модели. Для большего понимания моделирования ВИ я рекомендую книгу Овергаарда Use Case Patterns and Blueprints (в ней и модели и описание). Для того как использовать ВИ в процессе разработки рекомендую почитать Леффингула. На русском есть 1 и 3 книги. Вигерса тоже стоит почитать, но у него внимание уделено всем типам требований одинаково :)
Книга Леоненкова неплохая, но ИМХО, это переведенная спецификация UML2 :)
-
StUtk, к сожалению в литературе по uml приведена только нотация ВИ, в них никогда толком не рассказывают, что такое варианты использования и с чем их нужно "есть".
Да рассказывают...)
Основная часть ВИ (об этом кстати немного заикаются) это его описание (текст или диаграмма деятельности). На ДВИ выносят ВИ лишь для того, чтобы структурировать их и показать первое видение модели ВИ и функциональности системы.
Абсолютно согласен.
Книга Леоненкова неплохая, но ИМХО, это переведенная спецификация UML2 :)
Близость к источнику, чем плохо? :) А потом, у него, кстати, очень неплохо разжёвываются основные понятия с конкретными примерами.
-
Близость к источнику, чем плохо? :) А потом, у него, кстати, очень неплохо разжёвываются основные понятия с конкретными примерами.
Для UML совсем не плохо. Но к сожалению голое знание нотации не позволяет создавать качественные продукты :(
Чтобы писать "нормальные" спеки нужно уметь uml еще и применять. Если дать разработчику в руки модель ВИ я думаю, что они мало что смогут сделать, а вот если дать более или менее описанный сценарий, который в дальнейшем можно детализировать, то сделать думаю смогут намного больше :).
Я не навязываю свою точку зрения, но модель ВИ мы с коллегами обычно делаем после того как опишем потоки событий. Когда в голове есть полное видение тогда и структурировать легче и связи ставить между ВИ. Поэтому, я рекомендую сначала накидать драфт модели ВИ, потом описать все потоки, а потом уже оптимизировать модель и установить связи.
-
Для UML совсем не плохо. Но к сожалению голое знание нотации не позволяет создавать качественные продукты :(
Чтобы писать "нормальные" спеки нужно уметь uml еще и применять.
Любая теория без практики малоэффективна.
Я не навязываю свою точку зрения, но модель ВИ мы с коллегами обычно делаем после того как опишем потоки событий. Когда в голове есть полное видение тогда и структурировать легче и связи ставить между ВИ.
Да кто бы спорил...))
-
Самы распространенный пример: "Проверить пин код" :) включен в большое количество ВИ банкомата, например, в "Просмотреть счет", "Снять наличные"
И который, кстати, в большинстве таких примеров даёт неверное представление о работе банкомата.
Вот здесь, например:
http://www.intuit.ru/department/pl/umlbasics/4/2.html
Дело в том, что сам банкомат не в состоянии "проверить ПИН код".
А пошло это гулять от самого Коберна. ;)
-
Гриша,
Так не понятно - на приведенной тобой ДВИ правильно изображен ВИ "Проверка ПИН-Кода ..."?? ИМХО по твоей логике правильно.
Но хотелось бы заметить, что есть типы карточек, на которых зашит сам ПИН-Код и вроде даже остаток на Счету, и Банкомату необязательно обращаться в Банк для списания и проверки ДС.
-
1. ВИ "авторизация"
цель:
- получения доступа к ресурсам сайта
краткое описание:
- пользователь запрашивает форму авторизации
- система предлагает ввести логин/пароль
- пользователь вводит данные
- система обрабатывает данные и предоставляет или отказывает в доступе
2. ВИ "регистрация"
цель:
- возможность авторизоваться
краткое описание:
- пользователь запрашивает форму регистрации
- система предоставляет форму
- пользователь вводит данные
- система регистрирует пользователя
1. ВИ "Авторизоваться"
цель:
- получения доступа к ресурсам сайта
краткое описание:
- пользователь идентифицирует себя в системе
- система обрабатывает данные идентификации и
если данные верны предоставляет доступ к ресурсам сайта
иначе предлагает "Пройти регистрацию" (точка расширения Пользователь системе неизвестен или введены ошибочные данные)
Результат: в интересах пользователя - получен доступ к ресурсам
в интересах держателей системы - не предоставлен доступ к ресурсам неизвестному посетителю
Т.е. подключение ВИ пройти регистрацию возникает при возникновении определенной ситуации
2. ВИ "Пройти регистрацию"
цель:
- возможность получения доступа к ресурсам сайта
краткое описание:
- пользователь регистрируется в системе
- система регистрирует пользователя (или сообщает пользователю что регистрация прошла успешно)
Результат: в интересах пользователя - получена возможность получить ресусры сайта
в интересах держателей системы - получена информация о пользователе ресурсов
Обратите внимание, что я устранил даже намек на реализацию. Нет форм, нет требуемых данных. Предположим об этом подумают на стадии проектирования ВИ. Показано только ЧТО делает пользователь и ЧТО делает система.
А вообще процесс разработки итерационный
-
Гриша,
Так не понятно - на приведенной тобой ДВИ правильно изображен ВИ "Проверка ПИН-Кода ..."?? ИМХО по твоей логике правильно.
Но хотелось бы заметить, что есть типы карточек, на которых зашит сам ПИН-Код и вроде даже остаток на Счету, и Банкомату необязательно обращаться в Банк для списания и проверки ДС.
Ну да, есть такие чиповые карты. Но и в этом случае, введённый ПИН проверяет не банкомат, а сама карта.
Раньше, насколько я знаю, действительно были такие магнитные карты, на которых была записана информация для проверки ПИН кода (и Коберн то ли описал такую карту, то ли сам придумал простой учебный пример ("Клиент вставляет карточку с идентификатором банка, номером счёта и закодированным ПИН кодом").
Я понимаю, что все эти примеры учебные и не обязательно должны соответствовать реальности. Но именно пример с банкоматом меня "цепляет", потому что напрямую связан с нашими проектами и затрагивает ту часть, из-за которой ты порекомендовал мне использовать слово "сценарии" вместо "вариантов использования": взаимодействие с внешними системами.
Конкретно для проверки ПИН кода карт наиболее распространённых платёжных систем на низком уровне существует, по меньшей мере, три сценария. При этом с точки зрения держателя карты они ничем не различаются: он просто вставил карточку в банкомат и ввёл ПИН, и может пребывать в полной уверенности в том, что "банкомат проверяет ПИН".
Но здесь держатель карты является далеко не единственным заинтересованным лицом, интересы остальных основных заинтересованных лиц сосредоточены в смежных системах, с которыми взаимодействует банкомат - в банковском процессинге и в чиповом приложении самой карты.
В общем, простой и наглядый на первый взгляд пример при внимательном рассмотрении оказывается совсем не таким простым и однозначным.
-
если данные верны предоставляет доступ к ресурсам сайта
иначе предлагает "Пройти регистрацию" (точка расширения Пользователь системе неизвестен или введены ошибочные данные)
Трудно не согласиться. :)
-
Хочу еще заметить, что форма ВИ не догма. Это же не математика со строгим доказательством и каноническими формами. Это скорее практика жизни, эмпирика. До нас и после нас 1000 людей будут сталкиваться с одинаковыми проблемами и пытаться одинаково их решить.
Будет ли создан четкий математический аппарат позволяющий четко и конкретно определить - это математически верный ВИ, а это не. Думаю вряд ли.
Одни утверждают, что ВИ должен быть содержать абстракции, чтобы не дай бог не ограничить разработчика в его действиях. Другие наоборт утверждают, что ВИ нужно писть конкретно и достаточно четко.
Мне конечно близко второе утверждение, потому как ВИ - это требования, а требования должны быть конкретны, проверяемы, недвусмысленными и прочее.
Хорошо или нет сказать: Пользователь вводит данные для авторизации?
С одной стороны вроде хорошо - мы не стесняем проектировщика в средствах - пусть сам определяет ЧТО это за данные
Но ... а как проверить что данные авторизации достаточны? Разве не определеннее и не яснее сказать Пользователь вводит Логин и Пароль, а в доптребования написать Логин - строка не менее 6 символов только латинского алфавита
Пароль - строка не менее 8 символов
Резонный вопрос, а куда пользователь вводит данные каким способом?
Вероятно тут вовсе нет противоречия, просто ВИ нужно рассматривать на разных уровнях. Некий общий уровень - наиболее абстрактный от деталей, системный уровень более конкретный и точный, менее однозначный.
Более того многие авторы (авторитеты) призывают не описывать ВСЕ ВИ, или не описывать все ВИ одинаково.
Для отдельных достаточно краткого описания, для других нужны детализированные многостраничные описания.
Розенберг в своей книге посвященной использованию ICONIX, вообще утверждает - нечего парится. ВИ - это два абзаца (два параграфа) - 1 для основного потока в стиле обмена мячом, другой для альтернатив. Причем сразу в описании нужно использовать и выделять названия ПРЕДМЕТНЫХ классов и даже форм (интерфейсов). По его мнению это не нарушает принципов инкапсуляции - все что видно пользователю может быть элементарно использовано. Следует избегать описания внутренности черного ящика
-
Для начала нужно договориться о том, что такое функция системы ... я в данном случае не рассматриваю автоматизированную систему в терминах ГОСТ 34. Если принять что функция, это нечто, что делает СИСТЕМА, предположительно на основании ТРЕБОВАНИЙ к ней. То юзкейс, это однозначно НЕ ФУНКЦИЯ. Юзкейс - тогда скорее то, как функции этой системы будут задействованы для достижения цели пользователя. Например, у вас в программе есть функция фильтрации данных, отображаемых в гриде. Пользователь фильтрует данные не ради фильтрации, а скорее ради сравнения строк или нахождения нужной строки. Т.о. пользователь выполняет ряд действий для нахождения нужной информации, используя функцию фильтрации. Он может для достижения этой же цели воспользоваться более точным поиском по условию (использовать другую функцию).
Получается, что ВИ - это ничто иное, как функции системе в КОНТЕКСТЕ ИХ ИСПОЛЬЗОВАНИЯ, т.е. взгляд на систему из-за ее пределов. В то время как функция системы - это взгляд на мир из системы.
-
Отвечая на данную тему, задумался и пришел к выводу - не прав тот, кто задает вопросы, не правы и те, кто отвечает.
К счастью - те, кто отвечает не правы меньше.
Теперь несколько слов об основах.
1. Диаграмма Ви должна быть максимально простой
2. Чтобы быть простой она должна содержать как можно меньше структурных элементов(инклюд, экстенд, обобщение)
3. Инклюд означает, что базовый вариант не может быть исполнен без включение сопутствующего ВИ
4. Чаще всего ВИ включамый бывает неполным - т.е. не может иметь экземпляров, но бывает и полным - т.е. вполне самостоятельным
5. Расширяющие ВИ чаще всего бывают неполными
6. Расщиряемые ВИ не зависимы от расширяющих, если сравнивать с инклюдами
7. Расширяющие ВИ чаще все-таки неполные, т.е. не имеют экземпляров
Резюме. В обсуждаемом случае лучше иметь два независимых ВИ: авторизация и регистрация. ЭТо не инклюд 100%, но и как расширение тоже не тянет. Просто регистрация - есть предусловие для авторизации