Р.А. Файзрахманов, А.В. Архипов

УДК 681.3.06

Ф17

Рецензенты:

д-р техн. наук, профессор Г.Г Куликов

(Уфимский государственный авиационный технический университет)

заслуженный деятель науки РФ, д-р экон. наук, профессор Н.И. Артемов

(Пермский государственный технический университет)

Файзрахманов, Р.А.

Ф17 Проектирование автоматизированных информационных сис­ тем на основе объектно ориентированного подхода: учеб, посо­ бие / Р.А. Файзрахманов, А.В. Архипов. - Пермь: Изд-во Перм. гос. техн. ун-та, 2011. - 223 с.

ISBN 978-5-398-00545-5

Приводится описание процесса проектирования информационных систем с использованием унифицированного языка моделирования UML. Даны прак­ тические примеры построения диаграмм UML с помощью CASE-средства Rational Rose.

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

Адресовано студентам, обучающимся по направлению «Информатика и вычислительная техника» и другим ИТ-направлениям, а также всем, кто начинает изучать вопросы применения CASE-средств для проектирования информационных систем на основе объектно ориентированного подхода.

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

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

В настоящее время для объектно ориентированного анализа и проектирования широко используется унифицированный язык мо­ делирования UML (Unified Modeling Language), разработанный груп­ пой ведущих компьютерных фирм мира OMG (Object Management Group), и фактически является стандартом по объектно ориентиро­ ванным технологиям, реализованным многими фирмами-произво- дителями программного обеспечения в рамках CASE-технологий, в том числе Rational Software (продукт Rational Rose).

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

В первой главе пособия (Значение моделирования) обсуждается роль моделирования в разработке качественного программного продукта.

Вторая глава (Концептуальная модель и структура UML) знако­ мит читателя с концептуальной моделью и структурой языка UML. Эта глава рассказывает об основных строительных блоках UML.

Третья глава (Постановка задачи) содержит постановку задачи для практической реализации.

Следующие главы содержат детальное описание девяти основных диаграмм UML. Каждая из этих глав поделена на пять разделов: теоре­ тическая часть, реализация в системе Rational Rose, подведение ито­ гов, контрольные вопросы и контрольные задачи. В теоретической

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

Тринадцатая глава (Ггнерация кода) содержит описания инстру­ ментов генерации исходного кода, которые предоставляет система Rational Rose.

Вприложении 1 (Использование «Rational Rose C++ Analyzer» для обратного восстановления модели по исходному коду) предлага­ ются пошаговые инструкции по восстановлению модели проекта по исходному программному коду.

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

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

Учебное пособие обобщает опыт преподавания соответствующе­ го раздела дисциплин для студентов, обучающихся по направлению 230100 (552800) «Информатика и вычислительная техника». Оно может быть полезно также всем, кто начинает изучать вопросы при­ менения CASE-средств для проектирования информационных систем на основе объектно ориентированного подхода.

В руководстве [1] приведен пример, который, на наш взгляд, наи­ лучшим образом раскрывает причину неудач ряда проектов по созда­ нию программных систем.

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

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

Делая акцент на написании строк исходного кода и даже на ис­ пользовании языков визуального программирования (Visual Basic, Delphi и др.), разработчик вряд ли сможет сколько-нибудь полно ох­ ватить проект в целом. Предварительное моделирование, в свою оче­ редь, позволяет проектировщику увидеть общую картину взаимодей­ ствий компонентов проекта без необходимости анализа особых свойств каждого компонента [4].

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

Для понимания UML необходимо усвоить его концептуальную модель, которая включает в себя три составные части: основные строительные блоки языка, правила их сочетания и некоторые общие для всего языка механизмы. Язык UML имеет сложную иерархиче­ скую структуру, представленную на рис. 2.1.

Язык UML

■—Узлы

-Аннотационные

- Когаюнентав

L- Примечания

-Развертывания

Рис. 2.1. Структура UML

Словарь языка UML содержит три строительных блока: сущно­ сти, отношения, диаграммы.

Сущности - это абстракции, являющиеся основными элемен­ тами модели.

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

Поведенческие сущности являются динамическими составляю­ щими модели UML. Это глаголы языка, они описывают поведение модели во времени и пространстве.

Группирующие сущности являются организующими частями мо­ дели UML. Это блоки, на которые можно разложить модель.

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

Отношения связывают различные сущности.

