Данные (вычислительная техника) — Википедия

Материал из Википедии — свободной энциклопедии

Данные — поддающееся многократной интерпретации представление информации в формализованном виде, пригодном для передачи, связи, или обработки (ISO/IEC 2382-1:1993)^[1].

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

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

В языках высокого уровня данные воплощаются в виде переменных. Данные с точки зрения процесса (выполняемой программы) — содержимое части адресного пространства.

Традиционно применяют два способа организации данных: текстовые данные (в файловой системе: текстовый файл, в программировании: строковый тип данных) — последовательность символов алфавита, представленная в виде кодировки.

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

Типы и иерархия данных в программировании[править | править код]

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

Хотя с логической точки зрения данные для вычислительных систем хранятся в виде битов 0 и 1, однако на физических носителях эти биты могут иметь разную физическую природу.

1. ↑ ISO/IEC 2382-1:1993, Information technology — Vocabulary — Part 1: Fundamental terms:
   a reinterpretable representation of information in a formalized manner suitable for communication, interpretation, or communication, or processing

6. Программы и данные

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

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

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

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

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

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

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

7. Классификация программ

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

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

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

Прикладные программы или приложения – это программы, запускаемые из операционной системы и содержащие алгоритмы, служащие для обработки конкретных данных. Приложения тесно связаны с ОС, т.к. используют её для связи с компьютером, поэтому все они классифицируются по принадлежности к определенным операционным системам. Например, приложения для Windows, дляMacX, для DOS и др.

Осваиваем компьютерное зрение — 8 основных шагов / Habr

Привет, читатель.

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

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

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

Итак, теперь давайте приступим непосредственно к этапам.

Шаг 1 — Базовые методики работы с изображениями

Этот шаг посвящен техническим основам.

Посмотрите — отличный YouTube-плейлист «Древние секреты компьютерного зрения» от Joseph Redmon.

Прочтите — третью главу книги Ричарда Шелиски «Компьютерное зрение: Алгоритмы и приложения».

Закрепите знания — попробуйте себя в преобразовании изображений с помощью OpenCV. На сайте есть много пошаговых электронных пособий, руководствуясь которыми можно во всём разобраться.

Шаг 2 — Отслеживание движения и анализ оптического потока

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

Пройдите курс — курс по компьютерному зрению на Udacity, в особенности урок 6.
Посмотрите — 8-ое видео в YouTube-списке и лекцию об оптическом потоке и трекинге.

Прочтите — разделы 10.5 и 8.4 учебника Шелиски.

В качестве учебного проекта разберитесь с тем, как с помощью OpenCV отслеживать объект в видеофрейме.

Шаг 3 — Базовая сегментация

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

Так, преобразование Хафа позволяет найти круги и линии.

Посмотрите эти видео:

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

Шаг 4 — Фитинг

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

Посмотрите видео:

Прочтите — разделы 4.3.2 и 5.1.1 учебника Шелиски.

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

Шаг 5 — Совмещение изображений, полученных с разных точек осмотра

Посмотрите Youtube-плейлист

Прочтите — сопроводительное письмо.

Для проекта можно взять собственные данные. Например, сфотографировать с разных сторон что-то из мебели и сделать в OpenCV из альбома плоских изображений 3D-объект.

Шаг 6 — Трёхмерные сцены

Умея создавать 3D-объекты из плоских изображений, можно попробовать создать и трёхмерную реальность.

Пройдите — курс по стереозрению и трекингу

Посмотрите видео:

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

Шаг 7 — Распознавание объектов и классификация изображений

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

Далее, пользуясь ссылками, рассмотрите следующие темы:

В качестве проекта создайте в TensorFlow нейросеть, определяющую по изображению марку автомобиля или породу собаки.

Шаг 8 — Современное глубокое обучение

Прочитайте — лекции Стенфордского курса

Посмотрите видео:

На этом наши шаги в изучении компьютерного зрения подошли к концу. Надеюсь вы узнали для себя что-нибудь новое. Как принято на Хабре, понравился пост — поставь плюс. Не забудьте поделиться с коллегами. Также, если у вас есть то, чем вы можете поделиться сами — пишите в комментариях. Больше информации о машинном обучении и Data Science на Хабре и в телеграм-канале Нейрон (@neurondata).

Всем знаний!

Виды угроз / VPS.house corporate blog / Habr

Безопасность виртуального сервера может быть рассмотрена только непосредственно как «информационная безопасность». Многие слышали это словосочетание, но не все понимают, что же это такое?

