Технологии организации разработки ПО. 4 и 5.

Этапы разработки ПО.

Пре-альфа

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

Альфа

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

Бета

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

Beta Escrow

Стадия бета-тестирования, релиз-кандидат на Beta.

Релиз-кандидат

Релиз-кандидат или RC (англ. release candidate), Пре-релиз или Pre — стадия-кандидат на то, чтобы стать стабильной. Программы этой стадии прошли комплексное тестирование, благодаря чему были исправлены все найденные критические ошибки. Но в то же время существует вероятность выявления ещё некоторого числа ошибок, не замеченных при тестировании.

RC Escrow

Релиз, который готов получить звание релиз-кандидата. В этом релизе могут быть ещё ошибки.

Релиз

Основная статья: Релиз (программное обеспечение)

Релиз или RTM (англ. release to manufacturing промышленное издание) — издание продукта, готового к тиражированию. Это стабильная версия программы, прошедшая все предыдущие стадии, в которых исправлены основные ошибки, но существует вероятность появления новых, ранее не замеченных, ошибок. RTM предшествует общей доступности (GA), когда продукт выпущен для общественности.

RTM Escrow

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

Пост-релиз

Пост-релиз или Post-RTM (англ. post-release to manufacturing), издание продукта, у которого есть несколько отличий от RTM и помечается как самая первая стадия разработки следующего продукта. Такие релизы не выпускаются на продажу, а раздаются бета-тестерам. Это издание может быть либо стабильным (если не замечено ошибок), либо с ошибками.

Общая доступность

Общая доступность или общественность (англ. General availability, General acceptance)

 

 

Проблемы разработки ПО

Наиболее распространёнными проблемами, возникающими в процессе разработки ПО, считают:

• Недостаток прозрачности. В любой момент времени сложно сказать, в каком состоянии находится проект и каков процент его завершения.
  Данная проблема возникает при недостаточном планировании структуры (или архитектуры) будущего программного продукта, что чаще всего является следствием отсутствия достаточного финансирования проекта: программа нужна, сколько времени займёт разработка, каковы этапы, можно ли какие-то этапы исключить или сэкономить — следствием этого процесса является то, что этап проектирования сокращается.
• Недостаток контроля. Без точной оценки процесса разработки срываются графики выполнения работ и превышаются установленные бюджеты. Сложно оценить объём выполненной и оставшейся работы.
  Данная проблема возникает на этапе, когда проект, завершённый более чем наполовину, продолжает разрабатываться после дополнительного финансирования без оценки степени завершённости проекта.
• Недостаток трассировки.
• Недостаток мониторинга. Невозможность наблюдать ход развития проекта не позволяет контролировать ход разработки в реальном времени. С помощью инструментальных средств менеджеры проектов принимают решения на основе данных, поступающих в реальном времени.
  Данная проблема возникает в условиях, когда стоимость обучения менеджмента владению инструментальными средствами сравнима со стоимостью разработки самой программы.
• Неконтролируемые изменения. У потребителей постоянно возникают новые идеи относительно разрабатываемого программного обеспечения. Влияние изменений может быть существенным для успеха проекта, поэтому важно оценивать предлагаемые изменения и реализовывать только одобренные, контролируя этот процесс с помощью программных средств.
  Данная проблема возникает вследствие нежелания конечного потребителя использовать те или иные программные среды. Например, когда при создании клиент-серверной системы потребитель предъявляет требования не только к операционной системе на компьютерах-клиентах, но и на компьютере-сервере.
• Недостаточная надежность. Самый сложный процесс — поиск и исправление ошибок в программах на ЭВМ. Поскольку число ошибок в программах заранее неизвестно, то заранее неизвестна и продолжительность отладки программ и отсутствие гарантий отсутствия ошибок в программах. Следует отметить, что привлечение доказательного подхода к проектированию ПО позволяет обнаружить ошибки в программе до её выполнения. В этом направлении много работали Кнут, Дейкстра и Вирт. Профессор Вирт при разработке Паскаля и Оберона за счет строгости их синтаксиса добился математической доказуемости завершаемости и правильности программ, написанной на этих языках.
  Данная проблема возникает при неправильном выборе средств разработки. Например, при попытке создать программу, требующую средств высокого уровня, с помощью средств низкого уровня. Например, при попытке создать средства автоматизации с СУБД на ассемблере. В результате исходный код программы получается слишком сложным и плохо поддающимся структурированию.
• Отсутствие гарантий качества и надежности программ из-за отсутствия гарантий отсутствия ошибок в программах вплоть до формальной сдачи программ заказчикам.
  Данная проблема не является проблемой, относящейся исключительно к разработке ПО. Гарантия качества — это проблема выбора поставщика товара (не продукта).

 

 

