Студопедия

КАТЕГОРИИ:


Архитектура-(3434)Астрономия-(809)Биология-(7483)Биотехнологии-(1457)Военное дело-(14632)Высокие технологии-(1363)География-(913)Геология-(1438)Государство-(451)Демография-(1065)Дом-(47672)Журналистика и СМИ-(912)Изобретательство-(14524)Иностранные языки-(4268)Информатика-(17799)Искусство-(1338)История-(13644)Компьютеры-(11121)Косметика-(55)Кулинария-(373)Культура-(8427)Лингвистика-(374)Литература-(1642)Маркетинг-(23702)Математика-(16968)Машиностроение-(1700)Медицина-(12668)Менеджмент-(24684)Механика-(15423)Науковедение-(506)Образование-(11852)Охрана труда-(3308)Педагогика-(5571)Полиграфия-(1312)Политика-(7869)Право-(5454)Приборостроение-(1369)Программирование-(2801)Производство-(97182)Промышленность-(8706)Психология-(18388)Религия-(3217)Связь-(10668)Сельское хозяйство-(299)Социология-(6455)Спорт-(42831)Строительство-(4793)Торговля-(5050)Транспорт-(2929)Туризм-(1568)Физика-(3942)Философия-(17015)Финансы-(26596)Химия-(22929)Экология-(12095)Экономика-(9961)Электроника-(8441)Электротехника-(4623)Энергетика-(12629)Юриспруденция-(1492)Ядерная техника-(1748)

Етапи розвитку мов програмування

Розвиток мов програмування можна розглядати у вигляді етапів, кожний із яких характеризується певними ознаками. Початковий етап (1950-1960 р.) характеризується тим, що в основі засобів взаємодії людини й ЕОМ лежали мови, у яких програмування велося в термінах машинних кодів. Взаємодія програмістів з ЕОМ здійснювалося в діалоговому монопольному режимі. На цьому і наступних етапах (до появи інтелектуальних мов високого рівня) ЕОМ були доступні тільки професіоналам-програмістам. У ці роки почалося створення мов алгоритмічного типу.

Другий етап розвитку середовища програмування (I960 - 1970 роки) характеризувався створенням операційних систем, які дозволяли опрацьовувати декілька завдань, сформованих різними користувачами. Основна мета розробок на цьому етапі полягала в забезпеченні найбільшого завантаження машинних ресурсів. Почали використовувалися алгоритмічні мови, орієнтовані на ту або іншу предметну сферу.

Третій етап характерний якісною зміною критерію ефективності автоматизованого опрацювання даних. Якщо на перших етапах у якості такого критерію виступали (як видно, у силу обмеженої сфери використання ЕОМ) машинні ресурси, то далі основними стали людські ресурси, що здійснюють розробку і супровід програмного забезпечення. Сфера використання обчислювальної техніки до цього часу була вже достатньо велика і містила в собі ряд складних задач і проблем. Крім того, стали розроблятися і впроваджуватися в практику не тільки великі, але і дешевші міні ЕОМ, що дозволило в основному вирішити проблему необхідних обчислювальних ресурсів. З метою швидшої розробки програмного забезпечення на цьому етапі використовувався інтерактивний режим взаємодії декількох користувачів з ЕОМ, підтримуваний діалоговими операційними системами. Проте в цілому зростаючий рівень технології розробок програмного забезпечення ще не дозволив вирішити проблему людських ресурсів. Розрив між обсягами автоматизації і загальною кількості програмістів продовжував зростати.

