Сопоставление и взаимосвязь структурного и объектно-ориентированного подходов к проектированию программного обеспечения распределенны

Большинство современных коммерческих программных систем больше и существенно сложнее, чем были их предшественники даже несколько лет тому назад. Этот рост сложности вызвал большое число прикладных исследований по методологии проектирования, особенно, по декомпозиции, абстрагированию и иерархиям. Создание более выразительных языков программирования пополнило достижения в этой области. Возникла тенденция перехода от языков, указывающих компьютеру, что делать (императивные языки). К языкам, описывающим ключевые абстракции проблемной области (декларативные языки).

Из огромного числа языков программирования, появившихся за период развития информационных технологий, лишь наиболее удобные и совершенные были приняты обществом разработчиков и отстояли свое право на существование. Анализируя языки программирования и обстоятельства, сопутствующие их появлению, можно обнаружить множество общих черт. Это позволяет сгруппировать языки по основным используемым принципам и выделить поколения в их развитии. Романова Ю.Д. приводит следующую классификацию:

1. Первое поколение (1954-1958):

- FORTRAN I – математические формулы;

- ALGOL -58 –математические формулы;

- FLOWMATIC - математические формулы;

- IPL V - математические формулы.

2. Второе поколение (1959-1961):

- FORTRAN II – подпрограммы, раздельная компиляция%

- ALGOL-60 – блочные структуры, типы  данных;

- COBOL – описание данных, работа  с файлами.

3. Третье поколение (1962-1970):

- PL/1 FORTRAN+ALGOL+COBOL;

- ALGOL-68 более строгий преемник ALGOL-60;

- PASCAL – более простой преемник ALGOL-60;

- SIMULA – классы, абстрактные данные.

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

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

- малым объемом оперативной  памяти;

- несовершенством системы ввода-вывода.

Ввиду данных ограничений, а также малого количества и дороговизны этих машин, на них работали исключительно высококвалифицированные специалисты, способные управлять ими непосредственно на уровне двоичных кодов. Для облегчения процесса программирования вскоре были созданы языки первого поколения. Это были первые языки, которые приближали программирование к предметной области и отдаляли его от конкретной машины. Их словарь практически полностью был математическим.

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

На момент своего появления, подпрограммы расценивались лишь как средство облегчающее процесс написания программ. Будучи минимальными единицами пере использования, они стали «кирпичиками» для построения первых библиотек. Постепенно они стали играть фундаментальную роль в декомпозиции программных систем.

Выделение подпрограмм, как механизма абстрагирования, имело следующие важные последствия. Были разработаны различные механизмы передачи параметров. Были заложены основания для структурного программирования, что выражалось в появлении языковой поддержки механизмов вложенности подпрограмм и научной разработке структур управления и областей видимости. Возникли методы структурного проектирования, основой которых служило использование процедур или подпрограмм в качестве отдельных строительных блоков.

Первоначально языки программирования не имели достаточно развитых механизмов защиты данных одного модуля от использования их процедурами другого. Во многом эта задача ложилась на коллективы разработчиков. Появившиеся различные подходы в разработке программных систем благоприятствовали возникновению огромного количества языков, имеющих те или иные сильные и слабые стороны в реализации этих принципов. Одним из наиболее развитых представителей языков третьего поколения стал язык ALGOL-68. Будучи универсальным и реализуя почти все разработанные к тому времени механизмы в алгоритмических языках, он был достаточно труден для первоначального освоения, однако позволял разрабатывать системы корпоративного масштабы для больших ЭВМ.

Процедурно-ориентированные языки мало подходят для написания программных систем, где центральное место занимают данные, а не алгоритмы. С определенного момента возникла острая необходимость в языковой поддержке описания произвольных объектов окружающего мира. Вводятся абстрактные типы данных.

Первым языком, в котором нашли свое выражение идеи построения программ на основе данных и объектов стал язык Simula 67. Концепции, заложенные в языке Simula получили свое развитие в серии языков Smaltalk-72,-74,-76,-80, а также в языках C++ и Objective C. При внесении объектно-ориентированного подхода в язык Pascal появился язык Object Pascal. В 90-х годах компания Sun представила миру язык Java, как воплощение идеи платформенной независимости и наиболее полную реализацию концепций объектно-ориентированного программирования, положенных в основу языков Simula 67, Smalltalk, C++.

Объектно-ориентированные системы предъявляют повышенные требования к аппаратуре. Практика использования ТМООП на IBM PC/AT показала замедление скорости выполнения программ в 5-7 раз по сравнению с аналогичными программами на Си или Паскале. При этом время получения готовой программы сократилось в 2-3 раза, программы стали выглядеть яснее, лучше приспособлены для повторного использования. Далее рассматриваются примеры технологий создания программных обеспечений различных компаний-поставщиков.

 

1.3. Технология Rational Unified Process (IBM Rational Software)

Одна из наиболее совершенных технологий, претендующих на роль мирового корпоративного стандарта - Rational Unified Process (RUP). RUP представляет собой программный продукт, разработанный компанией Rational Software, которая в настоящее время входит в состав IBM.

