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

Общие сведения о языке ОМЬ как языке моделирования сложных систем

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

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

Моделирование в процессах разработки систем дает следующие преимущества [29]:

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

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

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

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

При проектировании программных систем моделирование используется для решения следующих задач [7, 21, 23]:

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

Для решения этих задач при описании поведения проектируемого программного продукта в настоящее время получил широкое распространение унифицированный язык моделирования UML [6]. Этот язык создавался как попытка объединить вместе объектно ориентированные подходы, получившие наибольшую поддержку и признание, а именно подходы Буча, ОМТ (техника объектного моделирования) и Обжектори (Objectory), предложенный Якобсоном. В середине 90-х гг. XX в. Буч, Румбах и Якобсон стали вместе работать в компании Rational. Здесь они разработали единый, общий и ныне широко используемый язык моделирования. С момента своего появления UML неоднократно подвергался доработке и изменениям. В настоящее время в основном используется версия UML 2.0, выпущенная в 2003 г. [17].

UML предполагает разработку нескольких моделей, совокупность которых описывает разрабатываемую систему [17, 25, 26]. Каждая модель относится к соответствующему этапу разработки системы и имеет собственное предназначение. При этом каждая из моделей состоит из одной или нескольких UML-диаграмм, которые можно классифицировать следующим образом:

  • • структурные диаграммы;
  • • диаграммы поведения;
  • • диаграммы взаимодействия.

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

Диаграмма классов (Class Diagram) - статическая структурная диаграмма, описывающая структуру системы. Она демонстрирует классы системы, их атрибуты, методы и зависимости между классами.

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

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

Диаграмма структуры (Composite Structure Diagram) - статическая структурная диаграмма, демонстрирует внутреннюю структуру классов и, по возможности, взаимодействие элементов (частей) внутренней структуры класса. Подвидом диаграмм композитной структуры являются кооперации (Collaboration Diagram, введены в UML 2.0), которые по-называют роли и взаимодействие классов в рамках кооперации. Кооперации удобны при моделировании проектирования.

Типы диаграмм в нотации UML 2.3

Рис. 5.21. Типы диаграмм в нотации UML 2.3

Диаграмма развертывания (Deployment Diagram) служит для моделирования работающих узлов (аппаратных средств, англ. - node) и артефактов, развернутых на них. В UML 2 на узлах разворачиваются артефакты (англ. - artifact), в то время как в UML 1 на узлах разворачивались компоненты. Между артефактом и логическим элементом (компонентом), который он реализует, устанавливается зависимость манифестации.

Диаграмма объектов (Object Diagram) демонстрирует полный или частичный снимок моделируемой системы в заданный момент времени. На диаграмме объектов отображаются экземпляры классов (объекты) системы с указанием текущих значений их атрибутов и связей между объектами.

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

Диаграмма деятельности (Activity Diagram) - диаграмма, на которой показано разложение некоторой деятельности на ее составные части. Под деятельностью (англ. - activity) понимается спецификация исполняемого поведения в виде координированного последовательного и параллельного выполнения подчиненных элементов- вложенных видов деятельности и отдельных действий (англ. - action), соединенных между собой потоками, которые идут от выходов одного узла ко входам другого.

Диаграмма автомата (State Machine Diagram, диаграмма конечного автомата, диаграмма состояний) - диаграмма, на которой представлен автомат с простыми состояниями, переходами и композитными состояниями.

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

Диаграмма прецедентов (Use Case Diagram, диаграмма вариантов использования) - диаграмма, на которой отражены отношения, существующие между акторами и прецедентами.

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

Диаграмма коммуникации (Communication Diagram, в UML 1.x - диаграмма кооперации, Collaboration Diagram) - диаграмма, на которой изображаются взаимодействия между частями композитной структуры или ролями кооперации. В отличие от диаграммы последовательности, на диаграмме коммуникации явно указываются отношения между элементами (объектами), а время как отдельное измерение не используется (применяются порядковые номера вызовов).

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

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

По причине того, что диаграммы Sequence и Collaboration являются разными взглядами на одни и те же процессы, Rational Rose позволяет создавать из Sequence-диаграммы диаграмму Collaboration и наоборот, а также производит автоматическую синхронизацию этих диаграмм.

Диаграмма взаимодействия (Interaction Overview Diagram) - разновидность диаграммы деятельности, включающая фрагменты диаграммы последовательности и конструкции потока управления.

Этот тип диаграмм включает в себя диаграммы Sequence Diagram (диаграммы последовательностей действий) и Collaboration Diagram (диаграммы сотрудничества). Эти диаграммы позволяют с разных точек зрения рассмотреть взаимодействие объектов в создаваемой системе.

Диаграмма синхронизации (Timing Diagram) - альтернативное представление диаграммы последовательности, явным образом показывающее изменения состояния на линии жизни с заданной шкалой времени. Может быть полезна в приложениях реального времени.

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

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

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

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

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

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

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

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

 
< Пред   СОДЕРЖАНИЕ     След >