Разработка WEB-приложения для тестирования программного обеспечения

Размещено на http://www.allbest.ru

Размещено на http://www.allbest.ru

Введение

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

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

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

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

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

Все вышесказанное определило актуальность темы работы - Разработка web-приложения для тестирования программного обеспечения

Целью дипломного проекта (работы) является разработка web-приложения для отслеживания ошибок в программном обеспечении.

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

1) Изучить возможности языка JS.

2) Рассмотреть принцип взаимодействия при использовании технологии RestFull API.

3) Разработать web-приложение для тестирования ПО.

4) Провести анализ выполненной работы.

Объектом исследования является разработка клиент-серверных web-приложений;

Предметом исследования является разработка web-приложение на языке JS.

Основными источниками информации для написания работы послужили книги, а так же публикации в открытом доступе сети Интернет.

1. Язык JavaScript

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

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

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

1.1 MVC и организация пространства имен

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

В JavaScript можно определить пространство имен функций и переменных, сделав их свойством объекта. Например:

var User = {

records: [ / * . . . * / ]

>;

Для массива пользователей определено должное пространство имен под свойством User.records. Функции, связанные с пользователями, также могут быть заключены в пространство имен модели User. Например, у нас может быть функция fetchRemote() для извлечения пользовательских данных из сервера:

var User = { records: [],

fetchRemote: function(){ / * . . . * / }

>;

Содержание всех свойств модели в пространстве имен гарантирует отсутствие каких-либо конфликтов и совместимость этой модели со схемой MVC. Это также оберегает ваш код от скатывания вниз к мешанине из функций и внешних (обратных) вызовов.

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

var user = new User; user.destroy()

Чтобы добиться этого, нам нужно сделать User классом, а не обычным объектом:

var User = function(atts){ this.attributes = atts || {};

};

User.prototype.destroy = function(){

/ * . . . * /

};

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

User.fetchRemote = function(){

/* ... */

};

программный веб реляционный

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

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

1.2 Прототипное наследование

Для создания нашего ORM мы собираемся воспользоваться функцией Object. create(), которая немного отличается от рассмотренных в главе 1 примеров, основанных на классах. Это позволит нам вместо функций-конструкторов и ключевого слова new использовать наследование, основанное на прототипах.

Функции Object.create() передается один аргумент, объект-прототип, а она воз­ вращает новый объект с указанным объектом-прототипом. Иными словами, вы даете ей объект, а она возвращает новый объект, унаследованный от указанного вами объекта.

Функция Object.create() была недавно добавлена к ECMAScript, пятое издание, поэтому в некоторых браузерах, таких как IE, она не реализована. Но это не проблема, поскольку мы при необходимости запросто можем добавить ее поддержку:

if (typeof Object.create !== "function") Object.create = function(o) {

function F() {> F.prototype = o; return new F();

};

Показанный выше пример был позаимствован у Дугласа Крокфорда (Douglas Crockford) из его статьи «Prototypal Inheritance». Почитайте эту статью, если вы хотите глубже изучить основы прототипов и наследования в JavaScript.

Мы собираемся создать объект Model, который будет отвечать за создание новых моделей и экземпляров:

var Model = {

inherited: function(){}> created: function(){},

prototype: {

init: function(){}

b

create: function(){

var object = Object.create(this); object.parent = this;

object.prototype = object.fn = Object.create(this.prototype);

object.created();

this.inherited(object); return object;

b

init: function(){

var instance = Object.create(this.prototype); instance.parent = this; instance.init.apply(instance, arguments); return instance;

}

>;

Если вы незнакомы с функцией Object.сreate(), этот код может показаться отпугивающим, поэтому давайте разберем его по частям. Функция create() возвращает новый объект, унаследованный у объекта Model, -- мы воспользуемся этим для создания новых моделей. Функция init() возвращает новый объект, унаследованный у Model.prototype, -- т. е. экземпляр объекта Model:

var Asset = Model.create(); var User = Model.create();

var user = User.initQ;

Теперь, если мы добавим свойства к Model, они будут доступны во всех унаследованных моделях:

// Добавление свойств объекта jQuery.extend(Model, {

find: function(){}

» ;

// Добавление свойств экземпляра jQuery.extend(Model.prototype, {

init: function(atts) {

if (atts) this.load(atts);

b

load: function(attributes){ for(var name in attributes)

this[name] - attributes[name];

>

» ;

Функция jQuery.extend() является всего лишь более коротким способом использования цикла for для самостоятельного копирования с перебором всех свойств, аналогично тому, что мы делали в функции load(). Теперь наши свойства объекта и экземпляра распространяются вниз на наши отдельные модели:

assertEqual( typeof Asset.find, "function" );

Фактически мы собираемся добавить множество свойств, поэтому мы можем так­ же сделать extend() и include() частью объекта Model:

var Model = {

/* ... фрагмент ... */

extend: function(o){

var extended = o.extended; jQuery.extend(this, o);

if (extended) extended(this);

b

include: function(o){

var included = o.included; jQuery.extend(this-prototype, o); if (included) included(this);

>

};

// Добавление свойств объекта Model.extend({

find: function(){}

» ;

// Добавление свойств экземпляра Model.include({

init: function(atts) { /* ... */ }, load: function(attributes){ / * . . . * / }

» ;

Теперь мы можем создать новые активы (assets) и установить атрибуты:

var asset = Asset.init({name: "foo.png"});

Нам нужен способ удерживания записей, т. е. сохранения ссылки на созданные экземпляры, чтобы потом иметь к ним доступ. Мы сделаем это с использованием объекта records, установленного в отношении Model. При сохранении экземпляра мы будем добавлять его к этому объекту, а при удалении экземпляров мы будем удалять их из этого объекта:

// Объект сохраненных активов Model.records - {};

Model.include({

newRecord: true,

create: function(){ this.newRecord = false;

this.parent.records[this.id] = this;

b

destroy: function(){

delete this.parent.records[this.id];

>

» ;

А что насчет обновления существующего экземпляра? Это нетрудно, достаточно обновить ссылку на объект:

Model.include({ update: function(){

this.parent.records[this.id] = this;

>

>);

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

// Сохранение объекта в хэше записей с сохранением ссылки на него Model.include({

save: function(){

this.newRecord ? this.create() : this.update();

}

» ;

А как насчет реализации функции find(), чтобы можно было искать активы по ID?

Model.extend({

// Поиск no ID или выдача исключения find: function(id){

return this.records[id]|| throw("Неизвестная запись ");

>

});

Теперь, преуспев в создании основного ORM, давайте испытаем его в работе:

var asset = Asset.init(); asset.name = "same, same"; asset.id = 1 asset.save();

var asset2 = Asset.init(); asset2.name = "but different"; asset2.id = 2; asset2.save();

assertEqual( Asset.find(l).name, "same, same" ); asset2.destroy();

Добавление поддержки ID.

Пока при каждом сохранении записи нам нужно указывать ID самостоятельно. Нехорошо, но, к счастью, именно это мы можем автоматизировать. Сначала нам нужно найти способ генерирования идентификаторов -- это можно сделать с помощью GUID-генератора (Globally Unique Identifier -- глобально уникальный идентификатор). Итак, технически JavaScript не способен генерировать официальные полноценные 128-разрядные GUID-идентификаторы для использования в API, он может только генерировать псевдослучайные числа. Генерирование по-настоящему случайных GUID-идентификаторов является печально известной и весьма трудной задачей, и операционная система вычисляет их, используя МАС-адрес, позицию мыши и контрольные суммы BIOS, путем измерения электрического шума или радиоактивного распада, и даже с помощью ламп со вплывающими и тонущими в жидкости каплями вязкого вещества, постоянно меняющими свои формы! Но нам вполне хватит и возможностей имеющейся в JavaScript функции Math.random().

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

Math.guid = function(){

return 'хххххххх-хххх-4ххх-уххх-хххххххххххх'.replace(/[xy]/g,

function(c) {

var r = Math.random()*16|0, v = с == 'x' ? r : (r&0x3|0x8); return v.toString(16);

}).toUpperCase();

>;

Теперь, когда у нас есть функция для генерации GUID-идентификаторов, ее интеграция в наш ORM не составит труда. Для этого нужно лишь изменить функцию

create():

Model.extend({ create: function(){

if :( !this.id ) this.id = Math.guid(); this.newRecord = false; this.parent.records[this.id] = this;

}

});

Теперь любые только что созданные записи имеют в качестве ID GUID-идентификаторы:

var asset = Asset.init(); asset.save();

asset.id //=> "54E52592-313E-4F8B-869B-58D61F00DC74"

1.3 Адресация ссылок

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

Проблема в том, что обновление активов нам требуется только при вызове функции update():

var asset = new Asset({name: "foo"}); asset.save();

// Утверждение соответствует истине

assertEqual( Asset.find(asset.id).name, "foo" );

//Давайте изменим свойство, но не будем вызывать update() asset.name = "wem";

//Надо же! Это утверждение дает ложный результат, поскольку теперь актив

//называется "wem"

assertEqual( Asset.find(asset.id).name, "foo" );

Давайте исправим ситуацию, создав новый объект в процессе операции find(). Нам также нужно создать дубликат объекта при каждом создании или обновле­ нии записи:

Asset.extend({

find: function(id){

var record = this.records[id];

if ( !record ) throw("Hen3BecTHafl запись"); return record.dup();

}

});

Asset.include({ create: function(){

this.newRecord = false; this.parent.records[this.id] = this.dup();

b

update: function(){ this.parent.records[this.id] = this.dup();

dup: function(){

return jQuery.extend(true, {}, this);

}

» ;

Есть еще одна проблема: Model.records является объектом, который совместно используется каждой моделью:

assertEqual( Asset.records, Person.records );

Это имеет досадный побочный эффект смешивания всех записей:

var asset = Asset.init(); asset.save();

assert( asset in Person.records );

Решение состоит в создании нового объекта records при каждом создании новой модели. Функция Model.created() является внешним вызовом для создания нового объекта, поэтому мы можем создавать любые объекты, которые там определены для модели:

Model.extend({ created: function(){

this.records = {};

}

});

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

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

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

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

Данные должны быть представлены в составе кода начальной страницы или загружаться с помощью отдельных HTTP-запросов с применением Ajax или JSONP. Лично я хочу порекомендовать последние две технологии, поскольку включение большого объема данных в состав кода увеличивает размер страницы, в то время как загрузка с помощью параллельных запросов осуществляется быстрее. AJAX и JSON также позволяют вам кэшировать HTML-страницу, вместо динамического вывода по каждому запросу.

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

Для этого нужно лишь вывести JSON-объект непосредственно в страницу. Например, в Ruby on Rails это делается следующим образом:

<script type="text/javascript"> var User = {};

User.records = <%= raw @users.to_json %>; </script>

ERB-теги используются для вывода JSON-интерпретации данных пользователя. Метод raw используется просто для приостановки нейтрализации JSON. При выводе страницы HTML выглядит следующим образом:

<script type="text/javascript"> var User = {};

User.records = [{"first_name": "Alex"}]; </script>

JavaScript может просто обработать JSON, поскольку этот формат имеет такую же структуру, что и объект JavaScript.

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

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

url

Запрашиваемый URL. По умолчанию --текущая страница,

success

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

contentType

Устанавливает для запроса заголовок Content-Type. Если запрос содержит данные, то по умолчанию устанавливается заголовок application/x-www-form-urlencoded, который подходит для большинства случаев.

data

Данные, отправляемые на сервер. Если они еще не в строковом виде, jQuery их преобразует в последовательную форму и закодирует в URL.

type

Используемый HTTP-метод: GET, POST или DELETE. По умолчанию ис­ пользуется метод GET.

dataType

Тип данных, ожидаемых с сервера. jQuery нужно это знать, чтобы понимать, что делать с результатом. Если dataType не указан, jQuery выстроит догадку на основе MIME-типа полученного ответа. Поддерживаются следующие значения:

text

Ответ в виде простого текста; обработка не требуется,

script

jQuery обрабатывает ответ как JavaScript,

json

jQuery обрабатывает ответ как JSON, используя строгий анализатор,

jsonp

Для JSONP-запросов, подробное рассмотрение которых нам еще предстоит.

Давайте, к примеру, сделаем простой Ajax-запрос, который выводит извещение о любых данных, возвращенных сервером:

jQuery.ajax({

url: "/ajax/endpoint", type: "GET",

success: function(data) { alert(data);

}

});

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

jQuery.get("/ajax/endpoint", function(data){ $(".ajaxResult").text(data);

» ;

Или же если нужно отправить ряд параметров запроса с помощью GET-метода:

jQuery.get("/ajax/endpoint", {foo: "bar"}, function(data){

/* . . . * /

»;

Если с сервера ожидается возвращение данных в формате JSON, нужно вместо этого вызвать функцию jQuery.getDSON(), которая установит для параметра data - Туре запроса значение "json":

jQuery.getDSON("/j son/endpoint", function(j son){

});

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

jQuery.post(H/usersH, {first_name: "Alex"}, function(result){ /* Ajax POST завершен успешно */});

Если нужно воспользоваться другими HTTP-методами -- DELETE, HEAD и OP­ TIONS, --придется воспользоваться имеющей более низкий уровень функцией jQuery.ajax().

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

Ограничением для Ajax служит политика исходного источника (same origin policy), которая ограничивает запросы тем же доменом, субдоменом и портом, что и у адреса страницы, с которой сделаны эти запросы. На это есть веские причины: при отправке Ajax-запроса с ним вместе отправляется вся информация из cookie-файлов домена. Это означает, что для удаленного сервера запрос окажется от вошедшего в систему пользователя. Без применения политики исходного источника злоумышленник потенциально может скопировать все ваши адреса электронной почты из Gmail, обновить ваш статус на Facebook или направить сообщение читателям вашего Твиттера, что считается существенной прорехой в системе безопасности.

Но когда политика исходного источника встроена в систему безопасности Интернета, это также создает неудобства для тех разработчиков, которые пытаются обратиться к допустимым удаленным ресурсам. В других технологиях, например в Adobe Flash и в Java, были реализованы методы, позволяющие обойти проблему междоменных файлов политики, и теперь Ajax связан стандартом, который называется междоменным совместным использованием исходных ресурсов -- CORS (cross-origin resource sharing).

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

Использовать CORS довольно просто. Если нужно получить авторизованный доступ к вашему серверу, следует просто добавить несколько строк к НТТР-заголовку возвращенных ответов:

Access-Control-Allow-Origin: example.com

Access-Control-Request-Method: GET,POST

Показанный выше заголовок проведет авторизацию междоменных GET-и POST-запросов с example.com. Несколько значений нужно отделять друг от друга запятыми, как это было в нашем примере со значениями GET, POST. Чтобы открыть доступ с дополнительных доменов, их нужно просто перечислить в заголовке Access-Control-Allow-Origin, используя в качестве разделителей запятые. Можно открыть доступ для любого домена, просто указав для заголовка источника (origin) звездочку (*).

Некоторые браузеры, например Safari, сначала сделают запрос OPTIONS, что­ бы проверить допустимость запроса. А вот Firefox сделает запрос, и если CORS-заголовки не установлены, просто выдаст защитное исключение. Эту разницу в поведении нужно будет учесть на стороне сервера.

Можно даже авторизовать заголовки специализированного запроса, воспользовавшись заголовком Access-Control-Request-Headers:

Access-Control-Request-Headers: Authorization

Это означает, что клиенты могут добавить к Ajax-запросам специализированные заголовки, например давая запросу подпись открытого протокола авторизации OAuth:

var req = new XMLHttpRequest(); req.open("POST", "/endpoint", true);

req.setRequestHeader("Authorization", oauth_signature);

К сожалению, несмотря на то что CORS работает с версиями Internet Explorer от 8 и выше, Microsoft решила проигнорировать спецификацию и рекомендации рабочей группы. Microsoft создала свой собственный объект, XDomainRequest, который также предназначался для использования вместо XMLHttpRequest в случае междоменных запросов. Хотя его интерфейс аналогичен интерфейсу XMLHttpRequest, у него есть ряд препятствий и ограничений. Например, работают только методы GET и POST, не поддерживаются аутентифицирующие или специализированные заголовки, и наконец, что совсем неожиданно, поддерживаются только заголовки «Content-Type:text/plain». Если вы готовы мириться с такими ограничениями, то, используя правильные заголовки Access-Control, вы можете воспользоваться CORS при работе в IE.

2. Фреймворк AngularJS

AngularJS является основой веб-приложений с открытым исходным кодом. Изначально он был разработан в 2009 году Misko Hevery и Adam Abrons. Cейчас поддерживается поддерживается Google. Его последняя версия 1.5 и AngularJS 2 beta.

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

2.1 Особенности AngularJS

AngularJS является мощным JavaScript фреймворком для создания многофункциональных интернет-приложений (RIA).

AngularJS предоставляет возможность разработчикам писать приложения на стороне клиента (с помощью JavaScript) с чистым MVC (Model View Controller).

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

AngularJS является open source, полностью бесплатный, и используется тысячами разработчиков по всему миру. Распространяется под лицензией Apache License версии 2.0.

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

Основные особенности AngularJS.

Ниже приведены наиболее важные основные черты AngularJS.

Data-binding -- Это автоматическая синхронизация данных между моделью и представлением.

Scope -- Это объекты, которые относятся к модели. Они действуют как клей между контроллером и видом.

Controller -- Эти функции JavaScript, которые связаны с конкретным Scope.

Services -- AngularJS поставляются с несколькими встроенными служб, например, $http, чтобы сделать XMLHttpRequests. Это одноэлементные объекты, которые построены по принципу singleton.

Filters -- Выбрать подмножество элементов из массива и возвращает новый массив.

Directives -- Директивы являются маркерами на элементы DOM (такие как элементы, атрибуты, CSS, и многое другое). Они могут быть использованы для создания пользовательских HTML тегов, которые служат в качестве новых, пользовательских виджетов. AngularJS имеет встроенные директивы (ngBind, ngModel…)

Templates -- Это рендер вида с информацией из контроллера и модели. Это может быть один файл (например, index.html) или несколько представлений на одной странице с помощью «partials».

Routing -- Это концепция переключения видов.

Model View Whatever -- MVC является шаблоном для разделения приложения на разные части (так называемый Model, View и Controller), каждый с различными обязанностями. AngularJS не реализует MVC в традиционном понимании этого слова, а скорее что-то ближе к MVVM (Model-View-ViewModel). Команда Angularjs относится это юмористически, как Model View Whatever.

Deep Linking -- Глубокие ссылки позволяет кодировать состояние приложения в URL, так что он может быть закладкой. После этого приложение может быть восстановлен из URL в том же состоянии.

Dependency Injection -- AngularJS имеет подсистему внедрение зависимости, которая помогает разработчику легче разрабатывать, понимать и тестировать.

Идея.

Следующая диаграмма иллюстрирует некоторые важные части AngularJS (Рис. 2.1).

Рис. 2.1 - Компоненты AngularJS

2.2 Преимущества AngularJS

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

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

§ код подходит под Unit Tests.

§ использует внедрение зависимости и использует разделение задач.

§ обеспечивает повторно используемые компоненты.

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

§ В AngularJS, чистые HTML-страницы, а также контроллеры, написанные на JavaScript делает обработку бизнес логики.

Вдобавок ко всему, AngularJS приложения могут работать во всех основных браузерах и смартфонах, Android и IOS.

2.3 Недостатки AngularJS

Хотя AngularJS поставляется с большим количеством плюсов, но то же самое время мы должны учитывать следующие моменты:

§ Не безопасно -- будучи JavaScript фреймворком, приложения, написанные в AngularJS не являются безопасными. Проверка подлинности на стороне сервера и авторизация обязательно должны присутствовать в приложении.

§ Не разлагаемые -- Если пользователь приложения отключает JavaScript, тогда он будет просто видеть HTML страницу и больше ничего.

AngularJS можно разделить на следующие три основные части --

§ ng-app -- Эта директива определяет и привязывает AngularJS к HTML.

§ ng-model -- Эта директива связывает значения данных приложения AngularJS в HTML элементы ввода.

§ ng-bind -- Эта директива связывает данные AngularJS для HTML-тегов.

3. Концепции в фрейморках JavaScript

Позиция AngularJS по работе с данными и другими инженерными концепциями отличается от таких фреймворков, как Backbone.js and Ember.js. Мы довольствуемся уже известным нам HTML, а Angular самостоятельно его улучшает. Angular обновляет DOM при любых изменениях Модели, которая живёт себе в чистых Объектах JavaScript с целью связи с данными. Когда обновляется Модель, Angular обновляет Объекты, которые содержат актуальную информацию о состоянии приложения.

3.1 MVC и MVVM

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

Держитесь за кресло - в Angular существует разделение обязанностей и динамический HTML. А это значит, что наши данные живут в Модели, наш HTML живёт в виде маленького шаблона, который будет преобразован в Вид, а Контроллер мы используем для соединения двух этих понятий, обеспечивая поддержку изменений Модели и Вида. То есть, навигация может выводиться динамически, создаваясь из одного элемента списка, и автоматически повторяться для каждого пункта из Модели. Это упрощённая концепция, позже мы ещё поговорим о шаблонах.

Разница между MVC и MVVM в том, что MVVM специально предназначен для разработки интерфейсов. Вид состоит из слоя презентации, ВидМодель содержит логику презентации, а Модель содержит бизнес-логику и данные. MVVM была разработана для облегчения двусторонней связи данных, на чём и процветают фреймворки типа AngularJS. Мы сосредоточимся на пути MVVM, так как в последние годы Angular склоняется именно туда.

3.2 Двусторонняя связь данных

Двусторонняя связь данных - очень простая концепция, предоставляющая синхронизацию между слоями Модели и Вида. Изменения Модели передаются в Вид, а изменения Вида автоматически отражаются в Модели. Таким образом, Модель становится актуальным источником данных о состоянии приложения.

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

Связываем мы эти значения через выражения Angular, которые доступны в виде управляющих шаблонов. Также мы можем связывать Модели через атрибут под названием ng-model. Angular использует свои атрибуты для разных API, которые обращаются к ядру Angular.

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

В приложении на одну страницу (SPA) либо весь необходимый код (HTML, CSS and JavaScript) вызывается за одну загрузку страницы, либо нужные ресурсы подключаются динамически и добавляются к странице по необходимости, обычно в ответ на действия пользователя. Страница не перезагружается во время работы, не передаёт управление другой странице, хотя современные технологии из HTML5 позволяют одному приложению работать на нескольких логических страницах. Взаимодействие с SPA часто происходит при помощи фонового общения с сервером.

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

Времена изменились, браузер хранит состояние приложение, сложная логика и фреймворки приобрели популярность. AngularJS хранит состояние в браузере и передаёт изменения при необходимости через Ajax (HTTP) с использованием методом GET, POST, PUT и DELETE. Красота в том, что сервер может быть независим от фротенда, а фронтенд - от сервера. Те же самые сервера могут работать с мобильными приложениями с совершенно другим фронтендом. Это даёт нам гибкость, так как на бэкенде мы работаем с JSON-данными любым удобным нам способом на любом серверном ЯП.

У Angular есть разные API, но структура приложения обычно одна и та же, поэтому почти все приложения строятся сходным образом и разработчики могут включаться в проект без усилий. Также это даёт предсказуемые API и процессы отладки, что уменьшает время разработки и быстрое прототипирование. Angular построен вокруг возможности тестирования («testability»), чтобы быть наиболее простым как в разработке, так и в тестировании.

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

У приложения есть один модуль app.

angular.module('app', []);

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

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

angular.module('app');

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

var app = angular.module('app', []);

Теперь мы можем использовать переменную app для построения приложения.

Для описания того, где приложение находится в DOM, а обычно это элемент <html>, нам надо связать атрибут ng-app с модулем. Так мы сообщаем Angular, куда подгрузить наше приложение.

<html ng-app="app">

<head></head>

<body></body>

</html>

Если мы грузим файлы с JavaScript асинхронно, нам надо подгрузить приложение вручную через angular.bootstrap(document.documentElement, ['app']);.

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

Это позволяет проще работать с шаблонами, когда мы используем при этом синтакс HTML, а Angular рендерит соответствующие значения $scope. Это создаёт связь между JavaScript и DOM.

В общем, $scope играет роль ViewModel. $scope используется только внутри Контроллеров.

Там мы привязываем данные Контроллера к Виду.

Вот пример того, как мы объявляем данные в Контроллере:

$scope.someValue = 'Hello';

Чтобы это отобразилось в DOM, мы должны присоединить Контроллер к HTML и сообщить Angular, куда вставлять значение.

<div ng-controller="AppCtrl">

{{ someValue }}

</div>

Перед вами концепция области видимости Angular, подчиняющаяся некоторым правилам JavaScript в плане лексических областей видимости. Снаружи элемента, к которому присоединён Контроллер, данные находятся вне области видимости - так же, как переменная вышла бы за область видимости, если б мы сослались на неё снаружи её области видимости. Мы можем привязать любые типы JavaScript $scope. Таким образом мы берём данные от сервиса, общающегося с сервером, и передаём их во View, слой презентации. Чем больше мы создадим Контроллеров и связей с данными, тем больше появляется областей видимости. Разобраться в их иерархии ничего не стоит - здесь нам поможет переменная $rootScope.

4. Практическая часть

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

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

2. Создание и просмотр списка задач, привязанных к определенному проекту;

3. Создание тегов, необходимых для отмечания определенных свойств той или иной задачи;

4. Авторизация пользователей.

Данное приложение имеет клиент-серверную архитектуру. Физически клиент и сервер написаны отдельно с использованием отличных языков и технологий. В частности, клиент данного приложения написан с использованием платформы Angularjs, тогда как сервер написан с использованием фреймфорка Ruby on Rails. Данный подход имеет несколько преимуществ

1. Более четкое разделение проекта на логику и представление;

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

Последний пункт возможен благодаря, так называемому, RESTfull API. REST (сокр. от англ. Representational State Transfer -- «передача репрезентативного состояния») -- метод взаимодействия компонентов распределённого приложения в сети Интернет, при котором вызов удаленной процедуры представляет собой обычный HTTP-запрос (обычно GET или POST; такой запрос называют REST-запрос), а необходимые данные передаются в качестве параметров запроса. Этот способ является альтернативой более сложным методам, таким как SOAP, CORBA и RPC.

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

При использовании RESTfull API удобно оперировать данными как ресурсами, к которым можно применять операции чтения, добавления, удаления и редактирования. В англоязычной литературе набор таких операция описывается термином CRUD (create, read, update, destroy). Каждое действие стандартизировано в рамках интерефейса. На примере нашего приложения рассмотрим, как организован API.

В качестве примера возьмем ресурс Проекты (projects). Т.к. общение клиента и сервера происходят по протоколу http, то для отправки команд можно использовать различные методы передачи (GET, POST, PUT, DELETE). Вот как выглядит API для управления ресурсом projects

Табл. 1. Управление ресурсом projects посредством RESTfull API

Метод	URL	Действие
GET	/projects	Возвращает список проектов
POST	/photos	Создает новый проект
GET	/photos/:id	Возвращает проект с ID = :id
PUT	/photos/:id	Обновляет проект с ID = :id
DELETE	/photos/:id	Удаляет проект с ID = :id

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

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

Общий вид архитектуры приложения с использованием RESTfull API отражен на рисунке 4.1.

Рис. 4.1 - Клиент-серверное приложение, разработанное с использованием RESTfull API

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

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

Рис. 4.2 - Главная страница системы

На ней можно заметить панель инструментов, расположенную сверху. Данная панель доступна в пределах всего приложения. С помощью нее осуществляется навигация по следующим разделам:

? Проекты.

? Теги.

? Главная страница.

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

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

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

Рис. 4.3 - Внешний вид формы авторизации

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

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

Список проектов представляет собой таблицу, в которой в каждой строке имеется краткая информация о каждом проекте: ID, название, дата создания. Внешний вид списка проектов представлен на рисунке 4.4.

Рис. 4.4 - Внешний вид списка проектов

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

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



Рис. 4.5 - Внешний вид окна карточки проекта

В данной карточке, помимо названия и ID, указана так же дата создания проекта. Данные представлены в табличном виде. Так же имеется возможность перейти на список список задач, привязанных к данному проекту, посредством клика на ссылку “Список задач”.

Привязка проекта и задач к определенному пользователю осуществляется за счет вложеных url (nested routes). То есть, ссылки, представленные выше при описании RESTfull API дополняются, например, информацией о текущем пользователе или текущем проекте. Например, создание задачи, привязанной к определенному проекту, доступне по ссылке следующего вида:

POST /projects/:projectid/tasks

где: projectid - это уникальный идентификатор искомого проекта. Таким же образом создаются другие вложенные сущности в проекте.

Рассмотрим подробнее форму для создания проекта. Она представлена на рисунке 4.6

Рис. 4.6 - Внешний вид формы для создания проекта

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

Еще одной немаловажной сущностью приложения являются теги. Они позволяют добавлять к задачам определённые пометки, которые тем или иным образом характеризуют проект. Например, к задаче можно добавить тег “Критичный”, “Ядро”. И тем самым пользователь может сделать какие-то выводы без вникания в саму суть задачи.

В интерфейсе нашего приложения есть доступ к списку тегов. Теги доступны при клике по ссылке “Теги” в верхней панели нашего приложения. При этом открывается список тегов, который выглядит как на рисунке 4.7.

Рис. 4.7 - Внешний вид списка тегов

Список тегов представляет из себя таблицу с простой структурой: в качестве полей для тегов используется ID и название. В будущем планируется ассоциировать тег с каким либо цветом. Это позволит лучше акцентировать внимание на тегах при просмотре списка задач.

Для добавления дополнительных тегов в систему служит ссылка “Создать тег”. При клике по ссылке мы переходим на форму создания тега, которая состоит из единственного поля “Название тега”. Внешний вид формы добавления тега представлен на рисунке 4.8.



Рис. 4.8 - Форма добавления тега

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

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

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

Рис. 4.9 - Внешний вид списка задач

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

...