Інструментальні засоби для розробки програмного забезпечення. Короткий історичний огляд розвитку інструментальні засоби розробки Інструменти що стосуються розробки

Головна / Контакти

Інструментальне програмне забезпечення (Software tools) - програмне забезпечення, що використовується під час розробки, коригування або розвитку інших програм: редактори, компілятори, налагоджувачі, допоміжні системні програми, графічні пакети та ін.

Сюди входять мови програмування, інтегровані середовища розробки програм, CASE-системи та ін.

Вибір мови програмування

Існуючі на сьогоднішній день мови програмування можна виділити в наступні групи:

  • Універсальні мови високого рівня;
  • спеціалізовані мови розробника програмного забезпечення;
  • спеціалізовані мови користувача;
  • мови низького рівня.

У групі універсальних мов високого рівнябезумовним лідером сьогодні є мова С++. Справді, він має низку переваг:

  • масштабованість. На мові С++ розробляють програми для різних платформ і систем;
  • можливість роботи на низькому рівні з пам'яттю, адресами, портами, що при необережному використанні може легко перетворитися на нестачу;
  • C++ має потужний препроцесор, успадкований від, але, як і будь-який інший потужний інструмент, вимагає обережного використання;
  • можливість створення узагальнених алгоритмів для різних типівданих, їх спеціалізація та обчислення на етапі компіляції, використовуючи шаблони.

