OOAD — объектно-ориентированная парадигма

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

• Первым объектно-ориентированным языком был Simula (Симуляция реальных систем), который был разработан в 1960 году исследователями из Норвежского вычислительного центра.

• В 1970 году Алан Кей и его исследовательская группа в Xerox PARK создали персональный компьютер под названием Dynabook и первый чистый объектно-ориентированный язык программирования (OOPL) — Smalltalk, для программирования Dynabook.

• В 1980-х Грэди Буч опубликовал статью под названием «Объектно-ориентированный дизайн», в которой в основном представлен дизайн для языка программирования Ada. В последующих изданиях он расширил свои идеи до полного метода объектно-ориентированного проектирования.

• В 1990-х годах Коад включил идеи поведения в объектно-ориентированные методы.

Первым объектно-ориентированным языком был Simula (Симуляция реальных систем), который был разработан в 1960 году исследователями из Норвежского вычислительного центра.

В 1970 году Алан Кей и его исследовательская группа в Xerox PARK создали персональный компьютер под названием Dynabook и первый чистый объектно-ориентированный язык программирования (OOPL) — Smalltalk, для программирования Dynabook.

В 1980-х Грэди Буч опубликовал статью под названием «Объектно-ориентированный дизайн», в которой в основном представлен дизайн для языка программирования Ada. В последующих изданиях он расширил свои идеи до полного метода объектно-ориентированного проектирования.

В 1990-х годах Коад включил идеи поведения в объектно-ориентированные методы.

Другими значительными нововведениями были Методы объектного моделирования (OMT) Джеймса Румбо и Объектно-ориентированная программная инженерия (OOSE) Ивара Якобсона.

Объектно-ориентированный анализ

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

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

Грэди Буч определил OOA как «Объектно-ориентированный анализ — это метод анализа, который исследует требования с точки зрения классов и объектов, найденных в словаре проблемной области» .

Основными задачами в объектно-ориентированном анализе (ООА) являются —

• Идентификация объектов
• Организация объектов путем создания диаграммы объектной модели
• Определение внутренних объектов или атрибутов объекта
• Определение поведения объектов, т. Е. Действий объекта
• Описание того, как объекты взаимодействуют

Общими моделями, используемыми в OOA, являются сценарии использования и объектные модели.

Объектно-ориентированный дизайн

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

Детали реализации обычно включают в себя:

• Реструктуризация данных класса (при необходимости),
• Реализация методов, т. Е. Внутренних структур данных и алгоритмов,
• Осуществление контроля и
• Реализация ассоциаций.

Грэди Буч определил объектно-ориентированное проектирование как «метод проектирования, охватывающий процесс объектно-ориентированной декомпозиции и обозначения для изображения как логических, так и физических, а также статических и динамических моделей проектируемой системы» .

Объектно-ориентированное программирование

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

Важными особенностями объектно-ориентированного программирования являются —

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

Некоторыми примерами объектно-ориентированных языков программирования являются C ++, Java, Smalltalk, Delphi, C #, Perl, Python, Ruby и PHP.

Грэди Буч определил объектно-ориентированное программирование как «метод реализации, в котором программы организованы в виде кооперативных коллекций объектов, каждый из которых представляет собой экземпляр некоторого класса, и все классы которого являются членами иерархии классов, объединенных через отношения наследования. »

OOAD — объектная модель

Объектная модель визуализирует элементы в программном приложении в терминах объектов. В этой главе мы рассмотрим основные понятия и терминологию объектно-ориентированных систем.

Объекты и Классы

Понятия объектов и классов неразрывно связаны друг с другом и составляют основу объектно-ориентированной парадигмы.

объект

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

• Идентичность, которая отличает его от других объектов в системе.

• Состояние, определяющее характерные свойства объекта, а также значения свойств, которые содержит объект.

• Поведение, которое представляет внешне видимые действия, выполняемые объектом с точки зрения изменений в его состоянии.

Идентичность, которая отличает его от других объектов в системе.

Состояние, определяющее характерные свойства объекта, а также значения свойств, которые содержит объект.

Поведение, которое представляет внешне видимые действия, выполняемые объектом с точки зрения изменений в его состоянии.

Объекты могут быть смоделированы в соответствии с потребностями приложения. Объект может иметь физическое существование, например, клиент, автомобиль и т. Д .; или нематериальное концептуальное существование, такое как проект, процесс и т. д.

Учебный класс

Класс представляет собой набор объектов, имеющих такие же характерные свойства, которые демонстрируют общее поведение. Он дает план или описание объектов, которые могут быть созданы из него. Создание объекта как члена класса называется созданием экземпляра. Таким образом, объект является экземпляром класса.

Составляющие класса —

• Набор атрибутов для объектов, которые должны быть созданы из класса. Как правило, разные объекты класса имеют некоторые различия в значениях атрибутов. Атрибуты часто называют данными класса.

• Набор операций, которые отображают поведение объектов класса. Операции также называются функциями или методами.

Набор атрибутов для объектов, которые должны быть созданы из класса. Как правило, разные объекты класса имеют некоторые различия в значениях атрибутов. Атрибуты часто называют данными класса.

Набор операций, которые отображают поведение объектов класса. Операции также называются функциями или методами.

пример

Рассмотрим простой класс Circle, представляющий круг геометрической фигуры в двумерном пространстве. Атрибуты этого класса могут быть определены следующим образом:

• х – координата, для обозначения х – координаты центра
• у – координата, для обозначения у – координата центра
• а, чтобы обозначить радиус круга

Некоторые из его операций могут быть определены следующим образом:

• findArea (), метод для расчета площади
• findCircumference (), метод для вычисления окружности
• scale (), метод увеличения или уменьшения радиуса

Во время создания экземпляра значения присваиваются хотя бы для некоторых атрибутов. Если мы создаем объект my_circle, мы можем присвоить значения, такие как x-коорди- наты: 2, y-координаты: 3 и a: 4, чтобы отобразить его состояние. Теперь, если операция scale () выполняется для my_circle с коэффициентом масштабирования 2, значение переменной a станет равным 8. Эта операция приводит к изменению состояния my_circle, т. Е. Объект демонстрирует определенное поведение.

Инкапсуляция и сокрытие данных

Инкапсуляция

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

Скрытие данных

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

пример

В классе Circle можно скрыть данные, сделав атрибуты невидимыми вне класса и добавив в класс еще два метода для доступа к данным класса, а именно:

• setValues ​​(), метод для присвоения значений x-координатам, y-координатам и
• getValues ​​(), метод для получения значений x-координаты, y-координаты и

Здесь закрытые данные объекта my_circle не могут быть доступны напрямую любым методом, который не инкапсулирован в классе Circle. Вместо этого к нему следует обращаться через методы setValues ​​() и getValues ​​().

Передача сообщений

Любое приложение требует, чтобы несколько объектов взаимодействовали гармонично. Объекты в системе могут взаимодействовать друг с другом с помощью передачи сообщений. Предположим, что система имеет два объекта: obj1 и obj2. Объект obj1 отправляет сообщение объекту obj2, если obj1 хочет, чтобы obj2 выполнил один из своих методов.

Особенности передачи сообщений —

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

наследование

Наследование — это механизм, который позволяет создавать новые классы из существующих классов, расширяя и совершенствуя его возможности. Существующие классы называются базовыми классами / родительскими классами / суперклассами, а новые классы называются производными классами / дочерними классами / подклассами. Подкласс может наследовать или получать атрибуты и методы суперкласса (ов) при условии, что суперкласс позволяет это. Кроме того, подкласс может добавлять свои собственные атрибуты и методы и может модифицировать любой из методов суперкласса. Наследование определяет отношение «есть».

пример

Из класса млекопитающих может быть получен ряд классов, таких как человек, кошка, собака, корова и т. Д. Люди, кошки, собаки и коровы имеют отличительные характеристики млекопитающих. Кроме того, у каждого есть свои особенности. Можно сказать, что корова — это млекопитающее.

Типы Наследования

• Одиночное наследование — подкласс происходит от одного суперкласса.

• Множественное наследование — подкласс происходит от нескольких суперклассов.

• Многоуровневое наследование — подкласс наследуется от суперкласса, который, в свою очередь, наследуется от другого класса и так далее.

• Иерархическое наследование — класс имеет несколько подклассов, каждый из которых может иметь последующие подклассы, продолжающиеся в течение ряда уровней, чтобы сформировать древовидную структуру.

• Гибридное наследование — комбинация множественного и многоуровневого наследования для формирования решетчатой ​​структуры.

Одиночное наследование — подкласс происходит от одного суперкласса.

Множественное наследование — подкласс происходит от нескольких суперклассов.

Многоуровневое наследование — подкласс наследуется от суперкласса, который, в свою очередь, наследуется от другого класса и так далее.

Иерархическое наследование — класс имеет несколько подклассов, каждый из которых может иметь последующие подклассы, продолжающиеся в течение ряда уровней, чтобы сформировать древовидную структуру.

Гибридное наследование — комбинация множественного и многоуровневого наследования для формирования решетчатой ​​структуры.

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

Полиморфизм

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

пример

Давайте рассмотрим два класса, Circle и Square, каждый из которых имеет метод findArea (). Хотя имя и назначение методов в классах одинаковы, внутренняя реализация, т. Е. Процедура вычисления площади, различна для каждого класса. Когда объект класса Circle вызывает свой метод findArea (), операция находит область круга без какого-либо конфликта с методом findArea () класса Square.

Обобщение и специализация

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

Обобщение

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

специализация

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

