Книги: [Классика] [Базы данных] [Internet/WWW] [Сети] [Программирование] [UNIX] [Windows] [Безопасность] [Графика] [Software Engineering] [ERP-системы] [Hardware]
Предисловие
Все больше разработчиков прибегают к помощи вариантов использования для описания бизнес-процессов или поведения программных систем и требований к ним. Составление описания использования системы может оказаться сложной задачей. Проблема в том, что создание вариантов использования можно сравнить с написанием прозаического эссе, где необходимы четкие формулировки, которые свойственны письменной прозе. Трудно сказать, на что похож хороший вариант использования. Однако еще труднее научиться писать хорошие варианты использования.
Здесь содержатся правила, которые я использую при написании вариантов использования: как может думать индивидуум, чего он может твердо придерживаться, чтобы создать лучший вариант использования и лучший набор вариантов использования.
Я включил примеры хороших и плохих вариантов использования, привел разные стили написания. Вариант использования не должен быть выдающимся, чтобы быть полезным. Даже посредственные варианты использования полезны, причем больше, чем многие конкурирующие с ними технические требования. Итак, напишите что-нибудь внятное, и вы окажете услугу вашей организации.
Круг читателей
Эта книга предназначена преимущественно для профессионалов, которые обучаются самостоятельно. В книге содержится подготовительная информация для усвоения нового материала: понятия, примеры, памятки и упражнения (некоторые с ответами).
Преподавателям следует найти подходящие объяснения и примеры для своих групп. Разработчики курсов должны суметь построить материал на основе этой книги, составляя задания по своему усмотрению. (Однако, поскольку я включил ответы ко многим упражнениям, им придется построить экзаменационный материал самим.)
Преемственность идей
В конце 60-х годов Ивар Якобсон, работая над телефонными системами в компании Ericsson, изобрел то, что позднее получило название вариантов использования (use cases). В конце 80-х он представил их специалистам по объектно-ориентированному программированию. Они получили признание, заполнив брешь в процессе формирования требований. В начале 90-х я прошел курс у Якобсона. Ни он, ни его команда не пользовались моими терминами цель (goal) и неудача (goal failure), однако на самом деле они применяли эти понятия. В нескольких случаях мы с ним не нашли серьезных противоречий между его и моей моделью. Я расширил его модель, чтобы осовременить ее.
Я создал концептуальную модель Действующие лица и цели (Actors and Goals) в 1994 г., когда писал руководство по вариантам использования для IBM Consulting Group. Модель объясняла многие непонятные моменты в вариантах использования и одновременно служила руководством по их структурированию и написанию. Модель Действующие лица и цели неформально распространялась с 1995 г. Она находилась на http://members.aol.com/acocburn, позднее на www.usecase.org, а в 1997 г. в журнале Journal of Object-Oriented Programming была опубликована моя статья о структурировании вариантов использования с целями.
В период с 1994 по 1999 гг. эти идеи не претерпели изменений, хотя в теории оставались еще "белые пятна". В конце концов я понял, почему многие с таким трудом усваивали столь простые идеи (не говоря уж о том, что я обнаружил много ошибок в своих первых опытах). Кроме того, выявились недостатки в модели Действующие лица и цели. Все это привело к трактовке, изложенной в этой книге, и к новой представленной здесь идее - модели Участники и интересы (Stakeholders and Interests).
Унифицированный язык моделирования UML (Unified Modeling Language) не оказал заметного влияния на эти идеи, обратное также верно. Гуннар Овергаард, бывший коллега Якобсона, написал большую часть материала о вариантах использования на основе UML и поддержал наследие Якобсона. Однако группа стандартизации UML подвержена серьезному влиянию графических средств, что привело к выхолащиванию текстовой природы вариантов использования в стандарте UML. Гуннар Овергаард и Ивар Якобсон обсудили мои идеи и уверили меня, что большая часть того, что я говорю о варианте использования, умещается внутри одного из эллипсов UML и, следовательно, никогда не подвергнется воздействию стандарта UML и не повлияет на него. Это значит, что идеи этой книги совместимы со стандартом варианта использования в UML версии 1.3. С другой стороны, если вы прочтете только стандарт UML, в котором не обсуждается содержание и способ написания варианта использования, вы не поймете, что такое вариант использования и как его применять, и получите ложное представление о вариантах использования как графической, так и текстовой конструкции. Цель этой книги - показать, как писать эффективные варианты использования. Стандарт немного говорит по этому поводу, поэтому я вынес свои замечания по UML в приложение А.
Используемые примеры
Примеры, приведенные в этой книге, в большинстве своем взяты из реальных проектов и могут показаться несовершенными. Однако они удовлетворяли потребностям команды разработчиков, которая их писала. Эти несовершенства находятся в допустимых пределах. В издательстве Addison-Wesley меня убедили убрать шероховатости, чтобы выделить корректный вид на фоне реального и адекватного представления. Надеюсь, для вас будет полезно посмотреть на примеры и распознать подлинные описания реальных проектов. Вы можете применить некоторые из моих правил к этим примерам, чтобы улучшить их. Так как совершенствовать кем-то написанное можно бесконечно, я принимаю возражения и любую критику.
Варианты использования в серии Crystal Collection
Это одна из книг из серии Crystal Collection для профессионалов в области программного обеспечения. Она посвящена простым и доступным методам разработки программных продуктов. Некоторые книги описывают какой-либо метод, другие - единственную роль в проектировании или вопросы взаимодействия в группе разработчиков.
В основу Crystal Collection положены два принципа:
- Разработка программного обеспечения - это кооперативная игра, построенная на изобретательстве и общении. Она совершенствует навыки разработчиков и повышает эффективность работы группы в целом.
- Разным проектам присущи разные потребности. Программные продукты отличаются характеристиками и разрабатываются различными по численности группами, состоящими из специалистов с неодинаковыми системами оценок и приоритетов. Невозможно указать лучший способ производства программного обеспечения.
В основополагающей книге серии Crystal Collection, Software Development as a Cooperative Game, детально разрабатываются идеи о проектировании программного обеспечения как о кооперативной игре и о методологии как о гармонизации культуры. В книге рассматриваются аспекты методологии, технологии и деятельности, рабочих продуктов и стандартов. Сущность дискуссии в необходимом для вариантов использования объеме изложена в разделе 1.2 данной книги.
Настоящая книга - это техническое руководство по основным элементам написания вариантов использования. Этот метод подходит почти для любого случая, однако шаблоны и стандарты следует выбирать в соответствии с потребностями конкретного проекта.
Начало
Полное содержание
Структура книги
Об авторе
Заказать книгу в магазине "Мистраль"
🔥 VPS до 5.7 ГГц под любые задачи с AntiDDoS в 7 локациях
Виртуальные VPS серверы в РФ и ЕС
