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

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

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

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

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

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 (Датчик Температуры).

Атрибуты.

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