
- •1)Понятие информационной системы (ис). Классификация ис.
- •2) Свойства, характеризующие ис. Составные части ис: функциональная и обеспечивающая (-ие). Потребительские свойства ис.
- •3)Стадии и этапы создания ис. Особенности проектов разработки ис. Трудности, возникающие в процессе разработки ис.
- •4)Жизненный цикл (жц) по ис. Модели жц по.
- •6)Уровни требований.
- •7)Требования функциональные и нефункциональные.
- •8)Свойства требований.
- •9) Характеристика процесса анализа требований. Результат анализа требований.
- •10) Источники требований. Стратегии выявления требований.
- •11) Формирование видения. Разработка концепции информационной системы. Концепция в гост 34.601-90.
- •1. Формирование требований к ас.
- •2. Разработка концепции ас.
- •12) Цели прототипирования. Классификация прототипов.
- •13)Классификация и спецификация требований.
- •14) Варианты использования. Описание вариантов использования. Диаграмма вариантов использования на uml.
- •15)Документирование требований.
- •16)Этапы проектирования.
- •4. Эскизный проект.
- •5. Технический проект.
- •17)Области проектирования.
- •18) Методология и технология проектирования. Требования к технологии проектирования.
- •19)Диаграмма прецедентов.
- •20)Диаграмма классов.
- •21)Диаграмма деятельности.
- •22)Диаграмма взаимодействий.
- •23)Диаграмма состояний.
- •24)Диаграмма компонентов.
- •25)Диаграмма развёртывания.
- •26)Принципы проектирования графического пользовательского интерфейса.
- •27)Проектирование оконного интерфейса.
- •28)Проектирование Web-интерфейса.
- •29)Моделирование навигации в графическом пользовательском интерфейсе.
- •30) Параметрически-ориентированное проектирование.
- •31)Модельно-ориентированное проектирвоание.
- •32) Критерии и стратегии выбора решения (покупное по, заказное по или интеграция).
- •33) Интеграция программных систем. Виды интеграции.
19)Диаграмма прецедентов.
Диаграмма прецедентов (англ. use case diagram, диаграмма вариантов использования) — диаграмма, на которой отражены отношения, существующие между акторами и прецедентами.
Основная задача — представлять собой единое средство, дающее возможность заказчику, конечному пользователю и разработчику совместно обсуждать функциональность и поведение системы.
При работе с вариантами использования важно помнить несколько простых правил:
каждый вариант использования относится как минимум к одному действующему лицу;
каждый вариант использования имеет инициатора;
каждый вариант использования приводит к соответствующему результату (результату с «бизнес-значением»).
20)Диаграмма классов.
Диаграмма классов - статическая структура модели.
Описывает структуру системы, показывая её классы, их атрибуты и операторы, а также взаимосвязи этих классов. Основа – понятие класса ООП.
Обязательным элементом для класса является его имя
Правила для ДК:
Имя класса должно быть уникальным в пределах пакета.
Имя класса - это имя существительное в именительном падеже. Записывается имя полужирным шрифтом посередине поля и должно начинаться с заглавной буквы.
Для абстрактного класса (не имеющего экземпляров или объектов) имя - курсив
Атрибуты класса:
<квантор видимости><имя атрибута>[кратность]:<тип атрибута>=<исходное значение>{строка-свойство}
квантор видимости: + - #
Имя – идентификатор
Кратность атрибута: общее количество конкретных атрибутов данного типа, входящих в класс:
[нижняя_граница1..верхняя_граница1, нижняя_граница2..верхняя_граница2, …, нижняя_границаN..верхняя_границаN]
Тип атрибута: выражение, семантика которого определяется спецификацией модели.
Примеры:
имя[1..2]:string
точка:Point
Исходное значение: для задания некоторого начального значения атрибута в момент создания экземпляра класса
Примеры:
имя[1..2]:string=Дмитрий Александрович;
точка:Point=(0,0,15)
Подчеркивание строки атрибута - атрибут может принимать подмножество значений из области значений атрибутов, определяемой его типом.
Строка-свойство: какие значения не могут быть изменены в программе при работе с данным типом объектов .
Операция
представляет собой некоторую услугу, которая предоставляется экземпляром класса по определенному требованию
Совокупность услуг характеризует поведение данного класса.
Правила записи:
Запись операции располагается на отдельной строке поля
<квантор видимости><имя операции>(список параметров):<тип возвращаемого значения>{строка-свойство}
<вид параметра><имя параметра>:<тип параметра>=<значение параметра по умолчанию>
Вид параметра - in, out, i nout
Примеры:
+показать()
+нарисовать(форма: точка = координаты, цвет:int=4)
сообщение():{"ERROR"}
Отношения ДК:
отношение зависимости,
изменение одного элемента объекта влечет за собой изменение другого, зависимого объекта
отношение ассоциации,
определяет некоторое отношение между классами
отношение обобщения
о
писывает
иерархическую структуру классов на
диаграмме