Реинжиниринг программы что это

Техники сопровождения. Понимание программных систем. Реинжиниринг. Обратный инжиниринг.

Данная секция вводит некоторые общепринятые техники, используемые в процессе сопровождения программных систем.

Понимание программных систем (Program Comprehension)

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

4.2 Реинжиниринг* (Reengineering)

Реинжиниринг определяется как детальная оценка (examination) и перестройка программного обеспечения для формирования понимания, воссоздания (на уровне модели и, в ряде случаев, требований) и дальнейшей реализации его в новой форме (например, с использованием новых технологий и платформ, при сохранении существующей и расширением и облегчением возможностей добавлений новой функциональности). Отмечается, что в индустрии существуют различные позиции в отношении реинжиниринга – одни считают, что реинжиниринг является наиболее радикальной и затратной формой изменений программных систем, другие, что такой подход может применяться и для не столь кардинальных изменений (например, как смена платформы или архитектуры). Реинжиниринг, обычно, провидится не столько для улучшения возможностей сопровождения (maintainability), сколько для замены устаревшего программного обеспечения. В принципе, реинжиниринг можно рассматривать как самостоятельный проект, включающий в себя, как отмечает SWEBOK, формирование концепции, применение соответствующих инструментов и техник, анализ и приложения опыта проведения реинжиниринга, а также оценку рисков и преимуществ, связанных с такими работами.

Проректор КнАГТУ про реинжиниринг

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

4.3 Обратный инжиниринг* (Reverse engineering)

“Обратный” инжиниринг (часто путаемый с реинжинирингом, в том числе, в понимании SWEBOK) или это процесс анализа программного обеспечения с целью идентификации программных компонент и связей между ними, а также формирования представления о программном обеспечении, с дальнейшей перестройкой в новой форме (уже, в процессе реинжиниринга). Обратный инжиниринг является пассивным, предполагая отсутствие деятельности по изменению или созданию нового программного обеспечения. Обычно, в результате усилий по обратному инжинирингу создаются модели вызовов (call graphs) и потоков управления (control flow graphs) на основе исходного кода системы. Один из типов обратного инжиниринга – создание новой документации на существующую систему (redocumentation). Другой из распространенных типов – восстановление дизайна системы (design recovery).

Процессы: реинжиниринг или оптимизация

К вопросам обратного инжиниринга, как и к вопросам реинжиниринга, также относятся работы по рефакторингу. Рефакторинг – трансформация программного обеспечения, в процессе которой программная система реорганизуется (не переписываясь) с целью улучшения структуры, без изменения поведения. Сохранение “формы” (платформы, архитектурных и технологических решений) существующей программной системы позволяет рассматривать рефакторинг как один из вариантов обратного инжиниринга.

* для обеих тем – 4.2 и 4.3 возможно применение слова реконструкция, в зависимости от контекста, означающее как полную перестройку или воссоздание чего-либо, идентичного по определенным характеристикам оригинальному образцу, так и восстановление какой-либо сущности по сохранившимся и/или доступным внешним признакам, где восстановление может подразумевать опять-таки создание нового образца или представления об оригинальной сущности.

В принципе, возможно объединение тем данной секции, включая реинжиниринг и обратный инжиниринг, в общую тему 4.1 “Reverse and Re-engineering” данной области знаний “Сопровождение”, с дальнейшей детализаций в виде “под-тем” 4.1.x. Такой подход соответствует структуре SWEBOK. При этом, соответствующая структура может быть организована, например, следующим образом:

• 4.1.1 Формирование представления об эксплуатируемой/сопровождаемой системе: включает восстановление, в первую очередь, бизнес- и функциональных требований к системе;
• 4.1.2 Восстановление детального дизайна системы: включает идентификацию всех компонентов системы и создание модели вызовов и других связей между компонентами;
• 4.1.3 Рефакторинг: как возможный процесс структурных изменений, вносимых в систему, в частности для улучшения возможностей по ее дальнейшему сопровождению (включая модификацию, связанную с расширением функциональности);
• 4.1.4 Переработка системы: создание нового релиза/версии системы в той же форме (например, с использованием той же технологической платформы), что и текущая (эксплуатируемая) версия;
• 4.1.5 Создание новой системы: рассматривает текущую версию и систему в целом, как устаревшую – legacy.

Управление SCM-процессом. Организационный контекст SCM. Ограничения и правила SCM. Планирование в SCM. План конфигурационного управления.

