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

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

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

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

1. Общая часть

1.1 Цель разработки

В данном дипломном проекте поставлена следующая задача: спроектировать и реализовать автоматизированную систему управления документооборотом центральной заводской лаборатории ОАО «ВМЗ». Техническое задание на проектирование необходимо разрабатывать на основании анализа текущей системы документооборота, сопровождающей процесс проведения испытаний в лабораториях ЦЗЛ.

1.1.1 Анализ использования разработки

Система предназначена для автоматизации процесса формирования и обработки заказов на испытание образцов продукции основных цехов ОАО «ВМЗ», а также записи и хранения их в электронном виде.

Объектом автоматизации является документооборот процесса подготовки, изготовления и испытания образцов продукции основных цехов ОАО «ВМЗ».

Автоматизированная система управления документооборотом ЦЗЛ ОАО «ВМЗ» (именуемая далее Система) разрабатывается для:

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

- централизованного электронного учёта заказов на испытание образцов и результатов испытаний;

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

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

- повышения оперативности поступления заказов и формирования протоколов и сертификатов на базе единой интегрированной автоматизированной системой оперативного управления производством (ИАСОУП) ОАО «ВМЗ».

Разрабатываемый программный продукт должен строиться по клиент-серверной архитектуре.

Серверная часть системы должна быть общей с интегрированной автоматизированной системой оперативного управления производством (ИАСОУП) и использовать в качестве хранилища данных единую базу данных (БД) в системе управления базами данных (СУБД) Oracle.

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

1.1.2 Характеристика объекта информатизации

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

Все формы различаются как по содержанию, так и по расположению полей. Номер заказа присваивается в цехе (порядковый с начала года). Регистрация заказов может проводиться в цехе и в ЦЗЛ (номер, дата). По одному заказу изготавливается несколько образцов.

Пробы сдаются сменному мастеру участка изготовления образцов. Сменный мастер регистрирует заказ в «журнале приёма проб». Объём и виды необходимых испытаний указываются цехом в заказе. Может указываться ссылка на научно-техническую документацию, в которой указано, какие образцы и каким образом необходимо изготавливать и / или непосредственно указываются виды и количество испытаний.

После изготовления образцов на участке изготовления производится регистрация в том же «журнале приёма проб» даты и времени сдачи и ответственного лица.

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

В лабораториях заказ регистрируется в «журнале приёма образцов» в лаборатории механических испытаний (ЛМИ), журнале «Сталь. Результаты испытаний (трубные цеха)» в объединенной аналитической лаборатории (ОАЛ) и в аналогичных журналах в других лабораториях. Заказ, как документ, хранится в лаборатории в течение 5 лет.

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

Кроме журналов, результаты испытаний фиксируются в протоколе. Протокол оформляется в 2_х экземплярах: один хранится в ЛМИ, второй - направляется в отдел технического контроля (ОТК) цеха.

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

1.2 Анализ методов решения

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

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

? Бизнес-компонента содержит логику, которая реализует манипуляции с выбранными данными по определенным правилам, т.е. бизнес-компонента - это обработка.

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

1.2.1 Однозвенные приложения

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

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

1.2.2 Двухзвенные приложения

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

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

Граница между клиентом и сервером в таких системах проводится в произвольном месте и большей частью зависит от используемых инструментов. В наиболее популярных и распространенных клиент-серверных системах в качестве клиентской рабочей станции применяется Windows_компьютер, а в качестве сервера - SQL сервер на основе Windows или UNIX. Инструментарий, при помощи которого создаются такие системы, позволяет разработчикам разрабатывать логику клиента и осуществлять простейшие запросные операции серверу. Такой тип клиент-серверной
архитектуры называют архитектурой с толстым клиентом, поскольку большая часть приложения, включая презентационную логику, бизнес-логику и логику доступа к данным, выполняется на персональном сетевом компьютере.

Двухзвенный клиент-серверный подход предоставляет значительные преимущества по сравнению с однозвенным подходом - проектирование происходит заметно быстрее, а сервер может быть довольно простым, поскольку большая часть сложной обработки возлагается на клиента. Следствием из этого является заметное удешевление системы, особенно серверной ее части. Появляется возможность не зависеть от платформы сервера, поскольку все базы данных от одного поставщика предоставляют одинаковый интерфейс независимо от платформы сервера. А такие интерфейсы, как ODBC (Microsoft) или IDAPI (Borland-Inprise) позволяют добиться и независимости от производителя БД.

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

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

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

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

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

Клиентские приложения становятся все более сложными и все менее управляемыми. Это общая тенденция для двухзвенного клиент-серверного подхода.

