2. Язык UML. Руководство пользователя. Буч_ Рамбо_ Якобсон (2-е издание) (2006) (1185732), страница 6
Текст из файла (страница 6)
Но стоит изменить модель, забыв о математическом анализе, и вы тут же получите легко интерпретируемыйрезультат. В данном случае речь идет о диаграммах Феймана, позволяющих графически представить чрезвычайно сложные проблемы.Рассмотрим еще одну область, где необходимо моделирование.24Зачем мы моделируемДопустим, вы проектируете здание и хотите знать, как оно будетсебя вести при сильном ветре.
Построив макет и испытав его в аэродинамической трубе, вы узнаете много интересного по этому поводу, хотя уменьшенная копия будет себя вести не так, как полноем математической модели даст вам дополнительную информациюи, возможно, позволит проработать больше различных сценариев,чем при работе с физическим макетом. Тщательно изучив поведение здания на этих моделях, вы будете гораздо больше увереныв том, что смоделированная система будет вести себя в реальныхусловиях так, как было задумано.Возвращаясь к проблеме создания программного обеспечения,можно сказать, что ваш взгляд на мир существенно зависит от выбираемой вами модели. Если вы смотрите на систему глазами разработчика баз данных, то основное внимание будете уделять моделям«сущность–связь», где поведение инкапсулировано в триггерах и хранимых процедурах.
Аналитик, использующий структурный подход,скорее всего, создал бы модель, в центре которой находятся алгоритмы и передача данных от одного процесса к другому. Результатомтруда разработчика, пользующегося объектноFориентированным методом, будет система, архитектура которой основана на множествеклассов и образцах взаимодействия, определяющих, как эти классыдействуют совместно. Любой из этих вариантов может оказатьсяподходящим для данного приложения и методики разработки, хотяопыт подсказывает, что объектноFориентированная точка зрения более эффективна при создании гибких архитектур, даже если системадолжна будет работать с большими базами данных или производитьсложные математические расчеты.
При этом надо учитывать, что различные точки зрения на мир приводят к созданию различных систем,со своими преимуществами и недостатками.Второй принцип формулируется так: каждая модель можетбыть представлена с различной степенью точности.При строительстве небоскреба может возникнуть необходимостьпоказать его с высоты птичьего полета, например, чтобы с проектоммогли ознакомиться инвесторы. В других случаях, наоборот, требуется детальное описание – допустим, чтобы показать какойFнибудьсложный изгиб трубы или необычный элемент конструкции.То же происходит и при моделировании программного обеспечения. Иногда простая и быстро созданная модель программногоинтерфейса – самый подходящий вариант.
В других случаях приходится работать на уровне битов (например, когда вы специфицируете межсистемные интерфейсы или боретесь с узкими местамив сети). В любом случае лучшей моделью будет та, которая позволяетвыбрать уровень детализации в зависимости от того, кто и с какойцелью на нее смотрит. Для аналитика или конечного пользователяПринципы моделирования25наибольший интерес представляет вопрос «что», а для разработчика –вопрос «как». В обоих случаях необходима возможность рассматривать систему на разных уровнях детализации в разное время.Третий принцип: лучшие модели – те, что ближе к реальности.Физическая модель здания, которая ведет себя не так, как изготовленная из реальных материалов, имеет лишь ограниченнуюценность.
Математическая модель самолета, для которой предполагаются идеальные условия работы и безупречная сборка, можети не обладать некоторыми характеристиками, присущими настоящему изделию, что в ряде случаев приводит к фатальным последствиям. Лучше всего, если ваши модели будут во всем соотноситьсяс реальностью, а там, где связь ослабевает, должно быть понятно,в чем заключается различие и что из этого следует. Поскольку модель всегда упрощает реальность, задача в том, чтобы это упрощение не повлекло за собой какиеFто существенные потери.Возвращаясь к программному обеспечению, можно сказать, что«ахиллесова пята» структурного анализа – несоответствие принятой в нем модели и модели системного проекта.
Если этот разрывне будет устранен, то поведение созданной системы с течением времени будет все больше и больше отличаться от задуманного. ПриобъектноFориентированном подходе можно объединить все почтинезависимые представления системы в единое семантическое целое.Четвертый принцип заключается в том, что нельзя ограничиваться созданием только одной модели.
Наилучший подход при разработке любой нетривиальной системы – использовать совокупность нескольких моделей, почти независимых друг от друга.Если вы конструируете здание, никакой отдельный комплектчертежей не поможет вам прояснить все детали до конца. Понадобятся как минимум поэтажные планы, виды в разрезе, схемы электропроводки, центрального отопления и водопровода.В формулировке четвертого принципа ключевое определение –«почти независимые». Оно означает, что модели могут создаватьсяи изучаться по отдельности, но вместе с тем остаются взаимосвязанными.
Например, можно изучать только схемы электропроводки проектируемого здания, но при этом наложить их на поэтажныйплан пола и даже рассмотреть совместно с прокладкой труб на схеме водоснабжения.Такой подход верен и в объектноFориентированных программных системах.
Для понимания архитектуры подобной системытребуется несколько взаимодополняющих представлений: представление с точки зрения вариантов использования (чтобы выявитьтребования к системе), с точки зрения проектирования (чтобы построить словарь предметной области и области решения), с точкизрения взаимодействий (чтобы смоделировать взаимодействия26Пять представленийархитектуры обсуждаютсяв главе 2.Зачем мы моделируеммежду частями системы, системой в целом и средой ее функционирования), с точки зрения реализации (позволяющее рассмотретьфизическую реализацию системы) и с точки зрения размещения(помогающее сосредоточиться на вопросах системного проектирования).
Каждое из перечисленных представлений имеет множествоструктурных и поведенческих аспектов, которые в своей совокупности составляют детальный чертеж программной системы.В зависимости от природы системы некоторые модели могутбыть важнее других. Так, при создании систем для обработки больших объемов данных более важны статические модели. В приложениях, ориентированных на интерактивную работу пользователя,на первый план выходят статические и динамические представления вариантов использования. В системах реального времени наиболее существенными будут представления с точки зрения динамических процессов. Наконец, в распределенных системах, такихкак WebFприложения, основное внимание нужно уделять моделямреализации и размещения.Объектное моделированиеИнженерыFстроители создают множество видов моделей.
Чащевсего это структурные модели, позволяющие визуализироватьи специфицировать части системы и то, как они соотносятся другс другом. Иногда создаются также динамические модели – например, если требуется изучить поведение конструкции при землетрясении. Эти два типа различаются по организации и по тому, на чтов первую очередь обращается внимание при проектировании.При разработке программного обеспечения тоже существуетнесколько подходов к моделированию. Важнейшие из них – алгоритмический и объектноFориентированный.Алгоритмический метод представляет традиционный подходк созданию программного обеспечения.
Основным строительнымблоком является процедура или функция, а внимание уделяетсяпрежде всего вопросам передачи управления и вопросам декомпозиции больших алгоритмов на меньшие. Ничего плохого в этом нет,если не считать того, что системы не слишком легко адаптируются.При изменении требований или увеличении размера приложения(что происходит нередко) сопровождать их становится сложнее.Наиболее современный подход к разработке программного обеспечения – объектноFориентированный. Здесь в качестве основногостроительного блока выступает объект или класс. В самом общемсмысле объект – это сущность, обычно извлекаемая из словаряпредметной области или решения, а класс – описание множества однотипных объектов. Каждый объект обладает идентичностьюОбъектное моделирование27(его можно поименовать или какFто поFдругому отличить от прочихобъектов), состоянием (обычно с объектом связаны некоторые данные) и поведением (с ним можно чтоFто делать или он сам можетчтоFто делать с другими объектами).В качестве примера давайте рассмотрим простую трехуровневую архитектуру биллинговой системы, состоящую из интерфейсапользователя, бизнесFлогики (промежуточного слоя) и базы данных.
Пользовательский интерфейс состоит из конкретных объектов: кнопок, меню и диалоговых окон. База данных также состоитиз конкретных объектов, а именно таблиц, представляющих сущности предметной области: клиентов, продукты и заказы. Программы промежуточного слоя включают такие объекты, как транзакциии бизнесFправила, а кроме того, более абстрактные представлениясущностей предметной области (клиентов, продуктов и заказов).ОбъектноFориентированный подход к разработке программного обеспечения сейчас наиболее широко используется потому, чтоон продемонстрировал свою полезность при построении системлюбого размера и сложности в самых разных областях.
Кроме того,большинство современных языков программирования, инструментальных средств и операционных систем являются в той или иноймере объектноFориентированными, а это дает веские основаниясудить о мире в терминах объектов. ОбъектноFориентированныеметоды разработки легли в основу идеологии сборки систем из отдельных компонентов (в качестве примеров можно назвать такиетехнологии, как J2EE и .NET).Если вы приняли объектноFориентированный взгляд на мир,вам придется ответить на ряд вопросов. Какая структура должнабыть у хорошей объектноFориентированной архитектуры? Какиеартефакты должны быть созданы в процессе работы над проектом?Компоненты Кто должен создавать их? И наконец, как оценить результат?Визуализация, специфицирование, конструирование и докуобсуждаютментирование объектноFориентированных систем – это и есть нася в главе 2.значение языка UML.Обзор UMLГлава 2.
Введение в UMLВ этой главе:Обзор UMLТри шага к пониманию UMLАрхитектура программного обеспеченияПроцесс разработки программного обеспеченияИтак, унифицированный язык моделирования (Unified ModelingLanguage – UML) – это стандартный инструмент для разработки«чертежей» программного обеспечения. Его можно использоватьдля визуализации, спецификации, конструирования и документирования артефактов программных систем.UML подходит для моделирования любых систем – от информационных систем масштаба предприятия до распределенных Webприложений и даже встроенных систем реального времени. Этоочень выразительный язык, предназначенный для представлениясистемы со всех точек зрения, относящихся к ее разработке и внедрению. Несмотря на богатство выразительных средств, UML простдля понимания и применения.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
