Функционально-ориентированные метрики

Исходят не из размера программного продукта, а из его функциональности.

Оценивают:

-характер пользовательского интерфейса;

-сложность выполняемой обработки;

-распространенность используемой конфигурации;

-степень сложности инсталляции;

-условия эксплуатации;

-степень модифицируемости.

Анализ предметной области

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

Анализ предметной области – это первый шаг этапа системного анализа, с которого начинается разработка программной системы.

Разработчики должны научиться

-понимать язык, на котором говорят заказчики;

-выявить цели их деятельности;

-определить набор решаемых ими задач;

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

Модели предметной области

Анализом предметной области занимаются системные аналитики или бизнес-аналитики;

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

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

Под системойподразумевается совокупность взаимодействующих компонентов и взаимосвязей между ними;

Моделью Mнекоторой системы S называется информационный объект, который может быть использован для получения ответов на некоторый круг вопросов относительно S;

Цель моделирования:

Получение ответов на эту совокупность вопросов является целью моделирования;

Цель моделирования формулируется на самом раннем этапе разработки модели;

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

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

Виды моделей

Формальные модели, используемые на этапе анализа предметной области можно разделить на две группы:

-модели, зависящие от подхода к разработке (структурного или объектно-ориентированного);

-модели, не зависящие от подхода к разработке;

Методологии IDEF

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

IDEF0 – методологиясоздания функциональной модели системы (основана на методе SADT Росса);

IDEF1 – методологиясоздания информационной модели системы (основана на реляционной теории Кодда и использовании ER-диаграмм Чена);

IDEF2 – методологиясоздания динамической модели системы;

IDEF3 – методологиясоздания модели потоков работ (обычно используется вместе с диаграммами потоков данных DFD Data flow diagram)

Синтаксис IDEF0-моделей

Основной формой представления IDEF0-модели является диаграмма.

Каждая IDEF0-диаграмма содержит блоки (работы) и дуги (стрелки).

-Блоки изображают функции моделируемой системы.

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

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

Основные правила:

Каждая сторона функционального блока должна иметь стандартное отношение блок/стрелки:

-входные стрелки должны связываться с левой стороной блока;

-управляющие стрелки должны связываться с верхней стороной блока;

-выходные стрелки должны связываться с правой стороной блока;

-стрелки механизма (кроме стрелок вызова) должны указывать вверх и подключаться к нижней стороне блока;

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

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

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

Чтобы связать стрелку с меткой, следует использовать "тильду" (~)

Принцип декомпозиции

Функции моделируемой системы могут быть разбиты на составные части и представлены в виде более подробных диаграмм (принцип декомпозиции)

-Диаграмма верхнего уровня называется контекстнойи обеспечивает наиболее общее описание объекта моделирования

-За этой диаграммой следует серия дочерних диаграмм, дающих детальное представление об объекте.

Состав IDEF0-модели

IDEF0-модели состоят из трех типов документов:

-графических диаграмм(главный компонент IDEF0-модели, содержащий блоки, стрелки, соединения блоков и стрелок и ассоциированные с ними отношения)

-текста(используется для объяснений и уточнений характеристик, потоков, внутриблочных соединений и т.д.)

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

В методологии IDEF0 существует 6 типов отношений между блокамив пределах одной диаграммы:

-доминирование;

-управление;

-выход - вход;

-обратная связь по управлению;

-обратная связь по входу;

-выход – механизм

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

Эти диаграммы (Data flow diagramming, DFD) хорошо дополняют функциональные диаграммы модели, описывая потоки данных.

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

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

Преимущества DFD-диаграмм:

DFD-диаграммы создавались как средство проектирования программных систем, тогда как IDEF0 - как средство проектирования систем вообще.

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

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

Главная цель декомпозиции DFD-функций - продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами.

На DFD-диаграммах могут присутствовать следующие cинтаксические элементы:

Диаграммы потоков работ

IDEF3 – методология создания модели потоков работ (обычно используется вместе с диаграммами потоков данных DFD Data flow diagram)

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

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

Сценарием (Scenario) называется описание последовательности изменений свойств объекта, в рамках рассматриваемого процесса.

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

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

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

Синтаксические элементы

-Функциональные элементы или элементы поведения (Unit of Behavior, UOB), обозначающие событие, стадию процесса или принятие решения – изображаются прямоугольниками;

-Стрелки или линии являются отображением перемещения объекта между UOB-блоками в ходе процесса;

-Перекрестки (Junction) используются для отображения логики взаимодействия стрелок (потоков) при слиянии и разветвлении

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

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

В процессе проектирования разрабатывается логика решения проблем, выявленных на этапе системного анализа.

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

Стадии проектирования

Проектирование может выполняться как «вручную», так и с использованием различных средствами автоматизации

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

Эскизное проектирование

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

-набор взаимодействующих подсистем(на этой стадии определяется архитектура системы);

Обеспечивает:

-идентификацию подсистем

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

Включает три типа деятельности:

-структурирование системы

-моделирование управления

-декомпозиция подсистем на модули

Результаты эскизного проектирования представляются в виде эскизного проекта (Software Architecture Document).

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

Детальное проектирование

На стадии детального проектирования конкретизируются решения архитектурного уровня и производится:

-разработка иерархии классов и структуры базы данных;

-построение алгоритмов для отдельных подзадач;

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