Реферат: Методические указания к курсовому проектированию по дисциплине «Прикладное программирование»

Министерство образования Российской Федерации

Государственное образовательное учреждение высшего профессионального образования

СЕВЕРО-ЗАПАДНЫЙ ГОСУДАРСТВЕННЫЙ ЗАОЧНЫЙ

ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ


Кафедра процессов управления и информационных систем




ПРИКЛАДНОЕ ПРОГРАММИРОВАНИЕ


Методические указания

к курсовому проектированию по дисциплине

«Прикладное программирование»


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

Направление и специальность подготовки дипломированного специалиста:

651900 – автоматизация и управление

210100 - управление и информатика в технических системах

Направление подготовки бакалавра

550200 - автоматизация и управление


^ Санкт- Петербург
2004

Утверждено редакционно-издательским советом университета

УДК 62.52/07

Прикладное программирование: Методические указания к курсовому проектированию по дисциплине «Прикладное программирование»/ Сост.: В.Л.Литвинов. - СПб.: СЗТУ, 2004. - 36с.


Рассмотрены особенности современных методов и средств проектирования информационных систем, основанных на использовании CASE-технологий. Даны общие рекомендации по технологиям разработки программных систем. Приведены варианты заданий к курсовому проектированию, ориентированные на среду разработки Borland C++ Builder.

Предназначены для студентов специальности 210100.


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


Рецензенты:

Ю.А.Кораблев, канд.техн.наук., доц.каф. АПУ Санкт-Петербургского государственного электротехнического университета;

Р.Р.Хамидуллин, канд.техн.наук, доц. каф. КТ и ПО Северо-Западного государственного заочного технического университета.


Составитель: В.Л.Литвинов, канд. техн. наук, доц.


© Северо-западный государственный заочный технический университет, 2004


^ Методические указания составлены в соответствии с рабочей программой дисциплины «Прикладное программирование» учебного плана специальности 210100 – «Управление и информатика в технических системах».

^ Целью курсового проектирования является формирование у студентов практических навыков по разработке программных систем с использованием современных информационных технологий. В качестве среды разработки предложено использовать среду визуального программирования Borland C++ Builder.

^ ОБЩИЕ ПОЛОЖЕНИЯ


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

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


^ Основы методологии проектирования ИС


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

Основным нормативным документом, регламентирующим ЖЦ ПО, является международный стандарт ISO/IEC 12207 (ISO – International Organization of Standardization – Международная организация по стандартизации, IEC – International Electrotechnical Commission – Международная комиссия по электротехнике). Он определяет структуру ЖЦ, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ПО.

Структура ЖЦ ПО по стандарту ISO/IEC 12207 базируется на трех группах процессов:

основные процессы ЖЦ ПО (приобретение, поставка, разработка, эксплуатация, сопровождение);

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

организационные процессы (управление проектами, создание инфраструктуры проекта, определение, оценка и улучшение самого ЖЦ, обучение).

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

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

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

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

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


^ Методология RAD


Одним из возможных подходов к разработке ПО в рамках модели ЖЦ является получившая в последнее время широкое распространение методология быстрой разработки приложений RAD (Rapid Application Development). Под этим термином обычно понимается процесс разработки ПО, содержащий три элемента:

небольшую команду программистов (от 2 до 10 человек);

короткий, но тщательно проработанный производственный график (от 2 до 6 мес.);

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

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

Жизненный цикл ПО по методологии RAD состоит из четырех фаз:

анализа и планирования требований;

проектирования;

построения;

внедрения.

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

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

После детального описания состава процессов оценивается количество функциональных элементов разрабатываемой системы и принимается решение о разделении ИС на подсистемы, поддающиеся реализации одной командой разработчиков за приемлемое для RAD-проектов время – порядка 60 – 90 дней. С использованием CASE-средств проект распределяется между различными командами (делится функциональная модель). Результатом данной фазы должны быть:

общая информационная модель системы;

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

