Вопросы на модульную контрольную работу №1

1. Основные понятия и определения реинжиниринга.

   Понятие	Чиковски и Кросс	Макклер	Йу
   Software reengineering	Исследования и модификация системы, с целью придания ей новой формы и повторного внедрения	Процесс, исследующий существующую программную систему и или изменяющий ее, с помощью различных автоматизированных средств	Действия, осуществляющие переформатирование существующей системы
   Обратная инженерия (reverse engineering)	Анализ системы, позволяющий в системе выделить компоненты и связи между ними и представить эту систему в другой форме на абстрактном уровне	Процесс ,анализирующий программную систему, с целью реконструкции описания ее компонент и связей между ними	Действия, направленные на получение описания внутренних спецификаций проекта и компонент из существующей системы
   Design recovery	Расширение обратной инженерии на применение доменных знаний внутренней и дедуктивной информации или нечеткое описание причин для полного абстрактного описания системы	-	-
   Redocumentation	Производство или ревизия семантически эквивалентного описания на абстрактном уровне	-	-
   Restructuring	Преобразование эволюционных документов на абстрактном уровне, не изменяя функциональность и семантику	Стандартизация имен данных, определений и логических программных структур, чтобы улучшить ценность и продуктивность ПО	-
   Reuse	-	Повторное использование, включающее не только повторное применение источников кода, а также повторное применение проектных планов, прототипов, тестовых данных, моделей данных и технических спецификаций	Действия, направленные на идентификацию повторно используемого ПО, чтобы суметь импортировать, реконфигурировать и внедрить его в новую прикладную систему
   Forward engineering	Традиционный процесс пошаговой конкретизации или переход от абстрактной проектной документации до запускаемой программы	-	-

2. Унаследованные программные системы.

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

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

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

1. Кс по тем или иным причинам переставшие вас устраивать

2. Система для mainframe, написанные на Cobol и прослужившие более пяти лет.

3. Исчерпавшие себя системы для miniPC или mainframe.

4. Приложения с интерфейсом для Unix

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

6. Любая морально устаревшая система.

3. Реверс-инжиниринг наследуемой системы и его цели.

Реверс инжиниринг наследуемая система, является основным методом ее реструктуризации.

В классической постановке решение задачи разработки программной системы представляет собой спиральный цикл, основанный на итеративном чередовании этапов анализа, проектирования и программирования (реализации).

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

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

Обратная инженерия обеспечивает два следующих процесса:

1. Выявление системных компонент и отношения между ними

2. Создание если необходимо высокоуровневых представления компонентов и системы в целом

Продуктами реверс инжиниринга являются:

1. Представление программного обеспечения на разных уровнях

2. Компоненты программного обеспечения и отношения между ними

В обратной инженерии решаться две задачи:

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

2. Создание методов и инструментов, облегчающих распознавание конструкций в существующем исходном коде и в прочей информации в программном обеспечении

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

1. Создание оптимальной структуры нацеленной на достижения определенной иерархии целей

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

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

Критерии оценки трудозатрат для перехода на новую

4. Критерии оценки трудозатрат перехода на новую систему.

Основные факторы для успешности перехода на новую систему являются: Первый фактор

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

Дадим основные признаки большой системы:

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

2. Возможность определения на каждом уровне системы или для каждой подсистемы входящей в систему иерархии целей и выполняемых функций.

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

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

Второй фактор

Уровень языка программирования, на котором написана перестраиваемая система.

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

Выстраивается иерархия уровней.

Третий фактор

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

Чем меньше срок, тем больше усилий и денег надо на переход и возрастает вероятность ошибок

Четвертый фактор

Количество и уровень квалификации разработчиков

Пятый фактор

Наличие программных продуктов автоматизирующих миграцию

Шестой фактор

Наличие создателей старой системы

5. Повторное использование.

Принцип повторного использования ПО

Повторное использование ПО это использование существующего кода при написании нового ПО или использование знаний при написании этого кода.

Разновидностями повторного использования кода являются:

1. Библиотеки

2. Паттерны проектирования

3. Copy Paste

C точки зрения реализации принципа повторного использование существует два подхода:

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

1. Выделение основных, наиболее стабильных бизнес сущностей и реализация высокоуровневых абстракций на их основе.

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

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

1. Построение адаптера

2. Построение абстракции более высокого уровня, чем имеющийся артефакт.

6. Понятие доменного анализа.

Доменный анализ

Домен - сфера деятельности и интересов либо какую-то область знаний

В контексте программного обеспечения понятие рассматривается как область применения либо сфера, в которой разрабатываться программные системы.

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

Доменный анализ обеспечивает выявление общих объектов, операций и отношений среди подобных систем в домене.

Доменный анализ похож на системный анализ, но вместо анализа одной системы это делается по возможности для всех систем домена.

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

1. Проблемы

2. Программные процессы

3. Решения

Сведения о них образуют доменные знания.

Предметом доменного анализа является сочетание объектов или каждый из них в отдельности.