«Информационная безопасность» — это процесс обеспечения доступности, целостности и конфиденциальности информации.

Под «доступностью» понимается соответственно обеспечение доступа к информации. «Целостность» — это обеспечение достоверности и полноты информации. «Конфиденциальность» подразумевает под собой обеспечение доступа к информации только авторизованным пользователям.

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

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

В другом случае если у Вас размещен на сервере продающий сайт или игровой сервер, то и необходимые меры защиты будут совершенно различными.

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

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

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

Угрозы информационной безопасности, которые наносят наибольший ущерб

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

1. Угроза непосредственно информационной безопасности:
   
   • Доступность
   • Целостность
   • Конфиденциальность
2. Компоненты на которые угрозы нацелены:
   • Данные
   • Программы
   • Аппаратура
   • Поддерживающая инфраструктура
3. По способу осуществления:
   • Случайные или преднамеренные
   • Природного или техногенного характера
4. По расположению источника угрозы бывают:
   • Внутренние
   • Внешние

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

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

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

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

Вам как администратору виртуального сервера, данные виды угроз нужно принимать во внимание только в случаях при которых даже кратковременная потеря доступа или частичная или полная остановка в работоспособности сервера по вине хостинг компании могут привести к не соизмеримым проблемам или убыткам. Это случается достаточно редко, но по объективным причинам ни одна хостинг компания не может обеспечить Uptime 100%.

Угрозы непосредственно информационной безопасности

К основным угрозам доступности можно отнести

1. Внутренний отказ информационной системы;
2. Отказ поддерживающей инфраструктуры.

Основными источниками внутренних отказов являются:

• Нарушение (случайное или умышленное) от установленных правил эксплуатации
• Выход системы из штатного режима эксплуатации в силу случайных или преднамеренных действий пользователей (превышение расчетного числа запросов, чрезмерный объем обрабатываемой информации и т.п.)
• Ошибки при (пере)конфигурировании системы
• Вредоносное программное обеспечение
• Отказы программного и аппаратного обеспечения
• Разрушение данных
• Разрушение или повреждение аппаратуры

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

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

Основные угрозы целостности

Можно разделить на угрозы статической целостности и угрозы динамической целостности.

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

С целью нарушения статической целостности злоумышленник может:

• Ввести неверные данные
• Изменить данные

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

Основные угрозы конфиденциальности

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

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

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

Для наглядности данные виды угроз так же схематично представлены ниже на рис 1.

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

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

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

1. Что защищать?
2. От кого защищать, какие виды угроз являются превалирующими: внешние или внутренние?
3. Как защищать, какими методами и средствами?

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

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

Нефункциональные требования к программному обеспечению. Часть 1 / Habr

Введение

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

В этой статье я расскажу о следующем:

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

Нефункциональные требования: какие они бывают

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

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

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

Примеры ограничений: «Разработка должна вестись на платформе вендора X», «При аутентификации пользователя должны использоваться биометрические методы идентификации».

• Бизнес-правила — политика, руководящие принципы или положения, которые определяют или ограничивают некоторые аспекты бизнеса, в т.ч. правила, определяющие состав и правила выполнения определенных бизнес-процессов. К бизнес-правилам относятся корпоративные политики, правительственные постановления, промышленные стандарты и вычислительные алгоритмы, которые используются при разработке продукта или системы либо непосредственно влияют на разработку.

Примеры бизнес-правил: «При отгрузке заказа менеджер должен запросить у бухгалтера товарно-транспортную накладную и счет-фактуру», «Если оплата по счету не поступила в течение 15 дней, заказ считается отменённым».

• Внешние интерфейсы — описание аспектов взаимодействия с другими системами и операционной средой. К ним относятся требования к API продукта или системы, а также требования к API других систем, с которыми осуществляется интеграция.

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

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

• Предложения по тестированию разрабатываемого ПО — дополнения к требованиям, указывающие, каким образом то или иное требование должно быть протестировано.

• Юридические требования — требования к лицензированию, патентной чистоте, etc.

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

Нефункциональные требования: как их определять

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

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

Нефункциональные требования: работа над определением

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

Роли, которые при этом играют участники рабочей группы по определению нефункциональных требований, описаны далее.

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

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

1. Система получает оповещение о событии, инициирующем рассылку уведомлений.
2. Система осуществляет рассылку оповещений по адресам из списка рассылки X, используя шаблон Y. Для рассылки сообщений используется сервис Z.
3. В случае невозможности завершения рассылки, система предпринимает повторные попытку рассылки.

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

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

