ВВЕДЕНИЕ

Добавил:

ivanov666 Опубликованный материал нарушает ваши авторские права? Сообщите нам.

Вуз:

Башкирский Государственный Аграрный Университет

Предмет:

[НЕСОРТИРОВАННОЕ]

Файл:

Основы разработки информационных систем. Учебное пособие.pdf

Скачиваний:

Добавлен:

07.09.2026

Размер:

2 Мб

Скачать

☆

1 / 101 2 3 4 5 6 7 8 9 10 > Следующая >>>

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

Федеральное государственное бюджетное

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

«Тамбовский государственный технический университет»

И. П. РАК, А. В. ПЛАТЁНКИН, А. В. ТЕРЕХОВ

ОСНОВЫ РАЗРАБОТКИ

ИНФОРМАЦИОННЫХ СИСТЕМ

Утверждено Учёным советом университета

в качестве учебного пособия для студентов 1 – 4 курсов,

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

09.03.03 «Прикладная информатика», очной и заочной форм обучения

Учебное электронное издание

комплексного распространения

Тамбов

Издательство ФГБОУ ВО «ТГТУ»

2017

УДК 343.23(075.8) ББК Х408я73 Р19

Рецензенты:

Кандидат технических наук,

ведущий математик технического КБ АО «ТЗ «Ревтруд»

С. Н. Мочалин

Кандидат технических наук,

начальник управления заочного обучения ФГБОУ ВО «ТГТУ»

М. Ю. Серегин

Р19

Рак, И. П.

Основы разработки информационных систем [Электронный ресурс] : учебное пособие / И. П. Рак, А. В. Платёнкин, А. В. Терехов. – Тамбов : Изд-во ФГБОУ ВО «ТГТУ», 2017. – 1 электрон. опт. диск (CD-ROM). –

Системные требования : ПК не ниже класса Penti дисковод ; 26,

BN 978-5-8265-1727-7

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

Предназначено для студентов 1 – 4 курсов, обучающихся по направлению подготовки 09.03.03 «Прикладная информатика», очной и заочной форм обучения.

5 Mb ; RAM ; Windows 95/98/XP ; мышь. – Загл. с экрана.

m II ; CD-ROM-

УДК 343.23(075.8) ББК Х408я73

Все права на размножение и распространение в любой форме остаются за разработчиком.

ISBN 978-5-8265-1727-7

Нелегальное копирование и использование данного продукта запрещено.

ВВЕДЕНИЕ

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

экономический эффект их разработки;

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

екту на любой стадии его разработки;

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

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

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

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

обеспечения, включая объектно-ориентированные;

пользователем;

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

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

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

• быстро обнаружить и устранить в процессе разработки разногласия и

рограм-

• упростить и облегчить для новых специалистов подключение к про-

• свести к минимуму затраты на дальнейшую доработку, модифика-

• создать в процессе раз

работки мощный пакет документации, позво-

• сэкономить много времени при реализации последующих проектов,

В настоящем учебном пособии:

• рассматриваются и подробно анализируются этапы разработки про-

й готового испытанного программного продукта

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

• описываются методы традиционного и визуального программирования;

• описываются правила организации диалога программного изделия с

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

Настоящее учебное пособие пр

едназначено для использования студен-

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

Изучение дисциплин, освещённых в учебном пособии, служит фοрмирοванию следующих кοмпетенций, уcтанοвленных вο ФГΟC пο направлению пοдгοтοвки «Прикладная информатика»:

• ПК-1 – способность проводить обследование организаций, выявлять

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

• ПК-2 – способность разрабатывать, внедрять и а

даптировать при-

кладное программное обеспечение;

• ПК-3 – способность проектировать ИС в соответствии с профилем

подготовки по видам обеспечения;

• ПК-4 – способность документировать процессы создания информа-

ционных систем на стадиях жизненного цикла;

• ПК-6 – способность собирать детальную информацию для формали-

зации требований пользователей заказчика;

• ПК-9 – способность составлять техническую документацию проектов

автоматизаци

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

• ПК-17 – способность принимать участие в управлении проектами

создания информационных систем на стадиях жизненного цикла;

• ПК-19 – способность принимать участие в реализации профессио-

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

• ПКВ-4 – способность разрабатывать прикладное программное обеспе-

чение с использованием современных языков п

рограммирования и шаблонов.

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

1. МЕТОДИЧЕСКИЕ АСПЕКТЫ ПРОЕКТИРОВАНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ

1.1. ОБЩИЕ ПРИНЦИПЫ ПРОЕКТИРОВАНИЯ

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

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

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

роится из более мелких частей и т.д., до тех пор, пока самые мелкие

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

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

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

Понятие «правильная» по отношению к декомпозиции означает сле-

дующее:

• количество связей между отдельными модулями должно быть мини-

мальным (принцип «слабой связанности» – Low Coupling);

• связнос

максимальной (принцип «сильного сцепления» – High Cohesion).

ИНФОРМАЦИОННЫХ СИСТЕМ

ов содержат другие системы (подсистемы). Опреде-

я больше, чем просто сумма отдельных её частей.

ще они сложены из результатов комплексного

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

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