При цьому мова C++ має ряд істотних недоліків:

  • підключення інтерфейсу зовнішнього модуля через препроцесорну вставку заголовного файлу (#include) серйозно уповільнює компіляцію при підключенні великої кількості модулів;
  • нестача інформації про типи даних під час компіляції;
  • складність для вивчення та компіляції;
  • деякі перетворення типів неінтуїтивні. Зокрема, операція над беззнаковим та знаковим числами видає беззнаковий результат.

Для C++ існує велика кількість бібліотек класів, що підтримують створення інтерфейсу користувача, клієнт-серверних додатків, роботу з базами даних і т. д., тому поки альтернативи C++ немає . Для другорядних проектів іноді використовується Visual Basic. Мова Java розглядалася як альтернатива Basic, але через відсутність візуального засобу розробки форм вона поки що залишається малопридатною. Сучасний Object Pascal, як і Pascal, запропонований М. Віртом у середині 70-х років XX ст., залишається найбільш привабливим для навчання основ програмування через свою простоту, структурованість та виявлення компілятором великої кількості не тільки синтаксичних, а й семантичних помилок.

Нині на відміну 60-х XX в. мови програмування створюються дуже рідко. За останні 15 років можна відзначити лише дві новинки, що набули широкого поширення - це Java (Sun Microsystems, 1995 р.), що став популярним багато в чому завдяки технології його використання в Інтернеті та появи такого поняття, як віртуальна Java-машина, та C# (Microsoft , 2000), створений на основі C++.

Творцем мови є співробітник Microsoft Андреас Хейлсберг. Він став відомим у світі програмістів задовго до того, як прийшов до Microsoft. Хейлсберг входив до числа провідних розробників однієї з найпопулярніших середовищ розробки - Delphi. У Microsoft він брав участь у створенні версії Java- J++, так що досвіду в написанні мов та середовищ програмування йому не позичати. Як зазначав сам Андреас Хейлсберг, C# створювався як мову компонентного програмування, й у цьому одне з головних переваг мови, спрямоване можливість повторного використання створених компонентів.

Інші переваги мови С#:

  • зберігає кращі риси популярних мов програмування C/C++, основі яких він створено. У зв'язку з цим полегшується перехід програмістів від C + + до C #;
  • є простіше і надійніше за C++. Простота і надійність головним чином пов'язані з тим, що C# хоча і допускаються, але не заохочуються такі небезпечні властивості C++, як покажчики, адресація, розіменування, адресна арифметика;
  • є повністю об'єктно-орієнтованою мовою, де навіть типи, вбудовані у мову, представлені класами;
  • реалізує можливості успадкування та універсалізації;
  • враховує всі можливості Framework .Net, оскільки C# створювався паралельно з цим середовищем;
  • завдяки каркасу Framework .Net, що став надбудовою над операційною системою, програмісти C# отримують ті ж переваги роботи з віртуальною машиною, як і програмісти Java. Ефективність коду навіть підвищується, оскільки виконавче середовище CLR є компілятором проміжної мови, в той час як віртуальна Java-машина є інтерпретатором байт-коду;
  • потужна бібліотека каркасу підтримує зручність побудови різних типівдодатків на С#, дозволяючи легко будувати Web-служби, інші види компонентів, досить просто зберігати та отримувати інформацію з бази даних та інших сховищ даних;
  • є джерелом надійного та ефективного коду.

Крім вищеописаних мов до групи універсальних

належать також Modula, Ada, COBOL, FORTRAN та деякі інші. Кожна з вищеописаних мов має свої особливості і, відповідно, свою сферу застосування. В даний час універсальні мови програмування застосовуються в різних галузях людської діяльності, таких як:

  • наукові обчислення (мови C++, FORTRAN, Java);
  • системне програмування (мови C++, Java);
  • обробка інформації (мови C++, COBOL, Java);
  • штучний інтелект (LISP, Prolog);
  • видавнича діяльність (Postscript, ТеХ);
  • віддалена обробка інформації (Perl, РНР, Java, C ++);
  • опис документів (HTML, XML).

З часом одні мови розвивалися, набували нових рис і залишилися затребуваними, інші втратили свою актуальність і сьогодні представляють у разі чисто теоретичний інтерес (Focal, PL/1 та інших.). Значною мірою це пов'язано з такими факторами:

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

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

  • мови баз даних;
  • мови створення мережевих програм;
  • мови створення систем штучного інтелекту тощо.

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

Мови низького рівнядозволяють здійснювати програмування на рівні машинних команд. При цьому отримують найоптимальніші як з точки зору часу виконання, так і з точки зору обсягу необхідної пам'яті програми. Недоліком їх є те, що вони не підтримують принципи структурного програмування.

В даний час мови типу асемблера зазвичай використовують:

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

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

Загальна характеристика інструментальних засобів розробки програм

    Загальна характеристикаінструментальних засобів розробки програм

    Інструментальні системи технології програмування

    CASE-кошти. Характеристика сучасних CASE-засобів

Огляд об'єктно-орієнтованих інструментальних засобів

Об'єктно-орієнтоване програмування виникло раніше об'єктно-орієнтованого аналізу та проектування, тому на сьогоднішній день існує досить велика кількість мов, що підтримують цю технологію. Першим із них, за датою виникнення, вважається мова Smalltalkхоча багато елементів об'єктно-орієнтованого підходу були використані ще в мові Simula 1967р. Найбільш потужним інструментом створення об'єктно-орієнтованих програм на сьогодні є мова C++, створений з урахуванням мови структурного програмування C. Успішно розвивається мова Java, що спочатку розроблявся як об'єктно-орієнтований.

Розробка великих програмних систему сучасних умовах неможлива без використання засобів автоматизації розробки програмного забезпечення (CASE). CASE, що підтримують об'єктно-орієнтований підхід, не так багато. Найбільш відомий засіб у цьому напрямку – система Rational Rose , яка підтримує, зокрема, етапи об'єктно-орієнтованого аналізу та проектування.

Об'єктно-орієнтований CASE засіб Rational Rose

Розробник Rational Rose- фірма Rational Software Corp., відома своїми доробками в галузі об'єктно-орієнтованих технологій, головною з яких є мова UML. Саме на підтримку UML, як основної мови проектування, і орієнтована дана CASE система.

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

Rational Roseскладається з наступних основних компонентів: репозиторій, графічний інтерфейс користувача, засоби інспекції проекту (browser), засоби контролю проекту, засоби збору статистики та генератор документів, а також розширення для підтримки різних мов програмування.

З основних можливостей можна перерахувати такі:

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

    Зручна навігація між елементами моделі за допомогою інспектора проекту.

    Зберігання результатів проектування як єдиної моделі.

    Підтримка роботи над проектом групи розробників.

    Потужна система підготовки звітів та документації про проект.

    Можливості синтезу програм практично на всіх сучасних об'єктно-орієнтованих мовах, у тому числі і міжплатформною мовою Java.

    Підтримка компонентних технологій побудови програмних систем.

    Широкі можливості з проектування програмного забезпечення різної архітектури, від простих програм, до великих "клієнт-серверних" систем та Інтернет-додатків.

    Можливість реінжинірингу моделі на основі вихідних текстів програми. Цим забезпечується підтримка єдності проектної інформації та реалізації.

    Налаштування та розширення функціональних можливостей CASE середовища шляхом встановлення модулів розширення, насамперед для підтримки різних мов програмування.

Принципи розробки програмних систем у Rational Rose

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

Основним способом проектування є створення різноманітних діаграм і специфікацій, що визначають логічну та фізичну структури моделі системи, її статичні та динамічні аспекти. До них входять діаграми класів, станів, сценаріїв, модулів, процесів.

На всіх етапах надається можливість застосовувати спеціалізовані графічні редактори елементів моделі та використовувати інспектор моделі для навігації серед її компонентів. Вся проектна інформація зберігається у єдиному файлі моделі (*.mdl).

Робота починається з побудови діаграми використання (Use Case Diagram), що характеризує основні завдання та оточення проектованої системи. Далі, для кожного блоку використання (Use Case), представленого на діаграмі використання, розробляються діаграми послідовностей (Sequence Diagram), що ідентифікують об'єкти в системі та описують послідовності подій, що виникають у процесі спілкування об'єктів. Rational Roseдозволяє автоматично пов'язувати діаграми послідовностей із блоками використання.

Об'єкти, присутні на діаграмах послідовностей, визначаються системі за допомогою класів. Класи та їх взаємозв'язок задається за допомогою діаграм класів, розробка яких також підтримується Rational Rose. Класи групуються у пакети. Rational Roseдозволяє визначити набір пакетів, взаємозв'язки між ними та уявити складові їх класи на вкладених діаграмах класів.

Склад компілюваних і виконуваних модулів системи задається в Rational Roseза допомогою діаграми компонентів. На діаграмі визначаються залежність між компонентами. Для компонентів можуть задаватися інтерфейси, якими реалізуються залежності. Діаграми розгортання в Rational Roseвідображають конфігурацію виконуваної програмної системи та складаються з вузлів та відносин взаємодії між вузлами. Вузли включають компоненти, представлені на діаграмі компонентів системи.

Для цілком певної моделі можна здійснити генерацію вихідних програмних текстів різними об'єктно-орієнтованими мовами програмування, що підтримуються Rational Rose, наприклад, Java або C++.

Отримані програмні тексти можуть бути модифіковані поза Rational Rose, а для обліку змін змін система дозволяє виконати реінжиніринг текстів в модель.

Проектування програмних засобів

Моделювання предметної галузі . Створення проекту починається із формування принципів використання системи. У рамках Rational Roseцей етап називається "Use Case View". Реалізація цього етапу дозволяє ідентифікувати зовнішніх користувачів, блоки використання, об'єкти системи та зв'язки між ними.

Складається діаграма використання, що відбиває зовнішнє функціонування створюваної системи. Ця модель багато в чому аналогічна діаграмі потоків даних у структурному аналізі. Основними її складовими є зовнішні користувачі (actors), блоки використання (use case) та зв'язки між компонентами. Для створення діаграми в Rational Roseвикористовується спеціалізований графічний редактор.

Всі елементи діаграми використання виділяються системою як самостійні компоненти моделі в рамках даного етапу та підлягають подальшій специфікації. Насамперед це стосується блоків використання, які відображають групи функцій системи, що подаються як єдине ціле для зовнішнього користувача.

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

Кожен об'єкт на діаграмі послідовностей супроводжується ім'ям класу, якого він належить. Конкретний об'єкт є екземпляром певного класу. Класи утворюють логічну структуру системи.

Розробка логічної структури. Після завершення формування принципів використання системи настає етап розробки її логічної структури. У Rational Roseвін називається "Logical View". Результатом даного етапу має стати головна діаграма та деталізуючі діаграми для її елементів.

На цьому етапі слід визначити класи, які необхідні у системі. Примірники цих класів вже вказані на діаграмах послідовностей. Класи та його зв'язку відбивається у моделі як діаграми класів. Групи класів цих діаграмах можуть бути об'єднані в пакети.

Проектування логічної структури слід розпочинати з визначення основних пакетів. Пакет – універсальний засіб для угрупування елементів моделі. Застосування пакетів дозволяє зробити модель більш доступною для огляду. Пакети можуть бути вкладені один в одного. Класи, що становлять кожен пакет, деталізуються на вкладеній діаграмі.

Вбудований у Rational Roseредактор діаграм класів представляє зручні засоби для таких операцій, а інспектор моделі полегшує переміщення ієрархією діаграм.

Для кожного класу задається специфікація, що описує склад атрибутів та методів, зв'язку, шаблон, на основі якого створено клас, та особливості реалізації.

Наявність шаблонів дозволяє легко створювати класи різної структури.

Класи можуть імпортуватися у систему ззовні. Rational Roseпідтримує компонентну структуру програмного забезпечення та дозволяє використовувати в моделі двійкові компоненти, такі як COM та ActiveX. Їх уявлення у моделі виконується з допомогою класів, заснованих на інтерфейсах даних компонентів.

Крім діаграм класів, для опису логіки системи застосовуються на даному етапі застосовуються діаграми станів, діаграми сценаріїв та інші елементи мови UML

Проектування фізичної структури програми. Класи, описані попередньому етапі, пов'язуються з фізичними компонентами програми з допомогою діаграм компонент.

Компонент являє собою модуль системи, що виконується, і пов'язаний з файлом вихідного тексту, двійковим файлом бібліотеки, об'єктним модулем, виконуваним файлом. Компоненти можуть включати інші компоненти.

Для візуалізації компонентів проектованої системи використовуються діаграми компонентів. Етап побудови діаграм компонент у Roseназивається "Component View". Він складається з побудови загальної діаграми та, при необхідності, деталізації окремих компонентів на вкладених діаграмах.

Дані діаграми відбивають взаємозв'язок складових частин програмного забезпечення. Взаємозв'язок реалізується через інтерфейси, що також відображаються на діаграмі.

Побудова діаграм виконується у спеціалізованому редакторі. Для компонента задаються складові його класи.

Для компонента може проводитися генерація вихідного тексту різними мовами програмування, що підтримуються Rational Rose,або призначатися програмні фрагменти, розроблені поза середовищем Rose. В останньому випадку їхній інтерфейс повинен відповідати оголошеному в моделі.

Останнім етапом у проектуванні програмного забезпечення є підготовка діаграми розгортання. У Roseцей етап називається "Deployment View". Діаграми розгортання показує конфігурацію виконуваної програмної системи. Вона складається з вузлів та відносин взаємодії між вузлами та компонентами. Вузли можуть містити компоненти та об'єкти. Вузли є фізичними елементами виконання.

Побудова та супровід системи

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

Фактично, Roseгенерує скелет програми, який згодом передається програмістам на доопрацювання. Автоматично синтезуються визначення класів та методів, конкретну реалізацію яких слід виконати вручну.

Вихідною інформацією для цієї операції є відомості про класи, що становлять даний компонент та обрану мову реалізації даного компонента.

Перед виконанням операції слід визначити склад та параметри збереження отриманого коду. Далі, виконати генерацію, вибравши потрібну мову. У разі помилок система проінформує звідси.

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

Rational Rose 98 Enterprise Editionдозволяє генерувати вихідний текст Visual Basic, C++, Java, а також отримувати опис інтерфейсів компонент на мові IDL і створювати проекти для системи Oracle 8.

Реінжиніринг моделі на основі вихідних текстів . Можливість реінжинірингу, або, як його ще називають, "зворотного проектування", моделі за вихідними програмними текстами є однією з важливих і, безумовно, корисних функцій Rose. Потреба такої операції часто виникає під час виконання модифікації та модернізації проекту. Згенеровані за моделлю шаблони програми, після їх передачі програмістам можуть бути модифіковані і необхідно враховувати ці зміни в моделі. Крім того, оскільки Rational Roseпідтримує імпорт двійкових компонентів (COM об'єкти серед Win32), то підтримка побудови класів з урахуванням опису інтерфейсів двійкового компонента просто необхідна.

Реінжиніринг класів можна виконати, вибравши мову програмування, якою реалізовані класи, і задавши каталог з вихідними файлами. Далі можна вибрати потрібні файли або провести реінжиніринг для всіх. При виконанні цих дій треба бути уважним і виділяти тільки ті елементи, які дійсно можуть бути перетворені на модель. У процесі роботи система інформуватиме вас про наявність помилок.

Після успішного завершення операції, на діаграмі компонентів (етап "Component View") з'явиться новий елемент, який має ім'я, що збігається з каталогом вихідних файлів. Перехід на етап "Logical View" покаже, що всі класи та пакети, що становлять новий компонент, також з'явилися на діаграмах класів.

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

Підтримка етапів розробки

Компоненти та шаблони. Однією з можливостей Roseє моделювання двійкових компонентів, які підтримують специфікацію COM. У моделі подібні компоненти є інтерфейсними класами, створеними на основі IDL файлів, що супроводжують COM об'єкт. Це дозволяє включати до моделі різні готові компоненти.

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

Робочі середовища. Логічним розвитком ідеї використання шаблонів та зовнішніх двійкових компонентів у Rational Roseстала поява робочого середовища (Framework).

Робоче середовище є різновидом шаблону, що встановлює оточення для створюваної моделі. Це виконується шляхом завантаження базових елементів, включених до робочого середовища, які стають невід'ємною частиною моделі.

Roseнадає широкий набір стандартних робочих середовищ, крім того, можна створювати власні. Набір стандартних робочих середовищ наступний:

    Середовище проектування розподілених програм (Application Performance Explorer)

    Стандартне середовище (Standard). Орієнтована створення додатків на Visual Basic. Включає в себе оголошення багатьох стандартних об'єктів VB.

    Середовище проектування програм для Інтернет (Internet). Включає визначення різних компонентів ActiveX та бібліотек VB.

    Середовище проектування програм для роботи з локальними базами даних (Local Database). Містить оголошення об'єктів системи DAO

    Середовище проектування програм з використанням RDO (Remote Data Object). Дозволяє використовувати об'єкти RDO для створення клієнт-серверних програм.

    Середовище проектування додатків для доступу до SQL-серверів (SQL-DMO), що підтримує доступ до SQL через об'єкти OLE-Automation.

    Середовище підтримки Microsoft Transaction Server

    Середовище підтримки Microsoft Outlook

    Середовище проектування програм на Java (Java JDK 114 Full і Java JDK 114 Quick). Включають моделі класів та інтерфейсів Java, отримані шляхом реінжинірингу.

    Середа підтримки Oracle8

Середовище розробки призначається під час створення моделі. Зберігаються середовища розробки як файлів моделі (*.mdl) призначених лише читання (Read only). У процесі створення нової моделі необхідні елементи завантажуються із вибраного середовища розробки, після чого нова модель.

Середовища розробки є чудовим механізмом для налаштування Roseна конкретний проект. Можна створити власне середовище розробки, яке включатиме необхідні вам елементи з різних стандартних середовищ. До складу Rational Roseвходить "майстер" створення робочих середовищ.

Підтримка групи розробників. Кожен великий проект зазвичай виконується групою розробників, куди входять аналітики, проектувальники, програмісти. Процес розробки є послідовними ітераціями з циклом "аналіз"-"проектування"-"реалізація". На кожному етапі з моделлю працюють кілька розробників та етапи циклічно повторюються. У таких умовах необхідно підтримувати цілісність проекту, враховувати зміни, що вносяться на різних етапах та узгоджувати етапи. Все це вимагає використання загального репозиторію та спеціальної ідеології проектування.

Поряд із зручним засобом інспектування моделі, що полегшує перемикання між етапами, Rational Roseвизначено механізми підтримки групи розробників.

Створюються різні робочі області для розробників та робоча область всього проекту. Кожен розробник здійснює зміни у своїй частині (підмоделі), і ці зміни стають глобальними (переносяться у загальну модель) лише після їх затвердження системою управління проектом. Як контролери проекту в Roseможуть використовуватися зовнішні системи, такі як ClearCaseі Microsoft SourceSafe.

Використання модулів розширення . У Rational Roseвведений гнучкий механізм конфігурації та налаштування можливостей системи. Існують різні модулі розширення, що встановлюються в Roseта вирішальні різні завдання. Можна виділити два основних типи модулів розширення: розширення, що підтримують мови програмування та розширення функціональних можливостей середовища.

При додаванні нового розширення воно інтегрується з системою шляхом додавання пунктів в системні менюта встановленням необхідних бібліотек та виконуваних файлів. Крім того, кожне розширення може додавати до системи власні типи та шаблони.

Додавання необхідних розширень зазвичай проводиться при початковій установці системи, проте їх можна встановити пізніше. Підтримується поширення розширень через мережу Internet

Для управління розширеннями RoseІснує менеджер розширень. З його допомогою можна активізувати та де активізувати різні модулі розширень.

Переваги та недоліки Rational Rose

Даний CASE засіб може бути застосований для створення різноманітного об'єктно-орієнтованого програмного забезпечення, в першу чергу для платформи Windows, а також міжплатформною мовою Java.

На всіх етапах розробки використовується мова UML, і проект програмного засобу є єдиною моделлю.

Важливими перевагами є налаштування на різні мови програмування та архітектури програмних систем, а також можливість "зворотного проектування" на основі вихідних текстів різними мовами програмування. Існує підтримка різних способів фізичної реалізації для компонентів проектованої системи.

Дуже корисною є можливість конфігурування системи за допомогою модулів розширення. По суті, єдиним способом написання програми для не Windows операційної системи є використання мови Java.

Қазақстан Республікасиниң Міністерство

Білим життям освіти і науки

міністрліги Республіки Казахстан

Д. Серікбаєв від ВКГТУ

ШММТУ ім. Д. Серікбаєва

СТВЕРДЖУЮ

Декан ФІТіБ

М. Килишканов

2015 р.

БАҒДАРЛАМАНИ ӘЗІРЛЕУДІҢ ҚҰРАЛ-САЙМАНДАРИ

Жмис модульдік о бадарламаси ж силлабус

ІНСТРУМЕНАЛЬНІ ЗАСОБИ РОЗРОБКИ ПРОГРАМ

Кількість кредитів дисципліни: 3

Усть-Каменогорськ

Робоча модульна навчальна програма та силабус розроблено на кафедрі «Інформаційні системи та комп'ютерне моделювання» на підставі Державного загальнообов'язкового стандарту освіти РК ГОСО РК 5.04.019 – 2011 Вища освіта. Бакалаврат, Робочого навчального плану, Типової навчальної програми та Модульної спеціальності.

Обговорено на засіданні кафедри «Інформаційні системи та комп'ютерне моделювання»

Зав. кафедрою Н. Денісова

Схвалено навчально – методичною порадою ФІТіБ

Голова Г. Уазирханова

Протокол № ____ від ____ ____________ 2015

Розробили

доцент кафедри Т. Балова

старший викладач кафедри І. Увалієва

Нормоконтролер І. ​​Фазилова

1 ХАРАКТЕРИСТИКА ДИСЦИПЛІНИ, ЇЇ МІСЦЕ В НАВЧАЛЬНОМУ ПРОЦЕСІ

1.1 Короткий змістдисципліни, що вивчається

Дисципліна «Інструментальні засоби розробки програм» (далі ІСРП) відноситься до обов'язкового компоненту циклу профілюючих дисциплін освітньої програми спеціальності 5В070400-«Обчислювальна техніка та програмне забезпечення» і входить до складу модуля розробки програм модульної освітньої програми спеціальності 5В070400 .

Зміст дисципліни, що вивчається, спрямовано на формування у навчальних знань у галузі сучасних технологій програмування та інструментальних засобів їх підтримки, сприяє формуванню ІТ-фахівця з широким кругозором і культурою мислення, підготовленого для використання у сфері сучасних CASE-засобів проектування програмних продуктів.

1.2 Цілі та завдання вивчення дисципліни

Мета вивчення дисципліни «Інструментальні засоби розробки програм» - ознайомлення учнів із теоретичними знаннями в галузі технологій проектування та забезпечення життєвого циклу програмних систем, а також набуття практичних навичок використання сучасних технологій, орієнтованих на моделювання бізнес-процесів та проектування програмних систем засобами CASE-технологій ( Computer Aided Software/System Engineering, CASE). Мета дисципліни узгоджена із загальними цілями модульної освітньої програми спеціальності.

Компетентнісний підхід у викладанні дисципліни «Інструментальні засоби розробки програм» визначає її основні завдання:

Сформувати у навчаються систему знань у галузі програмної інженерії (Software engineering) та програмування (computer programming);

Ознайомити тих, хто навчається з теоретичними основами моделювання бізнес-процесів, з методологіями проектування та розробки програмних продуктів та набором інструментальних засобів, що забезпечують їх життєвий цикл;

Виробити навички застосування CASE-засобів структурного та об'єктно-орієнтованого моделювання та проектування програмних засобів.


Завдання вивчення дисципліни забезпечують реалізацію встановлених у кваліфікаційній характеристиці вимог щодо підготовки бакалаврів за освітньою програмою 5В070400-«Обчислювальна техніка та програмне забезпечення».

1.3. Результати вивчення дисципліни

Результати навчання визначаються на основі Дублінських дескрипторів відповідного рівня освіти та виражаються через такі компетенції:

знати та розуміти:

Моделі життєвого циклу програмного забезпечення та теоретичні засади методології проектування програмного забезпечення;

принципи класифікації сучасних інструментальних засобів розробки програмних продуктів;

Підходи до моделювання та реструктуризації бізнес-процесів та систем;

вміти застосовувати на практиці CASE-засоби, що підтримують:

Методологію функціонального моделювання IDEF0;

Методологію подієвого моделювання IDEF3;

Методологію моделювання потоків даних DFD;

Методологію семантичного моделювання даних IDEF1X;

Методологію об'єктно-орієнтованого моделювання програмного забезпечення та метамоделі UML;

бути готовим формувати судження:

Про вибір моделі життєвого циклу для конкретного проекту та проекту;

З питань удосконалення програмного забезпечення у рамках корпоративних інформаційних систем та великих державних проектів (від моделі AS-IS до моделі TO-BE);

Про значення та наслідки своєї професійної діяльностіз урахуванням соціальних, професійних та етичних позицій;

розвивати комунікативні здібності, у тому числі:

розвивати навички навчання, що сприяють:

Професійний та особистісний розвиток, підвищення кваліфікації в галузі міжнародних стандартів програмної інженерії;

Самостійне придбання та використання у практичній діяльності нових знань та умінь роботи з інструментальними CASE-засобами, у тому числі в нових галузях знань, безпосередньо не пов'язаних зі сферою діяльності.

Навчально-методичне забезпечення дисципліни спрямоване на успішне формування вказаних результатів навчання.

1.4 Пререквізити

Для повноцінного засвоєння матеріалу з дисципліни ІСРП потрібна наявність знань з дисциплін, пов'язаних з алгоритмізацією та технологією програмування.

1.5 Постреквізити

Отримані знання необхідні якісного освоєння матеріалу дисциплін: інтерфейси комп'ютерних системта Інтернет технології; системи та проектування персональних баз даних; проектування інформаційних систем та прикладне програмування. Отримані знання необхідні успішної підготовки у частині розробки програмного забезпечення.

2.1 Тематичний план


Найменування теми, її зміст

та інші джерела

Трудомісткість,

Модуль 1 «CASE-засоби структурно-функціонального проектування програмних засобів»

Лекційні заняття

Тема 1 «Вступ до дисципліни».

Основні поняття. Класифікація сучасних інструментальних засобів розробки програмних продуктів. Мета та завдання інструментальних засобів розробки програм. Історія розвитку інструментальних засобів.

Тема 2 "Методи проектування програмного забезпечення".

Загальні вимоги до методології та технології проектування програмного забезпечення. Посібник зі зведення знань з програмної інженерії SWEBOK. Огляд методів проектування програмного забезпечення. Огляд інструментарію проектування програмного забезпечення

Тема 3 "Основи методології проектування програмного забезпечення".

Проектування програм, як складних систем. Життєвий цикл програмного забезпечення. Основні процеси ЖЦ ПЗ. Допоміжні процеси ЖЦ ПЗ. Організаційні процеси ЖЦ ПЗ

Тема 4 "Моделі життєвого циклу програмного забезпечення".

Концепція моделі життєвого циклу програмного забезпечення. Класична модель процесу розроблення програм. Прототипування. Стратегія інкрементальної розробки. Спіральна модель процесу. Модель швидкої розробки додатків RAD

Тема 5 "Методології розробки програмного забезпечення".

XP - процес чи екстремальне програмування. Методологія Rational Unified Process (RUP). Гнучкі (agile) методологія. Вибір моделі життєвого циклу конкретного проекту. Порядок розробки програмного забезпечення

Тема 6 «Сучасні CASE – технології».

CASE - технології та їх використання. Загальна характеристика та класифікація сучасних CASE-засобів. Технології впровадження та освоєння CASE-засобів. Оцінка CASE-засобів

Тема 7 «Моделювання бізнес-процесів».

Концепція бізнес-процесу. Реструктуризація бізнес-процесів. Моделювання бізнес-процесів. Методи моделювання бізнес-процесів

Тема 8 «CASE-технології структурного аналізу та проектування програмних засобів».

Методологія структурного аналізу та проектування. Методологія функціонального моделювання IDEF0. Методологія подієвого моделювання IDEF3. Моделювання потоків даних DFD. Методологія семантичного моделювання даних IDEF1X

Лабораторні заняття

Тема 1 "Розробка функціональної моделі IDEF0"

Тема 2 «Розробка моделей інформаційних процесів IDEF3 та потоків даних DFD»

Тема 3 "Методологія семантичного моделювання даних IDEF1X"

Тема 1 «Звіти та Sibling діаграми IDEF0-моделі»

Тема 2 «Кошти колективної розробки функціональних моделей у середовищі BPwin»

Тема 3 «Створення звітів у ERwin»

Тема 1 "Створення діаграм FEO"

Тема 3 «Створення зв'язку категоризації у IDEF1X-моделі»

Разом за модулем 1

Модуль 2 «CASE-засоби об'єктно-орієнтованого проектування програмних засобів»

Тема 9 «Основи об'єктно-орієнтованого моделювання програмного забезпечення та метамоделі UML».

Ієрархія метаописів, що використовуються у візуальному моделюванні програмного забезпечення. Призначення та рівні моделей UML. Подання в UML

21, 22, 23, 24, 25

Тема 10 «Уніфікована мова моделювання UML. Модель UML».

UML – уніфікована мова моделювання. Сутність в UML. Відносини в UML

22, 23, 24, 25, 26, 27

Тема 11 «Уніфікована мова моделювання UML. Діаграми UML».

Види діаграм UML. Загальні діаграми UML. Спеціальні діаграми UML

22, 23, 24, 25, 26, 27

Тема 12 «Уніфікована мова моделювання UML. Загальні механізми UML.

Використання загальних механізмів UML. Загальні характеристики моделі. Крапки семантики

22, 23, 24, 25, 26, 27

Тема 13 "Загальний опис системи з позиції подання UML".

Подання UML з позиції узагальнення описів. Загальні механізми UML Загальні властивості моделі

22, 23, 24, 25, 26, 27

Тема 14 "Опис функціональності розробки програмного забезпечення".

Управління ризиками проекту. Порядок розроблення програмного забезпечення. Документування програмних засобів. Управління вимогами

Тема 15 «Науково-технологічні тренди та найшвидше зростаючі сегменти на світовому ІТ ринку».

Три платформи в еволюції ринку ІТ. Нові тренди ІТ: прогноз компанії Gartner Світові Top тренди розвитку ІТ на найближчі 3-5 років

Лабораторні заняття

22, 23, 24, 25, 26, 27

22, 23, 24, 25, 26, 27

22, 23, 24, 25, 26, 27

Самостійна робота викладача, що навчається під керівництвом (СРОП)

Тема 4. "Побудова структурних діаграм UML"

22, 23, 24, 25, 26, 27


Тема 5. "Побудова поведінкових діаграм UML"

22, 23, 24, 25, 26, 27


Тема 6. "Генерація програмного коду за моделлю UML"

22, 23, 24, 25, 26, 27


Самостійна робота учня (СРО)

Тема 4. "Побудова структурних діаграм UML"

22, 23, 24, 25, 26, 27

Тема 5. "Побудова поведінкових діаграм UML"

22, 23, 24, 25, 26, 27

Тема 6. "Генерація програмного коду за моделлю UML"

22, 23, 24, 25, 26, 27

Разом за модулем 2

Разом з дисципліни, кредит РК


2.2 Завдання для самостійної роботи(СРОП, СРО)


Тривалість виконання, уч. тиждень

Форма контролю

Строк здачі

(Номер уч. Тижня)

Завдання на СРОП-IDEF0-модель доповнити звітами та діаграмами Node Tree.

Завдання на СРО-IDEF0-модель доповнити діаграмою FEO.

Ознайомитись з основними прийомами колективної розробки функціональних моделей у середовищі BPwin

Інд. завдання та додаткові питання при захисті. Тестові завдання

Завдання на СРОП:

Виконати розщеплення IDEF0-моделі та

ABC аналіз.

Завдання СРО – вивчити елементи імітаційної моделі.

Здобути практичні навички використання засобів колективної розробки моделі з елементами аналізу ABC

Завдання на СРОП - для IDEF1X моделі побудувати шаблон звіту.

Завдання на СРО – вивчити роботу зі створення зв'язку категоризації у IDEF1X-моделі

Вивчити прийоми побудови шаблонів звіту засобами Report Builder середовища ERwin та освоїти процедури роботи зі зв'язками категоризації

Інд. завдання та додаткові питання при захисті лабораторної роботи Тестові завдання

Сенсорне багатопозиційне введення та події WPF

Отримати початкові відомості про способи взаємодії з програмою WPF за допомогою

торкання екрану для інтерактивної взаємодії

Інд. завдання та додаткові питання щодо захисту лабораторної роботи. Тестові завдання

Тригери властивостей та подій WPF

Ознайомитись з механізмом тригерів WPF для створення анімаційного ефекту

Інд. завдання та додаткові питання щодо захисту лабораторної роботи. Тестові завдання

Використання API-інтерфейсу Office та первинних збірок. Net Microsoft. Office. Interop

Освоїти спрощений механізм взаємодії із СОМ з метою розширення практичних прийомів організації міжпрограмної взаємодії

Інд. завдання та додаткові питання щодо захисту лабораторної роботи.

Тестові завдання


2.3 Графік виконання та здачі завдань з дисципліни



Основна література

1 Рамбо Дж. Уніфікований процес розробки програмного забезпечення / А. Якобсон, Г. Буч, Дж. Рамбо - СПб.: Пітер, 2002.-496 с.: іл.

2 CASE-технології. Сучасні методи та засоби проектування інформаційних систем/- М.: Фінанси та статистика, 1998.- 176 с.

3 Бахтізін, розробки програмного забезпечення: навч. допомога / , . – Мінськ: БДУІР, 2010. – 267 с. : іл.

4 , Аналіз та комп'ютерне моделювання інформаційних процесів та систем / , .- Діалог-МІФІ, 2009. - 416 стор.

5 ISO/IEC 12207:2008. Systems and software engineering - Software life cycle processes [Електронний ресурс]. - URL: http://www. ISO. org/iso/catalogue_detail? csnumber=43447, вільний. - Загл. з екрану (дата звернення: 30.10.2015)

6 ГОСТ Р ІСО/МЕК 12207-2010 Інформаційна технологія. Системна та програмна інженерія. Процеси життєвого циклу програмних засобів. - М. Вид-во стандартів, 2011., 115с.

7 ГОСТ Р ИСО/МЭК 11179-2-2012 Інформаційна технологія. Регістри метаданих (РМД). Частина 2. Класифікація [Електронний ресурс]. - URL: http:///Catalog/64/6430.shtml, вільний. - Загл. з екрану (дата звернення: 30.10.2015)

8 ГОСТ Р ИСО/МЭК ТО 12182 - 2002. Інформаційна технологія. Класифікація програмних засобів. - Введ. 2002 – 06 – 11. – М. Вид-во стандартів, 2002

9 IEEE Computer Society. SWEBOK [Електронний ресурс]. - URL: http://puter. org/web/swebok, вільний. - Загл. з екрану (дата звернення: 30.10.2015)

10 , Навчальний посібникдо практичних занять «Структурно-функціональний підхід до проектування та з використанням CASE-засобів»/Перм. держ. тещн. ун.-т. - Перм, 2005. - 245 с.

11 Марка Макговен етодологія структурного аналізу та проектування SADT [Пер. з англ.] / арка, акГоуен – М.: МетаТехнологія, 1993. –240 с.

12 РД 50.1.028-2001. Методологія функціонального моделювання IDEF0, Керівний документ. Видання офіційне. – М.: ІПК Видавництво стандартів, 2000. – 75 с.

13 Обділення та аналіз систем. IDEF-технології: практикум/С. Черемних, І. Семенов, В. Ручкін. - М.: Фінанси та статистика, 2006. -192 с.

14, Структурний аналіз систем. IDEF – технології/С. Черемних, І. Семенов, У. Ручкин.- М.: Фінанси та статистика,2001. - 208 с.

15 труктурні моделі бізнесу: DFD-технології / А. Калашян, Г. Калянов. - М.: Прикладні інформаційні технології, 2009. - 256 с.

додаткова література

16 IEEE Std. 1320.2-1998. Стандарт IEEE із синтаксису та семантики мови концептуального моделювання IDEFIX97 (IDEF Object). - Введ. 1998-06-25. - Нью-Йорк: IEEE, 1998.

17 ефективне моделювання з AllFusion Process Modeler / В. Дубейковський. - М.: Діалог-МІФІ, -2007. - 384 с.

18 Обділення бізнес-процесів з AllFusion Process Modeler / С. Маклаков. - М.: Діалог-МІФІ, -2004. - 240 с.

19 BPwin та Erwin. CASE-засоби для розробки інформаційних систем/С. Маклаков. – Діалог-МІФІ, 2000. – 320 с.

20, Методологія функціонального проектування IDEF0. Навчальний посібник з курсу "Технологія розробки програмного забезпечення" для студ. спец. 40 01 01 Програмне забезпечення інформаційних технологій денної форми навчання. - Мінськ: БДУІР, 2003. - 24 с.: Іл.

21 , Моделювання UML. Теорія, практика, відеокурс. - СПб, Професійна література, Наука та Техніка, 2010, 640 с.

22 мова UML. Посібник користувача. Друге видання. – ДМК, 2006, 496 с.

23 Дж. Рамбо, М. Блаха, UML 2.0. Об'єктно-орієнтоване моделювання та розробка. - Пітер, 2007 р., 544 с.

24 Мартін Фаулер. UML. Основи. Короткий посібникз стандартної мови об'єктного моделювання. Символ-Плюс, 2011., 192с.

25 The Unified Modeling Language (UML) [Електронний ресурс]. - URL: http://www. uml. org/, вільний. - Загл. з екрану (дата звернення: 30.10.2015)

26 ведення в UML: [Електронний ресурс] - Відкриті курси Інтернет-університету інформаційних технологій (ІНТУІТ). - Режим доступу http://www. intuit. ru/studies/courses/1007/229/info (дата звернення: 30.10.2015)

27 моделювання в середовищі IBM Rational Rose 2003: [Електронний ресурс] - Відкриті курси Інтернет-університету інформаційних технологій (ІНТУІТ). - Режим доступу http://www. intuit. ru/studies/courses/14/14/info (дата звернення: 30.10.2015)

28 The Gartner Symposium/ITxpo [Електронний ресурс]. - URL: http://www. /technology/symposium/japan/exhibitor-directory. jsp, вільний. - Загл. з екрану (дата звернення: 30.10.2015)

29 Огляд та оцінка перспектив розвитку світового та російського ринків ІТ/Блог компанії Московська Біржа, IT-стандарти, ІТ-інфраструктура [Електронний ресурс]. - URL: http://habrahabr. ru/company/moex/blog/250463/, вільний. - Загл. з екрану (дата звернення: 30.10.2015)

4 ОЦІНКА ЗНАНЬ

4.1 Вимоги викладача

Вимоги викладача:

Відвідування лекційних та лабораторних занять, СРСП за розкладом є обов'язковим;

Присутність студентів на заняттях перевіряється на початку занять, у разі запізнення студент повинен безшумно увійти до аудиторії та включитися в роботу, а в перерві пояснити викладачеві причину запізнення;

Оцінювані в балах лабораторні роботи слід здавати у встановлений термін, до рубежного тестування допускаються студенти, які захистили не менше однієї лабораторної роботи поточного рейтингу;

Повторне проходження студентом кордону, у разі отримання незадовільної оцінки, не допускається;

Протягом занять мобільні телефонимають бути відключені;

Студент зобов'язаний приходити на заняття у діловому одязі.

4.2 Критерії оцінки

Оцінка всіх видів завдань здійснюється за 100-бальною системою.

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

Рубіжний контроль знань проводиться на 7 та 15 тижні семестру у формі тестування. Рейтинг складається з таких видів контролю:



Іспит з дисципліни відбувається під час екзаменаційної сесії у формі тестування.

Загальна оцінка знань студента з дисципліни включає:

40% результату, отриманого на іспиті;

60% результатів поточної успішності.

Формула підрахунку підсумкової оцінки:

де Р1, Р2 – цифрові еквіваленти оцінок першого, другого рейтингу відповідно; Е – цифровий еквівалент оцінки на іспиті.

Підсумкова літерна оцінка та її цифровий еквівалент у балах:



4.3 Матеріали для підсумкового контролю

4.3.1 Модуль 1 «CASE-засоби структурно-функціонального проектування програмних засобів»

Відповідно до міжнародного стандарту ISO та IEC (International Electrotechnical Commission) технологія програмування – це

A) один із видів діяльності, що входять до циклу розробки програмного забезпечення

B) процес створення програмістом (людиною) програми (інформаційної структури), призначеної для подальшого виконання (комп'ютером)

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

D) сукупність методів та засобів, що дозволяють налагодити виробничий процес створення програмного забезпечення

