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

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

Программисты говорят о них,как об основных инструментах;• когда она автоматизирует утомительные и подверженные ошибкамдействия. Компиляторы, электронные таблицы и средствауправления конфигурацией ПО настолько важны, что некоторыепрограммисты даже не упоминают о них как об инструментах, апросто предполагают их присутствие;• когда она облегчает общение между людьми, В средераспределенной разработки ПО все виды инструментов обменаинформацией помогают команде работать.Технология не должна действовать против характера культурныхценностей и познавательной способности человека.12При этом следует четко понимать: при всех достоинствах быстройразработки ПО этот подход не является универсальным и применим тольков проектах определенного класса. Для характеристики таких проектовАлистер Коберн ввел два параметра - критичность и масштаб.Критичность определяется последствиями, вызываемыми дефектами в ПО,и может иметь один из четырех уровней:• C - дефекты вызывают потерю удобства;• D - дефекты вызывают потерю возместимых средств(материальных или финансовых);• E - дефекты вызывают потерю невозместимых средств;• L - дефекты создают угрозу человеческой жизни.Масштаб определяется количеством разработчиков, участвующих впроекте:• от 1 до 6 человек - малый масштаб;• от 6 до 20 человек - средний масштаб;• свыше 20 человек - большой масштаб.По оценке Коберна, быстрая разработка ПО применима только впроектах малого и среднего масштаба с низкой критичностью (C или D).Общие принципы оценки технологий в таких проектах заключаются вследующем:• интерактивное общение лицом к лицу - это самый дешевый ибыстрый способ обмена информацией;• избыточная "тяжесть" технологии стоит дорого;• более многочисленные команды требуют более "тяжелых" иформальных технологий;• большая формальность подходит для проектов с большейкритичностью;• возрастание обратной связи и коммуникации сокращаетпотребность в промежуточных и конечных продуктах;• дисциплина, умение и понимание противостоят процессу,формальности и документированию;• потеря эффективности в некритических видах деятельности вполнедопустима.Одним из наиболее известных примеров практической реализацииподходабыстройразработкиПОявляется"Экстремальноепрограммирование" (Extreme Programming - XP).

XP предназначен длянебольших компактных команд, нацеленных на получение как можноболее высокого качества и продуктивности. Метод достигает этогопосредством насыщенной, неформальной коммуникации, приданием наперсональном уровне особого значения умению и навыкам, дисциплине ипониманию, сводя к минимуму все промежуточные рабочие продукты.13Глава 1. Методические аспекты проектирования ПО1.1.

Общие принципы проектирования системОдной из основных проблем, которые приходится решать присоздании больших и сложных систем любой природы, в том числе и ПО,является проблема сложности. Ни один разработчик не в состоянии выйтиза пределы человеческих возможностей и понять всю систему в целом.Единственный эффективный подход к решению этой проблемы, которыйвыработало человечество за всю свою историю, заключается в построениисложной системы из небольшого количества крупных частей, каждая изкоторых, в свою очередь, строится из частей меньшего размера, и т.д., дотех пор, пока самые небольшие части можно будет строить из имеющегосяматериала. Этот подход известен под самыми разными названиями, срединих такие, как "разделяй и властвуй" (divide et impera), иерархическаядекомпозиция и др. По отношению к проектированию сложнойпрограммной системы это означает, что ее необходимо разделить(декомпозировать) на небольшие подсистемы, каждую из которых можноразрабатывать независимо от других.

Это позволяет при разработкеподсистемы любого уровня держать иметь дело только с ней, а не со всемиостальными частями системы. Правильная декомпозиция являетсяглавным способом преодоления сложности разработки больших системПО. Понятие "правильная" по отношению к декомпозиции означаетследующее:• количество связей между отдельными подсистемами должнобыть минимальным (принцип "слабой связанности" - LowCoupling);• связность отдельных частей внутри каждой подсистемыдолжна быть максимальной (принцип "сильного сцепления" High Cohesion).Более подробно эти принципы будут рассмотрены в рамках объектноориентированного анализа.Структура системы должна быть такой, чтобы все взаимодействиямежду ее подсистемами укладывались в ограниченные, стандартныерамки.

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

Второй, объектноориентированный подход использует объектную декомпозицию. При этомструктура системы описывается в терминах объектов и связей междуними, а поведение системы описывается в терминах обмена сообщениямимежду объектами.В 1970 - 1980-х г.г. при разработке ПО достаточно широкоприменялись структурные методы, предоставляющие в распоряжениеразработчиков строгие формализованные методы описания проектныхрешений - спецификаций ПО (в настоящее время такое жераспространение получают объектно-ориентированные методы). Этиметоды основаны на использовании наглядных графических моделей: дляописания архитектуры ПО с различных точек зрения (как статическойструктуры, так и динамики поведения системы) используются схемы идиаграммы. Наглядность и строгость средств структурного и объектноориентированного анализа позволяет разработчикам и будущимпользователям системы с самого начала неформально участвовать в еесоздании, обсуждать и закреплять понимание основных техническихрешений.

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

Если все же удается создать строгую систему проектныхдокументов, то ее переработка при появлении серьезных измененийпрактически неосуществима. Ручная разработка обычно порождаласледующие проблемы:• неадекватная спецификация требований;• неспособность обнаруживать ошибки в проектных решениях;• низкое качество документации, снижающее эксплуатационныехарактеристики;• затяжной цикл и неудовлетворительные результаты тестирования.С другой стороны, разработчики ПО исторически всегда стоялипоследними в ряду тех, кто использовал компьютерные технологии для15повышения качества, надежности и производительности в своейсобственной работе (феномен "сапожника без сапог").Перечисленные факторы способствовали появлению программнотехнологических средств специального класса - CASE-средств,реализующих CASE-технологию создания ПО.

Понятие CASE (ComputerAided Software Engineering) используется в настоящее время в весьмашироком смысле. Первоначальное значение этого понятия, ограниченноетолько задачами автоматизации разработки ПО, в настоящее времяприобрело новый смысл, охватывающий большинство процессовжизненного цикла ПО.Появлению CASE-технологии и CASE-средств предшествовалиисследования в области программирования: разработка и внедрениеязыков высокого уровня, методов структурного и модульногопрограммирования, языков проектирования и средств их поддержки,формальных и неформальных языков описаний системных требований испецификаций и т.д.

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

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