Преподаватель который помогает студентам и школьникам в учёбе.

ПРИМЕНЕНИЕ ОБЪЕКТНО-ОРИЕНТИРОВАННОГО ПОДХОДА ПРИ ПРОЕКТИРОВАНИИ ИНФОРМАЦИОННОЙ СИСТЕМЫ (CASE системы)

Содержание:

ВВЕДЕНИЕ

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

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

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

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

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

Программные пакеты CASE-технологий (Computer Aided System Engineering) - применяются для проектирования любых объектов и систем, диаграмм UML (Unified Modeling Language). Как необходимый элемент системного и структурно-функционального анализа, CASE – средства позволяют моделировать компоненты программного обеспечения, базы данных, деятельности и структуре организаций, их бизнес-процессов.

Применяются практически во всех сферах деятельности.

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

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

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

Задачи курсовой:

1. Проанализировать общие понятия и методики проектирования информационной системы

2. Проанализировать общие понятия объектно-ориентированного проектирования

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

4. Выполнить проектирование нескольких информационных систем в наиболее перспективных CASE системах проектирования.

ГЛАВА 1. АНАЛИЗ ОБЪЕКТНО-ОРИЕНТИРОВАННГО ПРОЕКТИРОВАНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ

1.1. Общие понятия проектирования информационных систем

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

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

Каждая система может быть описана с разных точек зрения, для чего используются различные модели, каждая из которых является семантически замкнутым абстракцией системы. модель может быть структурной, что подчеркивает организацию системы, или моделью поведения, отражает ее динамику. [2,3,5]

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

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

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

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

Различные точки зрения приводят к созданию различных систем. Мировоззрение разработчика ПО зависит от выбранной модели. Разработчики баз данных (БД) основное внимание уделят UML-моделям «сущность - связь», где поведение инкапсулированная в процедурах сохранения и хранилищах. Аналитик структурного подхода создал бы модель, в центре которой являются алгоритмы и передача данных от одного процесса к другому и тому подобное. Результатом работы разработчика объектно-ориентированной парадигмы проектирования будет система, архитектура которой основана на множестве классов и образцах взаимодействия, определяющие, кооперации этих классов в реализации определенных сценариев. Каждый из этих вариантов может оказаться пригодным для конкретного применения и методики разработки, хотя опыт подсказывает, что объектно-ориентированный точка зрения эффективной при создании гибких архитектур, даже для больших БД или сложных математических расчетов. Различные точки зрения приводят к созданию различных систем со своими преимуществами и недостатками[6].

Принцип 2. Каждая модель может быть представлена с разной степенью точности. Лучшей моделью является та, что позволяет выбрать необходимый уровень детализации ПО. Иногда простая и наскоро созданная модель программного интерфейса является приемлемым вариантом. В других случаях приходится работать на уровне битов (спецификация межсистемных интерфейсов и т.д.). В каждом случае лучшей моделью будет та, которая позволяет выбрать уровень детализации в зависимости от того, кто и с какой целью на нее смотрит. Для аналитика или пользователя наибольший интерес представляет вопрос «что делать», а для разработчика - «как сделать». В обоих случаях необходима возможность рассматривать систему на различных уровнях детализации в разное время. [2,7]

Принцип 3. Лучшие модели те, которые ближе к реальности. При объектно-ориентированном подходе создания ПО можно объединить все почти независимым видом системы в единое семантическое целое. «Ахиллесова пята» структурного анализа - несоответствие принятой в нем модели и модели системного проекта. Если этот разрыв не будет устранен, то поведение созданной системы со временем будет все больше и больше отличаться от задуманного. [1,2,3]

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

Модели создаются и исследуются отдельно, хотя взаимосвязаны. Здесь ключевым моментом является определение «почти независимые» типы архитектурного понимания ПО.

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

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

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

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

SADT. Методология функционального моделирования работ, которая основана на структурном анализе и графическом представлении организации как системы функций. Тут выделяется функциональная, информационная и динамическая модели. В настоящее время методология известна как нотация (стандарт) IDEF0. Анализируемый процесс графически представляется в виде четырёхугольника, где сверху изображаются регламентирующие и управляющие воздействия, снизу – объекты управления, слева – входные данные, а справа – выходные.
RAD. Методология быстрой разработки приложений. В RAD быстрая разработка приложений возможна за счёт применения компонентно-ориентированного конструирования. Методология применяется на проектах с ограниченным бюджетом, нечёткими требованиями к ИС, при сжатых сроках реализации. К ней прибегают, если пользовательский интерфейс можно продемонстрировать в прототипе, а проект разделить на функциональные элементы.
RUP. В методологии RUP реализуются итерационный и наращиваемый (инкрементный) подходы. Построение системы происходит на базе архитектуры информационной системы, а планирование и проектное управление – на базе функциональных требований к ИС. Разработка общей информационной системы происходит итерациями, как комплекс отдельных небольших проектов со своими планами и задачами. Для итерационного цикла характерна периодическая обратная связь и адаптация к ядру ИС.

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

1.2. Объектно-ориентированное проектирование ИС

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

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

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

Объектная модель имеет четыре главных свойства:

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

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

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

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

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

Важнейшими свойствами классов считаются: инкапсуляция, наследование и полиформизм.

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

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

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

Атрибуты и методы классов

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

1.3. CASEсистемы объектно-ориентированного проектирования

1.3.1. Rational Rose

IBM Rational Rose – мощное средство анализа, моделирования, визуализации и разработки программных продуктов

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

IBM Rational Rose применяется при решении практически любых задач проектирования информационных систем: от анализа бизнес-процессов в кодогенерации на определенном языке программирования.

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

