Logo GenDocs.ru

Поиск по сайту:  

Загрузка...

Лекции курса - Проектирование ИС - файл 1.doc


Лекции курса - Проектирование ИС
скачать (626 kb.)

Доступные файлы (1):

1.doc626kb.18.11.2011 22:22скачать

содержание

1.doc

  1   2   3
ЛЕКЦИИ: Проектирование информационных систем
Основная задача любого проекта заключается в том, чтобы на момент запуска системы, и в течение всего срока её эксплуатации можно было обеспечить следующие задачи:

  1. Обеспечить необходимую функциональность и адаптируемость к изменяющимся условиям.

  2. Необходимая пропускная способность системы.

  3. Время наработки системы на отказ.

  4. Простота эксплуатации и поддержки системы.

  5. Обеспечение необходимой безопасности.


Проектирование ИС охватывает три основные области:

  1. Проектирование объектов данных

  2. Проектирование программ, экранных форм и диалогов с пользователем, которые обеспечивают взаимодействие с БД.

  3. Учет конкретной среды или топологии сети.


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

  1. Пошаговая процедура, которая определяет последовательность выполнения проектирования.

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

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

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

  1. Поддержка полного жизненного цикла программного обеспечения.

  2. Гарантия достижения целей разработки программного обеспечения.

  3. Выполнение крупных систем в виде мелких подсистем.

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

  5. Минимальное время получения работающей системы, готовой к реализации.

  6. Возможность управления конфигурацией проекта.

  7. Независимость выполнения проектных решений.

  8. Поддержка комплекса согласованных CASE-средств.

Реальное проектирование, разработка и сопровождение ИС невозможно без выработки ряда стандартов, которые будут выполняться участниками проекта. Выделяют три группы стандартов:

  1. Стандарты проектирования:

а) Набор необходимых моделей для каждой стадии проектирования.

б) Правила фиксации готовых проектных решений.

в) Требование к конфигурации рабочего места разработчика

г) Механизм обеспечения совместной работы

  1. Стандарты оформления проектной документации

а) Необходимая комплектность документации на каждой стадии проектирования.

б) Необходимые требования по оформлению документации.

  1. Стандарт пользовательского интерфейса

а) Правила оформления экранных форм

б) Правила использования клавиатуры и мыши

в) Правила оформления помощи

г) Перечень стандартных сообщений
Жизненный цикл программного обеспечения
Жизненный цикл представляет собой модель создания ПО и его использования. Это непрерывный процесс, который начинается с принятия решения о создании и заканчивается моментом изъятия из эксплуатации. Основным документом, который регламентирует жизненный цикл, является стандарт ISO/IEC 12207.

Структура ЖЦ по данному стандарту на трех группах процессов:

  1. Основные процессы ЖЦ (приобретение, поставка, проектирование)

  2. Вспомогательные процессы (оценка качества)

  3. Организационные процессы (управление проектом)


Этапы ЖЦ


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

а) Необходимый объём работ по выполнению проекта

б) График и сроки выполнения работы

г) Срок окупаемости проекта и ожидаемый экономический эффект

д) Ограничения, накладываемые на проект, риски, связанные с выполнением проекта

е) Критические сроки завершения этапов разработки

ж) Наличие потенциального развития системы.

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

  1. Анализ – предполагает подробное исследование бизнес-процессов системы. На данном этапе получается информационная модель. Вся информация, собранная на предыдущем этапе, уточняется и формализуется. Результатом является иерархия функций системы (разбиение на подсистемы) и модель «сущность – связь» (ER - модель). Помимо этого в результаты включены диаграммы потоков данных, диаграммы жизненных циклов, реализация на языке UML (язык для описания предметной области).

  2. Проектирование – формируется модель данных. Эта модель строится на основе модели, полученной на этапе анализа. Конечным итогом этого этапа является схема БД и набор спецификаций модулей системы. На данном этапе начинает формироваться план тестирования системы. Общими задачами этого проектирования является:

    1. Рассмотрение результатов анализа и проверки их полноты

    2. Определение критических участков системы

    3. Принятие решения об использовании программных продуктов сторонних организаций

    4. Проектирование хранилища данных

    5. Проектирование процессов и кода программного продукта

    6. Определение требований безопасности системы

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

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

    1. Хранение сообщений об ошибке

    2. Система уведомления о новых ошибках

    3. Информация об ошибке и её история

Все тесты системы разделяются на несколько категорий:

  1. Автономные тесты модулей

  2. Тесты связей компонентов системы

  3. Системный тест

  4. Тесты производительности и нагрузки

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

