Содержание:

ВВЕДЕНИЕ

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

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

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

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

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

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

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

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

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

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

CASE (англ. computer-aided software engineering) ‑ набор инструментов и методов программной инженерии для проектирования программного обеспечения, который помогает обеспечить высокое качество программ, отсутствие ошибок и простоту в обслуживании программных продуктов.

Методологии проектирования и первые CASE-системы появились достаточно давно. Этим вопросам посвящено множество печатных изданий и статей. Исторически первым появилось структурное и структурно-функциональное моделирование. Классическими трудами по структурному анализу и моделированию являются: работа Д. Марко [6] – рассматривает базовые принципы моделирования, Вендеров [6] рассматривает применение CASE – средств при структурном моделировании, С. В. Маклаков [16] рассматривает структурный подход на примере моделирования бизнес процессов предприятий и построения КИС.

Объектный подход появился позже, основы методологии описаны в трудах основоположников подхода Буча, Рамбо, Якобсона [23], из зарубежных авторов стоит упомянуть Д. Арлоу и А. Нейштадт [24], которые рассматривают уже непосредственно UML, как средство объектного моделирования.

Среди отечественных авторов можно назвать Пальчунова [14] – рассматривает практическое применение CASE – средства IBM Rational Rose, подобные вопросы рассматривает и Трофимов [18]. Рожкова в своей статье [15] проводит сравнительный анализ CASE – средств, Мирошниченко и Вичугова [12, 4] рассматриваю применение моделирования на конкретных предметных задачах.

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

Предметом исследования являются особенности методологии объектного подхода и ее применение на примере конкретной информационной системы.

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

В объеме курсовой работы ставятся следующие задачи:

1. Рассмотреть сущность проектирования ИС и содержание отдельных этапов, уделить особое внимание этапу проектирования ИС.
2. Рассмотреть основные подходы и особенности объектно-ориентированного моделирования систем.
3. Рассмотреть CASE-средства, поддерживающие язык моделирования UML
4. Практически реализовать модели на примере проектирования ИС «Автоматизация учета продаж цветочного магазина»

РАЗДЕЛ 1. ОБЪЕКТНО-ОРИЕНТИРОАНЫЙ ПОДХОД

1.1 Парадигма ООП

Основное правило ООП подхода – все объекты, которыми оперирует программа, являются классами.

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

ООП характеризуется следующими принципами[20]:

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

1.2 Основные понятия ООП

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

Класс (class) ‑ множество объектов, связанных общностью структуры и поведения; абстрактное описание данных и поведения (методов) для совокупности похожих объектов, представители которой называются экземплярами класса.

Объект (object) ‑ конкретная реализация класса, обладающая характеристиками состояния, поведения и индивидуальности, синоним экземпляра.

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

методы ‑ это функционал класса, его возможные действия;

поля или свойства – переменные, константы, данные.

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

Рисунок 1.1 – Архитектура программы при ООП

Первым ООП-языком программирования считается Smalltalk, разработанный сутрудниками Xerox PARC: Аланом Кейем, Дэном Ингаллсом, Тедом Кеглером в конце 1970-х годов. В результате разработчики языка получили объектно-ориентированный язык программирования с динамической типизацией и поддержкой базового набора требований ООП. Язык Smalltalk и сегодня активно развивается и имеет свой круг пользователей. Язык и история его развития оказали существенное влияние на парадигму ООП в целом и на развитие других языков с поддержкой ООП в частности. Многие современные идеи зародились именно в сообществе Smalltalk, были развиты и внедрены в программирование. Это касается понятий рефакторинга, шаблонов в проектировании. Сообществом впервые была предложена и концепция экстремального программирования, котрая достаточно хорошо зарекомендовале себя для определенного типа проектов.

Основные идеи языка легли в основы ООП парадигмы:

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

Model-View-Controller (MVC) ‑ шаблон структуры интерфейса. (В последнее время используют и другие концепции реализации пользовательского интерфейса - например, Morphic в Squeak и Pollock в VisualWorks).

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

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

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

1.3 Преимущества и недостатки объектного подхода

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

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

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

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

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

