Українська   English
ДонНТУ   Портал магистров

Реферат на тему магистерской работы

Содержание

Введение

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

Рассмотрена архитектура RIA (Rich Internet application) приложения для автоматизированного проектирования цифровых устройств с минимальным участием человека, при помощи суперкомпьютерных вычислений.

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

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

1 Актуальность темы

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

2 Актуальность проблемы

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

3 Постановка задачи

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

4 Цель работы

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

5 Выбор базовой архитектуры

5.1 Описание MVC архитектуры

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

Первоначально единственным API, доступным в Java для разработки серверных web-приложений, была технология сервлетов. У сервлетов было много преимуществ по сравнению со сценариями CGI, которые ранее были доминирующей технологией. Тем не менее, у сервлетов имелся один существенный недостаток. Поскольку код HTML, который будет представлен в окне обозревателя, должен был встраиваться в код Java, то большую часть кода сервлета было очень трудно поддерживать [2]. Подобный код был не очень удобен в сопровождении.

Один из распространенных способов приблизиться к разрешению этой проблемы состоит в том, чтобы использовать шаблон проектирования Модель-Представление-Контроллер (Model-View-Controller). Этот шаблон обеспечивает четкое разделение проблем, предоставляя артефакты, используемые исключительно в качестве данных (модели), в то время как другие артефакты отвечают (используются) исключительно за отображение (представление) данных, а третьи несут ответственность за управление данными (контроллер) и передают управление требуемому представлению [3]. Базовая концепция модели MVC представлена на рис. 1.

Базовая концепция модели MVC

Рисунок 1 – Базовая концепция модели MVC

(анимация: 2 кадра, зацикленная, задеркжа между кадрами 0.2 с., 12.3 КБ)

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

5.2 Реализация MVC модели

Наиболее типичная реализация отделяет вид от модели путем установления между ними протокола взаимодействия, используя аппарат событий (подписка/оповещение). При каждом изменении внутренних данных в модели она оповещает все зависящие от неё представления, и представление обновляется. Для этого используется шаблон «наблюдатель»При обработке реакции пользователя вид выбирает, в зависимости от нужной реакции, нужный контроллер, который обеспечит ту или иную связь с моделью. Для этого используется шаблон «стратгия» или вместо этого может быть модификация с использованием шаблона «комана». А для возможности однотипного обращения с подобъектами сложно-составного иерархического вида может использоваться шаблон «Компоновщик». Кроме того, могут использоваться и другие шаблоны проектирования, например, «фабричный метод» который позволит задать по умолчанию тип контроллера для соответствующего вида [9].

Различают две основных модификации модели MVC [10]:

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

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

6 Разработка уровня управления

6.1 Реализация уровня управления как часть MVC архитектуры

В качестве контроллера может служить сама реализация шаблона MVC, которая должна обеспечивать надежную структуру. С этой задачей полностью справляется модуль Spring MVC на базе фреймворка MVC. Он представляет развернутую поддержку данного шаблона, а также других средств (например, оформление темами, интернационализацию, проверку достоверности, преобразование типов, форматирование и т.п.). Главной и самой важной особенностью его является Inversion of сontrol контейнер, который представляет средства конфигурирования и управления объектами Java с помощью отражения. Контейнер отвечает за управление жизненным циклом объекта: создание объектов, вызов методов инициализации и конфигурирование объектов путем связывания их между собой. Объекты, создаваемые контейнером, также называются управляемыми объектами (beans). Обычно конфигурирование контейнера осуществляется путем загрузки XML-файлов, содержащих определение bean’ов и предоставляющих информацию, необходимую для создания bean’ов. Контейнер отвечает за управление жизненным циклом циклом объекта: создание объектов, вызов методов инициализации и конфигурирование объектов путем связывания их между собой [4].

6.2 Spring Framework как основной компонент в приложении