На следующем рисунке показан пример обобщения и специализации.

Ссылки и ассоциации

Ссылка на сайт

Ссылка представляет собой соединение, посредством которого объект взаимодействует с другими объектами. Рамбо определил это как «физическую или концептуальную связь между объектами». Через ссылку один объект может вызывать методы или перемещаться по другому объекту. Ссылка отображает отношения между двумя или более объектами.

ассоциация

Ассоциация — это группа ссылок, имеющих общую структуру и общее поведение. Ассоциация изображает отношения между объектами одного или нескольких классов. Ссылка может быть определена как экземпляр ассоциации.

Степень ассоциации

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

• Унарные отношения связывают объекты одного класса.

• Бинарные отношения связывают объекты двух классов.

• Тройные отношения связывают объекты трех или более классов.

Унарные отношения связывают объекты одного класса.

Бинарные отношения связывают объекты двух классов.

Тройные отношения связывают объекты трех или более классов.

Коэффициент кардинальности ассоциаций

Мощность бинарной ассоциации обозначает количество экземпляров, участвующих в ассоциации. Существует три типа коэффициентов кардинальности, а именно:

• Один-к-одному — один объект класса A связан с одним объектом класса B.

• Один-ко-многим — один объект класса A связан со многими объектами класса B.

• Многие ко многим — объект класса A может быть связан со многими объектами класса B, и наоборот, объект класса B может быть связан со многими объектами класса A.

Один-к-одному — один объект класса A связан с одним объектом класса B.

Один-ко-многим — один объект класса A связан со многими объектами класса B.

Многие ко многим — объект класса A может быть связан со многими объектами класса B, и наоборот, объект класса B может быть связан со многими объектами класса A.

Агрегация или состав

Агрегация или композиция — это связь между классами, с помощью которой класс может состоять из любой комбинации объектов других классов. Это позволяет размещать объекты непосредственно внутри тела других классов. Агрегация называется отношением «часть-часть» или «имеет-а» с возможностью перемещаться от целого к его частям. Агрегированный объект — это объект, который состоит из одного или нескольких других объектов.

пример

В отношениях «у автомобиля есть двигатель», автомобиль — это целый объект или совокупность, а двигатель — это «часть» автомобиля. Агрегация может обозначать —

• Физическое ограничение — например, компьютер состоит из монитора, процессора, мыши, клавиатуры и т. Д.

• Концептуальное сдерживание — пример, акционер имеет долю.

Физическое ограничение — например, компьютер состоит из монитора, процессора, мыши, клавиатуры и т. Д.

Концептуальное сдерживание — пример, акционер имеет долю.

Преимущества объектной модели

Теперь, когда мы ознакомились с основными понятиями, относящимися к объектной ориентации, было бы целесообразно отметить преимущества этой модели.

Преимущества использования объектной модели:

• Это помогает в более быстрой разработке программного обеспечения.

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

• Он поддерживает относительно беспроблемные обновления.

• Это позволяет повторно использовать объекты, проекты и функции.

• Это снижает риски развития, особенно при интеграции сложных систем.

Это помогает в более быстрой разработке программного обеспечения.

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

Он поддерживает относительно беспроблемные обновления.

Это позволяет повторно использовать объекты, проекты и функции.

Это снижает риски развития, особенно при интеграции сложных систем.

OOAD — объектно-ориентированная система

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

• Анализ,
• Дизайн и
• Реализация.

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

Этапы в объектно-ориентированной разработке программного обеспечения

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

Объектно-ориентированный анализ

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

Объектно-ориентированный дизайн

Объектно-ориентированное проектирование включает в себя два основных этапа, а именно: проектирование системы и проектирование объекта.

Системный дизайн

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

Объектный дизайн

На этом этапе модель проектирования разрабатывается на основе как моделей, разработанных на этапе системного анализа, так и архитектуры, разработанной на этапе проектирования системы. Все необходимые классы определены. Дизайнер решает, —

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

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

Объектно-ориентированная реализация и тестирование

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

OOAD — Объектно-ориентированные принципы

Принципы объектно-ориентированных систем

Концептуальная основа объектно-ориентированных систем основана на объектной модели. В объектно-ориентированной системе есть две категории элементов:

Основные элементы — Под основными подразумевается, что если модель не имеет ни одного из этих элементов, она перестает быть объектно-ориентированной. Четыре основных элемента —

• абстракция
• Инкапсуляция
• модульность
• иерархия

Незначительные элементы — Под второстепенными подразумевается, что эти элементы являются полезной, но не обязательной частью объектной модели. Три второстепенных элемента —

• Typing
• совпадение
• Упорство

абстракция

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

Грэди Буч определил абстракцию следующим образом:

«Абстракция обозначает основные характеристики объекта, которые отличают его от всех других видов объектов и, таким образом, обеспечивают четко определенные концептуальные границы относительно перспективы зрителя».

Пример. При разработке класса Student включаются атрибуты enrolment_number, name, course и address, в то время как такие характеристики, как pulse_rate и size_of_shoe, исключаются, поскольку они не имеют значения для перспективы образовательного учреждения.

Инкапсуляция

Инкапсуляция — это процесс связывания атрибутов и методов вместе в классе. Благодаря инкапсуляции внутренние детали класса могут быть скрыты снаружи. У класса есть методы, которые предоставляют пользовательские интерфейсы, с помощью которых могут использоваться сервисы, предоставляемые классом.

модульность

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

«Модульность — это свойство системы, которая была разложена на набор связных и слабо связанных модулей».

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

иерархия

По словам Грэди Буча, «Иерархия — это ранжирование или упорядочение абстракции». Посредством иерархии система может состоять из взаимосвязанных подсистем, которые могут иметь свои собственные подсистемы и так далее, пока не будут достигнуты компоненты наименьшего уровня. Он использует принцип «разделяй и властвуй». Иерархия позволяет повторно использовать код.

Два типа иерархий в OOA являются —

• Иерархия «IS – A» — она ​​определяет иерархические отношения в наследовании, в результате чего из суперкласса может быть получено несколько подклассов, которые могут снова иметь подклассы и так далее. Например, если мы извлекаем класс Rose из класса Flower, мы можем сказать, что роза — это цветок.

• Иерархия «PART – OF» — определяет иерархические отношения в агрегации, с помощью которых класс может состоять из других классов. Например, цветок состоит из чашелистика, лепестков, тычинок и ковра. Можно сказать, что лепесток — это часть цветка.

Иерархия «IS – A» — она ​​определяет иерархические отношения в наследовании, в результате чего из суперкласса может быть получено несколько подклассов, которые могут снова иметь подклассы и так далее. Например, если мы извлекаем класс Rose из класса Flower, мы можем сказать, что роза — это цветок.

Иерархия «PART – OF» — определяет иерархические отношения в агрегации, с помощью которых класс может состоять из других классов. Например, цветок состоит из чашелистика, лепестков, тычинок и ковра. Можно сказать, что лепесток — это часть цветка.

Typing

Согласно теориям абстрактного типа данных, тип — это характеристика набора элементов. В ООП класс визуализируется как тип, имеющий свойства, отличные от любых других типов. Типизация — это применение понятия, что объект является экземпляром одного класса или типа. Это также гарантирует, что объекты разных типов не могут быть взаимозаменяемыми; и могут быть заменены только в очень ограниченном порядке, если это абсолютно необходимо.

Два типа набора текста —

• Строгая типизация — здесь операция над объектом проверяется во время компиляции, как на языке программирования Eiffel.

• Слабая печать — здесь сообщения могут быть отправлены любому классу. Операция проверяется только во время выполнения, как на языке программирования Smalltalk.

Строгая типизация — здесь операция над объектом проверяется во время компиляции, как на языке программирования Eiffel.

Слабая печать — здесь сообщения могут быть отправлены любому классу. Операция проверяется только во время выполнения, как на языке программирования Smalltalk.

совпадение

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

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

Упорство

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

OOAD — объектно-ориентированный анализ

На этапе системного анализа или объектно-ориентированного анализа разработки программного обеспечения определяются системные требования, определяются классы и определяются отношения между классами.

Три метода анализа, которые используются вместе друг с другом для объектно-ориентированного анализа, — это объектное моделирование, динамическое моделирование и функциональное моделирование.

Моделирование объектов

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

Процесс моделирования объекта может быть визуализирован в следующих шагах —

• Определить объекты и сгруппировать в классы
• Определите отношения между классами
• Создать диаграмму модели объекта пользователя
• Определить атрибуты объекта пользователя
• Определите операции, которые должны быть выполнены на классах
• Обзор глоссария

Динамическое Моделирование

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

Динамическое моделирование может быть определено как «способ описания того, как отдельный объект реагирует на события, либо внутренние события, инициируемые другими объектами, либо внешние события, инициируемые внешним миром».

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

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

Функциональное моделирование

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

Процесс функционального моделирования может быть визуализирован в следующих шагах —

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

Структурный анализ против объектно-ориентированного анализа

Подход структурного анализа / структурного проектирования (SASD) — это традиционный подход к разработке программного обеспечения, основанный на модели водопада. Этапы разработки системы с использованием SASD:

• Технико-экономическое обоснование
• Анализ требований и спецификация
• Системный дизайн
• Реализация
• Обзор после внедрения

Теперь рассмотрим относительные преимущества и недостатки подхода структурного анализа и подхода объектно-ориентированного анализа.

Преимущества / недостатки объектно-ориентированного анализа

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

Преимущества / недостатки структурного анализа

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

OOAD — Динамическое моделирование

