Составные части технологии программирования (ТП). Отличие ТП от методологии программирования и программной инженерии.

Составные части технологии программирования (ТП). Отличие ТП от методологии программирования и программной инженерии.

Любая технология имеет две стороны:

- принципиальную (внутреннюю);

- организационно-производственную (внешнюю).

К внутренней части ТП относятся технологии проектирования, тестирования и разработки, к внешней – сопровождения.

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

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

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

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

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

Технологии программирования: этапы развития и базовые методологии программирования. Отличие методологии структурного проектирования программных систем от методологии объектно-ориентированного проектирования.

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

В 60-е годы стали развиваться процедурные ЯВУ, в которых применялся механизм подпрограмм. С появлением прерываний появилась концепция процедурного программирования.

 

С ростом объема программ стала применяться процедурная (алгоритмическая) декомпозиция, при которой отдельные части программы или модули представляли собой совокупность процедур для решения некоторой совокупности задач.

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

 

В 70-е годы с появлением ЭВМ 3-го поколения возникла необходимость поддержки коллективной разработки. Из-за концепции «снизу-вверх» случился кризис программирования: компания срывали сроки выполнения заказов, а то и вовсе не выполняли их.

В новых языках программирования (Clu, Pascal, Modula-2) появились средства абстрагирования типов для структурирования данных.

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

Именно в модульном программировании впервые применены механизмы инкапсуляции и импорта-экспорта, ставшие основой для ООП.

В 80-е годы ввиду широкого распространения ПК возникла методология объектно-ориентированного программирования, центральным понятием которой стал класс объектов.

Основными принципами (парадигмами) ООП являются:

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

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

- полиморфизм – определение свойств и методов объекта по контексту (полиморфизм подразумевает отделение идеи «что делать» от ее воплощения внутри иерархии класса объектов «как делать»).

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

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

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

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

В середине 80-х появилась концепция автоматизированной разработки ПО (CASE).

В 90-е годы стали широко использоваться CASE-технологии, бурно развивались среды визуального программирования и СУБД.

Основной концепцией стала методология объектно-ориентированного анализа и проектирования (ООАП) (основа – понятие предметной области).

В этот период стало широко использоваться понятие ЖЦ.

В середине 90-х на смену ООАП пришла методология системного анализа и системного моделирования.

Для разработки графических моделей был разработан унифицированный язык моделирования (UML), послуживший основой для одноименной методологии.

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

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

Компонентный подход лежит в основе технологий, разработанных на базе COM (Component Object Model – компонентная модель объектов) и технологии создания распределенных приложений CORBA (Common Object Request Broker Architecture – общая архитектура с посредником обработки запросов объектов).

Технология быстрой разработки приложений (RAD). Основные принципы и особенности.

Этот подход – в рамках спиральной модели ЖЦ. Модель RAD включает в себя три составляющие:

- небольшую команду программистов (от 2 до 10 человек);

- короткий, но тщательно проработанный производственный график (от 2 до 6 мес.);

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

Жизненный цикл ПО по методологии RAD состоит из четырѐх фаз:

1. Анализа и планирования требований;

2. Проектирования;

3. Построения;

4. Внедрения.

1. На первой стадии пользователи под руководством разработчиков формулируют требования к системе. На этом этапе устанавливаются временные рамки для каждой из последующих фаз разработки. В результате получают список расставленных по приоритету функций будущей ПС; предварительную функциональную модель ПС; предварительную информационную модель ПС.

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

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

Результатом фазы является готовая система, удовлетворяющая всем согласованным требованиям.

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

Основные принципы RAD:

1- разработка приложений итерациями;

2- необязательность полного завершения работ на каждом этапе ЖЦ;

3- обязательное вовлечение пользователей на этапе разработки;

4- использование прототипирования, позволяющего выяснить и удовлетворить все требования конечного пользователя;

5- тестирование и развитие проекта одновременно с разработкой;

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

Основные этапы ЖЦ: Требования к ПО.

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

Выделяют 5 основных этапов ЖЦ, первым является требования к ПО.

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

Уровни требований по Вигерсу:

Бизнес требования: определяют высокоуровневые цели организации - заказчика.

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

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

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

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

Внешние интерфейсы – конкретизируют аспекты взаимодействия, разрабатываемого ПО с другими системами, с ОС, а также определяет возможности мониторинга ПО при эксплуатации.

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

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

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

Качество и улучшения – процесс формулировки характеристик и атрибутов качества, которыми должно обладать ПО, а также методы и достижения на всех этапах жизни цикла и оценивание полученных результатов.

Извлечение требований – процесс извлечения информации из различных источников (договора, материалы аналитиков, обзор систем аналогов, декомпозиция задач и т.д.), проведение технических мероприятий (собеседований, собраний, и т.д. для формирования требований как к ПО, так и к процессам). Все требования согласованы с заказчиками.

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

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

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

Верификация требований – процесс правильности спецификаций на их соответствие, непротиворечивость, полноту, соответствие стандартам.

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

III фаза – разработка

1) концепция проекта подтверждена

2-N) промежуточные версии проекта

IV фаза – стабилизация

1) точка конвергенции пройдена

2) точка достижения нуля пройдена

3) тестирование приемлемости для потребителя

4) версии-кандидаты утверждены

5) контрольное тестирование завершено

6) пилотная версия внедрена

V фаза – развертывание

1) ключевые компоненты развернуты

2) внедрение на места завершено

3) внедрение решения стабилизировано

EXtreme Programming