E) алгоритм, записаний мовою програмування

F) послідовність команд (операторів, інструкцій) комп'ютера, виконання яких призводить до отримання результату розв'язання задачі

Інструментальні програмні засоби (Software tools) – це:

A) браузери, що надають графічний інтерфейсдля інтерактивного пошуку, виявлення, перегляду та обробки даних у мережі

B) програмне забезпечення підприємств, функції якого забезпечують фінансове управління, систему відносин із споживачами, управління кадрами та ін.

C) компонувальники та відладники

D) програмне забезпечення, яке використовується під час проектування, розробки, модифікації або розвитку інших програмних продуктів

E) програмне забезпечення для доступу до цифрового контенту або ресурсів без їх редагування, прикладами є медіа-плеєри, веб-браузери та ін.

Компілятор – це:

A) програма, що перетворює вихідний текст, написаної мовою програмування високого рівня, виконуваний програмний код, який може використовуватися на інших комп'ютерах без додаткових перетворень

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

C) програмний комплекс, який призначений для розробки програмних продуктів та інтегрує редактори вихідних текстів та ресурсів, компілятор або інтерпретатор, компонувальник та ін.

D) модуль системи програмування або самостійна програма, яка збирає результуючу програму з об'єктних модулів та стандартних бібліотечних модулів

