Понятие информационной системы (ИС). Корпоративные ИС

Понятие жизненного цикла ИС (ЖЦ ИС). Каскадная модель ЖЦ ИС.

 

Жизненный цикл – непрерывный процесс,

начинающийся с момента принятия решения о создании информационной системы и

заканчивающийся в момент полного изъятия ее из эксплуатации.

Группы процессов

· Основные (приобретение, поставка, разработка, эксплуатация, сопровождение)

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

· организационные — определяют действия и задачи, выполняемые заказчиком и разработчиком для управления своими процессами (управление проектами, создание инфраструктуры проекта, определение, оценка и улучшение самого ЖЦ, обучение)

Модель ЖЦ ИС – структура, определяющая последовательность осуществления процессов, действий и задач, выполняемых на протяжении ЖЦ ИС, а также взаимосвязи между этими процессами, действиями и задачами. Зависит от специфики ИС и условий, в которых она создается и функционирует.

· каскадная (модель водопада, waterfall) 70-80 гг. XX в.

Разработка требований → Проектирование → Реализация → Тестирование → Ввод в действие

+на каждом этапе формируется законченный набор проектной документации

+возможность планировать сроки и соответствующие затраты

-задержка в получении результатов (согласование результатов производится только после завершения очередного этапа работ)

-возврат на более ранние стадии (ошибки, допущенные на ранних этапах, обнаруживаются на последующих стадиях)

Недостатки:

· сложность параллельного ведения работ

· информационная перенасыщенность

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

· высокий уровень риска

· конфликт между разработчиками

Недостатки приводят к:

· увеличению сроков разработки

· увеличению стоимости проекта

 

Реальный процесс каскадной модели

 

Понятие жизненного цикла ИС (ЖЦ ИС). Спиральная модель ЖЦ ИС.

Жизненный цикл – непрерывный процесс, начинающийся с момента принятия решения о создании информационной системы и заканчивающийся в момент полного изъятия ее из эксплуатации.

Группы процессов

· Основные (приобретение, поставка, разработка, эксплуатация, сопровождение)

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

· организационные — определяют действия и задачи, выполняемые заказчиком и разработчиком для

управления своими процессами (управление проектами, создание инфраструктуры проекта, определение, оценка и улучшение самого ЖЦ, обучение)

Модель ЖЦ ИС – структура, определяющая последовательность осуществления процессов, действий и задач, выполняемых на протяжении ЖЦ ИС, а также взаимосвязи между этими процессами, действиями и задачами. Зависит от специфики ИС и условий, в которых она создается и функционирует

Итерационная (спиральная) с середины 80-х гг. XX в.

+упрощается внесение изменений

+постепенная интеграция отдельных элементов ИС

+уменьшение уровня рисков

+большая гибкость в управлении проектом

+упрощает повторное использование компонентов

+ИС более надежна и устойчива

+возможность совершенствования процесса разработки

-Сложность определения момента перехода к следующей итерации

-Планирование работ на основе накопленного опыта

 

 

Scrum-мастер (Scrum Master)

Scrum-команда (Scrum Team)

 

Sprint Planning Meeting. Проводится в начале каждой итерации. Сначала Produсt Owner, Scurm-мастер, команда, а также представители заказчика и пр. заинтересованные лица определяют, какие требования из Project Backlog наиболее приоритетные и их следует реализовывать в рамках данной итерации. Формируется Sprint Backlog. Далее Scurm-мастер и Scrum- команда определяют то, как именно будут достигнуты определенные выше цели из Sprint Backlog. Для каждого элемента Sprint Backlog определяется список задач и оценивается их трудоемкость.

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

реализовать цель итерации, и только это дает уверенность в том, что она будет достигнута. На них лежит ответственность за их собственные слова, и, если кто-то со стороны вмешивается и принимает решения за них, тем самым он снимает ответственность за результат с участников команды. Такие встречи поддерживают дисциплину обязательств в Scrum-команде, способствуют удержанию фокуса на целях итерации, помогают решать проблемы «в зародыше». Обычно такие совещания проводятся стоя, в течение 15-20 минут.

