Файл: Моделирование предметной области «Учет товаров» с помощью UML.pdf

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

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

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

Унифицированный язык моделирования UML стал основой для целого спектра различных средств поддержки разработки программного обеспечения - CASE-средств (Computer-Aided Software Engineering).

Термин CASE сегодня понимается достаточно широко. Первоначальное значение термина, ограниченное вопросами автоматизации разработки программного обеспечения (ПО), в настоящее время приобрело новый смысл, и теперь это понятие охватывает процесс разработки сложных информационных систем в целом.

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

К появлению CASE-технологии способствовали и такие факторы, как:

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

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

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

Все современные CASE-средства можно классифицировать по типам и категориям. Классификация по типам отражает функциональную ориентацию CASE-средств на те или иные процессы жизненного цикла. Помимо этого CASE-средства можно классифицировать по категориям, применяемым методологиям и моделям систем и БД; степени интегрированности с СУБД; доступным платформам.

К основным достоинствам CASE-средств можно отнести:

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

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

Но все же грамотное, продуманное и обоснованное использование CASE-технологии способно принести следующие выгоды:

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

Rational Rose - CASE-средство фирмы Rational Software Corporation (США) - предназначено для автоматизации этапов анализа и проектирования ПО, а также для генерации кодов на различных языках и выпуска проектной документации.

IBM Rational Rose - популярное средство визуального моделирования, которое считается стандартом де-факто среди средств визуального проектирования приложений. Этот продукт входит в состав пакета IBM Rational Suite и предназначен для моделирования программных систем с использованием широкого круга инструментальных средств и платформ. Инструментальное средство IBM Rational Rose расширяет возможности моделирования программных систем, выходящих за рамки платформы J2EE и инструментальных средств моделирования в составе IBM Rational Professional Bundle.

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

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

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

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

2. Достоинства продукта Rational Rose

• мощный графический язык моделирования предметной области, обладающий высоким уровнем формализации и поддерживающий объектно-ориентированную методологию;
• удобная навигация между элементами модели при помощи "инспектора проекта";
• хранение результатов проектирования в виде единой модели;
• поддержка работы над проектом группы разработчиков;
• данное CASE средство может быть применено для создания разнообразного объектно-ориентированного программного обеспечения, в первую очередь для платформы Windows, а так же на языке Java;
• на всех этапах разработки применяется язык UML, и проект программного средства представляет собой единую модель;
• возможность конфигурирования системы с помощью модулей расширения;
• в наибольшей степени подходит для разработки крупных информационных систем, так как реализует большую часть функций ARIS и ERwin/BPwin. И т.д.

3. Недостатки продукта Rational Rose

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

В результате разработки проекта с помощью CASE-средства Rational Rose формируются следующие документы:

• диаграммы классов;
• диаграммы состояний;
• диаграммы сценариев;
• диаграммы модулей;
• диаграммы процессов;
• спецификации классов, объектов, атрибутов и операций
• заготовки текстов программ;

модель разрабатываемой программной системы.

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

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

Суть данной диаграммы состоит в следующем: проектируемая система представляется в виде множества так называемых вариантов использования, предоставляемых системой множеству актеров или сущностей, взаимодействующих с системой. При этом актером (actor) или действующим лицом называется любая сущность, взаимодействующая с системой извне. Это может быть человек, техническое устройство, программа или любая другая система, которая может служить источником воздействия на моделируемую систему так, как определит сам разработчик. В свою очередь, вариант использования (use case) служит для описания сервисов, которые система предоставляет актеру. Другими словами, каждый вариант использования определяет некоторый набор действий, совершаемый системой при диалоге с актером. Варианты использования определяют функциональные возможности. Каждый из них представляет определенный способ использования. Таким образом, каждый вариант использования соответствует последовательности действий для того, чтобы клиент мог получить определенный результат. На рисунке представленном ниже, изображена диаграмма вариантов использования для магазина видеопроката. Клиент - все люди, желающие воспользоваться услугами видеопроката; магазин видеопроката – предоставляет услуги по видеопрокату; поставщик – внешнее лицо, которое поставляет видеотеку магазину. Клиенты и поставщики являются внешними сущностями. Клиент обращается в магазин видеопроката, для предоставления ему услуг, таких как заказ, выдача или возврат фильма. Выбрав нужную услугу, клиент проходит процедуру идентификации, и если нужно регистрируется в базе данных клиентов. Основным вариантом использования служит “выдача фильма”. Для получения фильма, клиент смотрит в каталог фильмов и выбирает нужный ему фильм, поэтому “выдача фильма”, включает (include) “просмотр каталога фильмов”. После выбора фильма, клиенту необходимо пройти процедуру идентификации, администратор проверяет БД клиентов на наличие клиента в базе, следовательно, выдача включает “работу с базой данных клиентов”. Заказывая фильм, клиент также смотрит в каталог фильмов. Для этого вариант использования “заказ фильма” имеет расширение (extend). Таким образом свойства варианта использования “заказ фильма” дополняются благодаря наличию свойств у расширенного варианта использования “выдача фильма”. При возврате фильма, клиент проходит идентификацию у администратора, который проверяет клиента в БД клиентов, тем самым вариант использования “возврат фильма” включает работу с БД клиентов. После того, как клиент вернул фильм, ему необходимо оплатить просмотр, следовательно, вариант использования “возврат фильма” включает (include) вариант использования “оплата”.

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

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

Диаграмма классов (class diagram) служит для представления статической структуры модели системы в терминологии классов объектно-ориентированного программирования. Диаграмма классов может отражать, в частности, различные взаимосвязи между отдельными сущностями предметной области, такими как объекты и подсистемы, а также описывает их внутреннюю структуру и типы отношений. На данной диаграмме не указывается информация о временных аспектах функционирования системы. С этой точки зрения диаграмма классов является дальнейшим развитием концептуальной модели проектируемой системы. Когда говорят о данной диаграмме, имеют в виду статическую структурную модель проектируемой системы. Поэтому диаграмму классов принято считать графическим представленном таких структурных взаимосвязей логической модели системы, которые не зависят от времени. Диаграмма классов состоит из множества элементов, которые в совокупности отражают декларативные знания о предметной области. Эти знания интерпретируются в базовых понятиях языка UML, таких как классы, интерфейсы и отношения между ними и их составляющими компонентами.

Данная диаграмма показывает взаимосвязи между сущностями видеопроката, описывает внутреннюю структуру и типы отношений.

На рисунке 2 представлена диаграмма классов.

Администратор (Case worker) – является ключевой фигурой, так как взаимодействует с актерами в бизнес системе. Главным атрибутом класса является: ФИО. База данных клиентов (Business Entity) – содержит базу всех клиентов зарегистрированных в прокате, также имеет возможность расширения и изменения списка клиентов. Главным атрибутом класса является: идентификационный номер клиента.

Каталог фильмов (Business Entity) – перечень всех фильмов представленных в магазине видеопроката. Главным атрибутом класса является: наименование фильма. Заявка (Business Entity) – для заказа фильма, клиенту необходимо подать заявку, после чего администратор начинает процедуру заказа. Залог (Business Entity) – документ или иной ценный предмет, который взимается у клиента на определенное время для предоставления клиенту фильма в прокат.

Рисунок 2 - Диаграмма классов