РАЗДЕЛ 2 ОБЪЕКТНО-ОРИЕНТИРОВАНОЕ МОДЕЛИРОВАНИЕ. UML

2.1 Объектно-ориентированное моделирование

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

Стандартная UML используется для создания моделей и проектирования системы. Это подход, предложенный многими исследователями, такими как Дуглас, [25], Гомма [26], Young [27], а также Мосеман и Вал в многочисленных электронных публикациях. Система представлена несколькими моделями. Каждая модель описывает систему с явно различной точки зрения.

Три вида просмотров определяются на высшем уровне [1, 4, 9, 23, 24]. Вид структурной классификации рассматривает вещи системы и их взаимосвязь между собой. Диаграммы классов используются для выражения статического вида системы, использование диаграммы вариантов использования для выражения режима просмотра использования, а также компонентов и диаграмм развертывания для выражения представления реализации.

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

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

Объектно-ориентированная парадигма, благодаря таким функциям, как абстракция, инкапсуляция данных поддерживает методики разработки различных видов сложных систем, таких как Real-Time, Embedded, Concurrent, Mobile и Distributed. В частности, функция абстракции поддерживает формальную основу для аргументации с системой с помощью статического или динамического анализа. Благодаря этим усилиям OMG (Object Management Group) в продвижении и совершенствовании UML, получили широкомасштабное принятие и одобрение. Недавняя спецификация UML2.0 с четко определенным семантическим фундаментом, основанной на семантике мелкозернистых действий, является результатом постоянных усилий сообщества UML, включая формальных методов исследователей к семантическому уточнения UML.

2.2 Язык моделирования UML

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

Авторами языка является Грейди Буч (Grady Booch), Джеймс Рамбо (James Rumbaugh) и Айвар Якобсон (Ivar Jacobson). В январе 1997 года в результате объединения разработок этих авторов выпущена версия UML 1.0, а в ноябре 1997 года – версию UML 1.1. следующие вершины сии: UML 1.3 - апрель 1999 года; UML 1.4 - октябрь 2001 года.

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

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

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

Язык UML предоставляет следующие основные возможности:

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

Среди главных свойств UML можно выделить следующие:

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

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

– это объектно-ориентированный язык, который наиболее эффективно можно применять именно в контексте объектно ориентированных методов анализа и проектирования.

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

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

– это стандартный язык, который гарантирует свободное понимание и распространение UML-моделей между различными разработчиками.

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

UML – это независимый язык, который не накладывает ограничений на языки программирования для реализации моделей и может быть совместимой с любым объектно-ориентированным языком.

2.3 Основные диаграммы объектной модели

Язык UML имеет четыре вида сущностей: структурные, поведенческие, группирующие и аннотационные сущности. Они показаны на втором уровне структурного дерева языка UML, представленного на рис. 2.1

Рисунок 2.1 – Иерархическая структура языка UML

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

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

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

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

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

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

2.4 Обзор case-средств, поддерживающих UML

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

ArgoUML – инструмент ориентированный на использование с java,тут можно видеть, какие плагины доступны для eclipse, импортировать сгенерированый код. Создавать программные заглушки и др.

Рисунок 2.2 ‑ ArgoUML

Рисунок 2.3 ‑ DIA

DIA ‑ это отличный бесплатный инструмент с открытым исходным кодом UML с простым пользовательским интерфейсомСреда предоставляет возможности:

быстро нарисовать диаграммы UML,

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

экспорт диаграмм в eps, pdf, jpg, svg и буфер обмена,

совместно использовать диаграммы с использованием Eclipse,

создавать новые, пользовательские элементы UML.

DIA может генерировать код в Java, PHP, C ++ и многие другие, достаточно установить Dia2code для генерации кода. Может использоваться для создания UML, а затем генерации кода классов.

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

Рисунок 2.4 ‑ Cacoo

