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

Размещено на http://www.allbest.ru/

Содержание

Введение

1 Технологии создания программного обеспечения

1.1 Технология структурного программирования

1.2 Технология объектно-ориентированного программирования

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

1.4 Технология Oracle

1.5 Технология Borland

2 Методические основы технологий создания программного обеспечения

2.1 Визуальное моделирование

2.2 Методы структурного анализа и проектирования программного обеспечения

2.3 Методы объектно-ориентированного анализа и проектирования программного обеспечения

2.4 Методы моделирования бизнес-процессов и спецификации требований

2.5 Методы анализа и проектирования программного обеспечения

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

3.1 Проектирование программного обеспечения распределенных информационных систем

3.2 Структурный подход к проектированию информационных систем

3.3 Проектирование информационных систем на основе объектно-ориентированного подхода

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

3.5 Проблемы преподавания структурного и объектно-ориентированного программирования

Заключение

Глоссарий

Введение

Создание систем программного обеспечения - это сложная и трудоемкая работа, требующая высокой квалификации участвующих в ней специалистов. Однако создание таких систем выполняется на интуитивном уровне с применением неформализованных методов, основанных на искусстве, практическом опыте, экспертных оценках и дорогостоящих экспериментальных проверках качества функционирования программного обеспечения. По данным Института программной инженерии (Software Engineering Institute, SEI) в последние годы до 80% всего эксплуатируемого программного обеспечения разрабатывалось без использования какой-либо дисциплины проектирования, методом «code and fix» (кодирования и исправления ошибок).

В конце 60-х годов прошлого века в США было отмечено явление под названием «software crisis» (кризис программного обеспечения). Это выражалось в том, что большие проекты стали выполняться с отставанием от графика или с превышением сметы расходов, разработанный продукт не обладал требуемыми функциональными возможностями, производительность его была низка, качество получаемого программного обеспечения не устраивало потребителей.

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

Актуальность исследования определяется современными тенденциями проектирования программного обеспечения распределенных информационных систем со структурным и объектно-ориентированным подходом.

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

Для достижения цели определены следующие задачи исследования:

1. Проведение анализа научно-технической литературы в аспекте структуры и содержания курсов, ориентированных на изучение объектно-ориентированного и структурного программирования.

2. Изучение теоретических основ структурного и объектно-ориентированного подходов, технологии создания программного обеспечения.

3. Ознакомление с методическими основами создания программного обеспечения.

4. Рассмотрение внедрения технологий создания программного обеспечения в организации для реализации выполнения пилотного проекта.

5. Обосновать сопоставление и взаимосвязь структурного и объектно-ориентированного подходов при создании программного обеспечения распределенных информационных систем.

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

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

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

Для решения поставленных задач использованы следующие методы исследования: анализ работ в области теоретической информатики, ресурсов сети Интернет по проблемам объектно-ориентированного программирования; наблюдение, выявление взаимосвязанности структурного и объектно-ориентированного программирования.

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

Аналитические исследования и обзоры, выполняемые в течение ряда последних лет ведущими зарубежными аналитиками, показывали не слишком обнадеживающие результаты. Результаты исследований, выполненных в 1995 году компанией Standish Group, которая проанализировала работу 364 американских корпораций и итоги выполнения более 23 тысяч проектов, связанных с разработкой программного обеспечения, выглядели следующим образом:

- только 16, 2% завершились в срок, не превысили запланированный бюджет и реализовали все требуемые функции и возможности;

- 52, 7% проектов завершились с опозданием, расходы превысили запланированный бюджет, требуемые функции не были реализованы в полном объеме;

- 31, 1% проектов были аннулированы до завершения;

- для двух последних категорий проектов бюджет среднего проекта оказался превышенным на 89%, а срок выполнения - на 122%.

В 1998 году процентное соотношение трех перечисленных категорий проектов лишь немного изменилось в лучшую сторону (26%, 46% и 28% соответственно).

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

В числе причин возможных неудач, по мнению разработчиков, фигурируют:

нечеткая и неполная формулировка требований к программному обеспечению;

недостаточное вовлечение пользователей в работу над проектом;

отсутствие необходимых ресурсов;

неудовлетворительное планирование и отсутствие грамотного управления проектом;

частое изменение требований и спецификаций;

новизна и несовершенство используемой технологии;

недостаточная поддержка со стороны высшего руководства;

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

