Методические указания для студентов очной формы обучения по выполнению практических заданий и внеаудиторной самостоятельной работы по МДК.02.01  Информационные технологии и платформы  разработки информационных систем Раздел 1 WEB-программирование

министерство образования и науки Российской Федерации

Старооскольский технологический институт им. А.А. УГАРОВА

(филиал) федерального государственного автономного образовательного учреждения

высшего образования

«Национальный исследовательский технологический университет «МИСиС»

ОСКОЛЬСКИЙ ПОЛИТЕХНИЧЕСКИЙ КОЛЛЕДЖ

УТВЕРЖДАЮ

ПРЕДСЕДАТЕЛЬ НМС опк

__________ _____________________

пРОТОКОЛ № 1

ОТ «01» сентября 2017 г.

МДК.02.01 Информационные технологии и платформы разработки информационных систем

Раздел 1 WEB-программирование

Методические указания для студентов очной формы обучения по выполнению практических заданий и внеаудиторной самостоятельной работы

Специальность 09.02.04 Информационные системы (по отраслям)

Старый Оскол 2017 г

Составитель:

О.А. Божкова – преподаватель ОПК СТИ НИТУ «МИСиС»

Рецензенты:

Внутренний

О.И. Назарова – преподаватель СТИ НИТУ «МИСиС» ОПК

Внешний

Д. В. Курашов – программист отдела АСУ МУП «РАЦ»

Введение 4

ПРАКТИЧЕСКАЯ РАБОТА 1. ОБЛАЧНЫЕ ТЕХНОЛОГИИ. РАБОТА С GOOGLE DOCS 5

ПРАКТИЧЕСКАЯ РАБОТА 2. 10

ОПРЕДЕЛЕНИЕ КОНЦЕПЦИИ САЙТА. СОСТАВЛЕНИЕ ТЕХНИЧЕСКОГО ЗАДАНИЯ НА РАЗРАБОТКУ САЙТА 10

ПРАКТИЧЕСКАЯ РАБОТА 3. 20

МОДЕЛИРОВАНИЕ ВЕБ - ПРИЛОЖЕНИЯ С ИСПОЛЬЗОВАНИЕМ ТЕХНОЛОГИЙ И ИНСТРУМЕНТАЛЬНЫХ СРЕДСТВ MICROSOFT 20

ПРАКТИЧЕСКАЯ РАБОТА 4. 30

ИСПОЛЬЗОВАНИЕ HTML ДЛЯ РЕШЕНИЯ ТИПОВЫХ ЗАДАЧ 30

ПРАКТИЧЕСКАЯ РАБОТА 5-6. 42

СПОСОБЫ СОЗДАНИЯ И РАЗМЕЩЕНИЯ ТИПОВЫХ САЙТОВ 42

ПРАКТИЧЕСКАЯ РАБОТА 7. 53

ЯЗЫК JAVASCRIPT. СИНТАКСИС. ОСНОВНЫЕ ОПЕРАТОРЫ. 53

ИНТЕГРАЦИЯ С HTML 53

ПРАКТИЧЕСКАЯ РАБОТА 8. 65

РАЗРАБОТКА WEB-ПРИЛОЖЕНИЯ ДЛЯ ВЗАИМОДЕЙСТВИЯ 65

КЛИЕНТСКОГО ПО С БАЗАМИ ДАННЫХ 65

Внеаудиторная самостоятельная работа 85

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

Методические указания к проведению практических работ составлены в соответствии с требованиями ФГОС СПО к минимуму содержания и уровню подготовки выпускника по специальности 09.02.04 Информационные системы (по отраслям).

Данные методические указания содержат 7 практических работ, направленных на закрепление полученных теоретических в ходе освоения МДК.02.01 «Информационные технологии и платформы разработки информационных систем» Раздел 1 «WEB-программирование».

Каждая практическая работа имеет четкую структуру:

• Наименование работы;

• Цель работы;

• Теоретическая часть;

• Практическая часть;