E) програма, яка забезпечує покрокове виконання програми, перегляд поточних значень змінних, обчислення значення будь-якого виразу програми та інші функції

Основними перевагами CASE-коштів є:

A) Збільшення витрат на розробку

B) Зменшення витрат на розробку

C) Ускладнення доступу до даних

D) Збільшення часу на розробку

E) Полегшення під час модифікації систем

F) Можливість зберігання даних

Відповідно до проекту ICAM (Інтеграція комп'ютерних та промислових технологій) методологія функціонального моделювання виробничого середовища або системи пов'язана з нотацією

До основних елементів IDEF3-моделі відносяться

B) зв'язки (Links)

C) зовнішні сутності (external entities)

D) перехрестя (Junctions)

E) потоки даних (data flow)

F) сховища даних (data stores)

G) зовнішні сутності (external entities)

H) процеси чи роботи (activity)

4.3.2 Модуль 2 «CASE-засоби об'єктно-орієнтованого проектування програмних засобів»

Ризик, пов'язаний з виходом за рамки бюджету, негативною реакцією замовника або поганими контактами з користувачами:

A) технічного ризику

B) календарного ризику

C) управлінського ризику

D) комерційний ризик

Використовуваний мовою UML принцип моделювання, відповідно до якого в модель слід включати тільки ті елементи системи, що проектується, які мають безпосереднє відношення до виконання їй своїх функцій або свого цільового призначення, інші елементи опускаються, щоб не ускладнювати процес аналізу та дослідження моделі, називається

