- •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.
40 Диаграмма прецедентов.
Показывает:
исполнителей
прецеденты
отношения между ними
Диаграммы прецедентов имеют второстепенное значение
Обозначения:
Отношение «extend» предоставляет возможность ввести новое поведение в существующий вариант использования (рис.1). Базовый ВИ представляет собой набор точек расширения (extension points) - точек входа, в которые может быть добавлено новое поведение. А расширяющий ВИ предоставляет ряд сегментов вставки, которые можно ввести в базовый в места, указанные точками входа. Базовый ВИ абсолютно полон и без расширений. Это существенно отличает «extend» от отношения «include», где базовые ВИ остаются неполными без включаемых ВИ.
Отношение включения («include»), устанавливаемое между вариантами использования, позволяет включить поведения одного варианта использования в поток другого варианта использования.
Включающий вариант использования назовем базовым, а тот, который включается, включаемый. Включаемый вариант использования предоставляет поведение своему базовому варианту использования.
В базовом ВИ необходимо точно указать место, где должно быть включено поведение включаемого ВИ. Синтаксис и семантика отношения включения немного напоминает вызов процедуры или функции.
Отношение включения имеет простую семантику. Базовый ВИ выполняется до момента включения. Затем выполнение переходит на включаемый ВИ. После завершения включаемого ВИ управление вновь возвращается в базовый ВИ.
41. Диаграмма классов. Обозначение классов. Отношение ассоциации.
42.Диаграмма классов. Обозначение интерфейсов. Отношение обобщения и зависимости.
Содержание класса
Обычно показывают: имя класса, ключевые атрибуты, ключевые операции, стереотипы
Обычно не показывают: параметры операций, видимость, исходные значения
Имя класса
- Существительное или именная группа
- Стиль: «UpperCamelCase»
- Избегать сокращений (DpstAccnt) и аббревиатур
- Имя абстрактного класса: курсив или свойство {abstract}
- Имя конечного класса: свойство {leaf}
Атрибуты
- Определяют состояние экземпляров
- Синтаксис: видимость имя: тип [кратность] = значение {свойства}
- Статические атрибуты подчеркиваются
Операции
- Характеризуют поведение экземпляров
- Синтаксис: видимость имя(параметры): результат {свойства}
- Статические операции подчеркиваются
- Абстрактные операции выделяются курсивом или помечаются свойством {abstract}
- Конечные операции — свойство {leaf}
О
тношения:
Ассоциация
- Указывает, что между объектами классов могут устанавливаться связи
- Обозначает действие, производимое исходным объектом над целевым элементом
- Синтаксис:
имя (глагол)
имена ролей (существительное)
кратность (задается явно)
возможность навигации
- Указывается: имя или роли
- Возможность навигации — «сообщения могут посылаться только в том направлении, в котором указывает стрелка»
- Стили указания: абсолютно явная навигация, абсолютно скрытая навигация, явная навигация
Рефлексивные ассоциации
Класс ассоциации
Единственная уникальная связь
Квалифицированные ассоциации
В
ыбирает
один объект из набора
Частные случаи ассоциации:
Агрегация
- Самое общее отношение типа «целое — часть»
- Не рекомендуется
Композиция
- Отношение типа «целое — часть»
- Части не могут существовать вне целого
- «Нет совместного владения»
- Целое может передавать свои части
Зависимость
Элемент-клиент обладает знаниями об элементе-поставщике, изменение в поставщике может повлиять на клиента
Рекомендуется использовать для обозначения:
- глобальных переменных
-переменных-параметров
- вызовов статических методов
Обобщение
Класс является частным случаем другого класса
Интерфейс
Нотации:
- класс (стереотип «interface»)
- «леденец на палочке»
Реализация интерфейса
Диаграмма классов, Class diagram — статическая структурная диаграмма, описывающая структуру системы, она демонстрирует классы системы, их атрибуты, методы и зависимости между классами.
