- •1. Понятие информационной системы (ис). Корпоративные ис. Структура ис.
- •2. Понятие информационной системы (ис). Корпоративные ис. Классификация ис.
- •3. История развития ис.
- •4. .Net Framework. Общеязыковая среда исполнения (clr). Управляемые модули и сборки.
- •5. .Net Framework. Общая система типов (cts) и Общеязыковая спецификация (cls).
- •6. .Net Framework. Механизм сборки мусора.
- •7. C#. Объявление класса.
- •8. Java. Объявление класса.
- •9. C#. Делегаты.
- •10. C#. События.
- •11. C#. Наследование: правила, синтаксис. Сокрытие имен.
- •12. Java. Наследование: правила, синтаксис. Сокрытие имен.
- •13. Правила наследования типов. Принцип «Open-Closed Principle».
- •14. Правила наследования типов. Принцип «Liskov Substitution Principle».
- •15. C#. Приведение типов. Операторы as и is.
- •16. C#. Виртуальные и невиртуальные методы. Статические методы.
- •17. C#. Абстрактные и конечные методы.
- •310 Часть I. Язык с#
- •18. Java. Абстрактные, виртуальные, конечные и статические методы.
- •19. C# и Java. Интерфейсы.
- •20.C#. Структуры.
- •21. C#. Перечисления.
- •22.C#. Упаковка и распаковка объектов значимых типов.
- •23.C# и Java. Исключения. Механизм исключений.
- •24.C# и Java. Исключения. Классы исключений.
- •25.C# и Java. Исключения. Основные принципы использования механизма
- •26.C#. Обобщения: понятие и синтаксис. Ограничения обобщений.
- •27. Java. Обобщения: понятие и синтаксис.
- •28.C#. Коллекции.
- •29.Java. Коллекции.
- •30.C#. Dispose Pattern.
- •31. .Net Framework 3.0, 3.5, 3.5 sp1: общая характеристика.
- •32. C# 3.0, linq: обзор.
- •Источники данных
- •SqlMetal
- •33. Понятие жизненного цикла ис (жц ис). Каскадная модель жц ис.
- •34. Понятие жизненного цикла ис (жц ис). Спиральная модель жц ис.
- •35. Анализ требований. Функциональные и нефункциональные требования.
- •36 Требования и прецеденты. Формат описания прецедента. Структура прецедента.
- •37 Требования и прецеденты. Взаимосвязь прецедентов.
- •38 Модель предметной области. Концептуальные классы. Ассоциации и атрибуты.
- •39 Язык uml. Способы использования. Model Driven Architecture. Executable uml. ДиаграммыUml.
- •40 Диаграмма прецедентов.
- •41. Диаграмма классов. Обозначение классов. Отношение ассоциации.
- •42.Диаграмма классов. Обозначение интерфейсов. Отношение обобщения и зависимости.
- •43.Диаграмма объектов.
- •44.Диаграмма пакетов.
- •45.Диаграмма состояний.
- •46.Диаграмма развертывания.
- •49.Диаграмма коммуникации.
- •50.Паттерн: понятие, структура, классификация.
- •1) Понятие паттерна
- •2) Структура и Классификация паттернов
- •51. Проектирование на основе обязанностей. Принципы grasp.
- •52.Grasp: принцип Low Coupling.
- •53.Grasp: принцип High Cohesion.
- •54.Grasp: принцип Information Expert.
- •55. Grasp: принцип Creator.
- •56.Grasp: принцип Pure Fabrication.
- •57. Grasp: принцип Indirection.
- •59.Grasp: принцип Protected Variations.
- •60.Grasp: принцип Controller.
2) Структура и Классификация паттернов
Низшим уровнем представления программной системы является описание ее в терминах классов (со своими атрибутами и операциями) и соответствующих им обьектов. Примером элемента следующего уровня является системная архитектура. Самым высоким уровнем является интеграция отдельных систем.
На основе этого разделения можно выделить следующие классы паттернов:
паттерны проектирования распределения обязанностей и взаимодействия отдельных классов или обьектов информационных систем;
архитектурные паттерны;
аттерны интеграции информационных систем.
Существуют монографии, посвященные каждой отдельной группе паттернов, но нет их унифицированного рассмотрения на единых принципах.
Что касается вышеперечисленных групп паттернов, внутри каждой из них обычно проводится дополнительная классификация.
51. Проектирование на основе обязанностей. Принципы grasp.
Зачастую проектирование программных объектов описывают в терминах обязанностей, ролей и кооперации (взаимодействия с другими объектами). Это — часть более широкого подхода, получившего название проектирование на основе обязанностей (Responsibility-Driven Design, RDD).
В RDD считается, что программные объекты имеют определенные обязанности — абстракции, реализуемые ими. Обязанности описывают 4 поведенеие объекта в терминах его ролей. В общем случае можно выделить две группы обязанностей: знание (knowing) и действие (doing).
К действиям объекта относятся следующие обязанности:
выполнение некоторых действий самим объектом (например, создание экземпляра или выполнение вычислений);
инициирование действий других объектов;
управление действиями других объектов и их координирование.
К знаниям объекта относятся следующие обязанности:
наличие информации о закрытых инкапсулированных данных;
наличие информации о связанных объектах;
наличие информации о следствиях или вычисляемых величинах.
Обязанности присваиваются объектам в процессе объектно-ориентированного проектирования. Например, можно сказать, что объект Sale отвечает за создание экземпляра SalesLineItems (действие) или что объект Sale отвечает за наличие информации о стоимости покупки (знание).
Обязанности-знания зачастую вытекают из модели предметной области, поскольку она иллюстрирует атрибуты и ассоциации. Например, если в модели предметной области класс Sale содержит атрибут time, то программный класс Sale тоже должен «знать» время соответствующей продажи.
Возможность реализации обязанностей в виде классов и методов зависит от точности их описаний. Реализация сложных обязанностей требует определения сотен классов и методов. Для простых обязанностей достаточно одного метода. Например, реализация обязанности «обеспечения доступа к реляционным БД» может потребовать создания десятков классов и сотен методов. А для реализации обязанности «создание экземпляра объекта Sale» достаточно одного метода одного класса.
В RDD существует идея кооперации (collaboration). Обязанности реализуются посредством методов, действующих либо отдельно, либо во взаимодействии с другими методами и объектами. Например, для класса Sale 5 можно определить один или несколько методов вычисления стоимости (скажем, метод getTotal). Для выполнения этой обязанности объект Sale должен взаимодействовать с другими объектами, в том числе передавать сообщения getSubtotal каждому объекту SalesLineItem.
RDD — это общий подход к проектированию программных объектов. Программные объекты рассматриваются как люди, имеющие свои обязанности и сотрудничающие с другими людьми для их выполнения.
Согласно основному принципу RDD, объектное программное решение представляет собой сообщество взаимодействующих объектов, имеющих свои обязанности.
Основные принципы распределения обязанностей выражены в шаблонах (или принципах) GRASP.
ПРИНЦИПЫ GRASP
Принципы объектно-ориентированного проектирования отражены в шаблонах GRASP, изучение и применение которых позволит освоить методологический подход к проектированию на основе распределения обязанностей.
Аббревиатура GRASP означает «General Responsibility Assignment Software Patterns (Общие принципы распределения обязанностей в программных системах)»
В состав GRASP входят 9 принципов: Creator (Создатель), Controller (Контроллер), Indirection (Перенаправление), Information Expert (Информационный эксперт), High Cohesion (Высокое зацепление), Low Coupling (Низкая связность), Polymorphism (Полиморфизм), Protected Variations (Защищенные изменения), Pure Fabrication (Чистая синтетика).