Sprint Review Meeting. Проводится в конце каждой итерации. Сначала Scrum-команда демонстрирует Product Owner сделанную в течение итерации работу, а тот в свою очередь ведет эту часть митинга и может пригласить к участию всех заинтересованных представителей заказчика. Product Owner определяет, какие требования из Sprint Backlog были выполнены, и обсуждает с командой и заказчиками, как лучше расставить приоритеты в Sprint Backlog для следующей итерации. Во второй части митинга производится анализ прошедшей итерации, который ведет Scrum-мастер. Scrum-команда анализирует в последней итерации положительные и отрицательные моменты совместной работы, делает выводы и принимает важные для дальнейшей работы решения. Scrum-команда также ищет пути для увеличения эффективности дальнейшей работы. Затем цикл повторяется

 

Начало (Inception)

На этом этапе:

 формируются видение и границы проекта; создается экономическое обоснование (business case);

 определяются основные требования, ограничения и ключевая

функциональность продукта;  создается базовая версия модели прецедентов;

 оцениваются риски.

Внедрение (Transition)

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

Дисциплина (discipline) — это набор видов деятельности (и связанных с ним артефактов) в рамках одного этапа, например в рамках анализа требований. В контексте унифицированного процесса артефактом (artifact) называется любой результат работы: код, графическое изображение для веб, схема базы данных, текстовые документы, диаграммы, модели и т. д. В рамках унифицированного процесса существует несколько дисциплин. В этом курсе внимание будет сосредоточено на некоторых артефактах следующих четырех дисциплин.

 Бизнес-моделирование (Business Modeling). Эта дисциплина подразумевает разработку модели предметной области, которая является визуальным представлением наиболее важных сущностей из предметной области и их взаимосвязей.

 Требования (Requirements). В рамках этой дисциплины создается модель прецедентов и дополнительная спецификация. В этих двух артефактах отражаются функциональные и нефункциональные требования.

 Проектирование (Design). Сюда относится модель проектирования, которая отражает программные объекты.

 Реализация (Implementation)

UML. Диаграммы UML.

UML (Unified Modeling Language):

· универсальный язык визуального моделирования систем

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

Поддерживается OMG (Object Management Group)

Способы использования:

· для черновиков

· для создания проектной документации

· в качестве языка программирования

Model Driven Architecture

Model Driven Architecture (MDA) — архитектура, управляемая моделью.

Executable UML

Диаграммы UML

· диаграммы структуры (structure diagrams)

o классов (Class)

o составных структур (Composite structure) (декомпозиция класса во время исполнения)

o компонентов (Component)

o развертывания (Deployment)

o объектов (Object)

o пакетов (Package)

· диаграммы поведения (Behavior)

o деятельности (Activity)

o состояний (State Machine)

o прецедентов (Use Case)

o взаимодействия (Interaction)

§ последовательности (Sequence)

§ коммуникационная (Communication)

§ временная (Timing)

§ обзора взаимодействий (Interaction Overview)

11. Анализ требований. Модель требований FURPS+. Функциональные и

нефункциональные требования. Требования, связанные с производительностью

Системы.

Требования (requirements):

· подробное описание того, что должно быть реализовано

· возможности или условия, которым должна соответствовать система или проект

Выработка требований (requirements engineering) —

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

Виды (FURPS+)

• функциональные: свойства, возможности, безопасность

• удобство: человеческий фактор, справочная система, документация

• надежность: частота сбоев, возможность восстановления

• производительность

возможность поддержки: адаптивность, соответствие стандартам, конфигурирование

• реализация: ресурсы, языки и средства, аппаратное обеспечение

• интерфейс: взаимодействие с внешними системами

• операции: управление системой и ее параметры

• юридические вопросы

 

Треб:

Производительность

 

• Время отклика (Response Time)

• Быстрота реагирования (Responsiveness)

• Время задержки (Latency)

• Пропускная способность (Throughput)

o количество транзакций в секунду (Transactions per second, TPS)

• Загрузка (Load)

• Чувствительность к загрузке (Load Sensitivity)

o A: отклик — 0,5 с для 10-20 пользов.

