Шпаргалка по "Информатике"

*обобщения, связыв обобщен классы со специализирован; *ассоциации, представл структур отнош между объектами. ассоциация назыв структ отнош, показыв, что объекты одного типа неким образом связаны с объектами др типа. Если между двумя классами определена ассоциация, то можно перемещаться от объектов одного класса к объектам др. Вполне допустимы случаи, когда оба конца ассоциации относятся к одному и тому же классу. Это означает, что с объектом некотор класса позволительно связать др объекты из того же класса. Ассоциация, связывающая два класса, назыв бинарной.Граф ассоциация изобр в виде линии, соедин класс сам с собой или с др классами. Используйте ассоциации, когда хотите показать структурные отношения. Ассоциации отобр структур отнош между экземплярами классов, то есть соедин между объектами. Каждая ассоциация может иметь метку — имя, которое описывает природу отношения.Имени можно придать направл — достаточно добавить треугольник направления, который указывает направл, заданное для чтения имени.  обобщение- это отношение между общей сущностью (суперклассом, или родителем) и ее конкретным воплощением (субклассом, или потомком). Обобщения иногда называют отношен типа "явл", имея в виду, что одна сущность явл частным выраж другой, более общей. Обобщение означает, что объекты класса-потомка могут использов всюду, где встречаются объекты класса-родителя, но не наоборот. Другими словами, потомок может быть подставлен вместо родителя. При этом он наследует св-ва родителя, в частности его атрибуты и операции. Часто, хотя и не всегда, у потомков есть и свои собственные атрибуты и операции, помимо тех, что сущест у родителя. Операция потомка с той же сигнатурой, что и у родителя, замещает операцию родителя; это св-во называют полиморфизмом. Граф отнош обобщения изобр в виде линии с большой незакраш стрелкой, направленной на родителя Обобщение — отнош между общим предметом (суперклассом) и специализиров разновидностью этого предмета (подклассом). Подкласс может иметь одного родителя (один суперкласс) или несколько родителей (несколько суперклассов). Во втором случае говорят о множественном наследовании.зависимость назыв отношение использов, согласно которому изменение в спецификации одного элемента может повлиять на другой элемент, его использующий причем обратное не обязательно. Граф зависимость изобр пунктир линией со стрелкой, направл от данного элемента на тот, от которого он зависит. Зависимость явл отношением использов между клиентом и поставщиком. Обычно операции клиента: вызывают операции поставщика; имеют сигнатуры, в котор возвращаемое значение или аргументы принадлежат классу поставщика. реализация -семантическое отношение между классами, в котором класс-приемник выполняет реализацию операций интерфейса класса-источника. агрегация В языке UML считаются разновидностями ассоциации, применяемыми для отображения структурных отношений между «целым» (агрегатом) и его «частями».

Агрегация показывает отнош по ссылке (в агрегат включены только указатели на части).

Композиция  — отношение физич включения (в агрегат включены сами части).

17.Деревья  наследования

18.Автомат (State machine) описывает поведение в терминах последовательности состояний, через которые проходит объект в течение своей жизни. Автомат: *задает поведение системы как цельной, единой сущности; *моделирует жизненный цикл единого объекта; *удобно применять для формализации динамики отдельного трудного для  понимания блока системы. Диаграмма схем состояний – отображает конечный автомат, выделяя поток управления, следующий от состояния к состоянию. Конечный автомат — поведение, которое определяет последовательность состояний в ходе существования объекта. Эта последовательность рассматривается как ответ на события и включает реакции на эти события.

Диаграмма схем состояний показывает:

1) набор состояний системы; 2) события, которые вызывают переход из одного состояния в другое;

3) действия, которые происходят  в результате изменения состояния. Элементы диаграммы схем состояний: состояния; переходы между состояниями. Диаграмма деятельности – это особая форма конечного автомата, в которой показываются процесс вычислений и потоки работ. В ней выделяются не обычные состояния объекта, а состояния выполняемых вычислений — состояния действий. При этом полагается, что процесс вычислений не прерывается внешними событиями. В диаграммах деятельности используются вспомогательные вершины:

*решение (ромбик с одной входящей и несколькими исходящими стрелками);

*объединение (ромбик с несколькими входящими и одной исходящей стрелкой); *линейка синхронизации — разделение (жирная горизонтальная линия с одной входящей и несколькими исходящими стрелками);

*линейка синхронизации — слияние (жирная горизонтальная линия с несколькими входящими и одной исходящей стрелкой); *начальное состояние (черный кружок); *конечное состояние (не закрашенный кружок, в котором размещен черный кружок меньшего размера).

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

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

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

