Дипломная работа: Автоматизация разработки модели бизнес-процесса для проекта системы корпоративной информационной (на примере ООО "Гепард")
Внимание! Если размещение файла нарушает Ваши авторские права, то обязательно сообщите нам
35
хранение, управление и целостность данных, а также обеспечивает
возможность одновременного доступа нескольких пользователей. Клиентская
часть представлена так называемым “толстым” клиентом, то есть приложением
(АРМ) на котором сконцентрированы основные правила работы системы и
расположен пользовательский интерфейс программы. При всей простоте
построения такой архитектуры, она обладает множеством недостатков,
наиболее существенные из которых - это высокие требования к сетевым
ресурсам и пропускной способности сети компании, а также сложность
обновления программного обеспечения из-за “размазанной” бизнес-логики
между АРМом и сервером БД. Кроме того, при большом количестве АРМов
возрастают требования к аппаратному обеспечению сервера БД, а это, как
известно, самый дорогостоящий узел в любой информационной системе.
Как видим, минусов у такой архитектуры достаточно, а решение
тривиально - нужно отделить бизнес-логику от клиентской части и СУБД,
выделив ее в отдельный слой. Так и поступили разработчики и следующим
шагом развития клиент-серверной архитектуры стало внедрение среднего
уровня, реализующего задачи бизнес-логики и управления механизмами
доступа к БД (рисунок 1.5).
Рис. 1.5. Трехуровневая клиент-серверная архитектура
Плюсы данной архитектуры очевидны. Благодаря концентрации бизнес-
логики на сервере приложений, стало возможно подключать различные БД.
36
Теперь, сервер базы данных освобожден от задач распараллеливания работы
между различными пользователями, что существенно снижает его аппаратные
требования. Также снизились требования к клиентским машинам за счет
выполнения ресурсоемких операций сервером приложений и решающих теперь
только задачи визуализации данных. Именно поэтому такую схему построения
информационных систем часто называют архитектурой “тонкого” клиента.
Но, тем не менее, узким местом, как и в двухуровневой клиент-серверной
архитектуре, остаются повышенные требования к пропускной способности
сети, что в свою очередь накладывает жесткие ограничения на использование
таких систем в сетях с неустойчивой связью и малой пропускной способностью
(Internet, GPRS, мобильная связь).
Существует еще один важный момент использования систем,
построенных на такой архитектуре. Самый верхний уровень (АРМы), в целом
обладающий огромной вычислительной мощностью, на самом деле
простаивает, занимаясь лишь выводом информации на экран пользователя. Так
почему бы не использовать этот потенциал в работе всей системы? Рассмотрим
следующую архитектуру (рисунок 1.6) которая позволяет решить эту задачу.
Рис. 1.6 Распределенная архитектура системы
Еще два-три года назад реализация такой архитектуры системы для
среднего и малого бизнеса была бы не возможна из-за отсутствия
соответствующих недорогих аппаратных средств. Сегодня хороший ноутбук
37
обладает мощностью, которой несколько лет назад обладал сервер крупной
корпорации, и позволял рассчитывать множество важных и судьбоносных
отчетов для всех сотрудников этой корпорации.
Более 95 % данных, используемых в управлении предприятием, могут
быть размещены на одном персональном компьютере, обеспечив возможность
его независимой работы. Поток исправлений и дополнений, создаваемый на
этом компьютере, ничтожен по сравнению с объемом данных, используемых
при этом. Поэтому если хранить непрерывно используемые данные на самих
компьютерах, и организовать обмен между ними исправлениями и
дополнениями к хранящимся данным, то суммарный передаваемый трафик
резко снизиться. Это позволяет понизить требования к каналам связи между
компьютерами и чаще использовать асинхронную связь, и благодаря этому
создавать надежно функционирующие распределенные информационные
системы, использующие для связи отдельных элементов неустойчивую связь
типа Интернета, мобильную связь, коммерческие спутниковые каналы. А
минимизация трафика между элементами сделает вполне доступной стоимость
эксплуатации такой связи. Конечно, реализация такой системы не элементарна,
и требует решения ряда проблем, одна из которых своевременная
синхронизация данных.
Каждый АРМ независим, содержит только ту информацию, с которой
должен работать, а актуальность данных во всей системе обеспечивается
благодаря непрерывному обмену сообщениями с другими АРМами. Обмен
сообщениями между АРМами может быть реализован различными способами,
от отправки данных по электронной почте до передачи данных по сетям.
Еще одним из преимуществ такой схемы эксплуатации и архитектуры
системы, является обеспечение возможности персональной ответственности за
сохранность данных. Так как данные, доступные на конкретном рабочем месте,
находятся только на этом компьютере, при использовании средств шифрования
и личных аппаратных ключей исключается доступ к данным посторонних, в
том числе и IT администраторов.
38
Такая архитектура системы также позволяет организовать
распределенные вычисления между клиентскими машинами. Например, расчет
какой-либо задачи, требующей больших вычислений, можно распределить
между соседними АРМами благодаря тому, что они, как правило, обладают
одной информацией в своих БД и, таким образом, добиться максимальной
производительности системы.
Таким образом, предложенная модель построения распределенных
систем вполне способна решить и реализовать функции современного
программного обеспечения для предприятий среднего и малого бизнеса.
Построенные на основе данной архитектуры системы будут обладать
надежностью, безопасностью информации и высокой скоростью вычислений,
что от них в первую очередь и требуется.
Обратимся к этапам проектирования корпоративных информационных
систем.
1.Анализ
Обследование и создание моделей деятельности организации, анализ
(моделей) существующих КИС, анализ моделей и формирование требований к
КИС, разработка плана создания КИС.
2.Проектирование
Концептуальное проектирование, разработка архитектуры КИС,
проектирование общей модели данных, формирование требований к
приложениям.
3.Разработка
Разработка, прототипирование и тестирование приложений, разработка
интеграционных тестов, разработка пользовательской документации.
4.Интеграция и тестирование
Интеграция и тестирование приложений в составе системы, оптимизация
приложений и баз данных, подготовка эксплуатационной документации,
тестирование системы.
5.Внедрение
39
Обучение пользователей, развертывание системы на месте эксплуатации,
инсталляция баз данных, эксплуатация.
6. Сопровождение
Регистрация, диагностика и локализация ошибок, внесение изменений и
тестирование, управление режимами работы ИС.
Анализ начинается с определения требований и назначения
подмножества этих требований программному элементу.
На этом этапе начинается решение задачи планирования проекта ПО.
В ходе планирования проекта определяются:
- объем проектных работ;
- риск проектных работ;
- необходимые трудозатраты;
- формируются рабочие задачи;
- формируется план-график работ.
Анализ требований, относящийся к программному элементу, т.е. к ПО,
уточняет и детализирует:
- функции ПО;
- характеристики ПО;
- интерфейс ПО.
Все определения документируются в спецификации анализа.
Проектирование создает представления:
- архитектуры ПО;
- модульной структуры ПО;
- алгоритмической структуры ПО;
- входного и выходного интерфейса (входных и выходных форм данных).
Кодирование (реализация)состоит в переводе результатов
проектирования в текст на языке программирования.
Тестирование – это выполнение программы для выявления дефектов в
функциях, логике и форме реализации программного продукта.
Источник: https://baza.diplomsite.ru/previewfile/2192