Папирус ‑ набор, разработанный комиссариатом Énergie Atomique во Франции, который сегодня доступен как плагин для Eclipse. Это самый продвинутый инструмент моделирования с открытым исходным кодом и поддержкой UML2. Папирус нацелен на создание интегрированной и удобной для пользователя среды для редактирования любой модели EMF и, в частности, поддержки UML и связанных языков моделирования, таких как SysML и MARTE. Папирус предоставляет диаграммные редакторы для языков моделирования на основе EMF среди них UML 2 и SysML. Papyrus поддерживает Model-Driven Development (MDD), являясь довольно способным инструментом для разработки доменных языков. В связи с этим Papyrus, по-видимому, является единственным инструментом с открытым исходным кодом, поддерживающим шаблон моделированной модели (MDA), выпущенный OMG.

Рисунок 2.5 ‑ Papyrus

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

РАЗДЕЛ 3. РАЗРАБОТКА ПРОЕКТА ИНФОРМАЦИОННОЙ СИСТЕМЫ С ПОМОЩЬЮ ОБЪЕКТНО- ОРИЕНТИРОВАННОГО ПОДХОДА (UML-ДИАГРАММЫ)

Лучший способ продемонстрировать объектный подход в моделировании программных систем – это применить данный подход к конкретной прикладной задаче и проиллюстрировать этапы моделирования отдельными диаграммами. В данном разделе рассмотрим элементы построения ООП модели на примере информационной системы автоматизации учета продаж цветочного магазина «Букет».

3.1 Постановка задачи

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

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

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

Цикл обработки товара средствами разработанной системы включает следующие этапы:

• Добавление поставщика

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

• Получение товара

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

• Продажа товара заказчику

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

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

Работа над моделью UML в среде IBM Rational Rose начинается с общего анализа проблемы и построения диаграммы вариантов использования, которая отражает функциональное назначение проектируемой программной системы. Обычно эта диаграмма не детализирует систему, а только описывает основной возможный функционал – показывая доступные способы действий в системе. Как некая степень детализации, возможен показ на диаграмме подсистем, которые задействуются в ходе обращения к основным функциям.

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

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

Построение нашей модели мы тоже начнем с диаграммы вариантов использования.

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

Рисунок 3.1 – Диаграмма вариантов использования

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

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

Таблица 3.1 ‑ Характеристики прецедентов системы

Название	Предусловия	Главный поток	Альтернативный поток (исключения)	Подпоток
Прецеденты Actor Оперетор АИС
Работа с АИС «Букет»	ПК должен находиться во включенном состоянии, Есть связь с сервером	Прецедент начинает выполняться, когда оператор входит в систему используя комбинацию логин/пароль	Если ПК оператора не исправен или нет соединения с сервером – прецедент не выполняется	Подключение к БД
Добавить данные	Существует новый товар/поставщик/заказ Выполнены условия предыдущего прецедента	При помощи интерфейса АИС оператор обращается к модулю работы с БД. Заполнив экранные формы информация добавляется в БД	Оператор ожидает появления новых данных, может проводить операции с существующими	Выполнение транзакций с БД
Построить ведомость	Условия первого прецедента+ введена корректная информация для ведомости	На экране отображаются ведомость выбранного типа за введенный период времени. Система дает возможность отправить ведомость на печать или сохранить во внешний файл	В случае некорректных данных система дает возможность изменить входные данные
Прецеденты Actor Клиент
Сделать заказ	У клиента есть желание и возможности купить товар. Магазин работает, система исправна. Товар желаемый клиентом существует на складе	Посредством требований озвученных Клиентом с использованием системы при участии Оператора формируется заказ	Вариант 1. Не удовлетворены предусловия прецедента: магазин работает, система исправна – Клиент выбирает другой магазин Вариант 2 Нет желаемого товара – изменение в составе заказа или Вариант 1	Получение накладной, получение чека, взимание оплаты, выдача сдачи
Прецеденты Actor Директор/Администратор
Получить отчет	Условия первого прецедента актера Оператор, необходимость в отчете для администрации, корректные данные	На экране отображаются отчет – выборка из БД(результат запроса) выбранного типа по введенным данным. Система дает возможность отправить отчет на печать или сохранить во внешний файл	В случае некорректных данных система дает возможность изменить входные данные. Отчет может быть пустым

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

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

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

Модель классов представлена на следующем рисунке (рис 3.2).

Класс «Накладная» описывает объект «Накладная», имеет атрибуты:

- Список товаров – перечень товаров заказа;

