Файл: Lektsii_TP.doc

Методика Джексона

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

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

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

• строят изображение структур входных и выходных данных;

• выполняют идентификацию связей обработки (соответствия) между этими данными;

• формируют структуру программы на основании структур данных и обнаруженных соответствий;

• добавляют блоки обработки элементов, для которых не обнаружены соответствия;

• анализируют и обрабатывают несоответствия, т. е. разрешают «столкновения»;

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

Методика Варнье-Орра.

Методика Варнье-Орра базируется на том положении, что и методика Джексона, но основными при построении диаграммы считаются структуры выходных данных и, если структуры входных данных не соответствуют структурам выходных, то их допускается менять. Таким образом, ликвидируется основная причина столкновений.

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

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

5.6. Case-технологии, основанные на структурных методологиях анализа и проектирования.

К нашему времени накоплен опыт успешного использования большинства известных методологий структурного анализа и проектирования в соответствующих CASE-средствах. Наибольшее распространение получили методологии: SADT (3, 3%), структурного системного анализа Гейна-Сарсона (20, 2%), структурного анализа и проектирования Йордана-Де (36, 5%), развития систем Джексона (7, 7%), развития структурных DSSD (Data Structured System Development) Варнье-Орра (5, 8%), анализ проектирования систем реального времени Уорда-Меллора и Хатли, информационного моделирования Мартина (22, 1%).

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

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

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

6. Анализ требований и определение спецификаций программного обеспечения при объектном подходе

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

Таким образом, на этапе анализа ставятся две задачи:

• уточнить требуемое поведение разрабатываемого программного обеспечения,

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

6.1. UML - стандартный язык описания разработки программных продуктов с использованием объектного подхода.

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

Рис. 6. 1. Объектная декомпозиция программы построения таблиц и графиков.

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

Конец «войне методов» положило появление в 1995 г первой версии языка UML (Unified Modeling Language - унифицированный язык моделирования), который в настоящее время фактически признан стандартным средством описания проектов, создаваемых с использованием объектно-ориентированного подхода. Его создателями являются ведущие специалисты в этой области Гради Буч, Ивар Якобсон и Джеймс Рамбо, которые использовали в своем языке все лучшее, что появилось в подходах этих авторов во время «войны методов».

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

Рис. 6. 2. Полная спецификация разрабатываемого программного обеспечения при объектном подходе (UML).

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

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

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

Модель процессов отображает организацию вычислений и оперирует понятиями «процессы» и «нити» Она позволяет оценить производительность, масштабируемость и надежность программного обеспечения.

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

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

Всего UML предлагает девять дополняющих друг друга диаграмм, входящих в различные модели:

• диаграммы вариантов использования;

• диаграммы классов;

• диаграммы пакетов;

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

• диаграммы кооперации;

• диаграммы деятельности;

• диаграммы состояний объектов;

• диаграммы компонентов;

• диаграммы размещения.

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

Помимо указанных диаграмм, как и при структурном подходе, спецификация обязательно включает словарь терминов, а также различного рода описания и текстовые спецификации. Конкретный набор документации определяется разработчиком. UML и предлагаемая теми же авторами методика Rational Unified Process поддерживаются пакетом Rational Rose фирмы Rational Software Corporation. Ряд диаграмм UML можно построить также средствами программы Microsoft Visual Modeler и других CASE-средств. По данным «USA Today» в настоящее время 49 из 50-ти ведущих компьютерных компаний USA пользуют UML при разработке программного обеспечения с использованием объектного подхода, что и позволяет говорить о том, что сегодня UML фактически стал стандартом описания подобных разработок.

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

Разработку спецификаций программного обеспечения начинают с анализа требований к функциональности, указанных в техническом задании. В процессе анализа выявляют внешних пользователей разрабатываемого программного обеспечения и перечень отдельных аспектов его поведения в процессе взаимодействия с конкретными пользователями. Аспекты поведения программного обеспечения были названы «вариантами использования» или «прецедентами» (use cases).

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

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

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

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

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

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

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