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

Лаборатория информационных технологий (ИТЛаб)При поддержке фирмы Intel

Учебно-исследовательский проект

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

Куратор проекта:Сысоев А.В.

СоставителиСтариков В.Зеленцова М.

Нижний Новгород2004г.

Раздел2: Методологии и технологиипроектирования ИС

Основные вопросы:Общие требования к методологии итехнологииМетодология RADСтруктурный подход

Методология функционального моделированияSADTМоделирование потоков данных (DFD)Case-метод Баркера (ERD)

Общие требования к методологии и технологии

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


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


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


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

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

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


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


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


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

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

Структурный подход

В структурном анализе используются в основном две группысредств, иллюстрирующих функции, выполняемые системой иотношения между данными. Каждой группе средствсоответствуют определенные виды моделей (диаграмм), наиболеераспространенными, среди которых являются следующие:SADT (Structured Analysis and Design Technique) модели исоответствующие функциональные диаграммыDFD (Data Flow Diagrams) диаграммы потоков данныхERD (Entity-Relationship Diagrams) диаграммы "сущность-связь

Методология функционального моделированияSADT

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


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


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


Структура SADT-модели. Декомпозиция диаграмм

Более общеепредставление

21

43

43

4142

Более детальноепредставление

Эта диаграммаЯвляется “родителем”

этой диаграммы


Значимость Тип связности Для функций Для данных

0 Случайная Случайная Случайная1 Логическая Функции одного и

того же множестваили типа

Данные одного и тогоже множества илитипа

2 Временная Функции одного итого же периодавремени

Данные, используемые вкаком-либовременном интервале

3 Процедурная Функции, работающие водной и той жефазе или итерации

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


Значимость Тип связности Для функций Для данных4 Коммуникаци-

оннаяФункции, использующиеодни и те жеданные

Данные, на которыевоздействует одна ита же деятельность

5 Последовате-льная

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

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

6 Функциональ-ная

Функции, объединяемые длявыполнения однойфункции

Данные, связанные содной функцией

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

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


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

ЗаказчикОбозначение на диаграммах


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

Поле номера

Подсистемаобслуживания клиентов

1Поле имени

Поле именипроектировщика

Номер подсистемы служит для ее идентификации. В поле имени вводитсянаименование подсистемы в виде предложения с подлежащим исоответствующими определениями и дополнениями


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

Поле номера

Рассчитать остаток средств

1.1Поле имени

Поле физическойреализации

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


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

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

D1 Получаемые счета


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

Вывести отчет о продажах

1.5

Бухгалтерия

Руководство

Отчет опродажах


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

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

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

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

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


Для каждой подсистемы, присутствующей на контекстных диаграммах, выполняется ее детализация при помощи ДПД. Каждый процесс на ДПД, в свою очередь, может быть детализирован при помощи ДПД или мини-спецификации.При детализации должны выполняться следующие правила:правило балансировки - означает, что при детализации подсистемы илипроцесса детализирующая диаграмма в качестве внешнихисточников/приемников данных может иметь только те компоненты(подсистемы, процессы, внешние сущности, накопители данных), скоторыми имеет информационную связь детализируемая подсистема илипроцесс на родительской диаграмме; правило нумерации - означает, что при детализации процессов должнаподдерживаться их иерархическая нумерация. Например, процессы, детализирующие процесс с номером 12, получают номера 12.1, 12.2, 12.3 и т.д.


Мини-спецификация является конечной вершиной иерархии ДПД. Решение о завершении детализации процесса и использовании мини-спецификации принимается аналитиком исходя из следующихкритериев:наличия у процесса относительно небольшого количества входных ивыходных потоков данных (2-3 потока)возможности описания преобразования данных процессом в видепоследовательного алгоритмавыполнения процессом единственной логической функциипреобразования входной информации в выходнуювозможности описания логики процесса при помощи мини-спецификации небольшого объема (не более 20-30 строк)

Case-метод Баркера (ERD)

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


Основные шаги:выделение сущностейидентификация связейидентификация атрибутов


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

<Имя сущности>


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


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

Один

Много

Обязательная

Необязательная


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

* обязательный атрибут(не допускаются null значения)<имя сущности>

*<атрибут - 1> 0 необязательный атрибут(допускаются null значения)

Case-метод Баркера (ERD)Помимо перечисленных основных конструкций модель данных можетсодержать ряд дополнительных:Подтипы и супертипы: одна сущность является обобщающим понятиемдля группы подобных сущностей

Взаимно исключающие связи: каждый экземпляр сущности участвуеттолько в одной связи из группы взаимно исключающих связей

Супертип

Подтип 1 Подтип 2

a b

c

Case-метод Баркера (ERD)Помимо перечисленных основных конструкций модель данных можетсодержать ряд дополнительных:Рекурсивная связь: сущность может быть связана сама с собой

Неперемещаемые (non-transferrable) связи: экземпляр сущности неможет быть перенесен из одного экземпляра связи в другой

a b

Documents

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