![]() Заглавная страница Избранные статьи Случайная статья Познавательные статьи Новые добавления Обратная связь FAQ Написать работу КАТЕГОРИИ: ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ТОП 10 на сайте Приготовление дезинфицирующих растворов различной концентрацииТехника нижней прямой подачи мяча. Франко-прусская война (причины и последствия) Организация работы процедурного кабинета Смысловое и механическое запоминание, их место и роль в усвоении знаний Коммуникативные барьеры и пути их преодоления Обработка изделий медицинского назначения многократного применения Образцы текста публицистического стиля Четыре типа изменения баланса Задачи с ответами для Всероссийской олимпиады по праву ![]() Мы поможем в написании ваших работ! ЗНАЕТЕ ЛИ ВЫ?
Влияние общества на человека
Приготовление дезинфицирующих растворов различной концентрации Практические работы по географии для 6 класса Организация работы процедурного кабинета Изменения в неживой природе осенью Уборка процедурного кабинета Сольфеджио. Все правила по сольфеджио Балочные системы. Определение реакций опор и моментов защемления |
Составные части технологии программирования (ТП). Отличие ТП от методологии программирования и программной инженерии.Содержание книги
Похожие статьи вашей тематики
Поиск на нашем сайте
Составные части технологии программирования (ТП). Отличие ТП от методологии программирования и программной инженерии. Любая технология имеет две стороны: - принципиальную (внутреннюю); - организационно-производственную (внешнюю). К внутренней части ТП относятся технологии проектирования, тестирования и разработки, к внешней – сопровождения. Методология программирования – совокупность механизмов, применяемых в процессе разработки программного обеспечения и объединенных одним общим философским подходом. Программная инженерия – систематический подход к разработке, эксплуатации, сопровождению и изъятию из обращения программных средств. Она изучает различные инструментальные средства с точки зрения достижения определенных целей. Не следует путать технологию программирования с методологией. В технологии программирования методы рассматриваются «сверху» - с точки зрения организации технологических процессов, а в методологии программирования методы рассматриваются «снизу» - с точки зрения основ их построения. Главное различие между технологией программирования и программной инженерией как дисциплинами для изучения заключается в способе рассмотрения и систематизации материала. В технологии программирования акцент делается на изучении процессов разработки ПП (технологических процессов) и порядке их прохождения - методы и инструментальные средства разработки ПП используются в этих процессах (их применение и образует технологические процессы). Тогда как в программной инженерии изучаются различные методы и инструментальные средства разработки ПС с точки зрения достижения определенных целей – эти методы и средства могут использоваться в разных технологических процессах (и в разных технологиях программирования). Технологии программирования: этапы развития и базовые методологии программирования. Отличие методологии структурного проектирования программных систем от методологии объектно-ориентированного проектирования. В 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- грамотное руководство разработкой, четкое планирование и контроль выполнения работ.
|
|||||||||
Последнее изменение этой страницы: 2016-04-21; просмотров: 1013; Нарушение авторского права страницы; Мы поможем в написании вашей работы! infopedia.su Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Обратная связь - 18.226.34.241 (0.019 с.) |