Критерии качественных нефункциональных требований

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

Ниже приведены основные характеристики качественных требований.

• Полнота (отдельного требования и системы требований) — требование должно содержать всю необходимую информацию для его реализации. В него включается вся информация об описываемом параметре, известная на момент описания. Система требований также не должна содержать невыявленных и не определенных требований. Причины неполноты описания следует явно объявлять.
• Однозначность — требование должно быть внутренне непротиворечиво и все работающие с ним должны понимать его одинаково. Требования следует выражать просто, кратко и точно, используя известные термины. Обычно базовые знания читателей спецификации требований к ПО различаются. Поэтому в ее состав нужно включить раздел с определением понятий прикладной области, используемых при определении требований. Пример, неоднозначного требования. «Период обновления экрана должен быть не менее 20 сек.»
• Корректность отдельного требования и согласованность (непротиворечивость) системы требований — требование не должно содержать в себе неверной, неточной информации, а отдельные требования в системе требований не должны противоречить друг другу.
• Необходимость — требование должно отражать возможность или характеристику ПО, действительно необходимую пользователям, или вытекающую из других требований.
• Осуществимость — включаемое в спецификацию требование должно быть выполнимым при заданных ограничениях операционной среды. Осуществимость требований проверяется в процессе анализа осуществимости разработчиком. В частности, для нефункциональных требований проверяется возможность достижения указанных численных значений при существующих ограничениях.
• Проверяемость — проверяемость требования означает, что существует конечный и разумный по стоимости процесс ручной или машинной проверки того, что ПО удовлетворяет этому требованию. Каждое требование (особенно нефункциональное) должно содержать достаточно информации для однозначной проверки его реализации. Иначе, факт реализации будет основываться на мнении, а не на анализе, что приведет к проблемам при сдаче готового ПО. Для атрибутов качества (как мы помним, отдельной разновидности нефункциональных требований) критерием проверямости можно считать наличие численных значений характеристик качества продукта или системы

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

Атрибуты качества

Этот раздел будет посвящен характеристикам качества продукта или системы.

Характеристики качества и модель качества ПО

Определение атрибутов качества тесно связано с выбранной для вашего продукта моделью качества. Разработкой модели качества занимается группа обеспечения качества (в которую входят тестировщики и которая ими, разумеется, не ограничивается).

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

Среди них можно выделить следующие:

Также можно назвать еще два стандарта, которые могут послужить источником для определения вашей модели качества:

• 1061-1998 IEEE Standard for Software Quality Metrics Methodology
• ISO 8402:1994 Quality management and quality assurance

Характеристики качества с точки зрения влияния на архитектуру системы

Все атрибуты качества с точки зрения архитектуры системы можно разделить на две большие группы: первая группа (runtime) – это атрибуты, относящиеся ко времени работы приложения или системы; вторая группа (design time) определяет ключевые аспекты проектирования приложения или системы. Многие из этих атрибутов взаимозависимы.

Рассмотрим более подробно каждую из этих групп.

Группа runtime

К этой группе относятся следующие атрибуты качества:

• Доступность — атрибут качества, определяющий время непрерывной работы приложения или системы. Чтобы определить этот параметр, обычно указывают максимально допустимое время простоя системы.
• Надежность — требование, описывающее поведение приложения или системы в нештатных ситуациях (примеры: автоматический перезапуск, восстановление работы, сохранение данных, дублирование важных данных, резервирование логики)
• Требования к времени хранения данных (например, использование БД в качестве постоянного хранилища данных, продолжительность хранения данных)
• Масштабируемость — требования к горизонтальному и/или вертикальному масштабированию приложения или системы. Говоря о вертикальной масштабируемости, мы определяем требования к вертикальной архитектуре системы или приложения. К требованиям вертикальной масштабируемости могут относиться, например, возможность переноса приложений на более мощные SMP-системы, поддержка большого объема памяти и файлов. Говоря о горизонтальной масштабируемости, мы определяем требования к горизонтальной архитектуре системы или приложения. К требованиям горизонтальной масштабируемости могут относиться, например, возможность использования технологий кластеризации. Следует особо заметить, что вертикальное масштабирование обычно направлено на повышение производительности системы. Горизонтальное масштабирование, помимо производительности, позволяет повысить отказоустойчивость системы. Более подробно о вертикальном и горизонтальном масштабировании можно прочитать, например, здесь.
• Требования к удобству использования системы/приложения (с точки зрения пользователя) и требования к удобству и простоте поддержки (Usability)
• Требования к безопасности, как правило, включают в себя три большие категории: требования, связанные с разграничением доступа, требования, связанные с работой с приватными данным, и требования, направленные на снижение рисков от внешних атак.
• Требования к конфигурируемости приложения, взаимодействия и расположения компонентов можно условно разделить на четыре уровня:
  1. конфигурируемость на основе предопределенного набора параметров (predefined configurability), когда необходимый уровень модификации достигается путем изменения значений параметров из предопределенного набора;
  2. конфигурируемость на основе предопределенного набора базовых объектов (framework constrained configurability), когда необходимый уровень модификации достигается путем перекомпоновки предопределенного набора процессов, сущностей и служебных процедур;
  3. конфигурируемость путем реализации новых базовых объектов (basis reimplementation), когда обеспечивается расширение набора процессов и сущностей;
  4. конфигурируемость путем новой реализации системы (system reimplementation), когда система должна устанавливаться и настраиваться с нуля.
