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

Содержание:

ВВЕДЕНИЕ

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

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

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

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

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

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

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

Все эти обстоятельства привели к появлению специальной методологии, получившей название методологии объектно-ориентированнного анализа и проектирования (ООАП). В рамках этого подхода возникало много направлений, период конца 80-х и начало 90-х годов принято называть «войной методов», завершение которой (хотя споры продолжаются) связано с появлением языка UML.

Унифицированный язык моделирования (UML, Unified Modeling Language) является преемником методов объектно-ориентированного анализа и проектирования, он непосредственно унифицирует методы ведущих специалистов в этой области Буча, Рамбо и Джекобсона, однако обладает большими возможностями [1]. Язык UML прошел процесс стандартизации в рамках консорциума OMG (Object Management Group) и с 1997 года является стандартом OMG.

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

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

Обзор UML

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

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

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

UML - это язык

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

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

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

UML - это не просто набор графических символов. За каждым из них стоит хорошо определенная семантика (см. "The Unified Modeling Language Reference Manual"). Это значит, что модель, написанная одним разработчиком, может быть однозначно интерпретирована другим - или даже инструментальной программой. Так решается первая из перечисленных выше проблем.

UML - это язык специфицирования

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

UML - это язык конструирования.

UML не является языком визуального программирования, но модели, создан­ные с его помощью, могут быть непосредственно переведены на различные языки программирования. Иными словами, UML-модель можно отобразить на такие языки, как Java, C++, Visual Basic, и даже на таблицы реляционной базы данных или устойчивые объекты объектно-ориентированной базы данных. Те понятия, которые предпочтительно передавать графически, так и представляются в UML; те же, которые лучше описывать в текстовом виде, выражаются с помощью языка программирования.

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

– требования к системе;

– архитектуру;

– проект;

– исходный код;

– проектные планы;

- тесты;

– прототипы;

– версии, и др.

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

1.1. Строительные блоки UML

Словарь языка UML включает три вида строительных блоков:

– сущности;

– отношения;

– диаграммы.

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

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

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

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

Ин­терфейс редко существует сам по себе - обычно он присоединяет­ся к реализующему его классу или компоненту.

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

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

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

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

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

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

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

Поведенческие сущности (Behavioral things) являются динамическими состав­ляющими модели UML. Это глаголы языка: они описывают поведение модели во времени и пространстве. Существует всего два основных типа поведен­ческих сущностей.

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

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

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

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

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

- диаграммы кооперации;

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

- диаграммы действий;

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

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

1.2. Правила языка UML

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

В языке UML имеются семантические правила, позволяющие корректно и од­нозначно определять:

– имена, которые можно давать сущностям, отношениям и диаграммам;

– область действия (контекст, в котором имя имеет некоторое значение);

– видимость (когда имена видимы и могут использоваться другими элемен­тами);

– целостность (как элементы должны правильно и согласованно соотноситься друг с другом);

– выполнение (что значит выполнить или имитировать некоторую динамичес­кую модель).

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

– содержат скрытые элементы (ряд элементов не показывают, чтобы упростить восприятие);

– неполные (отдельные элементы пропущены);

– несогласованные (целостность модели не гарантируется).

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

1.3 Общие механизмы языка UML

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

– спецификации (Specifications);

– дополнения (Adornments);

– принятые деления (Common divisions);

– механизмы расширения (Extensibility mechanisms).

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

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

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

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

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

Механизмы расширения. UML - это стандартный язык для разработки «черте­жей» программного обеспечения, но ни один замкнутый язык не в состоянии охватить нюансы всех возможных моделей в различных предметных областях. По­этому UML является открытым языком, то есть допускает контролируемые рас­ширения. Механизмы расширения UML включают:

– стереотипы;

– помеченные значения;

– ограничения.

Стереотип (Stereotype) расширяет словарь UML, позволяя на основе существу­ющих блоков языка создавать новые, специфичные для решения конкретной про­блемы. Например, работая с такими языками программирования, как Java или C++, часто приходится моделировать исключения (Exceptions) - они являются обыкно­венными классами, хотя и рассматриваются особым образом. Обычно требуется, чтобы ис­ключения можно было возбуждать и перехва­тывать, и ничего больше. Если пометить ис­ключения соответствующим стереотипом, то с ними можно будет обращаться как с обычны­ми строительными блоками языка.

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

1.4. Архитектура программной системы

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

Архитектура - это совокупность существенных решений касательно:

- организации программной системы;

- выбора структурных элементов, составляющих систему, и их интерфейсов;

- поведения этих элементов, специфицированного в кооперациях с другими элементами;

- составления из этих структурных и поведенческих элементов все более и бо­лее крупных подсистем;

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

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

Вид с точки зрения прецедентов (Use case view) охватывает прецеденты, кото­рые описывают поведение системы, наблюдаемое конечными пользователями, ана­литиками и тестировщиками.

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

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

Выводы

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

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

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

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

2. Классы

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

Классы используются для составления словаря разрабатываемой системы [2, c. 65].

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

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

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

2.1. Термины и понятия

