Учебное пособие Чебоксары 2013
Скачать 2.76 Mb.
|
| Глава III. Проектирование программ Начала унифицированного языка моделирования UML Прежде чем начинать разработку хоть сколько-нибудь сложных приложений, нужно хорошо проработать план действий. Если у вас нет тщательно продуманного сценария, команда разработчиков напрасно потратит время и деньги и, что хуже всего, конечный результат может совершенно не отвечать предъявляемым требованиям. Тогда применяется унифицированный язык моделирования UML (Unified Modeling Language). Технология UML, одобренная консорциумом Object Management Group, является мощным средством описания бизнес-процессов и представления их в той форме, которая устраивает как разработчиков, так и пользователей. Язык UML предлагает набор инструментальных средств, позволяющих проводить всесторонний анализ сложных проектов как с технической точки зрения, так и с точки зрения потребностей бизнеса. Данный язык упрощает процесс проектирования, снижает его стоимость и повышает эффективность. Концепция UML позволяет разработчикам определять методы технически сложных приложений, которые будут выполняться в многоуровневой распределенной среде. Достоинства: стандартная методология; интуитивно понятные обозначения, мощные описательные средства языка; автоматическая генерация кода [12]. Модель – упрощенное представление реальности. С точки зрения программирования модель – это чертеж системы. Моделирование необходимо для решения следующих задач:
Перечислим принципы моделирования.
Унифицированный язык моделирования является графическим языком для визуализации, специфицирования, конструирования и документирования систем, в которых большая роль принадлежит программному обеспечению. С помощью UML можно разработать детальный план создаваемой системы, отображающий не только концептуальные элементы, такие, как системные функции и бизнес-процессы, но и конкретные особенности реализации, в том числе классы, написанные на специальных языках программирования, схемы баз данных и программные компоненты многократного использования [2]. Язык UML состоит из словаря и правил, позволяющих комбинировать входящие в него слова и получать осмысленные конструкции. Язык моделирования, подобный UML, является стандартным средством для составления чертежей программною обеспечения. Моделирование необходимо для понимания системы, при этом единственной модели никогда не бывает достаточно. Напротив, для понимания любой нетривиальной системы приходится разрабатывать большое количество взаимосвязанных моделей. В применении к программным системам это означает, что необходим язык, с помощью которого можно с различных точек зрения описать представления архитектуры системы на протяжении цикла ее разработки. Проблемы, решаемые с помощью UML.
Строительные блоки UML:
Сущности – это абстракции, являющиеся основными элементами модели. Сущности бывают четырех типов: структурные, поведенческие, группирующие и аннотационные. Различают следующие структурные сущности: Класс (Class) – это описание совокупности объектов с общими атрибутами, операциями, отношениями и семантикой. Графически класс изображается в виде прямоугольника, в котором обычно записаны его имя, атрибуты и операции (рис. 3.1).
Рис.3.1. Графическая итерация класса Интерфейс (Interface) – это совокупность операций, которые определяют сервис (набор услуг), предоставляемый классом или компонентом. Таким образом, интерфейс описывает видимое извне поведение элемента. Графически интерфейс изображается в виде круга, под которым пишется его имя (рис. 3.2).  ISpelling Рис. 3.2. Графическая интерпретация класса Кооперация (Collaboration) определяет взаимодействие: она представляет собой совокупность ролей и других элементов (в частности, классов), которые, работая совместно, производят некоторый общий эффект. Изображается в виде эллипса, ограниченного пунктирной линией, а в центре – имя. Прецедент (Use case) – это описание последовательности выполняемых системой действий, которая производит наблюдаемый результат, значимый для какого-то определенного актера, (Actor). Изображается в виде эллипса, ограниченного сплошной линией, а в центре – имя (рис. 3.3).  Цепочка ответственности Разместить заказ Рис. 3.3. Графическая интерпретация прецедента Активным классом (Active class) называется класс, объекты которого вовлечены в один или несколько процессов, или нитей (Threads), и поэтому могут инициировать управляющее воздействие. Активный класс во всем подобен обычному классу, за исключением того, что его объекты представляют собой элементы, деятельность которых осуществляется одновременно с деятельностью других элементов. Графически активный класс изображается так же, как простой класс, но ограничивающий прямоугольник рисуется жирной линией, обычно включает имя, атрибуты и операции. Компонент (Component) – это физическая заменяемая часть системы, которая соответствует некоторому набору интерфейсов и обеспечивает его реализацию. Компонент, как правило, представляет собой физическую упаковку логических элементов, таких как классы, интерфейсы и кооперации. Графически компонент изображается в виде прямоугольника с вкладками, содержащего обычно только имя. Узел (Node) – это элемент реальной (физической) системы, который существует во время функционирования программного комплекса и представляет собой вычислительный ресурс, обычно обладающий, как минимум, некоторым объемом памяти, а часто еще и способностью обработки. Совокупность компонентов может размещаться в узле, а также мигрировать с одного узла на другой. Графически узел изображается в виде куба, обычно содержащего только имя (рис. 3.4). Перечислим теперь поведенческие сущности. Взаимодействие (Interaction) – это поведение, суть которого заключается в обмене сообщениями (Messages) между объектами в рамках конкретного контекста для достижения определенной цели. С помощью взаимодействия можно описать как отдельную операцию, так и поведение совокупности объектов. Взаимодействие предполагает ряд других элементов, таких, как сообщения, последовательности действий (поведение, инициированное сообщением) и связи (между объектами). Графически сообщения изображаются в виде стрелки, над которой почти всегда пишется имя соответствующей операции.  Сервер Рис. 3.4. Графическая интерпретация узла Автомат (State machine) – это алгоритм поведения, определяющий последовательность состояний, через которые объект или взаимодействие проходят на протяжении своего жизненного цикла в ответ на различные события, а также реакции на эти события. С помощью автомата можно описать поведение отдельного класса или кооперации классов. С автоматом связан ряд других элементов: состояния, переходы (из одного состояния в другое), события (сущности, инициирующие переходы) и виды действий (реакция на переход). Графически состояние изображается в виде прямоугольника с закругленными углами (рис. 3.5).  Рис. 3.5. Графическая интерпретация класса Классы. Класс изображается в виде прямоугольника, поделенного на несколько частей. В самой крупной абстракции указывается только имя класса (рис. 3.6). Custome Rectangle Рис. 3.6. Графическая интерпретация абстракции При более детальном описании класса нужно указать атрибуты и операции, выполняемые классом (рис. 3.7).
Рис. 3.5. Летальное описание класса Существуют также обязанности класса – это то, что должен делать класс, для чего его создают. Если в проект входит нечто большее, нежели пара несложных классов, следует позаботиться о сбалансированном распределении обязанностей. Это значит, что надо избегать слишком больших или, наоборот, чересчур маленьких классов. Каждый класс должен хорошо делать что-то одно. Если абстрактные классы будут слишком велики, то модель будет трудно модифицировать и повторно использовать. Если они слишком малы, то придется иметь дело с таким большим количеством абстракций, что ни понять, ни управлять ими будет невозможно. Язык UML способен помочь в визуализации и специфицировании баланса обязанностей [2]. Моделирование распределения обязанностей в системе включает следующие этапы:
Непрограммные сущности Моделируемые сущности могут не иметь аналогов в программном обеспечении. Например, частью рабочего процесса в модели предприятия розничной торговли могут быть люди, отправляющие накладные, и роботы, которые автоматически упаковывают заказанные товары для доставки со склада к месту назначения. В вашем приложении совсем не обязательно окажутся компоненты для представления этих сущностей [21]. Отношением называется связь между элементами. В объектно-ориентированном моделировании тремя самыми важными отношениями являются зависимости, обобщения и ассоциации. Графически отношение представлено линией, тип которой зависит oт вида отношения. Зависимостью (Dependency) называют отношение использования, согласно которому изменение в спецификации одного элемента (например, класса Event) может повлиять на другой элемент, его использующий (в данном случае -– класс Window), причем обратное не обязательно. Графически зависимость изображается пунктирной линией со стрелкой, направленной от данного элемента на тот, от которого он зависит. Используйте зависимости, когда хотите показать, что один элемент использует другой. Чаще всего зависимости применяются при работе с классами, чтобы отразить в сигнатуре операции тот факт, что один I класс использует другой в качестве аргумента. Обобщение (Generalization) – это отношение между общей сущностью (суперклассом, или родителем) и ее конкретным воплощением (субклассом, или потомком). Обобщения иногда называют отношениями типа «является», имея в виду, что одна сущность (например, класс BayWindow) является частным выражением другой, более общей (например, класса Window). Другими словами, потомок может быть подставлен вместо родителя. При этом он наследует свойства родителя, в частности, его атрибуты и операции. Часто, хотя и не всегда, у потомков есть свои собственные атрибуты и операции, помимо тех, что существуют у родителя. Операция потомка с той же сигнатурой, что и у родителя, замещает операцию родителя; это свойство называют полиморфизмом (Polymorphism). Графически отношение обобщения изображается в виде линии с большой незакрашенной стрелкой, направленной на родителя. Применяйте обобщения, когда хотите показать отношения типа «родитель/потомок» (рис. 3.6).  Рис. 3.6. Обобщение Ассоциацией (Association) называется структурное отношение, показывающее, что объекты одного типа неким образом связаны с объектами другого типа. Если между двумя классами определена ассоциация, то можно перемещаться от объектов одного класса к объектам другого. Вполне допустимы случаи, когда оба конца ассоциации относятся к одному и тому же классу. Ассоциация, связывающая дна класса, называется бинарной. Можно, хотя это редко бывает необходимым, создавать ассоциации, связывающие сразу несколько классов; они называются парными. Графически ассоциация изображается в виде линии, соединяющей класс сам с собой или с другими классами. Используйте ассоциации, когда хотите показать структурные отношения. Помимо описанной базовой формы существуют четыре наполнения, применимых к ассоциациям. Имя. Ассоциации может быть присвоено имя, описывающий природу отношения. Для того чтобы избежать возможных двусмысленностей и понимании имени, достаточно с помощью черною треугольника указать направление, в котором оно должно читаться. Роль. Класс, участвующий в ассоциации, играет в ней некоторую роль. По существу, это «лицо», которым класс, находящийся на одной стороне ассоциации, обращен к классу с другой ее стороны. Вы можете явно обозначить роль, которую класс играет в ассоциации. Кратность. Ассоциации отражают структурные отношения между объектами. Часто при моделировании бывает важно указать, сколько объектов может быть связано посредством одного экземпляра ассоциации. Это число называется кратностью (Multiplicity) роли ассоциации и записывается как выражение, значением которого является диапазон значений. Каждому объекту на одном конце ассоциации должно соответствовать такое же количество объектов на другом конце. Кратность можно задать равной единице (I), можно указать диапазон: «ноль или единица (0..I). Разрешается также указывать определенное число (например, 3). Агрегирование. Простая ассоциация между двумя классами отражает структурное отношение между равноправными сущностями, когда оба класса находятся на одном концептуальном уровне и ни один не является более важным, чем другой. Но иногда приходится моделировать отношение типа «часть/целое», при котором один из классов имеет более высокий ранг (целое) и состоит из нескольких меньших по рангу (частей). Отношение такого типа называют агрегированием; оно причислено к отношениям типа «имеет» (с учетом того, что объект-целое имеет несколько объектов-частей). Правила UML позволяют определить [2]:
Различают хорошо оформленные и не хорошо оформленные модели. Ко второму типу относятся модели:
Диаграммы UML Диаграмма в UML – это графическое представление набора элементов, изображаемое чаше всего в виде связного графа с вершинами (сущностями) и ребрами (отношениями). Диаграммы рисуют для визуализации системы с разных точек зрения. Диаграмма – в некотором смысле одна из проекций системы. Как правило, за исключением наиболее тривиальных случаев, диаграммы предлагалают свернутое представление элементов, из которых составлена система. Один и тот же элемент может присутствовать во всех диаграммах или только в нескольких (самый распространенный вариант) или не присутствовать ни в одной (очень редко). Теоретически диаграммы могут содержать любые комбинации сущностей и отношений [2]. Таким образом, в UML выделяют девять типов диаграмм:
В процессе моделирования человек упрощает реальное, чтобы лучше понять проектируемую систему. Используя UML, можно строить модели из базовых блоков, таких как классы, интерфейсы, кооперации, компоненты, узлы, зависимости, обобщения и ассоциации. Диаграммы позволяют обозревать эти строительные блоки в удобной для понимания форме При разработке программ необходимо руководствоваться следующими правилами:
Хорошо структурированная диаграмма обладает следующей функциональностью:
Диаграммы классов С помощью диаграммы классов показывают классы, интерфейсы, объекты и кооперации, а также их отношения. При моделировании объектно-ориентированных систем чаще всего используют этот тип диаграмм. Диаграммы классов соответствуют статическому виду системы с точки зрения проектирования Диаграммы классов, которые включают активные классы, соответствуют статическому виду системы с точки зрения процессов. Диаграммы классов обычно содержат следующие сущности:
Диаграммы объектов В языке UML статические аспекты строительных блоков системы визуализируют с помощью диаграмм классов. Диаграммы взаимодействия позволяют увидеть динамические аспекты системы, включая экземпляры этих строительных блоков, и сообщения, которыми они обмениваются. Диаграмма объектов содержит множество экземпляров сущностей, представленных на диаграмме классов. Таким образом, диаграммы объектов выражают статическую составляющую взаимодействия и состоят из сотрудничающих объектов, однако сообщения на них не показаны. Диаграмма объектов отражает состояние системы и фиксированный момент времени [2]. На диаграмме объектов представлены объекты и отношения между ними. Они являются статическими «фотографиями» экземпляров сущностей, показанных на диаграммах классов. Диаграммы объектов, как и диаграммы классов, относятся к статическому виду системы с точки зрения проектирования или процессов, но с расчетом на настоящую или макетную реализацию. Диаграммы прецедентов На диаграмме прецедентов представлены прецеденты и актеры (частный случай классов), а также отношения между ними. Диаграммы прецедентов относятся к статическому виду системы с точки зрения прецедентов использования. Они особенно важны при организации и моделировании поведения системы [2]. Диаграммы прецедентов представляют собой один из пяти типов диаграмм, применяемых в UML для моделирования динамических аспектов системы, и играют основную роль в моделировании поведения системы, подсистемы или класса. Каждая такая диаграмма показывает множество прецедентов, актеров и отношения между ними. Диаграммы прецедентов применяются для моделирования вида системы с точки зрения прецедентов (или вариантов использования). Чаще всего это предполагает моделирование контекста системы, подсистемы или класса либо моделирование требований, предъявляемых к поведению указанных элементов. Диаграммы прецедентов имеют большое значение для визуализации, специфицирования и документирования поведения элемента. Они облегчают понимание систем, подсистем или классов, представляя взгляд извне на то, как данные элементы могут быть использованы в соответствующем контексте. Кроме того, такие диаграммы важны для тестирования исполняемых систем в процессе прямого проектирования и для понимания их внутреннего устройства при обратном проектировании. Предположим, что вы получили по почте загадочное устройство, с одной стороны которого находятся несколько кнопок и маленький жидкокристаллический дисплей. Помимо этого в нем нет ничего примечательного и нет даже намека на то; как его использовать. Можно, конечно, использовать метод проб и ошибок: произвольно нажимать на кнопки и смотреть, что получится, но таким путем на изучение устройства вам придется потратить много времени. Программные системы часто выглядят столь же непривычно. Вам как пользователю могут передать некоторое приложение и посоветовать поработать с ним. Если приложение следует принятым соглашениям используемой вами операционной системы, то, может быть, после нескольких попыток вы добьетесь каких-то полезных результатов, но понять более сложные и тонкие аспекты поведения программы вам никогда не удастся. Если вы разработчик, то вам могут передать на сопровождение унаследованное приложение или набор компонентов и сказать, что их надо применить в работе. Вряд ли вы сумеете постичь, как нужно с ними обращаться, пока не сформируете концептуальную модель их работы. В языке UML диаграммы прецедентов как раз и позволяют визуализировать поведение системы, подсистемы или класса, чтобы пользователи могли понять, как их использовать, а разработчики – реализовать соответствующий элемент. Диаграммы взаимодействий Диаграммы последовательностей и кооперации (и те и другие называются диаграммами взаимодействий) относятся к числу пяти видов диаграмм, применяемых в UML для моделирования динамических аспектов. На диаграммах взаимодействий показывают связи, включающие множество объектов и отношений между ними, в том числе сообщения, которыми объекты обмениваются. При этом диаграмма последовательностей акцентирует внимание на временной упорядоченности сообщений, а диаграмма кооперации – на структурной организации посылающих и принимающих сообщения объектов [4]. Диаграммы взаимодействий используются для моделирования динамических аспектов системы. Сюда входит моделирование конкретных и прототипических экземпляров классов, интерфейсов, компонентов и узлов, а также сообщений, которыми они обмениваются, – и все это в контексте сценария, иллюстрирующего данное поведение. Диаграммы взаимодействий могут существовать автономно и служить для визуализации, специфицирования, конструирования и документирования динамики конкретного сообщества объектов, а могут использоваться для моделирования отдельного потока управления в составе прецедента. Диаграммы взаимодействий важны не только для моделирования динамических аспектов системы, но и для создания исполняемых систем посредством прямого и обратного проектирования. Так, когда человек смотрит фильм в кинотеатре или по телевизору, восприятие его обманывает. На самом деле он видит не непрерывный процесс, как в жизни, а последовательность статичных изображений, меняющихся так быстро, что создастся иллюзия движения. При планировании съемок фильма режиссеры и аниматоры используют ту же технику, но с меньшим разрешением. Выделяя основные кадры, они строят модель сцены, уровень детализации которой достаточен для того, чтобы определить роли всех участников съемочной команды. Фактически создание сценария – это ключевой момент кинематографического процесса, поскольку он помогает визуализировать, специфицировать, конструировать и документировать фильм. При моделировании программной системы возникает похожая проблема: как лучше смоделировать ее динамические аспекты. Вообразите на минуту, что вы способны визуализировать работающую систему. Если бы вы подключили к ней интерактивный отладчик, то могли бы сосредоточить внимание на любом участке памяти и наблюдать, как он изменяется. Можно было бы даже наблюдать за работой нескольких интересующих вас объектов. Вы увидели бы, как с течением времени объекты создаются, изменяют значения атрибутов и уничтожаются. Однако ценность такой визуализации будет весьма ограничена, особенно если речь идет о распределенной системе с несколькими параллельными потоками управления. Это напоминает попытку понять кровеносную систему человека, изучая кровоток через одно из сечений его артерии. В данном случае лучше разработать несколько сценариев, описывающих взаимодействие определенных объектов и сообщения, которыми они обмениваются. В UML это достигается с помощью диаграмм взаимодействий, которые описывают взаимодействия, состоящие из множества, объектов и отношений между ними, включая сообщения, которыми они обмениваются. Диаграммой последовательностей (Sequence diagram) начинается диаграмма взаимодействий, акцентирующая внимание на временной упорядоченности сообщений. Графически такая диаграмма представляет собой таблицу, объекты в которой располагаются вдоль оси X, а сообщения в порядке возрастания времени – вдоль оси Y. Диаграммой кооперации (Collaboration diagram) называется диаграмма взаимодействий, основное внимание в которой уделяется структурной организации объектов, принимающих и отправляющих сообщения. Графически такая диаграмма представляет собой граф из вершин и ребер. Как правило, диаграммы взаимодействий содержат:
Диаграммы деятельности Диаграммы деятельности – это один из пяти видов диаграмм, применяемых в UML для моделирования динамических аспектов поведения системы. Диаграмма деятельности – это, по существу, блок-схема, которая показывает, как поток управления переходит от одной деятельности к другой [2]. Диаграммы деятельности можно использовать для моделирования динамических аспектов поведения системы. Как правило, они применяются, чтобы промоделировать последовательные (а иногда и параллельные) шаги вычислительного процесса. С помощью диаграмм деятельности можно также моделировать жизнь объекта, когда он переходит из одного состояния в другое в разных точках потока управления. Диаграммы деятельности могут использоваться самостоятельно для визуализации, специфицирования, конструирования и документирования динамики совокупности объектов, но они пригодны также и для моделирования потока управления при выполнении некоторой операции. Если в диаграммах взаимодействий акцент делается на переходах потока управления от объекта к объекту, то диаграммы деятельности описывают переходы от одной деятельности к другой. Деятельность (Activity) – это некоторый относительно продолжительный этап выполнения в автомате. В конечном итоге деятельность сводится к некоторому действию, которое составлено из атомарных вычислений, приводящих к изменению состояния системы или возврату значения. Диаграммы деятельности важны не только для моделирования динамических аспектов поведения системы, но и для построения выполняемых систем посредством прямого и обратного проектирования. Динамику поведения можно моделировать с помощью диаграмм деятельности, в которых внимание сосредоточено прежде всего на содержании деятельности, в которой принимают участие объекты. Диаграмму деятельности можно представить как вывернутую наизнанку диаграмму взаимодействий. Диаграмма взаимодействий – это взгляд на объекты, которые передают друг другу сообщения, а диаграмма деятельности – взгляд на операции, которые передаются от одного объекта другому. Диаграмма деятельности (Activity diagram) показывает поток переходов от одной деятельности к другой. Деятельность (Activity) – это продолжающийся во времени неатомарный шаг вычислений в автомате; в конечном счете деятельность приводит к выполнению некоего действия, составленного из выполняемых атомарных вычислений, каждое из которых либо изменяет состояние системы, либо возвращает какое-то значение. Действие может заключаться в вызове другой операции, посылке сигнала, создании или уничтожении объекта либо в простом вычислении, например, значения выражения. Графически диаграмма деятельности представлена в виде графа, имеющего вершины и ребра и в общем случае состоит:
Диаграммы состояний Диаграммы состояний – это один из пяти видов диаграмм в языке UML, используемых для моделирования динамических аспектов. Ее частной разновидностью является диаграмма деятельности, в которой все или большая часть состояний – это состояния деятельности, а вес или большая часть переходов инициируются в результате завершения деятельности в исходном состоянии. Таким образом, при моделировании жизненного цикла объекта полезны как диаграммы деятельности, так и диаграммы состояний. Однако если диаграмма деятельности показывает поток управления от деятельности к деятельности, то на диаграмме состояний представлен поток управления от состояния к состоянию [2]. Диаграммы состояний используются для моделирования динамических аспектов системы. По большей части под этим подразумевается моделирование поведения реактивных объектов. Реактивным называется объект, поведение которого лучше всего характеризуется его реакцией на события, произошедшие вне его собственного контекста. У реактивного объекта есть четко выраженный жизненный цикл, когда текущее поведение обусловлено прошлым. Диаграммы состояния можно присоединять к классам, прецедентам или системе в целом для визуализации, специфицирования, конструирования и документирования динамики отдельного объекта. При моделировании программных систем необходимо отыскать наиболее естественный способ визуализации, специфицирования, конструирования и документирования поведения определенных типов объектов, когда основное внимание уделяется переходам из состояния в состояние, а не от деятельности к деятельности. Представьте себе моделирование поведения встроенной системы безопасности у себя дома. Она работает непрерывно, реагируя на внешние события, например на разбитое окно. Порядок событий изменяет повеление системы. Обнаружение разбитого окна вызовет срабатывание сигнализации, только если система предварительно была активизирована. Поведение такой системы лучше всего описывается путем моделирования ее устойчивых состояний (например, Ожидание, Активна, Проверка и т.д.), событий, инициирующих смену состояния, и действий, выполняемых при каждой такой смене. В UML для моделирования поведения объекта с точки зрения порядка возникновения событий используются диаграммы состояний. Диаграмма состояний (Slatechart diagram) показывает автомат, фокусируя внимание на потоке управления от состояния к состоянию. Автомат (State machine) – это описание последовательности состояний, через которые проходит объект на протяжении своего жизненною цикла, реагируя на события, в том числе описание реакций на эти события. Состояние (State) – это ситуация в жизни объекта, на протяжении которой он удовлетворяет некоторому условию, осуществляет определенную деятельность или ожидает какое-то событие. Событие (Event) – это спецификация существенного факта, который происходит во времени и пространстве. В контексте автоматов событие – это стимул, способный вызвать срабатывание перехода. Переход (Transition) – это отношение между двумя состояниями, показывающее, что объект, находящийся в первом состоянии, должен выполнить некоторые действия и перейти во второе состояние, как только произойдет определенное событие и будут выполнены заданные условия. Деятельность (Activity) – это продолжающееся неатомарное вычисление внутри автомата. Действие (Action) – это атомарное вычисление, которое приводит к смене состояния или возврату значения. Диаграмма состояний изображается в виде графа с вершинами и ребрами. Обычно диаграмма состояний включает в себя:
На диаграмме компонентов представлена организация совокупности компонентов, существующие между ними зависимости. Диаграммы компонентов относятся с точки зрения реализации к статическому виду системы. Они могут быть соотнесены с диаграммами классов, так как компонент обычно отображается на один или несколько классов, интерфейсов или коопераций. На диаграмме развертывания представлена конфигурация обрабатывающих узлов системы и размещенных в них компонентов. Диаграммы развертывания с точки зрения развертывания относятся к статическому виду архитектуры системы. Они связаны с диаграммами компонентов, поскольку в узле обычно размещаются один или несколько компонентов. Архитектура Для визуализации, специфицирования, конструирования и документирования программных систем необходимо рассматривать их с различных точек зрения. Все, кто имеет отношение к проекту: конечные пользователи, аналитики, разработчики, системные интеграторы, тестировщики, технические писатели и менеджеры проектов, – преследуют собственные интересы, и каждый смотрит на создаваемую систему по-разному в различные моменты ее жизни. Системная архитектура является наиболее важным артефактом, который используется для управления всевозможными точками зрения и тем самым способствует итеративной и инкрементной разработке системы на всем протяжении ее жизненного цикла. Архитектура – это совокупность существенных решений в отношении:
Архитектура программной системы охватывает не только ее структурные и поведенческие аспекты, но и использование, функциональность, производительность, гибкость, возможности повторного применения, полноту, экономические и технологические ограничения и компромиссы, а также эстетические вопросы. Архитектура программной системы наиболее оптимально может быть описана с помощью пяти взаимосвязанных видов или представлений, каждый из которых является одной из возможных проекций организации и структуры системы и заостряет внимание на определенном аспекте ее функционирования. Вид с точки зрения прецедентов (Use case view) охватывает прецеденты, которые описывают поведение системы, наблюдаемое конечными пользователями, аналитиками и тестировшиками. Этот вид специфицирует не истинную организацию программной системы, а те движущие силы, от которых зависит формирование системной архитектуры. В языке UML статические аспекты этого вида передаются диаграммами прецедентов, а динамические диаграммами взаимодействия, состояний и действий. Вид с точки зрения проектирования (Design view) охватывает классы, интерфейсы и кооперации, формирующие словарь задачи и ее решения. Этот вид поддерживает, прежде всего, функциональные требования, предъявляемые к системе, т.е. те услуги, которые она должна предоставлять конечным пользователям. С помощью языка UML статические аспекты этого вида можно передавать диаграммами классов и объектов, а динамические диаграммами взаимодействия, состояний и действий. Вид с точки зрения процессов (Process view) охватывает нити и процессы, формирующие механизмы параллелизма и синхронизации в системе. Этот вид описывает главным образом производительность, масштабируемость и пропускную способность системы. В UML его статические и динамические аспекты визуализируются теми же диаграммами, что и для вида с точки зрения проектирования, но особое внимание при этом уделяется активным классам, которые представляют соответствующие нити и процессы. Вид с точки зрения реализации (Implementation view) охватывает компоненты и файлы, используемые для сборки и выпуска конечного программного продукта. Этот вид предназначен в первую очередь для управления конфигурацией версий системы, составляемых из независимых (до некоторой степени) компонентов и файлов, которые могут по-разному объединяться между собой. В языке UML статические аспекты этого вида передают с помощью диаграмм компонентов, а динамические – с помощью диаграмм взаимодействия, состояний и действий. Вид с точки зрения развертывания (Deployment view) охватывает узлы, формирующие топологию аппаратных средств системы, на которой она выполняется. В первую очередь он связан с распределением, поставкой и установкой частей, составляющих физическую систему. Его статические аспекты описываются диаграммами развертывания, а динамические – диаграммами взаимодействия, состояний и действий. Каждый из перечисленных видов может считаться вполне самостоятельным, вследствие этого лица, имеющие отношение к разработке системы, могут сосредоточиться на изучении только тех аспектов архитектуры, которые непосредственно их касаются. UML позволяет отобразить каждый из пяти перечисленных видов и их взаимодействия [2]. Контрольные вопросы
|
Похожие:
 | Б 90 Основы риторики и коммуникации. Нормативный и коммуникативный аспекты современной риторики [Текст] : учебное пособие / М. Б.... | | Деловой английский язык. Часть I. Business English. Part I : учебное пособие / Ю. А. Вишневецкая, Л. М. Калянова. — Тюмень : Тюмгнгу,... |
 | «Владимирский государственный университет имени Александра Григорьевича и Николая Григорьевича Столетовых» | | Юрьева О. А. Бухгалтерский учет на предприятиях сферы услуг. Учебное пособие. Дгту: Ростов-на-Дону. 2008 |
| Учебное пособие для бакалавров направления подготовки 230700. 62 «Прикладная информатика в области экономики» | | Учебное пособие пм 04 Выполнение работ по профессии Младшая медицинская сестра по уходу за больными |
| Учебное пособие предназначено для студентов III v курсов специальности «Технология художественной обработки материалов» | | Хрестоматия по культурологии: учебное пособие / Под ред. Е. Я. Букиной. Новосибирск: Изд-во нгту, 2008 |
| Адамов Н. А., Амучиева Г. А. Бухгалтерский учет в строительстве: Учебное пособие / гуу. – М., 2004. – с. 128 | | Учебное пособие предназначено для студентов имтп, а также может быть использовано при самостоятельном освоении современного программного... |