• Требования к производительности решения, определяемые в терминах количества одновременно работающих пользователей, обслуживаемых транзакций, времени реакции, продолжительности вычислений, а также скорости и пропускной способности каналов связи
• Ограничения, накладываемые на объем доступной памяти, процессорного времени, дискового пространства, пропускную способность сети, при которых приложение должно эффективно выполнять возложенные на него задачи

Группа design time

К этой группе относятся следующие атрибуты качества:

• Требования к повторному использованию реализации или компонентов приложения или системы (Reusability). О том, как это выражается в конкретной реализации, будет рассказываться далее. Пока ограничимся лишь тем, что чаще всего эти требования будут возникать там, где общие компоненты используются несколькими модулями разрабатываемой вами системы.
• Требования к расширяемости (Extensibility) приложения или системы в связи с появлением новых функциональных требований, тесно связанное с таким архитектурным атрибутом качества, как переносимость кода. Как правило, на начальном этапе сбора требований можно ограничиться указанием тех функциональных областей, которые в дальнейшем должны удовлетворять требованию расширяемости.
• Требования к переносимости (Portability) приложения или системы на другие платформы.
• Требования к взаимодействию между компонентами решения, между внешними компонентами, использование стандартных протоколов и технологий взаимодействия (Interoperability). Например, к таким требованиям можно отнести возможность использования нескольких стандартных протоколов для обмена данными между одной из подсистем разрабатываемой системы и внешней системой-поставщиком данных (на примере ArcGIS)
• Требования к поддержке системы или приложения (Supportability). Среди этих параметров могут быть названы такие как, напрмер, дешевизна и скорость разработки, прозрачность поведения приложения, простота анализа ошибок и проблем в работе
• Требования к модульности приложения или системы (Modularity). Обычно такие требования указывают, каким образом система должна быть разделена на модули, или перечисляют список обязательных модулей, которые должны входить в состав системы.
• Требования к возможности тестирования (Testability) приложения или системы определяют объем требований к автоматическому и ручному тестированию, наличие необходимого инструментария
• Требования к возможности и простоте локализации (Localizability) приложения или системы определяют возможности и специфические архитектурные требования, накладываемые процессом локализации. Эти требования содержат также перечень языков, на которые предполагается выполнять локализацию приложения или системы

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

Статьи, лежащие в основе подхода Facebook к компьютерному зрению / Wunder Fund corporate blog / Habr

Знаете такую компанию — Facebook? Да-да, ту самую, у сайта которой 1,6 миллиардов пользователей. И если взять все посты-поздравления с днем рождения, ваши позорные детские фотографии (у меня они такие), того дальнего родственника, лайкающего каждый ваш статус, — и вот вам множество данных для анализа.

С точки зрения анализа изображений Facebook весьма далеко продвинулся со сверточными нейронными сетями (Convolutional Neural Network, CNN). В августе подразделение Facebook по исследованиям в области искусственного интеллекта (Facebook AI Research, сокращенно FAIR) опубликовала блог-пост об алгоритмах компьютерного зрения, которые лежат в основе некоторых их алгоритмов сегментации изображений. В этом посте мы кратко изложим и разъясним три статьи, на которые ссылается этот блог.

