Размещено на http://www.allbest.ru/

Содержание

• Введение
• Глава 1. Теоретическая часть. Проектирование программного обеспечения
• 1.1 Методологии разработки программного обеспечения
• 1.1.1 Процесс разработки программного обеспечения
• 1.1.2 Модели процесса разработки ПО
• 1.2.1 Case-технология
• 1.2.2 RAD-технология
• 1.3.1 Взаимосвязи данных
• 1.3.2 Нормализация модели базы данных
• 1.3.3 Ключи, индексы, триггеры, хранимые процедуры
• 1.3.4 SQL-язык
• 1.4.1 Инструментальные средства для разработки клиентской части
• 1.4.2 Инструментальные средства для разработки серверной части
• 1.4.3 Среда визуальной разработки
• Глава 2. Практическая часть. Проектирование и разработка программного обеспечения
• 2.1 Цель разработки программного обеспечения
• 2.2 Состав программного обеспечения
• 2.3 Требования к программному обеспечению
• 2.4 Обработка результатов экспериментов
• 2.5 Разработка базы данных
• 2.6 Разработка пользовательского интерфейса
• 2.6.1 Разработка меню
• 2.6.2 Разработка форм
• Глава 3. Экономическая часть. Расчет себестоимости разработки программного обеспечения
• 3.1 Расчет заработной платы исполнителя работ по созданию программного продукта и заработной платы руководителя.
• 3.2 Расчет себестоимости
• 3.3 Оценка экономической эффективности разработки
• 3.4. Оценка окупаемости вложенных средств
• 3.5. Экономическая эффективность разработки
• Глава 4. Охрана труда
• 4.1. Требования к помещениям для работы с ПЭВМ
• 4.2. Требования к микроклимату на рабочих местах, оборудованных ПЭВМ
• 4.3. Требования к уровням шума и вибрации на рабочих местах, оборудованных ПЭВМ
• 4.4. Требования к освещению на рабочих местах, оборудованных ПЭВМ
• 4.5. Требования к уровням электромагнитных полей на рабочих местах, оборудованных ПЭВМ
• 4.6. Требования к визуальным параметрам ВДТ, контролируемым на рабочих местах
• 4.7. Общие требования к организации рабочих мест пользователей ПЭВМ
• 4.8. Требования к организации и оборудованию рабочих мест с ПЭВМ
• 4.9.Требования безопасности при работе на ПЭВМ
• 4.9.1. Общие требования охраны труда при работе с ПЭВМ
• 4.9.2 Требования безопасности перед началом работы
• 4.9.3. Требования безопасности во время работы
• 4.9.4. Требования безопасности в аварийных ситуациях
• 4.9.5. Требования безопасности после окончания работ
• 4.10. Заключение
• Заключение
• Список использованных источников
• Приложение
• Введение
• Для успешного развития работ в области физики высоких плотностей энергии требуются мощные источники электромагнитной энергии, позволяющие получать мультимегаамперные импульсы тока с микросекундным временем нарастания.
• Идея преобразования механической энергии взрыва в электромагнитную энергию была высказана в 1951 г. А.Д. Сахаровым и им же были предложены конструктивные схемы устройств для генерации сверхсильных магнитных полей и токов, основанные на быстрой деформации взрывом токонесущих контуров. Взрывомагнитные системы такого типа получили название магнитокумулятивных генераторов. А.Д. Сахаровым были предложены два типа взрывных генераторов: МК-1 (сжатие аксиального магнитного поля) и МК-2 (вытеснение магнитного поля из соленоида и последующее его сжатие стенками коаксиала).
• К настоящему времени разработано много вариантов этих генераторов, отличающихся геометрией, способом создания начального магнитного потока, способом выведения магнитной энергии в нагрузку и другими параметрами. Позже стало использоваться также название взрывомагнитные генераторы (ВМГ) (здесь в дальнейшем используется название ВМГ применительно к МК-2). Сравнительно большое время нарастания тока (десятки - сотни микросекунд) не позволяет использовать ВМГ без специальных дополнительных устройств там, где требуется формирование импульсов тока с фронтом менее 1 мкс. Одним из способов получения таких импульсов является коммутация тока ВМГ в нагрузку с помощью размыкателя. Поэтому практически одновременно с разработкой ВМГ проводились исследования коммутации энергии из ВМГ в нагрузку. На основании этих исследований созданы несколько типов размыкателей, работа которых основана на использовании различных физических процессов, вызывающих рост сопротивления проводника за короткое время.
• Для коммутации мегаамперных токов обычно используются размыкатели, работающие на принципе электрического взрыва тонких фольг или проволочек, а также размыкатели на основе механического разрушения проводников продуктами взрыва заряда взрывчатого вещества (ВВ). Эффективность передачи энергии в нагрузку и параметры импульса тока зависят от величины и скорости нарастания сопротивления, вводимого размыкателем в цепь разрыва, а также от отношения и величины индуктивностей накопителя и нагрузки.
• Для повышения эффективности размыкателей проводились многочисленные экспериментальные и теоретические исследования. На первом этапе, в 60-70 гг. прошлого века, основной упор делался на экспериментальные методы, из-за сложности теоретического подхода.
• Разрабатываемые теоретические модели физических процессов, происходящих в размыкателе, позволяют с той или иной степенью достоверности описывать работу размыкателя и делать выводы о путях оптимизации их конструкции. Несмотря на длительную историю исследования, эта проблема еще далека от полного разрешения. В последнее время наметился определенный прогресс, связанный с разработкой программ для магнитогидродинамического моделирования, позволивший обосновать некоторые ранее известные эмпирические закономерности. Результаты таких исследований имеют большое познавательное и практическое значение, поскольку, с одной стороны, способствуют развитию представлений о физической природе явления, а с другой, выявляют пути целенаправленного улучшения характеристик размыкателя.
• Для хранения, систематизации, анализа результатов экспериментов, удобнее организовать их в базу данных.
• Дипломная работа посвящена разработке базы данных для хранения и обработки информации, отражающей начальные условия и результаты экспериментальных исследований плоских моделей взрывных размыкателей. К настоящему времени проведено около 200 таких экспериментов. Условия эксперимента заданы в виде эскиза размыкателя, параметров цепи и величины разрываемого тока. Результаты представлены в виде осциллограмм тока разряда конденсаторной батареи и производной тока в нагрузке, временных зависимостей физических величин, изменяющихся в процессе коммутации тока, полученных в результате обработки осциллограмм, а также выходных характеристик импульса тока в нагрузке.
• Целью данной работы является:
• - Систематизация данных
• - Оцифровка осциллограмм с помощью программы GetData Graph Digitizer.
• - Расчет временных зависимостей физических величин, изменяющихся в процессе коммутации тока, по результатам оцифровки осциллограмм.
• - Определение структуры базы данных с помощью sql-скрипта, разработанного с использованием некоммерческой системы управления базами данных (СУБД) Firebird.
• - Создание программного продукта, обеспечивающего связь с базой данных и формирующего запросы к ней для быстрого поиска и редактирования актуальной для пользователя информации. Создание программного продукта осуществляется с помощью среды быстрой разработки приложений Borland Delphi 7.

