Студопедия

КАТЕГОРИИ:

АвтомобилиАстрономияБиологияГеографияДом и садДругие языкиДругоеИнформатикаИсторияКультураЛитератураЛогикаМатематикаМедицинаМеталлургияМеханикаОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРелигияРиторикаСоциологияСпортСтроительствоТехнологияТуризмФизикаФилософияФинансыХимияЧерчениеЭкологияЭкономикаЭлектроника



Лабораторная работа №1. Тема: «Методология объектно-ориентированного моделирования»

Читайте также:
  1. Delphi. Работа с ресурсами
  2. Height и Angle не работает, если атрибут как выровненный текст.
  3. II Самостоятельная работа
  4. III. РАБОТА НАД РУКОПИСЬЮ ВКР
  5. IV. Повышение квалификации. Педагогическая деятельность. Санитарно-просветительская работа
  6. Oslash; 1. РАБОТА СО СТАНДАРТНЫМИ ПРИЛОЖЕНИЯМИ WINDOWS.
  7. quot;ПО ТУ СТОРОНУ ДОБРА И ЗЛА. Прелюдия к философии будущего" ("Jenseits von Gut und Bose", 1886) — работа Ницше
  8. V. Работа по подготовке к действиям в чрезвычайных ситуациях
  9. VI. Работа сновидения
  10. VII. ТРЕБОВАНИЯ, ПРЕДЪЯВЛЯЕМЫЕ К НАУЧНО-ИССЛЕДОВАТЕЛЬСКИМ РАБОТАМ, ФОРМЫ ПООЩРЕНИЯ

Тема: «Методология объектно-ориентированного моделирования»

 

1. Цель работы:

 

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

2. Методические указания

 

Лабораторная работа направлена на ознакомление с основными элементами определения, представления, проектирования и моделирования программных систем с помощью языка UML, получение навыков по применению данных элементов для построения объектно-ориентированных моделей ИС на основании требований.

 

 

3. Общие сведения об объектном моделировании ИС

 

Существует множество технологий и инструментальных средств, с помощью которых можно реализовать в некотором смысле оптимальный проект ИС, начиная с этапа анализа и заканчивая созданием программного кода системы. В большинстве случаев эти технологии предъявляют весьма жесткие требования к процессу разработки и используемым ресурсам, а попытки трансформировать их под конкретные проекты оказываются безуспешными. Эти технологии представлены CASE-средствами верхнего уровня или CASE-средствами полного жизненного цикла (upper CASE tools или full life-cycle CASE tools). Они не позволяют оптимизировать деятельность на уровне отдельных элементов проекта, и, как следствие, многие разработчики перешли на так называемые CASE-средства нижнего уровня (lower CASE tools). Однако они столкнулись с новой проблемой — проблемой организации взаимодействия между различными командами, реализующими проект.

 

Унифицированный язык объектно-ориентированного моделирования Unified Modeling Language (UML) явился средством достижения компромисса между этими подходами. Существует достаточное количество инструментальных средств, поддерживающих с помощью UML жизненный цикл информационных систем, и, одновременно, UML является достаточно гибким для настройки и поддержки специфики деятельности различных команд разработчиков.

 

Создание UML началось в октябре 1994 г., когда Джим Рамбо и Гради Буч из Rational Software Corporation стали работать над объединением своих методов OMT и Booch. В настоящее время консорциум пользователей UML Partners включает в себя представителей таких грандов информационных технологий, как Rational Software, Microsoft, IBM, Hewlett-Packard, Oracle, DEC, Unisys, IntelliCorp, Platinum Technology.



 

UML представляет собой объектно-ориентированный язык моделирования, обладающий следующими основными характеристиками:

 

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

 

- содержит механизмы расширения и специализации базовых концепций языка.

 

UML — это стандартная нотация визуального моделирования программных систем, принятая консорциумом Object Managing Group (OMG) осенью 1997 г., и на сегодняшний день она поддерживается многими объектно-ориентированными CASE-продуктами.

 

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

 

- строить модели на основе средств ядра, без использования механизмов расширения для большинства типовых приложений;



 

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

 

Язык UML

Рис. 1. Интегрированная модель сложной системы в нотации языка UML

 

