Лекци 5 - Кафедра анализа данных и исследования операций
advertisement
Методология процедурно-ориентированного программирования Основой данной методологии разработки программ являлась процедурная или алгоритмическая организация структуры программного кода. Исходным понятием этой методологии являлось понятие алгоритм, под которым, в общем случае, понимается некоторое предписание выполнить точно определенную последовательность действий, направленных на достижение заданной цели или решение поставленной задачи. Примерами алгоритмов являются хорошо известные правила нахождения корней квадратного уравнения или корней линейной системы уравнений. Однако потребности практики не всегда требовали установления вычислимости конкретных функций или разрешимости отдельных задач. В языках программирования возникло и закрепилось новое понятие процедуры, которое конкретизировало общее понятие алгоритма применительно к решению задач на компьютерах. Так же, как и алгоритм, процедура представляет собой законченную последовательность действий или операций, направленных на решение отдельной задачи. В языках программирования появилась специальная синтаксическая конструкция, которая получила название процедуры. Со временем разработка больших программ превратилась в серьезную проблему и потребовала их разбиения на более мелкие фрагменты. Основой для такого разбиения как раз и стала процедурная декомпозиция, при которой отдельные части программы или модули представляли собой совокупность процедур для решения некоторой совокупности задач. Главная особенность процедурного программирования заключается в том, что программа всегда имеет начало во времени или начальную процедуру (начальный блок) и окончание (конечный блок). Важным свойством таких программ является необходимость завершения всех действий предшествующей процедуры для начала действий последующей процедуры. Изменение порядка выполнения этих действий даже в пределах одной процедуры потребовало включения в языки программирования специальных условных операторов типа if-then-else и goto для реализации ветвления вычислительного процесса в зависимости от промежуточных результатов решения задачи. Рассмотренные идеи способствовали становлению некоторой системы взглядов на процесс разработки программ и написания программных кодов, которая получила название методологии структурного программирования. Основой данной методологии является процедурная декомпозиция программной системы и организация отдельных модулей в виде совокупности выполняемых процедур. В рамках данной методологии получило развитие, нисходящее проектирование программ или программирование "сверху вниз". Методология объектно-ориентированного программирования 2.1. Закон Филиппа Кан Со временем ситуация стала существенно изменяться. Оказалось, что трудоемкость разработки программных приложений на начальных этапах программирования оценивалась значительно ниже реально затрачиваемых усилий, что служило причиной дополнительных расходов и затягивания окончательных сроков готовности программ. В процессе разработки приложений изменялись функциональные требования заказчика, что еще более отдаляло момент окончания работы программистов. Увеличение размеров программ приводило к необходимости привлечения большего числа программистов, что, в свою очередь, потребовало дополнительных ресурсов для организации их согласованной работы. Но не менее важными оказались качественные изменения, связанные со смещением акцента использования компьютеров. Если в эпоху "больших машин" основными потребителями программного обеспечения были крупные предприятия, компании и учреждения, то позже появились персональные компьютеры и стали повсеместным атрибутом мелкого и среднего бизнеса. Вычислительные и расчетно-алгоритмические 1 задачи в этой области традиционно занимали второстепенное место, а на первый план выступили задачи обработки и манипулирования данными. График показывает: чем больше в команде разработки ПО специалистов, тем ниже продуктивность каждого из них. Такой эффект противоречит одному из базовых принципов индустриализации, суть которого в том, что рост уровня производства предполагает повышение, а не снижение производительности членов рабочего коллектива. 15,000 Ln = ---------------3 n где Ln – индивидуальная продуктивность каждого программиста команды, состоящей из n членов (LOG/год) 8 27 n Стало очевидным, что традиционные методы процедурного программирования не способны справиться ни с растущей сложностью программ и их разработки, ни с необходимостью повышения их надежности. Во второй половине 80-х годов возникла настоятельная потребность в новой методологии программирования, которая была бы способна решить весь этот комплекс проблем. Такой методологией стало объектноориентированное программирование (ООП). 2.2. Понятия класса и объекта Фундаментальными понятиями ООП являются понятия класса и объекта. При этом под классом понимают некоторую абстракцию совокупности объектов, которые имеют общий набор свойств и обладают одинаковым поведением. Каждый объект в этом случае рассматривается как экземпляр соответствующего класса. Объекты, которые не имеют полностью одинаковых свойств или не обладают одинаковым поведением, по определению, не могут быть отнесены к одному классу. 2.3. Основные принципы ООП: наследование, инкапсуляция и полиморфизм. Основными принципами ООП являются наследование, инкапсуляция и полиморфизм. Принцип, в соответствии с которым знание о более общей категории разрешается применять для более узкой категории, называется наследованием. Наследование тесно связано с иерархией классов, которая определяет, какие классы следует считать наиболее абстрактными и общими по отношению к другим классам. При этом, если некоторый более общий или родительский класс (предок) обладает фиксированным набором свойств и поведением, то производный от него класс (потомок) должен содержать этот же набор свойств и поведение, а также дополнительные, которые будут 2 характеризовать уникальность полученного таким образом класса. В этом случае говорят, что производный класс наследует свойства и поведение родительского класса. Для иллюстрации принципа наследования можно привести следующий пример. Рассмотрим в качестве общего класс "Автомобиль". Данный класс определяется как некоторая абстракция свойств и поведения всех реально существующих автомобилей. При этом свойствами класса "Автомобиль" могут быть такие общие свойства, как наличие двигателя, трансмиссии, колес, рулевого управления. Если в качестве производного класса рассмотреть класс "Легковой автомобиль", то все выделенные выше свойства будут присущи и этому классу. Можно сказать, что класс "Легковой автомобиль" наследует свойства родительского класса "Автомобиль". Однако, кроме перечисленных свойств, класс-потомок будет содержать дополнительные свойства, например такое, как наличие салона с количеством посадочных мест 2 — 5. В свою очередь, класс "Легковой автомобиль" способен порождать другие подклассы, которые вполне могут соответствовать, например, моделям конкретных фирм-производителей. Таким образом, можно рассматривать класс "Легковой автомобиль производства ВАЗ". Поскольку Волжский автомобильный завод выпускает несколько моделей автомобилей, одним из проездных классов для предыдущего класса может быть конкретная модель автомобиля, например, BA3-21083. Наконец, изготовленный автомобиль имеет уникальный заводской номер, отличающий один автомобиль от другого. Taким номером может быть, например, ХТА-210830S1594301. В последнем случае класс будет состоять из единственного объекта или экземпляра, которым будет являться легковой автомобиль производства BA3 с указанным выше заводским номером. Класс "Автомобиль" Класс "Легковой автомобиль' Класс "Легковой автомобиль производства ВАЗ" Класс "Модель ВАЗ-21083 Класс «Легковой автомобиль с номером ХТА-210830 S1594301» Следующий принцип ООП — инкапсуляция. Этот термин характеризует сокрытие отдельных деталей внутреннего устройства классов от внешних по отношению к нему объектов или пользователей. Действительно, взаимодействующему с классом субъекту или клиенту нет необходимости знать, каким образом реализован тот или иной метод класса, услугами которого он решил воспользоваться. Конкретная реализация присущих классу свойств и методов, которые определяют поведение этого класса, является собственным делом данного класса. Более того, отдельные свойства и методы класса вообще могут быть невидимы за пределами этого класса, что является базовой идеей введения различных категорий видимости для компонентов класса. Если продолжить рассмотрение примера с классом "Легковой автомобиль", то нетрудно проиллюстрировать инкапсуляцию следующим образом. Основным субъектом, 3 который взаимодействует с этим классом, является водитель. Вполне очевидно, что не каждый водитель в совершенстве знает внутреннее устройство легкового автомобиля. Более того, отдельные детали этого устройства сознательно скрыты в корпусе двигателя или в коробке передач. А в случае нарушения работы автомобиля, являющейся причиной неадекватности его поведения, необходимый ремонт выполняет профессиональный механик. Третьим принципом ООП является полиморфизм. Под полиморфизмом (греч. Poly — много, morfos — форма) понимают свойство некоторых объектов принимать различные внешние формы в зависимости от обстоятельств. Применительно к ООП полиморфизм означает, что действия, выполняемые одноименными методами, могут отличаться в зависимости от того, какому из классов относится тот или иной метод. Рассмотрим, например, три объекта или класса: двигатель автомобиля, электрический свет в комнате и персональный компьютер. Для каждого из них можно определить операцию "выключить". Однако сущность этой операции будет отличаться для каждого из рассмотренных объектов. Так для двигателя автомобиля вызов метода Двигатель.автомобиля.выключить() означает прекращение подачи топлива и его остановку. Вызов метода Комната.электрческий.свет.выключить() означает простой щелчок выключателя, после чего комната погрузится в темноту. В последнем случае действие Персональный.компьютер.выключить() может быть причиной потери данных, если выполняется нерегламентированным образом. 2.4. Объектно-ориентированная декомпозиция (процессная декомпозиция) Широкое распространение методологии ООП оказало влияние на процесс разработки программ. В частности, процедурно-ориентированная декомпозиция программ уступила место объектно-ориентированной декомпозиции, при которой отдельными структурными единицами программы стали являться не процедуры и функции, а классы и объекты с соответствующими свойствами и методами. Как следствие, программа перестала быть последовательностью предопределенных на этапе кодирования действий, а стала событийно-управляемой. Последнее обстоятельство стало доминирующим при разработке широкого круга современных приложений. В этом случае каждая программа представляет собой бесконечный цикл ожидания некоторых заранее определенных событий. Инициаторами событий могут быть другие программы или пользователи. При наступлении отдельного события, например, нажатия клавиши на клавиатуре или щелчка кнопкой мыши, программа выходит из состояния ожидания и реагирует на это событие вполне адекватным образом. Реакция программы при этом тоже связывается с последующими событиями. Наиболее существенным обстоятельством в развитии методологии ООП явилось осознание того факта, что процесс написания программного кода может быть отделен от процесса проектирования структуры программы. Действительно, до того как начать программирование классов, их свойств и методов, необходимо определить, чем же являются сами эти классы. Более того, нужно дать ответы на такие вопросы, как: сколько и какие классы нужно определить для решения поставленной задачи, какие свойства и методы необходимы для придания классам требуемого поведения, а также установить взаимосвязи между классами. Эта совокупность задач не столько связана с написанием кода, сколько с общим анализом требований к будущей программе, а также с анализом конкретной предметной области, для которой разрабатывается программа. Все эти обстоятельства привели к появлению специальной методологии, получившей название методологии объектноориентированного анализа и проектирования (ООАП). Разделение процесса разработки сложных программных приложений на отдельные этапы способствовало становлению концепции жизненного цикла программы. Под 4 жизненным циклом (ЖЦ) программы понимают совокупность взаимосвязанных и следующих во времени этапов, начиная от разработки требований к ней и заканчивая полным отказом от ее использования. Стандарт ISO/IEC 12207, хотя и описывает общую структуру ЖЦ программы, не конкретизирует детали выполнения тех или иных этапов. Согласно принятым взглядам ЖЦ программы состоит из следующих этапов: Анализа предметной области и формулировки требований к программе Проектирования структуры программы Реализации программы в кодах (собственно программирования), Внедрения программы Сопровождения программы Отказа от использования программы На этапе анализа предметной области и формулировки требований осуществляется определение функций, которые должна выполнять разрабатываемая программа, а также концептуализация предметной области. Эту работу выполняют аналитики совместно со специалистами предметной области. Результатом данного этапа должна являться некоторая концептуальная схема, содержащая описание основных компонентов и тех функций, которые они должны выполнять. Этап проектирования структуры программы заключается в разработке детальной схемы будущей программы, на которой указываются классы, их свойства и методы, а также различные взаимосвязи между ними. Как правило, на этом этапе могут участвовать в работе аналитики, архитекторы и отдельные квалифицированные программисты. Результатом данного этапа должна стать детализированная схема программы, на которой указываются все классы и взаимосвязи между ними в процессе функционирования программы. Согласно методологии ООАП, именно данная схема должна служить исходной информацией для написания программного кода. Этап программирования вряд ли нуждается в уточнении, поскольку является наиболее традиционным для программистов. Результатом данного этапа является программное приложение, которое обладает требуемой функциональностью и способно решать нужные задачи в конкретной предметной области. Этапы внедрения и сопровождения программы связаны с необходимостью настройки и конфигурирования среды программы, а также с устранением возникших в процессе ее использования ошибок. Иногда в качестве отдельного этапа выделяют тестирование программы, под которым понимают проверку работоспособности программы на некоторой совокупности исходных данных или при некоторых специальных режимах эксплуатации. Результатом этих этапов является повышение надежности программного приложения, исключающего возникновение критических ситуаций или нанесение ущерба компании, использующей данное приложение. 3. Методология объектно-ориентированного анализа (ООА) и проектирования (ООП) Что такое анализ и проектирование Этап анализа состоит в исследовании системных требований и проблемы, а не в поисках путей ее решения. Анализ – это достаточно широкое понятие. Его содержание более точно отражают термины анализ требований (т.е. исследование требований к системе) и объектный анализ (исследование объектов предметной области). В процессе проектирования основное внимание уделяется концептуальному решению, обеспечивающему выполнение основных требований, но не вопросам его реализации. Например, на этапе проектирования описываются программные объекты или схема базы данных. Этот термин тоже необходимо уточнить и говорить о объектном проектировании 5 В процессе объектно-ориентированного анализа основное внимание уделяется определению и описанию объектов (или понятий) в терминах предметной области. 3.1. Предметная область Необходимость анализа предметной области до начала написания программы была осознана давно при разработке масштабных проектов. Процесс разработки баз данных существенно отличается от написания программного кода для решения вычислительной задачи. Главное отличие заключается в том, что при проектировании базы данных возникает необходимость в предварительной разработке концептуальной схемы, которая отражала бы общие взаимосвязи предметной области и особенности организации соответствующей информации. При этом под предметной областью принято понимать ту часть реального мира, которая имеет существенное значение или непосредственное отношение к процессу функционирования программы. Другими словами, предметная область включает в себя только те объекты и взаимосвязи между ними, которые необходимы для описания требований и условий решения некоторой задачи. Выделение исходных или базовых компонентов предметной области, необходимых для решения той или иной задачи, представляет, в общем случае, нетривиальную проблему. Сложность данной проблемы проявляется в неформальном характере процедур или правил, которые можно применять для этой цели. Более того, такая работа должна выполняться совместно со специалистами или экспертами, хорошо знающими предметную область. Например, если разрабатывается база данных для обслуживания пассажиров крупного аэропорта, то в проектировании концептуальной схемы базы данных должны принимать участие штатные сотрудники данного аэропорта. Эти сотрудники должны хорошо знать весь процесс обслуживания пассажиров или данную предметную область. Процесс или идентификации компонентов предметной области получил название концептуализации предметной области. При этом под компонентой понимают некоторую абстрактную единицу, которая обладает функциональностью, т. е. может выполнять определенные действия, связанные с решением поставленных задач. Появление методологии ООАП потребовало, с одной стороны, разработки различных средств концептуализации предметной области, а с другой — соответствующих специалистов, которые владели бы этой методологией. На данном этапе появляется относительно новый тип специалиста, который получил название аналитика или архитектора. 4. Методология системного анализа и системного моделирования Центральным понятием системного анализа является понятие системы, под которой понимается совокупность объектов, компонентов или элементов произвольной природы, образующих некоторую целостность. Важнейшими характеристиками любой системы являются ее структура и процесс функционирования. Под структурой системы понимают устойчивую во времени совокупность взаимосвязей между ее элементами или компонентами. Именно структура связывает воедино все элементы и препятствует распаду системы на отдельные компоненты. Структура системы может отражать самые различные взаимосвязи, в том числе и вложенность элементов одной системы в другую. В этом случае принято называть более мелкую или вложенную систему подсистемой, а более крупную — метасистемой. Процесс функционирования системы тесно связан с изменением ее свойств или поведения во времени. При этом важной характеристикой системы является ее состояние, под которым понимается совокупность свойств или признаков, которые в каждый момент времени отражают наиболее существенные особенности поведения системы. Рассмотрим следующий пример. В качестве системы представим себе "Автомобиль". Для этого случая система охлаждения двигателя будет являться 6 подсистемой "Автомобиля". С одной стороны, двигатель является элементом системы "Автомобиль". С другой стороны, двигатель сам является системой, состоящей из отдельных компонентов, таких как цилиндры, свечи зажигания и др. Поэтому система "Двигатель" также будет являться подсистемой системы "Автомобиль". Структура системы "Автомобиль" может быть описана с разных точек зрения. Наиболее общее представление о структуре этой системы дает механическая схема устройства того или иного автомобиля. Взаимодействие элементов в этом случае носит механический характер. Состояние автомобиля можно рассматривать также с различных точек зрения, наиболее общей из которых является характеристика автомобиля как исправного или неисправного. Очевидно, что каждое из этих состояний в отдельных ситуациях может быть детализировано. Например, состояние "неисправный" может быть конкретизировано в состояния "неисправность двигателя", "неисправность аккумулятора", "отсутствие подачи топлива" и пр. Важно иметь четкое представление, что подобная детализация должна быть адекватна решаемой задаче. 4.1. Модель предметной области Методология системного анализа служит концептуальной основой системноориентированной декомпозиции предметной области. В этом случае исходными компонентами концептуализации являются системы и взаимосвязи между ними. Результатом системного анализа является построение некоторой модели системы или предметной области. А именно, под моделью будем понимать некоторое представление о системе, отражающее наиболее существенные закономерности ее структуры и процесса функционирования и зафиксированное на некотором языке или в другой форме. 4.2. Процесс моделирования Общим свойством всех моделей является их подобие оригинальной системе или системе-оригиналу. Важность построения моделей заключается в возможности их использования для получения информации о свойствах или поведении системыоригинала. При этом процесс построения и последующего применения моделей для получения информации о системе-оригинале получил название моделирование. Вопросы: Модель, что такое модель, для чего нужны модели, уровни моделей, что содержится в модели? Какое значение имеет модель? Что содержится в модели? Семантика и представление. Модель имеет два основных аспекта: семантическую информацию (семантику) и визуальное представление (нотацию). С точки зрения семантики модели, программное приложение — это набор взаимосвязанных логических конструкций, таких, например, как классы, ассоциации, состояния, варианты использования и сообщения. Семантические элементы определяют содержание модели. Семантика используется для создания программного кода, контроля правильности модели, измерения ее сложности и т. д. Для большинства инструментов, генерирующих модели, внешний вид модели совсем не важен, существенна лишь ее семантика. Семантическая информация сама по себе тоже часто называется моделью. У семантической модели есть синтаксическая структура, правила формальной правильности и динамика исполнения. Часто эти аспекты описываются отдельно, однако они тесно связаны между собой и являются частью единой согласованной модели. Нотация — это визуальное представление семантики модели. Визуальное представление дает людям возможность непосредственно работать с моделью, то есть просматривать и редактировать ее. Элементы нотации передают визуальное представление элементов модели, другими словами, показывают их в понятной для людей форме. Нотация не несет в себе новой информации, а лишь представляет имеющуюся информацию в удобной для работы форме. Элементы нотации строятся, исходя из 7 семантических элементов модели. Впрочем, диаграммы разрабатываются людьми, поэтому элементы нотации иногда зависят не столько от семантики модели, сколько от ее разработчика. С помощью нотации можно передавать информацию о семантических связях, которые слишком слабы или неопределенны, чтобы их можно было отразить в семантической модели, но которые тем не менее важны для проектирования системы. Моделирование позволяет решить четыре различных задачи: визуализировать систему в ее текущем или желательном для нас состоянии; определить структуру или поведение системы; получить шаблон, позволяющий затем сконструировать систему; документировать принимаемые решения, используя полученные модели. Моделирование предназначено не только для создания больших систем. Даже программный эквивалент собачьей конуры выиграет от этого процесса. Чем больше и сложнее система, тем большее значение приобретает моделирование при ее разработке. Дело в том, что моделировать сложную систему необходимо, поскольку иначе мы не можем воспринять ее как единое целое. Восприятие человеком сложных сущностей ограничено. Моделируя, мы сужаем проблему, заостряя внимание в данный момент только на одном аспекте. В сущности, этот подход есть не что иное, как принцип «разделяй и властвуй», который Эдсгер Дейкстра провозгласил много лет назад: сложную задачу легче решить, если разделить ее на несколько меньших. Кроме того, моделирование усиливает возможности человеческого интеллекта, поскольку правильно выбранная модель дает возможность создавать проекты на более высоких уровнях абстракции. Процесс разработки адекватных моделей и их последующего конструктивного применения требует не только знания общей методологии системного анализа, но и наличия соответствующих изобразительных средств или языков для фиксации результатов моделирования и их документирования. Очевидно, что естественный язык не вполне подходит для этой цели, поскольку обладает неоднозначностью и неопределенностью. Для построения моделей были разработаны достаточно серьезные теоретические методы, основанные на развитии математических и логических средств моделирования, а также предложены различные формальные и графические нотации, отражающие специфику решаемых задач. Мы с вами будем рассматривать вопросы о процессе объектно-ориентированного анализа и проектирования с помощью унифицированного языка моделирования UML. Язык UML – это система обозначений. Но можно в совершенстве освоить синтаксис UML, но не научиться при этом разрабатывать новые системы или модифицировать существующие. Для всего этого необходим свой язык, который позволяет формулировать мысли и общаться с другими разработчиками. Для этого мы рассматриваем то, как применить язык UML в процессе ООА/ООП. 8 Общие положения UML – это стандартизованный язык для создания рабочих чертежей программирования. UML это язык для Визуализации, Спецификации, Конструирования и Документации артефактов программной системы. UML – это язык UML дает возможность создавать и разбираться в правильно построенных моделях, но не говорит какие модели и когда нужно создавать. Последние два вопроса входят в компетенцию процесса разработки ПО. UML – язык визуализации Для многих программистов время между обдумыванием и написанием кода равно нулю. Код получается прекрасный, но программист при этом моделирует в уме. В связи с этим возникает несколько проблем. 1. При обсуждении концептуальной модели приходится так или иначе использовать единый язык. Как правило в группе вырабатывается некоторый внутренний язык совершенно не понятный извне. 2. Существуют некоторые вещи в программной системе, которые невозможно понять по модели, представленной в виде текста программного кода. Например, может быть сделано общее заключение о физическом распределении и возможной миграции объектов Web-системы, но это невозможно напрямую постичь путем непосредственного просмотра кодов. 3. Если разработчик уничтожил часть кода и никогда не записывал в каком-либо виде модель, а держал ее только в голове, тогда эта информация будет утрачена навсегда. Написание моделей на UML прежде всего относится к третьей проблеме. Т.е. точная модель обеспечивает инфраструктуру и коммуникации между разработчиками для кодирования. Некоторые вещи моделируются текстуально, а некоторые графически. UML является графическим языком и, следовательно, решает вторую проблему. Более того, UML обладает корректно-определенной семантикой и, поэтому, разные разработчики будут одинаково трактовать эту модель. Данное положение адресовано первой из перечисленных проблем. UML – язык спецификации В данном контексте спецификация означает построение точной, непротиворечивой и полной модели. Т.е. UML предоставляет возможность спецификации всех важных решений по анализу, проектированию и разработке при создании и внедрении программной системы. UML – язык конструирования Хотя UML не является языком программирования, но он может быть легко привязан непосредственно к языкам программирования, таким как C++, Java и пр. Это означает, что может быть построено отображение (mapping) модели UML на данные языки программирования. Возможно как прямое (engineering), так и обратное (reverse engineering) отображение. UML – язык документирования При создании программной системы создается много вторичных по отношению к исполняемому коду продуктов: требования, архитектура, проект, исходный код, планы проекта, тесты, прототипы, реализации и версии. UML предоставляет возможности документирования целого ряда из перечисленных артефактов. Концептуальная модель UML 9 Конструктивные блоки UML В UML задействованы три типа блоков: 1. Сущность (things) 2. Отношение (relationships) 3. Диаграмма (diagrams) Cущности являются основой модели, отношения обеспечивают их привязку друг к другу, а диаграммы группируют наборы сущностей. Сущности В UML представлены три типа сущностей: 1. Структурные (structural) 2. Поведенческие (behavioral) 3. Групповые (group) 4. Аннотационные (annotational) Структурные сущности Структурные сущности представляют статические части модели, представляя физические либо концептуальные элементы. В UML определены семь типов структурных сущностей: 1. Класс (Class) Это набор объектов которые используют одни и те же атрибуты, операции, отношения и семантику. 2. Интерфейс (Interface) Это набор операций которые специфицируют услугу, предоставляемую классом или компонентой. Т.е. интерфейс описывает видимое извне поведение элемента. Интерфейс определяет операции спецификации, но никогда операции реализаций (implementations) 3. Cотрудничество (Collaboration) Сотрудничество определяет взаимодействия и является сообществом ролей и других элементов, которые работают вместе для обеспечения некоторого совместного поведения, которое больше, чем совокупность всех элементов. Поэтому сущности сотрудничества представляются как в структурном, так и в поведенческом измерении (dimensions). Конкретный класс может участвовать в нескольких сущностях сотрудничества, которая следовательно будет представлять реализации шаблона, который является составляющей частью системы. 10 4. Сценарий использования (Use Case) Сценарий использования описывает набор последовательностей действий, которые выполняются системой и дают результат с конкретным значением для конкретного участника (actor). 5. Активный класс (Active Class) Активный класс это класс, объекты которого владеют одним или более процессами или нитями выполнения и, следовательно, могут инициировать управляющие воздействия. Его объекты представляют собой элементы, чье поведение параллельно с другими элементами. Компоненты и узлы представляют физические сущности, в то время, как предыдущие пять – концептуальные или логические. 6. Компонента (Component) Это физическая и перемещаемая часть системы, которая удовлетворяет и обеспечивает реализацию набора интерфейсов. 7. Узел (Node) Это физический элемент, который существует в момент исполнения действий системы и представляет вычислительный ресурс, как правило содержащий некоторую память и часто способность к обработке данных. Набор компонент может принадлежать узлу, а также мигрировать от узла к узлу. 11 Существуют также вариации перечисленных выше семи сущностей такие, как участники, утилиты (разновидность классов), процессы, нити выполнения (разновидность активных классов), а также приложения, документы, файлы, библиотеки, страницы и таблицы (разновидности компонент). Поведенческие сущности Это динамические составляющие UML-модели, представляющие ее поведение во времени и в пространстве. Определены два основных типа поведенческих сущностей. 1. Взаимодействие (interaction) Включает набор сообщений, передаваемых внутри набора объектов. Кроме того взаимодействие включает набор других элементов, таких как сообщения, последовательности действий (поведение, инициированное сообщением) и каналы (связи между объектами). 2. Машина состояний (state machine) Является поведенческой сущностью, которая специфицирует последовательности наборов, которые объект или взаимодействие проходит на протяжении своего жизненного цикла в ответ на события вместе со своими ответами на данные события. Например, поведение отдельно взятого класса или сущности сотрудничества классов может быть специфицированного с помощью машины состояний. Машина состояний включает ряд других элементов – состояния, переходы (поток из одного состояния в другое), события (сущности, переключающие переходы) и действия (ответы на переходы). Групповые сущности Групповые сущности это “ящики”, на которые может быть осуществлена декомпозиция модели. Единственным представителем данной сущности является пакет (package). Пакет это механизм общего назначения для организации элементов в виде единой группы. Структурные, поведенческие и даже другие сущности могут быть помещены внутрь пакета. Встречаются также такие разновидности пакетов, как frameworks, models, subsystems. 12 Аннотационные сущности Аннотации являются поясняющей и комментирующей частью UML. Единственным типом аннотационной сущности является примечание (note). Отношения В UML различают четыре типа отношений: 1. Зависимость (Dependency) 2. Взаимосвязь (Assosiation) 3. Обобщение (Generalization) 4. Реализация (Realization) Зависимость Это семантическое отношение между двумя сущностями при котором изменение в одной сущности (независимая сущность) может воздействовать на семантику другой (зависимой) сущности. Взаимосвязь Это структурное отношение, которое описывает набор каналов, являющихся связями между объектами. Агрегат (aggregation) это специальная разновидность взаимосвязи, представляющая структурное отношение между целым и его частями. Обобщение Это специализирующее\обобщающее отношение, в котором объекты специализированных элементов (дети(child)) могут быть подставлены вместо объектов обобщающих элементов. Реализация Это семантическое отношение между классификаторами (classifier), там где один классификатор специфицирует контракт, который должен выполнить другой 13 классификатор. Отношение реализации устанавливается в дух случаях: между интерфейсами и классами (компонентами) реализующими их; между сценариями использования и структурными сущностями сотрудничества которые реализуют данные сценарии использования. Диаграммы 1. Class diagram (диаграмма классов) Показывает набор классов, интерфейсов, сущностей сотрудничества и их отношения. Диаграммы классов являются статическими. 2. Object diagram (диаграмма объектов) Показывает набор объектов и отношения между ними. Диаграмма является “мгновенным снимком” сущностей обнаруженных в диаграмме классов. Диаграмма является статической. 3. Use case diagram (диаграмма сценария использования) Показывает набор сценариев использования и участников (специальный тип класса) и их отношения. Диаграмма является статической. Диаграмма очень важна для описания поведения системы. 4. Sequence diagram (диаграмма последовательности исполнения) 5. Colloboration diagram (диаграмма сотрудничества) Диаграммы последовательности исполнения и сотрудничества являются разновидностями диаграмм взаимодействия (interaction), которые показывают взаимодействия, состоящих из набора объектов и их отношений, включая сообщения которыми они могут обмениваться. Диаграммы взаимодействия являются динамическими. Диаграмма последовательности исполнения показывает последовательность обмена сообщениями. Диаграмма сотрудничества показывает структурную организацию объектов, которые посылают и принимают сообщения. Диаграммы являются изоморфными в том смысле, что одну можно трансформировать в другую. 6. Statechart diagram (диаграмма состояний) Диаграмма состояний представляет собой машину состояний, включающую состояния, переходы, события и действия. Диаграмма является динамический и особенно важна для моделирования поведения интерфейса, класса либо сущности сотрудничества и показывает упорядоченное по событиям поведение объекта, что особенно важно для моделирования “реагирующих” систем (reactive). 7. Activity diagram (диаграмма активности) Специальная разновидность диаграммы состояний, которая показывает поток от действия к действию внутри системы. Она особенно важна для моделирования функций системы, является динамической и показывает потоки управления между объектами 8. Component diagram (диаграмма компонент) Показывает организационные связи и зависимости между компонентами внутри одного набора. Диаграмма является статической и относится к диаграммам классов в том смысле, что компонента как правило отображается на один или более классов, интерфейсов и сущностей сотрудничества. 9. Deployment diagram (диаграмма размещения) Показывает конфигурацию обрабатывающих узлов, а также размещенные на них компоненты. Диаграмма является статической. Правила UML Правильной (грамматически правильной (well-formed model)) является семантически непротиворечивая модель, гармонирующая со всеми связанными с ней моделями. 14 Конструктивные блоки UML должны связываться друг с другом в соответствии с семантическими правилами для Имен (Names) (как можно именовать сущности, отношения и диаграммы) Целей (Scope) (контекст, определяющий специфическое значение имени) Различимости (Visibility) (как данные имена могут быть видимы и использованы другими именами) Целостности (Itegrity) (насколько правильно и содержательно сущности согласуются друг с другом) Исполнения (Execution) (что требуется для выполнения либо иммуляции системы) Поскольку в процессе разработки программная система имеет тенденцию к развитию, то кроме следования семантическим и грамматическим правилам UML необходимо строить модель, которая является Сокращенной (Elided) (некоторые элементы “прячутся” для простоты отображения) Неполной (Incomplete) (некоторые элементы могут быть пропущены) Противоречивой (целостность модели не гарантируется) (Inconsistent) Построение почти правильной модели (не совсем правильной) неизбежно, поскольку элементы системы меняются либо “перетряхиваются” в процессе жизненного цикла создания программного обеспечения. 15 Язык UML Сущности: 1.Структурные 2.Поведенческие 3.Группирующие 4.Аннотационные Диаграммы: Отношения: 1.Классов 2.Объектов 3.Прецедентов 4.Последовательностей 5.Коопераций 6.Состояний 7.Действий 8.Компонентов 9.Развертывания 1.Зависимостей 2.Ассоиаций 3.Обобщений 4.Реализаций Аннотационные сущности: Структурные сущности: 1.Классы 2.Интерфейсы 3.Кооперации 4.Прецеденты 5.Активные классы 6.Компоненты 7.Узлы Поведенческие сущности: 1.Взаимодействия 2.Автоматы Группирующие сущности: 1.Примечания 1.Пакет 16 Имя Атрибуты Операции Класс Актер Прецедент (use case) Пакет Примечание абстрактный область действия класса Window open() close() move() display открытый Frame тип Header: FrameHeader uniqueID: Long + add Message (m: Message): Status # set check Sum() - encrypt() сигнатура защищенный Окно закрытый Кадр 0..1 Зависимости Рработоддатель * работник Ассоциации Обобщения Реализации 17