Классом (Class) называется описание совокупности объектов с общими атрибутами, операциями, отношениями и семантикой. Графически класс изображает­ся в виде прямоугольника.

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

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

Атрибуты.

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

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

Операцией называется реализация услуги, которую можно запросить у любого объекта класса для воздействия на поведение. Иными словами, операция - это аб­стракция того, что позволено делать с объектом. У всех объектов класса имеется общий набор операций. Класс может содержать любое число операций или не со­держать их вовсе. Например, для всех объектов класса Rectangle (Прямоуголь­ник) из библиотеки для работы с окнами, содержащейся в пакете awt языка Java,определены операции перемещения, изменения размера и опроса значений свойств. Часто (хотя не всегда) обра­щение к операции объекта изменяет его состояние или его данные. Операции класса изображаются в разделе, расположенном ниже раздела с атрибутами.

Имя операции, как и имя класса, может быть произвольной тек­стовой строкой. На практике для именования операций использу­ют короткий глагол или глагольный оборот, соответствующий оп­ределенному поведению объемлющего класса. Каждое слово в имени операции, кроме самого первого, обычно пишут с заглавной буквы, например move или isEmpty.

2.2. Типичные приемы моделирования. Словарь системы

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

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

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

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

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

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

Shipment

Обязанности

­– сохранять информацию

о товарах, поставленных по закзам

­– отслеживать состояние и местонахождение товаров

Рисунок 1. Моделирование словаря системы

На рис. 1 показан набор классов для системы розничной торговли: Customer (Клиент), Order (Заказ) и Product (Товар). Представлено несколько соотнесен­ных с ними абстракций, взятых из словаря проблемной области: Shipment (От­грузка), Invoice (Накладная) и Warehouse (Склад). Одна абстракция, а именно Transaction (Транзакция), применяемая к заказам и отгрузкам, связана с тех­нологией решения задачи.

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

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

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

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

1. Идентифицируйте совокупность классов, совместно отвечающих за некото­рое поведение.

2. Определите обязанности каждого класса.

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

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

5. Рассмотрите, как классы кооперируются друг с другом, и пере­распределите обязанности с таким расчетом, чтобы ни один класс в рамках кооперации не делал слишком много или слишком мало.

2.3. Внепрограммные сущности

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

View

Обязанности

­– изображать модель на экране

– управлять перемещением и изменением размера поля зрения

– перехватывать события пользователя

Controller

Обязанности

– синхронизировать изменение модели и ее видов

Model

Обязанности

­– управлять состоянием

модели

Рисунок 2. Моделирование распределения обязанностей в системе

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

1. Смоделируйте сущности, абстрагируемые в виде классов.

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

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

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

2.4. Примитивные типы

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

Моделирование примитивных типов производится следующим образом:

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

2.Если требуется задать связанный с типом диапазон значений, воспользуй­тесь ограничениями.

Рис. 3 показывает, что такие сущности можно моделировать в UML как типы или перечисления, которые изображаются точно так же, как классы, но с явно указанным стереотипом. Сущности, подобные целым числам (представленные классом Int), моделируются как типы, а с помощью ограниче­ний вы можете явно указать диапазон принимаемых значений. Перечислимые типы (скажем, Boolean и Status) допустимо моделировать как перечисления, причем их конкретные значения становятся атрибутами.

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

Рисунок 3. Моделирование примитивных типов

2.5. Рекомендации к моделированию классов

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

- является четко очерченной абстракцией некоторого понятия из словаря про­блемной области или области решения;

- содержит небольшой, точно определенный набор обязанностей и выполняет каждую из них;

- поддерживает четкое разделение спецификаций абстракции и ее реализации;

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

Изображая класс в UML, придерживайтесь следующих правил:

- показывайте только те его свойства, которые важны для понимания абстрак­ции в данном контексте;

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

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

Выводы

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

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

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

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

3. Примеры моделирования

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

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

В качестве среды моделирования будем использовать систему Rational Rose [3] фирмы Rational Software, являющейся признанным лидером в разработке систем моделирования программного обепспечения.

3.1. Диаграмма прецедентов

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

В данной модели актером является пользователь электронной базы данных музыки, а набором действий - редактирование данных и поиск. Между сущностью «Пользователь» и «Редактирование», «Пользователь» и «Поиск исполнителя», а также «Пользователь» и «Поиск альбома», определены отношения ассоциации. Между сущностью «Редактирование» и сущностями «Создание новой записи», «Удаление записи», «Изменение записи» определены отношения включения (include). Между сущностью «Поиск альбома» и сущностями «по названию», «по стилю» также проставлены отношения включения. При этом ничего не говорится о том, каким образом будет реализовано взаимодействие актеров с системой. Диаграмма прецедентов приводится на рис. 4.

Рисунок 4. Диаграмма прецедентов (Use Case Diagram)

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

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

В нашем случае основным является класс «Исполнитель» с атрибутами: «Название», «Дата рождения», «Страна проживания», «Награды», «Фото». С помощью отношения ассоциации он связан с классом «Альбом», с помощью реализации – с классом «Поиск исполнителя», имеющим стереотип «interface», и с классом «Тип Стиля», имеющим стереотип «enum». Классы «Исполнитель» и «Альбом» связаны с классом «Электронная таблица», не имеющим атрибутов, с помощью отношений обобщения. Диаграмма классов для разрабатываемой нами системы приводится на рис. 5.

