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

З середини 1960-х до середини 1970-х років програми переважно писалися за принципом RYO (Roll Your Own), тобто кожен писав так, як хотів і як умів — не було певних підходів до процесу розробки ПО. В середині 70-х років минулого сторіччя виникла ідея структурного програмування (SDM, Structure Design Methodology), відбувається розвиток методології програмування і технології моделювання. У Європі головним ідеологом структурного програмування вважається Дейкстра, а в США – Демарко. Розробники приходять до розуміння, що систему (програму) можна описувати без використання конструкцій мови програмування, а на абстрактнішому рівні. У цей період часу програмісти (і не тільки) зрозуміли, що моделювання грає важливу роль, а разом з ним і правила для моделювання. До цього моменту відноситься і введення блок-схем (flow charts). Для цього етапу розвитку технології моделювання характерний, що центром програмного продукту є процес, а не дані (для зберігання даних використовувалися індексні файли і ієрархічні бази даних).

В середині 1980-х років відбувається черговий прорив: з'являються реляційні бази даних, один з авторів яких — James Martin. Головною частиною програмного продукту стають дані і бази даних. Теоретиками була створена реляційна алгебра, що стала основою для побудови реляційних баз даних. Звідси і новий підхід до моделювання систем — IE (Information Engineering — методи і засоби проектування прикладних і інформаційних програм), в яких за основу беруться не процеси, а структури оброблюваних даних.

С появлением персональных компьютеров на уровне систем клиент-сервер развивается графический интерфейс (GUI, Graphic User Interface). В связи с этим рождается объектно-ориентированный подход к проектированию (ОО), объединивший в одной сущности программу и данные.

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

Головні складові CASE-продукта такі:

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

· графічні редактори (Graphic Editors), які допомагають малювати діаграми; виникли з розповсюдженням РС і GUI. Цими двома складовими (так звані upper case технології) CASE-технологии спочатку і були обмежені. Діаграми почало легко малювати, їх з'явилася множина, але користі від них було мало – проектування було розвинене лише на рівні малювання. Існували багато проблем: ніхто не знав всі використовувані в той момент технології (не міг писати і для мейнфреймів, і для клієнта, і для сервера); неясно було, як об'єднувати написане для різних платформ.

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

· репозиторій, своєрідна база даних для зберігання результатів роботи програмістів (склалася парадоксальна ситуація: до того моменту базами даних користувалися всі, окрім програмістів), відбувається перехід від "плоских" файлів до системи зберігання інформації про розробку проекту.