1_11. Разработка объектно-ориентированного по

Итеративная модель разработки (развитие водопадной модели)

Анализ – проектирование – кодирование - тестирование

Моделирование

Модель – абстракция физической системы, рассматриваемая с определенной точки зрения и представления на некотором языке или в графической форме.

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

Анализ и проектирование

Предметная область (domain) – часть реального мира, которая имеет существенное значение или непосредственное отношение к функционированию программы.

Объектно-ориентированный анализ – выделение в предметной области классов и объектов, формулирование требований к программной системе

Объектно-ориентированное проектирование – проектирование программы, основанное на объектно-ориентированной декомпозиции, определение интерфейсов классов, описание их взаимодействия.

Унифицированный язык моделирования UML

Для ОО анализа и проектирования используется язык визуального моделирования UML (Unified Modeling Language). Диаграммы и спецификации языка UML связали исходный текст программы с характеристиками объекта автоматизации. Существует возможность автоматической генерации исходного кода программы по диаграммам UML и обратное преобразование (рефакторинг).

История UML

• Предки:

  • метод Грэди Буча (Booch 91);

  • метод Джеймса Румбаха (OMT);

  • метод Айвара Джекобсона (OOSE).

• Rational Software, OMG (Object Management Group) выпускают в 1997 UML 1.0

• 2003 г. UML 1.5

• Идет принятие стандарта UML 2.0

Идеология ООП с использованием UML

Модель – совокупность взаимосвязанных представлений (views), отражающих аспект поведения или структуры системы.

Уровень представления – способ рассмотрения модели на одном уровне абстракции.

ООАП – последовательный переход от наиболее общего концептуального уровня представления модели к детальным представлениям логического и физического уровня.

Диаграммы UML

Диаграмма - графическое представление элементов модели в форме графа, вершинам и ребрам которого приписывается определенная семантика.

Диаграммы

• концептуальный уровень

  • вариантов использования (прецедентов) – use case

• статический логический уровень

  • классов – class

• динамический логический уровень

  • кооперации – collaboration; последовательности – sequence

• моделирование поведения системы

  • состояний – statechart; деятельности – activity

• физический уровень

  • компонентов –component

  • развертывания - deployment

Варианты использования (прецеденты)

На этапе анализа для создания концептуальной модели изучаются варианты использования (use case) или прецеденты.

Диаграмма прецедентов содержит две основных сущности – действующие субъекты (актеры) и собственно прецеденты.

Актер – некоторая роль, которую играет пользователь (внешняя сущность) по отношению к системе.

Вариант использования – специальная задача, обычно инициируемая актером, описывающая некоторую цель. Вариант использования состоит из набора сценариев, описывающих способы достижения цели.

Использование диаграммы прецедентов для спецификации требований

Требование – желательное свойство, характеристика системы.

Требования: функциональные, надежность, производительность, удобство (usability).

Диаграммы прецедентов определяют функциональные требования. Они могут быть дополнены текстовыми сценариями.

Диаграммы классов

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

Класс изображается прямоугольником, содержащим имя класса, имена атрибутов и методов.

Объе́ктно-ориенти́рованное проектирование (ООП) — это часть объектно-ориентированной методологии, которая предоставляет возможность программистам оперировать понятием «объект», нежели понятием «процедура» при разработке своего кода. Объекты содержат инкапсулированные данные и процедуры, сгруппированные вместе, отображая т.о. сущность объекта. «Интерфейс объекта», описывает взаимодействие с объектом, то, как он определен. Программа, полученная при реализации объектно-ориентированного исходного кода, описывает взаимодействие этих объектов.

UML (сокр. от англ. Unified Modeling Language — унифицированный язык моделирования) — язык графического описания для объектного моделирования в области разработки программного обеспечения. UML является языком широкого профиля, это открытый стандарт, использующий графические обозначения для создания абстрактной модели системы, называемой UML моделью. UML был создан для определения, визуализации, проектирования и документирования в основном программных систем.

Использование UML не ограничивается моделированием программного обеспечения. Его также используют для моделирования бизнес-процессов, системного проектирования и отображения организационных структур.

UML позволяет разработчикам ПО достигнуть соглашения в графических обозначениях для представления общих понятий (таких как класс, компонент, обобщение (generalization), объединение (aggregation) и поведение) и больше сконцентрироваться на проектировании и архитектуре.

Структурные диаграммы:

Классов - статическая структурная диаграмма, описывающая структуру системы, она демонстрирует классы системы, их атрибуты, методы и зависимости между классами.