Глава 1. Теоретическая часть. Проектирование программного обеспечения

1.1 Методологии разработки программного обеспечения

1.1.1 Процесс разработки программного обеспечения

Процесс разработки программного обеспечения (англ. software development process, software process) -- структура, согласно которой построена разработка программного обеспечения (ПО).

Процесс разработки состоит из множества подпроцессов, или дисциплин:

1. Парадигма программирования

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

2. Бизнес-моделирование

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

3. Анализ требований

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

Виды требований по уровням:

1) Бизнес-требования - определяют назначение ПО, описываются в документе о видении (vision) и границах проекта (scope).

2) Пользовательские требования - определяют набор пользовательских задач, которые должна решать программа, а также способы (сценарии) их решения в системе. Пользовательские требования могут выражаться в виде фраз утверждений, в виде способов применения (use case), пользовательских историй (user story), сценариев взаимодействия (scenario).

3) Функциональные требования - охватывают предполагаемое поведение системы, определяя действия, которые система способна выполнять.

Виды требований по характеру:

1) Функциональный характер - требования к поведению системы.

2) Бизнес-требования.

3) Пользовательские требования.

4) Функциональные требования

5) Нефункциональный характер - требования к характеру поведения системы.

6) Бизнес-правила - определяют ограничения, проистекающие из предметной области и свойств автоматизируемого объекта (предприятия).

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

8) Атрибуты качества.

9) Внешние системы и интерфейсы.

10) Ограничения.

Методы выявления требований:

1) Интервью, опросы, анкетирование;

2) Мозговой штурм, семинар;

