АИС управления серверным программным обеспечением на базе программного комплекса Webmin/Alterator
Порядок создания автоматизированной информационной системы (АИС) для Министерства промышленной политики, транспорта и связи Омской области на базе Webmin/Alterator. Руководство пользователя Webmin. Оценка затрат труда на разработку программного продукта.
Рубрика | Программирование, компьютеры и кибернетика |
Вид | дипломная работа |
Язык | русский |
Дата добавления | 10.07.2010 |
Размер файла | 767,6 K |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Государственное образовательное учреждение высшего профессионального образования
«Сибирская государственная автомобильно-дорожная академия (СибАДИ)»
Факультет Информационные системы в управлении
Специальность Автоматизированные системы обработки информации и управления
Кафедра Компьютерные информационные автоматизированные системы
ПОЯСНИТЕЛЬНАЯ ЗАПИСКА
к дипломному проекту
Обозначение проекта ДП-02068982-230102-14-10
Тема проекта АИС управления серверным программным обеспечением на базе программного комплекса Webmin/Alterator
Студент группы АС-05И1
Майненгер Иван Геннадьевич
Омск 2010
Государственное образовательное учреждение высшего профессионального образования
«Сибирская государственная автомобильно-дорожная академия (СибАДИ)»
Кафедра Компьютерные информационные автоматизированные системы
УТВЕРЖДАЮ
Зав кафедрой КИАС
__________________ / С.Н. Чуканов/
«___» ___________20___г.
Задание
К дипломному проекту (работе) студенту гр. АС05И1
Майненгер Ивану Геннадьевичу
1 Тема работы: АИС управления серверным программным обеспечением на базе программного комплекса Webmin/Alterator
Утверждена приказом по СибАДИ № П-10-95/СТ от «29» марта 2010г.
2 Исходные данные к работе: результаты преддипломной практики результаты анализа литературы и интернет - источников.
3 Содержание пояснительной записки (конкретный перечень подлежащих разработке вопросов):
Введение
3.1 Анализ объекта автоматизации
3.2 Постановка задачи
3.3 Анализ алгоритмов
3.4 Руководство по эксплуатации
3.5 Экономическое обоснование проекта
3.6 Безопасность жизнедеятельности
Заключение
Список использованных источников
4 Перечень демонстрационного материала для сопровождения доклада в ГАК:
- демонстрационный плакат
- демонстрационная версия разработанной системы
5 Консультанты по разделам работы:
5.1 Экономический раздел - доцент, к.э.н. Сухарева Светлана Витальевна
5.2 Безопасность жизнедеятельности - доцент, к.т.н. Бедрина Елена Анатольевна
6 Назначенный кафедрой рецензент работы:
Задание выдано “____” __________ 20___г.
Руководитель работы ___________________ к.ф.-м.н. Барановский С.П., доцент кафедры КИАС
Задание к исполнению принял “___” __________20___г.
Студент _________________________________/Майненгер И.Г./
Реферат
Пояснительная записка
СЕРВЕР, СЕТЬ, УПРАВЛЕНИЕ, ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ, WEBMIN, ALTERATOR, LINUX, ПРОТОКОЛ, ИНТЕРФЕЙС.
Объектом для проекта является серверное программное обеспечение Министерства промышленной политики, транспорта и связи Омской области.
Целью развертывания данной системы является повышение эффективности работы сети, снижение временных затрат, получение оперативных возможностей настройки и конфигурации серверного программного обеспечения, решение возникших проблем.
Назначением создаваемой системы будет автоматизация процесса настройки серверов и сетевых служб.
В результате исследований были определены все данные и документы, необходимые для создания автоматизированной информационной системы.
Список условных сокращений и обозначений
BSD - Berkley Software Distributions license;
GPL - General Public License;
PHP - Personal Home Page;
АИС - автоматизированная информационная система;
БД - база данных;
ПК - программный комплекс;
ПО - программное обеспечение;
ПЭВМ - персональная электронная вычислительная машина;
СУБД - система управления базами данных;
ТО - техническое обеспечение;
ФСТЭК - Федеральная служба по техническому и экспортному контролю.
Содержание
Введение
1. Анализ существующей системы
1.1 Характеристика объекта автоматизации
1.2 Структура Министерства
1.3 Обоснование необходимости разработки АИС
1.4 Обзор аналогов проектируемой системы
1.5 Обоснование выбора используемого программного комплекса
1.6 Постановка задачи
1.7 Требования к системе
1.8 Вывод по разделу
2. АИС управления серверным программным обеспечением на базе программного комплекса Webmin/Alterator
2.1 Модель потоков данных
2.2 Функциональная модель
2.3 Практические цели и назначение системы
2.4 Обзор программного комплекса
2.5 Обзор платформы (конфигуратора)
2.6 Автоматизируемые функции
2.7 Выводы по разделу
3 Описание алгоритмов
3.1 Описание работы с пользователями
3.2 Описание протокола SMB
3.3 Описание протокола DNS
3.4 Протокол NFS
3.5 Выводы по разделу
4. Руководство пользователя
4.1 Руководство пользователя Webmin
4.2 Создание первичного контроллера домена в Webmin
4.3 Руководство пользователя Alterator
Выводы по четвертому разделу
5. Экономическое обоснование проекта
5.1 Цель и краткое описание программного продукта
5.2 Определение затрат труда на разработку программного продукта
5.3 Определение численности исполнителей
5.4 Расчет себестоимости разработки программного продукта
5.5 Расчет экономической эффективности внедрения продукта
5.6 Вывод по разделу
Заключение
Список использованных источников
Приложение А
Введение
Для создания полноценной IT-инфраструктуры, полностью удовлетворяющей всем потребностям необходимо позаботиться не только о грамотно реализованных аппаратных решениях, но и о программном обеспечении, которое будет способствовать оптимальной производительности всех систем. Программные средства помогут повысить производительность серверов, увеличить надёжность систем хранения и, как следствие, уменьшить затраты на обслуживание IT-инфраструктуры. Главным достоинством серверного ПО является возможность автоматизации процессов управления системами, что позволяет использовать рабочее время обслуживающего персонала для решения иных, более важных задач.
У UNIX-подобных операционных систем много положительных сторон: безопасность, стабильность и, что особенно привлекает внимание многих, - бесплатность. Но для системных администраторов настройка системы может превратиться в проблему. Копание в конфигурационных файлах, постоянное чтение документации, к тому же на не для всех понятном английском языке, может отпугнуть любого, привычного к удобному интерфейсу Windows-систем. Ошибки в конфигурационных файлах могут привести к серьезным проблемам с безопасностью.
Webmin - это программный комплекс, который позволяет администрировать unix-подобную операционную систему, не притрагиваясь к командной строке и не помня ни одной команды. Все управление сервером происходит через веб-интерфейс. Используя любой броузер, владелец сервера может заводить новые аккаунты, почтовые ящики, изменять настройки веб-сервера Apache, исправлять и дополнять записи ДНС, настраивать сайты, почтовые ящики и многое, многое другое.
Webmin - состоит из простенького веб-сервера и небольшого количества скриптов, которые собственно и осуществляют связь между приказаниями владельца сервера через веб-интерфейс и их исполнением на уровне операционной системы и прикладных программ. Webmin написан полностью на языке Perl и не использует никаких дополнительных нестандартных модулей. Простота, легкость и быстрота выполнения команд - одно из самых больших преимуществ данной панели управления.
Цель создания системы
Целью создания автоматизированной информационной системы является внедрение для Министерства промышленной политики, транспорта и связи Омской области программно комплекса Webmin/Alterator, позволяющего решить следующие задачи:
производить мониторинг процессов, запускать, останавливать и перезапускать процессы;
осуществлять полноправную навигацию по файловой системе, выполнять любые операции с файлами и каталогами;
единовременно запускать приложения на сервере с возможностью просмотра их вывода через браузер.
Актуальность проекта
Актуальность создания автоматизированной информационной системы обусловлена возможностью снижения временных затрат на создание и запуск новых направлений работы серверного оборудования. Также система позволит работать администратору удаленно, устранит необходимость поиска ошибок в конфигурационных файлах и постоянном чтении документации.
система дает возможность доработки её до полнофункциональной автоматизированной системы полностью автоматического управления серверным программным обеспечением и сетью как таковой.
Новизна проекта
Новизна проекта заключается в том, что подобная система, а точнее сложение различных систем, ранее не применялось на объекте автоматизации. Также в создании части системы, посвященной созданию почтового сервера на базе конфигуратора Alterator, принимали участие сертифицированные ФСТЭК программные продукты, что делает систему отвечающей современным стандартам.
Структура проекта
Проект содержит основные разделы, а также разделы по организационно-экономическому обоснованию и безопасности труда. Пояснительная записка содержит шесть разделов:
в первом разделе проведен анализ объекта автоматизации, техническое задание и постановка задачи;
во втором разделе приведен проект создания АИС управления серверным программным обеспечением;
третий раздел содержит сведения об используемых алгоритмах и протоколах в программном обеспечении;
в четвертом разделе приведено краткое руководство пользователя и примеры решения практических задач;
пятый раздел содержит организационную часть и экономические расчеты затрат на создание АИС;
в шестом разделе рассмотрены вопросы охраны труда.
1. Анализ существующей системы
Этапу непосредственного создания АИС всегда предшествует анализ объекта автоматизации обработки информации. В данном разделе дается общая характеристика Министерства промышленной политики, транспорта и связи Омской области и его структура, также раздел содержит общую постановку задачи, требования к системе и обзор аналогов.
1.1 Характеристика объекта автоматизации
При разработке данного проекта было изучено существующее положение Министерства промышленной политики, транспорта и связи Омской области с точки зрения управления серверным программным обеспечением. Был проведён общий анализ внедрённых информационных систем управления и используемых информационных ресурсов.
Выявив недостатки и проанализировав их, были предложены рациональные решения для их устранения, учитывая необходимые требования и специфику работы Министерства промышленной политики, транспорта и связи Омской области, а также времени.
Вследствие чего необходимо определить направление для повышения работоспособности и эффективности использования существующих серверов Министерства промышленной политики транспорта и связи Омской области: необходимо разработать автоматизированную информационную систему управления серверным программным обеспечением на базе программного комплекса Webmin/Alterator для Министерства промышленной политики транспорта и связи Омской области.
1.2 Структура Министерства
На рисунке 1.1 представлена организационная структура министерства.
Рисунок 1.1 - Структура министерства промышленной политики, транспорта и связи Омской области
1.3 Обоснование необходимости разработки АИС
В результате анализа схемы работы, очередности обработки информации выделены следующие недостатки:
неполное и частично неэффективное использование технических средств, имеющихся в наличии;
большие временные затраты на устранение неполадок в работе сети посредством командной строки и правки конфигурационных файлов;
не автоматизированный процесс конфигурирования и настройки серверного оборудования.
Работоспособность организации напрямую зависит от работоспособности локальной сети. В связи с этим, необходимо вовремя и с минимальной потерей рабочего времени устранять появившуюся неисправность, что существенно легче осуществить посредством web-интерфейса. Необходимо устранять нежелательные явления, как только они выявлены и прежде чем пользователи сообщат о них. Вся эта работа является очень трудоемкой и требующей больших затрат времени и внимания, она снижает возможности оперативного получения информации.
Таким образом, на основании приведенных выше недостатков, возникла необходимость автоматизации управления ПО серверного оборудования, что позволит снизить трудоемкость и повысить достоверность, оперативность получения информации.
Основные недостатки отсутствия управления программным обеспечением представлены на рисунке 1.2.
Для того чтобы определить задачи и функции разрабатываемой системы, необходимо для начала сформировать дерево целей, из дерева проблем, которое было построено выше, а затем из этих данных сформируются задачи, которые необходимо решить.
Графическое представление дерева целей отражено на рисунке 1.3.
Рисунок 1.2 - Дерево проблем, характеризующее основные недостатки отсутствия АИС.
Рисунок 1.3 - Дерево целей
1.4 Обзор аналогов проектируемой системы cPanel
cPanel -- платная панель управления веб-хостингом. Функционирует посредством отдельной копии веб-сервера, работающей, как правило, на порту 2082 (или 2083/SSL).
В состав cPanel входит достаточно большое количество свободного ПО, основным из которого является Apache, MySQL, PHP, exim.
Основные особенности: использование шаблонов, наличие локализации на 25 языках. Встроенная утилита «Фантастико» содержит порядка 50 готовых к использованию скриптов.
cPanel является достаточно популярным ПО, возможно, даже самой популярной из всех коммерческих панелей управления для хостинга. Не последняя причина в том, что cPanel имеет расширенную функциональность для перепродажи хостинга.
По состоянию на ноябрь 2008 года производителем заявлена поддержка следующих операционных систем:
Red Hat Enterprise Linux (рекомендованная ОС);
CentOS (рекомендованная ОС);
FreeBSD (предлагается использовать только квалифицированным специалистам).
cPanel может быть установлен и на другие дистрибутивы Linux, но это может потребовать больше усилий от администратора, чем использование ОС рекомендованных производителем. При использовании FreeBSD необходимо соблюдать рекомендацию разработчиков Cpanel и не использовать для установки нового ПО бинарные пакеты («пакаджи»), а пользоваться только портами.
На рисунке 1.4 представлен интерфейс cPanel.
DirectAdmin
DirectAdmin -- панель управления веб-хостингом, созданная в 2003 году Канадской компанией JBMC Software. DirectAdmin широко используется западными и российскими хостинг-провайдерами.
Панель управления DirectAdmin поддерживает операционные системы: FreeBSD, GNU/Linux (дистрибутивы CentOS, Red Hat, Fedora, Debian).
И работает с программным обеспечением: MySQL, Dovecot, Exim, Apache, PHP, Perl, BIND.
Также, DirectAdmin имеет открытый API и возможность написания собственных скриптов для автоматизации процессов.
Первая публичная версия (0.95) DA увидела свет 1 марта 2003 года. На данный момент последней стабильной версией панели управления является 1.336, представленная 28 апреля 2009 года.
Возможности:
Управление сервером (запуск\остановка демонов, настройка системы).
Управление сайтами клиентов (virtual-hosts, DNS).
Управление учетными записями пользователей.
Создание реселлеров услуг.
Управление резервным копированием (в том числе -- на удаленный сервер).
Контроль состояния сервера.
Преимуществами DirectAdmin являются:
Скорость работы и нетребовательность к ресурсам сервера.
Большой спектр поддерживаемых операционных систем и дистрибутивов.
Низкая стоимость.
Простота использования.
Недостатками являются:
Сложность администрирования и обновления.
Отсутствие официальной поддержки на русском языке.
Бедность функционала.
На рисунке 1.5 представлен интерфейс DirectAdmin.
1.5 Обоснование выбора используемого программного комплекса
Рассмотренные в пункте 1.4 программные продукты не удовлетворяют требованиям объекта автоматизации и имеют некоторые недостатки:
неполная функциональность;
отсутствие открытого кода программы и как следствие затруднение с её доработкой и созданием модулей;
программные продукты распространяются за плату.
В свою очередь, создаваемый на основе Webmin/Alterator программный комплекс будет иметь следующие положительные стороны:
Скорость работы и нетребовательность к ресурсам сервера;
Большой спектр поддерживаемых операционных систем и дистрибутивов;
Наличие полнофункционального, удобного, изменяемого под свои потребности, интерфейса;
Для Webmin - свободное распространение, лицензия BSD;
Для Alterator наличие сертификации ФСТЭК.
Этими доводами обусловлен выбор программных комплексов для создания АИС управления серверным программным обеспечением.
1.6 Постановка задачи
Назначение системы
Автоматизированная информационная система управления серверным программным обеспечением на базе программного комплекса Webmin/Alterator предназначена для автоматизации процесса настройки и конфигурирования программного обеспечения на серверах и сетевом оборудовании. АИС предполагается использовать в Министерстве промышленной политики, транспорта и связи Омской области.
Цели создания системы
Цели создания данной системы:
уход от необходимости ручной работы в процессе настройки работы сети;
повышение оперативности, объективности в работе с оборудованием;
автоматизация процесса управления серверным программным обеспечением;
создание условий для быстрого и надежного устранения ошибок и сбоев в работе сети.
Полученные объективные данные будут являться для принятия управленческих решений.
1.7 Требования к системе
Требования к системе в целом
При реализации ИС должны быть обеспечены меры по защите информации от несанкционированного доступа, в соответствии с требованиями руководящих документов (СТР-К);
ИС должна содержать механизм своевременной актуализации информационного наполнения;
ИС должна быть создана на основе свободно распространяемого программного обеспечения;
ИС должна иметь модульную структуру;
в ИС должны использоваться международные стандарты описания информации, удобные для обмена информацией между различными приложениями и использования в системе управления информацией;
ИС должна содержать подсистему авторизованного доступа к информационным ресурсам;
ИС должна соответствовать стандартам открытых систем ISO (ISO/IEC 17799, ISO 27000, ISO/IEC 27001, ISO 8601, ISO 9241);
ИС должна представлять собой многоуровневую иерархическую систему с учетом возможности передачи информационных ресурсов по каналам связи;
ИС должна обеспечивать совместную работу групп пользователей;
ИС должна использовать информацию, передаваемую по каналам электросвязи, использующим протокол стека TCP/IP.
Требования к структуре и функционированию системы
Система должна поддерживать разграничение прав доступа пользователей к объектам системы.
В системе должен быть реализован принцип однократного ввода информации и механизмы, предотвращающие произвольное изменение документов, порожденных на основе учетных данных.
При разработке данной системы Администратором будет использован набор библиотек и сервисов - ядро базовой функциональности информационной системы, поставляемое в виде базового программного комплекса Webmin.
Программный комплекс Webmin является открытым программным обеспечением, распространяемым по лицензии BSD (Berkley Software Distributions license).
Используемые при разработке платформы Webmin технологии не противоречат требованиям архитектуры программного обеспечения. Платформа Webmin поставляется по открытой лицензии GPL (General Public License).
Требования к численности и квалификации персонала системы и режиму его работы.
Количества персонала зависит от масштаба внедрения системы. Персонал должен иметь навыки работы с ПК, а также должен пройти небольшой курс работы с программным обеспечением.
Показатели назначения.
Данная систем имеют высокий ресурс модернизации, при необходимой поддержки, система будет всегда находиться в актуальном состоянии.
Требования к надежности
Обеспечить высокую надежность работы программного обеспечения, а также оборудования используемое для функционирования системы. А также при обеспечении надежности следовать инструкциям нормативно-технической документации.
Требования безопасности
Установку оборудования должны производить квалифицированные специалисты, чтобы обеспечить надежную работу системы и избежать возможной угрозе здоровья человеку.
Требования к эргономике и технической эстетике
Программное обеспечения должно иметь удобный и интуитивно понятный интерфейс.
Рабочее место пользователя должно быть удобным для работы, а также соответствовать всем необходимым требованиям нормативно-технической документации.
Требования по сохранности информации при авариях
Необходимо ежемесячно делать резервную копию БД системы.
Требования к защите от влияния внешних воздействий
Программное обеспечение должно иметь системы авторизации пользователей, чтобы обеспечить защиту от несанкционированного изменения данных АСОИУ. А также иметь защищенный канал для передачи данных.
Требования по стандартизации и унификации
Необходимо обеспечить максимальную стандартизацию задач системы, поставляемых программных средств, унифицированных форм управленческих документов, установленных ГОСТ 6.10.1-88.
1.8 Вывод по разделу
В данном разделе был проведен анализ объекта автоматизации, краткой характеристики предприятия Министерства промышленной политики, транспорта и связи Омской области, которая включает основные направления деятельности и организационную структуру. Был проведен анализ существующих подобных систем, выявлены преимущества используемой системы. Также были поставлены цели разработки и основные требования к системе.
2 АИС управления серверным программным обеспечением на базе программного комплекса Webmin/Alterator
В этой главе представлены основные этапы технического проектирования системы, такие как функциональное моделирование, моделирование и разработка.
2.1 Модель потоков данных
Диаграмма потоков данных описывает внешние по отношению к системе источники и адресаты данных, потоки данных и хранилища данных, к которым осуществляется доступ. Поток данных определяет информацию, передаваемую через некоторое соединение от источника к приемнику.
Поток данных на диаграмме изображается линией, оканчивающейся стрелкой, которая показывает направление потока. Каждый поток данных имеет имя, отражающее его содержание.
На рисунке 2.1 представлена контекстная диаграмма потоков данных разрабатываемой автоматизированной системы.
Рисунок 2.1 - Контекстная диаграмма потоков данных
Существует 5 видов стрелок:
Вход - материал или информация, которые используются или преобразуются для получения результата. Каждый тип стрелок подходит к определенной стороне прямоугольника, изображающего работу, или выходит из неё. Стрелка входа рисуется как входящая в левую грань работы.
Управление - правила, стратегии, процедуры, которыми руководствуется работа. Каждая работа должна иметь хотя бы одну стрелку управления. Рисуется как входящая в верхнюю грань. Управление влияет на работу, но не преобразуется работой.
Выход - материал или информация, которые производятся работой. Рисуется как исходящая из правой грани работы.
Механизм - ресурсы, которые выполняют работу. Рисуется как входящая в верхнюю грань.
Вызов - специальная стрелка, указывающая на другую модель работы. Рисуется как исходящая из нижней грани работы. Используется для указания того, что некоторая работа выполняется за пределами моделируемой системы.
2.2 Функциональная модель
Функциональная модель описывает вычисления в системе. Она показывает, каким образом выходные данные вычисляются по входным данным, не рассматривая порядок и способ реализации вычислений. Функциональная модель состоит из набора диаграмм потока данных, которые показывают потоки значений от внешних входов через операции и внутренние хранилища данных к внешним выходам. Функциональная модель описывает смысл операций объектной модели и действий динамической модели, а так же ограничения на объектную модель.
На рисунке 2.2 представлена контекстная диаграмма функциональной модели разрабатываемой автоматизированной системы.
Рисунок 2.2 - Функциональная модель
2.3 Практические цели и назначение системы
Для создания автоматизированной системы управления необходимо поставить задачи, которые нужно будет решить в процессе дипломного проектирования.
Целями развертывания данной системы является уход от необходимости ручной работы в процессе настройки работы сети, что позволит повысить оперативность и объективности в работе с оборудованием. Также целью является автоматизация процесса управления серверным программным обеспечением и создание условий для быстрого и надежного устранения ошибок и сбоев в работе сети.
Основной целью применения ПК Webmin/Alterator в Министерстве промышленной политики, транспорта и связи Омской области является повышение эффективности работы Министерства.
Для создания автоматизированной системы управления необходимо поставить задачи, которые нужно будет решить в процессе дипломного проектирования.
2.4 Обзор программного комплекса
Webmin - это программный комплекс, который позволяет администрировать unix-подобную операционную систему, не притрагиваясь к командной строке и не помня ни одной команды. Все управление сервером происходит через веб-интерфейс. Используя любой броузер, владелец сервера может заводить новые аккаунты, почтовые ящики, изменять настройки веб-сервера Apache, исправлять и дополнять записи ДНС, настраивать сайты, почтовые ящики и многое, многое другое.
Webmin - состоит из простенького веб-сервера и небольшого количества скриптов, которые собственно и осуществляют связь между приказаниями владельца сервера через веб-интерфейс и их исполнением на уровне операционной системы и прикладных программ. Webmin написан полностью на языке Perl и не использует никаких дополнительных нестандартных модулей. Простота, легкость и быстрота выполнения команд - одно из самых больших преимуществ данной панели управления.
Вторым несомненным плюсом Webmin'a является его стоимость - данная панель управления бесплатно распространяется для коммерческого и некоммерческого использования. Авторы этой программы не жадничают и позволяют всем желающим не только бесплатно использовать программу, но и изменять ее по своему усмотрению. Именно благодаря этому вокруг Webmin сложился мощный пласт сторонних добровольных помощников-программистов, которые дописывают данную программу, исправляют неудачные места, пишут дополнительные модули, производят перевод на другие языки. Благодаря этому Webmin оброс большой функциональностью, огромным количеством подключаемых модулей и переведен практически на все европейские языки, включая русский.
2.5 Обзор платформы (конфигуратора)
Alterator -- новое поколение платформ для разработки сложных систем. Используются по большей части Scheme, C и старый добрый sh+awk. На данный момент используется как инсталлятор и конфигуратор системы.
Alterator можно разделить на два слоя: backend и frontend. Первый слой реализует низкоуровневое взаимодействие с системой. Второй -- высокоуровневый интерфейс с пользователем.
Пользовательский интерфейс пишется на языке Scheme. Бэкенды могут быть написаны на любом языке программирования. Существуют библиотеки на Shell, Perl и Ruby для упрощения разработки.
Рисунок 2.3 - Архитектура Alterator
2.6 Автоматизируемые функции
- Создание, редактирование, и удаление пользователей в вашей системе.
- Экспорт файлов и директорий в другие системы с помощью протокола NFS.
- Установка дисковых квот, чтобы контролировать максимальное количество дискового пространства, занимаемого пользователями.
- Установка, просмотр и удаление программ в RPM и других форматах.
- Изменение IP-адреса, параметров DNS, и конфигурации роутинга.
- Настройка firewall для защиты компьютера или для раздачи компьютерам из локальной сети доступа в Интернет.
- Создание и конфигурация виртуальных Web-сайтов на сервере Apache.
- Управление базами данных, таблицами, и записями в базе данных MySQL или PostgreSQL.
- Совместное использование файлов с Windows-системами с помощью настройки Samba.
2.7 Выводы по разделу
В данном разделе были описаны потоки входной, выходной и нормативно-справочной информации, выделены автоматизированные функции. Приведен обзор используемых программных комплексов для автоматизации управления серверным программным обеспечением.
Был рассмотрен алгоритм функционирования системы и представлена структурная схема автоматизированной системы.
3. Описание алгоритмов
В процессе проектирования автоматизированной информационной системы должны быть рассмотрены основные принципы и алгоритмы работы системы, её взаимодействие с объектом автоматизации, используемые протоколы различных сетевых уровней.
3.1 Описание работы с пользователями
Пользователи системы
Прежде, чем система будет готова к работе с пользователем, происходит процедура загрузки системы. В процессе загрузки будет запущена основная управляющая программа (ядро), определено и инициализировано имеющееся оборудование, активизированы сетевые соединения, запущены системные службы. В Linux во время загрузки на экран выводятся диагностические сообщения о происходящих событиях, и если все в порядке и не возникло никаких ошибок, загрузка завершится выводом на экран приглашения "login:". Оно может выглядеть по-разному, в зависимости от настройки системы: может отображаться в красиво оформленном окне или в виде простой текстовой строки вверху экрана. Это приглашение к регистрации в системе: система ожидает, что в ответ на это приглашение будет введено входное имя пользователя, который начинает работу. Естественно, имеет смысл вводить такое имя, которое уже известно системе, чтобы она могла "узнать", с кем предстоит работать - выполнять команды неизвестного пользователя Linux откажется.
Многопользовательская модель разграничения доступа
Процедура регистрации в системе для Linux обязательна: работать в системе, не зарегистрировавшись под тем или иным именем пользователя, просто невозможно. Для каждого пользователя определена сфера его полномочий в системе: программы, которые он может запускать, файлы, которые он имеет право просматривать, изменять, удалять. При попытке сделать что-то, выходящее за рамки полномочий, пользователь получит сообщение об ошибке. Такая строгость может показаться излишней, если пользователи компьютера доверяют друг другу, и особенно если у компьютера только один пользователь. Эта ситуация очень распространена в настоящее время, когда слово "компьютер" означает в первую очередь "персональный компьютер".
Машинное время вычеслительного центра недешево, и при этом его возможности необходимы одновременно многим сотрудникам, которые могут ничего не знать о работе друг друга. Требуется следить за тем, чтобы не произошло случайного вмешательства пользователей в чужую работу и повреждения данных (файлов), выделять каждому машинное время (по возможности избежав простаивания) и пространство на диске и при этом не допускать захвата всех ресурсов одним пользователем и его задачей, а равномерно распределять ресурсы между всеми. Для такой системы принципиально важно знать, кому принадлежат задачи и файлы, поэтому и возникла необходимость предоставлять доступ к ресурсам системы только после того, как пользователь зарегистрируется в системе под тем или иным именем.
Учетные записи
Cистема может быть знакома с человеком только в переносном смысле: в ней должна храниться запись о пользователе с таким именем и о связанной с ним системной информации - учетная запись. Английский эквивалент термина учетная запись - account, "счет". Именно с учетными записями, а не с самими пользователями, и работает система. В действительности, соотношение учетных записей и пользователей в Linux обычно не является однозначным: несколько человек могут использовать одну учетную запись - система не может их различить. И в то же время в Linux имеются учетные записи для системных пользователей, от имени которых работают некоторые программы, но не люди.
Учетная запись (account) - объект системы, при помощи которого Linux ведет учет работы пользователя в системе. Учетная запись содержит данные о пользователе, необходимые для регистрации в системе и дальнейшей работы с ней. Учетные записи могут быть созданы во время установки системы или после установки.
Главное для человека в учетной записи - ее название, входное имя пользователя. Именно о нем спрашивает система, когда выводит приглашение "login:". Помимо входного имени в учетной записи содержатся некоторые сведения о пользователе, необходимые системе для работы с ним. Ниже приведен список этих сведений.
Входное имя (login name) - название учетной записи пользователя, которое нужно вводить при регистрации в системе.
Идентификатор пользователя
Linux связывает входное имя c идентификатором пользователя в системе - UID (User ID). UID - это положительное целое число, по которому система и отслеживает пользователей. Обычно это число выбирается автоматически при регистрации учетной записи, однако оно не может быть произвольным. В Linux есть некоторые соглашения относительно того, какому типу пользователей могут быть выданы идентификаторы из того или иного диапазона. В частности, UID от "0" до "100" зарезервированы для псевдопользователей.
Идентификатор группы
Кроме идентификационного номера пользователя, с учетной записью связан идентификатор группы. Группы пользователей применяются для организации доступа нескольких пользователей к некоторым ресурсам. У группы, так же, как и у пользователя, есть имя и идентификационный номер - GID (Group ID). В Linux пользователь должен принадлежать как минимум к одной группе - группе по умолчанию. При создании учетной записи пользователя обычно создается и группа, имя которой совпадает с входным именем, именно эта группа будет использоваться как группа по умолчанию для данного пользователя. Пользователь может входить более чем в одну группу, но в учетной записи указывается только номер группы по умолчанию.
Полное имя
Помимо входного имени в учетной записи содержится и полное имя (имя и фамилия) использующего данную учетную запись человека. Конечно, пользователь может указать что угодно в качестве своего имени и фамилии. Полное имя необходимо не столько системе, сколько людям - чтобы иметь возможность определить, кому принадлежит учетная запись.
Домашний каталог
Файлы всех пользователей в Linux хранятся раздельно, у каждого пользователя есть собственный домашний каталог, в котором он может хранить свои данные. Доступ других пользователей к домашнему каталогу пользователя может быть ограничен. Информация о домашнем каталоге обязательно должна присутствовать в учетной записи, потому что именно с него начинает работу пользователь, зарегистрировавшийся в системе.
Командная оболочка
Каждому пользователю нужно предоставить способ взаимодействия с системой: передача ей команд и получение от нее ответов. Для этой цели служит специальная программа - командная оболочка (или интерпретатор командной строки). Она должна быть запущена для каждого пользователя, который зарегистрировался в системе. Поскольку в Linux доступно несколько разных интерпретаторов командной строки, в учетной записи указано, какой из них нужно запустить для данного пользователя. Если специально не указывать командную оболочку при создании учетной записи, она будет назначена по умолчанию, вероятнее всего это будет bash.
Интерпретатор командной строки (командный интерпретатор,командная оболочка, оболочка) - это программа, используемая в Linux для организации "диалога" человека и системы. Командный интерпретатор имеет три основных ипостаси:
редактор и анализатор команд в командной строке,
высокоуровневый системно-ориентированный язык программирования,
средство организации взаимодействия команд друг с другом и с системой.
Понятие "администратор"
В Linux есть только один пользователь, полномочия которого в системе принципиально отличаются от полномочий остальных пользователей - это пользователь с идентификатором "0". Обычно учетная запись пользователя с UID=0 называется root (англ., "корень"). Пользователь root - это "администратор" системы Linux, учетная запись для root обязательно присутствует в любой системе Linux, даже если в ней нет никаких других учетных записей. Пользователю с таким UID разрешено выполнять любые действия в системе, а значит, любая ошибка или неправильное действие может повредить систему, уничтожить данные и привести к другим печальным последствиям. Поэтому категорически не рекомендуется регистрироваться в системе под именем root для повседневной работы. Работать в root следует только тогда, когда это действительно необходимо: при настройке и обновлении системы или восстановлении после сбоев.
3.2 Описание протокола SMB
SMB, или иначе CIFS - это протокол, определяющий сетевую файловую систему, ее структуру и порядок использования. NetBIOS предоставляет интерфейс, через который SMB-сообщения передаются в сети, он используется серверами для "анонса" служб в сети, и клиентами для "обзора" этих служб. NetBIOS в качестве транспортного протокола может использовать любой низкоуровневый сетевой протокол, однако наиболее часто используется TCP/IP; когда NetBIOS работает поверх TCP/IP, это называется NBT. WINS предоставляет централизованные службы имен (отображение имен машин в IP-адреса) там, где это необходимо.
Протокол SMB, соответствующий прикладному и представительному уровням модели OSI, регламентирует взаимодействие рабочей станции с сервером. В функции SMB входят следующие операции:
Управление сессиями. Создание и разрыв логического канала между рабочей станцией и сетевыми ресурсами файлового сервера.
Файловый доступ. Рабочая станция может обратиться к файл-серверу с запросами на создание и удаление каталогов, создание, открытие и закрытие файлов, чтение и запись в файлы, переименование и удаление файлов, поиск файлов, получение и установку файловых атрибутов, блокирование записей.
Сервис печати. Рабочая станция может ставить файлы в очередь для печати на сервере и получать информацию об очереди печати.
Сервис сообщений. SMB поддерживает простую передачу сообщений со следующими функциями: послать простое сообщение; послать широковещательное сообщение; послать начало блока сообщений; послать текст блока сообщений; послать конец блока сообщений; переслать имя пользователя; отменить пересылку; получить имя машины.
На высоком уровне представление протокола SMB довольно просто. Он включает в себя все возможные операции для работы с файлами и принтерами, которыми вы пользуетесь на обычном компьютере, например :
открыть и закрыть файл;
создание и удаление директорий;
чтение и запись в файл;
поиск файлов;
посылка на печать и отмена печати на принтере.
Все эти операции могут быть помещены в сообщение SMB и переданы к и от сервера. Название SMB происходит от названия формата данных v разновидности стандартных системных вызовов DOS к различным структурам данных или Server Message Blocks, адаптированная для передачи данных другому компьютеру по сети.
Формат SMB
Richard Shape из команды разработчиков Samba дал определение протоколу SMB как запрос-ответ. На практике это означает, что клиент посылает запрос SMB к серверу и сервер отвечает сообщением на этот запрос. Сервер редко формирует ответы, которые не относятся к клиенту.
Сообщение SMB не так сложно. Рассмотрим структуру сообщения. Его можно разделить на две части: заголовок фиксированного размера и поле команды, размер которой меняется динамически в зависимости от состава сообщения.
Формат заголовка SMB
Таблица 3.1 показывает формат заголовка SMB. Команды SMB не обязательно должны заполнять все поля заголовка SMB. Например, когда клиент впервые пытается соединиться с сервером, то значение идентификатора дерева (TID) пусто v он появляется после успешного соединения и нулевое значение TID (0xFFFF) устанавливается в соответствующее поле заголовка. Другие поля могут также устанавливаться в ноль, когда не используются.
Значения полей заголовка SMB перечислены в Таблице 3.1.
Таблица 3.1 Поля заголовка SMB
Поле |
Размер (байты) |
Описание |
|
0xFF 'SMB' |
1 |
Идентификатор протокола |
|
COM |
1 |
Код команды, от 0x00 до 0xFF |
|
RCLS |
1 |
Класс ошибки |
|
REH |
1 |
Зарезервирован |
|
ERR |
2 |
Код ошибки |
|
REB |
1 |
Зарезервирован |
|
RES |
14 |
Зарезервирован |
|
TID |
2 |
ID Дерева; уникальное ID для ресурса, исп. клиентом |
|
PID |
2 |
ID Вызывающего процесса |
|
UID |
2 |
Идентификатор пользователя |
|
MID |
2 |
Мультиплексный ID; используемый для передачи запросов внутри процесса |
Формат команды SMB
После того, как заголовок представлен определенным числом байт, происходит выполнение команды SMB. Любая команда, например такая, как открыть файл (ID поля COM: SMBopen ) или получить запрос на печать (SMBsplretq), имеет свой набор параметров и данные. Как и в поле заголовка SMB, здесь также могут быть заполнены не все командные поля, все зависит от команды. Например, команда GetServerAttributes (SMBdskattr) устанавливает поля WCT BCC в 0. Поля командных сегментов показаны в Таблице 3.2.
Таблица 3.2 - Содержание команды SMB
Поле |
Размер в байтах |
Описание |
|
WCT |
1 |
Счетчик слов |
|
VWV |
Переменная |
Параметр слов (размер, определяемый WCT) |
|
BCC |
2 |
Параметр счетчика байт |
|
DATA |
Переменная |
Данные (размер, определяемый BCC) |
3.3 Описание протокола DNS
Служба Доменных Имен (Domain Name System) предназначена для того, чтобы машины, работающие в Internet, могли по доменному имени узнать IP-адрес нужной им машины, а также некоторую другую информацию; а по IP-номеру могли узнать доменное имя машины.
Служба Доменных Имен была разработана для именования машин в глобальной сети. Основной особенностью глобальной сети является распределенное администрирование, когда один администратор физически не может уследить за выделением имен. Поэтому Служба Доменных Имен функционирует на принципе делегирования полномочий. Каждая машина либо знает ответ на вопрос, либо знает кого спросить. При правильном функционировании система замкнута, т.е. если запрошенная информация имеется у кого-либо, то она будет найдена и сообщена клиенту, либо, если вопрос не имеет ответа, клиент получит сообщение о невозможности получения ответа на вопрос.
Каждый клиент знает своего сервера; обычно указывается не один, а несколько серверов - если первый не отвечает, клиент обращается ко второму и так далее до исчерпания списка. В принципе неважно, к какому серверу обращаться - они дают (должны давать при правильном функционировании) одинаковые ответы на любой запрос. Поэтому для ускорения работы обычно указывают ближайший. Следует помнить, что на одной машине могут функционировать одновременно Name-сервер и программы-клиенты; поэтому если на машине запущен Name-сервер, то в качестве Name-сервера на ней должен быть прописан "я сам".
Имеется некий домен верхнего уровня, обозначаемый точкой: ".". Имеется девять серверов (по крайней мере на моем Name-сервере записано столько), которые отвечают за эту зону. Они не знают ни одного доменного имени - они только авторизуют серверы верхних зон. Серверы верхних зон тоже гнушаются хранить информацию о конкретных машинах и передают это право нижележащим серверам. Тут уже появляются первые упоминания о конкретных машинах, равно как и происходит авторизация нижележащих серверов.
Очень редко используются доменные имена из двух сегментов; имена из трех и четырех сегментов составляют подавляющую долю всех имен Internet; имена из пяти сегментов встречаются довольно редко.
Допустим, клиент запросил адрес "www.организация.город.страна". Поиск информации по доменному имени происходит следующим образом:
Клиент спрашивает своего сервера.
Если тот является сервером данной зоны, то ответит, на чем все заканчивается.
Сервер спрашивает корневой сервер.
Тот не может ответить, потому что не знает; зато знает, какой сервер отвечают за зону "страна".
Сервер зоны "страна" тоже не может ответить, но знает, что нужно спросить сервер зоны "город.страна".
Тот в свою очередь отсылает запрос серверу зоны "организация.город.страна", который сообщит нужную информацию.
Это приближенная модель, которая тем не менее позволяет представить работу системы DNS.
Однако эту стройную картину искажают системы кэширования и вторичных серверов. Дело в том, что получив ответ на свой вопрос, DNS-сервер получает также некоторое число, которое говорит ему о том, по истечении какого времени эта информация должна считаться устаревшей. Таким образом, все серверы, участвовавшие в поиске ответа на вопрос, заданный клиентом, могут (и скорее всего будут) помнить как ответ на заданный вопрос, так и путь, по которому шел поиск. При следующих запросах, имеющих общую правую часть с недавно сделанными запросами, поиск будет упрощен (ускорен).
Следует обратить внимание на сходство, различие и взаимодействие систем DNS и IP-маршрутизации. Как и IP-маршрутизация, DNS работает по принципу делегирования полномочий, но выделение доменных имен совершенно не зависит от выделения IP-адресов. Для примера рассмотрим домен freebsd.org. Это - домен организации, занимающейся распространением операционной системы FreeBSD Unix. FTP-сервер, содержащий дистрибутив операционной системы и множества утилит для нее, имеет копии в нескольких десятках стран.
Политика и стратегия назначения имен
Имена зон условно можно разделить на "организационные" и "географические". В высшей зоне зарегистрированы следующие "организационные" зоны:
com - commercial (коммерческие);
edu - educational (образовательные);
gov - goverment (правительственные);
mil - military (военные);
net - network (организации, обеспечивающие работу сети);
org - organization (некоммерческие организации).
3.4 Протокол NFS
Система NFS обеспечивает разнообразным приложениям на клиентских хостах прозрачный доступ к файловым системам и файлам на сервере. Слово доступ здесь означает, что становятся доступными разнообразные операции с отдельными частями содержимого файлов (а не только копирование файлов целиком с помощью специализированного клиента подобно тому, как это происходит при пересылке файлов в FTP). Предоставляемый доступ является прозрачным в том смысле, что каждое приложение на клиентской машине, работающее с локальными файлами, точно так же работает через NFS и с файлами на удаленной системе, причем без каких-либо изменений в коде этого приложения.
Система NFS построена по принципу клиент-сервер и базируется на RPC фирмы Sun Microsystems. NFS-клиент получает доступ к файлам на хосте NFS-сервера, посылая ему RPC-запросы. С принципиальной точки зрения NFS-клиент и NFS-сервер могли бы быть обычными пользовательскими процессами, взаимодействующими через RPC, однако из практических соображений NFS обычно реализуют иначе, и на это есть две причины. С одной стороны, как было сказано, доступ к файлам с помощью NFS должен быть прозрачным для любых приложений на стороне клиента. Следовательно, все обеспечивающие удаленную работу с файлами NFS-запросы с клиентской машины должны автоматически генерироваться операционной системой. С другой стороны, высокая производительность NFS-сервера достигается, только если он функционирует как часть операционной системы на его хосте. Если бы NFS-сервер был реализован как пользовательский процесс, то обращения сервера с запросом к файловой системе вместе с записываемыми и считываемыми данными в каждой транзакции пересекали бы границу между ядром и этим пользовательским процессом, что неизбежно повлекло бы значительные издержки и резко снизило производительность. Поэтому NFS-серверы реализуют в коде ядра.
1. Для пользовательского приложения скрыто, обращается он к местному файлу или через NFS к файлу на удаленном хосте (далее последние будем кратко называть NFS-файлами). За него это знает ядро: в момент открытия файла оно определяет его местонахождение и в зависимости от этого в последующем все обращения к местным файлам отдает на обработку своей файловой системе, а те, что относятся к дальним файлам, направляет NFS-клиенту.
2. NFS-клиент посылает RFC-запросы на NFS-сервер через используемый транспортный протокол. Большей частью NFS работает по UDP, но последние реализации могут быть конфигурированы на установление соединений по TCP.
3. NFS-сервер принимает дейтаграммы с запросами NFS-клиента на свой UDP-порт 2049. Хотя, в принципе, NFS-сервер мог бы использовать эфемерный порт, объявляя его на регистраторе портов, в большинстве реализаций NFS зафиксирован стандартный порт 2049.
4. При поступлении запроса от NFS-клиента NFS-сервер транслирует его в запросы к своей местной файловой системе, которая и осуществляет соответствующие действия на диске хоста сервера.
5. Обработка запроса на сервере может занять значительное время, особенно если потребуется выполнить манипуляции в его файловой системе. Чтобы в период выполнения одного запроса не блокировать запросы от других NFS-клиентов, NFS-сервер должен обрабатывать их параллельно. Способ параллельной обработки зависит от возможностей конкретной операционной системы. Поскольку большинство реализаций Unix не поддерживают механизм нитей (multithreading), то обычно используемый искусственный прием состоит в следующем. Запросы от клиента на стороне сервера обрабатывает пользовательский процесс, называемый демоном. NFS (обычное его имя -- nf sd), который может сам себя копировать в некотором числе экземпляров. Эта простейшая программа посылает один не требующий ответа вызов в код встроенного в ядро NFS-сервера.
6. В свою очередь, и NFS-клиент, обслуживающий свой пользовательский процесс, вынужден, выслав RPC-запрос, в течение достаточно длительного времени ждать завершения его обработки на сервере до получения RPC-ответа. Поэтому и на клиентском хосте необходимо так или иначе обеспечить параллельное обслуживание многих использующих NFS пользовательских процессов, что также решается различными способами в зависимости от операционной системы. В Unix на хосте клиента NFS часто используется тот же прием, что и в случае сервера: создается новая копия пользовательского процесса, называемого здесь демоном блочного ввода-вывода (biod), который посылает один не требующий ответа вызов в код встроенного в ядро NFS-клиента.
Большинство хостов в Unix поддерживают либо NFS-клиента, либо NFS-сервера, либо обоих одновременно. Реализации NFS-клиентов существуют и для персональных компьютеров с операционными системами, например, от Microsoft. Мэйнфреймы, в частности фирмы IBM, часто выполняют роль только NFS-сервера.
В системе NFS на стороне сервера кроме программы, реализующей собственно сам протокол NFS, действуют еще и другие работающие поверх RPC программы, включая непременный для RPC регистратор портов.
Та или иная файловая система NFS-сервера становится доступной с машины NFS-клиента только после того, как будет на ней должным образом смонтирована. Для этого NFS-клиент обращается с соответствующим запросом к демону монтирования (mount daemon) NFS-сервера. Сам протокол монтирования в NFS будет рассмотрен ниже.
Менеджер блокировок (lock manager) и монитор состояний (status monitor) позволяют блокировать фрагменты файлов на сервере. Эти две программы необходимы как отдельные дополнения к протоколу NFS, поскольку для временной блокировки обращений к частям файла при их модификации необходимо, чтобы клиент и сервер могли из одного состояния переходить в другое. (Протоколом NFS не предусмотрено запоминание состояний на стороне сервера).
3.5 Выводы по разделу
В данном разделе были рассмотрены алгоритмы функционирования автоматизированной информационной системы, а также детально рассмотрены протоколы используемые системой для настройки и конфигурирования серверного программного обеспечения.
Подобные документы
Техническое задание на разработку автоматизированной системы и складского учета управления универсальной торговой базы. Проектирование информационной системы и выбор среды для создания программного продукта. Создание интерфейса и руководство пользователя.
дипломная работа [2,1 M], добавлен 11.07.2015Диагностический анализ системы управления ООО "Система". Оценка функциональной структуры функционирующей АСУ, ее плюсы и минусы. Проектирование подсистемы "Учет разрабатываемых программных продуктов". Расчет затрат на разработку программного продукта.
дипломная работа [5,7 M], добавлен 29.06.2011Характеристика программного продукта и стадий разработки. Расчет затрат на разработку и договорной цены, эксплуатационных расходов, связанных с использованием нового программного продукта. Оценка конкурентоспособности. Изучение, оценка рыночного спроса.
курсовая работа [139,0 K], добавлен 22.09.2008Разработка программного обеспечения для микропроцессорных систем МК51, интерфейсы в системах связи, основы асинхронной связи. Этапы решения задачи на ЭВМ, принципы тестирования программ и их отладка. Расчет затрат на разработку программного продукта.
дипломная работа [270,6 K], добавлен 19.06.2010Особенности алгоритмов, критерии качества. Создание и применение программного продукта на языке Delphi. Тип операционной системы. Внутренняя структура программного продукта. Руководство пользователя и программиста, расчет себестоимости и цены программы.
дипломная работа [1,5 M], добавлен 12.06.2009Описание салона-магазина по предоставлению услуг оператора мобильной связи. Обоснование создания автоматизированной информационной системы "Оператор". Выбор программного обеспечения, проектирование реляционной базы данных. Описание основ интерфейса.
дипломная работа [1,9 M], добавлен 27.05.2015Структура программного комплекса и UML–представление программного обеспечения. Анализ статических нагрузок на пользователя при работе за компьютером. Руководство пользователя, программиста и системного администратора. Ошибки фискальных регистраторов.
дипломная работа [3,4 M], добавлен 02.09.2013Перечень основных требований к базе данных "Сведения о простоях". Процесс создания таблиц и связей между ними. Результаты выполнения запросов и форма выведения отчетов. Разработка интерфейса программы. Руководство для администратора и пользователя.
курсовая работа [3,7 M], добавлен 11.11.2012Современное планирование и управление информационными ресурсами предприятия. Интеграция организаций на базе информационных технологий. Разработка программного комплекса "ФОЛИО-КУПЕЦ". Задачи, решаемые применением корпоративной информационной системы.
курсовая работа [93,2 K], добавлен 12.10.2013Оснащенность предприятия системным программным обеспечением, используемым для организации производственного процесса. Проектирование, внедрение и эксплуатация системного и прикладного программного обеспечения. Тестирование и отладка программного продукта.
отчет по практике [272,2 K], добавлен 29.12.2014