Функционирование автовокзала

1 2

---

Содержание

  Введение 3

1. Аналитическая часть 5

1.1 Описание предметной области 5 1.2 Техническое задание 11 2 Проектная часть 18 2.1 Информационное обеспечение 18 2.2 Инструменты разработки 29 2.3 Описание интерфейса приложения 31 2.4 Руководство пользователя 41 Заключение 45 Список литературы 47 Приложение А 51 Приложение Б 55      

Введение

Проблема обработки потока пассажиров на любом виде транспорта всегда имела существенную роль. Расчет мест, маршрутов, огромное число пассажиров, огромное число билетов, которое нужно учитывать, обязательно где-то хранить и своевременно обновлять. Все это требует большого количества бумаг, времени и денег. Это особенно касается автомобильного вида транспорта, то тут проблема разворачивается более остро, так как основным типом транспорта дальнего следования в Мире и в России соответственно остаются автобусы. Для учета времени движения автобусов, которое изменяется, к сожалению ,каждую неделю, требуется немало времени и большой, просто огромного, объем носителя информации. Значит, таким образом, встает остро вопрос о проектировании новой системы, которая улучшит и упростить работу кассиров, поможет допускать намного меньше ошибок при выдачи билетов, и вообще поможет избежать многих неточностей. При таких сложных условиях необходимо четка просчитать слаженную, согласованную работу касс автовокзалов на высоком уровне: автоматизировать потоки, связанные с денежной стороной вопроса (продажа билетов), использовать простые, качественные, удобные для людей и кассиров формы и виды представления информации. Для этого для сотрудников касс разрабатываются специальные системы управления – базы данных, в которых хранится вся информация о автотранспорте, водителях, маршрутах, билетах. Важнейшей задачей проектирования ИС часто являются не столько вычисления, сколько процессы сбора, обмена, хранения, организации и распространения информации. Применение компьютерных технологий для построения типизированных систем переработки данных показывает, что самым эффективным и качественным инструментом здесь являются не стандартные алгоритмические языки высокого уровня, а специализированные языки для создания систем управления данными. Цель курсовой работы — приобретение практических навыков анализа и моделирования предметной области, разработки концептуальной модели ИС «Функционирование автовокзала«. Использованием IDEF0 диаграммы, отражающие функциональность, логическую структуру и динамические характеристики проектируемой ИС. Для достижения цели необходимо решить ряд задач:

1. сформулировать задачу проекта;
2. исследовать предметную область;
3. произвести бизнес-моделирование предметной области;
4. спроектировать статические модели предметной области;
5. спроектировать динамические модели
6. спроектировать логическую модель данных;
7. спроектировать физическую модель данных;
8. реализовать пользовательское приложение.

Для разработки и реализации системы управления базой данных применяются приложения Windows, такие как: StartUML, BPwin, Rational Rose 2003 среда Microsoft SQL SERVER и объектном- ориентированного программирования Visio Studio 2012 Windows Form.  

Аналитическая часть

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

Анализ предметной области, является одним из важнейших этапов проекта, разработки автоматизированной системы, целью которого является выявление, классификация и формализация информации обо всех аспектах предметной области, влияющих на конечный результат. Проведем предварительный анализ предметной области проектирования разрабатываемой системы. Акционерное общество «Автовокзал» являясь крупнейшим предприятием в сфере автоперевозок в России, ОАО «Автовокзал» имеет в своём составе более 100 автовокзалов и автостанций, расположенных по всей территории России . Об объёмах работы предприятия можно судить и по состоянию маршрутной сети. Каждый день от перронов автовокзалов, принадлежащих объединению, отправляются более 18000 рейсов по 3740 маршрутам. Основным направлением деятельности компании является перевозка пассажиров. Пассажирские перевозки осуществляются как в города России, так и по территории других стран. С автовокзалов предприятия прямым сообщением отправляются автобусы, следующие по маршрутам в города Германии, Болгарии, Украины, страны Закавказья и республики Северного Кавказа, в населённые пункты Краснодарского и Ставропольского краёв, Воронежской, Волгоградской и Астраханской областей. Организационная структура компании изображена в соответствии с рисунком 1   Рисунок 1 — Организационная структура компании Как видно из организационной структуры компании, представленной на рисунке 1, действующими лицами деятельности автовокзала являются следующие субъекты:

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