3) Наблюдение за производственной деятельностью, «фотографирование» рабочего дня;

4) Анализ нормативной документации;

5) Анализ моделей деятельности;

6) Анализ конкурентных продуктов;

7) Анализ статистики использования предыдущих версий системы.

4. Планирование

5. Разработка архитектуры

6. Кодирование

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

7. Тестирование и отладка

Тестирование программного обеспечения - процесс исследования программного обеспечения (ПО) с целью получения информации о качестве продукта.

8. Документирование

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

Документ - элемент документации: целевая информация, предназначенная для конкретной аудитории, размещенная на конкретном носителе (например, в книге, на диске, в краткой справочной карте) в заданном формате.

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

Существует четыре основных типа документации на ПО:

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

2) техническая - документация на код, алгоритмы, интерфейсы, API;

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

4) маркетинговая.

9. Внедрение

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

При внедрении программного обеспечения требуется действие в трех следующих плоскостях работ:

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

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

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

10. Сопровождение

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

1.1.2 Модели процесса разработки ПО

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

* Каскадная разработка или модель водопада.

* Итеративная разработка.

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

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

Рисунок 1. - Классическая каскадная модель с обратной связью

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

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

Краткое описание фаз каскадной модели

Приведенная ниже характеристика представляет собой краткое описание каждой фазы каскадной модели (включая фазы интеграции):

1) исследование концепции - происходит исследование требований на системном уровне с целью определения возможности реализации концепции;

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

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

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

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

6) процесс установки - включает установку ПО, его проверку и официальную приемку заказчиком для операционной среды;

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

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

9) процесс вывода из эксплуатации - вывод существующей системы из ее активного использования либо путем прекращения ее работы, либо благодаря ее замене новой системой или модернизированной версией существующей системы;

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

Преимущества каскадной модели

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

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

2) она упорядочение справляется со сложностями и хорошо срабатывает для тех проектов, которые достаточно понятны, но все же трудно разрешимы;

3) она весьма доступна для понимания, так как преследуется простая цель - выполнить необходимые действия;

4) она проста и удобна в применении, так как процесс разработки выполняется поэтапно;

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

6) она отличается стабильностью требований;

7) она представляет собой шаблон, в который можно поместить методы для выполнения анализа, проектирования, кодирования, тестирования и обеспечения;

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

9) она способствует осуществлению строгого контроля менеджмента проекта;

10) при правильном использовании модели дефекты можно обнаружить на более ранних этапах, когда их устранение еще не требует относительно больших затрат;

11) она облегчает работу менеджеру проекта по составлению плана и Комплектации команды разработчиков;

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

13) она определяет процедуры по контролю за качеством. Каждые полученные данные подвергаются обзору. Такая процедура используется командой разработчиков для определения качества системы;

14) стадии модели довольно хорошо определены и понятны;

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

Недостатки каскадной модели

Но при использовании каскадной модели для проекта, который трудно назвать подходящим для нее, проявляются следующие недостатки:

1) в основе модели лежит последовательная линейная структура, в результате чего каждая попытка вернуться на одну или две фазы назад, чтобы исправить какую-либо проблему или недостаток, приведет к значительному увеличению затрат и сбою в графике;

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

3) она не отображает основное свойство разработки ПО, направленное на разрешение задач. Отдельные фазы строго связаны с определенными действиями, что отличается от реальной работы персонала или коллективов;

4) она может создать ошибочное впечатление о работе над проектом. Выражение типа "35 процентов выполнено" -- не несет никакого смысла и не является показателем для менеджера проекта;

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

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

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

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

9) проект можно выполнить, применив упорядоченную каскадную модель, и привести его в соответствие с письменными требованиями, что, однако, не гарантирует его запуска в эксплуатацию;

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

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

12) все требования должны быть известны в начале жизненного цикла, но клиенты редко могут сформулировать все четко заданные требования на этот момент разработки. Модель не рассчитана на динамические изменения в требованиях на протяжении всего жизненного цикла, так как получаемые данные "замораживаются". Использование модели может повлечь за собой значительные затраты, если требования в недостаточной мере известны или подвержены динамическим изменениям во время протекания жизненного цикла;

13) возникает необходимость в жестком управлении и контроле, поскольку в модели не предусмотрена возможность модификации требований;

14) модель основана на документации, а значит, количество документов может быть избыточным;

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

16) отсутствует возможность учесть переделку и итерации за рамками проекта.

