Читайте также:
|
Перечисленные факторы способствовали появлению программных средств специального класса - CASE-средств, реализующих CASE-технологию создания и сопровождения ИС. Термин CASE используется в настоящее время в весьма широком смысле. Первоначальное значение термина CASE, ограниченное вопросами автоматизации разработки только лишь программного обеспечения, в настоящее время приобрело новый смысл, охватывающий процесс разработки сложных ИС в целом. Теперь под термином CASE-средства понимаются программные средства, поддерживающие процессы создания и сопровождения ИС, включая анализ и формулировку требований, проектирование прикладного обеспечения (приложений) и баз данных, генерацию кода, тестирование, документирование, обеспечение качества, конфигурационное управление и управление проектом, а также другие процессы. CASE-средства вместе с системным ПО и техническими средствами образуют полную среду разработки ИС.
В настоящее время CASE-технология представляет собой методологию проектирования ИС, а также набор инструментальных средств, позволяющих в стандартных формах моделировать предметную область, анализировать эту модель на всех этапах разработки и сопровождения ИС. Большинство существующих CASE-средств основано на методологиях структурного (в основном) или объектно-ориентированного анализа и проектирования.
Согласно обзору передовых технологий (Survey of Advanced Technology), составленному фирмой Systems Development Inc. в 1998 г. по результатам анкетирования более 1000 американских фирм, CASE-технология попала в разряд наиболее стабильных информационных технологий (ее использовала половина всех опрошенных пользователей более чем в трети своих проектов, из них 85% завершились успешно). [1]
3. Общие вопросы проектирования информационных систем
3.1. Понятие жизненного цикла программного обеспечения
Одним из базовых понятий методологии проектирования ИС является понятие жизненного цикла ее программного обеспечения (ЖЦ ПО). ЖЦ ПО - это непрерывный процесс, который начинается с момента принятия решения о необходимости его создания и заканчивается в момент его полного изъятия из эксплуатации.
Основным нормативным документом, регламентирующим ЖЦ ПО, является международный стандарт ISO/IEC 12207 [2]. Он определяет структуру ЖЦ, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ПО.
Структура ЖЦ ПО по стандарту ISO/IEC 12207 базируется на трех группах процессов:
Разработка включает в себя все работы по созданию ПО и его компонент в соответствии с заданными требованиями, включая оформление проектной и эксплуатационной документации, подготовку материалов, необходимых для проверки работоспособности и соответствующего качества программных продуктов, материалов, необходимых для организации обучения персонала и т.д. Разработка ПО включает в себя, как правило, анализ, проектирование и реализацию - программирование.
Эксплуатация включает в себя работы по внедрению компонентов ПО в эксплуатацию, в том числе конфигурирование базы данных и рабочих мест пользователей, обеспечение эксплуатационной документацией, проведение обучения персонала и т.д., и непосредственно эксплуатацию, в том числе локализацию проблем и устранение причин их возникновения, модификацию ПО в рамках установленного регламента, подготовку предложений по совершенствованию, развитию и модернизации системы.
Управление проектом связано с вопросами планирования и организации работ, создания коллективов разработчиков и контроля за сроками и качеством выполняемых работ. Техническое и организационное обеспечение проекта включает выбор методов и инструментальных средств для реализации проекта, определение методов описания промежуточных состояний разработки, разработку методов и средств испытаний ПО, обучение персонала и т.п. Обеспечение качества проекта связано с проблемами проверки соответствию требованиям на данном этапе проектирования и тестирования ПО. Проверка позволяет оценить соответствие параметров разработки исходным требованиям. Она частично совпадает с тестированием, которое связано с идентификацией различий между действительными и ожидаемыми результатами и оценкой соответствия характеристик ПО исходным требованиям. В процессе реализации проекта важное место занимают вопросы идентификации, описания и контроля конфигурации отдельных компонентов и всей системы в целом.
Управление конфигурацией является одним из вспомогательных процессов, поддерживающих основные процессы жизненного цикла ПО, прежде всего процессы разработки и сопровождения ПО. При создании проектов сложных ИС, состоящих из многих компонентов, каждый из которых может иметь разновидности или версии, возникает проблема учета их связей и функций, создания унифицированной структуры и обеспечения развития всей системы. Управление конфигурацией позволяет организовать, систематически учитывать и контролировать внесение изменений в ПО на всех стадиях жизненного цикла. Общие принципы и рекомендации конфигурационного учета, планирования и управления конфигурациями ПО отражены в проекте стандарта ISO 12207-2 [2, приложение].
Каждый процесс характеризуется выполнением определенных задач и методами их решения, исходными данными, полученными на предыдущем этапе, и результатами. Результатами анализа, в частности, являются функциональные модели, информационные модели и соответствующие им диаграммы. ЖЦ ПО носит итерационный характер: результаты очередного этапа часто вызывают изменения в проектных решениях, выработанных на более ранних этапах.
3.2. Модели жизненного цикла программного обеспечения
К настоящему времени наибольшее распространение получили следующие две основные модели ЖЦ:
Основной характеристикой каскадной модели является разбиение всей разработки на этапы, причем переход с одного этапа на следующий происходит только после того, как будет полностью завершена работа на текущем (рис. 1). Каждый этап завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков.
Рис. 1. Каскадная схема разработки ПО
Каскадный подход хорошо зарекомендовал себя при построении ИС, для которых в самом начале разработки можно достаточно точно и полно сформулировать все требования. В эту категорию попадают расчетные системы, системы реального времени и другие задачи создания автоматизированных систем. Реальный процесс создания ПО для автоматизированных систем никогда полностью не укладывался в такую жесткую схему. В процессе создания ПО постоянно возникала потребность в возврате к предыдущим этапам и уточнении или пересмотре ранее принятых решений (рис. 2):
Рис. 2. Реальный процесс разработки ПО по каскадной схеме
Основным недостатком каскадного подхода является существенное затягивание сроков выполнения проекта и других работ в периоде ЖЦ. Согласование результатов с пользователями производится только в точках, планируемых после завершения каждого этапа работ. Требования к ИС представлены в виде технического задания и неизменны на все время ее создания. Таким образом, пользователи могут внести свои замечания только после того, как работа над системой будет полностью завершена. В случае неточного изложения требований или их изменения в течение длительного периода создания ПО, пользователи получают систему, не удовлетворяющую их потребностям. Модели (как функциональные, так и информационные) автоматизируемого объекта могут устареть одновременно с их утверждением.
Для преодоления перечисленных проблем была предложена спиральная модель ЖЦ [3] (рис. 3), делающая упор на начальные этапы ЖЦ: анализ и проектирование. На этих этапах реализуемость технических решений проверяется путем создания прототипов. Каждый виток спирали соответствует созданию фрагмента или версии ПО, на нем уточняются цели и характеристики проекта, определяется его качество и планируются работы следующего витка спирали. Таким образом углубляются и последовательно конкретизируются детали проекта и в результате выбирается обоснованный вариант, который доводится до реализации. Разработка итерациями отражает объективно существующий спиральный цикл создания системы. Неполное завершение работ на начальных этапах позволяет переходить на следующий, не дожидаясь полного завершения работы на текущем. При итеративном способе разработки недостающую работу можно будет выполнить на следующей итерации. Главная задача - как можно быстрее показать пользователям системы работоспособный продукт, тем самым активизируя процесс уточнения и дополнения требований. Основная проблема спирального метода – не нарушать временные ограничения на каждый из этапов жизненного цикла. Переход осуществляется в соответствии с планом, даже если не вся запланированная работа закончена. План составляется на основе опыта, полученного в предыдущих проектах.
Рис 3. Спиральная модель ЖЦ
3.3. Технологии проектирования информационных систем
Технология проектирования определяется как совокупность трех составляющих:
Технологические инструкции, составляющие основное содержание технологии, должны состоять из описания последовательности технологических операций, условий, в зависимости от которых выполняется та или иная операция, и описаний самих операций.
Технология проектирования, разработки и сопровождения ИС должна удовлетворять следующим общим требованиям:
Реальное применение любой технологии проектирования, разработки и сопровождения ИС в конкретной организации и конкретном проекте невозможно без выработки ряда стандартов (правил, соглашений), которые должны соблюдаться всеми участниками проекта. К таким стандартам относятся следующие [1]:
Стандарт проектирования должен устанавливать [1]:
Стандарт оформления проектной документации должен устанавливать [1]:
Стандарт интерфейса пользователя должен устанавливать [1]:
4. Структурный подход к проектированию информационных систем
4.1. Сущность структурного подхода
Сущность структурного подхода к разработке ИС заключается в ее разбиении на подсистемы, выполняющие отдельные функции, которые в свою очередь делятся на подфункции, подразделяемые на задачи и так далее. Процесс разбиения (декомпозиции) продолжается вплоть до отдельных процедур. При разработке системы "снизу-вверх", то есть от отдельных задач ко всей системе, целостность теряется, возникают проблемы из-за нехватки информации для “стыковки” отдельных компонентов.
Все наиболее распространенные методологии структурного подхода [4,5,6,7] базируются на ряде общих принципов [8]. В качестве двух базовых принципов используются следующие:
В структурном анализе используются две группы средств, иллюстрирующих:
· функции, выполняемые системой;
· отношения между данными.
Каждой группе средств соответствуют определенные виды диаграмм, наиболее распространенными среди которых являются следующие:
Перечисленные диаграммы применяются для существующих и вновь разрабатываемых ИС. Состав диаграмм в каждом конкретном случае зависит от необходимой полноты описания системы.
Рассмотрим более подробно виды диаграмм (упомянутые выше).
4.2. Методология функционального моделирования SADT
Методология SADT разработана Дугласом Россом и получила дальнейшее развитие в работе [9]. На ее основе разработана известная методология IDEF0 (Icam DEFinition), которая является основной частью программы “Интеграция компьютерных и промышленных технологий”, проводимой по инициативе ВВС США.
Методология SADT представляет собой совокупность методов, правил и процедур, предназначенных для построения функциональной модели объекта какой-либо предметной области. Функциональная модель SADT отображает функциональную структуру объекта, т.е. производимые им действия и связи между этими действиями.
Основные элементы этой методологии основываются на следующих положениях [1]:
Правила SADT включают [1]:
Методология SADT может использоваться для моделирования широкого круга систем и определения требований и функций разрабатываемой системы. Для существующих систем SADT может быть использована для анализа функций, выполняемых системой, а также для указания механизмов, посредством которых они осуществляются.
4.2.1. Состав функциональной модели
Результатом применения методологии SADT является модель, которая состоит из диаграмм, фрагментов текстов и глоссария, имеющих ссылки друг на друга. Диаграммы - главные компоненты модели, все функции ИС и связи представлены как блоки и дуги. Место соединения дуги с блоком определяет тип связи. Управляющая информация входит в блок сверху, в то время как информация, которая подвергается обработке, показана с левой стороны блока, а результаты выхода показаны с правой стороны. Механизм (человек или автоматизированная система), который осуществляет операцию, представляется дугой, входящей в блок снизу (рис. 4).
Рис. 4. Функциональный блок (контекстная диаграмма)
Одной из наиболее важных особенностей методологии SADT является постепенное введение все больших уровней детализации по мере создания диаграмм, отображающих модель.
4.2.2. Иерархия диаграмм
Построение SADT-модели начинается с представления всей системы в виде одного блока и дуг, изображающих связи с функциями вне системы. Поскольку единственный блок представляет всю систему как единое целое, имя, указанное в блоке, является общим. Это верно и для дуг-связей - они также представляют полный набор внешних связей системы.
Затем блок, который представляет систему в качестве единого модуля, детализируется на другой диаграмме с помощью нескольких блоков, соединенных дугами. Эти блоки представляют основные подфункции исходной функции. Данная декомпозиция выявляет полный набор подфункций, каждая из которых представлена как блок, границы которого определены дугами. Каждая из этих подфункций может быть декомпозирована подобным образом для более детального представления.
Во всех случаях каждая подфункция может содержать только те элементы, которые входят в исходную функцию. Кроме того, модель не может опустить какие-либо элементы, т.е. родительский блок и его связи обеспечивают область “действия” диаграммы. К нему нельзя ничего добавить, и из него не может быть ничего удалено. [1]
Модель SADT представляет собой серию диаграмм с сопроводительной документацией, разбивающих сложный объект на составные части, которые представлены в виде блоков. Детали каждого из основных блоков показаны в виде блоков на других диаграммах. Каждая детальная диаграмма является декомпозицией блока из более общей диаграммы. На каждом шаге декомпозиции более общая диаграмма называется родительской для более детальной диаграммы.
Дуги, входящие в блок и выходящие из него на диаграмме верхнего уровня (родительской диаграмме), являются точно теми же самыми, что и дуги, входящие в диаграмму нижнего уровня и выходящие из нее, потому что блок и диаграмма представляют одну и ту же часть системы.
Некоторые дуги присоединены к блокам диаграммы обоими концами, у других же один конец остается неприсоединенным. Неприсоединенные дуги соответствуют входам, управлениям и выходам родительского блока. Источник или получатель этих дуг может быть обнаружен только на родительской диаграмме. Неприсоединенные концы должны соответствовать дугам на исходной диаграмме. Все дуги, выходящие за диаграмму данного уровня, должны продолжаться на родительской диаграмме, чтобы она была полной и непротиворечивой.
На SADT-диаграммах явно не указаны ни последовательность, ни время. Обратные связи, итерации, продолжающиеся процессы и перекрывающиеся (по времени) функции могут быть изображены с помощью дуг. Обратные связи могут выступать в виде комментариев, замечаний, исправлений и т.д. (рис. 5).
Рис. 5. Пример обратной связи
4.3. Моделирование потоков данных
В основе данной методологии (методологии Gane/Sarson [7]) лежит построение модели анализируемой ИС – проектируемой или реально существующей. В соответствии с методологией модель системы определяется как иерархия диаграмм потоков данных (ДПД или DFD), описывающих несвязанный по времени процесс преобразования информации от ее ввода в систему до выдачи пользователю. Диаграммы верхних уровней иерархии (контекстные диаграммы) определяют основные процессы или подсистемы ИС с внешними входами и выходами. Они детализируются при помощи диаграмм нижнего уровня. Такая декомпозиция продолжается, создавая многоуровневую иерархию диаграмм, до тех пор, пока не будет достигнут такой уровень декомпозиции, на котором процессы становятся элементарными и детализировать их далее невозможно.
Источники информации, которые являются в данной нотации внешними сущностями, порождают информационные потоки (потоки данных), переносящие информацию к подсистемам или процессам. Те в свою очередь преобразуют информацию и порождают новые потоки, которые переносят информацию к другим процессам или подсистемам, накопителям данных или внешним сущностям - потребителям информации. Таким образом, основными компонентами диаграмм потоков данных являются:
Рассмотрим схематическое изображение данных компонент диаграмм и их свойства.
4.3.1. Внешние сущности
Внешняя сущность представляет собой материальный предмет или физическое лицо, представляющее собой источник или приемник информации, например, заказчики, персонал, поставщики, клиенты, склад. Определение некоторого объекта или системы в качестве внешней сущности указывает на то, что она находится за пределами границ анализируемой ИС. В процессе анализа некоторые внешние сущности могут быть перенесены внутрь диаграммы анализируемой ИС, если это необходимо, или, наоборот, часть процессов ИС может быть вынесена за пределы диаграммы и представлена как внешняя сущность.
Внешняя сущность обозначается квадратом (рис. 6).
Рис. 6. Внешняя сущность
Дата добавления: 2015-09-04; просмотров: 72 | Нарушение авторских прав
| <== предыдущая страница | | | следующая страница ==> |
| Локальная сеть | | | Системы и подсистемы |