Алгоритм формирования диаграммы сотрудничества: отображ объекты, которые участвуют во взаимодействии;рисуются связи, соединяющие эти объекты; связи помечаются сообщ, которые посылают и получают выделенные объекты. Синтаксис свойства:

Имя:Тип=Значение Объекты взаимод друг с другом с помощью связей. Связь это путь для пересылки сообщения. Связь между двумя объектами сущест тогда, когда имеется ассоциация между их классами.

 Стандартные стереотипы видимости

«global»	Объект-поставщ наход  в глобал обл определ
«local»	Объект поставщ наход  в локал обл опред объекта-клиента
«para- meter»	Объект поставщ явл  парамет операции объекта-клиента
«self»	Один и тот же объект явл и клиентом, и поставщиком

Моделируемые  разновидности действий

Вызов	В объекте запускается  операция
Возврат	Возврат знач в вызываю  объект
Посылка (Send)	В объект посыл сигнал
Создание	Создание объекта, выполн по стандар сообщ «create»
Уничт ожение	Уничтожение объекта, выполн по стандарт сообщ «destroy»

Синтаксис для записи сообщений. ВозврВеличина:=ИмяСообщения(Аргументы)

Взаимодействие  объектов Для записи сообщений в языке UML принят следующий синтаксис:ВозврВеличина := ИмяСообщения (Аргументы) Помимо рассмотренных линейных потоков управления можно моделировать и более сложные формы – итерации и ветвления. Сообщение итерации будет повторятся заданное кол-во раз, а для моделирования ветвления после номера сообщения добавляется выражение условия.Алгоритм формир диагр сотрудничества.

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

21.Компонентные диаграммы

Модели реализации обеспеч  представление системы в физич  мире, рассматр вопросы упаков логич элементов в компоненты и размещение компонен в аппаратн узлах.* Компонентная диагр показывает организацию набора компонентов и зависимости между ними.Элементы компонентных диагр явл: компонен; отношение зависимости и реализации; Интерф;  могут включать примечания, ограничения и пакеты.Компоненты По своей сути компонент явл физич фрагмен реализации системы, котор заключает в себе програм код, сценарные описания или наборы команд ос.Компонент – физически ………

22.Диаграммы  размещения

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

Обозначение узла

Размещение компон в узле

Зависимость узла от компон

Экземпляр узла

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

 в дополнит секции узла указывать список размещ компон.

10.Унифицированный  процесс разработки программных  систем

Процессом называется частично упорядоченное множество шагов, направл на достижение некоторой  цели. В контексте проектирования по вашей целью явл Поставка в предсказуемые сроки продукта, удовлетвор потребностям бизнеса. UML практически не зависит от процесса, то есть его можно использ в различно организованных процессах изготовления прогр продукта. Но один способ организации, называемый Рациональным Унифицированным Процессом (Rational Unified Process), особенно хорошо приспособлен к UML. Цель Рационального Унифицир Процесса обеспеч изготовление прогр продукта высочайшего качества, соответствующего потребностям польз, в заданные сроки и в пределах заранее составленной сметы. Рацион Унифицир Процесс вобрал в себя лучшие из существ методик разработки и придал им форму, которая может быть легко адаптир для самых разных проектов и организаций. С точки зрения управления проектом РУП предлагает упорядоченный подход к тому, как должны распределяться работа и ответственность в организации, занимающейся производством по.

