43
некоторый компонент реализует отдельные классы, то для обозначения
компонентa используется расширенный символ прямоугольника. При этом
прямоугольник компонентa делится на две секции горизонтальной линией.
Верхняя секция служит для записи имени компонентa и, возможно,
дополнительной информации, а нижняя секция – для указания реализуемых
данным компонентом классов.
В случае если компонент является экземпляром и реализует три
отдельных объекта, он изображается в форме компонентa уровня экземпляров.
Объекты, которые находятся в отдельном компоненте-экземпляре,
изображаются вложенными в символ данного компонента. Подобная
вложенность означает, что выполнение компонентa влечет за собой
выполнение операций соответствующих объектов. При этом существование
компонентa в течение времени исполнения программы обеспечивает
функциональность всех вложенных в него объектов. Что касается доступа к
этим объектам, то он может быть дополнительно специфицирован с помощью
видимости, подобно видимости пакетов.
По моему мнению разработка диаграммы компонентов предполагает
использование информации не только о логическом представлении модели
системы, но и об особенностях ее физической реализации. В первую очередь,
необходимо решить, из каких физических частей или файлов будет состоять
программная система. На этом этапе следует обратить внимание на такую
реализацию системы, которая обеспечивала бы возможность повторного
использования кода за счет рациональной декомпозиции компонентов, а также
создание объектов только при их необходимости.
Общая производительность программной системы существенно зависит
от рационального использования вычислительных ресурсов. Для этой цели
необходимо большую часть описаний классов, их операций и методов вынести
в динамические библиотеки, оставив в исполняемых компонентах только самые
необходимые для инициализации программы фрагменты программного кода.
44
После общей структуризации физического представления системы
необходимо дополнить модель интерфейсами и схемами базы данных. При
разработке интерфейсов следует обращать внимание на согласование
различных частей программной системы. Включение в модель схемы базы
данных предполагает спецификацию отдельных таблиц и установление
информационных связей между ними.
Завершающий этап построения диаграммы компонентов связан с
установлением и нанесением на диаграмму взаимосвязей между компонентами,
а также отношений реализации. Эти отношения должны иллюстрировать все
важнейшие аспекты физической реализации системы, начиная с особенностей
компиляции исходных текстов программ и заканчивая исполнением отдельных
частей программы на этапе ее выполнения. Для этой цели можно использовать
различные графические стереотипы компонентов.
При разработке диаграммы компонентов следует придерживаться общих
принципов создания моделей на языке UML. В частности, в первую очередь
необходимо использовать уже имеющиеся в языке UML и общепринятые
графические и текстовые стереотипы. В большинстве типовых проектов этого
набора достаточно для представления компонентов и зависимостей между
ними.
Диаграмма компонентов, как правило, разрабатывается совместно с
диаграммой развертывания (см. следующий параграф ВКР), на которой
представляется информация о физическом размещении компонентов
программной системы по ее отдельным узлам.
Для компонент ООО Росинфом я применил трехуровневую архитектуру
(Рисунок 9). Она включает следующие уровни:
Интерфейс взаимодействия с внешней средой.
Чаще всего этот уровень рассматривается как интерфейс
пользователя. В его рамках определяется представление данных для передачи
другим системам или пользователям, набор экранов, форм и отчетов, с
которыми имеют дело пользователи.
45
Бизнес-логика. На этом уровне реализуются основные правила
функционирования данного бизнеса, данной организации.
Предметная область. Данный уровень содержит концептуальную
схему данных, с которыми имеет дело организация. Эти же данные могут
использоваться и другими организациями в своей работе.
Уровень управления ресурсами.
На нем находятся все ресурсы, которыми пользуется система, в том
числе другие системы. Очень часто используемые ресурсы сводятся к набору
баз данных, необходимых для работы организации. На этом уровне
определяется структура используемых ресурсов и способы управления ими, в
частности, конкретное размещение данных по таблицам реляционной базы
данных или классам объектной базы данных и соответствующий набор
индексов. Чаще всего схемы баз данных оптимизируются под конкретный
набор запросов, и поэтому их структура несколько отличается от
концептуальной схемы данных, находящейся на предыдущем уровне.
Диаграмма компонентов служит частью физического представления
модели, играет важную роль в процессе и является необходимой для генерации
программного кода.
46
Рисунок 9. Архитектура компонент в подсистеме WebРобот
Диаграммы размещения
Исходя из основных положений программной инженерии цель этапа
физического проектирования это разработка детальных инструкций для
выполнения реализации автоматизированной системы. При этом на этапе
физического проектирования обычно не делают выбора в пользу тех или иных
средств реализации. Хороший физический проект должен оставлять свободу
выбора средств реализации разработчикам, выполняющим окончательное
кодирование и отладку модулей системы. Однако необходимо учитывать
физические возможности и ограничения средств реализации. К примеру, на
этапе физического проектирование можно сказать, что для хранения данных в
системе будет использоваться СУБД, назвать требования, которым она должна
47
удовлетворять, какие технологии поддерживать, но выбор конкретной СУБД
остается за разработчиками, выполняющими реализацию проекта.
Архитектура системы автоматизации «Росинфом ».
На основании концептуального и логического дизайна системы
автоматизации можно сделать вывод, что система состоит из двух основных
модулей – сервера баз данных и клиентского приложения. Сервер баз данных –
центральное место хранения всех данных системы. Этот объект по
определению является единственным в системе автоматизации. Клиентское
приложение – программа, используемая пользователем для работы с
информацией, находящейся в базе данных. Система автоматизации должна
позволять нескольким сотрудникам вести работу с данными одновременно.
Исходя из вышесказанного, мною как разработчиком сделан вывод, что
для данной системы наиболее подходящий выбор – двухуровневая архитектура
«клиент-сервер».
В качестве сервера будет выступать сервер баз данных, отвечающий за
хранение и обработку всей информации.
Сервер должен поддерживать механизм хранимых процедур. В
хранимых процедурах будет реализована переменная логика системы, т. е.
специфические правила обработки данных, которые меняются год от года. При
помощи программного обеспечения управления сервером баз данных можно
будет редактировать код тех или иных хранимых процедур, для выполнения
адаптации системы к условиям проведения набора в текущем году.
Если рассматривать структуру любой системы автоматизации
относительно выполняемых функций, то в ней можно выделить три основных
элемента:
презентационный – отображение информации, доступ к
функциональности, поддержка навигации, защита целостности
пользовательского интерфейса;
прикладная логика – поддержка нужных алгоритмов, генерация
деловой информации на основе получаемых данных и защита ее целостности;
48
сервисы данных – определение структуры данных, хранение и выборка
информации, защита целостности данных.
Главная задача презентационного сервиса, или пользовательского
интерфейса, – взаимодействие с пользователем. В современных операционных
системах, поддерживающий графический интерфейс пользователя
презентационный сервис создается на основе окон и элементов управления.
Прикладная логика, или бизнес-правила, – это набор алгоритмов,
реализующих вычисления и контролирующих поток управления в приложении.
Бизнес-правила определяются конкретным видом деятельности человека, на
который рассчитано приложение. На их основе формулируются базовые
требования к приложению, ими руководствуются разработчики. На практике
бизнес-правила как раз и являются той целью, которую должно реализовать
приложение.
Сервисы данных управляют информацией, отвечают за ее сохранение и
обеспечивают функциональность, необходимую для обработки данных.
В системе автоматизации ООО Росинфом в качестве презентационного
сервиса выступает пользовательский интерфейс клиентского приложения,
который позволяет пользователю при работе с программой оперировать
понятиями предметной области.
В качестве сервиса данных выступает сервер баз данных, позволяющий
хранить, обрабатывать и выводить необходимую информацию.
Относительно сервиса прикладной логики дело обстоит несколько
иначе. Дело в том, что система автоматизации ООО Росинфом построена по
двухуровневой архитектуре клиент-сервер, но за реализацию прикладной
логики отвечает как сервер, так и клиент. На сервере баз данных при помощи
механизма хранимых процедур реализуются базовые закономерности
предметной логики, а также логика, которая с течением времени подвергается
изменениям, так как изменение кода хранимой процедуры – процесс более
простой, чем изменение кода клиентского приложения, при котором требуется
49
полная перекомпиляция приложения. Предметная логика, которая не
изменяется с течением времени, реализована в коде клиентского приложения.
Кроме того, клиентское приложение должно предоставлять
пользователю удобный графический интерфейс для работы с данными.
Интерфейс приложения не должен требовать от пользователя понимания
принципов и особенностей технической реализации системы.
Код приложения получает доступ к серверу посредством некоторого
механизма доступа к данным, при этом обязательна поддержка возможности
работы через компьютерную сеть.
Общая схема развертывания системы ООО Росинфом приведена на
(Рисунок 10).
Рисунок 10. Схема развертывания системы ООО Росинфом
50
Проектирование таблиц базы данных.
Для выполнения физического проекта будущей базы данных бала
использована реляционная модель представления данных [13], так как
подавляющее большинство современных СУБД реализовано именно на основе
этой модели.
На основании логической модели данных и выделенных сущностей
системы автоматизации «Росинфом » были выделены таблицы базы данных.
В ходе детального рассмотрения результатов анализа предметной
области было выявлено большое количество информационных полей, которые
должны храниться для каждой из сущностей при этом выделились еще
некоторые сущности.
В целях устранения избыточности хранимых данных была проведена
нормализация таблиц баз данных.
Нормализация – это процесс приведения структур данных в состояние,
обеспечивающее лучшие условия выборки, включения, изменения и удаления
данных. Это достигается разбиением одной большой таблицы на две более
мелкие таблицы. Конечной целью нормализации является получение такого
проекта базы данных, в котором каждый факт появляется лишь в одном месте,
т. е. исключена избыточность. Это делается не столько с целью экономии
памяти, сколько для исключения возможной противоречивости хранимых
данных.
В ходе проведения нормализации все таблицы базы данных были
приведены к третьей нормальной форме, так как третья нормальная форма
обеспечивает хороший баланс между пользой от устранения дублирования
данных и накладными расходами вычислительных ресурсов, затрачиваемых на
обеспечение целостности данных. Кроме того, с возрастанием уровня
нормализации таблиц возрастает сложность запросов для добавления, выборки,
изменения и удаления данных.
51
Выводы
1. В соответствии с результатами исследования предметной области
была построена диаграмма потоков данных системы автоматизации
«Росинфом», с помощью которой были выделены основные подсистемы,
потоки данных между ними, а также проанализирован характер связей между
подсистемами.
2. Выделены основные сущности системы автоматизации, определены
отношения между ними, в результате чего была построена инфологическая
модель данных, которая в дальнейшем будет использоваться при
проектировании физической модели базы данных.
3. Подробное рассмотрение процессов внутри подсистем и между
ними позволило осуществить выбор комерческой организации системы в
пользу двухуровневой архитектуры «клиент-сервер».
4. На основании рассмотрения инфологической модели данных был
определен набор таблиц базы данных. Все таблицы были приведены к третьей
нормальной форме, так как третья нормальная форма обеспечивает баланс
между пользой от устранения избыточности данных и накладными расходами,
необходимыми для поддержки целостности данных.
52
ГЛАВА 3. ПРОГРАММНАЯ МОДЕЛЬ СИСТЕМЫ
Прежде чем приступать непосредственно к реализации системы,
необходимо осуществить выбор платформы, на которой система будет
функционировать, а также выбрать средство разработки, с помощью которого
будут реализованы модули системы.
3.1. Выбор платформы для выполнения реализации системы
автоматизации «Росинфом »
Любая платформа для функционирования программного обеспечения
есть совокупность аппаратного обеспечения и операционной системы ОС,
функционирующей на средствах вычислительной техники.
Можно сказать, что выбор аппаратной платформы и ОС для реализации
системы автоматизации ООО Росинфом был предопределен поскольку бюджет
не включал покупку новых аппаратных средств и ОС.
Относительно выбора операционной системы можно сказать, что дело
здесь обстоит аналогично выбору аппаратной платформы. Принятым
стандартом де-факто на предприятии является операционные системы
семейства Microsoft Windows. Все эти ОС поддерживают общий интерфейс
прикладного программирования (API), это в частности означает, что
приложение, работающее на одной из ОС Windows будет работать на всех ОС
семейства Windows, независимо от внутренней архитектуры операционной
системы. Исключением являются лишь некоторые приложения, чье
функционирование непосредственно связано с прямым обращением к
аппаратному обеспечению, а также приложения, которые предъявляют
специальные требования к уровню надежности сервисов операционной
системы (аппаратные отладчики, диагностические средства, серверное ПО и т.
д.).
Следует отметить, что исходя из требований физической модели
системы необходимо обеспечить, чтобы клиентское приложение не
предъявляло специальных требований к ОС и было способно функционировать
на любой ОС семейства Windows.