А.М. Вендров - Объектно-ориентированный анализ и проектирование

МОСКОВСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТимени М. В. ЛОМОНОСОВАА. М. ВендровОБЪЕКТНО-ОРИЕНТИРОВАННЫЙ АНАЛИЗИ ПРОЕКТИРОВАНИЕМОСКВА2004МОСКОВСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТимени М. В. ЛОМОНОСОВАФакультет вычислительной математики и кибернетикиА. М. ВендровОбъектно-ориентированный анализи проектирование(учебное пособие для студентов 5-го курса факультета ВМиК)МОСКВА20042УДК 681.3.06ББКВендров А. М. „Объектно-ориентированный анализ и проектирование“, –М.: Издательский отдел факультета вычислительной математики икибернетики МГУ (лицензия ИД № 05899 от 24.09.2001), 2004.

– 139 с.Учебное пособие содержит материал курса лекций, который, начинаяс 2000 г., читается для студентов 5-го курса факультета ВМиК кафедрАСВК, АЯ и СП. Целью курса является получение студентами знаний посовременнымметодамисредстваманализаипроектированияпрограммного обеспечения (ПО) на основе объектно-ориентированногоподхода, а также выработка практических навыков моделирования ПО сиспользованием языка UML.Курс «Объектно-ориентированный анализ и проектирование»завершает цикл дисциплин специализации 010212 “Математическое ипрограммное обеспечение вычислительных машин и сетей” приподготовке студентов по специальности ‘Прикладная математика иинформатика’.Рецензенты:Печатается по решению Редакционно-издательского Совета факультетавычислительной математики и кибернетики МГУ им. М.

В. Ломоносова.ISBN© Издательский отдел факультетавычислительной математики и кибернетикиМГУ им. М.В. Ломоносова, 20043ВведениеПо определению Института Управления Проектами (ProjectManagement Institute, PMI), проект - это временное предприятие,осуществляемое с целью создания уникального продукта или услуги.В любой инженерной дисциплине под проектированием обычнопонимается некий унифицированный подход, с помощью которого мыищем пути решения определенной проблемы, обеспечивая выполнениепоставленной задачи.

В контексте инженерного проектирования можноопределить цель проектирования как создание системы, которая:• удовлетворяетзаданным(возможно,неформальным)функциональным спецификациям;• согласована с ограничениями, накладываемыми оборудованием;• удовлетворяетявныминеявнымтребованиямпоэксплуатационным качествам и потреблению ресурсов;• удовлетворяет явным и неявным критериям дизайна продукта;• удовлетворяет требованиям к самому процессу разработки, таким,например, как продолжительность и стоимость, а такжепривлечение дополнительных инструментальных средств.В другой формулировке, цель проектирования - выявление ясной иотносительно простой внутренней структуры, называемой архитектуройсистемы.

Проект есть окончательный продукт процесса проектирования.Проектирование подразумевает учет противоречивых требований. Егопродуктами являются модели, позволяющие понять структуру будущейсистемы, сбалансировать требования и наметить схему реализации.Таким образом, под проектом программного обеспечения (ПО)будем понимать совокупность спецификаций ПО (включающих модели ипроектную документацию), обеспечивающих создание ПО в конкретнойпрограммно-технической среде.Проектирование ПО представляет собой процесс созданияспецификаций ПО на основе исходных требований к нему.Проектирование ПО сводится к последовательному уточнению егоспецификаций на различных стадиях процесса создания ПО.Современные крупномасштабные проекты программных системхарактеризуются, как правило, следующими особенностями:• структурная, функциональная и информационная сложностьобъекта внедрения;• высокая техническая сложность, определяемая наличиемсовокупности тесно взаимодействующих компонентов (подсистем),имеющих свои локальные задачи и цели функционирования(транзакционных приложений, предъявляющих повышенные4•••••требования к надежности, безопасности и производительности, иприложений аналитической обработки (систем поддержкипринятия решений), использующих нерегламентированныезапросы к данным большого объема);отсутствие полных аналогов, ограничивающее возможностьиспользования каких-либо типовых проектных решений иприкладных систем, высокая доля вновь разрабатываемого ПО;большое количество и высокая стоимость унаследованныхприложений(существующегоприкладногоПО),функционирующих в различной среде (персональные компьютеры,миникомпьютеры, мэйнфреймы), необходимость интеграцииунаследованных и вновь разрабатываемых приложений;территориальнораспределеннаяинеоднороднаясредафункционирования (СУБД, операционные системы, аппаратныеплатформы);большое количество участников проекта как со стороны заказчиков(с разнородными требованиями), так и со стороны разработчиков(более 100 человек), разобщенность и разнородность отдельныхгрупп разработчиков по уровню квалификации, сложившимсятрадициям и опыту использования тех или иных инструментальныхсредств;значительная длительность жизненного цикла системы.В конце 60-х годов прошлого века в США было отмечено явление подназванием "software crisis" (кризис ПО).