RUP в значительной степени соответствует  стандартам и нормативным документам, связанным с процессами жизненного  цикла программного обеспечения  и оценкой технологической зрелости организаций-разработчиков (ISO 12207, ISO 9000, CMM и др.). Ее основными принципами являются:

- Итерационный и инкрементный (наращиваемый) подход к созданию программного  обеспечения.

- Планирование и управление  проектом на основе функциональных  требований к системе - вариантов использования.

Первый принцип является определяющим. В соответствии с ним разработка системы выполняется в виде нескольких краткосрочных мини-проектов фиксированной длительности (от 2 до 6 недель), называемых итерациями. Каждая итерация включает свои собственные этапы анализа требований, проектирования, реализации, тестирования, интеграции и завершается созданием работающей системы.

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

Общее представление RUP в двух измерениях представлено в приложении. (Приложение А) Горизонтальное измерение представляет время, отражает динамические аспекты процессов и оперирует такими понятиями, как стадии, итерации и контрольные точки. Вертикальное измерение отражает статические аспекты процессов и оперирует такими понятиями, как виды деятельности (технологические операции), рабочие продукты, исполнители и дисциплины (технологические процессы).

Согласно RUP, жизненный цикл программного обеспечения разбивается на отдельные циклы, в каждом из которых создается новое поколение продукта. Каждый цикл, в свою очередь, разбивается на следующие последовательные стадии:

- начальная стадия (inception);

- стадия разработки (elaboration);

- стадия конструирования (construction);

- стадия ввода в действие (transition).

Каждая стадия завершается в четко определенной контрольной точке (milestone). В этот момент времени должны достигаться важные результаты и приниматься критически важные решения о дальнейшей разработке.

Начальная стадия может принимать множество разных форм. Для крупных проектов начальная стадия может вылиться во всестороннее изучение всех возможностей реализации проекта, которое займет месяцы. Во время начальной стадии вырабатывается бизнес-план проекта - определяется, сколько приблизительно он будет стоить и какой доход принесет. Определяются также границы проекта, и выполняется некоторый начальный анализ для оценки размеров проекта.

Результатами начальной стадии являются:

- общее описание системы: основные  требования к проекту, его характеристики  и ограничения;

- начальная модель вариантов  использования (степень готовности - 10-20%);

- начальный проектный глоссарий (словарь терминов);

- начальный бизнес-план;

- план проекта, отражающий стадии  и итерации;

- один или несколько прототипов.

На стадии разработки выявляются более детальные требования к системе, выполняется высокоуровневый анализ предметной области и проектирование для построения базовой архитектуры системы, создается план конструирования и устраняются наиболее рискованные элементы проекта.

Результатами стадии разработки являются:

- модель вариантов использования (завершенная по крайней мере  на 80%), определяющая функциональные  требования к системе;

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

- описание базовой архитектуры  будущей системы;

- работающий прототип;

- уточненный бизнес-план;

- план разработки всего проекта, отражающий итерации и критерии  оценки для каждой итерации.

Самым важным результатом стадии разработки является описание базовой архитектуры будущей системы. Эта архитектура включает:

модель предметной области, которая отражает понимание бизнеса и служит отправным пунктом для формирования основных классов предметной области;

технологическую платформу, определяющую основные элементы технологии реализации системы и их взаимодействие.

Эта архитектура является основой всей дальнейшей разработки, она служит своего рода проектом для последующих стадий. В дальнейшем неизбежны незначительные изменения в деталях архитектуры, однако, серьезные изменения маловероятны.

Стадия разработки занимает около пятой части общей продолжительности проекта. Основными признаками завершения стадии разработки являются два события:

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

идентифицированы все наиболее серьезные риски, и степень понимания наиболее важных из них такова, что известно, как справиться с ними.

Сущность планирования заключается в определении последовательности итераций конструирования и вариантов использования, реализуемых на каждой итерации.

Итерации на стадии конструирования являются одновременно инкрементными и повторяющимися:

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

итерации являются повторяющимися по отношению к разрабатываемому коду.

На каждой итерации некоторая часть существующего кода переписывается с целью сделать его более гибким.

Результатом стадии конструирования является продукт, готовый к передаче конечным пользователям. Он содержит следующие понятия:

программное обеспечение, интегрированное на требуемых платформах;

руководства пользователя;

описание текущей реализации.

Назначением стадии ввода в действие является передача готового продукта в распоряжение пользователей. Данная стадия включает:

бета-тестирование, позволяющее убедиться, что новая система соответствует ожиданиям пользователей;

параллельное функционирование с существующей (legacy) системой, которая подлежит постепенной замене;

конвертирование баз данных;

оптимизацию производительности;

обучение пользователей и специалистов службы сопровождения.

Статический аспект RUP представлен следующими основными элементами:

роли;

виды деятельности;

рабочие продукты;

дисциплины.

Понятие «роль» (role) определяет поведение и ответственность личности или группы личностей, составляющих проектную команду. Одна личность может играть в проекте много различных ролей.