3 обзор технологии qreal

САНКТ-ПЕТЕРБУРГСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ
Математико-механический факультет
Кафедра системного программирования
ГЕНЕРАЦИЯ ПРОГРАММ НА ЯЗЫКЕ EIFFEL
НА ОСНОВЕ UML МОДЕЛИ
Допустить к защите
Зав. каф.: профессор Терехов А. Н.
_____________
Выполнила: Найдёнышева Екатерина Григорьевна
Научный руководитель: Терехов А. Н., профессор, д.ф.м.н.
Рецензент: Щербаков К. В.
Санкт-Петербург
2009 г.
2
СОДЕРЖАНИЕ
ВВЕДЕНИЕ ................................................................................................................................................................. 3
1 ОБОСНОВАНИЕ ВЫБОРА ТЕМЫ ................................................................................................................... 6
2 АНАЛИЗ СУЩЕСТВУЮЩИХ РЕШЕНИЙ ..................................................................................................... 9
2.1
IBM RATIONAL ROSE ............................................................................................................................ 9
2.2
BORLAND TOGETHER ......................................................................................................................... 10
2.3
TELELOGIC TAU G2 ............................................................................................................................. 10
2.4 STARUML ....................................................................................................................................................... 11
3 ОБЗОР ТЕХНОЛОГИИ QREAL ....................................................................................................................... 12
4 ПОСТАНОВКА ЗАДАЧИ ................................................................................................................................... 13
5 РЕАЛИЗАЦИЯ ...................................................................................................................................................... 14
ЗАКЛЮЧЕНИЕ ....................................................................................................................................................... 20
СПИСОК ЛИТЕРАТУРЫ ..................................................................................................................................... 21
2
3
ВВЕДЕНИЕ
В начале развития IT-индустрии программы решали совершенно
другие задачи, нежели современные. Они отличались малым набором
функциональных возможностей, были недоступны пониманию людей, не
обладающими
навыками
программирования,
а
профессиональных
специалистов в этой области можно было пересчитать по пальцам. В
основном программы выполняли специфические, узкоспециализированные
задачи, которые могли решаться небольшим количеством людей. Именно
поэтому для поддержания целостности проекта не требовалось специальных
средств.
Времена
изменились,
сейчас
к
программным
инструментам
предъявляются иные требования, и этот процесс не останавливается, с
каждым годом ПО становится всё сложнее и сложнее. Чтобы программные
продукты выполняли все возлагаемые на них функции, необходимо
описывать предметную область с разных точек зрения: с позиции заказчика, с
позиции аналитика, проектировщика, тестировщика и т.д. Таким образом,
они разрастаются, и чтобы они не превратились в неуправляемые громады,
необходимо сохранять согласованность взглядов. Именно для того, чтобы
облегчить проектирование и сопровождение больших проектов, используется
визуальное моделирование (представление логики программы при помощи
разнообразных диаграмм, описывающих приложение с разных позиций).
Унифицированный язык моделирования UML (Unified Modeling Language)
был разработан Г. Бучем, Дж.Рамбо и А.Якобсоном, входивших в
консорциум OMG (Object Management Group), в 1996 г. как инструмент для
моделирования сложных программных систем. Возникновение этого языка
обусловлено необходимостью создания мощного средства для анализа,
спецификации,
проектирования,
визуализации
и
документирования;
средства, прекратившего бы войну методологий, которая велась в то время,
то
есть
создания
общепринятого
стандарта,
включающего
все
3
4
положительные аспекты противоборствующих сторон. Итак, в UML
несколько типов диаграмм, которые можно разделить на три группы:

Представление статической структуры