Контроль выполнения SCM-процесса.

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

Дата добавления: 2018-05-12 ; просмотров: 937 ; Мы поможем в написании вашей работы!

Источник: studopedia.net

Реинжиниринг программного обеспечения

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

Разнообразие программного обеспечения куда больше, чем технических решений. Так как они решают самые различные задачи, начиная от связи с оборудованием (драйвера) и заканчивая автоматизацией бухгалтерского учета или 3-х мерными играми.

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

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

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

Проходит еще немного времени — от полу-года до 2-х лет и оказывается, что на данной программе больше нельзя работать, так как она «глючит», «тормозит» и вообще перестает работать.

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

А на рынке остались те, кто уехать не смог или кому не было в этом потребности. Предприятию очень повезет, если оно сразу найдет грамотного и ответственного программиста. Как правило, придется перебрать 2-3 человека, прежде, чем они найдут достойную кандидатуру. Однако, грамотные программисты дешево не стоят и постоянно хотят перспектив.

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

Вот, почему, предприятия, которые работают долго и успешно на рынке, в результате приходят к выводу, что для дальнейшего совершенствования программ необходимо нанять компанию-разработчик.

Компании-разработчики

Казалось бы, верный выбор — найти компанию для дальнейшей разработки программы. Но, оказывается не все так просто. Так как на рынке большее количество компаний существует с одной целью — заработать. Такие компании очень умело «раскручивают» на достаточно большие финансы, но при этом очень долго (иногда, до бесконечности) делают проект и никак не выпускают новую версию данной программы. Мне известны проекты, в которых подобные компании «разводили» предприятие на полмиллиона — миллион долларов взамен выдавая (через год-два) полу-фабрикат, который не может работать в реальной обстановке.

Как уберечься от таких компаний? Да никак! От этого нет защиты, есть только советы:

• Не начинайте работать с компанией, даже, казалось бы надежной, сразу над миллионным проектом, начинайте с меньшего — от нескольких тысяч до пару десятков тысяч.
• Посмотрите, что может предоставить данная компания.
• Разбейте работу на этапы и ставьте перед компанией четкие сроки.
• Обязательно, контролируйте выполненную работу.
• Вовремя присылайте найденные ошибки и замечания.
• Посмотрите насколько быстро исправляются ошибки. Успевает ли компания решить большинство ошибок в течении дня — двух или исправление каждой ошибки длится недели — месяцы.

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

Преимущества и недостатки компании-разработчика перед отдельным разработчиком

Теперь, перечислим преимущества и недостатки компании-разработчика перед отдельным разработчиком.

Преимущества компании-разработчика перед отдельным разработчиком:

• Компания может «тянуть» большие и очень большие проекты. Отдельный же разработчик крупный проект может не осилить физически.
• В компании, как правило, работает группа людей с различным образованием, тем самым дополняя и развивая знания друг-друга. В компании-разработчике переплетаются знания людей различных школ. Отдельный же разработчик варится в своем соку. Основной источник знаний у него — книги и Интернет.
• Стандартизация исходного текста в компании значительно выше, чем у отдельного разработчика, т.к. в компании работает группа разработчиков.
• Технически, компании выше оснащены, чем один разработчик.
• Источников информации у компании больше, чем у отдельного разработчика. А это отражается на результате — разрабатываемой программе.
• У компании значительно выше опыт работы с различными проектами, чем у отдельного человека.
• В компаниях больше направлений развития программных средств.
• Компания может предоставить комплексный подход при наличии специалистов различных направлений.
• Все, что тратится по договору с компанией идет в затраты. В то время, как отдельный программист чаще всего работает на зарплату.
• Скорость разработки компании выше, чем у одного человека, т.к. можно подключать к проекту нескольких человек.
• Разрабатывая программный продукт, компания тестирует его и пишет документацию. Отдельный же разработчик часто ленится это делать. А если не ленится и пытается писать документацию или тестировать, то развитие программного продукта временно приостанавливается (на время написания документации или тестирования).
• Компания не уволится.
• Компания не умрет и ее не переедет автобус.
• Компания не заболеет и по этой причине не приостановит поддержку.
• В компании всегда будут люди, которые смогут продолжить дело.
• Компания берет на себя головную боль по поиску высоко-квалифицированных и ответственных программистов.
• Компания следит за технологиями и тенденциями развития программного обеспечения.

