КОНТРОЛЬНАЯ РАБОТА по дисциплине

 «ТЕОРИЯ  СИСТЕМ И СИСТЕМНЫЙ АНАЛИЗ»

На тему «Унифицированный язык моделирования UML» 
 

Выполнил:

№ зач. книжки   

Проверил:

. 
 
 
 
 

Тюмень – 2010

Оглавление

Введение 3

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

2. Основные понятия  объектно-ориентированного  подхода - объект  и класс 6

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

4. Виды диаграмм 16

4.1 Диаграмма классов 16

4.2 Диаграмма взаимодействия 19

5. Определение целей,  функций, входов  и выходов модельной  системы 23

6. Пример использования  объектно-ориентированного  подхода 29

Выводы 33

Список  использованных источников 36

Введение

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

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

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

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

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

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

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

    • типизация (typing),

    • параллелизм (concurrency),

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

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

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

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

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

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

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

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

    Устойчивость - свойство объекта существовать во времени (вне зависимости от процесса, породившего данный объект) и/или  в пространстве (при перемещении  объекта из адресного пространства, в котором он был создан).

2. Основные  понятия объектно-ориентированного  подхода - объект  и класс

    Объект  определяется как осязаемая реальность (tangible entity) - предмет или явление, имеющие четко определяемое поведение. Объект обладает состоянием, поведением и индивидуальностью; структура  и поведение схожих объектов определяют общий для них класс. Термины "экземпляр  класса" и "объект'' являются эквивалентными. Состояние объекта характеризуется  перечнем всех возможных (статических) свойств данного объекта и  текущими значениями (динамическими) каждого  из этих свойств. Поведение характеризует  воздействие объекта на другие объекты  и наоборот относительно изменения  состояния этих объектов и передачи сообщений. Иначе говоря, поведение  объекта полностью определяется его действиями. Индивидуальность - это свойства объекта, отличающие его  от всех других объектов.

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

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

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

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

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

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

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

    Отдельные языки объектно-ориентированного моделирования  стали появляться в период между  серединой 1970-х и концом 1980-х годов, когда различные исследователи  и программисты предлагали свои подходы  к объектно-ориентированному анализу и проектированию (ООАП). В период между 1989-1994 гг. общее число наиболее известных языков моделирования возросло с 10 до более чем 50. Многие пользователи испытывали серьезные затруднения при выборе языка ООАП, поскольку ни один из них не удовлетворял всем требованиям, предъявляемым к построению моделей сложных систем. Принятие отдельных методик и графических нотаций в качестве стандартов (IDEF0, IDEF1X) не смогло изменить сложившуюся ситуацию непримиримой конкуренции между ними в начале 90-х годов, которая тоже получила название "войны методов".

    К середине 1990-х некоторые из методов  были существенно улучшены и приобрели  самостоятельное значение при решении  различных задач ООАП. Наиболее известными в этот период становятся:

• Метод Гради Буча (Grady Booch), получивший условное название Booch или Booch'91, Booch Lite (позже - Booch'93).
• Метод Джеймса Румбаха (James Rumbaugh), получивший название Object Modeling Technique - ОМТ (позже - ОМТ-2).
• Метод Айвара Джекобсона (Ivar Jacobson), получивший название Object-Oriented Software Engineering - OOSE.

    Каждый  из этих методов был ориентирован на поддержку отдельных этапов ООАП. Например, метод OOSE содержал средства представления вариантов использования, которые имеют существенное значение на этапе анализа требований в  процессе проектирования бизнес-приложений. Метод ОМТ-2 наиболее подходил для  анализа процессов обработки  данных в информационных системах. Метод Booch'93 нашел наибольшее применение на этапах проектирования и разработки различных программных систем.

    История развития языка UML берет начало с  октября 1994 года, когда Гради Буч  и Джеймс Румбах из Rational Software Corporation начали работу по унификации методов Booch и ОМТ. Хотя сами по себе эти методы были достаточно популярны, совместная работа была направлена на изучение всех известных объектно-ориентированных  методов с целью объединения  их достоинств. При этом Г. Буч и  Дж. Румбах сосредоточили усилия на полной унификации результатов своей  работы. Проект так называемого унифицированного метода (Unified Method) версии 0.8 был подготовлен  и опубликован в октябре 1995 года. Осенью того же года к ним присоединился  А. Джекоб-сон, главный технолог из компании Objectory AB (Швеция), с целью интеграции своего метода OOSE с двумя предыдущими.

    Вначале авторы методов Booch, ОМТ и OOSE предполагали разработать унифицированный язык моделирования только для этих трех методик. С одной стороны, каждый из этих методов был проверен на практике и показал свою конструктивность при решении отдельных задач  ООАП. Это давало основание для  дальнейшей их модификации на основе устранения имеющегося несоответствия отдельных понятий и обозначений. С другой стороны, унификация семантики  и нотации должна была обеспечить некоторую стабильность на рынке  объектно-ориентированных CASE-средств, которая необходима для успешного  продвижения соответствующих программных  ин-струментариев. Наконец, совместная работа давала надежду на существенное улучшение всех трех методов.

    Начиная работу по унификации своих методов, Г. Буч, Дж. Румбах и А. Дже-кобсон сформулировали следующие требования к языку  моделирования. Он должен:

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

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

