Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:

Ответы к экзамену (Технология программирования)

.pdf
Скачиваний:
21
Добавлен:
13.02.2021
Размер:
2.12 Mб
Скачать

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

затраты на разработку ниже, т.к. команда ориентирована на код, а не на документацию и собрания.

Недостатки XP:

успех проекта зависит от вовлеченности заказчика, которой не так просто добиться;

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

успех XP сильно зависит от уровня программистов, методология работает только с senior специалистами;

менеджмент негативно относится к парному программированию, не понимая, почему он должен оплачивать двух программистов вместо одного;

регулярные встречи с программистами дорого обходятся заказчикам;

требует слишком сильных культурных изменений;

из-за недостатка структуры и документации не подходит для крупных проектов;

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

9.*ОСНОВНЫЕ ЭТАПЫ РАЗВИТИЯ ЯЗЫКА UML. ИСТОРИЯ РАЗВИТИЯ ЯЗЫКА UML

Октябрь 1994 г. – начало работы Г.Буча и Дж.Рамбо по унификации методов Booch и OMT (объединение достоинств этих методов).

Октябрь 1995 г. – проект унифицированного метода (Unified Method) версии 0.8.

Октябрь 1995 г. – присоединение А.Якобсона к Г.Бучу и Дж.Рамбо с целью интеграции метода OOSE с Unified Method 0.8.

21

Осень 1995 г. – поддержка разработки UML становится одной из целей консорциума OMG.

UML приобрёл статус второго стратегического направления в работе

OMG.

Июнь 1996 г. – появление первых документов по описанию UML 0.9.

Октябрь 1996 г. – появление UML 0.91.

Конец 1996 г. Rational Software учредила консорциум партнёром UML, куда входили такие компании, как HP, Microsoft, Oracle и др. Члены консорциума выделили ресурсы для разработки строгого определения версии 1.0 языка UML.

Январь 1997 г. – публикация документа с описанием UML 1.0

Ноябрь 1997 г. – принятие в качестве стандарта версии UML 1.1, предложенной RTP (большая ясность семантики по сравнению с UML 1.0).

2009 г. – появление версии UML 1.5, которая позволяла применять UML не только как язык моделирования, но и как язык программирования.

Текущей версией UML является 2.5, принятая на консорциуме OMG в июне 2015 г.

В настоящее время все вопросы дальнейшей разработки UML ведутся в рамках консорциума OMG.

Статус зыка UML определён как открытый для всех предложений по его доработке и совершенствованию.

Сам язык не является чьей-либо собственностью и не запатентован.

10.

*ВИЗУАЛЬНОЕ

ПРОЕКТИРОВАНИЕ.

МЕТОДОЛОГИЯ

 

 

 

 

ОБЪЕКТНО-ОРИЕНТИРОВАННОГО АНАЛИЗА И ПРОЕКТИРОВАНИЯ

(ООАП)

ОБЪЕКТНО-ОРИЕНТИРОВАННЫЙ АНАЛИЗ И ПРОЕКТИРОВАНИЕ (ООАП) -

технология разработки программных систем, в основу которых положена объектно-ориентированная методология представления предметной области в виде объектов, являющихся экземплярами соответствующих классов.

22

ВИЗУАЛЬНЫМ МОДЕЛИРОВАНИЕМ называется способ представления идей и проблем реального мира с помощью моделей. Модель помогает понять проблему всем участникам, задействованным в реализации проекта на различных этапах: заказчику, эксперту, аналитику, проектировщику, автору документации, программисту и др. Моделирование обеспечивает более точную оценку необходимых ресурсов, четкую проработку планов и эффективное функционирование создаваемых систем.

МОДЕЛЬ - абстракция физической системы, рассматриваемая с определенной точки зрения и представленная на некотором языке или в графической форме.

Полная модель сложной системы представляет собой определенное число взаимосвязанных представлений (views), каждое из которых адекватно отражает аспект поведения или структуры системы. При этом наиболее общими представлениями сложной системы принято считать статическое и динамическое, которые в свою очередь могут подразделяться на другие более частные.

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

АБСТРАГИРОВАНИЕ - одна из основных способностей человека, которая позволяет разбираться в сложных вещах.

Для построения сложной системы необходимо сначала разделить ее на несколько абстрактных представлений и построить модели, используя принятые обозначения – НОТАЦИЮ. Затем убедиться, что модели удовлетворяют всем потребностям системы, и постепенно добавлять детали для перехода от моделей к реализации.

Нотация является важной составляющей любой модели - она служит связующим звеном между процессами и выполняет три функции:

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

обеспечивает достаточную семантику, позволяющую охватить важные стратегические и тактические решения;