Обычно FAIR использует следующую последовательность алгоритмов. Изображения подаются на вход фреймворку сегментации DeepMask. Алгоритм SharpMask служит для улучшения выделенных на первом этапе сегментов, затем объекты классифицируются с помощью MultiPathNet. Давайте рассмотрим, как работает каждый из этих компонентов в отдельности.

DeepMask

Введение

Эта работа, принадлежащая Педро Пинэйро, Роману Коллоберту и Петру Доллару, называется “Учимся выделять объекты-кандидаты” (“Learning to Segment Object Candidates”). Для решения задачи сегментации изображений авторы предлагают алгоритм, который, получая фрагмент изображения, выводит маску объекта и вероятность того, что в центре фрагмента находится объект целиком. Этот процесс применяется ко всему изображению так, чтобы маска была создана для каждого объекта. Весь процесс осуществляется с помощью всего одной CNN, так как оба компонента используют одни и те же слои сети.

Входные и выходные данные

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

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

*Рисунок 1. Сверху. Архитектура модели: после общего слоя извлечения характеристик, модель расходится на две ветки. Верхняя ветка предсказывает маску сегментации для объекта, находящегося в центре, в то время как нижняя ветка предсказывает вероятность того, что фрагмент содержит объект.
Снизу. Примеры обучающих троек: входной фрагмент x, маска m и метка y. Зеленые фрагменты содержат объекты, удовлетворяющие определенным условиям и поэтому помеченные y = 1. Заметьте, что маски из негативных примеров (красных) не используются и показаны только для иллюстрации.

Архитектура сети

Сеть была заранее обучена классификации изображений на базе ImageNet (Transfer Learning в действии). Изображение проходит через VGG-подобную модель (без полносвязных слоев) с восемью сверточными слоями размера 3х3 и пятью слоями maxpool 2х2. В зависимости от размеров исходного изображения, вы получите определенный объем выходных данных (в данном случае, 512х14х14).

Input: 3 x h x w
Output: 512 x h/16 x w/16

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

Компонент сегментации (Segmentation Head)

Теперь берем выходные данные, передаем их через внутренний слой и ReLU слой. Сейчас у нас есть слой из w’ x h’ (где w’ и h’ меньше, чем w и h исходного изображения) классификаторов пикселей, которые определяют, является ли данный пиксель частью объекта в центре изображения (если размер изображения 28х28, то классификаторов будет менее 784). Затем берем выходные значения классификаторов, методом билинейной интерполяции повышаем разрешение изображения до исходного и получаем двоичную маску (1 — если пиксель принадлежит искомому объекту, 0 — если нет).

Компонент “объектности” (Objectness Head)

Второй компонент сети определяет, содержит ли изображение объект нужного масштаба в центре. Передавая выходные данные VGG-подобных слоев через maxpool-слой размерности 2х2, модуль dropout и два полносвязных слоя, мы можем получить нашу вероятностную оценку.

Обучение

Оба компонента сети обучаются параллельно, так как функция потерь — это сумма потерь логистической регрессии (потери Objectness Head плюс потери применения Segmentation Head к каждому фрагменту). Алгоритм обратного распространения ошибки пробегает либо по Objectness Head, либо по Segmentation Head. Для улучшения модели был использован прием расширения обучающего множества (Data Augmentation). Модель обучали методом стохастического градиентного спуска на графическом процессоре Nvidia Tesla K40m в течение пяти дней.

Чем крута эта статья

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

SharpMask

Введение

Предыдущая группа исследователей (совместно с Цунг-Йи Лином) также являются авторами статьи под названием “Учимся улучшать сегменты объектов” (“Learning to Refine Object Segments”). Как видно из названия, эта статья рассказывает об улучшении масок, созданных на этапе DeepMask. Главная проблема DeepMask в том, что эта модель использует простую сеть прямого распространения, которая успешно создает “грубые” маски, но не выполняет сегментацию с точностью до пикселя. Причина этого в том, что, если помните, в DeepMask имеет место билинейная интерполяция, которая служит для подгона под размер исходного изображения. Поэтому соответствие реальным границам очень приблизительно. Чтобы решить эту проблему, модель SharpMask объединяет информацию низкоуровневых характеристик, которую мы получаем от первых слоем сети, с высокоуровневой информацией об объекте, которая приходит от более глубоких слоев. Сначала модель создает грубую маску каждого входного фрагмента (работа DeepMask), а затем передает через несколько уточняющих модулей. Рассмотрим этот этап более детально.

Архитектура сети

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

Уточняющий модуль (Refinement module)

