М. Фаулер, К. Скотт - UML. Основы - 2002 (1158629), страница 5
Текст из файла (страница 5)
Если вы применяете итеративную разработку с самого начала, то сможете правильно уяснить для себя характер процесса и начнете понимать, почему проектировщики предлагают делать некоторые вещи именно так, а не иначе. Применяя определенный метод, старайтесь пользоваться данной книгой.
Я рекомендую начинать с простых нотаций, в частности с диаграмм классов. Затем можно перейти к изучению более сложных понятий, которые представляются вам необходимыми. Возможно, вы придете к выводу, что соответствующий метод следует расширить. Общение с экспертами предметной области Одно из важнейших требований при разработке заключается в построении иравильяой системы, то есть такой системы, которая удовлетворяет потребности пользователей за разумную стоимость. Добиться этого весьма трудно, поскольку мы, с нашим жаргоном, должны общаться с пользователями, которые имеют собственный, еще более непонятный жаргон. (Я довольно продолжительное время работал в области медицины, где жаргон имеет весьма мало общего с английским языком1) Установление хороших контактов с пользователями наряду с хорошим пониманием их мира является ключом к разработке качественного программного обеспечения. Очевидным методом, который следует применять для этого, являются варианты использования (см.
главу 3). Вариант использования представляет собой некий моментальный снимок одного из аспектов вашей системы. Совокупность всех вариантов использования образует внешнее представление вашей системы, которому предстоит пройти долгий путь, объясняя, что эта система будет делать. Хороший набор вариантов применения — это главное для понимания потребностей ваших пользователей. Варианты использования также представляют собой хорошее средство для планирования проекта, поскольку они позволяют управлять итеративной разработкой. Последняя сама является важным методом, так как обеспечивает регулярную обратную связь с пользователями и тем самым позволяет отслеживать текущее состояние разработки программного обеспечения.
Хотя варианты использования и помогают установить взаимопонимание в отношении внешнего представления системы, исключительно важно рассмотреть также и более глубокие аспекты. Имеется в виду изучение того, как эксперты в вашей предметной области понимают свой мир. 27 Где найти дополнительную информацию В данной ситуации весьма важными могут оказаться диаграммы классов (см. главы 4 и 6), пока вы рассматриваете их с концептуальной точки зрения. Другими словами, каждый класс следует трактовать как некоторое понятие из области мышления пользователя. Построенные в этом случае диаграммы классов не являются диаграммами данных или классов, а представляют собой, скорее, диаграммы языка ваших пользователей.
В тех случаях, когда важной частью предметной области пользователей являются потоки работ, я считаю весьма полезным использовать диаграммы деятельности (см. главу 9). Поскольку диаграммы деятельностей поддерживают параллельные процессы, они позволяют избавиться от тех из них, выполнение которых не является необходимо последовательным. Характерной особенностью этих диаграмм является преуменьшение роли их связей с классами, что может повлечь за собой проблемы на более поздних стадиях проектирования, но на концептуальном этапе процесса разработки создает определенные преимущества.
Где найти дополнительную информацию Эта книга вовсе не является полным и окончательным справочным руководством по языку ПМ1., не говоря уже об объектно-ориентированном анализе и проектировании. Существует много такого, о чем здесь не говорится, и много полезного, что следует дополнительно прочесть. В ходе рассмотрения отдельных тем будут упоминаться и другие книги, к которым следует обратиться для получения более подробной информации о языке 1)МЬ и объектно-ориентированном анализе, а также о проектировании в целом. Без сомнения, после прочтения данного справочного руководства необходимо обратиться к книгам по языку 1)М1н написанным «тремя друзьями»: ° Гряди Буч возглавил работу по написанию руководства пользователя (Буч„Рамбо и Джекобсон, 1999 [61).
Эта книга является учебником, содержащим описание практических аспектов использования языка ПМЬ для решения различных задач проектирования. ° Джим Рамбо возглавил деятельность по написанию справочного руководства (Рамбо, Джекобсон и Буч, 1999 137)). Я часто обращаюсь за помощью к этому детальному справочнику по языку 1)М1..
° Айвар Джекобсон возглавил работу над книгой по описанию процесса, в ходе которого используется язык 11М1. (Джекобсон, Буч и Рамбо, 1999 123]). Более подробно об этом процессе говорится в главе 2. Конечно, чтобы хорошо изучить объектно-ориентированный анализ и проектирование, далеко не достаточно прочесть только эти книги Глава 1. Введение «троих друзей». Мой список рекомендуемой литературы часто изменяется; самую последнюю информацию можно получить на моей домашней странице в Интернете. Если вы новичок в объектном подходе, то обратитесь к моему фавориту среди имеющихся справочников и руководств для начинающих— книге Лармана, 1998 1281. Ее достоинством является то, что автор следует строго управляемому ответственностью подходу к проектированию.
Для тех, кто хочет больше знать об объектах с концептуальной точки зрения, теперь в серии книг по языку УМ1 есть работа Мартина и Оделла, 1998 129). Разработчикам-практикам следует обратиться также к книге Дугласа (Воиа1авв), 1998 Г17]. Для расширения вашего кругозора также рекомендую прочитать книги по образцам.
Сейчас, когда война методов уже закончилась, я думаю, что именно образцы окажутся среди наиболее интересных материалов по анализу и проектированию. Поскольку разработчики непременно будут создавать новые методы анализа и проектирования, то, вероятно, со временем они объяснят, как эти методы могут использоваться вместе с языком ПМ1. В этом еще одно преимущество языка БМЬ; он поощряет разработчиков создавать новые методы без дублирования уже выполненной кем-то работы. Основы процесса разработки БМ( — это язык моделирования, а вовсе не метод.
Язык СМ1. не содер- жит понятие процесса, который является важной частью метода. Название атой книги — «БМ».. Основы», поэтому можно было бы совершенно спокойно игнорировать сам процесс. Тем не менее, я думаю, что методы моделирования не имеют смысла без знания того, как они могут быть использованы в процессе. Я решил рассмотреть процесс в первую очередь, чтобы вы могли представить, каким образом выполняется объектно-ориентированная разработка. Но это не попытка глубоко проникнуть в многочисленные детали этого процесса, а лишь описание его основных особенностей. Знания последних вполне достаточно для типичного использования этих методов при разработке проекта. «Трое друзей» разработали некий единый процесс, получивший название йа11опа1 УпЦ(ей Ргосеяа.
(Ранее я использовал в его названии слово ОЬ|есгогу.) Этот процесс описан в книге «трех друзей» (Джекобсон, Буч и Рамбо, 19991231). Рассматривая основы процесса, я буду пользоваться терминологией и базовыми понятиями Рационального унифицированного процесса (ВаФ(опа1 Сп(1(еб Ргосезэ). Однако я не пытаюсь дать описание самого ВОР, поскольку это выходит за рамки данной книги. Взамен приведу лишь достаточно поверхностное и неформальное описание процесса, которое согласуется с ВОР.
Тем, кто заинтересуется всеми деталями Рационального унифицированного процесса, следует обратиться к 30 Глава 2. Основы процесса разработки книге «троих друзей е, посвященной процессу (23], или к обзору Крухтена (Кгцс)треп), 1999 (27). Хотя Рациональный унифицированный процесс содержит детальное описание того, какого рода модели следует разрабатывать на различных фазах процесса, я не буду углубляться в такие детали. Также не будут описываться задачи, ресурсы и роли.
Моя терминология беднее, чем терминология К11Р; это та цена, которую приходится платить за поверхностное описание. Какой бы процесс ни рассматривался, не забывайте, что с языком 1)М1. можно использовать любой процесс. Язык 1)М1. не зависит от процесса. Следует выбрать тот, который подходит для вашего типа проекта. Какой бы процесс вы ни применяли, язык ()М1. может использоваться для записи полученных решений по анализу и проектированию. В действительности я вовсе не думаю, что можно пользоваться только одним процессом для разработки программного обеспечения.
Различные факторы, связанные с разработкой программного обеспечения, приводят к различным типам процессов. Эти факторы относятся к типу разрабатываемого программного обеспечения (программа, работающая в реальном времени, информационная система или настольный продукт), масштабности разработки (один разработчик, небольшая команда, корпоративная разработка) и т. д. По моему мнению, командам следует применять свои собственные процессы, используя известные процессы не в качестве стандартов, а только лишь как рекомендации.
Общее представление о процессе На рис. 2.1 изображено самое общее представление о процессе разработки. Внедрение Рие. 2.1. Схема лроиеееа разработки Это итеративный и нарастающий процесс, при котором программное обеспечение не создается одним большим ударом в конце проекта, а, напротив, разрабатывается и реализуется по частям. Фаза построения состоит из многих итераций, на каждой из которых выполняются построение, тестирование и интеграция высококачественного программного обеспечения, удовлетворяющего некоторому подмножеству тре- Общее предста впение о процессе бований к проекту.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