Модельные техники.

• Модель водопада (Каскадная модель)
• структурное проектирование
• тестирование программ
• сертификация программ
• Итеративный процесс
• Итеративный подход (англ. iteration — повторение) — выполнение работ параллельно с непрерывным анализом полученных результатов и корректировкой предыдущих этапов работы. Проект при этом подходе в каждой фазе развития проходит повторяющийся цикл: Планирование — Реализация — Проверка — Оценка (англ. plan-do-check-act cycle).
• Гибкие методологии разработки
• Экстремальное программирование
• Формальные методы
• логическое программирование
• доказательное программирование

 

7. IDEF0\IDEF1

IDEF – Сокращение от Integration Definition Metodology (Объединение Методологических Понятий). Семейство совместно используемых методов для процесса моделирования.
IDEF технология используется, начиная с конца 1980-х годов. Department of Defense USA (Министерство обороны США) является основным пользователем данной технологии. Ей, также, пользуются некоторые крупные корпорации в США.

IDEF0 — Function Modeling — методология функционального моделирования и графическая нотация, предназначенная для формализации и описания бизнес-процессов. Отличительной особенностью IDEF0 является её акцент на соподчинённость объектов. В IDEF0 рассматриваются логические отношения между работами, а не их временна́я последовательность (WorkFlow

).

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

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

Также отображаются все сигналы управления, которые на DFD (Диаграмме Потоков Данных) не отображались. Данная модель используется при организации бизнес-проектов и проектов, основанных на моделировании всех процессов: как административных, так и организационных.

• IDEF0 on WEB [2]
• IDEF0.EM Tool
• MS Visio
• Ramus [3]
• Business Studio
• Dia

IDEF1 (Information Modeling) — одна из методологий семейства IDEF. Применяется для построения информационной модели, которая представляет структуру информации, необходимой для поддержки функций производственной системы или среды.

Метод IDEF1, разработанный Т. Рэмей (T. Ramey), также основан на подходе П. Чена и позволяет построить модель данных, эквивалентную реляционной модели в третьей нормальной форме. В настоящее время на основе совершенствования методологии IDEF1 создана ее новая версия — методология IDEF1X. IDEF1X разработана с учетом таких требований, как простота изучения и возможность автоматизации. IDEF1X–диаграммы используются рядом распространённых CASE–средств (в частности, ERwin, Design/IDEF).

 

 

Как управлять проектом.

Перейти к: навигация, поиск

Управле́ние разрабо́ткой програ́ммного обеспе́чения (англ. Software project management) - особый вид управления проектами, в рамках которого происходит планирование, отслеживание и контроль за проектами по разработке программного обеспечения. Ключевым моментом в управлении проектом по разработке программного обеспечения является правильный выбор метода разработки.

 

Планирование, отслеживание и контроль за проектом

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

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

12. Какие (драйвера) движущие силы проекта.

1.Календарный подход к разработке

+все подчинено временным вехам, определены сроки, управление сроками хорошо и для заказчика и управленцам

+планирование

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

2.Процессы управляемые документацией

+хорошая управляемость, просто управленцам

+организованнось в работе

-в сроки отчётности нет содержательной работы

-документацию не читают и удалённое отношение к продукту

3.Управляемый требованиями

+соответсвует нуждам заказчика

+разработчик понимает суть и объём работы

+делается только то, что нужно

-изменение требований

-страдает управляемость

4.Архитектурный тип

+решения не меняются

-ограничение архитектуры

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

5.Управление бизнесс-процессом

управленческие бизнесс-процессы - бизнес-правила

базовые(производство)

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

+соответствие самому бизнесу

+стабильность

-закреплённость бизнес-организации

 

ГОСТы

ГОСТ 19 "Единая система программной документации" ^[2] и ГОСТ 34 "Стандарты на разработку автоматизированных систем" ^[3] ориентированы на последовательный подход в разработке программного обеспечения. Разработка в соответствии с этими стандартами проводится по этапам, каждый из которых предполагает выполнение строго определенных работ. Строгое следование этим ГОСТам приводит к каскадной модели. На основе этих стандартов разрабатываются программные системы по госзаказам в России.

SW-CMM

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

RUP

Унифицированный процесс был разработан компанией Rational Software в качестве дополнения к языку UML. Модель RUP описывает абстрактный общий процесс, на основе которого организация или проектная команда должна создать конкретный специализированный процесс, ориентированный на ее потребности.

MSF