Рассмотрим более подробно, как устроен уточняющий модуль. Задача этого модуля — противостоять влиянию слоев подвыборки (pooling layer) на этапе DeepMask (слоев, которые сжали изображение 224×224 до 14×14), увеличивая размерность полученных масок с учетом карт признаков, созданных во время восходящего прохода (мы можем называть DeepMask восходящим проходом, а SharpMask — нисходящим). Говоря языком математики, уточняющий модуль — это функция, которая генерирует расширенную маску М, то есть функция от маски предыдущего слоя и карты признаков F. Количество уточняющих модулей должно равняться количеству слоев подвыборки, используемых в DeepMask.

Но что именно делает функция R? Рад, что вы спросили. Наивным подходом было бы просто объединить M и F, так как у них одна у них одинаковая высота и ширина. Проблему при таком подходе создает канал глубины цвета для каждого из этих компонентов. Число таких каналов в картах признаков может быть намного больше, чем в маске. Таким образом, простое объединение придаст слишком большое значение F. Решением было бы сократить число каналов глубины цвета для F с помощью сверточного слоя 3×3, объединения c M, прохождения через еще один сверточный слой 3х3 и, наконец, билинейную интерполяцию (см. схему архитектуры сети).

Обучение

Те же обучающие данные, что использовались для DeepMask, можно применить и для SharpMask. Сначала обучают слои DeepMask. Затем веса замораживают, и начинается обучение SharpMask.

Чем крута эта статья

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

MultiPathNet

Введение

DeepMask создаеь грубые маски сегментов. SharpMask уточняет контуры объектов. А задача MultiPathNet — идентифицировать или классифицировать объекты в масках. Группа, состоящая из Сергея Загоруйко, Адама Лерера, Ценг-Йи Лина, Педро Пинейро, Сэма Гросса, Сумит Чинтала и Петра Доллара опубликовали статью “Сеть MultiPath для распознавания объектов” (“A MultiPath Network for Object Detection”). Задача этой статьи — улучшить методы распознавания объектов, направив внимание на более точную локализацию, а также на сложные изображения с разными масштабами, большим количеством препятствий и лишних деталей. Эта модель использует Fast R-CNN в качестве отправной точки (см. эту статью или мой предыдущий пост). В сущности, эта модель — реализация Fast R-CNN с генерацией гипотез о местоположении объекта с помощью DeepMask и SharpMask. Три основных изменения, описанных в статье, — форвеальные области (forveal regions), skip connections, интегральная функция потерь (integral loss). Но прежде, чем углубляться, давайте взглянем на архитектуру сети.

Архитектура сети / фовеальные области

Как в Fast R-CNN, мы передает входное изображение через VGG-сеть без полносвязных слоев. ROI pooling слой используется для извлечения признаков из гипотез (region proposals) (как помним из статьи о Fast R-CNN, ROI poling — это метод составления из характеристик изображения карты признаков определенной области изображения). Для каждой гипотезы мы обрезаем изображение четырьмя различными способами, чтобы рассмотреть объект в разных масштабах. Это и есть “фовеальные области”, о которых шла речь во введении. Эти обрезанные фрагменты проходят через полносвязные слои, выходные данные объединяются, а сеть распадается на ветку классификации (classification head) и ветку регрессии (regression head). Авторы предполагают, что это фовеальные области помогут более точно определять местоположение объекта, потому что так сеть сможет видеть объект в различных масштабах и в различном окружении.

Skip Connections

Благодаря Fast R-CNN, после последнего сверточного слоя VGG входное изображение 32х32 будет быстро сжато до размеров 2х2. ROI pooling слой создаст карту 7х7, но мы все равно потеряем много пространственной информации. Чтобы решить эту проблему, мы объединяем признаки из словем conv3, conv4 и conv5, а результат передаем форвеальному классификатору. Как утверждается в статье, это объединение “дает классификатору доступ к информации о признаках из различных областей изображения”.

Интегральная функция потерь

Не хочется углубляться в эту тему, ибо думаю, что вся математика гораздо лучше объясняется в самой статье, но в целом идея в том, что авторы вывели функцию потерь, которая работает лучше с многими значениями Intersection over Union (IoU).

Чем крута эта статья

Если вы поклонник Fast R-CNN, то вам точно понравится эта модель. Она использует основные идеи VGG Net и ROI pooling, в то же время создавая новый способ более точной локализации и классифткации с помощью форвеальных областей, skip connections и интегральной функции потери.

