lab_4_TS_Ivanova_4117

Строки, которые совпадают матрице достижимости и являются узлами бикомпоненты. Так как почти все выбранные элементы участвуют при сборке проекта получилась одна очень большая бикомпонента, определяющая весь этот процесс. Ещё одна, маленькая, отвечает за пользовательский интерфейс. Обособленным узлом можно считать Библиотеки, которые являются внешним источников данных для среды. Граф Герца, отражающий бикомпоненты, показан на рисунке № 3. На нём синим цветом выделена группа узлов, отвечающая за этапы непосредственной разработки приложения, зелёным – группа элементов отображения результатов на экране, а оранжевым – обособленный узел.

Рисунок № 3 – Граф Герца

Остовное дерево на основе графа системы отражает минимальное число связей, необходимых для того, чтобы из любой вершины графа можно было попасть в другую. Такое дерево может быть определено множеством способов, один из которых приеден на рисунке № 4. Синим цветом выделены ребра, которые входят в дерево. Соответствующая матрица контуров представлена в таблице 4. На графе выведено только 26 связей, но так как 11 из них являются двойными, то в итоге получается раннее определённое число в 37. В построенном остовном дереве выделен цикл компиляции кода и сборки приложения, сохранения и использования ресурсов программы, отображения выполняемых действий в пользовательском интерфейсе.

Рисунок № 4 – Остовное дерево

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

Таблица № 4 – Марица контуров

	1	2	3	5	6	7	8	9	10	11	12	16
17	+1	+1	+1	0	0	+1	+1	+1	0	+1	0	-1
18	+1	+1	+1	0	0	+1	+1	+1	0	+1	-1	0
19	+1	0	0	0	0	0	0	0	0	0	0	0
20	+1	0	0	0	0	-1	-1	-1	0	0	0	0
21	-1	0	0	0	0	0	0	0	0	0	0	+1
22	0	0	0	-1	-1	0	0	0	+1	0	0	0
23	0	0	0	+1	+1	0	0	0	-1	0	0	0
24	+1	0	+1	0	0	0	0	0	0	0	0	0
25	+1	0	+1	0	0	0	0	0	-1	0	0	0
26	0	-1	-1	0	0	+1	+1	+1	0	-1	+1	0

В полученной таблице достаточно много контуров, состоящих более чем из 3 элементов, что говорит о том, что система является очень сложной, как и её тестирование и оценка надёжности. Проведена сортировка матрицы контуров сначала по убывания количества связей в контурах (по строкам), затем по возрастанию. Результат сортировок приведен в таблицах № 5 и № 6 соответственно.

Таблица № 5 – Марица контуров (первая сортировка)

	1	2	3	5	6	7	8	9	10	11	12	16
17	+1	+1	+1	0	0	+1	+1	+1	0	+1	0	-1
18	+1	+1	+1	0	0	+1	+1	+1	0	+1	-1	0
26	0	-1	-1	0	0	+1	+1	+1	0	-1	+1	0
20	+1	0	0	0	0	-1	-1	-1	0	0	0	0
22	0	0	0	-1	-1	0	0	0	+1	0	0	0
23	0	0	0	+1	+1	0	0	0	-1	0	0	0
25	+1	0	+1	0	0	0	0	0	-1	0	0	0
21	-1	0	0	0	0	0	0	0	0	0	0	+1
24	+1	0	+1	0	0	0	0	0	0	0	0	0
19	+1	0	0	0	0	0	0	0	0	0	0	0

Контуры 17-18 отвечают за обработку, перевод и в последующем передачу команд к системному процессору. Они проходят схожим образом, ведь их положительная часть отвечает за непосредственную компиляцию кода. Но отрицательная часть контура 17 отображает работу с данными кэша, а 18 контур к ним не обращается, используя данные из общего хранилища (что значительно медленнее, но также необходимо). Следующий по сложности контур 26 отвечает за обмен статичных данных, за которые в основном отвечает общее хранилище, а 20-ый контур, наоборот, отвечает за управление динамическими данными. Перечисленные контуры являются наиболее сложными.

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

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