Rational Rose имеет открытый рабочий интерфейс Application Programming Interface (API) с соответствующими операциями главного меню позволяет пользователям-проектировщикам создавать модули для других языков программирования, с визуализацией, изменением окна браузера проекта, иерархичности его структуры со специальной панелью инструментов, окнами проектирующих диаграмм, характеристик документации и журнала разрабатываемого проекта.

IBM Rational Rose –объектно-ориентрованное CASE средство проектирования информационных систем. Компания Rational Software Corp. (Гради Буч и Джеймс Рамбо ) стала инициатором унификации языка визуального моделирования в рамках консорциума OMG и первой разработала CASE систему, в которой язык UML был определен как базовая нотация визуального моделирования.

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

Функциональные возможности IBM Rational Rose:

проектирование систем любой сложности - от интерфейса программы или схемы базы данных схеме системы автоматизации предприятия;
поддержка языка UML в нотации Unified (унифицированной);
возможности автоматического контроля, в том числе проверки соответствия двух моделей;
предоставление развернутой информации о проекте (совместно со средствами документирования, в частности SoDA)
генерирование кода (стандартный список модулей включает C ++, ADA, CORBA, Visual Basic, XML, COM, Oracle);
обратное проектирование имеющихся систем.

Другие важные характеристики:

удобный графический интерфейс, открытый для дополнений. В частности, открытость архитектуры позволяет включить поддержку языков программирования, не предусмотренных стандартной поставкой, например языка Assembler, для чего достаточно написать дополнительный модуль;
многоплатформенность; '
интеграция с Microsoft Visual Studio с использованием библиотеки активных шаблонов ATL (Microsoft Active Template Library), Webкласив, DHTML и протоколов доступа к различным базам данных;
возможность интеграции с другими инструментальными средствами, поддерживающими жизненный цикл программных систем, в частности со средствами управления требованиями (IBM Rational RequisitePro), тестирования (SQA Suite, Performance Studio), конфигурационного управления (IBM Rational ClearCase, PVCS)
поддержка технологий MTS (Microsoft Transaction Server) и ADO (ActiveX Data Objects) на уровне шаблонов и исходного кода, а также элементов технологии Microsoft COM + (DCOM)
полная поддержка компонентов CORBA и J2EE, включая реализацией технологии компонентной разработки приложений CBD (Component Based Development), языка определения интерфейса IDL (Interface Definition Language) и языка определения данных DDL (Data Definition Language)
полная поддержка среды разработки Java приложений, включая кодогенерирование и обратный инжиниринг классов Java формата JAR, а также работу с файлами формата CAB и ZIP.

Пользователями IBM Rational Rose могут выступать проектировщики (а с ними и заказчики, будущие пользователи), аналитики, разработчики ИС. Ориентация на разработчика (программиста) отличает IBM Rational Rose среди других средств проектирования.

Преимуществами использования IBM Rational Rose является:

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

В IBM Rational Rose работа с моделью системы происходит с помощью четырех представлений:

Use Case View - описание проекта с точки зрения его использования. Может содержать варианты использования, действующих лиц, связи коммуникации между вариантами использования и действующими лицами, связи использования и расширения между вариантами использования, связи обобщения действующих лиц, диаграммы вариантов использования, в некоторых случаях - диаграммы последовательности и кооперативные диаграммы;
Logical View - описание логики реализации поведения, описанного в вариантах использования. Может содержать классы, их свойства и методы, отношение между классами, диаграммы классов, диаграммы взаимодействия, диаграммы состояний, пакеты, являются группами взаимосвязанных классов;
Component View - описание компонентов проекта, модули и зависимости между ними, переходы от главной программы к подпрограммам. Может содержать компоненты, диаграммы компонентов, пакеты, являются группами связанных компонентов;
Deployment View - расположение физических устройств и связей между ними. Может содержать процессы, процессоры, устройства, диаграммы размещения.

Рисунок 1.1. – Интерфейс Rational Rose

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

Большую часть работы по IBM Rational Rose можно подать путем создания и модификации диаграмм.

Практически IBM Rational Rose можетрассматриваться как среда моделирования, поддерживает генерацию программногокода моделей, написанных на языках ANSICORBA, Java / J2EE, C ++, C #, VisualC ++иVisualBasic.

Программа IBMRationalRose, вообще является стандартом в отрасли UML проектирования, с дополнениями классов на диаграммы классов с редактированием их особенностей, стереотипов классов сущностей с их графическим представлением.

Программный пакет IBM Программный пакет IBM Rational Rose применяется для повышения квалификации персонала, получение навыков в области автоматизации проектирования и реализации программных проектов использованием CASE-средств IBM Rational Rose.

1.3.2. Borland Together

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

Технология Borland Live Source, интегрированная в Control Center, автоматически синхронизирует все артефакты, так что изменения в них не прерывают процесс разработки.

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

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

Основные возможности Borland Together в визуальном проектировании:

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

1.3.3. Sparx Systems Enterprise Architect

Sparx Systems Enterprise Architect (SSEA) - это программа для реализации UMLмоделирования и проектирование нового поколения.

SSEA существует в вариантах для Windows и Linux и является средством для UML моделирования с возможностью многопользовательской работы и дружественным интерфейсом(Рис. 2).

Рисунок 2. Интерфейс SSEA

Возможности SSEA достаточно многочисленны:

поддержка Java, C ++, C #, VB,VB.Net, Delphi, PHP, NET;
моделирование баз данных (БД), прямоепроектирования в DDL и обратное проектирование с ODBC;
моделирование за счет возможностей управления поведением диаграмм, параллельной генерации новых элементов исвязей;
файлы UML-профили (например,SPEM) позволяют создавать узкоспециализированные модели;
поддержка паттернов проектирования;
генерация документов в форматахHTML, RTF;
многопользовательская работа, утилиты для менеджера проекта, тестирование,глоссарий, другие ресурсы;
автоматизация интерфейса, поддержка макросов.

