WWW.DISSERS.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА

   Добро пожаловать!


Pages:     | 1 |   ...   | 3 | 4 || 6 | 7 |   ...   | 15 |

Этапы создания сайта с помощью CMS и их проблемы 1. Проектирование прототипа сайта. Определяется, какая информация и в какой форме будет представлена на сайте. Создается проект дизайна сайта. Этот процесс делится на следующие этапы.

— Формирование технического задания.

— Определение структуры меню и разделов сайта.

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

— Формирование списка шаблонов страниц с указанием динамических блоков, расположенных на них.

К сожалению, CMS-системы не предоставляют автоматизированных средств, для проектирования макета сайта.

2. Установка и настройка необходимых динамических блоков.

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

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

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

— Неотделимость созданного сайта от CMS-системы. Вариантом решения этой проблемы является создание системы конструирования сайтов, которая позволит созданному сайту Сборник трудов молодых ученых и сотрудников кафедры ВТ ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ работать отдельно от CMS. Такая система фактически будет генерировать код динамического сайта.

3. Задание параметров сайта (логотип, название, электронный адрес администратора и т.д.).

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

Явным недостатком CMS-систем является конечное, заданное разработчиками CMS, число параметров сайта. Разработчик сайта не может создавать свои собственные параметры и в дальнейшем с ними работать.

4. Наполнение сайта информацией и последующая его отладка.

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

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

ЛИТЕРАТУРА 1. Базаров Р. Содержательная часть // CIO. 2004. № 10.

2. Robertson J. So,what is a content management system // KMC. 2003. june.

3. Макаров C. Что такое ECM // CIO. 2003. № 4.

Сборник трудов молодых ученых и сотрудников кафедры ВТ 28 ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ УДК 681.3.ИСПОЛЬЗОВАНИЕ ORACLE APEX ДЛЯ СОЗДАНИЯ КОРПОРАТИВНЫХ ИНТЕРНЕТ-ПРИЛОЖЕНИЙ В. В. Кириллов, А. А. Лаптева Обоснован выбор Oracle APEX как средства разработки и инфраструктуры для создания и выполнения web-приложений, основанных на базе данных Oracle. Разработано демонстрационное приложение, которое используется как пример в создаваемом учебном пособии по работе с Application Express. Рассматривается возможность организации практического курса по изучению среды студентами. По результатам исследований удалось сделать вывод, что данный продукт представляет собой одновременно полномасштабную среду разработки, внедрения и администрирования приложений и рабочих пространств.

Ключевые слова: APEX, Oracle Многие организации теряют ценное время, применяя для управления информацией электронные таблицы и персональные базы данных. Несмотря на простоту пользования, эти продукты плохо взаимодействуют с Веб и не допускают масштабирования, так что несколько пользователей не могут согласованно редактировать данные.

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

— объединение всей существующей корпоративной информации в единой системе webдоступа;

— предоставление актуальной информации в режиме реального времени;

— генерация отчетности в табличной и графической форме;

— импорт—экспорт данных в форматах PDF и CSV;

— поддержка технологического взаимодействия сотрудников, создание и ведение форумов, чатов, конференций;

— обеспечение механизма единой авторизации пользователей портала;

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

Oracle Application Express состоит из репозитория метаданных, где хранятся определения приложений, и механизм отображения и обработки страниц [1]. К нему обращаются через Web-браузер посредством встроенного в СУБД Oracle Web-сервера Embedded PL/SQL Gateway. Application Express полностью содержится в базе данных и представляет собой ядро Application Express и хранилище метаданных. Принцип работы Oracle Application Express.

— Данные о приложении (метаданные) хранятся в базе данных в виде таблиц, — Ядро Application Express преобразует метаданные и в режиме реального времени формирует визуальное представление (интерфейс, изображение) приложения.

Уникальный метод управления состоянием сеансов сводит к минимуму потребление ресурсов процессора. Состоянием сеанса управляет база данных. Каждый просмотр страницы приводит к созданию нового сеанса базы данных, поэтому когда механизм Oracle Application Express не обрабатывает и не отображает страницу, ресурсы обработки базы данных не используются [2].

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

Сборник трудов молодых ученых и сотрудников кафедры ВТ ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ ни разработчику, ни конечному пользователю не требуется устанавливать на настольном компьютере программное обеспечение.

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

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

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

— Developers (разработчики) — это пользователи, которые создают и изменяют приложения.

— End users (конечные пользователи) — это пользователи, которые имеют доступ к приложениям без использования внешних идентификационных схем.

Application Express содержит три главных средства разработки.

— Application Builder — создание динамических веб-приложений на основе баз данных.

— SQL Workshop — просмотр объектов баз данных, выполнение нерегламентированных запросов SQL, а также графический конструктор запросов.

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

В процессе исследования продукта разработано приложение на основе базы данных ПАНСИОНАТ, в котором реализовано большинство стандартных функций [3, 4]. Сейчас в приложение добавляются дополнительные возможности продукта, такие как генерация диаграмм, возможности полноценного расширения с помощью PL/SQL, Javascript, печать PDF и др. Рассматривается возможность организации практического курса по изучению данной среды разработки студентами. Приложение используется как пример в создаваемом учебном пособие по работе с Application Express. Выбор базы обусловливается тем, что при изучении студентами СПбГУ ИТМО курса «Проектирование приложений к базам данных» пособие по созданию приложений спомощью Oracle Forms основывалось именно на базе ПАНСИОНАТ и она знакома студентам.