Стандарт UML предлагает следующий набор диаграмм для моделирования:

 

- диаграммы вариантов использования (use case diagrams) – для моделирования бизнес-процессов организации и требований к создаваемой системе);

 

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

 

- диаграммы поведения системы (behavior diagrams):

 

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

 

- диаграммы последовательности (sequence diagrams) и

 

- кооперативные диаграммы (collaboration diagrams) – для моделирования процесса обмена сообщениями между объектами;

 

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

 

- диаграммы деятельностей (activity diagrams) – для моделирования поведения системы в рамках различных вариантов использования, или моделирования деятельностей;

 

- диаграммы реализации (implementation diagrams):

 

- диаграммы компонентов (component diagrams) – для моделирования иерархии компонентов (подсистем) системы;

 

- диаграммы развертывания (deployment diagrams) – для моделирования физической архитектуры системы.

 

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

 

Понятие варианта использования (use case) впервые ввел Ивар Якобсон и придал ему такую значимость, что в настоящее время вариант использования превратился в основной элемент разработки и планирования проекта.

 

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

 

Рис.2. Вариант использования

 

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

 

 

Рис.3. Действующее лицо (актер)

 

Действующие лица делятся на три основных типа:

 

- пользователи;

 

- системы;

 

- другие системы, взаимодействующие с данной;

 

- время.

 

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

 

Связи между вариантами использования и действующими лицами

 

В языке UML на диаграммах вариантов использования поддерживается несколько типов связей между элементами диаграммы. Это связи коммуникации (communication), включения (include), расширения (extend) и обобщения (generalization).

 

Связь коммуникации – это связь между вариантом использования и действующим лицом. На языке UML связи коммуникации показывают с помощью однонаправленной ассоциации (сплошной линии).

 

Рис.4. Пример связи коммуникации

 

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

 

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

 

Рис.5. Пример связи включения и расширения

 

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

 

Рис.6. Пример связи обобщения

 

Диаграммы взаимодействия (interaction diagrams)

 

Диаграммы взаимодействия (interaction diagrams) описывают поведение взаимодействующих групп объектов. Как правило, диаграмма взаимодействия охватывает поведение объектов в рамках только одного варианта использования. На такой диаграмме отображается ряд объектов и те сообщения, которыми они обмениваются между собой.

 

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

 

Информационное (informative) сообщение – это сообщение, снабжающее объект-получатель некоторой информацией для обновления его состояния.

 

Сообщение-запрос (interrogative) – это сообщение, запрашивающее выдачу некоторой информации об объекте-получателе.

 

Императивное (imperative) сообщение – это сообщение, запрашивающее у объекта-получателя выполнение некоторых действий.

 

Существует два вида диаграмм взаимодействия: диаграммы последовательности (sequence diagrams) и кооперативные диаграммы (collaboration diagrams).

 

Диаграмма последовательности (sequence diagrams)

 

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

 

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

 

На диаграмме последовательности объект изображается в виде прямоугольника, от которого вниз проведена пунктирная вертикальная линия. Эта линия называется линией жизни (lifeline) объекта. Она представляет собой фрагмент жизненного цикла объекта в процессе взаимодействия.

 

Каждое сообщение представляется в виде стрелки между линиями жизни двух объектов. Сообщения появляются в том порядке, как они показаны на странице сверху вниз. Каждое сообщение помечается как минимум именем сообщения. При желании можно добавить также аргументы и некоторую управляющую информацию. Можно показать самоделегирование (self-delegation) – сообщение, которое объект посылает самому себе, при этом стрелка сообщения указывает на ту же самую линию жизни.

 

Рис. 7. Пример диаграммы последовательности

 

Диаграмма кооперации (collaboration diagram)

 

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

 

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

 

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

 

 

Рис. 8. Пример диаграммы кооперации

 


Дата добавления: 2015-09-14; просмотров: 27; Нарушение авторских прав


<== предыдущая лекция | следующая лекция ==>
 | Диаграммы классов. Диаграмма классов определяет типы классов системы и различного рода статические связи, которые существуют между ними
lektsii.com - Лекции.Ком - 2014-2019 год. (0.016 сек.) Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав
Главная страница Случайная страница Контакты