Таблицу функций, субъектов деятельности, продемонстрируем при помощи таблицы1.   Таблица 1 — Таблица функций программного приложения.

Кассир	Продажа билета – получает информацию, выдает билеты, принимает возврат билета, выдает необходимую информацию Регистрирует в БД продажу билета и возврат билета Отчет в конце рабочего дня
Администратор	Организация работ кассира Контроль времени работы кассы Проверяем отчёт Создает справочники
Сотрудник и справочная служба	Дает справки о отправлении и приходе автобусов
Начальник сектора кассового обслуживания	Руководство деятельностью отдела Организация кассовой работы в филиале и его точках продаж Организация работы с денежными знаками с радиоактивным загрязнением

Далее представим предметную область в виде диаграммы IDEF0 автоматизируемого процесса. Рассмотрим, как протекает процесс деятельности автовокзала в настоящее время. Моделирование деятельности автовокзала представлено в методологии IDEF0 диаграмм. Основной деятельность автовокзала является оказание услуг по перевозки пассажиров. На рисунку 2 представлено функциональное моделирование деятельности автовокзала. Рисунок 2 — Контекстная диаграмма процесса функционирования автовокзала. Модель AS-IS Главный функциональный блок декомпозируется для более подробного рассмотрения деятельности автовокзала. На рисунке 3 представим декомпозицию контекстной диаграммы представленной на рисунке 2. Рисунок 3 — Декомпозиция первого рода основного процесса «Деятельность автовокзала»   Как видно на данной диаграмме основной процесс разбивается на три под процесса:

• создание справочников;
• учет продаж билетов;
• создание отчетов.

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

• Обеспечения сбора, первичной обработки и сохранения в системе информации об транспорте, водителях, маршрутах и билетах.
• Автоматизированного проведения расчетов выручки, цены билета и штрафов.
• Создания системы формирования отчетов и статистики.
• Повышения качества (полноты, точности, достоверности, своевременности, согласованности) информации.

Создание и внедрение информационной системы позволит:

1. Ускорить процесс обработки входящих заявок на билеты.
2. Снизить трудоемкость операций.
3. Сократить процент ошибок, вызванных человеческим фактором.
4. Снизить вероятность потери данных или путаницы в них, за счет структурирования данных в информационной системе.

 

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

  В рамках постановки задачи данной курсовой работы представим развернутое техническое задание на программный продукт: Наименование программного изделия Полное наименование программной разработки: ИС «Автовокзал»,  в дальнейшем именуемая как «Программа». Краткое название программы – ИС «Автовокзал». Применения Программа ИС«Автовокзал» предназначена для обработки и хранения данных необходимых для полного функционирования автовокзала. Может устанавливаться на всех ПК каждого автовокзала РФ .   Документ, на основании которого ведётся разработка Работа ведётся на основании задания на курсовое проектирование Назначение Целью текущей курсовой работы является проектирование и разработка информационной системы для автовокзала. Внедрение данной информационный системы значительно облегчает, улучшает и совершенствует ведение данных об водителях, транспортах, маршрутах и проданных билетах. В рамках курсовой  работы необходимо создать программный продукт, который будет реализовывать функционал современного автовокзала. Данное приложение очень актуально, так как позволяет систематизировать и собрать в себе всю информацию по данной теме, и далее, что очень важно, выдать эту информацию пользователю в нужном формате. Программный продукт новый, не имеет аналогов, очень эффективный, может применятся немедленно, кроме этого вполне подвержен модернизации, что увеличивает его привлекательность. Приложение простое и имеет интуитивно понятный интерфейс. Состав выполняемых функций Программа должна обеспечивать возможность выполнения перечисленных ниже свойств:

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

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

