Технология создания программной системы

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

1. сущность без атрибутов

2. сущность с атрибутами

3. сущность с уточнением атрибутов

Для сущности определены 2 понятия:

Супер-тип - сущность обобщающая некоторую группу сущности (подтипов). Он характеризуется общими для подтипов атрибутами и отношениями. Например: супертип - учащийся

Подтип

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

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

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Необязательная связь предоставляет собой условное отношение между сущностями.

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

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

Ассоциативная сущность представляет данные, которые ассоциируются с отношением между 2мя или более сущностями.

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

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

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

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

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

Рекурсивная связь:

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Предполагает что сущность может быть связана сама с собой

Неперещаемая

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

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

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

Схемы отношений между сущностями (копия).

Проектирование ПО при структурном подходе

Процесс проектирования сложного ПО начинается с уточнения его структуры т.е. определение структурных компонентов и связей между ними. Результат уточнения структуры Мб представлен в виде структурной или функциональной схем и описания спецификации компонентов. Структурной схемой называют схему отражающую состав и взаимодействие по управлению частей разрабатываемого ПО. Структурную схему разрабатывают для каждой программы входящей в пакет программ, а список программ пакетов определяют исходя из задач описанных в ТЗ. Самый простой вид ПО - это программа, которая в качестве структурных компонентов включает подпрограммы или библиотеки. Разработку структурной схемы программы выполняют методом пошаговой детализации. Функциональная схема - схема взаимодействия компонентов ПО с описанием информационных потоков, состава данных потоков, указания использования файлов и устройств. Для изображения функциональных схем используются специальные обозначения установленные стандартом ГОСТ 19.71-90. Функциональные схемы более информативны, чем структурные. Все компоненты структурных и функциональных схем дБ описаны.

Пример программного комплекса:

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Пример структурной схемы программного комплекса

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Пример структурной схемы программной системы

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Пример функциональной схемы комплекса программ

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

3

Функциональная схема программы системы

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

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

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

избегать дублирование действий в различных модулях. Целесообразнее выносить их в отдельные модули

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

Пример: разработать алгоритм программы построения графиков функций одной переменной на заданном интервале изменения аргумента от х1 до х2, при условии непрерывности функции на всём интервале определения.

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

Определение спецификаций ПО при объектном подходе

Модели разрабатываемого ПО при объектном подходе основаны на предметах и явлениях реального мира, поэтому на этапе анализов ставится 2 задачи:

уточнить требуемое поведение разрабатываемого ПО.

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

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

Например, объектная декомпозиция построения объектов и графиков:

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Для проектирования объектного подхода используется язык UML (unifaded model///) который является унифицированный языком моделирования, который в настоящее время признан стандартным средством описания проектов, создаваемая с использованием объектно-ориентированного программирования.

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

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

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

модель реализации - эта модель определяет реальную…… организацию в среде разработки.

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

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

Все эти модели характеризуют определённый аспект проектируемой системы и все вместе они представляют полную модель разрабатываемого ПО. Для построения этих моделей используется 9 диаграмм, которые описываются языком UML:

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

Диаграмма классов

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

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

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

Диаграмма деятельностей

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

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

Диаграмма размещения

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

Определение вариантов использования

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

Основные - они обеспечивают требуемую функциональность разрабатываемого ПО.

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

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

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

Название варианта	Выполнение задания
Цель	Получение результата решения задачи
Действующие лица	Пользователь,
Краткое описание	Решение задачи предполагает выбор задачи, выбор алгоритма, задание данных и получение результатов решений
Тип варианта	Основной

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

Пример, подробное описание варианта использования «Выполнения задания».

Типичный ход событий

Действия исполнителя	Отклик системы
1. Пользователь инициирует новое задание	2. Система регистрирует новое задание и предлагает список типов задач.
3. Пользователь выбирает тип задачи	4. Система регистрирует тип задачи и предлагает список способа задания данных
5. Пользователь выбирает способ задания данных: а) если выбран ввод с Клавы, смотри раздел ввод данных б) если выбран ввод из БД, смотри раздел выбор данных из базы	6. Система регистрирует данные и предлагает список решения
7. Пользователь выбирает алгоритм	8. Система регистрирует алгоритм и предлагает начать решение
9. Пользователь инициирует процесс решения	10. Система выполняет полноту определения задания и запускает подпрограмму решения задачи
11. Пользователь ожидает	12. Система демонстрирует юзеру результаты и предлагает сохранить их в БД
13. Юзер анализирует результаты и выбирает сохранить их в базе или нет	14. Если выбрано сохранение данных, то система выполняет запись данных задания в базу
	15 Система переходит в состояние ожидания