Кажется, Facebook отлично освоил всю эту науку о CNN.

Если вам есть что добавить, или вы можете иначе объяснить какую-либо из статей, дайте знать в комментариях.

Код DeepMask и SharpMask. Код MultuiPathNet.

→ Ссылка на оригинал

→ Источники

О, а приходите к нам работать? 🙂wunderfund.io — молодой фонд, который занимается высокочастотной алготорговлей. Высокочастотная торговля — это непрерывное соревнование лучших программистов и математиков всего мира. Присоединившись к нам, вы станете частью этой увлекательной схватки.

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

Присоединяйтесь к нашей команде: wunderfund.io

Организация памяти / Habr

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

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

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

Так ладно, хватит о печальном, переходим к делу.
Рассмотрим адресное пространство программного режима 32 битного процессора (для 64 бит все по аналогии)
Адресное пространство этого режима будет состоять из 2^32 ячеек памяти пронумерованных от 0 и до 2^32-1.
Программист работает с этой памятью, если ему нужно определить переменную, он просто говорит ячейка памяти с адресом таким-то будет содержать такой-то тип данных, при этом сам програмист может и не знать какой номер у этой ячейки он просто напишет что-то вроде:
int data = 10;
компьютер поймет это так: нужно взять какую-то ячейку с номером стопицот и поместить в нее цело число 10. При том про адрес ячейки 18894 вы и не узнаете, он от вас будет скрыт.

Все бы хорошо, но возникает вопрос, а как компьютер ищет эту ячейку памяти, ведь память у нас может быть разная:
3 уровень кэша
2 уровень кэша
1 уровень кэша
основная память
жесткий диск

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

Архитектура х86 поддерживает стек.

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

push operand
помещает операнд в стек

pop operand
изымает из вершины стека значение и помещает его в свой операнд

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

Теперь кратко рассмотрим что такое регистры.
Это ячейки памяти в самом процессоре. Это самый быстрый и самый дорогой тип памяти, когда процессор совершает какие-то операции со значением или с памятью, он берет эти значения непосредственно из регистров.
В процессоре есть несколько наборов логик, каждая из которых имеет свои машинные коды и свои наборы регистров.
Basic program registers (Основные программные регистры) Эти регистры используются всеми программами с их помощью выполняется обработка целочисленных данных.
Floating Point Unit registers (FPU) Эти регистры работают с данными представленными в формате с плавающей точкой.
Еще есть MMX и XMM registers эти регистры используются тогда, когда вам надо выполнить одну инструкцию над большим количеством операндов.

Рассмотрим подробнее основные программные регистры. К ним относятся восемь 32 битных регистров общего назначения: EAX, EBX, ECX, EDX, EBP, ESI, EDI, ESP
Для того чтобы поместить в регистр данные, или для того чтобы изъять из регистра в ячейку памяти данные используется команда mov:

mov eax, 10
загружает число 10 в регистр eax.

mov data, ebx
копирует число, содержащееся в регистре ebx в ячейку памяти data.

Регистр ESP содержит адрес вершины стека.
Кроме регистров общего назначения, к основным программным регистрам относят шесть 16битных сегментных регистров: CS, DS, SS, ES, FS, GS, EFLAGS, EIP
EFLAGS показывает биты, так называемые флаги, которые отражают состояние процессора или характеризуют ход выполнения предыдущих команд.
В регистре EIP содержится адрес следующей команды, которая будет выполнятся процессором.
Я не буду расписывать регистры FPU, так как они нам не понадобятся. Итак наше небольшое отступление про регистры и стек закончилось переходим обратно к организации памяти.

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

Логический адрес —> Линейный (виртуальный)—> Физический

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

Линейный адрес вычисляется по формуле:

линейный адрес=Базовый адрес сегмента(на картинке это начало сегмента) + смещение

Сегмент кода

Базовый адрес сегмента кода берется из регистра CS. Значение смещения для сегмента кода берется из регистра EIP, в котором хранится адрес инструкции, после исполнения которой, значение EIP увеличивается на размер этой команды. Если команда занимает 4 байта, то значение EIP увеличивается на 4 байта и будет указывать уже на следующую инструкцию. Все это делается автоматически без участия программиста.
Сегментов кода может быть несколько в нашей памяти. В нашем случае он один.

Сегмент данных