• Контрольные вопросы.

ЦЕЛЬ РАБОТЫ: изучить понятие «облачные технологии», изучить назначение и основные функциональные возможности Google Docs, зарегистрировать аккаунт Google, изучить возможности Google Docs: Writely (Document), Spreadsheets, Presentations.

Студент должен иметь практический опыт:

использования инструментальных средств обработки информации;

формирования отчетной документации по результатам работ;

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

Студент должен уметь:

осуществлять информационную постановку задач по обработке информации,

уметь решать прикладные вопросы интеллектуальных систем с использованием, статических экспертных систем, экспертных систем реального времени;

Студент должен знать:

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

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

ТЕОРЕТИЧЕСКАЯ ЧАСТЬ

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

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

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

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

Три модели «облаков»

Существует три модели обслуживания облачных вычислений:

Программное обеспечение как услуга (SaaS, Software as a Servise). Потребителю предоставляются программные средства — приложения провайдера, выполняемые на облачной инфраструктуре.

Платформа как услуга (PaaS, Platform as a Service). Потребителю предоставляются средства для развертывания на облачной инфраструктуре создаваемых потребителем или приобретаемых приложений, разрабатываемых с использованием поддерживаемых провайдером инструментов и языков программирования.

Инфраструктура как услуга (IaaS, Infrastructure as a Service). Потребителю предоставляются средства обработки данных, хранения, сетей и других базовых вычислительных ресурсов, на которых потребитель может развертывать и выполнять произвольное программное обеспечение, включая операционные системы и приложения.

Преимущества облачных сервисов

В прошлом году совокупный объем мирового рынка в сфере облачных технологий составил порядка $40 млрд. Некоторые эксперты прогнозируют, что к 2020 году этот показатель достигнет $240 млрд. Россия по внедрению cloud computing в бизнес занимает 34-е место с показателем $250 млн.

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

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

Мобильность. У пользователя нет постоянной привязанности к одному рабочему месту. Из любой точки мира менеджеры могут получать отчетность, а руководители — следить за производством.

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

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

Гибкость. Все необходимые ресурсы предоставляются провайдером автоматически.

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

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

Google Apps для бизнеса выделяет эти же преимущества, только добавляет, что при использовании их cloud computing компания защищает окружающую среду, объясняя это тем, что службы Apps работают на базе центров обработки данных Google, отличающихся сверхнизким энергопотреблением, поэтому углеродоемкость и энергозатраты при их использовании будут значительно ниже при использовании локальных серверов.

ПРАКТИЧЕСКАЯ ЧАСТЬ

1. Зарегистрируйте аккаунт Google.

Рис.1. Регистрация в Google

1. Создайте текстовый документ. Наберите текст (содержание на Ваше усмотрение, но без нарушения законодательства РФ), объем текста - 1 страница. Отредактируйте текст всеми способами представленными инструментами Google Документ. Загрузить документ Google на свой компьютер в виде файла Word, OpenOffice, RTF, PDF, HTML или ZIP. Перевести документ на другой язык. Прикрепить документ к сообщению электронной почты.

Рис.2. Google Документы

1. Создайте таблицу. Заполните ячейки (минимум заполнение таблицы 20*20 ячеек). Используйте формулы. Экспортировать таблицу в формате Excel, CSV, TXT, ODS, PDF или HTML. Вставить график и диаграмму.

Рис.3. Google Таблица

1. Создайте презентацию. Используйте необходимые инструменты Google Docs. Экспортировать презентацию в формате PDF, PPT или TXT. Обязательно добавить в презентацию изображения и видео.

Рис.3. Google Презентация

1. Создайте рисунок. Используйте инструменты: Выделение цветом форматирования. Подгонка холста по размерам экрана. Инструмент «Лупа». Инструмент «Выделение». Вставка линий. Вставка фигур. Вставка текстового поля. Вставка изображения. Вставка гиперссылки.

2. Создайте форму из любого шаблона, представленного в Google Docs.

