3 Проектирование разработка Технологии программирования Обзор n

3. Проектирование, разработка Технологии программирования

Обзор n Проектирование ПП при структурном подходе n Проектирование ПП при объектном подходе n Разработка ПП

Принципы моделирования n Модели позволяют наглядно продемонстрировать желаемую структуру и поведение системы n Модели необходимы для визуализации и управления архитектурой системы n Модели помогают добиться лучшего понимания создаваемой системы, что зачастую приводит к ее упрощению и возможности повторного использования. n Модели необходимы для минимизации риска

Структурный подход n Сущность структурного подхода заключается в декомпозиции программы по функциональному принципу n Полученная в результате структура должна быть представлена в виде структурной и /или функциональной схемы и спецификации ее компонентов

Структурная схема n Структурной называют схему, отражающую состав и взаимодействие по управлению модулями разрабатываемого ПП n Компонентами структурной схемы могут служить программы, подсистемы, БД, библиотеки ресурсов и т. п.

Функциональная схема n Функциональной называют схему взаимодействия компонентов ПО с описанием информационных потоков, состава данных в потоках и с указанием используемых файлов и устройств

Обозначения элементов функциональных схем ГОСТ 19. 701 -90

Пошаговая детализация при проектировании структуры l не отделять операции инициализации и завершения от соответствующей обработки l не проектировать слишком специализированных или слишком универсальных модулей l избегать дублирования действий в различных модулях, целесообразно просто реализовать эти действия в отдельном модуле l группировать сообщения об ошибках в один модуль по типу библиотеки ресурсов

Объектный подход n Модели разрабатываемого программного обеспечения при объектном подходе основаны на предметах и явлениях реального мира n На этапе анализа при объектном подходе ставятся две задачи: l уточнить требуемое поведение разрабатываемого программного обеспечения l разработать концептуальную модель его предметной области с точки зрения поставленных задач

UML-Унифицированный язык моделирования n UML (Unified Modeling Language )является графическим языком для визуализации, специфицирования, конструирования и документирования систем n Принципы: l l n абстрагирования многомодельности Наиболее общими представлениями сложной системы принято считать статическое и динамическое представления

Концептуальная модель n Составные части: l основные строительные блоки языка l правила сочетания блоков l некоторые общие для всего языка механизмы.

Спецификация ПП при объектном подходе n Каждая из моделей характеризует определенный аспект проектируемой системы, а все они вместе составляют относительно полную модель разрабатываемого. ПП

Строительные блоки n Словарь языка UML включает три вида строительных блоков: l предметы - сущности как абстракции, являющиеся основными элементами модели l отношения - связывают различные предметы l диаграммы - группируют представляющие интерес совокупности предметов

Структурные предметы. UML n Играют роль существительных в моделях на языке UML. Представляют собой статические части модели, соответствующие концептуальным (понятийным) или физическим элементам системы

Поведенческие предметы. UML n Это глаголы языка, описывающие поведение модели во времени и пространстве. Являются динамическими составляющими модели UML: l Взаимодействие(Interaction) представляет собой поведение, суть которого в обмене сообщениями между объектами l Автомат (State machine) - последовательность состояний, через которые объект проходит на протяжении своего жизненного цикла в ответ на различные события l Деятельность (Activity) - последовательность шагов процесса вычислений

Группирующие предметы UML n Являются организующими частями модели UML. Это блоки, на которые можно разложить модель n Пакеты(Packages) представляют собой универсальный механизм организации элементов в группы n В пакет можно поместить структурные, поведенческие и другие группирующие сущности

Поясняющие предметы n Представляют собой аннотационные сущности или пояснительные части модели UML. Это комментарии для дополнительного описания, разъяснения или замечания к любому элементу модели n Примечание (Note) - это символ для изображения комментариев или ограничений, присоединенных к элементу или группе элементов

Отношения: зависимость n Зависимость (Dependency) - семантическое отношение между двумя сущностями, при котором изменение одной из них, независимой, может повлиять на семантику другой, зависимой n Графически зависимость изображается в виде прямой пунктирной линии, часто со стрелкой, направленной от зависимой сущности к независимой, которая может содержать метку

Отношения: ассоциация n Ассоциация(Association - структурное отношение, ) описывающее совокупность связей как соединением между объектами. Ассоциации предполагают участие равноправных классов n Графически ассоциация изображается в виде линии, соединяющей класс сам с собой или с другими классами

Отношения: обобщение n Обобщение (Generalization) – отношение, при котором объект специализированного элемента (потомок) может быть подставлен вместо объекта обобщенного элемента (родителя или предка). n Потомок наследует структуру и поведение своего родителя n Графически отношение обобщения изображается в виде линии с не закрашенной треугольной стрелкой, указывающей на родителя

Отношения: реализация n Реализация (Realization) - семантическое отношение между структурными предметами, при котором один предмет определяет соглашение ("контракт"), а другой гарантирует его выполнение. n Реализации употребляются в двух ситуациях: в контексте интерфейсов и в контексте коопераций. n Графически отношение реализации изображается в виде пунктирной линии с не закрашенной треугольной стрелкой, как нечто среднее между отношениями обобщения и зависимости