Microsoft Solutions Framework построена на основе итеративной разработки. Особенностью MSF является большое внимание к созданию эффективной и небюрократизированной команды.

PSP /TSP

Personal Software Process определеяет требования к компетенциям разработчика для того, чтобы они смогли получить необходимые навыки для Team Software Process. Team Software Process в комбинации с Personal Software Process делает ставку на самоуправляемые команды численностью 3-20 человек. Команды должны:

• Установить собственные цели
• Составить свой процесс и планы
• Отслеживать работу
• Поддерживать мотивацию и максимальную производительность

Agile

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

 

 

14. Что такое требования и как с ними работать.

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

Требования могут выражаться в виде текстовых утверждений и графических моделей.

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

Проверка требований

Все требования должны быть поддающимися проверке. Наиболее общепринятая методика проверки — тесты. Если проверка тестами невозможна, тогда должен использоваться другой метод проверки (анализ, демонстрация, осмотр или обзор дизайна).

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

Нефункциональные требования, которые являются неподдающимися проверке на программном уровне, все равно должны быть сохранены как документация намерений клиента; Такие требования к продукту могут быть преобразованы в требования к процессу. Например, нефункциональное требование, чтобы ПО не содержало «потайных ходов», может быть удовлетворено заменой на требование использовать парное программирование. Сложные требования безопасности авиационного программного обеспечения могут быть удовлетворены следованием процессу разработки DO-178B (англ.).

Анализ требований

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

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

1. требуют много времени для разработки, иногда даже рискуют устареть к концу разработки

2. ограничивают возможные способы реализации

3. являются слишком дорогостоящими

Документирование требований

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

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

• Концепция программы (Vision)
• Спецификация программного обеспечения (англ. Software Requirements Specification, SRS)

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

За создание спецификации программного обеспечения чаще всего в российской практике отвечает Системный аналитик, иногда — Бизнес-аналитик.

Для графических моделей требований исторически использовались диаграммы: ER (IDEF1FX), IDEF0, IDEF3, DFD, UML, OCL, SysML, ARIS (eEPC, VAD).

 

15. Роли и обязанности участников проекта. Менеджер проекта

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

Подбор кадров и управление ими –

Формулирование и исполнение плана проекта

Руководство командой

Обеспечение связи между

Обеспечение готовности продукта

Тестировщики

• планирование испытаний;
• автоматизация испытаний;
• оценка и выбор инструментальных средств.

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

Риски проекта.

1. внутренние изъяны календарного планирования

2. раздувание требований (изменение требований)

3. текучесть кадров

4. нарушение спецификаций

5. низкая производительность

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

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

17. Реинженеринг, рефакторинг, ревью.

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

Рефакторинг или рефакторирование (англ. refactoring) — процесс изменения внутренней структуры программы, не затрагивающий её внешнего поведения и имеющий целью облегчить понимание её работы ^[1] . В основе рефакторинга лежит последовательность небольших эквивалентных (то есть сохраняющих поведение) преобразований. Поскольку каждое преобразование маленькое, программисту легче проследить за его правильностью, и в то же время вся последовательность может привести к существенной перестройке программы и улучшению её согласованности и четкости.

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

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

2. необходимо исправить ошибку, причины возникновения которой сразу не ясны;

3. преодоление трудностей в командной разработке, которые обусловлены сложной логикой программы.

 

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

Какие используете инструменты?
Скриптом генерится pdf-ка с diff-ом всех измененных файлов.

Как код попадает на review?
Есть свой веб-тул для формальных ревью (не только кода, ещё доков и т.п.). Всем заинтересованным рассылается письмо, выставляются даты, люди заносят свои комментарии, автор исправляет и выкладывает новую версию и снова идет ревью, когда все согласились (грубо говоря поставили галочки) — ревью закрывается.

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

Диаграммы UML

Диаграммы UML

Структурные диаграммы:

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

Диаграммы поведения:

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

Диаграммы взаимодействия:

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

 

Чего не хватает в UMI.

коммерческая система управления сайтом (CMS), написанная на языке программирования PHP. Создаётся с 2004 года командой российских разработчиков «Юмисофт». В массовую продажу поступила в 2007 году. Существует в бесплатной и коммерческой версиях.

Главная идеологическая особенность UMI.CMS — user-friendly интерфейс ^[2]. Например, поддерживается изменение структуры сайта с использованием drag & drop. В последних версиях используется способ редактирования содержания страницы и компонентов страниц на самом сайте без перехода в административный интерфейс и диалоговых окон.

Быстродействие

 

