6.2 Выбор языка программирования.

Поскольку созданный модуль предназначен для генерации SQL кода на основе ER диаграмм, то для начала необходимо определить, какие базы данных будут разрабатываться. Данный модуль предназначен только для реляционных баз данных и не поддерживает иерархические и сетевые. Код будет генерироваться при использовании любой модели данных, но правильная работа возможно только с реляционной моделью. Реляционные базы данных в настоящее время используются в небольших компаниях для хранения информации о клиентах, продукции или чего – либо ещё. Java Script был выбран в качестве языка разработки потому, что он обладает не плохой скоростью исполнения кода, объектно – ориентирован и обладает довольно простым C – подобным синтаксисом и поддерживает автоматическое приведение типов. Также к преимуществам можно добавить, что JavaScript исполнится на любой windows платформе, не требуя дополнительной закрузки каких-либо компонентов, а также этот язык активно развивается и программирование на JavaScript существенно упростилось благодаря библиотекам - помошникам, таким как jquery.

II. Конструкторско-технологическая часть работы. Обоснование выбора объектно-ориентированного подхода для реализации модуля.

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

Плюсами объектно – ориентированного подхода для разработки современной программной продукции являются:

• повышенно надежна и проста для сопровождения — правильное проектирование обеспечивает простоту расширения и модификации объектно-ориентированных программ. Модульная структура позволяет вносить независимые изменения в разные части программы, сводя к минимуму риск ошибок программирования;

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

Что касается самой разработки программ, то можно отметить, что сама разработка часто приводит к необходимости создания многослойных приложений, где выполнение объектом требуемого действия сводится к множеству обращений к объектам более низкого уровня, что при объектно – ориентированном подходе к разработке уменьшает время выполнения программы. Опять же уменьшается и время разработки. А использование методологии RUP делает процесс разработки программы более наглядным и понятным. По сути в настоящее время объектно – ориентированное программирование уже не является столько программированием, сколько разработкой программ с помощью различных средств. Сейчас это скорее процесс продумывания архитектуры программы, а не способ её конкретной реализации.

III. Решение задач на эвм

1.Разработка алгоритма решения задачи в системе StarUml.

Алгоритм работы модуля основан на широком наборе средств API (Application Programming Interface), предоставляемых со стороны программы StarUML. Внешний API StarUML - стандартизированный интерфейс программирования, который позволяет использовать внутренние функциональные возможности программы извне.

Алгоритм работы модуля можно условно разделить на несколько

разделов, каждому из которых соответствует своя функция. Первоначально осуществляется перебор всех элементов приложения StarUML сверху до низу через пространства имён пакетов, классов, интерфейсов и т.д. Осуществляет этот перебор функция “VisitOwnedElement(UML.prj)”. В процессе работы данной функции происходит перебор всех элементов, включая подчиненные элементы. Такой перебор необходим для того, чтобы найти все ассоциации на диаграмме классов. Ассоциации являются отправной точкой в работе модуля, поскольку они определяют, какие классы связаны друг с другом и каков тип этой связи. В процессе перебора в переменную “Elem” записывается ссылка на текущий объект, таким образом, если встречается объект типа ассоциация, ссылка на этот объект также записывается в переменную “Elem”. Далее осуществляется запуск функции WriteScript, сначала с аргументом 0, а затем с аргументом 1, при этом соответственно 0 это индекс доступа к первой роли, а 1 – индекс доступа ко второй роли.

В рамках функция “WriteScript”, непосредственно осуществляется

генерация SQL-запросов. Как уже было сказана, в качестве аргумента,

функция получает индекс доступа одной из ролей. Далее в переменную

“AssEnd” записывается ссылка на текущую роль, то есть на объект

UMLAssociationEnd. Получение ссылки на данный объект необходим для того, чтобы через него, далее получит ссылку на объект типа класс, который с точки зрения модели сущность-связь, представляет собой таблицу. После того, как в переменную “Table” записывается ссылка на класс, запускается функция “CheckTabe(NmTb)”. Данная функция необходима для того, что проверить, что для текущей таблицы уже не сгенерирован SQL-запрос на создание. В процессе проверки, имя текущей таблицы, которое функция получает в качестве входного параметра, сравнивается с каждым элементом массива “TableArry”. Массив “TableArry”, хранит все имена таблиц, запросы на создание которых уже сгенерированы. Если в процессе сравнения не встретится ни одного совпадения, то функция возвращает значение “true”, что означает, что запрос на создание данной таблицы не существует и его следует создать. Далее непосредственно осуществляется генерация SQL-запроса, при этом имя класса используются, как имея таблицы, а имена атрибутов и их свойств, соответственно, используются как имена и свойства полей таблицы. В процессе дальнейшей работы функции “WriteScript” осуществляется построчный вывод SQL-запроса, в поле сообщений(Message), при этом в качестве элементов каждой строки запроса используются определенные значения свойств атрибутов, а именно свойств “InitialValue” и “Type”. Значение свойства “InitialValue” определяет, каким является поле: обычным, первичным или внешним ключом. Значение свойства “Type” определяет тип данных, которые могут храниться в данном атрибуте таблицы. В случаи если в процессе генерации SQL-запроса встречается внешний ключ, то запускается функция “FindRef”, её выходным параметром является имя таблицы, на которую осуществляется ссылка, по данному полю. После того, как будет закончен вывод SQL-запроса на создание текущей таблицы, все предыдущие действия повторяются, таким образом, осуществляется вывод SQL-запросов на создание всех остальных таблиц, присутствующих на диаграмме, в качестве классов. Схема обобщенного алгоритма работы модуля представлена на рисунке 1.