Функционально-ориентированные метрики
Исходят не из размера программного продукта, а из его функциональности.
Оценивают:
-характер пользовательского интерфейса;
-сложность выполняемой обработки;
-распространенность используемой конфигурации;
-степень сложности инсталляции;
-условия эксплуатации;
-степень модифицируемости.
Анализ предметной области
Деятельность, направленная на выявление реальных потребностей заказчика, а также на выяснения смысла высказанных требований, называетсяанализом предметной области(бизнес-моделированием, если речь идет о потребностях коммерческой организации).
Анализ предметной области – это первый шаг этапа системного анализа, с которого начинается разработка программной системы.
Разработчики должны научиться
-понимать язык, на котором говорят заказчики;
-выявить цели их деятельности;
-определить набор решаемых ими задач;
-определить набор сущностей, с которыми приходится иметь дело при решении этих задач.
Модели предметной области
Анализом предметной области занимаются системные аналитики или бизнес-аналитики;
Они передают полученные ими знания другим членам проектной команды, сформулировав их на более понятном разработчикам языке;
Для передачи этих знаний обычно служит некоторый набор моделей, в виде графических схем и текстовых документов;
Под системойподразумевается совокупность взаимодействующих компонентов и взаимосвязей между ними;
|
|
|
Моделью 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).
Стадия эскизного проектирования не является строго обязательной и может быть исключена, если основные проектные решения определены ранее или достаточно очевидны.
Детальное проектирование
На стадии детального проектирования конкретизируются решения архитектурного уровня и производится:
-разработка иерархии классов и структуры базы данных;
-построение алгоритмов для отдельных подзадач;
-поиск и подбор готовых компонентов для реализации некоторых функций системы
Интерфейсное проектирование
Целью интерфейсного проектирование является формирование интерфейса пользователя Пользовательский интерфейс объединяет в себе все элементы и компоненты программы, которые способны оказывать влияние на его взаимодействие с программным обеспечением.
Эскизное проектирование
Разрабатываемый программный продукт рассматривается как:
-часть системы обработки информации, включающей аппаратную и программную составляющие
-набор взаимодействующих подсистем
На этой стадии определяется архитектура системы.
Под архитектурой ПСпонимают набор ее внутренних структур, которые видны с различных точек зрения и состоят из:
-компонентов (достаточно произвольный структурный элемент ПС, который можно выделить, определив интерфейс взаимодействия между этим компонентом и всем, что его окружает)
-связей и возможных взаимодействий между компонентами,
доступных извне свойств этих компонентов
Эскизное проектирование обеспечивает:
-идентификацию подсистем
-определение характера взаимодействия подсистем и принципов управления ими
Включает три типа деятельности:
-структурирование системы
-моделирование управления
-декомпозиция подсистем на модули
Результаты эскизного проектирования представляются в виде эскизного проекта (Software Architecture Document).
Стадия эскизного проектирования не является строго обязательной и может быть исключена, если основные проектные решения определены ранее или достаточно очевидны.
Понятие архитектуры ПС
Под архитектурой ПСпонимают набор ее внутренних структур, которые видны с различных точек зрения и состоят из
-компонентов,
-связей и возможных взаимодействий между компонентами,
-доступных извне свойств этих компонентов.
Под компонентом в этом определении понимается достаточно произвольный структурный элемент ПС, который можно выделить, определив интерфейс взаимодействия между этим компонентом и всем, что его окружает.
Выбор архитектуры ПС задает способ реализации требований на высоком уровне абстракции.
Архитектура ПС почти полностью определяет его:
-надежность,
-переносимость,
-удобство сопровождения.
Архитектура ПС значительно влияет на:
-удобство использования (эргономичность),
-эффективность. Эти характеристики, однако, сильно зависят и от реализации отдельных компонентов.
Значительно меньшее влияние архитектура оказываетна функциональность – заданную функциональность можно реализовать, использовав совершенно различные архитектуры. Выбор архитектурного решения основан на компромиссе между требованиями к различным характеристикам ПС.
Структурирование системы
Система структурируется на несколько подсистем, являющихся относительно независимыми программными компонентами.
Модели структурирования:
Наиболее часто используются 3 модели системного структурирования (архитектуры):
-модель хранилища данных
-модель клиент-сервер
-многоуровневая модель.
Модель хранилища данных:
Подсистемы разделяют данные, находящиеся в общей памяти и, как правило, представляющие собой базу данных.
Модель применима, если основные функции системы связаны с хранением, обработкой и представлением больших объемов данных.
Модель клиент-сервер:
Решаемые задачи естественно распределяются между инициаторами и обработчиками запросов; возможно изменение внешнего представления данных и способов их обработки.
Используется для распределенных систем и в большинстве бизнес-приложений.
Многоуровневая модель:
Имеется естественное расслоение задач системы на наборы подзадач, которые можно решать последовательно
Компоненты разделяются на несколько уровней таким образом, что компоненты данного уровня могут использовать для своей работы только соседей или компоненты предыдущего уровня.
Модульные компоненты
Одним из основных способов разбиения системы на компоненты является модульная декомпозиция.
Программное средство представляется как набор программных модулей.
Программный модуль - это любой функционально законченный фрагмент ПС, оформленный в виде отдельного файла с исходным кодом или поименованной непрерывной его части (например, класс в ООП), предназначенный для использования в других программах.
Обычно модули проектируются таким образом, чтобы предоставлять программистам удобную для многократного использования функциональность (интерфейс) в виде набора функций, классов, констант.
Модули могут объединяться в пакеты и, далее, в библиотеки.
Модульная декомпозиция может осуществляться на основе:
-модели потока данных
-модели объектов
В основе модели потока данных лежит разбиение по функциям.
Модель объектов основана на сущностях, имеющих собственные наборы данных, состояния и наборы операций.
Детальное проектирование
На стадии детального проектирования конкретизируются решения архитектурного уровня и производится:
-разработка иерархии классов и структуры базы данных;
-построение алгоритмов для отдельных подзадач;
-поиск и подбор готовых компонентов для реализации некоторых функций системы
Проектирование интерфейса
Целью интерфейсного проектирование является формирование интерфейса пользователя.
Пользовательский интерфейс объединяет в себе все элементы и компоненты программы, которые способны оказывать влияние на его взаимодействие с программным обеспечением.
Элементы интерфейса
-набор задач пользователя, которые он решает при помощи системы;
-используемая системой метафора (например, Рабочий стол в MS Windows®);
-элементы управления системой;
-навигация между блоками системы;
-визуальный дизайн экранов программы;
-отображаемая информация и ее форматы;
-устройства и технологии ввода данных;
-диалоги, взаимодействие и транзакции между пользователем и компьютером;
-обратная связь с пользователем;
-поддержка принятия решений в конкретной предметной области;
-порядок использования программы и документация на нее.
Технический проект
Результаты детального и интерфейсного проектирования представляются в техническом проекте (Software Design Document).
Технический проект должен также содержать оценку экономической эффективности системы и перечень мероприятий по подготовке к ее внедрению.
Шаблоны проектирования
Шаблоны проектирования(паттерн, англ. design pattern) — это многократно применяемая архитектурная конструкция, предоставляющая решение общей проблемы проектирования в рамках конкретного контекста.
Преимущества шаблонов:
-описывают решения целых классов абстрактных проблем;
-позволяют унифицировать терминологию, названия модулей и элементов проекта;
-позволяют повторно использовать удачное решение;
-независимы от применяемого языка программирования.
Шаблоны делятся на:
-Шаблоны анализа(analysis patterns) –представляют собой типовые решения при моделировании сложных взаимоотношений между понятиями некоторой предметной области.
-Архитектурные шаблоны (architectural styles, architectural patterns) представляют собой типовые способы организации системы в целом или крупных подсистем; задают некоторые правила выделения компонентов и реализации взаимодействий между ними.
Шаблоны проектирования(design patterns) определяют типовые проектные решения для часто встречающихся задач среднего уровня, касающиеся структуры одной подсистемы или организации взаимодействия двух-трех компонентов.
-Идиомы(idioms, programming patterns) являются специфическими для некоторого языка программирования способами организации элементов программного кода, позволяющими решить некоторую часто встречающуюся задачу.
Шаблоны могут применяться на всех стадиях разработки программных систем, способствуя существенному сокращению этих сроков
Описание шаблонов:
При описании шаблона выделяют четыре его составляющих:
Имя
-Позволяет сразу обозначить проблему, пути ее решения и последствия
-Присваивание шаблонам имен позволяет проектировать на более высоком уровне абстракции
-С помощью словаря шаблонов можно вести обсуждение с коллегами, упоминать шаблоны в документации, представлять тонкости системы
Задача
-Описание того, когда следует применять шаблон
-Формулируется задача и ее контекст (например, представить алгоритм в виде объектов)
-Иногда в описание задачи входит перечень условий, при выполнении которых имеет смысл применять шаблон
Решение
-Описание элементов решения, отношений между ними, функций каждого элемента
-При этом решение – не конкретный дизайн или реализация, а абстрактное описание задачи и того, как она может быть решена с помощью некоего весьма общего сочетания элементов
Результаты
Результаты - это следствия применения шаблона и разного рода компромиссы
-Иногда в результатах может быть описан выбор языка и реализации
-В случае проектирования к результатам относят влияние на степень гибкости, расширяемости и переносимости системы
Шаблоны анализа
Шаблоны анализа (analysis patterns) –представляют собой типовые решения при моделировании сложных взаимоотношений между понятиями некоторой предметной области.
Делятся на шаблоны функционального и объектно-ориентированного анализа.
Используются на этапе анализа (предметной области, системного, требований)
Дата добавления: 2018-05-13; просмотров: 647; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!