Лекция 5. Модели жизненного цикла. Лекция Модели жизненного цикла по, проектирование как конструирование. Аннотация
 Скачать 0.94 Mb.
|
|
6. Сопровождение Выявление ошибок и их устранение, модернизация. Достоинства каскадной модели: - проста, естественна, имеет некоторую привязку к ГОСТу Недостатки: - достаточно продолжительный цикл разработки по времени (система морально устаревает) 11 - доработка системы связана с большим объемом перепрограммирования (из-за слабого использования CASE-средств) Основным недостатком каскадного подхода является существенное запаздывание с получением результатов. Согласование результатов с пользователями производится только в точках, планируемых после завершения каждого этапа работ, требования к ИС «заморожены» в виде технического задания на все время ее создания. Таким образом, пользователи могут внести свои замечания только после того, как работа над системой будет полностью завершена. В случае неточного изложения требований или их изменения в течение длительного периода создания ПО пользователи получают систему, не удовлетворяющую их потребностям. Модели (как функциональные, так и информационные) автоматизируемого объекта могут устареть одновременно с их утверждением. Результаты исследований Д.Мартина (сер. 80х) 1-я диаграмма: распределение ошибок и просчетов по этапам проектирования, выявленных при сопровождении системы 56 % 27 % 7 % 10 % 1 2 3 4 5 6 этапы ошибки 2-я диаграмма: распределение затрат на исправление ошибок и просчетов, выявленных при сопровождении 82 % 13 % 1 % 4% 1 2 3 4 5 6 средства этапы 3-я диаграмма: распределение трудозатрат по этапам проектирования 40 % 10 % 50 % 1 2 3 4 5 6 этапы средства 12 Почти половина трудозатрат приходится на устранение ошибок, допущенных на первых 2-х этапах. На основании исследований Мартин сформулировал законы: 1. закон неопределенности в информатике: процесс автоматизации задачи меняет представление пользователя об этой задаче, т.е. пользователь решает задачу с использованием средств автоматизации иначе, чем без них (пользователя надо использовать постоянно в процессе проектирования, а не только в начале) 2. чем больше времени прошло с момента совершения ошибки до момента ее обнаружения, тем больше средств необходимо для ее устранения (смотри диаграмму 2) 3. программисты и проектировщики не учатся на чужих ошибках, а только на своих. Спиральная модель Для преодоления перечисленных проблем была предложена спиральная модель ЖЦ делающая упор на начальные этапы ЖЦ: анализ и проектирование. На этих этапах реализуемость технических решений проверяется путем создания прототипов. Каждый виток спирали соответствует созданию фрагмента или версии ПО, на нем уточняются цели и характеристики проекта, определяется его качество и планируются работы следующего витка спирали. Таким образом углубляются и последовательно конкретизируются детали проекта и в результате выбирается обоснованный вариант, который доводится до реализации. Разработка итерациями отражает объективно существующий спиральный цикл создания системы. Неполное завершение работ на каждом этапе позволяет переходить на следующий этап, не дожидаясь полного завершения работы на текущем. При итеративном способе разработки недостающую работу можно будет выполнить на следующей итерации. Главная же задача – как можно быстрее показать пользователям системы работоспособный продукт, тем самым активизируя процесс уточнения и дополнения требований. 13 Основная проблема спирального цикла – определение момента перехода на следующий этап. Для ее решения необходимо ввести временные ограничения на каждый из этапов жизненного цикла. Переход осуществляется в соответствии с планом, даже если не вся запланированная работа закончена. План составляется на основе статистических данных, полученных в предыдущих проектах, и личного опыта разработчиков. Декомпозиция системы на подсистемы 1 2 5 3 4 6 5 4 1 3 2 6 1 2 5 3 4 6 5 4 1 3 2 6 Сопряжение подсистем Сопряжение подсистем CASE-средства Подсистема 2 CASE-средства CASE-средства CASE-средства 1. выбор архитектуры подсистем 2. выявление информационных потребностей конечных пользователей системы 3. концептуальное проектирование 4. логическое проектирование 5. отладка подсистем 6. сопровождение подсистемы Начальный пилотный проект Каждый этап реализуется CASE-средствами. Содержание этапов совпадает с аналогичными в каскадной модели, но в отличие от нее, этапы реализуются с помощью CASE-средств (Computer Aided Software System Design) – (автоматизированная технология создания программных информационных систем) – использование этих средств позволяет существенно снизить время реализации витка спирали проектирования 14 подсистем (в этом состоит основное преимущество спиральной модели), но это профессиональные средства, непредназначенные для конечных пользователей. С помощью CASE-средств можно быстро сгенерировать проект хотя бы на уровне экранных форм и показать его конечному пользователю, который высказывает свои предложения и замечания, и на следующем витке реализуются они. Когда спецификация на уровне экранных форм будет будет согласована, то проектировщик может начинать детальную реализацию. Описанная схема разработки называют визуальным проектированием. Витков может быть много, разделение на этапы условно. Работы могут выполняться параллельно или в комплексной итерации на любом витке спирали. Проектирование как конструирование Идея конструирования информационных систем (ИС) из компонентов развивается на протяжении многих лет. По существу, речь идет о крупноблочном конструировании систем (Д. Видерхольд). Согласно этой идее, целесообразнее осуществлять капиталовложения в создание компонентов, которые можно было бы многократно использовать, чем всякий раз осуществлять разработку ИС сверху – вниз: от спецификаций требований к работающей системе. Во-первых, следует отметить то обстоятельство, что компонентно-ориентированный подход к проектированию и реализации программных систем и комплексов является в некотором смысле развитием объектно-ориентированного и практически более пригоден для разработки крупных и распределенных систем (например, корпоративных приложений). Прежде всего, сформулируем основополагающее для рассматриваемого подхода определение компонента. Под компонентом будем далее иметь в виду независимый модуль программного кода, предназначенный для повторного использования и развертывания. Как видно из определения, применение компонентного программирования призвано обеспечить более простую, быструю и прямолинейную процедуру первоначальной инсталляции прикладного программного обеспечения, а также увеличить процент повторного использования кода, т.е. усилить основные преимущества ООП. Говоря о свойствах компонентов, следует прежде всего отметить, что это существенно более крупные единицы, чем объекты (в том смысле, что объект представляет собой конструкцию уровня языка программирования). Другими отличиями компонентов от традиционных объектов являются возможность содержать множественные классы и (в большинстве случаев) независимость от языка программирования. Естественным требованием к современным информационным системам является способность наращивания их возможностей за счет использования дополнительно разработанных (а еще лучше - уже существующих) программных компонентов. Для этого требуется обеспечение свойства, называемого интероперабельностью. Интероперабельность программного обеспечения (функциональность программного обеспечения) - способность программного продукта выполнять набор функций, определенных в его внешнем описании и удовлетворяющих заданным или подразумеваемым потребностям пользователей. 15 Под этим понимается соблюдение определенных правил или привлечение дополнительных программных средств, обеспечивающих возможность взаимодействия независимо от разработанных программных модулей, подсистем или даже функционально завершенных программных систем. Новейшие технологии обеспечивают техническую возможность интероперабельного использования как программных (OMG CORBA), так и информационных компонент (WWW). Аспекты описания систем Наряду с декомпозицией описаний на иерархические уровни применяют разделение представлений о проектируемых объектах на аспекты. Расчленение (декомпозиция) описаний по характеру отображаемых свойств объекта приводит к появлению ряда аспектов описания. Аспект описания (страта) — описание системы или ее части с некоторой оговоренной точки зрения, определяемой функциональными, физическими или иного типа отношениями между свойствами и элементами. Различают функциональный, информационный, структурный и поведенческий (процессный) аспекты. Функциональное описание относят к функциям системы и чаще всего представляют его функциональными схемами. Информационное описание включает в себя основные понятия предметной области (сущности), словесное пояснение или числовые значения характеристик (атрибутов) используемых объектов, а также описание связей между этими понятиями и характеристиками. Информационные модели можно представлять графически (графы, диаграммы сущность - отношение), в виде таблиц или списков. Структурное описание относится к морфологии системы, характеризует составные части системы и их межсоединения и может быть представлено структурными схемами, а также различного рода конструкторской документацией. Поведенческое описание характеризует процессы функционирования (алгоритмы) системы и (или) технологические процессы создания системы. Иногда аспекты описаний связывают с подсистемами, функционирование которых основано на различных физических процессах. Отметим, что в общем случае выделение страт может быть неоднозначным. Так, помимо указанного подхода очевидна целесообразность выделения таких аспектов, как функциональное (разработка принципов действия, структурных, функциональных, принципиальных схем), конструкторское (определение форм и пространственного расположения компонентов изделий), алгоритмическое (разработка алгоритмов и программного обеспечения) и технологическое (разработка технологических процессов) проектирование систем. Типовые проектные решения – шаблоны проектирования 16 Идея, на которой основывается применение шаблонов проектирования, заключается в том, чтобы выработать стандартизованный подход к представлению общих решений, пригодных для часто встречающихся ситуаций при разработке ПО. Такой подход имеет ряд преимуществ. Со временем можно получить каталог шаблонов. Это позволяет новичкам в разработке ПО более эффективно использовать многолетний опыт их предшественников. Все решения, принимаемые при проектировании ПО, снабжены формализованным описанием, позволяющим оценить как достоинства, так и недостатки того или иного решения. Стандартизованные шаблоны облегчают как для новичков, так и для экспертов в области разработки ПО понимание того, как влияют на архитектуру создаваемой программы те или иные решения. Шаблоны проектирования позволяют всем, кто их использует, "говорить на одном языке". Это, в свою очередь, облегчает взаимопонимание между разработчиками при выборе того или иного решения. Вместо того чтобы детально описывать какое- либо архитектурное решение, мы говорим, какой шаблон мы намерены использовать. Мы можем соотносить шаблоны друг с другом, что позволяет разработчику увидеть, какие шаблоны могут использоваться в одном проекте. Шаблоны проектирования предоставляют в наше распоряжение эффективный способ делиться опытом со всеми участниками сообщества объектно-ориентированного программирования. Независимо от того, каким языком программирования мы владеем (C++, Smalltalk или Java), и того, в какой области мы приобрели опыт проектирования ПО (Web-проекты, интеграция устаревших систем или заказной проект), мы можем накапливать свой собственный опыт и делиться им с другими разработчиками. Если же говорить о долгосрочной перспективе, то данный подход позволяет улучшить состояние дел во всей индустрии разработки ПО. История применения шаблонов Идейным отцом применения шаблонов проектирования при разработке ПО считают профессора архитектуры Университета Калифорнии в Беркли Кристофера Александера (Christofer Alexander). В конце 70-х годов прошлого века он опубликовал несколько книг, в которых изложил основные принципы применения шаблонов в архитектуре, а также поместил каталог архитектурных шаблонов. Именно посвященные шаблонам работы Александера и привлекли внимание к проблеме программистов, интересующихся объектно-ориентированным программированием (ООП). В их среде появились пионеры применения шаблонов в разработке ПО, которые на протяжении последующих десяти лет сформулировали основные принципы этого метода. Среди первопроходцев были Кент Бэк (Kent Beck) и Уард Каннингхэм (Ward Cunningham). В 1987 году на конференции OOPSIA (Object Oriented Programming, Systems, and Applications), посвященной ООП, прозвучал их доклад о применении шаблонов проектирования в языке Smalltalk. Еще одним адептом нового подхода стал Джеймс Коплайен (James Coplien), который в начале 90-х гг написал книгу о применении идиом (т.е. шаблонов) при разработке ПО на языке C++. Ежегодные конференции OOPSLA сослужили хорошую службу для роста сторонников технологии шаблонов, так как на ее мероприятиях энтузиасты могли свободно делиться своими идеями со множеством благодарных слушателей. Кроме того, важную роль в 17 становлении данного направления технологии разработки ПО сыграли конференции некоммерческой организации Hillside Group, создателями которой были Кент Бэк и Гради Буч (Grady Booch). Однако по-настоящему ощутимый вклад в дело популяризации технологии шаблонов проектирования внесла изданная в 1995 году книга Design Patterns: Elements of Reusable Object-Oriented Software. Ее авторы Эрик Гамма (Erich Gamma), Ричард Хелм (Richard Helm), Ральф Джонсон (Ralph Johnson) и Джон Влиссидес (John Vlissides) приложили так много усилий для распространения своих идей, что заслужили шутливое прозвище "Банда четырех" (GoF — gang of four). В книге представлено введение в довольно сложный язык шаблонов с иллюстрациями реализации обсуждаемых шаблонов на языке C++. В это же время началось бурное развитие технологии Java, поэтому неудивительно, что Java-разработчики с самого начала стали применять шаблоны проектирования в своих проектах. Рост популярности технологии шаблонов проектирования среди Java- разработчиков проявился как в виде специальных презентаций на конференциях, таких как JavaOne, так и в появлении отдельной рубрики по шаблонам проектирования практически во всех специализированных журналах по программированию на Java. Основные концепции технологии шаблонов В центре технологии шаблонов лежит идея стандартизации информации о типичной проблеме и о методах ее решения. Один из самых полезных результатов, полученных в работе Александера, состоит в выделении некоторого способа представления шаблонов, который впоследствии был назван формой (form), или форматом (format). В форме Александера применялось пять направлений, по которым формализовалось обсуждение шаблонов и их применение в конкретных ситуациях. Самое главное преимущество такого подхода состоит в том, что даже само название шаблона представляет собой ответ на вопрос: "Что можно сделать с помощью этого шаблона?" Кроме того, в форме содержится: описание проблемной области; пояснение того, как данный шаблон решает означенную проблему; в чем заключаются преимущества, недостатки и, возможно, компромиссы при использовании данного шаблона. Естественно, когда шаблоны были восприняты миром ООП, появились вариации формы Александера, призванные учитывать интересы разработчиков ПО. Большинство из существующих сегодня форм были построены на одной или двух формах, получивших название "Канонических", или форм "Четверки". В данной книге используется одна из вариаций форм "Четверки", согласно которой при представлении шаблонов освещаются следующие вопросы. Название (Name). Слово или выражение, описывающее основное назначение шаблона. Также известен как (Also Known As). Альтернативные названия (если, конечно, таковые имеются). Свойства шаблона (Pattern Properties). Классификация шаблона. Мы будем определять шаблон, используя термины из двух следующих групп. Тип: Производящие шаблоны (Creational patterns), предназначенные для создания объектов. 18 Поведенческие шаблоны (Behavioral patterns), обеспечивающие координацию функционального взаимодействия между объектами. Структурные шаблоны (Structural patterns), используемые для управления статическими, структурными связями между объектами. Системные шаблоны (System patterns), предназначенные для управления взаимодействием на системном уровне. Уровень: Отдельный класс (single class). Шаблон применяется к отдельному, независимому классу. Компонент (component). Шаблон используется для создания группы классов. Архитектурный (architectural). Шаблон используется для координации работы систем и подсистем. Повторное использование и абстракция программного кода Технология шаблонов проектирования стала важным эволюционным этапом в развитии таких концепций, как абстракция (abstraction) и повторное использование (reuse) программного кода. Обе эти концепции занимают центральное место в самой идее программирования (некоторые даже полагают, что они являются важнейшими концепциями). Абстракция — это метод, с помощью кот`орого разработчики могут решать сложные проблемы, последовательно разбивая их на более простые. Затем можно использовать имеющиеся готовые решения полученных типовых простых проблем в качестве строительных блоков, из которых разработчики получают решения, пригодные для реализации повседневных сложных проектов. В ходе развития объектно-ориентированных языков программирования был совершен огромный скачок вперед в области абстракции и повторного использования программного кода. С помощью этой технологии была создана целая плеяда высокопроизводительных методов его создания. Например, чего стоит только одна концепция класса как "эталона" объектов, с ее объединением двух ранее возникших механизмов: функциональной абстракции и абстракции данных. Объединяя структуру сущности (данные) с функциональностью, которая применяется к сущности (поведение), мы получаем эффективный метод повторного использования программного элемента. Помимо основополагающего понятия класса, объектно-ориентированные языки принесли с собой множество других методов использования существующего кода. В качестве примера можно привести такие концепции, как концепции подклассов и интерфейсов, открывших совершенно новые возможности в повторном использовании программного кода при разработке ПО. 19 В столбце "Абстракция" таблицы указаны сущности, для которых выполняется абстракция, а в столбце "Универсальность подхода" показано то, насколько легко применить соответствующий метод, не прибегая к изменениям или переработке кода. Обратите внимание на то, что показатель степени повторного использования очень сильно зависит от эффективности применения того или иного метода на практике. Это понятно, так как любая, даже самая лучшая возможность может быть использована как правильно, так и неправильно. Одной из самых выдающихся возможностей, предоставляемых шаблонами проектирования, является то, что они позволяют разработчикам более эффективно применять другие методы повторного использования программного кода. Шаблон в определенных ситуациях может, например, использоваться как руководство для эффективного управления наследованием или же для эффективного назначения связей между классами, обеспечивая тем самым решение той или иной проблемы. |