Динамическая модель представляет зависящие от времени аспекты системы. Он связан с временными изменениями состояний объектов в системе. Основные понятия —

• Состояние, которое представляет собой ситуацию в определенном состоянии в течение жизни объекта.

• Переход, изменение в состоянии

• Событие, событие, которое вызывает переходы

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

• Параллельность переходов.

Состояние, которое представляет собой ситуацию в определенном состоянии в течение жизни объекта.

Переход, изменение в состоянии

Событие, событие, которое вызывает переходы

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

Параллельность переходов.

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

Государства и Государственные Переходы

государственный

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

Части государства

• Имя — строка отличает одно состояние от другого. Государство может не иметь никакого имени.

• Действия входа / выхода — обозначают действия, выполняемые при входе и выходе из состояния.

• Внутренние переходы — изменения в состоянии, которые не вызывают изменения в состоянии.

• Суб-штаты — штаты внутри штатов

Имя — строка отличает одно состояние от другого. Государство может не иметь никакого имени.

Действия входа / выхода — обозначают действия, выполняемые при входе и выходе из состояния.

Внутренние переходы — изменения в состоянии, которые не вызывают изменения в состоянии.

Суб-штаты — штаты внутри штатов

Начальные и конечные состояния

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

переход

Переход означает изменение состояния объекта. Если объект находится в определенном состоянии, когда происходит событие, объект может выполнять определенные действия в соответствии с указанными условиями и изменять состояние. В этом случае говорят, что произошел переход состояния. Переход дает связь между первым состоянием и новым состоянием. Переход графически представлен сплошной направленной дугой из исходного состояния в конечное состояние.

Пять частей перехода —

• Исходное состояние — состояние, затронутое переходом.

• Триггер события — возникновение, из-за которого объект в состоянии источника претерпевает переход, если выполняется условие защиты.

• Guard Condition — Булево выражение, которое, если True, вызывает переход при получении триггера события.

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

• Целевое состояние — состояние назначения после завершения перехода.

Исходное состояние — состояние, затронутое переходом.

Триггер события — возникновение, из-за которого объект в состоянии источника претерпевает переход, если выполняется условие защиты.

Guard Condition — Булево выражение, которое, если True, вызывает переход при получении триггера события.

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

Целевое состояние — состояние назначения после завершения перехода.

пример

Предположим, что человек едет на такси из места X в место Y. Состояния человека могут быть следующими: Ожидание (ожидание такси), Поездка (у него есть такси и он едет в нем) и Достигнутый (он достиг место назначения). На следующем рисунке показан переход состояния.

События

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

Примерами событий являются щелчок мышью, нажатие клавиши, прерывание, переполнение стека и т. Д.

События, инициирующие переходы, записываются рядом с дугой перехода на диаграммах состояний.

пример

Учитывая пример, показанный на рисунке выше, переход из состояния ожидания в состояние езды происходит, когда человек получает такси. Аналогично, конечное состояние достигается, когда он достигает пункта назначения. Эти два вхождения можно назвать событиями Get_Taxi и Reach_Destination. На следующем рисунке показаны события в автомате.

Внешние и внутренние события

Внешние события — это те события, которые передаются от пользователя системы к объектам в системе. Например, щелчок мыши или нажатие клавиши пользователем являются внешними событиями.

Внутренние события — это события, которые передаются от одного объекта другому объекту в системе. Например, переполнение стека, ошибка деления и т. Д.

Отложенные события

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

Классы событий

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

Flight_Departs (Flight_No, From_City, To_City, Route)

действия

Деятельность

Активность — это операция над состояниями объекта, требующая некоторого периода времени. Это текущие исполнения в системе, которые могут быть прерваны. Действия показаны в диаграммах действий, которые изображают переход от одного действия к другому.

действие

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

Действия входа и выхода

Действие входа — это действие, которое выполняется при входе в состояние, независимо от перехода, который привел к нему.

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

сценарий

Сценарий — это описание определенной последовательности действий. Он изображает поведение объектов, проходящих определенную серию действий. Первичные сценарии изображают основные последовательности, а вторичные сценарии — альтернативные последовательности.

Диаграммы для динамического моделирования

Для динамического моделирования используются две основные диаграммы:

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

Диаграммы взаимодействия описывают динамическое поведение различных объектов. Он состоит из набора объектов, их отношений и сообщения, которое объекты отправляют и получают. Таким образом, взаимодействие моделирует поведение группы взаимосвязанных объектов. Два типа диаграмм взаимодействия:

• Диаграмма последовательности — представляет временную последовательность сообщений в табличной форме.

• Диаграмма сотрудничества — представляет структурную организацию объектов, которые отправляют и получают сообщения через вершины и дуги.

Диаграмма последовательности — представляет временную последовательность сообщений в табличной форме.

Диаграмма сотрудничества — представляет структурную организацию объектов, которые отправляют и получают сообщения через вершины и дуги.

Диаграмма переходного состояния

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

Параллельность событий

В системе могут существовать два типа параллелизма. Они —

Системный параллелизм

Здесь параллелизм моделируется на системном уровне. Вся система моделируется как совокупность конечных автоматов, где каждый конечный автомат выполняется одновременно с другими.

Параллельность внутри объекта

Здесь объект может выдавать параллельные события. Объект может иметь состояния, которые состоят из подсостояний, и одновременные события могут происходить в каждом из подсостояний.

Концепции, связанные с параллелизмом внутри объекта, следующие:

Простые и составные состояния

Простое состояние не имеет подструктуры. Состояние, в которое вложены более простые состояния, называется составным состоянием. Подсостояние — это состояние, которое вложено в другое состояние. Обычно используется для уменьшения сложности конечного автомата. Подсостояния могут быть вложены в любое количество уровней.

Составные состояния могут иметь либо последовательные подсостояния, либо параллельные подсостояния.

Последовательные подсостояния

В последовательных подсостояниях управление выполнением переходит от одного подсостояния к другому подсостоянию один за другим последовательным образом. Существует не более одного начального состояния и одного конечного состояния в этих конечных автоматах.

Следующий рисунок иллюстрирует концепцию последовательных подсостояний.

Параллельные подсостояния

В параллельных подсостояниях подсостояния выполняются параллельно, или, другими словами, в каждом состоянии одновременно выполняются конечные автоматы. Каждый из конечных автоматов имеет свои начальные и конечные состояния. Если одно параллельное подсостояние достигает своего конечного состояния раньше другого, управление ожидает своего окончательного состояния. Когда все вложенные конечные автоматы достигают своих конечных состояний, подсостояния объединяются в единый поток.

На следующем рисунке показана концепция параллельных подсостояний.

OOAD — Функциональное моделирование

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

Диаграммы потока данных

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

Rumbaugh et al. определили DFD как: «Диаграмма потока данных — это график, который показывает поток значений данных из их источников в объектах через процессы, которые преобразуют их в их назначения в других объектах».

Четыре основные части DFD —

• Процессы,
• Потоки данных,
• Актеры и
• Хранилища данных.

Другие части DFD —

• Ограничения и
• Потоки управления.

Особенности DFD

Процессы

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

Представление в DFD — процесс представлен в виде эллипса с именем, написанным внутри него, и содержит фиксированное количество значений входных и выходных данных.

Пример — на следующем рисунке показан процесс Compute_HCF_LCM, который принимает два целых числа в качестве входных данных и выводит их HCF (наибольший общий множитель) и LCM (наименьшее общее кратное).

Потоки данных

Поток данных представляет собой поток данных между двумя процессами. Это может быть между субъектом и процессом или между хранилищем данных и процессом. Поток данных обозначает значение элемента данных в некоторой точке вычисления. Это значение не изменяется потоком данных.

Представление в DFD — Поток данных представлен направленной дугой или стрелкой, помеченной названием элемента данных, который он несет.

На приведенном выше рисунке Integer_a и Integer_b представляют потоки входных данных для процесса, а LCM и HCF — потоки выходных данных.

Поток данных может быть разветвлен в следующих случаях:

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

• Поток данных содержит совокупное значение, и каждый из компонентов отправляется в разные места, как показано на следующем рисунке. Здесь каждый из разветвленных компонентов помечен.

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

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

Актеры

Актеры — это активные объекты, которые взаимодействуют с системой, либо производя данные и вводя их в систему, либо потребляя данные, создаваемые системой. Другими словами, субъекты служат источниками и приемниками данных.

Представление в DFD — Актер представлен прямоугольником. Актеры подключены к входам и выходам и лежат на границе DFD.

Пример. На следующем рисунке показаны участники, а именно Customer и Sales_Clerk в системе встречных продаж.

Хранилища данных

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

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

Пример. На следующем рисунке показано хранилище данных Sales_Record, в котором хранится информация обо всех продажах. Входные данные в хранилище данных содержат подробную информацию о продажах, такую ​​как товар, сумма выставления счета, дата и т. Д. Чтобы найти средние продажи, процесс извлекает записи о продажах и вычисляет среднее значение.

Ограничения

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

• В объектном моделировании ограничения определяют отношения между объектами. Они также могут определять отношения между различными значениями, которые объект может принимать в разное время.

• В динамическом моделировании ограничения определяют отношения между состояниями и событиями различных объектов.

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

В объектном моделировании ограничения определяют отношения между объектами. Они также могут определять отношения между различными значениями, которые объект может принимать в разное время.

В динамическом моделировании ограничения определяют отношения между состояниями и событиями различных объектов.

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

Представление — ограничение выводится в виде строки в фигурных скобках.