A) успадкуванням

B) інкапсуляцією

C) поліморфізмом

D) абстрагуванням

E) багатомодельністю

F) ієрархічною побудовою

На діаграмі використання UML застосовують такі типи сутностей

B) Варіанти використання

C) Чинні особи

D) Інтерфейси

F) Стану

G) Об'єкти

Яка структурна сутність UML знаходиться поза модельованою системою і безпосередньо взаємодіє з нею

A) клас (class)

B) інтерфейс (interface)

C) дійова особа (actor)

D) варіант використання (use case)

E) артефакт (artifact)

F) вузол (node)

5 ОСНОВНІ ФОРМИ І МЕТОДИ НАВЧАННЯ

Для підвищення мотивації учнів до засвоєння знань з дисципліни використовуються:

Контекстне навчання, що дозволяє виявити зв'язок між конкретним знанням та його застосуванням практично;

Інтерактивна модель навчання, що передбачає публічний захист лабораторних робіт у формі презентації, повідомлення на тему СРОП та СРС;

Програмне забезпечення, що дозволяє при виконанні лабораторних робіт створювати групи розробників програм, керувати процесами комплексного налагодження, тестування та програм, що підвищує творчу активність учнів, стимулює до теоретичного осмислення знань та самостійного пошуку вирішення завдань індивідуального завдання;