Spring Framework обеспечивает решения многих задач, с которыми сталкиваются Java разработчики и организации, которые хотят создать информационную систему, основанную на платформе Java. Из-за широкой функциональности трудно определить наиболее значимые структурные элементы, из которых он состоит. Spring Framework не всецело связан с платформой Java Enterprise, несмотря на его масштабную интеграцию с ней, что является важной причиной его популярности. Spring Framework, вероятно, наиболее известен как источник расширений (features), нужных для эффективной разработки сложных бизнес-приложений вне тяжеловесных программных моделей, которые исторически были доминирующими в промышленности. Ещё одно его достоинство в том, что он ввел ранее неиспользуемые функциональные возможности в сегодняшние господствующие методы разработки, даже вне платформы Java. Этот фреймворк предлагает последовательную модель и делает её применимой к большинству типов приложений, которые уже созданы на основе платформы Java. Считается, чтоSpring Framework реализует модель разработки, основанную на лучших стандартах индустрии, и делает её доступной во многих областях Java.

Несмотря на то, что Spring Framework не обеспечивал какую-либо конкретную модель программирования, он стал широко распространённым в Java-сообществе главным образом как альтернатива и замена модели Enterprise JavaBeans. Spring Framework предоставляет большую свободу Java-разработчикам в проектировании, кроме того, он предоставляет хорошо документированные и лёгкие в использовании средства решения проблем, возникающих при создании приложений корпоративного масштаба. Между тем, особенности ядра Spring Framework применимы в любом Java-приложении, и существует множество расширений и усовершенствований для построения web-приложений на Java Enterprise платформе. По этим причинам Spring приобрёл большую популярность и признаётся разработчиками как стратегически важный фреймворк.

На безе этого фреймворка была составлена общая структура приложения, представленная на рис. 2

Общая структура приложения

Рисунок 2 – Общая структура приложения

7 Разработка уровня представления

7.1 Основные критерии к web-приложениям

В web-приложениях уровень представления является критически важным и оказывает значительное влияние на степень принятия приложения пользователями. Уровень представления – это своего рода «парадная дверь» в приложение. Он позволяет пользователям выполнять бизнес-функции, представляемые приложением, а также обеспечивает визуальное представление информации, которой управляет приложение. Эффективность пользовательского интерфейса вносит весьма существенный вклад в успех приложения в целом [5].

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

Построение web-приложения, удовлетворяющего указанным выше требованиям, не является простой задачей, однако данные требования рассматриваются пользователями как обязательные. Для решения этих потребностей были разработаны новые технологии и инфраструктуры. В последнее время многие платформы и библиотеки для разработки web-приложений – среди которых Spring MVC, Struts, Java Server Faces (JSF), Google Web Toolkit (GWT), jQuery и Dojo – предлагают инструменты и развитые библиотеки компонентов, помогающие построить высоко интерактивные пользовательские интерфейсы для web-сети.

7.2 RIA в качестве представления

Приложения базирующихся на таких концепциях стали называть RIA – Rich Internet application (Насыщенное интернет-приложение). Это web-приложение, доступное через Интернет, насыщенное функциональностью традиционных настольных приложений, которое предоставляется либо уникальной спецификой браузера, либо через плагин, либо путём «песочницы» (виртуальной машины).

Как правило, приложение RIA:

  1. передаёт веб-клиенту необходимую часть пользовательского интерфейса, оставляя большую часть данных (ресурсы программы, данные и пр.) на сервере;
  2. запускается в браузере и не требует дополнительной установки ПО;
  3. запускается локально в среде безопасности, называемой «песочница» (sandbox).