Пример. На следующем рисунке показана часть DFD для расчета заработной платы сотрудников компании, которая решила поощрять всех сотрудников отдела продаж и увеличивать зарплату всех сотрудников отдела кадров. Можно видеть, что ограничение {Dept: Sales} вызывает вычисление стимула только в том случае, если отдел занимается продажами, а ограничение {Dept: HR} приводит к вычислению приращения только в том случае, если в отделе работает HR.

Потоки управления

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

Представление в DFD — Потоки управления представлены пунктирной дугой от процесса, производящего логическое значение, до процесса, которым они управляют.

Пример — следующий рисунок представляет DFD для арифметического деления. Делитель проверяется на ненулевое значение. Если он не равен нулю, поток управления OK имеет значение True, а затем процесс деления вычисляет частное и остаток.

Разработка DFD-модели системы

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

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

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

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

Актеры в системе —

• Клиенты
• Salesperson
• владелец

На следующем уровне DFD, как показано на следующем рисунке, определены основные процессы системы, определены хранилища данных и установлено взаимодействие процессов с действующими лицами и хранилища данных.

В системе можно выделить три процесса:

• Регистрация клиентов
• Процесс продаж
• Выяснить подарки

Хранилища данных, которые потребуются, —

• Данные клиента
• Детали продаж
• Детали подарка

На следующем рисунке показаны подробности процесса регистрации клиента. В нем есть три процесса: «Проверить детали», «Создать C_Code» и «Обновить данные клиента». Когда данные клиента вводятся, они проверяются. Если данные верны, генерируется C_Code и обновляется информация о клиенте хранилища данных.

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

Преимущества и недостатки DFD

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

Связь между объектной, динамической и функциональной моделями

Объектная модель, динамическая модель и функциональная модель дополняют друг друга для полного объектно-ориентированного анализа.

• Объектное моделирование развивает статическую структуру программного комплекса в терминах объектов. Таким образом, он показывает «деятелей» системы.

• Динамическое моделирование развивает временное поведение объектов в ответ на внешние события. Он показывает последовательность операций, выполняемых над объектами.

• Функциональная модель дает обзор того, что должна делать система.

Объектное моделирование развивает статическую структуру программного комплекса в терминах объектов. Таким образом, он показывает «деятелей» системы.

Динамическое моделирование развивает временное поведение объектов в ответ на внешние события. Он показывает последовательность операций, выполняемых над объектами.

Функциональная модель дает обзор того, что должна делать система.

Функциональная модель и объектная модель

Четыре основные части функциональной модели с точки зрения объектной модели:

• Процесс — Процессы подразумевают методы объектов, которые должны быть реализованы.

• Актеры — актеры — это объекты в объектной модели.

• Хранилища данных — это либо объекты в объектной модели, либо атрибуты объектов.

• Потоки данных — потоки данных к субъектам или от них представляют операции над объектами или над ними. Потоки данных в или из хранилищ данных представляют собой запросы или обновления.

Процесс — Процессы подразумевают методы объектов, которые должны быть реализованы.

Актеры — актеры — это объекты в объектной модели.

Хранилища данных — это либо объекты в объектной модели, либо атрибуты объектов.

Потоки данных — потоки данных к субъектам или от них представляют операции над объектами или над ними. Потоки данных в или из хранилищ данных представляют собой запросы или обновления.

Функциональная модель и динамическая модель

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

Объектная модель и динамическая модель

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

OOAD — Модель анализа UML

Унифицированный язык моделирования (UML) — это графический язык для OOAD, который предоставляет стандартный способ написания плана системы программного обеспечения. Это помогает визуализировать, определять, конструировать и документировать артефакты объектно-ориентированной системы. Он используется для изображения структур и отношений в сложной системе.

Краткая история

Он был разработан в 1990-х годах как объединение нескольких методов, в частности метод OOAD Грэди Буча, OMT (Техника моделирования объектов) Джеймса Румбо и OOSE (Инженерия объектно-ориентированного программного обеспечения) Ивара Якобсона. UML попытался стандартизировать семантические модели, синтаксические обозначения и диаграммы OOAD.

Системы и модели в UML

Система — набор элементов, организованных для достижения определенных целей, образующих систему. Системы часто делятся на подсистемы и описываются набором моделей.

Модель — Модель — это упрощенная, полная и последовательная абстракция системы, созданная для лучшего понимания системы.

Представление — представление — это проекция модели системы с определенной точки зрения.

Концептуальная модель UML

Концептуальная модель UML включает три основных элемента:

• Основные строительные блоки
• правила
• Общие механизмы

Основные строительные блоки

Три строительных блока UML — это

• вещи
• Отношения
• Диаграммы

вещи

В UML есть четыре вида вещей, а именно:

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

• Поведенческие вещи — это глаголы UML-моделей, представляющие динамическое поведение во времени и пространстве. Два типа поведенческих вещей — это взаимодействие и конечный автомат.

• Группировка вещей — они составляют организационные части моделей UML. Существует только один вид группирования, т. Е. Упаковка.

• Аннотационные вещи — это объяснения в моделях UML, представляющие комментарии, применяемые для описания элементов.

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

Поведенческие вещи — это глаголы UML-моделей, представляющие динамическое поведение во времени и пространстве. Два типа поведенческих вещей — это взаимодействие и конечный автомат.

Группировка вещей — они составляют организационные части моделей UML. Существует только один вид группирования, т. Е. Упаковка.

Аннотационные вещи — это объяснения в моделях UML, представляющие комментарии, применяемые для описания элементов.

Отношения

Отношения — это связь между вещами. Четыре типа отношений, которые могут быть представлены в UML:

• Зависимость — это семантические отношения между двумя вещами, так что изменение одной вещи приводит к изменению другой. Первая вещь независимая, а вторая вещь зависимая.

• Ассоциация — это структурные отношения, представляющие группу связей, имеющих общую структуру и общее поведение.

• Обобщение — представляет отношение обобщения / специализации, в котором подклассы наследуют структуру и поведение от суперклассов.

• Реализация — это семантические отношения между двумя или более классификаторами, так что один классификатор устанавливает контракт, который другие классификаторы должны соблюдать.

Зависимость — это семантические отношения между двумя вещами, так что изменение одной вещи приводит к изменению другой. Первая вещь независимая, а вторая вещь зависимая.

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

Обобщение — представляет отношение обобщения / специализации, в котором подклассы наследуют структуру и поведение от суперклассов.

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

Диаграммы

Диаграмма — это графическое представление системы. Он состоит из группы элементов, обычно в форме графа. UML включает в себя девять диаграмм всего, а именно —

• Диаграмма классов
• Диаграмма объектов
• Диаграмма вариантов использования
• Схема последовательности
• Диаграмма сотрудничества
• Диаграмма состояния диаграммы
• Диаграмма деятельности
• Диаграмма компонентов
• Диаграмма развертывания

правила

UML имеет ряд правил, так что модели семантически самосогласованы и гармонично связаны с другими моделями в системе. UML имеет семантические правила для следующего:

• имена
• Объем
• видимость
• целостность
• выполнение

Общие механизмы

У UML есть четыре общих механизма:

• Характеристики
• Украшения
• Общие подразделения
• Механизмы расширяемости

Характеристики

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

Украшения

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

Общие подразделения

Объектно-ориентированные системы можно разделить по-разному. Два распространенных способа разделения —

• Разделение классов и объектов . Класс — это абстракция группы похожих объектов. Объект — это конкретный экземпляр, который реально существует в системе.

• Разделение интерфейса и реализации . Интерфейс определяет правила взаимодействия. Реализация — это конкретная реализация правил, определенных в интерфейсе.

Разделение классов и объектов . Класс — это абстракция группы похожих объектов. Объект — это конкретный экземпляр, который реально существует в системе.

Разделение интерфейса и реализации . Интерфейс определяет правила взаимодействия. Реализация — это конкретная реализация правил, определенных в интерфейсе.

Механизмы расширяемости

UML — это открытый язык. Можно расширить возможности UML контролируемым образом в соответствии с требованиями системы. Механизмы расширяемости:

• Стереотипы — расширяет словарный запас UML, с помощью которого можно создавать новые строительные блоки из существующих.

• Помеченные значения — расширяет свойства строительных блоков UML.

• Ограничения — расширяет семантику строительных блоков UML.

Стереотипы — расширяет словарный запас UML, с помощью которого можно создавать новые строительные блоки из существующих.

Помеченные значения — расширяет свойства строительных блоков UML.

Ограничения — расширяет семантику строительных блоков UML.

OOAD — UML Основные нотации

UML определяет конкретные обозначения для каждого из строительных блоков.

Учебный класс

Класс представлен прямоугольником, имеющим три секции —

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

Видимость атрибутов и операций может быть представлена ​​следующими способами:

• Public — публичный член виден из любой точки системы. На диаграмме классов он начинается с символа «+».

• Приватный — закрытый член виден только из класса. К нему нельзя получить доступ снаружи класса. Закрытый член имеет префикс «-».

• Защищенный — защищенный член виден изнутри класса и из подклассов, унаследованных от этого класса, но не снаружи. Он начинается с символа «#».

Public — публичный член виден из любой точки системы. На диаграмме классов он начинается с символа «+».

Приватный — закрытый член виден только из класса. К нему нельзя получить доступ снаружи класса. Закрытый член имеет префикс «-».

Защищенный — защищенный член виден изнутри класса и из подклассов, унаследованных от этого класса, но не снаружи. Он начинается с символа «#».

Абстрактный класс имеет имя класса, написанное курсивом.