Недостатки компании-разработчика перед отдельным разработчиком:

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

Почему компании-разработчики не любят реинжиниринг

Не много компаний реально занимается реинжинирингом программ. Если Вы закажете реинжиниринг, то вероятней всего Вам скажут: и пойдут именно этим путем. В результате Вы получите другую программу, которая может, решит те проблемы, которые были, но которая уже, возможно, будет обладать новыми проблемами. И не обязательно программного решения.

Почему же так не охотно компании берутся за реинжиниринг?

Вот они причины:

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

Рентабельность реинжиниринга

Чаще всего, реинжиниринг программ обходится дороже, чем разработка программы. Причиной этого является то, что нужно соблюдать совместимость новой версии со старой или же реализовывать конвертер старых данных в новые, а так же необходимость обходить ограничения, навязанные предыдущими версиями программ.

Рассмотрим два примера реинжиниринга из жизни.

1-й пример: На одном крупном предприятии с большим количеством филиалов работала программа, разработанная штатным программистом. На некотором этапе, данный программист не смог продолжать работу.

В результате, на предприятии было 2 версии программы: одна старая версия, работающая на BDE и одна новая, но не до конца работающая и доступ к данным в которой был совершенно другой: компоненты прямого доступа. Старую версию пытались установить на филиалах, но без успешно, а в центральном офисе она работала с большими ошибками. Из-за чего, возникали большие очереди из заказчиков и в результате, компания терпела большие убытки. Программа была разработана на Delphi, с использованием сервера базы данных Interbase 6. Таблиц в программе было 10-11 штук, а хранимых процедур и триггеров практически не использовалось.

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

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

В данном проекте реинжиниринг прошел полностью успешно. И программа пошла на дальнейшее развитие.

2-й пример: Один институт более 10 лет разрабатывал программу расчета, CAD-систему. Программа была написана одним инженером, который сам изучил Delphi и написал программу, взяв алгоритмы из программы на Fortran. В качестве базы данных использовались dbf-файлы.

Исходный текст программы написан очень плохо, без форматирования, без наименования компонент человеческими названиями (названия, часто вообще не изменялись и оставлялись такими, как назначал Delphi). Кроме того, система состояла из ряда dll (на каждую форму), исходный текст которых находился в различных каталогах, а файлы юнитов назывались одинаково. Проекты чертежей хранились в отдельных каталогах отдельных баз данных.

Задача: Привести программу к коммерческому виду. Организовать систему защиты от копирования. Организовать систему безопасности на современном уровне. Переделать базу данных на Firebird. Организовать возможность импорта/экспорта информации.

Увеличить возможности графического редактора (например, откат изменений). А так же многое другое такого же типа.

Решение: Исходный текст пришлось полностью переформатировать. Проекты объединять в один exe-файл, а одинаковые юниты удалять. Пришлось построить схему базы данных. В результате оказалось, что база данных избыточная, а структура безграмотно составлена. Систему от копирования организовали.

Но перевод в Firebird оказался практически не возможным, экономически не выгодным. Программа постоянно сбоила. Надежность ее была очень низкая.

В результате получился примерно такой график рентабельности обслуживания+разработки программы (по вертикали — в тысячах $, по горизонтали — в количестве компьютеров, реально работающих с программой):

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

Данная система не работала нигде. Поэтому мы посчитали, что в данном случае полная переделка программы оказалась бы более выгодной в результате, чем реинжиниринг программы.

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

О авторе

Специалисты компании НеРуСофт занимаются разработкой программного обеспечения много лет. Мы всегда стремились добиться идеального программного решения. Для того, чтобы добиться достойного уровня программного обеспечения нам приходилось много раз переделывать программы. В наших программах мы испробовали все, испытав на себе различные технологии. Таким образом, сформировался первый и самый основной опыт переделки программ.

Со временем, нашим опытом воспользовалось ряд достаточно крупных предприятий для реинжиниринга программного обеспечения. Тем самым, мы увеличили и укрепили опыт в этом не простом и тяжелом деле.

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

Так как, в нашей компании много направлений производства, то как правило, заказчики начинают с нами сотрудничать в 2-5 различных направлениях.

Наша цель — не только заработать деньги, но и добиться идеала в разработанных нами программах. Обеспечив, тем самым, успех и процветание наших партнеров.

Источник: codenet.ru

Реинжиниринг программы что это

