Курсовая работа (т): Моделирование при разработке программного обеспечения

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

Содержание

1. Введение в процесс моделирования

. Жизненный цикл программного обеспечения

.1 Понятие технологии разработки программного обеспечения

.2 Модели жизненного цикла

2.3 Rational Objectory Process - модель жизненного цикла

3. Объектно-ориентированный подход к разработке программного обеспечения

.1 Сущность объектно-ориентированного подхода

.2 Объект и класс

.3 Наследование и полиморфизм

.4 Унифицированный язык моделирования UML

. Введение в язык моделирования UML

. Строительные блоки UML

.1 Сущности

.2 Отношения

.3 Диаграммы

. Правила языка UML

. Общие механизмы языка UML

.1 Спецификация

.2 Дополнения

.3 Принятые деления

.4 Механизмы расширения

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

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

.1 Шаблоны классов

. Диаграммы состояний

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

.1 Состояния действия и состояния деятельности

.2 Переходы

.3 Ветвление

.4 Разделение и слияние

.5 Дорожки. Траектория объекта

. Диаграммы взаимодействий

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

.2 Диаграммы кооперации

.3 Семантическая эквивалентность

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

. Диаграммы развертывания

Литература

1.      Введение в процесс моделирования

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

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

-        визуализировать систему в ее текущем или желательном для нас состоянии;

-        определить структуру или поведение системы;

         получить шаблон, позволяющий затем сконструировать систему;

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

Длительный опыт использования моделирования позволил сформулировать четыре основных принципа.

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

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

         лучшие модели - те, что ближе к реальности;

         нельзя ограничиваться созданием только одной модели.

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

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

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

2.      Жизненный цикл программного обеспечения

2.1     Понятие технологии разработки программного обеспечения

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

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

2.2     Модели жизненного цикла

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

Первой по времени появления и самой распространенной явилась каскадная модель.

Основные этапы каскадной модели представлены на рисунке 2.1.

Рисунок 2.1 - Каскадная модель жизненного цикла ПО

Каскадная модель характеризуется следующими основными особенностями:

-        последовательным выполнением входящих в ее состав этапов;

-        окончанием каждого предыдущего этапа до начала последующего;

         отсутствием возврата к предыдущим этапам;

         наличием результата только в конце обработки.

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

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

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

Рисунок 2.2 - Итерационная модель жизненного цикла ПО

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

Рисунок 2.3 - Спиральная модель жизненного цикла ПО

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

2.3     Rational Objectory Process - модель жизненного цикла

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

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

-        модель ЖЦ;

-        действия;

         нотация языка.

Фирма Rational Software, разработавшая язык UML, предложила также и свою модель ЖЦ (рисунок 2.4), которая называется Rational Objectory Process (ROP). Основные свойства ROP-технологии:

-        ROP - итеративный процесс, в течение которого происходит последовательное уточнение результатов;

-        ROP направлен именно на создание моделей, а не на разработку каких-либо других элементов проекта (например, текстовых документов);

         Действия ROP определяются блоками использования.

ROP разбит на циклы, каждый из которых в свою очередь, состоит из четырех фаз:

-        начальная стадия (Inception);

-        разработка (Elaboration);

         конструирование (Construction);

         ввод в эксплуатацию (Transition).

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

Каждая стадия завершается в четко определенной контрольной точке (milestone). В этот момент должны быть достигнуты важные результаты и приняты критически важные решения о дальнейшей разработке.

Рисунок 2.4 - Модель жизненного цикла UML

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

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

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

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

3.      Объектно-ориентированный подход к разработке программного обеспечения

В начале 70-х гг. в США был отмечен кризис программирования (software crisis). Это выражалось в том, что большие проекты стали выполнятся с отставанием от графика или с превышением сметы расходов, разработанный продукт не обладал требуемыми функциональными возможностями, производительность его была низка, качество получаемого программного обеспечения не устраивало потребителей.

Аналитические исследования и обзоры, выполняемые в течение ряда последних лет ведущими зарубежными аналитиками, показывали не слишком обнадеживающие результаты. Так, например, в 1995г. компания Standish Group проанализировала работу 364 американских корпораций и итоги выполнения более 23 тыс. проектов, связанных с разработкой ПО, и сделали следующие выводы: только 16% проектов завершились в срок, 52,7% завершились с опозданием, расходы превысили запланированный бюджет.

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

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

3.1     Сущность объектно-ориентированного подхода

Принципиальное различие между структурным и объектно-ориентированным подходом заключается в способе декомпозиции системы. Объектно-ориентированный подход использует объектную декомпозицию, при этом статическая структура системы описывается в терминах объектов и связей между ними, а поведение системы описывается в терминах обмена сообщениями между объектами. Каждый объект системы обладает своим собственным поведением, моделирующим поведение объекта реального мира. Понятие "объект" впервые было использовано около 30 лет назад в технических средствах при попытках отойти от традиционной архитектуры фон Неймана и преодолеть барьер между высоким уровнем программных абстракций и низким уровнем абстрагирования на уровне компьютеров. С объектно-ориентированной архитектурой также тесно связаны объектно-ориентированные операционные системы. Однако наиболее значительный вклад в объектный подход был внесен объектными и объектно-ориентированными языками программирования: Simula, Smalltalk, C++, Object Pascal. На объектный подход оказали влияние также развивавшиеся достаточно независимо методы моделирования баз данных, в особенности подход "сущность-связь".

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

-        абстрагирование (abstraction);

-        инкапсуляция (encapsulation);

         модульность (modularity);

         иерархия (hierarchy).

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

-        типизация (typing);

-        параллелизм (concurrency);

         устойчивость (persistence).

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

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