Студопедия
Случайная страница | ТОМ-1 | ТОМ-2 | ТОМ-3
АвтомобилиАстрономияБиологияГеографияДом и садДругие языкиДругоеИнформатика
ИсторияКультураЛитератураЛогикаМатематикаМедицинаМеталлургияМеханика
ОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРелигияРиторика
СоциологияСпортСтроительствоТехнологияТуризмФизикаФилософияФинансы
ХимияЧерчениеЭкологияЭкономикаЭлектроника

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

Читайте также:
  1. A)можно изменить тип диаграммы, ряд данных, параметры диаграммы и т. д.
  2. II. Введение в нервную систему
  3. А. Введение
  4. В-5. Положительные направления электромагнитных величин, уравнения напряжения и векторные диаграммы источников и приемников электрической энергии
  5. Введение (Вход) во храм Пресвятой Владычицы нашей Богородицы и Приснодевы Марии
  6. Введение в Adobe Illustrator.
  7. Введение в Rational Unified Process

Лекция 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 определяется нотацией (т.е. синтаксисом) и метамоделью (набором диаграмм).

 

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

 

 

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

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

Sequence diagram

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

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

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

 

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

 

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

 

Пример Sequence Diagram:

 

Collaboration diagram

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

 

Пример Collaboration Diagram:

 

 


Дата добавления: 2015-10-24; просмотров: 207 | Нарушение авторских прав


Читайте в этой же книге: Мобильные агенты (Applets and other mobile code) | Введение в Web-приложения и сервлеты | Гранулярность (granularity) | Factory Method | Abstract Factory | Template Method | Структурные шаблоны | Аспектно-Ориентированное Программирование (Aspect Oriented Programming, AOP) | Подходы к межсистемной интеграции | Интеграция с помощью разделяемой базы данных |
<== предыдущая страница | следующая страница ==>
Бережливое производство с оглядкой на русский менталитет| Лекция 2. Основные определения ООП.

mybiblioteka.su - 2015-2024 год. (0.011 сек.)