Справочник радиолюбителя

2

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

ГОУ ВПО Череповецкий государственный университет

Институт инноваций и непрерывного образования

Кафедра Программное обеспечение ЭВМ

Дисциплина Проектирование информационных систем

КУРСОВАЯ РАБОТА

Проектирование информационной системы

«Справочник радиолюбителя»

Расчетно-пояснительная записка к курсовой работе

Листов 38

Выполнил студент:

Холодов К. И.

Группа: 6СПО32

Принял преподаватель:

Селяничев О. Л.

Отметка о зачете:______________

Череповец

2007г

1. Описание предметной области……………………………………….….....5

2.Выбор ЖЦ ИС………………………………………………………………..6

2.1 Методология RAD…………………………………………………….....10

3. Этапы ЖЦ…………………………………………………………………...11

3.1 Фаза анализа и планирования требований……………………………..11

3.2 Фаза проектирования…………………………...…………………….....11

3.3 Фаза построения……………………………………………………..…..17

3.4 Фаза внедрения…………………………………………………………..18

4. Выбор CASE средства……………………………….………………….....19

5. Описание программы………………………………………………………24

Заключение…………………………..……………………..............................25

Литература…………………………………..…………………………….......26

Приложение 1. Руководство пользователя………………………..………...27

Приложение 2. Листинг программы…………………………………………33

Введение

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

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

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

В приложении 1 необходимый материал для пользователя программы

В приложении 2 приводится листинг программы.

1.Описание предметной области

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

2. Выбор модели жизненного цикла информационной системы

Модель жизненного цикла (далее ЖЦ) программного обеспечения информационной системы (далее ПО ИС) при автоматизированном проектировании играет достаточно важную роль. Это обусловлено тем, что каждая из CASE-систем ориентирована на определенную модель ЖЦ ПО ИС.

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

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

Состав процессов ЖЦ регламентируется международным стандартом ISO/IEC 12207: 1995 «Information Technologe - Software Life Cycle Processes» («Информационные технологии - Процессы жизненного цикла программного обеспечения»). Стандарт ISO/IEC 12207 не предлагает конкретную модель ЖЦ и методы разработки ПО. Его регламенты являются общими для любых моделей ЖЦ, методологий и технологий разработки. Стандарт ISO/IEC 12207 описывает структуру процессов ЖЦ ПО, но не конкретизирует в деталях, как реализовать или выполнить действия и задачи, включенные в эти процессы.

К настоящему времени наибольшее распространение получили следующие две основные модели ЖЦ:

· каскадная модель (70-85 г.г.);

· спиральная модель (86-90 г.г.).

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

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

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

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

Рис.1 «Каскадная модель жизненного цикла»

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

Рис.2 «Модель жизненного цикла с промежуточным контролем»

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

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

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

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

Рис. 3 «Спиральная модель жизненного цикла»

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

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

В основе проекта любой ИС лежат: методологии, технологии и инструментальные средства проектирования.

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

Для разработки данной информационной системы использовалась методология RAD.

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

ЖЦ ПО по этой методологии состоит из 4-х этапов:

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

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

- построение;

- внедрение.

3. Этапы ЖЦ ИС

3.1 Фаза анализа и планирования требований.

Приоритетные функции ИС «Справочник радиолюбителя»:

- генерация различных отчетов о имеющихся радиодеталях;

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

- поиск по конкретным параметрам.

3.2 Фаза проектирования

Даталогическое проектирование

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

Начнём составление базы данных с нескольких ненормализованных таблиц, в которых заключаются все интересующие атрибуты (поля):

Ненормализованная таблица

Таблица 1 «Ненормализованная таблица»

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