Недостатки RIA:

  1. «Песочница». Поскольку RIA загружаются в локальной среде безопасности — «песочнице» — они имеют ограниченный доступ к системным ресурсам. Если права на доступ к ресурсам некорректны, RIA могут работать неправильно.
  2. Подключение скриптов. Как правило, для работы RIA требуется JavaScript или другие скриптовые языки. Если пользователь отключил активные сценарии в своем браузере, RIA может не функционировать должным образом или вообще не работать.
  3. Скорость обработки клиентом. Чтобы обеспечить платформенную независимость, некоторые RIA используют скриптовый язык на стороне клиента, например, такой как JavaScript, с частичной потерей производительности (серьёзная проблема для мобильных устройств). Однако такая проблема не возникает при использовании встроенного языка, скомпилированного на стороне клиента, такого как Java, где производительность сопоставима с использованием традиционных встроенных языков, либо с Flash или с Silverlight, в которых программный код запускается непосредственно в плагине Flash Player или Silverlight соответственно.
  4. Время загрузки скрипта. Даже если нет необходимости в установке скрипта, движок клиента RIA должен быть передан клиенту сервером. Поскольку большинство скриптов сохраняются в кэше, он должен быть передан хотя бы один раз. В зависимости от размера и типа передачи, загрузка скрипта может занять довольно много времени. Разработчики RIA могут уменьшить последствия этой задержки посредством сжатия скриптов, а также за счёт разбиения передачи приложения на несколько страниц.
  5. Утрата целостности. Если приложение основано на X/HTML, возможны конфликты между целями приложения (которое, естественно, хочет иметь контроль над его представлением и действиями) и целями X/HTML (которое хочет отдать контроль). Интерфейс DOM для X/HTML делает возможным создание RIA, но это не даёт никаких гарантий, что оно будет работать корректно. Из-за того, что клиент RIA может изменять основную структуру приложения и переопределять его действия и представление, это может привести к ошибке приложения на стороне клиента. В конце концов, эта проблема может быть решена за счёт нового механизма клиент-сервер, предоставляющего клиенту RIA ограниченный доступ к изменению тех ресурсов, которые не входят в сферу его полномочий. Работа родного стандартного ПО не вызывает подобных проблем, поскольку они по определению автоматически обладают всеми необходимыми правами на локальные ресурсы.
  6. Утрата видимости для поисковых систем. Поисковые системы могут оказаться не в состоянии проиндексировать содержимое приложения RIA.
  7. Зависимость от подключения к Интернету. Идеальная замена для настольных приложений должна позволять пользователям подключаться к сети «эпизодически», покидая хот-стопы, уходя и приходя в офис. Однако к 2007 году типичные приложения RIA требовали постоянного подключения.
  8. Доступность. Известно множество проблем веб-совместимости с RIA. Одна из распространённых заключается в том, что пользователю, читающему текст с экрана, сложно выявлять динамические изменения (вызванные JavaScript) в контенте HTML.
  9. Сложность расширяемости. RIA сложно расширять плагинами и модами, как это делается в традиционных приложениях. Возможно использование пользовательских JavaScript, внедряемым iFrame контентом, и т д.

Среди массы RIA платформ был выбран фреймворк Vaadin, который в отличие от библиотек на Javascript и специфических плагинов для браузеров предлагает сервер-ориентированную архитектуру, базирующуюся на Java Enterprise Edition. Использование JEE позволяет выполнять основную часть логики приложения на стороне сервера, тогда как технология AJAX, используемая на стороне браузера, позволяет интерактивно взаимодействовать с пользователем. Для отображения элементов пользовательского интерфейса и взаимодействия с сервером на стороне клиента Vaadin использует Google Web Toolkit [6].

На безе интеграции фреймворков Spring MVC и Vaadin была составлена общая структура web-приложения, представленная на рис. 3.

Общая структура web-приложения

Рисунок 3 – Общая структура web-приложения

8 Разработка уровня постоянства

8.1 Проблемы программирования баз данных и способы борьбы с ними

Уровень постоянства предоставляет данные и методы работы с этими данными. Этот уровень должен реагировать на запросы и изменять свое состояние. Не должен содержать информации о том, как эти данные нужные визуализировать. Важно отметить, что как представление, так и контроллер зависят от модели. Однако модель не зависит ни от представления, ни от контроллера. Тем самым достигается назначение такого разделения: оно позволяет строить модель независимо от визуального представления, а также создавать несколько различных представлений для одной модели.