23

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

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

Разработка и использование моделей языка UML осуществляется в рамках общей концепции объектно-ориентированного анализа и проектирования, которая, в свою очередь, является обобщением методологии объектноориентированного программирования.

Методология объектно-ориентированного анализа и проектирования

ПРЕДМЕТНАЯ ОБЛАСТЬ - часть реального мира, которая имеет существенное значение или непосредственное отношение к процессу функционирования программы.

ОБЪЕКТНО-ОРИЕНТИРОВАННЫЙ АНАЛИЗ И ПРОЕКТИРОВАНИЕ

(ООАП,Object-Oriented Analysis/Design) - технология разработки программных систем, в основу которых положена объектно-ориентированная методология представления предметной области в виде объектов, являющихся экземплярами соответствующих классов.

Методология ООП

ООП - совокупность принципов, технологий, а также инструментальных средств для создания программных систем на основе архитектуры взаимодействия объектов.

Основные принципы ООП:

АБСТРАКЦИЯ (характеристика сущности, которая отличает ее от других сущностей);

Наследование (концепция ООП, согласно которой абстрактный тип данных может наследовать данные и функциональность некоторого существующего типа, способствуя повторному использованию компонентов ПО);

24

Инкапсуляция (характеризует сокрытие отдельных деталей внутреннего устройства классов от внешних по отношению к нему объектов или пользователей);

Полиморфизм (действия, выполняемые одноименными методами, могут различаться в зависимости от того, к какому из классов относится тот или иной метод).

КЛАСС - абстракция совокупности реальных объектов, которые имеют общий набор свойств и обладают одинаковым поведением.

ОБЪЕКТ - экземпляр класса.

11. *ОСНОВНЫЕ ЭЛЕМЕНТЫ ЯЗЫКА UML. МОДЕЛЬ СЛОЖНОЙ СИСТЕМЫ

Достаточно полная модель сложной системы представляет собой определенное число взаимосвязанных представлений (views), каждое из которых адекватно отражает аспект поведения или структуры системы. При этом наиболее общими представлениями сложной системы принято считать статическое и динамическое, которые в свою очередь могут подразделяться на другие более частные.

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

УРОВЕНЬ ПРЕДСТАВЛЕНИЯ — способ организации и рассмотрения модели на одном уровне абстракции, который представляет горизонтальный срез архитектуры модели, в то время как разбиение представляет её вертикальный срез.

25

Рисунок 1. Общая схема взаимосвязей и представлений сложной системы в процессе ООАП

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

ПАКЕТ - основной способ организации элементов модели в языке UML. Каждый пакет владеет всеми своими элементами, т.е. теми элементами, которые включены в него. При этом каждый элемент может принадлежать только одному пакету. В свою очередь, одни пакеты могут быть вложены в другие.

ПОДПАКЕТ - пакет, который является составной частью другого пакета.

26

Рисунок 2. а) УГО пакета; б) УГО пакета с дополнительной информацией о пакете

Рисунок 3. УГО пакетов, вложенных в другой пакет

27

Рисунок 4. УГО принадлежности пакетов

МОДЕЛЬ – это подкласс пакета и представляет собой абстракцию физической системы, которая предназначена для вполне определенной цели (например, логическая модель, модель проектирования и др.), при этом каждая такая модель имеет собственную точку зрения на физическую систему и свой уровень абстракции

Модели могут быть вложены друг в друга. Пакет может содержать несколько моделей одной и той же системы. Общая модель системы в контексте языка UML содержит в себе модель анализа и модель проектирования.

28

Рисунок 5. Модель системы в виде пакетов моделей анализа и проектирования

ПОДСИСТЕМА – это группировка элементов модели, которые специфицируют простейшее поведение физической системы. При этом элементы подсистемы делятся на две части – спецификацию поведения и его реализацию.

Рисунок 6. УГО подсистемы в языке UML

12. *ПАКЕТЫ В ЯЗЫКЕ UML. ГРАФИЧЕСКОЕ ИЗОБРАЖЕНИЕ СИСТЕМЫ И ПОДСИСТЕМЫ В ЯЗЫКЕ UML

29

ПАКЕТ - основной способ организации элементов модели в языке UML. Каждый пакет владеет всеми своими элементами, т.е. теми элементами, которые включены в него. При этом каждый элемент может принадлежать только одному пакету. В свою очередь, одни пакеты могут быть вложены в другие.

ПОДПАКЕТ - пакет, который является составной частью другого пакета.

Рисунок 7. а) УГО пакета; б) УГО пакета с дополнительной информацией о пакете

Рисунок 8. УГО пакетов, вложенных в другой пакет

30