Область применения каскадной модели

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

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

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



Рисунок 2. - Итеративная разработка

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

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

1) Полноценную систему с ограниченной функциональностью, готовую для промышленной эксплуатации.

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

Итеративная разработка обладает рядом преимуществ по сравнению с последовательной моделью:

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

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

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

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

1.2 Технологическое обеспечение проектирования и разработки ПО

1.2.1 Case-технология

CASE (англ. Computer-Aided Software Engineering) - набор инструментов и методов программной инженерии для проектирования программного обеспечения, который помогает обеспечить высокое качество программ, отсутствие ошибок и простоту в обслуживании программных продуктов. Также под CASE понимают совокупность методов и средств проектирования информационных систем с использованием CASE-инструментов.

Типичными CASE-инструментами являются:

1) инструменты управления конфигурацией;

2) инструменты моделирования данных;

3) инструменты анализа и проектирования;

4) инструменты преобразования моделей;

5) инструменты редактирования программного кода;

6) инструменты реорганизации кода;

7) генераторы кода;

8) инструменты для построения UML-диаграмм.

Классификация case-инструментов

CASE-инструменты классифицируются по типам и категориям.

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

а) средства анализа -- предназначены для построения и анализа предметной области;

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

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

1.2.2 RAD-технология

RAD (от англ. rapid application development -- быстрая разработка приложений) -- концепция создания средств разработки программных продуктов, уделяющая особое внимание быстроте и удобству программирования, созданию технологического процесса, позволяющего программисту максимально быстро создавать компьютерные программы. Практическое определение: RAD -- это жизненный цикл процесса проектирования, созданный для достижения более высокой скорости разработки и качества ПО, чем это возможно при традиционном подходе к проектированию. С конца XX века RAD получила широкое распространение и одобрение. Концепцию RAD также часто связывают с концепцией визуального программирования.

Назначение

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

Применение

Технологию RAD целесообразно применять в тех случаях, когда

1) Четко определены некоторые приоритетные направления разработки проекта;

2) Необходимо выполнение проекта в сжатые сроки. Быстрое выполнение проекта позволяет создать систему, отвечающую требованиям сегодняшнего дня. Если система проектируется долго, то весьма высока вероятность, что за это время существенно изменятся фундаментальные положения, регламентирующие деятельность организации, то есть, система морально устареет ещё до завершения её проектирования;

3) Нечетко определены требования к ПО. В большинстве случаев заказчик весьма приблизительно представляет себе работу будущего программного продукта и не может четко сформулировать все требования к ПО. Требования могут быть вообще не определены к началу проекта либо могут изменяться по ходу его выполнения;

4) Проект выполняется в условиях ограниченности бюджета. Разработка ведется небольшими RAD-группами в короткие сроки, что обеспечивает минимум трудозатрат и позволяет вписаться в бюджетные ограничения;

5) Интерфейс пользователя (GUI) есть главный фактор. Нет смысла заставлять пользователя рисовать картинки. RAD-технология дает возможность продемонстрировать интерфейс в прототипе, причем достаточно скоро после начала проекта;

6) Возможно разбиение проекта на функциональные компоненты. Если предполагаемая система велика, необходимо, чтобы её можно было разбить на мелкие части, каждая из которых обладает четкой функциональностью. Они могут выпускаться последовательно или параллельно (в последнем случае привлекается несколько RAD-групп).

Основные принципы и фазы разработки

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

Принципы:

1) Инструментарий должен быть нацелен на минимизацию времени разработки.

2) Создание прототипа для уточнения требований заказчика.

3) Цикличность разработки: каждая новая версия продукта основывается на оценке результата работы предыдущей версии заказчиком.

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

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

6) Управление проектом должно минимизировать длительность цикла разработки.

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

Фазы разработки:

1) Планирование -- совокупность требований, полученных при системном планировании и анализе процедуры разработки жизненного цикла (SDLC). На этом этапе пользователи, менеджеры и IT-специалисты обсуждают задачи проекта, его объём, системные требования, а также сложности, которые могут возникнуть при разработке. Фаза завершается согласованием ключевых моментов с RAD-группой и получением от руководителей проекта разрешения на продолжение.

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

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

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

Преимущества

Технология быстрой разработки приложений (RAD) позволяет обеспечить:

1) быстроту продвижения программного продукта на рынок;

2) интерфейс, устраивающий пользователя;

3) легкую адаптируемость проекта к изменяющимся требованиям;