КОНТРОЛЬНЫЕ ВОПРОСЫ:

1. Понятие «облачные технологии».

2. Преимущества облачных сервисов.

3. Опишите модели «облаков».

4. Основные функциональные характеристики Google Docs.

ЦЕЛЬ РАБОТЫ: изучить руководствующие стандарты при написании ТЗ, научиться писать ТЗ относительно требований реального заказчика.

Студент должен иметь практический опыт:

использования инструментальных средств обработки информации;

участия в разработке технического задания;

формирования отчетной документации по результатам работ;

Студент должен уметь:

осуществлять информационную постановку задач по обработке информации,

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

Студент должен знать:

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

платформы для создания, исполнения и управления информационной системой;

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

ТЕОРЕТИЧЕСКАЯ ЧАСТЬ

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

Техническое задание (также — техзадание, ТЗ) — технический документ (спецификация), оговаривающий набор требований к системе и утверждённый как заказчиком/пользователем, так и исполнителем/производителем системы. Такая спецификация может содержать также системные требования и требования к тестированию.

Техническое задание позволяет:

• исполнителю — понять суть задачи, показать заказчику «технический облик» будущего изделия, программного изделия или автоматизированной системы;

• заказчику — осознать, что именно ему нужно;

• обеим сторонам — представить готовый продукт;

• исполнителю — спланировать выполнение проекта и работать по намеченному плану;

• заказчику — требовать от исполнителя соответствия продукта всем условиям, оговорённым в ТЗ;

• исполнителю — отказаться от выполнения работ, не указанных в ТЗ;

• заказчику и исполнителю — выполнить попунктную проверку готового продукта (приёмочное тестирование — проведение испытаний);

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

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

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

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

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

Как правило, этапу составления технического задания предшествует проведение обследования предметной области, которое завершается созданием аналитического отчета. Именно аналитический отчет (или аналитическая записка) ложится в основу документа Техническое задание.

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

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

Руководствующими стандартами при написании технического задания являются ГОСТ 34.602.89 «Техническое задание на создание автоматизированной системы» и ГОСТ 19.201-78 «Техническое задание. Требования к содержанию и оформлению». Первый стандарт предназначен для разработчиков автоматизированных систем, второй для программных средств.

В таблице 1 предоставлен список и описание разделов, которые должно содержать техническое задание согласно ГОСТам.

Таблица 1.

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

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

• Общие сведения о системе (программе);

• Назначение, цели и задачи системы (программы);

• Требования к системе (функциональные требования, пользовательские требования, требования к системе в целом и тд);

• Требования к видам обеспечения;

• Требования к документированию;

• Стадии и этапы разработки;

• Порядок контроля и приемки системы (программы).

Общие сведения 

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

Пример:

«В данном документе создаваемая информационная система называется «Единое окно доступа к образовательным ресурсам», сокращенно ЕО. 
Систему Единое окно доступа к образовательным ресурсам далее в настоящем документе допускается именовать Единое окно или Система.»

Также сюда следует включить подразделы сообщающие реквизиты организаций участвующих в разработке (Заказчика и Исполнителя).

В подразделе «Основания для разработки» документа Техническое задание перечисляются основные документы, на основании которых выполняются данные работы. Например, для системы, выполняемой по заказу Правительства страны или другого Государственного органа, должны быть указаны законы, указы  и постановления Правительства.

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

Неотъемлемой частью документа Техническое задание также  должен быть список терминов и сокращений. Термины и сокращения лучше представить в виде таблицы с двумя столбцами «Термин» и «Полная форма».

Термины и сокращения располагаются в алфавитном порядке. В первую очередь принято давать расшифровку русскоязычным терминам и сокращениям, потом англоязычным.

Назначение и цели создания системы

Данный раздел документа Техническое задание должен содержать назначение и цели создания системы.

Пример:

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

Основной целью Системы является формирование единой информационной среды и автоматизации бизнес-процессов Образовательных учреждений Российской Федерации.

Создание информационной системы «Единое окно» должно обеспечить:

• предоставление пользователям широкого спектра информационных ресурсов;

• повышение уровня информационной безопасности;

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

• повышение эффективности процесса взаимодействия информационных систем и сервисов внутри ведомства.

Создание Системы позволит сократить эксплуатационные затраты в результате повышения эффективности работы ведомства.»

Требования к системе

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

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

Пример:

«4.1 Бизнес-процесс «Предоставление информации об образовательных учреждениях Российской Федерации

В данном бизнес-процессе выделяются следующие участники:

Модератор – работник ведомства, входящий в состав обслуживающего персонала Системы, ответственный за корректность предоставляемых данных

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

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

4.1.1 Регистрация образовательного учреждения в Системе 

Регистрация образовательного учреждения Российской Федерации осуществляется ответственным сотрудником учреждения («Постановление Правительства»).

Процесс регистрации образовательного учреждения включает следующие шаги:

• Автор создает запись об организации;

• Автор заносит данные организации;

• Система проверяет наличие лицензии для данной организации

• Если лицензия существует в базе данных, Система отправляет Автору сообщение об успешной регистрации;

• Если лицензия не найдена в базе данных, Система отправляет сообщение Автору об отсутствии лицензии для данной организации.»

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

Требования к системе в целом включают раскрытие ее архитектуры с описанием всех подсистем. В данной части Технического задания следует описать требования к интеграции системы с другими продуктами (если таковые имеются). Далее в техническое задание должны быть включены:

• требования к режимам функционирования системы

• показатели назначения

• требования к надежности

• требования к безопасности

• требования к численности и квалификации персонала и режиму его работы

• требования к защите информации

• требования по сохранности информации при авариях

• требования к патентной чистоте

• требования по стандартизации и унификации

• и т.д.

Требованиям к видам обеспечения

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

Требования к документированию 

Раздел «Требования к документированию» технического задания включает перечень проектных и эксплуатационных документов, которые должны быть предоставлены заказчику.

Данный раздел технического задания также важен, как и описание функциональных требований, поэтому не следует ограничиваться фразой «Заказчику должна быть предоставлена вся документация согласно ГОСТ 34». Это означает, что вы должны предоставить весь пакет документов включая «Формуляр», «Паспорт» и т.п. Большинство документов из списка, указанного в ГОСТ 34.201-89 не нужны ни вам, ни заказчику, поэтому лучше сразу согласовать список на этапе разработки документа Техническое задание. 

Минимальный пакет документов обычно включает:

• Техническое задание;

• Ведомость эскизного (технического) проекта;

• Пояснительная записка к Техническому проекту;

• Описание организации информационной базы;

• Руководство пользователя;

• Руководство администратора;

• Программа и методика испытаний;

• Протокол приемочных испытаний;

• Акт выполненных работ

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

Стадии и этапы разработки

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

Порядок контроля и приемки системы 

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

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

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

Зачастую ТЗ составляется в свободной форме и служит договором между заказчиком и исполнителем. Приводим пример ТЗ на разработку сайта в практической части.

ПРАКТИЧЕСКАЯ ЧАСТЬ

Создайте техническое задание на разработку сайта образовательно-профориентационного центра «Выставка «Железно!» согласно представленной ниже структуры. Центр работает по двум основным направлениям: образовательное и профориентационное. В рамках его работы проходят культурно-массовые, научные мероприятия, экскурсии, разрабатывается и выпускается сувенирная продукция, а также проходят лектории, лекции, практические занятия по различным направлениям. Центр является наглядным пособием для будущих представителей металлургических профессий. В зале «Красота» можно познакомиться с минералами, в зале «Сила» - с процессом добычи руды и обработки железа, в зале «Польза» - с металлургическими профессиями, в зале «Гараж» посетители могут вести разговоры на умные темы, смотреть кино. Кроме того, Центр предоставляет 3 кинозала своим посетителям. Центр выполнен в следующих цветах: желтый, черный, белый, оранжевый и красный. Сайт должен привлекать посетителей от 6 до 80 лет разных профессий и рода деятельности. Проект Центра выполнен благодаря поддержке компании «Металлоинвест».

