|
Архитектура Аудит Военная наука Иностранные языки Медицина Металлургия Метрология Образование Политология Производство Психология Стандартизация Технологии |
|
|
Архитектура Аудит Военная наука Иностранные языки Медицина Металлургия Метрология Образование Политология Производство Психология Стандартизация Технологии |
Управляющие элементы ActiveX ⇐ ПредыдущаяСтр 10 из 10
Почему для включения в текстовый документ электронной таблицы необходимо использовать весь Excel? Если нужны только основные возможности электронных таблиц, то вероятно, можно обойтись меньшим, более быстрым и дешевым компонентом. Многим программистам пришлась бы по вкусу возможность построить целое приложение по большей части из готовых компонентов. Именно подобное желание и привело к идее компонентного программного обеспечения в области, где СОМ способен на очень многое. Повторно применимые компоненты можно создавать на основе исключительно самой СОМ, но для этой цели полезно определить и некоторые стандартные интерфейсы, и соглашения. Используя последние, можно создавать компоненты, единообразно выполняющие такие распространенные задачи, как обеспечение пользовательского интерфейса и посылка сообщений клиенту. Эти стандарты и определяет спецификация управляющих элементов ActiveX (ActiveX Controls). Управляющий элемент ActiveX – независимый программный компонент, выполняющий специфические задачи стандартным способом. Разработчики могут задействовать один или несколько таких элементов в приложении, чтобы получить преимущества функциональных возможностей существующего программного обеспечения. В результате программное обеспечение, построенное в основном из уже готовых частей, и будет то, что называется компонентным программным обеспечением. Управляющие элементы ActiveX – не отдельные приложения. Напротив, они являются серверами, которые подключаются к контейнеру элементов. Как обычно, взаимодействие между управляющим элементом и его контейнером определяется различными интерфейсами, поддерживаемыми СОМ - объектами. Фактически управляющие элементы ActiveX используют многие другие технологии OLE и ActiveX. Например, управляющие элементы обычно поддерживают интерфейсы для внедрения и зачастую предоставляют доступ к своим методам через диспинтерфейсы Автоматизации. Распределенная СОМ Хотя СОМ с самого начала разрабатывалась с учетом поддержки распределенных систем, ее первоначальная реализация могла работать только на одном компьютере. Объекты СОМ могли быть реализованы в DLL или в отдельном процессе, исполняемом на той же машине, что и их клиент, но не могли располагаться на других машинах в вычислительной сети. Эта ситуация изменилась с появлением распределенной СОМ (Distributed СОМ - DCOM). Теперь объекты СОМ могут предоставлять свои сервисы и клиентам на других машинах. Для достижения этого DCOM использует вызов удаленной процедуры (RPC). При использовании RPC клиент выполняет нечто похожее на локальный вызов компонента, но на самом деле вызов обрабатывается компонентом на другой машине сети. В DCOM также включена поддержка средств контроля доступа (контроль за тем, какими клиентами может использоваться данный объект), а также возможность указания, на какой машине должен быть создан объект. Сервисы DCOM можно использовать для создания защищенных распределенных приложений СОМ. Разработку OLE-контейнеров и серверов проще всего вести в среде VisualC++ при помощи специальных мастеров (например, AppWizard), а также библиотеки MFC. Порядок выполнения работы: 1. Создать приложение Cnt для этого: · чтобы приступить к созданию нового проекта, выберите в окне компилятора MicrosoftVisualC++ в меню File команду New; · в окне New выберите элемент MFC AppWizard(exe), в результате чего будет запущен мастер приложений, работа с которым осуществляется в шесть этапов: 1.1 . В первом окне установите опцию Singledocument. 1.2 . Во втором окне не задавайте поддержку баз данных. 1.3 . В третьем окне установите опцию Container, указывающую на то, что приложение будет OLE-контейнером. В этом же окне следует включить поддержку элементов управления ActiveX. 1.4 . В следующем, четвертом, окне необходимо оставить все опции, заданные по умолчанию. 1.5 . В пятом окне установите опцию MFC Standard, опцию включения комментариев в программу и опцию статической компоновки библиотеки MFC. 1.6 . Наконец, в шестом окне, просмотрите список классов, которые будут созданы автоматически, и щелкните на кнопке Finish. · мастер приложений отобразит окно с отчетом о сделанных установках. Если все правильно, щелкните на кнопке ОК, с тем, чтобы запустить процесс генерации кода нового приложения; · осталось только построить исполняемый файл приложения, выбрав для этого в меню Build команду Rebuild All. В результате в папку DEBUG будет добавлен файл СМТ.ЕХЕ. 2. Проанализировать программный код. Приложение включает пять основных исходных файлов, сгенерированных мастером AppWizard: CNT.CPP, MAINFRM.CPP, CNTDOC.CPP, CNTVIEW.CPP и CNTRITEM.CPP. Листинги файлов приведены в приложении 2 3. Внести, где это требуется, изменения. 4. Отладить программы. 5. Проверить работоспособность контейнера, для этого: · запустите приложение Cnt (рисунок 1); · выберите в меню Edit команду InsertNewObject..., в результате чего откроется стандартное диалоговое окно вставки объекта. · в этом окне выделите элемент, соответствующий электронной таблице Excel (рисунок 2); 6. Оценить результат (рисунок 3). 7. Создать приложение по выбору преподавателя. 8. Сдать и защитить работу.
Рис. 1. Окно приложения Cnt
Рис. 2. Выбор внедряемого объекта
Рис. 3. Внедрение электронной таблицы Excel в приложение Cnt Защита отчета по лабораторной работе: Отчет по лабораторной работе должен включать в себя: 1. Листинги программ. 2. Результаты работы. Защита отчета по лабораторной работе заключается в предъявлении преподавателю полученных результатов (на экране монитора), демонстрации полученных навыков и ответах на вопросы преподавателя. Контрольные вопросы: 1. Технологии OLE, COM и ActiveX. 2. Преимущества и недостатки OLE. 3. Преимущества и недостатки COM. 4. Развитие от OLE до ActiveX . 5. VisualC++ и OLE. приложение 1 Варианты заданий Лабораторные работы №№ 1-4 выполняются для одного и того же варианта. 1. Разработать программный модуль «Учет успеваемости студентов». Программный модуль предназначен для оперативного учета успеваемости студентов в сессию деканом, заместителями декана и сотрудниками деканата. Сведения об успеваемости студентов должны храниться в течение всего срока их обучения и использоваться при составлении справок о прослушанных курсах и приложений к диплому. 2. Разработать программный модуль «Личные дела студентов». Программный модуль предназначен для получения сведений о студентах сотрудниками деканата, профкома и отдела кадров. Сведения должны храниться в течение всего срока обучения студентов и использоваться при составлении справок и отчетов. 3. Разработать программный модуль «Решение комбинаторно-оптимизационных задач». Модуль должен содержать алгоритмы поиска цикла минимальной длины (задача коммивояжера), поиска кратчайшего пути и поиска минимального связывающего дерева. 4. Разработать приложение Windows «Органайзер». Приложение предназначено для записи, хранения и поиска адресов и телефонов физических лиц и организаций, а также расписания, встреч и др. Приложение предназначено для любых пользователей компьютера. 5. Разработать приложение Windows «Калькулятор». Приложение предназначено для любых пользователей, и должно содержать все арифметические операции (с соблюдением приоритетов) и желательно, (но не обязательно) несколько математических функций. 6. Разработать программный модуль «Кафедра», содержащий сведения о сотрудниках кафедры (ФИО, должность, ученая степень, дисциплины, нагрузка, общественная работа, совместительство и др.). Модуль предназначен для использования сотрудниками отдела кадров и деканата. 7. Разработать программный модуль «Лаборатория», содержащий сведения о сотрудниках лаборатории (ФИО, пол, возраст, семейное положение, наличие детей, должность, ученая степень). Модуль предназначен для использования сотрудниками профкома и отдела кадров. 8. Разработать программный модуль «Автосервис». При записи на обслуживание заполняется заявка, в которой указываются ФИО владельца, марка автомобиля, вид работы, дата приема заказа и стоимость ремонта. После выполнения работ распечатывается квитанция. 9. Разработать программный модуль «Учет нарушений правил дорожного движения». Для каждой автомашины (и ее владельца) в базе хранится список нарушений. Для каждого нарушения фиксируется дата, время, вид нарушения и размер штрафа. При оплате всех штрафов машина удаляется из базы. 10. Разработать программный модуль «Картотека агентства недвижимости», предназначенный для использования работниками агентства. В базе содержатся сведения о квартирах (количество комнат, этаж, метраж и др.). При поступлении заявки на обмен (куплю, продажу) производится поиск подходящего варианта. Если такого нет, клиент заносится в клиентскую базу и оповещается, когда вариант появляется. 11. Разработать программный модуль «Картотека абонентов АТС». Картотека содержит сведения о телефонах и их владельцах. Фиксирует задолженности по оплате (абонентской и повременной). Считается, что повременная оплата местных телефонных разговоров уже введена. 12. Разработать программный модуль «Авиа касса», содержащий сведения о наличии свободных мест на авиамаршруты. В базе должны содержаться сведения о номере рейса, экипаже, типе самолета, дате и времени вылета, а также стоимости авиабилетов (разного класса). При поступлении заявки на билеты программа производит поиск подходящего рейса. 13. Разработать программный модуль «Книжный магазин», содержащий сведения о книгах (автор, название, издательство, год издания, цена). Покупатель оформляет заявку на нужные ему книги, если таковых нет, он заносится базу и оповещается, когда нужные книги поступают в магазин. 14. Разработать программный модуль «Автостоянка». В программе содержится информация о марке автомобиля, его владельце, дате и времени въезда, стоимости стоянки, скидках, задолженности по оплате и др. 15. Разработать программный модуль «Кадровое агентство», содержащий сведения о вакансиях и резюме. Программный модуль предназначен как для поиска сотрудника, отвечающего требованиям руководителей фирмы, так и для поиска подходящей работы. Примечание: При разработке программы не ограничиваться функциями, приведенными в варианте, добавить несколько своих функций. Обязательно использование структурного и модульного подхода к программированию. Желательно использование объектного подхода. Приложение 2 Пример технического задания на программный продукт
1. ВВЕДЕНИЕ Настоящее техническое задание распространяется на разработку программы построения графиков и таблиц значений функций одной переменной, предназначенной для использования школьниками старших классов. В школьном курсе элементарной алгебры тема анализа функций является одной из самых сложных. При изучении данной темы школьники должны научиться исследовать и строить графики функций одной переменной, используя все известные характеристические точки функции, включая корни, точки разрыва первого и второго рода и т. д. Существующее программное обеспечение, которое может решать подобные задачи, является универсальным, например Eurica или MathCad. Оно имеет сравнительно сложный пользовательский интерфейс, ориентированный на пользователя, прослушавшего, как минимум, институтский курс высшей математики, что делает использование подобных средств школьниками невозможным. Разрабатываемая программа позволит школьникам проверить свои знания при изучении указанной темы. 2. ОСНОВАНИЕ ДЛЯ РАЗРАБОТКИ Программа разрабатывается на основе учебного плана кафедры «Компьютерные системы и сети» и в соответствии с договором кафедры со школой № ... от 5.09.2001. 3. НАЗНАЧЕНИЕ Основным назначением программы является помощь школьникам при изучении раздела «Исследование функций одного аргумента» школьного курса элементарной алгебры. 4.ТРЕБОВАНИЯ К ПРОГРАММЕ ИЛИ ПРОГРАММНОМУ ИЗДЕЛИЮ 4.1.Т р е б о в а н и я к ф у н к ц и о н а л ь н ы м х а р а к т е р и с т и к а м 4.1.1. Программа должна обеспечивать возможность выполнения следующих функций: • ввод аналитического представления функции одной переменной и длительное хранение его в системе; • ввод и изменение интервала определения функции; • ввод и корректировку шага аргумента; • построение таблицы значений функции на заданном интервале иди изображение графика функции на заданном интервале при условии, что на указанном интервале она не имеет точек разрыва. 4.1.2. Исходные данные: • аналитическое задание функции; • интервал определения функции; • шаг изменения аргумента, определяющий количество точек на интервале. 4.2. Т р е б о в а н и я к н а д е ж н о с т и 4.2.1.Предусмотреть контроль вводимой информации. 4.2.2.Предусмотреть блокировку некорректных действий пользователя при работе с системой. 4.3. Т р е б о в а н и я к с о с т а в у и п а р а м е т р а м т е х н и ч е с к и х с р е д с т в 4.3.1.Система должна работать на IBM совместимых персональных компьютерах. 4.3.2.Минимальная конфигурация: • тип процессора ...............................................................Pentium и выше; • объем оперативного запоминающего устройств ........32 Мб и более. 4.4. Т р е б о в а н и я к и н ф о р м а ц и о н н о й и п р о г р а м м н о й с о в м е с т и м о с т и Система должна работать под управлением семейства операционных систем Win 32 (Windows 95, Windows 98, Windows 2000, Windows NT и т. п.). 5. ТРЕБОВАНИЯ К ПРОГРАММНОЙ ДОКУМЕНТАЦИИ 5.1. Разрабатываемые программные модули должны быть самодокументированы, т. е. тексты программ должны содержать все необходимые комментарии. 5.2.Разрабатываемая программа должна включать справочную информацию об основных терминах соответствующего раздела математики и подсказки учащимся. 5.3.В состав сопровождающей документации должны входить: 5.3.1. Пояснительная записка на 25-30 листах, содержащая описание разработки. 5.3.2. Руководство пользователя. Приложение 3 Пример технического задания на разработку
«Утверждаю» Профессор кафедры ВС
Техническое задание системы оперативно-диспетчерского управления теплоснабжением корпусов Московского института »
Москва, 200_ Введение Работа выполняется в рамках проекта «Автоматизированная система оперативно-диспетчерского управления электро-, теплоснабжением корпусов Московского института»
2. Основание для разработки 2.1. Основанием для данной работы служит договор № 1234 от 10 марта 2003 г. 2.1. Наименование работы «Модуль автоматизированной системы оперативно-диспетчерского управления теплоснабжением корпусов Московского института» 2.2. Исполнители: OAO “Лаборатория создания программного обеспечения” 2.3. Соисполнители: нет.
3. Назначение разработки Создание модуля для контроля и оперативной корректировки состояния основных параметров теплообеспечения корпусов Московского института.
4. Технические требования 4.1. Требования к функциональным характеристикам 4.1.1. Состав выполняемых функций Разрабатываемое ПО должно обеспечивать: - сбор и анализ информации о расходовании тепла, горячей и холодной воды по данным теплосчетчиков SA-94 на всех тепловых выходах; - сбор и анализ информации с устройств управления системами воздушного отопления и кондиционирования типа РТ1 и РТ2 (разработки кафедры СММЭ и ТЦ); - предварительный анализ информации на предмет нахождения параметров в допустимых пределах и сигнализирование при выходе параметров за пределы допуска; - выдачу рекомендаций по дальнейшей работе; - отображение текущего состояния по набору параметров -циклически постоянно (режим работы круглосуточный), при сохранении периодичности контроля прочих параметров; - визуализацию информации по расходу теплоносителя: · текущую, аналогично показаниям счетчиков; · с накоплением за прошедшие сутки, неделю, месяц – в виде почасового графика для информации за сутки и неделю; · суточный расход – для информации за месяц. Для устройств управления приточной вентиляцией текущая информация должна содержать номер приточной системы и все параметры, выдаваемые на собственный индикатор. По отдельному запросу осуществляются внутренние настройки; - в конце отчетного периода система должна архивировать данный. 4.1.2. Организация входных и выходных данных Исходные данные в систему поступают в виде значений с датчиков, установленных в помещениях института. Эти значения отображаются на компьютере диспетчера. После анализа поступивший информации оператор диспетчерского пункта устанавливает необходимые параметры для устройств, регулирующих отопление и вентиляцию в помещениях. Возможно также автоматическая установка некоторых параметров для устройств регулирования. Основной режим использования системы – ежедневная работа.
4.2. Требования к надежности Для обеспечения надежности необходимо проверять корректность получаемых данных с датчиков.
4.3. Условия эксплуатации и требования к составу и параметрам технических средств Для работы системы должен быть выделен ответственный оператор. Требования к составу и параметрам технических средств уточняются на этапе эскизного проектирования системы.
4.4. Требования к информационной и программной совместимости Программа должна работать на платформах Windows 98/NT/2000
4.5. Требования к транспортировке и хранению Программа поставляется на лазерном носителе информации. Программная документация поставляется в электронном и печатном виде.
4.6. Специальные требования - Программное обеспечение должно иметь дружественный интерфейс, рассчитанный на пользователя (в плане компьютерной грамотности) квалификации; - Ввиду объемности проекта, задачи предполагается решать поэтапно, при этом модули ПО, созданные в разное время должны предполагать возможность наращивания системы и быть совместимы друг с другом, поэтому документация на принятое эксплуатационное ПО должна содержать полную информацию, необходимую для работы программистов с ним; - Язык программирования – по выбору исполнителя, должен обеспечивать возможность интеграции программного обеспечения с некоторыми видами периферийного оборудования (например счетчик SA-94 и т.п.)
5. Требования к программной документации Основными документами, регламентирующими разработку будущих программ, должны быть документы Единой Системы Программной Документации (ЕСПД): Руководство пользователя, руководство администратора, описание применения.
6. Технико-экономические показатели Эффективность системы определяется удобством использования системы для контроля и управления основными параметрами теплообеспечения помещений Московского института, а также экономической выгодой, полученной от внедрения аппаратно-программного комплекса.
7. Порядок контроля и приемки После передачи Исполнителем отдельного функционального модуля программы Заказчику, последний имеет право тестировать модуль в течении 7 дней. После тестирования Заказчик должен принять работу по данному этапу или в письменном виде изложить причину отказа принятия. В случае обоснованного отказа Исполнитель обязуется доработать модуль.
8. Календарный план работ
Руководитель работ Сидоров А.В. Литература 1. Иванова Г.С. Технология программирования. – М.: Из-во МГТУ им. Баумана 2002, - 241 с. 2. Гагарина Л.Г., Виснадул Б.Д, Игошин А.В. Основы технологии разработки программных продуктов: Учеб. пособие – М.: Форум, 2006. 3. Майерс Г. Искусство тестирования программ / Пер. с англ. под ред. Б. А. Позина. - М.: Финансы и статистика,1982.-176с. 4. http://www.realcoding.net/article/view/1833 5. http://www.rusdoc.ru/material/lang/other/activex/active.shtml
|
Последнее изменение этой страницы: 2019-05-08; Просмотров: 379; Нарушение авторского права страницы