Разновидность итерационно-инкрементальной модели, является примером «живой разработки» ПО.

· Живое планирование – определенный объем работ до конца текущей фазы.

· Частая смена версий.

· Простые проектные решения.

· Разработка на основе тестирования.

· Постоянная переработка.

Принципы:

· 40-часовая рабочая неделя + Сверхурчные работы.

· Парное программирование.

Rational Unified Process

Разновидность инкрементально-итеративная модель с элементами каскадной.

9 процессов в 4 основных фазах (Начало, Проработка, Разработка, Передача):

1) Бизнес-моделирование – понять и оценить риски, найти пути их решения, определить последствия для бизнеса, для которого будет работать система

2) Управление требованиями (их определение) – создать план проекта

3) Анализ и проектирование – разработать архитектуру, создать проект модели

4) Реализация – разработать исходный код и провести модульное тестирование

5) Тестирование – общая оценка дефектов и оценка качества продукции в целом.

6) Развертывание

7) Управление проектом

8) Управление конфигурацией и изменениями

9) Управление средой проекта

Административная модель.

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

Модель хаоса.

Основной тезис: Работа — естественная и приятная деятельность и большинство людей, на самом деле, очень ответственны и не увиливают от работы.

Характерными чертами модели хаоса являются:

- Отсутствие явно выраженных признаков власти;

- Роль менеджера – поставить задачу, обеспечить ресурсами, не мешать и следить, чтобы не мешали другие;

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

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

- Процесс напоминает творческую игру участников на основе дружеской соревновательности.

Преимущества модели: творческая инициатива участников ничем не связана и потенциал участников раскрывается в полной мере; цель команды – поиск наилучшего результата.

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

- Творческая соревновательность (конкуренция идей и личностей).

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

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

Составные части технологии программирования (ТП). Отличие ТП от методологии программирования и программной инженерии.

Любая технология имеет две стороны:

- принципиальную (внутреннюю);

- организационно-производственную (внешнюю).

К внутренней части ТП относятся технологии проектирования, тестирования и разработки, к внешней – сопровождения.

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

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

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

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

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

Технологии программирования: этапы развития и базовые методологии программирования. Отличие методологии структурного проектирования программных систем от методологии объектно-ориентированного проектирования.

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

В 60-е годы стали развиваться процедурные ЯВУ, в которых применялся механизм подпрограмм. С появлением прерываний появилась концепция процедурного программирования.

 

С ростом объема программ стала применяться процедурная (алгоритмическая) декомпозиция, при которой отдельные части программы или модули представляли собой совокупность процедур для решения некоторой совокупности задач.

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

 

В 70-е годы с появлением ЭВМ 3-го поколения возникла необходимость поддержки коллективной разработки. Из-за концепции «снизу-вверх» случился кризис программирования: компания срывали сроки выполнения заказов, а то и вовсе не выполняли их.

В новых языках программирования (Clu, Pascal, Modula-2) появились средства абстрагирования типов для структурирования данных.

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

Именно в модульном программировании впервые применены механизмы инкапсуляции и импорта-экспорта, ставшие основой для ООП.

В 80-е годы ввиду широкого распространения ПК возникла методология объектно-ориентированного программирования, центральным понятием которой стал класс объектов.

Основными принципами (парадигмами) ООП являются:

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

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

- полиморфизм – определение свойств и методов объекта по контексту (полиморфизм подразумевает отделение идеи «что делать» от ее воплощения внутри иерархии класса объектов «как делать»).

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

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

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

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

В середине 80-х появилась концепция автоматизированной разработки ПО (CASE).

В 90-е годы стали широко использоваться CASE-технологии, бурно развивались среды визуального программирования и СУБД.

Основной концепцией стала методология объектно-ориентированного анализа и проектирования (ООАП) (основа – понятие предметной области).

В этот период стало широко использоваться понятие ЖЦ.

В середине 90-х на смену ООАП пришла методология системного анализа и системного моделирования.

Для разработки графических моделей был разработан унифицированный язык моделирования (UML), послуживший основой для одноименной методологии.

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

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

Компонентный подход лежит в основе технологий, разработанных на базе COM (Component Object Model – компонентная модель объектов) и технологии создания распределенных приложений CORBA (Common Object Request Broker Architecture – общая архитектура с посредником обработки запросов объектов).

Технология быстрой разработки приложений (RAD). Основные принципы и особенности.

Этот подход – в рамках спиральной модели ЖЦ. Модель RAD включает в себя три составляющие:

- небольшую команду программистов (от 2 до 10 человек);

- короткий, но тщательно проработанный производственный график (от 2 до 6 мес.);

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

Жизненный цикл ПО по методологии RAD состоит из четырѐх фаз:

1. Анализа и планирования требований;

2. Проектирования;

3. Построения;

4. Внедрения.

1. На первой стадии пользователи под руководством разработчиков формулируют требования к системе. На этом этапе устанавливаются временные рамки для каждой из последующих фаз разработки. В результате получают список расставленных по приоритету функций будущей ПС; предварительную функциональную модель ПС; предварительную информационную модель ПС.

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

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

Результатом фазы является готовая система, удовлетворяющая всем согласованным требованиям.

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

Основные принципы RAD:

1- разработка приложений итерациями;

2- необязательность полного завершения работ на каждом этапе ЖЦ;

3- обязательное вовлечение пользователей на этапе разработки;

4- использование прототипирования, позволяющего выяснить и удовлетворить все требования конечного пользователя;

5- тестирование и развитие проекта одновременно с разработкой;

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