Генерация исходного кода из спецификации методологии IDEF

метки: Генерация, Стрелка, Диаграмма, Модель, Объект, Сторона, Рисунок, Вызов

Swapnil Shah в [ 1 ] рассматривает комплексное моделирование методологии IDEF, и доказывает, что IDEF это всесторонняя моделирующая методология, которая является мощнейшей для развития производственных систем. В статье также есть информацию относительно структуры и различных компонентов поддерживающего инструмента программного обеспечения. Также есть такие авторы, как Tsironis L., Gentsos A., Moustakis V., которые предоставляют свою версию об усовершенствовании языка моделирования IDEF0 в статье [5 ].

В статье [ 4 ] Канжелев С. Ю. описал подход к автоматической генерации исходного кода программ с явным выделением состояний, а также рассмотрел различные технологии и методики, описаны их преимущества и недостатки.

Роль, назначение и использование XML документов для генерации программного кода было предложено авторами Sarkar S., Cleaveland C. в своей работе [ 7 ]. В работе сказано, что использовать технологию преобразования XML документа будет легче для развития генераторы кода/документа в прикладных проектах.

Кручинин А. Н. в [ 9 ] предложил реализацию метода автоматической генерации программного кода по высокоуровневым спецификациям на примере протраммного комплекса «XpectEngine». Внедрение комплекса показало значительное сокращение времени внесения изменений в уже существующий код.

Целью данных работ [ 2 ,3 ] Грегора Кемпери и Алана Стила является обзор алгоритмов в теории инвариантов. Также в статье они демонстрируют легкие алгоритмы для вычисления несколько свойств инвариантных колец.

4. Обзор исследований и разработок

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

4.1 Общие принципы генерации кода

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

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

Программный комплекс моделирования релейно-контактных схем

... фидеров контактной сети) цифровые защиты, но даже они интегрируются в релейные схемы для надежности, поэтому и здесь от реле полностью не уйти. Целью ВКР является разработка программного ... разработке. В разделе «Разработка алгоритмов и программного комплекса» представлен код программ и то, как он работает. В шестом разделе «Реализация программных модулей» описано общая работа каждого модуля. ...

Генерацию кода можно считать функцией, определенной на синтаксическом дереве, которое построено в результате синтаксического анализа. В идеале компилятор должен выполнить синтаксический анализ всей входной программы, затем провести ее семантический анализ, после чего приступать к подготовке генерации и 2 непосредственно генерации кода [ 10 ].

Компилятор выполняет генерацию кода поэтапно, на основе законченных синтаксических конструкций входной программы. Из текста исходной программы компилятор выделяет законченную синтаксическую конструкцию, также порождает для нее фрагмент результирующего кода и помещает его в текст результирующей программы. Затем он переходит к следующей синтаксической конструкции. Так продолжается до тех пор, пока не будет разобрана вся исходная программа [ 11 ]. Необходимо отметить, что выступают блоки операторов, описания процедур и функций в качестве анализируемых законченных синтаксических конструкций. Их конкретный состав зависит от входного языка и реализации компилятора. Генерация кода почти готовой программы, соответствующего данной синтаксической конструкции выполняется в зависимости от типа синтаксической конструкции. Для семантически подобных конструкций различных входных ЯП может создаться типовой результирующий код.

4.2 Инструментарий для реализации

Программный продукт будет иметь такие структуры данных, как одномерные и двумерные массивы, списки, файлы, деревья и др., и базовые алгоритмы максимума, минимума, суммы, произведения, поиска элемента, удаления и т.п. Каждая структура данных со своими собственными переменными будет по своему уникальна. Было принято решение использовать среду разработки FlashDevelop с использованием языка программирования Action Script 3.0 чтобы не было конфликтов с совместимостью и не нарушалась логика работы алгоритмов. Для этого необходимо использовать несколько классов, каждый из которых будет уникален также как и структура данных со своим набором переменных. Каждый класс будет является структурой данных. Также это касается базовых алгоритмов, которые будут иметь свои собственные классы.

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

Для решения задачи необходимо прежде всего создать IDEF0 диаграммы, и соединить их между собой.

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

5. Концепция IDEF0

Методология IDEF0 основана на следующих концептуальных положениях.

5.1 Модель

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

Разработка программы для автоматизации работы кафе

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

5.2 Блочное моделирование и его графическое представление

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

5.3 Точность и сжатость

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

5.4 Передача информации

Средства IDEF0 облегчают передачу информации от одного участника разработки модели к другому. Средства:

1. диаграммы;
2. метки на естественном языке;
3. последовательная декомпозиция диаграмм;
4. древовидные схемы иерархии диаграмм и блоков.

5.5 Строгость и формализм

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

5.6 Итеративное моделирование

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

6. Семантика языка IDEF0

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

6.1 Семантика блоков и стрелок

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

