Общие принципы проектирования

СИСТЕМ

 

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

· количество связей между отдельными подсистемами должно быть минимальным (принцип «слабой связанности» — Low Coupling);

· связность отдельных частей внутри каждой подсистемы должна быть максимальной (принцип «сильного сцепления» — High Cohesion).

Более подробно эти принципы будут рассмотрены в рамках объектно-ориентированного анализа (подразд. 4.3.2).

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

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

· каждая подсистема должна иметь четко определенный интерфейс с другими подсистемами.

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

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

В 1970—1980 годах при разработке ПО достаточно широко применялись структурные методы, предоставляющие в распоряжение разработчиков строгие формализованные методы описания проектных решений — спецификаций ПО (в настоящее время такое же распространение получают объектно-ориентированные методы). Эти методы основаны на использовании наглядных графических моделей: для описания архитектуры ПО с различных точек зрения (как статической структуры, так и динамики поведения системы) используются схемы и диаграммы. Наглядность и строгость средств структурного и объектно-ориентированного анализа позволяет разработчикам и будущим пользователям системы с самого начала неформально участвовать в ее создании, обсуждать и закреплять понимание основных технических решений. Однако широкое применение этих методов и следование их рекомендациям при разработке конкретных систем ПО сдерживалось отсутствием адекватных инструментальных средств, поскольку при неавтоматизированной (ручной) разработке все их преимущества практически сведены к нулю. Действительно, вручную очень трудно разработать и графически представить строгие формальные спецификации системы, проверить их на полноту и непротиворечивость и тем более изменить. Если все же удается создать строгую систему проектных документов, то ее переработка при появлении серьезных изменений практически неосуществима. Ручная разработка обычно порождала следующие проблемы:

· неадекватная спецификация требований;

· неспособность обнаруживать ошибки в проектных решени­ях;

· низкое качество документации, снижающее эксплуатаци­онные характеристики;

· затяжной цикл и неудовлетворительные результаты тести­рования.

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

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

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

· подготовка аналитиков и программистов, восприимчивых к концепциям модульного и структурного программирования;

· широкое внедрение и постоянный рост производительности компьютеров, позволившие использовать эффективные графические средства и автоматизировать большинство этапов проектирования;

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

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

 

2.2.

ВИЗУАЛЬНОЕ МОДЕЛИРОВАНИЕ

 

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

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

Модель должна давать полное, точное и адекватное описание системы, имеющее конкретное назначение. Это назначение, называемое целью модели, вытекает из формального определения модели:

М есть модель системы S, если М может быть использована для получения ответов на вопросы относительно S с точностью А.

Таким образом, целью модели является получение ответов на некоторую совокупность вопросов. Эти вопросы неявно присутствуют (подразумеваются) в процессе анализа и, следовательно, они руководят созданием модели и направляют его. Это означает, что сама модель должна будет дать ответы на эти вопросы с заданной степенью точности. Если модель отвечает не на все вопросы или ее ответы недостаточно точны, то говорят, что модель не достигла своей цели.

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

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

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

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

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

· совокупность структурных элементов системы и связей между ними;

· поведение элементов системы в процессе их взаимодействия;

· иерархию подсистем, объединяющих структурные элементы;

· архитектурный стиль (используемые методы и средства описания архитектуры, а также архитектурные образцы).

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

· планы этажей;

· вертикальные проекции;

· планы монтажа кабельной проводки;

· чертежи водопроводов, системы центрального отопления и вентиляции;

· вид здания на фоне местности (эскизы).

Архитектура ПО также предусматривает различные представления, служащие разным целям:

· представлению функциональных возможностей системы;

· отображению логической организации системы;

· описанию физической структуры программных компонентов в среде реализации;

· отображению структуры потоков управления и аспектов параллельной работы;

· описанию физического размещения программных компонентов на базовой платформе.

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

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

Разработка модели архитектуры системы ПО промышленного характера на стадии, предшествующей ее реализации или обновлению, в такой же мере необходима, как и наличие проекта для строительства большого здания. Это утверждение справедливо как в случае разработки новой системы, так и при адаптации типовых продуктов класса R/3 или BAAN, в составе которых также имеются собственные средства моделирования. Хорошие модели являются основой взаимодействия участников проекта и гарантируют корректность архитектуры. Поскольку сложность систем повышается, важно располагать хорошими методами моделирования. Хотя имеется много других факторов, от которых зависит успех проекта, но наличие строгого стандарта языка моделирования является весьма существенным.

Язык моделирования включает:

· элементы модели — фундаментальные концепции моделирования и их семантику;

· нотацию (систему обозначений) — визуальное представление элементов моделирования;

· руководство по использованию — правила применения элементов в рамках построения тех или иных типов моделей ПО.

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

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

· общение с экспертами организации. Графические модели образуют внешнее представление системы и объясняют, что эта система будет делать;

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

В процессе создания ПО, автоматизирующего деятельность некоторой организации, используются следующие виды моделей:

· модели деятельности организации (или модели бизнес-процессов):

модели «AS-IS» («как есть»), отражающие существующее на момент обследования положение дел в организации и позволяющие понять, каким образом функционирует данная организация, а также выявить узкие места и сформулировать предложения по улучшению ситуации;

модели «AS-TO-BE» («как должно быть»), отражающие представление о новых процессах и технологиях работы организации. Переход от модели «AS-IS» к модели «AS-TO-BE» может выполняться двумя способами: 1) совершенствованием существующих технологий на основе оценки их эффективности; 2) радикальным изменением технологий и перепроектированием (реинжинирингом) бизнес-процессов.

· модели проектируемого ПО, которые строятся на основе модели «AS-TO-BE», уточняются и детализируются до необходимого уровня.

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

· сложности проектируемой системы;

· необходимой полноты ее описания;

· знаний и навыков участников проекта;

· времени, отведенного на проектирование.

2.3.