Контуры 24, 25 отвечают за обработку самого кода программы, введенного пользователем. Однако можно считать, что 25 контур смысловой нагрузки не несет, так как дублирует цикл 24-ого, исключая изменение динамических данных. К таковому можно отнести и 19, 21. Первый из которых непосредственное обращение к ядру процессора, после проверки и оптимизации кода, а второй – уже после запуска готового решения. То есть передающий команды для дальнейшего отклика о работе проекта.

В матрице контуров отсортированной по убыванию числа элементов (столбцы), приведенной в таблице № 6, видно, что элементы 5, 6, 12, 16 отвечают только за транспортировку данных от некого хранилища (кэш, журнал исполнения команд, ресурсы приложения). Наиболее значимым является первый, так как он является ключевым в контуре сборки всех компонентов в единое приложение. За связь между пользовательским интерфейсом и заданными командами отвечают узлы 11, 10 и 2.

Элементы 7, 8, 9 – играют большую роль в сборке проекта, отображая этапы обработки введенного кода. Сначала он обрабатывается java компилятором, ходящим в инструменты JDK, затем обрабатывается согласно версии SDK и только после конвертируется в машинный код.

Таблица № 6 – Марица контуров (вторая сортировка)

	1	3	7	8	9	2	10	11	5	6	12	16
17	+1	+1	+1	+1	+1	+1	0	+1	0	0	0	0
18	+1	+1	+1	+1	+1	+1	0	+1	0	0	-1	0
19	+1	0	0	0	0	0	0	0	0	0	0	0
20	+1	0	-1	-1	-1	0	0	0	0	0	0	0
21	-1	0	0	0	0	0	0	0	0	0	0	+1
22	0	0	0	0	0	0	+1	0	-1	-1	0	0
23	0	0	0	0	0	0	-1	0	+1	+1	0	0
24	+1	+1	0	0	0	0	0	0	0	0	0	0
25	+1	+1	0	0	0	0	-1	0	0	0	0	0
26	0	-1	+1	+1	+1	-1	0	-1	0	0	+1	0

Вывод:

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

Сложно сказать, насколько точно определены подсистемы среды Android Studio. Так как упор при изучении среды делался на анализ сборки цельного мобильного приложения, большая часть элементов непосредственно участвует в этом процессе, поэтому множество выделенных контуров имеют схожее предназначение. В этом же и причина наличия такой большой единой подсистемы разработки проекта, определённой на этапе поиска бикомпонент. Её в свою очередь также можно разбить на подсистемы, что позволяет выделить упомянутые ранее контуры 17-18 как подсистемы сбора данных из разных источников и обработки на их основе заданных команд. Выделен также один внешний источник данных для разработки, не относящийся к итоговому проекту – Библиотеки.

Ответы на контрольные вопросы:

1. Дайте определение структурной сложности орграфа:

- Структурная сложность орграфа G – это критерий S(G), посредством которого орграфу G в однозначное соответствие ставится целое неотрицательное число S(G), причем такое, что чем больше S(G), тем граф G сложнее.

2. Перечислите критерии структурной сложности графа:

- Первый критерий – число дуг в графе; второй критерий – количество и состав бикомпонентов графа; третий критерий сложности графов – число элементарных контуров.

3. Дайте определение бикомпоненты графа:

- Бикомпонента– это максимальный по включению сильно связанный подграф графа, её также называют компонентом сильной связности.

4. Дайте определение матрицы достижимости:

- Матрица достижимости отражает возможности достижения вершин в орграфе по путям, слагаемых из смежных дуг. Каждой бикомпоненте в матрице достижимости соответствует свой уникальный набор строк. Таким образом, по матрице достижимости можно выявить бикомпоненты орграфа

5. Дайте определение графа Герца:

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

6. По каким признакам сортируются дуги, входящие в граф системы?

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

1) числу контуров, проходящих через дугу (по убыванию);

2) весу дуги (по возрастанию);

3) индексу начала дуги (по возрастанию);

4) индексу конца дуги (по возрастанию).