Файл: ответы.doc

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

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

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

Иерархической базой данных является файловая система, состоящая из корневой директории, в которой имеется иерархия поддиректорий и файлов.

Реляционная база данных — база данных, основанная на реляционной модели. Слово «реляционный» происходит от английского «relation» (отношение[1]). Для работы с реляционными БД применяют Реляционные СУБД.

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

• Данные хранятся в таблицах, состоящих из столбцов ("атрибутов") и строк ("записей");

• На пересечении каждого столбца и строчки стоит в точности одно значение;

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

• Запросы к базе данных возвращают результат в виде таблиц, которые тоже могут выступать как объект запросов.

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

Общепринятым стандартом языка работы с реляционными базами данных является язык SQL.

К основным понятиям сетевой модели базы данных относятся: уровень, элемент (узел), связь.

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

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

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

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

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

Билет 14.

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

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

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

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

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

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

3.1.1. Логическая организация и представление компонент

Откроем среду разработки Borland Delphi и посмотрим на доступные компоненты (рис. 3.1). Все компоненты логически сгруппированы по страницам. Например, на странице «Standard» расположены стандартные графические компоненты для создания элементов интерфейса пользователя, на странице «System» – общесистемные компоненты, на странице «Data Access» –компоненты доступа к базам данных. Для быстрого перехода с одной страницы палитры компонент на другую при большом их количестве откройте всплывающее меню на палитре с помощью неактивной клавише мыши и выберите нужную страницу.

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

В задачу инспектора объектов (Object Inspector) входит представление состояния выделенного на форме компонента. При переходе к другому компоненту содержимое инспектора автоматически обновляется. Такое поведение оказывается возможным благодаря механизму, предоставляющего информацию о типе времени выполнения (RTTI, Run-time Type Information). Информация RTTI обеспечивает предоставление сведений об объектах непосредственно во время их исполнения, а также необходима для обмена информацией между компонентами и графической средой разработки. Информацию о типе можно получить для любого исполняемого объекта. Она содержится в памяти и при необходимости может быть получена с помощью библиотеки времени выполнения (RTL, Run-time Library). Базовый класс TObject содержит методы для извлечения этой информации.

Все публикуемые свойства компонента (объявленные в разделе Published) доступны в инспекторе объектов для изменения на его первой вкладке «Properties». Второй составляющей любого класса являются его методы, т.е. действия, которые служат для изменения внутреннего состояния объектов. Конечно, доступ возможен только к методам, объявленным в разделе Public.

Компоненты обладают еще одной возможностью – способностью реагировать на внешние воздействия, например, системные события или действия пользователя. Для этого используются события компонент, которые также являются свойствами, но иного, процедурного типа данных. Для назначения событий компонент служит вторая вкладка «Events» инспектора объектов. На рис. 3.3 показаны обе странице инспектора объектов для компонента Button1.

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

2. Жизненный цикл программного обеспечения. Модели жизненного цикла ПО: каскадная, спиральная. Стадии, фазы работы жизненного цикла.

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

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

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

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

Рис. Каскадная схема разработки ПО

• Поэтапная модель с промежуточным контролем. Разработка ИС ведется итерациями с циклами обратной связи между этапами. Межэтапные корректировки позволяют учитывать реально существующее взаимовлияние результатов разработки на различных этапах; время жизни каждого из этапов растягивается на весь период разработки.

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

Рис. Спиральная модель ЖЦ

На практике наибольшее распространение получили две основные модели ЖЦ: каскадная и спиральная. Можно выделить следующие положительные стороны применения каскадного подхода:

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

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

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