Пример. Рассмотрим класс Circle, представленный ранее. Атрибутами Circle являются координаты x, координата y и радиус. Это операции findArea (), findCircumference () и scale (). Предположим, что x-координировать и y-координировать являются частными членами данных, радиус является защищенным членом данных, а функции-члены являются открытыми. На следующем рисунке показано схематическое представление класса.

объект

Объект представлен в виде прямоугольника с двумя сечениями —

• Верхний раздел содержит имя объекта с именем класса или пакета, экземпляром которого он является. Имя принимает следующие формы —

  • имя-объекта — имя- класса

  • имя-объекта — имя- класса :: имя-пакета

  • имя класса — в случае анонимных объектов

• Нижний раздел представляет значения атрибутов. Он принимает форму атрибут-имя = значение.

• Иногда объекты представлены с помощью скругленных прямоугольников.

Верхний раздел содержит имя объекта с именем класса или пакета, экземпляром которого он является. Имя принимает следующие формы —

имя-объекта — имя- класса

имя-объекта — имя- класса :: имя-пакета

имя класса — в случае анонимных объектов

Нижний раздел представляет значения атрибутов. Он принимает форму атрибут-имя = значение.

Иногда объекты представлены с помощью скругленных прямоугольников.

Пример. Рассмотрим объект класса Circle с именем c1. Мы предполагаем, что центр c1 находится в (2, 3), а радиус c1 равен 5. На следующем рисунке изображен объект.

Составная часть

Компонент — это физическая и заменяемая часть системы, которая соответствует и обеспечивает реализацию набора интерфейсов. Он представляет собой физическую упаковку таких элементов, как классы и интерфейсы.

Обозначение — На диаграммах UML компонент представлен прямоугольником с вкладками, как показано на рисунке ниже.

Интерфейс

Интерфейс — это набор методов класса или компонента. Он определяет набор услуг, которые могут быть предоставлены классом или компонентом.

Обозначения. Обычно интерфейс отображается в виде круга вместе с его именем. Интерфейс почти всегда присоединен к классу или компоненту, который его реализует. На следующем рисунке приведены обозначения интерфейса.

пакет

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

Запись — Графически пакет представлен папкой с вкладками. Пакет обычно рисуется только с его именем. Однако он может содержать дополнительные сведения о содержимом пакета. Смотрите следующие рисунки.

отношения

Обозначения для различных типов отношений следующие:

Обычно элементы в отношениях играют определенные роли в отношениях. Имя роли означает поведение элемента, участвующего в определенном контексте.

Пример — на следующих рисунках показаны примеры различных отношений между классами. На первом рисунке показана связь между двумя классами, отделом и сотрудником, в которой в отделе может работать несколько сотрудников. Рабочий — это имя роли. ‘1’ рядом с Департаментом и ‘*’ рядом с Сотрудником показывают, что коэффициент кардинальности равен один к многим. На втором рисунке изображены отношения агрегации: университет является «целым» из множества факультетов.

OOAD — Структурированные диаграммы UML

Структурные диаграммы UML подразделяются на следующие категории: диаграмма классов, диаграмма объектов, диаграмма компонентов и диаграмма развертывания.

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

Диаграмма классов моделирует статическое представление системы. Он состоит из классов, интерфейсов и взаимодействий системы; и отношения между ними.

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

Давайте рассмотрим упрощенную банковскую систему.

Банк имеет много филиалов. В каждой зоне один филиал обозначен как зональный головной офис, который контролирует другие филиалы в этой зоне. Каждый филиал может иметь несколько учетных записей и кредитов. Счет может быть сберегательным или текущим. Клиент может открыть как сберегательный, так и текущий счет. Однако клиент не должен иметь более одного сберегательного или текущего счета. Клиент также может получить кредит в банке.

На следующем рисунке показана соответствующая диаграмма классов.

Занятия в системе

Банк, Филиал, Счет, Сберегательный счет, Текущий счет, Кредит и Клиент.

Отношения

• Банк имеет «a – a» количество филиалов — состав, один ко многим

• Филиал с ролью Зональный головной офис контролирует другие филиалы — унарное объединение, один ко многим

• Филиал «имеет – a» количество счетов — агрегация, один ко многим

Банк имеет «a – a» количество филиалов — состав, один ко многим

Филиал с ролью Зональный головной офис контролирует другие филиалы — унарное объединение, один ко многим

Филиал «имеет – a» количество счетов — агрегация, один ко многим

От класса Account унаследованы два класса, а именно Сберегательный счет и Текущий счет.

• У Клиента может быть один Текущий счет — ассоциация, один к одному

• У Клиента может быть один Сберегательный счет — ассоциация, один к одному

• Филиал «имеет – a» количество ссуд — агрегация, один – ко-многим

• Клиент может взять много кредитов — объединение, один ко многим

У Клиента может быть один Текущий счет — ассоциация, один к одному

У Клиента может быть один Сберегательный счет — ассоциация, один к одному

Филиал «имеет – a» количество ссуд — агрегация, один – ко-многим

Клиент может взять много кредитов — объединение, один ко многим

Диаграмма объектов

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

Пример — на следующем рисунке показана диаграмма объекта части диаграммы классов банковской системы.

Диаграмма компонентов

Диаграммы компонентов показывают организацию и зависимости между группой компонентов.

Диаграммы компонентов состоят из —

• Компоненты
• Интерфейсы
• Отношения
• Пакеты и подсистемы (необязательно)

Диаграммы компонентов используются для —

• построение систем с помощью прямого и обратного проектирования.

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

• представление схем в модельных базах данных.

• моделирование поведения динамических систем.

построение систем с помощью прямого и обратного проектирования.

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

представление схем в модельных базах данных.

моделирование поведения динамических систем.

пример

На следующем рисунке показана диаграмма компонентов для моделирования исходного кода системы, разработанного с использованием C ++. Он показывает четыре файла исходного кода, а именно, myheader.h, otherheader.h, priority.cpp и other.cpp. Показаны две версии myheader.h, начиная с последней версии до ее предка. Файл priority.cpp имеет зависимость компиляции от other.cpp. Файл other.cpp имеет зависимость компиляции от otherheader.h.

Диаграмма развертывания

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

Диаграммы развертывания используются для —

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

• представляют топологии клиент-серверных систем.

• моделировать полностью распределенные системы.

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

представляют топологии клиент-серверных систем.

моделировать полностью распределенные системы.

пример

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

OOAD — UML Поведенческие диаграммы

Диаграммы поведения UML визуализируют, определяют, конструируют и документируют динамические аспекты системы. Диаграммы поведения подразделяются на следующие категории: диаграммы вариантов использования, диаграммы взаимодействия, диаграммы состояний и диаграммы деятельности.

Модель варианта использования

Случай использования

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

Актер

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

На следующем рисунке показаны обозначения актера с именем Student и сценарий использования с именем Generate Performance Report.

Диаграммы использования

Диаграммы прецедентов представляют внешний вид поведения элементов системы и их использования в контексте.

Диаграммы прецедентов состоят из —

• Случаи применения
• Актеры
• Отношения, такие как зависимость, обобщение и ассоциация

Диаграммы прецедентов используются —

• Смоделировать контекст системы, заключив все действия системы в прямоугольник и сосредоточившись на субъектах вне системы, взаимодействуя с ней.

• Для моделирования требований системы с внешней точки зрения.

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

Для моделирования требований системы с внешней точки зрения.

пример

Давайте рассмотрим Автоматизированную Систему Торгового Дома. Мы предполагаем следующие особенности системы —

• Торговый дом имеет сделки с двумя типами клиентов, индивидуальных клиентов и корпоративных клиентов.

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

• Система позволяет менеджеру управлять учетными записями клиентов и отвечать на любые запросы, отправленные клиентом.

Торговый дом имеет сделки с двумя типами клиентов, индивидуальных клиентов и корпоративных клиентов.

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

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

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

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

• Диаграммы последовательности
• Диаграммы сотрудничества

Диаграммы взаимодействия используются для моделирования —

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

• управление потоком организации с использованием диаграмм сотрудничества.

поток управления по времени упорядочения с использованием диаграмм последовательности.

управление потоком организации с использованием диаграмм сотрудничества.

Диаграммы последовательности

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

Обозначения — Эти диаграммы представлены в виде двумерных диаграмм. Объекты, которые инициируют взаимодействие, расположены на оси X. Сообщения, отправляемые и получаемые этими объектами, располагаются вдоль оси y в порядке увеличения времени сверху вниз.

Пример . Диаграмма последовательности действий для Автоматизированной торговой системы представлена ​​на следующем рисунке.

Диаграммы сотрудничества

Диаграммы взаимодействия — это диаграммы взаимодействия, которые иллюстрируют структуру объектов, которые отправляют и получают сообщения.

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

Пример — Диаграмма сотрудничества для Автоматизированной Торговой Системы представлена ​​на рисунке ниже.

Диаграммы состояний

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

Диаграммы состояния-диаграммы состоят из —

• Состояния: простые или составные
• Переходы между государствами
• События, вызывающие переходы
• Действия из-за событий

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

пример

В Автоматизированной Системе Торгового Дома давайте смоделируем Order как объект и проследим его последовательность. На следующем рисунке показана соответствующая диаграмма состояний.

Диаграммы деятельности

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

Диаграммы деятельности состоят из —

• Состояния активности и состояния действия
• Переходы
• Объекты

Диаграммы деятельности используются для моделирования —

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

пример

На следующем рисунке показана диаграмма действий части Автоматизированной торговой системы.

OOAD — Объектно-ориентированный дизайн

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

Этапы объектно-ориентированного проектирования могут быть определены как —

