---

сейчас тебе скину лекции тебе нужно составить 30 вопросов можешь брать информацию из любой из них желательно примерно поровну


Лекция 3. Анализ исходных программ и компонентов программного средства
Требуемые условия завершения
Средства разработки программ
Средства разработки программного обеспечения – совокупность приемов, методов, методик, а также набор инструментальных программ (компиляторы, прикладные/системные библиотеки и т.д.), используемых разработчиком для создания программного кода программы, отвечающего заданным требованиям.
Разработка программ – сложный процесс, основной целью которого является создание, сопровождение программного кода, обеспечивающего необходимый уровень надежности и качества. Для достижения основной цели разработки программ используются средства разработки программного обеспечения.

Основные средства, используемые на разных этапах разработки программ

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

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

Анализ требований.
Разработка архитектуры будущего программного обеспечения.
Разработка устройств основных компонент программного обеспечения.
Разработка макетов пользовательских интерфейсов.
Результатом проектирования обычно является «Эскизный проект» (Software Design Document) или «Технический проект» (Software Architecture Document).

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

BPMN (Vision 2003 + BPMN, AcuaLogic BPMN, Eclipse, Sybase Power Designer);
Блок-схемы (Vision 2003 и многие другие);
ER-диаграмы (Visio 2003, ERWin, Sybase Power Designer и многие другие);
UML-диаграмы (Sybase Power Designer, Rational Rose и многие другие);
макеты, мат-модели и т.д.
Результаты анализа позволяют сформировать обоснованные требования к той или иной функциональности разрабатываемой программы и просчитать реальную выгоду от внедрения разрабатываемого продукта. Более того, иногда получается так, что по результатам анализа первоначальные цели и задачи автоматизации кардинально меняются или по результатам оценки эффективности разработки и внедрения принимается решение продукт не разрабатывать.
Целью второй и третьей задачи из приведенного списка задач является разработка модели (описания) будущей системы, понятной для кодировщика – человека, который пишет код программы. Здесь огромное значение имеет то, какую парадигму программирования необходимо использовать при написании программы. В качестве примера основных парадигм необходимо привести следующее:

Функциональное программирование;
Структурное программирование;
Императивное программирование;
Логическое программирование;
Объектно-ориентированное программирование (прототипирование; использование классов; субъективно-ориентированное программирование).
Выбор её во многом зависит от сложившихся привычек, опыта, традиций, инструментальных средств, которыми располагает коллектив разработчиков. Иногда разрабатываемый программный продукт настолько сложен, что для решения ряда задач в разных компонентах системы используются разные парадигмы. Выбор того или иного подхода накладывает ограничения на средства, которые будут применены на этапе реализации программного кода. Результатом решения данной задачи в зависимости от подхода могут быть (в скобках приведены программные средства, которые могут быть использованы для их получения):

диаграмма классов и т.д (Ration Rose, Sybase PowerDisigner и многие другие);
описание модулей структур и их программного интерфейса (например, Sybase PowerDisigner и многие другие).
Разработка макетов пользовательских интерфейсов подразумевает создание наглядного представления того, как будут выглядеть те или иные видеоформы, окна в разрабатываемом приложении. Решение данной задачи основывается на применение средств дизайнера.


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

методы и методики алгоритмирования;
языки программирования (C++,Си, Java, C#, php и многие другие);
средства создания пользовательского интерфейса (MFC, WPF, QT, GTK+ и т.д.;
средства управления версиями программного кода (cvs, svn, VSS);
средства получения исполняемого кода (MS Visual Studio, gcc и многие другие);
средства управления базами данных (Оracle, MS SQL, FireBird, MySQL и многие другие);
отладчики (MS Visual Studio, gdb и т.д.).
Средства тестирования программ
Основными задачами тестирования является проверка соответствия функциональности разработанной программы первоначальным требованиям, а также выявление ошибок, которые в явном или неявном виде проявляются во время работы программы. Среди основных работ по тестированию можно выделить следующее:

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

средства анализа кода, профилирования (Code Wizard - ParaSoft, Purify - RationalSoftawre. Test Coverage - Semantic и т.д.);
средства для тестирования функциональности (TEST - Parasoft, QACenter - Compuware, Borland SilkTestii т.д.);
средства для тестирования производительности (QACenter Performance - Compuware и т.д).

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

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

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

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

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

Реинжиниринг, этапы реинжиниринга

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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