Проектна технологія, яка передбачає індивідуальну або колективну діяльність із систематизації знань з суміжних дисциплін (модулі проектування баз даних та проектування ІВ), що передбачають реальну виробничу тему;

Навчання на основі наукового та виробничого досвіду викладачів, що дозволяє активізувати учнів за рахунок асоціації власного досвіду з предметом вивчення;

Дистанційна розробка навчання.

p align="justify"> Для формування індивідуальних завдань з елементами наукових досліджень при виконанні лабораторних робіт використовуються результати наукових досліджень вчених кафедри.

6 ЧАС КОНСУЛЬТАЦІЙ

Консультації проводяться за графіком роботи викладача.


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

Будь-яка розвинена технологічна система має підтримувати всі основні етапи створення програмного комплексу, що проектується. Для досягнення цієї мети в загальній структурі типової технологічної системи підтримки розробки(рис. 6.3) зазвичай виділяють базу даних проекту; підсистему автоматизації проектування та програмування; підсистеми налагодження, документування та супроводу,а також підсистему керування ходом виконання проекту.


Рис. 6.3.Загальна структура типової технологічної системи підтримки розробки

Розвинені бібліотечні системи підтримки розробки використовуються в даний час у всьому світі в усіх серйозних програмних проектах. Але у переважній більшості випадків такі системи досягли рівня зручності роботи з ними кваліфікованих програмістів. Нас же, перш за все, цікавлять системи та проекти, в яких є тенденції до експліцитного представлення технологічних знань, навіть якщо вони не базуються на ідеях та методах ІІ.

