Определение требований к программным системам 6 2Проектирование систем 7




Скачать 229.22 Kb.
НазваниеОпределение требований к программным системам 6 2Проектирование систем 7
Дата конвертации31.12.2012
Размер229.22 Kb.
ТипРеферат
Содержание

Содержание 1

Введение 3

1Определение Требований 4

1.1Предметная область 4

1.2Постановка задачи 4

1.3Анализ предметной области 5

1.4Определение требований к программным системам 6

2Проектирование систем 7

2.1Анализ модифицируемой системы 7

2.2Выбор жизненного цикла разработки системы 8

2.3Выбор модели проектирования 12

2.4Решения по комплексу технических средств 14

2.5Выбор программных средств 16

18

2.6C# 3.5, ASP.NET 18

2.7MS SQL 2008 Express 19

3Архитектура разрабатываемых систем 21

3.1Описание и модель системы отчетности, общее описание принципов функционирования 21

3.2Описание модели взаимодействия системы методических пособий 23

4Описание интерфейса 24

4.1Интерфейс преподавателя 25

ЗАКЛЮЧЕНИЕ 27

ЛИТЕРАТУРА 28

БД — база данных

ВУЗ — высшее учебное заведение

Гб — гигабайт

ЖЦ — жизненный цикл

ИС — информационная система

Мб — мегабайт

ОС — операционная система

ОЗУ — оперативное запоминающее устройство (оперативная память)

ПО — программное обеспечение

ПЭВМ — персональная ЭВМ

СУБД — система управления базами данных

СПБГУАП – Санкт-Петербургский государственный университет аэрокосмического приборостроения

ТЗ — техническое задание

ЭВМ — электронная вычислительная машина


Введение

1Определение Требований




1.1Предметная область




Рассматриваемая предметная область – рейтинговая система оценки успеваемости студентов на кафедра СПБГУАП.

1.2Постановка задачи


В дипломной работе поставлена задача модифицировать, созданный ранее, проект и разработать:

  1. Систему отчетности успеваемости студентов, позволяющую:

  • Добавлять, удалять и редактировать сведения об успеваемости студентов

  • Распечатать ведомость об успеваемости

  • Обеспечить возможность экспорта данных в традиционные форматы

  1. Систему просмотра и редактирования данных о предметах, позволяющую:

  • хранить и редактировать данные о предметах (такие данные, как – список рекомендуемой литературы, методические пособия и т.д.)

  • просматривать данные о предметах на web-странице


Для выполнения поставленных задач необходимо:

  • Провести анализ созданного проекта

  • Определить программные средства для реализации создаваемых систем

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



1.3Анализ предметной области




На основе описания предметной области и поставленной задачи проводится анализ предметной области с целью выявления:

  • Пользователей системы

  • Недостатков системы и способов их устранения

  • Ограничений для разных групп пользователей


Из описания предметной области можно выделить несколько ролей для внешних пользователей системы:

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

  • Преподаватель – основное действующее лицо – занимается редактированием успеваемости студентов, их посещаемости занятий, редактированием данных о предмете.



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

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

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


1.4Определение требований к программным системам




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

Система отчетности должна быть:

  • универсальной,

  • простой в использовании,

  • наиболее подходящей для разработки в существующем проекте.

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

Разработка системы методических пособий по лабораторным работам должна заключаться в том, чтобы обеспечить возможность:

  • просмотра данных,

  • добавления методических пособий и дополнительных материалов,

  • удаления невостребованных данных.

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

Проектирование необходимых нам систем включает в себя следующие этапы:

  • Определение предметной области

  • Проектирование систем

  • Реализация систем



2Проектирование систем




2.1Анализ модифицируемой системы


Информационная система LabTracker позволила значительно увеличить качество и удобство ведения практических лабораторных занятий в рамках рейтинговой системой ВУЗа. В настоящее время в системе реализован web-интерфейс пользователей, разделенный на 2 группы: преподаватели и студенты.

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

Студенты имеют открытый доступ к данным. При аутентификации пользователя студент выбирает свою группу, имя пользователя (из списка группы) и вводит единый для них пароль – user. Ему выводится на странице баллы за лабораторные работы по тем дисциплинам, которые у него преподаются.