Это выражалось в том, чтобольшие проекты стали выполняться с отставанием от графика или спревышением сметы расходов, разработанный продукт не обладалтребуемыми функциональными возможностями, производительность егобыла низка, качество получаемого программного обеспечения неустраивало потребителей.Аналитические исследования и обзоры, выполняемые в течение рядапоследних лет ведущими зарубежными аналитиками, показывали неслишком обнадеживающие результаты.

Так, например, результатыисследований, выполненных в 1995 году компанией Standish Group,которая проанализировала работу 364 американских корпораций и итогивыполнения более 23 тысяч проектов, связанных с разработкой ПО,выглядели следующим образом:• только 16,2% завершились в срок, не превысили запланированныйбюджет и реализовали все требуемые функции и возможности;• 52,7% проектов завершились с опозданием, расходы превысилизапланированный бюджет, требуемые функции не былиреализованы в полном объеме;• 31,1% проектов были аннулированы до завершения;5• для двух последних категорий проектов бюджет среднего проектаоказался превышенным на 89%, а срок выполнения - на 122%.В 1998 году процентное соотношение трех перечисленных категорийпроектов лишь немного изменилось в лучшую сторону (26%, 46% и 28%соответственно).В последние годы процентное соотношение трех перечисленныхкатегорий проектов также незначительно изменяется в лучшую сторону,однако, по оценкам ведущих аналитиков, это происходит в основном засчет снижения масштаба выполняемых проектов, а не за счет повышенияуправляемости и качества проектирования.В числе причин возможных неудач, по мнению разработчиков,фигурируют:• нечеткая и неполная формулировка требований к ПО;• недостаточное вовлечение пользователей в работу над проектом;• отсутствие необходимых ресурсов;• неудовлетворительное планирование и отсутствие грамотногоуправления проектом;• частое изменение требований и спецификаций;• новизна и несовершенство используемой технологии;• недостаточная поддержка со стороны высшего руководства;• недостаточно высокая квалификация разработчиков, отсутствиенеобходимого опыта.Однако основная причина всех проблем заключается в ответе навопрос: является ли проектирование ПО ремеслом, инженернойдисциплиной или чем-то средним? Многие разработчики ПО, вероятно,заявят, что программирование хотя и не сложилось в установившуюсяинженерную дисциплину, но уже близко подошло к этому.Однако, можно утверждать, что разработка ПО на сегодняшний деньявляется почти чистым ремеслом.

Все знание о способах разработки ПОосновано исключительно на пробах и ошибках. Конечно, со временизарождения программирования сообщество программистов добилосьнекоторых успехов. Признанные корифеи программирования изобрели впомощь разработчикам ПО успешные методы и правила.