1. Отказ отдельного компонента

2. Отказ группы компонентов

3. Отказ ОС

4. Жесткий сбой

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

  1. Внедрение – система редко вводится в эксплуатацию полностью. Как правило, этот процесс является постепенным или итерационным, и проходит как минимум 3 стадии:

    1. Первоначальная загрузка информации

    2. Накопление информации

    3. Выход на проектную мощность

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

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

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

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


Модели жизненного цикла ПО
Стандарт ISO/IEC 12207 не предполагает конкретной модели ЖЦ. Он описывает структуру процессов, но не конкретизирует детали, как реализовать и выполнить действия, включенные в процесс ЖЦ.

Под моделью ЖЦ понимается структура, которая определяет последовательность выполнения и взаимосвязи процессов, выполняемых на протяжении ЖЦ. Модель ЖЦ зависит от условий и назначения ИС.

В настоящее время распространены три модели ЖЦ:

1. Модель «водопад» или каскадная модель

2. Модель «водоворот» или поэтапная модель с промежуточным контролем.

3. Модель «спираль» или спиральная модель

Каскадная модель

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

  1. Этапы не перекрываются во времени

  2. Возврат к предыдущему этапу не предусмотрен

  3. Исправление ошибок выполняется только на стадии проектирования

  4. Результат появляется только в конце разработки

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

Плюсы:

  1. На каждом этапе формируется законченный набор документации

  2. Выполняемые работы позволяют планировать сроки получения готовой системы

Минусы:

  1. Существенное запаздывание получения результатов работы

  2. Как правило, информационные и функциональные модели системы устаревают с момента их утверждения

Данную модель ЖЦ использую при построении систем реального времени.
Поэтапная модель с промежуточным контролем



Модель характеризуется следующими свойствами взаимодействия этапов:

  1. Каждый этап имеет обратную связь с предыдущим

  2. Исправление ошибок происходит на каждом этапе, т.е. выполняется промежуточный контроль

  3. Этапы перекрываются во времени за счет наличия обратной связи

  4. Результат появляется только в конце разработки

«+» и «-» аналогичны каскадной модели.
Спиральная модель
Данная модель является самой молодой. По ней ведутся коммерческие разработки. На ней же реализованы методологии RUP и MSF.



  1. Анализ

  2. Проектирование

  3. Реализация

  4. Тестирование

  5. Внедрение

  6. Эксплуатация

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

Свойства взаимодействия этапов:

  1. Внутри витка спирали этапы не имеют обратной связи

  2. Исправление ошибок происходит на этапе тестирования, на каждом витке спирали

  3. Этапы могут перекрываться во времени в пределах одного витка спирали

  4. Результат появляется в конце каждого витка спирали и подвергается подробному анализу

  5. При переходе от витка к витку происходит накопление и повторное использование программных средств, моделей и прототипов

Основная особенность данной модели состоит в концентрации сложностей на этапах анализа и проектирования, при этом сложность и трудоёмкость последующих этапов в пределах этого витка относительно не высокие. Основной проблемой данной модели является определение момента перехода на следующий этап. Для решения этой проблемы вводят временные ограничения, поэтому переход осуществляется в соответствие с планом, даже в том случае, если не вся работа закончена.
Методологии разработки программных средств
Методология XP
Основоположником данной методологии является Кент Бекк. ХР является молодой методологией, основными принципами которой является:

  1. Простота решения

  2. Разработка малыми группами (до 10 человек)

  3. Обратная связь с клиентом

  4. Достаточная степень смелости и желание идти на риск

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

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

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

ХР характеризуют набором из 12 действий (практик), которые необходимо выполнять для достижения результата.