Альтернатива:

11. Если время выполнения программы с точки зрения пользователя велико, то он прерывает процесс выполнения

12. Система прерывает расчёты предлагает список алгоритмов решения и возвращается на шаг № 7.

Доп инфа

Необходимо обеспечивает произвольный выбор типа задачи

Необходимо обеспечить возможность выхода из варианта на люб этапе

Раздел: Ввод данных

Типичный ввод данных

Действие исполнителя	Отклик системы
1. Юзер выбрал ввод данных	2. Система последовательно запрашивает все данные
3. Юзер вводит данные	4. Система проверяет данные и запрашивает сохранять их в базе или нет
5. Пользователь отвечает на запрос	6. Если данные нужно сохранять, то система выполняет запись данных в базу и регистрирует их в текущем задании

Альтернатива

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

Раздел «Выбор данных из базы»

Типичный ход событий

Действие исполнителя	Отклик системы
1. Пользователь выбрал выбор данных из базы	2. Система демонстрирует список данных в базе
3. Пользователь выбирает данные	4. Система читает данные и регистрирует их в текущем задании

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

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

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

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

Связь - взаимодействие действующих лиц и соответствующих вариантов использования. Обозначается линией. Бывают 2х видов: использования и расширения

Использования - она подразумевает, что существует фрагмент поведения, который повторяется в нескольких вариантах использования. Этот фрагмент выполняют как отдельный вариант и указывают с ним связь типа «использования».

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

Пример, диаграмма вариантов использования длял систем решения задач

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

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

Диаграммы классов являются центральным звеном ООР методов разработки ПО. UML предлагает использовать 3 уровня диаграмм классов в зависимости от степени и детализации:

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

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

Уровень реализации - Диаграммы классов непосредственно показывают поля и операции конкретный классов

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

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

Между классами определяются отношения.

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

Отношение ассоциации означает наличие связи между экземплярами класса и объектами. Например, класс студенты, ассоциирован с классом институт. Ассоциация может иметь имя, например, обучается: в институте обучается студент.

Связь между экземплярами класса подразумевает некоторые роли. Роль связана с направлением ассоциации. У каждой роли есть имя, например, институт носит роль - место обучения, студент - обучающийся. Кроме этого роль обладает характеристикой множественности, которая показывает сколько объектов может участвовать в одной связи с каждой стороны. Множественно определяется след знаками: * - от0 до бесконечности, N….*; N; N1, N2….

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

Определение основных понятий предметной области, которые должны представляться на конкретной диаграмме в виде классов делят на 2 части:

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

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

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

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

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

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

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

Пример: Диаграмма последовательности системы для вариантов использования задачи решения системы задачи

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

После этого каждую операцию необходимо описать: для примера

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

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

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

Деятельность обозначается прямоугольником с закруглёнными краями с названием деятельности. Ромб - вывод. Линии - синхронизации. Чёрный кружок закрашенный - начало, чёрный круг с точкой внутри - конец.

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

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

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Пример: Диаграмма деятельности, уточняющей вариант использования «решения задачи» системы задач:

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Проектирование ПО при объектном подходе

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

Физическое проектирование при объектном подходе включает объединение классов и других ресурсов программных компонентов и размещение этих компонентов на конкретных устройствах.

Разработка структуры ПО при объектном подходе

Все классы можно отнести к определённому типу. Существует 4 типа классов:

Классы сущности. Они используются для представления сущности реального мира или внутренних элементов системы. Они не зависят от окружения и их используют в различных приложениях. Класс сущности обозначают на диаграммах Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Граничные классы (интерфейсные) они осуществляют взаимодействия между действующими лицами и внутренними элементами системы. К этому типу относят классы реализующие пользовательские интерфейсы и классы обеспеч интерф с аппаратными классами Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Управляющие классы. Служат для моделирования последовательного поведения заложенного в один или несколько вариантов использованияРазмещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

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

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Глобальный - пакет, с которыми связаны все пакеты разработанной системы

Пример: Разработать диаграмму пакетов: решение системы задач.

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Определение отношений между объектами

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

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

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

Класс алгоритм. Объекты этого класса определяют алгоритм решения задачи.

Данные. Объекты этого класса определяются при вводе или выводе из БД.

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

Диаграмма пакета данных для объекта задачи

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

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

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Условные обозначения передачи управления между классами:

сообщение

Создание объектаРазмещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Активизация объектаРазмещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Уничтожение объектаРазмещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Прерывание объектаРазмещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

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

1)нормальный процесс

2)прерывание последовательности пользователем

3)возникновение искажения

Предполагается, что при команде «создать» создаётся объект решения управлений.

Следующее сообщение «начать» активирует этот объект. Объект решения запрашивает у объекта класса «задание»- тип объекта «алгоритм» создать объект требуемого класса и активирует его, при этом может получать и обрабатывать сообщения.

Объект классов «алгоритм» запрашивает у объекта класса «задание данных» и начинает обработку. Нормально завершив обработку объект класса «алгоритм» передаёт объекту класса «задание» результаты и возвращает объекту «решение» признак нормального завершения. Объект «решение» уничтожает объект класса «алгоритм» и возвращает вызвавшему ему объекту признак нормального завершения.

Диаграмма последовательности действий сценария «процесс решения» при нормальном процессе.

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

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

Проектирование классов предполагает окончательное определение структуры. Определение структуры и поведения. Структура объектов определяется совокупностью атрибутов и операции классов. Каждый атрибут - это поле или совокупность полей данных содержащихся в объекте класса. Поведение объектов класса определяется реализуемыми обязанностями. Обязанности выполняются через операции класса. Таким образом при проектировании класса, кроме имени и полного списка атрибутов необходимо уточнить его ответственность и операции. В зависимости от степени детализации диаграммы классов обозначения атрибутов может включать: имя, тип, описание видимости и значения по умолчанию. Для этого используется следующий формат: <признак видимости> <имя>: <тип> = <значение по умолчанию>.

Признак видимости может принимать одно из 3х значений:

+общий,

-скрытый,

# защищённый

Операциями называют основные действия реализуемые классами. В отличие от методов операция не всегда реализуется непосредственно классами. Например, операция ввод числа может быть реализована не классом, а интерфейсным элементов «окно ввода». Описание операции на диаграмме класса имеет следующий вид: <признак видимости> <имя> (<список параметров>): <тип возвращаемого значения>.

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

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Переход обозначается линией со стрелкой, он может быть помечен меткой состоящей из 3х частей, каждую из которых можно опустить: <Событие>/<Условие>/<Действие>.

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

Условие - логическое выражение определяет переходы в 2 различных состояния.

Действия - задаются действия для перехода, которые являются мгновенными и не прерываемыми.

Пример диаграммы состояния для объекта класса «решение»:

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

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

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

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

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

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

Класс «решение». Объект класса решение обращается к классу алгоритм, соответственно необходимо иметь их адреса. Операции начать, прервать, обработать исключения вытекают из диаграмм последовательности действия. Таким образом результат уточнения атрибутов и операции классов имеет следующий вид:

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

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

Разработка пользовательских интерфейсов

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

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

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

Типы интерфейсов

Различают процедурно-ориентированный и объектно-ориентированный подход к разработки интерфейса.

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

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

Процедурно-ориентированные интерфейсы делят на 3 типа: примитивный, меню, со свободной навигацией.

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

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

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

Пример: разработать юзерский интерфейс построения графикой или вывода таблицы функций по данному ТЗ.

Примеры на листочках (в Эл виде)

Этапы разработки пользовательского интерфейса включают те же этапы что и разработка ПО:

постановка задачи - определяется тип интерфейса и общие требования к нему

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

проектирование - включает в себя проектирование диалогов и реализацию в виде процессов ввода и вывода.