точно определенные с помощью CASE-средства интерфейсы между автономно разрабатываемыми подсистемами;

построенные прототипы экранов, отчетов, диалогов.

Все модели и прототипы должны быть получены с применением тех CASE-средств, которые будут использоваться в дальнейшем при построении системы. Данное требование вызвано тем, что в традиционном подходе при передаче информации о проекте с этапа на этап может произойти фактически неконтролируемое искажение данных. Применение единой среды хранения информации о проекте позволяет избежать этой опасности.

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

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

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

определяется необходимость распределения данных;

производится анализ использования данных;

производится физическое проектирование базы данных;

определяются требования к аппаратным ресурсам;

определяются способы увеличения производительности;

завершается разработка документации проекта.

Результатом фазы является готовая система, удовлетворяющая всем согласованным требованиям.

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

Следует, однако, отметить, что методология RAD, как и любая другая, не может претендовать на универсальность, она хороша в первую очередь для относительно небольших проектов, разрабатываемых для конкретного заказчика. Если же разрабатывается типовая система, которая не является законченным продуктом, а представляет собой комплекс типовых компонентов, централизованно сопровождаемых, адаптируемых к программно-техническим платформам, СУБД, средствам телекоммуникации, организационно-экономическим особенностям объектов внедрения и интегрируемых с существующими разработками, на первый план выступают такие показатели проекта, как управляемость и качество, которые могут войти в противоречие с простотой и скоростью разработки. Для таких проектов необходимы высокий уровень планирования и жесткая дисциплина проектирования, строгое следование заранее разработанным протоколам и интерфейсам, что снижает скорость разработки.

Методология RAD неприменима для построения сложных расчетных программ, операционных систем или программ управления космическими кораблями, т. е. программ большого объема (сотни тысяч строк) .

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


^ CASE-средства. Общая характеристика и классификация


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

Наиболее трудоемкими этапами разработки ИС являются этапы анализа и проектирования, в процессе которых CASE-средства обеспечивают качество принимаемых технических решений и подготовку проектной документации. При этом большую роль играют методы визуального представления информации. Это предполагает построение структурных или иных диаграмм в реальном масштабе времени, использование многообразной цветовой палитры, сквозную проверку синтаксических правил. Графические средства моделирования предметной области позволяют разработчикам в наглядном виде изучать существующую ИС, перестраивать ее в соответствии с поставленными целями и имеющимися ограничениями.

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

Обычно к CASE-средствам относят любое программное средство, автоматизирующее ту или иную совокупность процессов жизненного цикла ПО и обладающее следующими основными характерными особенностями:

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

интеграцией отдельных компонентов CASE-средств, обеспечивающей управляемость процессом разработки ИС;

использованием специальным образом организованного хранилища проектных метаданных (репозитория).

Интегрированное CASE-средство (или комплекс средств, поддерживающих полный ЖЦ ПО) содержит следующие компоненты:

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

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

средства разработки приложений, включая генераторы кодов;

средства конфигурационного управления;

средства документирования;

средства тестирования;

средства управления проектом;

средства реинжиниринга.

Все современные CASE-средства могут быть классифицированы в основном по типам и категориям. Классификация по типам отражает функциональную ориентацию CASE-средств на те или иные процессы ЖЦ. Классификация по категориям определяет степень интегрированности по выполняемым функциям и включает отдельные локальные средства, решающие небольшие автономные задачи (tools), набор частично интегрированных средств, охватывающих большинство этапов жизненного цикла ИС (toolkit) и полностью интегрированные средства, поддерживающие весь ЖЦ ИС и связанные общим репозиторием. Помимо этого CASE-средства можно классифицировать по следующим признакам:

применяемым методологиям и моделям систем и БД;

степени интегрированности с СУБД;

доступным платформам.

Классификация по типам в основном совпадает с компонентным составом CASE-средств и включает следующие основные типы:

средства анализа (Upper CASE), предназначенные для построения и анализа моделей предметной области (Design/IDEF (Meta Software), BPwin (Logic Works));

