«система». Лекция автоматизированные экономические информационные системы

• Название: Лекция автоматизированные экономические информационные системы
• Дата: 11.10.2019
• Размер: 0.87 Mb.
• Имя файла: «система».doc
• Тип: Лекция; #89613
• страница: 13 из 18

ЛЕКЦИЯ 9.

ТИПОВОЕ АВТОМАТИЗИРОВАННОЕ ПРОЕКТИРОВАНИЕ. СТАДИЯ РАЗРАБОТКИ ПРОЕКТОВ.

Техническое проектирование – 2 этап. Основные задачи и особенности этапа. Проектирование базы данных (логическое проектирование)

Построение модели данных

На этапе технического проектирования формируется модель данных. Проектировщики в качестве исходной информации получают результаты анализа – комплекс функциональных и информационных моделей. Конечным продуктом этапа проектирования являются:

• 
  схема базы данных (на основании информационной модели, разработанной на этапе анализа). Схема БД содержит описание всех ее объектов: пользователей, их привилегий, таблиц, индексов, ограничений, хранимых процедур и т.п. При этом создаются не только определения этих объектов, но и сами объекты, с которыми потом работают разработчики;
  
• 
  набор спецификаций модулей системы (строятся на базе функциональных моделей).
  

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

Информационная модель и ее отображение на модель данных.

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

• 
  В информационной модели определен атрибут, представляющий собой строку длиной в 500 символов. По этому атрибуту часто осуществляется поиск в информационной системе; объем данных велик. В СУБД можно индексировать строки символов не длиннее чем 128 или 256 символов. Если осуществлять поиск без индекса, то время ответа информационной системы существенно превышает допустимое, вследствие чего придется изменить описание сущности.
  
• 
  Две диаграммы потока данных описывают различные бизнес-процессы, работающие над одними и теми же данными. Допустим, первая диаграмма описывает выписку товара со склада, а вторая — сложный отчет, отражающий состояние склада. Один процесс интенсивно модифицирует данные, второй работает в режиме чтения данных, но требует согласованности данных в течение длительного времени. Каждый из процессов описывается транзакцией над данными. В СУБД уровни изолированности транзакций реализованы так, что читающие транзакции конфликтуют с модифицирующими транзакциями. Это приводит к остановке выписки товаров со склада на время выполнения отчета, что неприемлемо для заказчика. Здесь может потребоваться очень серьезное изменение информационной модели.
  

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

Подобных примеров, когда не только информационная модель, но и другие продукты анализа не могут быть перенесены автоматически на модель данных, можно привести множество. Каждый такой случай инициирует изменение информационной модели. Решение проблемы определяется возможностями СУБД, выбранной для реализации проекта. Если проблем, не разрешаемых в рамках данной СУБД, накапливается очень много, то проектировщики могут поставить вопрос о смене СУБД. Такой вопрос поднимается именно на стадии проектирования, поскольку если уже разработчики столкнутся с подобными проблемами, то цена смены СУБД будет выше. Ясно, что одинаковых СУБД не бывает: то, что хорошо работает в одной, может плохо работать или вообще не работать в другой.

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

Оценка производительности системы.

Вопросы производительности информационной системы также влияют на отображение информационной модели на модель данных. За счет мощного сервера баз данных можно добиться большей скорости реакции системы, но мощность аппаратного комплекса ограниченна. Производительность системы в целом зависит, в том числе, и от нормализации. Часто до 80% запросов к базе данных являются выборками данных, а соединение по тому или иному атрибуту относится к затратным операциям, в первую очередь соединение по нечисловым атрибутам. Увеличить производительность системы можно посредством введения избыточной информации — денормализации. Следует отметить, что решение об этом не принимается на основе одной информационной модели — требуется внимательно проанализировать потоки данных. Критичные процессы являются хорошими кандидатами для денормализации: по времени выполнения, по частоте выполнения, по большому объему обрабатываемых данных, по частоте изменения обрабатываемой информации, по явному приоритету. Часто к денормализации прибегают в целях ускорения выполнения отчетов.

Проектирование процессов и отображение функций на модули

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

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

Определение спецификаций модулей

Это основная часть функционального проектирования. Здесь решаются следующие задачи:

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

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

Интегрирование и наследование механизмов обмена данными

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

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

Разработка требований к безопасности, доступу, обслуживанию системы

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

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

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

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

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

Ответы на эти вопросы позволят более реально оценить ситуацию и уточнить требования заказчика, формализованные аналитиками. Бывает, что заказ работоспособности системы в режиме 24х7 вовсе не является обоснованным и система простаивает, например, 50% времени. Если же требование 24х7 действительно отражает особенности данного бизнеса, то эти вопросы помогут построить соответствующую стратегию защиты данных от сбоев. Качество построенной при проектировании стратегии защиты должно быть проверено тестерами, причем их работа по генерации и проведению тестов, имитирующих отказы оборудования, должна проводиться как на этапе проектирования, так и в течение всего этапа разработки — в целях раннего обнаружения дефектов стратегии защиты данных от сбоев.