За історії інформатики на тему

Санкт Петербурзький державний університет інформаційних технологій механіки і оптики

реферат

За історії інформатики на тему

"Історія розвитку методів і технологій

проектування додатків "

Санкт-Петербург

2009 г.

Зміст

Вступ. 3

1. Розвиток методів проектування. 5

1.1 Структурна методологія. 5

1.2 CASE-технології. 8

2. Моделі життєвого циклу програми. 10

2.1 Каскадна модель. 11

2.2 Спіральна модель. 13

Висновок. 16

Список літератури .. 17

Вступ

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

· Складність опису: досить велика кількість функцій, процесів, елементів даних і складні взаємозв'язки між ними; вимагає ретельного моделювання і аналізу даних і процесів;

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

· Відсутність прямих аналогів, що обмежує можливість використання будь-яких типових проектних рішень і прикладних систем;

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

· Функціонування в неоднорідному середовищі на декількох апаратних платформах;

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

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

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

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

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

1. Розвиток методів проектування

До недавнього часу проектування ІС виконувалося в основному на інтуїтивному рівні із застосуванням неформалізованих методів, заснованих на мистецтві, практичному досвіді, експертних оцінках і дорогих експериментальних перевірках якості функціонування ІС.

1.1 Структурна методологія

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

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

Частина PLEX-теорій відносяться до методології і мови опису систем, були названі їх автором, Дугласом Т. Россом «Методологією структурного аналізу і проектування» (SADT - Structural Analysis and Design Technique). Вихідна робота над SADT почалася в 1969 р Перше її велике додаток було реалізовано в 1973 р при розробці великого аерокосмічного проекту, коли вона була кілька переглянута співробітниками SofTech, Inc. У 1974 р SADT була ще поліпшена і передана однією з найбільших європейських телефонних компаній. Поява SADT на ринку відбулося в 1975 р після річної оформлення у вигляді продукту. ДО 1981 р SADT вже використовували більш ніж в 50 компаніях при роботі більш ніж над 200 проектами, що включали понад 2000 людей і охоплювали дюжину проблемних областей, в тому числі телефонні мережі, аерокосмічне виробництво, управління і контроль, облік матеріально-технічних ресурсів та обробку даних. Її широке поширення в даний час в європейській, далекосхідній і американської аерокосмічної промисловості (під назвою IDEF0) дозволяє ці цифри істотно збільшити. Таким чином, SADT виділяється серед сучасних методологій опису систем завдяки своєму широкому застосуванню.

На початку 70-х років методологія SADT була реалізована у вигляді чіткої формальної процедури. В ході цієї реалізації, SADT-аналітики використовували бланки діаграм і титульні листи. В кінці 70-х з'явилися комп'ютери достатньої потужності і діапазону з прийнятною швидкістю створення графічних зображень. Це дало можливість автоматизувати ті структурні методи, які, подібно до SADT, істотно спиралися на графіку. Хоча такі технології в той час тільки починали розвиватися, ВПС США фінансували розробку першої системи автоматизації SADT (і, до речі кажучи, першого автоматизованого кошти для структурного аналізу, що робить упор на графіку), названого AUTOIDEF0.

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

Сучасний рівень інформаційних технологій надає багатий вибір методів для створення автоматизованої підтримки SADT. Найбільш доступним на сьогоднішній день SADT-засобом є Design / IDEF (Meta Software Corp.) - спочатку побудований в рамках програми інтегрованої комп'ютеризації виробництва і широко використовуваний нині в різних областях діяльності. Автоматизована підтримка SADT відбувається в розвитку від просто графічного кошти до програмного забезпечення, що функціонує на базі знань більш загальних понять моделювання. Такі розвинені засоби мають здатність розуміти семантику взаємозалежної мережі діаграм SADT і безлічі моделей, а також об'єднувати це безліч відомостей і правил з іншими технологіями.

У той же час розробка по SADT методології зазвичай породжувала такі проблеми:

· Неадекватна специфікація вимог;

· Нездатність виявляти помилки в проектних рішеннях;

· Низька якість документації, що знижує експлуатаційні якості;

· Затяжний цикл і незадовільні результати тестування.

1.2 CASE-технології

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

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

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

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

· Широке розмаїття якості і можливостей CASE-засобів;

· Відносно невеликий час використання CASE-засобів в різних організаціях і брак досвіду їх застосування;

· Широке розмаїття в практиці впровадження різних організацій;

· Відсутність детальних метрик і даних для вже виконаних і поточних проектів;

· Широкий діапазон предметних областей проектів;

· Різна ступінь інтеграції CASE-засобів в різних проектах

Успішне впровадження CASE-засобів має забезпечити такі вигоди як:

· Високий рівень технологічної підтримки процесів розробки і супроводу ПЗ;

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

· Прийнятний рівень віддачі від інвестицій в CASE-засоби.

2. Моделі життєвого циклу додатки

Основним нормативним документом, що регламентує ЖЦ ПО, є міжнародний стандарт ISO / IEC 12207 [5] (ISO - International Organization of Standardization - Міжнародна організація по стандартизації, IEC - International Electrotechnical Commission - Міжнародна комісія з електротехніки). Він визначає структуру ЖЦ, що містить процеси, дії і завдання, які повинні бути виконані під час створення ПЗ.

Структура ЖЦ ПО за стандартом ISO / IEC 12207 базується на трьох групах процесів:

· Основні процеси ЖЦ ПО (придбання, постачання, розробка, експлуатація, супровід);

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