Объективная потребность контролировать процесс разработки сложных систем программного обеспечения, прогнозировать и гарантировать стоимость разработки, сроки и качество результатов привела в конце 60-х годов прошлого века к необходимости перехода от кустарных к индустриальным способам создания программного обеспечения и появлению совокупности инженерных методов и средств создания программного обеспечения, объединенных общим названием «программная инженерия» (software engineering). В основе программной инженерии лежит одна фундаментальная идея: проектирование программного обеспечения является формальным процессом, который можно изучать и совершенствовать. Освоение и правильное применение методов и средств создания программного обеспечения позволяет повысить его качество, обеспечить управляемость процесса проектирования программного обеспечения и увеличить срок его жизни. В то же время, попытки чрезмерной формализации процесса, а также прямого заимствования идей и методов из других областей инженерной деятельности (строительства, производства) привели к ряду серьезных проблем. После двух десятилетий напрасных ожиданий повышения продуктивности процессов создания программного обеспечения, возлагаемых на новые методы и технологии, специалисты в индустрии программного обеспечения пришли к пониманию, что фундаментальная проблема в этой области - неспособность эффективного управления проектами создания программного обеспечения. Невозможно достичь удовлетворительных результатов от применения даже самых совершенных технологий и инструментальных средств, если они применяются бессистемно, разработчики не обладают необходимой квалификацией для работы с ними, и сам проект выполняется и управляется хаотически, в режиме «тушения пожара». Бессистемное применение технологий создания программного обеспечения, в свою очередь, порождает разочарование в используемых методах и средствах (анализ мнений разработчиков показывает, что среди факторов, влияющих на эффективность создания программного обеспечения, используемым методам и средствам придается гораздо меньшее значение, чем квалификации и опыту разработчиков). Если в таких условиях отдельные проекты завершаются успешно, то этот успех достигается за счет героических усилий фанатично настроенного коллектива разработчиков. Постоянное повышение качества создаваемого программного обеспечения и снижение его стоимости может быть обеспечено только при условии достижения организацией необходимой технологической зрелости, создании эффективной инфраструктуры как в сфере разработки программного обеспечения, так и в управлении проектами. В соответствии с моделью SEI СММ (Capability Maturity Model), в хорошо подготовленной (зрелой) организации персонал обладает технологией и инструментарием оценки качества процессов создания программного обеспечения на протяжении всего жизненного цикла программного обеспечения и на уровне всей организации.

Одна из причин распространенности «хаотического» процесса создания программного обеспечения - стремление сэкономить на стадии разработки, не затрачивая времени и средств на обучение разработчиков и внедрение технологического процесса создания программного обеспечения. Эти затраты до недавнего времени были довольно значительными и составляли, по различным оценкам (в частности, Gartner Group), более $100 тыс. и около трех лет на внедрение развитой технологии создания программного обеспечения, охватывающей большинство процессов жизненного цикла программного обеспечения, в многочисленной команде разработчиков. Причина - в «тяжести» технологических процессов. «Тяжелый» процесс обладает следующими особенностями:

- необходимость документировать каждое действие разработчиков;

- множество рабочих продуктов (в первую очередь - документов), создаваемых в бюрократической атмосфере;

- отсутствие гибкости;

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

Альтернативой «тяжелому» процессу является адаптивный (гибкий) процесс, основанный на принципах «быстрой разработки программного обеспечения», интенсивно развиваемых в последнее десятилетие.