Откуда берутся требования к системе? Один источник требований мы уже описали – это бизнес-анализ, проводимый в начальной фазе проекта. Вторым таким источником являются ПС, эксплуатируемые в организации. Разработка современных ПС редко когда начинается «с нуля».

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

К сожалению, в RUP реинжинирингу ПС уделено весьма незначительное внимание. Настоящая статья позволит частично восполнить этот пробел.

Цели реинжиниринга

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

Задачи реинжиниринга

Задачи, решаемые при реинжиниринге, включают:
• определение системной архитектуры;
• определение актеров существующей системы;
• определение функциональности существующей системы;
• определение логической структуры системы;
• восстановление реляционной модели данных.

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

Начальная фаза

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

Определение системной архитектуры

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

Автоматический реинжиниринг

Автоматический реинжиниринг осуществляется с помощью инструментальных средств визуального моделирования. Его выполнение позволяет построить модели, которые могут быть приняты как исходные. Автоматическому реинжинирингу подвергается как бизнес логика (если есть исходные коды на объектно-ориентированном или объектно-базированном языке), так и БД.

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

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

Редактирование диаграмм моделей

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

Главной целью редактирования на этом этапе является достижение наглядности диаграмм. Для этого используется перемещение элементов диаграмм. В процессе редактирования могут вноситься комментарии к элементам модели. Например, можно прокомментировать назначение отдельных классов. Комментарии заносятся в поля спецификаций элементов моделей.

Если диаграмма содержит слишком много элементов, то анализировать ее сложно. Попробуйте проанализировать диаграмму, содержащую более 100 классов! Поэтому целесообразно разбить такую диаграмму на несколько отдельных диаграмм, оставляя в каждой примерно по 7 – 10 элементов.

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

Каждый из таких пакетов должен получить имя, отражающее суть соответствующей подсистемы. На этом уровне можно также показать пакеты классов, являющиеся общими для всей системы и используемые подсистемами. На начальной стадии реструктуризации логической модели можно ввести пакет верхнего уровня, куда помещаются классы, которые трудно отнести к какому-либо другому пакету. В любой ПС есть пользовательский интерфейс, связь с БД, управление, обработка, классы данных. Такого типа пакеты можно ввести в каждой подсистеме на следующем уровне иерархии.

Построение функциональной модели

Модель функционирования описывается с помощью диаграмм ВИ и детализирующих их диаграмм последовательностей и деятельностей. Источником для ее построения является работающая наследуемая система и проводимые с ней эксперименты. На этом этапе особенно эффективно привлечение к работам по реинжинирингу эксперта организации заказчика (см. статью «RUP. Общие сведения»).

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

Определение актеров

Для нахождения актеров следует искать ответы на следующие вопросы:
• Кто является непосредственными пользователями системы? Необходимо при ответе на данный вопрос указывать роли, а не конкретных людей, исполняющих эти роли.
• С каким внешним оборудованием или программами осуществляет взаимодействие система?
• Выполняет ли система работы, активизируемые наступлением конкретного времени или истечением определенных интервалов времени (при положительном ответе одним из актеров является таймер)?

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

Актерам следует присвоить имена, отражающие их роли в работе с системой.

Определение вариантов использования

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

Далее выполняется детализация построенных пакетов ВИ на основе анализа экранных форм. Рекомендуемые правила:
• если экран содержит меню, то это пакет ВИ. При этом каждая строка меню – это либо подпакет, либо отдельный ВИ;
• если основной экран – форма, то это отдельный ВИ.

Определение взаимодействий актеров и ВИ

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

Распределение по пакетам

Если число актеров или ВИ слишком велико, то для упрощения поддержки модели ВИ целесообразно разделить их по пакетам. Это также упрощает понимание модели и распределение ответственности путем назначения разработчиков, ответственных за пакеты ВИ. Можно использовать следующие критерии упаковки ВИ в один пакет:
• если они взаимодействуют с одним актером;
• имеют друг с другом отношения включения или расширения.

Могут быть и другие способы обеспечения наглядности модели, важно лишь иметь четкую стратегию разбиения на пакеты.

Построение навигации экранов

Одновременно с выделением ВИ строится навигация экранов наследуемой системы в виде диаграммы классов UML. Каждый экран показывается в модели как отдельный класс, в котором полям соответствуют атрибуты, функциональным кнопкам – операции, а кнопкам меню – одноименные отношения.

Детализация функциональности

