Проблемы разработки сложных программных систем

Проблемы разработки сложных программных систем

Сложные ПО:

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

2. коллективная разработка

3. необходимость увеличения степени повторяемости кодов

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

 

I.

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

 

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

 

 

Каскадная.

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

Достоинства:

1) получение в конце каждой стадии законченного набора проектирования документации

2) простота планирования процесса разработки.

Недостатки:

1) при неточных спецификациях приводят к пересмотру уже принятых решений.

2) Изменение требования заказа непосредственно в процессе разработки.

 

Модель с промежуточным контролем.

В данной схеме можно вернуться на любой уровень.

 

Спиральная модель.

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

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

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

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

- уменьшить вероятность морального устарения системы за время разработки.

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

1. Поддержка полного жизненного цикла ПО

2. Гарантированное достижения цели разработки с заданным качеством и в установленное время.

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

4. Минимальное время получения работоспособной системы

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

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

 

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

1. Анализ и планирование требования пользователя

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

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

4. Внедрение

 

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

Нормы определяющие количество человек для разработки человек: менее 1000 функциональных точек – 1 человек, от 1-4000 точек – команда (3-7 человек). На каждые 4000 точек – 1 команда.

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

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

Понятие технологичности ПО.

 

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

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

1. 1 точка входа

2. 1 точка выхода.

3. Отдельная компиляция

4. Соответствие принципу вертикального управления

5. Выполнение одной функции

6. Небольшой размер (50-70 операторов)

7. Возможность вызова других модулей

 

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

Существует 5 типов сцепления модулей:

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

2. сцепление по образцу – модули обмениваются данными, объединённые в некоторые структуры (элементы массива)

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

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

5. Сцепление по содержимому – один модуль содержит обращение к внутренним компонентам другого. Такой вид сцепления тоже не допустим.

 

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

1. Функциональная

2. Последовательная

3. Информационная (коммуникативная)

4. Процедурная

5. Временная

6. Логическая

7. Случайная

 

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

Последовательная – выход одной функции служит исходными данными для другой функции.

Информационная – считается функция обрабатывающая одни и те же данные.

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

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

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

Случайная – связь между элементами мала или отсутствует.

 

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

 

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

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

 

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

 

1. Вход-выход

 

 

1. Управление

 

1. обратная связь по выходу

 

 

1. Выход исполнитель

 

 

1. Обратная связь по управлению.

 

 

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

Символ обозначает тип связи:

I – входная информация

С – управляющая

М – механизм

R – результат

Число – номер связи с родительским блоком, считая сверху вниз и слева на право.

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

1й уровень нумеруется А0

2й уровень– А1, А2……

3й уровень – А11, А12, А21, А22……..

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

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

Термин: Алгоритм

Категория: Понятия предметной области

Описание: В данном проекте используется для обозначения команд

 

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

 

Верхнего уровня

 

Детализированная диаграмма

 

 

I1 – функция

I2 – отрезок

I3 – шаг

С1 – вид график/функция

R1 – график

R2 – таблица значений

 

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

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

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

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

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

4. Поток данных – процесс передачи инфы от источника к приёмнику.

 

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

 

Понятие	Йордана Де Морга	Гейна-Сарсона
Внешняя сущность	Наименование	Номер Наименование
Процесс
Накопитель данных
Поток

 

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

Диаграмма по Гейна-Сарсену

 

 

Диаграмма Джексона.

В основе диаграмм Джексона лежит предположение о том, что структуры данных, так же как и программ можно строить из элементов с использованием всего 3х основных конструкций (последовательности, выбора, повторения). Каждая конструкция представляется в виде 2х уровней иерархии. На верхнем расположен блок конструкция, на нижнем блоки элементов. Конструкции различают специальными символами в правом верхнем углу блоков элементов. При изображении последовательности символ не указывается. При изображении выбора ставится символ «О» - сокращённое от OR «ИЛИ». Конструкции последовательности и выбора обязательно должны содержать по 2 или более элементов 2го уровня. При изображении повторения в блоке единственного (повторяющегося) элемента ставится значок *

 

 

 

Скобочные диаграммы Орра

 

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

Пример: Описанить структуру данных файла «Электронная ведомость» которая отображает

№ группы, записи об успеваемости студентов (ФИО, предмет, оценка)

 

Сетевые модели данных

Используются в тех случаях, если отношения между компонентами данных не исчерпываются включением. Для графического представления используют 3 вида модели:

1. Модель П.Чена

2. модель Баркера

3. модель IDEF1

 

Модель Баркера является наиболее распространённой.

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

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

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

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

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

 

Сущность представляет собой множество экземпляров реальных или абстрактных объектов (людей, событий, предметов и т.д.). Имя сущности должно отражать тип или класс объекта, а не его конкретный экземпляр. На диаграмме Баркера сущность изображается прямоугольником с закруглёнными углами. Каждая сущность обладает одним или несколькими атрибутами. Атрибут – любая характеристика сущности, которая является значимой для рассматриваемой предметной области и предназначена для квалификации, идентификации, количественной характеристики или выражения состояния сущности. Атрибуты делятся на ключевые и описательные. Ключевые – это те которые входят в состав уникального идентификатора, описательные – все прочие. Все …… перемещают в начало списка и обозначают решёткой.

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

 

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

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

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

 

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

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

 

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

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

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

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

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

 

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

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

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

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

 

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

 

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

 

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

 

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

 

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

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

 

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

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

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

 

Доп инфа

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

 

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

 

 

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

 

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

 

 

 

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

 

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

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

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

 

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

 

 

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

 

 

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

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

+общий,

-скрытый,

# защищённый

 

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

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

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

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

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

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

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

 

 

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

 

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

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

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

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

 

 

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

 

 

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

 

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

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

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

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

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