Рис.4. Оформление исторических справок ОПЦ «Выставка «Железно!»

Структура технического задания разработки сайта

1. Термины, используемые в техническом задании.

2. Общие положения.

2.1. Название сайта.
2.2. Наименование предприятий (объединений) разработчика и заказчика (пользователя) сайта и их реквизиты.

2.3. Состав и содержание работ по созданию системы.

3. Назначение и цели создания сайта.
3.1. Цели создания сайта.

3.2. Задачи, решаемые при помощи сайта.

4. Требования к сайту и программному обеспечению.
4.1. Требования к программному обеспечению сайта.

4.2. Общие требования к оформлению и верстке страниц.

4.3. Требования к численности и квалификации персонала, обслуживающего сайт.

5. Структура сайта.

6. Языковые версии сайта.

7. Группы пользователей.

8. Дизайн сайта.

9. Навигация по сайту.

9.1. Основное навигационное меню.

9.2. Дополнительная навигация по сайту.

10. Описание страниц сайта.
10.1. Описание статических страниц.

10.2. Описание динамических страниц.

11. Функционал сайта.

12. Контент и наполнение сайта.

12.1. Формат предоставления материалов для сайта.

13. Дополнительная информация.

КОНТРОЛЬНЫЕ ВОПРОСЫ:

1. Что такое ТЗ?

2. Для чего оно создается?

3. Обозначьте руководствующие стандарты при написании ТЗ

ЦЕЛЬ РАБОТЫ: познакомиться с принципом работы ASP.NET, научиться использовать нотацию ARIS eEPC для декомпозиции бизнес-процессов низкого уровня организаций на примере модели веб-сервиса.

Студент должен иметь практический опыт:

формирования отчетной документации по результатам работ;

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

Студент должен уметь:

уметь решать прикладные вопросы интеллектуальных систем с использованием, статических экспертных систем, экспертных систем реального времени;

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

Студент должен знать:

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

спецификации языка, создание графического пользовательского интерфейса (GUI), файловый ввод-вывод, создание сетевого сервера и сетевого клиента;

ТЕОРЕТИЧЕСКАЯ ЧАСТЬ

ASP .NET — один из компонентов .NET Framework. основные черты этой технологии:

• Общеязыковая исполнительная среда CLR.

• Библиотека классов .NET Framework.

