лекции. Лекции по дисциплине _Разработка программных модулей_. Лекции на специальности спо базовой подготовки 09. 02. 07 Информационные системы и программирование 2 Содержание
 Скачать 0.77 Mb.
|
|
Тема 10 Проведение изменений в ПО Обратный инжиниринг. Определение, цели проведения Под реверс-инжинирингом программного обеспечения понимается следующее: Обратная разработка (обратный инжиниринг, реверс-инжиниринг; англ. reverse engineering) — исследование некоторого устройства или программы, а также документации на них с целью понять принцип его работы и, чаще всего, воспроизвести устройство, программу или иной объект с аналогичными функциями, но без копирования как такового. Обратная инженерия (процесс систематического разбора программы (восстановления её исходного текста и структуры) или микросхемы для изучения алгоритмов её работы с целью имитации или повторения некоторых или всех её функций в другой форме или на более высоком уровне абстракции, снятия защиты, изучения алгоритмов, добавления новых возможностей, восстановления протоколов или исправления ошибок и др. Реверс-инжиниринг (Reverse Engineering) или, как его еще называют, обратная разработка, а иногда — обратное проектирование — это процесс анализа приложения для определения его функциональных характеристик, внутренней архитектуры и, собственно, его работы: модулей, функций, алгоритмов. Обобщая, можно утверждать, что реверс-инжиниринг (или обратная разработка) программного обеспечения представляет собой процесс исследования содержимого программы путем ее преобразования в исходный код для определения ее структуры и принципов ее работы. Цели проведения реинжиниринга заключаются в следующем: 67 · получение представления о составе существующей системы; · моделирование существующей системы; · определение фрагментов программного кода, которые могут быть использованы в разрабатываемой новой системе; · определение наследуемых данных. Задачи, решаемые при реинжиниринге, включают: · определение системных архитектур; · определение актеров существующей системы; · определение функциональности существующей системы; · определение логической структуры системы; · восстановление реляционной модели данных. Этапы обратного инжиниринга Начальная фаза. Фиксируется текущее состояние наследуемой системы (все изменения, вносимые в нее после этого момента, при выполнении реинжиниринга не учитываются). Определение системных архитектур. Определяются архитектуры БД, оборудования и стандартного ПО, телекоммуникаций. Все архитектуры представляются в нотации UML и при необходимости дополняются текстовыми описаниями. Автоматический реинжиниринг осуществляется с помощью инструментальных средств визуального моделирования. Ему подвергается как бизнес логика (если есть исходные коды на объектно- ориентированном или объектно-базированном языке), так и БД. Реинжиниринг БД выполняется с помощью инструментальных средств проектирования БД. Результатом является реляционная модель данных, которая может графически отображаться этим средством. Редактирование диаграмм моделей. Главной целью редактирования на этом этапе является достижение наглядности диаграмм. Метод повышения наглядности диаграмм хорошо известен. Это 68 иерархическая реструктуризация. Средством ее осуществления в UML являются пакеты. Сложные ПС обычно включают несколько подсистем, имеющих разное целевое назначение и функциональность. Построение функциональной модели. Модель функционирования описывается с помощью диаграмм ВИ и детализирующих их диаграмм последовательностей и деятельностей. Источником для ее построения является работающая наследуемая система и проводимые с ней эксперименты. Определение актеров. Для нахождения актеров следует искать ответы на следующие вопросы: · Кто является непосредственными пользователями системы? Необходимо при ответе на данный вопрос указывать роли, а не конкретных людей, исполняющих эти роли. Определение вариантов использования выполняется на основе анализа экранов работающей системы. Сначала определяются пакеты ВИ. Для этого следует найти все первичные экраны и для каждого из них в модели на головной диаграмме ВИ завести отдельный пакет. Таким образом, на этой диаграмме будет пакет актеров и несколько пакетов ВИ. Далее выполняется детализация построенных пакетов ВИ на основе анализа экранных форм. Определение взаимодействий актеров и ВИ. В модель включаются ассоциации. Они имеют направления, соответствующие направлениям передачи информации между актерами и ВИ. Распределение по пакетам. Если число актеров или ВИ слишком велико, то для упрощения поддержки модели ВИ целесообразно разделить их по пакетам. Построение навигации экранов. Одновременно с выделением ВИ строится навигация экранов наследуемой системы в виде диаграммы классов UML. Каждый экран показывается в модели как отдельный класс, в котором полям соответствуют атрибуты, функциональным кнопкам – операции, а кнопкам меню – одноименные отношения. 69 Детализация функциональности представляет собой построение сценариев реализации ВИ, представленных в модели ВИ. Она выполняется с помощью диаграмм последовательностей и диаграмм деятельностей UML. Анализ исходных данных Цель процесса анализа и проектирования состоит в разработке технических инструкций, предписывающих, как реализовать ПС, удовлетворяющую сформулированным требованиям. Для этого следует хорошо понять требования к ПС и преобразовать их в проект системы, выбрав правильную стратегию реализации. На ранних стадиях процесса должна быть создана устойчивая архитектура, на основе которой можно спроектировать ПС, легкую для понимания, построения и развертывания. Архитектура должна быть согласована со средой реализации с целью удовлетворения требований к производительности, устойчивости, безопасности, расширяемости и тестируемости. К числу решаемых задач при этом относятся: разработка точной архитектуры распределенной программной системы; преобразование модели требований в модель проектную разрабатываемой системы; адаптация проекта системы к среде реализации с целью повышения производительности разработки; выбор механизмов реализации и определение ограничений на реализацию; разработка компонентной структуры; распределение компонентов по узлам. Главной задачей анализа является преобразование требований в форму, понятную разработчику, то есть, определение подсистем, компонентов и классов, с помощью которых реализуется требуемое поведение ПС. В основе такого преобразования лежат ВИ, созданные при определении требований к 70 ПС. При этом рассматриваются только функциональные требования и игнорируются нефункциональные. В процессе анализа и проектирования создаются следующие документы: Модель проектирования – это основная модель ПС. Она описывает подсистемы, пакеты, компоненты, интерфейсы и классы, а также их взаимодействия, обеспечивающие требуемое поведение ПС. Документ «Архитектура ПС», в котором собраны различные архитектурные представления ПС. Модель данных – это описание структуры данных, хранимых в БД (например, реляционная модель данных). Получение экспертиз. Реверсивный инжиниринг Исследование и обратная разработка программ обычно осуществляются с целью дальнейшей модификации, копирования, или, например, написания генераторов ключей, алгоритм работы которых получен на основе анализа алгоритма их проверки. Также исследование программ применяется с целью получения некоторых закрытых сведений о внутреннем устройстве программы — о протоколе сетевого обмена с сервером, аппаратным средством, ключом защиты или о взаимодействии с другой программой. Ещё одна область применения — получение информации о способах экспортирования данных из многочисленных проприетарных форматов файлов. Такой способ наиболее приемлем в тех случаях, когда создатель первоначальной программы скрыл или не предоставил информацию о производстве конкретного объекта. Осуществляет такой инжиниринг специалист, имеющий квалификацию: «программист» или «инженер компьютерных технологий». Способ широко применяется в производстве, бизнесе, различных отраслях промышленности. Первоначальная программа, переделанная в соответствии с новыми усовершенствованиями, позволяет добиться наилучших результатов при 71 изготовлении готовой продукции и запасных частей к различным устройствам. Инжиниринг использует при этом: Машинный анализ кода. Составление алгоритма. Выработку кода. Выделяет особенности и спецификации. Вносит усовершенствования. Использует некоторые элементы идентичности. Заменяет драйвер собственным. С развитием Интернета популярные операционные системы и программы всё интенсивнее исследуются на предмет обнаружения в них уязвимостей или т. н. «дыр». В дальнейшем найденные дыры могут использоваться для получения несанкционированного доступа к удалённому компьютеру или компьютерной сети. C другой стороны, обратная разработка применяется при исследовании антивирусными компаниями вредоносного ПО c целью добавления его сигнатур в базы своих продуктов. В настоящее время под словами «reverse engineering» чаще всего понимается т. н. clean room reverse engineering, то есть процесс, при котором одна группа разработчиков анализирует машинный код программы, составляет алгоритм данной программы на псевдокоде либо, если программа является драйвером какого-либо устройства, составляет исчерпывающие спецификации интересующего устройства. После получения спецификаций другая группа разработчиков пишет собственный драйвер на основе полученных спецификаций или алгоритмов. Такой подход позволяет избежать обвинений в нарушении авторских прав на исходную программу. Результат обратной разработки редко идентичен оригиналу, что и позволяет избежать ответственности перед законом, особенно при условии контроля отсутствия 72 этой идентичности первой группой разработчиков и отсутствия нарушений торговых марок и патентов. Методики проведения обратного инжиниринга Обратная разработка программного обеспечения основана на следующих способах, применяющихся в производстве и бизнес-сфере: Постоянный обменный анализ данных любого протокола. Здесь используют анализатор шины, а также пакетный сниффер. Дизассемблирование – метод считывания прямого кода машины и используемого языка. Применяется к любой компьютерной программе. Считается длительным процессом. Декомпиляция – создание ключевого кода программы с помощью определенного языка программирования. Язык выбирает инженер- программист. Использование первоначальной базы данных. Это позволяет создать конкретную модель. Аналитика исходного кода и создание нужной программы предоставляют возможность восстановления исходного кода проекта, который был первоначальным. Это позволяет образовать связи между классами и блоками различных бизнес-процессов. Реверс часто применяется в отношении форматов, которые поддерживаются программой Microsoft Office. В ряде инструментов UML процесс импорта и анализа исходного кода для создания диаграмм UML называется «обратным проектированием». Хотя UML является одним из подходов к обеспечению «обратного проектирования», недавние достижения в области международных стандартов привели к разработке Метамодели обнаружения знаний (KDM). Стандарт предоставляет онтологию для промежуточного (или абстрактного) представления конструкций языка программирования и их взаимосвязей. Стандарт группы управления объектами (который также становится стандартом ISO), KDM начал завоевывать промышленность с помощью разработки инструментов и сред анализа, которые могут обеспечивать извлечение и анализ источника, двоичный и байтовый код. Для анализа исходного кода архитектура гранулярных стандартов KDM позволяет 73 извлекать потоки программной системы (данные, управление и карты вызовов), архитектуры и знания бизнес-уровня (правила, термины и процессы). Стандарт позволяет использовать общий формат данных (XMI), позволяющий коррелировать различные уровни системных знаний для детального анализа (например, первопричина, влияние) или производного анализа (например, извлечения бизнес-процессов). Хотя усилия по представлению языковых конструкций могут быть бесконечными из-за количества языков, непрерывной эволюции языков программного обеспечения и разработки новых языков, стандарт все же позволяет использовать расширения для поддержки широкого набора языков, а также эволюция. KDM совместим с UML, BPMN, RDF и другими стандартами, что позволяет выполнять миграцию в другие среды и, таким образом, использовать системные знания для таких усилий, как преобразование программных систем и анализ уровня предприятия. Оформление кода Стандарт оформления кода (англ. coding standards, coding convention или programming style) — набор правил и соглашений, используемых при написании исходного кода на некотором языке программирования. Наличие общего стиля программирования облегчает понимание и поддержание исходного кода, написанного более чем одним программистом, а также упрощает взаимодействие нескольких человек при разработке программного обеспечения. Стандарт сильно зависит от используемого языка программирования. В целом, исходя из назначения стандарта, обычно он имеет целью добиться такого положения, когда программист достаточной квалификации мог бы дать заключение о функции, выполняемой конкретным участком кода, а в идеале — также определить его корректность, изучив только сам этот участок кода или, во всяком случае, минимально изучив другие части программы. 74 Иными словами, смысл кода должен быть виден из самого кода, без необходимости изучать контекст. Поэтому стандарт кодирования обычно строится так, чтобы за счёт определённого визуального оформления элементов программы повысить информативность кода для человека. Обычно, стандарт оформления кода описывает: способы выбора названий и используемый регистр символов для имён переменных и других идентификаторов: запись типа переменной в её идентификаторе (венгерская нотация) и регистр символов (нижний, верхний, «верблюжий», «верблюжий» с малой буквы), использование знаков подчёркивания для разделения слов; стиль отступов при оформлении логических блоков — используются ли символы табуляции, ширина отступа; способ расстановки скобок, ограничивающих логические блоки; использование пробелов при оформлении логических и арифметических выражений; стиль комментариев и использование документирующих комментариев. Основные принципы распространённых стандартов кодирования в последнее время оказывают влияние на синтаксис вновь создаваемых языков программирования. В некоторых из них соглашения, ранее применявшиеся только в стандартах кодирования, стали обязательными элементами синтаксиса. В результате, если ранее недисциплинированный программист мог игнорировать стандарты кодирования из личных соображений, ради удобства или скорости написания кода, то теперь, при работе на новых языках, соблюдение стандартов в определённой мере контролируется транслятором. Реинжиниринг 75 Реинжиниринг – это процесс создания нового или преобразования существующего ПО с целью улучшения характеристик качества, поддерживаемой им функциональности, понижения стоимости сопровождения, уменьшения вероятности возникновения значимых для заказчика рисков. Реинжиниринг подразумевает использование уже имеющегося в эксплуатации у заказчика программного обеспечения в качестве базиса, основы для работы. Реинжиниринг включает в себя следующие виды работ: анализ исходного ПО; изучение и анализ исходного кода (если применимо); анализ слабых мест исходного ПО; исследование возможностей исходного ПО и подробное их документирование восстановление архитектуры исходного ПО; анализ рисков и выработка шагов к их нейтрализации; составление технического задания на новое ПО; трансформация восстановленной архитектуры к желаемой новой архитектуре; тестирование нового ПО; установка и настройка нового ПО; конвертация накопленных данных на новое ПО; документирование новой системы; обучение персонала (если необходимо). Реинжиниринг имеет несомненные достоинства для заказчика, использующего наработанный годами опыт, бизнес-логику, а также функционал автоматизирующий уникальные процессы предприятия. Для исполнителя же реинжиниринг является довольно сложной задачей, требующей высокой квалификации разработчиков. Это связано со следующими проблемами: 76 Необходимость разбора чужого исходного кода. Такую задачу не может сделать программист низкой и средней квалификации. Даже профессионалы часто не могут качественно реализовать его. Поэтому требуется работа специалистов с большим опытом и знанием различных технологий. Необходимость расширения границ существующего функционала, но при этом обязательная совместимость с предыдущими версиями. Риски изменения функционала «в живую» – на работающем предприятии, в режиме реального времени. Именно поэтому стоимость реинжиниринга зачастую выше стоимости разработки с нуля. В то же время, если изначально программа обладала строгой и ясной архитектурой, то провести реинжиниринг будет проще. Поэтому при проектировании, как правило, анализируется, что выгоднее - провести реинжиниринг, или разработать программный продукт "с нуля". Анализ интерфейса Графический интерфейс пользователя (Graphical user interface, GUI) – разновидность пользовательского интерфейса, в котором элементы интерфейса (меню, кнопки, значки, списки и т. п.), представленные пользователю на дисплее, исполнены в виде графических изображений. Проверяется в целом общий вид приложения и в отдельности формы, расположенные на странице. Общие проверки: • Вид элементов при уменьшении окна браузера + появление скрола • Правильность написания текста + текст должен быть выровнен • Правильность перемещения фокуса в окне (Tab / Tab+Shift) • Выбранные элементы выделяются • Неизменяемые поля выглядят одинаково и отличаются от редактируемых • Желательно не использовать двойной клик 77 • Проверка наличия нужных нотификейшенов • Унификация дизайна (цвет, шрифт, размер) • При необходимости должны быть тултипы • Изменение вида элемента при ховере на него • Если формы дублируются, то должны быть одинаковые названия • Дополнительные проверки для веб-форм Основные моменты при проверке GUI: • расположение, размер, цвет, ширина, длина элементов; возможность ввода букв или цифр • реализуется ли функционал приложения с помощью графических элементов • размещение всех сообщений об ошибках, уведомленией (а также шрифт, цвет, размер, расположение и орфография текста) • читабелен ли использованный шрифт • переходит ли курсор из текстового в поинтер при наведении на активные элементы, выделяются ли выбранные элементы • выравнивание текста и форм • качество изображений • проверить расположение и отображение всех элементов при различных разрешениях экрана, а также при изменении размера окна браузера (проверить, появляется ли скролл) • проверить текст на орфографические, пунктуационные ошибки • появляются ли тултипы (если есть необходимость) • унификация дизайна (цвета, шрифты, текст сообщений, названия кнопок и т.д.) Наиболее распространенные баги: • курсор не переходит в поинтер при наведении на активный элемент • орфографические и грамматические ошибки • не ровное расположение полей ввода в формах, самих форм 78 • неправильное отображение элементов при смене размера окна браузера и масштаба страницы • изменение размера текста при смене языка • неровное расположение форм • разные шрифты • выбранные элементы не отличаются от не выбранных Список использованных источников 1. Орлов С.А., Цилькер Б.Я. Технологии разработки программного обеспечения: Учебник для вузов./С.А.Орлов, Б.Я.Цилькер- 4-е изд. Стандарт третьего поколения. – СПб.: Питер, 2018 – 608 с. 2. Златопольский Д.М. Основы программирования на языке Python./Д.М.Златопольский – М.: ДМК Пресс, 2017. – 284 с. 3. Гэддис Т. Начинаем программировать на Python. /Т.Геддис – 4-е изд.: Пер. с англ. – СПб.: БХВ-Петербург, 2019. – 768 с. 4. Лучано Рамальо Python. К вершинам мастерства./Л.Ромальо – М.: ДМК Пресс, 2016. – 768 с. 5. Свейгарт, Эл. Автоматизация рутиных задач с помощью Python: практическое руководство для начинающих./Эл.Цвейгарт- Пер. с англ. — М.: Вильямc, 2016. – 592 с. 6. Рейтц К., Шлюссер Т. Автостопом по Python. /К.Рейтц, Т.Шлюссер – СПб.: Питер, 2017. – 336 с.: ил. – (Серия «Бестселлеры O’Reilly»). 7. Любанович Билл Простой Python. Современный стиль программирования. /Б.Лобанович– СПб.: Питер, 2016. – 480 с.: – (Серия «Бестсепперы O’Reilly»). 8. Павловская Т.А. С#. Программирование на языке высокого уровня. /Т.А.Павловская-СПб.: Питер, 2014 9. Федоров, Д. Ю. Программирование на языке высокого уровня Python : учебное пособие для прикладного бакалавриата / Д. Ю. Федоров. – 2-е изд., 79 перераб. и доп. – Москва : Издательство Юрайт, 2019. – 161 с. – (Бакалавр. Прикладной курс). – ISBN 978-5-534-10971-9. – Текст: электронный // ЭБС Юрайт [сайт]. – URL: https://urait.ru/bcode/437489 (дата обращения: 13.02.2020). 10. Шелудько, В. М. Основы программирования на языке высокого уровня Python: учебное пособие / В. М. Шелудько. – Ростов-на-Дону, Таганрог: Издательство Южного федерального университета, 2017. – 146 c. – ISBN 978-5-9275-2649-9. – Текст: электронный // Электронно-библиотечная система IPR BOOKS: [сайт]. – URL: http://www.iprbookshop.ru/87461.html (дата обращения: 13.02.2020). – Режим доступа: для авторизир. пользователей |