В качестве уровня постоянства будет использована реляционная база данных. Но использование реляционной базы данных для хранения объектно-ориентированных данных приводит к семантическому провалу, заставляя программистов писать программное обеспечение, которое должно уметь как обрабатывать данные в объектно-ориентированном виде, так и уметь сохранить эти данные в реляционной форме. Эта постоянная необходимость в преобразовании между двумя разными формами данных не только сильно снижает производительность, но и создает трудности для программистов, так как обе формы данных накладывают ограничения друг на друга [7]. Разработано множество пакетов, устраняющих необходимость в преобразовании объектов для хранения в реляционных базах данных. Некоторые пакеты решают эту проблему, предоставляя библиотеки классов, способных выполнять такие преобразования автоматически. Имея список таблиц в базе данных и объектов в программе, они автоматически преобразуют запросы из одного вида в другой. В результате запроса объекта «человек» (из примера с адресной книгой) необходимый SQL-запрос будет сформирован и выполнен, а результаты особым образом преобразованы в объекты «номер телефона» внутри программы. С точки зрения программиста система должна выглядеть как постоянное хранилище объектов. Он может просто создавать объекты и работать с ними как обычно, а они автоматически будут сохраняться в реляционной базе данных. Такой подход называется ORM (Object-relational mapping,) – объектно-реляционное отображение.

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

С точки зрения программиста система должна выглядеть как постоянное хранилище объектов. Он может просто создавать объекты и работать с ними как обычно, а они автоматически будут сохраняться в реляционной базе данных. На практике всё не так просто и очевидно. Все системы ORM обычно проявляют себя в том или ином виде, уменьшая в некотором роде возможность игнорирования базы данных. Более того, слой транзакций может быть медленным и неэффективным (особенно в терминах сгенерированного SQL). Все это может привести к тому, что программы будут работать медленнее и использовать больше памяти, чем программы, написанные «вручную».

Но ORM избавляет программиста от написания большого количества кода, часто однообразного и подверженного ошибкам, тем самым значительно повышая скорость разработки. Кроме того, большинство современных реализаций ORM позволяют программисту при необходимости самому жёстко задать код SQL-запросов, который будет использоваться при тех или иных действиях (сохранение в базу данных, загрузка, поиск и т. д.) с постоянным объектом.

8.2 Hibernate как реализация уровня постоянства

В качестве ORM библиотеки была выбрана библиотека Hibernate, которая предоставляет легкий в использовании каркас (фреймворк) для отображения объектно-ориентированной модели данных в традиционные реляционные базы данных [8].

Hibernate не только решает задачу связи классов Java с таблицами базы данных (и типов данных Java с типами данных SQL) но также предоставляет средства для автоматической генерации и обновления набора таблиц, построения запросов и обработки полученных данных и может значительно уменьшить время разработки, которое обычно тратится на ручное написание SQL – и JDBC-кода. Hibernate автоматизирует генерацию SQL-запросов и освобождает разработчика от ручной обработки результирующего набора данных и преобразования объектов, максимально облегчая перенос (портирование) приложения на любые базы данных SQL.

Hibernate обеспечивает прозрачную поддержку сохранности данных (persistence) для «POJO» (то есть для стандартных Java-объектов); единственное строгое требование для сохраняемого класса — наличие конструктора по умолчанию (без параметров). Может использоваться как в самостоятельных приложениях Java, так и в программах Java EE, выполняемых на сервере (например, сервлет или компоненты EJB). Также он может включаться как дополнительная возможность к другим языкам программирования.

Коллекции объектов данных, как правило, хранятся в виде коллекций Java-объектов, таких как набор (Set) и список (List). Поддерживаются обощенные классы (Generics), введены в Java 5. Hibernate может быть настроен на «ленивые» (отложенные) загрузки коллекций. Отложенные загрузки является вариантом по умолчанию, начиная с Hibernate 3. Связанные объекты могут быть настроены на каскадные операции. Например, родительский класс, Album (музыкальный альбом), может быть настроен на каскадное сохранение и/или удаление своего отпрыска Track. Это может сократить время разработки и обеспечить целостность. Функция проверки изменения данных (dirty checking) позволяет избежать ненужной записи действий в базу данных, выполняя SQL обновление только при изменении полей персистентных объектов.

На безе интеграции фреймворка Spring MVC и библиотеки Hibernate была разработана усовершенствованная структура web-приложения. Структура программного модуля постоянства представлена на рис. 4.

Структура программного модуля постоянства

Рисунок 4 – Структура программного модуля постоянства