Диаграммы n Диаграмма - это графическое представление совокупности элементов, чаще всего изображаемое в виде связного графа, состоящего из вершин (сущностей) и ребер (отношений ) n С помощью диаграмм можно визуализировать систему с различных точек зрения n Диаграммы можноиспользовать двумя способами : l для описания моделей, на основе которых в дальнейшем будет сконструирована исполняемая система (прямое проектирование) l для воссоздания модели из частей существующей исполняемой системы (обратное проектирование)

Диаграмма прецедентов (вариантов использования) n Показывает взаимодействие пользователя и системы с точки зрения ее функционирования l Действующее лицо- внешняя по отношению к разрабатываемому ПП сущность, которая взаимодействует с ним l Вариант использования- некоторая очевидная для действующего лица процедура, решающая его конкретную задачу l Связь - взаимодействие действующих лиц и соответствующих вариантов использования

Диаграмма классов n Показывает набор классов, интерфейсов, объектов и коопераций, а также их отношения n UML предлагает использовать три уровня диаграмм классов в зависимости от степени их детализации: l концептуальная модель - на этапе анализа l уровня спецификации - на этапе проектирования l уровня реализации - на этапе реализации

Диаграмма объектов. Диаграмма последовательностей. n Диаграмма объектов представляет объекты и отношения между ними. Является экземпляром диаграммы классов n Диаграмма последовательностей графическая — модель, которая для определенного сценария варианта использования показывает генерируемые действующими лицами события и их порядок l диаграммы последовательности отражают временную упорядоченность сообщений l диаграммы кооперации - структурную организацию обменивающихся сообщениями объектов

Диаграмма состояний n Показывают состояния объекта, возможные переходы, а также события или сообщения, вызывающие каждый переход l состояниеобъекта - ситуация в жизненном цикле объекта, во время которой он удовлетворяет некоторому условию, осуществляет определенную деятельность или ожидает некоторого события l переход - изменение состояния, связанное с нарушением условия или, соответственно, завершением деятельности или наступлением события

Диаграмма деятельности n Представляет переходы потока управления от одной деятельности (не атомарные, а последовательность шагов) к другой внутри системы n Деятельностьзадача (операцию), которую необходимо выполнить вручную или с помощью средств автоматизации n Позволяют описывать альтернативные и параллельные процессы

Диаграмма компонентов n Представляет организацию совокупности компонентов и существующие между ними зависимости n Применяют при проектировании физической структуры разрабатываемо ПП n Компонентами физические заменяемые части программного обеспечения, которые соответствуют некоторому набору интерфейсов и обеспечивают их реализацию

Диаграмма развертывания. Диаграмма размещения. n Диаграмме развертывания представляет конфигурациюобрабатывающих узлов системы и размещенных в нихкомпонентов n Диаграмма размещенияотражает физические взаимосвязи между программными и аппаратными компонентами системы

Этап разработки n На этапе разработки ПП выполняются следующие основные действия: l кодирование l первичное тестирование l разработка справочной системы ПП l создание документации пользователя l создание версии и инсталляции ПП

Первичное тестирование n На этапе кодирования программист сам тестирует программы. Такое тестирование называется модульным n Преимущества: l направленность тестирования l полный охват кода l возможность управления потоком команд l возможность отслеживания целостности данных l видение внутренних граничных точек l возможность тестирования, определяемого выбранным алгоритмом

Разработка справочной системы ПП n У хорошо документированного ПП имеются следующие преимущества: l Легкость использования l Меньшая стоимость технической поддержки l Высокая надежность l Легкость сопровождения l Упрощенная установка l Коммерческий успех

Виды программных документов ГОСТ 19. 101 -77 n Основные программные документы по стандарту: l Спецификация l Текст программы l Описание программы l Ведомость эксплуатационных документов (формуляр, описание применения, руководство программиста, оператора, описание языка, руководство по техническому обслуживанию) l Программа и методика испытаний l Пояснительная записка

Пояснительная записка ГОСТ 19. 404 -79 n Должна содержать всю информацию, необходимую для сопровождения и модификации программного обеспечения: l введение l назначение и областьприменения l технические характеристики l ожидаемые технико-экономическиепоказатели l источники используемые при разработке ,

Руководство пользователя n Руководство пользователя, как правило, содержит следующие разделы : l общие сведения о программном продукте l описание установки l описание запуска l инструкциипо работе (или описание пользовательского интерфейса ) l сообщения пользователю

Создание инсталяции ПП n Позволяет автоматизировать процесс установки ПП на компьютеры пользователей, предоставляя им при этом возможность выбора различных сценариев установки и обеспечивая корректность его дальнейшей работы n Также необходимо обеспечить корректное удаление ПП с компьютера пользователей :

Управление созданием версий n Версией ПП называют экземпляр ПП, имеющий определенные отличия от других экземпляров этого же ПП. n Новые версии могут отличаться функциональными возможностями, эффективностью или отсутствием ошибок, имевшихся в старых версиях. n Некоторые версии имеют одинаковые функциональные возможности, однако разработаны под различные конфигурации аппаратного или ПО

Идентификация версий n Процедуры управления версиями должны четко идентифицироватькаждую версию компонента: l Нумерация версий - каждый компонент имеет уникальный и явный номер версии l Идентификация, основанная на значениях атрибутов - каждый компонент идентифицируется именем и набором значений атрибутов l Идентификация на основе изменений – каждая версия ПП идентифицируется именем и теми изменениями, которые реализованы в компонентах