Единым представлением и для преподавателя, и для студента являются методические пособия. При нажатии на название лабораторной работы, открывается новая страница с 2 полями: Методические указания и Варианты. Эти данные невозможно просмотреть, находясь вне локальной сети на кафедре.

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

2.2Выбор жизненного цикла разработки системы



Одним из базовых понятий методологии проектирования информационных систем является понятие жизненного цикла ее программного обеспечения (ЖЦ ПО). ЖЦ ПО – это непрерывный процесс, который начинается с момента принятия решения о необходимости его создания и заканчивается в момент его полного изъятия из эксплуатации.

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

К настоящему времени наибольшее распространение получили следующие две основные модели ЖЦ:

  • каскадная модель (70-85 г.г.);

  • спиральная модель (86-90 г.г.).

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

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




image336

Рис. 1. Каскадная модель ЖЦ


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

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

Для преодоления перечисленных проблем была предложена спиральная модель ЖЦ (Рис.2), делающая упор на начальные этапы ЖЦ: анализ и проектирование. На этих этапах реализуемость технических решений проверяется путем создания прототипов. Каждый виток спирали соответствует созданию фрагмента или версии ПО, на нем уточняются цели и характеристики проекта, определяется его качество и планируются работы следующего витка спирали. Таким образом, углубляются и последовательно конкретизируются детали проекта, и в результате выбирается обоснованный вариант, который доводится до реализации.

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

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






Рис. 2. Спиральная модель ЖЦ



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

2.3Выбор модели проектирования



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

  • метод структурного проектирования сверху вниз;

  • метод потоков данных;

  • объектно-ориентированное проектирование.

В 60-70-е годы было разработано много методов, помогающих справится с растущей сложностью программ. Наибольшее распространение получило структурное проектирование по методу сверху вниз. Метод был непосредственно основан на топологии традиционных языков высоко уровня типа FORTRAN или COBOL. В этих языках основной базовой единицей является подпрограмма, и программа в целом принимает форму дерева, в котором одни подпрограммы в процессе работы вызывают другие подпрограммы. Структурное программирование использует именно такой подход: алгоритмическая декомпозиция применяется для разбиения большой задачи на более мелкие. Необходимо отметить, что большинство существующих программ написано, по-видимому, в соответствии с этим методом. Тем не менее, структурный подход не позволяет выделить абстракции и обеспечить ограничение доступа к данным; он также не предоставляет достаточных средств для организации параллелизма. Структурный подход не может обеспечить создание предельно сложных систем, и он, как правило, неэффективен в объектно-ориентированных языках программирования.//5

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

Объектно-ориентированное проектирование (object-oriented design, OOD) – это подход, в основу которого положено представление о том, что программную систему необходимо проектировать как совокупность взаимодействующих друг с другом объектов, рассматривая каждый объект как экземпляр определенного класса, причем классы образуют иерархию. Объектно-ориентированный подход отражает топологию языков высокого уровня, таких как Delphi, C++ и C#.

Общая концепция ИС предполагает реализацию совокупности объектов и их взаимодействие, поэтому реализацию системы было решено создавать на базе объектно-ориентированного подхода с применением языка высокого уровня C# 3.5.

2.4Решения по комплексу технических средств



Среди всего множества критериев отбора технических средств нас интересуют:

  • достаточный объем оперативного запоминающего устройства сервера;

  • достаточный объем накопителя на жестком магнитном диске сервера;

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

  • достаточная производительность центрального процессора сервера;

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

  • достаточная скорость передачи данных в локальной сети;

  • приемлемая стоимость составляющих комплекса технических средств.

Объем необходимого ОЗУ рассчитывается, исходя из размеров памяти, занимаемой загружаемой операционной системой, из необходимого объема памяти, выделяемого под драйверы для обслуживания ЭВМ, программы-оболочки, основного загружаемого модуля программного комплекса, динамических библиотек, подгружаемых по мере выполнения программы и резерва памяти для обработки информации.

Исходя из вышеизложенного, приходим, что для нормальной работы системы необходимо не менее 1024 Мбайт ОЗУ. По современным понятиям, это уже не слишком высокое требование объясняется тем, что для нормальной работы, выбранной в качестве рекомендуемой ОС системы Windows XP необходимо не менее 512 Мбайт оперативной памяти.

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