средства анализа и проектирования (Middle CASE), поддерживающие наиболее распространенные методологии проектирования и использующиеся для создания проектных спецификаций (Vantage Team Builder (Cayenne), Designer/2000 (ORACLE), Silverrun (CSA), PRO-IV (McDonnell Douglas), CASE.Аналитик (МакроПроджект)). Выходом таких средств являются спецификации компонентов и интерфейсов системы, архитектуры системы, алгоритмов и структур данных;

средства проектирования баз данных, обеспечивающие моделирование данных и генерацию схем баз данных (как правило, на языке SQL) для наиболее распространенных СУБД. К ним относятся ERwin (Logic Works), S-Designer (SDP) и DataBase Designer (ORACLE). Средства проектирования баз данных имеются также в составе CASE-средств Vantage Team Builder, Designer/2000, Silverrun и PRO-IV;

средства разработки приложений. К ним относятся средства 4GL (Uniface Compuware), JAM (JYACC), PowerBuilder (Sybase), Developer/2000 (ORACLE), NewEra (Informix), SQL Windows (Gupta), Delphi и Borland C++ Builder(Borland) и генераторы кодов, входящие в состав Vantage Team Builder, PRO-IV и – частично – в Silverrun;

средства реинжиниринга, обеспечивающие анализ программных кодов и схем баз данных и формирование на их основе различных моделей и проектных спецификаций. Средства анализа схем БД и формирования ERD входят в состав Vantage Team Builder, PRO-IV, Silverrun, Designer/2000, ERwin и S-Designor. В области анализа программных кодов наибольшее распространение получают объектно-ориентированные CASE-средства, обеспечивающие реинжиниринг программ на языке С++ (Rational Rose (Rational Software), Object Team (Cayenne)).

Вспомогательные типы включают:

средства планирования и управления проектом (SE Companion, Microsoft Project и др.); •средства конфигурационного управления (PVCS (Intersolv));

средства тестирования (Quality Works (Segue Software));

средства документирования (SoDA (Rational Software)).


^ ОСОБЕННОСТИ ПРОГРАММИРОВАНИЯ В СРЕДЕ

Borland C++ Builder

Основные компоненты


Мощная система под названием C++ Builder на языке C++, выпущенная на рынок систем быстрой разработки приложений RAD корпорацией Borland, следует традиции нисходящего визуального стиля программирования Delphi.

Вместо привычных библиотек OWL (Object Windows Library) и MFC C++Builder использует библиотеку VCL. Каждая библиотека представляет собой специфическую модель объектно-ориентированного программирования под Windows. C++Builder не делает различия между тем, какие программные модули вы добавляете к проекту своего приложения – написаны они на C++ (файлы с расширением СРР) или на Delphi (файлы с расширением PAS). Компилятор свободно принимает следующие кодовые конструкции модулей Delphi: компоненты, формы, объекты, константы, простые методы и функции – все перечисленные коды можно прямо подставлять в свои проектные файлы. Технология визуального наследования форм дает возможность модифицировать формы Delphi в среде C++Builder без каких бы то ни было проблем.

После запуска программы на экране откроется интегрированная среда разработки (IDE) в начальном состоянии.

Основными инструментами интегрированной среды являются:

палитра компонентов, содержащая более cта повторно используемых компонентов, предлагаемых для построения приложений;

редактор форм, предназначенный для создания интерфейса программы с пользователем;

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

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

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

Окно редактора программы в свою очередь состоит из двух панелей:

панели Просмотрщика классов (ClassExplorer);

панели редактора текста программы.

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

строка заголовка;

строка меню;

панель инструментов, на которой располагаются командные кнопки для выполнения наиболее часто требуемых действий;

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

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

Standard – стандартные элементы управления Windows;

Additional – дополнительные, нестандартные элементы управления Windows;

Win32 – элементы управления Windows 9х;

System – системные объекты (таймер, музыкальный проигрыватель и др.);

