Системы управления контентом

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

Содержание

1. Назначение, функциональные возможности, состав и структурная схема системы

2. Алгоритм опроса датчика температуры процессора

3. Блок сопряжения с ЭВМ

4. Расчет интенсивности отказа

5. Расчет оценки средней наработки на отказ (Т₀)

6. Расчет оценки среднего времени восстановления

7. Расчет оценки среднего времени реакции на получение входного сигнала

8. Расчет значения коэффициента готовности ССОИ

9. Расчет оценки вероятности надежного преобразования входной информации

10. Определение значения доверительной вероятности а для интервала оценивания

11. Расчет доверительных границ заданных показателей надежности

Вывод

Список литературы

1. Назначение, функциональные возможности, состав и структурная схема системы

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

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

Рис. 1. Схема функционирования CMS

Функции систем управления контентом структурированы согласно жизненному циклу системы.

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

Создание контента

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

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

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

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

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

Создание шаблонов оформления

В качестве решения проблемы представления в системах управления контентом используется технология шаблонов, определяющих внешний вид страницы. Разработчику шаблонов не нужно знать никаких технических тонкостей. На ранних этапах существования WWW шаблоны представляли "заготовки" HTML-кода, из которого путем манипуляций в HTML-редакторе получались готовые страницы. Сегодня такими заготовками манипулируют уже не дизайнеры в своих редакторах, а серверные web-приложения. Таким образом, современный шаблон Web-страницы представляет собой блок HTML, который благодаря специальным тегам или внедренным сценариям, облегчает включение динамически сгенерированного содержания на этапе выполнения. При использовании подобных шаблонов программистам необходим некоторый стандартизированный интерфейс для работы с ними - шаблонный движок (в английском языке существует устоявшийся термин - template engine), который может иметь разнообразные дополнител ьные функции, например, поддерживать кэширование шаблонов, их динамическое обновление и т.д.

Публикация контента

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