• Добавление, удаление и обновление информации об маршрутах;
• Добавление, удаление и обновление информации об пунктах маршрута;
• Добавление, удаление и обновление информации об проданных билетах;
• Добавление, удаление и обновление информации об водителях;
• Добавление, удаление и обновление информации об транспортах автовокзала;
• Добавление, удаление и обновление информации об выручке маршрута и штрафах водителя;
• Поиск билетов;
• Поиск водителей;
• Поиск транспорта;
• Поиск маршрута по водителю;
• Поиск маршрута по транспорту;
• Поиск маршрута по дате;
• Отчет маршрутов по водителю;
• Отчет маршрута по транспорту;
• Отчет маршрута по выручке;
• Отчеты маршрутов по датам;
• Авторизация;
• Вывод отчета в Exel документ.

Ожидаемый результат:

• Спроектированная и реализованная база данных;
• Программа реализующая основной функционал компании.

Организация входных и выходных данных В процессе работы программы входной информацией для программы должны являться: информация об водителях, транспортах, маршрутах и проданных билетах . В процессе работы программы выходной информацией для программы должны являться: информация о билетах и маршрутах выданная в подготовленном виде. Временные характеристики, и размер занимаемой памяти Время реакции программы на нажатие любой из клавиш и манипуляции мышью не должно превышать 0,25 с, в случае соответствия системных ресурсов требованию к составу и параметрам технических средств. Реакция на команды меню, кроме Открытия, Сохранения, Поиска не должна превышать 2 с. Реакция на команды Открытия, Сохранения, Поиска зависит от размера файла данных и настроек поиска. Объем занимаемой оперативной памяти не должен превышать 8 Мбайт. Требования к надежному функционированию Программа должна нормально функционировать при бесперебойной работе  ЭВМ. При возникновении сбоя в работе аппаратуры, восстановление нормальной работы программы должно производиться после: перезагрузки операционной системы; запуска исполняемого файла программы; повторного выполнения действий, потерянных до последнего сохранения информации в файл на магнитном диске. Уровень надежности программы должен соответствовать технологии программирования, предусматривающей: инспекцию исходных текстов программы; автономное тестирование модулей (методов) программы; тестирование сопряжении модулей (методов) программы; комплексное тестирование программы Контроль входной и выходной информации Программа должна контролировать выбор пользователя пункта меню «Выход» и предупреждать его о потере «не сохраненных изменений». Время восстановления после отказа Время восстановления после отказа должно состоять из: времени перезапуска пользователем операционной системы; времени запуска пользователем исполняемого файла программы; времени повторного ввода потерянных данных. Условия эксплуатации Программа должна храниться в виде двух маркированных дискетных копий — эталонной и рабочей. Периодическая перезапись информации должна осуществляться согласно нанесенной маркировке. Условия хранения дискет должны соответствовать нанесенной на них маркировке. Требования к составу и параметрам технических средств Рекомендуемая конфигурация ПК:

• Операционная система: Windows 7/8/8.1/10;
• Процессор: Intel Core i3/ AMD FX 4330 или мощнее;
• Видеокарта: AMD Radeon 1Gb/ nVidea GeForse 640 1Gb или мощнее;
• Оперативная память: 1Gb  DDR3 RAM и более;
• Жесткий диск: 100Mb свободного места;
• Разрешение экрана: 1920X1080, 32 бит;
• Звуковая карта: совместимая с DirectX 9.0
• Другие устройства: клавиатура, мышь;

Необходимые программные компоненты: Библиотека Microsoft. NET Framework 4.5 Требования к языкам программирования Разработка программы должна вестись на одном из следующих языков:

• Microsoft Visual Basic v5.0 и выше.
• Microsoft Visual C v5.0 и выше.
• Borland Delphi v4.0 ив выше.
• Microsoft Visio Studio 2012 и выше

Выбор других языков нецелесообразен. Требования к программным средствам, используемым программой Для работы программы необходима операционная система WINDOWS 7 и более поздняя, драйвера мыши и принтера. Требования к программной документации Состав программной документации должен включать следующие документы: Инструкцию по эксплуатации программного средства Стадии и этапы разработки Разработка программы должна выполняться по следующим этапам: 1) разработка, согласование и утверждение технического проекта программы с пояснительной запиской — 5 недель; 2) разработка рабочего проекта программы с комплексным тестированием — 6 недель; 3) приемка-сдача с исправлением обнаруженных недостатков в программе и программной документации — 2 недели. 4)внедрение. Виды испытаний Проверка документации программы осуществляется самим заказчиком с привлечением сторонних экспертов, способных засвидетельствовать факт соответствия созданного программного продукта всем пунктам технической документации, включая техническое задание и технический проект. Испытания и тестирование программы должны проводиться в процессе создания программы самим разработчиком:

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

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

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

   