1. Должна ли данная нотация включать в себя спецификацию требований?
2. Следует ли расширять данную нотацию до уровня языка визуального программирования?

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

    В этот период поддержка разработки языка UML становится одной из целей консорциума OMG (Object Management Group). Хотя консорциум OMG был  образован еще в 1989 году с целью  разработки предложений по стандартизации объектных и компонентных технологий CORBA, язык UML приобрел статус второго  стратегического направления в  работе OMG. Именно в рамках OMG создается команда разработчиков под руководством Ричарда Соли, которая будет обеспечивать дальнейшую работу по унификации и стандартизации языка UML. В июне 1995 года OMG организовала совещание всех крупных специалистов и представителей входящих в консорциум компаний по методологиям ООАП, на котором впервые в международном масштабе была признана целесообразность поиска индустриальных стандартов в области языков моделирования под эгидой OMG.

    Усилия  Г. Буча, Дж. Румбаха и А. Джекобсона привели к появлению первых документов, содержащих описание собственно языка UML версии 0.9 (июнь 1996 г.) и версии 0.91 (октябрь 1996 г.). Имевшие статус запроса предложений RTP (Request For Proposals), эти документы послужили  своеобразным катализатором для  широкого обсуждения языка UML различными категориями специалистов. Первые отзывы и реакция на язык UML указывали  на необходимость его дополнения отдельными понятиями и конструкциями.

    В это же время стало ясно, что  некоторые компании и организации  видят в языке UML линию стратегических интересов для своего бизнеса. Компания Rational Software вместе с несколькими организациями, изъявившими желание выделить ресурсы  для разработки строгого определения  версии 1.0 языка UML, учредила консорциум партнеров UML, в который первоначально  вошли такие компании, как Digital Equipment Corp., HP, i-Logix, Intellicorp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle, Rational Software, TI и Unisys. Эти компании обеспечили поддержку последующей  работы по более точному и строгому определению нотации, что привело  к появлению версии 1.0 языка UML. В  январе 1997 года был опубликован документ с описанием языка UML 1.0, как начальный  вариант ответа на запрос предложений RTP. Эта версия языка моделирования  была достаточно хорошо определена, обеспечивала требуемую выразительность и  мощность и предполагала решение  широкого класса задач.

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

    Из  более чем 800 компаний и организаций, входящих в настоящее время в  состав консорциума OMG, особую роль продолжает играть Rational Software Corporation, которая стояла у истоков разработки языка UML. Эта  компания разработала и выпустила  в продажу одно из первых инструментальных CASE-средств Rational Rose 98, в котором был  реализован язык UML.

    В январе 1997 года целый ряд других компаний, среди которых были IBM, ObjecTime, Platinum Technology и некоторые другие, представили на рассмотрение OMG свои собственные ответы на запрос предложений RFP. В дальнейшем эти компании присоединились к партнерам UML, предлагая включить в язык UML некоторые свои идеи. В  результате совместной работы с партнерами UML была предложена пересмотренная версия 1.1 языка UML. Основное внимание при разработке языка UML 1.1 было уделено достижению большей ясности семантики языка  по сравнению с UML 1.0, а также учету  предложений новых партнеров. Эта  версия языка была представлена на рассмотрение OMG и была одобрена и  принята в качестве стандарта OMG в ноябре 1997. года.

    В настоящее время все вопросы  дальнейшей разработки языка UML сконцентрированы в рамках консорциума OMG. Соответствующая  группа специалистов обеспечивает публикацию материалов, содержащих описание последующих  версий языка UML и запросов предложений RFP по его стандартизации. Очередной  этап развития данного языка закончился в марте 1999 года, когда консорциумом OMG было опубликовано описание языка UML 1.3 (alpha R5). Последней версией языка UML на момент написания книги является UML 1.3, которая описана в соответствующем  документе - "OMG Unified Modeling Language Specification", опубликованном в июне 1999 года. История разработки и последующего развития языка UML графически представлена на рис:

    Рис.1 История развития языка UML 

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

    Язык UML ориентирован для применения в  качестве языка моделирования различными пользователями и научными сообществами для решения широкого класса задач  ООАП. Многие специалисты по методологии, организации и поставщики инструментальных средств обязались использовать язык в своих разработках. При  этом термин "унифицированный" в  названии UML не является случайным и имеет два аспекта. С одной стороны, он фактически устраняет многие из несущественных различий между известными ранее языками моделирования и методиками построения диаграмм. С другой стороны, создает предпосылки для унификации различных моделей и этапов их разработки для широкого класса систем, не только программного обеспечения, но и бизнес-процессов. Семантика языка UML определена таким образом, что она не является препятствием для последующих усовершенствований при появлении новых концепций моделирования.

    В этой связи следует отметить внимание гиганта компьютерной индустрии  компании Microsoft к технологии UML. Еще  в октябре 1996 г. Microsoft и Rational Software Coiporation объявили о своем стратегическом партнерстве, которое, по их общему мнению, способно оказать решающее влияние  на рынок средств объектно-ориентированной  разработки программ. При этом Microsoft лицензировала у Rational Software некоторые  технологии визуального моделирования, в результате чего был разработан Microsoft Visual Modeler for Visual Basic. В свою очередь Rational Software лицензировала у Microsoft Visual Basic и Microsoft Repositoiy, разрабатываемые вместе с Texas Instruments. При создании языка UML Microsoft внесла свой вклад в интеграцию UML со своими стандартами типа ActiveX и  СОМ и в использование языка UML со своей технологией Microsoft Repository.

    На  основе технологии UML Microsoft, Rational Software и  другие поставщики средств разработки программных систем разработали  единую информационную модель, которая  получила название UML Information Model. Предполагается, что эта модель даст возможность  различным программам, поддерживающим идеологию UML, обмениваться между собой  компонентами и описаниями. Все это  позволит создать стандартный интерфейс  между средствами разработки приложений и средствами визуального моделирования.

    Уже в настоящее время разработаны  средства визуального программирования на основе UML, обеспечивающие интеграцию, включая прямую и обратную генерацию  кода программ, с наиболее распространенными  языками и средами программирования, такими как MS Visual C++, Java, Object Pascal/Delphi, Power Builder, MS Visual Basic, Forte, Ada, Smalltalk. Поскольку при разработке языка UML были приняты во внимание многие передовые идеи и методы, можно ожидать, что на очередные версии языка UML также окажут влияние и другие перспективные технологии и концепции. Кроме того, на основе языка UML могут быть определены многие новые перспективные методы. Язык UML может быть расширен без переопределения его ядра.

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

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

    4.1 Диаграмма классов

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

    • ассоциации (например, клиент может  сделать заказ);

    • подтипы (частный клиент является разновидностью клиента). 

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

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

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

    Построение  диаграмм классов можно рассматривать  в различных аспектах:

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

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

    аспект  реализации - модель действительно  определяет реализацию классов ПО. Этот аспект наиболее важен для программистов.

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

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

    Точка зрения на диаграммы классов, не будучи собственно формальной частью UML, однако при построении и анализе моделей является крайне важной. Конструкции UML можно использовать с любой из трех точек зрения. Большинство опытных разработчиков-программистов предпочитают аспект реализации. С другой стороны, очевидно, что построение диаграмм классов на стадии формирования требований к ПО должно выполняться с концептуальной точки зрения.