Данные загружаются в регистры DS, ES, FS, GS
Это значит что сегментов данных может быть до 4х. На нашей картинке он один.
Смещение внутри сегмента данных задается как операнд команды. По дефолту используется сегмент на который указывает регистр DS. Для того чтобы войти в другой сегмент надо это непосредственно указать в команде префикса замены сегмента.

Сегмент стека

Используемый сегмент стека задается значением регистра SS.
Смещение внутри этого сегмента представлено регистром ESP, который указывает на вершину стека, как вы помните.
Сегменты в памяти могут друг друга перекрывать, мало того базовый адрес всех сегментов может совпадать например в нуле. Такой вырожденный случай называется линейным представлением памяти. В современных системах, память как правило так организована.

Теперь рассмотрим определение базовых адресов сегмента, я писал что они содержаться в регистрах SS, DS, CS, но это не совсем так, в них содержится некий 16 битный селектор, который указывает на некий дескриптор сегментов, в котором уже хранится необходимый адрес.

Так выглядит селектор, в тринадцати его битах содержится индекс дескриптора в таблице дескрипторов. Не хитро посчитать будет что 2^13 = 8192 это максимальное количество дескрипторов в таблице.
Вообще дескрипторных таблиц бывает два вида GDT и LDT Первая называется глобальная таблица дескрипторов, она в системе всегда только одна, ее начальный адрес, точнее адрес ее нулевого дескриптора хранится в 48 битном системном регистре GDTR. И с момента старта системы не меняется и в свопе не принимает участия.
А вот значения дескрипторов могут меняться. Если в селекторе бит TI равен нулю, тогда процессор просто идет в GDT ищет по индексу нужный дескриптор с помощью которого осуществляет доступ к этому сегменту.
Пока все просто было, но если TI равен 1 тогда это означает что использоваться будет LDT. Таблиц этих много, но использоваться в данный момент будет та селектор которой загружен в системный регистр LDTR, который в отличии от GDTR может меняться.
Индекс селектора указывает на дескриптор, который указывает уже не на базовый адрес сегмента, а на память в котором хранится локальная таблица дескрипторов, точнее ее нулевой элемент. Ну а дальше все так же как и с GDT. Таким образом во время работы локальные таблицы могут создаваться и уничтожаться по мере необходимости. LDT не могут содержать дескрипторы на другие LDT.
Итак мы знаем как процессор добирается до дескриптора, а что содержится в этом дескрипторе посмотрим на картинке:
Дескрипторы состоит из 8 байт.
Биты с 15-39 и 56-63 содержат линейный базовый адрес описываемым данным дескриптором сегмента. Напомню нашу формулу для нахождения линейного адреса:

линейный адрес = базовый адрес + смещение

С помощью такой нехитрой операции процессор может обращаться по нужному адресу линейной памяти.
Рассмотрим другие биты дескриптора, очень важным является Segment Limit или предел, он имеет 20битное значение от 0-15 и 48-51 бит. Предел задает размер сегмента. Для сегментов данных и кода доступными являются все адреса, расположенные в интервале:

[база; база+предел)

В зависимости от 55 G-бита(гранулярити), предел может измеряться в байтах при нулевом значении бита и тогда максимальный предел составит 1 мб, или в значении 1, предел измеряется страницами, каждая из которых равна 4кб. и максимальный размер такого сегмента будет 4Гб.
Для сегмента стека предел будет в интервале:

(база+предел; вершина]

Кстати интересно почему база и предел так рвано располагаются в дескрипторе. Дело в том что процессоры х86 развивались эволюционно и во времена 286х дескрипторы были по 8 бит всего, при этом старшие 2 байта были зарезервированы, ну а в последующих моделях процессоров с увеличением разрядности дескрипторы тоже выросли, но для сохранения обратной совместимости пришлось оставить структуру как есть.
Значение адреса «вершина» зависит от 54го D бита, если он равен 0, тогда вершина равна 0xFFF(64кб-1), если D бит равен 1, тогда вершина равна 0xFFFFFFFF (4Гб-1)
С 41-43 бит кодируется тип сегмента.
000 — сегмент данных, только считывание
001 — сегмент данных, считывание и запись
010 — сегмент стека, только считывание
011 — сегмент стека, считывание и запись
100 — сегмент кода, только выполнение
101- сегмент кода, считывание и выполнение
110 — подчиненный сегмент кода, только выполнение
111 — подчиненный сегмент кода, только выполнение и считывание

44 S бит если равен 1 тогда дескриптор описывает реальный сегмент оперативной памяти, иначе значение S бита равно 0.

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

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