Разработка и внедрение адаптированной автоматизированной системы управления филиалом КГПУ ИМ. В.П. Астафьева в г. Канске
Анализ имеющихся систем для управления учебным заведением. Запросы и потребности автоматизации управления учебным процессом в филиале КГПУ им. В.П.Астафьева. Оценка эффективности внедрения новой адаптированной автоматизированной системы управления.
Рубрика | Программирование, компьютеры и кибернетика |
Вид | дипломная работа |
Язык | русский |
Дата добавления | 19.06.2013 |
Размер файла | 1,1 M |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Один из наиболее известных теоретиков в области моделей данных Беери предлагает в общих чертах формальную основу ООБД, далеко не полную и не являющуюся моделью данных в традиционном смысле, но позволяющую исследователям и разработчикам систем ООБД по крайней мере говорить на одном языке (если, конечно, предложения Беери будут развиты и получат поддержку). Независимо от дальнейшей судьбы этих предложений мы считаем полезным кратко их пересказать:
Во-первых, следуя практике многих ООБД, предлагается выделить два уровня моделирования объектов: нижний (структурный) и верхний (поведенческий). На структурном уровне поддерживаются сложные объекты, их идентификация и разновидности связи «отношением классификации (ISA)».База данных - это набор элементов данных, связанных отношениями "входит в класс" или "является атрибутом". Таким образом, БД может рассматриваться как ориентированный граф. Важным моментом является поддержание наряду с понятием объекта понятия значения (позже мы увидим, как много на этом построено в одной из успешных объектно-ориентированных СУБД O2).
Важным аспектом является четкое разделение схемы БД и самой БД. В качестве первичных концепций схемного уровня ООБД выступают типы и классы. Отмечается, что во всех системах, использующих только одно понятие (либо тип, либо класс), это понятие неизбежно перегружено: тип предполагает наличие некоторого множества значений, определяемого структурой данных этого типа; класс также предполагает наличие множества объектов, но это множество определяется пользователем. Таким образом, типы и классы играют разную роль, и для строгости и недвусмысленности требуется одновременная поддержка обоих понятий. Беери не представляет полной формальной модели структурного уровня ООБД, но выражает уверенность, что текущего уровня понимания достаточно, чтобы формализовать такую модель. Что же касается поведенческого уровня, предложен только общий подход к требуемому для этого логическому аппарату (логики первого уровня недостаточно).
Важным, хотя и недостаточно обоснованным предположением Беери является то, что двух традиционных уровней - схемы и данных - для ООБД недостаточно. Для точного определения ООБД требуется уровень мета-схемы, содержимое которой должно определять виды объектов и связей, допустимых на схемном уровне БД. Мета-схема должна играть для ООБД такую же роль, какую играет структурная часть реляционной модели данных для схем реляционных баз данных.
Имеется множество других публикаций, относящихся к теме объектно-ориентированных моделей данных, но они либо затрагивают достаточно частные вопросы, либо используют слишком серьезный для этого обзора математический аппарат (например, некоторые авторы определяют объектно-ориентированную модель данных на основе теории категорий) [5].
Для иллюстрации текущего положения дел мы кратко рассмотрим особенности конкретной модели данных, применяемой в объектно-ориентированной СУБД O2 (это, конечно, тоже не модель данных в классическом смысле).
В O2 поддерживаются объекты и значения:
Объект - это пара (идентификатор, значение), причем объекты инкапсулированы, т.е. их значения доступны только через методы - процедуры, привязанные к объектам.
Значения могут быть атомарными или структурными. Структурные значения строятся из значений или объектов, представленных своими идентификаторами, с помощью конструкторов множеств, кортежей и списков. Элементы структурных значений доступны с помощью предопределенных операций (примитивов).
Возможны два вида организации данных: классы, экземплярами которых являются объекты, инкапсулирующие данные и поведение, и типы, экземплярами которых являются значения. Каждому классу сопоставляется тип, описывающий структуру экземпляров класса. Типы определяются рекурсивно на основе атомарных типов и ранее определенных типов и классов с применением конструкторов. Поведенческая сторона класса определяется набором методов.
Объекты и значения могут быть именованными. С именованием объекта или значения связана долговременность его хранения (persistency): любые именованные объекты или значения долговременны; любые объект или значение, входящие как часть в другой именованный объект или значение, долговременны.
С помощью специального указания, задаваемого при определении класса, можно добиться долговременности хранения любого объекта этого класса. В этом случае система автоматически порождает значение-множество, имя которого совпадает с именем класса. В этом множестве гарантированно содержатся все объекты данного класса [21].
Метод - программный код, привязанный к конкретному классу и применимый к объектам этого класса. Определение метода в O2 производится в два этапа. Сначала объявляется сигнатура метода, т.е. его имя, класс, типы или классы аргументов и тип или класс результата. Методы могут быть публичными (доступными из объектов других классов) или приватными (доступными только внутри данного класса). На втором этапе определяется реализация класса на одном из языков программирования O2 (подробнее языки обсуждаются в следующем разделе нашего обзора).
В модели O2 поддерживается множественное наследование классов на основе отношения супертип/подтип. В подклассе допускается добавление и/или переопределение атрибутов и методов. Возможные при множественном наследовании двусмысленности (по именованию атрибутов и методов) разрешаются либо путем переименования, либо путем явного указания источника наследования. Объект подкласса является объектом каждого суперкласса, на основе которого порожден данный подкласс.
Поддерживается предопределенный класс "Оbject", являющийся корнем решетки классов; любой другой класс является неявным наследником класса "Object" и наследует предопределенные методы ("is_same", "is_value_equal" и т.д.).
Специфической особенностью модели O2 является возможность объявления дополнительных "исключительных" атрибутов и методов для именованных объектов. Это означает, что конкретный именованный объект-представитель класса может обладать типом, являющимся подтипом типа класса. Конечно, с такими атрибутами не работают стандартные методы класса, но специально для именованного объекта могут быть определены дополнительные (или переопределены стандартные) методы, для которых дополнительные атрибуты уже доступны. Подчеркивается, что дополнительные атрибуты и методы привязываются не к конкретному объекту, а к имени, за которым в разные моменты времени могут стоять вообще говоря разные объекты. Для реализации исключительных атрибутов и методов требуется развитие техники позднего связывания.
Логическое проектирование
Для логического проектирования выбрана реляционная модель данных, т.к. она наиболее полно соответствует требованиям, предъявленным к разрабатываемой информационной системе [21]:
отсутствие дублируемой информации;
поддержание целостности данных при вставке, удалении или изменении записей;
возможность организации всех видов связи между отношениями 1:1, 1:N и M:N.
В реляционной базе данных даталогическое проектирование приводит к разработке корректной схемы базы данных, т.е. такой схемы, в которой отсутствуют нежелательные зависимости между атрибутами. При этом можно использовать процесс проектирования с помощью декомпозиции, т.е. последовательно нормализовать схему отношений, тем самым накладывая ограничения и избавляясь от нежелательных зависимостей между атрибутами.
Чтобы перейти к реляционной модели и построить даталогическую модель АСУ, каждой сущности из инфологической модели данных поставим в соответствие отношение реляционной модели. В таком случае, каждый атрибут сущности становится атрибутом соответствующего ему отношения. Также укажем каждому атрибуту тип данных и признак обязательности. Обозначим первичные и внешние ключи. После всего проведем нормализацию получившейся модели данных.
Приведем список атрибутов для каждого отношения в схеме базы данных:
Преподаватель
ФИО - текстовый
Должность - текстовый
Образование - поле MEMO
Квалификация - поле MEMO
Ученая степень - поле MEMO
Дисциплина
ФИО преподавателя - текстовый
Название - текстовый
Количество кредитов - числовой
Количество часов - числовой
Курс - числовой
Специалитет/ бакалавриат - числовой
Экзамен/ зачет - числовой
Сессия зимняя/ летняя - числовой
Студент
ФИО - текстовый
Курс - числовой
Адрес - текстовый
Дата рождения - текстовый
Телефон - текстовый
Номер группы - числовой
Данные о студенте - поле MEMO
Школа - поле MEMO
Семья - поле MEMO
Сессия - поле MEMO
Активность - поле MEMO
Практика - поле MEMO
Курсовые работы - поле MEMO
ИГА - поле MEMO
Размещено на http://www.allbest.ru
Размещено на http://www.allbest.ru
Рис. 4 Схема базы данных до нормализации.
Нормализация схемы базы данных
Нормальная форма -- свойство отношения в реляционной модели данных, характеризующее его с точки зрения избыточности, которая потенциально может привести к логически ошибочным результатам выборки или изменения данных. Нормальная форма определяется как совокупность требований, которым должно удовлетворять отношение [8].
Нормализация - это процесс преобразования базы данных к виду, отвечающему нормальным формам. Нормализация предназначена для приведения структуры базы данных к виду, обеспечивающему минимальную избыточность, то есть нормализация не имеет целью уменьшение или увеличение производительности работы или же уменьшение или увеличение объёма БД. Конечной целью нормализации является уменьшение потенциальной противоречивости хранимой в БД информации [7].
Устранение избыточности производится, как правило, за счёт декомпозиции отношений таким образом, чтобы в каждом отношении хранились только первичные факты (то есть факты, не выводимые из других хранимых фактов).
Таблица находится в первой нормальной форме, если каждый её атрибут атомарен, то есть может содержать только одно значение. Таким образом, не существует 1NF таблицы, в полях которых могут храниться списки значений. Для приведения таблицы к 1NF обычно требуется разбить таблицу на несколько отдельных таблиц.
Отношение находится во второй нормальной форме (2NF), если она находится в первой нормальной форме, и при этом любой её атрибут, не входящий в состав первичного ключа, функционально полно зависит от первичного ключа. Функционально полная зависимость означает, что атрибут функционально зависит от всего первичного составного ключа, но при этом не находится в функциональной зависимости от какой-либо из входящих в него атрибутов (частей). Или другими словами: в 2NF нет неключевых атрибутов, зависящих от части составного ключа.
Отношение находится в третьей нормальной форме (3NF), если она находится во второй нормальной форме 2NF и при этом любой ее неключевой атрибут зависит только от первичного ключа (Primary key, PK). Таким образом, отношение находится в 3NF тогда и только тогда, когда оно находится во 2NF и отсутствуют транзитивные зависимости неключевых атрибутов от ключевых.
Результирующее отношение, находящееся в третьей нормальной форме, приведено на рисунке 5.
Размещено на http://www.allbest.ru
Размещено на http://www.allbest.ru
Рис. 5 Нормализованная база данных
Разработка адапированной автоматизированной системы управления для филиала КГПУ в г.Канске
В данной главе проведен анализ и выбрана СУБД, в которой осуществлено физическое проектирование базы данных. Также указаны особенности разработки представлений, форм и отчетов, методы реализации ограничений и способы обеспечения безопасности информации, хранимой в базе данных
Анализ и выбор СУБД
Для программной реализации информационной системы выбрана СУБД Microsoft Access. Microsoft Access является настольной СУБД (система управления базами данных) реляционного типа. Достоинством Access является то, что она имеет очень простой графический интерфейс, который позволяет не только создавать собственную базу данных, но и разрабатывать приложения, используя встроенные средства [13].
В отличие от других настольных СУБД, Access хранит все данные в одном файле, хотя и распределяет их по разным таблицам, как и положено реляционной СУБД. К этим данным относится не только информация в таблицах, но и другие объекты базы данных, которые будут описаны ниже.
Для выполнения почти всех основных операций Access предлагает большое количество Мастеров (Wizards), которые делают основную работу за пользователя при работе с данными и разработке приложений, помогают избежать рутинных действий и облегчают работу неискушенному в программировании пользователю.
Особенности MS Access, отличающиеся от представления об «идеальной» реляционной СУБД [13]:
Создание многопользовательской БД Access и получение одновременного доступа нескольких пользователей к общей базе данных возможно в локальной одноранговой сети или в сети с файловым сервером.
Сеть обеспечивает аппаратную и программную поддержку обмена данными между компьютерами.
Access следит за разграничением доступа разных пользователей к БД и обеспечивает защиту данных. При одновременной работе. Так как Access не является клиент серверной СУБД, возможности его по обеспечению многопользовательской работы несколько ограничены. Обычно для доступа к данным по сети с нескольких рабочих станций, файл БД Access (с расширением *.mdb) выкладывается на файловый сервер. При этом обработка данных ведется в основном на клиенте - там, где запущено приложение, в силу принципов организации файловых СУБД. Этот фактор ограничивает использование Access для обеспечения работы множества пользователей (более 15-20) и при большом количестве данных в таблицах, так как многократно возрастает нагрузка не сеть.
В плане поддержки целостности данных Access отвечает только моделям БД небольшой и средней сложности. В нем отсутствуют такие средства как триггеры и хранимые процедуры, что заставляет разработчиков возлагать поддержание бизнес логики БД на клиентскую программу.
В отношении защиты информации и разграничения доступа Access не имеет надежных стандартных средств. В стандартные способы защиты входит защита с использованием пароля БД и защита с использованием пароля пользователя. Снятие такой защиты не представляет сложности для специалиста.
Однако, при известных недостатках MS Access обладает большим количеством преимуществ по сравнению с системами подобного класса.
В первую очередь можно отметить распространенность, которая обусловлена тем, что Access является продуктом компании Microsoft, программное обеспечение и операционные системы которой использует большая часть пользователей персональных компьютеров. MS Access полностью совместим с операционной системой Windows, постоянно обновляется производителем, поддерживает множество языков [13].
В целом MS Access предоставляет большое количество возможностей за сравнительно небольшую стоимость. Также необходимо отметить ориентированность на пользователя с разной профессиональной подготовкой, что выражается в наличии большого количества вспомогательных средств (Мастеров, как уже отмечалось), развитую систему справки и понятный интерфейс. Эти средства облегчают проектирование, создание БД и выборку данных из нее.
MS Access предоставляет в распоряжение непрограммирующему пользователю разнообразные диалоговые средства, которые позволяют ему создавать приложения не прибегая к разработке запросов на языке SQL или к программированию макросов или модулей на языке VBA.
Access обладает широкими возможностями по импорту/экспорту данных в различные форматы, от таблиц Excel и текстовых файлов, до практически любой серверной СУБД через механизм ODBC.
Еще одно немаловажное преимущество MS Access заключается в развитых встроенных средствах разработки приложений. Большинство приложений, распространяемых среди пользователей, содержит тот или иной объем кода VBA (Visual Basic for Applications). Поскольку VBA является единственным средством для выполнения многих стандартных задач в Access (работа с переменными, построение команд SQL во время работы программы, обработка ошибок, использование Windows API и т. д.), для создания более-менее сложных приложений необходимо его знание и знание объектной модели MS Access [13].
Одним из средств программирования в Access является язык макрокоманд. Программы, созданные на этом языке, называются макросами и позволяют легко связывать отдельные действия, реализуемые с помощью форм, запросов, отчетов. Макросы управляются событиями, которые вызываются действиями пользователями при диалоговой работе с данными через формы или системными событиями.
Для отображения отчетов и форм написана программа-клиент на языке Delphi 7, используя технологию ADO для доступа к базе данных Microsoft Access.
Delphi -- императивный, структурированный, объектно-ориентированный язык программирования, диалект Object Pascal. Начиная со среды разработки Delphi 7.0, в официальных документах Borland стала использовать название Delphi для обозначения языка Object Pascal. Начиная с 2007 года уже язык Delphi (производный от Object Pascal) начал жить своей самостоятельной жизнью и претерпевал различные изменения, связанные с современными тенденциями (например, с развитием платформы .NET) развития языков программирования: появились class helpers, перегрузки операторов и другое [26].
Object Pascal -- результат развития языка Турбо Паскаль, который, в свою очередь, развился из языка Паскаль. Паскаль был полностью процедурным языком, Турбо Паскаль, начиная с версии 5.5, добавил в Паскаль объектно-ориентированные свойства, а в Object Pascal -- динамическую идентификацию типа данных с возможностью доступа к метаданным классов (то есть к описанию классов и их членов) в компилируемом коде, также называемом интроспекцией -- данная технология получила обозначение RTTI. Так как все классы наследуют функции базового класса TObject, то любой указатель на объект можно преобразовать к нему, после чего воспользоваться методом ClassType и функцией TypeInfo, которые и обеспечат интроспекцию.
Также отличительным свойством Object Pascal от С++ является то, что объекты по умолчанию располагаются в динамической памяти. Однако можно переопределить виртуальные методы NewInstance и FreeInstance класса TObject. Таким образом, абсолютно любой класс может осуществить «желание» «где хочу -- там и буду лежать». Соответственно организуется и «многокучность».
ADO (от англ. ActiveX Data Objects -- «объекты данных ActiveX») -- интерфейс программирования приложений для доступа к данным, разработанный компанией Microsoft (MS Access, MS SQL Server) и основанный на технологии компонентов ActiveX. ADO позволяет представлять данные из разнообразных источников (реляционных баз данных, текстовых файлов и т. д.) в объектно-ориентированном виде [21].
Физическое проектирование базы данных в СУБД.
При физическом проектировании базы данных созданы следующие таблицы:
Активности (Activities)
Курсовые работы (Course_works)
Дисциплины (Disciplines)
Факультеты (Faculty)
Формы обучения (Form_of_edu)
ИГА (IGA)
Кафедры (kafedra)
Курс (Kurs)
Список зачетов (log_credit)
Список экзаменов (log_exam)
Практика (Practice)
Профессоры (Professors)
Студенты (Students)
Тип курсовой работы (Type_kWork)
Тип обучения (Type_of_edu)
Схема разработанной в СУБД базы данных приведена в приложении №2.
Разработка форм
Для упрощения добавления новых данных в базу данных для пользователей информационной системы созданы следующие формы:
Добавление преподавателя - добавляет нового преподавателя в базу данных с назначением дисциплин, которые закрепляется за преподавателем;
Добавление студента - добавляет нового студента в базу данных, а также записывается группа, в которой будет числиться студент;
Дисциплины - добавляет новую дисциплину в базу данных, а также привязывает ее к конкретному преподавателю;
Сессия - для редактирования списка экзаменов и зачетов в сессии на разных курсах;
Управление шаблонами - для вывода информации в другие приложения (MS Word, MS Excel, Notepad) [13];
Редактирование БД - просмотр всех форм предназначенных для редактирования БД;
Настройки - настройка некоторых особенностей АСУ.
Разработка отчетов
Для отображения информации находящейся в БД, в удобной для печати форме, а также для автоматизации заполнения некоторых текстовых документов созданы следующие шаблоны и процедуры для их заполнения, например:
Приказ на стипендию (приложени № 3);
Приказ на практику (приложение № 4);
Шаблоны объявлений;
Рассписание экзаменов и зачетов;
И прочее.
Безопасность и контроль
Для безопасного хранения информации в базе данных используются средства, предоставляемые СУБД Microsoft Access, такие как: шифрование данных, ограничение доступа паролем и другие.
А также данные защищаются от несанкционированного доступа через приложение при помощи системы логинов и паролей.
2.2 Практика внедрения адаптированной автоматизированной системы управления «Деканат» в практику работы филиала
Тестирование программного продукта - это процесс многократного выполнения программы с целью обнаружения ошибок. При его проведении необходимо помнить, что тестирование считается удачным, если оно позволяет выявить ошибки, а не продемонстрировать отсутствие ошибок в программе. Тестовый набор, или наборы входных данных, эффективен, если имеет высокую вероятность обнаружения ошибок. Суть тестирования заключается в том, что это процесс творческий, плохо поддающийся формализации.
Методы тестирования направлены на обнаружение максимального числа ошибок в наиболее важных режимах функционирования программ при ограниченных ресурсах. Применяются такие методы тестирования, как статическое тестирование, детерминированное тестирование, стохастическое тестирование, тестирование в реальном масштабе времени.
Статическое тестирование является наиболее формализованным, базирующимся на правилах структурного построения программ обработки данных. Его нередко называют символическим, так как операторы и операнды текста программы анализируются в символьном виде. Статическое тестирование базируется на применении ручных методов и осуществляется обычно группой специалистов.
Стохастическое тестирование применяется для комплексного тестирования программного изделия и предполагает использование в качестве исходных данных множества случайных величин с соответствующими распределениями, а для сравнения полученных результатов используется также распределения случайных величин.
Тестирование в реальном масштабе времени применяется для программных изделий, предназначенных для работы в системах реального времени. В процессе такого тестирования проверяются результаты обработки исходных данных с учетом времени их поступления, длительности и приоритетности обработки, динамики использования памяти и взаимодействия с другими программами [20].
Детерминированное тестирование - наиболее трудоемкое и детализированное, требующее многократного выполнения программы на ЭВМ с использованием определенных, специальным образом подобранных тестовых наборов данных. При детерминированном тестировании контролируется каждая комбинация исходных данных и соответствующие результаты. Детерминированное тестирование в силу трудоемкости возможно применять для отдельных модулей в процессе сборки программы или для небольших и несложных программных комплексов. Детерминированное тестирование является наиболее эффективным и основывается на подходах структурного и функционального тестирования.
Структурное тестирование предполагает детальное изучение логики программы и подбор таких входных наборов данных, которые позволили бы при многократном выполнении программы на ЭВМ обеспечить выполнение максимально возможного количества маршрутов, логических ветвлений, циклов и так далее. Функциональное тестирование, полностью абстрагируется от логики программы. Здесь, тестовые наборы, выбираются на основании анализа входных функциональных спецификаций [20].
В ходе тестирования были устранены недочеты в оформлении интерфейса; в правильности построения логики событий; в адекватности реакции приложения на возникающие исключительные ситуации.
Наибольшее внимание, при реализации данного программного продукта, было уделено надежности и защите от ошибок при вводе, редактировании данных, а также при расчетах модели. При тестировании, специальным образом, был допущен ряд ошибок при вводе. Все это было сделано с целью создания ряда исключительных ситуаций. В итоге, программа самостоятельно обрабатывала каждый возникающий сбой и выдавала соответствующее сообщение об ошибке.
Корректный ввод и редактирование обеспечивается, прежде всего, с помощью программного отслеживания всей вводимой информации, а также использования блоков обработки исключительных ситуаций.
ЗАКЛЮЧЕНИЕ
На сегодняшний день снижение времени принятия управленческих решений является актуальным для руководителей организаций, так как это позволит наиболее эффективно работать организации.
Данная выпускная квалификационная работа посвящена проектированию системы автоматизированного документооборота кафедры информатики филиала. Целью проектирования является повышение эффективности работы факультета информатики в филиале, снижение трудоемкости процессов обработки информации.
В ходе иследования был проведен обзор продуктов аналогов на рынке информационных систем (АСУ «КОЛЛЕДЖ», АСУ «Учебное заведение», АСУ «ВУЗ»). Выявлено, что выбор в пользу коммерческих разработок не всегда является рациональным. За частую ВУЗы делают выбор в пользу разработки собственной автоматизированной системы, что позволяет иметь в руках систему, которая будет адаптированна под конкретное учебное заведение, что позволяет использовать ее более эффективно, чем систему которая разработанна под общие требования.
Следующим этапом иследования стала разрабботка информационно-логической модели. Выделены сущности, дано их описание и построена инфологическая модель предметной области.
Далее в ходе обоснования выбора модели данных описаны существующие модели данных (иерархическая, сетевая, реляционная, объектно-ориентированная), указаны их достоинства и недостатки, и сделан выбор в пользу реляционной модели.
Затем на основании инфологической модели построена даталогическая модель данных, дан список атрибутов ее отношений и проведена нормализация до третьей нормальной формы. Таким образом, завершено проектирование базы данных и получена вся информация, необходимая для реализации проектируемой инфомационной системы в одной из реляционных СУБД.
Выбор СУБД был отдан в пользу Microsoft Access, в которой осуществлено физическое проектирование базы данных.
При этом построена схема базы данных, введены ограничения на информацию, составлены процедуры, и получены отчеты. Для реализации форм и отчетов написаны программы на языке Delphi с использованием технологии доступа к базе данных ADO. Далее были рассмотрены вопросы безопасности и контроля доступа к информации, хранящейся в базе данных.
Таким образом, в процессе разработки выпускной квалификационной работы было разработано программное средство, позволяющее автоматизировать управление образованием. Данная работа реализована в виде приложения. Результатами работы приложения являются отчёты, содержащие результаты учета и движения студенческого контингента. Отчёты программно передаются в MS Word и MS Excel., разработанная автоматическая система управления готова к опытной эксплуатации в филиале КГПУ им. В.П.Астафьева. На данный момент система проходит тестирование, выявляются недостатки, исправляются ошибки.
СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ
Архангельская А.Я. Программирование в Delphi для Windows. Версии 2006, 2007, Turbo Delphi. - М.: Изд-во Бином-Пресс, 2007 г.
Баженова И.Ю. Основы проектирования приложений баз данных - СПб.: Изд-во "Питер", 2009г.
Воронов А.А., Титов В.К., Новоградов Б.Н. Основы теории автоматического регулирования и управления. - М.: «Высшая школа», 1977г.
ГОСТ 34.602-89 «Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы».
Грибачев К.Е. Delphi и Model Driven Architecture. Разработка приложений баз данных. - СПб.: Изд-во "Питер", 2004г.
Дарахвелидзе П.Г., Марков Е.П. Программирование в Delphi 7. - СПб.: Изд-во БХВ-Петербург, 2003 г.
Диго С.М. Проектирование и использования баз данных. Москва: - М.: Изд-во BHV, 1995 г.
К.Дж.Дейт, Хью Дарвен Основы будущих систем баз данных. Третий манифест. Изд-во Янус-К, 2004 г.
Кириленко А.Ю., Кириленко Г.В., Малышев Н.К. Автоматизированная система управления энергетическими ресурсами муниципального образования. - СПб.: Изд-во БХВ-Петербург, 2003 г.
Кириллов В.В. Структуризованный язык запросов (SQL). - СПб.: ИТМО, 1994г.
Кириллов В.В., Громов Г.Ю. Введение в реляционные базы данных, - СПб.: Изд-во "Питер", 2009г.
Когловский М.Р., Технология баз данных на персональных ЭВМ - М.: Изд-во BHV, 1992 г.
Корняков В.И. Программирование документов и приложений MS Office в Delphi. - СПб.: Изд-во БХВ-Петербург, 2005 г.
Косарева В.П., Королёва А.Ю. Экономическая информатика и вычислительная техника. - М.: «Финансы и статистика», 1996г
Л.А. Астреина, В.В. Балдесов и др., Технико-экономическое обоснование дипломных проектов: учебное пособие для ВУЗов. - М.: Изд-во Высшая шк. , 1991г.
Лукас В.А. Теория автоматического управления. - М.: «Недра», 1990г.
Первозванский А.А. Курс автоматического управления. - М.: «Наука», 1986г.
Пестриков В.П., Маслобоев А.В. Delphi на примерах. - СПб.: Изд-во БХВ-Петербург, 2005 г.
Подлесный Н.И., Рубанов В.Г. Элементы систем автоматического управления и контроля. - Киев.: Изд-во «Вища школа»,1982 г.
Ревич Ю.А. Нестандартные приемы программирования на Delphi. - М.: Изд-во BHV, 2005 г.
Сорокин А.Ю. Delphi. Разработка баз данных. - СПб.: Изд-во "Питер", 2005г.
Ульман Д.К., Уидом Д.Б. Основы реляционных баз данных, - М.: Изд-во BHV, 2006 г.
Фленов М.Г. Библия для программиста в среде Delphi . - СПб.: Изд-во БХВ-Петербург, 2003 г.
Ципкин Я.З. Основы теории автоматических систем. - М.: «Наука», 1977г.
BookDelphi Delphi -- что это? [электронный ресурс] http://bookdelphi.narod.ru/Delphi7_nach/Intro/Index1.htm
http://www.realcoding.net/articles/predislovie-delphi-%E2%80%94-chto-eto.html
WikiPedia - свободная энциклопедия Delphi (язык программирования) [электронный ресурс] http://ru.wikipedia.org/wiki/Delphi_ (%FF%E7%FB%EA_%EF%F0%EE%E3%F0%E0%EC%EC%E8%F0%EE%E2%E0%ED%E8%FF)
АСУ «ВУЗ» [электронный ресурс] http://www.gisoft.ru/
АСУ «КОЛЛЕДЖ» [электронный ресурс] http://www.tpcol.ru/asu/
АСУ «Учебное заведение» [электронный ресурс] http://www.mkr.org.ua/index.php?mnu=36
Бартенев А.С. Обзор основных вопросов автоматизированного составления расписания занятий в высшем учебном заведении [электронный ресурс] http://web.snauka.ru/issues/2011/09/2576
Зинин Ф.П. Автоматизированные системы управления учебным процессом в вузе [электронный ресурс] http://www.referat.ru/referats/ view/20211
Ливанов Ю.С. Делфи - что это? [электронный ресурс]
Прокофьева Е.К. Из опыта организации управления учебным процессом высшей школы [электронный ресурс] http://www.relga.ru/ Environ/WebObjects/tgu-www.woa/wa/Main?textid=1261&level1=main &level2=articles
Светловская А.Р.Автоматизация управления учебно-воспитательным процессом [электронный ресурс] http://conspects.ru/content/view/20/4/
Солдатова Г.Г. Как решить проблемы использования компьютерных технологий... [электронный ресурс] http://www.ug.ru/archive/36071
Спиридонов Г.В. Дистанционное обучение школьников с «КМ-школой» [электронный ресурс] http://www.digital-edu.ru/issh/161/382
Электронный Журнал "Успехи современного естествознания" Автоматизация управления учебным процессом в вузе [электронный ресурс] http://www.rae.ru/use/?section=content&op=show_article&article _id=7784566
Энциклопедия Кольера on-line Slovoblog.ru [электронный ресурс] http://www.slovoblog.ru/koler/
ПРИЛОЖЕНИЕ 1
Диск с адаптированной автоматизированной системой управления филиалом КГПУ им. В.П. Астафьева в г. Канске
ПРИЛОЖЕНИЕ 2
Размещено на http://www.allbest.ru
Размещено на http://www.allbest.ru
ПРИЛОЖЕНИЕ 3
Шаблон приказа на стипендию
Филиал федерального государственного бюджетного образовательного учреждения высшего профессионального образования
КРАСНОЯРСКИЙ ГОСУДАРСТВЕННЫЙ ПЕДАГОГИЧЕСКИЙ УНИВЕРСИТЕТ имени В.П.Астафьева в г.Канске
ПРИКАЗ
«_25_»____января_____ 2013г. №
О назначении на стипендию студентов
факультета информатики филиала
КГПУ им В.П.Астафьева в г.Канске
- 1 -
На основании результатов зимней экзаменационной сессии 2012-2013 учебного года ПРИКАЗЫВАЮ:
назначить на стипендию с 1 февраля 2013 года по 30 июня 2013 года следующих студентов:
51 ГРУППА
обучающихся на оценки «отлично» |
обучающихся на оценки «хорошо» и «отлично» |
обучающихся на оценки «хорошо» |
|
41 ГРУППА
обучающихся на оценки «отлично» |
обучающихся на оценки «хорошо» и «отлично» |
обучающихся на оценки «хорошо» |
|
31 ГРУППА
обучающихся на оценки «отлично» |
обучающихся на оценки «хорошо» и «отлично» |
обучающихся на оценки «хорошо» |
|
21 ГРУППА
обучающихся на оценки «отлично» |
обучающихся на оценки «хорошо» и «отлично» |
обучающихся на оценки «хорошо» |
|
11 ГРУППА
обучающихся на оценки «отлично» |
обучающихся на оценки «хорошо» и «отлично» |
обучающихся на оценки «хорошо» |
|
Назначить на материальное обеспечение….
Директор филиала КГПУ им В.П.Астафьева в г.Канске А.Л.АНДРЕЕВ
Подготовил: Ю. С. БАРАНОВ
ПРИЛОЖЕНИЕ 4
Шаблонриказа на практику
ФИЛИАЛ КГПУ в г. КАНСКЕ
08.09.2011 г. ПРИКАЗ №___
В соответствии с учебным планом и графиком учебного процесса на факультете «Информатика», направить на государственную (стажерскую) педагогическую практику студентов 5 курса факультета информатики с 8 сентября по 9 ноября 2011 года в следующие образовательные учреждения:
В базовые образовательные учреждения, на основании договоров о сотрудничестве:
В образовательные учреждения, на основании справок - отношений о принятии студентов на государственную (стажерскую) практику:
Общее руководство и контроль за прохождением на государственной (стажерской) педагогической практикой возложить на Баранова Ю.С., декана факультета.
Директор _______________________
Размещено на Allbest.ru
Подобные документы
Организация управления высшим учебным заведением. Анализ деятельность кафедры, перечень исходных показателей. Построение автоматизированной концептуальной информационно-логической модели базы данных. Системные и технические средства реализации проекта.
дипломная работа [1,3 M], добавлен 25.03.2015Использование автоматизированной системы управления учебным процессом. Изучение возможностей реализации задач документооборота "Приемной комиссии" в системе "1С:Колледж". Требования к функциональным характеристикам. Уровни администрирования и доступа.
дипломная работа [182,1 K], добавлен 31.03.2014Обзор медицинских информационных систем. Анализ и моделирование автоматизированной системы "Регистратура". Требования к составу и параметрам вычислительной системы. Обоснование выбора системы управления базами данных. Разработка инструкции пользователя.
дипломная работа [1,2 M], добавлен 14.10.2012Понятие автоматизированной информационной системы, ее структурные компоненты и классификация. Основные функции систем управления процессом. Применение базы данных процесса для мониторинга и управления. Доступ к базе данных процесса, запросы и протоколы.
реферат [457,1 K], добавлен 18.12.2012Общая характеристика системы контроля и управления. Разработка автоматизированной 2-х уровневой системы управления технологическим процессом вакуумной компрессорной станции № 23 Самотлорского месторождения на базе продукции компании Rockwell Automation.
дипломная работа [2,6 M], добавлен 29.09.2013Технология выполнения работ по автоматизации систем управления. Адаптация автоматизированной системы "1С: Предприятие 8" для ООО "СтройРемонтПодряд". Обследование ведения учета заработной платы и кадров. Оценка экономической эффективности проекта.
дипломная работа [2,9 M], добавлен 15.02.2017Обзор средств автоматизации торговли. Обзор состояния Интернет-торговли и роли в них аукционов. Описание процесса проектирования автоматизированной системы. Расчет экономической эффективности от внедрения программного продукта. Охрана труда работников.
дипломная работа [569,0 K], добавлен 09.09.2008Разработка автоматизированной системы управления процессом подогрева нефти в печах типа ПТБ-10 на примере установки подготовки нефти ЦПС Южно-Ягунского месторождения. Проектирование экранов человеко-машинного интерфейса в программной среде InTouch 9.0.
дипломная работа [3,1 M], добавлен 30.09.2013Разработка и реализация автоматизированной информационной системы "Трехмерная печать", предназначенной для организации заказов в филиале на производство трехмерных моделей. Системный анализ и анализ требований. Модели проектирования и реализации.
курсовая работа [889,8 K], добавлен 18.12.2010Разработка структурной схемы устройства управления учебным роботом. Выбор двигателя, микроконтроллера, микросхемы, интерфейса связи и стабилизатора. Расчет схемы электрической принципиальной. Разработка сборочного чертежа устройства и алгоритма программы.
курсовая работа [577,8 K], добавлен 24.06.2013