Методы анализа программных проектов реферат

Обновлено: 05.07.2024

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

Известно два подхода к разработке ПО:

Функционально-модульный или структурный.
Объектно - ориентированный подход.

Функционально-модульный подход основан на принципе функциональной декомпозиции. При этом структура системы описывается в терминах иерархии ее функций и передачи информации между отдельными функциональными элементами.

Объектно-ориентированный подход использует объектную декомпозицию.

Классические методы анализа требований ориентированы на процедурную реализацию программных систем.

2.1.1. Структурный анализ

Структурный анализ — один из формализованных методов анализа требований к ПО.

Все известные методы структурного подхода базируются на ряде общих принципов :

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

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

DFD (Data Flow Diagrams) — диаграммы потоков данных;
SADT (Structured Analysis and Design Technique) — метод структурног o анализа и проектирования;
ERD (Entity-Relationship Diagrams) — диаграммы "сущность — связь".

DFD и ERD — наиболее часто используемые в CASE-cредствах виды моделей. Основной элемент структурного анализа — диаграммы потоков данных (DFD-data flow diagrams). Конкретный вид диаграмм и интерпретация их конструкций зависят от стадии разработки ПО. Программное изделие рассматривается как преобразователь информационного потока данных.

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

Рис. 1. Элементы диаграммы потоков данных

Рис. 2. Диаграмма потоков данных

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

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

Описание потоков данных и процессов

Базовые средства диаграммы не обеспечивают полного описания требований к программному изделию. Должны быть описаны стрелки (потоки данных) и преобразователи (процессы). Для этих целей используются словарь требований (данных) – глоссарий и спецификации процессов. Глоссарий содержит описания потоков данных и хранилищ данных. Глоссарий является элементом любого CASE-средства автоматизации анализа.

Структура словаря зависит от особенностей конкретного CASE-средства:

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

Спецификация процесса — это описание преобразователя.

ввод данных в преобразователь;
алгоритм обработки;
характеристики производительности преобразователя;
формируемые результаты.

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

Рис. 3. Поток данных и процессов

2.1.2. Методы анализа, ориентированные на структуры данных

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

Методы, ориентированные на структуры данных, обеспечивают:

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

Наиболее известны два метода: метод Варнье—Орра и метод Джексона .

В методе Варнье-Орра для представления структур применяют диаграммы Варнье. Для построения диаграмм Варнье используют 3 базовых элемента: последовательность, выбор, повторение (Рис. 4).

Рис. 4. Базовые элементы

Как показано на Рис. 5, с помощью этих элементов можно строить информационные структуры с любым количеством уровней иерархии.

Рис. 5. Информционная структура

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

Метод анализа Джексона.

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

Метод Джексона (1975) включает 6 шагов. Три шага выполняются на этапе анализа, а остальные — на этапе проектирования.

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

Шаг объект—действие. Этот шаг начинается с определения проблемы на естественном языке. При выделении объектов и действий возможны ошибки. Но список объектов и действий может модифицироваться в ходе дальнейшего анализа.

Шаг объект—структура. Структура объектов описывает последовательность действий над объектами (в условном времени). Для представления структуры объектов Джексон предложил 3 типа структурных диаграмм. Они показаны на Рис. 6.

В первой диаграмме к объектам применяется такое действие, как последовательность, во второй — выбор, в третьей — повторение.

Рис. 6. Три типа структурных диаграмм

Рассмотрим объектную структуру для транспорта Рис. 7. Условимся, что начало и конец истории транспорта — у первой остановки. Действиями, влияющими на объект, являются Покинуть и Прибыть.

Рис. 7. Объектная структура для транспорта

Диаграмма показывает, что транспорт начинает работу у остановки 1, тратит основное время на перемещение между остановками 1 и 2 и окончательно возвращается на остановку 1. Прибытие на остановку, следующее за отъездом с другой остановки, представляется как пара действий Прибыть(i) и Покинуть(i). Заметим, что диаграмму можно сопровождать комментариями, которые не могут прямо представляться средствами метода. Например, значение i в двух последовательных остановках должно быть разным.

Рис. 8. Объектная структура для транспорта

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

Структурная диаграмма — время, ориентированное описание действий, выполняемых над объектом. Она создается для каждого объекта модели.

Шаг начального моделирования. Начальное моделирование — это шаг к созданию описания системы как модели реального мира. Описание создается с помощью диаграммы системной спецификации.

Элементами диаграммы системной спецификации являются физические процессы (имеют суффикс 0) и их модели (имеют суффикс 1). Как показано на Рис. 9, предусматриваются два вида соединений между физическими процессами и моделями.

Рис. 9. Виды соединений между физическими процессами и моделями

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

Диаграмма системной спецификации для системы обслуживания перевозок приведена на Рис. 10.

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

Рис. 10. Диаграмма системной спецификации
для системы обслуживания перевозок

Для фиксации особенностей процессов - моделей Джексон предлагает специальное описание — структурный текст. Структурная диаграмма модели примет вид, изображенный на Рис. 11. Соответственно, структурный текст модели записывается в следующей форме:

Использование методов и алгоритмов анализа программного кода и серверного архитектурного стиля REST для повышения качества С- программного продукта

Научный руководитель: д.т.н., проф. Зори Сергей Анатольевич

Консультант: ст. пр. Чернышова Алла Викторовна

Содержание

Введение

Данное исследование заостряет внимание на статическом анализе программного кода. Один из самых старых методов выявления дефектов в исходном коде — это обзор кода (code review). Он заключается в совместном внимательном чтении исходного кода и высказывании рекомендаций по его улучшению. [1] Однако появляется желание автоматизировать данный процесс, поэтому придуманы другие методы, которые реализованы в различных инструментах анализа ПО .

Существует следующие основные формы статического анализа программного обеспечения:

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

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

1. Актуальность темы

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

Статья Интегрируемый статический анализ для программного проекта с использованием архитектурного стиля REST [2] представлена на III Международной научно-практической конференции Программная инженерия: методы и технологии разработки информационно-вычислительных систем (ПИИВС-2020). В ней описывается подробно данный интегрируемый подход к статическому анализу программного проекта.

2. Цель и задачи исследования

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

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

Основные задачи исследования:

Объекты исследования : статический анализ ПО и архитектурный подход REST .

3. Обзор исследований и разработок

3.1 Обзор исследований в области метрик ПО

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

Морис Холстед предложил полноценный набор метрик ПО , который отображает характеристики существующей программы. [3] Данные метрики не полагаются на традиционный подсчет строк кода (LOC), а на подсчет количества операндов и операторов. Набор метрик делится на: базовые показатели, различные метрики объема программы, уровня качества, трудоемкости и затрат.

Томас Мак-Кейб описал метрику цикломатической сложности программы. [4] Метрика основана на анализе потока передачи управления от одного оператора к другому. Такой подход позволяет учесть логику программы. Программа представляется в виде управляющего ориентированного графа, такой граф называют графом управления, графом потока управления или управляющим графом программы. Метрика Мак-Кейба является цикломатическим числом графа управления, сумма количества ребер и вершин графа. Для данной метрики существуют модификации, предложенные разными авторами, две самые известные — Майерса и Хансена. [5]

Данные метрики разбираются в работе магистра ДонНТУ Жуковой Д.К., опубликованной на ее личном сайте. В работе описываются различные метрики Холстеда, цикломатическая метрика Мак-Кейба. Также помимо этих метрик, разобраны различные метрики для объектно-ориентированных языков: количество вызываемых удаленных методов (NORM), отклик на класс (RFC), взвешенная насыщенность класса (WMPC1, WMPC2) и др. Представлены количественные метрики: количество строк кода (LOC), количество классов (NOC), число происходящих классов (NDC), число локальных методов (NLM) и т. д.

Виктор Базили и Ричард Сэлби рассмотрели различные стратегии тестирования. [6] Работа показывает, что существует широкий диапазон стратегий тестирования. Из-за такого широкого диапазона стратегий тестирования, полезно использовать метрики, которые подсчитывают количество тестовых случаев, требуемых для каждой стратегии для заданной программы, например, метрика Мак-Кейба может измерить количество тестовых случаев требуемых для структурного тестирования.

Большинство современных языков поддерживают модульность. Одним из намерений при разбиении программы на модули — предотвратить влияние изменения одного модуля на другой. Для того чтобы измерить подобную связь, Норман Фэнтон предложил классифицировать модули на 6 классов сцепления. [7] В дальнейшем сцепление для программы может быть построен граф модели сцепления. Граф модели сцепления может предоставить хороший метод визуализации сцеплений между модулями.

Обычно модульные программы состоят из модулей с данными, протекающими через них способом, называемым информационным потоком. Информационные потоки могут показать сложные взаимодействия и сложное алгоритмическое поведение в программе. Сэлли Гэнри и Дэннис Кафура предложили метрику для модулей, которая подсчитывает кол-во таких потоков, завершающихся в модуле и происходящих из модуля. [8] Данная метрика позволяет определить влияние модулей на информационный поток программы, и, таким образом, выявить, что делает изменения и тестирования в программе более сложным.

3.2 Обзор исследований в области визуализации ПО

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

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