Один з таких проектів – Gandalf – орієнтований на автоматизовану генерацію систем розробки програмного забезпечення. Дослідження, що виконуються в рамках проекту Gandalf, стосуються трьох аспектів підтримки проектування програмного забезпечення: управління проектом, контроль версій та інкрементне програмування, а також інтеграція їх у єдине середовище. Управління в Gandalf-середовищі базується на припущенні, що проект, що розробляється, повинен трактуватися як безліч абстрактних типів даних, над якими можуть виконуватися лише певні операції. Засобом, що реалізує цю концепцію, стала система SDC (Software Development Control), що є набір програм, спочатку реалізованих мовою Shell в системі UNIX, а пізніше перекладена мовою С.

Дослідження в галузі контролю версій було розпочато ще Л. Коопридером на базі проекту FAFOS, де спочатку аналізувалися можливості створення сімейства операційних систем. Була розроблена нотація для опису взаємодії між підсистемами, для опису різних версій підсистем (вихідного та об'єктного коду, документації тощо) та для опису механізмів, що діють на етапі розробки (компіляція, редагування зв'язків тощо). Потім було створено спеціальну мову Intercol як опис взаємозв'язку і версій модулів у системі. І, нарешті, в систему були вбудовані знання про те, як конструювати систему із частин, не змушуючи займатися цим користувача. У розвиток цих робіт було створено систему SUCE, у межах якої відстежувалися різницю між реалізаціями (версіями, які справді дають код ряду специфікацій) і композиціями (версіями, визначальними нові підсистеми як групи існуючих підсистем).



У системі LOIPE (Language-Oriented Incremental Programming Environment) інкрементна компіляція виконується лише на рівні окремої процедури. Перевагою такого підходу і те, що з корекції процедури лише на рівні локальних об'єктів чи типів перекомпілюється лише вона. Якщо ж змінюється специфікація, то перекомпілюються і всі процедури, що залежать від неї. Інтерфейс користувача з LOIPE-системою базується на підсистемі синтаксично-орієнтованого редагування ALOE (A Language-Oriented Editor). Метою розробки цієї підсистеми було дослідження можливості створення та використання синтаксично-орієнтованих редакторів як базис для середовищ програмування.

Аналіз літератури останніх років за технологією програмування показує, що новою гілкою в технології промислової розробки та реалізації, складних та значних за обсягом систем програмного забезпечення є CASE-технологія(Computer Aided Software Engineering).

Спочатку CASE-технологія з'явилася у проектах створення промислових систем обробки даних. Ця обставина наклала свій відбиток і на інструментальні засоби CASE-технології, де найсерйознішу увагу приділяли принаймні в ранніх CASE-системах підтримці проектування. інформаційних потоків. В даний час спостерігається відхід від орієнтації на системи обробки даних, і інструментальні засоби CASE-технології стають все більш універсальними.