4) простоту развития функциональности системы.

1.3 Проектирование баз данных

1.3.1 Взаимосвязи данных

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

Главная таблица (родительская таблица или master) - это таблица, в которой содержатся основные данные.

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

Главная таблица может иметь несколько подчиненных таблиц.

Существует четыре вида связи между таблицами:

1) один к одному;

2) один ко многим;

3) много к одному;

4) много ко многим.

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

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

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

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

1.3.2 Нормализация модели базы данных

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

1) достаточно быстрый доступ к данным;

2) отсутствие повторяющихся записей;

3) целостность данных.

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

Избыточность информации - это повторение данных, содержащихся в базе данных.

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

- аномалии удаления;

- аномалия обновления;

- аномалия ввода.

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

Аномалии обновления имеют место, если значение поля одной записи изменяется, а аналогичные значения того же поля для всей таблицы остаются без изменения.

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

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

Обычно выделяют три нормальные формы базы данных:

1) первая нормальная форма;

2) вторая нормальная форма;

3) третья нормальная форма.

Условиям первой нормальной формы удовлетворяет таблица, в которой:

1) каждое поле содержит неделимую информацию;

2) отсутствуют повторяющиеся группы полей.

Таблица, соответствующая второй нормальной форме, должна отвечать следующим требованиям:

1) таблица должна быть приведена к первой нормальной форме;

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

Третья нормальная форма предъявляет к таблице следующие требования:

1) таблица должна быть приведена ко второй нормальной форме;

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

1.3.3 Ключи, индексы, триггеры, хранимые процедуры

Ключи

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

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

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

Критерии выбора ключевых полей:

1) ключ не должен содержать поля, которые можно удалять, не нарушив при этом уникальности ключа;

2) ключевым полем не может быть поле, содержащее графику, или поле типа memo, включающее в себя комментарии;

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

Индексы

Индекс - это комбинация нескольких полей, которые служат для быстрого доступа к необходимой информации.

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

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

Хранимые процедуры

Хранимые процедуры - это подпрограммы на языке SQL, хранящиеся в базах данных и представляющие собой один из видов их общих ресурсов. Тело любой хранимой процедуры представляет последовательность SQL-операторов, например таких, как выборка данных (SELECT), их модификация (UPDATE), удаление данных (DELETE), операторы цикла (LOOP), условные операторы (IF, CASE) и ряд других. Процедуры вызываются оператором CALL и могут использовать как входные параметры (передающие значения в процедуру), так и выходные параметры (возвращающие результаты процедуры вызывающему программному объекту). Процедуры могут вызываться из процедур, функций и других типов программных объектов.

Хранимые процедуры, создаются оператором CREATE PROCEDURE. Модификация тела хранимой процедуры осуществляется оператором ALTER PROCEDURE. Эти операторы могут использовать:

1) пользователи, которым разрешено создавать объекты базы данных, т.е. тем, кто имеет класс полномочий - RESOURCE;

2) администратор базы данных.

Триггеры

Триггер - хранимая в базе данных процедура, автоматически вызываемая СУБД при возникновении соответствующих условий. При определении триггера указывается два условия его применимости - общее условие (имя отношения и тип операции манипулирования данными) и конкретное условие (логическое выражение, построенное по правилам, близким к правилам ограничений целостности), а также действие, которое должно быть выполнено над БД при наличии условий применимости. В языке обеспечиваются возможности определения триггеров, которые вызываются («срабатывают») при вставке одной или нескольких строк в указанную таблицу, при модификации одной или нескольких строк в указанной таблице или при удалении одной или нескольких строк из указанной таблицы. Вообще говоря, триггер может производить любое действие, необходимое для соответствующего приложения. Можно определить триггеры, срабатывающие по одному разу для операций INSERT, UPDATE или DELETE, но существует и возможность определения триггеров, вызываемых при вставке, модификации или удалении каждой отдельной строки. Таблица, с которой связывается определение триггера, называется предметной таблицей (subject table), а оператор SQL, выполнение которого приводит к срабатыванию триггера, мы будем называть инициирующим (triggering SQL statement).

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

1.3.4 SQL-язык

SQL (англ. Structured Query Language -- «язык структурированных запросов») -- универсальный компьютерный язык, применяемый для создания, модификации и управления данными в реляционных базах данных.

SQL позволяет выполнять следующий набор операций:

1) создание в базе данных новой таблицы;

2) добавление в таблицу новых записей;