Четвертий етап знаменує новий якісний стрибок у технології розробки програмного забезпечення, що відчиняє можливість рішення зазначеної проблеми. Його суть зводиться до того, що центр ваги технологічних рішень переноситься на створення засобів, що забезпечують взаємодію користувачів з ЕОМ на етапах створення програмного продукту. Ключовою ланкою нової інформаційної технології стає представлення та опрацювання знань. Розваються мови представлення знань, що дозволяє користувачам безпосередньо вносити свої знання в ЕОМ і надалі використовувати їх для вирішення конкретних задач. Індустрія знань стала широко впроваджуватися в різноманітні області створення прикладних інформаційних систем - створюються інтелектуальні пакети прикладних програм, бази даних, експертні системи. Цей етап характеризується також створенням і використанням персональних комп’ютерів. Створюються технічні передумови для застосування комп’ютера у широкому масштабі безпосередньо споживачами інформації - користувачами.

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

Об’єктно-орієнтовані технології.

Суть об’єктно-орієнтованого програмування виражається формулою “об’єкт це дані плюс процедури“. Об’єкт інтегрує деякий стан (або структуру даних) і доступні тільки йому механізми керування ним. Багато об’єктно-орієнтованих мов мають засоби для об’єднання об’єктів у класи. Це дозволяє зберігати процедури (у термінах об’єктно-орієнтованого програмування - методи), застосовувані до всіх об’єктів цього класу, в єдиному примірнику, лише у відповідному класі. Засоби візуального програмування розширили поняття “об’єкт“. Об’єкт - це деяка річ, із якою можна щось робити, і яка може бути видимою або ж ні. Видимим об’єктом може бути рамка, кнопка, автономний модуль та інше. Завдяки засобам візуальної розробки можна працювати з видимим об’єктом, тримаючи його перед очима й одержуючи результати практично відразу.

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

Поняття про CASE-технології.

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

Важливий напрям в розвитку технологій склали розробки інтегрованих інструментальних засобів, які базуються на концепціях життєвого циклу і управління якістю автоматизованих інформаційних технологій і систем, які являють собою комплексні технології, орієнтовані на створення складних автоматизованих управлінських систем і підтримку їх повного життєвого циклу або ряду його основних етапів. Подальший розвиток робіт в цьому напрямку привело до створення ряду концептуально цілісних, оснащених високошвидкісними засобами проектування і реалізації варіантів, доведених по якості і легкості тиражування до рівня програмних продуктів технологічних систем, які отримали назву CASE-систем або CASE-технологій (Computer-Aided Software/System Engeneering).

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

Сфера застосування CASE-технологій.

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

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

Переваги CASE-технологій.

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

Крім автоматизації структурних методологій і, як наслідок, можливості застосування сучасних методів системної і програмної інженерії, CASE-технологіям притаманні такі переваги:

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

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

· прискорюють процес проектування і розробки системи;

· звільняють розробника від рутинної роботи, дозволяючи йому цілком зосередитися на творчій частині розробки;

· підтримують розвиток і супроводження розробки автоматизованої інформаційної системи;

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

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

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

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

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

Під час розробки програмного забезпечення виникають наступні питання:

1. Складність програмного забезпечення

2. Як організувати командну роботу

3. Як оптимально організувати спілкування у групі професіоналів різних дисциплін

4. Які методи необхідно використовувати щоб виконати якісний і не дуже дорогий програмний продукт в необхідні терміни

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

Складність інформаційних систем.

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

Причини складності програмного забезпечення:

1. Велика кількість напрямків в інформаційних технологіях

2. Складнощі спілкування членів однієї команди різних напрямків

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

4. Зміна вимог коритсувача і непевність в процесі формулювання вимог

Розробка програмного забезпечення

Розробка ПЗ не у всіз випадках є успішною, тому в процесі розробки виникають наступні питання:

1. Що необхідно зробити, щоб підвищити шанси успішності розробки ПЗ?

2. Як бути впевненим в тому, що результати роботи задовільнять користувача?

3. Як перевірити безпомилковість ПЗ?

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

На всі ці питання намагається знайти відповідь практична дисципліна «ТПСПП». ТПСПП охоплює всі етапи розробки системи.

ТПСПП включає в себе:

1. Методи управління під час розробки ПЗ

2. Технології планування розробки

