Skip to content

Билет 2

Jump to bottom Edit New page
Evgeny edited this page Dec 16, 2018 · 25 revisions

Билет 2

ИДМ-18-01

  • Федоров Д.В.
  • Андриянов Е.С.
  • Анисимов О.Э.
  • Лаптев А.С.

1) Понятия информации, данных, знаний. Средства онтологического описания интернет-ресурсов (OWL).

Термин данные происходит от слова data - факт, а информация (informatio) означает разъяснение, изложение, т.е. сведения или сообщение.

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

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

Знания – это зафиксированная и проверенная практикой обработанная информация, которая использовалась и может многократно использоваться для принятия решений.

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

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

Неформальные знания – это знания и опыт специалистов в определенной предметной области.

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

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

OWL

OWL (Web Ontology Language, в аббревиатуре буквы намеренно переставлены местами, чтобы получилось английское слово "сова") - язык представления онтологий в Web. Фактически это словарь, расширяющий набор терминов, определенных RDFS. OWL-онтологии могут содержать описания классов, свойств и их экземпляров. Создание OWL - это ответ на необходимость представления знаний в Сети в едином формате. Исторически предшественником OWL был язык DAML+OIL, объединивший 2 инициативы: проект DAML (DARPA Agent Markup Language) и проект OIL (Ontology Inference Layer). Наиболее ранним проектом представления онтологий в Web был SHOE (Simlpe HTML Ontology Extensions). Ветви развития языков описания онтологий для Web показаны на рис. 6.4. Верхний уровень: OIL, DAML+OIL и OWL продолжают развиваться, но наибольшей популярностью пользуется OWL. Язык OWL имеет 3 диалекта (подмножества терминов).

  1. OWL Lite - имеет наименьшую выразительную мощность из всех, но для решения простых задач его может быть достаточно. Данный диалект языка OWL эквивалентен некоторой дескриптивной логике (разрешимой части логики предикатов первого порядка). OWL Lite обладает важнейшим свойством - разрешимостью. Именно разрешимость является главной причиной использования OWL Lite для создания многочисленных практических онтологий (в медицине, биоинформатике и т.п.).
  2. OWL DL - обладает большей выразительной мощью, чем OWL Lite, но тоже эквиваленен некоторой дескриптивной логике. Для большинства задач, встречающихся при проектировании онтологий, выразительности этого диалекта достаточно. OWL DL тоже обладает свойством разрешимости, однако вычислительная сложность у него выше, чем OWL Lite. Разрешимость достигается, в частности, наложением ограничений на синтаксис языка; так, в OWL DL классу запрещено быть экземпляром.
  3. OWL Full - наиболее выразительный диалект. Эквивалентен RDF. При использовании OWL Full нет никаких гарантий по вычислимости заключений.

Базовые элементы OWL

В OWL введен новый термин - класс ( owl:Class ). Необходимость этого объясняется тем, что не все классы диалектов OWL DL и OWL Lite являются RDFS-классами (в этом случае owl:Class является подклассом rdfs:Class ). В диалекте OWL Full подобных ограничений нет, и owl:Class фактически является синонимом rdfs:Class. OWL-класс может быть описан шестью способами:

  1. идентификатором класса (URI);
  2. перечислением всех экземпляров класса;
  3. ограничением на значение свойства;
  4. пересечением 2-х и более определений классов;
  5. объединением 2-х и более определений классов;
  6. дополнением (логическим отрицанием) определения класса.

Только первый способ определяет именованный класс OWL. Все оставшиеся определяют анонимный класс через ограничение его экстенсионала. Способ 2 явно перечисляет экземпляры класса, способ 3 ограничивает экстенсионал только теми экземплярами, которые удовлетворяют данному свойству. Способы 4-6 используют теоретико-множественные операции (объединение, пересечение и дополнение) над экстенсионалами соответствующих классов, чтобы определить экстенсионал нового класса. Описания класса являются строительными блоками для определения классов посредством аксиом. Простейшая аксиома, определяющая именованный класс: <owl:Class rdf:ID="Human"/> В OWL выделяют две категории свойств: свойства-объекты (или объектные свойства ) и свойства-значения. Первые связывают между собой индивиды (экземпляры классов). Вторые связывают индивиды со значениями данных. Оба класса свойств являются подклассами класса rdf:Property. Для определения новых свойств как экземпляров owl:ObjectProperty или owl:DatatypeProperty используются аксиомы свойств. Пример аксиомы: <owl:ObjectProperty rdf:ID="hasParent"/>

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

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

Инструмент для автоматизированного тестирования — это программное обеспечение, посредством которого осуществляется создание, отладка, выполнение и анализ результатов прогона тест-скриптов (Test Scripts — это наборы инструкций для автоматической проверки определенной части программного обеспечения).

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

Инструменты:

HP QuickTest Professional

Средство автоматизации от кампании Hewlett-Packard. Распространяется на платной основе (8000-10000 USD). Является основным инструментом автоматизации функционального тестирования от данного производителя. Позволяет автоматизировать функциональные и регрессионные тесты через записи действий пользователя при работе с тестируемым приложением, а потом исполнять записанные действия с целью проверки работоспособности ПО. Записанные действия сохраняются в виде скриптов. Скрипты могут быть отображенные в инструменте как VBScript (expert view), или же как визуальные последовательные шаги с действиями (keyword view). Каждый шаг может быть отредактирован и на него можно добавить точки проверки (checkpoint), которые сравнивают ожидаемый результат с полученным.

**IBM Rational Functional Tester **

Платный( 6000 USD). Rational Functional Tester предоставляет тестировщикам средства автоматизированного тестирования, позволяющие выполнять функциональное тестирование, регрессивное тестирование, тестирование пользовательского интерфейса и тестирование управляемое данными.

**Selenium **

Бесплатный пакет от компании OpenQA.org. В основе Selenium лежит среда для тестирования web-приложений, реализованная на JavaScript и выполняющая проверки непосредственно средствами браузера. В рамках проекта Selenium выпускается 3 инструмента, каждый из которых имеет свои особенности и область применения: Selenium Core, Selenium IDE, Selenium RC и Selenium GRID. Поддерживаемые технологии: DHML, JavaScript, Ajax Поддерживаемые ОС: Mac OS, Microsoft Windows, Linux, Solaris Язык тестов: HTML, Java, C#, Perl, PHP, Python, и Ruby Тестируемые приложения: веб-приложения.

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

Обратимся к принципам методологии гибкой разработки программного обеспечения и выделим те, на которые непосредственно влияет или может повлиять процесс непрерывной интеграции:

  • удовлетворение потребностей заказчика благодаря ранней и регулярной поставке программного обеспечения;

  • изменение требований даже на поздних этапах разработки;

  • учащение выпуска обновлений продукта;

  • повышение мотивации команды за счет повышения технологичности процесса разработки;

  • стабильный и работающий продукт – основной показатель прогресса;

  • устойчивый и постоянный ритм процесса разработки;

  • постоянное внимание к техническому совершенству и качеству проектирования.

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

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

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

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

  • исходный код продукта и все, что необходимо для сборки и тестирования, должны храниться в системе контроля версий;

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

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

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

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

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

  • Немедленная реакция на неполный или нерабочий код приучает команду к коротким продуктивным циклам работы.

Рисунок 1. Структурная схема стадий непрерывной интеграции

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

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

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

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

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

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

Не лишена непрерывная интеграция и недостатков, а именно:

  • постоянные издержки на поддержку работы;

  • необходимость вычислительных ресурсов.

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

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

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

Add a custom footer
Add a custom sidebar
Clone this wiki locally