o B: отклик — 0,2 с для 10 пользов., 2 с для 20 пользов.

• Эффективность (Efficiency)

o A: 2 CPU, 30 TPS

o B: 4 CPU, 40 TPS

• Масштабируемость (Scalability)

Требования и прецеденты. Формат описания прецедента. Структура прецедента.

Прецеде́нт — спецификация последовательностей действий (варианты последовательностей и ошибочные последовательности), которые может осуществлять система, подсистема или класс, взаимодействуя с внешними акторами (англ. Actors).

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

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

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

Один и тот же прецедент может быть описан с различной степенью детализации.

Исполнитель (актер, actor) — некоторая роль, которую пользователь играет по отношению

к системе: люди, организации, машины, программы.

типы:

· основной (primary)

· вспомогательный (supporting)

· закулисный (offstage)

Прецедент (вариант использования, use case) — множество взаимосвязанных сценариев, объединенных некоторой общей целью пользователя (исполнителя).

Прецеденты — текстовые описания, а не диаграммы.

Форматы прицедентов:

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

· свободный (там же)Возврат товара

o Основной успешный сценарий: Покупатель подходит к кассе с товарами, подлежащими возврату. Кассир использует систему для регистрации каждого возвращаемого товара...

o Альтернативные сценарии: Если в авторизации кредитной карточки отказано, кассир информирует об этом покупателя и предлагает ему другой способ оплаты покупки.

o Если у системы возникли сложности при коммуникации с внешней системой вычисления налога...

· развернутый (для представления части наиболее важных прецедентов)

Содержимое прецедентов:

· Название

o Оформление продажи

· рамки

o Приложение автоматизации торговли NextGen

· уровень

o пользовательские (user-geal level)

o вспомогательные (subfuncion level)

o Задача, определенная пользователем

· основной исполнитель

o Кассир

 

 

Характеристики ПО

 

• Функциональность

• Адекватность функционирования

• Надежность

• Удобство использования

• Безопасность

• Производительность

• Приемлемость по затратам и срокам

Соответствие законодательству

 

Архитектурные факторы

 

• Определяющие – нефункциональные требования

• Функциональные – с точки зрения возможных изменений

 

• Способность к изменениям

o Какие изменения наиболее вероятны?

• Производительность

• Емкость

o Сколько пользователей одновременно работает? Какой объем данных хранить?

• Экосистема

o Как система будет взаимодействовать с другими системами?

• Модульность

o Как разбить на модули, которые можно разрабатывать независимо?

o Можно ли строить в виде набора компонент? Какие из них можно повторно использовать? Какие нужно приобрести?

• Безопасность

o Требуется ли авторизация? Как обеспечить безопасность данных? Как защититься от атак?

 

Описание архитектуры

• Software Architecture Document (SAD) или Application Architecture Description (AAD)

o Описание и обоснование архитектурных решений

o Архитектурные виды (N +1)

o Зачем нужен?

 

Понятие паттерна

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

Паттерн (шаблон, pattern) — это именованное описание проблемы и ее решения, которое можно применить при разработке других систем.

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

Использование именованных паттернов позволяет:

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

· зафиксировать описываемое паттерном понятие в памяти;

· облегчить общение разработчиков при совместном решении проблем;

· передать опыт решения различных проблем анализа, проектирования и разработки.

Назначение

Проецирует программную архитектуру на аппаратную архитектуру

Определяет:

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

- как ПО будет развертываться на это оборудование

Основные элементы

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

- устройство (device)

- среда выполнения (execution environment) (операционная система, виртуальная машина, СУБД)

Коммуникационный путь (communication path) — канал связи узлов

- помечается названием протокола, реализующего взаимодействие

Артефакт («artefact») — реальная сущность (файл)

(исходный код («source») и исполняемые файлы («executable», «library»), сценарии («script»), таблицы БД, документы («document»), файл («file»), «deployment spec»)

Диаграмма развёртывания, Deployment diagram — служит для моделирования работающих узлов (аппаратных средств, англ. node) и артефактов, развёрнутых на них. В UML 2 на узлах разворачиваются артефакты (англ. artifact), в то время как в UML 1 на узлах разворачивались компоненты. Между артефактом и логическим элементом (компонентом), который он реализует, устанавливается зависимость манифестации.

 

 