Рисунок 5. Диаграмма классов (Class Diagram)

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

Подробно о преобразовании объектно-ориентированной модели в реляционную можно прочитать в [6], мы остановимся на основных моментах:

1) основные классы, содержащие данные, предназначенные для хранения, преобразуются в таблицы;

2) при наличии ассоциаций типа «один-к-одному» хотя бы с одной стороны нужно добавить дополнительное кодовое поле где указать код (ключ) второй записи для обеспечения связи данных;

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

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

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

3.3. Диаграммы взаимодействия

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

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

Рисунок 6. Диаграмма последовательностей (Sequence Diagram)

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

3.4. Реализация информационной системы

Для реализации модели справочно-информационной системы музыки на CD была выбрана одна из самых популярных систем программирования Borland Delphi .

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

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

Фирмой Ensemble Systems разработана программа-мост Rose Delphi Link (RDL), связывающая Rational Rose и Delphi. Основные функции RDL – это генерация кода и обратное проектирование. Генерируемый RDL код не содержит реализацию функциональности. Генерируются только декларативные элементы: определения классов, интерфейсов, записей, типов и т.д.

Рисунок 7. Диаграмма классов, выполненная с помощью Rose Delphi Link

Мощность и гибкость Delphi при работе с базами данных, возможность связи с Rational Rose и отсутствие специальных требований к ресурсам компьютера, позволяют эффективно использовать Delphi для разработки приложения справочно-информационной системы музыки на CD.Приложение состоит из одной формы, на которой находятся следующие основные компоненты: DBGrid, DBEdit, DBNavigator, Table, DataSource и Query.

Рисунок 8. Внешний вид диалогового окна

Слева на форме отображаются характеристики исполнителя, такие как, «Исполнитель», «Дата рождения», «Страна проживания», «Награды», «Фото».

Справа на форме отображаются сведения об альбоме, такие как, «Исполнитель», «Название альбома», «Стиль», «Год выпуска», «Описание».

Поиск осуществляется с помощью компонента Query, в котором формируется SQL-запрос на выборку. Полученный результат отправляется в компонент DataSource и после этого отображается в компоненте DBGrid.

Ниже представлен вариант поиска исполнителя по названию.

Рисунок 9. Поиск по критериям

Итак, проанализировав предметную область и поставленную задачу, с помощью программы Rational Rose была разработана концептуальная модель информационно – справочной системы музыки на CD. Затем эта модель была реализована в Borland Delphi 7. В результате получилась удобная и наглядная система, с помощью которой пользователь всегда будет знать о том, какие альбомы и каких исполнителей имеются в его фонотеке, добавлять данные при приобретении нового диска или удалять при утере.

В [7] приводится пример подробной разработки модели медицинского учреждения средствами UML.

Выводы

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

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

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

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

ЗАКЛЮЧЕНИЕ

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

Можно выделить основные этапы разработки системы с использованием средств UML:

1) описание задания в общих чертах на естественном языке;

2) выделение прецедентов и актеров бедующей системы;

3) определение объектов и взаимодействий между ними;

4) детализация функциональности с помощью диаграмм последовательности (переходов) для каждого прецедента;

5) группировка объектов, переход от объектов и сущностей к компонентам;

6) ревизия результатов предыдущих этапов;

7) детальная проработка реализации компонентов, разделение компонентов по участникам коллектива разработчиков;

8) Построение профиля баз данных с учетом способа хранения данных в выбранной СУБД;

9) размещение компонентов системы;

10) кодирование.

Каждый этап поддерживается соответствующими UML-диаграммами.

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

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

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

Библиографический список

1. Буч Г. Рамбо Дж., Джекобсон А. UML Руководство пользователя: Пер. с англ.- М.: ДМК Пресс, 2001. - 423 с.: ил.

2. Фаулер М., Скотт К. UML в кратком изложении. Применение стандартного языка объектного моделирования. Пер. с англ.- М. Мир, 1999. – 192 с.: ил.

3. Боггс У., Боггс. М. UML Rational Rose. – М.: Издательство «Лори», 2002. – 510 с.

4. Липаев В.В. Проектирование программных средств: Учебное пособие для вузов.- М.Высшая школа, 1990.-303 с., ил.

5. Лучко О. Н. и др. Базы данных: Учебное пособие. Лучко О. Н. Морарь Е. В. Червенчук И. В. Омск: Изд-во ОГИС, 2003. – 168 с.

6. Мюллер Р. Дж. Базы данных и UML. Проектирование. Пер. с англ.- Изд-во ЛОРИ, 2000. - 420с.: ил.

7. Нейбург Э. Дж., Максимчук Р. А. Проектирование баз данных с помощью UML – Вильямс, 2002. – 228 с.

8. «Проектирование на Rose Delphi Link» (http://www.interface.ru/fset.asp?Url=/rational/rational.htm)

9. Электронная версия учебника по UML (http://www.isuct.ru/~ivt/books/CASE/case6.html )