Типичный процесс публикации информации в World Wide Web реализован в Microsoft Content Management Server. Обычным приемом обеспечения оформления информационного наполнения являются шаблоны представления информации. Поэтому первым этапом процесса является создание наборов шаблонов. Типичный шаблон содержит разметку HTML и места, куда в дальнейшем будут вставлены данные (placeholder'ы в терминологии Microsoft). Далее на основе этих шаблонов авторы информационного наполнения создают страницы и представляют их редакторам для одобрения. Редакторы, в свою очередь, могут либо отклонить страницу и вернуть ее автору на доработку, либо одобрить ее и передать модератору сайта. В первом случае процесс повторяется снова, во втором же модератор сайта проверяет расположение страницы на сайте, дату и срок ее публикации. Если все в порядке, страница становится видна пользователям. Несмотря на то, что рабочий процесс в Microsoft Content Management Server фиксирован и не может быть изменен в дальнейшем, подобное решени е подходит большинству пользователей, которым необходимо публиковать информацию в World Wide Web.

Управление пользователями

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

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

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

Архитектура системы управления контентом на примере DotNetNuke

В самом общем виде архитектуру систем управления Web-контентом можно представить следующим образом (7.2).

Рис. 2. Архитектура CMS

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

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

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

Рассмотрим пример реализации архитектуры системы управления контентом на примере CMS DotNetNuke 4

Рис. 3. Архитектура CMS на примере DNN

Ядро системы управления контентом представляет собой динамический сайт, созданный на языке Visual Basic.NET с использованием технологи и ASP.NET 2.0. Поэтому для ее функционирования требуется web-сервер с поддержкой этой технологии. В качестве такого сервера может выступать Microsoft Internet Information Services 5 или 6. В качестве хранилища данных CMS DotNetNuke 4 может использовать файловую систему web-сервера и базу данных под управлением СУБД Microsoft SQL Server. Поддерживаются все варианты поставки этой СУБД и версии 2000/2005. СУБД может функционировать как в операционной системе web-сервера, так и на удаленном компьютере. В первом случае возможно использование бесплатных версий MS SQL Server - Microsoft Desktop Engine и Microsoft SQL Server Express 2005.

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

Рис. 4. Структурная схема сервера

Технические характеристики элементов сервера.

Материнская плата

Gigabyte GA-MA790X-DS4

(AMD 790X, PCIe, PCI, 4x DDR2533/667/800, SLI/CrossFire)

Время наработки на отказ T_мп=150000 ч.

Жесткий диск

Seagate Barracuda ST3500320AS 500 Гб (SATA II, 7200 об./мин, 16МБ)

Время наработки на отказ T_жд=1500000 ч.

Центральный процессор

AMD Athlon 64 X2 6000+ BOX

(ядро Windsor, Частота 3000 МГц. Socket AM2, кеш L2 2048 Кб)

Время наработки на отказ T_цп=1500000 ч.

Сетевая карта

Производитель Intel

Модель PRO/1000 PT EXPI9400PT

Чип Intel 82572EI

PCI Express 1x

Скорость передачи данных 10/100/1000 Мбит/сек

Разъемы 1 порт RJ-45

Интерфейс PCI Express 1.0a

Поддержка Wake-On-LAN Есть

Потребление энергии 4.95 Вт

Поддержка ОС Windows 2000 Server, Windows 2003 Server (32-bit и 64-bit), Red Hat Linux 2.4x и выше (32-bit и 64-bit), FreeBSD 4.x и выше, Novell Netware 5.x, 6.x, Sun Solaris x86, OS 8 и выше, SCO Open Server 5, OpenUNIX 8

Размеры внешние 129.5 x 120 мм

Рабочая температура 0 ~ 55°C

Время наработки на отказ T_ск=60000 ч.

Блок питания

Производитель BFG

Модель MX-680-680W

Мощность блока питания 680W

Отсоединяющиеся кабели питания Да

Разъемы для подключения HDD/FDD/SATA 7 / 2 / 8

Разъемы питания VGA 6/8 pin 3 / 2

Разъемы питания мат.платы 20+4-pin ATX, 4+4pin ATX12V

Охлаждение блока питания 120mm + 80mm

Время наработки на отказ T_БП=100000 ч.

Датчик температуры процессора

Модель TMP37

Питание +(2.7-5.5) В.



Рис. 4. Схема измерителей датчика температуры процессора

контент информация алгоритм процессор

На рисунке 4 приведена схема измерителей с выходом на магнитоэлектрическую головку чувствительностью 50 микроампер с внутренним сопротивлением 2 кОм и цифровой вольтметр, установленный на предел 200 милливольт. Время наработки на отказ T_д=75000 ч.

При превышении температуры процессора допустимых значений система автоматически выключается.

2. Алгоритм опроса датчика температуры процессора

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

Рис. 5. Алгоритм опроса датчика температуры процессора

При включении системы, сначала происходит ввод необходимых для работы датчика данных, затем устройством замеряется текущая температура процессора системы, после чего значение сравнивается с максимально допустимым значением температуры работы процессора (в данном случае ~120°C). В случае, если текущая температура не превышает максимально допустимой, происходит вывод текущего значения температуры на ЖК дисплей датчика, и процесс повторяется. В противном случае, происходит принудительное выключение системы.

3. Блок сопряжения с ЭВМ

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

К компьтеру- серверу посредством многожильного компонентного видео кабеля подключен монитор.

Характеристики кабеля.

· Производитель Supra

· Модель VGA -VGA

· Производство Швеция

· Межблочный

· Длина 1м

· Тип разъема VGA

· Внешняя изоляция хлорированный ПВХ

· Внутренняя изоляция хлорный ПВХ со стабил. ионами

· Внутренний экран оплетка 120х0,10 OFC Sn>95%

· Материал изолятора пена РЕ

· Материал проводника лужоная бескислородная медь

· Сечение 0.20 мм2

· Внешний диаметр 11 мм Цвет:голубой лед

Архитектура видеоадаптера VGA

VGA состоит из следующих основных подсистем:

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

Видеопамять (Display Memory), в которой размещаются данные, отображаемые на экране монитора. 256 кБ DRAM разделены на четыре цветовых слоя по 64 кБ.

Последовательный преобразователь (Serializer или Sequencer) -- преобразует данные из видеопамяти в поток битов, передаваемый контроллеру атрибутов[3].

Контроллер атрибутов (Attribute Controller) -- с помощью палитры преобразует входные данные в цветовые значения.

Синхронизатор (Sequencer) -- управляет временнымми параметрами видеоадаптера и переключением цветовых слоёв.

Контроллер ЭЛТ (CRT Controller) -- генерирует сигналы синхронизации для ЭЛТ[4][5].

В компьютере PS/2 видеоадаптер VGA интегрирован в материнскую плату. PS/2

Данный разъем используется для подключения компьютерных мышей, клавиатур, питания некоторых устройств. Распиновка разъема PS/2 показана на рисунке.

Рис. 6. Распиновка разъема PS/2

Номер вывода Назначение

2 RxD

3 GND

4 +5В

6 TxD

USB 2.0

USB (англ. Universal Serial Bus -- универсальная последовательная шина) -- последовательный интерфейс передачи данных для среднескоростных и низкоскоростных периферийных устройств.



Рис. 10. Размещение проводников

Сигналы USB передаются по двум проводам четырёхпроводного кабеля.

Таблица 1

Номер контакта	Обозначение	Цвет провода
1	V BUS	красный
2	D?	белый
3	D+	зелёный
4	GND	чёрный

Здесь GND -- цепь «корпуса» для питания периферийных устройств, VBus -- +5 В, так же для цепей питания. Данные передаются по проводам D+ и D? дифференциально (состояния 0 и 1 (в терминологии официальной документации diff0 и diff1 соответственно) определяются по разности потенциалов межу линиями более 0,2 В и при условии, что на одной из линий (D? в случае diff0 и D+ при diff1) потенциал относительно GND выше 2,8 В.[3] Дифференциальный способ передачи является основным, но не единственным (например, при инициализации устройство сообщает хосту о режиме, поддерживаемом устройством (Full-Speed или Low-Speed), подтягиванием одной из линий данных к V_BUS через резистор 1.5 кОм (D? для режима Low-Speed и D+ для режима Full-Speed, устройства, работающие в режиме Hi-Speed, ведут себя на этой стадии как устройства в режиме Full-Speed). Так же иногда вокруг провода присутствует волокнистая обмотка для защиты от физических повреждений.[4].

Протокол IEEE 802.11b

IEEE 802.11 -- набор стандартов связи, для коммуникации в беспроводной локальной сетевой зоне частотных диапазонов 2.4, 3.6 и 5 Ггц. В настоящее время IEEE 802.11b -- самый распространённый стандарт, на базе которого построено большинство беспроводных локальных сетей. Он обеспечивает скорость передачи данных 11 Мбит/с

Канал Частота (GHz)

1 2,412

2 2,417

3 2,422

4 2,427

5 2,432

6 2,437

7 2,442

8 2,447

9 2,452

10 2,457

11 2,462

12 2,467

13 2,472

14 2,484

4. Расчет интенсивности отказа

Рассчитаем интенсивность отказа каждого элемента.

,

где Т - время наработки на отказ.

Рассчитаем суммарную интенсивность отказа.

ч^-1

- вероятность безотказной работы системы

Из графика определяем, что АСУ интернет ресурсом, будет безотказно работать при P(t)=0.999 в течении 16 часов.

Практическое освоение методики оптимизации логических схем и оценки их надежности.

В качестве исходных данных возьмем следующие данные из таблицы 1

Таблица 1.

Номера прерываний и восстановлений работоспособности АИС
Нач. раб. (00ч.00м.00с.) Конец работы (00ч.00м.00с.)	1	2	3	4	5	6	7
tН1	09.00.00	09.28.56	10.15.34	11.02.11	12.59.10	13.59.12	15.41.00
tК1	09.00.15	10.06.23	10.46.46	12.45.46	13.43.13	15.34.32	17.00.00

5. Расчет оценки средней наработки на отказ (Т0)

Производится расчет суммарного (общего) времени пребывания системы в работоспособном состоянии по формуле:

где N = 7 - суммарное за период испытаний количество прерываний работоспособного функционирования;

t_Нl- момент времени фактического начала работы после наступления (l-1 )-го прерывания, берется из таблицы 1;

t_Kl - момент времени фактического окончания работы при наступлении 1-го прерывания, берется из таблицы 1.

Теперь можно рассчитать среднюю наработку на отказ по формуле

T_oi=3939

где T_pi = 23632 - суммарное (общее) время пребывания АИС в работоспособном состоянии;

k = N-1=6 - суммарное число отказов АИС.

6. Расчет оценки среднего времени восстановления

Рассчитаем среднее время восстановления в работоспособное состояние после отказа(данные из табл.1):

где

k=N-1 =6

j=0..k-1

тогда среднее время восстановления будет равно

T_Bi=861.33

где k = 6 - число отказов, после которых происходило восстановление во время испытаний ;

t_Bi - время восстановления после j-го отказа.

7. Расчет оценки среднего времени реакции на получение входного сигнала

Данные берутся из таблицы 2.

Таблица 2

№ i-го запр.	Обозначение показателя	Номер s-го замера времени обработки i-го запроса Время обработки
21	s	1	2	3	4	5
	ts(00мин.00сек)	03.34	03.35	03.34	03.35	03.35

Расчет производим по следующей формуле:

T_реакj=214.6 c.

где m = 5 - количество замеров времени обработки запросов i-го типа;

t_is - время обработки входной информации.

8. Расчет значения коэффициента готовности ССОИ

Расчет значения коэффициента готовности производится по формуле. (Исходные данные из пунктов 3.1 и 3.2 .)

9. Расчет оценки вероятности надежного преобразования входной информации

Расчет вероятности производится по следующей формуле:

Pнад=0,778

где T_oi=3939 и T_Bj=861.33 - среднее время наработки на отказ и восстановления после отказа; T_peaк.i = 214.6 - среднее время реакции.

10. Определение значения доверительной вероятности а для интервала оценивания

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

Из представленных исходных данных выбираем доверительную вероятность ?. Для увеличения точности расчётов ? принимаем равным 0.999 (выбор производится по табл. 3).

Таблица 3

Значения коэффициента r1	Значения коэффициента r3
k \ a	0.990	k \ a	0.999
6	3.36	6	0.36

11. Расчет доверительных границ заданных показателей надежности

Расчет нижней (To_iH) и верхней (To_iB) доверительных границ для показателя наработки на отказ производится по формулам:

где коэффициенты r₁( k, a ) = 3.36 и r₃( k, a ) = 0,36 берутся из табл. 3.;

=3939 - рассчитанная оценка.

Расчет нижней (TBiH) и верхней (TBiB) доверительных границ для показателя времени восстановления работоспособности АИС. Расчет будет следующим:

где коэффициенты r₁( k, a ) = 3.36 и r₃( k, a ) = 0,36 берутся из табл. 3.;

T_Bj=861.33- рассчитанная оценка.

Расчет нижней (K_riH) и верхней (K_riB) доверительных границ для показателя коэффициент готовности АИС производится по формулам:



где и и

Расчет нижней (P_надIH) и верхней (P_надIB) доверительных границ вероятности надежного представления запрашиваемой выходной информации производится по формулам:

Среднее время наработки на отказ	Среднее время восстановления работоспособности после отказа	Коэффициент готовности	Вероятность надежного преобразования запрашиваемой выходной информации
ToiH		ToiB	TBiH	TBi	TBiB	KriH	Kri	KriB	PнадIH	PнадI	PнадIB
1418	3939	9295	310.08	861.33	2033	0,411	0,821	0,968	0,357	0,778	0,0.946

Вывод

Анализ графика показывает, что АСУ интернет ресурсом, будет безотказно работать при P(t)=0.999 в течении 16 часов. Для повышения надежности работы системы необходимо внести изменения в аппаратную часть.

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

За время работы системы 8:00:00 вероятность надежной работы входной информации составляет 0,778, а вероятность надежной работы запрашиваемой выходной информации составляет 0,946, следовательно, система работает без сбоя, то есть надежно.

Список использованной литературы

1. http://www.intuit.ru

2. Садчикова Г.М., Расчет надежности систем автоматического сбора и обработки информации на базе ЭВМ, Саратов, 2002.

Размещено на Allbest.ru