Содержание класса

Обычно показывают: имя класса, ключевые атрибуты, ключевые операции, стереотипы

Обычно не показывают: параметры операций, видимость, исходные значения

Имя класса

- Существительное или именная группа

- Стиль: «UpperCamelCase»

- Избегать сокращений (DpstAccnt) и аббревиатур

- Имя абстрактного класса: курсив или свойство {abstract}

- Имя конечного класса: свойство {leaf}

Атрибуты

- Определяют состояние экземпляров

- Синтаксис: видимость имя: тип [кратность] = значение {свойства}

- Статические атрибуты подчеркиваются

Операции

- Характеризуют поведение экземпляров

- Синтаксис: видимость имя(параметры): результат {свойства}

- Статические операции подчеркиваются

- Абстрактные операции выделяются курсивом или помечаются свойством {abstract}

- Конечные операции — свойство {leaf}

Отношения:

Ассоциация

- Указывает, что между объектами классов могут устанавливаться связи

- Обозначает действие, производимое исходным объектом над целевым элементом

- Синтаксис:

имя (глагол)

имена ролей (существительное)

кратность (задается явно)

возможность навигации

- Указывается: имя или роли

- Возможность навигации — «сообщения могут посылаться только в том направлении, в котором указывает стрелка»

- Стили указания: абсолютно явная навигация, абсолютно скрытая навигация, явная навигация

Рефлексивные ассоциации

Класс ассоциации

Единственная уникальная связь

Зависимость

Элемент-клиент обладает знаниями об элементе-поставщике, изменение в поставщике может повлиять на клиента

Рекомендуется использовать для обозначения:

- глобальных переменных

-переменных-параметров

- вызовов статических методов

Обобщение

Класс является частным случаем другого класса

Интерфейс

Нотации:

- класс (стереотип «interface»)

- «леденец на палочке»

Реализация интерфейса

Назначение

Иллюстрирует логическую архитектуру приложения (уровни, подсистемы, пространства имен)

Показывает: пакеты и зависимости между ними

Пакет — механизм группировки элементов

 

 

Диаграмма пакетов, Package diagram — структурная диаграмма, основным содержанием которой являются пакеты и отношения между ними. Жёсткого разделения между разными структурными диаграммами не проводится, поэтому данное название предлагается исключительно для удобства и не имеет семантического значения (пакеты и диаграммы пакетов могут присутствовать на других структурных диаграммах). Диаграммы пакетов служат, в первую очередь, для организации элементов в группы по какому-либо признаку с целью упрощения структуры и организации работы с моделью системы.

 

Назначение

Показывают: события и состояния объектов

Основные элементы

- Событие (event) — значимое происшествие; инициирует переход

- Состояние (state) — характеризует объект между событиями

- Переход (transition) — движение между состояниями trigger [guard] / activity

Применение

Моделирование зависимых от состояний типов со сложным поведением

- физические устройства с программным управлением

- транзакции и взаимосвязанные бизнес-объекты

- классы, изменяющие свою роль

Моделирование протоколов и допустимых последовательностей событий

- коммуникационные протоколы

- окна пользовательского интерфейса

- обработка событий отдельного окна

- контроллеры/сеансы

 

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

Назначение Диаграммы деятельности (activity) — «объектно-ориентированные» блок-схемы

Отображают:

последовательные и параллельные бизнес-процессы

логику процедур

потоки работ

потоки данных

Пример

Основные элементы

система узлов, соединенных ребрами

Узлы (nodes):

узлы действия (action nodes) элементарные единицы работы

действие

посылка сигнала

принятие события

принятие события времени

объектные узлы (object nodes) — данные

узлы управления (control nodes) — управляют потоком деятельности

начальный и конечный узел деятельности

узел решения и узел слияния

узел ветвления и узел объединения

Ребра (edges):

ребра потоков управления (control flows)

ребра потоков объектов (object flows) — вместе с узлами объектов показывают поток данных

Разделы (partitions):

группа взаимосвязанных действий

