51. Технологии доступа к данным

ODBC- Это программные интерфейсы (API) на языке C для подключения приложений к различным СУБД.

OLE DB - гибрид ODBC и COM, то есть для доступа к данным в ней используются не API на языке C, а COM-интерфейсы.

RDO- (Remote Data Objects - удалённые объекты данных).

DAO - это Data Access Objects (объекты доступа к данным).

ADO- ActiveX Data Object (ActiveX-объекты для доступа к данным).

ADO.NET - Новое поколение объектов для работы с данными, где вместо ActiveX-компонентов используются компоненты .NET.

MDAC- Microsoft Data Access Components (компоненты доступа к данным корпорации Microsoft) - это общее название ODBC, OLE DB и ADO.

Свойства компонентов

ADOConnection:

Connection String – путь к БД

(Connection String -> Build-> MicrosoftJet 4.0. OLE DB Provider -> Указать путь к БД)

Путь к БД указывается относительно текущего корнивого каталога!

Текущий корневой каталок – это раздел (пусть к папке, где находится исполняемый файл – eхе, т.е приложение)

AdoConnection

Login Promt – пароль к БД (false - отключить)

Connected – соединение БД (true - подключиться)

DataSource – ресурс таблицы

Свойства DataSource:

DataSet – подключение ресурса таблицы

(DataSet = AdoTable1)

DBGrid – таблица

Свойства DBGrid:

DataSource – подключение ресурса таблицы к визульному компоненту

(DataSource=DataSource1)

52. Методы разработки программного обеспечения

Процесс разработки программного обеспечения (англ. software development process, software process) — структура, согласно которой построена разработка программного обеспечения (ПО). Существует несколько моделей такого процесса (методологий разработки ПО), каждая из которых описывает свой подход, в виде задач и/или деятельности, которые имеют место в ходе процесса.

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

Каскадная разработка или модель водопада (англ. waterfall model) — модель процесса разработки программного обеспечения, в которой процесс разработки выглядит как поток, последовательно проходящий фазы анализа требований, проектирования, реализации, тестирования, интеграции и поддержки. В качестве источника названия «водопад» часто указывают статью, опубликованную У. У. Ройсом (W. W. Royce) в 1970 году; забавно, что сам Ройс использовал итеративную модель разработки и даже не использовал термин «водопад».

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

Rational Unified Process (RUP) — методология разработки программного обеспечения, созданная компанией Rational Software.

В основе RUP лежат следующие основные принципы:

Ранняя идентификация и непрерывное (до окончания проекта) устранение основных рисков.

Концентрация на выполнении требований заказчиков к исполняемой программе (анализ и построение модели прецедентов).

Ожидание изменений в требованиях, проектных решениях и реализации в процессе разработки.

Компонентная архитектура, реализуемая и тестируемая на ранних стадиях проекта.

Постоянное обеспечение качества на всех этапах разработки проекта (продукта).

Работа над проектом в сплочённой команде, ключевая роль в которой принадлежит архитекторам.

Гибкая методология разработки (англ. Agile software development). Большинство гибких методологий нацелены на минимизацию рисков, путём сведения разработки к серии коротких циклов, называемых итерациями, которые обычно длятся одну-две недели. Каждая итерация сама по себе выглядит как программный проект в миниатюре, и включает все задачи, необходимые для выдачи мини-прироста по функциональности: планирование, анализ требований, проектирование, кодирование, тестирование и документирование. Хотя отдельная итерация, как правило, недостаточна для выпуска новой версии продукта, подразумевается что гибкий программный проект готов к выпуску в конце каждой итерации. По окончании каждой итерации, команда выполняет переоценку приоритетов разработки.