• Языки.NET (C#, VB .NET, J# и другие).

• ADO .NET.

• ASP .NET.

• Web-службы.

• Промежуточный язык MSIL (Microsoft Intermediate Language). Это ассемблер для среды выполнения CLR.

ADO.NET — набор классов, предназначенных для доступа к базам данных Microsoft SQL Server, к источникам данных OLEDB и к файлам XML.

Разные части вашего проекта могут быть написаны на разных языках, это называется interoperability. Мы попробуем написать проект, где одна из страниц будет на Visual Basic, а другая — на С#.

Компьютерные языки бывают компилируемыми и интерпретируемыми. В процессе компиляции программы, написанной на компилируемом языке, создается выполняемый файл (в Windows — .exe). Он выполняется быстро, но не может исполняться на другой платформе. Машина, на которой она выполняется, должна иметь похожую конфигурацию. Например, если программа использует динамическую библиотеку DLL, то эта библиотека должна быть установлена и на целевой машине. Интерпретируемые программы компилируются в момент выполнения, поэтому они работают медленнее, но не зависят от конкретной машины. В .NET Framework применяется двухэтапная компиляция, то есть первый этап — это компиляция в MSIL, а вторая — компиляция "just-in-time" компилятором во время исполнения. JIT-компилятор оптимизирует код для той машины, на которой он исполняется. В ASP .NET страница компилируется в MSIL при первом обращении клиента к странице. Вместе с ней компилируются классы, которые она использует. Если вы применяете Visual Studio 2005, можно не ожидать первого запроса, а принудительно скомпилировать все страницы вашего проекта. Это позволит выявить синтаксические и другие ошибки.

MSIL — это ассемблер, не зависящий от машины. Он может выполняться на любой машине, где установлена CLR. Проект Mono пытается перенести CLR на другие платформы, позволяя взаимодействовать серверам, работающим на разных платформах.

Как работает ASP .NET

Когда мы инсталлируем .NET, в соответствующих директориях C:\WINDOWS\Microsoft.NET\Framework\ помещается также файлaspnet_isapi.dll. Это — ISAPI-расширение, и предназначено оно для получения запросов, адресованных ASP.NET-приложениям (*.aspx *.asmx и т.д.), а также для создания рабочих процессов aspnet_wp.exe, обрабатывающих запросы. Интернет-сервер — IIS или встроенный в WebMatrix и в Visual Studio Cassini — используют это расширение, когда им надо обработать обращение к страницам с расширением aspx.

Этот модуль разбирает (parse) содержимое страниц aspx вместе с файлом отделенного кода и генерирует класс на языке страницы с объектом Page. Страница aspx отличается от обычной HTML-страницы наличием серверных элементов управления, которые описываются специальными тегами. Для понимания работы ASP.NET важно отметить, что каждому тегу элемента управления соответствует свой член класса страницы. Например,

преобразуется в

@__ctrl = new global::System.Web.UI.WebControls.Label();

Основная задача объекта Page — посылка HTML-кода в выходной поток. Этот класс компилируется в библиотеку DLL, которая загружается в процесс web-сервера. Последующие запросы к странице также обрабатывает DLL, если исходный код страницы не меняется. Все эти файлы можно найти в директории "Temporary ASP.NET Files" текущей версии .NET. Если мы работаем в среде разработки Visual Studio 2005 или VWD, для каждого проекта создается своя поддиректория.

Перед реализацией какого-либо сервиса разрабатывают его модель. Далее рассмотрим декомпозицию бизнес-процессов низкого уровня организации на примере модели веб-сервиса при использовании нотации ARIS eEPC.

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

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

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

• Разные разработчики таких нотаций. В разное время разные разработчики пытались придумать новые принципы описания схем. Делали они это из благих побуждений, когда на практике сталкивались с ситуацией, когда используемая ими нотация не может отразить необходимых тонкостей (либо не наглядно). Иногда в процессе эволюции такие нотации стали как бы параллельными, т.е. выглядят по разному, а задачи решают одинаковые.

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

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

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

ARIS eEPC (extended Event Driven Process с hain) является одной из самых популярных нотаций, которая описывает цепочку процесса, управляемого событиями. Нотация разработана специалистами компании IDS Prof . Scheer GmbH , в частности, самим доктором Шером.

Преимущества нотации eEPC:

1. Это не совсем нотация в чистом виде. Т.е. если в некоторых нотациях существует жесткий набор элементов и правил их использования (иначе все запутается), то принцип eEPC позволяет добавлять собственные элементы. Существует определенный «стержень», вокруг которого все строится, т.е. набор четких правил, по которым строится схема и по которым она потом читается. Кроме этого Вы можете добавить свой элемент, включить правила его использования в собственный корпоративный стандарт (чтобы исключить самодеятельность, которая может запутать схему и усложнить ее читаемость) Это очень важный момент. Кроме этого, в своем корпоративном стандарте можно задать и любые другие ограничения и правила

2. eEPC содержит элементы логики. Это позволяет строить схемы с условиями, что необходимо для описания деятельности («если договор согласован, то… ., иначе … »)

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

4. eEPC настолько легка в обучении и восприятии, что может использоваться в реальной деятельности. На обучение правилам потребуется около 2-х часов.

Главный недостаток, это тот факт, что если использовать простые инструменты (т.е. программы для рисования схем, а не для моделирования бизнес-процессов), то мы не имеем единой базы данных объектов. Кроме этого, сложно проконтролировать, входы-выходы (надо их именно контролировать, т.е. придумать способ такого контроля, если требуется). Но, с другой стороны, использование инструментов моделирования сложных бизнес-процессов стоит весьма внушительных сумм, а проект с их использованием измеряется в миллионах. А так мы имеем очень экономичный и понятный инструмент. Если говорить точнее, этот недостаток относится именно к рассматриваемому способу описания, т.е. с использованием MS V isio или аналогичного ПО. Если Вы будете использовать специализированные системы описания бизнес-процессов, поддерживающие базы данных объектов, то этого недостатка можно избежать.

Нотация ARIS eEPC относится к классу нотаций work flow (описания потоков работ), которые предназначены для описания деятельности в динамике (так же, как и нотация IDEF 3).

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

Основные графические объекты и их взаимосвязь в модели процесса представлены на рис. 48.

Рис. 5. Основные графические объекты и их взаимосвязь в модели - ARIS eEPC

В дословном переводе аббревиатуры eEPC кроется понятие событийности. Это очень важный момент, на котором и строится весь принцип построения схемы. Итак, есть два ключевых понятие: «Событие» и «Функция». Когда первый раз попытаетесь нарисовать свой процесс в виде диаграммы eEPC, то возникнет вопрос, а чем отличается событие от функции? Это надо четко себе уяснить, иначе получится непредсказуемый результат. Так вот: событие – это факт свершения чего-либо, причем не имеющий продолжительности во времени, либо это время стремиться к нулю (или не имеет значения). Причем событие всегда вызывает необходимость исполнения функции, и исполнение функции всегда заканчивается событием.

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

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

Рис.6. Бизнес-процесс трудоустройства в нотации eEPS.

Основные правила при моделировании достаточно просты:

• каждая функция инициируется событием и завершается так же событием,

• в каждую функцию не может входить более одной стрелки, "запускающей" выполнение функции,

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

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

Логические разветвления в потоке процесса отображаются при помощи операторов:

• логическое И;

• логическое ИЛИ;

• логическое взаимоисключающее ИЛИ.

При этом различают два вида операторов: операторы событий и операторы функций. Значения операторов представлены на рис. 7.

Рис. 7. Значения логических операторов в модели ARIS eEPC

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

• Графические элементы процесса (события и функции) следует располагать сверху вниз

• Графические элементы, отображающие исполнителей функций (сотрудников и подразделений) следует располагать справа от функций

• Документы, используемые при выполнении функций, а так же формируемые в результате выполнения функций, располагаются слева от функций

Итогом кропотливой, но творческой работы в ARIS Toolset будет, с одной стороны модель, отвечающая практически на все вопросы как разработчиков и экспертов, так и участников процесса, с другой – наглядная, информативная, логически выстроенная и красивая.

Дело останется за малым: описать модель в документированной процедуре.

Рис. 8. Правила связывания функций и событий через логические операторы в модели ARIS eEPC

Расширение нотации собственными элементами

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

Рис.9. Собственные элементы нотации

Файл с данными. Используется, если в результате выполнения операции создается файл данных, или файл используется для выполнения операции.

База данных. Используется при описании информационных потоков между автоматизированными системами.

Картотека. Используется для отображения бумажной картотеки или архива.

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

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

ПРАКТИЧЕСКАЯ ЧАСТЬ

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

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

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

Рис.10 Microsoft Visio

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

Приложения Microsoft Office, такие как Word и PowerPoint, предоставляют базовые функции для создания диаграмм.

Visio — это специализированное средство, которое более эффективно для создания широкого спектра диаграмм и экономит вам немало времени.

Например, Visio позволяет выполнять следующие операции:

• создавать диаграммы на основе данных и данные на основе диаграмм (в том числе экспортировать данные в отчеты)

• использовать средства соединения для привязки объектов (например, соединения фигур оборудования с линиями, представляющими кабели).

• связывать диаграммы с внешними данными.

• масштабировать диаграммы до нужного уровня точности.

• импортировать САПР-чертежи для использования в качестве основы для точных чертежей.

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

Выполните следующие задания:

1. Запустите MS Visio. Для открытия шаблона EPC в MS Visio необходимо выбрать при создании нового проекта «Бизнес» → «Схема EPC».

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

3. Постройте диаграмму eEPC:

• определите события и действия использования системы;

• определите и покажите на диаграмме типовой ход процесса. Свяжите события и действия в цепочку (используя правила построения диаграмм eEPC). Дополните полученную диаграмму дополнительной информацией (прикладные системы, документы и т.д.);

• определите места ветвления процесса и используйте перекрестки для связи функций и событий;

• определите и разместите на диаграмме документы и организационные единицы.

КОНТРОЛЬНЫЕ ВОПРОСЫ:

1. Как работает ASP.NET?

2. Почему нельзя создать одну нотацию и использовать её? Назовите причины.

3. Как в соответствии с методологией ARIS рассматривается организация?

4. Что такое ARIS eEPC?

5. Назовите преимущества нотации eEPC.

6. Главный недостаток нотации eEPC.

7. К какому классу нотаций относится нотация ARIS eEPC?

8. Назовите основные графические объекты и отразите их взаимосвязь в модели процесса.

9. Чем отличается событие от функции?

10. Назовите основные правила при моделировании.

11. Перечислите правила расположения графических элементов на диаграмме.

12. Перечислите правила связывания функций и событий через логические операторы в модели ARIS eEPC.

ЦЕЛЬ РАБОТЫ: научиться создавать простейший гипертекстовый документ средствами текстового редактора Блокнот, научиться использовать теги форматирования шрифта и абзаца, научиться выполнять вставку рисунков в HTML-документ, научиться создавать закладки и гиперссылки, научиться использовать таблицы для оформления WEB-страниц.

Студент должен иметь практический опыт:

использования инструментальных средств обработки информации;

формирования отчетной документации по результатам работ;

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

Студент должен уметь:

осуществлять информационную постановку задач по обработке информации,

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

Студент должен знать:

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

платформы для создания, исполнения и управления информационной системой;

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

ТЕОРЕТИЧЕСКАЯ ЧАСТЬ

HTML – это стандартный язык разметки документов во Всемирной паутине. Все веб-страницы создаются при помощи языка HTML (или XHTML). Язык HTML интерпретируется браузером и отображается в виде документа, удобном для человека.

Изначально язык HTML был задуман и создан как средство структурирования и форматирования документов без их привязки к средствам воспроизведения (отображения). В идеале, текст с разметкой HTML должен был без искажений воспроизводиться на оборудовании с различной технической оснащённостью.

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

Место языка HTML в иерархии форматов данных

1. SGML-HTML

SGML (англ. Standard Generalized Markup Language ) — метаязык, на котором можно определять язык разметки для документов.

Изначально SGML был разработан для совместного использования машинно-читаемых документов в больших правительственных и аэрокосмических проектах.

HTML является приложением SGML

2. SGML-XML-XHTML

XML (англ. eXtensible Markup Language ) — рекомендованный Консорциумом Всемирной паутины язык разметки, фактически представляющий собой свод общих синтаксических правил. XML — текстовый формат, предназначенный для хранения структурированных данных, для обмена информацией между программами. XML является упрощённым подмножеством языка SGML.

XHTML (англ. Extensible Hypertext Markup Language) — язык разметки веб-страниц, по возможностям сопоставимый с HTML, созданный на базе XML. Соответствует спецификации SGML. Для XHTML можно применять множество технологий, разработанных для XML, например, XSLT и XPath. Анализ XHTML проще и быстрее, чем HTML. Поскольку синтаксис XML строже, чем SGML, обработка XHTML возможна даже на мобильных телефонах с малыми ресурсами.

Структура HTML-документа

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

HTML-документ состоит из двух частей: заголовок (head) и тела (body), расположенных в следующем порядке:

Заголовок документа

Тело документа