Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Лекции по ая.docx
Скачиваний:
22
Добавлен:
20.09.2019
Размер:
276.66 Кб
Скачать

Модификаторы доступа

Каждое поле имеет модификатор доступа, принимающий одно из четырех значений: public, private, protected, internal.

Модификатор private является атрибутом доступа по умолчанию. Он закрывает поля от всех других классов, разрешая прямой доступ к ним (чтение и запись) только методам самого класса. Все поля всегда доступны всем методам класса. Они являются для методов класса глобальной информацией, с которой работают все методы класса, извлекая из полей нужные им данные и изменяя их значения в ходе работы.

Модификатор protected. Этот модификатор открывает поля классам наследникам. Если класс A объявил некоторое поле с модификатором protected, то методы класса B, который является наследником класса A и, следовательно, наследует поля класса A, могут непосредственно работать с наследуемыми полями.

Модификатор internal. Этот модификатор открывает поля из одного проэкта. Если класс A объявил некоторое поле с модификатором internal, то методы класса B из этого же проекта, являющегося клиентом класса A, могут непосредственно работать с таким полем.

Комбинация атрибутов protected и internal

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

Если поля доступны только для методов класса, то они имеют модификатор доступа private, который можно опускать. Такие поля считаются закрытыми, но часто желательно, чтобы некоторые из них были доступны в более широком контексте. Если некоторые поля класса A должны быть доступны для методов класса B, являющегося потомком класса A, то эти поля следует снабдить модификатором protected. Такие поля называются защищенными. Если некоторые поля должны быть доступны для методов классов B1, B2 из одного проекта с классом А, то эти поля следует снабдить модификатором internal, а все классы B поместить в один проект ( assembly ). Такие поля называются дружественными. Наконец, если некоторые поля должны быть доступны для методов любого класса B, которому доступен сам класс A, то эти поля следует снабдить модификатором public. Такие поля называются общедоступными или открытыми.

Модификатор

Определение

public

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

private

Доступ к типу или члену можно получить только из кода в том же классе.

protected

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

internal

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

protected

internal

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

Uml, назначение, типы диаграм.

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

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

Модель (model) - абстракция физической системы, рассматриваемая с определенной точки зрения и представленная на некотором языке или в графической форме.

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

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

  • Структурные диаграммы

    1. Диаграмма классов.

    2. Диаграмма компонентов.

    3. Диаграмма составной структуры.

    4. Диаграмма развёртывания.

    5. Диаграмма объектов.

    6. Диаграмма пакетов.

  • Диаграммы поведения

    1. Диаграмма деятельности.

    2. Диаграмма состояний.

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

      • Диаграмма коммуникации.

      • Диаграмма последовательности.

      • Диаграмма сотрудничества.

    4. Диаграмма взаимодействия.

    5. Диаграмма синхронизации.

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

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

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

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

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