Проектирование информационной системы средствами case технологий. Курсовая работа: CASE-технологии проектирования автоматизированных информационных систем

Федеральное агентство по образованию

Федеральное государственное образовательное учреждение Высшего профессионального образования «Чувашский государственный университет им. И.Н.Ульянова»

Финансово - экономический институт

Экономический факультет

Реферат на тему: CASE-технологии проектирования автоматизированных информационных систем

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

Группы ЭК 22-06

Евграфова И.А

Проверила: Павлова С.Ю.

Чебоксары 2007

· Введение……………………………………………………………..3

· Жизненный цикл программного обеспечения информационной системы……………………………………………………………….5

· RAD-технологии прототипного создания приложений…………...7

· Структурный метод разработки программного обеспечения……10

· Использованная литература………………………………………..17

Введение

За последнее десятилетие сформировалось новое направ­ление в программотехнике - CASE (Computer-Aided Software/System Engineering) - в дословном переводе - разработка программного обеспечения информационных сис­тем при поддержке (с помощью) компьютера. В настоящее время не существует общепринятого определения CASE, тер­мин CASE используется в весьма широком смысле. Первона­чальное значение термина CASE, ограниченное вопросами автоматизации разработки только лишь программного обес­печения, в настоящее время приобрело новый смысл, охва­тывающий процесс разработки сложных автоматизированных информационных систем в целом. Теперь под термином CASE-средства понимаются программные средства, поддерживаю­щие процессы создания и сопровождения ИС, включая анализ и формулировку требований, проектирование приклад­ного ПО (приложений) и баз данных, генерацию кода, тести­рование, документирование, обеспечение качества, конфи­гурационное управление и управление проектом, а также другие процессы. CASE-средства вместе с системным ПО и техническими средствами образуют полную среду раз­работки АИС.

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

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

♦ разработка системного и управляющего ПО. Активное применение CASE-технологий связано с большой слож­ностью данной проблематики и со стремлением повы­сить эффективность работ.

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

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

♦ улучшают качество создаваемого ПО за счет средств автоматического контроля (прежде всего контроля про­екта);

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

♦ ускоряют процесс проектирования и разработки;

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

♦ поддерживают развитие и сопровождение разработки;

♦ поддерживают технологии повторного использования компонента разработки.

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

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

1. Жизненный цикл программного обеспечения информационной системы

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

Структура ЖЦ ПО базируется на трех группах процес­сов:

♦ основные процессы ЖЦ ПО (приобретение, поставка, разработка, эксплуатация, сопровождение);

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

♦ организационные процессы (управление проектами, создание инфраструктуры проекта, определение, оцен­ка и улучшение самого ЖЦ, обучение).

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

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

Управление проектом связано с вопросами планирова­ния и организации работ, создания коллективов разработчи­ков и контроля за сроками и качеством выполняемых работ.

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

Управление конфигурацией является одним из вспомо­гательных процессов, поддерживающих основные процессы жизненного цикла ПО, прежде всего процессы разработки и сопровождения ПО. При создании проектов сложных ИС, со­стоящих из многих компонентов, каждый из которых может иметь разновидности или версии, возникает проблема учета их связей и функций, создания унифицированной структуры и обеспечения развития всей системы. Управление конфигу­рацией позволяет организовывать, систематически учитывать и контролировать внесение изменений в ПО на всех стадиях ЖЦ. Общие принципы и рекомендации конфигурационного учета, планирования и управления конфигурациями ПО от­ражены в проекте стандарта ISO 12207-2.

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

Существующие модели ЖЦ определяют порядок испол­нения этапов в ходе разработки, а также критерии перехода от этапа к этапу. В соответствии с этим наибольшее распрос­транение получили три следующие модели ЖЦ:

♦ каскадная модель (1970-1980 гг.) - предлагает пере­ход на следующий этап после полного окончания работ по предыдущему этапу;

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

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

Специалистами отмечаются следующие преимущества спиральной модели:

♦ накопление и повторное использование программных средств, моделей и прототипов;

♦ ориентация на развитие и модификацию ПО в процес­се его проектирования;

♦ анализ риска и издержек в процессе проектирования.

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

2. RAD -технологии прототипного создания приложений

Одним из возможных подходов к разработке ПО в рам­ках спиральной модели ЖЦ является получившая в после­днее время широкое распространение методология быстрой разработки приложений RAD (Rapid Application Development). Под этим термином обычно понимается процесс разработки ПО, содержащий три элемента:

♦ небольшую команду программистов (от 2 до 10 чело­век);

♦ короткий, но тщательно проработанный производствен­ный график (от 2 до б мес);

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

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

Жизненный цикл ПО по методологии RAD состоит из четырех фаз:

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

♦ фазы проектирования;

♦ фазы построения;

♦ фазы внедрения.

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

На фазе проектирования часть пользователей принимает участие в техническом проектировании системы под руко­водством специалистов-разработчиков. CASE-средства исполь­зуются для быстрого получения работающих прототипов при­ложений. Пользователи, непосредственно взаимодействуя с ними, уточняют и дополняют требования к системе, которые не были выявлены на предыдущей фазе. Более подробно рас­сматриваются процессы системы. Анализируется и при необ­ходимости корректируется функциональная модель. Каждый процесс рассматривается детально. При необходимости для каждого элементарного процесса создается частичный про­тотип: экран, диалог, отчет, устраняющий неясности или неоднозначности. Определяются требования разграничения доступа к данным. На этой же фазе происходит определение набора необходимой документации.

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

♦ общая информационная модель системы;

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

♦ точно определенные с помощью CASE-средства интер­фейсы между автономно разрабатываемыми подсисте­мами;

♦ построенные прототипы экранов, отчетов, диалогов.

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

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

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

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

♦ определяется необходимость распределения данных;

♦ производится анализ использования данных;

♦ производится физическое проектирование базы дан­ных;

♦ определяются требования к аппаратным ресурсам;

♦ определяются способы увеличения производительности;

♦ завершается разработка документации проекта. Результатом фазы является готовая система, удовлетво­ряющая всем согласованным требованиям.

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

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

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

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

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

♦ разработка приложений итерациями;

♦ необязательность полного завершения работ на каж­дом из этапов жизненного цикла;

♦ обязательное вовлечение пользователей в процесс раз­работки АИС;

♦ необходимое применение CASE-средств, обеспечива­ющих целостность проекта;

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

♦ необходимое использование генераторов кода;

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

♦ тестирование и развитие проекта, осуществляемые одновременно с разработкой;

♦ ведение разработки немногочисленной хорошо управ­ляемой командой профессионалов;

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

3. Структурный метод разработки программного обеспечения

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

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

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

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

2. Принцип формализации - заключается в необходимо­сти строгого методического подхода к решению проблемы.

3. Принцип «упрятывания» - заключается в упрятыва­нии несущественной на конкретном этапе информации: каж­дая часть «знает» только необходимую ей информацию.

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

5. Принцип полноты - заключается в контроле присут­ствия лишних элементов.

6. Принцип непротиворечивости - заключается в обо­снованности и согласованности элементов.

7. Принцип логической независимости - заключается в концентрации внимания на логическом проектировании для обеспечения независимости от физического проектирования.

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

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

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

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

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

♦ SADT (Structured Analysis and Design Technique) - модели и соответствующие функциональные диаграм­мы;

♦ DFD (Data Flow Diagrams) - диаграммы потоков дан­ных;

♦ ERD (Entity-Relationship Diagrams) - диаграммы«сущ-ность-связь»;

♦ STD (State Trasition Diagrams) - диаграммы переходов состояний.

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

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

Методология SADT

Методология SADT разработана Дугласом Россом, на ее основе разработана, в частности, известная методология IDEFO (Icam Definition), которая является основной частью программы Icam (Интеграция компьютерных и промышлен­ных технологий), проводимой по инициативе США. Методо­логия SADT представляет собой совокупность методов, пра­вил и процедур, предназначенных для построения функцио­нальной модели объекта какой-либо предметной области. Фун­кциональная модель SADT отображает функциональную структуру объекта, т. е. производимые им действия и связи между этими действиями. Основные элементы этой методо­логии основываются на следующих концепциях:

♦ графическое представление блочного моделирования. Графика блоков и дуг SADT-диаграммы отображает функцию в виде блока, а интерфейсы входа/выхода представляются дугами, соответственно входящими в блок и выходящими из него. Взаимодействие блоков друг с другом описывается посредством интерфейсных дуг, выражающих «ограничения», которые, в свою очередь, определяют, когда и каким образом функции выполня­ются и управляются;

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

Правила SADT включают:

♦ ограничение количества блоков на каждом уровне де­композиции (правило 3-б блоков);

♦ связность диаграмм (номера блоков);

♦ уникальность меток и наименований (отсутствие по­вторяющихся имен);

♦ синтаксические правила для графики (блоков и дуг);

♦ разделение входов и управлений (правило определе­ния роли данных);

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

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

Результатом применения методологии SADT является модель, которая состоит из диаграмм, фрагментов текстов и глоссария, имеющих ссылки друг на друга. Диаграммы - глав­ные компоненты модели, все функции ИС и интерфейсы на них представлены как блоки и дуги. Место соединения дуги с блоком определяет тип интерфейса. Управляющая информа­ция входит в блок сверху, в то время как информация, кото­рая подвергается обработке, показана с левой стороны блока, а результаты выхода показаны с правой стороны. Механизм (человек или автоматизированная система), который осуще­ствляет операцию, представляется дугой, входящей в блок снизу (рис. 1.6.1).

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

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

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

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

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

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

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

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

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

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

Моделирование потоков данных (процессов)

Основным средством моделирования функциональных требований АИС являются диаграммы потоков данных (DFD:- Data Flow Diagrams). С их помощью эти требования разбива­ются на функциональные компоненты (процессы) и представ­ляются в виде сети, связанной потоками данных. Главная цель таких средств - продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также вы­явить отношения между этими процессами.

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

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

♦ внешние сущности;

♦ системы/подсистемы;

♦ процессы;

♦ накопители данных;

♦ потоки данных.

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

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

♦ «Ввести сведения о клиентах»;

♦ «Выдать информацию о текущих расходах»;

♦ «Проверить кредитоспособность клиента».

Использование таких глаголов, как «обработать»,«модер­низировать» или «отредактировать» означает, как правило, недостаточно глубокое понимание данного процесса и требу­ет дальнейшего анализа.

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

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

Накопитель данных может быть реализован физически в виде микрофиши, ящика в картотеке, таблицы в оператив­ной памяти, файла на магнитном носителе и т. д. Накопитель данных идентифицируется буквой «D» и произвольным чис­лом. Имя накопителя выбирается из соображения наиболь­шей информативности для проектировщика.

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

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

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

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

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

После построения контекстных диаграмм полученную модель следует проверить на полноту исходных данных об объектах системы и изолированность объектов (отсутствие информационных связей с другими объектами). Для каждой подсистемы, присутствующей на контекстных диаграммах, выполняется ее детализация при помощи DFD. Каждый про­цесс на DFD, в свою очередь, может быть детализирован при помощи DFD или миниспецификации. При детализации долж­ны выполняться следующие правила:

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

♦ правило нумерации - означает, что при детализации процессов должна поддерживаться их иерархическая нумерация. Например, процессы, детализирующие процесс с номером 12, получают номера 12.1, 12.2, 12.3 и т. д.

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

Миниспецификация является конечной вершиной иерар­хии DFD. Решение о завершении детализации процесса и использовании миниспецификации принимается аналитиком, исходя из следующих критериев:

♦ наличия у процесса относительно небольшого количе­ства входных и выходных потоков данных (2-3 пото­ка);

♦ возможности описания преобразования данных процес­сом в виде последовательного алгоритма;

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

♦ возможности описания логики процесса при помощи миниспецификации небольшого объема (не более 20- 30 строк).

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

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

Моделирование данных

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

Наиболее распространенным средством моделирования данных являются диаграммы «сущность-связь» (ERD). С их помощью определяются важные для предметной области объекты (сущности), их свойства (атрибуты) и отношения друг с другом (связи). ERD непосредственно используются для про­ектирования реляционных баз данных (см. подразд. 2.2).

Нотация ERD была впервые введена П. Ченом (P. Chen) и получила дальнейшее развитие в работах Баркера.

Методология IDEF 1

Метод IDEF1, разработанный Т. Рэмеем (Т. Ramey), так­же основан на подходе П. Чена и позволяет построить модель данных, эквивалентную реляционной модели в третьей нор­мальной форме. В настоящее время на основе совершенство­вания методологии IDEF1 создана ее новая версия - методо­логия IDEF1X. IDEF1X разработана с учетом таких требова­ний, как простота изучения и возможность автоматизации. IDEF IX-диаграммы используются рядом распространенных CASE-средств (в частности, ERWin, Design/IDEF).

Использованная литература

· Федотова Д.Э. CASE – технологии: учебник – М: Горячая линия – Телеком, 2007

· Трофимов В.Е., Лобачева И.Н. Информационные системы в экономике – М: Юнити-Дана, 2008

· Балдин Н.В., Уткин В.Б. Информационные системы и технологии в экономике – М: Юнити, 2007

· Титоренко Т.А. Автоматизированные информационные технологии в экономике – М: Юнити, 2006

· Барановская Т.П., Лойко В.И., Семенов М.И., Трубилин И.Т. Автоматизированные информационные технологии в экономике – М: Финансы и статистика, 2006

12 и 13 октября прошел форум РИФ-Воронеж 2018. За два дня на мероприятии зарегистрировалось 4600 человек. Еще 3700 человек посмотрели онлайн-трансляцию. Перед аудиторией выступили более ста спикеров, актуальные темы сферы информационных технологий обсудили в формате презентаций и дискуссий. В первый день форума подвели итоги региональной интернет-премии. А завершилась деловая программа финалом первого студенческого IT-чемпионата по решению кейсов в области digital-технологий, проектирования и онлайн-коммуникации в Центральном Черноземье. Победителем стала команда ВГТУ. Чемпионат организован совместно с проектом Стажировка.ру.

В отборочном туре чемпионата IT-Generation приняли участие 30 команд из Воронежа, Курска, Липецка, Орла, Брянска, Санкт-Петербурга, Москвы, Самары, Алматы. Самый младший участник чемпионата - ученик 8 класса школы (он вошел в состав студенческой команды). В финале свои работы защищали 10 команд. Ребята решали реальные задачи, с которыми программисты сталкиваются в своей работе.

Для каждого кейса компании определили лучшее решение:

· Кейс компании DSR (разработка корпоративного мобильного приложения) - команда ВГТУ (Воронеж)

· Кейс компании Atos (доработка корпоративной информационной системы) - команда БГИТУ (Брянск)

· Кейс компании Dr.Web (поиск скрытого майнера в корпоративной сети) - команда ВГУ (Воронеж)

Также же эксперты выбрали победителя всего чемпионата, им стала команда ВГТУ! Победителей пригласили на стажировку в компании.

Итоги форума

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

Новое развитие получила на форуме тема digital-коммуникаций, доклады спикеров о тенденциях, контенте и продвижении в соцстеях, видеомаркетинге, личном брендинге прошли при полных залах. Максимально широко была представлена тема web-дизайна. Впервые в Воронеже прошла мини-конференция с участием спикеров Baltic Digital Days, эксперты говорили о поисковом продвижении сайтов и управлении репутацией в сети интернет.

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

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

Экспертами РИФ-Воронеж в 2018 году стали представители топовых IT-компаний: Mozilla Foundation, ВКонтакте, Яндекс, Mail.Ru Group, Rambler&Co, T-Systems, Ingate, Seopult, «НЛМК-Информационные технологии», «Северсталь-инфоком» и других.

Как всегда, все мероприятия ежегодного форума были бесплатными. Организаторы форума: Агентство инноваций и развития экономических и социальных проектов, Департамент экономического развития Воронежской области, Рекомендательный проект «LikenGo!», при поддержке Российской ассоциации электронных коммуникаций. Генеральным партнером форума стала авиакомпания Turkish Airlines.

О форуме:

Региональный интернет-форум (РИФ) проходит в Воронеже с 2009 года. В 2013 году мероприятие получило поддержку областного казенного учреждения «Агентство инноваций и развития экономических и социальных проектов» и департамента экономического развития Воронежской области, подтвердив статус значимого для региона события. В рамках «РИФ-Воронеж» также проходит интернет-премия, основные задачи которой - содействие развитию интернет-технологий на территории региона и демонстрация ярких проектов рынка.

Организаторы РИФ в 2018 году:

Областное казенное учреждение «Агентство инноваций и развития экономических и социальных проектов» www.innoros.ru

Департамент экономического развития Воронежской области www.econom.govvrn.ru

При поддержке:

Министерства цифрового развития, связи и массовых коммуникаций Российской Федерации, www.minsvyaz.ru
Российской ассоциации электронных коммуникаций,

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

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

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

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

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

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

улучшают качество создаваемых ИС за счет средств автоматического контроля (прежде всего контроля проекта);

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

ускоряют процесс проектирования и разработки;

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

поддерживают развитие и сопровождение разработки;

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

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

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

^

CASE-технологии проектирования информационных систем

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

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

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

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

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

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

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

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

Характеристика современных CASE-средств

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

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

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

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

• 
  мощными графическими средствами для описания и документирования ИС, обеспечивающими удобный интерфейс с разработчиком и развивающими его твор-ческие возможности;
• 
  интеграцией отдельных компонент CASE-средств, обеспечивающей управляемость процессом разработки ИС;
• 
  использованием специальным образом организованного хранилища проектных метаданных (репозитория). Интегрированное CASE-средство (или комплекс средств, поддерживающих полный ЖЦ ИС) содержит следующие компоненты:
• 
  репозиторий, являющийся основой CASE-средства. Он должен обеспечивать хранение версий проекта и его отдельных компонентов, синхронизацию поступления информации от различных разработчиков при групповой разработке, контроль метаданных на полноту и непротиворечивость;
• 
  графические средства анализа и проектирования, обеспечивающие создание и редактирование иерархичес-ки связанных диаграмм (DFD, ERD и др.), образующих модели ИС;
• 
  средства разработки приложений, включая языки 4GL и генераторы кодов;
• 
  средства конфигурационного управления;
• 
  средства документирования;
• 
  средства тестирования;
• 
  средства управления проектом;
• 
  средства реинжиниринга.

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

• 
  применяемым методологиям и моделям систем и БД;
• 
  степени интегрированности с СУБД;
• 
  доступным платформам.

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

• 
  средства анализа (Upper CASE), предназначенные для построения и анализа моделей предметной области (Design/IDEF (Meta Software), BPWin (Logic Works));
• 
  средства анализа и проектирований (Middle CASE), поддерживающие наиболее распространенные методологии проектирования и использующиеся для создания проектных спецификаций (Vantage Team Builder (Cayenne), Designer/2000 (Oracle), Silverrun (CSA), PRO-IV (McDonnell Douglas), CASE. Аналитик (Макро-Проджект)). Выходом таких средств являются специ-фикации компонентов и интерфейсов системы, архитектуры системы, алгоритмов и структур данных;
• 
  средства проектирования баз данных , обеспечивающие моделирование данных и генерацию схем баз данных (как правило, на языке SQL) для наиболее рас-пространенных СУБД. К ним относятся ERwin (Logic Works). S-Designor (SDP) и DataBase Designer (Oracle). Средства проектирования баз данных имеются также в составе CASE-средств Vantage Team Builder, Designer/2000, Silverrun и PRO-IV;
• 
  средства разработки приложений . К ним относятся средства 4GL (Uniface (Compuware), JAM (JYACC), PowerBuilder (Sybase), Developer/2000 (Oracle), New Era (Informix), SQL Windows (Gupta), Delphi (Borland) и др.) и генераторы кодов, входящие в состав Vantage Team Builder, PRO-IV и частично - в Silverrun;
• 
  средства реинжиниринга , обеспечивающие анализ про-граммных кодов и схем баз данных и формирование на их основе различных моделей и проектных специфи-каций. Средства анализа схем БД и формирования ERD входят в состав Vantage Team Builder, PRO-IV, Silverrun, Designer/2000, ERwin и S-Designor. В области анализа программных кодов наибольшее распространение получают объектно-ориентированные CASE-средства, обеспечивающие реинжиниринг программ на языке C++ (Rational Rose (Rational Software), Object Team (Cayenne)). Вспомогательные типы включают:
• 
  средства планирования и управления проектом (SE Companion, Microsoft Project и др.);
• 
  средства конфигурационного управления (PVCS (Intersolv));
• 
  средства тестирования (Quality Works (Segue Software));
• 
  средства документирования (SoDA (Rational Software)).

На сегодняшний день российский рынок программного обеспечения располагает следующими наиболее развитыми CASE-средствами:

• 
  Silverrun;
• 
  Designer/2000;
• 
  Vantage Team Builder (Westmount I-CASE);
• 
  ERwin+BPwin;
• 
  S-Designor;
• 
  CASE-Аналитик.

Кроме того, на рынке постоянно появляются как новые для отечественных пользователей системы (например, CASE/ 4/0, PRO-IV, System Architect, Visible Analyst Workbench, EasyCASE), так и новые версии и модификации перечислен-ных систем.

Охарактеризуем основные возможности CASE-средств на примере имеющей широкое распространение системы Silverrun.

CASE-средство Silverrun американской фирмы Computer Systems Advisers, Inc. (CSA) используется для анализа и про-ектирования ИС бизнес-класса и ориентировано в большей степени на спиральную модель ЖЦ. Оно применимо для поддержки любой методологии, основанной на раздельном построении функциональной и информационной моделей (диаграмм потоков данных и диаграмм "сущность-связь").

Настройка на конкретную методологию обеспечивается выбором требуемой графической нотации моделей и набора правил проверки проектных спецификаций. В системе имеются готовые настройки для наиболее распространенных методологий: DATARUN (основная методология, поддерживае-мая Silverrun), Gane/Sarson, Yourdon/DeMarco, Merise, Ward/Mellor, Information Engineering. Для каждого понятия, введенного в проекте, имеется возможность добавления собственных описателей. Архитектура Silverrun позволяет наращивать среду разработки по мере необходимости.

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

Модуль построения моделей бизнес-процессов в форме диаграмм потоков данных (ВРМ - Business Process Modeler) позволяет моделировать функционирование обследуемой организации или создаваемой ИС. В модуле ВРМ обеспечена возможность работы с моделями большой сложности: автома-тическая перенумерация, работа с деревом процессов (вклю-чая визуальное перетаскивание ветвей), отсоединение и при-соединение частей модели для коллективной разработки. Диаграммы могут изображаться в нескольких предопределенных нотациях, включая Yourdon/DeMarco и Gane/Sarson. Имеется также возможность создавать собственные нотации, в том числе добавлять в число изображаемых на схеме дескрипторов определенные пользователем поля.

Модуль концептуального моделирования данных (ERX - Entity-Relationship eXpert) обеспечивает построение моделей данных "сущность-связь", не привязанных к конкретной реализации. Этот модуль имеет встроенную экспертную систему, позволяющую создать корректную нормализованную модель данных посредством ответов на содержательные вопросы о взаимосвязи данных. Возможно автоматическое построение модели данных из описаний структур данных. Анализ функциональных зависимостей атрибутов дает возможность проверить соответствие модели требованиям третьей нормальной формы и обеспечить их выполнение. Проверенная модель передается в модуль RDM.

Модуль реляционного моделирования (RDM- Relational Data Modeler) позволяет создавать детализированные модели "сущность-связь", предназначенные для реализации в ре-ляционной базе данных. В этом модуле документируются все конструкции, связанные с построением базы данных: индексы, триггеры, хранимые процедуры и т. д. Гибкая изменяемая нотация и расширяемость репозитория позволяют работать по любой методологии. Возможность создавать подсхемы соответствует подходу ANSI SPARC к представлению схемы базы данных . На языке подсхем моделируются как узлы распределенной обработки, так и пользовательские представле-ния. Этот модуль обеспечивает проектирование и полное документирование реляционных баз данных.

^ Менеджер репозитория рабочей группы (WRM - Workgroup Repository Manager) применяется как словарь данных для хранения общей для всех моделей информации, а также обеспечивает интеграцию модулей Silverrun в единую среду проектирования.

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

Для автоматической генерации схем баз данных у Silverrun существуют мосты к наиболее распространенным СУБД: Oracle, Informix, DB2, Ingres, Progress, SQL Server, SQLBase, Sybase. Для передачи данных в средства разработки приложений имеются мосты к языкам 4GL: JAM, PowerBuilder, SQL Windows, Uniface, NewEra, Delphi. Все мосты позволяют загрузить в Silverrun RDM информацию из каталогов соответствующих СУБД или языков 4GL. Это позволяет доку-ментировать, перепроектировать или переносить на новые платформы уже находящиеся в эксплуатации базы данных и прикладные системы. При использовании моста Silverrun расширяет свой внутренний репозиторий специфичными для целевой системы атрибутами. После определения значений этих атрибутов генератор приложений переносит их во внутренний каталог среды разработки или использует при генерации кода на языке SQL. Таким образом, можно полностью определить ядро базы данных с использованием всех воз-можностей конкретной СУБД: триггеров, хранимых процедур, ограничений ссылочной целостности. При создании приложения на языке 4GL данные, перенесенные из репозитория Silverrun, используются либо для автоматической генерации интерфейсных объектов, либо для быстрого их создания вручную.

Для обмена данными с другими средствами автоматиза-ции проектирования, создания специализированных проце-дур анализа и проверки проектных спецификаций, составле-ния специализированных отчетов в соответствии с различными стандартами в системе Silverrun имеются три способа выдачи проектной информации во внешние файлы:

• 
  система отчетов. Можно, определив содержимое отчета по репозиторию, выдать отчет в текстовый файл. Этот файл можно затем загрузить в текстовый редак-тор или включить в другой отчет;
• 
  система экспорта/импорта. Для более полного контро-ля над структурой файлов в системе экспорта/импор-та имеется возможность определять не только содержимое экспортного файла, но и разделители записей, полей в записях, маркеры начала и конца текстовых полей. Файлы с указанной структурой можно не толь-ко формировать, но и загружать в репозитории. Это дает возможность обмениваться данными с различны-ми системами: другими CASE-средствами, СУБД, тек-стовыми редакторами и электронными таблицами;
• 
  хранение репозитория во внешних файлах через ODBC-драйверы. Для доступа к данным репозитория из наиболее распространенных систем управления базами данных обеспечена возможность хранить всю проектную информацию непосредственно в формате этих СУБД.

Групповая работа поддерживается в системе Silverrun двумя способами:

• 
  в стандартной однопользовательской версии имеется механизм контролируемого разделения и слияния моделей. Разделив модель на части, можно раздать их нескольким разработчикам. После детальной доработки модели объединяются в единые спецификации;
• 
  сетевая версия Silverrun позволяет осуществлять одно-временную групповую работу с моделями, хранящи-мися в сетевом репозитории на базе СУБД Oracle, Sybase или Informix. При этом несколько разработчи-ков могут работать с одной и той же моделью, так как блокировка объектов происходит на уровне отдельных элементов модели.

Имеются реализации Silverrun трех платформ - MS Windows, Macintosh и OS/2 Presentation Manager – с возможностью обмена проектными данными между ними.

Помимо системы Silverrun, укажем назначение и дру-гих популярных CASE-средств и их групп.

Vantage Team Builder представляет собой интегрирован-ный программный продукт, ориентированный на реализацию каскадной модели ЖЦ ИС и поддержку полного ЖЦ ИС.

Uniface 6.1 – продукт фирмы Compuware (США) - представляет собой среду разработки крупномасштабных прило-жений в архитектуре "клиент-сервер".

CASE-средство Designer/2000 2.0 фирмы Oracle является интегрированным CASE-средством, обеспечивающим в со-вокупности со средствами разработки приложений Developer/ 2000 поддержку полного ЖЦ ИС для систем, использующих СУБД Oracle.

Пакет CASE/4/0 (microTOOL GmbH), включающий структурные средства системного анализа, проектирования и программирования, обеспечивает поддержку всего жизненного цикла разработки (вплоть до сопровождения), на основе сете-вого репозитория, контролирующего целостность проекта и поддерживающего согласованную работу всех его участников (системных аналитиков, проектировщиков, программистов).
^

Локальные средства

Пакет ERWin (Logic Works) используется при моделировании и создании баз данных произвольной сложности на ос-нове диаграмм "сущность-связь". В настоящее время ERWin является наиболее популярным пакетом моделирований дан-ных благодаря поддержке широкого спектра СУБД самых различных классов - SQL-серверов (Oracle, Informix, Sybase SQL Server, MS SQL Server, Progress, DB2, SQLBase, Ingress, Rdb и др.) и "настольных" СУБД типа xBase (Clipper, dBase, FoxPro, MS Access, Paradox и др.).

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

S-Designer 4.2 (Sybase/Powersoft) представляет собой CASE-средство для проектирования реляционных баз данных. По своим функциональным возможностям и стоимости он близок к CASE-средству ERWin, отличаясь внешне ис-пользуемой на диаграммах нотацией. S-Designer реализует стандартную методологию моделирования данных и генери-рует описание БД для таких СУБД, как Oracle, Informix, Ingres, Sybase, DB2, Microsoft SQL Server и др.

CASE-Аналитик 1.1 (Эйтекс) является практически един-ственным в настоящее время конкурентоспособным отече-ственным CASE-средством функционального моделирования и реализует построение диаграмм потоков данных в соответ-ствии с описанной ранее методологией.
^

Объектно-ориентированные CASE-средства

Rational Rose - CASE-средство фирмы Rational Software Corporation (США) - предназначено для автоматизации этапов анализа и проектирования ИС, а также для генерации кодов на различных языках и выпуска проектной документа-ции. Rational Rose использует синтез-методологию объектно-ориентированного анализа и проектирования, основанную на подходах трех ведущих специалистов в данной области: Буча, Рамбо и Джекобсона. Разработанная ими универсальная нотация для моделирования объектов (язык UML - Unified Modeling Language) является в настоящее время и, очевид-но, останется в будущем общепринятым стандартом в области объектно-ориентированного анализа и проектирования. Конкретный вариант Rational Rose определяется языком, на котором генерируются коды программ (C++, Smalltalk, PowerBuilder, Ada, SQLWindows и ObjectPro). Основной вариант – Rational Rose/C++ - позволяет разрабатывать проектную документацию в виде диаграмм и спецификаций, а также генерировать программные коды на C++. Кроме того, Rational Rose содержит средства реинжиниринга программ, обеспечивающие повторное использование программных компонент в новых проектах.
^

Средства конфигурационного управления

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

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

Наиболее распространенным средством КУ является PVCS фирмы Intersolv (США), включающее ряд самостоятельных продуктов: PVCS Version Manager, PVCS Tracker, PVCS Configuration Builder и PVCS Notify.
^

Средства документирования

Для создания документации в процессе разработки АИС используются разнообразные средства формирования отчетов, а также компоненты издательских систем. Обычно средства документирования встроены в конкретные CASE-средства. Исключением являются некоторые пакеты, предоставляющие дополнительный сервис при документировании. Из них наиболее активно используется SoDA (Software Document Automation).

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

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

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

Итоговым результатом работы системы SoDA является готовый документ (или книга). Документ может храниться в файле формата SoDA (Frame Builder), который получается в результате генерации документа. Вывод на печать этого до-кумента (или его части) возможен из системы SoDA.

Среда функционирования SoDA - ОС типа UNIX на рабочих станциях Sun SPARCstation, IBM RISC System/6000 или Hewlett Packard HP 9000 700/800.
^

Средства тестирования

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

Одно из наиболее развитых средств тестирования QA (новое название – Quality Works) представляет собой интег-рированную, многоплатформенную среду для разработки автоматизированных тестов любого уровня, включая тесты регрессии для приложений с графическим интерфейсом пользователя.

QA позволяет начинать тестирование на любой фазе ЖЦ, планировать и управлять процессом тестирования, отображать изменения в приложении и повторно использовать тесты для более чем 25 различных платформ.

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

Лекция №8

Многоуровневая архитектура 9

Интернет/интранет-технологии 10

Требования, предъявляемые к информационным системам 10

Гибкость 11

Надежность 11

Эффективность 11

Безопасность 12

Жизненный цикл информационных систем 16

Общие сведения об управлении проектами 17

^ Классификация проектов 18

Основные фазы проектирования информационной системы 18

Концептуальная фаза 19

Подготовка технического предложения 19

Проектирование 19

Разработка 20

Ввод системы в эксплуатацию 20

Процессы, протекающие на протяжении жизненного цикла информационной системы 21

^ Основные процессы жизненного цикла 21

Разработка 21

Эксплуатация 21

Сопровождение 22

Вспомогательные процессы жизненного цикла 23

Организационные процессы 23

Структура жизненного цикла информационной системы 23

Начальная стадия 24

Стадия уточнения 24

^ Стадия конструирования 24

Стадия передачи в эксплуатацию 24

Жизненный цикл информационных систем 28

Модели жизненного цикла информационной системы 28

^ Каскадная модель жизненного цикла информационной системы 29

Основные этапы разработки по каскадной модели 29

Основные достоинства каскадной модели 29

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

^ Спиральная модель жизненного цикла 31

Итерации 31

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

Недостатки спиральной модели 33

Методология и технология разработки информационных систем 37

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

Основные особенности методологии RAD 40

^ Объектно-ориентированный подход 41

Визуальное программирование 42

Событийное программирование 43

Фазы жизненного цикла в рамках методологии RAD 44

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

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

Фаза построения 45

Фаза внедрения 46

^ Ограничения методологии RAD 46

Методология и технология разработки информационных систем 51

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

Понятие профиля информационной системы 52

Принципы формирования профиля информационной системы 53

^ Структура профилей информационных систем 55

Профиль прикладного программного обеспечения 57

Профиль среды информационной системы 57

Профиль защиты информации 58

Профиль инструментальных средств 58

^ Методология и технология разработки информационных систем 63

Стандарты и методики 63

Виды стандартов 64

Методика CDM фирмы Oracle 65

Общая структура 66

Особенности методики СDМ 68