Практики ХР не определяют сам процесс ХР, но ХР определяет эти практики, т.е. выполнение практик не гарантирует результата.

  1. Планирование процесса. На данном этапе определяются свойства системы, способы реализации и трудоемкость

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

  3. Метафора системы. Под метафорой понимается простота именования классов и переменных. Команда разработчиков должна иметь единые правила именования

  4. Простая архитектура. Любое свойство системы должно быть реализовано как можно проще. За счет этого правила экономится время разработки

  5. Стандарты кодирования. Данные стандарты необходимы для обеспечения других действий: коллективное владение ядром системы, для парного программирования и для рефакторинга

  6. Рефакторинг. Это оптимизация существующего кода в сторону упрощения и сохранения прозрачности кода. Рефакторинг нельзя совмещать с дизайном

  7. Парное программирование. При разработке программ все программисты должны работать в парах, поэтому необходимо размещать программистов в одном месте, чаще всего на территории заказчика

  8. 40 часовая рабочая неделя. Программист не должен работать более 8 часов в день. Сверхурочная работа – это индикатор проблемы на данном направлении, которую нужно устранить

  9. Коллективное владение кодом. Каждый программист должен иметь доступ к коду системы, при этом соблюдается одно правило – если после внесения корректировок система работает не корректно, то программист, внесший изменения, должен выявить и исправить данную ошибку

  10. Частая смена версий. Общее правило для выпуска версий касается временного интервала. Минимальный срок – 1 день, максимальный – 1 месяц. Чем чаще выпускаются релизы, тем больше будет выявления ошибок

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

  12. Тестирование. Тестирование в данной методологии – одна из важнейших составляющих. Необходимые тесты пишутся еще до написания кода системы

Данная методология обладает высокой адаптацией к часто изменяющимся требованиям. Её основным недостатком является зависимость от человеческого фактора, поэтому в результате проект получается либо экстремально хорошим, либо плохим.
Методология RUP
Рациональный унифицированный процесс (RUP или РУП) – одна из спиральных методологий разработки ПО.

Данная методология официально поддерживается компанией Rational Software, обновляется два раза в год. В качестве языка программирования используется язык UML.

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

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

Для успешного процесса разработки необходимо 3 составляющих:

  1. Процесс

  2. Нотация

  3. Набор утилит

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

В этой методологии представлены все три компоненты.

Функции нотации

  1. Осуществляет «склеивание» процессов в единое целое

  2. Является языковым средством принятия решений

  3. Представляет семантику для наглядности решений

  4. Предлагает форму для принятия и манипуляции данными

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

В данной методологии в качестве нотации используется UML.

Методология РУП предоставляет структурный подход к разработке ПО и подразделяет процессы разработки на 4 основные фазы:

  1. Исследование (начало)

  2. Уточнение плана

  3. Конструирование (построение)

  4. Переход

Целями каждой из фаз является:

  1. Начало – фаза сбора информации, анализа требований, определение образа проекта

  2. Уточнение плана – фаза анализа требований проектирования системы, планирование действий и ресурсов, спецификации процедур, разработка особенностей дизайна

  3. Конструирование – фаза разработки, кодирования, создание бета-версий программы

  4. Переход – фаза создания конечной версии продукта, внедрение продукта и поставка конечному пользователю

Методология РУП основана на основных 9 потоках, которые являются основными элементами итераций ЖЦ.

  1. Бизнес-анализ – предполагает анализ требований на данной итерации ЖЦ, определение необходимых параметров системы и нужд пользователей.

  2. Требования, т.е. формализация образа системы – предполагает сбор сведений и перевод требования в функциональные спецификации.

  3. Анализ и моделирование, т.е. перевод собранных требований в программную модель.

  4. Реализация и кодирование, т.е. написание кода программы.

  5. Тестирование – на данном этапе происходит тестирование продукта

  6. Внедрение – на данном этапе предполагается внедрение продукта у заказчика, подготовка персонала, запуск системы и приемо-сдаточные испытания.

Особенностью методологии являются временные этапы, а именно на каких итерациях будут доминировать те или иные потоки, а также наличие специального языка и набора утилит, которые позволяют описать процесс разработки.
Методология MSF (Microsoft Solution Framework)
Данная методология разрабатывается компанией Майкрософт, базируется на опыте компаний по созданию больших проектов, их дальнейшему сопровождению. Особенности данной методологии заключаются в гибкости и отсутствии жестких процедур разработки.

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

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

Веха «Концепция утверждена» - главная веха выработки концепции. К моменту её достижения заказчик и проектная группа должны прийти к общему соглашению о задачах проекта и его временных рамках. Результатами данной фазы являются:

  1. Общее описание проекта

  2. Документ оценки риска

  3. Описание структуры проекта

Фаза планирования – на ней выполняется функциональная спецификация, разрабатывается дизайн, оцениваются затраты и сроки разработки.

Существует три уровня процесса проектирования:

  1. Концептуальный дизайн

  2. Логический дизайн

  3. Физический дизайн

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

Результатами фазы планирования являются:

  1. Функциональная спецификация

  2. План управления

  3. Календарный план (график) проекта

Фаза разработки – на данной фазе создается программный код. Часть команды разработчиков принимает участие в тестировании готовых модулей. Данная фаза завершается вехой «Разработка завершена». К моменту ее наступления создание всех составляющих проекта завершено. Проект полностью готов к тестированию.

