А.М. Вендров - Объектно-ориентированный анализ и проектирование, страница 4

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

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

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

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

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

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

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

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

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

Множество людей отмечаетналичие серьезных трудностей, связанных, например, с освоениемобъектно-ориентированных методов, и, в первую очередь, сменупарадигмы. В некоторых случаях переход к объектноориентированнымметодампроисходитотносительнобезболезненно. В других случаях при работе с объектамиприходится сталкиваться с рядом препятствий, особенно в частимаксимального использования их потенциальных возможностей.Графические средства позволяют облегчить решение этойпроблемы.В процессе создания ПО, автоматизирующего деятельность некоторойорганизации, используются следующие виды моделей:• модели деятельности организации (или модели бизнес-процессов):o модели "AS-IS" ("как есть"), отражающие существующее намомент обследования положение дел в организации ипозволяющей понять, каким образом функционирует данная19организация, а также выявить узкие места и сформулироватьпредложения по улучшению ситуации;o модели "AS-TO-BE" ("как должно быть"), отражающиепредставление о новых процессах и технологиях работыорганизации.

Переход от модели "AS-IS" к модели "AS-TOBE"можетвыполнятьсядвумяспособами:1)совершенствованием существующих технологий на основеоценки их эффективности; 2) радикальным изменениемтехнологий и перепроектированием (реинжинирингом)бизнес-процессов.• модели проектируемого ПО, которые строятся на основе модели"AS-TO-BE", уточняются и детализируются до необходимогоуровня.Состав моделей, используемых в каждом конкретном проекте, истепень их детальности в общем случае (как для структурного, так и дляобъектно-ориентированного подхода) зависят от следующих факторов:• сложности проектируемой системы;• необходимой полноты ее описания;• знаний и навыков участников проекта;• времени, отведенного на проектирование.1.3. Основы объектно-ориентированного подхода к анализу ипроектированию ПОВ основе объектно-ориентированного подхода (ООП) лежитобъектная декомпозиция, при этом статическая структура системыописывается в терминах объектов и связей между ними, а поведениесистемы описывается в терминах обмена сообщениями между объектами.Каждый объект системы обладает своим собственным поведением,моделирующим поведение объекта реального мира.Проблемы, стимулировавшие развитие ООП:• необходимость повышения производительности разработки за счетмногократного (повторного) использования ПО;• необходимость упрощения сопровождения и модификацииразработанных систем (локализация вносимых изменений);• облегчение проектирования систем (за счет сокращениясемантического разрыва между структурой решаемых задач иструктурой ПО).Объектная модель является наиболее естественным способомпредставления реального мира.