• Определение контекста системы
• Проектирование системной архитектуры
• Идентификация объектов в системе
• Построение дизайнерских макетов
• Спецификация объектных интерфейсов

Системный дизайн

Объектно-ориентированное проектирование системы включает в себя определение контекста системы с последующим проектированием архитектуры системы.

• Контекст . Контекст системы имеет статическую и динамическую части. Статический контекст системы разработан с использованием простой блок-схемы всей системы, которая расширена в иерархию подсистем. Модель подсистемы представлена ​​UML-пакетами. Динамический контекст описывает, как система взаимодействует со своей средой. Он моделируется с использованием диаграмм вариантов использования .

• Архитектура системы — Архитектура системы разработана на основе контекста системы в соответствии с принципами архитектурного проектирования, а также с учетом предметной области. Как правило, система разбивается на слои, и каждый слой разлагается для формирования подсистем.

Контекст . Контекст системы имеет статическую и динамическую части. Статический контекст системы разработан с использованием простой блок-схемы всей системы, которая расширена в иерархию подсистем. Модель подсистемы представлена ​​UML-пакетами. Динамический контекст описывает, как система взаимодействует со своей средой. Он моделируется с использованием диаграмм вариантов использования .

Архитектура системы — Архитектура системы разработана на основе контекста системы в соответствии с принципами архитектурного проектирования, а также с учетом предметной области. Как правило, система разбивается на слои, и каждый слой разлагается для формирования подсистем.

Объектно-ориентированная декомпозиция

Разложение означает деление большой сложной системы на иерархию более мелких компонентов с меньшей сложностью на принципах «разделяй и властвуй». Каждый основной компонент системы называется подсистемой. Объектно-ориентированная декомпозиция идентифицирует отдельные автономные объекты в системе и связь между этими объектами.

Преимущества разложения:

• Отдельные компоненты имеют меньшую сложность и поэтому более понятны и управляемы.

• Это позволяет разделение рабочей силы, имеющей специализированные навыки.

• Это позволяет заменять или модифицировать подсистемы, не затрагивая другие подсистемы.

Отдельные компоненты имеют меньшую сложность и поэтому более понятны и управляемы.

Это позволяет разделение рабочей силы, имеющей специализированные навыки.

Это позволяет заменять или модифицировать подсистемы, не затрагивая другие подсистемы.

Выявление параллелизма

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

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

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

Идентификация шаблонов

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

Некоторые часто используемые шаблоны дизайна —

• Фасадный рисунок
• Модель разделения вида модели
• Образец наблюдателя
• Модель контроллера вида модели
• Опубликовать шаблон подписки
• Прокси шаблон

Управление событиями

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

Событие — это спецификация значимого события, имеющего местоположение во времени и пространстве.

Существует четыре типа событий, которые можно смоделировать, а именно:

• Сигнальное событие — именованный объект, брошенный одним объектом и захваченный другим объектом.

• Событие вызова — синхронное событие, представляющее отправку операции.

• Событие времени — событие, представляющее течение времени.

• Событие изменения — событие, представляющее изменение состояния.

Сигнальное событие — именованный объект, брошенный одним объектом и захваченный другим объектом.

Событие вызова — синхронное событие, представляющее отправку операции.

Событие времени — событие, представляющее течение времени.

Событие изменения — событие, представляющее изменение состояния.

Обработка граничных условий

Этап проектирования системы должен учитывать инициализацию и завершение системы в целом, а также каждой подсистемы. Различные аспекты, которые задокументированы, следующие:

• Запуск системы, т. Е. Переход системы из неинициализированного состояния в устойчивое состояние.

• Завершение работы системы, т. Е. Закрытие всех запущенных потоков, очистка ресурсов и отправка сообщений.

• Начальная конфигурация системы и реконфигурация системы при необходимости.

• Предвидение сбоев или нежелательного завершения работы системы.

Запуск системы, т. Е. Переход системы из неинициализированного состояния в устойчивое состояние.

Завершение работы системы, т. Е. Закрытие всех запущенных потоков, очистка ресурсов и отправка сообщений.

Начальная конфигурация системы и реконфигурация системы при необходимости.

Предвидение сбоев или нежелательного завершения работы системы.

Граничные условия моделируются с использованием граничных вариантов использования.

Объектный дизайн

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

Проектирование объекта включает в себя следующие этапы —

• Идентификация объекта
• Представление объекта, т. Е. Построение проектных моделей
• Классификация операций
• Алгоритм проектирования
• Дизайн отношений
• Осуществление контроля внешних взаимодействий
• Пакетные классы и ассоциации в модули

Идентификация объекта

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

Функции этого этапа —

• Выявление и уточнение классов в каждой подсистеме или пакете

• Определение связей и ассоциаций между классами

• Разработка иерархических ассоциаций между классами, т. Е. Обобщение / специализация и наследования

• Проектирование агрегатов

Выявление и уточнение классов в каждой подсистеме или пакете

Определение связей и ассоциаций между классами

Разработка иерархических ассоциаций между классами, т. Е. Обобщение / специализация и наследования

Проектирование агрегатов

Представление объекта

Как только классы идентифицированы, они должны быть представлены с использованием методов объектного моделирования. Этот этап в основном включает в себя построение UML-диаграмм.

Есть два типа дизайнерских моделей, которые должны быть произведены —

• Статические модели — Для описания статической структуры системы используются диаграммы классов и диаграммы объектов.

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

Статические модели — Для описания статической структуры системы используются диаграммы классов и диаграммы объектов.

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

Классификация операций

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

В отношении операций выполняются следующие задачи:

• Разработана схема перехода состояний каждого объекта в системе.

• Операции определены для событий, полученных объектами.

• Идентифицированы случаи, когда одно событие вызывает другие события в том же или в другом объекте.

• Подоперации в действиях определены.

• Основные действия расширены до диаграмм потоков данных.

Разработана схема перехода состояний каждого объекта в системе.

Операции определены для событий, полученных объектами.

Идентифицированы случаи, когда одно событие вызывает другие события в том же или в другом объекте.

Подоперации в действиях определены.

Основные действия расширены до диаграмм потоков данных.

Разработка алгоритма

Операции в объектах определяются с помощью алгоритмов. Алгоритм — это пошаговая процедура, которая решает проблему, изложенную в операции. Алгоритмы сосредоточены на том, как это должно быть сделано.

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

• Сложность вычислений — Сложность определяет эффективность алгоритма с точки зрения времени вычислений и требований к памяти.

• Гибкость — Гибкость определяет, может ли выбранный алгоритм быть реализован надлежащим образом, без потери соответствия в различных средах.

• Понятность — это определяет, является ли выбранный алгоритм простым для понимания и реализации.

Сложность вычислений — Сложность определяет эффективность алгоритма с точки зрения времени вычислений и требований к памяти.

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

Понятность — это определяет, является ли выбранный алгоритм простым для понимания и реализации.

Дизайн Отношений

Стратегия реализации отношений должна быть записана на этапе проектирования объекта. Основные взаимосвязи, которые адресованы, включают ассоциации, агрегации и наследования.

Дизайнер должен сделать следующее относительно ассоциаций —

• Определите, является ли ассоциация однонаправленной или двунаправленной.

• Проанализируйте пути ассоциаций и обновите их при необходимости.

• Реализуйте ассоциации как отдельный объект, в случае отношений «многие ко многим»; или как ссылка на другой объект в случае отношений один-к-одному или один-ко-многим.

Определите, является ли ассоциация однонаправленной или двунаправленной.

Проанализируйте пути ассоциаций и обновите их при необходимости.

Реализуйте ассоциации как отдельный объект, в случае отношений «многие ко многим»; или как ссылка на другой объект в случае отношений один-к-одному или один-ко-многим.

Что касается наследования, проектировщик должен сделать следующее —

• Настройте классы и их ассоциации.

• Определите абстрактные классы.

• Сделайте так, чтобы при необходимости обменивались поведением.

Настройте классы и их ассоциации.

Определите абстрактные классы.

Сделайте так, чтобы при необходимости обменивались поведением.

Осуществление контроля

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

Подходы для реализации динамической модели:

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

• Механизм конечного автомата — этот подход напрямую представляет конечный автомат через класс конечного автомата. Этот класс выполняет конечный автомат посредством набора переходов и действий, предоставляемых приложением.

• Управление как параллельные задачи — при таком подходе объект реализуется как задача на языке программирования или в операционной системе. Здесь событие реализовано как межзадачный вызов. Сохраняет присущий параллелизм реальных объектов.

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

Механизм конечного автомата — этот подход напрямую представляет конечный автомат через класс конечного автомата. Этот класс выполняет конечный автомат посредством набора переходов и действий, предоставляемых приложением.

Управление как параллельные задачи — при таком подходе объект реализуется как задача на языке программирования или в операционной системе. Здесь событие реализовано как межзадачный вызов. Сохраняет присущий параллелизм реальных объектов.

Классы упаковки

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

Различные аспекты упаковки —

• Скрытие внутренней информации от внешнего вида. Это позволяет рассматривать класс как «черный ящик» и позволяет изменять реализацию класса, не требуя, чтобы какие-либо клиенты этого класса модифицировали код.

• Согласованность элементов . Элемент, такой как класс, операция или модуль, является связным, если он организован по согласованному плану, и все его части неразрывно связаны, так что они служат общей цели.