Двухзвенная клиент-серверная архитектура - это архитектура, существенно зависящая от применяемых программных инструментов.

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

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

1.2.3 Трехзвенные приложения

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

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

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

1.2.3.1 Модули и объекты

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

1.2.3.2 Балансировка загрузки и надежность системы

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

1.2.3.3 Служба каталогов

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

1.2.3.4 Сервис безопасности

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

1.2.3.5 Служба управления приложениями

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

1.2.3.6 Интерфейс приложений

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

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

Для того чтобы разработчик мог использовать программные инструменты от различных производителей (например, Java, C++, Delphi и т.п.) для определения интерфейсов распределенных объектов применяется специальный язык определения интерфейсов IDL. Для разных стандартов (CORBA, DCOM, DCE) этот язык несколько отличается, но главный его смысл - он нужен для однозначного определения интерфейса взаимодействия модулей между собой.

1.2.3.7 Гранулированность информационной системы

За высокую гранулированность в системе приходится платить производительностью (динамическое связывание объектов требует затрат процессорного времени), а если система разбита на слишком крупные гранулы, уменьшается степень повторного использования кода, что нежелательно. CORBA, DCOM, DCE подталкивают разработчика к разбиению системы на мелкие гранулы (или объекты, что более правильный термин). Приложения серверного слоя также могут дополнительно разбиваться на гранулы-объекты, статически связываемые в период проектирования (компилирование приложения). Как правило, продукт от каждого производителя ориентирован на соответствующую архитектуру объектов (CORBA, DCOM, DCE), так Entera ориентирована на DCE, MIDAS - на DCOM, ORBIX - на CORBA.

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

1.2.3.8 Минусы трехзвенных архитектур

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

- непроработанность архитектуры;

- тяжелые в реальности решения;

- несоответствие с уже имеющимися технологиями;

- неустойчивость версий стандартов, а, следовательно, потенциальная несовместимость;

- недоразвитость инструментов (неудобство, ошибки);

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

Рассмотрим два основных вида объектных архитектур DCE и DCOM. DCE - это распределенная архитектура появившаяся раньше DCOM.

Исходная UNIX-ориентированность технологии DCE, ее некоторая громоздкость, ее ориентированность только на язык С, отсутствие системы управления приложениями - это очевидные минусы.

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

DCOM - закрытая архитектура с закрытым протоколом. Может использоваться только в рамках данной реализации, соотношения между объектными сервисами обладают очевидными недостатками. Производителем DCOM является компания Microsoft.

Но недостатки архитектуры так же, как и в случае DCE, можно исправить удачно сделанными продуктами. Inprise MIDAS вносит необходимую гибкость в архитектуру, снабжая ее необходимым инструментарием и утилитами.

1.2.3.9 Тонкие и толстые клиенты

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

Тонким клиентом называют также и стандартные internet_клиенты, которые в интрасетях действительно занимаются только отображением / представлением данных, хотя и не являются объектами, соответствующими архитектурам DCE, CORBA, DCOM. Эти два типа клиентов различаются не столько по объему кода, сколько по способу их применения в течение жизни информационной системы. Трехзвенная архитектура предназначена для того, чтобы внести расширяемость и масштабируемость в информационные системы. Системы, которым нужны эти качества, никогда не бывают полностью завершены, и в течение жизненного цикла всегда подвергаются изменениям. Тонкие клиенты первого типа также подвергаются изменениям с изменениями системы и, должны время от времени заменяться новыми, более модифицированными версиями. Тонкие клиенты второго типа (ультратонкие) могут не заменяться в течение жизненного цикла системы, поэтому обслуживание интранет-системы несравненно проще трехзвенной системы, построенной без применения стандартных тонких клиентов. В принципе, никакого противоречия тут нет, и можно было бы построить ультратонкого клиента и для DCE, CORBA, DCOM.

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

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

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

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

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

1.3 Анализ средств программирования

На сегодняшний момент существует большое количество языков программирования с различными возможностями и функционалом. В процессе обучения был изучен язык программирования С++, поэтому было принято решение вести разработку системы на С++ или родственном ему языке. Язык C++ - это универсальный язык программирования, для которого характерны экономичность выражения, современный поток управления и
структуры данных, богатый набор операторов. Язык C++ не является ни языком «очень высокого уровня», ни «большим» языком, и не предназначается для некоторой специальной области применения, но отсутствие ограничений и общность языка делают его более удобным и эффективным для многих задач, чем языки, предположительно более мощные.

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

Проведем сравнительный анализ основных сред разработки на С++:

1.3.1 Borland C++ Builder

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