Результатами фазы разработки являются:

  1. Исходный и скомпилированный код приложения

  2. Скрипты установки и конфигурирования

  3. Окончательная, функциональная спецификация

  4. Материалы сопровождения и поддержки решения

  5. Спецификации и сценарии тестирования

Фаза стабилизации – на данной фазе происходит тестирование проекта. Обычно в начальной фазе скорость появления ошибок превосходит скорость устранения их. Нельзя заранее сказать, сколько потребуется времени на их устранение. Данная методология не использует понятия бета-версия. Как только создана достаточно стабильная версия, происходит ее пилотное внедрение. Фаза завершается вехой «Готовность решения утверждена». К этому моменту завершаются работы по устранению ошибок, и происходит выпуск или внедрение продукта.

Результатами фазы стабилизации являются:

  1. Окончательный продукт

  2. Документация выпуска

  3. Материалы поддержки решений

  4. Инструментарий тестирования

  5. Исходный и исполняемый код приложения

  6. Проектная документация

Фаза внедрения – на данном этапе внедряются технологии и компоненты ПО, обучается персонал, вырабатывается окончательное заключение о работе продукта. Данный этап заканчивается вехой «Внедрение завершено». К этому моменту заказчик должен начать получать бизнес-отдачу, а проектная группа – свернуть свою деятельность.

Результатами фазы внедрения являются:

  1. Система поддержки

  2. Отчеты и журналы протоколов

  3. Версии проектных документов

  4. Отчет о завершении проекта

  5. Показатели качества от заказчика


Методология RAD (Rapid Application Development)
Одним из важнейших подходов спиральной методологии разработки ПО является методология быстрой разработки (РАД). Под этим термином понимается процесс разработки, который содержит 3 элемента:

  1. Небольшая группа программистов (до 10 человек)

  2. Короткий производственный график

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

ЖЦ по данной методологии состоит из 4-х фаз:

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

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

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

  4. Фаза внедрения

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

Фаза проектирования – на данном этапе часть пользователей принимает участие в проектировании. Для более быстрой разработки используются CASE – средства. С помощью пользователей уточняют и дополняют требования к системе, корректируется функциональная модель. В результате данного этапа должно быть готово:

  1. Информационная модель системы

  2. Функциональные модели системы и подсистемы

  3. Интерфейсы взаимодействия между подсистемами

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

Фаза построения - на данном этапе происходит самая быстрая разработка. Ускорение разработки достигается за счет использования автоматически сгенерированных кусков программного кода при помощи CASE – средств. По окончании работ над отдельной подсистемой происходит ее интеграция в систему. Также на данном этапе выполняется тестирование системы.

Результатом данного этапа является:

  1. Физическое проектирование БД

  2. Определение требований к аппаратным ресурсам

  3. Определение способов повышения производительности

  4. Завершение разработки документации проекта

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

Основные принципы методологии РАД:

  1. Разработка приложений итерациями

  2. Необязательность завершения работ на каждом этапе

  3. Обязательность привлечения пользователей к разработке

  4. Использование CASE – средств для обеспечения целостности проекта

  5. Использование средств управления конфигурацией

  6. Использование генераторов кода

  7. Использование прототипов

  8. Тестирование выполняется одновременно с разработкой


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

  1. Принцип решения сложных проблем путем их разбиения на более мелкие

  2. Принцип иерархического упорядочения, т.е. упорядочение составных частей в древовидные структуры

  3. Принцип абстрагирования, т.е. выделение наиболее существенных, характерных черт системы

  4. Принцип формализации, т.е. необходимость строгого методичного подхода

  5. Принцип непротиворечивости, т.е. согласованность элементов

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

На текущий момент широкое распространение получили следующие модели структурного анализа:

  1. SADT

  2. DFD

  3. ERD


Методология функционального моделирования SADT
Данная методология разработана Дугласом Россом. На ее основе построена методология IDEF0. SADT представляет собой совокупность методов, правил и процедур и используется для построения функциональной модели какой-либо предметной области. Построенная модель отображает структуру объекта, производимые им действия и связи между ними.

Методология SADT базируется на двух основных принципах:

  1. Графическое представление блочного моделирования

  2. Связи в модели должны подчиняться точности и строгости:

а) Ограничение количества блоков на каждом уровне

б) Связность диаграмм

в) Уникальность меток и наименований

г) Разделение входов и управлений