2 Проектная часть

2.1 Информационное обеспечение

Проанализируем задачи работы. При более подробном рассмотрении поставленных задач, можно весьма ответственно утверждать, что такую задачу не решить без использования хранилища данных. Любая программа, написанная на языке программирования высокого уровня, а у нас именно так, язык программирования С#, для решения такого рода задач, нужно где-то хранить данные, информацию, в нашем случае, информацию про маршруты и проданные на них билеты. Кроме этого ее нужно обрабатывать. Решать такие задачи целесообразно и удобно используя БД. Для качественной работы в программе предусмотрено подключение к такой базе. Имеется в виду, что нужно создать базу данных. Под базой данных будем понимать такую базу данных, которая создана средствами других СУБД (например ACCESS2007 или БД SQL на сервере), а не возможностями самого языка программирования(например хранить данные в массивах). Язык программирования используется только для связи с СУБД и обработки данных. Кроме этого БД более эффективно поможет осуществить реализацию функционала программного комплекса. Цели создания внешней БД:

• Структурированность необходимых данных;
• Наличие взаимосвязи данных (Связи в БД);
• Представление внешних данных в виде моделей данных для дальнейшего целенаправленного их использования;

База данных позволит уже рассмотреть первичный вариант проекта, что позволит рассмотреть и оценить несколько важных характеристик будущего проекта, например, это может быть, производительность системы. Во время создания внешней БД создаются один за одним две модели БД. Имеется в виду логическая и физическая модель БД. ER — модель базы данных представим на рисунке 5. Рисунок 5 — ER модель БД Логический уровень — это абстрактный вид данных. В этой модели данные представляются так, как это понимает и видит человек, со своими понятиями структурирования и названий данных, как в реальном мире. Такая модель данных делит поступившие данные на сущности. Логическую модель БД представим на рисунке 6. Рисунок 6 — Логическая модель БД Далее на основании логической модели и при помощи СУБД строится таблицы физической (реляционной) БД. В нашем случае физическая модель БД состоит из  5 таблиц: маршрут, транспорт, водитель, билет, пункты маршрута. Для проектирования базы данных по заданию «ИС Автовокзал»  использовалось My SQL Serwer . При помощи функционала данной СУБД и на основании поставленных требований была разработана БД «BD.mdf». В составе данной БД таблицы маршрут, транспорт, водитель, билет, пункты маршрута.. Физическую модель БД представим на рисунке 7. Рисунок 7 — физическая модель БД В результате анализа были выделены 5 объектов, которые описывают данную предметную область. Это: — сущность “Маршрут”, атрибутами которой являются ID_ маршрута, ID_ водителя, ID_ транспорта,  начало и конец маршрута, дата, время и время пути маршрута, штраф и выручка маршрута. Данная сущность включает в себя основные сведения об маршрутах автовокзала. В качестве ключевого атрибута выбран ID_ маршрута. Данный атрибут является инверсным входом и он обязателен. В качестве внешнего ключа здесь выступают регистрационной номер водителя для связи с сущностью «Водители», регистрационной номер транспорта для связи с сущностью «Транспорт». — сущность “Водители” содержит следующие атрибуты: регистрационной номер водителя,  имя фамилия и отчество водителя, стаж, год рождения, класс и категория водителя. Ключевым атрибутом является ID_ водителя. Данный атрибут является инверсным входом и он обязателен.. — сущность “Пункты маршрута”, атрибутами которой являются ID_пункта, ID_ маршрута, название пункта. Данная сущность включает в себя основные сведения о пуктах маршрута. В качестве ключевого атрибута выбран ID_ пункта. Данный атрибут является инверсным входом и он обязателен. — сущность “Билет”, атрибутами которой являются ID_билета, ID_ маршрута, начало и конец движения, места, стоимость, места продажи. Данная сущность включает в себя основные сведения о билете на проезд. В качестве ключевого атрибута выбран ID_ билета. Данный атрибут является инверсным входом и он обязателен. — сущность “Транспорт”, атрибутами которой являются ID_ транспорта, марка, модель, количество мест, год выпуска, год ремонта, пробег. Данная сущность включает в себя основные сведения об транспорте данного автовокзала. В качестве ключевого атрибута выбран ID_ транспорта. Данный атрибут является инверсным входом и он обязателен. Между объектами предметной области существуют связи, которые должны быть отражены в виде связей между объектами инфологической модели. Графически связь обозначается линией, соединяющей связываемые объекты. Связь снабжается алфавитно-цифровым идентификатором. В каждом направлении связи можно выделить главный объект, от которого идет связь, и подчиненный. Различают идентифицирующую связь и не идентифицирующую связь. При установлении не идентифицирующей связи дочерняя сущность остается независимой. Экземпляр сущности родителя может существовать безотносительно к какому-либо экземпляру  дочерней сущности. Идентифицирующей является связь между двумя сущностями, в которой каждый экземпляр подчиненной сущности идентифицируется значениями атрибутов родительской сущности. Это означает, что экземпляр подчиненной сущности зависит от родительской сущности и не может существовать без экземпляра родительской сущности. При проектирование была проведена нормализация отношений до третьей нормальной формы, т.е. были устранены не ключевые столбцы, не зависящие от ключа. Таким образом, все не ключевые атрибуты функционально полно зависят от ключа и отсутствуют транзитивные зависимости. Связи между сущностями представлены в таблице 1. Таблица 1 – Структура связей

