Основания для разработки

МИНИСТЕРСТВО ОБОРОНЫРОССИЙСКОЙ ФЕДЕРАЦИИ

ВОЕННО-МОРСКОЙ ИНСТИТУТ РАДИОЭЛЕКТРОНИКИ

Им. А. С. Попова

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

высшего профессионального образования

«Военный учебно-научный центр Военно-Морского Флота «Военно-морская академия

имени Адмирала Флота Советского Союза Н. Г. Кузнецова»

Кафедра боевого применения АСУ

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

по дисциплине:

«ТЕХНОЛОГИИ РАЗРАБОТКИ ПРОГРАМНОГО ОБЕСПЕЧЕНИЯ»

на тему: «Разработка информационно-справочной системы администратора ЛВС ».

Выполнил: курсант 246 класса Редин Н.А.

Проверил: капитан-лейтенант Скородумов Д.Н.

Петродворец

СОДЕРЖАНИЕ:

ВВЕДЕНИЕ ……………………………………………………………...…...3

1.Функциональная модель ……………………………………….…...........9

ТЕХНИЧЕСКОЕ ЗАДАНИЕ

2.1. Введение. …...…...…...…...…...…...…...…...…...…...…...…...….. 13

2.2. Основания для разработки …..…..…..…..…..…..…..…..…..…..….. 13

2.3. Назначение разработки..…..…..…..…..…..…..…..…..…..…..…..13

2.4. Требования к программе или программному изделию …..…14

2.4.1. Требования к функциональным характеристикам …..…….14

2.4.2. Требования к надежности …..…..…..…..…..…..…..…..…..…..…..14

2.4.3. Условия эксплуатации..…..…..…..…..…..…..…..…..…..…..…15

2.4.4. Требования к параметрам технических средств …..………...15

2.4.5. Требования к информационной и программной совместимости. ……………………………………………………………….…15

2.4.6. Требования к маркировке и упаковке ………………………..…15

2.4.7. Требования к транспортированию и хранению ……………...16

3. Требования к программной документации ……………………….16

4. Стадии и этапы разработки …………………………………………..…16

4.1 Стадии разработки ………………………………………………………..16

4.2 Этапы разработки ………………………………………………………...16

4.3 Содержание работ по этапам …………………………………………..17

4.4 Календарный план ……………………………………………………..…18

5. Порядок контроля и приемки ………………………………………..…19

5.1 Виды испытаний ………………………………………………………..…19

5.2 Общие требования к приемке работы ……………………………..19

6. Предложения по архитектуре программной системы ……….....19

7.Информационно-логическая модель базы данных …………….20

8.Заключение …………………………………………………………………….21

9. Список используемой литературы ………………………………….....22

Введение

Технология создания крупных информационно-справочных систем (далее - ИСС) предъявляет особые требования к методикам реализации и программным инструментальным средствам, а именно:

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

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

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

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

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

Рис.1. Общая схема взаимодействия инструментальных средств Logic Works и Rational Software.

Для проведения анализа и реорганизации бизнес-процессов Logic Works предлагает CASE - средство верхнего уровня - BPwin, поддерживающий методологии IDEF0 (функциональная модель), IDEF3 (WorkFlow Diagram) и DFD (DataFlow Diagram). Функциональная модель предназначена для описания существующих бизнес-процессов на предприятии (так называемая модель AS-IS) и идеального положения вещей - того, к чему нужно стремиться (модель TO-BE). Методология IDEF0 предписывает построение иерархической системы диаграмм - единичных описаний фрагментов системы. Сначала проводится описание системы в целом и ее взаимодействия с окружающим миром (контекстная диаграмма), после чего проводится функциональная декомпозиция - система разбивается на подсистемы и каждая подсистема описывается отдельно (диаграммы декомпозиции). Затем каждая подсистема разбивается на более мелкие и так далее до достижения нужной степени подробности. После каждого сеанса декомпозиции проводится сеанс экспертизы, каждая диаграмма проверяется экспертами предметной области, представителями заказчика, людьми, непосредственно участвующими в бизнес - процессе. Такая технология создания модели позволяет построить модель адекватную предметной области на всех уровнях абстрагирования. Если в процессе моделирования нужно осветить специфические стороны технологии предприятия, BPwin позволяет переключиться на любой ветви модели на нотацию IDEF3 или DFD и создать смешанную модель. Нотация DFD включает такие понятия как внешняя ссылка и хранилище данных, что делает ее более удобной (по сравнению с IDEF0) для моделирования документооборота. Методология IDEF3 включает элемент “перекресток”, что позволяет описать логику взаимодействия компонентов системы.