семантику определяет разработчик

прецеденты, классы, компоненты, организационные единицы, роли

Применение

Моделирование бизнес-процессов

Моделирование потоков данных

Графическое моделирование потока прецедента

Блок-схемы — редко

Диаграмма деятельности, Activity diagram — диаграмма, на которой показано разложение некоторой деятельности на её составные части. Под деятельностью (англ. activity) понимается спецификация исполняемого поведения в виде координированного последовательного и параллельного выполнения подчинённых элементов — вложенных видов деятельности и отдельных действий (англ. action), соединённых между собой потоками, которые идут от выходов одного узла ко входам другого.

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

 

 

Участник взаимодействия

Участник взаимодействия — экземпляр класса

Представлен линией жизни (lifeline)

Синтаксис: имя [ селектор ]: тип

Фокус управления

Фокус управления — активное состояние объекта (выполнение некоторых действий)

Новое название: Блок управления, описание

выполнения (execution specification bar)

Часто не указывается

Сообщение

 

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

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

Назначение

Показывают: объекты и то, как они обмениваются сообщениями в рамках одного сценария

Акцент:

- обмен данными

- структурные аспекты взаимодействия

Обозначения

- Участники взаимодействия

- Связи — коммуникационные каналы для передачи сообщений

- Сообщения

номер (иерархический — вложенность вызовов), сигнатура, направление

Применение

- Незаменимы при распределении обязанностей

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

ясно показывают последовательность

богатый набор обозначений

неудобно расширять

занимают много места по горизонтали

-Диаграммы коммуникации

экономия пространства

сложнее отследить последовательность

более бедная система обозначений

Сообщение — описывает взаимодействие объектов

вызов операции, создание или уничтожение экземпляра, отправка сигнала

Отображаются: стрелки между линиями жизни

