Web-браузеры

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

Содержание

Введение

Особенности web-приложений, необходимые компоненты web-ориентированных информационных систем

Описание предметной области, постановка задачи

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

Заключение

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



Введение

web архитектура информационный предметный

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



Особенности web-приложений, необходимые компоненты web-ориентированных информационных систем

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

Изначально World Wide Web (WWW) создавалась как «пространство для обмена информацией, в котором люди и компьютеры могут общаться между собой». Поэтому первые Web-приложения представляли собой примитивные файловые серверы, которые возвращали статические HTML-страницы запросившим их клиентам. Таким образом, Web начиналась как документно-ориентированная сеть.

Следующим этапом развития Web стало появление понятия приложений, которые базировались на таких интерфейсах, как CGI (или FastCGI), а в дальнейшем -- на ISAPI. Common Gateway Interface (CGI) -- это стандартный интерфейс с серверами, позволяющий выполнять серверные приложения, вызываемые через URL. Входной информацией для таких приложений служило содержимое HTT P-заголовка (и тело запроса при использовании протокола POST). CGI-приложения генерировали HTML-код, который возвращался браузеру. Основной проблемой CGI-приложений было то, что при каждом клиентском запросе сервер выполнял CGI-программу в реальном времени, загружая ее в отдельное адресное пространство.

Появление Internet Server API (ISAPI) позволило не только решить проблемы производительности, которые возникали с CGI-приложениями, но и предоставить в распоряжение разработчиков более богатый программный интерфейс. ISAPI DLL можно было ассоциировать с расширениями имен файлов через специальную мета-базу. Эти два механизма (CGI и ISAPI) послужили основой создания первого типа Web-приложений, в которых в зависимости от каких-либо клиентских действий выполнялся серверный код.

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

Интерфейс ISAPI -- это особенность Microsoft Internet Information Server. ISAPI-приложения представляют собой динамические загружаемые

библиотеки (DLL), которые выполняются в адресном пространстве Web-сервера. У других Web-серверов через некоторое время также появилась возможность выполнять приложения, реализованные в виде библиотек. В случае Web-серверов Netscape этот программный интерфейс назывался NSAPI (Netscape Server API). У довольно популярного Web-сервера Apache также имеется возможность выполнять Web-приложения, реализованные в виде библиотек; такие библиотеки называются Apache DSO (Dynamic Shared Objects).

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

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

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

Решение многих описанных выше задач, возникающих при создании современных Webприложений, теперь начинает возлагаться на Web-сервисы -- не зависящие от платформы, объектной модели и клиента программные компоненты, которые можно вызывать из клиентских Web-приложений (а также из самих Web-сервисов) через основанный на протоколе HTTP и языке XML протокол SOAP. Для описания Web-сервисов используется XML-подобный язык WSDL, а для организации реестров Web-сервисов, в которых разработчики и компании могут искать необходимые им сервисы, а также публиковать данные о своих сервисах, -- интерфейс UDDI.

Обзор возможных архитектур построения Web-приложений позволяет сделать вывод о реализации распределенных САПР на основе технологии ASP.NET, предложенной фирмой Microsoft в среде Visual Studio. Рассмотрим применение данной технологии при разработке Web-ориентированной САПР электронных схем.

Традиционная архитектура САПР (рис. 1) включает отдельные подсистемы, написанные на процедурных или объектно-ориентированных языках программирования, имеющих мощные средства для работы с различными структурами данных, таких как списки, очереди, стеки, деревья, графы и т. д. Обмен данными между подсистемами обеспечивается через общую область памяти, через систему двоичных файлов, посредством специализированных языков описания (текстовые файлы).



Рис. 1. Традиционная архитектура САПР

На настоящий момент актуальными являются разработка и адаптация специальных Internet-ориентированных версий настольных САПР, позволяющих обеспечить автоматизацию процесса проектирования объектов различной физической природы в масштабах предприятия.

Рассмотрим архитектуру Internet-версии подобной САПР на примере САПР электронных схем Design Lab корпорации MicroSim, получившую наибольшее распространение среди разработчиков радиоэлектронной аппаратуры.

