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