9 Сервис проектирования цифровых устройств

Для проектирования цифровых устройств будет разработан программный модуль (сервис), который будет реализовывать оптимальный алгоритм вычислений на суперкомпьютере. В качестве суперкомпьютера будет использоваться кластер NeClus кафедры компьютерной инженерии ДонНТУ. Для удаленного подключения к кластеру необходимо использовать SSH протокол. Для этого будет использована библиотека JSCH.

Разрабатываемый модуль по описанию алгоритма управления создает VHDL-модель управляющего устройства, интерпретирующий данный алгоритм. Пользователь описывает алгоритм управления, для которого должна быть синтезирована схема управляющего устройства. Для описания алгоритма управления будет использоваться язык XML или графический редактор блок-схем. Модуль содержит некоторую информацию о создаваемой ГСА: количество ОЛЦ, логических условий, наборов микроопераций, долю операторных вершин.

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

Процесс синтеза логической схемы устройства будет выполнятся в САПР Xilinx ISE WebPack входными данными для которой являются файлы VHDL-модели КМУУ, а также параметры микросхемы (семейство, тип, корпус и др.), которая будет использована для реализации схемы. Результатом синтеза логической схемы КМУУ в базисе современных микросхем типа FPGA при помощи САПР Xilinx будет являться файл отче та синтеза, который содержит информацию о количестве необходимых ресурсов микросхемы и временных параметрах синтезированной схемы УУ. Информация о количестве доступных ресурсов микросхемы позволяет сделать вывод о возможности реализации схемы в данном элементном базисе, а сравнение временных параметров с требованиями к минимально необходимому быстродействию устройства еще и о целесообразности такой реализации.

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

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

Рисунок 5 – Структура модуля проектирования цифровых устройств

Вывод

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

Таким образом, для реализации данного приложения необходимо иметь один сервер для развертывания Spring-MVC приложения с выделенным реальным IP и отдельный аккаунт для SSH доступа к кластеру NeClus. Базу данных можно разместить на том-же сервере вместе с web-приложением, чем сократив аппаратурные затраты.

При написании данного реферата магистерская работа еще не завершена. Окончательное завершение: декабрь 2014 года. Полный текст работы и материалы по теме могут быть получены у автора или его руководителя после указанной даты.

Список источников

  1. Методы синтеза композиционных микропрограммных устройств управления с модификацией системы адресации микрокоманд. : дис. на соискание науч. степени канд. техн. наук : спец. 05.13.05 "Компьютерные системы и компоненты" / Мирошкин А.Н. ; ДонНТУ. –Донецк – 2013 г. – 152 с.
  2. Java ЕЕ 6 и сервер приложений GlassFish 3. Дэвид Хеффельфингер - М.: ДМК Пресс, 2013. - 416 с.: ил.
  3. Разработка приложений Java ЕЕ 6 в NetBeans 7. Дэвид Хеффельфингер - М.: ДМК Пресс, 2013. - 330 с.: ил.
  4. Spring в действии. Уоллс К. – М.: ДМК Пресс, 2013. – 752 с.: ил.
  5. Spring 3 для профессионалов. Роб Харроп, Кларенс Хо. – М.: Вильямс, 2012. – 880с.:ил.
  6. Vaadin. Материал из Википедии – свободной энциклопедии. Электронный ресурс. Режим доступа: http://ru.wikipedia.org/wiki/Vaadin
  7. ORM. Материал из Википедии – свободной энциклопедии. Электронный ресурс. Режим доступа: http://ru.wikipedia.org/wiki/ORM
  8. Hibernate. Материал из Википедии – свободной энциклопедии. Электронный ресурс. Режим доступа: http://ru.wikipedia.org/wiki/Hibernate
  9. Приемы объектно-ориентированного проектирования. Паттерны проектирования. Гамма Э., Хелм Р., Джонсон Р., Влиссидес Дж. - СПб: Питер, 2001. — 368 с.: ил.
  10. Pro Spring MVC (The Expert`s Voice in Spring). – M. Deinum, K. Serneels, C. Yates – M.: Apress,2012. – 590c.:ил.