страница 1страница 2страница 3страница 4
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Похожие работы
|
Дипломная работа/выпускная квалификационная работа студента 4 курса - страница №1/4
МОСКОВСКИЙ ФИЗИКО-ТЕХНИЧЕСКИЙ ИНСТИТУТ(ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ) Кафедра/специализация«Вычислительные модели технологических процессов» Неверов Николай ВладимировичСредства и методы коллективной разработки проектов информационных технологий на основе продуктов фирмы Rational: ClearCase и RequisitePro Дипломная работа/выпускная квалификационная работа студента 4 курса Направление: 511600 - «Прикладные математика и физика» Специальность: 511656 - «Математические и информационные технологии» Научный руководитель: д.т.н., проф. Глухарев К.К. Научный консультант: Сенкевич В.В. Москва2001Содержание 1. Введение····························································································································5 2. О программных средствах автоматизированного проектирования информационных систем····································································································································6 4.3.2. Системы и подсистемы··········································································15 4.3.3. Процессы·······························································································15 4.3.4. Накопители данных···············································································16 4.3.5. Потоки данных······················································································16 4.3.6. Построение иерархии диаграмм потоков данных···································16 5. Методология моделирования данных IDEF1·····································································17 6. CASE-средства. Общая характеристика и классификация·················································18 7. Знакомство с корпорацией Rational Software·····································································19 8. Продукт ClearCase············································································································32 8.1. Описание возможностей продукта·················································································32 8.2. На чем основана программа···························································································34 8.3. Интеграция с другими программными продуктами························································36 8.4. Дополнительные функции продукта···············································································36 8.5. Спецификации ClearCase·····················································································37 8.6. Пример использования ClearCase········································································388.7. Выводы··························································································································41
9.1. Описание возможностей продукта··················································································41 9.2. На чем основана программа···························································································41 9.3. Интеграция с другими программными продуктами························································43 9.4. Дополнительные функции продукта···············································································43 9.5. Спецификации RequisitePro·················································································44 9.6. Пример использования RequisitePro·····································································44 9.7. Выводы·············································································································· 4510. Заключение·····················································································································46 11. Словарь специальных терминов······················································································47 Литература···························································································································51 АннотацияВ данной работе представлена общая информация по Case-средствам компании Rational Software. Эта информация позволяет ввести неподготовленного в курс дела, и на основе этой информации более подробно остановится на двух программных продуктах компании Rational: ClearCase и RequisitePro. Данные продукты являются средствами коллективной разработки проектов в области информационных технологий, в качестве методов данной разработки выступает взаимодействие членов коллектива, как партнерских сторон в разработке какого-либо проекта. Рассмотрены основные функциональные возможности и области применения данных продуктов. Также сказано о необходимом уровне подготовки специалиста, которому необходимо использовать то или иное средство, т.е. кому позиционируются данные продукты. С какими программными продуктами интегрируются ClearCase и RequisitePro, минимальные системные требования на технику и операционную среду. Стр. 52; рис. 26; табл. 3. Ключевые слова: Данные Система Информационная система (ИС) Информационная технология Метод Методология Проектирование Верификация База данных (БД) Система управления базами данных Предметная область Структурное проектирование Метод потока данных CASE CASE-технология Жизненный цикл программного обеспечения (ЖЦ ПО) ISO/IEC Абстракция Иерархия Иерархическая система Структурный aнaлиз Функциональная модель Информационная модель Репозиторий Релиз Архитектура системы Архитектор проекта Ответственный за подсистемы Прикладные программисты Менеджер проекта Аналитик Инженер по повторному использованию Контролер качества Менеджер интеграции Ответственный за конфигурацию Инструментальщик Системный администратор Сущность Реинжиниринг DFD (Data Flow Diagrams) Объектно-ориентированное проектирование Объектно-ориентированный анализРеляционная база данных Реляционная модель Бизнес-процесс Прямое и обратное проектирование Масштабируемость Нормальная форма Третья нормальная форма RUP (Rational Unified Process) SCM (Source Code Management) Функциональная структура объекта SADT IDEF0 (Icam DEFinition) IDEFIX MultiSite VOB (Version Object Base) Branch Private Branch MergeManager OMake Клиент Сервер Клиент-серверная архитектура Импортирование данных Экспортирование данных Библиотека DLL Операционная система Файловая система Wizard (мастер) Режим реального времени Проект Локальная сетьBrowser (браузер или броузер) Online 1. Введение Тенденции развития современных информационных технологий приводят к постоянному возрастанию сложности информационных систем (ИС), создаваемых в различных областях деятельности человека. Под термином информационные системы мы будем понимать cреду, составляющими элементами которой являются компьютеры, компьютерные сети, программные продукты, базы данных, люди, различного рода технические и программные средства связи и т.д. Основная цель информационной системы - организация хранения, обработки и передачи информации. Информационная система представляет собой человеко-компьютерную систему обработки информации. Как раз частью ИС являются продукты, которые мы рассмотрим в данном тексте, а технологии, на которых они построены, так называемые CASE-технологии. Данные продукты являются средствами коллективной разработки проектов в области информационных технологий. Для понимания того, для чего и зачем они используются в проектировании, перепроектировании, документировании, контроле изменений в проекте, генерации кода, его тестировании, и многих других этапах в жизненном цикле программного обеспечения, мы сначала познакомимся с видами информационных систем, их строением, особенностями проектирования. Потом рассмотрим необходимые для этого CASE-средства, познакомимся кратко с основными методологиями (набором элементов, которыми оперирует методология) проектирования данных, процессов. После этого, умудренные знанием всех об устройстве информационных системах и методологиях их проектирования, перейдем к конкретным продуктам, в которых воплощены все эти подходы. Рассматриваемые в тексте продукты основаны на централизованных репозиториях, которые имеют формат данных СУБД Microsoft Access. Данная база является реляционной, то есть основана на множестве простых таблиц, поэтому мы принимаем такой план изложения материала (см. выше), чтобы читатель понял, как проектируются такие системы и на каких концепциях они основаны. Так как реляциооные базы данных проектируются методами структурного подхода, то рассмотрим его более подробно, также коснемся методологий структурного подхода, с помощью которых осуществляется проектирование. Нужно сказать, что современные крупные проекты информационных технологий, а это в том числе разработка в коллективе программного обеспечения (ПО), информационного сетевого ресурса, создание сетевого сервиса, характеризуются, как правило, следующими особенностями:
Для успешной реализации проекта объект проектирования – информационная система, должен быть прежде всего адекватно описан: должны быть построены полные и непротиворечивые функциональные модели ИС. Накопленный к настоящему времени опыт показывает, что проектирование ИС - это логически сложная, трудоемкая и длительная по времени работа, требующая высокой квалификации участвующих в ней специалистов. Однако, до недавнего времени проектирование ИС выполнялось в основном на интуитивном уровне с применением неформализованных методов, основанных на искусстве, практическом опыте, экспертных оценках и дорогостоящих экспериментальных проверках качества функционирования ИС. В процессе создания и функционирования ИС потребности пользователей могут изменяться и/или уточняться, что еще более усложняет процесс проектирования таких систем. В 70-х и 80-х годах при разработке ИС достаточно широко применялся структурный подход к проектированию, предоставляющий в распоряжение разработчиков строгие формализованные методы описания ИС и принимаемых технических решений. Он основан на наглядной графической технике: для описания различного рода моделей ИС используются типовые схемы и диаграммы. Наглядность средств структурного анализа позволяла разработчикам и будущим пользователям системы с самого начала участвовать в ее создании, обсуждать и закреплять понимание основных технических решений. Однако, широкое применение этого подхода встречалось достаточно редко. Вручную очень трудно разработать и графически представить типовые спецификации системы, проверить их на полноту, непротиворечивость, и тем более изменить. Если все же удается создать систему проектных документов, то ее переработка при появлении серьезных изменений практически неосуществима. Ручная разработка обычно порождала следующие проблемы:
С другой стороны, разработчики ИС исторически всегда стояли последними в ряду тех, кто использовал компьютерные технологии для повышения качества, надежности и производительности в своей собственной работе. 2. О программных средствах автоматизированного проектирования информационных систем Перечисленные факторы способствовали появлению программных средств специального класса - CASE-средств, реализующих CASE-технологию создания и сопровождения ИС. Термин CASE используется в настоящее время в весьма широком смысле. Первоначальное значение термина CASE, ограниченное вопросами автоматизации разработки только лишь программного обеспечения, в настоящее время приобрело новый смысл, охватывающий процесс разработки сложных ИС в целом. Теперь под термином CASE-средства понимаются программные средства, поддерживающие процессы создания и сопровождения ИС, включая анализ и формулировку требований, проектирование прикладного обеспечения (приложений) и баз данных, генерацию кода, тестирование, документирование, обеспечение качества, конфигурационное управление и управление проектом, а также другие процессы. CASE-средства вместе с системным ПО и техническими средствами образуют полную среду разработки ИС. В настоящее время CASE-технология представляет собой методологию проектирования ИС, а также набор инструментальных средств, позволяющих в стандартных формах моделировать предметную область, анализировать эту модель на всех этапах разработки и сопровождения ИС. Большинство существующих CASE-средств основано на методологиях структурного (в основном) или объектно-ориентированного анализа и проектирования. Согласно обзору передовых технологий (Survey of Advanced Technology), составленному фирмой Systems Development Inc. в 1998 г. по результатам анкетирования более 1000 американских фирм, CASE-технология попала в разряд наиболее стабильных информационных технологий (ее использовала половина всех опрошенных пользователей более чем в трети своих проектов, из них 85% завершились успешно). [1] Одним из базовых понятий методологии проектирования ИС является понятие жизненного цикла ее программного обеспечения (ЖЦ ПО). ЖЦ ПО - это непрерывный процесс, который начинается с момента принятия решения о необходимости его создания и заканчивается в момент его полного изъятия из эксплуатации. Основным нормативным документом, регламентирующим ЖЦ ПО, является международный стандарт ISO/IEC 12207 [2]. Он определяет структуру ЖЦ, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ПО. Структура ЖЦ ПО по стандарту ISO/IEC 12207 базируется на трех группах процессов:
Разработка включает в себя все работы по созданию ПО и его компонент в соответствии с заданными требованиями, включая оформление проектной и эксплуатационной документации, подготовку материалов, необходимых для проверки работоспособности и соответствующего качества программных продуктов, материалов, необходимых для организации обучения персонала и т.д. Разработка ПО включает в себя, как правило, анализ, проектирование и реализацию - программирование. Эксплуатация включает в себя работы по внедрению компонентов ПО в эксплуатацию, в том числе конфигурирование базы данных и рабочих мест пользователей, обеспечение эксплуатационной документацией, проведение обучения персонала и т.д., и непосредственно эксплуатацию, в том числе локализацию проблем и устранение причин их возникновения, модификацию ПО в рамках установленного регламента, подготовку предложений по совершенствованию, развитию и модернизации системы. Управление проектом связано с вопросами планирования и организации работ, создания коллективов разработчиков и контроля за сроками и качеством выполняемых работ. Техническое и организационное обеспечение проекта включает выбор методов и инструментальных средств для реализации проекта, определение методов описания промежуточных состояний разработки, разработку методов и средств испытаний ПО, обучение персонала и т.п. Обеспечение качества проекта связано с проблемами проверки соответствию требованиям на данном этапе проектирования и тестирования ПО. Проверка позволяет оценить соответствие параметров разработки исходным требованиям. Она частично совпадает с тестированием, которое связано с идентификацией различий между действительными и ожидаемыми результатами и оценкой соответствия характеристик ПО исходным требованиям. В процессе реализации проекта важное место занимают вопросы идентификации, описания и контроля конфигурации отдельных компонентов и всей системы в целом. Управление конфигурацией является одним из вспомогательных процессов, поддерживающих основные процессы жизненного цикла ПО, прежде всего процессы разработки и сопровождения ПО. При создании проектов сложных ИС, состоящих из многих компонентов, каждый из которых может иметь разновидности или версии, возникает проблема учета их связей и функций, создания унифицированной структуры и обеспечения развития всей системы. Управление конфигурацией позволяет организовать, систематически учитывать и контролировать внесение изменений в ПО на всех стадиях жизненного цикла. Общие принципы и рекомендации конфигурационного учета, планирования и управления конфигурациями ПО отражены в проекте стандарта ISO 12207-2 [2, приложение]. Каждый процесс характеризуется выполнением определенных задач и методами их решения, исходными данными, полученными на предыдущем этапе, и результатами. Результатами анализа, в частности, являются функциональные модели, информационные модели и соответствующие им диаграммы. ЖЦ ПО носит итерационный характер: результаты очередного этапа часто вызывают изменения в проектных решениях, выработанных на более ранних этапах. 3.2. Модели жизненного цикла программного обеспечения К настоящему времени наибольшее распространение получили следующие две основные модели ЖЦ:
Основной характеристикой каскадной модели является разбиение всей разработки на этапы, причем переход с одного этапа на следующий происходит только после того, как будет полностью завершена работа на текущем (рис. 1). Каждый этап завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков. Рис. 1. Каскадная схема разработки ПО Каскадный подход хорошо зарекомендовал себя при построении ИС, для которых в самом начале разработки можно достаточно точно и полно сформулировать все требования. В эту категорию попадают расчетные системы, системы реального времени и другие задачи создания автоматизированных систем. Реальный процесс создания ПО для автоматизированных систем никогда полностью не укладывался в такую жесткую схему. В процессе создания ПО постоянно возникала потребность в возврате к предыдущим этапам и уточнении или пересмотре ранее принятых решений (рис. 2): Рис. 2. Реальный процесс разработки ПО по каскадной схеме Основным недостатком каскадного подхода является существенное затягивание сроков выполнения проекта и других работ в периоде ЖЦ. Согласование результатов с пользователями производится только в точках, планируемых после завершения каждого этапа работ. Требования к ИС представлены в виде технического задания и неизменны на все время ее создания. Таким образом, пользователи могут внести свои замечания только после того, как работа над системой будет полностью завершена. В случае неточного изложения требований или их изменения в течение длительного периода создания ПО, пользователи получают систему, не удовлетворяющую их потребностям. Модели (как функциональные, так и информационные) автоматизируемого объекта могут устареть одновременно с их утверждением. Для преодоления перечисленных проблем была предложена спиральная модель ЖЦ [3] (рис. 3), делающая упор на начальные этапы ЖЦ: анализ и проектирование. На этих этапах реализуемость технических решений проверяется путем создания прототипов. Каждый виток спирали соответствует созданию фрагмента или версии ПО, на нем уточняются цели и характеристики проекта, определяется его качество и планируются работы следующего витка спирали. Таким образом углубляются и последовательно конкретизируются детали проекта и в результате выбирается обоснованный вариант, который доводится до реализации. Разработка итерациями отражает объективно существующий спиральный цикл создания системы. Неполное завершение работ на начальных этапах позволяет переходить на следующий, не дожидаясь полного завершения работы на текущем. При итеративном способе разработки недостающую работу можно будет выполнить на следующей итерации. Главная задача - как можно быстрее показать пользователям системы работоспособный продукт, тем самым активизируя процесс уточнения и дополнения требований. Основная проблема спирального метода – не нарушать временные ограничения на каждый из этапов жизненного цикла. Переход осуществляется в соответствии с планом, даже если не вся запланированная работа закончена. План составляется на основе опыта, полученного в предыдущих проектах. Рис 3. Спиральная модель ЖЦ 3.3. Технологии проектирования информационных систем Технология проектирования определяется как совокупность трех составляющих:
Технологические инструкции, составляющие основное содержание технологии, должны состоять из описания последовательности технологических операций, условий, в зависимости от которых выполняется та или иная операция, и описаний самих операций. Технология проектирования, разработки и сопровождения ИС должна удовлетворять следующим общим требованиям:
Реальное применение любой технологии проектирования, разработки и сопровождения ИС в конкретной организации и конкретном проекте невозможно без выработки ряда стандартов (правил, соглашений), которые должны соблюдаться всеми участниками проекта. К таким стандартам относятся следующие [1]:
Стандарт проектирования должен устанавливать [1]:
Стандарт оформления проектной документации должен устанавливать [1]:
Стандарт интерфейса пользователя должен устанавливать [1]:
4. Структурный подход к проектированию информационных систем 4.1. Сущность структурного подхода Сущность структурного подхода к разработке ИС заключается в ее разбиении на подсистемы, выполняющие отдельные функции, которые в свою очередь делятся на подфункции, подразделяемые на задачи и так далее. Процесс разбиения (декомпозиции) продолжается вплоть до отдельных процедур. При разработке системы "снизу-вверх", то есть от отдельных задач ко всей системе, целостность теряется, возникают проблемы из-за нехватки информации для “стыковки” отдельных компонентов. Все наиболее распространенные методологии структурного подхода [4,5,6,7] базируются на ряде общих принципов [8]. В качестве двух базовых принципов используются следующие:
В структурном анализе используются две группы средств, иллюстрирующих:
Каждой группе средств соответствуют определенные виды диаграмм, наиболее распространенными среди которых являются следующие:
Перечисленные диаграммы применяются для существующих и вновь разрабатываемых ИС. Состав диаграмм в каждом конкретном случае зависит от необходимой полноты описания системы. Рассмотрим более подробно виды диаграмм (упомянутые выше). 4.2. Методология функционального моделирования SADT Методология SADT разработана Дугласом Россом и получила дальнейшее развитие в работе [9]. На ее основе разработана известная методология IDEF0 (Icam DEFinition), которая является основной частью программы “Интеграция компьютерных и промышленных технологий”, проводимой по инициативе ВВС США. Методология SADT представляет собой совокупность методов, правил и процедур, предназначенных для построения функциональной модели объекта какой-либо предметной области. Функциональная модель SADT отображает функциональную структуру объекта, т.е. производимые им действия и связи между этими действиями. Основные элементы этой методологии основываются на следующих положениях [1]:
Правила SADT включают [1]:
Методология SADT может использоваться для моделирования широкого круга систем и определения требований и функций разрабатываемой системы. Для существующих систем SADT может быть использована для анализа функций, выполняемых системой, а также для указания механизмов, посредством которых они осуществляются. 4.2.1. Состав функциональной модели Результатом применения методологии SADT является модель, которая состоит из диаграмм, фрагментов текстов и глоссария, имеющих ссылки друг на друга. Диаграммы - главные компоненты модели, все функции ИС и связи представлены как блоки и дуги. Место соединения дуги с блоком определяет тип связи. Управляющая информация входит в блок сверху, в то время как информация, которая подвергается обработке, показана с левой стороны блока, а результаты выхода показаны с правой стороны. Механизм (человек или автоматизированная система), который осуществляет операцию, представляется дугой, входящей в блок снизу (рис. 4). Рис. 4. Функциональный блок (контекстная диаграмма) Одной из наиболее важных особенностей методологии SADT является постепенное введение все больших уровней детализации по мере создания диаграмм, отображающих модель. Затем блок, который представляет систему в качестве единого модуля, детализируется на другой диаграмме с помощью нескольких блоков, соединенных дугами. Эти блоки представляют основные подфункции исходной функции. Данная декомпозиция выявляет полный набор подфункций, каждая из которых представлена как блок, границы которого определены дугами. Каждая из этих подфункций может быть декомпозирована подобным образом для более детального представления. Во всех случаях каждая подфункция может содержать только те элементы, которые входят в исходную функцию. Кроме того, модель не может опустить какие-либо элементы, т.е. родительский блок и его связи обеспечивают область “действия” диаграммы. К нему нельзя ничего добавить, и из него не может быть ничего удалено. [1] Модель SADT представляет собой серию диаграмм с сопроводительной документацией, разбивающих сложный объект на составные части, которые представлены в виде блоков. Детали каждого из основных блоков показаны в виде блоков на других диаграммах. Каждая детальная диаграмма является декомпозицией блока из более общей диаграммы. На каждом шаге декомпозиции более общая диаграмма называется родительской для более детальной диаграммы. Дуги, входящие в блок и выходящие из него на диаграмме верхнего уровня (родительской диаграмме), являются точно теми же самыми, что и дуги, входящие в диаграмму нижнего уровня и выходящие из нее, потому что блок и диаграмма представляют одну и ту же часть системы. Некоторые дуги присоединены к блокам диаграммы обоими концами, у других же один конец остается неприсоединенным. Неприсоединенные дуги соответствуют входам, управлениям и выходам родительского блока. Источник или получатель этих дуг может быть обнаружен только на родительской диаграмме. Неприсоединенные концы должны соответствовать дугам на исходной диаграмме. Все дуги, выходящие за диаграмму данного уровня, должны продолжаться на родительской диаграмме, чтобы она была полной и непротиворечивой. На SADT-диаграммах явно не указаны ни последовательность, ни время. Обратные связи, итерации, продолжающиеся процессы и перекрывающиеся (по времени) функции могут быть изображены с помощью дуг. Обратные связи могут выступать в виде комментариев, замечаний, исправлений и т.д. (рис. 5). Рис. 5. Пример обратной связи 4.3. Моделирование потоков данных В основе данной методологии (методологии Gane/Sarson [7]) лежит построение модели анализируемой ИС – проектируемой или реально существующей. В соответствии с методологией модель системы определяется как иерархия диаграмм потоков данных (ДПД или DFD), описывающих несвязанный по времени процесс преобразования информации от ее ввода в систему до выдачи пользователю. Диаграммы верхних уровней иерархии (контекстные диаграммы) определяют основные процессы или подсистемы ИС с внешними входами и выходами. Они детализируются при помощи диаграмм нижнего уровня. Такая декомпозиция продолжается, создавая многоуровневую иерархию диаграмм, до тех пор, пока не будет достигнут такой уровень декомпозиции, на котором процессы становятся элементарными и детализировать их далее невозможно. Источники информации, которые являются в данной нотации внешними сущностями, порождают информационные потоки (потоки данных), переносящие информацию к подсистемам или процессам. Те в свою очередь преобразуют информацию и порождают новые потоки, которые переносят информацию к другим процессам или подсистемам, накопителям данных или внешним сущностям - потребителям информации. Таким образом, основными компонентами диаграмм потоков данных являются:
Рассмотрим схематическое изображение данных компонент диаграмм и их свойства. 4.3.1. Внешние сущности Внешняя сущность представляет собой материальный предмет или физическое лицо, представляющее собой источник или приемник информации, например, заказчики, персонал, поставщики, клиенты, склад. Определение некоторого объекта или системы в качестве внешней сущности указывает на то, что она находится за пределами границ анализируемой ИС. В процессе анализа некоторые внешние сущности могут быть перенесены внутрь диаграммы анализируемой ИС, если это необходимо, или, наоборот, часть процессов ИС может быть вынесена за пределы диаграммы и представлена как внешняя сущность. Внешняя сущность обозначается квадратом (рис. 6). Рис. 6. Внешняя сущность 4.3.2. Системы и подсистемы При построении модели сложной ИС она может быть изображена в виде одной системы как единого целого, либо может быть декомпозирована на ряд подсистем. Подсистема (или система) на контекстной диаграмме изображается следующим образом (рис. 7). Рис. 7. Система или подсистема Номер подсистемы служит для ее идентификации. В поле имени вводится наименование подсистемы в виде предложения с подлежащим и соответствующими определениями и дополнениями. Процесс на диаграмме потоков данных изображается, как показано на рис. 8. Рис. 8. Процесс Номер процесса служит для его идентификации. В поле имени вводится наименование процесса в виде предложения с недвусмысленным глаголом в неопределенной форме (вычислить, рассчитать, проверить, определить, создать, получить), за которым следуют существительные в винительном падеже, например [1]:
Использование таких глаголов, как "обработать", "модернизировать" или "отредактировать" означает, как правило, недостаточно глубокое понимание данного процесса и требует дальнейшего анализа. Информация в поле физической реализации показывает, какое подразделение организации, программа или аппаратное устройство выполняет данный процесс. 4.3.4. Накопители данных Накопитель данных представляет собой абстрактное устройство для хранения информации, которую можно в любой момент поместить в накопитель и через некоторое время извлечь, причем способы помещения и извлечения могут быть любыми. Накопитель данных может быть реализован физически в виде, ящика в картотеке, таблицы в оперативной памяти, файла на магнитном носителе и т.д. Накопитель данных на диаграмме потоков данных изображается, как показано на рис. 9. Рис. 9. Накопитель данных Накопитель данных идентифицируется буквой "D" и произвольным числом. Имя накопителя выбирается из соображения наибольшей информативности для проектировщика. Накопитель данных в общем случае является прообразом будущей базы данных и описание хранящихся в нем данных должно быть увязано с информационной моделью. 4.3.5. Потоки данных Поток данных определяет информацию, передаваемую через некоторое соединение от источника к приемнику. Реальный поток данных может быть информацией, передаваемой по кабелю между двумя устройствами, пересылаемыми по почте письмами, магнитными лентами или дискетами, переносимыми с одного компьютера на другой и т.д. Поток данных на диаграмме изображается линией, оканчивающейся стрелкой, которая показывает направление потока (рис. 10). Каждый поток данных имеет имя, отражающее его содержание. Рис. 10. Поток данных 4.3.6. Построение иерархии диаграмм потоков данных При построении иерархии ДПД переходить к детализации процессов следует только после определения содержания всех потоков, которое описывается при помощи структур данных. Структуры данных конструируются из элементов данных и могут содержать альтернативы, условные вхождения и итерации. Условное вхождение означает, что данный компонент может отсутствовать в структуре. Альтернатива означает, что в структуру может входить один из перечисленных элементов. Итерация означает вхождение любого числа элементов в указанном диапазоне. Для каждого элемента данных может указываться его тип (непрерывные или дискретные данные). Для непрерывных данных может указываться единица измерения (кг, см и т.п.), диапазон значений, точность представления и форма физического кодирования. Для дискретных данных может указываться таблица допустимых значений. [1] После построения законченной модели системы ее необходимо проверить на полноту и согласованность. В полной модели все ее объекты (подсистемы, процессы, потоки данных) должны быть подробно описаны и детализированы. Выявленные недетализированные объекты следует детализировать, вернувшись на предыдущие шаги разработки. В согласованной модели для всех потоков данных и накопителей данных должно выполняться правило сохранения информации: все поступающие куда-либо данные должны быть считаны, а все считываемые данные должны быть записаны. [10] 5. Методология моделирования данных IDEF1 Метод IDEF1, разработанный Т.Рэмей (T.Ramey), также основан на подходе П.Чена и позволяет построить модель данных, эквивалентную реляционной модели в третьей нормальной форме. В настоящее время на основе методологии IDEF1 создана ее новая версия - методология IDEF1X. IDEF1X разработана с учетом таких требований, как простота изучения и возможность автоматизации. IDEF1X-диаграммы используются рядом распространенных CASE-средств (в частности, ERwin). Сущность в методологии IDEF1X является независимой от идентификаторов или просто независимой, если каждый экземпляр сущности может быть однозначно идентифицирован без определения его отношений с другими сущностями. Сущность называется зависимой от идентификаторов или просто зависимой, если однозначная идентификация экземпляра сущности зависит от его отношения к другой сущности (рис. 11). Рис. 11. Сущности Каждой сущности присваивается уникальное имя и номер, разделяемые косой чертой "/" и помещаемые над блоком. Связь может дополнительно определяться с помощью указания степени или мощности (количества экземпляров сущности-потомка, которое может существовать для каждого экземпляра сущности-родителя). В IDEF1X могут быть выражены следующие мощности связей [1]:
Если экземпляр сущности-потомка однозначно определяется своей связью с сущностью-родителем, то связь называется идентифицирующей, в противном случае - неидентифицирующей. Связь изображается линией, проводимой между сущностью-родителем и сущностью-потомком с точкой на конце линии у сущности-потомка. Мощность связи обозначается как показано на рис. 12 (мощность по умолчанию - N). Рис. 12. Мощность связи Идентифицирующая связь между сущностью-родителем и сущностью-потомком изображается сплошной линией. Сущность-потомок в идентифицирующей связи является зависимой от идентификатора сущностью. Сущность-родитель в идентифицирующей связи может быть как независимой, так и зависимой (рис. 13) от идентификатора сущностью (это определяется ее связями с другими сущностями). Рис. 13. Идентифицирующая связь Пунктирная линия вместо сплошной линии изображает неидентифицирующую связь. Сущность-потомок в неидентифицирующей связи будет независимой от идентификатора, если она не является также сущностью-потомком в какой-либо идентифицирующей связи. Атрибуты изображаются в виде списка имен внутри блока сущности. Атрибуты, определяющие первичный ключ, размещаются наверху списка и отделяются от других атрибутов горизонтальной чертой (рис. 14). Рис. 14. Атрибуты и первичные ключи 6. CASE-средства. Общая характеристика и классификация Современные CASE-средства охватывают ряд областей технологии проектирования ИС: от простых средств анализа и документирования до полномасштабных средств автоматизации, покрывающих весь жизненный цикл ПО. Наиболее ответственными этапами разработки ИС являются этапы анализа и проектирования, в процессе которых обеспечивается качество принимаемых технических решений проектной документации. При этом большую роль играют методы визуального представления информации. Это предполагает построение структурных или иных диаграмм в реальном масштабе времени с использованием графических средств, проверку синтаксических правил. Графические средства моделирования предметной области позволяют разработчикам в наглядном виде изучать существующую ИС, перестраивать ее в соответствии с поставленными целями и имеющимися ограничениями. Обычно к CASE-средствам относят любое программное средство, автоматизирующее ту или иную работу в жизненном цикле ПО. Интегрированное CASE-средство (или комплекс средств, поддерживающих полный ЖЦ ПО) содержит следующие компоненты [1]:
Все современные CASE-средства могут быть классифицированы. Классификация по функциональной ориентации CASE-средств на этапы ЖЦ, т.е. все CASE-средства разбиваются на группы, которые решают отдельные локальные задачи: конфигурационное управление, документирование, тестирование, управление проектом и др. На сегодняшний день Российский рынок программного обеспечения располагает следующими основными CASE-средствами, программными продуктами, выполняющие роли, которые были обсуждены выше (табл. 1):
|
|