Янг П. и Манро М. описали визуализацию, основанную на трехмерных геометрических формах, таких как кубы и цилиндры [10]. Их система состоит из двух частей, CallStax и FileVis, которые можно объединить в одну систему визуализации. Есть и другие виды визуализаций с использованием абстрактных структур: представления кода в виде реального мира (например, города), полиметрические представления, гиперболические деревья, тримапинг, радар эволюции и др.

3.3 Обзор исследований в области распределенных систем и архитектурного подхода REST

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

Щелоков С. А. выделяет следующие требования к распределенным системам: открытость, масштабируемость, стабильность и безопасность. Он утверждает, что для удовлетворения этим требованиям, система должна включать дополнительный уровень программного обеспечения, который находится между прикладным и транспортным уровнями по модели OSI, называемый промежуточное программное обеспечение. [11]

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

4. Подход к статическому анализу с интеграцией с веб-сервисами хостинга проектов

Как говорилось в предыдущем разделе, инструмент для статического анализа кода должен быть создан как веб-сервис. Веб-сервис проще интегрируется с другими инструментами сборки, развертывания и тестирования проекта. Это упрощает его использование в непрерывной интеграции (CI ) [15] и в непрерывном развертывании (CD ) [16]. Также веб-сервис позволяет сделать систему статического анализа кросс-платформенной, снизить нагрузку на систему, в которую интегрируется статический анализ.

4.1. Требования к веб-сервису для статического анализа кода

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

Веб-сервис статического анализа должен вычислять следующие метрики ПО :

разнообразные метрики строк кода (SLOC, NCLOC, CLOC, количество пустых строк кода, процент комментариев, среднее число строк для функций, среднее число строк исходного кода для функций и т.д.);
метрики Хотстеда (полагаются на подсчет операндов и операторов);
метрики цикломатической сложности (для оценки сложности потока управления программы);
метрики покрытий кода для измерения сложности тестирования;
метрики для измерения сложности модулей программы (для языка C модулями выступают функции).

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

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

4.1.2. Требования к визуализациям, используемым веб-сервисом

В качестве подходов к визуализации веб-сервис должен использовать следующие:

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

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

4.1.3. Требования к REST интерфейсу и веб интерфейсу сервиса

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

Рисунок 1 — Дерево ресурсов REST API веб-сервиса

От корня ответвляются следующие ресурсы: register и :имя_пользователя (параметр, который указывается при запросе, например, /omegadog). Используя запрос register, можно создать аккаунт в системе. Затем, используя имя пользователя, указанное в аккаунте, можно управлять проектами этого аккаунта. Таким образом ресурс /:имя_пользователя/:название_проекта (:название_проекта — это параметр, который определяет имя проекта на аккаунте с именем пользователя :имя_пользователя) является корневым ресурсом для всех запросов, которые управляют проектом.

При помощи ресурса contents управляют содержимым проекта, добавляют или удаляют файлы, или получают информацию о файле или директории проекта. Затем впоследствии можно получить метрики файла, директории или проекта при помощи ресурса metrics, используя полученные пути при помощи contents. То есть, если клиент получил какой-то путь при помощи contents, например, /contents/директория1/файл1, то используя ресурс metrics и тот же путь (/metrics/директория1/файл1), можно получить метрики по этому пути. Тот же самый подход к запросам используется и для ресурса visualization, который позволяет получить визуализации для указанного пути.

Ресурс /:имя_пользователя/settings используется для изменения настроек аккаунта с именем пользователя :имя_пользователя.

Запросы типа записи должны быть аутентифицированы, поэтому при в запросе должно быть поле для передачи HMAC [23] запроса. Если запрос не был аутентифицирован, то запрос должен вернуть ответ 403 Forbidden. Подписывание запросов HMAC сделано для того, чтобы разграничить права среди клиентов. Для доверенных клиентов следует сгенерировать секретные ключи, сервис и данные клиенты должны разделять эти ключи.

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

4.2. Пример интеграции веб-сервиса статического анализа с веб-сервисом хостинга проектов

Рассмотрим пример интеграции веб-сервиса статического анализа с веб-сервисом Github, который является крупнейшим сервисом для хостинга проектов на данный момент. Данный сервис, как и многие подобные, поддерживает подписку на события, которые происходят в репозитории проекта. При возникновении события отправляется POST запрос на указанный URL REST интерфейса, данная возможность называется веб-хуками (webhooks) [24]. Сервис поддерживает разные события:

create, Git ветка или тэг созданы;
delete, Git ветка или тэг удалены;
fork, пользователь создал форк репозитория;
pull_request, произошел запрос на получение (git pull) ветки или тэга репозитория;
push, один или несколько коммитов отправлены (git push) в ветку или тэг репозитория;
и т.д.

Веб-хук для события push передает большое количество параметров в теле запроса, однако самым важным параметром является after, который хранит SHA -хеш [25] последнего отправленного коммита в ветку. Имея данное значение хеша, сервис в дальнейшем может обработать изменения в ветке репозитория с использованием REST API Github.