Зависимость —это семантическое отношение между двумя сущ­ ностями, при котором изменение одной из них, независимой, может повлиять на семантику другой, зависимой.

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

Обобщение — это отношение «специализация/обобщение», при котором объект специализированного элемента (потомок) может быть подставлен вместо объекта обобщенного элемента (родителя или предка).

Реализация —это семантическое отношение между классифика­ торами (классификатор - механизм, описывающий структурные и поведенческие свойства), при котором один классификатор опреде­ ляет «контракт», а другой гарантирует его выполнение.

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

Выделяют девять видов диаграмм:

-диаграммы прецедентов;

-диаграммы классов;

-диаграммы объектов;

-диаграммы последовательностей;

-диаграммы сотрудничества;

-диаграммы состояний;

-диаграммы деятельностей;

-диаграммы компонентов;

-диаграммы развертывания.

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

должна выполнять проектируемая система, не вдаваясь в подробно­

сти, как это реализуется.

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

на будущей системы.

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

После того как получено функционально ориентированное

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

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

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

На заключительном этапе проектирования информационной сис­ темы с помощью UML ведется разработка диаграмм компонентов

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

3.ПОСТАНОВКА ЗАДАЧИ ДЛЯ РЕАЛИЗАЦИИ

ВRATIONAL ROSE

Входе изучения методического пособия будет рассматриваться разработка системы учета университетских дисциплин. За основу взят пример, приведенный в работе Т. Кватрани [4].

Студенты старших курсов имеют возможность по желанию вы­ брать четыре элективные дисциплины.

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

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

Студент посредством системы учета осуществляет выбор четы­

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

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

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

Система учета дисциплин передает информацию во внешнюю систему учета студентов.

Нотация UML допускает определять общие типы актеров, напри­ мер «Работник предприятия», а затем специализировать их, создав разновидности, например «Менеджер», «Аналитик» (рис. 4.3).

Рис. 4.3. Пример обобщенного актера

Рис. 4.4. Изображение прецедента

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

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

Связь (communication). Актеров можно связывать с прецедентами только отношениями ассоциации [1]. Ассоциация между актером и прецедентом показывает, что они общаются друг с другом, воз­ можно, посылая или принимая сообщения. Ассоциативное отноше­ ние устанавливает, какую конкретную роль играет актер при взаимо­ действии с прецедентом. На диаграмме прецедентов, так же, как и на других диаграммах, отношение ассоциации обозначается сплошной линией между актером и прецедентом (рис. 4.5).

Отношение обобщения означает, что прецедент-потомок насле­ дует поведение и семантику своего родителя, может замещать его или дополнять его поведение, а кроме того, может быть подставлен всюду, где появляется его родитель (как родитель, так и потомок мо­ гут иметь конкретные экземпляры). Например, прецедент «Прове­ рить клиента» может иметь двух специализированных потомков: «Проверить документы» и «Проверить задолженность» (рис. 4.8).

Рис. 4.8. Пример отношения расширения, отношения включения и отношения обобщения

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

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

Организация прецедентов. Для организа­ ции прецедентов и других элементов языка UML их группируют в пакеты [1]. Пакеты позволяют упростить проектирование боль­ ших систем путем организации элементов

в более крупные блоки. На рис. 4.9 представлено графическое изо­ бражение пакета в нотации UML.

После того как дисциплины распределены, сотрудник деканата должен убедиться в корректности распределения и сохранить (утвер­ дить) заявки преподавателей. В том случае, если возникла конфликт­ ная ситуация, сотрудник деканата вправе сам произвести необходимое перераспределение дисциплин, уведомив об этом преподавателей. На­ зовем этот прецедент «Сохранение информации о преподавателях».

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

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

По истечении определенного периода сотрудник деканата закры­ вает регистрацию. С этого момента ни один студент не может вно­ сить изменения в список выбранных им дисциплин. Этот прецедент назовем соответственно «Закрытие регистрации». После закрытия регистрации сотрудник деканата сохраняет и утверждает заявки сту­ дентов на выбранные дисциплины. Если на одну из дисциплин запи­ салось менее пяти человек, то сотрудник деканата удаляет эту дисци­ плину и согласовывает со студентами, которые подали заявки на эту дисциплину, перевод на другую дисциплину. Эти действия объеди­ ним в прецеденте «Сохранение информации о студентах».

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

6.0Дополнительные Нет. замечания