Подготовка исходных данных для разработки новой версии БД

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

Исходные данные для внесения изменений и получения новой версии БД включают:

– схему эксплуатируемой предыдущей версии БД в среде AllFusion Erwin Data Modeler (по возможности) или структура таблиц данных конкретной БД (при первоначальном формировании схемы);

– совокупность отчетов по старой схеме БД в среде AllFusion Erwin Data Modeler;

– эксплуатируемую физическую БД;

– исходные данные для изменений по форме некоторого установленного документа пользователя;

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

Формы документов, предназначенных для документального оформления требований по внесению изменений в эксплуатирующуюся БД, получению исходных данных для заполнения БД и выпуску новой ее версии, регламентируется внутренними распоряжениями или документами пользователя. Рекомендуется по возможности приближать вид этих документов к отчетам AllFusion Erwin Data Modeler для схем моделей БД.

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

– запустить CASE систему AllFusion Erwin Data Modeler;

– загрузить существующую модель старой БД в AllFusion Erwin Data Modeler или получить ее средствами AllFusion Erwin Data Modeler, операция “Reverse engineering”;

– получить доступ к эксплуатируемой БД;

– произвести полное сравнение существующей модели БД с физической БД средствами AllFusion Erwin Data Modeler для контроля их соответствия;

– при наличии отклонений произвести выяснение причин различий и привести в соответствии схемы модели БД структуре физической БД;

– получить полную логическую и физическую схемы БД со всеми ее подсхемами, таблицами, столбцами и их характеристиками;

– произвести анализ исходных данных для внесения изменений и определения оптимального варианта их включения в новую версию БД;

– на основе анализа получить более полный, исправленный и детализированный перечень вносимых изменений в БД по структуре отчетов AllFusion Erwin Data Modeler для БД (вставка, замена, удаление элементов схемы).

Рис. 5.36. Схема технологического процесса этапа подготовки исходных данных для новой версии БД

6. Язык UML, модели ПО, объектно–ориентированный анализ и проектирование ПО.

Язык UML представляет собой общецелевой язык визуального моделирования, который разработан для спецификации, визуализации, проектирования и документирования компонентов программного обеспечения, бизнес–процессов и других систем. Язык UML является достаточно строгим и мощным средством моделирования, который может быть эффективно использован для построения концептуальных, логических и графических моделей сложных систем различного целевого назначения. Этот язык вобрал в себя наилучшие качества и опыт методов программной инженерии, которые с успехом использовались на протяжении последних лет при моделировании больших и сложных систем.

С точки зрения методологии ООАП достаточно полная модель сложной системы представляет собой определенное число взаимосвязанных представлений (views), каждое из которых адекватно отражает аспект поведения или структуры системы. При этом наиболее общими представлениями сложной системы принято считать статическое и динамическое, которые в свою очередь могут подразделяться на другие более частные.

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

Уровень представления (layer) — способ организации и рассмотрения модели на одном уровне абстракции, который представляет горизонтальный срез архитектуры модели, в то время как разбиение представляет ее вертикальный срез.

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

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

Рис. 6.1. Взаимосвязь моделей ООАП

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

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

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

Однако, UML – это всего лишь язык моделирования; он является одной из составляющих процесса разработки программного обеспечения. Хотя UML не зависит от моделируемой реальности, лучше всего применять его, когда процесс моделирования основан на рассмотрении вариантов использования, является итеративным и пошаговым, а сама система имеет четко выраженную архитектуру.

UML не является языком визуального программирования, но модели, созданные с его помощью, могут быть непосредственно переведены на различные языки программирования. Иными словами, UML–модель можно отобразить на такие языки, как Java, C++, Visual Basic и даже на таблицы реляционной базы данных. Те понятия, которые предпочтительно передавать графически, так и представляются в UML; те же, которые лучше описывать в текстовом виде, выражаются с помощью языка программирования.

Такое отображение модели на язык программирования позволяет осуществлять прямое проектирование: генерацию кода из модели UML в какой–то конкретный язык. Можно решить и обратную задачу: реконструировать модель по имеющейся реализации.

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

Дата добавления: 2014-01-07