13.09.2011 Технология разработки программных продуктов. Основные определения и подходы

Синдром «пользователь и разработчик». Данный синдром является следствием расхождения взглядов пользователя и разработчиков. Рекомендации по смягчению синдрома:

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

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

3. Аналитики думают что понимают проблему лучше самого пользователя. Решение: поставить аналитика на место пользователя.

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

1. Статус. Может быть: предлагаемая/утверждаемая/включенная функция

2. Приоритет или полезность. Критичная/важная/полезная

3. Трудоемкость: низкая/средняя/высокая

4. Риск: высокий/средний/низкий

5. Стабильность (вероятность того, что функция будет меняться): высокая/средняя/низкая

6. Целевая версия (указание версий продукта, в которые впервые появилась реализация данной функции)

7. Назначение (информация для разработчиков)

8. Обоснование(ссылка на источник запрашиваемой функции).

Методы выявления требования:

• Интервьюирование и анкетирование. Интервью помогает понять проблему, не оказывая влияния на ответы пользователей. Правила подготовки интервью:

1. Все вопросы должны быть составлены заранее

2. Перед интервью необходимо ознакомиться с информацией о клиенте

3. Необходимость кратно записывать ответы

Совещания, посвященные требованиям. Хорошо проведенное совещание по вопросам требования, имеет множество преимуществ:

1. помогает создать команду подчиненную одной цели,

2. все заинтересованные лица получают возможность высказаться,

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

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

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

Мозговой штурм и отбор идей. Все участники собираются в одной комнате. Им раздаются листки для заметок, не менее 25-ти листов (формат 7х12). Правила проведения мозгового штурма:

1. Не допускается критика и дебаты

2. Не ограничивать фантазию участников

3. Генерировать как можно больше идей

4. Переделывайте и комбинируйте идеи

Идеи записываются по принципам:

1. Сохраняется авторская формулировка идеи

2. Гарантия что идеи не будут утрачены

3. Перспектива развития идей в дальнейшем

4. Обеспечивается творческий процесс

• Раскадровка. Цель раскадровки выявление преждевременно реакции «да, но…». Существует три типа раскадровок:

1. Пассивная. Пользователю излагают некоторую историю с применением рисунка, схем, картинок.

2. Активная. Пользователю предлагают еще не созданный «фильм» с применением анимации и слайдов.

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

Применение прецедента. Рисуется схема с факторами…

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

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

Оценка качества процессов создания ПО

• Международные стандарты серии ISO 9000. Рекомендуется следующая схема процессов установки характеристика качества программ (стандарт 14 598):

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

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

3. Планирование и проектирование процессов оценки характеристик и атрибутов качества в жизненном цикле программного средства (ЖЦ ПС).

4. Выполнение измерений, сравнение результатов с критериями требований, обобщение и оценка результатов.

Характеристики оценки качества:

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

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

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

4. Оценка защищенности ПС. Включает определение полноты использования доступных методов и средств защиты программного средства от потенциальных угроз.

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

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

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

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

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

• CMM _ модель зрелости процессов создания ПО, предложенная SEI

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

Определение характеристик и субхарактеристик качества.

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

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

Правильность (корректность) – способность ПС обеспечивать правильные или приемлемые для пользователя результаты и внешние дефекты.

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

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

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

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

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

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

Мобильность – это подготовленность ПС к переносу с одной аппаратной платформы на другую.

Шкала CMM:

1. Начальный уровень.

2. Повторяемость. Установлены некоторые процессы, затраты, графики.

3. Разработка. Используются стандартные модели ЖЦ.

4. Контроль.

5. Улучшение качества.

Разработка программ подразумевает создание программных систем из фрагментов. Таким образом уверенность в компонентах которые юзаются должны исходить не только от разработчиков, но и от некоторого независимого эксперта. Зачастую уровень тестирования который может предложить SCL , бывает гораздо ниже уровня которые может предложить сам разработчик. Таким образом SCL выдает сертификаты основываясь не только на своих тестах. Гарантии на ПО должны опираться на результаты массового юзания в условиях реального мира. Подобное тестирование продемонстрирует стабильность продукта в конкретных средах и конкретных секторах рынка.

Сертификация ПО с участием пользователей.

20.09.2011

Интервью помогает понять проблемы влияния на ответы пользователя

Правила подготовки интервью:

• Все вопросы должны быть составлены за ранее

• Вы должны ознакомится с клиентом

• Кратко записывать ответы

Хорошо проведение совещание имеет множество преимуществ

Совещания

• Помогает создать команду подчинённой одной цели

• Все заинтересованные лица получают возможность высказаться

• Формируются соглашения между разработчиком и заказчиком по поводу того что должно делать приложение

• Может высветится и разрешится политический вопрос.

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

• Все материалы должны быть выданы за ранее

Мозговой штурм

• Все участники собираются в одной комнате им раздаются карточки для заметок.

• Не допускается критика или дебаты.

• Не ограничивать фантазию участников.

• Идей как можно больше.

• Переделывать и генерировать идеи.

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

Гарантия что идеи не будут утрачены

Перспективы развития идей в подальше

Все идеи будут сохранены