• Построение физических модулей . Следующие рекомендации помогут при создании физических модулей.

  • Классы в модуле должны представлять похожие вещи или компоненты в одном и том же составном объекте.

  • Тесно связанные классы должны быть в одном модуле.

  • Несвязанные или слабо связанные классы следует размещать в отдельных модулях.

  • Модули должны обладать хорошей связностью, т. Е. Высоким уровнем взаимодействия между их компонентами.

  • Модуль должен иметь слабую связь с другими модулями, т. Е. Взаимодействие или взаимозависимость между модулями должны быть минимальными.

Скрытие внутренней информации от внешнего вида. Это позволяет рассматривать класс как «черный ящик» и позволяет изменять реализацию класса, не требуя, чтобы какие-либо клиенты этого класса модифицировали код.

Согласованность элементов . Элемент, такой как класс, операция или модуль, является связным, если он организован по согласованному плану, и все его части неразрывно связаны, так что они служат общей цели.

Построение физических модулей . Следующие рекомендации помогут при создании физических модулей.

Классы в модуле должны представлять похожие вещи или компоненты в одном и том же составном объекте.

Тесно связанные классы должны быть в одном модуле.

Несвязанные или слабо связанные классы следует размещать в отдельных модулях.

Модули должны обладать хорошей связностью, т. Е. Высоким уровнем взаимодействия между их компонентами.

Модуль должен иметь слабую связь с другими модулями, т. Е. Взаимодействие или взаимозависимость между модулями должны быть минимальными.

Оптимизация дизайна

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

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

Различные вещи, которые можно сделать для оптимизации дизайна:

• Добавить избыточные ассоциации
• Опустить неиспользуемые ассоциации
• Оптимизация алгоритмов
• Сохраните производные атрибуты, чтобы избежать повторного вычисления сложных выражений

Добавление избыточных ассоциаций

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

Исключение неиспользуемых ассоциаций

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

Оптимизация алгоритмов

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

Оптимизация алгоритмов достигается путем —

• Перестановка порядка вычислительных задач
• Изменение порядка выполнения циклов по сравнению с установленным в функциональной модели
• Удаление мертвых путей в алгоритме

Сохранение и хранение производных атрибутов

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

Однако это может привести к аномалиям обновления, то есть изменению значений базовых атрибутов без соответствующего изменения значений производных атрибутов. Чтобы избежать этого, предпринимаются следующие шаги:

• При каждом обновлении значения базового атрибута производный атрибут также пересчитывается.

• Все производные атрибуты пересчитываются и обновляются периодически в группе, а не после каждого обновления.

При каждом обновлении значения базового атрибута производный атрибут также пересчитывается.

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

Проектная документация

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

Области использования

Хотя вторичный продукт, хорошая документация необходима, особенно в следующих областях —

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

содержание

Полезная документация должна по существу включать следующее содержание —

• Архитектура системы высокого уровня. Диаграммы процессов и диаграммы модулей

• Ключевые абстракции и механизмы — Диаграммы классов и диаграммы объектов.

• Сценарии, иллюстрирующие поведение основных аспектов — поведенческие диаграммы

Архитектура системы высокого уровня. Диаграммы процессов и диаграммы модулей

Ключевые абстракции и механизмы — Диаграммы классов и диаграммы объектов.

Сценарии, иллюстрирующие поведение основных аспектов — поведенческие диаграммы

Характеристики

Особенности хорошей документации —

• Краткий и в то же время однозначный, последовательный и полный

• Прослеживается в соответствии с требованиями системы

• Хорошо структурированная

• Схематическое, а не описательное

Краткий и в то же время однозначный, последовательный и полный

Прослеживается в соответствии с требованиями системы

Хорошо структурированная

Схематическое, а не описательное

OOAD — Стратегии реализации

Реализация объектно-ориентированного проектирования обычно включает использование стандартного объектно-ориентированного языка программирования (OOPL) или сопоставление объектных проектов с базами данных. В большинстве случаев это включает оба.

Реализация с использованием языков программирования

Обычно задача преобразования объекта в код — это простой процесс. Любой объектно-ориентированный язык программирования, такой как C ++, Java, Smalltalk, C # и Python, включает в себя условия для представления классов. В этой главе мы иллюстрируем концепцию, используя C ++.

На следующем рисунке показано представление класса Circle с использованием C ++.

Реализация Ассоциаций

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

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

Однонаправленные Ассоциации

Для реализации однонаправленных ассоциаций необходимо соблюдать осторожность, чтобы поддерживать однонаправленность. Реализации для различной множественности следующие:

• Необязательные ассоциации. Здесь может существовать или не существовать связь между участвующими объектами. Например, в связи между клиентом и текущим счетом на рисунке ниже, клиент может иметь или не иметь текущий счет.

Необязательные ассоциации. Здесь может существовать или не существовать связь между участвующими объектами. Например, в связи между клиентом и текущим счетом на рисунке ниже, клиент может иметь или не иметь текущий счет.

Для реализации объект Текущего счета включен в качестве атрибута в Customer, который может быть НЕДЕЙСТВИТЕЛЕН. Реализация с использованием C ++ —

class Customer {
   private:
   // attributes
   Current_Account c; //an object of Current_Account as attribute
   
   public:  

   Customer() {
      c = NULL; 
   } // assign c as NULL

   Current_Account getCurrAc() {
      return c;
   }
   
   void setCurrAc( Current_Account myacc) {
      c = myacc;
   }

   void removeAcc() {  
      c = NULL;
   } 
};

• Связи один-к-одному — Здесь один экземпляр класса связан ровно с одним экземпляром ассоциированного класса. Например, отдел и менеджер имеют непосредственную связь, как показано на рисунке ниже.

Связи один-к-одному — Здесь один экземпляр класса связан ровно с одним экземпляром ассоциированного класса. Например, отдел и менеджер имеют непосредственную связь, как показано на рисунке ниже.

Это реализуется путем включения в Department объекта Manager, который не должен иметь значение NULL. Реализация с использованием C ++ —

class Department {
   private:
   // attributes
   Manager mgr; //an object of Manager as attribute
   
   public:  
   Department (/*parameters*/, Manager m) { //m is not NULL   
      // assign parameters to variables
      mgr = m;
   } 

   Manager getMgr() {  
      return mgr;  
   }    
};

• Ассоциации «один ко многим». Здесь один экземпляр класса связан с несколькими экземплярами ассоциированного класса. Например, рассмотрим связь между Сотрудником и Зависимым на следующем рисунке.

Ассоциации «один ко многим». Здесь один экземпляр класса связан с несколькими экземплярами ассоциированного класса. Например, рассмотрим связь между Сотрудником и Зависимым на следующем рисунке.

Это реализуется путем включения списка иждивенцев в класс Employee. Реализация с использованием контейнера списков C ++ STL —

class Employee {
   private:
   char * deptName;
   list <Dependent> dep; //a list of Dependents as attribute

   public:  
   void addDependent ( Dependent d) { 
      dep.push_back(d); 
   } // adds an employee to the department

   void removeDeoendent( Dependent d) { 
      int index = find ( d, dep );
      // find() function returns the index of d in list dep
      dep.erase(index);
   }               
};

Двунаправленные ассоциации

Для реализации двунаправленной ассоциации необходимо поддерживать связь в обоих направлениях.

• Необязательные или взаимно-однозначные ассоциации. Рассмотрим взаимосвязь между Проектом и Руководителем проекта, имеющую двустороннюю связь «один-к-одному», как показано на рисунке ниже.

Необязательные или взаимно-однозначные ассоциации. Рассмотрим взаимосвязь между Проектом и Руководителем проекта, имеющую двустороннюю связь «один-к-одному», как показано на рисунке ниже.

Реализация с использованием C ++ —

Class Project {
   private:
   // attributes
   Project_Manager pmgr; 
   public:  
   void setManager ( Project_Manager pm);       
   Project_Manager changeManager();   
};

class Project_Manager {
   private:
   // attributes
   Project pj; 

   public:  
   void setProject(Project p);       
   Project removeProject();   
};

• Ассоциации «один ко многим». Рассмотрите отношения между Департаментом и Сотрудником, имеющие ассоциацию «один ко многим», как показано на рисунке ниже.

Ассоциации «один ко многим». Рассмотрите отношения между Департаментом и Сотрудником, имеющие ассоциацию «один ко многим», как показано на рисунке ниже.

Реализация с использованием контейнера списков C ++ STL

class Department {
   private:
   char * deptName;
   list <Employee> emp; //a list of Employees as attribute

   public:  
   void addEmployee ( Employee e) { 
      emp.push_back(e); 
   } // adds an employee to the department

   void removeEmployee( Employee e) { 
      int index = find ( e, emp );
      // find function returns the index of e in list emp
      emp.erase(index);
   }               
};

class Employee {
   private:
   //attributes
   Department d;

   public:
   void addDept();
   void removeDept();
};

Реализация ассоциаций как классов

Если с ассоциацией связаны некоторые атрибуты, она должна быть реализована с использованием отдельного класса. Например, рассмотрим связь «один к одному» между сотрудником и проектом, как показано на рисунке ниже.

Реализация WorksOn с использованием C ++

class WorksOn {
   private:
   Employee e; 
   Project p;
   Hours h;
   char * date;

   public:
   // class methods
};	  

Реализация ограничений

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

пример

Рассмотрим класс Employee, где age — это атрибут, который может иметь значения в диапазоне от 18 до 60. Следующий код C ++ включает его:

class Employee {
   private: char * name;
   int age;
   // other attributes

   public:
   Employee() {                 // default constructor   
      strcpy(name, "");
      age = 18;                // default value
   }
 
