Развитие методологии проектирования
С середины 1960-х до середины 1970-х годов программы преимущественно писались по принципу RYO (Roll Your Own), т. е. каждый писал так, как хотел и как умел — не было определенных подходов к процессу разработки ПО. В середине 70-х годов прошлого столетия возникла идея структурного программирования (SDM, Structure Design Methodology), происходит развитие методологии программирования и технологии моделирования. В Европе главным идеологом структурного программирования считается Дейкстра, а в США – ДеМарко. Разработчики приходят к пониманию, что систему (программу) можно описывать без использования конструкций языка программирования, а на более абстрактном уровне. В этот период времени программисты (и не только) поняли, что моделирование играет немаловажную роль, а вместе с ним и правила для моделирования. К этому моменту относится и введение блок-схем (flow charts). Для этого этапа развития технологии моделирования характерно, что центром программного продукта является процесс, а не данные (для хранения данных использовались индексные файлы и иерархические базы данных).
В середине 1980-х годов происходит очередной прорыв: появляются реляционные базы данных, один из авторов которых — James Martin. Главной частью программного продукта становятся данные и базы данных. Теоретиками была создана реляционная алгебра [21], ставшая основой для построения реляционных баз данных. Отсюда и новый подход к моделированию систем — IE (Information Engineering — методы и средства проектирования прикладных и информационных программ), в которых за основу принимаются не процессы, а структуры обрабатываемых данных.
С появлением персональных компьютеров на уровне систем клиент-сервер развивается графический интерфейс (GUI, Graphic User Interface). В связи с этим рождается объектно-ориентированный подход к проектированию (ОО), объединивший в одной сущности программу и данные.
Стоит отметить два вида объектно-ориентированного программирования, которые по сей день сосуществуют, хотя и велись споры о правильности каждого из них и нелогичности другого.
Object Action заключается в том, что сначала выбирается объект, а потом уже реализовываются его действия, которые впоследствии будут использованы. Action Object же, наоборот, предлагает продумать необходимые действия, а затем выбрать, какой именно объект будет их реализовывать.
Главные составляющие CASE-продукта таковы:
- методология (Method Diagrams), которая задает единый графический язык и правила работы с ним. CASE-технологии обеспечивают всех участников проекта, включая заказчиков, единым, строгим, наглядным и интуитивно понятным графическим языком, позволяющим получать обозримые компоненты с простой и ясной структурой. При этом программы представляются двумерными диаграммами (которые проще в использовании, чем многостраничные описания), позволяющими заказчику участвовать в процессе разработки, а разработчикам — общаться с экспертами предметной области, разделять деятельность системных аналитиков, проектировщиков и программистов, облегчая им защиту проекта перед руководством, а также обеспечивая легкость сопровождения и внесения изменений в систему.
- графические редакторы (Graphic Editors), которые помогают рисовать диаграммы; возникли с распространением PC и GUI. Этими двумя составляющими (так называемые upper case технологии) CASE-технологии поначалу и были ограничены. Диаграммы стало легко рисовать, их появилось множество, но пользы от них было мало – проектирование было развито лишь на уровне рисования. Существовало много проблем: никто не знал все используемые в тот момент технологии (не мог писать и для мэйнфреймов, и для клиента, и для сервера); неясно было, как объединять написанное для разных платформ.
- генератор: по графическому представлению модели можно сгенерировать исходный код для различных платформ (так называемая low case часть CASE-технологии). Генерация программ позволяет автоматически построить до 85-90% объектного кода или текстов на языках высокого уровня, но только для хорошо формализуемых частей программы (прежде всего, для описания баз данных и для задания форм ввода-вывода информации).Сложная обработка, как обычно, может быть описана с помощью ручного программирования.
- репозиторий, своеобразная база данных для хранения результатов работы программистов (сложилась парадоксальная ситуация: к тому моменту базами данных пользовались все, кроме программистов), происходит переход от "плоских" файлов к системе хранения информации о разработке проекта.