- Сумма к оплате – общая цена заказа (сумма цен товаров заказа);

- Тип ‑ «расходная» для клиента, «приходная» для поставщика;

- Номер – для фиксации операции в системе.

«Накладная» предназначена для документирования операций в ходе торговых отношений.

Класс «Товар» описывает объект «Товар», имеет атрибуты:

- Название товара;

- Цена за единицу (порцию);

- Срок годности;

Предназначение полей однозначно трактуется по их названиям.

Класс «Заказ» описывает объект «Заказ», имеет атрибуты:

- Список товаров – перечень товаров заказа;

- Сумма к оплате – общая цена заказа (сумма цен товаров заказа);

- Дата – определяет дату на которую нужно выполнить поставку заказа для клиента;

- Статус – определяет состояние заказа, может принимать значения:

«потенциальный» ‑ желание заказника приобрести товар;

«оформленный» ‑ заказ зарегистрирован в системе;

«отмененный» ‑ клиент отменил заказ;

«оплаченный» ‑ клиент оплатил заказ по накладной;

«выданный» ‑ товары выданы со склада и получены клиентом.

Рисунок 3.2 – Диаграмма классов модели

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

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

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

Рисунок 3.3 – Диаграмма состояний сущности «Заказ»

Как видно из диаграммы «Заказ» может находится в 5 состояниях:

‑ Потенциальный заказ

‑ Отмененный заказ

‑ Оформленный заказ

‑ Оплаченный заказ

‑ Выданный заказ(расходованный)

3.5 Диаграмма последовательности

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

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

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

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

В нашей модели построено две таких диаграмма: первая описывает глобальный процесс – «Оформление заказа», вторая ‑ детализирует внутренний процесс «Построение ведомости»

Рисунок 3.4 – Диаграмма последовательности «Оформление заказа»

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

Рисунок 3.5 – Построение кассовой ведомости

3.6 Диаграмма кооперации

Эта диаграмма в некотором смысле дублирует диаграмму последовательности выполнения. Но ее основной целью есть показать задействованные компоненты в ходе выполнения той или иной операции в системе. Для иллюстрации этого момента выполним диаграмму «оформления заказа», но уже в виде кооперационной диаграммы(collaboration)

Рисунок 3.6 – Диаграмма кооперации «Оформление заказа»

3.7 Диаграмма деятельностей

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

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

Рисунок 3.7‑ Диаграмма деятельности

Наличие на диаграмме «дорожек» позволяет сразу понять – какая часть системы отвечает за выполнение действия. Диаграмма может иметь множество альтернативных окончаний. В нашем случае их два: «отмененный заказ», «полученный заказ».

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

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

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

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

Рисунок 3.8 – Компонентная диаграмма системы

Как видим «Отчеты», «Работа с БД», «Ведомости» отображены в виде закладок (Package) этим можно подчеркнуть что эти компоненты имеют набор различных функций. Кроме модулей основных функций на диаграмме присутствуют внешние компоненты и наборы данных (без которых система тоже работать не будет): это сама БД, драйвер для обслуживания принтера, драйвер(технология) для доступа к БД. Последним компонентом есть пользовательский интерфейс, в нашей разработке планируется как оконный (WinForms) интерфейс, но может быть и другим, например – Web ориентированная система.

3.9 Диаграмма размещения

Рисунок 3.9 – Диаграмма размещения

Диаграмма размещения отражает физические взаимосвязи между программными и аппаратными компонентами системы. Она показывает размещение объектов и компонентов в распределенной системе.

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

В случае разрабатываемой системы эта диаграмма имеет наиболее простой вид. На диаграмме показаны основные компоненты системы с аппаратной точки зрения. Имеем сервер с размещенной БД, это не обязательно какой то отличный от других ПК, просто на нем установлена БД что не исключает ситуации – на том же ПК установлен и клиент для доступа к БД. Кроме сервера показаны 3 клиента (количество не критично). Клиенты должны иметь принтер ‑ печать накладных и чеков и средство удаленного соединения с БД (в этом случае должна использоваться сетевая технология).

ЗАКЛЮЧЕНИЕ

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

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

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

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

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

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

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

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

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

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

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

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

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

