Чтение онлайн

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

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

Примечание.

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

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

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

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

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

Использование в работе такого словаря весьма полезно и эффективно при решении практически любых задач.

Диаграммы сущность-связь.

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

Метод Аббота.

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

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

CRC-карточки.

Аббревиатура CRC означает Class-Responsibilities-Collaborators (класс-ответственность-участники). CRC-карточки впервые предложили Кент Бек (Kent Beck) и Уорд Каннингхэм (Ward Cunningham) для обучения объектно-ориентированному программированию.

CRC-карточки представляют собой обычные картонные карточки размером 10 на 15 сантиметров, на которых карандашом сверху пишется название класса, слева – за что он отвечает, справа – с какими классами он взаимодействует (сотрудничает, обменивается сообщениями).

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

Примечание.

Возможна ситуация, когда одни и те же сообщения будут передаваться между разными классами. Можно выделить такие сообщения в отдельный класс для удобства отладки и внесения изменений. Так поступают, например, при обращениях к базе данных с помощью SQL-запросов, выделяя транзакции в отдельный класс.

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

Метод Буча.

Метод Буча стал основой UML. Предложенная Бучем графическая нотация достаточно распространена и наряду с UML используется в системах автоматизации процесса разработки программного обеспечения, в частности, в системе Rational Rose.

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

Примечание.

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

Структура UML

В структуре универсального языка моделирования выделяют две основные составляющие:

• метамодель;

• правила построения диаграмм.

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

Примечание.

Описание метамодели приводится на естественном человеческом языке с применением конструкций самого языка UML, что однако не создает трудностей при ее изучении.

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

Основной интерес для проектировщика представляют правила построения UML-диаграмм, основными разновидностями которых являются диаграммы:

Qпрецедентов, или вариантов использования (use case diagram);

Qклассов (class diagram);

Qсостояний (statechart diagram);

Qактивности, или деятельности (activity diagram);

• взаимодействия (interaction diagrams), к которым относятся диаграммы последовательности (sequence diagram) и кооперации, или сотрудничества (collaboration diagram);

• компонентов (component diagram);

• развертывания (deployment diagram).

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

Примечание.

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