Детализация функциональности представляет собой построение сценариев реализации ВИ, представленных в модели ВИ. Она выполняется с помощью диаграмм последовательностей и диаграмм деятельностей UML. Выбор вида диаграмм в каждом конкретном случае зависит от того, что преобладает в данном ВИ – логика выполнения или передачи данных. В первом случае предпочтительно применять диаграммы деятельностей, где легко показывать ветвления и параллельную обработку, во втором – диаграммы последовательностей.

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

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

Варьирование входных данных и анализ реакции системы на эти данные делает возможным обнаружение ветвлений и ограничений. Можно также выдвигать и проверять гипотезы об алгоритмах вычислений.

Модели, построенные в результате реинжиниринга, являются основой для определения требований к проектируемой ПС, а также для построения логической и функциональной моделей новой системы.

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

Источник: www.informicus.ru

Автоматизация реинжиниринга программного обеспечения при портировании на новые библиотеки с помощью частичных спецификаций Текст научной статьи по специальности «Компьютерные и информационные науки»

Аннотация научной статьи по компьютерным и информационным наукам, автор научной работы — Ицыксон Владимир Михайлович

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

i Надоели баннеры? Вы всегда можете отключить рекламу.

Похожие темы научных работ по компьютерным и информационным наукам , автор научной работы — Ицыксон Владимир Михайлович

Профессиональный библиограф составит и оформит по ГОСТ список литературы для вашей работы
Формализм для описания частичных спецификаций компонентов программного окружения
Язык спецификаций поведения программных компонентов

Трансляция фрагментов исходных текстов программ с использованием спецификаций синтаксиса и семантики языков программирования

Автоматизированный реинжиниринг цифровых устройств на основе HDL-СПЕЦИФИКАЦИй

Обзор статических методов восстановления частичных спецификаций программных библиотек на основе анализа программных проектов

i Не можете найти то, что вам нужно? Попробуйте сервис подбора литературы.
i Надоели баннеры? Вы всегда можете отключить рекламу.

Automated Program Reengineering at Porting Software into a New Environments via Partial Specifications

The approach to program reengineering based on the use of environment partial specifications which describe its behavior is considered. Semantic primitives of environment specification and specification creation methods are depicted. Program reengineering is automated using an algorithm which checks compatibility of two environments, analyses the semantics of an old and a new environments and transforms the old environment interface in the new one, thus, porting the program.

Текст научной работы на тему «Автоматизация реинжиниринга программного обеспечения при портировании на новые библиотеки с помощью частичных спецификаций»

X ПРОГРАММНЫЕ И АППАРАТНЫЕ СРЕДСТВА

АВТОМАТИЗАЦИЯ РЕИНЖИНИРИНГА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ПРИ ПОРТИРОВАНИИ НА НОВЫЕ БИБЛИОТЕКИ С ПОМОЩЬЮ ЧАСТИЧНЫХ СПЕЦИФИКАЦИЙ

канд. техн. наук, доцент

Санкт-Петербургский государственный политехнический университет

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

Ключевые слова — библиотека, частичная спецификация, семантика программы, реинжиниринг программ, портирование.

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

Рассмотрим подробнее ситуации, в которых разработчику требуется проводить реинжиниринг программ.

Задачи переноса программ в новое библиотечное окружение

Задача портирования в новую операционную систему (ОС) встает перед разработчиком, когда имеется приложение, функционирующее под управлением одной ОС (например, Windows), которое требуется запускать в другой ОС (например, Linux). Обычно API библиотек в разных ОС отличаются, а сами библиотеки имеют разное функциональное наполнение.

В качестве примера рассмотрим перенос программы, осуществляющей сетевой обмен с помощью сокетов, из ОС Linux в Windows. Отличие

двух программ на языке C состоит в разном программном интерфейсе библиотек BSD-sockets и WinSock. Если не вдаваться в глубокую детализацию, то модификация программы заключается в замене заголовочных файлов; в добавлении функций WSAStartup и WSACleanup, инициализирующих и выгружающих библиотеку WinSock; в изменении некоторых функций API (closesocket вместо close и т. п.) и в изменении некоторых типов данных.

Задача адаптации приложения на новую аппаратную платформу возникает, когда программа, функционирующая на одной платформе (например, Intel x86), должна быть адаптирована для работы в другой платформе (например, на Apple iPhone). Адаптация заключается в интеграции программы с библиотеками, поддерживающими новую аппаратуру.

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