Состав функциональной модели.

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

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

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

  1. Каждая подфункция может содержать только те же элементы, которые входят в исходную функцию.

  2. Модель не может опускать какие-либо элементы для сохранения целостности системы.


Тип связей между функциями


  1. Тип случайной связности – возникает, когда конкретная связь между функциями мала или полностью отсутствует

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

  3. Тип временной связности – элементы данного типа возникают вследствие того, что они представляют функции, связанные по времени, когда данные используются одновременно, или функции включаются параллельно, а не последовательно.

  4. Тип процедурной связности – возникает вследствие того, что функции выполняются в течение одной и той же части цикла или процесса.






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





  1. Тип последовательной связности – при данном типе связи выход одной функции служит входными данными для следующей функции.




  1. Тип функциональной связности – диаграммы данного типа отражают полную функциональную связность при наличии полной зависимости одной функции от другой.




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

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

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

Системы и подсистемы – при построении сложных систем система может быть представлена в самом общем виде, либо декомпозирована на подсистемы.


1 – Номер системы

2 – Имя системы

3 – Имя проектировщика

Процессы – это преобразование входных потоков данных в выходные, в соответствии с определенным алгоритмом. На практике процесс может быть реализован в виде подразделения организации, которая выполняет обработку входных документов и выпускает отчеты. Изображается как подсистема, но в названии присутствует глагол.

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


DN – обязательно присутствует, N – порядковый номер накопителя.

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

Первым шагом при построении является построение диаграмм. Если система простая, то строится единственная диаграмма со звездообразной топологией.

Признаки сложной системы:

  1. Наличие большого числа внешних сущностей

  2. Распределенная природа системы

  3. Многофункциональность системы

При детализации диаграмм должны выполняться следующие условия:

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

  2. Правило нумерации – при детализации должна сохраняться иерархичная нумерация

Детализация завершается при выполнении следующих условий:

  1. Наличие у процесса небольшого количества входных и выходных потоков

  2. Возможность описания процессов системы в виде одного законченного алгоритма

  3. Выполнение процессом логических функций из входной в выходную


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

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

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

Пример:

Рассматривается деятельность компании по торговле автомобилями. Выделяются три основных лица персонала: главный менеджер – он должен знать, сколько заплачено за машину и какие расходы. На основе этих данных он устанавливает нижнюю цену продажи. Второе лицо – продавец. Ему необходимо знать, какую цену запрашивать, какая нижняя цена, и основную информацию о машине. Третье лицо – администратор. Его задача – составление контракта. Для этого ему нужна информация о покупателе, машине и продавце.

Первый шаг моделирования – извлечение информации и выделение сущностей.

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

Каждая сущность обладает свойствами:

  1. Уникальное имя

  2. Наличие атрибутов

  3. Наличие связей с другими сущностями



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

Различают несколько типов связей и обязательностей.



  1. Связь «много»

  2. Связь «один»

  3. Связь «необязательная»

  4. Связь «обязательная»



Следующим этапом моделирования является описание атрибутов системы. Атрибут – это любая характеристика сущности, значимая для рассматриваемой области и предназначенная для идентификации или классификации сущностей.

«*» - обязательные

«°» - необязательные

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


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

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

Рекурсивная связь – сущность может быть связана сама с собой.

Неперемещаемая связь – т.е. экземпляр сущности не может быть перенесен из одного узла связи в другой.


Методологии IDEF1X
Данный метод разработан Рамэем. Основан на подходе Чена и позволяет построить модель, эквивалентную данных реляционной модели в третьей нормальной форме. В настоящее время на основе методологии IDEF1 разработана IDEF1X, к которой были предъявлены следующие требования:

  1. Простота изучения

  2. Возможность автоматизации

На основе IDEF1X построен ряд CASE – средств, таких, как Erwin, Designer.

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

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

В методологии выделяют различные типы мощности связи:

1. Каждый экземпляр сущности – родителя может иметь 0, 1 или более связанных с ним сущностей экземпляров – потомков.

2. Каждый экземпляр сущности – родителя должен иметь не менее одного связанного с ним сущности – потомка.

3. Каждый экземпляр сущности – родителя связан с некоторым числом сущностей – потомков.

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

Идентифицирующая связь изображается сплошной линией. Сущность – потомок в таком типе связи является зависимой от идентификатора сущности.

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

Сущности могут также иметь внешние ключи (FK), которые могут использоваться в качестве части или целого первичного ключа.

Архитектура ИС
Файл-серверная архитектура
Данная архитектура наиболее распространена по следующим причинам:

- сокращение автономности ПО клиента

- простота организации

- сохранение привычных условий для пользователя


При всей простоте организации необходимо учитывать особенности:

- при работе с БД необходимо учитывать особенности каждой выбранной СУБД;

- необходимо учитывать особенности поддержания целостности и надежности хранимой БД. Для этого должно выполняться:

  • Наличие транзакционного управления

  • Хранение избыточных данных

  • Возможность введения ограничений целостности и их проверку

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

  • На стороне «клиент» выполняется ввод приложения, в который обязательно входят компоненты, поддерживающие интерфейс с пользователем;

  • Клиентская часть приложения взаимодействует с клиентской частью СУБД, которая является представителем СУБД для приложения.



Интерфейс (ИФ) между клиентской частью приложения и клиентской частью сервера БД основан на использовании языка SQL. Функции предварительной обработки, предназначенные для запросов к БД или формирования конечных отчетов, выполняются в коде приложения. Клиентская часть сервера БД, используя средства сетевого доступа, обращается к серверу БД, передавая ему текст на языке SQL. На стороне сервера БД происходит компиляция полученных операторов на языке SQL, далее выполняются операторы, результаты обработки передаются клиентской части приложения и в конечном итоге – пользователю.

В клиент-серверной архитектуре клиенты могут быть достаточно «тонкими», а сервер д.б. настолько «толстым», чтобы удовлетворить запросы всех клиентов.

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

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

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

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

- в ручном режиме

Архитектура клиент-сервер является более дорогой по сравнению с файл-серверной, требуется более мощная аппаратура для сервера и более развитые СУБД.

Однако наряду с этим недостатком, существует основное достоинство данной архитектуры, заключающееся в масштабируемости системы и способности к развитию.
Internet – приложение
IntraInternet – архитектура базируется на протоколе http. Данная служба получила широкое распространение по ряду причин:

  • Достаточно просто разработать ИС, а затем осуществить доступ по данному методу

  • Наличие готовых клиентских частей (браузеры)

Наряду с этими достоинствами существует ряд ограничений:

  • В данной ИС отсутствует прикладная обработка данных,

  • Гипертекстовые структуры сложно модифицируются

  • Пользователь имеет право только просматривать данные

  • Недостаточно организован поиск информации. Однако все эти причины могут быть разрешены с использованием более развитых механизмов WEB-технологий.

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

Данный метод доступа используется для обеспечения доступа к БД в Интернет системах. Язык HTML позволяет вставлять в документ необходимые формы. Когда браузер встречает форму, он предлагает пользователю заполнить её, а затем посылает серверу сообщение, которое содержит введенные параметры. Как правило, к сообщению приписывается внешняя процедура сервера. При получении сообщения от клиента сервер вызывает указанную процедуру и передает ей параметры, введенные пользователем. Таким образом, процедура играет роль шлюза между веб-сервером и сервером БД.



Системы оперативной обработки данных (OLAP - системы)
OLAP системы – аналитические системы, помогающие принимать бизнес-решения за счет динамически проводимых анализов моделирования или прогнозирования данных.

Данные системы использую в случаях:

  1. Если основным источником информации является деятельность какой-либо корпорации

  2. Если для оперативной обработки требуются свежие данные

  3. Если одновременно существуют несколько ОС

  4. Если БД являются сильно изменчивыми

  5. Если информация БД настолько критична для корпорации, что для ее защиты требуются более тонкие приемы защиты.





Склады данных (Data Ware Housing)
Хранилища такого типа наиболее актуальны. Они характеризуются большим объемом редко изменяемых данных. Хранилища могут обмениваться информацией с другими хранилищами (VLBD – очень большие хранилища данных)

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

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

  1. Программное обеспечение источников данных

  2. Загрузочная секция (отвечает за трансформацию информации)

  3. Программное обеспечение трансформации данных (пересылка, проверка на корректность)

  4. Хранилища данных (несколько параллельных серверов БД, которые обеспечивают переработку информации и хранение)

  5. Интерфейс клиента




CASE – средства

Истоки возникновения Case средств

Современные проекты характеризуются следующими особенностями:

  1. Сложность описания данных и взаимосвязи между ними

  2. Наличие совокупности тесно взаимосвязанных компонентов

  3. Отсутствие прямых аналогов

  4. Функционирование в неоднородной аппаратной среде

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

  1. Неадекватная спецификация требований

  2. Неспособность обнаруживать ошибки в проектных решениях

  3. Низкое качество документации

  4. Затяжной цикл и не удовлетворительные результаты тестирования

Первоначальное значение термина Case средства ограничено вопросами автоматизации.

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

В связи с применением Case средств необходимо учитывать:

1. Case средства не дают немедленный эффект внедрения

2. Реальные затраты на внедрение Case средств превышают затраты на приобретение

3. Case средства обеспечивают возможность для получения выгоды только после успешного их внедрения.

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

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

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

  3. Область управления, т.е. четкое руководство и организованность

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

При внедрении Case средств необходимо отметить ряд проблем:

  1. Отсутствие полного соответствия между процессами и методами, которые поддерживают Case средства и которые используются в организации.

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

  3. Негативное отношение персонала к использованию новых Case средств


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

^ Метод - процедура или техника генерации описания компонентов системы.

Нотация – отображение структуры системы, элементов данных, этапов обработки, а также описание проекта системы на формальных и естественных языках.

^ Инструментальные средства Case – это специальные программы, которые поддерживают одну или несколько методологий анализа и проектирования ИС.
Архитектура Case средств


  • Ядром системы является репозиторий. Он представляет собой специализированную БД, которая используется для отображения состояния системы в любой момент времени. Репозиторий содержит информацию о всех объектах проектной ИС. В репозитории хранятся описания следующих объектов:

  1. Имена проектировщиков и их права доступа

  2. Организованные структуры

  3. Компоненты диаграмм и диаграммы в целом

  4. Структуры данных

  5. Взаимосвязи между диаграммами

  6. Программные модули, процедуры и библиотеки модулей

  • ГРД используется для отображения в графическом виде заданной нотации проектной ИС. Он позволяет выполнять следующие операции:

  1. Создавать элементы диаграмм и взаимосвязи между ними

  2. Задавать описание элементов диаграмм

  3. Редактирование элементов диаграмм и их взаимосвязь

  • Верификатор диаграмм – используется для контроля правильности построения диаграмм заданной методологии проектирования. Он выполняет следующие функции:

  1. Мониторинг правильности построения диаграмм

  2. Диагностика и выдача сообщений об ошибках

  3. Выделение на диаграмме ошибочных элементов

  • Документатор – позволяет получить информацию о состоянии объекта в виде различных отчетов.

  • Администратор проекта – инструменты, необходимые для выполнения следующих функций:

  1. Инициализация проекта

  2. Задание начальных параметров проекта

  3. Назначение и изменение прав доступа к объектам проекта

  • Сервис – набор системных утилит для обслуживания репозитория.

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

Всё большую популярность приобретают системы, ориентированные на создание и генерацию БД, а также интерфейсов к ним, поэтому стратегия выбора Case средств зависит как от целей и потребностей самого проекта, так и квалификации персонала. При выборе Case средств необходимо учитывать следующие аспекты:

  1. Наличие БД, архива или словаря

  2. Интерфейсы с другими Case системами

  3. Возможности экспорта и импорта информации

  4. Открытая архитектура

  5. Наличие необходимых методологий

  6. Графические средства поддержки проекта

  7. Генерация кода программа

  8. Планирование и управление проектом

К Case средствам относят любое ПО, автоматизирует совокупность ЖЦ и обладает следующими характеристиками:

1. Мощное графическое средство для описания ИС, которое обеспечивает удобство работы пользователя

2. Интеграция отдельных компонентов с Case средства

3. Использование организованного хранилища проектных метаданных
Классификация Case средств
Все Case средства могут быть классифицированы по типам и категориям. Классификация по типам отражает функциональность Case средств. Классификация по категориям отражает степень интегрированности.

  • Современные Case системы классифицируются по следующим категориям:

1. По поддерживаем методологиям

- функциональный или структурно-ориентированный

- объектно-ориентированный

- комплексно-ориентированный

2. По поддерживаем графическим нотациям

3. По степени интегрированности

4. По типу и архитектуре вычислительной техники

5. По типу коллективной разработки

6. По типу операционной среды

  • Классификация по типам:

  1. Средства анализа (Design, BpWin)

  2. Средства анализа и проектирования (Designer 2000 - Oracle)

  3. Средства проектирования БД (ErWin, Designer 2000 - Oracle)

  4. Средства разработки приложений (Developer 2000 – Oracle, Delphi)

  5. Средства реинженеринга (ErWin, Rational Rose)


Оценка и выбор Case средств
Процесс оценки и выбора может преследовать несколько целей:

- оценка нескольких Case средств и выбор одного

- оценка нескольких Case средств и сохранение результата для последующей оценки

- выбор одного или нескольких Case средств с использованием результатов предыдущих оценок.