Раскадровка – выявление реакции на «да но» существуют три типа раскадровки

• пассивная

• активная

• интерактивная

Применение прецедентов – рисуются схемы с факторами

Обыгрывание ролей – данный способ позволяет разработчику прочувствовать потребности пользователей

Прототипирование - это частичная реализация системы созданная для того что бы помочь разработчикам пользователей и клиентов для определения требований

Оценка качества процессов создания ПО.

• международные стандарты серии ИСО 9000 – ИСО 9004

• СММ – модель зрелости

• Процесс сертификации программ на базе информации об их использовании

Схема процессов оценки характеристик качества программ

Рекомендуется следующая схема установки характеристик программ.

• Установка исходных требований для оценки (Определение цели испытания идентификация метрик программного средства, значение атрибутов качества)

• Выделение критериев для проведения экспертиз и измерений.

• Планирование и проектирование процессов оценки характеристик и атрибутов качества в жизненном цикле ПО

• Выполнение измерений сравнение результатов с критериями, обобщение и оценка результатов.

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

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

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

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

Оценка надежности измерение количественных метрик атрибута суб характеристик в использовании:

• завершённости

• устойчивости к дефектам восстанавливаемости

• Доступности

Потребность в ресурсах памяти и производительность

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

Оценка практичности функциональных средств

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

Оценка мобильности

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

Система управления

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

Определение характеристик и суб характеристик качества

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

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

Правильность – способность ПС обеспечивать правильные или приемлемые для пользователя результаты или внешние дефекты .

Способность взаимодействовать – свойство программного средства и их компонентов взаимодействовать с одной или большим числом компонентов внутренней или внешней среды .

Защищённость - это способность компонентов защищать программу и данные.

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

Эффективность – свойство программного средства обеспечивающие требуемую ПС для вычисления с учетом используемых ресурсов

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

Сопровождаемость - приспособленность программного средства к модификации и изменению конфигурации и функций.

Мобильность - это подготовленность ПС с одного аппаратного средства к другому

СММ уровни

1. начальный ( процессы носит хаотический характер).

2. повторяемость.

3. Разработка.

4. Контроль.

5. Улучшения качества.

Процесс сертификации программ на базе информации об их использовании

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

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

Даже если данная лаборатория использует лучшие методы невозможно предусмотреть воздействия пользователя

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

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

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

Этапы ЖЦ(ГОСТ 19.102-77)

1. Техническое задание:

Постановка задачи

выбор критерия эффективности

проведение предварительных научно пользовательских работ

разработка ТЗ

2. Эскизный проект

Структура выходных данных

Уточнение методов решения

Общий алгоритм

Разработка документации эскизного проекта

3. Технический проект

Уточнение структуры входных выходных данных

Разработка алгоритмов

Формы данных

Семантика и синтаксис языка

Структура программы

Конфигурация технических средств

4. рабочий проект

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

Разработка документов

Подготовка проведения испытаний

Корректировка программы и документов по итогам испытаний

5. Внедрение

Передача программы и документов для сопровождения

Оформление Акта

Передача в фонд алгоритмов и программ.

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

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

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

В процессе определения спецификаций строят общею модель предметной области и его поведение с окружающей средой.

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

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

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

Состоит и трех частей

Описание внешней информационной среды с которой будет работать система должны быть определены все используемые каналы ввода и вывода все информационные объекты

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

Описание исключительных ситуаций если таковые могут возникнуть при выполнении программы и реакции на эти ситуации.

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

К таким характеристикам относят

Правильность - функционирование в соответствии с техническим заданием.

Универсальность – обеспечение правильности работы при любых данных и неправильных данных

Надежность – (помехозащищённость) – обеспечение полной повторяемости результата, после сбоев

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

Точность результатов - обеспечение погрешности результата не выше заданной

Защищенность – обеспечение конфиденциальности защита информации.

Аппаратная совместимость - Возможность функционирования с некоторым оборудованием

Программная совместимость – это совместимость с другим ПО

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

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

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

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

Анализ требований и определение спецификаций при структурном подходе

На данном этапе необходимо построить модели ПО во взаимодействии с окружающей средой. Поскольку разные модели описывают ПО с разных сторон рекомендуют использовать сразу несколько моделей и сопровождать их описанием.

Структурный подход предполагает следующие модели

Диаграмма потоков данных(DEF – data flow diagrams)

Диаграмма сущность связь(ERD – entity – reltionship diagrams)

Диаграмма переходов состояний (SDT – state Transitions Diagrams)

Функциональных диаграмм(SADT)

Спецификация процессов

Словаря терминов

Спецификации процессов могут быть представлены в виде

Псевдокодов

Блок схем алгоритмов

Флов- форм

Диаграммы Насси-Шнедерма

Текстового описания

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

Линейный

Разветвлений

Циклический

Обозначение схем алгоритмов (ГОСТ 19.701-90)

Терминатор (овал)

Процесс(квадрат)

Данные (параллелограмм)

Решения (ромб)

Подготовка (шестиугольник)

Границы цикла

Предопределённый процесс(квадрат и имя процесса) – вызов процедур