Предполагаемый срок службы техники – 5 лет. Так как 5 лет – средний срок полного морального устаревания парка машин и его замены.

Скорость передачи данных в ЛВС зависит от выбранного сетевого программного и технического обеспечения. Парк применяемых машин на предприятии заказчика оснащен Ethernet-адаптерами и прочими сетевыми устройствами со скоростью передачи данных 100Mбит/сек. Учитывая достаточность этой скорости для работы системы, принято решение использовать имеющиеся средства.

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


Сервер (минимальные требования):

  • процессор не хуже Pentium IV 1ГГц

  • объем ОЗУ не менее 1024 Мб

  • объем жесткого диска не менее 10 Гб (свободно не менее 1ГБ)

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

Клиент:

  • процессор не хуже Pentium II 400 МГц

  • объем ОЗУ не менее 256 Мб;

  • графический адаптер не хуже SVGA 8 Мб;

  • монитор не хуже SVGA 0.26, 15 дюймов

  • сетевая карта


2.5Выбор программных средств




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

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

При выборе средства программирования и генерации отчетов необходимо определить основные требования:

  • Удобство разработки / модификации – т.е. является ли генератор встроенным приложением или отдельным программным продуктом, требующим внедрения

  • Экспорт в различные форматы – позволяет расширить возможности отчетности

  • Печать отчетов

  • Стоимость – крайне важный параметр при ограниченном бюджете ВУЗа.

В таблице 1 дана сравнительная характеристика всех выбранных для анализа ИС.

Табличка будет!


При просмотре Таблицы 1 можно сделать вывод, что оптимальным программным средством для разрабатываемой системы отчетности является Microsoft Reporting Services. Данный компонент является встроенным в Visual Studio 2008, он поставляется в комплекте с SQL Server, который предоставлен в бесплатной Express-версии, соответственно тоже является бесплатным, он предоставляет возможность экспортирования данных в Excel и PDF, печать сформированных отчетов.

Reporting Services включает графическую оболочку для создания отчетов - Report Designer, которая использует интегрированную среду разработки Visual Studio .NET и позволяет обойтись без написания кода.

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

Report Wizard облегчает создание отчета. Отчет с загруженными в него данными можно просмотреть предварительно, а как только он будет готов, Report Designer опубликует его на сервере отчетов посредством Reporting Services SOAP API.

Reporting Services для формирования отчета использует отраслевой XML-стандарт - Report Definition Language (RDL), который помимо удобства передачи данных обеспечивает совместимость с различными инструментами третьих фирм.

Исходные данные могут извлекаться из широкого спектра источников, в том числе реляционных, иерархических и многомерных БД. Напрямую поддерживаются MS SQL Server 2005 и SQL Server 7.0, Oracle, OLE DB-совместимые источники данных, включая Analysis Services, а также ODBC. Возможно подключение и других источников данных через открытый набор API на базе .NET. //7

В процессе выбора модели проектирования был выбран объектно-ориентированный подход и язык программирования C# 3.5 и следующие средства:

  • СУБД – MS SQL Server 2008 Express

  • IDE – MS Visual Studio 2008 Express


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

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

AJAX

ASP.NET

LINQ

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

2.6C# 3.5, ASP.NET




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

  • В качестве языка программирования для разработки системы может использоваться язык C# 3.5, который был выбран при выборе модели проектирования

  • Полная интеграция с СУБД MS SQL Server 2008

  • Полная поддержка спецификации IE 7.0, как наиболее используемого веб-браузера.

Язык C# 3.5 был выбран как наиболее подходящий для разработки в связи с выбором объектно-ориентированного подхода к проектированию системы и позволяющий, использовать все возможности .NET Framework, ASP.NET и LINQ , фактически являясь частью этих технологий.

2.7MS SQL 2008 Express




Microsoft SQL Server в качестве языка запросов использует версию SQL, получившую название Transact-SQL (сокращённо T-SQL), являющуюся реализацией SQL-92 (стандарт ISO для SQL) с множественными расширениями. T-SQL позволяет использовать дополнительный синтаксис для хранимых процедур и обеспечивает поддержку транзакций (взаимодействие базы данных с управляющим приложением). Microsoft SQL Server и Sybase ASE для взаимодействия с сетью используют протокол уровня приложения под названием Tabular Data Stream (TDS, протокол передачи табличных данных). Протокол TDS также был реализован в проекте FreeTDS, с целью обеспечить различным приложениям возможность взаимодействия с базами данных Microsoft SQL Server и Sybase.