ду её модулями укладывались в ограниченные, стандартные рамки, т.е.:

• каждый модуль должен инкапсулировать своё содержимое, т.е. скры-

вать его от других модулей;

• каждый модуль должен иметь чётко определённый интерфейс с дру-

гими модулями.

Инкапсуляция позволяет рассматривать структуру каждого мо

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

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

о результата.

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

Функциональные группы п

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

ольких модулей.

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

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

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

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

снованы на единых правилах структурного построения,

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

На данный момент в технологии разработки ИС существуют два основных подхода к декомпозиции систем:

1) функционально-модульный (структурный);

2) объектно-ориентированный.

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

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

Главным недостатком данного подхо

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

Другой важной проблемой является неоднородность информационных

ресурсов, используемых в большинстве ИС. Проблема неоднородности тре-

ешения, опирающегося на методику интеграции ресурсов ИС. Такая

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

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

ведение системы описывается в терминах обмена сообще-

ниями между объектами.

При разработке ИС в настоящее время широко используется термин «архитектура».

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

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

Рассмотрим несколько определений архитектуры относительно инфор-

мационной системы:

• архитектура – организационная структура системы;

• архитектура информационной системы – концепция, оп

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

• архитектура – базовая организация системы, воплощённая в её ком-

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

• архитектура – набор значимых решений по поводу организации сис-

темы программного обеспечения (ПО), набор структурных элементов и их

фейсов, с помощью которых компонуется система вместе с их поведе-

интер

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

Архитектура ИС определяется как набор ответов на следующие вопросы:

• что делает система?;

• на какие части она разделяется?;

• как эти час

ти взаимодействуют?;

• где эти части размещены?.

Таким образом, архитектура ИС является моделью, связанной с решениями по выбору средств реализации, системы управления базами данных (СУБД), операционной платформы, телекоммуникационных средств и т.п.

1.2. ПОНЯТИЕ ЖИЗНЕННОГО ЦИКЛА ИНФОРМАЦИОННОЙ СИСТЕМЫ

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

ническим системам.

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

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

Крупномасштабные проекты создания программных средств характери-

зуются длительным ЖЦ (10 – 15 лет), в кот

ором на стадию создания (разработки) приходятся только первые 3–4 года, а остальное время эксплуатации созданной системы (стадия сопровождения и развития) распределяется, по оценкам Института программной инженерии (Software Engineering Institute, SEI), примерно поровну на следующие стадии:

• начальную стадию сопровождения, связанную с устранением ошибок

и доработками, возникшими из-за не учтённых или вновь возникши

х требо-

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

• стадию «зрелого» сопровождения, характеризующуюся относитель-

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

− в процессе развития и изменения программного продукта его пер-

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

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

женных при её создании. Например, увеличение числа поддерживаемых в организации платформ или прекращение поддержки аппаратной платформы

ороны поставщика может привести к необходимости переноса ИС в но-

со ст вую среду;

− текучесть кадров приводит к снижению количества специалистов,

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

одуктом;

• стадию эволюции/замены, характеризующуюся достижением систе-

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

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

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

ровождение превратилось в весьма трудоёмкий процесс модификации и

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

Можно выделить следующие виды сопровождения:

• корректирующее – внесение изменений в эксплуатируемый про-

граммный продукт в целях исправления обнаруженных ошибок;

• совершенствующее – повышение производительности и улучшение

эксплуатационных характеристик системы;

• адапт

ирующее – адаптации к изменившейся или изменяющейся среде.

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

Сопровождение коммерческого п

рограммного продукта производится в форме устранения обнаруженных ошибок путём выпуска программных «заплаток» – патчей. Эти программы выкладываются на web-сайте разработчика и предлагаются пользователям. Обновление обычно происходит в автомати-

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

Длительность ЖЦ для различных программных продуктов неодинакова. Для большинства современных программных продуктов длительность ЖЦ измеряется двумя-тремя годами. Хотя достаточно часто встречаются и давно снятые с производства программные продукты.

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

Первый класс составляют относительно небольшие программные средства, создаваемые одиночками или небольшими коллективами (3 – 5) специалистов, которые:

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

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

• не предназначены для массового тиражирования и распространения

как программного продукта на рынке;

• не имеют конкретного независимого заказчика-потребителя, опреде-

ляющего требования к программам и их финансирование;

• не ограничиваются заказчиком допустимой стоимостью, трудоём-

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

• не подлежат независимому тестированию, гарантированию качества

и/или сертификации.

Второй класс составляют крупномасштабные комплексы программ для сложных систем управления и обработки информации, оформляемые в виде программных продуктов с гарантированным качеством, и отличаются следующими особенностями и свойствами их ЖЦ:

• большая размерность, высокая трудоёмкость и стоимость создания

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

• от заказчика, финансирующего проект программного средства, раз-

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

• для организации и координации деятельности специалистов-разра-

ботчиков при наличии единой, крупной целевой задачи, создания и совершенствования п

рограммного продукта необходимы квалифицированные

менеджеры проектов;

• в проектах таких сложных программных средств с множеством раз-

личных функциональных компонентов участвуют специалисты разной квали-

1 / 101 2 3 4 5 6 7 8 9 10 > Следующая >>>

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]