IT_exam 21 01 2020

Коссов Г.О. ИДМ-19-05

1. Понятия автоматизированной системы, информационной системы. Стадии создания автоматизированных систем

Aвтоматизированная система; AC: Система, состоящая из персонала и комплекса средств автоматизации его деятельности, реализующая информационную технологию выполнения установленных функций. en automated system; AS Примечания:

1. В зависимости от вида деятельности выделяют, например, следующие виды АС: автоматизированные системы управления (АСУ), системы автоматизированного проектирования (САПР), автоматизированные системы научных исследований (АСНИ) и др.
2. В зависимости от вида управляемого объекта (процесса) АСУ делят, например, на АСУ технологическими процессами (АСУТП), АСУ предприятиями (АСУП) и т.д. (ГОСТ 34.003-90 Автоматизированные системы.)

Информационная система (ИС) — система, предназначенная для хранения, поиска и обработки информации, и соответствующие организационные ресурсы (человеческие, технические, финансовые и т. д.), которые обеспечивают и распространяют информацию (ISO/IEC 2382:2015) Предназначена для своевременного обеспечения надлежащих людей надлежащей информацией[2], то есть для удовлетворения конкретных информационных потребностей в рамках определённой предметной области, при этом результатом функционирования информационных систем является информационная продукция — документы, информационные массивы, базы данных и информационные услуги.

ГОСТ 34.601-90 АВТОМАТИЗИРОВАННЫЕ СИСТЕМЫ. СТАДИИ СОЗДАНИЯ.

.1. Процесс создания АС представляет собой совокупность упорядоченных во времени, взаимосвязанных, объединённых в стадии и этапы работ, выполнение которых необходимо и достаточно для создания АС, соответствующей заданным требованиям.

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

1.3. Работы по развитию АС осуществляют по стадиям и этапам, применяемым для создания АС.

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

Перечень организаций, участвующих в работах по созданию АС, приведён в приложении 2.

2. СТАДИИ И ЭТАПЫ СОЗДАНИЯ АС 2.1. Стадии и этапы создания АС в общем случае приведены в таблице.

Стадии

Этапы работ

1. Формирование требований к АС

1.1. Обследование объекта и обоснование необходимости создания АС.

1.2. Формирование требований пользователя к АС.

1.3. Оформление отчёта о выполненной работе и заявки на разработку АС (тактико-технического задания)

2. Разработка концепции АС.

2.1. Изучение объекта.

2.2. Проведение необходимых научно-исследовательских работ.

2.3. Разработка вариантов концепции АС, удовлетворяющего требованиям пользователя.

2.4. Оформление отчёта о выполненной работе.

3. Техническое задание.

Разработка и утверждение технического задания на создание АС.

4. Эскизный проект.

4.1. Разработка предварительных проектных решений по системе и её частям.

4.2. Разработка документации на АС и её части.

5. Технический проект.

5.1. Разработка проектных решений по системе и её частям.

5.2. Разработка документации на АС и её части.

5.3. Разработка и оформление документации на поставку изделий для комплектования АС и (или) технических требований (технических заданий) на их разработку.

5.4. Разработка заданий на проектирование в смежных частях проекта объекта автоматизации.

6. Рабочая документация.

6.1. Разработка рабочей документации на систему и её части.

6.2. Разработка или адаптация программ.

7. Ввод в действие.

7.1. Подготовка объекта автоматизации к вводу АС в действие.

7.2. Подготовка персонала.

7.3. Комплектация АС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями).

7.4. Строительно-монтажные работы.

7.5. Пусконаладочные работы.

7.6. Проведение предварительных испытаний.

7.7. Проведение опытной эксплуатации.

7.8. Проведение приёмочных испытаний.

8. Сопровождение АС

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

8.2. Послегарантийное обслуживание.

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

Допускается исключить стадию "Эскизный проект" и отдельные этапы работ на всех стадиях, объединять стадии "Технический проект" и "Рабочая документация" в одну стадию "Технорабочий проект". В зависимости от специфики создаваемых АС и условий их создания допускается выполнять отдельные этапы работ до завершения предшествующих стадий, параллельное во времени выполнение этапов работ, включение новых этапов работ.

Технологии отрисовки (rendering) в браузере. Возможности программного управления порядком отрисовки.

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

Модули рендеринга. Взятые мной в качестве примеров браузеры — Firefox, Chrome и Safari созданы на основе двух движков визуализации. Firefox использует Gecko — модуль собственной разработки компании Mozilla. А в Chrome, как и в Safari используется Webkit. Webkit является движком рендеринга с отрытым кодом, который изначально разрабатывался для применения на платформе Linux и впоследствии был модифицирован компанией Apple с целью поддержки платформ Mac и Windows. Более подробную информацию по этому вопросу вы можете получить на официальном сайте Webkit.org. Ход главного процесса. Функционирование модуля рендеринга начинается с получения контента запрашиваемого документа, для чего задействуется компонент сетевого уровня. Контент передается по сетевому соединению порционно, как правило, пакетами размером 8 Кбайт. Далее основной поток работы движка визуализации выглядит следующим образом: Модуль визуализации начнет парсинг полученного HTML документа и на основе используемых в нем тегов создаст DOM узлы дерева, называемого “content tree” («дерево контента»). Далее парсингу подвергаются данные стилей: как внешние CSS файлы, так и встроенные таблицы стилей и соответствующие атрибуты элементов. Стилевая информация совместно с предоставляемыми HTML разметкой визуальными инструкциями будут использованы при построении другого дерева — “render tree” («дерево визуализации»). Дерево визуализации состоит из прямоугольников с атрибутами, содержащими визуальные инструкции, такие как цвет и размеры. Эти прямоугольники должны отображаться на экране в строгом, предусмотренном данным деревом порядке. Далее, после построения дерева визуализации, оно подвергается процессу компоновки. Это означает, что каждый узел дерева будет наделен точными координатами, определяющими место его отображения на экране. Следующим этапом является отрисовка, предусматривающая полный обход дерева визуализации, в процессе которого средствами внутреннего интерфейса будет отрисован каждый его узел. Необходимо понимать, что описываемый здесь процесс является последовательным. С целью создания максимально удобных условий просмотра для пользователя, модуль рендеринга будет делать все возможное, чтобы контент был отображен на экране как можно быстрее. Он не станет ждать полного окончания анализа HTML разметки, а начнет построение и компоновку дерева визуализации уже в ходе парсинга. Контент будет обрабатываться и отображаться частями, в то время как оставшиеся его компоненты все еще поступают по сети. Примеры главного процесса. Изображение 3: Ход основного процесса движка Webkit Изображение 4: Основной процесс движка рендеринга Gecko компании Mozilla (см. список ресурсов 3.6). Из представленных выше иллюстраций видно, что хотя движки Webkit и Gecko используют немного разную терминологию, предусмотренные ими функциональные потоки практически одинаковы. В Gecko дерево визуально форматируемых элементов называется “frame tree” («дерево фреймов»), каждый элемент которого является фреймом. Webkit для этого использует термин “render tree” («дерево визуализации»), состоящее из “render objects” («объектов визуализации»). Процесс размещения элементов в Webkit называется “layout” («компоновка»), который в Gecko именуется “reflow” («реорганизация» потока). Процесс связывания DOM узлов с соответствующей им визуальной информацией, в ходе которого создается дерево визуализации, в Webkit называется “attachment” («привязка» стилей). Незначительное не семантическое расхождение также и в том, что в Gecko между HTML разметкой и деревом DOM документа предусмотрен дополнительный уровень, называемый “content sink” («сток контента»), который является неким конвейером по производству DOM элементов. Далее мы поговорим о каждом компоненте в отдельности. *Примечание переводчика: Хочу обратить ваше внимание на термин «поток» или в оригинале “flow”, применяемый в технической литературе. Дело в том, что HTML стандарт использует поточную модель компоновки документа, которая в большинстве случаев позволяет рассчитать геометрические данные компонентов страницы за один проход структуры документа. При таком подходе элементы, находящиеся ниже в потоке, как правило (хотя далеко не всегда), не влияют на геометрические данные элементов, которые расположены выше в потоке документа. То есть процесс формирования разметки страницы происходит поточным образом, начиная от верхнего левого угла, направо и далее построчно вниз. В противоположность этому методу можно назвать блочную модель компоновки XUL, согласно которой в ходе расчета геометрических характеристик определенного элемента, в первую очередь принимаются во внимание все ограничения и преимущества элементов, составляющих его окружение, лишь после этого рассчитывается геометрия самого элемента. В Gecko процесс компоновки элементов страницы именуется “reflow” — «реорганизация потока». Данный движок предусматривает пять разновидностей такой реорганизации, каждая из которых применяется в различных ситуациях. Но это уже тема для отдельной публикации. Вернемся к статье.

Процесс отрисовки страницы в браузере

Браузер анализирует HTML-код страницы (кашу из тегов) и строит некоторое DOM-дерево — представление данных, в котором каждому HTML-тегу соответствует свой узел, а текстовые куски между тегами соответствуют своим текстовым узлам. Корневым узлом такого дерева является documentElement (тег ). Затраты на время построения DOM-дерева исследовались в этих статьях. Браузер анализирует CSS-код, пытается понять все заложенным в нем хаки и корректно распознать все известные ему приемы, среди которых могут быть -moz, -webkit и другие расширения, которые он может не понимать и должен игнорировать. Информация по стилям строится каскадным образом: сначала идут правила по умолчанию из самого браузера (более подробно их размер исследовался в этой статье), затем идут пользовательские стили, затем авторские (автора страницы) — внешние, импортированные, внутренние, а уже потом — все стили, прописанные в атрибутах style HTML-тегов. После этого наступает самая интересная часть: браузер строит дерево отрисовки. Дерево отрисовки в какой-то мере связано с DOM-деревом, но не соответствует ему полностью. Дерево отрисовки знает о текущих стилях (поэтому если вы спрячете div при помощи display: none, то он в это дерево не попадет, это не совсем верно, как видно из следующей статьи, но принцип тот). То же самое для других невидимых элементов: например, для тега head и всех вложенных элементов. С другой стороны в этом дереве DOM-узлы могут быть представлены в виде нескольких узлов, например, если каждая строка

требует своего узла для отрисовки. Узел в таком дереве называется кадр (frame) или блок (box) (так же как и CSS-блок, соответствующий блочной модели). У каждого из этих блоков есть блочные CSS-свойства: ширина, высота, граница, поля, и т.д (таким образом, даже строчные (inline) элементы будут представлены в дереве отрисовки отдельными блоками). После того как готово дерево отрисовки, его можно наконец и отрисовать (paint, draw) на экране.

Порядок отрисовки

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

Хранилище прямоугольников в WebKit Перед повторной отрисовкой старый прямоугольник сохраняется в WebKit как растровое изображение, а затем отрисовываются только различия между старым и новым прямоугольником. Динамические изменения При наступлении изменений браузеры стараются не выполнять лишних операций. Например, при изменении цвета одного элемента остальные не отрисовываются заново. При изменении положения элемента выполняется повторная компоновка и отрисовка его самого, его дочерних элементов и, возможно, других объектов того же уровня. При добавлении узла DOM выполняется его повторная компоновка и отрисовка. Серьезные изменения, такие как увеличение размера шрифта элемента html, ведут к очистке кэша и повторной компоновке и отрисовке целого дерева. Потоки модуля отображения Модуль отображения работает с одним потоком: в нем выполняется почти все, кроме сетевых операций. В Firefox и Safari это основной поток браузера, в Chrome – основной процесс вкладки. Сетевые операции могут выполняться в нескольких параллельных потоках. Количество параллельных соединений ограничено и обычно составляет от 2 до 6 (например, в Firefox 3 их используется 6). Цикл событий Основной поток браузера представляет собой цикл событий – бесконечный цикл, который поддерживает рабочие процессы. Он ожидает отправки событий (таких как layout и paint), чтобы их обработать. Так выглядит код Firefox для основного цикла событий: while (!mExiting) NS_ProcessNextEvent(thread); Визуальная модель CSS2 Холст Согласно спецификации CSS2, под холстом (canvas) подразумевается пространство, где отображается отформатированная структура, то есть область, в которой браузер отрисовывает содержание. Сам по себе холст бесконечен, однако браузеры обычно определяют для него ширину исходя из размеров области просмотра.

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

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