Сущность-родитель	Сущность-потомок	Мощность связи	Тип связи
Водители	Маршрут	Один ко многим	Идентифицирующая
Транспорт	Маршрут	Один ко многим	Идентифицирующая
Маршрут	Билеты	Один к одному	Идентифицирующая
Маршрут	Пункты	Один ко многим	Идентифицирующая

  На основании логического проектирования были созданы 5 таблиц, которые описаны в таблицах 2 — 6.         Описание атрибутов сущности «Маршрут» представлено в таблице 2. Таблица 2 – Описание атрибутов сущности «Маршрут»

Номер	Поле	Тип поля	Размер поля	Ключевые параметры
1	2	3	4	5
1	ID_mar	int		PK
2	Id_vad	int		FK
3	Id_avto	int		FK
4	Nach	Varchar()	20
5	Con	Varchar()	20
6	Data	DataTime
7	T	Varchar()	20
8	Tr	Varchar()	20
9	Dengi	Varchar()	20
10	Straf	Varchar()	20

Описание атрибутов сущности «Билет» представлено в таблице 3. Таблица 3 – Описание атрибутов сущности «Билет»

Номер	Поле	Тип поля	Размер поля	Ключевые параметры
1	2	3	4	5
1	ID_bilet	int		PK
2	ID_ mar	int		FK
4	Nac	Varchar()	20
5	Kon	Varchar()	20
6	N	int
7	Mesta	Varchar()	20
8	Dengi	Varchar()	20

Описание атрибутов сущности «Пункты» представлено в таблице 4. Таблица 4 – Описание атрибутов сущности «Пункты»

Номер	Поле	Тип поля	Размер поля	Ключевые параметры
1	2	3	4	5
1	ID_punkt	int		PK
2	ID_ mar	int		FK
3	Name	Varchar()	20

Описание атрибутов сущности «Транспорт» представлено в таблице 5. Таблица 5 – Описание атрибутов сущности «Транспорт»

Номер	Поле	Тип поля	Размер поля	Ключевые параметры
1	2	3	4	5
1	ID_avto	int		PK
2	Marka	Varchar()	20
3	Model	Varchar()	20
4	Kol	int
5	God_v	int
6	God_r	int
7	Probeg	int

Описание атрибутов сущности «Водители» представлено в таблице 6. Таблица 6 – Описание атрибутов сущности «Водители»

