ДонНТУ   Портал магістрів

Реферат за темою випускної роботи

Зміст

Вступ

Постійне ускладнення виробничо-технічних і організаційно-економічних систем – фірм, підприємств, виробництв, і ін. суб'єктів виробничо-господарської діяльності - і необхідність їх аналізу з метою вдосконалення функціонування і підвищення ефективності обумовлюють необхідність вживання спеціальних засобів опису і аналізу таких систем. Ця проблема набуває особливої ??актуальності у зв'язку з появою інтегрованих комп'ютеризованих виробництв і автоматизованих підприємств.

Для вирішення проблем була обрана методологія IDEF0, особливості та прийоми застосування якої описуються в сьогоденні Керівному документі (КД), заснована на підході, розробленому Дугласом Т. Россом на початку 70-их років і отримав назву SADT (Structured Analysis & Design Technique - метод структурного аналізу і проектування)[6].

1. Актуальність теми

Нотація IDEF0 дозволяє моделювати системні функції (роботи, дії, операції, процеси), функціональні зв'язки і дані (інформацію та об'єкти), які забезпечують інтеграцію системних комплексів. Розроблені моделі являють собою повноцінний і взаємопов'язаний опис діяльності підприємства або функціонування системи[8].

У підсумку слід застосування методології IDEF0 стане ключем для створення і модернізації програмного продукту.

2. Мета і задачі дослідження та заплановані результати

Метою роботи є розробка програмного продукту, який по побудованій діаграмі буде виводити генерацію програмного коду.

Основні завдання дослідження:

  1. Аналіз різних існуючих методологій і мов специфікацій для вирішення задач про генерації програмного коду;
  2. Вибір методів побудови та використання специфікації за методологією IDEF0 для генерації коду;
  3. Вибір алгоритмів, за якими буде генеруватися вихідний код;
  4. Реалізація програми, в якому мають бути надані компоненти для реалізації генерації програмного коду;
  5. Дослідження сучасних підходів для покращення додаткa.

Об'єкт дослідження: генерація вихідного коду.

Предмет дослідження: методи та алгоритми, використовувані для побудови діаграми.

3. Огляд міжнародних джерел

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 діаграма для одновимірного масиву.

Малюнок 1 – IDEF0 діаграма для одновимірного масиву

Малюнок 1 – IDEF0 діаграма для одновимірного масиву
(анімація: 8 кадрів, 8 циклів повторення, 20 кілобайт)
(x – вхідний масив, b – елемент, що шукається, Res – індекс знайденого елемента в масиві, x` - вихідний масив)

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 для прикладу представлені види стрілок.

Малюнок 2 – Види стрілок

Малюнок 2 – Види стрілок

6.2 Імена і мітки

Імена функцій повинні бути в дієслівної формі. Наприклад: обробити запит, заблокувати доступ до БД, видаляти. Кожна стрілка повинна бути іменована в іменник формі. Наприклад: завантаження, змінена БД, ім'я клієнта. На малюнку 3 представлений приклад відображення мітки стрілки.

Малюнок 3 – Відображення мітки стрілки

Малюнок 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.

Малюнок 4 – Діаграма А-0

Малюнок 4 - Діаграма А-0

Контекстна діаграма A-0 також повинна містити короткі твердження, що визначають точку зору посадової особи або підрозділу, з позицій якого створюється модель, і мета, для досягнення якої її розробляють. Ці твердження допомагають керувати розробкою моделі і ввести цей процес у певні рамки. Точка зору визначає, що і в якому розрізі можна побачити в межах контексту моделі. Зміна точки зору, призводить до розгляду інших аспектів об'єкта. Аспекти, важливі з однієї точки зору, можуть не з'явитися в моделі, що розробляється з іншої точки зору на той же самий об'єкт. Формулювання мети висловлює причину створення моделі, тобто містить перелік питань, на які повинна відповідати модель, що значною мірою визначає її структуру.

6.6 Дочірня діаграма

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

6.7 Батьківська діаграма

Батьківська діаграма - це така діаграма, яка містить один або більше батьківських блоків. Звичайна діаграма може бути також дочірньої, т.к вона описує деякий батьківський блок. Будь-яка діаграма може бути як батьківської, так і дочірньої, виходить блок може бути як батьківським, так і дочірнім.

6.8 Текст і глосарій

Текст використовується для пояснень і уточнень характеристик, внутрішньоблокових з'єднань і т.д, але текст не потрібно використовувати для опису блоків і стрілок, які і так зрозумілі.

Що стосується глосарія, він визначає поняття і терміни, які повинні бути зрозумілі всіма учасниками розробки і користувачами моделі, щоб правильно інтерпретувати її зміст.

Висновки

У рамках даного реферату по темі магістерської роботи були виявлені загальні принципи генерації коду, які дають зрозуміти як працює механізм генерації коду в цілому, і огляд концепції та семантики методології IDEF0, за допомогою якої буде побудована діаграма. Так чи інакше можливий варіант використання технології XML документа, як сказано в [7], який буде легше для розвитку генератори коду в програмному продукті.

Реферат написаний по магістерській роботі, яка ще перебуває в стадії написання. Кінцева готовність магістерської роботи - грудень 2013 року.

Перелік посилань

  1. IE 880I – Enterprise Engineering- Fall 2000 / IMfgE at Wichita State University / Paper #1 – IDEF Modeling / Swapnil Shah
  2. Журнал Qualitative Theory of Dynamical Systems / Выпуск №11, — 2012
  3. Gregor Kempery and Allan Steel // In: P. Draxler, G.O. Michler, C. M. Ringel, eds., Proceedings of the Euroconference on Computational Methods for Representations of Groups and Algebras, Progress in Mathematics, Birkhauser, Basel, 1998 (to appear)
  4. Канжелев С. Ю. Автоматическая генерация кода программ с явным выделением состояний, Software Engineering Conference (Russia) — 2006 (SEC (R) 2006), с. 60–63.
  5. International Journal of Business and Management / Chania, Greece - May, 2008
  6. Ross, D.: "Doug Ross Talks about Structured Analysis", IEEE Computer, July 1985
  7. The Server Side - Your j2ee community / Soumen Sarkar & Craig Cleveland Page 1 of 20 Code generation using XML based document
  8. О.А. Бистерфельд: МЕТОДОЛОГИЯ ФУНКЦИОНАЛЬНОГО МОДЕЛИРОВАНИЯ IDEF0, Учебно-методическое пособие / Рязань - 2008
  9. Кручинін А. Н. Автоматическая генерация программных компонент по высокоуровневым спецификациям, Ростов–на–Дону, 2006.
  10. Aхо А., Ульман Дж. Теория синтаксического анализа, перевода и компиляции. Том 1. Синтаксический анализ. – М.: Мир, 1978. – 613 с.
  11. Ахо А.В., Лам М. С., Сети Р., Ульман Дж. Д. Компиляторы: принципы, технологии и инструментарий, 2-е изд.: Пер. с англ. – М.: ООО Изд. дом Вильямс, 2008. – 1184 с.