3. Оцінки ціни або вартості розробки

4. Розклад проведення робіт

5. Та моніторинг процесу розробки ПЗ

6. Аналіз різних методів проектування системи

7. Технології підвищення надійності ПЗ

8. Методи підготовки технічної і користувацької документації

9. Аналіз процедур контролю якості

10. Різні методи зменшення витрат на підтримку, усунення неполадок, модифікацію ПЗ

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

Останнім часом на розробку програмних продуктів спостерігають кризу пов’язану з розробкою ПЗ. До основних причин кризи відносять:

1. Постійно зростаюча складність ПЗ та складність процесу їх розробки

Якщо провести детальний аналіз причин кризи, то можна виділити наступні їх аспекти:

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

2. Вартісна підтримка систем

3. Рідкісне повторне використання вже існуючих проектів і компонентів ПЗ в нових розробках (це пов’язане із специфікою розробки систем)

4. Тривалий і дорогий цикл розробки ПЗ (тому існують великі шанси, що проект буде незавершений)

5. Практична необхідність робити зміни та оновлювати систему

6. Велика кількість та специфіка мов програмування, які використовуються в процесі розробки

7. Велика залежність результатів роботи від зміни методів, пристроїв, та інших умов, які безпосередньо впливають на розробку

8. Проблеми, які пов’язані з інтеграцією готових компонентів розроблених різними командами

На практиці всі ці явища намагаються обмежити завдяки:

1. різних методів та інструментів, що полегшують роботу зі складними системами

2. використання методів аналізу нових проблем, які можуть виникнути в процесі розробки

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

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

Одним із методів подолання кризи є концептуальне моделювання.

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

Процес побудови концептуальної моделі стосується:

1. сприйняття світу (як ми бачимо систему в використанні (цілі, задачі))

2. аналітична модель реальної (що би мало входити в систему)

3. модель структури даних та процесів (те що треба виконати, реалізувати)

Життєві цикли ПЗ

На практиці існують дві базові моделі:

1. класична модель водоспаду (каскадна модель)

2. спіральна модель

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

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

Каскадна модель передбачає наступні етапи розробки ПЗ:

1. Визначення вимог – на цьому етапі формулюються цілі майбутньої системи та основні її аспекти

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

3. Реалізації – на даному етапі відбувається написання коду, реалізація дизайну системи та тестування модулів

4. Тестування – об’єднання системи в єдине ціле та загальне тестування системи

5. Підтримка – цей етап пов’язаний з періодом, коли замовник експлуатує програмний продукт, а виробник його підтримує (обслуговує). В процесі підтримки замовник може попросити внести зміни в систему або доповнити її.

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

В приведеній каскадній моделі крім вказаних етапів також можуть бути присутні інші етапи:

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

2. Аналізу – на цьому етапі будується аналітична (логічна) модель системи

3. Документування – на цьому етапі відбувається виготовлення всієї документації призначеної для користувача

4. Установка – на цьому етапі система передається користувачу. Цей етап йде після тестування перед підтримкою

Переваги каскадної моделі:

Основна перевага каскадної моделі – керованість розробкою. Така модель значно полегшує планування розробки та її моніторинг.

Недоліки каскадної моделі:

1. Необхідність чіткого дотримання встановленого порядку проведення роботи

2. Підвищення ціни розробки в наслідок помилок зроблених на різних етапах розробки

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

Модель водоспаду із зворотними зв’язками

Малюнок не повний – повинні бути зворотні зв’язки (стрілки) від поточного етапу до всіх попередніх.

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

<== предыдущая лекция | следующая лекция ==>
Визначення робочого набору | Прототипування
Поделиться с друзьями:


Дата добавления: 2014-01-05; Просмотров: 3767; Нарушение авторских прав?; Мы поможем в написании вашей работы!


Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет



studopedia.su - Студопедия (2013 - 2024) год. Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав! Последнее добавление




Генерация страницы за: 0.17 сек.