Представление поведения
Это позволяет наиболее полно изложить принципы приложения,
охарактеризовать все его стороны работы. Таким образом, используя этот
язык, охватывается весь спектр деятельности по созданию проекта: от
описания функциональности с заказчиком до реализации. К тому же
представление работы в виде диаграмм облегчает понимание системы в
целом, давно известно, что визуальные образы легче воспринимаются
человеком, чем, например, программный код. Если использовать UML при
обсуждениях функциональности с заказчиком или руководителем проекта,
такие схемы будут восприниматься яснее всего, потому что сознание
понимает картинки лучше – это уже доказанный факт человеческой психики.
На практике большие прикладные системы создаются разными людьми, а
некоторые – разными отделами, значит, используя диаграммы проще
добиться согласованности системы, разработчикам прийти к единому взгляду
на задачи. Понятность графического представления по сравнению с разбором
программного кода также облегчает коммуникации внутри проекта,
внедрение нового персонала, переговоры с заказчиком, выкристаллизовывает
основные концепции ПО. Согласованность действий всех людей, занятых в
разработке новой системы делает управление более эффективным.
Прогресс пробуждает желание усовершенствовать существующие
технологии, более высокие требования предъявляются уже к самим методом.
Всем ясно, что сейчас недостаточно просто согласовать мнения, изобразив
логику работы приложения в наглядных картинках. Хочется, чтобы эти
картинки понимали не только люди (заказчики, проектировщики), а чтобы
диаграммы интерпретировались программами в понятный и программистам,
и компьютерам код. То есть, та работа, которая была проделана при
проектировании, не терялась, не дублировалась программистами, чтобы
4
5
автоматически создавалась некоторая часть кода. Современная задача
предполагает чтобы по нарисованным в инструментальном средстве
диаграммам
автоматически
генерировался
исполняемый
код
самого
приложения. Это позволяет абстрагироваться от конкретного языка
программирования, сосредоточив внимание на разработке UML-модели, в
которой отображается бизнес-логика и поведение всей системы. Таким
образом, высвобождается больше времени для улучшения качества,
детального продумывания «узких» мест.
Именно поэтому большую популярность в IT-среде получил метод
разработки
MDA
(Model
Driven
преимуществами
являются
приложения
технических
от
Architecture).
отделение
деталей
принципов
реализации.
Его
и
несомненными
логики
работы
Инструментальные
средства, поддерживающие MDA должны использовать UML-модели.
Немаловажным
преимуществом
подхода
является
использование
общепринятого стандартизированного языка моделирования. Принципы
работы MDA можно описать следующим образом: на начальном этапе,
используя язык UML, формируется платформенно-независимая модель
приложения, затем с помощью этой модели создается платформеннозависимая модель. На заключительном этапе автоматически генерируется
исполняемый код приложения.
Как
выяснилось,
поддерживают
решений
существует
стандарт
показало,
что
не
построения
представлено
так
MDA.
много
средств,
Изучение
совсем немного
которые
существующих
программных
продуктов, позволяющих, по диаграммам генерировать исполняемый код. И,
к сожалению, тем, которые поддерживают эту концепцию потребуется время,
чтобы развиться и использовать всю мощь данного метода. Проанализируем
представленные средства.
5
6
1 ОБОСНОВАНИЕ ВЫБОРА ТЕМЫ
Существует множество языков, которые соответствуют принципам
объектно-ориентированного программирования. Но чтобы качественно
выделятся из толпы конкурентов необходимо идти в ногу со временем,
поддерживать самые передовые технологии. Одной из интереснейших
технологий является «проектирование по контракту». Эта идея была
разработана и впервые воплощена Бертраном Мейером [] в 1986 при
создании
объектно-ориентированного
языка
программирования
Eiffel.
Изначально этот язык, спроектированный в 1985г., разрабатывался для
внутренних потребностей компании Eiffel Software (затем известной как ISE),
нуждающейся в мощном инструменте. Как коммерческий продукт он был
представлен на конференции OOPSLA в октябре 1986г., где он привлек
всеобщее внимание. С этого времени началось его победное шествие в мире
ИТ-индустрии.
Язык Eiffel получил своё название в честь знаменитого архитектора
Густава Эйфеля. Его проект – строительство легендарной башни было
приурочено к Всемирной Выставке 1889 года. Самое важное, что она была
возведена точно вовремя и не выходила за рамки бюджета, такую же
характеристику имеют и проекты, написанные на Eiffel. По статистике более
45% современных разработок нарушают временные и финансовые границы,
что влечет за собой потерю конкурентоспособности, а значит престижа и
доходности компании. Такие неудачи исключены при программировании на
Eiffel. Залогом успеха является рассмотрение системы как набора классов,
связанных между собой контрактами. Контракт – мнемоничное понятие. Как
и в жизни когда в договоре указываются гарантии для клиента, которые, в
свою очередь, являются обязательствами поставщика, в программирование –
проектирование по контракту – это установление отношений между классом
и его клиентами в виде формального соглашения. Такую семантику можно
записывать с помощью утверждений, которые делятся на предусловия,
6
7
постусловия, а также инварианты. Это позволяет создавать корректные
программы.
Стоит заметить, что сам по себе класс не может быть корректным или не
корректным. На этот вопрос можно ответить только с помощью
его
спецификации. Класс считается корректным, если он согласован со своей
спецификацией, которая задается с помощью предусловий, постусловий и
инвариантов.
По
определению
класс
C
корректен
по
отношению
к
своим
утверждениям, тогда и только тогда, когда:
С1. Для любого правильного множества аргументов х процедуры
создания m:
{ Default C and pre m(x)} Body m { post m(x) and Inv},
С2. Для каждой экспортируемой программы n и для любого множества
правильных аргументов :
{ pre n(y) and Inv} Body n { post n(y) and Inv}.
Условные обозначения: С – класс, Inv C – инвариант, Default C –
означает тот факт, что атрибуты класса С имеют значения по умолчанию,
определенные их типами, если r - программа класса, то Body r – её тело, pre
r(x), post r(x) – её предусловие и постусловие с возможными аргументами x.
Если предусловие или постусловие для программы r опущены, то будем
считать их заданными константой True.
То есть, тело программы выполняется, если верны утверждения в первых
скобках, и если тело процедуры выполнилось за конечное время, то
гарантируется обеспечение условий в последних фигурных скобках.
Таким образом,
в языке Eiffel воплощается один из важнейших
факторов – корректность. Но спецификация применяется не только для
доказательства корректности, она также помогает создавать элегантный и
читабельный код, что упрощает его сопровождение и отладку, упрощает
создание программной документации, улучшает понимание проблемы и
достижение ее решения. Благодаря такой изящной и красивой структуре,
7
8
язык Eiffel используется в качестве обучающего языка, прививающего
понятие
объектно-ориентированного
программирования,
во
многих
университетах по всему миру.
Из-за популярности к языку Eiffel, к нему предъявляются и повышенные
требования. Несомненным достоинством языка является Reverse Engineering.
Это возможность построить схему программы, опираясь на её исполняемый
код. Именно поэтому, существует острая необходимость обратной задачи –
Forward Engineering’а – создать технологию, позволяющую по диаграммам –
обобщенному макету проекта, автоматически сгенерировать исполняемый
код.
8
9
2 АНАЛИЗ СУЩЕСТВУЮЩИХ РЕШЕНИЙ
В настоящее время на рынке представлено множество caseсредств, помогающих рисовать красивые диаграммы, но как
оказалось, лишь немногие из них способны воплотить принципы
MDA подхода. Некоторые из них обладают полной кодогенерацией,
некоторые – только каркасной, одни – распространяются платно, у
других
есть
льготные
условия,
часть
поддерживает
многоплатформенность, остальные – нет. Но, о каждом по порядку.
2.1
IBM RATIONAL ROSE
Компания IBM предлагает богатый перечень продуктов данной
линейки. Rational Rose Modeler предназначен только для анализа и
проектирования, никакой кодогенерации не производится. Rational
Rose Professional предлагает прямое и обратное проектирования,
возможна
частичная
кодогенерация
на
выбранном
языке
программирования, т.е подходит только для определенного языка,
под который настраивается конфигурация и полученный код придется
дорабатывать вручную. Используя Rational Rose RealTime можно
получить
полностью
исполняемый
код,
прямое
и
обратное
проектирование только на языках C и C++ (то есть такое
проектирование, при котором по исполняемому коду можно
сгенерировать модель системы и наоборот). Rational Rose Enterprise
включает в себя все описанные выше компоненты, за исключением
100%
кодогенерации.
Это
коммерческий
продукт,
распространятся бесплатно для обучающих целей.
но
может
Rational Rose
позволяет поддерживать соответствие кода и модели при их
изменениях.
9
10
2.2
BORLAND TOGETHER
Этот продукт, предоставленный компанией Borland обладает
схожими достоинствами: синхронизация кода и модели, прямое и
обратное
проектирование,
использование
стандартизированного
языка UML, причем поддержка всех видов диаграмм. Приятными
преимуществами являются поддержка уже выработанных в компании
шаблонов, чтобы сотрудники придерживались принятых в их отделах
стандартов проектирования, и постоянный контроль качества,
возможный благодаря встроенному функциональному тестированию,
однако,
отсутствует
возможность
создания
пользовательских
редакторов. Добавим к сказанному автоматическую генерацию
документации и бесплатно распространяемые продукты данной
линейки. Для определенных технологий разработки, таких как .Net, у
Borland есть отдельные редакции. Имеется построение каркасного
кода приложения, но, к сожалению, 100% кодогенерации не
происходит.
2.3
Средство
TELELOGIC TAU G2
моделирования
TAU
G2
достаточно
удобно
в
использовании. В его достоинства входит многоплатформенность
(Windows, Linux, Solaris), верификация, интегрируемость в некоторые
среды
(.Net
и
Eclipse).
Кодогенерация
возможна
только
в
TAU/Developer для C, C++ и Java. Все продукты являются платными,
для учебных целей возможно соглашение на более мягких условиях.
10
11
2.4 STARUML
К положительным особенностям следует отнести то, что этот
пакет поддерживает подход MDA, то есть способен автоматически
создавать код приложения, правда только на языках C, C++ и Java,
также он обладает открытым кодом, расширяется с использованием
паттернов и генерирует документацию проекта. Однако является
одноплатформенным (Windows).
11
12
3 ОБЗОР ТЕХНОЛОГИИ QREAL
Case-средство
QReal
разрабатывается
на
кафедре
системного
программирования СПбГУ 3 года. Архитектура основывается на схеме
Model/View и включает в себя репозиторий и набор редакторов. Репозиторий
реализует функциональность модели, а редакторы являются реализациями
представлений. Особенностями этого инструмента являются:

Многоплатформенность (Windows, Linux, МАС OS)

Возможность многопользовательской работы

Включает полный набор диаграмм UML 2.1

Логические и графические модели хранятся в репозитории

Разрабатываются генераторы в C#, Java, PADL (VHDL)
К репозиторию можно обращаться не только с локальной машины, но и в
удаленном доступе, то есть из глобальных сетей, таких как Internet. В связи с
этими требованиями возможности распределенной работы, репозиторий
реализован в соответствии с архитектурой клиент/сервер, т.е. клиентская
часть встроена в сам CASE-пакет, а серверная может физически
располагаться на другом компьютере, доступном по локальной сети. Это
позволяет набору генераторов оперативно обращаться к репозиторию,
который хранит данные и предоставляет интерфейсы доступа к ним других
компонент. Серверная часть реализована как надстройка над СУБД. Чтобы
обеспечить кроссплатформенность при реализации графического интерфейса
применялись платформо-независимые инструментарии.
12
13
4 ПОСТАНОВКА ЗАДАЧИ
Итак, необходимо создать технологию, благодаря которой появится
возможность автоматически генерировать исполняемый код программы на
языке Eiffel, используя предложенные виды диаграмм UML 2.1. Язык
моделирования UML может визуализировать концепции работы программы с
разных позиций, для нас наибольший интерес представляет описание
структуры приложения и семантики поведения, поскольку с их помощью
можно создать код.
Для представления статической структуры программы, на наш взгляд,
удобно использовать диаграмму классов. Поскольку в этом виде диаграмм
указывается иерархия, атрибутивность и поведенческая структура классов
системы, то есть их поля, методы, а также взаимозависимости между
классами.
Для представления поведения была выбрана диаграмма состояний.
Этот тип диаграмм представляет конечный автомат []. Вершинами графа
являются состояния, ребрами – направленные дуги – переходы. Состояние –
это элемент модели, предназначенный для визуализации ситуации, в ходе
которой поддерживается некоторое условие инварианта. Переходы –
направленное отношение между состояниями, одно из которых является
источником, а другое – целью. Переход между состояниями выполняется при
срабатывании некоторого события. Событие – спецификация условий,
которые оказывают влияние на поведение моделируемой сущности.
Таким образом, рассматриваемых видов диаграмм достаточно для
решения нашей задачи.
13
14
5 РЕАЛИЗАЦИЯ
5.1 Обзор структурных элементов языка Eiffel
Конструкции языка Eiffel можно разбить на две категории: классические
структурные элементы и специфические. Классические – это типичные для
различных языков конструкции, такие как цикл, условные переходы и т.д.
Может быть разница в нотации, но семантика у них одна и та же. Например,
в C# цикл выглядит так: for (i=1; i<9;i++) (тело цикла), а в Delphi цикл с
такой же семантикой запишется по-другому: for i:=1 to 8 do (тело цикла),
однако выполнять они будут одно и тоже. Аналогичная идея относится и к
другим классическим конструкциям. Далее будут рассмотрены условные
переходы, циклы, классы, вызовы функций. К специфическим мы относим
такие языковые конструкции, которые впервые появились в языке Eiffel. К
ним относятся предусловия и постусловия.
5.2. Проекция базовых конструкций
Логично будет начать с базовых конструкций, а затем перейти
непосредственно к особенностям языка. Проекция – это отношение
соответствия между диаграммой и программным кодом. Разработанные
проекции будут продемонстрированы с помощью тестовых примеров.
5.2.1. Условные переходы
В языке Eiffel рассматриваются два вида условных переходов: переход
типа if…then и inspect. Первый оператор ветвления может иметь или не иметь
ветви else. Сначала проверяется логическое выражение в секции if, и если
оно истинно, то выполнение передаётся в секцию then, в противном случае –
14
15
в секцию else, если она есть или происходит выход из условного оператора.
Проекцию этого оператора в UML можно представить как:
(картинка)
Второй условный оператор работает как классический переключатель,
т.е. inspect (expression)
when (value) then (do_somthing)
В отличие от if…then, где проверяемое выражение является логическим,
здесь оно может принимать различны значения, вследствие чего происходит
более обширное ветвление. Проекцию этого оператора в UML можно
представить как:
5.2.2. Цикл
Одной из самых распространенных конструкций является цикл. Сложно
представить себе современную программу, в которой есть только две
управляющие структуры – последовательность и выбор. Поэтому значение
цикла трудно переоценить. В языке Eiffel представлен один вид цикла. Он
выглядит следующим образом:
from
init
until
exit
loop
body
end
В других языках программирования, например, в Pascal, C такой цикл
называется «циклом while». Описать эффект выполнения цикла можно так:
вначале выполняется init, затем 0 или более раз выполняется тело цикла,
которое перестает выполняться, как только exit принимает значение false.
Представленную структуру можно легко получить из UML диаграмм такого
рода:
(картинка)
15
16
5.2.3. Классы
Одним из главных достижений объектно-ориентированного подхода
является объединение понятий модуля и типа в одной лингвистической
конструкции – классе. С одной стороны класс как модуль можно
рассматривать как задание синтаксической концепции, т.е. для деления
программ
на
обозримые
функциональность
и
системы.
управляемые
С
другой
части,
не
стороны,
влияющие
класс
на
является
семантической концепцией, он описывает форму объектов, которые система
создает и которыми она манипулирует.
Для проекции классов из UML наиболее удобно, на наш взгляд,
использовать диаграммы классов, потому что в этом типе диаграмм
содержится вся необходимая информация, такая как поля, методы,
отношение наследования, вложенность классов.
(картинка)
5.2.4. Вызовы функций
Поскольку Eiffel – объектно-ориентированный язык, то в нем все
функции
являются
чьими-то
методами,
а
значит,
все
заголовки
сгенерировались при проекции из диаграммы классов. Самым подходящим
представлением для описания поведения функций является композитное
состояние в диаграмме состояний. При проекции наименования состояний
сопоставляются с заголовками функций. Тело функции генерируется исходя
из логики поведения в регионе композитного состояния.
(картинка)
16
17
5.3. Проекции особых конструкций
Теперь следует рассказать о проекциях специфических управляющих
структур.
Эти
особые
утверждения
помогают
нам
не
только
в
проектировании, но и при последующей реализации, а также для понимания
программного текста. Правило контракта говорит, что предусловие дает
гарантии поставщику, если клиентская часть не выполняется, то класс
перестает быть связан постусловием. Это существенно упрощает жизнь
разработчика, теперь он смело может писать тело программы, не проверяя
ограничения.
5.3.1. Предусловия
Предусловия выражают ограничения, выполнение которых необходимо
для корректной работы функции. Предполагая, что все ограничения
выполняются, стиль программирования существенно упрощается. На вид
безобидная проверка x>=0 при вычислении квадратного корня, может
превратиться в ужасного монстра. Представьте, например, что подобные
тривиальные проверки участвуют в коде из тысячи строк. Такие
загромождения противоречат правилу простоты, усложняют программу и
ухудшают её читабельность, а значит и сопровождение.
Наличие предусловий значительно упрощает и UML диаграмму, делая ее
более понятной. Допустим, что есть некоторая функция, скажем, с пятью
аргументами. Правилом хорошего тона является проверка в теле функции ее
входных параметров. Все эти проверки должны быть отображены на
диаграмме, причем каждая из них порождает условный переход, а значит,
происходит ветвление. Раз большинство новых веток тривиальны, значит, их
следует задавать в предусловиях.
Поскольку в UML нет соответствующих конструкций для отображения
предусловий, то возможны два решения проблемы:
17
18
 добавить в UML новые узлы
 использовать уже существующие состояния.