Синхронные (отправитель ожидает завершения выполнения сообщения получателем

_______ >( жирная стрелка )

Асинхронные отправитель посылает сообщение и продолжает исполнение — он не ожидает

возврата от получателя _________>

Возврат получатель сообщения возвращает управление отправителю

ß----------------------

Создание объекта отправитель создает экземпляр получателя

Уничтожение объекта отправитель уничтожает получателя

 

Найденное сообщение отправитель находится вне области видимости взаимодействия

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

Диаграмма коммуникации, Communication diagram (в UML 1.x — диаграмма кооперации, collaboration diagram) — диаграмма, на которой изображаются взаимодействия между частями композитной структуры или ролями кооперации. В отличие от диаграммы последовательности, на диаграмме коммуникации явно указываются отношения между элементами (объектами), а время как отдельное измерение не используется (применяются порядковые номера вызовов).

Формулировка

· Модули верхних уровней не должны зависеть от модулей нижних уровней. Оба типа модулей должны зависеть от абстракций.

· Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций.

 

CLR

- поддерживает приложения, разработанные на различных языках

- вместе с Framework распространяются (ассемблер IL, C#, Visual Basic.NET, J#, Jscript)

- Устанавливается в каталог: %WINDOWS%\Microsoft.NET\Framework\vверсия

Компиляция

Управляемый модуль (managed module) – стандартный исполняемый файл Windows, который требует для своего исполнения CLR

 

 

Метаданные (metadata) – «данные о данных» – набор таблиц данных, описывающих:

- какие типы определены в данном модуле

- на какие типы, определенные в других модулях, ссылается данный модуль

Использование метаданных:

- Устраняют необходимость в заголовочных файлах

- IntelliSense

- Верификация

- Сериализация/десериализация

- Сборка мусора

IL (Intermediate Language, промежуточный язык) – не зависящий от процессора псевдо-машинный язык

Особенности:

- создание и инициализация объектов

- вызов виртуальных методов

- манипулирование элементами массивов

- генерация и обработка исключений

- исполняется на любой платформе

Исполнение

JIT-компиляция (Just-in-Time, «точно в срок»): команды IL во время первого обращения к методу преобразуются в команды процессора (“native” код).

При этом осуществляется и верификация – проверка IL-кода на безопасность.

Framework Class Library

- FCL основана на объектно-ориентированной парадигме

- Содержит несколько тысяч типов

- Типы скомпонованы в пространства имен

Общая система типов (Common Type System, CTS) – формальная спецификация, описывающая определение типов и их поведение

- Типы (класс, структура, перечисление, интерфейс, делегат)

- Определяет элементы типов: поле, метод, свойство, событие

- Определяет правила видимости типов и доступа к их элементам public, protected, private, internal

Типы

- Ссылочные (reference types)

- Переменная содержит ссылку на объект

- При присваивании создается еще одна ссылка на тот же объект

- Объекты размещаются в управляемой куче

- Типы-значения (value-types)

- Переменная содержит сам объект

- При присваивании создается копия объекта

- Объекты размещаются в стеке

- Элементарные (primitive types)

Видимость типа

- public (открытый)

- internal (внутренний) (тип доступен только из сборки, в которой он определен)

Члены типа

Константа – идентификатор, представляющий некую постоянную величину

Поле

Статическое Экземплярное

Конструктор экземпляров

Конструктор типа – метод, инициализирующий статические поля типа

Метод

Перегруженный оператор

Оператор преобразования — метод определяющий порядок приведения объекта из одного типа в другой

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

Событие – метод, позволяющий объекту/типу посылать уведомления слушающему типу/объекту

Тип – позволяет определить вложенные типы

Доступ к членам типа

private – тип (и вложенные типы)

protected – тип и производные от него

internal – сборка

protected internal – тип, производные от него и любой код в сборке

public – любой код из любой сборки

Общеязыковая спецификация (Common Language Specification, CLS) – спецификация, описывающая набор правил, позволяющих типам, реализованным на разных языках взаимодействовать друг с другом.

- Учет регистра символов

- Целые числа без знака

- Перегрузка операторов

- Методы с переменным числом параметров

Общеязыковая спецификация

- Учет регистра символов

- Целые числа без знака

- Перегрузка операторов

- Методы с переменным числом параметров

C#. Объявление класса.

Объявление класса в языке C# создает новый ссылочный тип, дающий возможность программисту моделировать объекты (элементы данные) и которым присуще определённое поведение (методы).

доступ class имя_класса

{

// члены класса

}

Пример:

public class Complex

{... }

Каждый класс в C# автоматически снабжается типовым конструктором, который вы можете при необходимости переопределить. Этот типовой конструктор используется по умолчанию и гарантирует что все члены-данные по умолчанию получат типовые входные значения. Конструктор имеет имя, соответствующее имени класса и он никогда не возвращает значения.

 

Поле – член типа, которые представляет данные и хранит ссылку на ссылочный тип или экземпляр размерного типа.

доступ модификатор тип имя = значение;

public static int MaxSize = 10;

private int x = 7;

• static – поле связано с типом, а не с каким-либо конкретным объектом
• readonly – запись в поле разрешается только из кода конструктора

Определение метода

доступ модификатор тип_возврата имя_метода(параметры)

{

тело_метода

}

 

 

C#. Делегаты. События.

Делегат – тип, поддерживающий механизм функций обратного вызова.

Экземпляры этого типа являются оболочками методов других типов.

 обеспечивают безопасность типов

 поддерживают вызов статических и экземплярных методов

 цепочка делегатов — набор делегатов, который позволяет вызвать все методы,

представленные делегатами набора

 

Начнем с определения термина делегат (delegate). Делегат — это объект, который

может ссылаться на метод. Таким образом, создавая делегат, вы по сути создаете объект, который может содержать ссылку на метод. Более того, этот метод можно вызвать

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

на который он ссылается.

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

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

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

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

Делегат объявляется с помощью ключевого слова delegate. Общая форма объявления делегата имеет следующий вид:

delegate тип_возврата имя(список_параметров);

 

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

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

статический метод, связанный с классом.

Примеры:

 internal delegate void FooCallback(int value)

 public delegate int BarCallback(int [] anArray)

 

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

Во-вторых, делегаты позволяют во время выполнения программы выполнить метод,

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

компоненты.

 

На основе делегатов построено еще одно важное средство С#: событие (event). Собы