Методы должны включать в себя

следующие компоненты:

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

Правила и ограничения, которые надо выполнять при разработке моделей (например, каждый объект должен иметь одинаковое имя)

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

Руководство по применению метода — описание последовательности работ (действий), которые надо выполнить для построения моделей (все атрибуты должны быть задокументированны до определения операций, связанных с этим объектом)

Начиная с 70-х годов создано достаточно много методов разработки ПО. Наиболее известны:

Метод структурного анализа и проектирования Том ДеМарко (1978),

Метод объектно-ориентированного анализа Буч (1994), Рамбо (1991).

Метод сущность-связь проектирования информационных систем Чен (1976)

UML Unified Modeling Language

блок-схемы (40г) ()

структурный анализ (60 г SADT, 70 г сущность-связь, потоков данных)

Объектно-ориентированный подход стандарт UML(1997 г.) С

тех пор вышло несколько

версий стандарта UML.

Текущая версия UML 2.4.1

Виды диаграмм

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

Структурные диаграммы

диаграммы классов (class diagrams) предназначены для моделирования структуры объектно-ориентированных приложений классов, их атрибутов и заголовков методов, наследования, а также связей классов друг с другом;

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

диаграммы объектов (object diagrams) применяются для моделирования фрагментов работающей системы, отображая реально существующие в runtime экземпляры классов и значения их атрибутов;

диаграммы композитных структур (composite structure diagrams) используются для моделирования составных структурных элементов моделей – коопераций, композитных компонент и т.д.;

диаграммы развертывания (deployment diagrams) предназначены для моделирования аппаратной части системы, с которой ПО непосредственно связано (размещено или взаимодействует);

Поведенческие

диаграммы

диаграммы активностей (activity diagrams) используются для спецификации бизнес-процессов, которые должно автоматизировать разрабатываемое ПО, а также для задания сложных алгоритмов;

диаграммы случаев использования (use case diagrams) предназначены для «вытягивания» требований из пользователей, заказчика и экспертов предметной области;

диаграммы конечных автоматов (state machine diagram) применяются для задания поведения систем;

диаграммы взаимодействий (interaction diagram):

диаграммы последовательностей (sequence diagram) используются для моделирования временных аспектов внутренних и внешних протоколов ПО;

диаграммы схем взаимодействия (interaction overview diagram) служат для организации иерархии диаграмм последовательностей;

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

временные диаграммы (timing diagrams) являются разновидностью диаграмм последовательностей и позволяют в наглядной форме показывать внутреннюю динамику взаимодействия некоторого набора компонент системы.

1. Диаграммы вариантов использования (Use Case)

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

.

Суть диаграммы use case

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

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

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

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