Но, подобносредневековым архитекторам, разработчики ПО изучили и испытали этиметоды путем проб и ошибок. Современным разработчикам не хватаетсистемы основных принципов, на основе которых можно было бы строитьсвои правила и методы. Замечено, что ключевым фактором успеха проектаявляется хорошая архитектура. Именно неспособность регулярносоздавать хорошую архитектуру не дает права разработке ПО называтьсясложившейся инженерной дисциплиной. Для доказательства адекватностипроекта до завершения любых строительных работ инженер, в отличие отпрограммиста, использует систему основных принципов.

Разработчик ПО,с другой стороны, при оценке качества архитектуры должен полагаться на6тестирование. Проще говоря, он должен искать хорошую архитектурупутем проб и ошибок.Это объясняет, почему двумя наиболее явными проблемаминеудачных программных проектов являются переделка программ иобнаружение негодности проекта на его поздних стадиях. Разработчикпроектирует архитектуру на ранних стадиях разработки ПО, но не имеетвозможности сразу же оценить ее качество.

У него отсутствуют под рукойосновные принципы для доказательства адекватности проекта.Тестирование программного обеспечения постепенно выявляет вседефекты архитектуры, но только на поздних стадиях разработки, когдаисправление ошибок становится дорогим и разрушительным для проекта.Почему же идеология проб и ошибок так глубоко проникла вразработку ПО? Для ответа на этот вопрос необходимо понять, чторазработка ПО изначально является проектированием и не имеетпризнаков строительства или производства. Это утверждение труднопринять, но оно может быть легко обосновано.

Все хорошо понимают, чтотакое проектирование, где оно заканчивается и где начинаетсястроительство или производство. Рассмотрим два следующих аргумента:1. Граница между проектированием и строительством всегда четкообозначена чертежом. Проектирование включает в себя все операции,необходимые для создания чертежа, а строительство охватывает всеоперации, необходимые для создания продуктов по этому чертежу. Видеальном случае чертеж должен определять создаваемый продукт во всехподробностях - что, конечно же, бывает очень редко.

Тем не менее, цельючертежа является настолько подробное описание конструируемогопродукта, насколько это возможно. Описывает ли проект архитектурыпрограммной системы создаваемый продукт "во всех подробностях"? Нет.Проект архитектуры предназначен для описания существенных, но,безусловно, не всех подробностей программной системы. Поэтомуочевидно, что проект архитектуры не является чертежом. Все подробностипрограммной системы описываются только кодом на языке высокогоуровня, который, таким образом, является чертежом программы.

Апоскольку все операции, ведущие к созданию чертежа, являютсяпроектированием, то и вся разработка ПО должна считатьсяпроектированием.2. Объем работ (время, деньги, ресурсы), необходимый для созданияпродукта, всегда может быть разделен на проектировочную ипроизводственную составляющие. В чем разница? Объем работпроектирования является общим для всех копий продукта и должен бытьзатрачен только один раз.

Объем работ с точки зрения производствадолжен затрачиваться при создании каждой копии продукта. Программныйпродукт обычно представляет собой двоичный исполняемый файлпрограммы, поставляемой на компакт-диске. Ясно, что усилия посозданию исходного кода программы - включая проект архитектуры,7подробный проект и код на языке высокого уровня - должны бытьзатрачены лишь однажды, независимо от количества выпущенных копийпрограммного обеспечения. Следовательно, усилия по созданиюисходного кода программы являются целиком проектировочными, а всяразработка ПО является проектированием.Разработчики не строят ПО - они его проектируют.

Конечныйрезультат проектирования - код на языке высокого уровня - являетсячертежом ПО. Компилятор и компоновщик механически строятпрограммный продукт - двоичный исполняемый файл - по этомуспроектированному коду. Проект архитектуры программной системынаиболее близко соответствует картонным моделям или эскизам проекта,используемым в некоторых инженерных дисциплинах.Чтобы понять, почему разработчики ПО до сих пор не увидели и ненашли основных принципов, представим себе мир, в котором созданиенебоскреба не требует ничего, кроме подробного чертежа. Имея чертеж,архитектор мог бы одним нажатием кнопки построить небоскреб мгновенно и практически без затрат.