- •17. Критерии и метрики определения качества и сложности разработки пс. Фунционально и размерно-ориентированные метрики. Метрики оопс (метрики Чидамбера-Кемерерва).
- •Метрика 1: Взвешенные методы на класс wmc (Weighted Methods Per Class)
- •Метрика 2: Высота дерева наследования dit (Depth of Inheritance Tree)
- •Метрика 3: Количество детей noc (Number of children)
- •Метрика 4: Сцепление между классами объектов сво (Coupling between object classes)
- •Метрика 5: Отклик для класса rfc (Response For a Class)
- •Метрика 6: Недостаток связности в методах lсom (Lack of Cohesion in Methods)
- •18. Web-программирование. Обработка данных. Get и post запросы. Анатомия Web-формы. Серверные элементы управления
- •19. Страничные директивы и страничные события. Механизмы. Фоновый код.
- •20. Данные и источники данных. Элементы управления, обработка и связывание с источниками данных. Механизмы
- •21. Проверяющие элементы управления. Назначение и использование
- •22. Многостраничные приложения. Связи между формами
- •24. Сеансы и сессии. Назначение и принципы работы. Состояния
- •25. Web-сервисы. Общие принципы организации. Soap
- •26. Web-сервисы. Язык wsdl. Пользовательские типы данных
- •27. Безопасность в asp.Net. Принципы идентификации и аутентификации. Авторизация
- •28. Шаблон проектирования mvc. Взгляд ms .Net. Особенности работы
- •Жизненный цикл запроса.
- •29. Методы разработки по через тестирование (tdd). Взгляд с точки зрения .Net. Особенности
- •30. Многопоточность и параллелизм в .Net. Особенности.
- •31. Коллективная разработка и коллективное владение кодом. Методы организации через svn.
- •32. Идеология Windows Workflow Foundation (wwf). Перспективы и возможности
30. Многопоточность и параллелизм в .Net. Особенности.
Многопоточность в среде .NET Framework реализована следующим образом: существуют два типа потоков: высокоприоритетный и низкоприоритетный.
Высокоприоритетный(foreground) поток в отличии от низкоприоритетного (или фонового -background), назначается, как тип потока по умолчанию, а так же не будет остановлен, в том случае, если все высокоприоритетные потоки к его процессе будут остановлены.
Параллелизм означает управление количеством потоков, одновременно активных в некотором контексте InstanceContext. Управление осуществляется с помощью System.ServiceModel.ServiceBehaviorAttribute.ConcurrencyMode с перечислением ConcurrencyMode.
Доступны следующие три режима параллелизма:
Single: в каждом контексте экземпляра одновременно допускается максимум один поток, обрабатывающий сообщения в контексте экземпляра. Другие потоки, которым требуется использовать этот же контекст экземпляра, должны оставаться блокированными, пока исходный поток не выйдет из контекста экземпляра.
Multiple: каждый экземпляр службы может иметь несколько потоков, параллельно обрабатывающих сообщения. Чтобы использовать этот режим параллелизма, реализация службы должна быть потокобезопасной.
Reentrant: каждый экземпляр службы одновременно обрабатывает одно сообщение, но принимает вызовы операций с повторным входом. Служба принимает такие вызовы только при вызове через объект клиента WCF.
Использование параллелизма связано с режимом создания экземпляров. В режиме создания экземпляров PerCall параллелизм не имеет значения, так как каждое сообщение обрабатывается новым контекстом InstanceContext и, следовательно, в контексте InstanceContext никогда не бывает активно несколько потоков.
31. Коллективная разработка и коллективное владение кодом. Методы организации через svn.
Коллективное владение кодом позволяет каждому разработчику выдвигать новые идеи в любой части проекта, изменять любую строку программы, добавлять функциональность, фиксировать ошибку и проводить реорганизацию. Один человек просто не в состоянии удержать в голове проект нетривиальной системы. Благодаря коллективному владению кодом снижается риск принятия неверного решения и устраняется нежелательная зависимость проекта от одного человека.
Работа начинается с создания тестов модуля, она должна предшествовать программированию модуля. Тесты необходимо помещать в библиотеку кодов вместе с кодом, который они тестируют. Тесты делают возможным коллективное создание кода и защищают код от неожиданных изменений. В случае обнаружения ошибки также создается тест, чтобы предотвратить ее повторное появление.
Кроме тестов модулей, создаются тесты приемки, они основываются на пользовательских историях. Эти тесты испытывают систему как «черный ящик» и ориентированы на требуемое поведение системы. На основе результатов тестирования разработчики включают в очередную итерацию работу над ошибками.
Все коды в проекте создаются парами программистов, работающими за одним компьютером. Парное программирование приводит к повышению качества без дополнительных затрат времени. А это, в свою очередь, уменьшает расходы на будущее сопровождение программной системы.
Во время очередной итерации всех сотрудников перемещают на новые участки работы. Такие перемещения помогают устранить изоляцию знаний.
Код нужно постоянно обновлять – удалять лишние части, убирать ненужную функциональность. Этот процесс называют реорганизацией кода. Реорганизация поддерживает прозрачность и целостность кода, обеспечивает его легкое понимание, исправление и расширение. На реорганизацию уходит значительно меньше времени, чем на сопровождение устаревшего кода.
Еще одна составляющая коллективного владения кодом – непрерывная интеграция. Без последовательной и частой интеграции результатов в систему разработчики могут быть уверены в правильности своих действий. Кроме того, трудно вовремя оценить качество выполненных фрагментов проекта и внести необходимые коррективы. По возможности разработчики должны интегрировать и публично отображать, демонстрировать код каждые несколько часов. Интеграция позволяет объединить усилия отдельных пар и стимулирует повторное использование кода.
Subversion — централизованная система (в отличие от распределённых систем, таких как Git или Mercurial), то есть данные хранятся в едином хранилище. Хранилище может располагаться на локальном диске или на сетевом сервере.
Работа в Subversion мало отличается от работы в других централизованных системах управления версиями. Клиенты копируют файлы из хранилища, создавая локальные рабочие копии, затем вносят изменения в рабочие копии и фиксируют эти изменения в хранилище. Несколько клиентов могут одновременно обращаться к хранилищу. Для совместной работы над файлами в Subversion преимущественно используется модель копирование — изменение — слияние. Кроме того, для файлов, не допускающих слияние (различные бинарные форматы файлов), можно использовать модель блокирование — изменение — разблокирование.
При сохранении новых версий используется дельта-компрессия: система находит отличия новой версии от предыдущей и записывает только их, избегая дублирования данных.
При использовании доступа с помощью WebDAV также поддерживается прозрачное управление версиями — если любой клиент WebDAV открывает для записи и затем сохраняет файл, хранящийся на сетевом ресурсе, то автоматически создаётся новая версия.