Internet – все для приложений, работающих с Интернетом;

Data Access – компоненты для организации связи с базами данных;

Data Controls – управляющие элементы для работ с базами данных;

Midas – компоненты для создания приложений, способных работать на нескольких компьютерах;

Decision Cube – компоненты системы анализа данных;

QReport – компоненты создания различных отчетов;

Dialogs – стандартные диалоги Windows;

Win 3.1 – элементы управления Windows 3.1;

Samples – примеры компонентов, входящие в поставку системы;

ActiveX – ActiveX-компоненты (ActiveX – формат активных компонентов, разработанный фирмой Microsoft. Borland C++ Builder также поддерживает этот формат).

Конструирование по способу "drag-and-drop " позволяет создавать приложение простым перетаскиванием захваченных мышью визуальных компонентов из палитры на форму приложения. Инспектор объектов предоставляет возможность оперировать со свойствами и событиями компонентов, автоматически создавая заготовки функций обработки событий, которые наполняются кодом и редактируются в процессе разработки.

Разработка по способу "drag-and-drop" многократно упрощает и ускоряет обычно трудоемкий процесс программирования СУБД в архитектуре клиент/сервер. Широкий выбор компонентов управления визуализацией и редактированием позволяет легко изменять вид отображаемой информации и поведение программы. C++Builder использует Проводник баз данных (Database Explorer) и масштабируемый Словарь данных (Data Dictionary), чтобы автоматически настроить средства отображения и редактирования применительно к специфике вашей информации.

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

Элементы управления размещаются на форме путем выбора нужного компонента из палитры и перетаскиванием с помощью мыши. В дальнейшем их можно перемещать по полю формы и изменять их размеры (то же можно делать и с самими формами). В итоге мы как бы составляем интерфейс будущей программы из готовых компонентов.

Компонент – это не конкретный элемент управления на вашей форме, не конкретное окно и не конкретная форма. Компонент палитры содержит обобщенный образ элемента управления. Так, например, компонент с названием Button содержит обобщенный образ для всевозможных командных кнопок.

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

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

Компоненты C++Builder не обязательно описывают только элементы управления Windows. Они используются для самых разных целей – для создания соединений Интернета, для работы с базами данных, для воспроизведения музыки и видео. Размещая на форме экземпляр компонента, например NMPOP3, мы получаем возможность обращаться из программы к свойствам этого объекта и принимать электронную почту, т. е. без особых усилий можем сделать свою собственную почтовую программу наподобие Microsoft Outlook Express. Следует отметить, что, используя другие компоненты, можно даже сделать оригинальный Web-обозреватель. При этом объем программирования будет минимальным, если структура будущего приложения тщательно продумана (спроектирована).

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

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

Инспектор объектов – очень важная часть среды разработки. Он предназначен для задания свойств объекта и определения их реакции на различные события.

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

Инспектор объектов позволяет быстро и удобно менять любые свойства текущего (выделенного на форме) объекта. При этом вносимые изменения немедленно сказываются на внешнем виде этого объекта.

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

Задавая реакции на различные события, мы тем самым определяем всю внутреннюю логику работы программы. Если нужно, чтобы при щелчке на кнопке Button1 появилось диалоговое окно с надписью Привет!, надо соответствующим образом запрограммировать действия, которые будут выполняться при наступлении события OnClick (ПриЩелчке) для кнопки Button 1.

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

В окне Инспектора объектов имеются две вкладки – вкладка свойств выбранного объекта (Properties) и вкладка событий (Events), на которые этот объект может реагировать. Каждая из вкладок содержит панель, состоящую из двух колонок. В первой указываются названия свойств (их менять нельзя), во второй – текущие значения соответствующих свойств. Эти значения должны отвечать определенным ограничениям C++Builder. В частности, если, например, свойство – это название объекта, то в нем не должно быть пробелов. В некоторых случаях надо ввести число из небольшого диапазона или выбрать одно из фиксированных значений, заданных в раскрывающемся списке.

