Билет 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. Жизненный цикл программного обеспечения. Модели жизненного цикла ПО: каскадная, спиральная. Стадии, фазы работы жизненного цикла.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В соответствии с базовым международным стандартом ISO/IEC 12207 все процессы ЖЦ ПО делятся на три группы:

• Основные процессы: приобретение, поставка, разработка, эксплуатация и сопровождение;

• Вспомогательные процессы: документирование, управление конфигурацией, обеспечение качества, разрешение проблем, аудит, аттестация, совместная оценка, верификация;

• Организационные процессы: создание инфраструктуры, управление, обучение, усовершенствование.

Традиционные этапы разработки программ.

Фаза разработки в жизненном цикле программы традиционно включает следующие этапы: анализ, проектирование, реализацию и тестирование.

Анализ

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

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

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

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

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

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

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

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

3. На языке С++ вычислить сумму ряда целых чисел от 1 до n.

#pragma hdrstop

//---------------------------------------------------------------------------

#include <iostream.h>

void main()

{

int N,S=0,i;

cout<<"\n Vvedite N ==";

cin>>N;

for(i=1;i<=N;i++) S=S+i;

cout<<"\n Summa =="<<S;

}