· Організаційні процеси (управління проектами, створення інфраструктури проекту, визначення, оцінка та поліпшення самого ЖЦ, навчання).

Стандарт ISO / IEC 12207 не пропонує конкретну модель ЖЦ і методи розробки ПЗ (під моделлю ЖЦ розуміється структура, що визначає послідовність виконання і взаємозв'язку процесів, дій і завдань, що виконуються протягом ЖЦ. Модель ЖЦ залежить від специфіки ІС і специфіки умов, в яких остання створюється і функціонує). Його регламенти є загальними для будь-яких моделей ЖЦ, методологій і технологій розробки. Стандарт ISO / IEC 12207 описує структуру процесів ЖЦ ПО, але не конкретизує в деталях, як реалізувати або виконати дії і завдання, включені в ці процеси.

До теперішнього часу найбільшого поширення набули наступні дві основні моделі ЖЦ:

· Каскадний модель (70-85 р.р.);

· Спіральна модель (86-90 р.р.).

2.1 Каскадна модель

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

Малюнок 1. Каскадна схема розробки

Позитивні сторони застосування каскадного підходу полягають в наступному [2]:

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

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

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

Малюнок 2. Реальний процес розробки в каскадної моделі

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

2.2 Спіральна модель

Для подолання перелічених проблем була запропонована спіральна модель ЖЦ [10] (рис. 3), що робить упор на початкові етапи ЖЦ: аналіз і проектування. На цих етапах реалізація технічних рішень перевіряється шляхом створення прототипів. Кожен виток спіралі відповідає створенню фрагмента або версії ПЗ, на ньому уточнюються цілі і характеристики проекту, визначається його якість і плануються роботи наступного витка спіралі. Таким чином поглиблюються і послідовно конкретизуються деталі проекту і в результаті вибирається обгрунтований варіант, який доводиться до реалізації.

Малюнок 3. Спіральна модель

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

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

Хоча індустрія розробки ПО досить молода, багато компаній-розробники вже усвідомили, що успіх програмних проектів залежить від однозначного визначення і грамотного документування процесу. Корпорація Rational Software, провідний виробник інструментарію для створення складних програмних систем, формалізувала технологічний процес розробки ПО і випустила на ринок структуровану базу знань під назвою Rational Unified Process (RUP), до якої увійшли методичні рекомендації провідних розробників з ефективного створення додатків і систем. При цьому RUP не є щось застигле. База знань регулярно оновлюється і вдосконалюється з урахуванням передового досвіду. RUP веде свою історію від продуктів Rational Approach і Objectory Process 3.8, об'єднання яких відбулося після злиття в 1995 р корпорацій Rational Software і Objectory AB. Основними поняттями RUP є артефакт (artifact) і прецедент (precedent). Артефакти - це деякі продукти проекту, породжувані або використовуються в ньому при роботі над остаточним продуктом. Прецеденти - це послідовності дій, які виконуються системою для отримання спостережуваного результату.

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

У 1994 році Граді Буч і Джеймс Рамбо, що працювали в компанії Rational Software, об'єднали свої зусилля для створення нової мови об'єктно-орієнтованого моделювання. За основу мови вони взяли на себе методи моделювання, розроблені Бучем (Booch) і Рамбо (Object Modeling Technique - OMT). OMT був орієнтований на аналіз, а Booch - на проектування програмних систем. У жовтні 1995 року була випущена попередня версія 0.8 уніфікованого методу (англ. Unified Method). Восени 1995 року до компанії Rational приєднався Айвар Якобсон, автор методу Object-Oriented Software Engineering - OOSE. OOSE забезпечував чудові можливості для специфікації бізнес-процесів і аналізу вимог за допомогою сценаріїв використання. OOSE був також інтегрований в уніфікований метод.

На цьому етапі основна роль в організації процесу розробки UML перейшла до консорціуму OMG (Object Management Group). Група розробників в OMG, в яку також входили Буч, Рамбо і Якобсон, випустила специфікації UML версій 0.9 та 0.91 в червні і жовтні 1996 року.

На хвилі зростаючого інтересу до UML до розробки нових версій мови в рамках консорціуму UML Partners приєдналися такі компанії, як Digital Equipment Corporation, Hewlett-Packard, i-Logix, IntelliCorp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle Corporation, Rational Software , Texas Instruments і Unisys. Результатом спільної роботи стала специфікація UML 1.0, що вийшла в січні 1997 року. У листопаді того ж року за нею пішла версія 1.1, що містила поліпшення нотації, а також деякі розширення семантики.

висновок

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

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

Список літератури

1. Д. Марка, К. МагГоуен. Методологія структурного аналізу і проектування SADT. -М .: МетаТехнологія, 1993 р .;

2. Г. Буч. Об'єктно-орієнтований аналіз та проектування з прикладами додатків. - Вільямс, 2008;

3. Дж. Нільссон. Застосування DDD і шаблонів проектування: проблемно-орієнтоване проектування додатків з прикладами на C # і .NET. - Вільямс, 2007;

4. М. Тернер. Основи Microsoft Solution Framework. - Пітер, 2008;

5. Е. Йордон. Об'єктно-орієнтований аналіз та проектування систем.- Лорі, 2007;

6. Е. Таненбаум. Розподілені системи. Принципи та парадигми. - Пітер, 2003;

7. IBM Developer Networks: Rational software developer resources http://www.ibm.com/developerworks/rational