^ Международный стандарт ISO/IEC 12207: 1995-08-01 69

Общая структура 69

Основные и вспомогательные процессы ЖЦ 69

Особенности стандарта ISO 12207 71

CASE-технологии проектирования информационных систем 77

Характеристика современных CASE-средств 80

^ Локальные средства 86

Объектно-ориентированные CASE-средства 87

Средства конфигурационного управления 87

Средства документирования 87

Средства тестирования 88

Принципы построения и этапы проектирования баз данных 93

Основные понятия и определения 93

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

^ Принципы построения и этапы проектирования баз данных 111

Концептуальные модели данных 111

Типы структур данных 112

Операции над данными 113

^ Ограничения целостности 114

Иерархическая модель данных 115

Сетевая модель данных 117

Реляционная модель данных 118

Бинарная модель данных 119

Семантическая сеть 119

Технология моделирования информационных систем 124

Методы моделирования систем 124

^ Математическая модель системы 126

Классификация математических моделей 128

Имитационные модели информационных систем 136

Методологические основы применения метода имитационного моделирования 136

^ Имитационные модели информационных систем 146

Классификация имитационных моделей 146

Структура типовой имитационной модели с календарем событий 153

^ Имитационные модели информационных систем 161

Технология моделирования случайных факторов 161

Генерация псевдослучайных чисел (ПСЧ) 161

Мультипликативный метод 163

Аддитивный метод 164

Смешанный метод 164

^ Моделирование случайных событий 165

Последовательное моделирование 167

Моделирование после предварительных расчетов 167

Имитационные модели информационных систем 172

Технология моделирования случайных факторов 172

^ Моделирование случайных величин 172

Моделирование непрерывных случайных величин 173

Метод обратной функции 173

Метод исключения (Неймана) 174

Метод композиции 176

Моделирование дискретных случайных величин 177

Метод последовательных сравнений 177

Метод интерпретации 178

^ Моделирование случайных векторов 178

Метод условных распределений 179

Метод исключения (Неймана) 180

Метод линейных преобразований 181

Имитационные модели информационных систем 187

Основы организации имитационного моделирования 187

^ Этапы имитационного моделирования 187

Испытание имитационной модели 188

Задание исходной информации 189

Верификация имитационной модели 189

Проверка адекватности модели 189

Калибровка имитационной модели 190

Исследование свойств имитационной модели 190

Оценка погрешности имитации, связанной с использованием в модели генераторов псевдослучайных чисел (ПСЧ) 190

Определение длительности переходного режима 191

Оценка устойчивости результатов имитации 192

Исследование чувствительности модели 192

^ Языки моделирования 193

Характеристики современных операционных систем

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

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

· Архитектура микроядра.

· Многопоточность.

· Симметричная многопроцессорность.

· Распределенные операционные системы.

· Объектно-ориентированный дизайн.

Отличительной особенностью большинства операционных систем на сего­дняшний день является большое монолитное ядро. Ядро операционной системы обеспечивает большинство ее возможностей, включая планирование, работу с файловой системой, сетевые функции, работу драйверов различных устройств, управление памятью и многие другие. Обычно монолитное ядро реализуется как единый процесс, все элементы которого используют одно и то же адресное про­странство. В архитектуре микроядра ядру отводится лишь несколько самых важных функций, в число которых входят работа с адресными пространствами, обеспечение взаимодействия между процессами (interprocess communication - IPC) и основное планирование. Работу других сервисов операционной системы обеспечивают процессы, которые иногда называют серверами. Эти процессы за­пускаются в пользовательском режиме и микроядро работает с ними так же, как и с другими приложениями. Такой подход позволяет разделить задачу разработ­ки операционной системы на разработку ядра и разработку сервера. Серверы можно настраивать для требований конкретных приложений или среды. Выде­ление в структуре системы микроядра упрощает реализацию системы, обеспечи­вает ее гибкость, а также хорошо вписывается в распределенную среду. Факти­чески микроядро взаимодействует с локальным и удаленным сервером по одной и той же схеме, что упрощает построение распределенных систем.

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

· Поток. Диспетчеризуемая единица работы, включающая контекст процессо­ра (куда входит содержимое программного счетчика и указателя вершины стека), а также свою собственную область стека (для организации вызова подпрограмм и хранения локальных данных). Команды потока выполняют­ ся последовательно; поток может быть прерван при переключении процес­сора на обработку другого потока 4 .Процесс. Набор из одного или нескольких потоков, а также связанных с этими потоками системных ресурсов (таких, как область памяти, в которую входят код и данные, открытые файлы, различные устройства). Эта кон­цепция очень близка концепции выполняющейся программы. Разбивая приложение на несколько потоков, программист получает все преимущества модульности приложения и возможность управления связанными с прило­жением временными событиями.

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

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

1. В системе имеется несколько процессоров.

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

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

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

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

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

· Наращивание . Добавляя в систему дополнительные процессоры, пользователь может повысить ее производительность.

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

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

Рис. 2.12. Многозадачность и многопроцессорность

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

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

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