- •1.Проблемы создания больших программ.
- •2. Основные понятия
- •3. Состав жизненного цикла по
- •1.Анализ требований
- •4.Стандартизация процессов жизненного цикла программ
- •5. Модели жизненного цикла программного обеспечения.
- •6.Техническое задание на разработку.
- •7.Документирование программ.
- •8.Выбор архитектуры по.
- •9.Структурный и объектный подходы к разработке программ.
- •10. Метод структурного анализа и проектирования sadt (idef0)
- •11. Диаграммы потоков данных dfd.
- •12. Диаграмма сущность – связь erm
- •13. Методы объектно-ориентированного анализа и проектирования. Язык uml.
- •14. Методы разработки структуры программной системы
- •15.Выбор языка программирования. Стиль программирования.
- •16.Защитное программирование.
- •17.Тестирование и отладка
- •18.Типичные ошибки
- •19.Отладка программных продуктов
- •20.Ввод в зксплуатацию
- •21.Ускорение разработки по. Технология rad
- •22. Экстремальное программирование
13. Методы объектно-ориентированного анализа и проектирования. Язык uml.
UML – унифицированный язык моделирования. Основой объектно-ориентированного анализа и проектирования программы является объектная модель.
Её основные принципы:
1.абстрагирование
2.инкапсуляция
3.модульность
4.иерархия
и понятия ( объект, класс, атрибут, операция, интерфейс ) наиболее чётко сформулированы Гради Бучом.
Большинство современных методов анализа и проектирования основываются на использовании языка UML.
UML- язык для определения представления, проектирования и документирования ПС. UML содержит стандартный набор диаграмм и нотаций. Создание UML началось в конце 1994 года Гради Бучом и Джейсом Рамбом.
Главными в разработке UML были следующие цели:
1.предоставление пользователям готовый к использованию выразительный язык визуального моделирования, позволяющий разработчикам осмысливать модели и обмениваться ими.
2.предусмотрение механизмов расширенности и специализации для расширения базовых концепций.
3.обеспечить независимость от конкретных языков программирования.
4.язык должен быть точным и доступным для понимания, лишен формализма.
5.стимулировать рост рынка объектно-ориентированных инструментальных средств.
6.интегрировать лучший практический опыт.
Стандарт UML версия 1.1., принятый организацией OMG в 1997 году.
Содержит следующий набор диаграмм:
1.структурные модели:
1.1 диаграммы классов для моделирования статичной структуры классов системы и связи между ними.
диаграмма компонентов для моделирования иерархии компонентов системы.
диаграммы размещения для моделирования физической архитектуры системы.
2.модели поведения:
2.1 диаграммы вариантов использования для моделирования функциональных требований к системе (в виде сценариев взаимодействия пользователя с системой).
2.2. диаграммы взаимодействия
2.3. диаграммы последовательности и кооперативные диаграммы для моделирования процесса обмена сообщениями между объектами.
2.4.диаграммы состояний для моделирования поведения объекта системы при переходе из 1 состояния в другое.
2.5. диаграммы деятельности для моделирования поведения системы в рамках различных вариантов использования или потоков управления.
1.1Диаграмма классов - определяет типы классов системы и статические связи. На диаграммах классов изображаются их атрибуты, операции классов и ограничения, которые накладываются на связи между классами.
1.2Диаграммы компоненты – моделируют физический уровень системы, на них изображаются компоненты ПО и связи между ними.
Выделяют 2 типа компонентов: исполняемые и библиотеки кода.
Каждый класс модели преобразуется в компонент исходного кода.
Между отдельными компонентами изображают зависимости, соответствующие зависимости на этапе компиляции или выполнению программы.
Диаграммы компонентов применяют участники проекта, ответственные за компиляцию и сборку системы. Они нужны там, где начинается генерация кода.
1.3Диаграмма размещения – отражает физические взаимосвязи между программными и аппаратными компонентами системы.
Её основными элементами являются узел (вычислительный ресурс и соединения – канал взаимодействия узлов, т.е. сеть).
Диаграммы использует менеджер проекта, пользователи, архитектор системы и эксплуатационный персонал. Для понимания физического размещения системы и расположения её отдельных подсистем.
2.1 Диаграмма вариантов использования показывает взаимодействие между вариантами использования и действующими лицами, отражая функциональные требования к системе с точки зрения пользователя.
Цель построения диаграмм: документирование функциональных требований в общем виде.
Модель вариантов имеет следующие достоинства:
1.определяет пользователей и границы системы;
2.определяет системный интерфейс;
3.удобна для общения пользователей с разработчиками;
4.используется для написания текста программ;
5.является основой для написания пользовательской документации;
6.хорошо вписывается в любые методы проектирования, как структурные, так и объектно-ориентированные;
ПРИМЕРЫ!!!!!
2.2. Диаграммы взаимодействия описывают поведения, взаимодействия групп объектов. На диаграммах отображается ряд объектов и те сообщения, которыми они обмениваются между собой.
Существуют 2 вида диаграмм взаимодействия:
1.диаграммы последовательности
2.кооперативные диаграммы
Диаграммы последовательности отражают временную последовательность событий, происходящих в рамках варианта использования.
Кооперативные диаграммы концентрируют внимание на связях между объектами. ПРИМЕРЫ!!!
2.4. Диаграммы состояния определяют все возможные состояния, в которых может находиться объект, а также процесс смены состояния объекта в результате наступления некоторого события.
Диаграммы не надо создавать для каждого объекта, их применяют только в сложных случаях.
2.5. Диаграммы деятельности используются при описании поведения системы, включающей большое количество программных процессов, а также применяются для описания потоков событий и вариантов использования.
UML обладает механизмами расширения, предназначенными для того, чтобы разработчики могли адаптировать язык моделирования к своим конкретным нуждам.
Механизм расширения даёт преимущества UML перед: IDEFO, DFD, ERM.
UML допускает произвольную интерпретацию семантики (смысл значения команды) элементов модели.
UML является слабо типизированным языком. К механизмам расширения языка UML относят стереотипы, именованные значения и ограничения.
Стереотип – новый тип элемента модели, который определяется на основе уже существующего элемента.
Стереотипы классов - это механизм, позволяющий разделять классы на категории. ПРИМЕР!
Именованное значение – пара строк : тег = значение или имя = содержимое , в которых хранится дополнительная информация о элементе системы.
Например: время создания, статус разработки, время окончания работ.
Семантическое ограничение, имеющее вид текстового выражения, которое невозможно выразить с помощью нотации UML. ПРИМЕР!