У блока каждая сторона имеет своё предназначение с точки зрения связи блок/стрелки. Каждая сторона блока определяет свою роль. Если стрелка присоединена к блоку слева, то она является входной. Входы преобразуются или расходуются функцией, чтобы создать то, что появится на её выходе. Если стрелка присоединена к блоку сверху, то она является управлением. Управления прежде всего определяют условия, которые необходимы для функции для произведения верного выхода. Если стрелка выходит из блока справа, то она является выходной. Выходы – это данные или материальные объекты, которые были созданы функцией. Если стрелка присоединена к блоку снизу, то она является механизмом. Если стрелка направленна вверх, то она идентифицирует средства, которые поддерживают работу функции[ 8 ]. Если стрелка механизма направленна вниз, то она является стрелкой вызова, а значит она обозначает обращение из данный модели (или части модели) к блоку, который входит в состав другой модели (или другой части модели) и поддерживает связь. Тем самым разные модели или разные части одной и той же модели могут вместе использовать один и тот же элемент. На рисунке 2 для примера представлены виды стрелок.

Модели жизненного цикла автоматизированных информационных систем

... (v-shapedmodel); модель прототипирования (prototypemodel); модель быстрой разработки приложений, или RAD-модель (RAD-rapidapplicationdevelopmentmodel); многопроходная модель (incrementalmodel); спиральная модель (spiralmodel). ГЛАВА 1. Модели жизненного цикла автоматизированных информационных систем 1.1 Жизненный цикл АИС Жизненный цикл автоматизированных информационных систем - это непрерывный ...

6.2 Имена и метки

Имена функций должны быть в глагольной форме. К примеру: обработать запрос, заблокировать доступ к БД, удалять. Каждая стрелка должна быть именована в существительной форме. К примеру: загрузка, изменённая БД, имя клиента. На рисунке 3 представлен пример отображения метки стрелки.

6.3 Семантические правила блоков и стрелок

Название блока должно быть в глагольной форме.

Каждая сторона блока должна иметь стандартное отношение блок/стрелки:

1. входные стрелки присоединены к левой стороне блока;
2. управляющие стрелки присоединены к верхней стороне блока;
3. выходные стрелки присоединены с правой стороной блока;
4. стрелки механизма (кроме стрелок вызова) указывают вверх и присоединены к нижней стороне блока;
5. стрелки вызова механизма указывают вниз, присоединены к нижней стороне блока и именуются ссылкой на вызываемый блок.

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

В метках стрелок ни в коем случае нельзя использовать такие термины, как:

1. функция;
2. вход;
3. выход;
4. управление;
5. механизм;
6. вызов.

6.4 Диаграммы IDEF0

Есть 3 типа документов, которые входят в состав IDEF0-модели:

1. графическая диаграмма;
2. текст;
3. глоссарий.

Графическая диаграмма – это главный компонент IDEF0-модели, который содержит блоки, стрелки, соединения блоков и стрелок. Блоки показывают функции объекта[ 8 ]. Эти функции могут быть разбиты на составные части и представлены в виде подробных диаграмм. Пока объект не будет описан на уровне детализации, который необходим для достижения целей конкретного проекта, процесс декомпозиции будет продолжаться.

6.5 Контекстная диаграмма верхнего уровня

Каждая модель должна иметь контекстную диаграмму верхнего уровня, в которой есть объект моделирования, изображённый одним блоком и стрелками связанными с ним. Такая диаграмма имеет название А-0. Стрелки показывают связи объекта с окружающей средой. Диаграмма А-0 устанавливает область моделирования и её границу. На рисунке 4 представлен небольшой пример того, как может выглядеть диаграмма А-0.

Литье по газифицируемым моделям

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

Контекстная диаграмма A-0 также должна содержать краткие утверждения, определяющие точку зрения должностного лица или подразделения, с позиций которого создается модель, и цель, для достижения которой ее разрабатывают. Эти утверждения помогают руководить разработкой модели и ввести этот процесс в определенные рамки. Точка зрения определяет, что и в каком разрезе можно увидеть в пределах контекста модели. Изменение точки зрения, приводит к рассмотрению других аспектов объекта. Аспекты, важные с одной точки зрения, могут не появиться в модели, разрабатываемой с другой точки зрения на тот же самый объект. Формулировка цели выражает причину создания модели, т.е. содержит перечень вопросов, на которые должна отвечать модель, что в значительной мере определяет ее структуру.

6.6 Дочерняя диаграмма

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

6.7 Родительская диаграмма

Родительская диаграмма – это такая диаграмма, которая содержит один или более родительских блоков. Обычная диаграмма может являться также дочерней, т.к она описывает некоторый родительский блок. Любая диаграмма может быть как родительской, так и дочерней, получается блок может быть как родительским, так и дочерним.