Основу системы Design Lab составляет программа PSpice, которая является наиболее известной модификацией программы схемотехнического моделирования SPICE (Simulation Program with Integrated Circuit Emphasis), разработанной в начале 70-х гг. в Калифорнийском университете г. Беркли. Она оказалась очень удачной, интенсивно развивается и де-факто стала эталонной программой моделирования аналоговых устройств.

В состав САПР Design Lab входят следующие подсистемы:

Schematics -- интегрированная управляющая подсистема и графический редактор электронных схем;

PSpice -- проектирующая подсистема, выполняющая построение математической модели и численный анализ схемы;

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

StmEd -- редактор входных сигналов, позволяющий задавать произвольную форму возмущающих воздействий;

Parts -- подсистема расчета параметров моделей схемных компонентов.

Для передачи данных между подсистемами Schematics и PSpice используется текстовый файл с описанием схемы на входном языке системы.

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

Для адаптации работы системы Design Lab в сети Internet необходима разработка новой распределенной архитектуры САПР с разделением функций между клиентом и сервером, чтобы добиться оптимальной производительности в условиях низкоскоростных каналов Internet и лимитированных ресурсов Web-серверов. Так, предварительную обработку и ввод данных, отправляемых серверу, имеет смысл выполнять на стороне клиента. Это позволит исключить, например, повторные передачи неправильно составленных схем. Графическое представление результатов запроса также стоит выполнять на стороне клиента, что существенно сократит объем данных, передаваемых по сети. Моделирование схемы и доступ к библиотекам параметров схемных компонентов целесообразно обеспечить за счет ресурсов сервера. Отметим, что сеть Intranet -- отличная платформа для работы с информацией внутри предприятия. Современный Web-браузер доступен для любой клиентской системы.

Архитектура Web-ориентированной САПР электронных схем представлена на (рис. 2).

В настоящее время стали появляться Web-ориентированные САПР. Они представляют собой приложения, разделенные на 3 модуля - клиентский, обслуживающий и проектирующий. Клиентский модуль, выполняемый на компьютере пользователя, осуществляет формирование данных для их передачи на сервер. Обслуживающий модуль через Web-страницы запускает части клиентского модуля. Проектирующий модуль, выполняемый на сервере, производит обработку поступивших данных (см. рис. 2). Intranet ориентирован, как правило, на применение в рамках одного компактного или распределенного предприятия и отличается высокой безопасностью и скоростью работы. Используется для решения задач по автоматизации документооборота, информационному сопровождению бизнес-процессов, поиска и совместного доступа к данным и документам организации и имеет шлюзы для подключения в Internet.

Рис. 2. Архитектура Web-ориентированной САПР электронных схем



Описание предметной области, постановка задачи

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

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

Классы объектов

Передачи (Название, Рейтинг, Стоимость минуты).

Реклама (Передача, Заказчик, Дата, Длительность в минутах).

Заказчики (Название, Банковские реквизиты, Телефон, Контактное лицо).

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

Конструируем в программе Rational Rose Enterprise Edition диаграмму прецедентов.

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

1. Подготовка:

В навигаторе модели открываем Use Case View.

Там же открываем Main.

Даём имя диаграмме прецедентов.

В контекстном меню для Main выбраем команду Rename.

Вводим имя диаграммы прецедентов.

2. Создание субъекта:

Нажимаем кнопку создания субъекта.

В окне диаграммы прецедентов указываем место субъекта.

Щелчком вызываем изображение субъекта.

Вводим имя субъекта.

3. Создание аспекта:

Нажимаем кнопку создания аспекта.

Повторяем п.п. 2b, c, d для аспекта.

4. Создание ассоциации

Нажимаем кнопку создания ассоциации.

Рисуем стрелку от одного элемента диаграммы прецедентов к другому.

Регулируем размещение элементов диаграммы прецедентов.

В результате выполнения работы получается диорама прецедентов (рис. 3).

Рис. 3. Диаграмма прецедентов

Конструируем в той же программе, Rational Rose Enterprise Edition, диаграмму классов.

Технологический процесс создания диаграммы классов:

1. Подготовка:

В навигаторе модели открываем Logical View.

Там же открываем Main.

Даём имя диаграмме классов.

В контекстном меню для Main выбираем команду Rename.

