Дж. Рамбо, М. Блаха - UML 2.0 - Объектно-ориентированное моделирование и разработка (1158633), страница 116
Текст из файла (страница 116)
Чем больше имеется информации, тем меньше остается простора для индивидуальных интерпретаций. ° Не бойтесь приближенных результатов. Вполне допустимо потратить разумное количество времени на извлечение 80;4 информации о сути приложения. Получить оставшиеся 20 Ж вы сможете с помощью методик обычной разработки (таких как интервью с опытными пользователями). Многих нервирует неточность результатов, поскольку она означает работу с иной парадигмой, отличающейся от парадигмы разработки приложений. ° Будьте готовы к нестандартным конструкциям.
Иногда даже опытные разработчики используют необычные конструкции. В некоторых случаях вам не удастся построить полную и точную модель, потому что такой модели никогда не существовало. ° Следите за согласованностью стиля. Программное обеспечение обычно разрабатывается в рамках единой стратегии. Даже нарушения хорошего стиля должны быть одинаковыми во всем приложении. Поэтому вы можете определить стратегию даже по части приложения. 486 Глава 23 ° Унаследованные системы 23.6. Обертка Иногда попадаются хрупкие и трудные для понимания приложения, написанные очень давно, с утерянной документацией и без поддержки разработчиков. Любые изменения могут угрожать жизнеспособности этих приложений.
Поэтому многие организации стремятся ограничить внесение изменений в такие приложения. Вместо этого код изолируют, а вокруг него строят обертку. Обертка (итаррег) — это совокупность интерфейсов, управляющих доступом к системе. Она состоит из пограничных классов, предоставляющих соответствующие интерфейсы, а потому должна разрабатываться в соответствии с принципами объектно-ориентированного программирования. Методы пограничных классов вызывают методы системы, используя существующие операции. Пограничный метод может задействовать несколько существующих операций и объединять данные из различных источников. Вызовы методов унаследованного приложения могут выглядеть сумбурно, но пограничные классы скрывают это от внешних клиентов.
Исходный код может и не быть объектно-ориентированным. Обертки сохраняют форму унаследованного программного обеспечения и дают возможность использовать его функциональность. Функциональность существующих приложений может быть трудной для понимания, непредсказуемой или сложной. Часто достаточно бывает извлечь ядро функциональности, наиболее фундаментальное, простое в использовании и хорошо протестированное. В этом случае обертка даст удобный интерфейс этой функциональности.
Некоторые составляющие старого приложения теряются, но обычно лишь наиболее сомнительные. Новую функциональность обычно можно добавить в виде отдельного пакета. Проектируйте этот пакет в соответствии с принципами объектно-ориентированного программирования. Старайтесь минимизировать взаимодействие с существующей системой и сохранять однородность этого взаимодействия. В качестве примера рассмотрим веб-приложение. Исходное банковское приложение написано на Коболе и работает на старом аппаратном обеспечении. Обертка предоставляет доступ к логике Кобола через объектно-ориентированные методы, которые можно присоединить к современному веб-интерфейсу.
Унаследованный код все равно будет нуждаться в обслуживании, но на это никак не повлияет существование веб-интерфейса. Фактически исполняемый код вебприложения может быть неаккуратным, но он будет работать до тех пор, пока обслуживание логики на Коболе не будет затрагивать методы обертки. Обертка обычно используется лишь в качестве временного решения, потому что она бывает серьезно ограничена организацией унаследованного программного обеспечения (обычно акцидентальной).
Сама по себе комбинация старого кода, обертки и нового кода в новом формате становится настолько неудобной, что ее приходится переписывать заново. Синд предлагает использовать ХМЕ для взаимодействия унаследованного программного обеспечения с внешним миром [Япеес1-01]. Он также отмечает, что обертки служат не только технологическим, но и общественным целям. Тех, кто занимается обслуживанием старого кода, обертка не беспокоит. Обертки помогают 23.8. Резюме 48У программистам сохранять неизменными их мысленные модели программного обеспечения. Это помогает в повседневном обслуживании заключенного в обертку кода.
23.7. Обслуживание В литературе по программному обеспечению обслуживание рассматривается как нечто монолитное, но мы предпочитаем точку зрения Райлича и Беннетта. Согласно [Ва~йсЬ-ОО], программное обеспечение проходит пять стадий: ° Начальная разработка. Разработчики создают программное обеспечение. ° Развитие. Программа претерпевает серьезные изменения в функциональности и архитектуре. Для поддержания его качества может быть использован рефакторинг. ° Обслуживание. Доступные технические таланты сокращаются. Изменения сводятся к небольшим исправлениям и простым корректировкам функциональности. На этом этапе программа начинает неуклонно устаревать. Здесь уместно использовать технологию создания оберток.
° Постепенное прекращение работы. Производитель продолжает получать прибыль, но уже планирует вывод программы из употребления. ° Прекращение работы. Продукт удаляется с рынка, клиенты переводятся на другое обеспечение. Эти пять этапов не разделены жесткими стенами. Технический уровень качества программы непрерывно убывает с течением времени.
Авторы отмечают, что данную последовательность этапов могут переживать отдельные версии программных продуктов, сменяемые новыми версиями. Цель разработки программного обеспечения состоит в том, чтобы замедлить спад и продержать программу на этапах развития и обслуживания как можно дольше. В любом случае, менеджеры обычно стремятся к тому, чтобы избежать внезапного устаревания программы, и стараются заранее предусмотреть такой исход. 23.8.
Резюме Предметом разработки чаще всего бывает не создание новых приложений, а развитие существующих. Вы, как разработчик, должны уметь модифицировать существующие приложения и обеспечивать интеграцию с ними. Вы можете унаследовать от старого приложения требования, идеи, данные и код. Основная технология, используемая в работе с унаследованными приложениями, — инженерный анализ. Назначение инженерного анализа — сохранение информации из старых систем и перенесение ее в новые системы. Инженерный анализ не предназначен для увековечения прошлых ошибок.
Вы должны исключить все ошибки, которые вам удастся обнаружить. Это просто дополнительный источник требований для новых приложений, однако важность его велика. Входных данных для инженерного анализа может быть довольно много, и вы должны быть готовы использовать их все. Выходными данными инженерного анализа являются модели. 488 Глава 23 ° Унаследованные системы Таблица 23.2. Ключевые понятия главы инженерный анализ обертка прямое конструирование поддержка Библиографические замечания [ВасЬшап-89] утверждает, что большинство информационных систем строятся на базе старых программ, и только в исключительных случаях создается что-то новое.
Это относится не только к информационным системам, но и к программному обеспечению вообще. Книга (СЬ!]го1зйу-90] оказала больше влияние на стандартизацию терминологии инженерного анализа. [Ко!!шапп-01] рассказывает о том, каким образом следует восстанавливать модель классов из исходного кода на основании тестовых запусков. Тестовые запуски часто не могут полностью подтвердить гипотезы о модели классов, но они могут помочь понять ее или подсказать правильное решение. В книге [Впеед-96] приводится базовый подход к преобразованию процедурной программы на языке Кобол в объектно-ориентированное представление. Литература [ВасЬшап-89] СЬаг1ез ЪЧ.
ВасЬшап. А регзопа! сЬгошс!е: Сгеайпй Ьегсег !п1оппаг!оп зузгешз, тг!гЬ зоше 8шг]1п8 рппс!р!ез. 1ЕЕЕ Тгапзасг!опз оп Кпотг!ег]8е апг] Пата Епй!пеег!п8 1, 1 [МагсЬ 1989), 17 — 32. Начинайте работу с построения модели классов. Перенесите в нее классы, ассоциации и обобщения. Мы рекомендуем строить модель классов в три этапа, которые мы называем восстановлением реализации, восстановлением проектирования и восстановлением анализа. На каждом этапе количество решений по интерпретации программы возрастает.
Затем приступайте к построению модели взаимодействия, связывая ваше понимание поведения программы с моделью классов. Вы можете начать с процедурного кода и при помощи разделения на слои получить порции логики, относящиеся к различным объектам. Разделение на слои позволяет преобразовать процедурный код в объектно-ориентированный.
В конечном итоге вы должны представить модель взаимодействия в виде совокупности диаграмм деятельности и последовательности. При необходимости постройте модель состояний. Делать это нужно в последнюю очередь. При этом полезно обращаться к диаграммам последовательности. Инженерный анализ отличается от разработки и требует другого образа мышления. Мы привели несколько советов, помогающих настроиться на нужный лад. Обертки — альтернативный метод работы с унаследованными приложениями. Вы можете рассматривать такое приложение как черный ящик и создать вокруг него удобные интерфейсы. После этого новые приложения смогут обращаться к функциональности старого посредством оберток.
,ь4~ Система графических ~. обозначений 0М~ На внутренней стороне обложки книги приведены графические обозначения, используемые в моделях классов, состояний и взаимодействия. Вы можете использовать их в качестве краткого справочника при построении или интерпретации диаграмм. Однако мы должны предупредить вас, что новичку будет сложно разобраться в этих обозначениях.
Чтобы понять концепции, для которых используются эти обозначения, вы должны изучить первую часть нашей книги. Чтобы научиться применять обозначения и концепции в течение жизненного цикла программного обеспечения, изучите главы 2 и 3. Для поиска нужного материала можно использовать алфавитный указатель. За исключением названий концепций и примечаний, все элементы диаграмм, текстовые названия и символы пунктуации входят в систему графических обозначений. Названия на диаграммах (такие как С1аы, аипбше1, оретайоп и епепг2) указывают на элементы, к которым они относятся.
Вы можете изменить синтаксис имен и объявления атрибутов и сигнатур, чтобы согласовать их с синтаксисом языка реализации. Большинство приведенных элементов не относятся к обязательным (особенно на ранних этапах моделирования). Даже на этапе проектирования не следует перегружать модель лишними названиями и обозначениями. Например, если у полюсов ассоциации указаны имена, давать имя самой ассоциации уже не обязательно.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
