
- •Этапы развития технологии программирования
- •1). «Стихийное» программирование (до середины 60х гг.).
- •2). «Структурный» подход к программированию (60е – 70е гг.).
- •3). Объектный подход (середина 80-х – конец 90х гг.).
- •Компонентный подход к программированию и case-технологии.
- •Платформа .Net
- •Проблемы разработки сложных программных систем
- •Блочно-иерархический подход к созданию сложных систем
- •Жизненный цикл и этапы разработки программного обеспечения
- •Модели жизненного цикла программного обеспечения
- •Модели с промежуточным контролем.
- •Понятия эффективности и технологичности программного обеспечения.
- •Модули и их свойства (сцепление модулей).
- •Модули и их свойства (связность модулей)
- •Нисходящая и восходящая разработка программного обеспечения
- •Структурное программирование.
- •Линейный, 2)разветвляющий, 3) цикличный.
- •Средства описания структурных алгоритмов (псевдокоды, блок-схемы алгоритмов, Flow-формы, диаграммы Насси-Шнейдермана).
- •Правила оформления программ
- •Этап постановки задачи. Классификация программных продуктов по функциональному признаку.
- •Этап постановки задачи. Основные эксплуатационные требования к программным продуктам.
- •Этап постановки задачи. Предпроектные исследования предметной области.
- •Разработка технического задания.
- •Принципиальные решения начальных этапов проектирования (выбор архитектуры программного обеспечения, выбор пользовательского интерфейса, выбор языка программирования и т.Д.).
- •2) Выбор типа пользовательского интерфейса.
- •3) Выбор подхода к разработке.
- •4) Выбор языка программирования.
- •Классификация моделей разрабатываемого программного обеспечения
- •Модели разрабатываемого по, используемые на этапе анализа технического задания. Структурный подход. Диаграммы переходов состояний.
- •Модели разрабатываемого по, используемые на этапе анализа технического задания. Структурный подход. Функциональные диаграммы.
- •Модели разрабатываемого по, используемые на этапе анализа технического задания. Структурный подход. Диаграммы потоков данных.
- •Модели разрабатываемого по, используемые на этапе анализа технического задания. Структурный подход. Структуры данных и диаграммы отношений компонентов данных.
- •Модели разрабатываемого по, используемые на этапе анализа технического задания. Структурный подход. Сетевая модель данных (Диаграммы «сущность-связь»)
- •Модели разрабатываемого по, используемые на этапе анализа технического задания. Структурный подход. Математические модели.
- •Проектирование программного обеспечения при структурном подходе. Структурная и функциональная схемы.
- •Метод пошаговой детализации при проектировании структуры по
- •Структурный подход. Структурные карты Константайна
- •Проектирование программного обеспечения при структурном подходе. Проектирование структур данных
- •Модель использования. Определение вариантов использования. Диаграммы вариантов использования.
- •Построение диаграммы классов на этапе анализа технического задания.
- •Диаграмма последовательностей системы.
- •Построение диаграммы деятельности на этапе анализа технического задания.
- •Проектирование по при объектном подходе.
- •Диаграмма пакетов.
- •Диаграмма классов этапа проектирования. Уточнение отношений между классами на этапе проектирования.
- •Диаграммы последовательностей этапа проектирования.
- •Диаграммы состояний объекта
- •Диаграмма деятельности на этапе проектирования.
- •Диаграмма компонентов
- •Диаграмма размещения
- •Тестирование программных продуктов.
- •Структурное тестирование.
- •Функциональное тестирование.
- •Восходящее и нисходящее тестирование
- •Классификация ошибок
- •Методы отладки программного обеспечения
Диаграмма деятельности на этапе проектирования.
Достаточно существенную информацию о действиях, которые должны выполняться методами класса, можно получить, анализируя диаграммы последовательности действий. Однако алгоритмы всех сколько-нибудь сложных методов необходимо проработать детально. При этом можно использовать как уже известные нотации (схемы алгоритмов и псевдокоды), так и диаграммы деятельностей.
Диаграммы деятельностей могут использоваться и при проектировании методов обработки сообщений, в том числе и затрагивающих несколько объектов. В последнем случае целесообразно указать вертикальными пунктирными линиями ответственности объектов соответствующих классов, что позволит проследить вызовы других объектов.
Следует помнить, что в соответствии с общими правилами процедурной декомпозиции любую деятельность можно декомпозировать и изобразить в виде диаграммы деятельности более низкого уровня.
Диаграмма компонентов
Диаграммы компонентов применяют при проектировании физической структуры разрабатываемого программного обеспечения. Эти диаграммы показывают, как выглядит программное обеспечение на физическом уровне, т. е. из каких частей оно состоит и как эти части связаны между собой.
Диаграммы компонентов оперируют понятиями компонент и зависимость. Под компонентами при этом понимают физические заменяемые части программного обеспечения, которые соответствуют некоторому набору интерфейсов и обеспечивают их реализацию. По сути дела, это отдельные файлы различных типов: исполняемые (ехе), текстовые, графические, таблицы баз данных и т. п., составляющие разрабатываемое программное обеспечение. Условные графические обозначения компонентов различных типов приведены на рис. 7.6.
а б в г
Рис. 7.5. Условные обозначения компонентов в UML: а - программный компонент, б- файл, в - база данных, г - таблица базы данных.
Зависимость между компонентами фиксируют, если один компонент содержит некоторый ресурс (модуль, объект, класс и т. д.), а другой - его использует. Качество компоновки оценивают по количеству и типу связей между компонентами, т. е. по степени независимости компонентов. На диаграмме компонентов зависимость обозначают пунктиром со стрелкой на конце.
Рис. 7.6. Диаграмма компоновки Internet-приложения, которое выводит фотографию и текст «Hello World».
Для программного обеспечения с архитектурой «клиент-сервер», диаграмму компонентов можно использовать в качестве структурной схемы, определяющей архитектуру разрабатываемого программного обеспечения, так как она позволяет показать связи по управлению частей системы (компонентов). Однако при проектировании такую схему необходимо уточнить, показав более подробно состав компонентов разрабатываемой системы.
Диаграмма размещения
При физическом проектировании распределенных программных систем необходимо определить наиболее оптимальный вариант размещения программных компонентов на реальном оборудовании в локальной или глобальной сетях. Для этого используют специальную модель UML - диаграмму размещения.
Диаграмма размещения отражает физические взаимосвязи между программными и аппаратными компонентами системы. Каждой части аппаратных средств системы, например, компьютеру или датчику, на диаграмме размещения соответствует узел. Соединения узлов означают наличие в системе соответствующих коммуникационных каналов. Внутри узлов указывают размещенные на данном оборудовании программные компоненты разрабатываемой программной системы, сохраняя указанные на диаграмме компонентов отношения зависимости.
С точки зрения диаграммы размещения локальная и глобальная сети - это тоже узлы, которые обладают некоторой спецификой. На рис. 7.7. показаны условные обозначения узлов (процессора и устройства) на диаграмме размещения.
Рис. 7.7. Условные обозначения диаграммы размещения: а - процессор (компьютер), б – устройство.