   class AgeError {};          // Exception class
   void changeAge( int a) {    // method that changes age

      if ( a < 18 || a > 60 )  // check for invalid condition
      throw AgeError();        // throw exception
      age = a;			
   }
};

Реализация государственных карт

Существует две альтернативные стратегии реализации для реализации состояний в диаграммах диаграммы состояний.

Перечисления в классе

В этом подходе состояния представлены различными значениями элемента данных (или набора элементов данных). Значения явно определены перечислением в классе. Переходы представлены функциями-членами, которые изменяют значение соответствующего элемента данных.

Расположение классов в иерархии обобщения

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

Сопоставление объектов с системой баз данных

Постоянство объектов

Важным аспектом разработки объектно-ориентированных систем является постоянство данных. Благодаря постоянству объекты имеют более длительный срок службы, чем программа, создавшая их. Постоянные данные сохраняются на вторичном носителе, откуда они могут быть перезагружены при необходимости.

Обзор РСУБД

База данных — это упорядоченная коллекция связанных данных.

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

В системах управления реляционными базами данных (RDBMS) данные хранятся в виде отношений или таблиц, где каждый столбец или поле представляет атрибут, а каждая строка или кортеж представляет запись экземпляра.

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

Внешний ключ — это атрибут, который является первичным ключом связанной таблицы.

Представление классов в виде таблиц в РСУБД

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

Например, класс Circle можно преобразовать в таблицу, как показано на рисунке ниже.

Schema for Circle Table: CIRCLE(CID, X_COORD, Y_COORD, RADIUS, COLOR)
Creating a Table Circle using SQL command:
CREATE TABLE CIRCLE (   
   CID	VARCHAR2(4) PRIMARY KEY,
   X_COORD INTEGER NOT NULL,
   Y_COORD INTEGER NOT NULL,
   Z_COORD INTEGER NOT NULL,
   COLOR 
);

Сопоставление ассоциаций с таблицами базы данных

Индивидуальные ассоциации

Для реализации связей 1: 1 первичный ключ любой таблицы назначается в качестве внешнего ключа другой таблицы. Например, рассмотрим связь между отделом и менеджером —

Команды SQL для создания таблиц

CREATE TABLE DEPARTMENT ( 
   DEPT_ID INTEGER PRIMARY KEY,
   DNAME VARCHAR2(30) NOT NULL,
   LOCATION VARCHAR2(20),
   EMPID INTEGER REFERENCES MANAGER 
);

CREATE TABLE MANAGER ( 
   EMPID INTEGER PRIMARY KEY,
   ENAME VARCHAR2(50) NOT NULL,
   ADDRESS VARCHAR2(70),
);

Один ко многим Ассоциациям

Для реализации связей 1: N первичный ключ таблицы на 1-й стороне ассоциации назначается как внешний ключ таблицы на N-стороне ассоциации. Например, рассмотрим связь между Департаментом и Сотрудником —

Команды SQL для создания таблиц

CREATE TABLE DEPARTMENT ( 
   DEPT_ID INTEGER PRIMARY KEY,
   DNAME VARCHAR2(30) NOT NULL,
   LOCATION VARCHAR2(20),
);

CREATE TABLE EMPLOYEE ( 
   EMPID INTEGER PRIMARY KEY,
   ENAME VARCHAR2(50) NOT NULL,
   ADDRESS VARCHAR2(70),
   D_ID INTEGER REFERENCES DEPARTMENT
);

Много-ко-много ассоциаций

Для реализации ассоциаций M: N создается новое отношение, которое представляет ассоциацию. Например, рассмотрим следующую связь между Сотрудником и Проектом —

Схема для таблицы Works_On — WORKS_ON (EMPID, PID, HOURS, START_DATE)

Команда SQL для создания ассоциации Works_On — CREATE TABLE WORKS_ON

( 
   EMPID INTEGER,
   PID INTEGER, 
   HOURS INTEGER,
   START_DATE DATE,
   PRIMARY KEY (EMPID, PID),
   FOREIGN KEY (EMPID) REFERENCES EMPLOYEE,
   FOREIGN KEY (PID) REFERENCES PROJECT 
);

Отображение наследования в таблицы

Для сопоставления наследования первичный ключ базовой таблицы (таблиц) назначается как первичный ключ, а также внешний ключ в производной таблице (таблицах).

пример

OOAD — Тестирование и обеспечение качества

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

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

Тестирование объектно-ориентированных систем

Тестирование — это постоянная деятельность при разработке программного обеспечения. В объектно-ориентированных системах тестирование включает три уровня: модульное тестирование, подсистемное тестирование и тестирование системы.

Модульное тестирование

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

Подсистема тестирования

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

Тестирование системы

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

Объектно-ориентированные методы тестирования

Тестирование серой коробки

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

• Тестирование на основе модели состояния — это охватывает покрытие состояния, покрытие перехода состояния и покрытие пути перехода состояния.

• Тестирование на основе варианта использования — каждый сценарий в каждом сценарии использования тестируется.

• Тестирование на основе диаграмм классов. Проверяется каждый класс, производный класс, ассоциации и агрегаты.

• Тестирование на основе диаграмм последовательности — проверяются методы в сообщениях на диаграммах последовательности.

Тестирование на основе модели состояния — это охватывает покрытие состояния, покрытие перехода состояния и покрытие пути перехода состояния.

Тестирование на основе варианта использования — каждый сценарий в каждом сценарии использования тестируется.

Тестирование на основе диаграмм классов. Проверяется каждый класс, производный класс, ассоциации и агрегаты.

Тестирование на основе диаграмм последовательности — проверяются методы в сообщениях на диаграммах последовательности.

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

Два основных подхода к тестированию подсистемы:

• Тестирование на основе потоков — все классы, необходимые для реализации одного варианта использования в подсистеме, интегрированы и протестированы.

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

Тестирование на основе потоков — все классы, необходимые для реализации одного варианта использования в подсистеме, интегрированы и протестированы.

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

Категории системного тестирования

• Альфа-тестирование — это выполняется группой тестирования в организации, которая разрабатывает программное обеспечение.

• Бета-тестирование — это проводится выбранной группой сотрудничающих клиентов.

• Приемочное тестирование — это выполняется заказчиком до принятия результатов.

Альфа-тестирование — это выполняется группой тестирования в организации, которая разрабатывает программное обеспечение.

Бета-тестирование — это проводится выбранной группой сотрудничающих клиентов.

Приемочное тестирование — это выполняется заказчиком до принятия результатов.

Гарантия качества программного обеспечения

Качество программного обеспечения

Schulmeyer и McManus определили качество программного обеспечения как «пригодность для использования всего программного продукта». Качественное программное обеспечение делает именно то, для чего оно предназначено, и интерпретируется с точки зрения удовлетворения спецификации требований, установленных пользователем.

Гарантия качества

Обеспечение качества программного обеспечения — это методология, которая определяет степень пригодности программного продукта для использования. Действия, которые включены для определения качества программного обеспечения:

• Аудиторская проверка
• Разработка стандартов и руководств
• Изготовление отчетов
• Обзор системы качества

Факторы качества

• Правильность. Правильность определяет, правильно ли выполнены требования к программному обеспечению.

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

• Переносимость — Переносимость определяет, может ли программное обеспечение работать на разных платформах с разными аппаратными устройствами.

• Ремонтопригодность — ремонтопригодность определяет легкость исправления ошибок и обновления модулей.

• Возможность повторного использования — возможность повторного использования определяет, можно ли повторно использовать модули и классы для разработки других программных продуктов.

Правильность. Правильность определяет, правильно ли выполнены требования к программному обеспечению.

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

Переносимость — Переносимость определяет, может ли программное обеспечение работать на разных платформах с разными аппаратными устройствами.

Ремонтопригодность — ремонтопригодность определяет легкость исправления ошибок и обновления модулей.

Возможность повторного использования — возможность повторного использования определяет, можно ли повторно использовать модули и классы для разработки других программных продуктов.

Объектно-ориентированные метрики

Метрики можно в целом разделить на три категории: метрики проектов, метрики продуктов и метрики процессов.

Метрики проекта

Метрики проекта позволяют руководителю проекта программного обеспечения оценить состояние и производительность текущего проекта. Следующие метрики подходят для объектно-ориентированных программных проектов —

• Количество сценариев сценария
• Количество ключевых классов
• Количество классов поддержки
• Количество подсистем

Метрики продукта

Метрики продукта измеряют характеристики программного продукта, который был разработан. Метрики продукта, подходящие для объектно-ориентированных систем:

• Методы на класс — это определяет сложность класса. Если предполагается, что все методы класса одинаково сложны, то класс с большим количеством методов более сложен и, следовательно, более подвержен ошибкам.

• Структура наследования. Системы с несколькими небольшими решетками наследования имеют более хорошую структуру, чем системы с одной большой решеткой наследования. Как правило, у дерева наследования не должно быть более 7 (± 2) уровней, и дерево должно быть сбалансировано.

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

• Ответ для класса — Он измеряет эффективность методов, которые вызываются экземплярами класса.

Методы на класс — это определяет сложность класса. Если предполагается, что все методы класса одинаково сложны, то класс с большим количеством методов более сложен и, следовательно, более подвержен ошибкам.

Структура наследования. Системы с несколькими небольшими решетками наследования имеют более хорошую структуру, чем системы с одной большой решеткой наследования. Как правило, у дерева наследования не должно быть более 7 (± 2) уровней, и дерево должно быть сбалансировано.

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

Ответ для класса — Он измеряет эффективность методов, которые вызываются экземплярами класса.

Метрики процесса

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