Опишем процесс обработки изменений в ветке репозитория при получении веб-хука push сервисом статического анализа. Процесс состоит из следующих этапов:

Получив SHA -хеш последнего коммита, сервис отправляет запрос на получения информации о коммите с использованием запроса REST API Github /repos/:имя_пользователя/:название_проекта/git/commits/:хеш_коммита. В ответе на запрос, приходит много параметров, но важным является параметр tree. Параметр tree — это объект, внутри которого хранится свойство sha. Свойство sha хранит SHA -хеш дерева BLOB -объектов [26], на которое указывает коммит.
При помощи запроса /repos/:имя_пользователя/:название_проекта/git/trees/:хеш_дерева, в ответе на запрос получаем структуру дерева. Данная структура хранится в параметре tree, это массив объектов JSON . Важными параметрами каждого объекта являются: path (путь к файлу или директории), type (BLOB или дерево (tree)) и sha (SHA -хеш BLOB -объекта или поддерева).
В случае возникновения новых путей, необходимо добавить соответствующе ресурсы для проекта.
Необходимо сверить для каждого уже существующего пути хеш-значения со значениями, которые хранятся на сервисе статического анализа. В случае несовпадения значений и если путь является типа BLOB , необходимо получить содержимое при помощи запроса /repos/:имя_пользователя/:название_проекта/git/blobs/:хеш_blob. Для каждого нового пути тоже необходимо получить содержимое, если тип нового пути BLOB . Ответ на данный запрос содержит 2 поля: content (содержимое BLOB -объекта) и encoding (кодирование данных в поле content, например, base64 [27]).
В случае несовпадений хеш-значений и если путь является поддеревом (тип tree), рекурсивно повторить шаги 2–5. Для нового пути с типом tree, тоже повторить шаги 2–5 для поддерева.

На рисунке 2 показан конкретный пример процесса обработки изменений в ветке репозитория при отправке веб-хука push сервису статического анализа, в данном примере в ветку репозитория отправляется коммит, который изменяет файл file1.c и добавляет file2.c.

Рисунок 2 — Пример обработки веб-хука push
(анимация: 6 кадров, 65.3 килобайт)

Выводы

В рамках проведенных исследований:

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

Дальнейшие исследования направлены на следующие аспекты:

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

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

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

Подобные документы

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

курсовая работа, добавлен 08.02.2017

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

дипломная работа, добавлен 01.10.2015

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

дипломная работа, добавлен 12.06.2013

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

статья, добавлен 12.03.2019

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

дипломная работа, добавлен 10.07.2017

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

отчет по практике, добавлен 19.11.2020

Тестирование программного обеспечения как средство выявления ошибок в работе программ. Исследование основных методов и принципы тестирования программных комплексов, применяемых в интересах оценивания и контроля безопасности автоматизированных систем.

статья, добавлен 07.03.2019

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

учебное пособие, добавлен 03.03.2018

Обзор методов оценки систем на этапе концептуального проектирования. Разработка функциональной структуры комплекса. Проектирование программного комплекса на основе CASE-технологий; алгоритмов работы программного комплекса и программного обеспечения.

дипломная работа, добавлен 04.07.2018

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

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

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

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

Диаграмма потока данных

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

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

Типы ДФД

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

Логический DFD — этот тип DFD концентрируется на системном процессе и потоке данных в системе. Например, в банковской системе программного обеспечения, как данные перемещаются между различными объектами.
Физический DFD — этот тип DFD показывает, как поток данных фактически реализуется в системе. Это более конкретно и близко к реализации.

DFD Компоненты

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

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

Уровни DFD

Уровень 0 — DFD самого высокого уровня абстракции известен как DFD уровня 0, который изображает всю информационную систему в виде одной диаграммы, скрывающей все базовые детали. DFD уровня 0 также известны как DFD контекста уровня.

Уровень 2 — На этом уровне DFD показывает, как данные передаются внутри модулей, упомянутых на уровне 1.

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

Уровень 2 — На этом уровне DFD показывает, как данные передаются внутри модулей, упомянутых на уровне 1.

Структурные диаграммы

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

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

Вот символы, используемые при построении структурных схем —

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

Диаграмма HIPO

Диаграмма HIPO (иерархический ввод-вывод) представляет собой комбинацию двух организованных методов для анализа системы и предоставления средств документирования. Модель HIPO была разработана IBM в 1970 году.

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

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

В отличие от диаграммы IPO (Input Process Output), которая отображает поток управления и данные в модуле, HIPO не предоставляет никакой информации о потоке данных или потоке управления.

пример

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

Структурированный английский

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

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

Читайте также: