Инкапсуляцией
 Скачать 0.92 Mb.
|
|
Введение UML (Unified Modeling Language — Унифицированный Язык Моделирования), одну из наиболее распространенных нотаций моделирования, применяемых при разработке объектно-ориентированных систем. Термин "объектно-ориентированный" является сравнительно новым в компьютерной индустрии. Компании активно работают, адаптируя эту технологию и интегрируя ее в существующие приложения. Большинство создаваемых сегодня приложений фактически уже являются объектно-ориентированными. В объектно-ориентированных системах данные комбинируются с конкретным поведением, т.е. с действиями, осуществляемыми над ними. Все это объединяется в объект. Данный процесс называется инкапсуляцией. По-другому ее можно описать, сказав, что мы разделяем приложение на небольшие фрагменты связанной функциональности. Преимуществом инкапсуляции является то, что она ограничивает последствия изменений, вносимых в систему. Наследование — вторая из фундаментальных объектно-ориентированных концепций. В объектно-ориентированных системах наследование представляет собой механизм, позволяющий создавать новые объекты, основываясь на уже существующих. Порождаемый (child) объект-потомок наследует свойства порождающего, родительского (parent) объекта. Одним из основных преимуществ механизма наследования является простота его поддержки. Третий принцип объектной ориентации — это полиморфизм. В словаре данный термин определен как проявление различных форм, стадий или типов. Полиморфизм означает наличие множества форм или реализаций конкретной функциональности. Визуальное моделирование Изучая требования к системе, вы берете за основу запросы пользователей и преобразуете их в такую форму, которую ваша команда сможет понять и реализовать. На основе этих требований вы генерируете код. Формально преобразуя требования в код, вы гарантируете их соответствие друг другу, а также возможность в любой момент вернуться от кода к породившим его требованиям. Этот процесс называется моделированием. Моделирование позволяет проследить путь от запросов пользователей к требованиям модели и затем к коду и обратно, не теряя при этом своих наработок. Визуальным моделированием называется процесс графического представления модели с помощью некоторого стандартного набора графических элементов. Наличие стандарта жизненно необходимо для реализации одного из преимуществ визуального моделирования — коммуникации. Общение между пользователями, разработчиками, аналитиками, тестировщиками, менеджерами и всеми остальными участниками проекта является основной целью визуального моделирования. Общение можно обеспечить и с помощью невизуальной (текстовой) информации, но люди — это зрительно-ориентированные существа. Мы легче понимаем сложную информацию, если она представлена нам визуально, нежели описана в тексте. Создавая визуальную модель системы, мы можем показать ее работу на различных уровнях — мы можем моделировать взаимодействие между пользователями и системой, взаимодействие объектов внутри системы и даже взаимодействие между различными системами, если хотим этого. Созданные модели представляются всем заинтересованным сторонам, которые могут извлечь из них ценную информацию. Например, глядя на модель, пользователи визуализируют свое взаимодействие с системой. Аналитики увидят взаимодействие между объектами модели. Разработчики поймут, какие объекты нужно создать и что эти объекты должны делать. Тестировщики визуализируют взаимодействие между объектами, что позволит им построить тесты. Менеджеры увидят как всю систему в целом, так и взаимодействие ее частей. Наконец, руководители информационной службы, глядя на высокоуровневые модели, поймут, как взаимодействуют друг с другом системы в их организации. Таким образом, визуальные модели предоставляют мощный инструмент, позволяющий показать разрабатываемую систему всем заинтересованным сторонам. Метод Буча, ОМТ и UML Важный вопрос визуального моделирования — выбор графической нотации для описания различных аспектов системы. Нотация должна быть понятна всем заинтересованным сторонам, иначе модель не будет полезна. Множество разработчиков предлагали свои варианты решения этого вопроса. Из них наибольшую поддержку получили метод Буча, технология объектного моделирования (ОМТ, Object Modeling Technology) и унифицированный язык моделирования (UML, Unified Modeling Language). Rational Rose 98i поддерживает все эти нотации. Однако большинством производителей и такими комитетами по стандартам, как ANSI и Object Management Group (OMG), был принят стандарт UML. Метод Буча назван по имени его изобретателя, Гради Буча (Grady Booch), работающего в корпорации Rational Software руководителем по науке (Chief Scientist). Он написал несколько книг, в которых обсуждаются необходимость и преимущества визуального моделирования, и разработал нотацию графических символов для описания различных аспектов модели.  Нотация ОМТ была разработана Джеймсом Рамбо (Dr. James Rumbaugh), написавшим несколько книг о системном анализе и проектировании. В книге "System Analysis and Design" Рамбо рассматривает значимость моделирования систем с помощью компонентов реального мира, называемых объектами. Предложенная им нотация ОМТ получила широкое признание, ее поддерживают такие стандартные промышленные инструменты моделирования программного обеспечения, как Rational Rose и Select ОМТ. ОМТ использует более простую графику моделирования систем по сравнению с методом Буча. Примеры объектов и связей в нотации ОМТ.  Унифицированный язык моделирования (UML) является результатом совместных усилий Гради Буча, Джеймса Рамбо, Ивара Якобсона (Ivar Jacobson), Ребекки Вирс-Брок (Rebecca Wirfs-Brock), Питера Йордона (Peter Yourdon) и многих других. Якобсон первым описал процесс выявления и фиксации требований к системе в виде совокупностей транзакций, называемых вариантами использования (use case). Детально мы рассмотрим варианты использования в разделе "Основы Rose" в главе 3. Якобсон также разработал метод проектирования систем под названием "Объектно-ориентированное проектирование программного обеспечения" (Object Oriented Software Engineering, OOSE), концентрирующий внимание на анализе. Буч, Рамбо и Якобсон, о которых обычно говорят как о "трех друзьях" (three amigos), работают в корпорации Rational Software. Их деятельность связана в основном со стандартизацией и усовершенствованием языка UML. Символы UML сильно напоминают нотации Буча и ОМТ, но содержат также элементы из других нотаций. На рис. 1.7 показан пример нотации UML. ДИАГРАММЫ UML UML позволяет создавать несколько типов визуальных диаграмм. Rational Rose поддерживает разработку большинства этих моделей, а именно:
Диаграммы иллюстрируют различные аспекты системы. Например, Кооперативная диаграмма показывает, как должны взаимодействовать объекты, чтобы реализовать некоторую функциональность системы. У каждой диаграммы есть своя цель и своя аудитория. Диаграммы Вариантов Использования Диаграммы Вариантов Использования отображают взаимодействие между вариантами использования, представляющими функции системы, и действующими лицами, представляющими людей или системы, получающие или передающие информацию в данную систему. Пример диаграммы Вариантов Использования для банковского автомата (Automated Teller Machine, ATM) показан на рис. 1.8.  На диаграмме представлено взаимодействие между вариантами использования и действующими лицами. Она отражает требования к системе с точки зрения пользователя. Таким образом, варианты использования — это функции, выполняемые системой, а действующие лица — это заинтересованные лица (stakeholders) по отношению к создаваемой системе. Диаграммы "показывают, какие действующие лица инициируют варианты использования. Из них также видно, когда действующее лицо получает информацию от варианта использования. В сущности, диаграмма Вариантов Использования может иллюстрировать требования к системе. В нашем примере клиент банка иллюстрирует различные варианты использования: Снять деньги со счета, Перевести деньги, Положить деньги на счет, Показать баланс, Изменить идентификационный номер, Произвести оплату. Банковский служащий может инициировать вариант использования "Изменить идентификационный номер". От варианта использования "Произвести оплату" идет стрелка к Кредитной системе. Действующими лицами могут быть и внешние системы, в данном случае Кредитная система показана именно как действующее лицо — она является внешней для системы ATM. Стрелку, направленная от варианта использования к действующему лицу, показывает, что вариант использования предоставляет некоторую информацию действующему лицу. В данном случае вариант использования "Произвести оплату" предоставляет Кредитной системе информацию об оплате по кредитной карточке. Из диаграмм Вариантов Использования можно получить довольно много информации о системе. Этот тип диаграмм описывает общую функциональность системы. Пользователи, менеджеры проектов, аналитики, разработчики, специалисты по контролю качества и все, кого интересует система в целом, могут, изучая диаграммы Вариантов Использования, понять, что система должна делать. Диаграммы Последовательности Диаграммы Последовательности отражают поток событий, происходящих в рамках варианта использования. Например, вариант использования "Снять'деньги" предусматривает несколько возможных последовательностей: снятие денег, попытка снять деньги при отсутствии их достаточного количества на счету, попытка снять деньги по неправильному идентификационному номеру и некоторые другие. Нормальный сценарий снятия $20 со счета (при отсутствии таких проблем, как неправильный идентификационный номер или недостаток денег на счету) показан на рис. 1.9.  Эта диаграмма Последовательности отображает поток событий в рамках варианта использования "Снять деньги". В верхней части диаграммы показаны все действующие лица и объекты, требуемые системе для выполнения варианта использования "Снять деньги". Стрелки соответствуют сообщениям, передаваемым между действующим лицом и объектом или между объектами для выполнения требуемых функций. Следует отметить также, что на диаграмме Последовательности показаны именно объекты, а не классы. Классы представляют собой типы объектов (см. главу 5). Объекты конкретны; вместо класса Клиент на диаграмме Последовательности представлен конкретный клиент Джо. Вариант использования начинается, когда клиент вставляет свою карточку в устройство для чтения — этот объект показан в прямоугольнике в верхней части диаграммы. Он считывает номер карточки, открывает объект "счет Джо" (account) и инициализирует экран ATM. Экран запрашивает у Джо его регистрационный номер. Клиент вводит число 1234. Экран проверяет номер у объекта "счет Джо" и обнаруживает, что он правильный. Затем экран предоставляет Джо меню для выбора, и тот выбирает пункт "Снять деньги". Экран запрашивает, сколько он хочет снять, и Джо указывает $20. Экран снимает деньги со счета. При этом он инициирует серию процессов, выполняемых объектом "счет Джо". Во-первых, осуществляется проверка, что на этом счету лежат, по крайней мере, $20. Во-вторых, из счета вычитается требуемая сумма. Затем кассовый аппарат получает инструкцию выдать чек и $20 наличными. Наконец все тот же объект "счет Джо" дает устройству для чтения карточек инструкцию вернуть карточку. Итак, данная диаграмма Последовательности иллюстрирует последовательность действий, реализующих вариант использования "Снять деньги со счета" на конкретном примере снятия клиентом Джо $20. Глядя на эту диаграмму, пользователи знакомятся со спецификой своей работы. Аналитики видят последовательность (поток) действий, разработчики — объекты, которые надо создать, и их операции. Специалисты по контролю качества поймут детали процесса и смогут разработать тесты для их проверки. Таким образом, диаграммы Последовательности полезны всем участникам проекта. Кооперативные диаграммы Кооперативные диаграммы отражают ту же самую информацию, что и диаграммы Последовательности. Однако делают они это по-другому и с другими целями. Показанная на рис. 1.9 диаграмма Последовательности представлена на рис. 1.10 в виде Кооперативной диаграммы. Как и раньше, объекты изображены в виде прямоугольников, а действующие лица в виде фигур. Если диаграмма Последовательности показывает взаимодействие между действующими лицами и объектами во времени, то на Кооперативной диаграмме связь со временем отсутствует. Так, можно видеть, что устройство для чтения карточки выдает счету Джо инструкцию открыться, а счет Джо заставляет это устройство вернуть карточку владельцу. Непосредственно взаимодействующие объекты соединены линиями. Если, например, устройство для чтения карточки общается непосредственно с экраном ATM, между ними следует провести линию. Отсутствие линии означает, что непосредственное сообщение между объектами отсутствует.  Итак, на Кооперативной диаграмме отображается та же информация, что и на диаграмме Последовательности, но нужна она для других целей. Специалисты по контролю качества и архитекторы системы смогут понять распределение процессов между объектами. Допустим, что какая-то Кооперативная диаграмма напоминает звезду, где несколько объектов связаны с одним центральным объектом. Архитектор системы может сделать вывод, что система слишком сильно зависит от центрального объекта, и перепроектировать ее для более равномерного распределения процессов. На диаграмме Последовательности такой тип взаимодействия было бы трудно увидеть. Диаграммы Классов Диаграммы Классов отражают взаимодействие между классами системы. Классы можно рассматривать как типы объектов (см. главу 5). Например, счет Джо — это объект. Типом такого объекта можно считать счет вообще, т.е. "Счет" (Account) — это класс. Классы содержат данные и поведение (действия), влияющее на эти данные. Так, класс Account содержит идентификационный номер клиента и проверяющие его действия. На диаграмме Классов класс создается для каждого типа объектов из диаграмм Последовательности или Кооперативных диаграмм. Диаграмма Классов для варианта использования "Снять деньги" показана на рис. 1.11. На диаграмме показаны связи между классами, реализующими вариант использования "Снять деньги". В этом процессе задействованы четыре класса: Card Reader (устройство для чтения карточек), Account (счет), ATM.Screen (экран ATM) и Cash Dispenser (кассовый аппарат). Каждый класс на диаграмме Классов изображается в виде прямоугольника, разделенного на три части. В первой части указывается имя класса, во второй — его атрибуты. Атрибут — это некоторая информация, характеризующая класс. Например, класс Account (счет) имеет три атрибута: Account Number (номер счета), PIN (идентификационный номер) и Balance (баланс). В последней части содержатся операции класса, отражающие его поведение (действия, выполняемые классом). Для класса Account   определены четыре операции: Open (открыть), Withdraw Funds (снять деньги), Deduct Funds (вычесть сумму денег из счета) и Verify Funds (проверить наличие денег). Связывающие классы линии показывают взаимодействие между классами. Так, класс Account (счет) связан с классом ATM Screen (экран ATM), потому что они непосредственно взаимодействуют друг с другом. Класс Card Reader (устройство для чтения карточек) не связан с классом Cash Dispenser (кассовый аппарат), поскольку они не общаются друг с другом непосредственно. Обратите внимание, что слева от некоторых атрибутов и операций имеются маленькие значки в виде висячего замка. Они указывают, что атрибут или операция класса закрыта (private). Доступ к закрытым атрибутам или операциям возможен только из содержащего их класса. Account Number, PIN и Balance — закрытые атрибуты класса Account. Кроме того, закрытыми являются операции Deduct Funds и Verify Funds. Разработчики используют диаграммы Классов для реального создания классов. Такие инструменты, как Rose, генерируют основу кода классов, которую программисты заполняют деталями на выбранном ими языке. С помощью этих диаграмм аналитики могут показать детали системы, а архитекторы — понять ее проект. Если, например, какой-либо класс несет слишком большую функциональную нагрузку, это будет видно на диаграмме классов, и архитектор сможет перераспределить ее между другими классами. С помощью диаграммы можно также выявить случаи, когда между сообщающимися классами не определено никаких связей. Диаграммы Классов следует создавать, чтобы показать взаимодействующие классы в каждом варианте использования. Можно строить также более общие диаграммы, охватывающие все системы или подсистемы. Диаграммы Состояний Диаграммы Состояний предназначены для моделирования различных состояний, в которых может находиться объект. В то время как диаграмма Классов показывает статическую картину классов и их связей, диаграммы Состояний применяются при описании динамики поведения системы. Диаграммы Состояний отображают поведение объекта. Так, банковский счет может иметь несколько различных состояний. Он может быть открыт, закрыт, или может быть превышен кредит по нему. Поведение счета меняется в зависимости от состояния, в котором он находится. На диаграмме Состояний показывают именно эту информацию. На рис. 1.12 приведен пример диаграммы Состояний для банковского счета. На данной диаграмме показаны возможные состояния счета, а также процесс перехода счета из одного состояния в другое. Например, если клиент требует закрыть открытый счет, последний переходит в состояние "Закрыт". Требование клиента называется событием (event), именно события вызывают переход из одного состояния в другое. Когда клиент снимает деньги с открытого счета, счет может перейти в состояние "Превышение кредита". Это происходит, только если баланс по счету меньше нуля, что отражено условием [отрицательный баланс] на нашей диаграмме. Заключенное в квадратные скобки условие (guard condition) определяет, когда может или не может произойти переход из одного состояния в другое.  На диаграмме имеются два специальных состояния — начальное (start) и конечное (stop). Начальное состояние выделяется черной точкой, оно соответствует состоянию объекта в момент его создания. Конечное состояние обозначается черной точкой в белом кружке, оно соответствует состоянию объекта непосредственно перед его уничтожением. На диаграмме Состояний может быть одно и только одно начальное состояние. В то же время может быть столько конечных состояний, сколько вам нужно, или их может не быть вообще. Когда объект находится в каком-то конкретном состоянии, могут выполняться те или иные процессы. В нашем примере при превышении кредита клиенту посылается соответствующее сообщение. Процессы, происходящие, когда объект находится в определенном состоянии, называются действиями (actions). Диаграммы Состояний не нужно создавать для каждого класса, они применяются только в очень сложных случаях. Если объект класса может существовать в нескольких состояниях и в каждом из них ведет себя по-разному, для него, вероятно, потребуется такая диаграмма. Однако во многих проектах они вообще не используются. Если же диаграммы Состояний все-таки были построены, разработчики могут применять их при создании классов. Диаграммы Состояний необходимы в основном для документирования. При генерации в Rose кода на основе вашей модели содержащаяся в них информация не преобразуется ни в какой код. Тем не менее для работающих в режиме реального времени систем доступны различные расширения Rose, которые позволяют генерировать исполняемый код, основываясь на диаграммах Состояний. Диаграммы Компонентов Диаграммы Компонентов показывают, как выглядит модель на физическом уровне. На ней изображаются компоненты программного обеспечения вашей системы и связи между ними. При этом выделяют два типа компонентов: исполняемые компоненты и библиотеки кода. В среде Rose каждый класс модели преобразуется в компонент исходного кода. Созданные компоненты сразу добавляются к диаграмме Компонентов. Затем указываются зависимости между отдельными компонентами, соответствующие зависимостям на этапе компиляции или выполнения программы. На рис. 1.13 изображена одна из диаграмм Компонентов для системы ATM.  На этой диаграмме показаны компоненты клиента системы ATM. В данном случае команда разработчиков решила строить систему с помощью языка C++. У каждого класса имеется свой собственный заголовочный файл и файл с расширением . СРР, так что каждый класс преобразуется в свои собственные компоненты на диаграмме. Например, класс ATM Screen преобразуется в два компонента ATM Screen диаграммы. Вместе эти компоненты представляют тело и заголовок класса ATM Screen. Выделенный темным компонент называется спецификацией пакета (package specification) и соответствует файлу тела класса ATM Screen на языке C++ (файл с расширением .СРР). Невыделенный компонент также называется спецификацией пакета, но соответствует заголовочному файлу класса языка C++ (файл с расширением . H). Компонент АТМ.ехе является спецификацией задачи и представляет поток обработки информации (thread of processing). В данном случае поток обработки программы. Компоненты соединены штриховой линией, отображающей зависимости между ними. Например, класс Card Reader зависит от класса ATM Screen. Следовательно, для того чтобы класс Card Reader мог быть скомпилирован, класс ATM Screen должен уже существовать. После компиляции всех классов может быть создан исполняемый файл ATMClient.exe. Пример ATM содержит два потока обработки, и таким образом получаются два исполняемых файла. Один из них — это клиент ATM, он содержит компоненты Cash Dispenser, Card Reader и ATM Screen. Второй файл — сервер ATM, включающий в себя компонент Account. Диаграмма Компонентов для сервера ATM  Как видно из примера, у системы может быть несколько диаграмм Компонентов в зависимости от числа подсистем или исполняемых файлов. Каждая подсистема является пакетом компонентов. В общем случае, пакеты — это совокупности компонентов (см. раздел "Основы Rose" главы 3). В примере ATM используются два пакета: клиент ATM и сервер ATM. Диаграммы Компонентов применяются теми участниками проекта, кто отвечает за компиляцию системы. Диаграмма Компонентов дает представление о том, в каком порядке надо компилировать компоненты, а также какие исполняемые компоненты будут созданы системой. Диаграмма показывает соответствие классов реализованным компонентам. Итак, она нужна там, где начинается генерация кода. Диаграммы Размещения Диаграммы Размещения показывают физическое расположение различных компонентов системы в сети. В нашем примере система ATM состоит из большого количества подсистем, выполняемых на отдельных физических устройствах, или узлах (node). Диаграмма Размещения для системы ATM представлена на рис. 1.15.  Из данной диаграммы можно узнать о физическом размещении системы. Клиентские программы ATM будут работать в нескольких местах на различных сайтах. Через закрытые сети будет осуществляться сообщение клиентов с региональным сервером ATM. На нем будет работать программное обеспечение сервера ATM. В свою очередь, посредством локальной сети региональный сервер будет взаимодействовать с сервером банковской базы данных, работающим под управлением Oracle. Наконец с региональным сервером ATM соединен принтер. Итак, данная диаграмма показывает физическое расположение системы. Например, наша система ATM соответствует трехуровневой архитектуре, когда на первом уровне размещается база данных, на втором — региональный сервер, а на третьем — клиент. Диаграмма Размещения используется менеджером проекта, пользователями, архитектором системы и эксплуатационным персоналом для выяснения физического размещения системы и расположения ее отдельных подсистем. Менеджер проекта объяснит пользователям, как будет выглядеть готовый продукт. Эксплуатационный персонал сможет планировать работу по установке системы. Приведенные диаграммы описывают систему с различных точек зрения. В разделе "Основы Rose" главы 3 мы детальнее рассмотрим каждую из этих диаграмм и покажем, как создавать их в среде Rational Rose. Вы сможете потренироваться в их построении и применении в этой среде. Однако прежде чем углубиться в детали Rose, стоит обсудить еще один аспект разработки программного обеспечения сам процесс. Хотя эта книга и не является учебником по методологии или по организации процесса, мы хотели бы познакомить вас с процессом разработки приложений, использующим описанные выше диаграммы UML. Визуальное моделирование и процесс разработки программного обеспечения Программное обеспечение может быть создано разными способами. Существует несколько различных типов процесса разработки, которые могут быть использованы в проекте: от "водопада” (waterfall) до объектно-ориентированного подхода. У каждого есть свои преимущества и недостатки. В данном разделе мы не собираемся указывать вам, какой именно процесс применять в своей работе, а представляем лишь краткое описание процесса, связанного с визуальным моделированием. Еще раз подчеркнем, что это только общий обзор. Долгое время программное обеспечение разрабатывали, следуя так называемой модели "водопада". В соответствии с ней необходимо было сначала проанализировать требования к будущей системе, спроектировать, создать и протестировать систему, а затем установить ее у пользователей. Как видно из названия, движение в обратную сторону по этой цепочке было невозможно — вода не потечет вверх. Данный метод был официальной методологией, применявшейся в тысячах проектов, но мы готовы утверждать, что в чистом виде, как его принято понимать, он не использовался ни разу. Одним из главных недостатков модели "водопада" является невозможность возврата назад на пройденные этапы, В начале проекта, следующего такой модели, перед разработчиками стоит обескураживающая задача полностью определить все требования к системе. Для этого необходимо тщательно и всесторонне обсудить с пользователями и исследовать бизнес-процессы. Пользователи должны согласиться со всем тем, что выясняется в ходе такого обследования, хотя они могут и не ознакомиться до конца с его результатами. При некотором везении таким способом на стадии анализа удается собрать около 80% требований к системе. Затем начинается этап проектирования. Необходимо сесть и определить архитектуру будущей системы. Мы выясняем, где будут установлены программы и какая аппаратура нужна для достижения приемлемой производительности. На данном этапе могут обнаружиться новые проблемы, их необходимо опять обсуждать с пользователями, что выразится в появлении новых требований к системе. Итак, приходится возвращаться к анализу. После нескольких таких кругов наконец наступает этап написания программного кода. На этом этапе обнаруживается, что некоторые из принятых ранее решений невозможно осуществить. Приходится возвращаться к проектированию и пересматривать эти решения. После завершения кодирования наступает этап тестирования. Здесь выясняется, что требования не были достаточно детализированы и их реализация некорректна. Нужно возвращаться назад на этап анализа и пересматривать эти требования. Наконец система готова и поставлена пользователям. Поскольку прошло уже много времени и бизнес, вероятно, уже успел измениться, пользователи воспринимают ее без большого энтузиазма, отвечая примерно так: "Да, это то, что я просил, но не то, что я хочу!" Это — магическая фраза, заклинание, которое разом состарит всю команду разработчиков как минимум на 10 лет! Рассмотрев этот мрачный сценарий и задумавшись о правильности выбора профессии, давайте поразмышляем, можно ли как-нибудь улучшить процесс. Состоит ли проблема в том, что правила бизнеса изменяются слишком быстро? Может быть, пользователи не могут объяснить, чего они хотят? Может быть, они не понимают команду разработчиков? Или сама команда не придерживается определенного процесса? Ответы на эти вопросы: да, да, да и нет. Бизнес меняется очень быстро, и как профессионалы-программисты мы должны поспевать за этим. Пользователи не всегда могут сказать, чего они хотят, поскольку их работа стала для них "второй натурой". Спрашивать об этом прослужившего 30 лет банковского клерка — примерно то же самое, что спрашивать, как он дышит. Работа стала для него настолько привычной, что ее уже трудно описать. Еще одна проблема заключается в том, что пользователи не всегда понимают команду разработчиков. Команда показывает им графики, выпускает тома текста, описывающего требования к системе, но пользователи не всегда понимают, что именно им дают. Есть ли способ обойти эту проблему? Да, здесь поможет визуальное моделирование. И наконец, команда разработчиков точно следует процессу — методу "водопада". К сожалению, планирование и реализация метода — две разные вещи. Итак, одна из проблем заключается в том, что разработчики использовали метод "водопада11, заключающийся в аккуратном и последовательном прохождении через все этапы проекта, но им приходилось возвращаться на пройденные этапы. Происходит ли это из-за плохого планирования? Вероятно, нет. Разработка программного обеспечения — сложный процесс, и его поэтапное аккуратное выполнение не всегда возможно. Если же игнорировать необходимость возврата, то система будет содержать дефекты проектирования и некоторые требования будут потеряны, возможны и более серьезные последствия. Прошли годы, пока мы не научились заранее планировать возвраты на пройденные этапы. Таким образом, мы пришли к итеративной разработке. Это название означает лишь, что мы собираемся повторять одни и те же этапы снова и снова. В объектно-ориентированном процессе нужно по многу раз небольшими шагами проходить этапы анализа, проектирования, разработки, тестирования и установки системы. Невозможно выявить все требования на ранних этапах проектирования. Мы учитываем появление новых требований в процессе разработки, планируя проект в несколько итераций. В рамках такой концепции проект можно рассматривать как последовательность небольших "водопадиков". Каждый из них достаточно велик, чтобы означать завершение какого-либо важного этапа проекта, но мал, чтобы минимизировать необходимость возврата назад. Мы проходим четыре фазы проекта: начальная фаза (inception), уточнение (elaboration), конструирование (construction) и ввод в действие (transition). Начальная фаза — это начало проекта. Мы собираем информацию и разрабатываем базовые концепции. В конце этой фазы принимается решение продолжать (или не продолжать) проект. В фазе уточнения детализируются варианты использования и принимаются архитектурные решения. Уточнение включает в себя некоторый анализ, проектирование, кодирование и планирование тестов. В фазе конструирования разрабатывается основная часть кода. Ввод в действие — это завершающая компоновка системы и установка ее у пользователей. Далее мы рассмотрим, что означает каждая из этих фаз в объектно-ориентированном проекте. Начальная фаза Начальная фаза — это начало работы над проектом, когда кто-нибудь говорит: "А хорошо бы, чтобы система делала..." Затем кто-то еще изучает идею, и менеджер спрашивает, сколько времени потребует ее реализация, сколько это будет стоить и насколько она выполнима. Начальная фаза как раз и заключается в том, чтобы найти ответы на эти вопросы. Мы исследуем свойства системы на высоком уровне и документируем их. Определяем действующих лиц и варианты использования, но не углубляемся в (детали вариантов использования, ограничиваясь одним или двумя предложениями. Мы также готовим оценки для высшего руководства. Итак, применяя Rose для поддержки нашего проекта, мы создаем действующих лиц и варианты использования и строим диаграммы Вариантов Использования. Начальная фаза завершается, когда данное исследование закончено и для работы над проектом выделены необходимые ресурсы. Начальная фаза проекта в основном последовательна и не итеративна. В отличие от нее, другие фазы повторяются несколько раз в процессе работы над проектом. Так как проект может быть начат только один раз, начальная фаза также выполняется лишь однажды. По этой причине в начальной фазе должна быть решена еще одна задача — разработка плана итераций. Это план, описывающий, какие варианты использования на каких итерациях должны быть реализованы. Если, например, в начальной фазе было выявлено 10 вариантов использования, можно создать следующий план: Итерация 1 Варианты Использования 1, 5, 6 Итерация 2 Варианты Использования 7, 9 Итерация 3 Варианты Использования 2, 4, 8 Итерация 4 Варианты Использования 3, 10 План определяет, какие варианты использования надо реализовать в первую очередь. Построение плана требует рассмотрения зависимостей между вариантами использования. Если для того, чтобы мог работать Вариант Использования 5, необходима реализация Варианта Использования 3, то описанный выше план неосуществим, поскольку Вариант Использования 3 реализуется на четвертой итерации — значительно позже Варианта Использования 5 из первой итерации. Такой план нужно пересмотреть, чтобы учесть все зависимости. |