Заключение Oracle Application Express свободная среда разработки программного обеспечения на основе СУБД Oracle. Позволяет очень быстро проходить весь процесс разработки вебприложения. С помощью APEX можно разрабатывать как небольшие приложения с дюжиной пользователей, так и масштабные приложения корпоративного уровня с тысячами пользователей. Предполагается использовать эту среду для расширения лекционного курса и лабораторного практикума по изучению студентами методов создания приложений к базам данных, а также для построения новой версии корпоративного портала СПбГУ ИТМО.

ЛИТЕРАТУРА 1. [Электронный ресурс]: .

2. [Электронный ресурс]: .

3. Кириллов В.В. Основы проектирования реляционных баз данных. СПб: ИТМО, 1994. 88 с.

4. Кириллов В.В., Громов Г.Ю. Введение в реляционные базы данных. СПб: BHV-Петербург, 2009. 464 с.

Сборник трудов молодых ученых и сотрудников кафедры ВТ КОМПЬЮТЕРНЫЕ СИСТЕМЫ УДК 004.СПОСОБЫ ФОРМАЛЬНОГО ОПИСАНИЯ АСИНХРОННЫХ СХЕМ А. А. Герасимов, П. В. Кустарев Рассмотрена проблема разработки асинхронных схем. Дан обзор существующих методов описания асинхронных схем, используемых при их создании, автоматическом синтезе и анализе. Рассматриваются модели вычислений, применяемые при проектировании как на высоких уровнях абстракции (взаимодействующие процессы, взаимодействующие модули), так и на уровне вентильной реализации (конечные автоматы, графы изменений сигналов), а также средства временного анализа (графы зависимостей).

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

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

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

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

Взаимодействие модулей асинхронных схем Несмотря на отсутствие общей синхронизации, в асинхронных схемах должна быть обеспечена локальная синхронизация выполнения операций и передачи данных между непосредственно связанными модулями. Данная задача решается посредством процедуры асинСборник трудов молодых ученых и сотрудников кафедры ВТ КОМПЬЮТЕРНЫЕ СИСТЕМЫ хронных коммуникаций. Наиболее распространенный вариант процедуры — обмен с подтверждениями (квитированием), описанный в [2].

Процедура асинхронных коммуникаций — неотъемлемая составляющая диаграмм взаимодействующих модулей [2, 3], которые являются основным способом высокоуровневого описания асинхронных схем. Эта модель позволяет наглядно представить асинхронную схему, разбивая ее на простые модули (регистры, мультиплексоры, арбитры и т.д.), между которыми передаются потоки данных, и тем самым справиться со сложностью восприятия децентрализованности и параллелизма. Сами модули описываются на уровне поведения, без детализации внутренней организации, а основное внимание уделяется их взаимодействию.

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

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

Диаграммы взаимодействующих модулей используются для структурного описания асинхронных схем, на уровне модулей и на RTL-уровне, при этом RTL-описания асинхронных схем по форме могут отличаться от RTL-описаний синхронных схем. Формальную модель взаимодействующих модулей разработал C.H. van Berkel [3], а возможность автоматического синтеза подобных описаний в схемы на КМОП-логике математически доказал A. Martin в [4].

Взаимодействующие процессы Формальный язык взаимодействующих последовательных процессов (communicating sequential processes) был разработан Чарльзом Хоаром. Этот язык ориентирован на описание параллелизма компонентов системы, допускает операции присваивания, последовательной и параллельной композиции, выбора и блокирующего ввода—вывода через порты. Реализации этого языка, ориентированные на синтез асинхронных схем, включают в себя CHP, Tangram и Balsa. Описания могут быть синтезированы в нечувствительную к задержкам на вентилях схему из взаимодействующих модулей, при этом каждому оператору сопоставляется один модуль (цикла, присваивания, модули последовательной и параллельной композиции, модуль условного исполнения и т.д.). Такой подход носит название компиляции, управляемой синтаксисом [2]. Альтернативный подход разработал A. Martin [4], используя промежуточную нотацию правил вывода, он описал процедуру синтеза описаний на CHP в КМОП-схемы.

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

Правила вывода Правило вывода представляет собой пару «условие—присваивание», где условие — булева функция от сигналов схемы, а присваивание определяет положительный или отрицательный перепад одного из сигналов, который инициируется, когда условие истинно. При этом подразумевается, что перепад осуществляется в течение некоторого времени, что соответствует поведению реальных логических и запоминающих элементов. Два дополняющих правила вывода (определяющих условия фронта и спада перепада одного и того же сигнала) задают поведение асинхронного вентиля (с памятью или без). Например, логический элемент «И» задают правила i1 i2 o ;i1 i2 o, элемент «ИЛИ» — правила i1 i2 o ;i1 i2 o, а C-элемент Сборник трудов молодых ученых и сотрудников кафедры ВТ 32 КОМПЬЮТЕРНЫЕ СИСТЕМЫ Маллера, изменяющий значения на своем выходе, только когда значения на входах совпадают – i1 i2 o ;i1 i2 o.

Pages:     | 1 |   ...   | 3 | 4 || 6 | 7 |   ...   | 15 |






















© 2011 www.dissers.ru - «Бесплатная электронная библиотека»

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