1 – уточнение критериев

2 – оценка Case средств

3 – выбор Case средств

4 – список критериев

5 – пользовательские потребности

6 – цели предположения и ограничения

7 – доступные Case средства

8 – уточненный список критериев

9 – потребность в дополнительной информации

10 – результаты оценки

11 – рекомендуемое решение
Входной информацией для процесса оценки является:

  1. Определение пользовательских потребностей

  2. Цели и ограничения проекта

  3. Данные о доступных Case средствах

  4. Список критериев, используемых для оценки

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

Определение списка критериев основано на пользовательских требованиях и включает:

1. Выбор критериев для использования из приведенного списка

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

3. Назначение удельного веса каждому критерию
Процесс оценки
Целью процесса оценки – является определение функционирования и качества Case средств для последующего выбора. Оценка выполняется в соответствии с выбранными критериями и включает в себя следующие действия:

1. Формулировка задачи

2. Определение критериев оценки

3. Определение средств кандидатов

4. Оценка средств кандидатов на основе критериев

5. Подготовка отчета по результатам оценки

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

Все выбранные Case средства оцениваются по двум критериям:

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

        2. Субъективные критерии. Case средства оцениваются группой специалистов, которые используют одни и те же критерии.

Данный этап заканчивается заключением в виде оценки Case средств. Выполняется в виде отчета, который содержит:

  1. выбранные подходы и оценки

  2. информация о Case средствах кандидатах

  3. этапы оценки

  4. конкретные результаты оценки

  5. выводы и заключения


Процесс выбора
Процесс выбора включает следующие действия:

  1. формулировка задачи выбора

  2. выполнение всех необходимых действия по выбору

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

  4. подготовка отчета по результатам выбора

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

1. числовые меры в широком диапазоне

2. числовые меры в ограниченном диапазоне

3. двоичные меры

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



1 – надежность

2 – простота использования

3 – эффективность

4 – сопровождаемость

5 – общие критерии

6 – переносимость

7 – функциональные характеристики

8 – среда функционирования

9 – проектная среда

10 – ПО

11 – технологическая среда

12 – функции, ориентированные на фазы ЖЦ

13 – моделирование

14 – реализация

15 – тестирование

16 – общие функции

17 – документирование

18 – управление конфигурацией

19 – управление проектом
Выполнение пилотного проекта
Перед масштабным внедрением выбранного Case средства в организации выполняется пилотный проект. Целью такого проекта является экспертная проверка правильности решений, принятых на предыдущих этапах, и начальная подготовка к внедрению.

Пилотный проект представляет собой первоначальное реальное использование Case средства, он преследует следующие цели:

1. подтверждение результатов оценки

2. сбор необходимой информации для внедрения Case средств

3. накопление собственного опыта в использовании Case средств



1 – определение характеристик ПП

2 – планирование ПП

3 – выполнение ПП

4 – оценка ПП

5 – принятие решения о внедрении

6 – внедрение Case средств

7 – выполнение дополнительного ПП

8 – отказ от внедрения

ПП должен обладать следующими характеристиками:
1. Требуемая область применения

2. Масштабируемость

3. Представительность

4. Критичность

5. Авторитетность

6. Характеристики проектной мощности
Планирование ПП должно по возможности вписываться в процесс разработки организации. План должен содержать следующие пункты:

1. Цели, задачи, критерии оценки

2. Персонал

3. Процедуры и соглашения

4. Обучение

5. График и ресурсы

После завершения ПП, его результаты необходимо оценить и сопоставить с начальными потребностями организации.

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

1. Целесообразно ли внедрять Case средства

2. Какие конкретные особенности ПП привели к его успеху

3. Какие проекты или подразделения организации могли получить выгоду от внедрения Case средств

После ответа на них, принимается решение о внедрении Case средства. Варианты могут быть следующими:

1. Внедрить Case средство

2. Выполнить дополнительный ПП

3. Отказаться от внедрения Case средства

4. Отказаться от использования Case средства вообще

После оценки результатов внедрения Case средства, организация оценивает – реально ли повысилась производительность разработки ПО. Для оценки используются следующие критерии:

  1. Используемое время

  2. Время, выданное для конкретного специалиста

  3. Размер, сложность и качество ПО

  4. Удобство сопровождения ПО



^ ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННЫХ СИСТЕМ (2 семестр)
  1   2   3



Скачать файл (626 kb.)

Поиск по сайту:  

© gendocs.ru
При копировании укажите ссылку.
обратиться к администрации