Анализ возможностей организации 5 страница
! Следует запомнить:
Сущность структурного подхода к разработке ПО ЭИС заключается в его декомпозиции (разбиении) на автоматизируемые функции. В структурном анализе используются в основном две группы средств, иллюстрирующих функции, выполняемые системой, и отношения между данными.
ОБЪЕКТНО-ОРИЕНТИРОВАННЫЙ ПОДХОД К ПРОЕКТИРОВАНИЮ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Прочитав эту главу, вы узнаете:
· Что представляет собой объектно-ориентированный подход к проектированию ПО.
· В чем заключаются основные особенности языка моделирования
· UML.
· Как строятся модели и диаграммы, входящие в состав средств языка
· UML.
3.1
СУЩНОСТЬ ОБЪЕКТНО-ОРИЕНТИРОВАННОГО ПОДХОДА
Как было отмечено в разд. 2.1, принципиальное различие между структурным и объектно-ориентированным подходом заключается в способе декомпозиции системы. Объектно-ориентированный подход использует объектную декомпозицию, при этом статическая структура системы описывается в терминах объектов и связей между ними, а поведение системы описывается в терминах обмена сообщениями между объектами. Каждый объект системы обладает своим собственным поведением, моделирующим поведение объекта реального мира.
Понятие "объект" впервые было использовано около 30 лет назад в технических средствах при попытках отойти от традиционной архитектуры фон Неймана и преодолеть барьер между высоким уровнем программных абстракций и низким уровнем абстрагирования на уровне компьютеров. С объектно-ориентированной архитектурой также тесно связаны объектно-ориентированные операционные системы. Однако наиболее значительный вклад в объектный подход был внесен объектными и объектно-ориентированными языками программирования: Simula, Smalltalk, C++, Object Pascal. На объектный подход оказали влияние также развивавшиеся достаточно независимо методы моделирования баз данных, в особенности подход "сущность-связь".
Концептуальной основой объектно-ориентированного подхода является объектная модель. Основными ее элементами являются:
· абстрагирование (abstraction);
· инкапсуляция (encapsulation);
· модульность (modularity);
· иерархия (hierarchy).
Кроме основных имеются еще три дополнительных элемента, не являющихся в отличие от основных строго обязательными:
· типизация (typing);
· параллелизм (concurrency);
· устойчивость (persistence).
Абстрагирование — это выделение существенных характеристик некоторого объекта, которые отличают его от всех других видов объектов и, таким образом, четко определяют его концептуальные границы относительно дальнейшего рассмотрения и анализа. Абстрагирование концентрирует внимание на внешних особенностях объекта и позволяет отделить самые существенные особенности его поведения от деталей их реализации. Выбор правильного набора абстракций для заданной предметной области представляет собой главную задачу объектно-ориентированного проектирования.
Инкапсуляция — это процесс отделения друг от друга отдельных элементов объекта, определяющих его устройство и поведение. Инкапсуляция служит для того, чтобы изолировать интерфейс объекта, отражающий его внешнее поведение, от внутренней реализации объекта. Объектный подход предполагает, что собственные ресурсы, которыми могут манипулировать только методы самого класса, скрыты от внешней среды. Абстрагирование и инкапсуляция являются взаимодополняющими операциями: абстрагирование фокусирует внимание на внешних особенностях объекта, а инкапсуляция (или, иначе, ограничение доступа) не позволяет объектам-пользователям различать внутреннее устройство объекта.
Модульность — это свойство системы, связанное с возможностью ее декомпозиции на ряд внутренне связных, но слабо связанных между собой модулей. Инкапсуляция и модульность создают барьеры между абстракциями.
Иерархия — это ранжированная или упорядоченная система абстракций, расположение их по уровням. Основными видами иерархических структур применительно к сложным системам являются структура классов (иерархия по номенклатуре) и структура объектов (иерархия по составу). Примерами иерархии классов являются простое и множественное наследование (один класс использует структурную или функциональную часть соответственно одного или нескольких других классов), а иерархии объектов — агрегация.
Типизация — это ограничение, накладываемое на класс объектов и препятствующее взаимозаменяемости различных классов (или сильно сужающее ее возможность). Типизация позволяет защититься от использования объектов одного класса вместо другого или по крайней мере управлять таким использованием.
Параллелизм — свойство объектов находиться в активном или пассивном состоянии и различать активные и пассивные объекты между собой.
Устойчивость — свойство объекта существовать во времени (вне зависимости от процесса, породившего данный объект) и/или в пространстве (при перемещении объекта из адресного пространства, в котором он был создан).
Основные понятия объектно-ориентированного подхода — объект и класс.
Объект определяется как осязаемая реальность (tangible entity) - предмет или явление, имеющие четко определяемое поведение. Объект обладает состоянием, поведением и индивидуальностью; структура и поведение схожих объектов определяют общий для них класс. Термины "экземпляр класса" и "объект" являются эквивалентными. Состояние объекта характеризуется перечнем всех возможных (статических) свойств данного объекта и текущими значениями (динамическими) каждого из этих свойств. Поведение характеризует воздействие объекта на другие объекты и наоборот относительно изменения состояния этих объектов и передачи сообщений. Иначе говоря, поведение объекта полностью определяется его действиями. Индивидуальность - это свойства объекта, отличающие его от всех других объектов.
Определенное воздействие одного объекта на другой с целью вызвать соответствующую реакцию называется операцией. Как правило, в объектных и объектно-ориентированных языках операции, выполняемые над данным объектом, называются методами и являются составной частью определения класса.
Класс — это множество объектов, связанных общностью структуры и поведения. Любой объект является экземпляром класса. Определение классов и объектов — одна из самых сложных задач объектно-ориентированного проектирования.
Следующую группу важных понятий объектного подхода составляют наследование и полиморфизм. Понятие полиморфизма может быть интерпретировано как способность класса принадлежать более чем одному типу. Наследование означает построение новых классов на основе существующих с возможностью добавления или переопределения данных и методов.
Объектно-ориентированная система изначально строится с учетом ее эволюции. Наследование и полиморфизм обеспечивают возможность определения новой функциональности классов с помощью создания производных классов - потомков базовых классов. Потомки наследуют характеристики родительских классов без изменения их первоначального описания и добавляют при необходимости собственные структуры данных и методы. Определение производных классов, при котором задаются только различия или уточнения, в огромной степени экономит время и усилия при производстве и использовании спецификаций и программного кода.
return false">ссылка скрытаВажным качеством объектного подхода является согласованность моделей деятельности организации и моделей проектируемой системы от стадии формирования требований до стадии реализации. Требование согласованности моделей выполняется благодаря возможности применения абстрагирования, модульности, полиморфизма на всех стадиях разработки. Модели ранних стадий могут быть непосредственно подвергнуты сравнению с моделями реализации. По объектным моделям может быть прослежено отображение реальных сущностей моделируемой предметной области (организации) в объекты и классы информационной системы.
3.2
УНИФИЦИРОВАННЫЙ ЯЗЫК МОДЕЛИРОВАНИЯ UML
Большинство существующих методов объектно-ориентированного анализа и проектирования (ООАП) включают как язык моделирования, так и описание процесса моделирования. Язык моделирования — это нотация (в основном графическая), которая используется методом для описания проектов. Нотация представляет собой совокупность графических объектов, которые используются в моделях; она является синтаксисом языка моделирования. Например, нотация диаграммы классов определяет, каким образом представляются такие элементы и понятия, как класс, ассоциация и множественность. Процесс — это описание шагов, которые необходимо выполнить при разработке проекта.
Унифицированный язык моделирования UML (Unified Modeling Language) — это преемник того поколения методов ООАП, которые появились в конце 80-х и начале 90-х гг. Создание UML фактически началось в конце 1994 г., когда Гради Буч и Джеймс Рамбо начали работу по объединению методов Booch и OMT (Object Modeling Technique) под эгидой компании Rational Software. К концу 1995 г. они создали первую спецификацию объединенного метода, названного ими Unified Method, версия 0.8. Тогда же, в 1995 г., к ним присоединился создатель метода OOSE (Object-Oriented Software Engineering) Ивар Якобсон. Таким образом, UML является прямым объединением и унификацией методов Буча, Рамбо и Якобсона, однако дополняет их новыми возможностями. Главными в разработке UML были следующие цели:
· предоставить пользователям готовый к использованию выразительный язык визуального моделирования, позволяющий разрабатывать осмысленные модели и обмениваться ими;
· предусмотреть механизмы расширяемости и специализации для расширения базовых концепций;
· обеспечить независимость от конкретных языков программирования и процессов разработки;
· обеспечить формальную основу для понимания этого языка моделирования (язык должен быть одновременно точным и доступным для понимания, без лишнего формализма);
· стимулировать рост рынка объектно-ориентированных инструментальных средств;
· интегрировать лучший практический опыт.
Язык UML находится в процессе стандартизации, проводимом OMG (Object Management Group) — организацией по стандартизации в области объектно-ориентированных методов и технологий, в настоящее время принят в качестве стандартного языка моделирования и получил широкую поддержку в индустрии ПО. Язык UML принят на вооружение практически всеми крупнейшими компаниями — производителями ПО (Microsoft, IBM, Hewlett-Packard, Oracle, Sybase и др.). Кроме того, практически все мировые производители CASE-средств, помимо Rational Software (Rational Rose), поддерживают UML в своих продуктах (Paradigm Plus 3.6, System Architec, Microsoft Visual Modeler for Visual Basic, Delphi, PowerBuilder и др.). Полное описание UML можно найти на сайтах http://www.omg.org, http://www.rational.com и http://uml.shl.com. Описание UML на русском языке содержится в книге М. Фаулера и К. Скотта , в дальнейшем изложении терминология языка соответствует данному переводу.
Создатели UML представляют его как язык для определения, представления, проектирования и документирования программных систем, организационно-экономических, технических и др. UML содержит стандартный набор диаграмм и нотаций самых разнообразных видов. Стандарт UML версии 1.1, принятый OMG в 1997 г., предлагает следующий набор диаграмм для моделирования:
· диаграммы вариантов использования (use case diagrams) — для моделирования бизнес-процессов организации (требований к системе);
· диаграммы классов (class diagrams) — для моделирования статической структуры классов системы и связей между ними;
· диаграммы поведения системы (behavior diagrams);
· диаграммы взаимодействия (interaction diagrams) - для моделирования процесса обмена сообщениями между объектами. Существуют два вида диаграмм взаимодействия:
· диаграммы последовательности (sequence diagrams);
· кооперативные диаграммы (collaboration diagrams);
· диаграммы состояний (statechart diagrams) — для моделирования поведения объектов системы при переходе из одного состояния в другое;
· диаграммы деятельностей (activity diagrams) — для моделирования поведения системы в рамках различных вариантов использования или моделирования деятельностей;
· диаграммы реализации (implementation diagrams):
· диаграммы компонентов (component diagrams) — для моделирования иерархии компонентов (подсистем) системы; диаграммы размещения (deployment diagrams) — для моделирования физической архитектуры системы.
3.3. ВАРИАНТЫ ИСПОЛЬЗОВАНИЯ
В течение достаточно длительного периода времени в процессе как объектно-ориентированного, так и традиционного структурного проектирования разработчики использовали типичные сценарии, помогающие лучше понять требования к системе. Эти сценарии трактовались весьма неформально — они почти всегда использовались и крайне редко документировались. Ивар Якобсон впервые ввел понятие "вариант использования" (use case) и придал ему такую значимость, что он превратился в основной элемент разработки и планирования проекта.
Вариант использования представляет собой последовательность действий (транзакций), выполняемых системой в ответ на событие, инициируемое некоторым внешним объектом (действующим лицом). Вариант использования описывает типичное взаимодействие между пользователем и системой. Например, два типичных варианта использования обычного текстового процессора — "сделать некоторый текст полужирным" и "создать индекс". Даже на таком простом примере можно выделить ряд свойств варианта использования: он охватывает некоторую очевидную для пользователей функцию, может быть как небольшим, так и достаточно крупным и решает для пользователя некоторую дискретную задачу. В простейшем случае вариант использования определяется в процессе обсуждения с пользователем тех функций, которые он хотел бы реализовать.
Когда Якобсон в 1994 г. предложил варианты использования в качестве основных элементов процесса разработки ПО, он Также предложил применять для их наглядного представления диаграммы вариантов использования. На рис. 3.1 показаны некоторые варианты использования для системы торговой организации; человеческие фигурки здесь обозначают действующих лиц, овалы — варианты использования, а линии и стрелки - различные связи между действующими лицами и вариантами использования.
Рис. 3.1.Диаграмма вариантов использования
Действующее лицо (actor) — это роль, которую пользователь играет по отношению к системе. На рис. 3.1 четыре действующих лица:
Менеджер по продажам, Оптовый торговец, Продавец и Система учета. Действующие лица представляют собой роли, а не конкретных людей или наименования работ. Несмотря на то, что на диаграммах вариантов использования они изображаются в виде стилизованных человеческих фигурок, действующее лицо может также быть внешней системой, которой необходима некоторая информация от данной системы (например, Система учета). Показывать на диаграмме действующих лиц системы следует только в том случае, когда им действительно необходимы некоторые варианты использования.
Все варианты использования так или иначе связаны с внешними требованиями к функциональности системы. Если Системе учета требуется файл, то это требование должно быть удовлетворено. Варианты использования всегда следует анализировать вместе с действующими лицами системы, определяя при этом реальные задачи пользователей и рассматривая альтернативные способы решения этих задач.
Действующие лица могут играть различные роли по отношению к варианту использования. Они могут пользоваться его результатами или могут сами непосредственно в нем участвовать. Значимость различных ролей действующего лица зависит от того, каким образом используются его связи.
Хорошим источником для идентификации вариантов использования служат внешние события. Следует начать с перечисления всех событий, происходящих во внешнем мире, на которые система должна каким-то образом реагировать. Какое-либо конкретное событие может повлечь за собой реакцию системы, не требующую вмешательства пользователей, или, наоборот, вызвать чисто пользовательскую реакцию. Идентификация событий, на которые необходимо реагировать, помогает выделить варианты использования.
В дополнение к связям между действующими лицами и вариантами использования существуют два других типа связей (см. рис. 3.1): "использование" (uses) и "расширение" (extends) между вариантами использования. Связь типа "расширение" применяется тогда, когда один вариант использования подобен другому, но несет несколько большую нагрузку.
В данном примере основным вариантом использования является Заключить сделку. В этом варианте предполагается нормальный ход процесса. Однако в случае превышения некоторого лимита — например, максимальной суммы торговой сделки, установленной дай конкретного клиента, процесс, связанный с данным вариантом использования, не может выполняться обычным образом и должен претерпеть некоторое изменение. Такое изменение можно предусмотреть в рамках основного варианта использования Заключить сделку. Однако такой подход может привести к загромождению варианта использования разной "побочной" логикой, за которой теряется его "нормальная" логика. Другой способ учесть изменение - это поместить нормальный процесс в рамки одного варианта использования, а все отклонения от него - в другие варианты.
Связь "использование" применяется в тех ситуациях, когда имеется какой-либо фрагмент поведения системы, который повторяется более чем в одном варианте использования, и нет необходимости копировать его описание в каждом из этих вариантов. Например, варианты Проанализировать риск и Договориться о цене требуют оценки стоимости сделки. Таким образом, создается отдельный вариант использования под названием Оценка стоимости, и предыдущие два варианта будут на него ссылаться.
Отметим сходства и различия между связями "расширение" и "использование". Оба они предполагают выделение общих фрагментов поведения из нескольких вариантов использования в единственный вариант, который "используется" или1 "расширяет" несколько других вариантов. С другой стороны, в каждом случае это делается с различными целями.
Два типа связей подразумевают различный смысл связей с действующими лицами. В случае "расширения" у действующих лиц имеется связь с основным вариантом использования. При этом предполагается, что данное действующее лицо реализует как основной вариант использования, так и все его расширения. В случае применения связи "использование" действующие лица, связанные с общим вариантом использования, как правило, отсутствуют. Даже если имеются исключения, то такое действующее лицо не имеет отношения к реализации других вариантов использования.
Выбор применяемой связи определяется следующими правилами:
· связь "расширение" следует применять при описании изменений в нормальном поведении системы;
· связь "использование" следует применять для избежания повторов в двух (или более) вариантах использования.
Варианты использования являются необходимым средством на стадии формирования требований к ПО. Каждый вариант использования — это потенциальное требование к системе, и пока оно не выявлено, невозможно запланировать его реализацию.
Различные разработчики подходят к описанию вариантов использования с разной степенью детализации. Например, Ивар Якобсон утверждает, что для проекта с трудоемкостью в 10 человеко-лет количество вариантов использования может составлять около 20 (не считая связей "использование" и "расширение"). Следует предпочитать небольшие и детализированные варианты использования, поскольку они облегчают составление и реализацию согласованного плана проекта.
3.4. ДИАГРАММЫ КЛАССОВ
3.4.1. ОБЩИЕ СВЕДЕНИЯ
Диаграммы классов являются центральным звеном объектно-ориентированных методов. Диаграмма классов определяет типы объектов системы и различного рода статические связи, которые существуют между ними. Имеются два основных вида статических связей:
· ассоциации (например, клиент может сделать заказ);
· подтипы (частный клиент является разновидностью клиента).
На диаграммах классов изображаются также атрибуты классов,
операции классов и ограничения, которые накладываются на связи между объектами.
На рис. 3.2 изображена типичная диаграмма классов.
Рис. 3.2.Диаграмма классов
Перед тем как приступить к описанию диаграмм классов, следует обратить внимание на один важный момент, связанный с характером использования этих диаграмм разработчиками. Этот момент обычно никак не документируется, однако оказывает существенное воздействие на способ интерпретации диаграмм и поэтому имеет важное отношению к тому, что описывается с помощью модели.
Построение диаграмм классов можно рассматривать в различных аспектах:
· концептуальный аспект — диаграммы классов отображают понятия изучаемой предметной области (моделируемой организации). Эти понятия, естественно, будут соответствовать реализующим их классам, однако такое прямое соответствие зачастую отсутствует. На самом деле концептуальная модель может иметь весьма слабое отношение или вообще не иметь никакого отношения к реализующему ее программному обеспечению, поэтому ее можно рассматривать как не зависимую от средств реализации (языка программирования);
· аспект спецификации — модель спускается на уровень ПО, но рассматриваются только интерфейсы, а не программная реализация классов (под интерфейсом здесь понимается набор операций класса, видимых извне);
· аспект реализации — модель действительно определяет реализацию классов ПО. Этот аспект наиболее важен для программистов.
Понимание аспекта имеет большое значение как для построения, так и для чтения диаграмм классов. К сожалению, различия между аспектами не столь отчетливы, и большинство разработчиков при построении диаграмм допускают их смешение.
При построении диаграммы необходимо выбрать единственный аспект. При чтении диаграммы следует выяснить, в соответствии с каким аспектом она строилась. Если нужно интерпретировать эту диаграмму правильным образом, то без такого знания не обойтись.
Точка зрения на диаграммы классов, не будучи собственно формальной частью UML, однако при построении и анализе моделей является крайне важной. Конструкции UML можно использовать с любой из трех точек зрения. Большинство опытных разработчиков-программистов предпочитают аспект реализации. С другой стороны, очевидно, что построение диаграмм классов на стадии формирования требований к ПО должно выполняться с концептуальной точки зрения.
3.4.2. АССОЦИАЦИИ
На рис. 3.2 изображена простая модель классов, связанная с обработкой заказов клиентов. Опишем каждый фрагмент модели и рассмотрим его возможную интерпретацию с различных точек зрения.
Ассоциации представляют собой связи между экземплярами классов (личность работает в компании, компания имеет ряд офисов).
С концептуальной точки зрения ассоциации представляют собой концептуальные связи между классами. На диаграмме показано, что Заказ должен поступить от единственного Клиента, а Клиент в течение некоторого времени может сделать несколько Заказов. Каждый из этих Заказов содержит несколько Строк заказа, каждая из которых соответствует единственному Продукту.
Каждая ассоциация обладает двумя ролями; каждая роль представляет собой направление ассоциации. Таким образом, ассоциация между Клиентом и Заказом содержит две роли: одна от Клиента к Заказу, другая - от Заказа к Клиенту.
Роль может быть явно поименована с помощью метки. Например, роль ассоциации в направлении от Заказа к Строкам заказа называется "позиции заказа". Если такая метка отсутствует, роли присваивается имя класса-цели — таким образом, роль ассоциации от Заказа к Клиенту может быть названа Клиент (термины "начало" (source) и "цель" (target) употребляются для обозначения классов, являющихся соответственно начальным и конечным для ассоциации).
Роль также обладает множественностью, которая показывает, сколько объектов может участвовать в данной связи. На рис. 3.2 символ "*" над ассоциацией между Клиентом и Заказом означает, что с одним Клиентом может быть связано много Заказов; символ "1" показывает, что любой Заказ может поступить только от одного Клиента.
В общем случае множественность указывает нижнюю и верхнюю границы количества объектов, которые могут участвовать в связи. Символ "*" в действительности выражает диапазон "ноль-бесконечность": Клиент может и не сделать ни одного Заказа, а может сделать неограниченное количество Заказов (теоретически). Единица означает диапазон "один-один": Заказ должен быть сделан одним и только одним Клиентом.
На практике наиболее распространенными вариантами множественности являются "1", "*" и "0..1" (либо ноль, либо единица). В общем случае может использоваться единственное число (например, 11 для количества игроков в команде), диапазон (например, 2..4 для игроков в карты) или дискретная комбинация из чисел и диапазонов (например, 2,4 для количества дверей в автомобиле).
Ассоциации в аспекте спецификации представляют собой ответственности классов.
На рис. 3.2 подразумевается, что существуют методы (один или более), связанные с Клиентом, с помощью которых можно узнать, какие заказы сделал данный Клиент. Аналогично в классе Заказ существуют методы, с помощью которых можно узнать, какой Клиент сделал данный Заказ и какие Позиции Заказа строки входят в Заказ.
Если допустить, что имеются стандартные соглашения по именованию методов запросов, то можно извлечь из диаграммы наименования этих методов. Например, можно принять соглашение, в соответствии с которым однозначные связи реализуются посредством метода, который возвращает связанный объект, а многозначные связи реализуются посредством перечисления (enumeration) или итератора, указывающего на совокупность связанных объектов.
Диаграмма классов (см. рис. 3.2) также предполагает, что существуют некоторые механизмы обновления связей. Например, должен существовать некоторый способ связи конкретного Заказа с конкретным Клиентом. Детали этого способа на диаграмме отсутствуют.
Если же модель отражает аспект реализации, можно исходить из предположения, что между связанными классами существуют указатели в обоих направлениях. Диаграмма может теперь сообщить, что Заказ содержит поле, представляющее собой совокупность указателей на Строки заказа, а также содержит указатель на Клиента.
Рассмотрим теперь рис. 3.3. В основном он совпадает с рис. 3.2, за исключением того, что к ассоциациям добавлены стрелки. Эти стрелки показывают направление навигации.
Рис. 3.3. Диаграмма классов с направлениями навигации
На модели спецификаций таким образом можно показать, что Заказ обязан ответить на вопрос, к какому Клиенту он относится, а у Клиента соответствующая ответственность отсутствует. Вместо симметричных ответственностей показываются только односторонние. На диаграмме реализации это может означать, что Заказ содержит указатель на Клиента, но Клиент не указывает на Заказ.
Как можно увидеть, направление навигации является важной частью диаграмм спецификации и реализации. На концептуальных же диаграммах, как правило, направления навигации отсутствуют. Они появляются по мере того, как аспект меняется в сторону спецификации и реализации.
Если навигация указана только в одном направлении, то такая ассоциация называется однонаправленной. У двунаправленной ассоциации навигация указана в обоих направлениях. В языке UML отсутствие стрелок у ассоциации трактуется следующим образом: направление навигации неизвестно, или ассоциация является двунаправленной. Для моделей спецификации и реализации предпочтительнее трактовать отсутствие стрелок как неопределенное направление навигации.
Двунаправленные ассоциации содержат дополнительное ограничение, которое заключается в следующем: две их роли являются инверсными (обратными) по отношению друг к другу. Это утверждение подобно понятию обратных функций в математике. По отношению к рис. 3.3 это означает, что каждая Строка заказа, связанная с некоторым Заказом, должна быть связана с конкретным Заказом-источником (в смысле направления навигации). Аналогично если взять какую-либо Строку заказа и взглянуть на Позиции Строки, соответствующие связанному с ними Заказу, то можно обнаружить Строку заказа — источник данной совокупности элементов. Указанное свойство остается справедливым для любой из трех точек зрения.
3.4.3. АТРИБУТЫ