1.3.4. StarUML

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

StarUML - это бесплатный пакет с открытым программным кодом, написанный на Delphi и работает под управлением ОС семейства Windows. Относится к средствам моделирования, используют парадигму объектно-ориентированного анализа и проектирования и базируется на языке моделирования UML. StarUML поддерживает UML и их профайлы и MDA. Функционал пакета расширяется за счет использования полигонов, позволяет пользователям проектировщикам создать собственный модуль для StarUML на любом COM совместимом языке (C ++, C #, Delphi).

Имеет бесплатную свободно распространяемую версию (рис.3).

Рисунок 3. – Интерфейс CASE средства

Основными категориями пользователей являются:

Agile и небольшие команды разработчиков
Профессиональные разработчики,
Проектировщики ПО,
Учебные заведения.

Ключевые особенности StarUML:

Мультиплатформенная поддержка (MacOS, Windows и Linux)
Соответствует стандарту UML 2.x
Диаграмма сущности-отношения (ERD)
Диаграмма потока данных (DFD)
Блок-схема
Несколько окон
Современный UX
Темные и светлые темы
Retina (High-DPI) поддержка дисплея
Модельно-ориентированная разработка
Открытые API
Различные сторонние расширения
Проверка асинхронной модели
Экспорт в HTML документы
Автоматические обновления.
Открытый формат программной модели

В отличие от многих существующих программ, которые используют собственные не эффективные форматы файла модели, StarUML ™ оперирует файлами в стандартном форматеXML. Коды, написанные в легких для чтения структурах и форматах, могут быть легко изменены с помощью синтаксического анализатора XML. Учитывая факт, что XML является мировым стандартом, это, конечно, большое преимущество, которое гарантирует, что программные модели

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

StarUML ™ действительно поддерживает профили UML. Это максимизирует расширяемость UML, делая моделирование на UML применимым даже в области финансов, обороны, электронной коммерции, страховании и аэронавтике. На самом деле можно создавать платформенно-независимые модели (PIM), а платформенно зависимые модели (PSM) и исполняемые коды могут быть всегда автоматически сгенерированы на их основе.

Применимость методологий и платформ

StarUML ™ использует концептуальный подход, который применим к любым методологиям/процессам. Легко создаются не только модели под средства разработки дляконкретных платформ типа .NET или J2EE, но также и для других основных структур программных моделей (например модель представления 4+1, и т.д.).

Превосходная расширяемость

Все функции StarUML ™ реализованы в соответствии с Microsoft COM. Любой язык, который поддерживает COM (Visual Basic Script, Java Script, VB, Delphi, C++, C#, VB.NET, Python, и т.д.),может использоваться, чтобы вызывать StarUML ™ или разрабатывать интегрированные дополнения (аддины).

Программная функция проверки модели

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

Полезные дополнения

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

1.3.5. Sybase PowerDesigner

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

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

Особенностями последних версий PowerDesigner является поддержка анализа и проектирования систем с использованием стандарта UML (диаграммы бизнес-процессов, последовательности выполнения, классов и компонентов). На основе диаграммы классов PowerDesigner автоматически осуществляет генерацию и реинжиниринг кода для Java, C +, PowerBuilder, Visual Basic, C #, Visual Basic. NET и ряда других языков программирования и средств разработки. PowerDesigner 9.0 автоматизирует создание кода компонента на выбранном языке программирования, а также генерацию описания WSDL, необходимого для разработки Web-сервисов.

В зависимости от требований к проектированию и разработке можно выбрать только такие модули PowerDesigner 9.0, которые нужны конкретной компании. Доступные версии продукта, состоящие из различных наборов модулей, включают: PhysicalArchitect - для физического проектирования и генерации баз данных (OLTP и OLAP), DataArchitect - для концептуального и физического проектирования данных, ObjectArchitect - для объектно-ориентированного анализа и проектирования, а также концептуального и физического проектирования данных, Developer - для объектно-ориентированного моделирования и физического проектирования баз данных, Studio - для моделирования бизнес-процессов, для расширенного UML-моделирования и моделирования данных, Viewer - для просмотра всех типов моделе без возможности редактирования, Enterprise - для ведения централизованного архива для моделей и других файлов и групповой работы с моделями.

1.3.6. Редакторы, которые не являются CASEсредствами

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

Данный пакет из семейства Microsoft Office, хотя и предназначен исключительно для рисования диаграмм, иллюстрирования документов MS Office (рис. 4), но имеет некоторые дополнительные возможности:

- диаграммы ER-моделей БД;

- документирование и анализ бизнес процессов;

- отслеживание комментариев членов команды;

- поддержка Tablet PC;

- инструменты для "мозгового штурма";

- создание календарей;

- удобное создание и использование технических диаграмм;

- более быстрое создание и редактирование диаграмм;

- поддержка множество локальных языков;

- отличная интеграция с другими приложениями MS Office;

- статические диаграммы UML.

SmartDraw - это программная альтернатива MS Visio (рис. 5). Как и MS Visio, эта программа предназначена исключительно для рисования объектов без функций поддержки командной разработки программного обеспечения.

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

Основные возможности SmartDraw – это проектирование:

блок-схем и временных диаграмм;
организационных диаграмм;
UML-диаграмм;
сетевых диаграмм;
форм и поэтажных планов.

Dia - кроссплатформенное средство для создание диаграмм, основанный на технологии gtk + и распространяется как часть GNOME Office, так и как независимо.

Используется для разработки многих видов диаграмм:

- ER-диаграмм (проектирование баз данных);

- статических структур UML;

- блок-схем алгоритмов программ;

- сетевых диаграмм и простых схем электрических цепей;

- поддержка диаграмм потоков.

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

Dia может работать под управлением Linux в среде Gnome, с поддержкой библиотек gtk + и glib. Dia поддерживаетмножество региональных стандартов, как в том числе и русский с украинским.

Umbrello UML Modeller. Пакет Umbrello UML Modeller успешно работает в операционных системахUnix и Linux. Его интерфейс очень прост.

Этот редактор поддерживает все стандартные типы UML-диаграмм. Им поддерживается импорт из C +

К недостаткам следует отнести ориентированность пакета только на операционную систему Windows, а также отсутствие поддержки .NET Framework 2.0 и 3.0.

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

Umbrello UML Modeller не стоит использовать в случае разработкисложных прикладных программ.

1.4. Проектирование объектно-ориентированных баз данных

Для моделирования использовалась CASE система Sybase PowerDesigner 16.2

Процесс проектирования баз данных - анализ того, какого рода информация должна в ней представлена и каковы взаимосвязи между элементами информации. Структура или схема (schema) определяется средствами языков или систем обозначений пригодных для описания проектов. По завершению уточнений и согласований проект преобразовывается в форму, которая может быть воспринята СУБД – инструкции языка DDL.

В настоящее время существует несколько подходов. Самый распространенный и традиционный подход – модель «сущность-связь» (entity-relationship). Графическая модель. Модель "сущность-связь" была предложена в 1976 г. Питером Пин-Шэн Ченом

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

ODL (Object Definition Language – язык определения объектов) - стандарт средств описания объектно-ориентированных БД. Сочетаясь с реляционной моделью образуют объектно-реляционную модель (object-relational model).

Основные положения объектного языка описания объектов данных ODMG:

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

Язык описания объектов (ODL - Object Defifnition Language) - средство определения схемы базы данных (по аналогии с DDL в реляционных СУБД). ODL является расширением IDL (Interface Definition Language - язык описания интерфейсов) модели OMG и предоставляет средства для определения объектных типов, их атрибутов, связей и методов. ODL создает слой абстрактных описаний так, что схема базы данных становится независима как от языка программирования, так и от СУБД. ODL рассматривает только описание объектных типов данных, не вдаваясь в детали реализации их методов. Это позволяет переносить схему БД между различными ODMG-совместимыми СУБД и языками программирования, а также транслировать ее в другие DDL.

Язык объектных запросов (OQL - Object Query Language) - SQL - подобный декларативный язык, который предоставляет эффективные средства для извлечения объектов из базы данных, включая высокоуровневые примитивы для наборов объектов и объектных структур. Синтаксис опретора SELECT, определенный SQL-92, является подмножеством OQL, это гарантирует, что SELECT-утверждения, выполняемые над реляционными таблицами, сохранят работоспособность и с наборами объектов ODMG. OQL-запросы могут вызываться из ОО-языка, точно также из OQL-запросов могут делаться обращения к процедурам, написанным на OO-языке. OQL предоставляет средства обеспечения целостности объектов (вызов объектных методов и использование собственных операторов изменения данных).

Связывание с ОО-языками. Стандарт связывания с C++, Smalltalk и Java определяет Object Manipulation Language (OML) - язык манипулирования объектами, который расширяет базовые ОО-языки средствами манипулирования и хранения объектов. Также включаются OQL, средства навигации и поддержка транзакций. Каждый ОО-язык имеет свой собственный OML, поэтому разработчик остается в одной языковой среде, ему нет необходимости разделять средства программмирования и доступа к данным. Харакетристики объекта определяется описанием строки таблицы.

На основе нового типа могут быть определены таблицы, например:

Create table Addresses of Address;

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

Сreate table People of new type Person (

name char (30),

address Address,

birthdate date,

);

Наследование определяется с помощью фразы under.

Create type Employee under Person (

empno char(10),

dept ref(Department)

);

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

Рисунок 1.4. Модель ODL Базы данных магазина

ГЛАВА 2. ПРАКТИЧЕСКИЕ ПРИМЕРЫ ПРОЕКТИРОВАНИЯ ИС В РАЗЛИЧНЫХ РЕДАКТОРАХ

2.1. Проектирование ИС управления теплицей в RationalRose

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

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

При помощи диаграммы Use Case (вариантов использования) определим объекты системы и действия, которые эти объекты должны производить.

Разрабатываем UseCase диаграмму по указанному алгоритму

Рисунок 2.1. Разработанная диаграмма в редакторе

Устройства тепличного хозяйства

Рисунок 2.2.DeploymentDiagram

2. СозданиеStatechartдиаграммы

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

Рисунок 2.3. Диаграмма состояний

Рисунок 2.4. Настройка среды

Рисунок 2.5. Настройка состояний

Рисунок 2.6. Statechart Diagram в развернутом виде

Рисунок 2.7. Statechart Diagram в свернутом виде

Создание Activity Diagram

Строим диаграмму активности по указанному алгоритму

Рисунок 2.8. Диаграмма активности

Рисунок 2.9. Создание вложенной диаграммы по алгоритму

Создаем диаграмму Sequence Diagramпо предлагаемому сценарию

Рисунок 2.10. Sequence Diagram: Use case View / Progress

Строим диаграмму сотрудничества Collaborationпо алгоритму

Рисунок 2.11. Collaboration Diagram: Use Case View / Progress

Рисунок 2.12. Настройка диаграммы

Строим диаграмму компонент по алгоритму

Рисунок 2.13. Диаграмма компонент

Рисунок 2.14. Спецификация связей в диаграмме компонент

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

Рисунок 2.15. ClassDiagram: Logical / Main

Рисунок 2.16. Установка спецификаций компонент

Рисунок 2.17. Установка спецификаций компонент

Определяем связи

Рисунок 2.18 Настройка операций

Рисунок 2.19. Связи

Рисунок 2.20. Спецификации связей

2.2. Проектирование ИС рекламного агентства в StarUML

Предметная область

Проектирование программного обеспечения учета телекомпанией стоимости прошедшей в эфире рекламы

Описание предметной области

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

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

Граничными классами будут AutorizationManager (Авторизация пользователя) – класс отвечает за авторизацию, аутентификацию менеджера в системе и переход его на страницу работы с системой, InputInformation (Ввод информации) – класс отвечает за ввод новой информации в систему, Change Information (Изменение информации) - класс отвечает за изменение и редактирование информации, которая расположена в базе данных системы, DeleteInformation (Удаление информации) – класс отвекчает за удаление информации из системы, ViewInformation (Просмотр информации) – класс содержит набор фильтров, которые позволяют просматривать различную информацию из базы данных.

Управляющими классами будут ActMeneger(Действия менеджера) – класс отвечает за выбор действий и сущностей на которые он будет направлен,

Сущностными классами будут Reclam (Класс, содержащий и работающий с данными, о располагаемой рекламе), Firm (Класс, содержащий и работающий с данными, о фирме заказчике), DateTime (Класс, содержащий и работающий с данными, о времени и днях демонстрации рекламы, а также передачах и их рейтингах), Cash (Класс, содержащий и работающий с данными, по коэффициентам и размерам вычисления стоимости рекламы).

Рисунок. 2.21. UseCase рекламного агентства

Рисунок. 2.21. Диаграмма активности рекламного агантства

Manager–Менеджер, который работает с системой

System – Система

DataBase – База данных системы

InputManagerMenuPage Работу с системой начинает авторизованный менеджер, который заходит на свою страницу и видит меню с опциями:AddInformation (добавление информации), ChangeInformation (изменение информации), ViewInformation (просмотр информации), DeleteInformation (удаление информации)

Рисунок. 2.21. Диаграмма последовательности

Менеджер

Input Information aboutFirm – вводит информацию о фирме заказчике
Test fields – система проверяет правильность заполнения полей
Info Reclam – Менеджер вводит информацию о рекламе
Test Fields– система проверяет правильность заполнения полей
Desired Data/time – Вводит прогнозируемое время рекламы
Forminganinvoice – системаоплаты : PayManager проверяет данные и формирует счет
Invoicing payment – система оплаты выводит счет
Receipt of payment – переводит счет к оплате
Pay и производит оплату (через платежную систему
Reclam Order – Менеджер предоставляет договор о рекламном времени

Рисунок. 2.22. Уточненный вариант

Менеджер

Autorization – авторизуется
InputInformation – вводит информацию о заказе
Input Information aboutFirm – вводит информацию о фирме заказчике
Test fields – система проверяет правильность заполнения полей
Info Reclam – Менеджер вводит информацию о рекламе
Test Fields– система проверяет правильность заполнения полей
Desired Data/time – Вводит прогнозируемое время рекламы
Forminganinvoice – системаоплаты : PayManagerпроверяетданные и формирует счет
Invoicing payment – система оплаты выводит счет
Receipt of payment – переводит счет к оплате
Pay и производит оплату (через платежную систему
Reclam Order – Менеджер предоставляет договор о рекламном времени
ViewInformation – Менеджер просматривает информацию
ChangeInformation – Изменяет информацию
DeleteInformation- Удаляет информацию

Рисунок. 2.24.Диаграмма взаимодействия

Менеджер

Autorization – авторизуется
InputInformation – вводитинформациюозаказе
Input Information aboutFirm – вводитинформацию о фирме заказчике
Test fields – система проверяет правильность заполнения полей
Info Reclam – Менеджер вводит информацию о рекламе
Test Fields– система проверяет правильность заполнения полей
Desired Data/time – Вводит прогнозируемое время рекламы
Forminganinvoice – системаоплаты : PayManagerпроверяетданные и формирует счет
Invoicing payment – система оплаты выводит счет
Receipt of payment – переводит счет к оплате
Pay и производит оплату (через платежную систему
Reclam Order – Менеджер предоставляет договор о рекламном времени
ViewInformation – Менеджер просматривает информацию
ChangeInformation – Изменяет информацию
DeleteInformation- Удаляет информацию

На этапе разработки классов были определены следующие атрибуты классов

<<boundary>> InputInformation -Кодзаписи (idInput: String)

<<entity>> Reclam

idReclam: String – Код рекламы
nameFilm: String[1..*] – Название рекламного ролика
productName: String[1] – Фирма изготовитель
slogan: String[1..*] – Слоган, может быть несколько
duration: Integer = 20 – продолжительность в секундах (по умолчанию 20
description: String – описание содержания
author: String – автор

<<entity>> Firm

idFirm: String –код Фирмы
firmName: String - Название
adress: String – Юридический адрес
contactPerson: String[1..*] – Ответственная персона (не менее одной)
telephone: String[1..*] – контактный телефон ( не менее одного)
e-mail: String[1..*] - электронный адрес ( не менее одного)

<<entity>> DateTime

idZakaz: String – код заказа
data: String – дата заказа
Day: String[1..*] – какой день показа (может быть несколько)
time: Integer[1..*] – время показа (может быть несколько)
count: Integer = 1 – количество показав в передаче (по умолчанию 1)

<<entity>> Cash

idPayment: String – код платежа
sumPayment: Float – сумма платежа
dataPayment: String[1..*] – дата оплаты, платеж может продолжаться, тогда дат будет несколько

Рисунок. 2.25. Диаграмма классов

Опишем операции классов

<<control>> ActManager

Forming an invoice() – формирует счет на оплату
Invoicing payment() – передает счет к оплате
Receipt of payment() – фиксирует данные об оплате

<<boundary>> AuthorizationManager

Autorization()- авторизуетвсистеме

<<boundary>> InputInformation

InputInformationaboutFirm() – вводитинформациюофирме (платежные документы)
InfoInformation() – выводит формы для ввода информации
Test fields() – тестирует поля с информацией

<<entity>> Reclam

Info Reclam() – генерирует форму для ввда рекламной информации

<<entity>> Firm

InfoFirm() – генерирует форму для ввода информации о фирме
Test fields() – верифицирует фирму (постоянные клиенты)

<<entity>> DateTime

DesiredData/time() – генерирует форму для ввода даты и времени, анализирует их доступность

<<entity>> Cash

Info Cash() - генерирует платежный счет на основе даты и времени

Рисунок. 2.26. Определение атрибутов и методов

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

Проанализировав диаграмму последовательности выясняем, что класс <boundary>> AuthorizationManager связан с <<control>> ActManager, а объект ActManager посылает сообщения объекту классам <<boundary>> InputInformation, <<boundary>> ChangeInformation, <<boundary>> DeleteInformation,<<boundary>> ViewInformation. Каждый из этих классов Связан имеет направленную связь с объектами классов Reclam, Firm, DateTime. Класс ViewInformation имеет направленную связь с Cash.

Рисунок. 2.27. Диаграмма классов со связями

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

Менеджер вводит данные о рекламе. Класс Реклама (Reclam) имеет ряд характеристик (Свойств) и один метод InfoReclam имеет статус в работе или закрыт.

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

Данные о Рекламе (InfoReclam) поступают менеджеру, который проверяет оплату рекламы и вводит данные в систему для предоставления рекламного времени.

Поскольку реклама должна быть предоплачена, то входным действием будет действие Оплатить рекламу (topayReclam).

Обработка заказа (Reclam processing) подразумевает проверку оплаты заказа и наличия времени для рекламы - деятельность Проверить оплату и наличие (Check availability and payment reclam)

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

Действия оператора переводят рекламу (Reclam) в одно из следующих состояний:

Рекламное время согласовывается – Alignment Time for Reclam;

Рекламноевремяустановлено – Time for Reclam is completed;

Таким образом, выходным действием для перечисленных состояний является действие Согласование (Aligment ReclamStatus).

После согласования рекламного времени наступает переход состояния заказа рекламы (Reclam) из состояния Поиск рекламного времени (Find Reclam Time) в состояние рекламное время установлено (ReclamTime).

Менеджер помечает заказ рекламы, меткой Реклама в работе (Reclam in work), и отмечает в системе, что рекламное время для рекламы установлено.

Далее данные о заказе можно передать в архив.

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

Условие [Рекламное время не согласовано в течение 2 недель (Reclam time not aligment within 2 weeks)] вызывает переход в состояние нет рекламного времени (noReclamTime) при этом выполняется действие Вернуть деньги на карту (Return the money to the сustomer 's card).

Рисунок. 2.27. Диаграмма состояний

Обоснование построенных связей между компонентами.

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

Интерфейс Control позволяет установить связь с базой данных,

InputItem – случит для создание новых объектов

ChangeItem- для реализации функций по изменению,

DeleteItem – для реализации функций по удалению

View – для просмотра.

Стереотипы соответствуют описанным функциям.

Avtorization

Операции:Avtorization – авторизация менеджера в системе

Menegment

Операции: Formated in invoce – сформировать счет

Invoising payment – выдать к оплате

Receipt on payment – внести данные об оплате

Input

InputInformationaboutFirm – ввести данные о фирме

InputInformation – ввести информацию о рекламе

TestField – проверитьполя

Change

ChangeInformation – изменитьинформацию

Delete

DeleteInformation – удалитьинформацию

View

ViewInformation – просмотреть информацию

Item

Test Fields – проверить поля

InfoReclam – данные по рекламе

Desired Data/time проверить дату и время, установить

TestField – проверить возможность

Info Cash – дать данные по оплате

Рисунок. 2.28. Диаграмма компонентов

ЗАКЛЮЧЕНИЕ

На данный момент присутствует огромное количество полноценных CASEсредств UML моделирования и программ для рисованиядиаграмм, в том числе UML. Такие продукты, какBorlandTogether, Dia, StarUML могут быть загружены с сайта производителя бесплатно. StarUML выглядит наиболее функциональным из бесплатных продуктов и можетслужить полноценной заменой коммерческим программам для UML-моделирования.

Для использования в качестве справочника идеально подходит Sparx Systems Enterprise Architect. Для построения статических диаграммUML, ER-моделей БД и их документирования с анализом бизнес-процессов можно применять программное средство MicrosoftVisio.

Наиболее полнофункциональной системой является IBMRationalRose, но неменее интересными являются решения от Sparx Systems Enterprise Architectили SybasePowerDesigner

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

Пакет StarUML является кроссплатформенным бесплатным средством UML моделирования, для работы которого требуется установка Java 2 JRE или JDK версии 1.4 или выше. CASE-средство содержит поддержку спецификаций UML 1.3, 1.4 и XMI 1.0,1.1, 1.2. В нем можно строить 9 основных видов диаграмм UML (классов,состояний, кооперации, последовательности, деятельности, прецедентов, объектов,компонентов, развертывания). С помощью пакета генерируется исходный кодJava, C ++, C #, SQL и PHP, а также можно осуществить обратное проектирование сисходного кода и байт-кода Java в одну или более диаграмм. Данная версия пакетаподдерживает автоматическую верификацию модели UML (design critics).

Среди недостатков StarUML следует выделить отсутствие возможностиинтеграции с другими продуктами, кроме IBMRationalRose, многопользовательского режима работы игенерации отчетов. В последнем случае недостатка, то следует заметить, что пакет предоставляетвозможность сохранять диаграммы в форматах .png, .gif, .ps, .eps или .svg. Последняяверсия данного средства создана еще в 2011.

StarUML 5.0 относится к средствам моделирования, используtтпарадигму объектно-ориентированного анализа и проектирования и базируется наязыке моделирования UML 2.0. В пакете можно построить основные видыдиаграмм, сгенерировать исходный код C #, Java, Delphi, Python, VB.NET и C ++.

Средство предусматривает поддержку паттернов, расширение функционала и работу с.NET Framework 1.0. Документацию в средстве можно экспортировать в один изформатов DOC, PPT, TXT, XLS. Этот CASE-средство также конвертирует выходныетексты в модели, импортирует файлы Rational Rose, осуществляет обмен модельнойинформацией с другими программными средствами, с использованием XMI.

Таким образом, лучшимпакетом свободно распространяется, является StarUML. Если же рассматривается приобретение платной версии, то IBM RationalRose.

СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ

Бондаренко М.Ф. Моделирование и проектирование бизнес-систем: методы, стандарты, технологии / М.Ф. Бондаренко, С.И. Маторин, Е.А. Соловьева. − Харьков: Компания СМИТ, 2004. − 272 с.
Боровик В. Н. Программные компоненты проектирования диаграмм UML. / В. М. Боровик, А. И. Труш. // Проблемы информатизации и управления. - 2010. - № 3 (31). - С. 14-19.
Боровик В.М., Гамаюн В.П. Автоматизоване робоче місце проектування інформаційних систем і баз даних: навч. посіб. – К.: Вид-во Нац. авіац. ун-ту «НАУ-друк», 2010. –128 с.
Генсен П. Учебник по Umbrello UML Modeller. [Электронный ресурс]. – Режим доступа: http://docs.kde.org/development/uk/ kdesdk / umbrello / index.html
Каюмова А.В. Визуальное моделирование систем в StarUML: Учебное пособие / А.В. Каюмова. - Казань: Казанский федеральный университет, 2013. - 104 с.
Ильясова Ф. С. Объектно-ориентированный подход как архитектурное решение проектирование систем с использованием IBM Rational Software Arhitect & MS Visual Studio 2010 Rose / Ф. С. Ильясова, Ф. В. Шкарбан // Ученые записки КИПУ.
Маклаков С.В. Создание информационных систем с ALLFusion Modelling Suite. − М.: ДИАЛОГ-МИФИ, 2005. − 432 с.
Р. Дж. Мюллер. Базы данных и UML проектирование. – М.: Изд-во Лори, 2002. – 420 с. 5. Томашевський В.М. Моделювання систем. – К.: Видавнича група BHV, 2007. – 352 с.
Педагогические науки. Вып. 18.- Симфепополь: НИЦ КИПУ, 2011. - С. 94-97.
Трофимов С.А. CASE-технологии: практическая работа в Rational Rose. – М.: Бином-Пресс, 2002. – 288 с.
Федотова Д.Э., Семенов Ю.Д., Чижик К.Н. CASE-технологии: Практикум – М.: Горячая линия – Телеком, 2003. – 160 с.
Образовательно-профессиональная программа подготовки. Бакалавр. Направление подготовки 040302Информатика. Квалификация 3121 специалист по информационным технологиям. - М., 2010. -94 с.
Рекомендации по преподаванию программной инженерии и информатики вуниверситетах = SoftwareEngineering 2004: CurriculumGuidelinesforUndergraduateDegreeProgramsinSoftwareEngineering; ComputingCurricula 2001: ComputerScience:пер. с англ. - М .: ИНТУИТ.РУ «Интернет-Университет ИнформационныхТехнологий », 2007. - 462 с.

Приложения.

/***********************************************************************

* Module: AllTovar.cs

* Author: Admin

* Purpose: Definition of the Class AllTovar

***********************************************************************/

using System;

public class AllTovar

{

public int listAllTovar()

{

// TODO: implement

return 0;

}

public int findTovar()

{

// TODO: implement

return 0;

}

private int numbTovar;

}

/***********************************************************************

* Module: Tovar.cs

* Author: Admin

* Purpose: Definition of the Class Tovar

***********************************************************************/

using System;

public class Tovar

{

public object printCatalogEntry()

{

// TODO: implement

return null;

}

public object listAccessories()

{

// TODO: implement

return null;

}

public System.Collections.ArrayList allTovar;

/// <pdGenerated>default getter</pdGenerated>

public System.Collections.ArrayList GetAllTovar()

{

if (allTovar == null)

allTovar = new System.Collections.ArrayList();

return allTovar;

}

/// <pdGenerated>default setter</pdGenerated>

public void SetAllTovar(System.Collections.ArrayList newAllTovar)

{

RemoveAllAllTovar();

foreach (AllTovar oAllTovar in newAllTovar)

AddAllTovar(oAllTovar);

}

/// <pdGenerated>default Add</pdGenerated>

public void AddAllTovar(AllTovar newAllTovar)

{

if (newAllTovar == null)

return;

if (this.allTovar == null)

this.allTovar = new System.Collections.ArrayList();

if (!this.allTovar.Contains(newAllTovar))

this.allTovar.Add(newAllTovar);

}

/// <pdGenerated>default Remove</pdGenerated>

public void RemoveAllTovar(AllTovar oldAllTovar)

{

if (oldAllTovar == null)

return;

if (this.allTovar != null)

if (this.allTovar.Contains(oldAllTovar))

this.allTovar.Remove(oldAllTovar);

}

/// <pdGenerated>default removeAll</pdGenerated>

public void RemoveAllAllTovar()

{

if (allTovar != null)

allTovar.Clear();

}

private int tovarCod;

private int tovarArticle;

private object tovarFoto;

private String tovarDescription;

private float tovarCena;

private DateTime tovarYearOfIssue;

}

/***********************************************************************

* Module: Computers.cs

* Author: Admin

* Purpose: Definition of the Class Computers

***********************************************************************/

using System;

public class Computers : Tovar

{

private String cpuType;

private int cpuFrequency;

private String memoryType;

private int memorySize;

private String hddType;

private int hddSpeed;

private String mbType;

private int mbFrequency;

}

/***********************************************************************

* Module: Person.cs

* Author: Admin

* Purpose: Definition of the Class Person

***********************************************************************/

using System;

public class Person

{

public int findTovar()

{

// TODO: implement

return 0;

}

public System.Collections.ArrayList tovar;

/// <pdGenerated>default getter</pdGenerated>

public System.Collections.ArrayList GetTovar()

{

if (tovar == null)

tovar = new System.Collections.ArrayList();

return tovar;

}

/// <pdGenerated>default setter</pdGenerated>

public void SetTovar(System.Collections.ArrayList newTovar)

{

RemoveAllTovar();

foreach (Tovar oTovar in newTovar)

AddTovar(oTovar);

}

/// <pdGenerated>default Add</pdGenerated>

public void AddTovar(Tovar newTovar)

{

if (newTovar == null)

return;

if (this.tovar == null)

this.tovar = new System.Collections.ArrayList();

if (!this.tovar.Contains(newTovar))

this.tovar.Add(newTovar);

}

/// <pdGenerated>default Remove</pdGenerated>

public void RemoveTovar(Tovar oldTovar)

{

if (oldTovar == null)

return;

if (this.tovar != null)

if (this.tovar.Contains(oldTovar))

this.tovar.Remove(oldTovar);

}

/// <pdGenerated>default removeAll</pdGenerated>

public void RemoveAllTovar()

{

if (tovar != null)

tovar.Clear();

}

private int personID;

private String personSurname;

private int personName;

private int personEmail;

}

/***********************************************************************

* Module: Client.cs

* Author: Admin

* Purpose: Definition of the Class Client

***********************************************************************/

using System;

public class Client

{

public int findTovar()

{

// TODO: implement

return 0;

}

public int bayTovar()

{

// TODO: implement

return 0;

}

public int pay()

{

// TODO: implement

return 0;

}

public System.Collections.ArrayList person;

/// <pdGenerated>default getter</pdGenerated>

public System.Collections.ArrayList GetPerson()

{

if (person == null)

person = new System.Collections.ArrayList();

return person;

}

/// <pdGenerated>default setter</pdGenerated>

public void SetPerson(System.Collections.ArrayList newPerson)

{

RemoveAllPerson();

foreach (Person oPerson in newPerson)

AddPerson(oPerson);

}

/// <pdGenerated>default Add</pdGenerated>

public void AddPerson(Person newPerson)

{

if (newPerson == null)

return;

if (this.person == null)

this.person = new System.Collections.ArrayList();

if (!this.person.Contains(newPerson))

this.person.Add(newPerson);

}

/// <pdGenerated>default Remove</pdGenerated>

public void RemovePerson(Person oldPerson)

{

if (oldPerson == null)

return;

if (this.person != null)

if (this.person.Contains(oldPerson))

this.person.Remove(oldPerson);

}

/// <pdGenerated>default removeAll</pdGenerated>

public void RemoveAllPerson()

{

if (person != null)

person.Clear();

}

private int clientID;

private String adressClient;

private float payClient;

private int typeDostavka;

}

/***********************************************************************

* Module: Manager.cs

* Author: Admin

* Purpose: Definition of the Class Manager

***********************************************************************/

using System;

public class Manager

{

public object inputTovar()

{

// TODO: implement

return null;

}

public object changeTovar()

{

// TODO: implement

return null;

}

public void deleteTovar()

{

// TODO: implement

}

public System.Collections.ArrayList person;

/// <pdGenerated>default getter</pdGenerated>

public System.Collections.ArrayList GetPerson()

{

if (person == null)

person = new System.Collections.ArrayList();

return person;

}

/// <pdGenerated>default setter</pdGenerated>

public void SetPerson(System.Collections.ArrayList newPerson)

{

RemoveAllPerson();

foreach (Person oPerson in newPerson)

AddPerson(oPerson);

}

/// <pdGenerated>default Add</pdGenerated>

public void AddPerson(Person newPerson)

{

if (newPerson == null)

return;

if (this.person == null)

this.person = new System.Collections.ArrayList();

if (!this.person.Contains(newPerson))

this.person.Add(newPerson);

}

/// <pdGenerated>default Remove</pdGenerated>

public void RemovePerson(Person oldPerson)

{

if (oldPerson == null)

return;

if (this.person != null)

if (this.person.Contains(oldPerson))

this.person.Remove(oldPerson);

}

/// <pdGenerated>default removeAll</pdGenerated>

public void RemoveAllPerson()

{

if (person != null)

person.Clear();

}

private int managerID;

private String managerTelephone;

}