Введение в UML. Краткая историческая справка. Диаграммы классов, диаграммы последовательностей.

Лекция 1. Введение в Объектно-ориентированный анализ, проектирование и программирование.

Список литературы

1. «Язык программирования Java», Кен Арнолд, Джеймс Гослинг, Дэвид Холмс

2. «Объектно - ориентированный анализ и проектирование с примерами приложений на С++», Гради Буч

3. «Приемы объектно-ориентированного проектирования. Паттерны проектирования», Э. Гамма, Р. Хелм, Р. Джонсон, Дж. Влиссидес

4. «UML. Основы. Краткое руководство по унифицированному языку моделирования», Мартин Фаулер и Кендалл Скотт

5. «Применение UML и шаблонов проектирования», Крэг Ларман

6. «Java. Эффективное программирование», Джошуа Блох

7. «Распределённые системы. Принципы и парадигмы», Э. Таненбаум, М. Ван Стеен

8. «Java Message Service Specification. Version 1.0.2», SUN Microsystems

9. RFC 1034 “Domain names - concepts and facilities”

10. RFC 1035 “Domain names - implementation and specification”

11. RFC 2251 “Lightweight Directory Access Protocol (v3)”

12. “Java Naming and Directory Interface TM Application Programming Interface (JNDI API)”, SUN Microsystems

13. RFC 1945 “Hypertext Transfer Protocol -- HTTP/1.0”

14. RFC2616 “Hypertext Transfer Protocol -- HTTP/1.1”

15. “Java Servlet Specification Version 2.3”, SUN Microsystems

16. “JDBC 3.0 Specification”, SUN Microsystems

17. "Hibernate in Action", Christian Bauer, Gavin King

18. “The Timeless Way of Building”, Christopher Alexander

19. «Применение шаблонов Java», Стивен Стерлинг, Олав Маассен

20. И. Д. Медведовский, Б. В. Семьянов, Д. Г. Леонов, А. В. Лукацкий "Атака из Internet"

21. Мартин Фаулер «Архитектура корпоративных приложений»

22. http://www.martinfowler.com/articles/injection.html

23. “Enterprise Integration Patterns”, Gregor Hope, Bobby Woolf

24. http://www.sei.cmu.edu

25. Pressman Roger S. Software Engineering: A Practitioner's Approach, 5_е издание. NY: McGraw_Hill. P. 225, 2001.

26. Dirk Krafzig, Karl Banke, Dirk Slama, “Enterprise SOA: Service-Oriented Architecture Best Practices”, Prentice Hall PTR, 2004

27. Java Transaction Processing: Design and Implementation. Mark Little, Jon Maron, Greg Pavlik

28. Roy Fielding, “Architectural Styles and the Design of Network-based Software Architectures”, UNIVERSITY OF CALIFORNIA, IRVINE, 2000

Введение в объектно-ориентированный анализ. Понятие объекта. Отношения между объектами.

В процессе своего развития, индустрия программного обеспечения прошла ряд этапов, характеризующихся постоянным повышением сложности создаваемого ПО. Одной из основных её задач является выработка способов упрощения работы со сложностью создаваемых систем.

Экспериментально показано, что человек может одновременно оперировать в среднем объектами, независимо от их внутренней сложности. Очевидно, что постоянное усложнение создаваемых систем вызывает необходимость борьбы со сложностью. Одним из наиболее популярных принципов борьбы со сложностью является принцип «разделяй и властвуй», т.е. сложная система разбивается на ряд простых подсистем, управлять или разрабатывать которыми по отдельности гораздо проще. Этот принцип носит название декомпозиции.

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

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

Несмотря на огромный шаг вперёд, данный подход не лишён недостатков, как то:

• большое дублирование функциональных блоков;
• невозможность абстрагирования в отношении функционирования блоков;
• слабая связь функциональных блоков с объектами внешнего мира.

С точки зрения восприятия человеком объектом может быть:

· осязаемый и (или) видимый предмет;

• нечто, воспринимаемое мышлением;
• нечто, на что направлена мысль или действие.

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

• функционально,
• стурктурно – композиция,
• отношениями обобщения, называемыми ещё наследованием или генерализацией.

Таким образом, можно считать, что статическая объектная модель выражается совокупностью объектов и заданных отношений наследования и композиции между ними.

Динамическая объектная модель выражается функциональными интерфейсами между объектами и порядком взаимодействия объектов друг с другом.

Термин объект в программном обеспечении впервые был введен в языке Simula.

Объект обладает состоянием, поведением и идентичностью; структура и поведение схожих объектов определяет общий для них класс; термины «экземпляр класса» и «объект» взаимозаменяемы.

Введение в UML. Краткая историческая справка. Диаграммы классов, диаграммы последовательностей.

UML появился на волне развития объектно-ориентированных технологий анализа и дизайна в конце 80-ых начале 90-ых годов. UML стандартизован OMG (Object Management Group) и на настоящий момент является стандартом.

UML это язык моделирования а не метод.

UML определяется нотацией (т.е. синтаксисом) и метамоделью (набором диаграмм).

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

• Необходимость в коммуникации между разработчиками (включая документацию);
• Обычный язык слишком неточен для обсуждения концептов дизайна, в то время как язык программирования слишком детальный. UML позволяет опустить незначимые детали и подчеркнуть значимые.
• Обучение объектно-ориентированным методикам;
• Диаграммы классов могут применяться для иллюстрации статических моделей классов;
• Диаграммы взаимодействия (Sequence, Collaboration) для иллюстрации динамических моделей системы;

Диаграмма классов описывает типы объектов в системе и их статические взаимоотношения. Существует два основных типа отношений между объектами:

• Ассоциации
• Подтипы

Кроме этого, диаграммы классов показывают атрибуты и операции над классами.

Для ассоциации может указываться навигация:

• Однонаправленная
• Двунаправленная

Диаграммы классов могут быть расширены с помощью стереотипов.

Атрибуты и операции могут быть помечены как доступные для класса (static scope), так и только для объекта (instance scope).

Дополнительно на диаграммах классов можно показывать зависимости между классами.

Можно показывать область видимости (visibility):

• + public
• - private
• # protected

Пример диаграммы классов:

Диаграммы взаимодействия описывают то, как группы объектов взаимодействуют друг с другом, т.е. представляют динамическую модель.

Существует два типа диаграмм взаимодействия:

• Sequence – диаграмма последовательности
• Collaboration – диаграмма сотрудничества

Sequence diagram

Вертикальная линия называется линией жизни объекта (object lifeline).

Каждое сообщение отображается в виде стрелки между двумя линиями жизни объектов.

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

• Condition – условие выполнения. Сообщение будет передано только при условии что condition==true.
• Iteration marker – итерация – указывает сколько раз передаётся сообщение (происходит вызов метода).

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

Асинхронные сообщения (вызовы методов) можно показывать «одноуголковой» стрелкой.

Пример Sequence Diagram:

Collaboration diagram

Объекты на таких диаграммах рисуются в виде прямоугольников, сообщения так же в виде стрелок. Однако, в отличие от sequence diagram на collaboration diagram порядок сообщений указывается с помощью номеров. И хотя нумерование сообщений не столь наглядна как последовательное отображение сообщений на sequence diagram, возможность пространственного расположения объектов предоставляет дополнительные преимущества, так как можно показать статические отношения между объектами, что способствует логической группировке объектов.

Пример Collaboration Diagram:

Дата добавления: 2015-10-24