Номер	Поле	Тип поля	Размер поля	Ключевые параметры
1	2	3	4	5
1	ID_vad	int		PK
2	LastName	Varchar()	20
3	FirstName	Varchar()	20
4	MiddleName	Varchar()	20
5	Experiense	int
6	Year	int
7	Category	Varchar()	20
8	Class	Varchar()	20

          Модель реальной базы данных на Microsoft SQL Server представлена на рисунке 8. Рисунок 8 — Модель БД проекта Нормализация предусматривает определение требуемых атрибутов с последующим созданием из них нормализованных таблиц, основанных на функциональных зависимостях между этими атрибутами. Отношение, в котором на пересечении каждой строки и каждого столбца содержится атомарное (или единственное) значение, находится в 1НФ. При этом необходимо, чтобы отношение имело первичный ключ. Вторая нормальная форма применяется к отношениям с составными ключами, т.е. к таким отношениям, первичный ключ которых состоит из двух или больше атрибутов. Отношение с первичным ключом на основе единственного атрибута всегда находится в 2НФ. Отношение, которое находится в 1НФ и каждый атрибут которого, не входящий в состав первичного ключа, зависит только от полного значения ключа и не зависит ни от какого отдельного атрибута, входящего в состав первичного ключа, имеет вторую нормальную форму (каждый неключевой атрибут функционально полно зависит от ключа). Отношение находится в 3НФ, если оно представлено в 2НФ и не имеет не входящих в первичный ключ атрибутов, которые находились бы в транзитивной функциональной зависимости от этого первичного ключа. Разработанная модель находится в третьей нормальной форме т.к.: — атрибуты сущностей являются атомарными; — каждый неключевой атрибут функционально полно зависит от первичного ключа; — в модели отсутствуют транзитивные зависимости неключевых атрибутов от ключа. Созданная БД полностью замкнутая и обеспечивает полное функционирования данного приложения. Данная БД является внешней по отношению к программной оболочке, к интерфейсу, разработанному на языке программирования С# и технологии Windows Forms.

2.2 Инструменты разработки

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

• Язык программирования C#;
• Платформа разработки Visio Studio;
• СУБД Microsoft SQL Server 2008 R2.

Приведем обоснование выбора данных средств разработки. Рассмотрим Сервер  MySQL. Производитель компания Microsoft.  В текущий момент  является одной из ведущих систем обработки данным в мире. Является современным программным продуктом. Постоянно обновляется и совершенствуется. Основные плюсы такой СУБД:

• Простата;
• Удобство;
• Простой и интуитивно понятный интерфейс;
• Огромные функциональные возможности;
• Компактность данных. Данные располагаются в таблицах, которые в сваю очередь занимают только один файл;
• Огромное количество подсказок и мастеров, которые выполняют работа всю практически за вас;
• Распростроняемость;
• Обновляемость;
• Совместимость с ОС Windows;
• Импорт и экспорт необходимых данных;
• Наличие необходимых микрокоманд.

Недостатки:

• Слабо развита возможность многопользовательского режима;
• Слабо развита защита данных.

Проанализировав все плюсы и минусы, для выполнения данной работы была выбрана Microsoft SQL Server 2008 R2. Анализ и выбор языка программирования В качестве языка программирования выберем язык высокого уровня  С#. С# — язык программирования высокого уровня. Объектно-ориентируемый язык. День рождения данного языка можно считать 1998 год. Данный язык программирования был создан разработчиками компании Microsoft, как основной подход для программирования программных комплексов под ОС Windows. Имеет синтаксис подобный на другие языки высокого уровня с++ и java.  Данный язык входит в основу таких платформ разработки приложений как Windows Form, ASP. Net MVC, XAMARIN. Последнее кстати, много — обесчающая и быстро развивающаяся технология проектирования приложений для мобильных устройств. Достоинства языка  программирования:

• Ярко выраженный объектное — ориентируемый подход;
• Гибкость программного кода;
• Переносимость программного кода;
• Простата повторного использования готовых программных наработок;
• Безопасность разработанного кода;
• Унифицированная система типизации;

Недостатки:

• Трудный и своеобразный синтаксис программного кода;
• Мало новых, своих, идей;
• Медленный, по сравнению с другими языками высокого уровня;
• Не кросс — платформенный язык.

---

1 2