|
Страница 1 из 6
Вариант использования - это прозаическое описание поведения системы при ее взаимодействии с окружающим миром. Я полагаю, большинство из вас уже использовали их или, по крайней мере, о них слышали. Некоторые, возможно, знают также и о жарких спорах, которые разгорелись по поводу их полезности (или бесполезности). Последнее десятилетие многое изменило в наших взглядах на варианты использования. Цель данной статьи - рассказать об эволюции этой концепции и тем самым дать возможность увидеть, насколько правильно или неправильно люди используют ее в наши дни. Кроме этого, конечно, автор хотел бы помочь вам наилучшим образом задействовать варианты использования в своей работе.
Действие первое - предысторияАйвар Якобсон (его фамилия так и произносится: "Я-коб-сон") начал писать о сценариях использования программных продуктов году эдак в 1967, когда работал над системой AXE для компании Eriksson. Те первые сценарии были написаны в свободной форме и весьма неформальным языком. Писал он их для того, чтобы показать, как люди будут использовать эти самые системы AXE. Тогда варианты использования еще не напоминали те сложные формальные структуры, которые зачастую используются сейчас при их описании (к чему и автор, вынужден признаться, приложил руку...). В середине 80-х Якобсон уже тратил немало времени и сил на описание тех решений, которые он смог найти в этой области в течение прошедших 20 лет. Именно тогда он придумал шведский термин "anvendningfall", что в приблизительном переводе означает "ситуация использования" или, по-английски, "usage case". Работая над английским переводом своей статьи, он решил, что "usage case" звучит как-то не по-английски, и переделал его в "use case". Если вам чем-то не нравится термин use case ("вариант использования"), скажите спасибо, что вам не приходится каждый раз выговаривать anvendningfall. Идея неформальности и свободы изложения была заложена в понятие варианта использования изначально. Дело в том, что людям не нравилось - да и сейчас не нравится - излагать сценарии формальным образом. Когда я однажды спросил Якобсона, нет ли у него модели для формального изложения вариантов использования, он ответил: "Ох, ну конечно же, я сделал такую модель. Есть только одна проблема - никто не хочет ею пользоваться". Впрочем, если считать варианты использования неформальными документами, возникнет другая проблема. Люди начнут спрашивать: "Да что же это такое, эти ваши "варианты использования"? Как мне узнать, что я пишу их правильно? А как связать между собой много вариантов использования?" В 1992 я натолкнулся на первую, программную статью Якобсона о вариантах использования, которую он написал в 1987 году. В то время я работал над созданием объектно-ориентированной методологии для IBM Consulting Group . Как и многие до меня, я сразу понял, что эти описания поведения системы естественным образом дополняют внутренние описания компонентов системы, которые создаются во время ОО-проектирования. Поэтому я, как и многие другие, начал искать ответ на вопрос: а что же такое эти варианты использования? И, как и многие другие, я попадал то в одну, то в другую ловушку - писал их слишком формально или слишком свободно. Нужно было накопить некоторый опыт, чтобы понять, что лучше всего выбрать средний вариант. Якобсон, тем временем, продолжал издавать книги и статьи, посвященные вариантам использования, однако почему-то вопросы при этом никуда не исчезали. Действие второе - последние десять лет Те, кто писал о вариантах использования между 1992 и 1997 годом, предпочитали умалчивать о том, что же это все-таки такое. Тем не менее, все говорили о том, как полезно использовать эту технику при разработке различных проектов. Итак, несмотря на то, что никто так и не сумел дать определение вариантам использования, или хотя бы объяснить разницу между ними и сценариями, идея не теряла своей привлекательности: нужно вкратце описать, как система взаимодействует с окружающим миром в процессе выполнения задачи, которую ставит перед ней пользователь. И, кроме того, зафиксировать поведение системы в непредвиденных и ошибочных ситуациях. Эта идея была привлекательной с самого начала, она остается такой и до сих пор, причем независимо от того, насколько формально или неформально пишутся подобные описания. "Научные школы", образовавшиеся в то время, предлагали всевозможные комбинации ответов на несколько основополагающих вопросов: - Что такое вариант использования - строгое изложение требования к системе или просто описание (story)?
- Может быть, "сценарий" - это еще одно название для варианта использования?
- Насколько формальной или неформальной должна быть структура варианта использования?
- Образуют ли варианты использования некую взаимосвязанную структуру, или же просто сваливаются в кучу?
Для некоторых вариант использования был просто еще одним определением понятия "сценарий" (краткого описания некоторого взаимодействия пользователя с системой). Мартин Фаулер (Martin Fowler) часто язвительно замечал, что "вариант использования", скорее всего, и значит "сценарий", только по-шведски. Последователи этой школы считают, что у варианта использования нет никакой внутренней структуры. Если их становится много, то их просто сваливают в кучу, и все. Те, кто пишет варианты использования таким образом, вполне довольны результатами, поэтому до сих пор многие рекомендуют описывать варианты использования именно так. Прочие же, особенно исследователи и разработчики CASE (Computer Aided Software Engineering) средств, посчитали, что неформальные артефакты будут слишком неполными, и что им нужен математический базис и поддержка в CASE средствах. Они разработали специальные языки, нотации и программы, с помощью которых варианты использования превратились в строгие и скрупулезные описания. Этот подход снискал куда меньше последователей. Людям был нужен простой способ выражения своих соображений относительно будущей системы. Они не хотели использовать формальные программные средства. Более того, им казалось, что дополнительная работа по формализации вариантов использования не дает ощутимых результатов. Кроме того, формалисты столкнулись с еще одной проблемой: как учесть все варианты поведения, с которыми может столкнуться система? Как-то меня спросили: "Если я разрабатываю автомат для продажи конфет, как мне специфицировать, какие монетки засунет туда покупатель? Он может положить три монетки по 25 центов, а может и 15 пятицентовиков. Или сначала положит 25 центов, а потом десять пятицентовиков? Или в обратном порядке? Или еще как-нибудь?" Я ответил: "Нужно написать: человек кладет в автомат деньги". После того, как я на своем опыте убедился в том, что слишком много формализма так же плохо сказывается на результатах работы над вариантами использования, как и его отсутствие, я остановился на неком среднем варианте: полуформальный текст, который находится в полуформальной структуре. В этом случае мы можем: - провозгласить, что варианты использования являются требованиями, а значит, имеют некоторую базовую структуру
- дать людям возможность писать то, что они хотят, причем так, как они считают нужным.
Может быть, это покажется неожиданным, но вторая цель гораздо важнее первой. Ниже я изложу структуру, которую я считаю оптимальной, и которая позволяет одновременно учитывать обе приведенные выше конфликтующие между собой цели.
|