Если вы перейдете на вкладку событий (Events) текущего объекта в Инспекторе, то обнаружите, что никаких значений возможным событиям пока не задано. Реакции на различные события вам придется задавать самостоятельно – в этом и заключается процесс программирования.

За главной формой скрыто окно редактора программы. Между текущей формой и редактором можно переключаться с помощью клавиши F12. Окно редактора состоит из двух панелей – панели Просмотрщика классов и панели редактора исходного текста программы на С++. Просмотрщик классов визуально отображает структуру связей между различными объектами нашей программы и позволяет быстро перемещаться по ее тексту.

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


^ Компоненты вкладки Standard


Компоненты этой вкладки включают в ваше приложение следующие типовые интерфейсные элементы Windows:

ТMаinМеnu создает панель команд главного меню для формы;

TPopUpMenu создает "выскакивающее" меню для формы или для другой компоненты;

TLabel отображает на форме текст названия, который нельзя редактировать;

TEdit отображает область редактируемого ввода одиночной строки информации на форме;

TMemo отображает область редактируемого ввода множественных строк информации на форме;

TButton создает кнопку с надписью;

TRadioButton создает элемент управления с двумя состояниями;

TListBox отображает область списка текстовых строк;

TComboBox создает комбинацию области редактирования и выпадающего списка текстовых строк;

TScrollBar создает линейку прокрутки для просмотра содержимого окна, формы, списка или диапазона значений;

TGroupBox создает контейнер, объединяющий на форме логически связанную группу некоторых компонент;

TRadioGroup создает контейнер, объединяющий на форме группу логически взаимоисключающих радиокнопок;

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


^ Администратор проекта


Администратор проекта предназначен для манипуляций с текущим проектным файлом с расширением .срр. Чтобы открыть окно администратора, выполните команду View / Project Manager. Окно содержит список всех составляющих файлов, ассоциированных с текущим проектом. С помощью кнопок панели быстрого вызова или опций контекстного меню вы сможете добавлять, вычеркивать, сохранять и копировать выбранный файл в текущем проекте.

Открыть контекстное меню администратора проекта можно щелчком правой кнопкой мыши в любом месте окна администратора или нажатием клавиш Alt+F10. Контекстное меню содержит следующие опции:

Save Project, сохраняющую изменения всех составляющих проектного файла, используя текущие имена файлов. Такое же действие вызывает команда File | Save Project As;

Add To Repository, открывающую диалог Save Project Template для добавления проектного шаблона к хранилищу объектов;

New Unit, создающую новый модуль в окне Редактора кода и добавляющую его к проектному файлу. Новым модулям присваиваются имена Unit1, Unit2, ... Такое же действие вызывает команда File | New Unit;

New Form, создающую пустую форму и новый модуль в окне Редактора кода и добавляющую их к проектному файлу. Новым формам присваиваются имена Form1, Form2, Такое же действие вызывает команда File | New Form;

Add File, открывающую диалог Add To Project для добавления текущего модуля и связанной с ним формы к проектному файлу;

Remove File, вычеркивающую модуль из списка ассоциированных файлов текущего проекта. Такое же действие вызывает команда Project | Remove from Project. Внимание! Не вычеркивайте файлы модулей напрямую или посредством других программ;

View Unit, активизирующий выбранный модуль в окне Редактора кода. Такое же действие вызывает команда View | Units;

View Form активизирующий форму, связанную с выбранным моТема 5. Информационная система ДЕКАНАТ для автоматизации работы деканата факультета вуза

Пусть максимальное число кафедр на факультете равно 10, кафедры готовят студентов по 12 специальностям.

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

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

Система должна обеспечивать ввод и обработку учебных планов специальностей, учебных карточек студентов.

Разработать:

меню системы;

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


Тема 6. Информационная система КАДРЫ для автоматизации работы отдела кадров предприятия

Система должна функционировать в двух режимах: первично