SQL Server поддерживает зеркалирование и кластеризацию баз данных. Кластер сервера SQL — это совокупность одинаково конфигурированных серверов; такая схема помогает распределить рабочую нагрузку между несколькими серверами. Все сервера имеют одно виртуальное имя, и данные распределяются по IP адресам машин кластера в течение рабочего цикла. Также в случае отказа или сбоя на одном из серверов кластера доступен автоматический перенос нагрузки на другой сервер.

Основаниями для выбора стали следующие свойства SQL Server 2008:

  • Бесплатность SQL Server 2008 Express

  • Полная поддержка .NET Framework

  • Полная интеграция с используемой средой разработки MS Visual Studio 2008

3Архитектура разрабатываемых систем




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




Существующая система разработана с использованием архитектуры клиент-сервер (рис. 3), когда между клиентом и ядром системы присутствуют посредники в виде веб-браузера и веб-сервера.







Рис.3. Архитектура системы

Разрабатываемая система отчетности должна удовлетворять данным требованиям. Создаваемая система взаимодействует с БД при помощи запросов, написанных на языке C# с использованием LINQ. Основой взаимодействия между системой и БД являются хранимые процедуры, написанные на языке SQL.

Для простоты использования и повышения защищенности приложения основные интерфейсы и сервисы взаимодействия между системой и БД вынесены в отдельную сборку LabTracker.Framework.dll.

Использование Microsoft Reporting Services предполагает работу с простыми типами данных, но информация необходимая для отчетов находится в классах. Поэтому нужно было перевести данные в простые типы. Для этого были написаны дополнительные функции MapDiscipline и MapScore, которые позволили использовать выбранные данные для отчетов. Количество лабораторных работ устанавливается автоматически при проверке ID дисциплины. Список студентов получается тоже автоматически при вводе ID группы и ID дисциплины и записывается в соответствующую графу. Также в отчете использованы такие поля как Bonus, SummaryScore, LabName и MaxBalls.

Для того чтобы отчет был универсальным необходимо было сделать передаваемыми параметрами название дисциплины, группу, фамилию преподавателя, количество лабораторных работ и их названия. Эти параметры были включены в класс ReportParameter, который является встроенным в Microsoft Reporting Services и позволяет их использовать вне описанной внутренней структуры.

Процесс создания отчета происходит в дизайнере Microsoft Reporting Services (Рис.4) – данный продукт поддерживает следующие основные типы отчетов:

  • табличный - фиксированное количество столбцов;

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

  • графический - данные представлены графически;

  • свободная форма - данные на странице организованы в произвольном виде.



Рис.4. Дизайнер Microsoft Reporting Services

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

Готовый отчет (Рис.5), например группы 4736 по ООП, можно увидеть в Internet Explorer, при нажатии на кнопку «Экспорт», и его можно распечатать.


Рис.5. Вид готового отчета


3.2Описание модели взаимодействия системы методических пособий


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

labworkinfo

Рис.6. Информация о лабораторной работе

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

Добавление и удаление файлов разрешено только преподавателям, у студентов такой панели не существует, на нее поставлено условие в зависимости от авторизации пользователя. Также стоят условия на добавление файлов. Невозможно добавить пустой файл и файл без названия (описания).

Файлы представлены в списке (Рис.7), позволяющем просмотреть методическое пособие в окне браузера или загрузить к себе на компьютер.


Рис.7. Список методических пособий


4Описание интерфейса




4.1Интерфейс преподавателя




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

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



Вид страницы выставления оценок

main

Рис 24



Вид страницы редактирования посещения студентов

teacherattendance3

Рис 25










ЗАКЛЮЧЕНИЕ




