Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
Подписываем
Министерство образования Российской Федерации
Государственное образовательное учреждение
высшего профессионального образования
«Санкт-Петербургский государственный университет
аэрокосмического приборостроения»
ТЕХНОЛОГИИ ПРОГРАММИРОВАНИЯ
Методические указания к выполнению курсовой работы
Составитель Пятлина Е.О.
Санкт-Петербург
2010
Цель работы:
Ознакомление с основными элементами определения, представления, проектирования и моделирования информационных систем с помощью языка UML.
2. Методические указания
Курсовая работа направлена на ознакомление с основными элементами определения, представления, проектирования и моделирования программных систем с помощью языка UML, получение навыков по применению данных элементов для построения объектно-ориентированных моделей ИС на основании требований.
Требования к результатам выполнения курсовой работы:
3. Содержание курсовой работы
Введение
Приложение. Результаты автоматической генерации текстов программ (коды)
3. Общие сведения об объектном моделировании ИС
Существует множество технологий и инструментальных средств, с помощью которых можно реализовать в некотором смысле оптимальный проект ИС, начиная с этапа анализа и заканчивая созданием программного кода системы. В большинстве случаев эти технологии предъявляют весьма жесткие требования к процессу разработки и используемым ресурсам, а попытки трансформировать их под конкретные проекты оказываются безуспешными. Эти технологии представлены CASE-средствами верхнего уровня или CASE-средствами полного жизненного цикла (upper CASE tools или full life-cycle CASE tools). Они не позволяют оптимизировать деятельность на уровне отдельных элементов проекта, и, как следствие, многие разработчики перешли на так называемые CASE-средства нижнего уровня (lower CASE tools). Однако они столкнулись с новой проблемой — проблемой организации взаимодействия между различными командами, реализующими проект.
Унифицированный язык объектно-ориентированного моделирования Unified Modeling Language (UML) явился средством достижения компромисса между этими подходами. Существует достаточное количество инструментальных средств, поддерживающих с помощью UML жизненный цикл информационных систем, и, одновременно, UML является достаточно гибким для настройки и поддержки специфики деятельности различных команд разработчиков.
Создание UML началось в октябре 1994 г., когда Джим Рамбо и Гради Буч из Rational Software Corporation стали работать над объединением своих методов OMT и Booch. В настоящее время консорциум пользователей UML Partners включает в себя представителей таких грандов информационных технологий, как Rational Software, Microsoft, IBM, Hewlett-Packard, Oracle, DEC, Unisys, IntelliCorp, Platinum Technology.
UML представляет собой объектно-ориентированный язык моделирования, обладающий следующими основными характеристиками:
UML — это стандартная нотация визуального моделирования программных систем, принятая консорциумом Object Managing Group (OMG) осенью 1997 г., и на сегодняшний день она поддерживается многими объектно-ориентированными CASE-продуктами.
UML включает внутренний набор средств моделирования, которые сейчас приняты во многих методах и средствах моделирования. Эти концепции необходимы в большинстве прикладных задач, хотя не каждая концепция необходима в каждой части каждого приложения. Пользователям языка предоставлены возможности:
Язык UML
Рис. 1. Интегрированная модель сложной системы в нотации языка UML
Стандарт UML предлагает следующий набор диаграмм для моделирования:
Диаграммы вариантов использования
Понятие варианта использования (use case) впервые ввел Ивар Якобсон и придал ему такую значимость, что в настоящее время вариант использования превратился в основной элемент разработки и планирования проекта.
Вариант использования представляет собой последовательность действий (транзакций), выполняемых системой в ответ на событие, инициируемое некоторым внешним объектом (действующим лицом). Вариант использования описывает типичное взаимодействие между пользователем и системой. В простейшем случае вариант использования определяется в процессе обсуждения с пользователем тех функций, которые он хотел бы реализовать. На языке UML вариант использования изображают следующим образом:
Рис.2. Вариант использования
Действующее лицо (actor) – это роль, которую пользователь играет по отношению к системе. Действующие лица представляют собой роли, а не конкретных людей или наименования работ. Несмотря на то, что на диаграммах вариантов использования они изображаются в виде стилизованных человеческих фигурок, действующее лицо может также быть внешней системой, которой необходима некоторая информация от данной системы. Показывать на диаграмме действующих лиц следует только в том случае, когда им действительно необходимы некоторые варианты использования. На языке UML действующие лица представляют в виде фигур:
Рис.3. Действующее лицо (актер)
Действующие лица делятся на три основных типа:
Время становится действующим лицом, если от него зависит запуск каких-либо событий в системе.
Связи между вариантами использования и действующими лицами
В языке UML на диаграммах вариантов использования поддерживается несколько типов связей между элементами диаграммы. Это связи коммуникации (communication), включения (include), расширения (extend) и обобщения (generalization).
Связь коммуникации – это связь между вариантом использования и действующим лицом. На языке UML связи коммуникации показывают с помощью однонаправленной ассоциации (сплошной линии).
Рис.4. Пример связи коммуникации
Связь включения применяется в тех ситуациях, когда имеется какой-либо фрагмент поведения системы, который повторяется более чем в одном варианте использования. С помощью таких связей обычно моделируют многократно используемую функциональность.
Связь расширения применяется при описании изменений в нормальном поведении системы. Она позволяет варианту использования только при необходимости использовать функциональные возможности другого.
Рис.5. Пример связи включения и расширения
С помощью связи обобщения показывают, что у нескольких действующих лиц имеются общие черты.
Рис.6. Пример связи обобщения
Диаграммы взаимодействия (interaction diagrams)
Диаграммы взаимодействия (interaction diagrams) описывают поведение взаимодействующих групп объектов. Как правило, диаграмма взаимодействия охватывает поведение объектов в рамках только одного варианта использования. На такой диаграмме отображается ряд объектов и те сообщения, которыми они обмениваются между собой.
Сообщение (message) – это средство, с помощью которого объект-отправитель запрашивает у объекта получателя выполнение одной из его операций.
Информационное (informative) сообщение – это сообщение, снабжающее объект-получатель некоторой информацией для обновления его состояния.
Сообщение-запрос (interrogative) – это сообщение, запрашивающее выдачу некоторой информации об объекте-получателе.
Императивное (imperative) сообщение – это сообщение, запрашивающее у объекта-получателя выполнение некоторых действий.
Существует два вида диаграмм взаимодействия: диаграммы последовательности (sequence diagrams) и кооперативные диаграммы (collaboration diagrams).
Диаграмма последовательности (sequence diagrams)
Диаграмма последовательности отражает поток событий, происходящих в рамках варианта использования.
Все действующие лица показаны в верхней части диаграммы. Стрелки соответствуют сообщениям, передаваемым между действующим лицом и объектом или между объектами для выполнения требуемых функций.
На диаграмме последовательности объект изображается в виде прямоугольника, от которого вниз проведена пунктирная вертикальная линия. Эта линия называется линией жизни (lifeline) объекта. Она представляет собой фрагмент жизненного цикла объекта в процессе взаимодействия.
Каждое сообщение представляется в виде стрелки между линиями жизни двух объектов. Сообщения появляются в том порядке, как они показаны на странице сверху вниз. Каждое сообщение помечается как минимум именем сообщения. При желании можно добавить также аргументы и некоторую управляющую информацию. Можно показать самоделегирование (self-delegation) – сообщение, которое объект посылает самому себе, при этом стрелка сообщения указывает на ту же самую линию жизни.
Рис. 7. Пример диаграммы последовательности
Диаграмма кооперации (collaboration diagram)
Диаграммы кооперации отображают поток событий через конкретный сценарий варианта использования, упорядочены по времени, а кооперативные диаграммы больше внимания заостряют на связях между объектами.
На диаграмме кооперации представлена вся та информация, которая есть и на диаграмме последовательности, но кооперативная диаграмма по-другому описывает поток событий. Из нее легче понять связи между объектами, однако, труднее уяснить последовательность событий.
На кооперативной диаграмме так же, как и на диаграмме последовательности, стрелки обозначают сообщения, обмен которыми осуществляется в рамках данного варианта использования. Их временная последовательность указывается путем нумерации сообщений.
Рис. 8. Пример диаграммы кооперации
Диаграммы классов
Общие сведения
Диаграмма классов определяет типы классов системы и различного рода статические связи, которые существуют между ними. На диаграммах классов изображаются также атрибуты классов, операции классов и ограничения, которые накладываются на связи между классами.
Диаграмма классов UML - это граф, узлами которого являются элементы статической структуры проекта (классы, интерфейсы), а дугами - отношения между узлами (ассоциации, наследование, зависимости).
На диаграмме классов изображаются следующие элементы:
Класс
Класс - это группа сущностей (объектов), обладающих сходными свойствами, а именно, данными и поведением. Отдельный представитель некоторого класса называется объектом класса или просто объектом.
Под поведением объекта в UML понимаются любые правила взаимодействия объекта с внешним миром и с данными самого объекта.
На диаграммах класс изображается в виде прямоугольника со сплошной границей, разделенного горизонтальными линиями на 3 секции:
Любая из секций атрибутов и операций может не изображаться (а также обе сразу). Для отсутствующей секции не нужно рисовать разделительную линию и как-либо указывать на наличие или отсутствие элементов в ней.
На усмотрение конкретной реализации могут быть введены дополнительные секции, например, исключения (Exceptions).
Рис. 9. Пример диаграммы классов
Стереотипы классов
Стереотипы классов – это механизм, позволяющий разделять классы на категории.
В языке UML определены три основных стереотипа классов:
Граничные классы
Граничными классами (boundary classes) называются такие классы, которые расположены на границе системы и всей окружающей среды. Это экранные формы, отчеты, интерфейсы с аппаратурой (такой как принтеры или сканеры) и интерфейсы с другими системами.
Чтобы найти граничные классы, надо исследовать диаграммы вариантов использования. Каждому взаимодействию между действующим лицом и вариантом использования должен соответствовать, по крайней мере, один граничный класс. Именно такой класс позволяет действующему лицу взаимодействовать с системой.
Классы-сущности
Классы-сущности (entity classes) содержат хранимую информацию. Они имеют наибольшее значение для пользователя, и потому в их названиях часто используют термины из предметной области. Обычно для каждого класса-сущности создают таблицу в базе данных.
Управляющие классы
Управляющие классы (control classes) отвечают за координацию действий других классов. Обычно у каждого варианта использования имеется один управляющий класс, контролирующий последовательность событий этого варианта использования. Управляющий класс отвечает за координацию, но сам не несет в себе никакой функциональности, так как остальные классы не посылают ему большого количества сообщений. Вместо этого он сам посылает множество сообщений. Управляющий класс просто делегирует ответственность другим классам, по этой причине его часто называют классом-менеджером.
В системе могут быть и другие управляющие классы, общие для нескольких вариантов использования. Например, может быть класс SecurityManager (менеджер безопасности), отвечающий за контроль событий, связанных с безопасностью. Класс TransactionManager (менеджер транзакций) занимается координацией сообщений, относящихся к транзакциям с базой данных. Могут быть и другие менеджеры для работы с другими элементами функционирования системы, такими как разделение ресурсов, распределенная обработка данных или обработка ошибок.
Помимо упомянутых выше стереотипов можно создавать и свои собственные.
Атрибуты
Атрибут – это элемент информации, связанный с классом. Атрибуты хранят инкапсулированные данные класса.
Так как атрибуты содержатся внутри класса, они скрыты от других классов. В связи с этим может понадобиться указать, какие классы имеют право читать и изменять атрибуты. Это свойство называется видимостью атрибута (attribute visibility).
У атрибута можно определить четыре возможных значения этого параметра:
В общем случае, атрибуты рекомендуется делать закрытыми или защищенными. Это позволяет лучше контролировать сам атрибут и код.
С помощью закрытости или защищенности удается избежать ситуации, когда значение атрибута изменяется всеми классами системы. Вместо этого логика изменения атрибута будет заключена в том же классе, что и сам этот атрибут. Задаваемые параметры видимости повлияют на генерируемый код.
Операции
Операции реализуют связанное с классом поведение. Операция включает три части – имя, параметры и тип возвращаемого значения.
Параметры – это аргументы, получаемые операцией «на входе». Тип возвращаемого значения относится к результату действия операции.
На диаграмме классов можно показывать как имена операций, так и имена операций вместе с их параметрами и типом возвращаемого значения. Чтобы уменьшить загруженность диаграммы, полезно бывает на некоторых из них показывать только имена операций, а на других их полную сигнатуру.
В языке UML операции имеют следующую нотацию:
Имя Операции (аргумент: тип данных аргумента, аргумент2:тип данных аргумента2,...): тип возвращаемого значения
Следует рассмотреть четыре различных типа операций:
Операции реализации
Операции реализации (implementor operations) реализуют некоторые бизнес-функции. Такие операции можно найти, исследуя диаграммы взаимодействия. Диаграммы этого типа фокусируются на бизнес-функциях, и каждое сообщение диаграммы, скорее всего, можно соотнести с операцией реализации.
Каждая операция реализации должна быть легко прослеживаема до соответствующего требования. Это достигается на различных этапах моделирования. Операция выводится из сообщения на диаграмме взаимодействия, сообщения исходят из подробного описания потока событий, который создается на основе варианта использования, а последний – на основе требований. Возможность проследить всю эту цепочку позволяет гарантировать, что каждое требование будет реализовано в коде, а каждый фрагмент кода реализует какое-то требование.
Операции управления
Операции управления (manager operations) управляют созданием и уничтожением объектов. В эту категорию попадают конструкторы и деструкторы классов.
Операции доступа
Атрибуты обычно бывают закрытыми или защищенными. Тем не менее, другие классы иногда должны просматривать или изменять их значения. Для этого существуют операции доступа (access operations). Такой подход дает возможность безопасно инкапсулировать атрибуты внутри класса, защитив их от других классов, но все же позволяет осуществить к ним контролируемый доступ. Создание операций Get и Set (получения и изменения значения) для каждого атрибута класса является стандартом.
Вспомогательные операции
Вспомогательными (helper operations) называются такие операции класса, которые необходимы ему для выполнения его ответственностей, но о которых другие классы не должны ничего знать. Это закрытые и защищенные операции класса.
Чтобы идентифицировать операции, выполните следующие действия:
Связи
Связь представляет собой семантическую взаимосвязь между классами. Она дает классу возможность узнавать об атрибутах, операциях и связях другого класса. Иными словами, чтобы один класс мог послать сообщение другому на диаграмме последовательности или кооперативной диаграмме, между ними должна существовать связь.
Существуют четыре типа связей, которые могут быть установлены между классами: ассоциации, зависимости, агрегации и обобщения.
Ассоциации
Ассоциация (association) – это семантическая связь между классами. Их рисуют на диаграмме классов в виде обыкновенной линии.
Рис. 10. Связь ассоциация
Ассоциации могут быть двунаправленными, как в примере, или однонаправленными. На языке UML двунаправленные ассоциации рисуют в виде простой линии без стрелок или со стрелками с обеих ее сторон. На однонаправленной ассоциации изображают только одну стрелку, показывающую ее направление.
Направление ассоциации можно определить, изучая диаграммы последовательности и кооперативные диаграммы. Если все сообщения на них отправляются только одним классом и принимаются только другим классом, но не наоборот, между этими классами имеет место однонаправленная связь. Если хотя бы одно сообщение отправляется в обратную сторону, ассоциация должна быть двунаправленной.
Ассоциации могут быть рефлексивными. Рефлексивная ассоциация предполагает, что один экземпляр класса взаимодействует с другими экземплярами этого же класса.
Зависимости
Связи зависимости (dependency) также отражают связь между классами, но они всегда однонаправлены и показывают, что один класс зависит от определений, сделанных в другом. Например, класс A использует методы класса B. Тогда при изменении класса B необходимо произвести соответствующие изменения в классе A.
Зависимость изображается пунктирной линией, проведенной между двумя элементами диаграммы, и считается, что элемент, привязанный к концу стрелки, зависит от элемента, привязанного к началу этой стрелки.
Рис. 11. Связь зависимость
При генерации кода для этих классов к ним не будут добавляться новые атрибуты. Однако, будут созданы специфические для языка операторы, необходимые для поддержки связи.
Агрегации
Агрегации (aggregations) представляют собой более тесную форму ассоциации. Агрегация – это связь между целым и его частью. Например, у вас может быть класс Автомобиль, а также классы Двигатель, Покрышки и классы для других частей автомобиля. В результате объект класса Автомобиль будет состоять из объекта класса Двигатель, четырех объектов Покрышек и т. д. Агрегации визуализируют в виде линии с ромбиком у класса, являющегося целым:
Рис. 11. Связь агрегация
В дополнение к простой агрегации UML вводит более сильную разновидность агрегации, называемую композицией. Согласно композиции, объект-часть может принадлежать только единственному целому, и, кроме того, как правило, жизненный цикл частей совпадает с циклом целого: они живут и умирают вместе с ним. Любое удаление целого распространяется на его части.
Такое каскадное удаление нередко рассматривается как часть определения агрегации, однако оно всегда подразумевается в том случае, когда множественность роли составляет 1..1; например, если необходимо удалить Клиента, то это удаление должно распространиться и на Заказы (и, в свою очередь, на Строки заказа).
Обобщения (Наследование)
Обобщение (наследование) - это отношение типа общее-частное между элементами модели. С помощью обобщений (generalization) показывают связи наследования между двумя классами. Большинство объектно-ориентированных языков непосредственно поддерживают концепцию наследования. Она позволяет одному классу наследовать все атрибуты, операции и связи другого. Наследование пакетов означает, что в пакете-наследнике все сущности пакета-предка будут видны под своими собственными именами (т.е. пространства имен объединяются). Наследование показывается сплошной линией, идущей от класса-потомка к классу-предку (в терминологии ООП - от потомка к предку, от сына к отцу, или от подкласса к суперклассу). Со стороны более общего элемента рисуется большой полый треугольник.
Рис. 12. Пример связи наследование
Помимо наследуемых, каждый подкласс имеет свои собственные уникальные атрибуты, операции и связи.
Множественность
Множественность (multiplicity) показывает, сколько экземпляров одного класса взаимодействуют с помощью этой связи с одним экземпляром другого класса в данный момент времени.
Например, при разработке системы регистрации курсов в университете можно определить классы Course (курс) и Student (студент). Между ними установлена связь: у курсов могут быть студенты, а у студентов – курсы. Вопросы, на который должен ответить параметр множественности: «Сколько курсов студент может посещать в данный момент? Сколько студентов может за раз посещать один курс?»
Так как множественность дает ответ на оба эти вопроса, её индикаторы устанавливаются на обоих концах линии связи. В примере регистрации курсов мы решили, что один студент может посещать от нуля до четырех курсов, а один курс могут слушать от 0 до 20 студентов.
В языке UML приняты определенные нотации для обозначения множественности.
Таблица 1 - Обозначения множественности связей в UML
Имена связей
Связи можно уточнить с помощью имен связей или ролевых имен. Имя связи – это обычно глагол или глагольная фраза, описывающая, зачем она нужна. Например, между классом Person (человек) и классом Company (компания) может существовать ассоциация. Можно задать в связи с этим вопрос, является ли объект класса Person клиентом компании, её сотрудником или владельцем? Чтобы определить это, ассоциацию можно назвать «employs» (нанимает):
Рис. 13. Пример имен связей
Роли
Ролевые имена применяют в связях ассоциации или агрегации вместо имен для описания того, зачем эти связи нужны. Возвращаясь к примеру с классами Person и Company, можно сказать, что класс Person играет роль сотрудника класса Company. Ролевые имена – это обычно имена существительные или основанные на них фразы, их показывают на диаграмме рядом с классом, играющим соответствующую роль. Как правило, пользуются или ролевым именем, или именем связи, но не обоими сразу. Как и имена связей, ролевые имена не обязательны, их дают, только если цель связи не очевидна. Пример ролей приводится ниже:
Рис. 14. Пример ролей связей
Пакет. Механизм пакетов
В контексте диаграмм классов, пакет - это вместилище для некоторого набора классов и других пакетов. Пакет является самостоятельным пространством имен.
Рис. 15. Обозначение пакета в UML
В UML нет каких-либо ограничений на правила, по которым разработчики могут или должны группировать классы в пакеты. Но есть некоторые стандартные случаи, когда такая группировка уместна, например, тесно взаимодействующие классы, или более общий случай - разбиение системы на подсистемы.
Пакет физически содержит сущности, определенные в нем (говорят, что "сущности принадлежат пакету"). Это означает, что если будет уничтожен пакет, то будут уничтожено и все его содержимое.
Существует несколько наиболее распространенных подходов к группировке.
Во-первых, можно группировать их по стереотипу. В таком случае получается один пакет с классами-сущностями, один с граничными классами, один с управляющими классами и т.д. Этот подход может быть полезен с точки зрения размещения готовой системы, поскольку все находящиеся на клиентских машинах пограничные классы уже оказываются в одном пакете.
Другой подход заключается в объединении классов по их функциональности. Например, в пакете Security (безопасность) содержатся все классы, отвечающие за безопасность приложения. В таком случае другие пакеты могут называться Employee Maintenance (Работа с сотрудниками), Reporting (Подготовка отчетов) и Error Handling (Обработка ошибок). Преимущество этого подхода заключается в возможности повторного использования.
Механизм пакетов применим к любым элементам модели, а не только к классам. Если для группировки классов не использовать некоторые эвристики, то она становится произвольной. Одна из них, которая в основном используется в UML, – это зависимость. Зависимость между двумя пакетами существует в том случае, если между любыми двумя классами в пакетах существует любая зависимость.
Таким образом, диаграмма пакетов представляет собой диаграмму, содержащую пакеты классов и зависимости между ними. Строго говоря, пакеты и зависимости являются элементами диаграммы классов, то есть диаграмма пакетов – это форма диаграммы классов.
Рис. 16. Пример диаграммы пакетов
Зависимость между двумя элементами имеет место в том случае, если изменения в определении одного элемента могут повлечь за собой изменения в другом. Что касается классов, то причины для зависимостей могут быть самыми разными:
Если класс меняет свой интерфейс, то любое сообщение, которое он посылает, может утратить свою силу.
Пакеты не дают ответа на вопрос, каким образом можно уменьшить количество зависимостей в вашей системе, однако они помогают выделить эти зависимости, а после того, как они все окажутся на виду, остается только поработать над снижением их количества. Диаграммы пакетов можно считать основным средством управления общей структурой системы.
Пакеты являются жизненно необходимым средством для больших проектов. Их следует использовать в тех случаях, когда диаграмма классов, охватывающая всю систему в целом и размещенная на единственном листе бумаги формата А4, становится нечитаемой.
Диаграммы состояний
Диаграммы состояний определяют все возможные состояния, в которых может находиться конкретный объект, а также процесс смены состояний объекта в результате наступления некоторых событий.
Существует много форм диаграмм состояний, незначительно отличающихся друг от друга семантикой.
На диаграмме имеются два специальных состояния – начальное (start) и конечное (stop). Начальное состояние выделено черной точкой, оно соответствует состоянию объекта, когда он только что был создан. Конечное состояние обозначается черной точкой в белом кружке, оно соответствует состоянию объекта непосредственно перед его уничтожением. На диаграмме состояний может быть одно и только одно начальное состояние. В то же время, может быть столько конечных состояний, сколько вам нужно, или их может не быть вообще. Когда объект находится в каком-то конкретном состоянии, могут выполняться различные процессы. Процессы, происходящие, когда объект находится в определенном состоянии, называются действиями (actions).
С состоянием можно связывать данные пяти типов: деятельность, входное действие, выходное действие, событие и история состояния.
Деятельность
Деятельностью (activity) называется поведение, реализуемое объектом, пока он находится в данном состоянии. Деятельность – это прерываемое поведение. Оно может выполняться до своего завершения, пока объект находится в данном состоянии, или может быть прервано переходом объекта в другое состояние. Деятельность изображают внутри самого состояния, ей должно предшествовать слово do (делать) и двоеточие.
Входное действие
Входным действием (entry action) называется поведение, которое выполняется, когда объект переходит в данное состояние. Данное действие осуществляется не после того, как объект перешел в это состояние, а, скорее, как часть этого перехода. В отличие от деятельности, входное действие рассматривается как непрерываемое. Входное действие также показывают внутри состояния, ему предшествует слово entry (вход) и двоеточие.
Выходное действие
Выходное действие (exit action) подобно входному. Однако, оно осуществляется как составная часть процесса выхода из данного состояния. Оно является частью процесса такого перехода. Как и входное, выходное действие является непрерываемым.
Выходное действие изображают внутри состояния, ему предшествует слово exit (выход) и двоеточие.
Поведение объекта во время деятельности, при входных и выходных действиях может включать отправку события другому объекту. В этом случае описанию деятельности, входного действия или выходного действия предшествует знак « ^ ».
Соответствующая строка на диаграмме выглядит как
Do: ^Цель.Событие (Аргументы)
Здесь Цель – это объект, получающий событие, Событие – это посылаемое сообщение, а Аргументы являются параметрами посылаемого сообщения.
Деятельность может также выполняться в результате получения объектом некоторого события. При получении некоторого события выполняется определенная деятельность.
Переходом (Transition) называется перемещение из одного состояния в другое. Совокупность переходов диаграммы показывает, как объект может перемещаться между своими состояниями. На диаграмме все переходы изображают в виде стрелки, начинающейся на первоначальном состоянии и заканчивающейся последующим.
Переходы могут быть рефлексивными. Объект может перейти в то же состояние, в котором он в настоящий момент находится. Рефлексивные переходы изображают в виде стрелки, начинающейся и завершающейся на одном и том же состоянии.
У перехода существует несколько спецификаций. Они включают события, аргументы, ограждающие условия, действия и посылаемые события.
События
Событие (event) – это то, что вызывает переход из одного состояния в другое. Событие размещают на диаграмме вдоль линии перехода.
На диаграмме для отображения события можно использовать как имя операции, так и обычную фразу.
Большинство переходов должны иметь события, так как именно они, прежде всего, заставляют переход осуществиться. Тем не менее, бывают и автоматические переходы, не имеющие событий. При этом объект сам перемещается из одного состояния в другое со скоростью, позволяющей осуществиться входным действиям, деятельности и выходным действиям.
Ограждающие условия
Ограждающие условия (guard conditions) определяют, когда переход может, а когда не может осуществиться. В противном случае переход не осуществится.
Ограждающие условия изображают на диаграмме вдоль линии перехода после имени события, заключая их в квадратные скобки.
Ограждающие условия задавать необязательно. Однако если существует несколько автоматических переходов из состояния, необходимо определить для них взаимно исключающие ограждающие условия. Это поможет читателю диаграммы понять, какой путь перехода будет автоматически выбран.
Действие
Действием (action), как уже говорилось, является непрерываемое поведение, осуществляющееся как часть перехода. Входные и выходные действия показывают внутри состояний, поскольку они определяют, что происходит, когда объект входит или выходит из него. Большую часть действий, однако, изображают вдоль линии перехода, так как они не должны осуществляться при входе или выходе из состояния.
Действие рисуют вдоль линии перехода после имени события, ему предшествует косая черта.
Событие или действие могут быть поведением внутри объекта, а могут представлять собой сообщение, посылаемое другому объекту. Если событие или действие посылается другому объекту, перед ним на диаграмме помещают знак « ^ ».
Рис. 17. Пример диаграммы состояний
Диаграммы состояний не надо создавать для каждого класса, они применяются только в сложных случаях. Если объект класса может существовать в нескольких состояниях и в каждом из них ведет себя по-разному, для него может потребоваться такая диаграмма.
Диаграммы размещения
Диаграмма размещения (deployment diagram) отражает физические взаимосвязи между программными и аппаратными компонентами системы. Она является хорошим средством для того, чтобы показать маршруты перемещения объектов и компонентов в распределенной системе.
Каждый узел на диаграмме размещения представляет собой некоторый тип вычислительного устройства – в большинстве случаев, часть аппаратуры. Эта аппаратура может быть простым устройством или датчиком, а может быть и мэйнфреймом.
Диаграмма размещения показывает физическое расположение сети и местонахождение в ней различных компонентов.
Рис. 19. Пример диаграммы размещения
Диаграмма размещения используется менеджером проекта, пользователями, архитектором системы и эксплуатационным персоналом, чтобы понять физическое размещение системы и расположение её отдельных подсистем.
Диаграммы компонентов
Диаграммы компонентов показывают, как выглядит модель на физическом уровне. На них изображены компоненты программного обеспечения и связи между ними. При этом на такой диаграмме выделяют два типа компонентов: исполняемые компоненты и библиотеки кода.
Каждый класс модели (или подсистема) преобразуется в компонент исходного кода. После создания они сразу добавляются к диаграмме компонентов. Между отдельными компонентами изображают зависимости, соответствующие зависимостям на этапе компиляции или выполнения программы.
Рис. 18. Пример диаграммы компонентов
Диаграммы компонентов применяются теми участниками проекта, кто отвечает за компиляцию системы. Из нее видно, в каком порядке надо компилировать компоненты, а также какие исполняемые компоненты будут созданы системой. На такой диаграмме показано соответствие классов реализованным компонентам. Она нужна там, где начинается генерация кода.
Объединение диаграмм компонентов и развертывания
В некоторых случаях допускается размещать диаграмму компонентов на диаграмме развертывания. Это позволяет показать какие компоненты выполняются и на каких узлах.
Словарь UML включает два вида блоков:
Оценка диаграммы производится по формуле: , где
S – оценка диаграммы,
Sobj – оценка элементов диаграммы,
Slink – оценка связей на диаграмме,
Obj – количество объектов на диаграмме,
Tobj – количество типов объектов,
Tlink – количество типов связей.
Если диаграмма содержит большое число связей одного типа, то их можно не учитывать.
Если на диаграмме класса указываются для каждого класса атрибуты и операции, то к оценке класса добавляется следующая составляющая:
, где
Op – число операций класса,
Atr – число атрибутов класса,
Op – количество операций,
Atr – количество атрибутов.
Оценки основных элементовUML
|
Тип элемента |
Оценка элемента |
|
Класс class |
5 |
|
Интерфейс interface |
4 |
|
Сценарий use-case |
2 |
|
Компонент component |
4 |
|
Узел node |
3 |
|
Взаимодействие interaction |
6 |
|
Пакет package |
4 |
|
Состояние state |
4 |
|
Примечание note |
2 |
Оценки основных типов связей
|
Тип связи |
Оценка связи |
|
Зависимость dependency |
2 |
|
Ассоциация association |
1 |
|
Агрегирование aggregation |
2 |
|
Композиция composition |
3 |
|
Обобщение generalization |
3 |
|
Реализация realization |
2 |
Остальные типы связей рассматриваются как ассоциации.
Оценка диаграммы должна попадать в оптимальный диапазон, иначе диаграмма или слишком краткая, или перегружена информацией.
Диапазоны оптимальных оценок диаграмм.
|
Class – диаграмма классов с атрибутами и операциями |
5-5,5 |
|
Class - диаграмма классов без атрибутов и операций |
3-3,5 |
|
Component – диаграмма компонентов |
3,5-4 |
|
Use case - диаграмма вариантов использования |
2,5-3 |
|
Deployment - диаграмма развёртывания |
2-2,5 |
|
Sequences - диаграмма последовательности |
3-3,5 |
|
Cooperative - диаграмма кооперации |
3,5-4 |
|
Package - диаграмма пакетов |
3,5-4 |
|
State – диаграмма состояния |
2,5-3 |
Примеры:
контролёр
база
оператор
БД Студентов
=1
Работодатель
Название фирмы
Доска объявл.
Пользователь
Преподаватель
Студент
=1
=2
=2
=2
оценка классов оценка связей
Если оценка не попадает в рекомендуемый диапазон, нужно диаграмму доработать, либо добавить информацию, либо убрать лишнюю.
Литература
ПРИЛОЖЕНИЕ. Пример выполнения курсовой работы
|
Проектирование информационной системы «Охранная фирма» с помощью языка UML |
Содержание:
Введение…………………………………………………………………………………
Краткая информация о аппарате проектирования……………………………
Диаграмма Use-case …………………………………………………..
Диаграмма классов……………………………………………………
Диаграммы последовательностей……………………………………
Диаграммы состояний………………………………………………..
Диаграммы видов деятельности…………………………………….
Диаграмма размещения…………………………………...................
Диаграмма пакетов………………………………………………….
Приложение «Результаты автоматической генерации текстов программ» (Коды)………….
Введение.
Создание крупных программных систем ставит перед разработчиками много проблем, часть из которых не может быть эффективно решена классическими средствами структурного подхода. Окружающий мир состоит из объектов, поэтому вполне логичным выглядит стремление перенести подобный метод представления информации о предметной области в программирование.
Один из путей решения задачи эффективной жизнедеятельности в рамках безгранично сложного окружающего нас мира – это создание упрощенных моделей, их анализ и прогнозирование. В данном курсовом проекте мы обратимся к вопросу построению и анализу определенной информационной системы. В качестве предметной области мы рассмотрим «Охранную фирму». Первой задачей данной работы является построение соответствующих диаграмм и схем. Этот анализ будет производится с помощью специализированного программного обеспечения. IBM Rational Rose – программный пакет для создания диаграмм нотации UML(англ. Unified Modeling Language — унифицированный язык моделирования), мощный инструмент построения и анализа различных диаграмм и средств с полным набором графических средств и инструментов.
2. Описание функций Информационной системы:
1)Получение лицензии
2)Сотрудничество с заказчиками
Поиск
Составление договоров
Получение объектов
Работа на объектах
Получение средств на банковский счет
3)Сотрудничество с магазином специализированной охранной одежды
Перечисление средств магазину
Получение охранной одежды
4)Прием на работу охранников
Проверка документов
Составление договоров
Назначение на объекты
Служба охранников на объектах
Выдача заработной платы
6)Составление отчетности по фирме
Обработка проделанной работы
Составление акта проделанных работ
Составление отчета в налоговую службу
Составление отчета в ОРЛЛ
3. Описание аппарата проектирования.
UML (Unified Modeling Language — унифицированный язык моделирования) — язык графического описания для объектного моделирования в области разработки программного обеспечения. UML - это открытый стандарт, использующий графические обозначения для создания абстрактной модели системы, называемой UML-моделью. UML был создан для определения, визуализации, проектирования и документирования в основном программных систем.
UML использую не только для разработки программного обеспечения, но также используют для моделирования бизнес-процессов.
UML дает общее соглашение между разработчиками, что такое класс, компоненты и т.д.
В 1994 году Гради Буч и Джеймс Рамбо, работавшие в компании Rational Software, объединили свои усилия для создания нового языка объектно-ориентированного моделирования. За основу языка ими были взяты методы моделирования, разработанные Бучем и Рамбо (Object-Modeling Technique, OMT). OMT был ориентирован на анализ, а Booch — на проектирование программных систем. В октябре 1995 года была выпущена предварительная версия 0.8 унифицированного метода (англ. Unified Method). Осенью 1995 года к компании Rational присоединился Айвар Якобсон, автор метода Object-Oriented Software Engineering — OOSE. OOSE обеспечивал превосходные возможности для спецификации бизнес-процессов и анализа требований при помощи сценариев использования. OOSE был также интегрирован в унифицированный метод.
На этом этапе основная роль в организации процесса разработки UML перешла к консорциуму OMG (Object Management Group). Группа разработчиков в OMG, в которую также входили Буч, Рамбо и Якобсон, выпустила спецификации UML версий 0.9 и 0.91 в июне и октябре 1996 года.
На волне растущего интереса к UML к разработке новых версий языка в рамках консорциума UML Partners присоединились такие компании, как Digital Equipment Corporation, Hewlett-Packard, i-Logix, IntelliCorp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle Corporation, Rational Software, Texas Instruments и Unisys. Результатом совместной работы стала спецификация UML 1.0, вышедшая в январе 1997 года. В ноябре того же года за ней последовала версия 1.1, содержавшая улучшения нотации, а также некоторые расширения семантики.
Последующие релизы UML включали версии 1.3, 1.4 и 1.5, опубликованные, соответственно в июне 1999, сентябре 2001 и марте 2003 года.
Формальная спецификация последней версии UML 2.0 опубликована в августе 2005 года. Семантика языка была значительно уточнена и расширена для поддержки методологии Model Driven Development — MDD (англ.). Последняя версия UML 2.3 опубликована в мае 2010 года.
UML 1.4.2 принят в качестве международного стандарта ISO/IEC 19501:2005.
Ниже приведен список наиболее использующих диаграмм.
Структурные диаграммы:
Диаграммы поведения:
3.5. Недостатки языка UML
Несмотря на то, что UML достаточно широко распространённый и используемый стандарт, его часто критикуют из-за следующих недостатков:
3.6.CASE-средства.
Аббревиатура CASE расшифровывается как Computer Aided Software Engineering(Автоматизированная Разработка Программного Обеспечения). CASE средства подразумевают процесс разработки сложных ИС в целом: создание и сопровождение ИС, анализ, формулировка требований, проектирование прикладного ПО и баз данных, генерацию кода, тестирование, документирование, обеспечение качества, конфигурационное управление и управление проектом, а также другие процессы. Таким образом, CASE-технологии образуют целую среду разработки ИС.
Большинство существующих CASE-средств основано на методологиях структурного или объектно-ориентированного анализа и проектирования, использующих спецификации в виде диаграмм или текстов для описания внешних требований, связей между моделями системы, динамики поведения системы и архитектуры программных средств. Главные составляющие CASE-продукта таковы:
Разумеется, существуют свои недостатки применения технологий, значимыми являются недостатки со стороны аспектов бизнеса:
Ряд преимуществ созданной системы:
Rational Rose - CASE-средство фирмы Rational Software Corporation - предназначено для автоматизации этапов анализа и проектирования ПО, а также для генерации кодов на различных языках и выпуска проектной документации. Rational Rose использует синтез-методологию объектно-ориентированного анализа и проектирования, основанную на подходах трех ведущих специалистов в данной области: Буча, Рамбо и Джекобсона. Разработанная ими универсальная нотация для моделирования объектов (UML - Unified Modeling Language) претендует на роль стандарта в области объектно-ориентированного анализа и проектирования. Конкретный вариант Rational Rose определяется языком, на котором генерируются коды программ (C++, Smalltalk, PowerBuilder, Ada, SQLWindows и ObjectPro). Основной вариант - Rational Rose/C++ - позволяет разрабатывать проектную документацию в виде диаграмм и спецификаций, а также генерировать программные коды на С++. Кроме того, Rational Rose содержит средства реинжиниринга программ, обеспечивающие повторное использование программных компонент в новых проектах.
4. Разработка ПО информационной системы “Охранная фирма”.
4.1.Use-case диаграмма (диаграмма вариантов использования, сценариев, прецедентов). Диаграммы позволяют наглядно представить ожидаемое поведение системы. Элементы, используемые на диаграмме:
Диаграммы Use Case по концепции напоминают классические DFD диаграммы, также применяемые для структурного анализа. Use Case также отображают границы исследуемой системы, её функциональность и определяют сущности и процессы, а также пользователей системы. При составлении этих диаграмм существует некоторая неопределённость. Она состоит в проблеме определения различий между сущностями и пользователями системы, а также её администраторами. Диаграммы Use Case чаще всего используются на этапе трансформации логической архитектуры системы в концептуальную модель, реализуемую при объектном подходе с определением событийной структуры управления будущим программным проектом.
Расчет оценки диаграммы.
Sdiagr= ,
где Sobj-оценка элемента на диаграмме, Slink- оценка связей, Оbj- кол-во объектов на диаграмме, Tobj –количество типов объектов, Tlink- количество типов связи.
S diagram=
Рис.1 Общая USE-CASE диаграмма
4.2.Диаграмма классов.
Диаграмма классов (Class diagram) — статическая структурная диаграмма, описывающая структуру системы, она демонстрирует классы системы, их атрибуты, методы и зависимости между классами.Существуют разные точки зрения на построение диаграмм классов в зависимости от целей их применения:
Элементы:
1)Класс - множество объектов, обладающие одинаковой структурой, поведением и отношением с другими классами.
Атрибуты-параметры класса(переменные).
Операции(методы)- функции, которые может выполнить класс или которые можно выполнить относительно него.
2)Связи между классами – поведенческие сущности, взаимодействие объектов. (Зависимость, обобщение, ассоциация, агрегирование, композиция, реализация.)
Расчет оценки диаграммы.
Sdiagr= ,
где Sobj-оценка элемента на диаграмме, Slink- оценка связей, Оbj- кол-во объектов на диаграмме, Tobj –количество типов объектов, Tlink- количество типов связи.
Sclas = , где Op- количество операций, Atr- количество атрибутов.
Рис 2. Диаграмма классов
S diagram=
S(Oxrannik)=
S(Lichnii_sostav)=
S(Spisok_ob’ektov)=
S(Ob’ekt)=
S(Spisok_zakazchikov)=
S(Otdel_kadrov)=
S(Bank_schet)=
S(Zakazchik)=
S(Zam_directora)=
S(Gen_direktor)=
4.3.Диаграммы последовательностей.
Диаграммы последовательностей (англ. Sequence diagram) — диаграмма, на которой показаны взаимодействия объектов, упорядоченные по времени их проявления. Основными элементами диаграммы последовательностей являются обозначения объектов (прямоугольники), вертикальные линии (англ. lifeline), отображающие течение времени при деятельности объекта, и стрелки, показывающие выполнение действий объектами.
Объекты - это информационные единицы, участвующие в сценарии. Первым указывается объект, который является инициатором данного сценария. Объекты обмениваются сообщениями, порядок их указывается.
На данной диаграмме объекты располагаются слева направо.
рис3. Диаграмма последовательностей для сценария “Выдача зарплаты”.
S diagram=
Рис 4. Диаграмма последовательностей для сценария “Назначение на объект”.
S diagram=
Рис 5. Диаграмма последовательностей для сценария “Перечисление средств”.
S diagram=
Рис 6. Диаграмма последовательностей для сценария “Подписание договоров”.
S diagram=
Рис 7. Диаграмма последовательностей для сценария “Получение лицензии”.
S diagram=
Рис 8. Диаграмма последовательностей для сценария “Предоставление формы”.
S diagram=
Рис 9. Диаграмма последовательностей для сценария “Прием на работу ”.
S diagram=
Рис 10. Диаграмма последовательностей для сценария “Составление акта выполненных работ ”.
S diagram=
Рис 11. Диаграмма последовательностей для сценария “Составление отчета в налоговую”.
S diagram=
Рис 12. Диаграмма последовательностей для сценария “Составление отчета в ОРЛЛ”.
S diagram=
4.4.Диаграммы состояний(Statechar diagram)
Диаграмма состояний(Statechar diagram) определяют все возможные состояния, в которых может находиться конкретный объект, а также процесс смены состояний объекта в результате наступления некоторых событий.
Существует много форм диаграмм состояний, незначительно отличающихся друг от друга семантикой.
На диаграмме имеются два специальных состояния – начальное (start) и конечное (stop). Начальное состояние выделено черной точкой, оно соответствует состоянию объекта, когда он только что был создан. Конечное состояние обозначается черной точкой в белом кружке, оно соответствует состоянию объекта непосредственно перед его уничтожением. На диаграмме состояний может быть одно и только одно начальное состояние. В то же время, может быть столько конечных состояний, сколько вам нужно, или их может не быть вообще. Когда объект находится в каком-то конкретном состоянии, могут выполняться различные процессы. Процессы, происходящие, когда объект находится в определенном состоянии, называются действиями (actions).
С состоянием можно связывать данные пяти типов: деятельность, входное действие, выходное действие, событие и история состояния.
Рис 13. Диаграмма состояний для класса “Bank_schet’”
S diagram=
Рис 14. Диаграмма состояний для класса “Gen_director”
S diagram=
Рис 15. Диаграмма состояний для класса “Lichnii_sostav”
S diagram=
Рис 16. Диаграмма состояний для класса ‘Ob’ekt’”
S diagram=
Рис 17. Диаграмма состояний для класса “Otdel_kadrov”
S diagram=
Рис 18. Диаграмма состояний для класса “Oxrannik”
S diagram=
Рис 19. Диаграмма состояний для класса “Spisok_ob’ektov”
S diagram=
Рис 20. Диаграмма состояний для класса “Spisok_zakazchikov”
S diagram=
Рис 21. Диаграмма состояний для класса “Zakazchik”
S diagram=
Рис 22. Диаграмма состояний для класса “Zam_directora”
S diagram=
4.5 Диаграммы видов деятельности(Activity diagram)
Диаграммы видов деятельности(Activity diagram)-диаграмма, на которой показано разложение некоторой деятельности на ее составные части. Под деятельностью понимается спецификация исполняемого поведения в виде координированного последовательного и параллельного выполнения подчиненных элементов - вложенных видов деятельности и отдельных действий, соединенных между собой потоками, которые идут от выходов одного узла ко входам другого.
рис.23. Диаграмма видов деятельности. “Перечисление средств”.
S diagram=
рис.24. Диаграмма видов деятельности. “ Назначение охранника”.
S diagram=
рис.25. Диаграмма видов деятельности. “ Подача документов”.
S diagram=
рис.26. Диаграмма видов деятельности. “Получение зарплаты”.
S diagram=
рис.27. Диаграмма видов деятельности. “Сотрудничество с охранной фирмой”.
S diagram=
4.6.Диаграмма размещений (Диаграмма развертывания).
Диаграмма развертывания (Deployment diagram)- предназначена для визуализации элементов и компонентов программы, существующих лишь на этапе ее исполнения. Диаграмма развертывания отражает физические взаимосвязи между программными и аппаратными компонентами разрабатываемой системы. Каждый узел на диаграмме развертывания представляет собой некоторый тип вычислительного устройства - в большинстве случаев самостоятельную часть аппаратуры.
S =
4.7.Диаграмма пакетов (Package diagram)
Диаграмма пакетов(Package diagram)- структурная диаграмма, основным содержанием которой являются пакеты и отношения между ними. Диаграммы пакетов служат, в первую очередь, для организации элементов в группы по какому-либо признаку с целью упрощения структуры и организации работы с моделью системы. Строго говоря, пакеты и зависимости являются элементами диаграммы классов, т. е. диаграмма пакетов - это всего лишь форма диаграммы классов. Однако на практике причины построения таких диаграмм различны.
S diagram=
В данной курсовой работе спроектирована информационная система «Охранная фирма» в нотации UML с использованием Сase-средства IBM Rational Rose EnterPrise Edition. Система описана практически со всех возможных точек зрения, рассмотрены разные аспекты поведения системы, диаграммы сравнительно просты для чтения, методы описания результатов анализа и проектирования семантически близки к методам программирования на современных ОО-языках.
Данная работа дает возможность организовать качественное функционирование описанной информационной системы, позволяет автоматизировать процессы, что сэкономит и время, и средства.
7. Литература