- •Использование системного подхода при проектировании программного обеспечения
- •Основные проблемы разработки и проектирования по и методы их преодоления
- •Понятие жизненного цикла по и его роль в проектировании информационных систем
- •Понятие модели жц в проектировании информационных систем, терминология моделей жц
- •Основные модели жц и рекомендации по их использованию
- •Преимущества и недостатки использования каскадной модели жц
- •Преимущества и недостатки использования эволюционной модели жц
- •Сравнение эволюционной и итерационной моделей жц
- •Понятие архитектуры программного обеспечения и причины возникновения такого понятия в рамках процесса создания информационных систем
- •Понятие "сложности" в современном проектировании информационных и способы её преодоления
- •Использование принципа декомпозиции в процессе проектирования информационных систем
- •Принципы объектно-ориентированного подхода к проектированию информационных систем
- •Основные понятия объектно-ориентированного подхода к проектированию информационных систем
- •Понятие соединения между элементами объектной модели и различные виды соединений
- •Понятие гибкого моделирования, манифест и основные принципы гибкого процесса проектирования
- •Понятие гибкого унифицированного процесса проектирования
- •Фазы и дисциплины унифицированного процесса проектирования, распределение работ на различных фазах для основных дисциплин
- •Начальная фаза унифицированного процесса и артефакты, которые могут создаваться на этой фазе процесса проектирования
- •Понятие требования к информационной системе, типы и категории требований
- •Понятие прецедента в процессе моделирования требований к информационной системе, модель прецедентов.
- •Понятие исполнителя в процессе формализации требований к информационной системе
- •Артефакты унифицированного процесса, используемые для описания нефункциональных требований к информационной системе
- •Фаза развития унифицированного процесса и артефакты, которые могут создаваться на этой фазе процесса проектирования
- •Задачи фазы развития унифицированного процесса и планирование итераций на этой фазе проектирования
- •Моделирование предметной области и основные понятия модели предметной области
- •Использование классов описаний и производных атрибутов в процессе моделирования предметной области
- •Понятие системного события и идентификация системных событий
- •Открытый системный интерфейс и описание операций в рамках унифицированного процесса проектирования
- •Проектирование динамической структуры по с использованием uml в рамках объектно-ориентированного подхода
- •Средства uml для выражения полиморфных сообщений в контексте проектирования динамической структуры по
- •Средства uml для выражения асинхронных вызовов в контексте проектирования динамической структуры по
- •Проектирование статической структуры по с использованием uml в рамках объектно-ориентированного подхода
- •Средства uml для представления атрибутов коллекций в контексте проектирования статической структуры по
- •Признаки существования зависимости между классами в контексте проектирования статической структуры по
- •Стадии создания информационной системы в рамках канонического проектирования
- •Обследование и технико-экономическое обоснование проекта
- •Разработка технического задания в соответствии с гост 34.602-89
- •Состав и содержание технического задания (гост 34.602- 89)
- •Состав эскизного и технического проектов
- •Типовое проектирование информационных систем
Средства uml для представления атрибутов коллекций в контексте проектирования статической структуры по
Формат описания атрибута имеет следующий вид:
Область_видимости имя : тип кратность = значение_по_умолчанию {строка свойств}
Если область видимости не указана явно, то предполагается, что атрибут относится к закрытой области видимости.
Представление атрибута с помощью линии ассоциации на диаграммах класса проектирования осуществляется следующим образом:
Стрелка навигации – указывает направление связи от объекта источника к целевому объекту, это значит, что объект источник в качестве своего атрибута содержит целевой объект.
Кратность – указывается со стороны целевого объекта
Имя роли - Определяет имя атрибута и указывается только со стороны целевого объекта
Имя ассоциации отсутствует.
Атрибут обозначается с использованием имени, если относится к типом данных и линией ассоциации во всех других случаях. (рекомендательный характер)
Термин «тип данных» применим к тем объектам, для которых уникальная тождественность не является важной. Необходимо понимать, что значимые различие в обозначении атрибутов только в процессе проектирования (для выставления визуальных акцентов и большей наглядности диаграмм). В программном коде все атрибуты всегда записываются однообразно. Рядом с линией ассоциации в соответствии с описанием атрибута можно указывать строку ограничений в фигурных скобках.
Представление атрибутов коллекций.
Class A
{
List <Item> items;
}
Блоки примечаний используется в трех случаях:
Примечание – некий произвольны текст.
Для указания ограничений, если текст заключен в фигурные скобки.
Для указания тела метода.
Формат операции:
Область_видимости имя (список_параметров): тип_фозвращаемого_значения {строка свойств}
Если область видимости не указана, то она считается public.
Операции — это не метод, а объявление с указанием имени, параметров, строки свойств и т.д.
Метод – реализация операции. Для того, чтобы правильно показывать методы.
Ключевые слова – текстовые представления категории или метомодели, самые часто используемые слова: <<актер>>, <<interface>>, <<abstract>>, {ordered}
<<>> {} “” –это возможные обозначения.
Стереотип – отображает уточнение существующего понятия моделирования или проектирования.
В отличие от ключевых свойств допускается определение пользовательских стереотипов.
Стереотип определяет множество дескрипторов или меток, с использованием синтаксиса атрибутов. Если элемент модели отмечен некоторым стереотипом, то все метки стереотипа применяется и к этому стереотипу.
Пример определения стереотипа и пример его использования:
Стереотип расширяет такой класс как Element
Свойство – именованное значение, описывающая характеристику элемента и имеющая семантическое значение. Часть свойств определены стандартом UML, остальные могут быть определены пользователем самостоятельно.
Текстовое представление свойств выглядит следующим образом:
{Имя = значение1, имя2 = значение2}
Признаки существования зависимости между классами в контексте проектирования статической структуры по
Зависимость (отношение зависимости)
Элемент клиент обладает знанием об элементе поставщике. (пунктирная стрелка от клиента к поставщику)
Зависимость есть когда:
Клиент обладает атрибутом типа элемента поставщика.
Происходит отправка сообщения поставщику посредством:
Атрибутов
Переменных – параметров
Локальной переменной
Глобальной переменной
Вызовом статических членов.
Когда происходит получение параметра с типом элемента поставщика
Поставщик является супер классом или интерфейсом.
Для избегания дублирования на диаграммах классов проектирования UML следует использовать
обозначения зависимости для отображения глобальных переменных, переменных параметров,
локальных переменных и статических методов, когда есть их вызов. Во всех остальных случаях –
линиями другого типа.