Вводим имя диаграммы классов.

2. Создание класса:

Нажимаем кнопку создания класса.

В окне диаграммы классов указываем место класса.

Щелчком вызываем изображение класса.

Вводим имя класса:

Не повторяющееся с именами субъектов диаграммы прецедентов

Являющиеся субъектами, их необходимо привести в стандартный для класса вид командой Format/Stereotype Display.

3. Оформить класс:

В контекстном меню класса выбраем команду New Attribute

Вводим имя атрибута.

Активизировав класс, щелкаем по значку атрибута.

В списке выбираем требуемый значок атрибута:

public (default)

protected

private

implemented

В контекстном меню класса выбираем команду New Operation.

Вводим имя операции.

i) Повторяем п.п. 2e, f для операции.

4. Создание ассоциации:

Нажимаем кнопку создания ассоциации.

Рисуем стрелку от одного класса к другому.

Регулируем размещение классов в диаграмме.

5. Оформить ассоциацию:

В контекстном меню ассоциации выбираем команду Multiplicity.

В списке выбраем требуемый вид ассоциации

1 - обязательная однозначная;

0 .. * - Zero or More, необязательная многозначная;

1 .. * - One or More, обязательная многозначная;

0 .. 1 - Zero or One, необязательная однозначная;

В контекстном меню ассоциации выбираем команду Navigable, убрав "галочку".

В результате выполнения работы получается диорама классов (рис. 4).

Рис. 4. Диаграмма классов

Конструируем в той же программе, Rational Rose Enterprise Edition, кооперативную диаграмму.

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

1. Подготовка:

В меню выбираем команду Browse/Interaction Diagram/New для вызова окна Select Interaction Diagram.

В подокне Package окна Select Interaction Diagram выбираем Use Case View, нажать ОК.

В диалоговом окне New Interaction Diagram в поле Title вводим имя диаграммы последовательности.

В диалоговом окне New Interaction Diagram выбираем тип диаграммы sequence, нажать ОК.

2. Создание объекта:

Нажимаем кнопку создания объекта.

В окне диаграммы классов указываем место объекта.

Щелчком вызываем изображение объекта и соответствующей ему линии жизни.

Через контекстное меню открываем окно Object Specification и ввести имя объекта и соответствующий ему класс.

3. Создание сообщения:

Нажимаем кнопку создания сообщения Object Message.

Рисуем стрелку от линии одного объекта к линии жизни другого объекта

Регулируем размещение элементов диаграммы прецедентов.

4. Построение соответствующей диаграммы кооперации:

Нажимаем функциональную клавишу F5.

Изменяем сообщение, вызвав закладку Messages.

В результате выполнения работы получается кооперативная диорама(рис. 5).

Рис. 4. Кооперативная диаграмма

Заключение

В данной курсовой работе я изучил эволюцию архитектуры Web-решений, начиная от простейших хранилищ HTML-страниц и заканчивая современными корпоративными решениями, интегрированными с корпоративными информационными системами и информационными системами партнеров. Рассмотрел задачи, возникающие на каждом этапе развития Web-приложений и технологии, их решающие, включая CGI, ISAPI; взаимодействие с серверами приложений и с базами данных; создание и применение Web-сервисов, основанных на XML. Предложил архитектуру Web-ориетированной САПР на основе популярной САПР электронных схем Design Lab корпорации MicroSim. Так же в ходе выполнения практической части были разработаны: диаграмма прецедентов, диаграмма деятельности (кооперативная) и диаграмму классов.



Библиографический список

1. Berners-Lee T. WWW: Past, present, and future // Computer. Oct. 1996. Vol. 29. N 10. Р. 69-77.

2.http://supportline.microfocus.com/Documentation/books/nx30books/piisapcn.htm (дата обращения:

10.11.2009).

3. http://zone.ni.com/devzone/cda/epd/p/id/6363 (дата обращения: 02.12.2009).

4. Разевиг В. Д. Система схемотехнического моделирования и проектирования печатных плат Design Center (PSpice). -- М.: СК Пресс, 1996. -- 272 с.

5. Разевиг В. Д. Система схемотехнического моделирования Micro-CAP V. -- М.: СОЛОН, 1997. -- 273 с.

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

...