Задача перехода на альтернативные библиотеки встает, когда для достижения поставленной

цели требуется частично модифицировать приложение, и функции, ранее реализованные с использованием одних подходов и библиотек, должны быть переписаны с использованием других. Примерами таких задач являются переход с использования мьютексов на использование семафоров, миграция с библиотеки GTK+ на QT или замена многопроцессного приложения многопоточным.

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

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

Перечисленные ситуации показывают необходимость разработки подходов, позволяющих частично или полностью автоматизировать процесс портирования программы. Наиболее актуально это для языков программирования C и С++, компиляторы которых существуют практически для всех ОС, и с помощью которых реализован огромный объем программного кода.

Стандартные пути проведения портирования

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

Ручное портирование приложения предполагает переход на новые библиотеки путем последовательной замены элементов старой библиотеки новыми. Этот подход является ресурсозатратным и требует длительной отладки и глубокого тестирования преобразованной программы.

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

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

новой. Такой подход наиболее прост в отладке, но накладывает ограничения на степень отличия библиотек друг от друга и требует повторного создания промежуточного слоя при новом портиро-вании.

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

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

В рамках данной работы получены следующие основные результаты:

— определены и классифицированы способы взаимодействия программы с библиотечным окружением;

— предложен формальный аппарат для описания структуры и поведения библиотек;

— предложена методика автоматизированной трансформации программ при портировании в новое библиотечное окружение.

Существующие подходы к проблеме автоматизации реинжиниринга

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

Основные достижения в области трансформации приложений связаны с развитием синтакси-

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

В подходах, основанных на шаблонах, по исходному коду программы строится модель, определяются шаблоны кода, используемые при поиске и трансформации. Далее осуществляется обнаружение участков кода по шаблону и применение трансформаций. Различаются подходы используемыми моделями, языком описания шаблонов и способом задания трансформаций. Примерами таких средств являются InjectJ [1] — система преобразования кода на языке Java, технология модификации программ на основе шаблонов [2] и система ReSharper [3]. Все эти подходы являются сугубо синтаксическими и ограничены необходимостью создания отдельных шаблонов для каждого преобразования.

i Не можете найти то, что вам нужно? Попробуйте сервис подбора литературы.

Многие синтаксические подходы основаны на использовании правил перезаписи (rewriting rules), поддержанных мощными языками трансформаций. Абстрактная система перезаписи [4] включает множество объектов, над которыми выполняется перезапись, и множество отношений, которые задают возможные преобразования элементов из множества друг в друга.

Развитием подхода правил перезаписи является концепция стратегий перезаписи (rewriting strategies) [5]. Данная концепция легла в основу языка трансформации Stratego, реализованного в рамках системы Stratego/XT [6]. В качестве модели программы, над которой выполняется трансформация, используется система аннотированных термов — вариант абстрактных синтаксических деревьев, в которой элементы дерева могут содержать аннотации, дополняющие синтаксическую информацию о программе семантической, которая затем может использоваться в правилах перезаписи.

Еще одним представителем этой группы подходов является язык TXL, предназначенный для разработки различных систем трансформации программ [7]. В основе TXL лежит система перезаписи термов, работа с которой осуществляется при помощи специального функционального языка. Все правила перезаписи записываются в терминах этого языка, а синтаксис языка — в расширенной форме Бэкуса-Науэра. Данный подход получил практическое воплощение в компиляторе FreeTXL [8]. Похожие подходы используются в языке правил перезаписи ASF+SDF [9], реализованном в рамках платформы ASF+SDF Meta Environment, а также в системе DMS [10].

Основным недостатком перечисленных подходов является их синтаксическая ориентированность, ограничивающая их применение в основном только простыми трансформациями, когда

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

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

К наиболее характерным относятся подходы, предназначенные для переноса программ с устаревших языков или технологий программирования на более новые. В работах [11, 12] описывается автоматизация преобразования программ с языка С++ и Java в Java и С# соответственно. Существуют и другие подходы, применяемые для межязыкового портиро-вания программ. Все они используют семантику языков и, иногда, конкретных библиотек для проведения миграции, но возможностей задания семантики целых библиотек и преобразования программ с учетом этой семантики они не предоставляют.

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

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

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

В случае если библиотеки семантически совместимы, то производится преобразование исходной

Исходная п рограмма

‘ Частичная спецификация исходной библиотеки

Источник: cyberleninka.ru