Рациональный Унифицированный  Процесс итеративен. Если речь идет о простых системах, не представляет особого труда последовательно  определить задачу, спроектировать ее целостное решение, написать программу и протестировать конечный продукт. Но, учитывая сложность и разветвленность современных систем, такой линейный подход к разработке оказывается нереалистичным. Итеративный подход предполагает постепенное проникновение в суть проблемы путем последовательных уточнений и построение все более емкого решения на протяжении нескольких циклов. Итеративному подходу присуща внутренняя гибкость, позволяющая включать в бизнес-цели новые требования или тактические изменения. Его использование оставляет возможность выявить и устранить риски, связанные с проектом, на возможно более ранних этапах разработки.Суть работы в рамках РУП это создание и сопровождение моделей, а не бумажных документов. Модели, особенно выраженные на языке UML, дают семантически насыщенное представление разрабатываемого программного комплекса. На них можно смотреть с разных точек зрения, а представленную в них инфор допустимо мгновенно извлечь и проконтролировать электр способом. РУП обращен прежде всего на модели, а не на бумажные докум; причина состоит в том, чтобы свести к минимуму накладные расходы, связанные с созданием и сопровождением документов, и повысить степень информ наполнения проектирования. В центре разработки в рамках РУП лежит архитектура. Основное внимание уделяется раннему определению архит прогр комплекса и формулир основных ее особенностей. Наличие прочной архитектуры позволяет распараллелить" разработку, сводит к минимуму переделки, увеличивает вероятность того, что компоненты можно будет исполь повторно, и в конечном счете делает систему более удобной для последующего сопровож. Подобный архитектурный чертеж - это фундамент, на базе которого можно планировать процесс разработки компонент по и управлять им.Разработка в рамках РУП сосредоточена на прецедентах. В основу построения системы положено исчерпывающее представление о том, каково ее назначение. Концепции прецедентов и сценариев использ на всех стадиях процесса, от формулир требований до тестирования; они помогают проследить все действия от начала разработки до поставки готовой системы.РУП поддерживает объектно-ориентир методики. Каждая модель основаны на понятиях объектов и классов и отнош между ними, а в качестве общей нотации используют нотацию UML.РУП поддается конфигурир. Хотя ни один отдельно взятый процесс не способен удовлетворить требованиям всех организаций, занимающихся разработкой по, РУП поддается настройке и масштабируется для использ как в совсем небольших коллективах, так и в гигант компаниях. Он базируется на простой и ясной архитектуре, которая обеспеч концептуальное единство во множестве всех процессов разработки, но при этом адаптируется к различным ситуациям. Составной частью РУП явл рекомендации по его конфигур для нужд конкретной организации.РУП поощряет объективный контроль качества и управление рисками на всех стадиях воплощения проекта. Контроль качества явл неотъемлемой частью процесса, охват все виды работ и всех участников. При этом примен объективные критерии и методы оценки. Контроль качества не рассматр как особый род деятельности, которой можно заняться по завершении разработки. Управление рисками также встроено в процесс, так что возможные Препятствия на пути успешного завершения проекта выявляются и устраняются на ранних этапах разработки, когда для реагирования еще остается время.Фазы и итерации Фаза (Phase) - это промежуток времени между двумя важными опорными точками процесса, в которых должны быть достигнуты четко определенные цели, подготовлены те или иные артефакты и принято решение о том, следует ли переходить к следующей фазе. РУП состоит из след 4 фаз:Начало определ бизнес-целей проекта. Исследование разработка плана и архитектуры проекта. Построение постепенное создание системы. Внедрение поставка системы конечным пользов. Фазы начала и исследования охват проектные стадии жц процесса разработки; фазы построения и внедрения относятся к производству. Внутри каждой фазы происходит несколько итераций. Итерация представ полный цикл разработки, от выработки требов во время анализа до реализации и тестирования. Конечным результатом является выпуск готового продукта.Циклы разработкиПрохождение через четыре основные фазы называется циклом разработки. Каждый цикл завершается генерацией версии системы. Первый проход через все четыре фазы называют начальным циклом разработки. Если после этого работа над проектом не прекращается, то полученный продукт продолжает развиваться и снова минует те же фазы: начальную, исследования, построения и внедрения. Система таким образом эволюционирует, поэтому все циклы, следующие за начальным, называются эволюционными.

Рабочие процессыРУП состоит из 9рабочих процессов:моделирование бизнес-процессов - описывается структура и динамика организации; разработка требований - описывается основанный на прецедентах метод постановки требований; анализ и проектирование - описываются различные виды архитектуры системы; реализация - собственно разработка программ, автономное тестирование и интеграция; тестирование - описываются тестовые сценарии, процедуры и метрики для измерения числа ошибок; развертывание - охватывает конфигурирование поставляемой системы; управление конфигурацией - управление изменениями и поддержание целостности артефактов проекта;

управление проектом - описывает разные стратегии работы с итеративным процессом; анализ среды - рассматриваются вопросы инфраструктуры, необходимой для разработки системы. Внутри каждого рабочего процесса сосредоточены связанные между собой артефакты и деятельности. Артефакт это некоторый документ, отчет или исполняемая программа, которые производятся, а впоследствии преобразуются или потребляются. Артефакты С каждой деятельностью в РУП связаны артефакты, которые либо подаются на вход, либо получаются на выходе. Артефакты используются как исходные данные для последующей деятельн, содержат справочные сведения о проекте или выступают в роли поставляемых по контракту составляющих. Модели это самый важный вид артефактов в РУП. Модель- это упрощение реальности; она создается для лучшего понимания разрабат системы. В РУП имеется 9 моделей, которые совместно охватывают все важнейшие решения относительно визуализации, пецифицирования, конструирования и документир программной системы:модель бизнес-процессов - формализует абстракцию организации; модель предметной области формализ контекст системы; а модель прецедентов - формализует функциональные требования к системе; аналитическая модель (необязательная) - формализует идею проекта; проектная модель - формализует словарь предм обл и обл решения;модель процессов (необязательная) - формализует механизмы параллелизма и синхронизации в системе;

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

модель тестирования формализ способы проверки и приемки системы.

9.Архитектура  прогр системы

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