На основе модели BPwin’а можно построить модель данных. Для построения модели данных Logic Works предлагает мощный и удобный инструмент - ERwin. Хотя процесс преобразования модели BPwin в модель данных плохо формализуется и поэтому полностью не автоматизирован, Logic Works предлагает удобный инструмент для облегчения построения модели данных на основе функциональной модели - механизм двунаправленной связи BPwin - ERwin (1, рис.1). ERwin имеет два уровня представления модели - логический и физический. На логическом уровне данные представляются безотносительно конкретной СУБД, поэтому могут быть наглядно представлены даже для неспециалистов. Физический уровень данных - это, по - существу, отображение системного каталога, который зависит от конкретной реализации СУБД. ERwin позволяет проводить процессы прямого и обратного проектирования БД (2, рис.1). Это означает, что по модели данных можно сгенерировать схему БД или автоматически создать модель данных на основе информации системного каталога. Кроме того, ERwin позволяет выравнивать модель и содержимое системного каталога после редактирования того, либо другого. ERwin интегрируется с популярными средствами разработки клиентской части - PowerBuilder, SQLWindows, Visual Basic, Delphi (3, рис.1), что позволяет автоматически генерировать код приложения, который готов к компиляции и выполнению (4, рис.1).

Создание современных информационно-справочных систем, основанных на широком использовании распределенных вычислений, объединении традиционных и новейших информационных технологий, требует тесного взаимодействия всех участников проекта: менеджеров, бизнес и системных аналитиков, администраторов баз данных, разработчиков. Для этого использующиеся на разных этапах и разными специалистами средства моделирования и разработки должны быть объединены общей системой организации совместной работы. Фирма Logic Works разработала систему Model Mart - хранилище моделей, к которому открыт доступ для участников проекта создания информационной системы (5, рис.1). Model Mart удовлетворяет всем требованиям, предъявляемым к средствам разработки крупных информационных систем, а именно:

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

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

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

Как было указано выше, при разработке крупных проектов критичным становится время реализации проекта. Одним из решений проблемы может стать автоматическая генерация кода приложения (клиентской части) CASE - средствами на основе модели предметной области. Хотя ERwin решает эту задачу, код генерируется на основе модели IDEF1X, то есть фактически на основе реляционной модели данных, которая непосредственно не содержит информацию о бизнес - процессах. Как следствие этого, сгенерированный код не может полностью обеспечить функциональность приложения со сложной бизнес-логикой. Существует альтернативная технология кодогенерации, которая лишена этого недостатка - объектно-ориентированное проектирование, реализованное в Rational Rose (Rational Software). Rational Rose – позволяющее строить объектные модели в различных нотациях (OMT, UML, Буч) и генерировать на основе полученной модели приложения на языках программирования C++, Visual Basic, Power Builder, Java, Ada, Smalltalk и др. Поскольку генерация кода реализована на основе знаний предметной области, а не на основе реляционной структуры данных, полученный код более полно отражает бизнес-логику. Rational Rose поддерживает не только прямую генерацию кода, но и обратное проектирование, то есть создание объектной модели по исходному коду приложения (6, рис.1).

Rational Rose предназначен для генерации клиентской части приложения. Для генерации схемы БД объектную модель следует конвертировать в модель данных IDEF1X. Модуль ERwin Translation Wizard (Logic Works) позволяет перегружать объектную модель Rational Rose в модель данных ERwin (и обратно) и, с помощью ERwin, сгенерировать схему БД (7, рис.1). Таким образом, технологическая цепочка Rational Rose - ERwin Translation Wizard - ERwin позволяет реализовывать крупные проекты в технологии клиент - сервер.

ФУНКЦИОНАЛЬНАЯ МОДЕЛЬ

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

На рисунке 2 показано обеспечение деятельности администратора ЛВС. Для работы системы необходимо наличие данных для анализа, т.е. наличие входного потока данных(информация о аппаратных средствах; информация о пользователях; информация о политике безопасности). Выходным ресурсом системы являются результат запроса. В качестве механизма управления выступает администратор ЛВС, а механизмом исполнения являются программные средства, которые выводят на экран нужную информацию для администратора ЛВС.

Получаем контекстную диаграмму верхнего уровня, представленную на рисунке 2.

Рис.2 Контекстная диаграмма верхнего уровня

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

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

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

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

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

Из выше сказанного получаем контекстную диаграмму 2 уровня представленную на рисунке 3.

Рис.3 Контекстная диаграмма 2 уровня

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

- учетные записи пользователей;

- типы учетных записей пользователей;

- пароли пользователей;

- данные о используемой политике безопасности;

- данные о используемых аппаратных средствах;

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

Контекстная диаграмма блока настройки политики безопасности имеет след вид:

Рис. 4

ТЕХНИЧЕСКОЕ ЗАДАНИЕ

Введение

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

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

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

Основания для разработки

Документом для разработки является бланк задания на выполнение курсовой работы по дисциплине «Технология разработки программного обеспечения», подписанный начальником кафедры БП АСУ капитаном

1 ранга О. Пантиховским __ марта 2010 г. по теме «Разработка информационно-справочной системы администратора ЛВС»

Назначение разработки

Информационно-справочная системы для администратора ЛВС должна:

-осуществлять просмотр информации об аппаратных средствах;

-включать возможность добавления информации, удаления и редактирования;

-возможность просмотра и печати отчетов, содержащих информацию: