ВУЗ:
Составители:
позволяющие настроить все таким образом, чтобы специфика конкретного
проекта была бы полностью учтена.
Процесс реинжениринга делится на два этапа: анализ и генерация
модели.
На первом этапе производятся все подготовительные операции по
анализу текста программы на отсутствие синтаксических ошибок. Второй
этап – это преобразование кода в модель.
Все операции выполняются независимо, что дает большой маневр для
разработчика, который, например, хочет провести только синтаксический
разбор теста, без генерации модели.
Соответственно, при отсутствии ошибок в файле, можно приступить к
генерации модели. В целях оптимизации времени генерации в Rose
предусмотрено три способа проведения реинжениринга, каждый из которых
может охватить и превосходно выполнить определенный сегмент работ.
Если пользователю по каким либо причинам не подходит ни один из трех
предустановленных способов, то Rose допускает создание собственного
реверсинжениринга.
Три стандартных способа:
FirstLook - приближенная пробежка по «телу» программы.
DetailedAnalysis - детальный анализ проекта.
RoundTrip - комбинация двух вышеперечисленных способов.
Позволяет безболезненно строить и перестраивать
разрабатываемые приложения по принципу круговой разработки.
Все настройки могут быть изменены пользователем по усмотрению.
При сохранении изменений, возможно, указать новое имя шаблона или
перезаписать уже существующее, что позволит при частом использовании
обратного проектирования не терять времени на установку нужного пункта.
Выбор соответствующего пункта обязательно сказывается на скорости
анализа, чем больше, тем дольше. Еще хочется отметить такую особенность
модуля Analyzer: после анализа создается не только модель, но и лог-файл с
сообщениями, возникшими в результате сканирования программы. Лог
может содержать как предупреждения, так и ошибки. А особенность
генерации модели состоит в том, что она состоится несмотря ни на что, то
есть, невзирая на ошибки в тексте программы. Естественно, никакой речи
нет о какой-либо правильной модели! Эту особенность следует учитывать, и
внимательно анализировать файл отчета после генерации модели.
Еще одна немаловажная ремарка. Как правило, обратному
проектированию подвергается полноценный проектный файл, содержащий в
себе и директивы #INCLUDE для определений, и комментарии, а также
прочие сопроводительные инструкции. И, естественно, разработчику хочется
иметь такой инструмент, который адекватно будет реагировать на все
составляющие. Модуль Analyzer в режиме (DetailedAnalysis) обеспечивает
следующее:
позволяющие настроить все таким образом, чтобы специфика конкретного проекта была бы полностью учтена. Процесс реинжениринга делится на два этапа: анализ и генерация модели. На первом этапе производятся все подготовительные операции по анализу текста программы на отсутствие синтаксических ошибок. Второй этап – это преобразование кода в модель. Все операции выполняются независимо, что дает большой маневр для разработчика, который, например, хочет провести только синтаксический разбор теста, без генерации модели. Соответственно, при отсутствии ошибок в файле, можно приступить к генерации модели. В целях оптимизации времени генерации в Rose предусмотрено три способа проведения реинжениринга, каждый из которых может охватить и превосходно выполнить определенный сегмент работ. Если пользователю по каким либо причинам не подходит ни один из трех предустановленных способов, то Rose допускает создание собственного реверсинжениринга. Три стандартных способа: FirstLook - приближенная пробежка по «телу» программы. DetailedAnalysis - детальный анализ проекта. RoundTrip - комбинация двух вышеперечисленных способов. Позволяет безболезненно строить и перестраивать разрабатываемые приложения по принципу круговой разработки. Все настройки могут быть изменены пользователем по усмотрению. При сохранении изменений, возможно, указать новое имя шаблона или перезаписать уже существующее, что позволит при частом использовании обратного проектирования не терять времени на установку нужного пункта. Выбор соответствующего пункта обязательно сказывается на скорости анализа, чем больше, тем дольше. Еще хочется отметить такую особенность модуля Analyzer: после анализа создается не только модель, но и лог-файл с сообщениями, возникшими в результате сканирования программы. Лог может содержать как предупреждения, так и ошибки. А особенность генерации модели состоит в том, что она состоится несмотря ни на что, то есть, невзирая на ошибки в тексте программы. Естественно, никакой речи нет о какой-либо правильной модели! Эту особенность следует учитывать, и внимательно анализировать файл отчета после генерации модели. Еще одна немаловажная ремарка. Как правило, обратному проектированию подвергается полноценный проектный файл, содержащий в себе и директивы #INCLUDE для определений, и комментарии, а также прочие сопроводительные инструкции. И, естественно, разработчику хочется иметь такой инструмент, который адекватно будет реагировать на все составляющие. Модуль Analyzer в режиме (DetailedAnalysis) обеспечивает следующее:
Страницы
- « первая
- ‹ предыдущая
- …
- 13
- 14
- 15
- 16
- 17
- …
- следующая ›
- последняя »