Компонентов - статическая структурная диаграмма, показывает разбиение программной системы на структурные компоненты и связи (зависимости) между компонентами. В качестве физических компонент могут выступать файлы, библиотеки, модули, исполняемые файлы, пакеты и т. п.

Композитной/составной структуры — статическая структурная диаграмма, демонстрирует внутреннюю структуру классов и, по возможности, взаимодействие элементов (частей) внутренней структуры класса.

Подвидом диаграмм композитной структуры являются диаграммы кооперации (Collaboration diagram, введены в UML 2.0), которые показывают роли и взаимодействие классов в рамках кооперации. Кооперации удобны при моделировании шаблонов проектирования. Диаграммы композитной структуры могут использоваться совместно с диаграммами классов.

Развёртывания — служит для моделирования работающих узлов (аппаратных средств, англ. node) и артефактов, развёрнутых на них. В UML 2 на узлах разворачиваются артефакты (англ. artifact), в то время как в UML 1 на узлах разворачивались компоненты. Между артефактом и логическим элементом (компонентом), который он реализует, устанавливается зависимость манифестации.

Объектов — демонстрирует полный или частичный снимок моделируемой системы в заданный момент времени. На диаграмме объектов отображаются экземпляры классов (объекты) системы с указанием текущих значений их атрибутов и связей между объектами.

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

Диаграммы поведения:

Деятельности — диаграмма, на которой показано разложение некоторой деятельности на её составные части. Под деятельностью (англ. activity) понимается спецификация исполняемого поведения в виде координированного последовательного и параллельного выполнения подчинённых элементов — вложенных видов деятельности и отдельных действий (англ. action), соединённых между собой потоками, которые идут от выходов одного узла ко входам другого.

Диаграммы деятельности используются при моделировании бизнес-процессов, технологических процессов, последовательных и параллельных вычислений.

Аналогом диаграмм деятельности являются схемы алгоритмов по ГОСТ 19.701-90.

Состояний — диаграмма, на которой представлен конечный автомат с простыми состояниями, переходами и композитными состояниями.

Конечный автомат (англ. State machine) — спецификация последовательности состояний, через которые проходит объект или взаимодействие в ответ на события своей жизни, а также ответные действия объекта на эти события. Конечный автомат прикреплён к исходному элементу (классу, кооперации или методу) и служит для определения поведения его экземпляров.

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

Диаграммы взаимодействия:

Коммуникации (UML2.0) / Кооперации (UML1.x) - спецификация множества объектов, совместно взаимодействующих с целью реализации отдельных вариантов использования в общем контексте моделируемой системы.

На диаграмме кооперации изображаются необходимые объекты (экземпляры классов), статические связи между ними и динамические связи – потоки сообщений в форме стрелок с указанием направления, имени сообщения и порядкового номера в реализации варианта использования.

Обзора взаимодействия (UML2.0)

Последовательности - Описывают взаимодействие объектов во времени. Объекты – прямоугольники, вертикальные линии – линии жизни. прямоугольники – периоды активности объектов (фокус управления)

Сообщения – горизонтальные стрелки

Синхронизации (UML2.0)

Преимущества UML

• UML объектно-ориентированный, в результате чего методы описания результатов анализа и проектирования семантически близки к методам программированияна современныхОО-языках;

• UML позволяет описать систему практически со всех возможных точек зрения и разные аспекты поведения системы;

• Диаграммы UML сравнительно просты для чтения после достаточно быстрого ознакомления с его синтаксисом;

• UML расширяет и позволяет вводить собственные текстовые и графические стереотипы, что способствует его применению не только в сфере программной инженерии;

• UML получил широкое распространение и динамично развивается.

Пример диаграммы кооперации

Этапы моделирования:

1. Постановка цели моделирования

2. Анализ моделирования объекта и выделение всех его известных свойств

3. Анализ его выделенных свойств с точки зрения цели моделирования и определение, какие из них следует считать существенными

4. Выбор формы представления модели

5. Формализация

6. Анализ полученной модели на непротиворечивость

7. Анализ адекватьности полученной модели объекты и цели моделирования

1_12. Архитектура ЭВМ - это общее описание структуры и функций ЭВМ на уровне, достаточном для понимания принципов работы и системы команд ЭВМ, не включающее деталей технического и физического устройства компьютера.

К архитектуре относятся следующие принципы построения ЭВМ:

1. структура памяти ЭВМ;

2. способы доступа к памяти и внешним устройствам;

3. возможность изменения конфигурации;

4. система команд;

5. форматы данных;

6. организация интерфейса.