Второй вариант мы считаем предпочтительнее, потому что при
использовании первого, теряется унифицированность UML диаграмм, а они
являются стандартом.
Для того чтобы использовать стандартизированные состояния нам
нужно разработать правила, по которым мы будем отличать предусловия от
обычных состояний,
Предлагается использовать специальное название для состояний с
предусловиями – Require Statements.
5.3.2. Постусловия
Постусловие выражает свойство состояния, завершающего выполнение
программы. Оно выражает гарантию, что если программы была запущена в
состоянии, удовлетворяющем предусловию, то программа завершится и
приведет к состоянию с заданными свойствами. Таким образом, это
позволяет создавать нам программы со встроенной надежностью, т.е.
создавать корректные программы и знать это.
Проекцией постусловий из диаграммы UML будут состояния со
специальными наименованиями – Ensure Statements.
(картинка)
5.4. Генератор
Используя эти проекции, был создан генератор, который по набору
диаграмм UML автоматически создает исполняемый код приложения.
Отрисовывая
диаграммы
в
QReal
создается
логическая
модель
приложения, которая хранится в виде графа. С помощью API QReal’а мы
18
19
можем получить доступ к этой модели. API включает в себя базовые
функции такие как: вернуть все типы, вернуть все объекты данного типа,
перебрать все ассоциации.
При генерации в первую очередь генерируется статическая стороны
классов – их взаимосвязи, поля, методы. Затем генератор обращается к
диаграмме состояний. Для каждого метода находит соответствующее
композитное состояние, и начинает строить проекцию для тела функции.
19
20
ЗАКЛЮЧЕНИЕ
В процессе дипломной работы изучен язык Eiffel, выявлены его
специфические характеристики, благодаря которым он стал популярен. К
ним относятся предусловия и постусловия. Однако в среде разработки Eiffel
нет своей системы графических средств проектирования образов. Для этого
был выбран продукт QReal, разработанный на кафедре системного
программирования СПбГУ, изучена структура его репозитория. Также
освоен язык UML и построены его проекции в Eiffel для предложенных
диаграмм: классов и состояний. В рамках данной дипломной работы
ставилась задача генерации программ, семантика которых может быть
описана с помощью этих диаграмм. К сожалению, во время разработки
проекций было обнаружено, что на данный момент UML не использует все
возможности языка Eiffel (пост- и предусловия), хотя их наличие в UML
значительно
облегчило
бы
восприятие,
понимаемость
диаграммы,
надежность сгенерированного по ней исполняемого кода. Поэтому, были
продуманы методы добавления вышеуказанных возможностей в UML,
применяя его стандартные средства. Мы выбрали данный подход, поскольку
создание его расширения уменьшило бы универсальность диаграмм, которые
мы использовали.
Работа генератора протестирована на нескольких примерах.
20
21
СПИСОК ЛИТЕРАТУРЫ
1.
Бертран Мейер. Объектно-ориентированное конструирование
программных систем. Москва: Интернет Университет Информационных
технологий, 2005, 1199с
2.
Александр Леоненков. UML 2. Санкт-Петербург: БХВ – Петербург,
2007, 576с
3.
http://unreal.tepkom.ru
4.
Karine Arnout, Eric Bezault. How to get Singleton in Eiffel? Journal of
Object Technology, 2004, 21 c
+ ещё несколько ресурсов
21