Соединитель(Кружок) – маркировка разрыва линий

Комментарий -=

Базовые алгоритмические структуры

1. Следование

2. Ветвление

3. Цикл –пока

Дополнительные структуры алгоритмов

1. Выбор(кейс)

2. Цикл до(до - вайл)

3. Цикл с заданным числом повторений(фор)

Псевдокод - текстовая нотация

Флов формы – представляют собой графическую нотацию алгоритмов

Имеют вид прямоугольника и могут быть вписаны в любой внутренний прямоугольника другого символа

1 . Следование

2 . Ветвление

3. выбор

4. цикл пока

5. цикл до

6. счетный цикл

4.10.2011

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

Условные обозначения диаграмм Насси-Шнайдермана:

6. Выбор

<Действие 1>

<Действие 2>

Иначе <действие 3>

7. Ветвление

Да <действие 1>

Нет <действие 2>

Словарь терминов

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

Обычно описание терминов выполняется по следующей схеме:

1. Термин

2. Категория (понятие предметной области, элементы данных, условные обозначения т.д.)

3. Краткое описание.

Например:

1. Термин – вебсайт

2. Категория – интернет программирование

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

Диаграммы перехода в состояние

STD, демонстрирует поведение разрабатываемой программной системы, при получении управляющих воздействий (из вне).

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

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

Функциональные диаграммы

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

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

Основные элементы данной методологии основаны на следующих принципах:

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

2. Строгость и точность отображения.

В SADT диаграммах, функции представляются в виде блоков, а интерфейсы входов/выходов в виде дуг. Интерфейсные дуги отображают взаимодействие функций друг с другом.

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

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

2. Ограничение кол-ва блоков на каждом уровне декомпозиции

3. Синтаксические правила для графики

4. Связность диаграмм

5. Отделение организации от функции

6. Разделение входов и управлений.

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

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

Типы влияний блоков (входов):

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

2. Управление. Выход блока используется как управление для блока с меньшим доминированием (вход сверху).

3. Обратная связь по входу. Выход блока подается на вход блока с большим доминированием (возврат данных на вход).

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

5. Выход-исполнитель. Выход блока используется, как механизм для другого блока (вход снизу).

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

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

Все диаграммы связаны между собой иерархической нумерацией. Самый общий вид это А-0, второй уровень: А-1, третий уровень: А-1.1 и т.д. Где первая цифра – номер родительского блока, а последняя – номер конкретного блока детальной диаграммы.

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

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

Диаграммы потоков данных (DFD)

Данная диаграмма состоит из трех узлов: узлов хранения данных, внешних узлов, узлы обработки данных.

Дуги диаграммы соответствуют потокам данных передаваемых от узла к узлу и помечаются именами соответствующих данных. Для изображения диаграмм потоков данных традиционно используют нотации Йордана и Гейна-Сарсона.

Посмотреть в интернете обозначения элементов диаграмм потоков данных (DFD).

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

Правила детализации диаграмм:

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

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

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

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

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

1. Выделение множества требований в основные функциональные группы – процессы.

2. Выявление внешних объектов связанных с разрабатываемой системой.

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

4. Предварительная разработка контекстной диаграммы.

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

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

7. Проверка основных требований контекстной диаграммы.

8. Декомпозиция каждого процесса, текущей DFD с помощью детализирующей диаграммы или спецификации процесса.

9. Проверка основных требований по DFD соответствующему уровню.

10. Добавление определений новых потоков, в словарь данных, при каждом появлении их в диаграмме.

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

Пример: рассмотрим иерархию диаграммы потоков данных в программе сортировки одномерного массива.

11.10.2011

Диаграмма сущность-связь

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

Основные понятия

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

Существуют сущности:

1. Без атрибутов

2. С указанием атрибутов

3. С ключевым атрибутом.

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

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

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

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

Связь может иметь один из нескольких типов:

1. Один к одному (такая связь свидетельствует о том, что неправильно разбита одна сущность на две).

2. Один к многим (означает что один экземпляр одной сущности может быть связан с экземплярами другой сущности).

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

Каждая связь может иметь одну из двух модальных связей:

1. Может (-----)

2. Должен (_____________)

Анализ требований и объявление спецификаций при объектном подходе

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

Модель – упрощенное представление реальности.

Моделирование необходимо для решения следующих задач:

1. Визуализация системы

2. Определение ее структуры и поведения

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

4. Документирование принимаемых решений, используя полученные модели.

Для решения этих задач, при описании поведения проектируемого ПО, в настоящее время используется UML.

Спецификация разрабатываемого ПО, при использовании UML объединяет несколько моделей:

1. Модель использования содержит описание функций ПО с точки пользования

2. Логическая модель описывает ключевые понятия моделируемого ПО (классы, интерфейсы и т.д.), то есть средства, обеспечивающие его функциональность.

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

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

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

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

1. Диаграмма вариантов использования

2. Диаграммы классов

3. Диаграммы пакетов

4. Диаграммы последовательности действий

5. Диаграммы коопераций

6. Диаграммы деятельности

7. Диаграммы состояний объектов

8. Диаграммы компонентов

9. Диаграммы размещения

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