Давайте откроем рекламный проспект UMI.CMS и пробежимся по нему глазами. У вас его, наверное, нет, но я постараюсь по памяти сформулировать один из пунктов: “UMI.CMS выдерживает несколько миллионов посетителей в день”.

Предположим, что если день - 12 часов, а “несколько миллионов” - минимум 2 миллиона (для сравнения - у ЖЖ примерно 2-4 млн). То есть в час у нас примерно 166 667 посетителей или 2778 посетителей в минуту. Выглядит круто, правда? На практике это не так: получив в течение 1 минуты 2000 запросов сайт UMI.CMS умирает.

Скорость загрузки

Что касается удобства использования, то проблемы начинаются сразу как только пользователь входит в админку. Интерфейс в UMI.CMS тяжеловесный, как и в любой системе подобного рода. При загрузке на сервер отправляется аж 99 (!) HTTP-запросов и время порой больше 30 секунд.

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

Управление файлами

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

Программирование в UMI.CMS

 

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

 

Языки программирования

• Оберон (ограниченно)
• Компонентный Паскаль
• .NET Framework
• PHP

Отличия от ООП

• Компонент — «независимый модуль программного кода, предназначенный для повторного использования и развертывания».
• Может содержать «множественные классы».
• Как правило, независим от конкретного языка.

 

IDL.

IDL, или язык описания интерфейсов (англ. Interface Description Language или Interface Definition Language) — язык спецификаций для описания интерфейсов, синтаксически похожий на описание классов в языке C++.

Реализации

• CORBA IDL — язык описания интерфейсов распределённых объектов, разработанный рабочей группой OMG. Создан в рамках обобщённой архитектуры CORBA.
• IDL DCE, язык описания интерфейсов спецификации межплатформенного взаимодействия служб, которую разработал консорциум Open Software Foundation (теперь The Open Group) ^[1]
• MIDL (Microsoft Interface Definition Language) — язык описания интерфейсов для платформы Win32 определяет интерфейс между клиентом и сервером. Предложенная от Microsoft технология использует реестр Windows и используется для создания файлов и файлов конфигурации приложений (ACF), необходимых для дистанционного вызова процедуры интерфейсов (RPC) и COM / DCOM интерфейсов. ^[2]
• COM IDL — язык описания интерфейсов между модулями COM. Является преемником языка IDL в технологии DCE (англ. среда распределённых вычислений) — спецификации межплатформенного взаимодействия служб, которую разработал консорциум Open Software Foundation (теперь The Open Group) ^[1]

Основные принципы ООП.

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

• Пользователь может взаимодействовать с объектом только через этот интерфейс. Реализуется с помощью ключевого слова: public.

· Пользователь не может использовать закрытые данные и методы. Реализуется с помощью ключевых слов: private, protected, internal.
Инкапсуляция — один из четырёх важнейших механизмов объектно-ориентированного программирования (наряду с абстракцией, полиморфизмом и наследованием).

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

• предельная локализация изменений при необходимости таких изменений,
• прогнозируемость изменений (какие изменения в коде надо сделать для заданного изменения функциональности) и прогнозируемость последствий изменений.
• Полиморфизм (polymorphism) (от греческого polymorphos) - это свойство, которое позволяет одно и то же имя использовать для решения двух или более схожих, но технически разных задач. Целью полиморфизма, применительно к объектно-ориентированному программированию, является использование одного имени для задания общих для класса действий. Выполнение каждого конкретного действия будет определяться типом данных. Например для языка Си, в котором полиморфизм поддерживается недостаточно, нахождение абсолютной величины числа требует трёх различных функций: abs(), labs() и fabs(). Эти функции подсчитывают и возвращают абсолютную величину целых, длинных целых и чисел с плавающей точкой соответственно. В С++ каждая из этих функций может быть названа abs(). Тип данных, который используется при вызове функции, определяет, какая конкретная версия функции действительно выполняется. В С++ можно использовать одно имя функции для множества различных действий. Это называется перегрузкой функций (function overloading).

 

 

Описание

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

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

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

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

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

При использовании контрактов сам код не обязан проверять их выполнение. Обычно в таких случаях в коде делают жёсткое падение ^{[ уточнить ]} («fail hard»), таким образом облегчая отладку выполнения контрактов. Во многих языках, таких как C, C++, Delphi, PHP, такое поведение реализуется оператором assert. В релизовом варианте кода это поведение может быть сохранено, либо проверки могут быть убраны чтобы повысить производительность.

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

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

 

 

Преимущества

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

Этот тип тестирования обычно выполняется программистами.

Поощрение изменений

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

Упрощение интеграции

Модульное тестирование помогает устранить сомнения по поводу отдельных модулей и может