Всі засоби підтримки CASE-технології поділяються на дві великі групи: САSE-Toolkitsі CASE-Workbenches.Хороших російських еквівалентів цим термінам немає. Однак перші часто називають "інструментальними скриньками" (пакетами розробника, технологічними пакетами), а другі - "верстатами для виробництва програм" (технологічними лініями).

За визначенням CASE-Toolkit -колекція інтегрованих програмних засобів, що забезпечують автоматичне асистування у вирішенні завдань одного типу у процесі створення програм.

Такі пакети використовують загальне «сховище» для всієї технічної та керуючої інформації за проектом (репозиторій), забезпечені спільним інтерфейсом з користувачем та уніфікованим інтерфейсом між окремими інструментами пакета. Зазвичай, CASE-Toolkit концентруються навколо підтримки розробки однієї фази виробництва програм чи одному типі прикладних завдань.

Все сказане вище справедливо і по відношенню до CASE-WorkBench. Але тут, крім того, забезпечується автоматизована підтримка аналізу розв'язуваних завдань із виробництва програмного забезпечення, що базується на загальних припущеннях про процес та технологію такої діяльності; підтримується автоматична передача результатів робіт від одного етапу до іншого, починаючи зі стадії проектування та закінчуючи відчуженням створеного програмного продукту та його супроводом.

Таким чином, CASE-WorkBenchє природним «замиканням» технології розробки, реалізації та супроводу програмного забезпечення.

В даний час "типова" система підтримки CASE-технології має функціональні можливості, представлені на рис. 6.4.

Рис. 6.4. Функціональні можливостітипової системи підтримки CASE-технології

Як випливає з цієї Н-діаграми, у CASE-середовищі повинні підтримуватись всі основні етапи розробки та супроводу процесів створення програмних систем. Проте рівень такої підтримки суттєво різний. Так, наприклад, якщо говорити про етапи аналізу та проектування, більшість інструментальних пакетів підтримує екранні та звітні форми, створення прототипів, виявлення помилок. Значна частина цих засобів призначена для ПЕОМ. Багато хто підтримує такі широко використовувані методології, як структурний аналіз DeMarco або Gane/Sarson, структурне проектування Yourdan/Jackson та деякі інші. Існують спеціалізовані пакети розробників для створення інформаційних систем, наприклад, Ana Tool (Advanced Logical Software) для Macintosh; CA-Universe/Prototype (Computer Associates International) для ПЕОМ. Є CASE-середовища та для підтримки розробки систем реального часу.

Серед розробників ПЗ існують дві оцінки даного підходу: частина з них вважає, що CASE-технологія кардинально змінює процеси розробки та експлуатації ПЗ, інші заперечують це та залишають за інструментальними засобами CASE лише функцію автоматизації рутинних робіт. Проте аналіз літератури показує, що CASE кошти таки «зсувають» технології розробки програмного забезпечення з управління виконанням проектів у бік методу прототипізації. І це зрушення, на наш погляд, надзвичайно важлива тенденція в сучасної технологіїпрограмування.

Вступ

У процесі розробки програмного забезпечення використовується велика кількість різнобічного програмного забезпечення (ПЗ). Цей курс лекцій розглядає коли і що використовується протягом усього етапу розробки додатків.

Щоб дати більш повне уявлення про роль кожної утиліти або зрізи розробки в процесі створення ПЗ, усі розглянуті в даному курсі лекцій інструментальні засоби будуть розглянуті на прикладі розробки додатків з використанням однієї з високорівневих мов. Для простоти, всі інструментальні засоби можна розділити на 4 групи. Розглянемо докладніше кожну групу.

Необхідні

Необхідні інструментальні засоби - це ті, без яких у принципі неможливо отримати код, що виконується; До цієї групи можна віднести:

§ редактори текстів;

§ компілятори та асемблери;

§ компонувальники або редактори зв'язків (linkers);

Часто використовуються

Це кошти, використання яких, на відміну необхідних, можна уникнути. Але без них процес розробки дуже утруднюється та подовжується; Із часто використовуваних засобів варто назвати:

§ утиліти автоматичного складання проекту;

§ відладчики;

§ програми створення інсталяторів;

§ редактори ресурсів;

§ профільники;

§ програми підтримки версій;

§ програми створення файлів допомоги (документації).

Спеціалізовані

Ці інструментальні засоби використовуються у виняткових випадках, вирішують досить специфічні завдання:

§ програми відстеження залежностей;

§ дизассемблери;

§ декомпілятори;

§ hex-редактори;

§ програми відстеження активності системи та змін, що відбуваються в системі;

§ програми-верифери та контейнери (створюють віртуальне середовищедля окремих класів програм, у яких можна дослідити поведінку програми);

Інтегровані середовища розробки

Інтегровані середовища розробки містять більшу частину наведених вище програм і дозволяють спростити процес створення додатків. За великим рахунком, середовище розробки – це програма, яка збирає разом кілька інструментальних засобів із першої та другої (а іноді й третьої) груп.

Надалі, ми більш докладно познайомимося з основними представниками кожної групи, а також розглянемо як це все працює в інтегрованому середовищі розробки.

КЛАСИФІКАЦІЯ ІНСТРУМЕНТАЛЬНИХ ЗАСОБІВ

ТЕМА 1 ПОНЯТТЯ ІНСТРУМЕНТАЛЬНИХ ЗАСОБІВ.

КЛАСИФІКАЦІЯ ІНСТРУМЕНТАЛЬНИХ ЗАСОБІВ.

Інструментальна система технології програмування- це інтегрована сукупність програмних та апаратних інструментів, що підтримує всі процеси розробки та супроводу великих ПС протягом усього його життєвого циклу в рамках певної технології.

Інструментальні системи технології програмування можна виділити три основні компоненти:

· Репозиторій,

· Інструментарій,

· Інтерфейси.

Інструментарій- Набір інструментів, що визначає можливості, що надаються системою колективу розробників. Зазвичай цей набір є відкритим та структурованим. Крім мінімального набору ( вбудовані інструменти), він містить засоби свого розширення ( імпортованими інструментами). Крім того, в силу інтегрованості за діями він складається з деякої загальної частини всіх інструментів ( ядра) та структурних (іноді ієрархічно пов'язаних) класів інструментів.

Інтерфейсиподіляються на користувальницький та системні. Користувальницькийінтерфейс забезпечує доступ розробникам до інструментарію. Він реалізується оболонкоюсистеми. Системніінтерфейси забезпечують взаємодію між інструментами та їх загальними частинами. Системні інтерфейси виділяються як архітектурні компоненти у зв'язку з відкритістю системи - їх мають використовувати нові ( імпортовані) інструменти, що включаються до системи.

Найзагальніша архітектура інструментальних систем технології програмування представлена ​​на рис.

Рис. Спільна архітектура інструментальних систем технології програмування.

Розрізняють два класи інструментальних систем технології програмування: інструментальні системи підтримки проекту та мовно-залежні інструментальні системи.

Інструментальна система підтримки проекту- це відкрита система, здатна підтримувати розробку ПС різними мовами програмування після її розширення програмними інструментами, орієнтованими на обрану мову. Набір інструментів такої системи підтримує розробку ПС, а також містить незалежні від мови програмування інструменти, що підтримують розробку ПС (текстові та графічні редактори, генератори звітів тощо). Крім того, він містить інструменти розширення системи. Ядро такої системи забезпечує, зокрема, доступ до репозиторію.

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

© 2022 androidas.ru - Все про Android