Система содержит библиотеку из более 100 визуальных компонент. Помимо известных элементов управления Windows (кнопки, линейки прокрутки, поля редактирования, простые и комбинированные списки и т.д.) библиотека содержит новые компоненты поддержки диалогов, обслуживания баз данных и многие другие.

Опытным C++ программистам нравится синтаксис и структура кода разрабатываемых на C++ Builder программ, хотя его графическое обрамление заметно отличается от традиционных оболочек систем разработки. C++ Builder поддерживает основные принципы объектно-ориентированного программирования - инкапсуляцию, полиморфизм и множественное наследование, а также нововведенные спецификации и ключевые слова в стандарте языка.

1.3.2 Microsoft Visual C++

Microsoft Visual C++ - универсальный язык программирования, задуманный так, чтобы сделать программирование более приятным для серьезного программиста. Visual C++ предоставляет гибкие и эффективные средства определения новых типов. Используя определения новых типов, точно отвечающих концепциям приложения, программист может разделять разрабатываемую программу на легко поддающиеся контролю части. Информация о типах содержится в некоторых объектах типов, определенных пользователем. Такие объекты просты и надежны в использовании в тех ситуациях, когда их тип нельзя установить на стадии компиляции. Программирование с применением таких объектов часто называют объектно-ориентированным. При правильном использовании этот метод дает более короткие, проще понимаемые и легче контролируемые программы.

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

1.3.3 Microsoft Visual Studio

Microsoft Visual Studio - это уже проверенный временем программный продукт. Выделим две важнейшие его идеи:

· открытость для языков программирования;

· принципиально новый подход к построению каркаса среды - Framework. Net.

Среда разработки теперь является открытой языковой средой. Это означает, что наряду с языками программирования, включенными фирмой Microsoft в среду могут добавляться любые языки программирования, компиляторы которых создаются другими фирмами-производителями. Таких расширений среды Visual Studio сделано уже достаточно много, практически они существуют для всех известных языков - Fortran и Cobol, RPG и Component Pascal, Oberon и SmallTalk.

Открытость среды не означает полной свободы. Главное ограничение, которое можно считать и главным достоинством, состоит в том, что все языки, включаемые в среду разработки Visual Studio. Net, должны использовать единый каркас - Framework. Net. Благодаря этому достигаются многие желательные свойства:

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

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

ь возможность бесшовной отладки такого приложения;

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

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

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

Рассмотрим два типа языка Visual С, включенных в среду разработки Microsoft Visual Studio:

1.3.3.1 Visual С++

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

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

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

Перечислим некоторые особенности языка С++:

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

ь Базовые типы данных языка С++ отражают те же объекты, с которыми приходится иметь дело в программе на языке ассемблера, - байты, машинные слова, символы, строки.

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

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

1.3.3.2 Visual C #

Многие разработчики хотели бы использовать современный язык, который позволял бы писать, читать и сопровождать программы с простотой Visual Basic и в то же время давал мощь и гибкость C++, обеспечивал доступ ко всем функциональным возможностям системы, взаимодействовал бы с существующими программами и легко работал с возникающими Web - стандартами.

Учитывая все подобные пожелания, Microsoft разработала новый язык - C#. В него входит много полезных особенностей - простота, объектная ориентированность, типовая защищенность, «сборка мусора», поддержка совместимости версий и многое другое. Данные возможности позволяют быстро и легко разрабатывать приложения, особенно COM - приложения и Web - сервисы. При создании C#, его авторы учитывали достижения многих
других языков программирования: C++, C, Java, Delphi, Visual Basic и т.д. При разработке C# у его авторов была возможность оставить в прошлом все неудобные и неприятные особенности (существующие, как правило, для обратной совместимости), любого из предшествующих ему языков. В результате получился действительно простой, удобный и современный язык, по мощности не уступающий С++, но существенно повышающий продуктивность разработок.

C# является хорошим выбором для быстрого конструирования различных компонентов - от высокоуровневой бизнес логики до системных приложений, использующих низкоуровневый код. Также следует отметить, что C# является и Web_ориентированным - используя простые встроенные конструкции языка ваши компоненты могут быть легко превращены в Web_сервисы, к которым можно будет обращаться из Internet посредством любого языка на любой операционной системе. Дополнительные возможности и преимущества перед другими языками приносит в C# использование передовых Web_технологий, таких как: XML и SOAP. Среда разработки Web_сервисов позволяет программисту смотреть на существующие сегодня Web_приложения, как на родные C# объекты, что дает возможность разработчикам соотнести имеющиеся Web_сервисы с их познаниями в объектно-ориентированном программировании.

Страницы: 1, 2