реализация - включает программирование и тестирование интерфейсных процессов.

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

Так же в процессе обработки информации мозг сравнивает поступающие данные с предыдущими, поэтому при смене кадра мозг на некоторое время блокируется. Поэтому если необходима быстрая реакция пользователя то резкая смена картинки не рекомендуется. Краткосрочная память это самая узкое место в системе обработки информации человека. Её ёмкость 7+2 не связанных объекта. Невостребованная информация хранится не более 30 секунд. Если необходимо ввести или запомнить число или группу символов, то количество не должно превышать 7 + 2.

Особенности восприятия цвета

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

Особенности восприятия звука

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

Субъективное восприятие времени.

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

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

Существует 3 модели интерфейса:

модель программиста

модель пользователя

программная модель

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

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

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

уровнем подготовки владения компьютера

моделями выполнения операции в данной предметной области

устоявшимися стереотипами работы

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

Критерии оценки интерфейса пользователя:

Основным критерием оценки интерфейса пользователя является

простота освоения и запоминания системы

Скорость достижения результатов при использовании системы

субъективная удовлетворённость при эксплуатации системы

Классификация диалогов и общие принципы их разработки.

Различают в диалогах тип диалога и его форму.

Тип диалога определяет кто управляет процессом обмена информации, существуют 2 типа:

управляемый программой

управляемый пользователем

Диалог управляемый программой предусматривает наличие жёсткого линейного или древовидного сценария (когда есть альтернативные варианты) диалога заложенного в ПО. Такой тип диалога как правило содержит большое количество подсказок которое уточняет действия на каждом шаге

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

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

Фразовый диалог

Директивная

Табличная

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

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

Табличная форма. Она позволяет выбирать пользователю ответ из предложенных вариантов. Её не всегда можно использовать, только при определённом количестве ответов. Если количество ответов велико (более 20), то нужно отказаться от табличных форм.

Типы и формы диалога выбирают независимо друг от друга, любая форма применима для обоих типов диалогов

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

определение множества необходимых диалогов их основных сообщений и возможных сценариев. Проектирование абстрактных диалогов

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

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

Основные компоненты графических пользовательских интерфейсов

Современные графические ин WIMP (window icon mouse popup)

Окна - все виды делятся на 5 категорий:

Основное окно - рамка, основное меню

Дочернее или подчинённые окна

Диалоговое окно пункт меню/масштаб

Информационные окна (окно сообщений и окно помощи)

Окна меню

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

Мышь используется для прямого манипулирования изображения в интерфейсе.

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

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

Пример, разработать основное меню системы решения системы задач.

Это стандартный вариант меню для данной системы

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

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

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Через экранную форму

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Через закладки

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

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

Тестирование является важным и трудоёмким процессом разработки ПО. Существует 3 стадии тестирования:

Автономное

комплексное

системное

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

Тестирование - процесс выполнения программы, целью которого является выявление ошибок.

Процесс разработки ПО предполагает 3 стадии тестирования: автономное тестирование компонентов ПО, комплексное тестирование разрабатываемого ПО, системное (оценочное) тестирование на соответствие основным критериям качества. Основные принципы тестирования:

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

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

необходимо досконально изучать результаты каждого теста

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

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

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

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

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

не обнаруживает пропущенных маршрутов

не обнаруживает ошибок не зависящих от обрабатываемых данных

не даёт гарантии, что программа правильная.

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

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

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

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

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

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

Файл с критериями!!!

Функциональный подход Функциональное тестирование

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

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

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

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

Комплексное тестирование

Делится на восходящее и нисходящее.

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

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

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

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

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

Критерием для завершения тестирования служит 1 из 3х вариантов:

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

возможное количество ошибок (оценивается экспертно или по специальным методикам) достигает 93-95 %.

строят график зависимости количества обнаруженных ошибок от времени тестирования.

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Оценочное тестирование.

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

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

тестирование на предельных объёмах

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

тестирование удобства эксплуатации

тестирование защиты

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

тестирование требований к памяти

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

тестирование совместимости - приемлемость на разные версии

тестирование удобства установки

тестирование надёжности

тестирование восстановления

...