В начале 2001 года ряд ведущих специалистов в области программной инженерии (Алистер Коберн, Мартин Фаулер, Джим Хайсмит, Кент Бек и другие) сформировали группу под названием Agile Alliance. Слово agile (быстрый, ловкий, стремительный) отражало в целом их подход к разработке программного обеспечения, основанный на богатом опыте участия в разнообразных проектах в течение многих лет. Этот подход под названием «Быстрая разработка программного обеспечения» (Agile software development) базируется на четырех идеях, сформулированных ими в документе «Манифест быстрой разработки программного обеспечения» (Agile Alliance's Manifesto) и заключающихся в следующем:

- индивидуумы и взаимодействия между ними ценятся выше процессов и инструментов;

- работающее программное обеспечение ценится выше всеобъемлющей документации;

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

- реагирование на изменения ценится выше строгого следования плану.

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

- когда она позволяет людям легче выразить свои мысли;

- когда она выполняет задачи, невыполнимые вручную;

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

- когда она облегчает общение между людьми;

Технология не должна действовать против характера культурных ценностей и познавательной способности человека. При этом следует четко понимать: при всех достоинствах быстрой разработки программного обеспечения этот подход не является универсальным и применим только в проектах определенного класса. Для характеристики таких проектов Алистер Коберн ввел два параметра - критичность и масштаб. Критичность определяется последствиями, вызываемыми дефектами в программном обеспечении, ее уровень может иметь одно из четырех значений:

- C - дефекты вызывают потерю удобства;

- D - дефекты вызывают потерю возместимых средств (материальных или финансовых) ;

- E - дефекты вызывают потерю невозместимых средств;

- L - дефекты создают угрозу человеческой жизни.

Масштаб определяется количеством разработчиков, участвующих в проекте:

- от 1 до 6 человек - малый масштаб;

- от 6 до 20 человек - средний масштаб;

- свыше 20 человек - большой масштаб.

По оценке Коберна, быстрая разработка программного обеспечения применима только в проектах малого и среднего масштаба с низкой критичностью (C или D). Общие принципы оценки технологий в таких проектах заключаются в следующем:

- интерактивное общение лицом к лицу - это самый дешевый и быстрый способ обмена информацией;

- избыточная «тяжесть» технологии стоит дорого;

- более многочисленные команды требуют более «тяжелых» и формальных технологий;

- большая формальность подходит для проектов с большей критичностью;

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

- дисциплина, умение и понимание противостоят процессу, формальности и документированию;

- потеря эффективности в некритических видах деятельности вполне допустима.

Одним из наиболее известных примеров практической реализации подхода быстрой разработки программного обеспечения является «Экстремальное программирование» (Extreme Programming - EP). Этот метод предназначен для небольших компактных команд, нацеленных на получение как можно более высокого качества и продуктивности, и достигает этого посредством насыщенной, неформальной коммуникации, придания на персональном уровне особого значения умению и навыкам, дисциплине и пониманию, сводя к минимуму все промежуточные рабочие продукты.

1. Технологии создания программного обеспечения

1.1 Технология структурного программирования

программное обеспечение

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

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

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

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

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

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

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

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

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

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

- функционального описания на подфункции;

- соответствующие программы на отдельные инструкции.

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

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

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

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

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

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

Фундаментальным понятием и функциональным элементом технологии структурного программирования является - модуль.

Модуль - это подпрограмма, но оформленная в соответствии со следующими правилами:

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

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

3. модуль может вызывать другие модули по их именам;

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

5. модуль кодируется только стандартными структурами и тщательно комментируется.

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

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

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

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

Структурный подход рекомендует соблюдать следующие принципы при создании программного продукта:

- модульность программ;

- структурное кодирование модулей программ;

- нисходящее проектирование рациональной иерархии модулей программ;

- нисходящая реализация программы с использованием заглушек;

- осуществление планирования на всех стадиях проекта;

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

Модульность программ характеризуется тем, что вся программа состоит из модулей. Некоторые смысловые группы модулей сосредотачиваются в отдельных файлах. Например, в отдельных файлах (Unit) могут быть сосредоточены модули текстового редактора и модули иерархического меню.

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

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

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

Осуществление планирования на всех стадиях проекта позволяет первоначально спланировать как состав стадий, таки продолжительность всех этапов работ. Такое планирование позволяет завершить разработку в заданный срок при заданных затратах на разработку.

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

При структурном программировании программа в основном реализуется (собирается и тестируется) сверху вниз. Сначала из 20-30 модулей пишется ядро. Чтобы начать тестировать, недостающие модули нижних уровней заменяются заглушками. По окончании тестирования ядра, заглушки заменяются новыми готовыми модулями, но если программа еще не закончена, то для успешной ее линковки понадобятся все новые заглушки недостающих модулей. Затем проводится тестирование собранной части и т. д.

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

Проектированию структуры программы предшествует разработка внешних функциональных описаний. Функциональные описания (алгоритмы выполнения программы) для достижения их восприятия должны быть декомпозированы от общего к частному. Также они должны включать описания форм представления и объема внутренних данных.

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

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

Фонд критериев оптимальности схем иерархии является необходимым подспорьем при оптимизации схем иерархии и состоит из следующих критериев:

- полнота выполнения специфицированных функций;

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

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

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

- возможность связывания программы с обширной многоуровневой схемой иерархии конкретным редактором связей (линковщиком). Если начинается работа над новой программой, то очень полезно выполнить на эВМ ее модель в виде пустых заглушек модулей, которые не содержат никаких действий;

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

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

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

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

- всемерно сокращение затрат на тестирование уже собранного ядра программы по ключевым датам сетевого графика реализации. Характеризуется простотой используемых заглушек и качеством тестирования по всем вычислительным маршрутам модулей. Достигается первичной реализацией сверху вниз модулей ввода и вывода программы с отсрочкой реализации остальных ветвей схемы иерархии. Обычно затраты на тестирование составляют около 60% стоимости всего проекта. Хорошая схема иерархии сокращает затраты на тестирование по сравнению с первоначальным вариантом в 2-5 раз и более;

- использованием в данном проекте как можно большего числа разработанных в предшествующих проектах модулей и библиотек при минимальном объеме изготавливаемых заново частей;

- удачное распределение модулей по компилируемым файлам программы и библиотекам;

- накопление уже готовых модулей и библиотек модулей для использования их во всех новых разработках.

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

1.2 Технология объектно-ориентированного программирования

По мере развития вычислительной техники создавались новые подходы, помогающие справляться с растущим усложнением программ. Использование структурного программирования при написании умеренно сложных программ принесло свои результаты, однако оказалось несамостоятельным тогда, когда программа достигала определенной длины. Чтобы писать более сложные программы, были разработаны принципы объектно-ориентированного программирования. Объектно-ориентированное программирование - это подход к разработке программного обеспечения, основанный на объектах, а не на процедурах. Этот подход позволяет максимизировать принципы модульности и «сокрытия информации». Объектно-ориентированное программирование базируется на связывании или инкапсуляции структур данных и процедуры, которая работает с данными в структуре, с модулем.

Объектно-ориентированное программирование позволяет разложить проблему на составные части. В этом случае вся процедура упрощается, и появляется возможность оперировать с гораздо более объемными программами. Каждая составляющая становится самостоятельным объектом, содержащим свои собственные коды и данные, относящиеся к нему.

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

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

- объект - обладающий именем набора данных (полей объекта), физически находящихся в памяти компьютера, и методов, имеющих доступ к ним. Имя используется для доступа к полям и методам, составляющим объект. В предельных случаях объект может не содержать полей и методов, а также не иметь имени;

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

Объектно-ориентированное программирование основано на следующих принципах:

- абстрагирования данных;

- инкапсуляции;

- наследования;

- полиморфизма;

- «позднего связывания».

Абстрагирование является одним из основных методов, используемых для решения сложных задач. Хоар считает, что «абстрагирование проявляется в нахождении сходств между определенными объектами, ситуациями или процессами реального мира, и в принятии решений на основе этих сходств, отвлекаясь на время от имеющихся различий» [42]. Шоу определила это понятие так: «Упрощенное описание или изложение системы, при котором одни свойства и детали выделяются, а другие опускаются. Хорошей является такая абстракция, которая подчеркивает детали, существенные для рассмотрения и использования, и отпускает те, которые на данный момент несущественны» [43]. Берзинс, Грей и Науман рекомендовали, чтобы «идея квалифицировалась как абстракция только, если она может быть изложена, понята и проанализирована независимо от механизма, который будет в дальнейшем принят для ее реализации» [44]. Суммирую эти разные точки зрения, получается следующее определение абстракции: Абстракция выделяет существенные характеристики некоторого объекта, отличающие его от всех других видов объектов и, таким образом, четко определяет его концептуальные границы с точки зрения наблюдателя.

Инкапсуляция (encapsulation) - это принцип, объединяющий данные и код, манипулирующий этими данными, а также защищающий в первую очередь данные от прямого внешнего доступа и неправильного использования. Другими словами, доступ к данным класса возможен только посредством методов этого же класса.

Наследование (inheritance) - это процесс, посредством которого один объект может приобретать свойства другого. То есть, объект может наследовать основные свойства другого объекта и добавлять к ним свойства и методы, характерные только для него.

Наследование делится на два вида:

1. одиночное наследование - класс (он же подкласс) имеет один и только один суперкласс (предок) ;

2. множественное наследование - класс может иметь любое количество предков (в Java запрещено).

Полиморфизм (polymorphism) - это механизм, использующий одно и то же имя метода для решения двух или более похожих, но несколько отличающихся задач.

Целью полиморфизма применительно к объектно-ориентированному программированию является использование одного имени для задания общих для класса действий. Концепцией полиморфизма является идея «один интерфейс, множество методов».

Механизм «позднего связывания» в процессе выполнения программы определяет принадлежность объекта конкретному классу и производит вызов метода, относящегося к классу, объект которого был использован.

Краеугольным камнем наследования и полиморфизма предстает следующая парадигма: «объект подкласса может использоваться всюду, где используется объект суперкласса».

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

Объектно-ориентированная технология основывается на так называемой объектной модели. Основными ее принципами являются, как уже отмечено выше: абстрагирование, инкапсуляция, модульность, иерархичность, типизация, параллелизм и сохраняемость. Каждый из этих принципов сам по себе нов, но в объектной модели они впервые применены в совокупности.

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

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

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

- развитие и совершенствование языков программирования высокого уровня.

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

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

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%), определяющая функциональные требования к системе;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

...