ЛИТЕРАТУРА




  1. Э. Гамма, Р. Хелм, Р. Джонсон, Д. Влиссидес - Gang of Four, Приемы объектно-ориентированного проектирования, паттерны проектирования – издательство Питер, 2007;

  2. Мартин Фаулер, Рефакторинг, улучшение существующего кода – издательство Символ-Плюс, 2007;

  3. http://www.studfiles.ru/dir/cat32/subj1340/file14246/view142176.html;

  4. Эрик Аллен, Типичные ошибки проектирования – издательство Питер, 2003;

  5. http://www.helloworld.ru/texts/comp/other/oop/ch01.htm;

  6. Дж. Рамбо, М. Блаха, UML 2.0, объектно-ориентированное моделирование и разработка – 2е издание, издательство Питер, 2007.

  7. Д. Крёнке, Теория и практика построения баз данных – издательство Питер, 2005;

  8. Ричард Веймаер, Microsoft SQL Server 2000 – издательский дом Вильямс, 2001.

  9. http://www.interface.ru/home.asp?artId=968;

  10. Г. Шилдт, C# - учебный курс - издательство Питер, 2003;

  11. Джеффри Рихтер, CLR via C#: программирование на платформе .NET 2.0 на языке C# – издательство Питер, 2007;

  12. Мэтью Мак-Дональд, Марио Шпушта, Microsoft ASP.NET 2.0 с примерами на C# 2005 для профессионалов – издательский дом Вильямс, 2006;

  13. Дино Эспозито, Знакомство с ASP.NET 2.0 – издательство Питер, 2006;

  14. Дино Эспозито, ASP.NET 2.0 углубленное изучение – издательство Питер, 2007;

  15. О.Н. Рева, JavaScript – издательство Эксмо, 2007.

  16. Shakhgeldyan C., Kryukov V. Integration of University Information Resources into the Unified Information Environment // Proceedings of the 10-th International Conference of European University Information Systems . Slovenia, 2004.

  17. “СанПиН 2.2.2.542-96. Гигиенические требования к видеодисплейным терминалам, персональным электронно-вычислительным машинам и организации работы”, Госкомсанэпиднадзор России, 1996, 43 с.






Добавить в свой блог или на сайт

Похожие:

Определение требований к программным системам 6 2Проектирование систем 7 iconОпределение эффективности тонкопленочных теплоизоляционных покрытий применительно к системам теплоснабжения
...

Определение требований к программным системам 6 2Проектирование систем 7 icon4 определение расчётных расходов воды и стоков
Дополнительные требования к системам внутренней канализации и водостокам в особых природных и климатических условиях

Определение требований к программным системам 6 2Проектирование систем 7 iconСистема стандартов безопасности труда
Стандарт не устанавливает требований к вентиляционным системам подземных и открытых горных выработок, метрополитенов, транспортных...

Определение требований к программным системам 6 2Проектирование систем 7 iconВопросы вступительного экзамена по специальной дисциплине
Основные положения теории систем. Определение системы. Свойства системы. Классификация систем. Модели экономических систем

Определение требований к программным системам 6 2Проектирование систем 7 iconКомментарии к Таблицам конкурентных преимуществ систем измерения уровня
Ниже приводятся правильные данные по системам струна для сравнительных таблиц. Просим обратить внимание на комментарии и неточности...

Определение требований к программным системам 6 2Проектирование систем 7 iconТребования к работе!
...

Определение требований к программным системам 6 2Проектирование систем 7 iconСтатья Применение кольцевых теплонасосных систем
В. Е. Шабанов, инженер по системам овк и автоматики гостиницы «Ирис Конгресс Отель»

Определение требований к программным системам 6 2Проектирование систем 7 iconУстройство систем распределенного
Комитетом по системам инженерно-технического обеспечения зданий и сооружений Национального объединения строителей, протокол от 18....

Определение требований к программным системам 6 2Проектирование систем 7 iconСвод правил по проектированию и строительству сп 31-106-2002
Выполнение этих рекомендаций обеспечит соблюдение обязательных требований по инженерным системам жилых домов, установленных сниП...

Определение требований к программным системам 6 2Проектирование систем 7 iconСвод правил по проектированию и строительству сп 31-106-2002
Выполнение этих рекомендаций обеспечит соблюдение обязательных требований по инженерным системам жилых домов, установленных сниП...


Разместите кнопку на своём сайте:
lib.convdocs.org


База данных защищена авторским правом ©lib.convdocs.org 2012
обратиться к администрации
lib.convdocs.org
Главная страница