Use case in action
•
9 gefällt mir•2,019 views
Варианты Использования (use cases) - это наиболее популярный метод описания пользовательских требований в последние нескольких лет. Но только единицы владеют этим <<искусством>>. Да-да, не побоюсь этого слова, т.к. при правильном применении варианты использования дают неоспоримые преимущества: интуитивно понятны заказчикам и разработчикам; помогают выявить функциональные требования; диаграмма помогает представить требования в целом; Аналитик фокусируется на потребностях Пользователя, а не на Системе и т.д. На мастер классе будут даны основные понятия вариантов использования, их шаблоны и конечно будет разобран пример моделирования и описания вариантов использования для одной из популярных веб систем. Для проведения полноценного тренинга обращайтесь ко мне.
![Немного о себе ,[object Object],[object Object],[object Object],[object Object],[email_address]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie Use case in action
Ähnlich wie Use case in action (20)
Mehr von Alexander Baikin
Mehr von Alexander Baikin (20)
Use case in action
- 1. Варианты использования в действии Байкин Александр uml2.ru
- 5. Экскурс в историю ВИ UML 1.1, UP, 1997 г. Варианты Использования, 10 лет спустя, А. Коберн, перевод Use Cases, 10 years later, Alistair Cockburn
- 7. Actor = Действующее лицо
- 8. Элементы ДВИ
- 9. Диаграмма ВИ Основное ДЛ Вспомогательное ДЛ Вспомогательное ДЛ Основное ДЛ
- 10. ВИ и типы Требований Функциональные Нефункциональные Пользовательские требования Бизнес- правила Атрибуты качества Функциональные требования Системные требования Внешний интерфейс Ограничения Бизнес- требования Спецификация требований к ПО Спецификация ПТ Границы проекта Системные Варианты Использования Бизнес Варианты Использования Кто такой аналитик?, Байкин Александр Разработка требований к ПО, К. Вигерс, ISBN 5-7502-0240-2 Software requirements, Karl Wiegers, ISBN 0-7356-1879-8
- 11. ВИ и Требования
- 12. Уровни ВИ Обобщенный Пользовательский Подфункция Современные методы описания функциональных требований к системе, Алистр Коберн , ISBN 5-85582-152-8 Writing effective use cases, Alistair Cockburn, ISBN 0-201-70225-80
- 26. Пример плохого ДВИ Форум uml2.ru , Раздел «Примеры»
- 29. ВИ в разработке
- 30. ВИ в Методологиях Уровень А. Коберн RUP ICONIXpenUP Бизнес Требования ВИ обобщенные Текст Бизнес ВИ Текст + Модель Нет Пользовательские Требования ВИ уровня Цели Пользователя Текст Системные ВИ Текст + Модель Системные ВИ Текст + Модель Системные Требования ВИ подфункция Текст Реализация ВИ Текст + Модель Реализация ВИ Модель
- 34. Литература К. Вигерс, Разработка требований к программному обеспечению А. Коберн, Современные методы описания функциональных требований к системам У. Леффингуэлл, Принципы работы с требованиями к программному обеспечению. Унифицированный подход
Hinweis der Redaktion
- &quot;Варианты использования, десять лет спустя&quot;, Алистэр Коуберн Действие первое - предыстория Айвар Якобсон (его фамилия так и произносится: &quot;Я-коб-сон&quot;) начал писать о сценариях использования программных продуктов году эдак в 1967, когда работал над системой AXE для компании Eriksson. Те первые сценарии были написаны в свободной форме и весьма неформальным языком. Писал он их для того, чтобы показать, как люди будут использовать эти самые системы AXE. Тогда варианты использования еще не напоминали те сложные формальные структуры, которые зачастую используются сейчас при их описании (к чему и автор, вынужден признаться, приложил руку...). В середине 80-х Якобсон уже тратил немало времени и сил на описание тех решений, которые он смог найти в этой области в течение прошедших 20 лет. Именно тогда он придумал шведский термин &quot;anvendningfall&quot;, что в приблизительном переводе означает &quot;ситуация использования&quot; или, по-английски, &quot;usage case&quot;. Работая над английским переводом своей статьи, он решил, что &quot;usage case&quot; звучит как-то не по-английски, и переделал его в &quot;use case&quot;. Если вам чем-то не нравится термин use case (&quot;вариант использования&quot;), скажите спасибо, что вам не приходится каждый раз выговаривать anvendningfall. Идея неформальности и свободы изложения была заложена в понятие варианта использования изначально. Дело в том, что людям не нравилось - да и сейчас не нравится - излагать сценарии формальным образом. Когда я однажды спросил Якобсона, нет ли у него модели для формального изложения вариантов использования, он ответил: &quot;Ох, ну конечно же, я сделал такую модель. Есть только одна проблема - никто не хочет ею пользоваться&quot;. Впрочем, если считать варианты использования неформальными документами, возникнет другая проблема. Люди начнут спрашивать: &quot;Да что же это такое, эти ваши &quot;варианты использования&quot;? Как мне узнать, что я пишу их правильно? А как связать между собой много вариантов использования?&quot; В 1992 я натолкнулся на первую, программную статью Якобсона о вариантах использования, которую он написал в 1987 году. В то время я работал над созданием объектно-ориентированной методологии для IBM Consulting Group . Как и многие до меня, я сразу понял, что эти описания поведения системы естественным образом дополняют внутренние описания компонентов системы, которые создаются во время ОО-проектирования. Поэтому я, как и многие другие, начал искать ответ на вопрос: а что же такое эти варианты использования? И, как и многие другие, я попадал то в одну, то в другую ловушку - писал их слишком формально или слишком свободно. Нужно было накопить некоторый опыт, чтобы понять, что лучше всего выбрать средний вариант. Якобсон, тем временем, продолжал издавать книги и статьи, посвященные вариантам использования, однако почему-то вопросы при этом никуда не исчезали.
- Спросите себя – для чего ДЛ выполняет этот ВИ, чтобы определить более высокоуровневый ВИ
- Мозговой штурм для выявления полного списка расширяемых условий Включить все, что Система может обнаружить и должна обрабатывать Написать все шаги для обработки расширений Каждый из них должен заканчиваться в ОУС, в отдельном успешном или неуспешное сценарии. Выделить сложные потоки в подВИ (sub UC), объединить одинаковые подВИ Выделить подВИ – это легко, но это добавит больше ценности проекту Заново переопределите ВИ и сценарии: добавьте, урежьте, или слейте что-то, если надо