3) изменение записей;

4) удаление записей;

5) выборка записей из одной или нескольких таблиц (в соответствии с заданным условием);

6) изменение структур таблиц;

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

Каждое предложение SQL -- это либо запрос данных из базы, либо обращение к базе данных, которое приводит к изменению данных в базе. В соответствии с тем, какие изменения происходят в базе данных, различают следующие типы запросов:

1) запросы на создание или изменение в базе данных новых или существующих объектов (при этом в запросе описывается тип и структура создаваемого или изменяемого объекта);

2) запросы на получение данных;

3) запросы на добавление новых данных (записей)

4) запросы на удаление данных;

5) обращения к СУБД.

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

1) запросы, оперирующие самими таблицами (создание и изменение таблиц);

2) запросы, оперирующие с отдельными записями (или строками таблиц) или наборами записей.

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

1) типа хранимых в каждом поле значений;

2) связей между таблицами (задание первичных и вторичных ключей);

3) информации, необходимой для построения индексов.

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

1) вставка новой строки;

2) изменение значений полей строки или набора строк;

3) удаление строки или набора строк.

Самый главный вид запроса -- это запрос, возвращающий (пользователю) некоторый набор строк, с которым можно осуществить одну из трёх операций:

1) просмотреть полученный набор;

2) изменить все записи набора;

3) удалить все записи набора.

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

Описание

Язык SQL представляет собой совокупность:

1) операторов;

2) инструкций;

3) вычисляемых функций.

Операторы SQL делятся на:

1) операторы определения данных (Data Definition Language, DDL);

2) CREATE создает объект БД (саму базу, таблицу, представление, пользователя и т. д.);

3) ALTER изменяет объект;

4) DROP удаляет объект;

5) операторы манипуляции данными (Data Manipulation Language, DML);

6) SELECT считывает данные, удовлетворяющие заданным условиям;

7) INSERT добавляет новые данные;

8) UPDATE изменяет существующие данные;

9) DELETE удаляет данные;

10) операторы определения доступа к данным (Data Control Language, DCL);

11) GRANT предоставляет пользователю (группе) разрешения на определенные операции с объектом;

12) REVOKE отзывает ранее выданные разрешения;

13) DENY задает запрет, имеющий приоритет над разрешением;

14) операторы управления транзакциями (Transaction Control Language, TCL);

15) COMMIT применяет транзакцию;

16) ROLLBACK откатывает все изменения, сделанные в контексте текущей транзакции;

17) SAVEPOINT делит транзакцию на более мелкие участки.

1.4 Инструментальные средства разработки БД и интерфейсов ПО

Любое клиент-серверное приложение состоит из клиентского и серверного приложений. Соответственно этому имеются инструментальные среды разработки клиентской части и серверной. В качестве первых обычно выступают интегрированные среды разработки, ИСР (Integrated Development Environment, IDE). В качестве вторых - системы управления базами данных, СУБД.

1.4.1 Инструментальные средства для разработки клиентской части

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

Раньше для разработки пользовательских корпоративных программ, работающих в основном в символьном режиме, использовались такие языки программирования, как ANSI С, COBOL, FORTRAN и Pascal. Сегодня большинство вновь разрабатываемых клиентских прикладных программ является GUI-приложениями - они содержат графический интерфейс пользователя. Большинство из доступных сегодня инструментальных средств являются дружественными по отношению к пользователю и объектно-ориентированными. В них широко используются пиктограммы, различного рода мастера, а также технология drag-and-drop. Наиболее популярными средствами для создания Web-приложений являются C++-Builder и IntraBuilder фирмы Borland, а также Visual J++ и Visual C++ компании Microsoft. Другие популярные средства разработки корпоративных приложений для локальных вычислительных сетей - PowerBuilder компании Powersoft, Developer/2000 корпорации Oracle, Visual Basic компании Microsoft и Delphi фирмы Borland.

1.4.2 Инструментальные средства для разработки серверной части

Ядром любой прикладной программы является ее серверная часть. Именно здесь незаметно для конечного пользователя базы данных происходит вся основная работа. Серверная часть приложения включает сам сервер БД, источники данных, а также связующее программное обеспечение, с помощью которого приложение подключается к Web-серверу или удаленной базе данных в локальной сети. Важнейшими серверами баз данных являются Oracle, Informix, Sybase, Microsoft SQL Server и Borland InterBase.

Сервер БД

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

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