Реферат: CASE-технологии - текст реферата. Скачать бесплатно.
Банк рефератов, курсовых и дипломных работ. Много и бесплатно. # | Правила оформления работ | Добавить в избранное
 
 
   
Меню Меню Меню Меню Меню
   
Napishem.com Napishem.com Napishem.com

Реферат

CASE-технологии

Банк рефератов / Программирование

Рубрики  Рубрики реферат банка

закрыть
Категория: Реферат
Язык реферата: Русский
Дата добавления:   
 
Скачать
Microsoft Word, 1927 kb, скачать бесплатно
Заказать
Узнать стоимость написания уникального реферата

Узнайте стоимость написания уникальной работы

CASE-технологии . Современные методы и средства проектирования инфор мационных систем Введение Целью данного обзора является введение в особенности современных методов и средств проектирования информационных систем , основанных на использовании CASE-технологии . Несмотря на высокие потенциальные возможности CASE-технологии (увеличение производительности труда , улучшение качества программных продуктов , поддержка унифицированного и согласованного стиля работы ) далеко не все разработчики информационных систем , использующие CASE-средства , достигают ожидаемых результатов . Сущес твуют различные причины возможных неудач , но , видимо , основной причиной является неадекватное понимание сути программирования информационных систем и применения CASE-средств . Необходимо понимать , что процесс проектирования и разработки информационной сист е мы на основе CASE-технологии не может быть подобен процессу приготовления пищи по поваренной книге . Всегда следует быть готовым к новым трудностям , связанным с освоением новой технологии , последовательно преодолевать эти трудности и последовательно добива т ься нужных результатов . Тенденции развития современных информационных технологий приводят к постоянному возрастанию сложности информационных систем (ИС ), создаваемых в различных областях экономики . Современные крупные проекты ИС характеризуются , как прави ло , следующими особенностями : · сложность описания (достаточно большое количество функций , процессов , элементов данных и сложные взаимосвязи между ними ), требующая тщательного моделирования и анализа данных и процессов ; · наличие совокупности тесно вза имодействующих компонентов (подсистем ), имеющих свои локальные задачи и цели функционирования (например , традиционных приложений , связанных с обработкой транзакций и решением регламентных задач , и приложений аналитической обработки (поддержки принятия реш е ний ), использующих нерегламентированные запросы к данным большого объема ); · отсутствие прямых аналогов , ограничивающее возможность использования каких-либо типовых проектных решений и прикладных систем ; · необходимость интеграции существующих и вновь разрабатываемых приложений ; · функционирование в неоднородной среде на нескольких аппаратных платформах ; · разобщенность и разнородность отдельных групп разработчиков по уровню квалификации и сложившимся традициям использования тех или иных инструмента льных средств ; · существенная временная протяженность проекта , обусловленная , с одной стороны , ограниченными возможностями коллектива разработчиков , и , с другой стороны , масштабами организации-заказчика и различной степенью готовности отдельных ее подраз делений к внедрению ИС. Для успешной реализации проекта объект проектирования (ИС ) должен быть прежде всего адекватно описан , должны быть построены полные и непротиворечивые функциональные и информационные модели ИС . Накопленный к настоящему времени опыт п роектирования ИС показывает , что это логически сложная , трудоемкая и длительная по времени работа , требующая высокой квалификации участвующих в ней специалистов . Однако до недавнего времени проектирование ИС выполнялось в основном на интуитивном уровне с п рименением неформализованных методов , основанных на искусстве , практическом опыте , экспертных оценках и дорогостоящих экспериментальных проверках качества функционирования ИС . Кроме того , в процессе создания и функционирования ИС информационные потребност и пользователей могут изменяться или уточняться , что еще более усложняет разработку и сопровождение таких систем . В 70-х и 80-х годах при разработке ИС достаточно широко применялась структурная методология , предоставляющая в распоряжение разработчиков стро гие формализованные методы описания ИС и принимаемых технических решений . Она основана на наглядной графической технике : для описания различного рода моделей ИС используются схемы и диаграммы . Наглядность и строгость средств структурного анализа позволяла разработчикам и будущим пользователям системы с самого начала неформально участвовать в ее создании , обсуждать и закреплять понимание основных технических решений . Однако , широкое применение этой методологии и следование ее рекомендациям при разработке ко н кретных ИС встречалось достаточно редко , поскольку при неавтоматизированной (ручной ) разработке это практически невозможно . Действительно , вручную очень трудно разработать и графически представить строгие формальные спецификации системы , проверить их на п о лноту и непротиворечивость , и тем более изменить . Если все же удается создать строгую систему проектных документов , то ее переработка при появлении серьезных изменений практически неосуществима . Ручная разработка обычно порождала следующие проблемы : · не адекватная спецификация требований ; · неспособность обнаруживать ошибки в проектных решениях ; · низкое качество документации , снижающее эксплуатационные качества ; · затяжной цикл и неудовлетворительные результаты тестирования. С другой стороны , разра ботчики ИС исторически всегда стояли последними в ряду тех , кто использовал компьютерные технологии для повышения качества , надежности и производительности в своей собственной работе (феномен "сапожника без сапог "). Перечисленные факторы способствовали по явлению программно-технологических средств специального класса - CASE-средств , реализующих CASE-технологию создания и сопровождения ИС . Термин CASE (Computer Aided Software Engineering) используется в настоящее время в весьма широком смысле . Первоначально е значение термина CASE, ограниченное вопросами автоматизации разработки только лишь программного обеспечения (ПО ), в настоящее время приобрело новый смысл , охватывающий процесс разработки сложных ИС в целом . Теперь под термином CASE-средства понимаются пр о граммные средства , поддерживающие процессы создания и сопровождения ИС , включая анализ и формулировку требований , проектирование прикладного ПО (приложений ) и баз данных , генерацию кода , тестирование , документирование , обеспечение качества , конфигурационн о е управление и управление проектом , а также другие процессы . CASE-средства вместе с системным ПО и техническими средствами образуют полную среду разработки ИС . Появлению CASE-технологии и CASE-средств предшествовали исследования в области методологии прог раммирования . Программирование обрело черты системного подхода с разработкой и внедрением языков высокого уровня , методов структурного и модульного программирования , языков проектирования и средств их поддержки , формальных и неформальных языков описаний с и стемных требований и спецификаций и т.д . Кроме того , появлению CASE-технологии способствовали и такие факторы , как : · подготовка аналитиков и программистов , восприимчивых к концепциям модульного и структурного программирования ; · широкое внедрение и по стоянный рост производительности компьютеров , позволившие использовать эффективные графические средства и автоматизировать большинство этапов проектирования ; · внедрение сетевой технологии , предоставившей возможность объединения усилий отдельных исполнит елей в единый процесс проектирования путем использования разделяемой базы данных , содержащей необходимую информацию о проекте. CASE-технология представляет собой методологию проектирования ИС , а также набор инструментальных средств , позволяющих в наглядной форме моделировать предметную область , анализировать эту модель на всех этапах разработки и сопровождения ИС и разрабатывать приложения в соответствии с информационными потребностями пользователей . Большинство существующих CASE-средств основано на методо л огиях структурного (в основном ) или объектно-ориентированного анализа и проектирования , использующих спецификации в виде диаграмм или текстов для описания внешних требований , связей между моделями системы , динамики поведения системы и архитектуры программ н ых средств . Согласно обзору передовых технологий (Survey of Advanced Technology), составленному фирмой Systems Development Inc. в 1996 г . по результатам анкетирования более 1000 американских фирм , CASE-технология в настоящее время попала в разряд наиболее стабильных информационных технологий (ее использовала половина всех опрошенных пользователей более чем в трети своих проектов , из них 85% завершились успешно ). Однако , несмотря на все потенциальные возможности CASE-средств , существует множество примеров и х неудачного внедрения , в результате которых CASE-средства становятся "полочным " ПО (shelfware). В связи с этим необходимо отметить следующее : · CASE-средства не обязательно дают немедленный эффект ; он может быть получен только спустя какое-то время ; · реальные затраты на внедрение CASE-средств обычно намного превышают затраты на их приобретение ; · CASE-средства обеспечивают возможности для получения существенной выгоды только после успешного завершения процесса их внедрения. Ввиду разнообразной приро ды CASE-средств было бы ошибочно делать какие-либо безоговорочные утверждения относительно реального удовлетворения тех или иных ожиданий от их внедрения . Можно перечислить следующие факторы , усложняющие определение возможного эффекта от использования CAS E -средств : · широкое разнообразие качества и возможностей CASE-средств ; · относительно небольшое время использования CASE-средств в различных организациях и недостаток опыта их применения ; · широкое разнообразие в практике внедрения различных организа ций ; · отсутствие детальных метрик и данных для уже выполненных и текущих проектов ; · широкий диапазон предметных областей проектов ; · различная степень интеграции CASE-средств в различных проектах. Вследствие этих сложностей доступная информация о р еальных внедрениях крайне ограничена и противоречива . Она зависит от типа средств , характеристик проектов , уровня сопровождения и опыта пользователей . Некоторые аналитики полагают , что реальная выгода от использования некоторых типов CASE-средств может бы т ь получена только после одно - или двухлетнего опыта . Другие полагают , что воздействие может реально проявиться в фазе эксплуатации жизненного цикла ИС , когда технологические улучшения могут привести к снижению эксплуатационных затрат . Для успешного внедре ния CASE-средств организация должна обладать следующими качествами : · Технология. Понимание ограниченности существующих возможностей и способность принять новую технологию ; · Культура. Готовность к внедрению новых процессов и взаимоотношений между разр аботчиками и пользователями ; · Управление. Четкое руководство и организованность по отношению к наиболее важным этапам и процессам внедрения. Если организация не обладает хотя бы одним из перечисленных качеств , то внедрение CASE-средств может закончиться неудачей независимо от степени тщательности следования различным рекомендациям по внедрению . Для того , чтобы принять взвешенное решение относительно инвестиций в CASE-технологию , пользователи вынуждены производить оценку отдельных CASE-средств , опираясь на неполные и противоречивые данные . Эта проблема зачастую усугубляется недостаточным знанием всех возможных "подводных камней " использования CASE-средств . Среди наиболее важных проблем выделяются следующие : · достоверная оценка отдачи от инвестиций в CA SE-средства затруднительна ввиду отсутствия приемлемых метрик и данных по проектам и процессам разработки ПО ; · внедрение CASE-средств может представлять собой достаточно длительный процесс и может не принести немедленной отдачи . Возможно даже краткосроч ное снижение продуктивности в результате усилий , затрачиваемых на внедрение . Вследствие этого руководство организации-пользователя может утратить интерес к CASE-средствам и прекратить поддержку их внедрения ; · отсутствие полного соответствия между теми п роцессами и методами , которые поддерживаются CASE-средствами , и теми , которые используются в данной организации , может привести к дополнительным трудностям ; · CASE-средства зачастую трудно использовать в комплексе с другими подобными средствами . Это объя сняется как различными парадигмами , поддерживаемыми различными средствами , так и проблемами передачи данных и управления от одного средства к другому ; · некоторые CASE-средства требуют слишком много усилий для того , чтобы оправдать их использование в неб ольшом проекте , при этом , тем не менее , можно извлечь выгоду из той дисциплины , к которой обязывает их применение ; · негативное отношение персонала к внедрению новой CASE-технологии может быть главной причиной провала проекта. Пользователи CASE-средств д олжны быть готовы к необходимости долгосрочных затрат на эксплуатацию , частому появлению новых версий и возможному быстрому моральному старению средств , а также постоянным затратам на обучение и повышение квалификации персонала . Несмотря на все высказанны е предостережения и некоторый пессимизм , грамотный и разумный подход к использованию CASE-средств может преодолеть все перечисленные трудности . Успешное внедрение CASE-средств должно обеспечить такие выгоды как : · высокий уровень технологической поддержк и процессов разработки и сопровождения ПО ; · положительное воздействие на некоторые или все из перечисленных факторов : производительность , качество продукции , соблюдение стандартов , документирование ; · приемлемый уровень отдачи от инвестиций в CASE-сре дства. 1. Основы методологии проектирования ИС 1.1. Жизненный цикл по ИС Одним из базовых понятий методологии проектирования ИС является понятие жизненного цикла ее программного обеспечения (ЖЦ ПО ). ЖЦ ПО - это непрерывный процесс , который начинается с мом ента принятия решения о необходимости его создания и заканчивается в момент его полного изъятия из эксплуатации . Основным нормативным документом , регламентирующим ЖЦ ПО , является международный стандарт ISO/IEC 12207 [5] (ISO - International Organization o f Standardization - Международная организация по стандартизации , IEC - International Electrotechnical Commission - Международная комиссия по электротехнике ). Он определяет структуру ЖЦ , содержащую процессы , действия и задачи , которые должны быть выполнены во время создания ПО . Структура ЖЦ ПО по стандарту ISO/IEC 12207 базируется на трех группах процессов : · основные процессы ЖЦ ПО (приобретение , поставка , разработка , эксплуатация , сопровождение ); · вспомогательные процессы , обеспечивающие выполнение о сновных процессов (документирование , управление конфигурацией , обеспечение качества , верификация , аттестация , оценка , аудит , решение проблем ); · организационные процессы (управление проектами , создание инфраструктуры проекта , определение , оценка и улучше ние самого ЖЦ , обучение ). Разработка включает в себя все работы по созданию ПО и его компонент в соответствии с заданными требованиями , включая оформление проектной и эксплуатационной документации , подготовку материалов , необходимых для проверки работоспос обности и соответствующего качества программных продуктов , материалов , необходимых для организации обучения персонала и т.д . Разработка ПО включает в себя , как правило , анализ , проектирование и реализацию (программирование ). Эксплуатация включает в себя р аботы по внедрению компонентов ПО в эксплуатацию , в том числе конфигурирование базы данных и рабочих мест пользователей , обеспечение эксплуатационной документацией , проведение обучения персонала и т.д ., и непосредственно эксплуатацию , в том числе локализа ц ию проблем и устранение причин их возникновения , модификацию ПО в рамках установленного регламента , подготовку предложений по совершенствованию , развитию и модернизации системы . Управление проектом связано с вопросами планирования и организации работ , соз дания коллективов разработчиков и контроля за сроками и качеством выполняемых работ . Техническое и организационное обеспечение проекта включает выбор методов и инструментальных средств для реализации проекта , определение методов описания промежуточных сос т ояний разработки , разработку методов и средств испытаний ПО , обучение персонала и т.п . Обеспечение качества проекта связано с проблемами верификации , проверки и тестирования ПО . Верификация - это процесс определения того , отвечает ли текущее состояние раз р аботки , достигнутое на данном этапе , требованиям этого этапа . Проверка позволяет оценить соответствие параметров разработки с исходными требованиями . Проверка частично совпадает с тестированием , которое связано с идентификацией различий между действительн ы ми и ожидаемыми результатами и оценкой соответствия характеристик ПО исходным требованиям . В процессе реализации проекта важное место занимают вопросы идентификации , описания и контроля конфигурации отдельных компонентов и всей системы в целом . Управление конфигурацией является одним из вспомогательных процессов , поддерживающих основные процессы жизненного цикла ПО , прежде всего процессы разработки и сопровождения ПО . При создании проектов сложных ИС , состоящих из многих компонентов , каждый из которых мож е т иметь разновидности или версии , возникает проблема учета их связей и функций , создания унифицированной структуры и обеспечения развития всей системы . Управление конфигурацией позволяет организовать , систематически учитывать и контролировать внесение изм е нений в ПО на всех стадиях ЖЦ . Общие принципы и рекомендации конфигурационного учета , планирования и управления конфигурациями ПО отражены в проекте стандарта ISO 12207-2 [5]. Каждый процесс характеризуется определенными задачами и методами их решения , ис ходными данными , полученными на предыдущем этапе , и результатами . Результатами анализа , в частности , являются функциональные модели , информационные модели и соответствующие им диаграммы . ЖЦ ПО носит итерационный характер : результаты очередного этапа часто вызывают изменения в проектных решениях , выработанных на более ранних этапах . 1.2. Модели жизненного цикла ПО Стандарт ISO/IEC 12207 не предлагает конкретную модель ЖЦ и методы разработки ПО (под моделью ЖЦ понимается структура , определяющая последователь ность выполнения и взаимосвязи процессов , действий и задач , выполняемых на протяжении ЖЦ . Модель ЖЦ зависит от специфики ИС и специфики условий , в которых последняя создается и функционирует ). Его регламенты являются общими для любых моделей ЖЦ , методолог и й и технологий разработки . Стандарт ISO/IEC 12207 описывает структуру процессов ЖЦ ПО , но не конкретизирует в деталях , как реализовать или выполнить действия и задачи , включенные в эти процессы . К настоящему времени наибольшее распространение получили сле дующие две основные модели ЖЦ : · каскадная модель (70-85 г.г .); · спиральная модель (86-90 г.г .). В изначально существовавших однородных ИС каждое приложение представляло собой единое целое . Для разработки такого типа приложений применялся каскадный сп особ . Его основной характеристикой является разбиение всей разработки на этапы , причем переход с одного этапа на следующий происходит только после того , как будет полностью завершена работа на текущем (рис . 1.1). Каждый этап завершается выпуском полного к о мплекта документации , достаточной для того , чтобы разработка могла быть продолжена другой командой разработчиков . Положительные стороны применения каскадного подхода заключаются в следующем [2]: · на каждом этапе формируется законченный набор проектной документации , отвечающий критериям полноты и согласованности ; · выполняемые в логичной последовательности этапы работ позволяют планировать сроки завершения всех работ и соответствующие затраты. Рис . 1.1. Каскадная схема разработки ПО Каскадный подход хорошо зарекомендовал себя при построении ИС , для которых в самом начале разработки можно достаточно точно и полно сформулировать все требования , с тем чтобы предоставить разра ботчикам свободу реализовать их как можно лучше с технической точки зрения . В эту категорию попадают сложные расчетные системы , системы реального времени и другие подобные задачи . Однако , в процессе использования этого подхода обнаружился ряд его недостат к ов , вызванных прежде всего тем , что реальный процесс создания ПО никогда полностью не укладывался в такую жесткую схему . В процессе создания ПО постоянно возникала потребность в возврате к предыдущим этапам и уточнении или пересмотре ранее принятых решени й . В результате реальный процесс создания ПО принимал следующий вид (рис . 1.2): Рис . 1.2. Реальный процесс разработки ПО по каскадной схеме Основным недостатком каскадного под хода является существенное запаздывание с получением результатов . Согласование результатов с пользователями производится только в точках , планируемых после завершения каждого этапа работ , требования к ИС "заморожены " в виде технического задания на все вре м я ее создания . Таким образом , пользователи могут внести свои замечания только после того , как работа над системой будет полностью завершена . В случае неточного изложения требований или их изменения в течение длительного периода создания ПО , пользователи п о лучают систему , не удовлетворяющую их потребностям . Модели (как функциональные , так и информационные ) автоматизируемого объекта могут устареть одновременно с их утверждением . Для преодоления перечисленных проблем была предложена спиральная модель ЖЦ [10] (рис . 1.3), делающая упор на начальные этапы ЖЦ : анализ и проектирование . На этих этапах реализуемость технических решений проверяется путем создания прототипов . Каждый виток спирали соответствует созданию фрагмента или версии ПО , на нем уточняются цели и характеристики проекта , определяется его качество и планируются работы следующего витка спирали . Таким образом углубляются и последовательно конкретизируются детали проекта и в результате выбирается обоснованный вариант , который доводится до реализации . Р азработка итерациями отражает объективно существующий спиральный цикл создания системы . Неполное завершение работ на каждом этапе позволяет переходить на следующий этап , не дожидаясь полного завершения работы на текущем . При итеративном способе разработки недостающую работу можно будет выполнить на следующей итерации . Главная же задача - как можно быстрее показать пользователям системы работоспособный продукт , тем самым активизируя процесс уточнения и дополнения требований . Основная проблема спирального ци кла - определение момента перехода на следующий этап . Для ее решения необходимо ввести временные ограничения на каждый из этапов жизненного цикла . Переход осуществляется в соответствии с планом , даже если не вся запланированная работа закончена . План сост а вляется на основе статистических данных , полученных в предыдущих проектах , и личного опыта разработчиков . Рис 1.3. Спиральная модель ЖЦ 1.3. Методологии и технологии проекти рования ИС 1.3.1. Общие требования к методологии и технологии Методологии , технологии и инструментальные средства проектирования (CASE-средства ) составляют основу проекта любой ИС . Методология реализуется через конкретные технологии и поддерживающие их ста ндарты , методики и инструментальные средства , которые обеспечивают выполнение процессов ЖЦ . Технология проектирования определяется как совокупность трех составляющих : · пошаговой процедуры , определяющей последовательность технологических операций проект ирования (рис . 1.4); · критериев и правил , используемых для оценки результатов выполнения технологических операций ; · нотаций (графических и текстовых средств ), используемых для описания проектируемой системы. Рис . 1.4. Представление технологической операции проектирования Технологические инструкции , составляющие основное содержание технологии , должны состоять из описания последовательности технологических операций , услов ий , в зависимости от которых выполняется та или иная операция , и описаний самих операций . Технология проектирования , разработки и сопровождения ИС должна удовлетворять следующим общим требованям : · технология должна поддерживать полный ЖЦ ПО ; · технол огия должна обеспечивать гарантированное достижение целей разработки ИС с заданным качеством и в установленное время ; · технология должна обеспечивать возможность выполнения крупных проектов в виде подсистем (т.е . возможность декомпозиции проекта на сост авные части , разрабатываемые группами исполнителей ограниченной численности с последующей интеграцией составных частей ). Опыт разработки крупных ИС показывает , что для повышения эффективности работ необходимо разбить проект на отдельные слабо связанные по данным и функциям подсистемы . Реализация подсистем должна выполняться отдельными группами специалистов . При этом необходимо обеспечить координацию ведения общего проекта и исключить дублирование результатов работ каждой проектной группы , которое может воз н икнуть в силу наличия общих данных и функций ; · технология должна обеспечивать возможность ведения работ по проектированию отдельных подсистем небольшими группами (3-7 человек ). Это обусловлено принципами управляемости коллектива и повышения производител ьности за счет минимизации числа внешних связей ; · технология должна обеспечивать минимальное время получения работоспособной ИС . Речь идет не о сроках готовности всей ИС , а о сроках реализации отдельных подсистем . Реализация ИС в целом в короткие сроки может потребовать привлечения большого числа разработчиков , при этом эффект может оказаться ниже , чем при реализации в более короткие сроки отдельных подсистем меньшим числом разработчиков . Практика показывает , что даже при наличии полностью завершенного п роекта , внедрение идет последовательно по отдельным подсистемам ; · технология должна предусматривать возможность управления конфигурацией проекта , ведения версий проекта и его составляющих , возможность автоматического выпуска проектной документации и син хронизацию ее версий с версиями проекта ; · технология должна обеспечивать независимость выполняемых проектных решений от средств реализации ИС (систем управления базами данных (СУБД ), операционных систем , языков и систем программирования ); · технология должна быть поддержана комплексом согласованных CASE-средств , обеспечивающих автоматизацию процессов , выполняемых на всех стадиях ЖЦ . Общий подход к оценке и выбору CASE-средств описан в разделе 4, примеры комплексов CASE-средств - в подразделе 5.7. Реаль ное применение любой технологии проектирования , разработки и сопровождения ИС в конкретной организации и конкретном проекте невозможно без выработки ряда стандартов (правил , соглашений ), которые должны соблюдаться всеми участниками проекта . К таким станда р там относятся следующие : · стандарт проектирования ; · стандарт оформления проектной документации ; · стандарт пользовательского интерфейса. Стандарт проектирования должен устанавливать : · набор необходимых моделей (диаграмм ) на каждой стадии проекти рования и степень их детализации ; · правила фиксации проектных решений на диаграммах , в том числе : правила именования объектов (включая соглашения по терминологии ), набор атрибутов для всех объектов и правила их заполнения на каждой стадии , правила оформ ления диаграмм , включая требования к форме и размерам объектов , и т . д .; · требования к конфигурации рабочих мест разработчиков , включая настройки операционной системы , настройки CASE-средств , общие настройки проекта и т . д .; · механизм обеспечения сов местной работы над проектом , в том числе : правила интеграции подсистем проекта , правила поддержания проекта в одинаковом для всех разработчиков состоянии (регламент обмена проектной информацией , механизм фиксации общих объектов и т.д .), правила проверки п р оектных решений на непротиворечивость и т . д. Стандарт оформления проектной документации должен устанавливать : · комплектность , состав и структуру документации на каждой стадии проектирования ; · требования к ее оформлению (включая требования к содержан ию разделов , подразделов , пунктов , таблиц и т.д .), · правила подготовки , рассмотрения , согласования и утверждения документации с указанием предельных сроков для каждой стадии ; · требования к настройке издательской системы , используемой в качестве встро енного средства подготовки документации ; · требования к настройке CASE-средств для обеспечения подготовки документации в соответствии с установленными требованиями. Стандарт интерфейса пользователя должен устанавливать : · правила оформления экранов (шр ифты и цветовая палитра ), состав и расположение окон и элементов управления ; · правила использования клавиатуры и мыши ; · правила оформления текстов помощи ; · перечень стандартных сообщений ; · правила обработки реакции пользователя. 1.3.2. Методоло гия RAD Одним из возможных подходов к разработке ПО в рамках спиральной модели ЖЦ является получившая в последнее время широкое распространение методология быстрой разработки приложений RAD (Rapid Application Development). Под этим термином обычно понимает ся процесс разработки ПО , содержащий 3 элемента : · небольшую команду программистов (от 2 до 10 человек ); · короткий , но тщательно проработанный производственный график (от 2 до 6 мес .); · повторяющийся цикл , при котором разработчики , по мере того , ка к приложение начинает обретать форму , запрашивают и реализуют в продукте требования , полученные через взаимодействие с заказчиком. Команда разработчиков должна представлять из себя группу профессионалов , имеющих опыт в анализе , проектировании , генерации ко да и тестировании ПО с использованием CASE-средств . Члены коллектива должны также уметь трансформировать в рабочие прототипы предложения конечных пользователей . Жизненный цикл ПО по методологии RAD состоит из четырех фаз : · фаза анализа и планирования т ребований ; · фаза проектирования ; · фаза построения ; · фаза внедрения. На фазе анализа и планирования требований пользователи системы определяют функции , которые она должна выполнять , выделяют наиболее приоритетные из них , требующие проработки в перв ую очередь , описывают информационные потребности . Определение требований выполняется в основном силами пользователей под руководством специалистов-разработчиков . Ограничивается масштаб проекта , определяются временные рамки для каждой из последующих фаз . К р оме того , определяется сама возможность реализации данного проекта в установленных рамках финансирования , на данных аппаратных средствах и т.п . Результатом данной фазы должны быть список и приоритетность функций будущей ИС , предварительные функциональные и информационные модели ИС . На фазе проектирования часть пользователей принимает участие в техническом проектировании системы под руководством специалистов-разработчиков . CASE-средства используются для быстрого получения работающих прототипов приложений . П ользователи , непосредственно взаимодействуя с ними , уточняют и дополняют требования к системе , которые не были выявлены на предыдущей фазе . Более подробно рассматриваются процессы системы . Анализируется и , при необходимости , корректируется функциональная м одель . Каждый процесс рассматривается детально . При необходимости для каждого элементарного процесса создается частичный прототип : экран , диалог , отчет , устраняющий неясности или неоднозначности . Определяются требования разграничения доступа к данным . На э той же фазе происходит определение набора необходимой документации . После детального определения состава процессов оценивается количество функциональных элементов разрабатываемой системы и принимается решение о разделении ИС на подсистемы , поддающиеся реа лизации одной командой разработчиков за приемлемое для RAD-проектов время - порядка 60 - 90 дней . С использованием CASE-средств проект распределяется между различными командами (делится функциональная модель ). Результатом данной фазы должны быть : · общая информационная модель системы ; · функциональные модели системы в целом и подсистем , реализуемых отдельными командами разработчиков ; · точно определенные с помощью CASE-средства интерфейсы между автономно разрабатываемыми подсистемами ; · построенные прототипы экранов , отчетов , диалогов. Все модели и прототипы должны быть получены с применением тех CASE-средств , которые будут использоваться в дальнейшем при построении системы . Данное требование вызвано тем , что в традиционном подходе при передаче инфор мации о проекте с этапа на этап может произойти фактически неконтролируемое искажение данных . Применение единой среды хранения информации о проекте позволяет избежать этой опасности . В отличие от традиционного подхода , при котором использовались специфиче ские средства прототипирования , не предназначенные для построения реальных приложений , а прототипы выбрасывались после того , как выполняли задачу устранения неясностей в проекте , в подходе RAD каждый прототип развивается в часть будущей системы . Таким обр а зом , на следующую фазу передается более полная и полезная информация . На фазе построения выполняется непосредственно сама быстрая разработка приложения . На данной фазе разработчики производят итеративное построение реальной системы на основе полученных в предыдущей фазе моделей , а также требований нефункционального характера . Программный код частично формируется при помощи автоматических генераторов , получающих информацию непосредственно из репозитория CASE-средств . Конечные пользователи на этой фазе оцен и вают получаемые результаты и вносят коррективы , если в процессе разработки система перестает удовлетворять определенным ранее требованиям . Тестирование системы осуществляется непосредственно в процессе разработки . После окончания работ каждой отдельной ко манды разработчиков производится постепенная интеграция данной части системы с остальными , формируется полный программный код , выполняется тестирование совместной работы данной части приложения с остальными , а затем тестирование системы в целом . Завершает с я физическое проектирование системы : · определяется необходимость распределения данных ; · производится анализ использования данных ; · производится физическое проектирование базы данных ; · определяются требования к аппаратным ресурсам ; · определяю тся способы увеличения производительности ; · завершается разработка документации проекта. Результатом фазы является готовая система , удовлетворяющая всем согласованным требованиям . На фазе внедрения производится обучение пользователей , организационные и зменения и параллельно с внедрением новой системы осуществляется работа с существующей системой (до полного внедрения новой ). Так как фаза построения достаточно непродолжительна , планирование и подготовка к внедрению должны начинаться заранее , как правило, на этапе проектирования системы . Приведенная схема разработки ИС не является абсолютной . Возможны различные варианты , зависящие , например , от начальных условий , в которых ведется разработка : разрабатывается совершенно новая система ; уже было проведено об с ледование предприятия и существует модель его деятельности ; на предприятии уже существует некоторая ИС , которая может быть использована в качестве начального прототипа или должна быть интегрирована с разрабатываемой . Следует , однако , отметить , что методол огия RAD, как и любая другая , не может претендовать на универсальность , она хороша в первую очередь для относительно небольших проектов , разрабатываемых для конкретного заказчика . Если же разрабатывается типовая система , которая не является законченным пр о дуктом , а представляет собой комплекс типовых компонент , централизованно сопровождаемых , адаптируемых к программно-техническим платформам , СУБД , средствам телекоммуникации , организационно-экономическим особенностям объектов внедрения и интегрируемых с сущ е ствующими разработками , на первый план выступают такие показатели проекта , как управляемость и качество , которые могут войти в противоречие с простотой и скоростью разработки . Для таких проектов необходимы высокий уровень планирования и жесткая дисциплина проектирования , строгое следование заранее разработанным протоколам и интерфейсам , что снижает скорость разработки . Методология RAD неприменима для построения сложных расчетных программ , операционных систем или программ управления космическими кораблями , т.е . программ , требующих написания большого объема (сотни тысяч строк ) уникального кода . Не подходят для разработки по методологии RAD приложения , в которых отсутствует ярко выраженная интерфейсная часть , наглядно определяющая логику работы системы (напри мер , приложения реального времени ) и приложения , от которых зависит безопасность людей (например , управление самолетом или атомной электростанцией ), так как итеративный подход предполагает , что первые несколько версий наверняка не будут полностью работосп о собны , что в данном случае исключается . Оценка размера приложений производится на основе так называемых функциональных элементов (экраны , сообщения , отчеты , файлы и т.п .) Подобная метрика не зависит от языка программирования , на котором ведется разработка . Размер приложения , которое может быть выполнено по методологии RAD, для хорошо отлаженной среды разработки ИС с максимальным повторным использованием программных компонентов , определяется следующим образом : < 1000 функциональных элементов один человек 1000-4000 функциональных элементов одна команда разработчиков > 4000 функциональных элементов 4000 функциональных элементов на одну команду разработчиков В качестве итога перечислим основные принципы методологии RAD: · разработка приложений итерациям и ; · необязательность полного завершения работ на каждом из этапов жизненного цикла ; · обязательное вовлечение пользователей в процесс разработки ИС ; · необходимое применение CASE-средств , обеспечивающих целостность проекта ; · применение средств уп равления конфигурацией , облегчающих внесение изменений в проект и сопровождение готовой системы ; · необходимое использование генераторов кода ; · использование прототипирования , позволяющее полнее выяснить и удовлетворить потребности конечного пользоват еля ; · тестирование и развитие проекта , осуществляемые одновременно с разработкой ; · ведение разработки немногочисленной хорошо управляемой командой профессионалов ; · грамотное руководство разработкой системы , четкое планирование и контроль выполнени я работ. 2. Структурный подход к проектированию ИС 2.1. Сущность структурного подхода Сущность структурного подхода к разработке ИС заключается в ее декомпозиции (разбиении ) на автоматизируемые функции : система разбивается на функциональные подсистемы , кот орые в свою очередь делятся на подфункции , подразделяемые на задачи и так далее . Процесс разбиения продолжается вплоть до конкретных процедур . При этом автоматизируемая система сохраняет целостное представление , в котором все составляющие компоненты взаим о увязаны . При разработке системы "снизу-вверх " от отдельных задач ко всей системе целостность теряется , возникают проблемы при информационной стыковке отдельных компонентов . Все наиболее распространенные методологии структурного подхода [9,11,12,13] базиру ются на ряде общих принципов [3]. В качестве двух базовых принципов используются следующие : · принцип "разделяй и властвуй " - принцип решения сложных проблем путем их разбиения на множество меньших независимых задач , легких для понимания и решения ; · п ринцип иерархического упорядочивания - принцип организации составных частей проблемы в иерархические древовидные структуры с добавлением новых деталей на каждом уровне. Выделение двух базовых принципов не означает , что остальные принципы являются второстеп енными , поскольку игнорирование любого из них может привести к непредсказуемым последствиям (в том числе и к провалу всего проекта ). Основными из этих принципов являются следующие : · принцип абстрагирования - заключается в выделении существенных аспектов системы и отвлечения от несущественных ; · принцип формализации - заключается в необходимости строгого методического подхода к решению проблемы ; · принцип непротиворечивости - заключается в обоснованности и согласованности элементов ; · принцип структ урирования данных - заключается в том , что данные должны быть структурированы и иерархически организованы. В структурном анализе используются в основном две группы средств , иллюстрирующих функции , выполняемые системой и отношения между данными . Каждой груп пе средств соответствуют определенные виды моделей (диаграмм ), наиболее распространенными среди которых являются следующие : · SADT (Structured Analysis and Design Technique) модели и соответствующие функциональные диаграммы (подраздел 2.2); · DFD (Data Flow Diagrams) диаграммы потоков данных (подраздел 2.3); · ERD (Entity-Relationship Diagrams) диаграммы "сущность-связь " (подраздел 2.4). На стадии проектирования ИС модели расширяются , уточняются и дополняются диаграммами , отражающими структур у программного обеспечения : архитектуру ПО , структурные схемы программ и диаграммы экранных форм . Перечисленные модели в совокупности дают полное описание ИС независимо от того , является ли она существующей или вновь разрабатываемой . Состав диаграмм в каж дом конкретном случае зависит от необходимой полноты описания системы . 2.2. Методология функционального моделирования SADT Методология SADT разработана Дугласом Россом и получила дальнейшее развитие в работе [4]. На ее основе разработана , в частности , изв естная методология IDEF0 (Icam DEFinition), которая является основной частью программы ICAM (Интеграция компьютерных и промышленных технологий ), проводимой по инициативе ВВС США . Методология SADT представляет собой совокупность методов , правил и процедур, предназначенных для построения функциональной модели объекта какой-либо предметной области . Функциональная модель SADT отображает функциональную структуру объекта , т.е . производимые им действия и связи между этими действиями . Основные элементы этой метод о логии основываются на следующих концепциях : · графическое представление блочного моделирования . Графика блоков и дуг SADT-диаграммы отображает функцию в виде блока , а интерфейсы входа /выхода представляются дугами , соответственно входящими в блок и выходя щими из него . Взаимодействие блоков друг с другом описываются посредством интерфейсных дуг , выражающих "ограничения ", которые в свою очередь определяют , когда и каким образом функции выполняются и управляются ; · строгость и точность . Выполнение правил SA DT требует достаточной строгости и точности , не накладывая в то же время чрезмерных ограничений на действия аналитика . Правила SADT включают : · ограничение количества блоков на каждом уровне декомпозиции (правило 3-6 блоков ); · связность диаграмм (номе ра блоков ); · уникальность меток и наименований (отсутствие повторяющихся имен ); · синтаксические правила для графики (блоков и дуг ); · разделение входов и управлений (правило определения роли данных ). · отделение организации от функции , т.е . исклю чение влияния организационной структуры на функциональную модель. Методология SADT может использоваться для моделирования широкого круга систем и определения требований и функций , а затем для разработки системы , которая удовлетворяет этим требованиям и реа лизует эти функции . Для уже существующих систем SADT может быть использована для анализа функций , выполняемых системой , а также для указания механизмов , посредством которых они осуществляются . 2.2.1. Состав функциональной модели Результатом применения мет одологии SADT является модель , которая состоит из диаграмм , фрагментов текстов и глоссария , имеющих ссылки друг на друга . Диаграммы - главные компоненты модели , все функции ИС и интерфейсы на них представлены как блоки и дуги . Место соединения дуги с блок о м определяет тип интерфейса . Управляющая информация входит в блок сверху , в то время как информация , которая подвергается обработке , показана с левой стороны блока , а результаты выхода показаны с правой стороны . Механизм (человек или автоматизированная си с тема ), который осуществляет операцию , представляется дугой , входящей в блок снизу (рисунок 2.1). Одной из наиболее важных особенностей методологии SADT является постепенное введение все больших уровней детализации по мере создания диаграмм , отображающих м одель . Рис . 2.1. Функциональный блок и интерфейсные дуги На рисунке 2.2, где приведены четыре диаграммы и их взаимосвязи , показана структура SADT-модели . Каждый компонент мод ели может быть декомпозирован на другой диаграмме . Каждая диаграмма иллюстрирует "внутреннее строение " блока на родительской диаграмме . 2.2.2. Иерархия диаграмм Построение SADT-модели начинается с представления всей системы в виде простейшей компоненты - одного блока и дуг , изображающих интерфейсы с функциями вне системы . Поскольку единственный блок представляет всю систему как единое целое , имя , указанное в блоке , является общим . Это верно и для интерфейсных дуг - они также представляют полный набор внеш н их интерфейсов системы в целом . Затем блок , который представляет систему в качестве единого модуля , детализируется на другой диаграмме с помощью нескольких блоков , соединенных интерфейсными дугами . Эти блоки представляют основные подфункции исходной функц ии . Данная декомпозиция выявляет полный набор подфункций , каждая из которых представлена как блок , границы которого определены интерфейсными дугами . Каждая из этих подфункций может быть декомпозирована подобным образом для более детального представления . Во всех случаях каждая подфункция может содержать только те элементы , которые входят в исходную функцию . Кроме того , модель не может опустить какие-либо элементы , т.е ., как уже отмечалось , родительский блок и его интерфейсы обеспечивают контекст . К нему н е льзя ничего добавить , и из него не может быть ничего удалено . Модель SADT представляет собой серию диаграмм с сопроводительной документацией , разбивающих сложный объект на составные части , которые представлены в виде блоков . Детали каждого из основных бло ков показаны в виде блоков на других диаграммах . Каждая детальная диаграмма является декомпозицией блока из более общей диаграммы . На каждом шаге декомпозиции более общая диаграмма называется родительской для более детальной диаграммы . Дуги , входящие в бл ок и выходящие из него на диаграмме верхнего уровня , являются точно теми же самыми , что и дуги , входящие в диаграмму нижнего уровня и выходящие из нее , потому что блок и диаграмма представляют одну и ту же часть системы . Рис . 2.2. Структура SADT-модели . Декомпозиция диаграмм На рисунках 2.3 - 2.5 представлены различные варианты выполнения функций и соединения дуг с блоками . Рис . 2.3. Одновременное выполнение Рис . 2.4. Соответствие должно быть полным и непротиворечивым Некоторые дуги присоединены к блокам диаграммы обоими концами , у других же один конец остается неприсоединенным . Неприсоединенные дуги соответствуют входам , управлениям и выходам родительского блока . Источник или получатель этих пограничных дуг может быть обнаружен только на родительской диаграмме . Неприсоединенные концы должны соответствовать дугам на исходной диаграмме . Все грани ч ные дуги должны продолжаться на родительской диаграмме , чтобы она была полной и непротиворечивой . На SADT-диаграммах не указаны явно ни последовательность , ни время . Обратные связи , итерации , продолжающиеся процессы и перекрывающиеся (по времени ) функции могут быть изображены с помощью дуг . Обратные связи могут выступать в виде комментариев , замечаний , исправлений и т.д . (рисунок 2.5). Рис . 2.5. Пример обратной связи Как был о отмечено , механизмы (дуги с нижней стороны ) показывают средства , с помощью которых осуществляется выполнение функций . Механизм может быть человеком , компьютером или любым другим устройством , которое помогает выполнять данную функцию (рисунок 2.6). Рис . 2.6. Пример механизма Каждый блок на диаграмме имеет свой номер . Блок любой диаграммы может быть далее описан диаграммой нижнего уровня , которая , в свою очередь , может быть д алее детализирована с помощью необходимого числа диаграмм . Таким образом , формируется иерархия диаграмм . Для того , чтобы указать положение любой диаграммы или блока в иерархии , используются номера диаграмм . Например , А 21 является диаграммой , которая детал изирует блок 1 на диаграмме А 2. Аналогично , А 2 детализирует блок 2 на диаграмме А 0, которая является самой верхней диаграммой модели . На рисунке 2.7 показано типичное дерево диаграмм . Рис . 2.7. Иерархия диаграмм 2.2.3. Типы связей между функциями Одним из важных моментов при проектировании ИС с помощью методологии SADT является точная согласованность типов связей между функциями . Различают по крайней мере семь типов связывани я : Тип связи Относительная значимость Случайная 0 Логическая 1 Временная 2 Процедурная 3 Коммуникационная 4 Последовательная 5 Функциональная 6 Ниже каждый тип связи кратко определен и проиллюстрирован с помощью типичного примера из SADT. (0) Тип случайной связности : наименее желательный . Случайная связность возникает , когда конкретная связь между функциями мала или полностью отсутствует . Это относится к ситуации , когда имена данных на SADT-дугах в одной диаграмме имеют малую связь друг с другом . Крайний вариант этого случая показан на рисунке 2.8. Рис . 2.8. Случайная связность (1) Тип логической связности. Логическое связывание происходит тогда , когда данные и функции собираются вместе вследствие того , что они попадают в общий класс или набор элементов , но необходимых функциональных отношений между ними не обнаруживается . (2) Тип временной связности. Связанные по времени элементы возникают вследствие того , чт о они представляют функции , связанные во времени , когда данные используются одновременно или функции включаются параллельно , а не последовательно . (3) Тип процедурной связности. Процедурно-связанные элементы появляются сгруппированными вместе вследствие т ого , что они выполняются в течение одной и той же части цикла или процесса . Пример процедурно-связанной диаграммы приведен на рисунке 2.9. Рис . 2.9. Процедурная связность (4) Тип коммуникационной связности. Диаграммы демонстрируют коммуникационные связи , когда блоки группируются вследствие того , что они используют одни и те же входные данные и /или производят одни и те же выходные данные (рисунок 2.10). (5) Тип последовател ьной связности. На диаграммах , имеющих последовательные связи , выход одной функции служит входными данными для следующей функции . Связь между элементами на диаграмме является более тесной , чем на рассмотренных выше уровнях связок , поскольку моделируются пр ичинно-следственные зависимости (рисунок 2.11). (6) Тип функциональной связности. Диаграмма отражает полную функциональную связность , при наличии полной зависимости одной функции от другой . Диаграмма , которая является чисто функциональной , не содержит чуж еродных элементов , относящихся к последовательному или более слабому типу связности . Одним из способов определения функционально-связанных диаграмм является рассмотрение двух блоков , связанных через управляющие дуги , как показано на рисунке 2.12. В математических терминах необходимое условие для простейшего типа функциональной связности , показанной на рисунке 2.12, имеет следующий вид : C = g(B) = g(f(A)) Ниже в таблице предст авлены все типы связей , рассмотренные выше . Важно отметить , что уровни 4-6 устанавливают типы связностей , которые разработчики считают важнейшими для получения диаграмм хорошего качества . Рис . 2.12. Функциональная связность Значимость Тип связности Для функций Для данных 0 Случайная Случайная Случайная 1 Логическая Функции одного и того же множества или типа (например , "редактировать все входы ") Данные одного и того же множества или типа 2 Временная Функции одного и того же периода времени (например , "операции инициализации ") Данные , используемые в каком-либо временном интервале 3 Процедурная Функции , работающие в одной и той же фазе или итерации (например , "первый проход компилятора ") Данные , используемые во время одной и той же фазы или итерации 4 Коммуникационнная Функции , использующие одни и те же данные Данные , на которые воздействует одна и та же деятельность 5 Последовательная Функции , выполняющие послед овательные преобразования одних и тех же данных Данные , преобразуемые последовательными функциями 6 Функциональная Функции , объединяемые для выполнения одной функции Данные , связанные с одной функцией 2.3. Моделирование потоков данных (процессов ) В о снове данной методологии (методологии Gane/Sarson [11]) лежит построение модели анализируемой ИС - проектируемой или реально существующей . В соответствии с методологией модель системы определяется как иерархия диаграмм потоков данных (ДПД или DFD), описыв а ющих асинхронный процесс преобразования информации от ее ввода в систему до выдачи пользователю . Диаграммы верхних уровней иерархии (контекстные диаграммы ) определяют основные процессы или подсистемы ИС с внешними входами и выходами . Они детализируются пр и помощи диаграмм нижнего уровня . Такая декомпозиция продолжается , создавая многоуровневую иерархию диаграмм , до тех пор , пока не будет достигнут такой уровень декомпозиции , на котором процесс становятся элементарными и детализировать их далее невозможно . Источники информации (внешние сущности ) порождают информационные потоки (потоки данных ), переносящие информацию к подсистемам или процессам . Те в свою очередь преобразуют информацию и порождают новые потоки , которые переносят информацию к другим процессам или подсистемам , накопителям данных или внешним сущностям - потребителям информации . Таким образом , основными компонентами диаграмм потоков данных являются : · внешние сущности ; · системы /подсистемы ; · процессы ; · накопители данных ; · потоки данны х. 2.3.1. Внешние сущности Внешняя сущность представляет собой материальный предмет или физическое лицо , представляющее собой источник или приемник информации , например , заказчики , персонал , поставщики , клиенты , склад . Определение некоторого объекта или си стемы в качестве внешней сущности указывает на то , что она находится за пределами границ анализируемой ИС . В процессе анализа некоторые внешние сущности могут быть перенесены внутрь диаграммы анализируемой ИС , если это необходимо , или , наоборот , часть про ц ессов ИС может быть вынесена за пределы диаграммы и представлена как внешняя сущность . Внешняя сущность обозначается квадратом (рисунок 2.13), расположенным как бы "над " диаграммой и бросающим на нее тень , для того , чтобы можно было выделить этот символ с реди других обозначений : Рис . 2.13. Внешняя сущность 2.3.2. Системы и подсистемы При построении модели сложной ИС она может быть представлена в самом общем виде на так называ емой контекстной диаграмме в виде одной системы как единого целого , либо может быть декомпозирована на ряд подсистем . Подсистема (или система ) на контекстной диаграмме изображается следующим образом (рисунок 2.14). Рис . 2.14. Подсистема Номер подсистемы служит для ее идентификации . В поле имени вводится наименование подсистемы в виде предложения с подлежащим и соответствующими определениями и дополнениями . 2.3.3. Процессы П роцесс представляет собой преобразование входных потоков данных в выходные в соответствии с определенным алгоритмом . Физически процесс может быть реализован различными способами : это может быть подразделение организации (отдел ), выполняющее обработку вход н ых документов и выпуск отчетов , программа , аппаратно реализованное логическое устройство и т.д . Процесс на диаграмме потоков данных изображается , как показано на рисунке 2.15. Рис . 2.15. Процесс Номер процесса служит для его идентификации . В поле имени вводится наименование процесса в виде предложения с активным недвусмысленным глаголом в неопределенной форме (вычислить , рассчитать , проверить , определить , создать , получить ), за которым следуют существительные в винительном падеже , например : · "Ввести сведения о клиентах "; · "Выдать информацию о текущих расходах "; · "Проверить кредитоспособность клиента ". Использование таких глаголов , как "обработать ", "модернизировать " и ли "отредактировать " означает , как правило , недостаточно глубокое понимание данного процесса и требует дальнейшего анализа . Информация в поле физической реализации показывает , какое подразделение организации , программа или аппаратное устройство выполняет данный процесс . 2 .3.4. Накопители данных Накопитель данных представляет собой абстрактное устройство для хранения информации , которую можно в любой момент поместить в накопитель и через некоторое время извлечь , причем способы помещения и извлечения могут быть любыми . Накопитель данных может быть реализован физически в виде микрофиши , ящика в картотеке , таблицы в оперативной памяти , файла на магнитном носителе и т.д . Накопитель данных на диаграмме потоков данных изображается , как показано на рисунке 2.16. Рис . 2.16. Накопитель данных Накопитель данных идентифицируется буквой "D" и произвольным числом . Имя накопителя выбирается из соображения наибольшей информативности для про ектировщика . Накопитель данных в общем случае является прообразом будущей базы данных и описание хранящихся в нем данных должно быть увязано с информационной моделью . 2.3.5. Потоки данных Поток данных определяет информацию , передаваемую через некоторое с оединение от источника к приемнику . Реальный поток данных может быть информацией , передаваемой по кабелю между двумя устройствами , пересылаемыми по почте письмами , магнитными лентами или дискетами , переносимыми с одного компьютера на другой и т.д . Поток д анных на диаграмме изображается линией , оканчивающейся стрелкой , которая показывает направление потока (рисунок 2.17). Каждый поток данных имеет имя , отражающее его содержание . Рис . 2.17. Поток данных 2.3.6. Построение иерархии диаграмм потоков данных Первым шагом при построении иерархии ДПД является построение контекстных диаграмм . Обычно при проектировании относительно простых ИС строится единственная контекстная диаграмма с о звездообразной топологией , в центре которой находится так называемый главный процесс , соединенный с приемниками и источниками информации , посредством которых с системой взаимодействуют пользователи и другие внешние системы . Если же для сложной системы о граничиться единственной контекстной диаграммой , то она будет содержать слишком большое количество источников и приемников информации , которые трудно расположить на листе бумаги нормального формата , и кроме того , единственный главный процесс не раскрывает структуры распределенной системы . Признаками сложности (в смысле контекста ) могут быть : · наличие большого количества внешних сущностей (десять и более ); · распределенная природа системы ; · многофункциональность системы с уже сложившейся или выявленн ой группировкой функций в отдельные подсистемы. Для сложных ИС строится иерархия контекстных диаграмм . При этом контекстная диаграмма верхнего уровня содержит не единственный главный процесс , а набор подсистем , соединенных потоками данных . Контекстные диаг раммы следующего уровня детализируют контекст и структуру подсистем . Иерархия контекстных диаграмм определяет взаимодействие основных функциональных подсистем проектируемой ИС как между собой , так и с внешними входными и выходными потоками данных и внешни ми объектами (источниками и приемниками информации ), с которыми взаимодействует ИС . Разработка контекстных диаграмм решает проблему строгого определения функциональной структуры ИС на самой ранней стадии ее проектирования , что особенно важно для сложных м ногофункциональных систем , в разработке которых участвуют разные организации и коллективы разработчиков . После построения контекстных диаграмм полученную модель следует проверить на полноту исходных данных об объектах системы и изолированность объектов (о тсутствие информационных связей с другими объектами ). Для каждой подсистемы , присутствующей на контекстных диаграммах , выполняется ее детализация при помощи ДПД . Каждый процесс на ДПД , в свою очередь , может быть детализирован при помощи ДПД или миниспециф икации . При детализации должны выполняться следующие правила : · правило балансировки - означает , что при детализации подсистемы или процесса детализирующая диаграмма в качестве внешних источников /приемников данных может иметь только те компоненты (подсис темы , процессы , внешние сущности , накопители данных ), с которыми имеет информационную связь детализируемая подсистема или процесс на родительской диаграмме ; · правило нумерации - означает , что при детализации процессов должна поддерживаться их иерархичес кая нумерация . Например , процессы , детализирующие процесс с номером 12, получают номера 12.1, 12.2, 12.3 и т.д. Миниспецификация (описание логики процесса ) должна формулировать его основные функции таким образом , чтобы в дальнейшем специалист , выполняющий реализацию проекта , смог выполнить их или разработать соответствующую программу . Миниспецификация является конечной вершиной иерархии ДПД . Решение о завершении детализации процесса и использовании миниспецификации принимается аналитиком исходя из следующи х критериев : · наличия у процесса относительно небольшого количества входных и выходных потоков данных (2-3 потока ); · возможности описания преобразования данных процессом в виде последовательного алгоритма ; · выполнения процессом единственной логиче ской функции преобразования входной информации в выходную ; · возможности описания логики процесса при помощи миниспецификации небольшого объема (не более 20-30 строк ). При построении иерархии ДПД переходить к детализации процессов следует только после оп ределения содержания всех потоков и накопителей данных , которое описывается при помощи структур данных . Структуры данных конструируются из элементов данных и могут содержать альтернативы , условные вхождения и итерации . Условное вхождение означает , что дан н ый компонент может отсутствовать в структуре . Альтернатива означает , что в структуру может входить один из перечисленных элементов . Итерация означает вхождение любого числа элементов в указанном диапазоне . Для каждого элемента данных может указываться его тип (непрерывные или дискретные данные ). Для непрерывных данных может указываться единица измерения (кг , см и т.п .), диапазон значений , точность представления и форма физического кодирования . Для дискретных данных может указываться таблица допустимых знач е ний . После построения законченной модели системы ее необходимо верифицировать (проверить на полноту и согласованность ). В полной модели все ее объекты (подсистемы , процессы , потоки данных ) должны быть подробно описаны и детализированы . Выявленные недетали зированные объекты следует детализировать , вернувшись на предыдущие шаги разработки . В согласованной модели для всех потоков данных и накопителей данных должно выполняться правило сохранения информации : все поступающие куда-либо данные должны быть считаны, а все считываемые данные должны быть записаны . 2.4. Моделирование данных 2.4.1. Case-метод Баркера Цель моделирования данных состоит в обеспечении разработчика ИС концептуальной схемой базы данных в форме одной модели или нескольких локальных моделей , ко торые относительно легко могут быть отображены в любую систему баз данных . Наиболее распространенным средством моделирования данных являются диаграммы "сущность-связь " (ERD). С их помощью определяются важные для предметной области объекты (сущности ), их с войства (атрибуты ) и отношения друг с другом (связи ). ERD непосредственно используются для проектирования реляционных баз данных . Нотация ERD была впервые введена П . Ченом (Chen) и получила дальнейшее развитие в работах Баркера [8]. Метод Баркера будет из лагаться на примере моделирования деятельности компании по торговле автомобилями . Ниже приведены выдержки из интервью , проведенного с персоналом компании . Главный менеджер : одна из основных обязанностей - содержание автомобильного имущества . Он должен зна ть , сколько заплачено за машины и каковы накладные расходы . Обладая этой информацией , он может установить нижнюю цену , за которую мог бы продать данный экземпляр . Кроме того , он несет ответственность за продавцов и ему нужно знать , кто что продает и сколь к о машин продал каждый из них . Продавец : ему нужно знать , какую цену запрашивать и какова нижняя цена , за которую можно совершить сделку . Кроме того , ему нужна основная информация о машинах : год выпуска , марка , модель и т.п . Администратор : его задача свод ится к составлению контрактов , для чего нужна информация о покупателе , автомашине и продавце , поскольку именно контракты приносят продавцам вознаграждения за продажи . Первый шаг моделирования - извлечение информации из интервью и выделение сущностей . Сущ ность (Entity) - реальный либо воображаемый объект , имеющий существенное значение для рассматриваемой предметной области , информация о котором подлежит хранению (рисунок 2.18). Рис . 2.18. Графическое изображение сущности Каждая сущность должна обладать уникальным идентификатором . Каждый экземпляр сущности должен однозначно идентифицироваться и отличаться от всех других экземпляров данного типа сущности . Каждая сущность должна обладать некоторыми свойствами : · каждая сущность должна иметь уникальное имя , и к одному и тому же имени должна всегда применяться одна и та же интерпретация . Одна и та же интерпретация не может применяться к различным именам , если только они не являютс я псевдонимами ; · сущность обладает одним или несколькими атрибутами , которые либо принадлежат сущности , либо наследуются через связь ; · сущность обладает одним или несколькими атрибутами , которые однозначно идентифицируют каждый экземпляр сущности ; · каждая сущность может обладать любым количеством связей с другими сущностями модели. Обращаясь к приведенным выше выдержкам из интервью , видно , что сущности , которые могут быть идентифицированы с главным менеджером - это автомашины и продавцы . Продавцу в ажны автомашины и связанные с их продажей данные . Для администратора важны покупатели , автомашины , продавцы и контракты . Исходя из этого , выделяются 4 сущности (автомашина , продавец , покупатель , контракт ), которые изображаются на диаграмме следующим образ о м (рисунок 2.19). Рис . 2.19. Следующим шагом моделирования является идентификация связей . Связь (Relationship) - поименованная ассоциация между двумя сущностями , значимая д ля рассматриваемой предметной области . Связь - это ассоциация между сущностями , при которой , как правило , каждый экземпляр одной сущности , называемой родительской сущностью , ассоциирован с произвольным (в том числе нулевым ) количеством экземпляров второй с ущности , называемой сущностью-потомком , а каждый экземпляр сущности-потомка ассоциирован в точности с одним экземпляром сущности-родителя . Таким образом , экземпляр сущности-потомка может существовать только при существовании сущности родителя . Связи может даваться имя , выражаемое грамматическим оборотом глагола и помещаемое возле линии связи . Имя каждой связи между двумя данными сущностями должно быть уникальным , но имена связей в модели не обязаны быть уникальными . Имя связи всегда формируется с точки зр е ния родителя , так что предложение может быть образовано соединением имени сущности-родителя , имени связи , выражения степени и имени сущности-потомка . Например , связь продавца с контрактом может быть выражена следующим образом : · продавец может получить вознаграждение за 1 или более контрактов ; · контракт должен быть инициирован ровно одним продавцом. Степень связи и обязательность графически изображаются следующим образом (рисунок 2.20). Описав также связи остальных сущностей , получим следующую схему (рисунок 2.22). Рис . 2.22. Последним шагом моделирования является идентификация атрибутов . А трибут - любая характеристика сущности , значимая для рассматриваемой предметной области и предназначенная для квалификации , идентификации , классификации , количественной характеристики или выражения состояния сущности . Атрибут представляет тип характеристик или свойств , ассоциированных со множеством реальных или абстрактных объектов (людей , мест , событий , состояний , идей , пар предметов и т.д .). Экземпляр атрибута - это определенная характеристика отдельного элемента множества . Экземпляр атрибута определяетс я типом характеристики и ее значением , называемым значением атрибута . В ER-модели атрибуты ассоциируются с конкретными сущностями . Таким образом , экземпляр сущности должен обладать единственным определенным значением для ассоциированного атрибута . Атрибут может быть либо обязательным , либо необязательным (рисунок 2.23). Обязательность означает , что атрибут не может принимать неопределенных значений (null values). Атрибут может быть либо описательным (т.е . обычным дескриптором сущности ), либо входить в сост а в уникального идентификатора (первичного ключа ). Уникальный идентификатор - это атрибут или совокупность атрибутов и /или связей , предназначенная для уникальной идентификации каждого экземпляра данного типа сущности . В случае полной идентификации каждый эк земпляр данного типа сущности полностью идентифицируется своими собственными ключевыми атрибутами , в противном случае в его идентификации участвуют также атрибуты другой сущности-родителя (рисунок 2.24). Каждый атрибут идентифицируется уникальным именем , выражаемым грамматическим оборотом существительного , описывающим представляемую атрибутом характеристику . Атрибуты изображаются в виде списка имен внутри блока ассоциированно й сущности , причем каждый атрибут занимает отдельную строку . Атрибуты , определяющие первичный ключ , размещаются наверху списка и выделяются знаком "#". Каждая сущность должна обладать хотя бы одним возможным ключом . Возможный ключ сущности - это один или несколько атрибутов , чьи значения однозначно определяют каждый экземпляр сущности . При существовании нескольких возможных ключей один из них обозначается в качестве первичного ключа , а остальные - как альтернативные ключи . С учетом имеющейся информации до полним построенную ранее диаграмму (рисунок 2.25). Помимо перечисленных основных конструкций модель данных может содержать ряд дополнительных . Подтипы и супертипы : одна сущность является обобщающим понятием для группы подобных сущностей (рисунок 2.26). Взаимно исключающие связи : каждый экземпляр сущности участвует только в одной связи из группы взаимно исключающих связей (рисунок 2.27). Рис . 2.25. Рекурсивная связь : сущность может быть связана сама с собой (рисунок 2.28). Неперемещаемые (non-transferrable) связи : экземпляр сущности не может быть перенесен из одного экземпляра связи в другой (рисунок 2.29). Рис . 2.29. Неперемещаемая связь 2.4.2. Методология IDEF1 Метод IDEF1, разработанный Т.Р эмей (T.Ramey), также основан на подходе П.Чена и позволяет построить модель данных , эквивалентную реляционной модели в третьей нормальной форме . В настоящее время на основе совершенствования методологии IDEF1 создана ее новая версия - методология IDEF1X. IDEF1X разработана с учетом таких требований , как простота изучения и возможность автоматизации . IDEF1X-диаграммы используются рядом распространенных CASE-средств (в частности , ERwin, Design/IDEF). Сущность в методологии IDEF1X является независимой от иде нтификаторов или просто независимой , если каждый экземпляр сущности может быть однозначно идентифицирован без определения его отношений с другими сущностями . Сущность называется зависимой от идентификаторов или просто зависимой , если однозначная идентифик а ция экземпляра сущности зависит от его отношения к другой сущности (рисунок 2.30). Рис . 2.30. Сущности Каждой сущности присваивается уникальное имя и номер , разделяемые косой чертой "/" и помещаемые над блоком . Связь может дополнительно определяться с помощью указания степени или мощности (количества экземпляров сущности-потомка , которое может существовать для каждого экземпляра сущности-родителя ). В IDEF1X могут быть выражен ы следующие мощности связей : · каждый экземпляр сущности-родителя может иметь ноль , один или более связанных с ним экземпляров сущности-потомка ; · каждый экземпляр сущности-родителя должен иметь не менее одного связанного с ним экземпляра сущности-пото мка ; · каждый экземпляр сущности-родителя должен иметь не более одного связанного с ним экземпляра сущности-потомка ; · каждый экземпляр сущности-родителя связан с некоторым фиксированным числом экземпляров сущности-потомка. Если экземпляр сущности-пото мка однозначно определяется своей связью с сущностью-родителем , то связь называется идентифицирующей , в противном случае - неидентифицирующей . Связь изображается линией , проводимой между сущностью-родителем и сущностью-потомком с точкой на конце линии у с ущности-потомка . Мощность связи обозначается как показано на рис . 2.31 (мощность по умолчанию - N). Рис . 2.31. Мощность связи Идентифицирующая связь между сущностью-родителе м и сущностью-потомком изображается сплошной линией (рисунок 2.32). Сущность-потомок в идентифицирующей связи является зависимой от идентификатора сущностью . Сущность-родитель в идентифицирующей связи может быть как независимой , так и зависимой от идентиф и катора сущностью (это определяется ее связями с другими сущностями ). Рис . 2.32. Идентифицирующая связь Пунктирная линия изображает неидентифицирующую связь (рисунок 2.33). Су щность-потомок в неидентифицирующей связи будет независимой от идентификатора , если она не является также сущностью-потомком в какой-либо идентифицирующей связи . Рис . 2.33. Н еидентифицирующая связь Атрибуты изображаются в виде списка имен внутри блока сущности . Атрибуты , определяющие первичный ключ , размещаются наверху списка и отделяются от других атрибутов горизонтальной чертой (рисунок 2.34). Рис . 2.34. Атрибуты и первичные ключи Сущности могут иметь также внешние ключи (Foreign Key), которые могут использоваться в качестве части или целого первичного ключа или неключевого атрибута . Внешний к люч изображается с помощью помещения внутрь блока сущности имен атрибутов , после которых следуют буквы FK в скобках (рисунок 2.35). Рис . 2.35. Примеры внешних ключей 3. Хара ктеристики CASE-средств 3.1. Silverrun+JAM 3.1.1. Silverrun CASE-средство Silverrun американской фирмы С omputer Systems Advisers, Inc. (CSA) используется для анализа и проектирования ИС бизнес-класса [22] и ориентировано в большей степени на спиральную мод ель ЖЦ . Оно применимо для поддержки любой методологии , основанной на раздельном построении функциональной и информационной моделей (диаграмм потоков данных и диаграмм "сущность-связь "). Настройка на конкретную методологию обеспечивается выбором требуемой графической нотации моделей и набора правил проверки проектных спецификаций . В системе имеются готовые настройки для наиболее распространенных методологий : DATARUN (основная методология , поддерживаемая Silverrun), Gane/Sarson, Yourdon/DeMarco, Merise, War d /Mellor, Information Engineering. Для каждого понятия , введенного в проекте имеется возможность добавления собственных описателей . Архитектура Silverrun позволяет наращивать среду разработки по мере необходимости . Структура и функции Silverrun имеет моду льную структуру и состоит из четырех модулей , каждый из которых является самостоятельным продуктом и может приобретаться и использоваться без связи с остальными модулями . Модуль построения моделей бизнес-процессов в форме диаграмм потоков данных (BPM - Bu siness Process Modeler) позволяет моделировать функционирование обследуемой организации или создаваемой ИС . В модуле BPM обеспечена возможность работы с моделями большой сложности : автоматическая перенумерация , работа с деревом процессов (включая визуальн о е перетаскивание ветвей ), отсоединение и присоединение частей модели для коллективной разработки . Диаграммы могут изображаться в нескольких предопределенных нотациях , включая Yourdon/DeMarco и Gane/Sarson. Имеется также возможность создавать собственные н о тации , в том числе добавлять в число изображаемых на схеме дескрипторов определенные пользователем поля . Модуль концептуального моделирования данных (ERX - Entity-Relationship eXpert) обеспечивает построение моделей данных "сущность-связь ", не привязанных к конкретной реализации . Этот модуль имеет встроенную экспертную систему , позволяющую создать корректную нормализованную модель данных посредством ответов на содержательные вопросы о взаимосвязи данных . Возможно автоматическое построение модели данных из описаний структур данных . Анализ функциональных зависимостей атрибутов дает возможность проверить соответствие модели требованиям третьей нормальной формы и обеспечить их выполнение . Проверенная модель передается в модуль RDM. Модуль реляционного моделиро вания (RDM - Relational Data Modeler) позволяет создавать детализированные модели "сущность-связь ", предназначенные для реализации в реляционной базе данных . В этом модуле документируются все конструкции , связанные с построением базы данных : индексы , триг г еры , хранимые процедуры и т.д . Гибкая изменяемая нотация и расширяемость репозитория позволяют работать по любой методологии . Возможность создавать подсхемы соответствует подходу ANSI SPARC к представлению схемы базы данных . На языке подсхем моделируются к ак узлы распределенной обработки , так и пользовательские представления . Этот модуль обеспечивает проектирование и полное документирование реляционных баз данных . Менеджер репозитория рабочей группы (WRM - Workgroup Repository Manager) применяется как слов арь данных для хранения общей для всех моделей информации , а также обеспечивает интеграцию модулей Silverrun в единую среду проектирования . Платой за высокую гибкость и разнообразие изобразительных средств построения моделей является такой недостаток Silv errun, как отсутствие жесткого взаимного контроля между компонентами различных моделей (например , возможности автоматического распространения изменений между DFD различных уровней декомпозиции ). Следует , однако , отметить , что этот недостаток может иметь с у щественное значение только в случае использования каскадной модели ЖЦ ПО . Взаимодействие с другими средствами Для автоматической генерации схем баз данных у Silverrun существуют мосты к наиболее распространенным СУБД : Oracle, Informix, DB2, Ingres, Progr ess, 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 - с возможностью обмена проектными данными между ними . Для функционирования в среде Windows необходимо иметь компьютер с процессором модели не ниже i486 и оперативную память объемом не менее 8 Мб (рекомендуется 16 Мб ). На диске пол ная инсталляция Silverrun занимает 20 Мб . 3.1.2. JAM Средство разработки приложений JAM [28] (JYACC's Application Manager) - продукт фирмы JYACC (США ). В настоящее время поставляется версия JAM 7 и готовится к выходу JAM 8. Основной чертой JAM является е го соответствие методологии RAD, поскольку он позволяет достаточно быстро реализовать цикл разработки приложения , заключающийся в формировании очередной версии прототипа приложения с учетом требований , выявленных на предыдущем шаге , и предъявить его польз о вателю . Структура и функции JAM имеет модульную структуру и состоит из следующих компонент : · Ядро системы ; · JAM/DBi - специализированные модули интерфейса к СУБД (JAM/DBi-Oracle, JAM/DBi-Informix, JAM/DBi-ODBC и т.д .); · JAM/RW - модуль генератор а отчетов ; · JAM/CASEi - специализированные модули интерфейса к CASE-средствам (JAM/CASE-TeamWork, JAM/CASE-Innovator и т.д .); · JAM/TPi - специализированные модули интерфейса к менеджерам транзакций (например , JAM/TPi-Server TUXEDO и т.д .); · Jterm - специализированный эмулятор X-терминала. Ядро системы (собственно , сам JAM) является законченным продуктом и может самостоятельно использоваться для разработки приложений . Все остальные модули являются дополнительными и самостоятельно использоваться не м огут . Ядро системы включает в себя следующие основные компоненты : · редактор экранов . В состав редактора экранов входят : среда разработки экранов , визуальный репозиторий объектов , собственная СУБД JAM - JDB, менеджер транзакций , отладчик , редактор стиле й ; · редактор меню ; · набор вспомогательных утилит ; · средства изготовления промышленной версии приложения. При использовании JAM разработка внешнего интерфейса приложения представляет собой визуальное проектирование и сводится к созданию экранных фо рм путем размещения на них интерфейсных конструкций и определению экранных полей ввода /вывода информации . Проектирование интерфейса в JAM осуществляется с помощью редактора экранов . Приложения , разработанные в JAM, имеют многооконный интерфейс . Разработка отдельного экрана заключается в размещении на нем интерфейсных элементов , возможной (но не обязательной ) их группировке и конкретизации различных их свойств , включающих визуальные характеристики (позиция , размер , цвет , шрифт и т.п .), поведенческие характе р истики (многообразные фильтры , форматы , защита от ввода и т.п .) и ряд свойств , ориентированных на работу с БД . Редактор меню позволяет разрабатывать и отлаживать системы меню . Реализована возможность построения пиктографических меню (так называемые toolba r). Назначение каждого конкретного меню тому или иному объекту приложения осуществляется в редакторе экранов . В ядро JAM встроена однопользовательская реляционная СУБД JDB. Основным назначением JDB является прототипирование приложений в тех случаях , когда работа со штатной СУБД невозможна или нецелесообразна . В JDB реализован необходимый минимум возможностей реляционных СУБД за исключением индексов , хранимых процедур , триггеров и представлений (view). С помощью JDB можно построить БД , идентичную целевой Б Д (с точностью до отсутствующих в JDB возможностей ) и разработать значительную часть приложения . Отладчик позволяет проводить комплексную отладку разрабатываемого приложения . Осуществляется трассировка всех событий , возникающих в процессе исполнения прилож ения . Утилиты JAM включают три группы : · конверторы файлов экранов JAM в текстовые . JAM сохраняет экраны в виде двоичных файлов собственного формата . В ряде случаев (например для изготовления программной документации проекта ) необходимо текстовое описан ие экранов ; · конфигурирование устройств ввода /вывода . JAM и приложения , построенные с его помощью , не работают непосредственно с устройствами ввода /вывода . Вместо этого JAM обращается к логическим устройствам ввода /вывода (клавиатура , терминал , отчет ). Отображение логических устройств в физические осуществляется с помощью средств конфигурирования ; · обслуживание библиотек экранов (традиционные операции с библиотеками ). Одним из дополнительных модулей JAM является генератор отчетов . Компоновка отчета ос уществляется в редакторе экранов JAM. Описание работы отчета осуществляется с помощью специального языка . Генератор отчетов позволяет определить данные , выводимые в отчет , группировку выводимой информации , форматирование вывода и др . Приложения , разработа нные с использованием JAM, не требуют так называемых исполнительных (run-time) систем и могут быть изготовлены в виде исполняемых модулей . Для этого разработчик должен иметь компилятор C и редактор связей . Для изготовления промышленной версии в состав JAM входит файл сборки (makefile), исходные тексты (на языке C) ряда модулей приложения и необходимые библиотеки . JAM содержит встроенный язык программирования JPL (JAM Procedural Language), с помощью которого в случае необходимости можно написать модули , реа лизующие специфические действия . Данный язык является интерпретируемым , что упрощает отладку . Существует возможность обмена информацией между средой визуально построенного приложения и такими модулями . Кроме того , в JAM реализована возможность подключения внешних модулей , написанных на каком-либо языке , совместимым по вызовам функций с языком C. С точки зрения реализации логики приложения JAM является событийно-ориентированной системой . В JAM определен набор событий , включающий открытие и закрытие окон , на жатие клавиши клавиатуры , срабатывание системного таймера , получение и передача управления каждым элементом экрана . Разработчик реализует логику приложения путем определения обработчика каждого события . Например , обработчик события "нажатие кнопки на экра н е " (мышью или с помощью клавиатуры ) может открыть следующее экранное окно . Обработчиками событий в JAM могут быть как встроенные функции JAM, так и функции , написанные разработчиком на C или JPL. Набор встроенных функций включает в себя более 200 функций р азличного назначения . Встроенные функции доступны для вызовов из функций , написанных как на JPL, так и на C. Промышленная версия приложения , разработанного с помощью JAM, включает в себя следующие компоненты : · исполняемый модуль интерпретатора приложен ия . В этот модуль могут быть встроены функции , написанные разработчиками на языках 3-го поколения ; · экраны , составляющие само приложение (могут поставляться в виде отдельных файлов , в составе библиотек экранов или же быть встроены в тело интерпретатора ) ; · внешние JPL-модули . Могут поставляться в виде текстовых файлов или в прекомпилированном виде , причем прекомпилированные внешние JPL-модули могут быть как в виде отдельных файлов , так и в составе библиотек экранов ; · файлы конфигурации приложения - файлы конфигурации клавиатуры и терминала , файл системных сообщений , файл общей конфигурации. Взаимодействие с другими средствами Непосредственное взаимодействие с СУБД реализуют модули JAM/DBi (Data Base interface). Способы реализации взаимодействия в JA M разделяются на два класса : ручные и автоматические . При ручном способе разработчик приложения самостоятельно пишет запросы на SQL, в которых как источниками , так и адресатами приема результатов выполнения запроса могут быть как интерфейсные элементы виз у ально спроектированного внешнего уровня , так и внутренние , невидимые для конечного пользователя переменные . Автоматический режим , реализуемый менеджером транзакций JAM, осуществим для типовых и наиболее распространенных видов операций с БД , так называемых QBE (Query By Example - запросы по образцу ), с учетом достаточно сложных взаимосвязей между таблицами БД и автоматическим управлением атрибутами экранных полей ввода /вывода в зависимости от вида транзакции (чтение , запись и т.д .), в которой участвует сген е рированный запрос . JAM позволяет строить приложения для работы более чем с 20 СУБД : ORACLE, Informix, Sybase, Ingres, InterBase, NetWare SQL Server, Rdb, DB2, ODBC-совместимые СУБД и др . Отличительной чертой JAM является высокий уровень переносимости при ложений между различными платформами (MS DOS/MS Windows, SunOS, Solaris (i80x86, SPARC), HP-UX, AIX, VMS/Open VMS и др .). Может потребоваться лишь "перерисовать " статические текстовые поля на экранах с русским текстом при переносе между средами DOS-Window s -UNIX. Кроме того , переносимость облегчается тем , что в JAM приложения разрабатываются для виртуальных устройств ввода /вывода , а не для физических . Таким образом при переносе приложения с платформы на платформу , как правило , требуется лишь определить соот в етствие между физическими устройствами ввода /вывода и их логическими представлениями для приложения . Использование SQL в качестве средства взаимодействия с СУБД также создает предпосылки для обеспечения переносимости между СУБД . При условии переноса струк туры самой БД в ряде случаев приложения могут не требовать никакой модификации , за исключением инициализации сеанса работы . Такая ситуация может сложиться в том случае , если в приложении не использовались специфические для той или иной СУБД расширения SQL. При росте нагрузки на систему и сложности решаемых задач (распределенность и гетерогенность используемых ресурсов , количество одновременно подключенных пользователей , сложность логики приложения ) применяется трехзвенная модель архитектуры "клиент-сервер " с использованием менеджеров транзакций . Компоненты JAM/TPi-Client и JAM/TPi-Server позволяют достаточно просто перейти на трехзвенную модель . При этом ключевую роль играет модуль JAM/TPi-Server, так как основная трудность внедрения трехзвенной модели зак л ючается в реализации логики приложения в сервисах менеджеров транзакций . Интерфейс JAM/CASE подобен интерфейсу к СУБД и позволяет осуществить обмен информацией между репозиторием объектов JAM и репозиторием CASE-средства аналогично тому , как структура БД импортируется в репозиторий JAM непосредственно из БД . Отличие заключается в том , что в случае интерфейса к CASE этот обмен является двунаправленным . Кроме модулей JAM/CASEi, существует также модуль JAM/CASEi Developer's Kit. С помощью этого модуля можно с амостоятельно разработать интерфейс (т.е . специализированный модуль JAM/CASEi) для конкретного CASE-средства , если готового модуля JAM/CASEi для него не существует . Мост (интерфейс ) Silverrun-RDM <-> JAM реализует взаимодействие между CASE-средством Silve rrun и JAM (перенос схемы базы данных и экранных форм приложения между CASE-средством Silverrun-RDM и JAM версии 7.0). Данный программный продукт имеет 2 режима работы : · прямой режим (Silverrun-RDM->JAM) предназначен для создания объектов CASE-словаря и элементов репозитория JAM на основе представления схем в Silverrun-RDM. В этом режиме мост позволяет , исходя из представления моделей данных интерфейса в Silverrun-RDM, производить генерацию экранов и элементов репозитория JAM. Мост преобразует таблицы и отношения реляционных схем RDM в последовательность объектов JAM соответствующих типов . Методика построения моделей данных интерфейса в Silverrun-RDM предполагает применение механизма подсхем для прототипирования экранов приложения . По описанию каждой из п одсхем RDM мост генерирует экранную форму JAM; · обратный режим (JAM->Silverrun-RDM) предназначен для переноса модификаций объектов CASE-словаря в реляционную модель Silverrun-RDM. Режим реинжиниринга позволяет переносить модификации всех свойств экранов JAM, импортированных ранее из RDM, в схему Silverrun. На этом этапе для контроля целостности базы данных не допускаются изменения схемы в виде добавления или удаления таблиц и полей таблиц . Групповая работа Ядро JAM имеет встроенный интерфейс к средства м конфигурационного управления (PVCS на платформе Windows и SCCS на платформе UNIX). Под управлением этих систем передаются библиотеки экранов и /или репозитории . При отсутствии таких систем JAM самостоятельно реализует часть функций поддержки групповой ра з работки . Использование PVCS (см . подраздел 3.6) является более предпочтительным по сравнению с SCCS, так как позволяет организовать единый архив модулей проекта для всех платформ . Так как JAM на платформе UNIX не имеет прямого интерфейса к архивам PVCS, т о выборка модулей из архива и возврат их в архив производятся с использованием PVCS Version Manager. На платформе MS-Windows JAM имеет встроенный интерфейс к PVCS и действия по выборке /возврату производятся непосредственно из среды JAM. Среда функциониров ания JAM, как среда разработки , и приложения , построенные с его использованием , не являются ресурсоемкими системами . Например , на платформе MS-Windows достаточно иметь 8MB оперативной памяти и 50 MB дискового пространства для среды разработки . На UNIX-пла тформах требования к аппаратуре определяются самой операционной системой . 3.2. Vantage Team Builder (Westmount I-CASE) + Uniface 3.2.1. Vantage Team Builder (Westmount I-CASE) Vantage Team Builder [14] представляет собой интегрированный программный продук т , ориентированный на реализацию каскадной модели ЖЦ ПО и поддержку полного ЖЦ ПО . Структура и функции Vantage Team Builder обеспечивает выполнение следующих функций : · проектирование диаграмм потоков данных , "сущность-связь ", структур данных , структур ных схем программ и последовательностей экранных форм ; · проектирование диаграмм архитектуры системы - SAD (проектирование состава и связи вычислительных средств , распределения задач системы между вычислительными средствами , моделирование отношений типа "клиент-сервер ", анализ использования менеджеров транзакций и особенностей функционирования систем в реальном времени ); · генерация кода программ на языке 4GL целевой СУБД с полным обеспечением программной среды и генерация SQL-кода для создания таблиц Б Д , индексов , ограничений целостности и хранимых процедур ; · программирование на языке C со встроенным SQL; · управление версиями и конфигурацией проекта ; · многопользовательский доступ к репозиторию проекта ; · генерация проектной документации по ст андартным и индивидуальным шаблонам ; · экспорт и импорт данных проекта в формате CDIF (CASE Data Interchange Format). Vantage Team Builder поставляется в различных конфигурациях в зависимости от используемых СУБД (ORACLE, Informix, Sybase или Ingres) или средств разработки приложений (Uniface). Конфигурация Vantage Team Builder for Uniface отличается от остальных некоторой степенью ориентации на спиральную модель ЖЦ ПО за счет возможностей быстрого прототипирования , предоставляемых Uniface. Для описания п роекта ИС используется достаточно большой набор диаграмм , конкретные варианты которого для наиболее распространенных конфигураций приведены ниже в таблице. Тип диаграммы Обозначение Vantage Team Builder for ORACLE Vantage Team Builder for Informix Vantage Team Builder for Uniface Сущность-связь ERD + + + Потоков данных DFD + + + Структур данных DSD + + + Архитектуры системы SAD + + + Потоков управления CSD + + + Типов данных DTD + + + Структуры меню MSD + Последовательности блоков BSD + Последовательности форм FSD + + Содержимого форм FCD + + Переходов состояний STD + + + Структурных схем SCD + + + При построении всех типов диаграмм обеспечивается контроль соответствия моделей синтаксису используемых методов , а также контроль соотв етствия одноименных элементов и их типов для различных типов диаграмм . При построении DFD обеспечивается контроль соответствия диаграмм различных уровней декомпозиции . Контроль за правильностью верхнего уровня DFD осуществляется с помощью матрицы списков событий (ELM). Для контроля за декомпозицией составных потоков данных используется несколько вариантов их описания : в виде диаграмм структур данных (DSD) или в нотации БНФ (форма Бэкуса-Наура ). Для построения SAD используется расширенная нотация DFD, дающ ая возможность вводить понятия процессоров , задач и периферийных устройств , что обеспечивает наглядность проектных решений . При построении модели данных в виде ERD выполняется ее нормализация и вводится определение физических имен элементов данных и табли ц , которые будут использоваться в процессе генерации физической схемы данных конкретной СУБД . Обеспечивается возможность определения альтернативных ключей сущностей и полей , составляющих дополнительные точки входа в таблицу (поля индексов ), и мощности отн о шений между сущностями . Наличие универсальной системы генерации кода , основанной на специфицированных средствах доступа к репозиторию проекта , позволяет поддерживать высокий уровень исполнения проектной дисциплины разработчиками : жесткий порядок формирова ния моделей ; жесткая структура и содержимое документации ; автоматическая генерация исходных кодов программ и т.д . - все это обеспечивает повышение качества и надежности разрабатываемых ИС . Для подготовки проектной документации могут использоваться издател ьские системы FrameMaker, Interleaf или Word Perfect. Структура и состав проектной документации могут быть настроены в соответствии с заданными стандартами . Настройка выполняется без изменения проектных решений . При разработке достаточно крупной ИС вся си стема в целом соответствует одному проекту как категории Vantage Team Builder. Проект может быть декомпозирован на ряд систем , каждая из которых соответствует некоторой относительно автономной подсистеме ИС и разрабатывается независимо от других . В дальне й шем системы проекта могут быть интегрированы . Процесс проектирования ИС с использованием Vantage Team Builder реализуется в виде 4-х последовательных фаз (стадий ) - анализа , архитектуры , проектирования и реализации , при этом законченные результаты каждой стадии полностью или частично переносятся (импортируются ) в следующую фазу . Все диаграммы , кроме ERD, преобразуются в другой тип или изменяют вид в соответствии с особенностями текущей фазы . Так , DFD преобразуются в фазе архитектуры в SAD, DSD - в DTD. По с ле завершения импорта логическая связь с предыдущей фазой разрывается , т.е . в диаграммы могут вноситься все необходимые изменения . Взаимодействие с другими средствами Конфигурация Vantage Team Builder for Uniface обеспечивает совместное использование дву х систем в рамках единой технологической среды проектирования , при этом схемы БД (SQL-модели ) переносятся в репозиторий Uniface, и , наоборот , прикладные модели , сформированные средствами Uniface, могут быть перенесены в репозиторий Vantage Team Builder. В о зможные рассогласования между репозиториями двух систем устраняются с помощью специальной утилиты . Разработка экранных форм в среде Uniface выполняется на базе диаграмм последовательностей форм (FSD) после импорта SQL-модели . Технология разработки ИС на б а зе данной конфигурации показана на рисунке 3.1. Структура репозитория (хранящегося непосредственно в целевой СУБД ) и интерфейсы Vantage Team Builder являются открытыми , что в принципе позволяет интеграцию с любыми другими средствами . Среда функционирован ия Vantage Team Builder функционирует на всех основных UNIX-платформах (Solaris, SCO UNIX, AIX, HP-UX) и VMS. Vantage Team Builder можно использовать в конфигурации "клиент-сервер ", при этом база проектных данных может располагаться на сервере , а рабочие места разработчиков могут быть клиентами . Рис . 3.1. Взаимодействие Vantage Team Builder и Uniface 3.2.2. Uniface Uniface 6.1 [15] - продукт фирмы Compuware (США ) - представляет собой среду разработки крупномасштабных приложений в архитектуре "клиент-сервер " и и меет следующую компонентную архитектуру : · Application Objects Repository (репозиторий объектов приложений ) содержит метаданные , автоматически используемые всеми остальными компонентами на протяжении жизненного цикла ИС (прикладные модели , описания данны х , бизнес-правил , экранных форм , глобальных объектов и шаблонов ). Репозиторий может храниться в любой из баз данных , поддерживаемых Uniface; · Application Model Manager поддерживает прикладные модели (E-R модели ), каждая из которых представляет собой под множество общей схемы БД с точки зрения данного приложения , и включает соответствующий графический редактор ; · Rapid Application Builder - средство быстрого создания экранных форм и отчетов на базе объектов прикладной модели . Оно включает графический ред актор форм , средства прототипирования , отладки , тестирования и документирования . Реализован интерфейс с разнообразными типами оконных элементов управления (Open Widget Interface) для существующих графических интерфейсов - MS Windows (включая VBX), Motif, O S/2. Универсальный интерфейс представления (Universal Presentation Interface) позволяет использовать одну и ту же версию приложения в среде различных графических интерфейсов без изменения программного кода ; · Developer Services (службы разработчика ) - ис пользуются для поддержки крупных проектов и реализуют контроль версий (Uniface Version Control System), права доступа (разграничение полномочий ), глобальные модификации и т.д . Это обеспечивает разработчиков средствами параллельного проектирования , входног о и выходного контроля , поиска , просмотра , поддержки и выдачи отчетов по данным системы контроля версий ; · Deployment Manager (управление распространением приложений ) - средства , позволяющие подготовить созданное приложение для распространения , устанавлив ать и сопровождать его (при этом платформа пользователя может отличаться от платформы разработчика ). В их состав входят сетевые драйверы и драйверы СУБД , сервер приложений (полисервер ), средства распространения приложений и управления базами данных . Unifa c e поддерживает интерфейс практически со всеми известными программно-аппаратными платформами , СУБД , CASE-средствами , сетевыми протоколами и менеджерами транзакций ; · Personal Series (персональные средства ) - используются для создания сложных запросов и от четов в графической форме (Personal Query и Personal Access - PQ/PA), а также для переноса данных в такие системы , как WinWord и Excel; · Distributed Computing Manager - средство интеграции с менеджерами транзакций Tuxedo, Encina, CICS, OSF DCE. Объявлен ная в конце 1996 г . версия Uniface 7 полностью поддерживает распределенную модель вычислений и трехзвенную архитектуру "клиент-сервер " (с возможностью изменения схемы декомпозиции приложений на этапе исполнения ). Приложения , создаваемые с помощью Uniface 7 , могут исполняться в гетерогенных операционных средах , использующих различные сетевые протоколы , одновременно на нескольких разнородных платформах (в том числе и в Internet). В состав компонент Uniface 7 входят : · Uniface Application Server - сервер пр иложений для распределенных систем ; · WebEnabler - серверное ПО для эксплуатации приложений в Internet и Intrа net; · Name Server - серверное ПО , обеспечивающее использование распределенных прикладных ресурсов ; · PolyServer - средство доступа к данным и интеграции различных систем. В список поддерживаемых СУБД входят DB2, VSAM и IMS; PolyServer обеспечивает также взаимодействие с ОС MVS. Среда функционирования Uniface - все основные UNIX - платформы и MS Windows. 3.3. Designer/2000 + Developer/2000 C ASE-средство Designer/2000 2.0 фирмы ORACLE [23] является интегрированным CASE-средством , обеспечивающим в совокупности со средствами разработки приложений Developer/2000 поддержку полного ЖЦ ПО для систем , использующих СУБД ORACLE. Структура и функции D esigner/2000 представляет собой семейство методологий и поддерживающих их программных продуктов . Базовая методология Designer/2000 (CASE*Method) - структурная методология проектирования систем , полностью охватывающая все этапы жизненного цикла ИС [8,9]. В соответствии с этой методологией на этапе планирования определяются цели создания системы , приоритеты и ограничения , разрабатывается системная архитектура и план разработки ИС . В процессе анализа строятся модель информационных потребностей (диаграмма "сущ н ость-связь "), диаграмма функциональной иерархии (на основе функциональной декомпозиции ИС ), матрица перекрестных ссылок и диаграмма потоков данных . На этапе проектирования разрабатывается подробная архитектура ИС , проектируется схема реляционной БД и прог раммные модули , устанавливаются перекрестные ссылки между компонентами ИС для анализа их взаимного влияния и контроля за изменениями . На этапе реализации создается БД , строятся прикладные системы , производится их тестирование , проверка качества и соответс твия требованиям пользователей . Создается системная документация , материалы для обучения и руководства пользователей . На этапах эксплуатации и сопровождения анализируются производительность и целостность системы , выполняется поддержка и , при необходимости, модификация ИС ; Designer/2000 обеспечивает графический интерфейс при разработке различных моделей (диаграмм ) предметной области . В процессе построения моделей информация о них заносится в репозиторий . В состав Designer/2000 входят следующие компоненты : · Repository Administrator - средства управления репозиторием (создание и удаление приложений , управление доступом к данным со стороны различных пользователей , экспорт и импорт данных ); · Repository Object Navigator - средства доступа к репозиторию , обе спечивающие многооконный объектно-ориентированный интерфейс доступа ко всем элементам репозитория ; · Process Modeller - средство анализа и моделирования деловой деятельности , основывающееся на концепциях реинжиниринга бизнес-процессов (BPR - Business Pro cess Reengineering) и глобальной системы управления качеством (TQM - Total Quality Management); · Systems Modeller - набор средств построения функциональных и информационных моделей проектируемой ИС , включающий средства для построения диаграмм "сущность- связь " (Entity-Relationship Diagrammer), диаграмм функциональных иерархий (Function Hierarchy Diagrammer), диаграмм потоков данных (Data Flow Diagrammer) и средство анализа и модификации связей объектов репозитория различных типов (Matrix Diagrammer); · Systems Designer - набор средств проектирования ИС , включающий средство построения структуры реляционной базы данных (Data Diagrammer), а также средства построения диаграмм , отображающих взаимодействие с данными , иерархию , структуру и логику приложений , р е ализуемую хранимыми процедурами на языке PL/SQL (Module Data Diagrammer, Module Structure Diagrammer и Module Logic Navigator); · Server Generator - генератор описаний объектов БД ORACLE (таблиц , индексов , ключей , последовательностей и т.д .). Помимо прод уктов ORACLE, генерация и реинжиниринг БД может выполняться для СУБД Informix, DB/2, Microsoft SQL Server, Sybase, а также для стандарта ANSI SQL DDL и баз данных , доступ к которым реализуется посредством ODBC; · Forms Generator (генератор приложений для ORACLE Forms). Генерируемые приложения включают в себя различные экранные формы , средства контроля данных , проверки ограничений целостности и автоматические подсказки . Дальнейшая работа с приложением выполняется в среде Developer/2000; · Repository Repo rts - генератор стандартных отчетов , интегрированный с ORACLE Reports и позволяющий русифицировать отчеты , а также изменять структурное представление информации. Репозиторий Designer/2000 представляет собой хранилище всех проектных данных и может работать в многопользовательском режиме , обеспечивая параллельное обновление информации несколькими разработчиками . В процессе проектирования автоматически поддерживаются перекрестные ссылки между объектами словаря и могут генерироваться более 70 стандартных отчет о в о моделируемой предметной области . Физическая среда хранения репозитория - база данных ORACLE. Генерация приложений , помимо продуктов ORACLE, выполняется также для Visual Basic. Взаимодействие с другими средствами Designer/2000 можно интегрировать с д ругими средствами , используя открытый интерфейс приложений API (Application Programming Interface). Кроме того , можно использовать средство ORACLE CASE Exchange для экспорта /импорта объектов репозитория с целью обмена информацией с другими CASE-средствами. Developer/2000 обеспечивает разработку переносимых приложений , работающих в графической среде Windows, Macintosh или Motif. В среде Windows интеграция приложений Developer/2000 с другими средствами реализуется через механизм OLE и управляющие элементы VB X. Взаимодействие приложений с другими СУБД (DB/2, DB2/400, Rdb) реализуется с помощью средств ORACLE Client Adapter для ODBC, ORACLE Open Gateway и API. Среда функционирования Среда функционирования Designer/2000 и Developer/2000 - Windows 3.x, Windows 95, Windows NT. 3.4. Локальные средства (ERwin, BPwin, S-Designor, CASE.Аналитик ) ERwin - средство концептуального моделирования БД [24], использующее методологию IDEF1X (см . подраздел 2.5). ERwin реализует проектирование схемы БД , генерацию ее описания н а языке целевой СУБД (ORACLE, Informix, Ingres, Sybase, DB/2, Microsoft SQL Server, Progress и др .) и реинжиниринг существующей БД . ERwin выпускается в нескольких различных конфигурациях , ориентированных на наиболее распространенные средства разработки пр и ложений 4GL. Версия ERwin/OPEN полностью совместима со средствами разработки приложений PowerBuilder и SQLWindows и позволяет экспортировать описание спроектированной БД непосредственно в репозитории данных средств . Для ряда средств разработки приложений (PowerBuilder, SQLWindows, Delphi, Visual Basic) выполняется генерация форм и прототипов приложений . Сетевая версия Erwin ModelMart обеспечивает согласованное проектирование БД и приложений в рамках рабочей группы . BPwin - средство функционального модели рования , реализующее методологию IDEF0 (см . подраздел 2.2). Возможные конфигурации и ориентировочная стоимость средств (без технической поддержки ) приведены в таблице. Конфигурация Стоимость , $ ERwin/ERX 3,295 Bpwin 2,495 ERwin/ERX for PowerBuilder, Visual Basic, Progress 3,495 ERwin/ERX for Delphi 4,295 ERwin/Desktop for PowerBuilder, Visual Basic 495 ERwin/ERX for SQLWindows / Designer/2000 / Solaris 3,495 / 5,795 / 6,995 ModelMart 5 / 10 user 11,995 / 19,995 Erwin/OPEN for ModelMart 3,995 S-Designor 4.2 представляет собой CASE-средство для проектирования реляционных баз данных [25]. По своим функциональным возможностям и стоимости он близок к CASE-средству ERwin, отличаясь внешне используемой на диаграммах но тацией . S-Designor реализует стандартную методологию моделирования данных и генерирует описание БД для таких СУБД , как ORACLE, Informix, Ingres, Sybase, DB/2, Microsoft SQL Server и др . Для существующих систем выполняется реинжиниринг БД . S-Designor совме стим с рядом средств разработки приложений (PowerBuilder, Uniface, TeamWindows и др .) и позволяет экспортировать описание БД в репозитории данных средств . Для PowerBuilder выполняется также прямая генерация шаблонов приложений . CASE.Аналитик 1.1 [3] являе тся практически единственным в настоящее время конкурентоспособным отечественным CASE-средством функционального моделирования и реализует построение диаграмм потоков данных в соответствии с методологией , описанной в подразделе 2.3. Его основные функции : · построение и редактирование DFD; · анализ диаграмм и проектных спецификаций на полноту и непротиворечивость ; · получение разнообразных отчетов по проекту ; · генерация макетов документов в соответствии с требованиями ГОСТ 19.ХХХ и 34.ХХХ. Среда функ ционирования : процессор - 386 и выше , основная память - 4 Мб , дисковая память - 5 Мб , MS Windows 3.x или Windows 95. Ориентировочная стоимость : · однопользовательская версия - 605 $; · многопользовательская версия (одно рабочее место ) - 535 $. База да нных проекта реализована в формате СУБД Paradox и является открытой для доступа . С помощью отдельного программного продукта (Catherine) выполняется обмен данными с CASE-средством ERwin. При этом из проекта , выполненного в CASE.Аналитике , экспортируется оп исание структур данных и накопителей данных , которое по определенным правилам формирует описание сущностей и их атрибутов . 3.5. Объектно-ориентированные CASE-средства (Rational Rose) Rational Rose - CASE-средство фирмы Rational Software Corporation (США ) - предназначено для автоматизации этапов анализа и проектирования ПО , а также для генерации кодов на различных языках и выпуска проектной документации [21]. Rational Rose использует синтез-методологию объектно-ориентированного анализа и проектирования , ос н ованную на подходах трех ведущих специалистов в данной области : Буча , Рамбо и Джекобсона . Разработанная ими универсальная нотация для моделирования объектов (UML - Unified Modeling Language) претендует на роль стандарта в области объектно-ориентированного анализа и проектирования . Конкретный вариант Rational Rose определяется языком , на котором генерируются коды программ (C++, Smalltalk, PowerBuilder, Ada, SQLWindows и ObjectPro). Основной вариант - Rational Rose/C++ - позволяет разрабатывать проектную док у ментацию в виде диаграмм и спецификаций , а также генерировать программные коды на С ++. Кроме того , Rational Rose содержит средства реинжиниринга программ , обеспечивающие повторное использование программных компонент в новых проектах . Структура и функции В основе работы Rational Rose лежит построение различного рода диаграмм и спецификаций , определяющих логическую и физическую структуры модели , ее статические и динамические аспекты . В их число входят диаграммы классов , состояний , сценариев , модулей , проце с сов [21]. В составе Rational Rose можно выделить 6 основных структурных компонент : репозиторий , графический интерфейс пользователя , средства просмотра проекта (browser), средства контроля проекта , средства сбора статистики и генератор документов . К ним до бавляются генератор кодов (индивидуальный для каждого языка ) и анализатор для С ++, обеспечивающий реинжиниринг - восстановление модели проекта по исходным текстам программ . Репозиторий представляет собой объектно-ориентированную базу данных . Средства прос мотра обеспечивают "навигацию " по проекту , в том числе , перемещение по иерархиям классов и подсистем , переключение от одного вида диаграмм к другому и т . д . Средства контроля и сбора статистики дают возможность находить и устранять ошибки по мере развития проекта , а не после завершения его описания . Генератор отчетов формирует тексты выходных документов на основе содержащейся в репозитории информации . Средства автоматической генерации кодов программ на языке С ++, используя информацию , содержащуюся в логиче ской и физической моделях проекта , формируют файлы заголовков и файлы описаний классов и объектов . Создаваемый таким образом скелет программы может быть уточнен путем прямого программирования на языке С ++. Анализатор кодов С ++ реализован в виде отдельного программного модуля . Его назначение состоит в том , чтобы создавать модули проектов в форме Rational Rose на основе информации , содержащейся в определяемых пользователем исходных текстах на С ++. В процессе работы анализатор осуществляет контроль правильнос т и исходных текстов и диагностику ошибок . Модель , полученная в результате его работы , может целиком или фрагментарно использоваться в различных проектах . Анализатор обладает широкими возможностями настройки по входу и выходу . Например , можно определить тип ы исходных файлов , базовый компилятор , задать , какая информация должна быть включена в формируемую модель и какие элементы выходной модели следует выводить на экран . Таким образом , Rational Rose/С ++ обеспечивает возможность повторного использования програм м ных компонент . В результате разработки проекта с помощью CASE-средства Rational Rose формируются следующие документы : · диаграммы классов ; · диаграммы состояний ; · диаграммы сценариев ; · диаграммы модулей ; · диаграммы процессов ; · спецификации классов , объектов , атрибутов и операций · заготовки текстов программ ; · модель разрабатываемой программной системы. Последний из перечисленных документов является текстовым файлом , содержащим всю необходимую информацию о проекте (в том числе необходим ую для получения всех диаграмм и спецификаций ). Тексты программ являются заготовками для последующей работы программистов . Они формируются в рабочем каталоге в виде файлов типов .h (заголовки , содержащие описания классов ) и .cpp (заготовки программ для ме тодов ). Система включает в программные файлы собственные комментарии , которые начинаются с последовательности символов //##. Состав информации , включаемой в программные файлы , определяется либо по умолчанию , либо по усмотрению пользователя . В дальнейшем э т и исходные тексты развиваются программистами в полноценные программы . Взаимодействие с другими средствами и организация групповой работы Rational Rose интегрируется со средством PVCS для организации групповой работы и управления проектом и со средством S oDA - для документирования проектов . Интеграция Rational Rose и SoDA обеспечивается средствами SoDA. Для организации групповой работы в Rational Rose возможно разбиение модели на управляемые подмодели . Каждая из них независимо сохраняется на диске или заг ружается в модель . В качестве подмодели может выступать категория классов или подсистема . Для управляемой подмодели предусмотрены операции : · загрузка подмодели в память ; · выгрузка подмодели из памяти ; · сохранение подмодели на диске в виде отдельн ого файла ; · установка защиты от модификации ; · замена подмодели в памяти на новую. Наиболее эффективно групповая работа организуется при интеграции Rational Rose со специальными средствами управления конфигурацией и контроля версий (PVCS). В этом случ ае защита от модификации устанавливается на все управляемые подмодели , кроме тех , которые выделены конкретному разработчику . В этом случае признак защиты от записи устанавливается для файлов , которые содержат подмодели , поэтому при считывании "чужих " подм о делей защита их от модификации сохраняется и случайные воздействия окажутся невозможными . Среда функционирования Rational Rose функционирует на различных платформах : IBM PC (в среде Windows), Sun SPARC stations (UNIX, Solaris, SunOS), Hewlett-Packard (HP UX), IBM RS/6000 (AIX). Для работы системы необходимо выполнение следующих требований : · Платформа Windows - процессор 80386SX или выше (рекомендуется 80486), память 8Mб (рекоменду ется 12Mб ), пространство на диске 8Mб + 1-3Mб для одной модели . · Платформа UNIX - память 32+(16*число пользователей )Mб , пространство на диске 30Mб + 20 при инсталляции + 1-3Mб для одной модели. Совместимость по версиям обеспечивается на уровне моделей . 3.6. Вспомогательные средства поддержки жизненного цикла ПО 3.6.1. Средства конфигурационного управления Цель конфигурационного управления (КУ ) - обеспечить управляемость и контролируемость процессов разработки и сопровождения ПО . Для этого необходима точ ная и достоверная информация о состоянии ПО и его компонент в каждый момент времени , а также о всех предполагаемых и выполненных изменениях . Для решения задач КУ применяются методы и средства обеспечивающие идентификацию состояния компонент , учет номенкла туры всех компонент и модификаций системы в целом , контроль за вносимыми изменениями в компоненты , структуру системы и ее функции , а также координированное управление развитием функций и улучшением характеристик системы . Наиболее распространенным средство м КУ является PVCS фирмы Intersolv (США ), включающее ряд самостоятельных продуктов : PVCS Version Manager, PVCS Tracker, PVCS Configuration Builder и PVCS Notify. PVCS Version Manager [18] предназначен для управления всеми компонентами проекта и ведения пл аномерной многоверсионной и многоплатформенной разработки силами команды разработчиков в условиях одной или нескольких локальных сетей . Понятие "проект " трактуется как совокупность файлов . В процессе работы над проектом промежуточное состояние файлов пери о дически сохраняется в архиве проекта , ведутся записи о времени сохранения , соответствии друг другу нескольких вариантов разных файлов проекта . Кроме этого , фиксируются имена разработчиков , ответственных за тот или иной файл , состав файлов промежуточных ве р сий проекта и др . Это позволяет вернуться при необходимости к какому-либо из предыдущих состояний файла (например , при обнаружении ошибки , которую в данный момент трудно исправить ). PVCS Version Manager предназначен для использования в рабочих группах . Си стема блокировок , реализованная в PVCS Version Manager позволяет предотвратить одновременное внесение изменений в один и тот же файл . В то же время , PVCS Version Manager позволяет разработчикам работать с собственными версиями общего файла с полуавтоматич е ским разрешением конфликтов между ними . Доступ к архивам PVCS Version Manager возможен не только через сам Version Manager, но и из более чем 50 инструментальных средств , в том числе MS Visual C и MS Visual Basic, Uniface, PowerBuilder, SQL Windows, JAM, Delphi, Paradox и др . Результатом работы PVCS Version Manager является созданный средствами файловой системы репозиторий , хранящий в компактной форме все рабочие версии программного продукта вместе с необходимыми комментариями и метками . PVCS Version Man ager функционирует в среде MS Windows, Windows 95, Windows NT, OS/2, SunOS, Solaris, HP-UX, AIX и SCO UNIX и может исполняться на любом персональном компьютере с процессором 80386 или выше , рабочих станциях Sun, HP и IBM (RS-6000). Другим средством конфиг урационного управления является PVCS Tracker [19] - специализированная надстройка над офисной электронной почтой , предназначенная для обработки сообщений об ошибках в продукте , доставке их исполнителям и контроля за исполнением . Интеграция с PVCS Version M anager дает возможность связывать с сообщениями те или иные компоненты проекта . Отчетные возможности PVCS Tracker включают множество разновидностей графиков и диаграмм , отражающих состояние проекта и процесса его отладки , срезы по различным компонентам пр о екта , разработчикам и тестировщикам . С их помощью можно наглядно показать текущее состояние работы над проектом и ее временные тенденции . Персонал , работающий с PVCS Tracker делится на пять групп в зависимости от их обязанностей : пользователи , разработчик и , группа тестирования и контроля качества , группа технической поддержки и сопровождения , управленческий персонал . Этим пяти группам персонала соответствуют пять предопределенных групп PVCS Tracker: · пользователи (Submitters) - имеют ограниченные права на внесение замечаний и сообщений об ошибках в базу данных PVCS Tracker; · разработчики (Development Engineers) - имеют право производить основные операции с требованиями и замечаниями в базе данных PVCS Tracker. Если разработчики делятся на подгруппы , т о для каждой подгруппы могут быть заданы отдельные списки прав доступа ; · тестировщики (Quality Engineers) - имеют право производить основные операции с требованиями и замечаниями ; · сопровождение (Support Engineers) - имеют право вносить любые замечан ия , требования и рекомендации в базу данных , но не имеют прав по распределению работ и изменению их приоритетности и сроков исполнения ; · руководители (Managers) - имеют право распределять работы между исполнителями и принимать решения о их надлежащем ис полнении . Руководителям разных групп могут заданы различные права доступа к базе данных PVCS Tracker. В дополнение к этим пяти предопределенным группам , существует группа администратора базы данных и 11 дополнительных групп , которые могут быть настроены в соответствии со специфическими должностными обязанностями сотрудников , использующих PVCS Tracker. Требование или замечание поступающее в PVCS Tracker проходит четыре этапа обработки : · регистрация - внесение замечания в базу данных ; · распределение - назначение ответственного исполнителя и сроков исполнения ; · исполнение - устранение замечания , которое в свою очередь может вызвать дополнительные замечания или требования на дополнительные работы ; · приемка - приемка работ и снятие их с контроля или направление на доработку. Требования и замечания , поступающие в базу данных PVCS Tracker оформляются в виде специальной формы , которая может содержать до 18 полей выбора стандартных значений и до 12 произвольных текстовых строк . При разработке формы следуе т определить оптимальный набор информации , характерный для всех записей в базе данных . Для получения содержательной информации о ходе разработки PVCS Tracker позволяет получать три типа статистических отчетов : частотные , тренды и диаграммы распределения . Частотные отчеты содержат информацию о частоте поступающих замечаний за один час тестирования программного продукта . Однако универсального частотного отчета не существует , т.к . на оценку качества влияют тип методов тестирования , серьезность выявленных оши бок и значение дефектных модулей для функционирования всей системы . Малое число фатальных ошибок , приводящих к полной остановке разработки , хуже большого числа замечаний к внешнему виду интерфейса пользователя . Следовательно , частотные отчеты должны быть н астроены на выявление какого-либо конкретного аспекта качества для того , чтобы их можно было использовать для прогнозирования окончания работ над проектом . Тренды содержат информацию об изменениях того или иного показателя во времени и характеризуют стаби льность и непрерывность процесса разработки . Они позволяют ответить на вопросы : · успевает ли группа разработчиков справляться с поступающими замечаниями ; · улучшается ли качество программного продукта и какова динамика этого процесса ; · как повлияло то или иное решение (увеличение числа разработчиков , введение скользящего графика , внедрение нового метода тестирования ) на работу группы и т.п. Диаграммы распределения - наиболее разнообразные и полезные для осуществления оперативного руководства формы о тчетов . Они позволяют ответить на вопросы : какой метод тестирования более эффективен , какие модули вызывают наибольшее число нареканий , кто из разработчиков лучше справляется с конкретным типом заданий , нет ли перекоса в распределении работ между исполнит е лями , нет ли модулей , тестированию которых было уделено недостаточно внимания и т.д . PVCS Tracker предназначен для использования в рабочих группах , объединенных в общую сеть . В этом случае центральная база или проект PVCS Tracker находится на общедоступно м сервере сети , доступ к которому реализуется посредством ODBC-драйверов , входящих в состав PVCS Tracker. Главной особенностью PVCS Tracker по сравнению с обычным приложением СУБД является его способность автоматически уведомлять пользователя о поступлени и интересующей его или относящейся к его компетенции информации и гибкая система распределения полномочий внутри рабочей группы . При необходимости PVCS Tracker может использовать для уведомления удаленных членов группы электронную почту . PVCS Tracker подде рживает групповую работу в локальных сетях и взаимодействует с СУБД dBase, ORACLE, SQL Server и SYBASE посредством ODBC. PVCS Tracker может быть интегрирован с любой системой электронной почты , поддерживающей стандарты VIM, MAPI или SMTP. PVCS Version Ma nager и PVCS Tracker окружены вспомогательными компонентами : PVCS Configuration Builder и PVCS Notify. PVCS Configuration Builder предназначен для сборки окончательного продукта из компонент проекта . PVCS Configuration Builder позволяет описывать процесс сборки как на стандартном языке MAKE, так и на собственном внутреннем языке , имеющем существенно большие возможности . PVCS Configuration Builder позволяет осуществлять сборку программного продукта на основании файлов , хранящихся в репозитории PVCS Version Manager. Обычная процедура сборки программного продукта с помощью PVCS Configuration Builder состоит из трех шагов : · строится файл зависимостей между исходными модулями ; · в полученный файл вносятся изменения с целью его настройки и оптимизации ; · осуществляется сборка программного продукта из исходных модулей. Результатом работы PVCS Configuration Builder является специальный файл , описывающий оптимальный алгоритм сборки программного продукта , построенный на основе анализа дерева зависимостей между исходными модулями . PVCS Notify обеспечивает автоматическую рассылку сообщений об ошибках из базы данных пакета PVCS Tracker по рабочим станциям назначения . При этом используется офисная система электронной почты cc:Mail или Microsoft Mail. PVCS Notify р асширяет возможности PVCS Tracker и используется только совместно с ним . PVCS Notify настраивается из среды PVCS Tracker. Настройка включает в себя определение интервала времени , через который PVCS Notify проверяет содержимое базы данных , определение крит ериев отбора записей для рассылки уведомлений , определение списков адресов для рассылки . После настройки PVCS Notify начинает работу в автономном режиме , автоматически рассылая уведомления об изменениях в базе данных PVCS Tracker. PVCS Notify предназначен для использования в больших рабочих группах , часть членов которых хотя и доступна только через средства электронной почты , однако должна иметь оперативную информацию о требованиях на изменение программного продукта , замечаниях , ошибках , ходе и результата х его тестирования . Результатом работы PVCS Notify являются оформленные в соответствии с одним из стандартов почтовые сообщения , готовые для рассылки посредством системы электронной почты . 3.6.2. Средства документирования Для создания документации в проце ссе разработки ИС используются разнообразные средства формирования отчетов , а также компоненты издательских систем . Обычно средства документирования встроены в конкретные CASE-средства . Исключением являются некоторые пакеты , предоставляющие дополнительный сервис при документировании . Из них наиболее активно используется SoDA (Software Document А utomation). Продукт SoDA предназначен для автоматизации разработки проектной документации на всех фазах ЖЦ ПО . Он позволяет автоматически извлекать разнообразную ин формацию , получаемую на разных стадиях разработки проекта , и включать ее в выходные документы . При этом контролируется соответствие документации проекту , взаимосвязь документов , обеспечивается их своевременное обновление . Результирующая документация автом а тически формируется из множества источников , число которых не ограничено . SoDA не зависит от применяемых инструментальных средств . Связь с приложениями осуществляется через стандартный программный интерфейс API. Переход на новые инструментальные средства не влечет за собой дополнительных затрат по документированию проекта . SoDA содержит набор шаблонов документов , определяемых стандартом на программное обеспечение DOD 2167A. На их основе можно без специального программирования создавать новые формы докумен тов , определяемые пользователями . Пакет включает в себя графический редактор для подготовки шаблонов документов . Он позволяет задавать необходимый стиль , фон , шрифт , определять расположение заголовков , резервировать места , где будет размещаться извлекаема я из разнообразных источников информация . Изменения автоматически вносятся только в те части документации , на которые они повлияли в программе . Это сокращает время подготовки документации за счет отказа от перегенерации всей документации . SoDA реализована на базе издательской системы FrameBuilder и предоставляет полный набор средств по редактированию и верстке выпускаемой документации . Разные версии документации могут быть для наглядности отмечены своими отличительными признаками . В системе создаются табл и цы требований к проекту , по которым можно проследить , как реализуются эти требования . Разные виды документации , сопровождающие различные этапы ЖЦ , связаны между собой , и можно проследить состояние проекта от первоначальных требований до анализа , проектиро в ания , кодирования и тестирования программного продукта . Итоговым результатом работы системы SoDA является готовый документ (или книга ). Документ может храниться в файле формата SoDA (Frame Builder), который получается в результате генерации документа . Выв од на печать этого документа (или его части ) возможен из системы SoDA. Среда функционирования SoDA - ОС типа UNIX на рабочих станциях Sun SPARCstation, IBM RISC System/6000 или Hewlett Packard HP 9000 700/800. SoDA требует по крайней мере 32 MB оперативн ой памяти , 100-300 MB для установки и 64 MB рабочего пространства на диске . 3.6.3. Средства тестирования Под тестированием понимается процесс исполнения программы с целью обнаружения ошибок . Регрессионное тестирование - это тестирование , проводимое после усовершенствования функций программы или внесения в нее изменений . Одно из наиболее развитых средств тестирования QA (новое название - Quality Works) [20] представляет собой интегрированную , многоплатформенную среду для разработки автоматизированных тесто в любого уровня , включая тесты регрессии для приложений с графическим интерфейсом пользователя . QA позволяет начинать тестирование на любой фазе ЖЦ , планировать и управлять процессом тестирования , отображать изменения в приложении и повторно использовать тесты для более чем 25 различных платформ . Основными компонентами QA являются : · QA Partner - среда для разработки , компиляции и выполнения тестов ; · QA Planner - модуль для разработки планов тестирования и обработки результатов . Для создания и выполн ения тестов в процессе работы QA Planner вызывается QA Partner; · Agent - модуль , поддерживающий работу в сети. Процесс тестирования состоит из следующих этапов : · создание плана тестирования ; · связывание плана с тестами ; · пометка и выполнение те стов ; · получение отчетов о тестировании и управление результатами. Создание тестового плана в QA Planner включает в себя составление схемы тестовых требований и выделение уровней детализации . Для этого необходимо определить все , что должно быть протести ровано , подготовить функциональную декомпозицию приложения , оценить , сколько тестов необходимо для каждой функции и характеристики , определить , сколько из них будет реализовано в зависимости от доступных ресурсов и времени . Эта информация используется для создания схемы тестовых требований . Для связывания плана с тестами необходимо создать управляющие предложения (скрипты ) на специальном языке 4Test и тесты , которые выполняют требования плана , и связать компоненты любым способом . Для избежания перегруженно сти тестов используют управление тестовыми данными . При выполнении плана результаты записываются в формате , похожем на план . Все результаты связаны с планом . Есть возможность просмотреть или скрыть общую информацию о выполнении , слить файлы результатов , р азметить неудавшиеся тесты , сравнить результаты предыдущего выполнения тестов , выполнить или отменить отчет . Одним из атрибутов теста является имя его разработчика , что позволяет при необходимости выполнять тесты , созданные конкретным разработчиком . Комп лекс QA занимает на жестком диске не более 21МВ . Поддерживаемые платформы : Windows 3.x, Windows 95, Windows NT, OS/2, Macintosh, VMS, HP-UX, AIX, Solaris. 3.7. Примеры комплексов CASE-средств В заключение приведем примеры комплексов CASE-средств обеспечив ающих поддержку полного ЖЦ ПО . Здесь хотелось бы еще раз отметить нецелесообразность сравнения отдельно взятых CASE-средств , поскольку ни одно из них не решает в целом все проблемы создания и сопровождения ПО . Это подтверждается также полным набором крите р иев оценки и выбора , которые затрагивают все этапы ЖЦ ПО . Сравниваться могут комплексы методологически и технологически согласованных инструментальных средств , поддерживающие полный ЖЦ ПО и обеспеченные необходимой технической и методической поддержкой со стороны фирм-поставщиков . По мнению автора , на сегодняшний день наиболее развитым из всех поставляемых в России комплексов такого рода является комплекс технологий и инструментальных средств создания ИС , основанный на методологии и технологии DATARUN. В с о став комплекса входят следующие инструментальные средства : · CASE-средство Silverrun; · средство разработки приложений JAM; · мост Silverrun-RDM <-> JAM; · комплекс средств тестирования QA; · менеджер транзакций Tuxedo; · комплекс средств плани рования и управления проектом SE Companion; · комплекс средств конфигурационного управления PVCS; · объектно-ориентированное CASE-средство Rational Rose; · средство документирования SoDA. Примерами других подобных комплексов являются : · Vantage Tea m Builder for Uniface + Uniface (фирмы "DataX/Florin" и "ЛАНИТ "); · комплекс средств , поставляемых и используемых фирмой "ФОРС ": · CASE-средства Designer/2000 (основное ), ERwin, Bpwin и Oowin (альтернативные ); · средства разработки приложений Develop er/2000, ORACLE Power Objects (основные ) и Usoft Developer (альтернативное );
1Архитектура и строительство
2Астрономия, авиация, космонавтика
 
3Безопасность жизнедеятельности
4Биология
 
5Военная кафедра, гражданская оборона
 
6География, экономическая география
7Геология и геодезия
8Государственное регулирование и налоги
 
9Естествознание
 
10Журналистика
 
11Законодательство и право
12Адвокатура
13Административное право
14Арбитражное процессуальное право
15Банковское право
16Государство и право
17Гражданское право и процесс
18Жилищное право
19Законодательство зарубежных стран
20Земельное право
21Конституционное право
22Конституционное право зарубежных стран
23Международное право
24Муниципальное право
25Налоговое право
26Римское право
27Семейное право
28Таможенное право
29Трудовое право
30Уголовное право и процесс
31Финансовое право
32Хозяйственное право
33Экологическое право
34Юриспруденция
 
35Иностранные языки
36Информатика, информационные технологии
37Базы данных
38Компьютерные сети
39Программирование
40Искусство и культура
41Краеведение
42Культурология
43Музыка
44История
45Биографии
46Историческая личность
47Литература
 
48Маркетинг и реклама
49Математика
50Медицина и здоровье
51Менеджмент
52Антикризисное управление
53Делопроизводство и документооборот
54Логистика
 
55Педагогика
56Политология
57Правоохранительные органы
58Криминалистика и криминология
59Прочее
60Психология
61Юридическая психология
 
62Радиоэлектроника
63Религия
 
64Сельское хозяйство и землепользование
65Социология
66Страхование
 
67Технологии
68Материаловедение
69Машиностроение
70Металлургия
71Транспорт
72Туризм
 
73Физика
74Физкультура и спорт
75Философия
 
76Химия
 
77Экология, охрана природы
78Экономика и финансы
79Анализ хозяйственной деятельности
80Банковское дело и кредитование
81Биржевое дело
82Бухгалтерский учет и аудит
83История экономических учений
84Международные отношения
85Предпринимательство, бизнес, микроэкономика
86Финансы
87Ценные бумаги и фондовый рынок
88Экономика предприятия
89Экономико-математическое моделирование
90Экономическая теория

 Анекдоты - это почти как рефераты, только короткие и смешные Следующий
- Доктор, я как получу зарплату, так смеюсь не переставая!
- Ну и хорошо! Смех продлевает жизнь!
- Т.е. до пенсии дотяну?
- Конечно! А там ещё смешнее будет!
Anekdot.ru

Узнайте стоимость курсовой, диплома, реферата на заказ.

Обратите внимание, реферат по программированию "CASE-технологии", также как и все другие рефераты, курсовые, дипломные и другие работы вы можете скачать бесплатно.

Смотрите также:


Банк рефератов - РефератБанк.ру
© РефератБанк, 2002 - 2016
Рейтинг@Mail.ru