1. Бабич А.В. UML: Первое знакомство :БИНОМ. Лаборатория знаний, Интернет-университет информационных технологий - ИНТУИТ.ру, 2008
2. Вендров А.М., CASE-технологии. Современные методы и средства проектирования информационных систем - М.: Финансы и статистика, 2007 г, 456 стр.
3. Вигерс Карл, Разработка требований к программному обеспечению, Пер, с англ. - М.: Издательско-торговый дом "Русская Редакция", 2008. -576с.: ил
4. Вичугова А. А., Вичугов В. Н., Цапко Г. П. МЕТОДЫ И СРЕДСТВА UML КАК ИНСТРУМЕНТЫ ПРОЕКТИРОВАНИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ // Вестник науки Сибири / Выпуск № 2 (8) / 2013 ВАК РФ: 05.13.00 ‑ 2013
5. Гвоздева Т. В., Б. А. Баллод, Проектирование информационных систем, М, Издательство: Феникс, 2009 г., 512 стр.
6. Д. Марка, К. МакГоуэн Методология структурного анализа и проектирования SADT (Structured Analysis & Design Technique), М.: ‑ "Мета Технология", 1993
7. Емельянова Н. З., Партыка Т. Л., И. И. Попов, Проектирование информационных систем, М, Издательство: Форум, 2009 г., 432 стр.
8. Игошина Л.В. Программирование на языке высокого уровня. - Пенза: ПГУ, 2014. - с.5
9. Кознов Д.В. Основы визуального моделирования :БИНОМ. Лаборатория знаний, Интернет-университет информационных технологий - ИНТУИТ.ру, 2012
10. Котляров В. П., Т. В. Коликова, Основы тестирования программного обеспечения, Издательства: Интернет-университет информационных технологий, Бином. Лаборатория знаний, 2009 г., 288 стр.
11. С. В. Маклаков “ERwin и BPwin. CASE-средства разработки информационных систем” Москва «Диалг-МИФИ» 2001.
12. Мирошниченко Е.А. Технологии программирования. 2-е изд., испр. и доп. – Томск: Изд-во ТПУ, 2014. – 128 с.
13. Онлайн руководство по разработке программ с использованием VisualStudio, Электронный ресурс [режим доступа: https://msdn.microsoft.com], время доступа 24.09.2019
14. Пальчунов М.Н, CASE-технологии. Практические работы в среде Rational Rose – М.:; Бином-Пресс, 2014
15. Рожкова Е. CASE-средства. Сравнительный анализ // ARIS – Rational Rose. URL: http://ocnova.ru/?p=334 10.12.2012
16. Сафьянова Е.Н. Основы алгоритмизации и программирование: Учебное пособие. - Томск: Томский межвузовский центр дистанционного образования, 2012. - 111 с.
17. Создание функциональных, событийных моделей и моделей потоков данных в среде моделирования BPWin 4.0 Методическое пособие, Рязань ГОУ ВПО «МГУ ЭКОНОМИКИ, СТАТИСТИКИ И ИНФОРМАТИКИ (РЯЗАНСКИЙ ФИЛИАЛ)» 2007.
18. Трофимов С.А. CASE-технологии. Modelling in Rational Rose, ‑ М.:БИНОМ. Лаборатория знаний 2012
19. Унифицированный процесс разработки программного обеспечения - А. Якобсон, Г. Буч, Дж. Рамбо; Исд: Питер, 2002г
20. Хайдаров К.А. Объектно-ориентированное программирование, [элетронный ресурс], режим доступа: http://bourabai.kz/alg/oop.htm, дата доступа ­- 05.10.2019
21. Язык UML 2 и Унифицированный процесс. Практический объектно-ориентированный анализ и проектирование, 2-ое издание - Джим Арлоу, Айла Нейштадт; Исд: Символ-Плюс, 2007
22. Язык UML. Проектирование систем реального времени, распределенных и параллельных приложений, 4-е издание - Хассан Гома; Исд: ДМК Пресс, 2012
23. Язык UML. Руководство пользователя, 2-е издание-ради Буч, Джеймс Рамбо, Ивар Якобсон; Исд: ДМК Пресс, 2007
24. Язык UML 2 и унифицированный процесс. Практический объектно-ориентированный анализ и проектирование, 2-ое издание - Джим Арлоу, Айла Нейштадт; Исд: Символ-Плюс, 2007
25. B. Douglas “Doing Hard Time: Developing Real_time Systems with UML, Objects, Frameworks, and Patterns”, Addison Wesley 1999.
26. H. Gomma, Designing Concurrent, Distribute, and Real-Time Appli- cations with UML, Addison Wesley 2000.
27. K., Young, R. Piggin, P . Rachitrangsan, “An Object-Oriented Ap- proach to an Agile Manufacturing Control System Design”, Int. Journal of Advanced Manufacturing Technology, Vol. 17, Springer- verlag 2001.

ПРИЛОЖЕНИЯ

Приложение 1. Программные продукты (средства моделирования) с поддержкой языка UML

Бесплатные программы

Acceleo: (http://www.acceleo.org/pages/home/en) - основанная на Eclipse и EMF шаблонная система для генерации исходного кода из UML моделей.

ArgoUML: (http://argouml.tigris.org/ написано на языке Java)

Astade: (http://astade.tigris.org/) - платформо-независимое UML-средство на основе wxWidgets.

ATLAS Transformation Language: (http://www.eclipse.org/m2m/atl/) - QVT-инструмент, который способен трансформировать UML модели в другие модели. Доступно из Eclipse GMT project (Generative Modeling Tools).

BOUML: (http://bouml.free.fr/) - мультиплатформенное UML 2.0 средство, генерирует код C++/Java/IDL/PHP/Python. Очень высокая производительность (написано на C++, на Qt). Лицензия GNU GPL.

Dia: (http://live.gnome.org/Dia) GTK+/GNOME средство для построения диаграмм, которое также поддерживает UML (Лицензия GNU GPL)

Gaphor: (http://gaphor.sourceforge.net/) - GTK+/GNOME среда моделирования UML 2.0, написанная на Python

Kivio: (http://www.koffice.org/kivio/) - часть проекта KOffice

NetBeans: (http://www.netbeans.org) - с NetBeans IDE 5.5 Enterprise Pack

Umbrello UML Modeller: программа для составления диаграмм UML для KDE

Software Ideas Modeler: (http://softwareideas.net/) средство моделирования UML, написанное на C#

StarUML:(http://staruml.sourceforge.net/en/) UML/MDA платформа для Microsoft Windows с открытым исходным кодом, выпущенная по модифицированной версии GNU GPL; написана в основном на Delphi

Rhapsody Modeler: (http://www.ilogix.com/sublevel.aspx?id=1756 Rhapsody Modeler) бесплатная версия Rhapsody для создания UML моделей для встраиваемых систем реального времени

UML Pad: (http://web.tiscali.it/ggbhome/umlpad/umlpad.htm) - средство моделирования UML, написанное на C++/wxWidgets

Распространенные коммерческие системы

ARIS: (http://www.ids-scheer.com/en/ARIS/ARIS_Software/3730.html)

Borland Together: (http://www.borland.com/together/index.html)

Enterprise Architect: (http://www.sparxsystems.com.au)

Gentleware Poseidon: (http://www.gentleware.com/products.html) - удобное средство моделирования, есть русифицированная версия

IBM Rational Rose: (http://ibm.com/software/awdtools/developer/rose/)

MagicDraw: (http://magicdraw.com/) - есть русифицированная версия

Microsoft Visio: — редактор диаграмм для Windows

ModelMaker Tools: (http://www.modelmakertools.com/)

ObjectDomain: (http://objectdomain.com/welcome.do)

Sybase PowerDesigner: (http://www.sybase.ru/products/powerdesigner) — полнофункциональный инструментарий для создания бизнес-приложений.

SmartDraw: (http://www.smartdraw.com/)

Telelogic Rhapsody: — среда разработки на основе визуального моделирования для разработчиков встраиваемых систем реального времени

UML Studio: (http://www.pragsoft.com/products.html)

Visual Paradigm for UML: (http://visual-paradigm.com/)