OOAD - Краткое руководство

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

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

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

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

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

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

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

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

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

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

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

Основные задачи объектно-ориентированного анализа (OOA):

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Объект

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

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

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

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

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

Класс

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

Составляющими класса являются -

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

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

Example

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

• x – координата, чтобы обозначить x – координату центра.
• y – координата, чтобы обозначить y – координату центра.
• a, чтобы обозначить радиус круга

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

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

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

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

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

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

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

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

Example

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

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

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

Сообщение передается

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

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

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

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

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

Example

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

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

• Single Inheritance - Подкласс происходит от одного суперкласса.

• Multiple Inheritance - Подкласс происходит от более чем одного суперкласса.

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

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

• Hybrid Inheritance - Комбинация многоуровневого и многоуровневого наследования с целью формирования решетчатой ​​структуры.

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

Полиморфизм

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

Example

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

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

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

Обобщение

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

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

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

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

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

Ссылка

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

Ассоциация

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

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

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

• А unary relationship связывает объекты одного класса.

• А binary relationship связывает объекты двух классов.

• А ternary relationship связывает объекты трех и более классов.

Коэффициенты мощности ассоциаций

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

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

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

• Many–to–Many - Объект класса A может быть связан со многими объектами класса B и, наоборот, объект класса B может быть связан со многими объектами класса A.

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

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

Example

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

• Physical containment - Например, компьютер состоит из монитора, процессора, мыши, клавиатуры и так далее.

• Conceptual containment - Например, у акционера - акция.

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

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

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

• Это помогает ускорить разработку программного обеспечения.

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

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

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

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

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

• Analysis,
• Дизайн и
• Implementation.

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

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

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

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

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

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

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

System Design

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

Object Design

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

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

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

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

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

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

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

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

• Abstraction
• Encapsulation
• Modularity
• Hierarchy

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

• Typing
• Concurrency
• Persistence

Абстракция

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

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

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

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

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

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

Модульность

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

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

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

Иерархия

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

В OOA есть два типа иерархий:

• “IS–A” hierarchy- Он определяет иерархические отношения в наследовании, в соответствии с которыми из суперкласса может быть получено несколько подклассов, которые могут снова иметь подклассы и так далее. Например, если мы производим класс Rose от класса Flower, мы можем сказать, что роза «является…» цветком.

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

Набор текста

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

Есть два типа набора текста:

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

• Weak Typing- Здесь сообщения можно отправлять любому классу. Операция проверяется только во время выполнения, как в языке программирования Smalltalk.

Параллелизм

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

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

Упорство

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Параллелизм переходов.

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

Состояния и переходы между состояниями

состояние

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

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

• Name- Строка отличает одно состояние от другого. У государства не может быть названия.

• Entry/Exit Actions - Обозначает действия, выполняемые при входе в состояние и выходе из него.

• Internal Transitions - Изменения в состоянии, которые не вызывают изменения состояния.

• Sub–states - Состояния внутри государств.

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

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

Переход

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

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

• Source State - Состояние, на которое влияет переход.

• Event Trigger - Событие, из-за которого объект в исходном состоянии претерпевает переход, если выполняется условие защиты.

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

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

• Target State - Состояние назначения после завершения перехода.

Example

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

События

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

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

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

Example

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

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

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

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

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

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

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

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

Flight_Departs (Flight_No, From_City, To_City, Маршрут)

Действия

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

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

Действие

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

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

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

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

Сценарий

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

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

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

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

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

• Sequence Diagram - Он представляет собой временной порядок сообщений в табличной форме.

• Collaboration Diagram - Он представляет собой структурную организацию объектов, которые отправляют и получают сообщения через вершины и дуги.

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

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

Параллелизм событий

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

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

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

Параллелизм внутри объекта

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Процессы

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

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

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

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

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

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

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

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

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

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

Актеры

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

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

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

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

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

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

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

Ограничения

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

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

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

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

Representation - Ограничение отображается в виде строки в фигурных скобках.

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

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

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

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

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

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

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

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

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

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

Действующие лица в системе -

• Customers
• Salesperson
• Proprietor

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

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

• Зарегистрировать клиентов
• Процесс продаж
• Определить подарки

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Data Stores - Это либо объекты в объектной модели, либо атрибуты объектов.

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

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

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

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

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

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

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

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

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

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

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

View - Вид - это проекция модели системы с определенной точки зрения.

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

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

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

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

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

• Things
• Relationships
• Diagrams

вещи

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

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

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

• Grouping Things- Они составляют организационные части моделей UML. Есть только один вид группировки, т. Е. Упаковка.

• Annotational Things - Это объяснения в моделях UML, представляющие комментарии, применяемые для описания элементов.

Отношения

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

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

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

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

• Realization - Это семантическая связь между двумя или более классификаторами, такая, что один классификатор устанавливает контракт, соблюдение которого гарантируют другие классификаторы.

Диаграммы

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

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

Правила

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

• Names
• Scope
• Visibility
• Integrity
• Execution

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

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

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

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

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

Украшения

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

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

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

• Division of classes and objects- Класс - это абстракция группы похожих объектов. Объект - это конкретный экземпляр, реально существующий в системе.

• Division of Interface and Implementation- Интерфейс определяет правила взаимодействия. Реализация - это конкретная реализация правил, определенных в интерфейсе.

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

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

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

• Tagged Values - Расширяет свойства строительных блоков UML.

• Constraints - Расширяет семантику строительных блоков UML.

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

Класс

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

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

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

• Public- Общедоступный член виден из любой точки системы. На диаграмме классов перед ним стоит символ "+".

• Private- Частный член виден только изнутри класса. К нему нельзя получить доступ извне класса. Частный член имеет префикс '-'.

• Protected- Защищенный член виден изнутри класса и из подклассов, унаследованных от этого класса, но не снаружи. Перед ним стоит символ "#".

У абстрактного класса имя класса выделено курсивом.

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

Объект

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

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

  • object-name - имя класса

  • object-name - имя-класса :: имя-пакета

  • class-name - в случае анонимных объектов

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

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

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

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

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

Notation - В схемах UML компонент представлен прямоугольником с вкладками, как показано на рисунке ниже.

Интерфейс

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

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

Пакет

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

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

Отношения

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

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

Example- На следующих рисунках показаны примеры различных отношений между классами. На первом рисунке показана связь между двумя классами, «Отдел» и «Сотрудник», при этом в отделе может работать несколько сотрудников. Worker - это имя роли. «1» рядом с отделом и «*» рядом с сотрудником обозначают, что коэффициент мощности - один ко многим. На втором рисунке изображены отношения агрегирования, университет - это «целое из» множества факультетов.

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

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

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

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

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

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

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

Классы в системе

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

Отношения

• A Bank “has–a” number of Branches - композиция, один ко многим

• A Branch with role Zonal Head Office supervises other Branches - унарная ассоциация, один-ко-многим

• A Branch “has–a” number of accounts - агрегирование, один-ко-многим

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

• A Customer can have one Current Account - общение один на один

• A Customer can have one Savings Account - общение один на один

• A Branch “has–a” number of Loans - агрегирование, один-ко-многим

• A Customer can take many loans - ассоциация, один ко многим

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

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

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

Схема компонентов

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

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

• Components
• Interfaces
• Relationships
• Пакеты и подсистемы (необязательно)

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

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

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

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

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

Example

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

Схема развертывания

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

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

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

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

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

Example

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

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

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

Пример использования

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

Актер

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

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

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

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

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

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

Используются диаграммы вариантов использования -

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

• Смоделировать требования к системе со стороны.

Example

Рассмотрим систему АТД. Мы предполагаем следующие особенности системы -

• Торговый дом ведет операции с двумя типами клиентов: физическими лицами и корпоративными клиентами.

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

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

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

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

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

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

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

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

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

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

Notations- Эти диаграммы представлены в виде двухмерных диаграмм. Объекты, инициирующие взаимодействие, размещаются на оси x. Сообщения, отправляемые и получаемые этими объектами, располагаются по оси Y в порядке увеличения времени сверху вниз.

Example - Схема работы системы АТД представлена ​​на следующем рисунке.

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

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

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

Example - Схема взаимодействия АТС представлена ​​на рисунке ниже.

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

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

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

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

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

Example

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

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

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

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

• Состояния действий и состояния действий
• Transitions
• Objects

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

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

Example

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

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

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

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

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

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

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

• System Architecture- Архитектура системы разработана на основе контекста системы в соответствии с принципами архитектурного проектирования, а также знаниями предметной области. Обычно система разбивается на уровни, и каждый уровень разбивается на подсистемы.

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

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

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

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

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

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

Определение параллелизма

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

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

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

Выявление паттернов

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

Некоторые часто используемые шаблоны проектирования:

• Образец фасада
• Схема разделения вида модели
• Образец наблюдателя
• Шаблон контроллера представления модели
• Опубликовать шаблон подписки
• Шаблон прокси

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

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

Событие - это спецификация важного события, которое имеет место во времени и пространстве.

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

• Signal Event - Именованный объект, брошенный одним объектом и пойманный другим объектом.

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

• Time Event - Событие, отображающее течение времени.

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

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

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

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

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

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

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

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

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

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

Дизайн объекта включает следующие этапы -

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

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

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

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

• Идентификация и уточнение классов в каждой подсистеме или пакете

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

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

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

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

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

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

• Static Models - Для описания статической структуры системы с помощью диаграмм классов и диаграмм объектов.

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

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

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

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

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

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

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

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

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

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

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

Одной операции может быть несколько алгоритмов. После определения альтернативных алгоритмов выбирается оптимальный алгоритм для данной проблемной области. Метрики для выбора оптимального алгоритма:

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

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

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

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

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

В отношении ассоциаций дизайнер должен сделать следующее:

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

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

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

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

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

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

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

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

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

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

• Represent State as a Location within a Program- Это традиционный подход, основанный на процедурах, при котором местоположение управления определяет состояние программы. Конечный автомат может быть реализован в виде программы. Переход формирует оператор ввода, основной путь управления формирует последовательность инструкций, ветви формируют условия, а обратные пути формируют циклы или итерации.

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

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

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

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

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

• Hiding Internal Information from Outside View - Он позволяет рассматривать класс как «черный ящик» и позволяет изменять реализацию класса, не требуя от клиентов этого класса изменения кода.

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

• Construction of Physical Modules - Следующие рекомендации помогают при создании физических модулей -

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

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

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

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

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

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

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

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

Для оптимизации дизайна можно выполнить следующие действия:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Содержание

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

• High–level system architecture - Технологические схемы и схемы модулей

• Key abstractions and mechanisms - Диаграммы классов и диаграммы объектов.

• Scenarios that illustrate the behavior of the main aspects - Диаграммы поведения

Особенности

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

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

• Отслеживание требований к системе

• Well-structured

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

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

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

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

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

Реализующие ассоциации

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

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

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

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

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

Для реализации объект Current Account включается в качестве атрибута в Customer, который может иметь значение NULL. Реализация с использованием 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;
   } 
};

• One–to–one Associations- Здесь один экземпляр класса связан ровно с одним экземпляром связанного класса. Например, у отдела и менеджера есть взаимно однозначная связь, как показано на рисунке ниже.

Это реализуется включением в 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;  
   }    
};

• One–to–many Associations- Здесь один экземпляр класса связан с более чем одним экземпляром связанного класса. Например, рассмотрим связь между сотрудником и зависимым на следующем рисунке.

Это реализуется включением списка иждивенцев в класс 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);
   }               
};

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

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

• Optional or one–to–one Associations - Рассмотрите связь между проектом и менеджером проекта, имеющую двунаправленную связь один-к-одному, как показано на рисунке ниже.

Реализация с использованием 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();   
};

• One–to–many Associations - Рассмотрите связь между отделом и сотрудником, имеющую связь «один ко многим», как показано на рисунке ниже.

Реализация с использованием контейнера списка 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
};

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

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

Example

Рассмотрим класс Employee, где возраст - это атрибут, который может иметь значения в диапазоне от 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;			
   }
};

Реализация диаграмм состояний

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

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

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

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

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

Отображение объекта в систему базы данных

Постоянство объектов

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

Обзор СУБД

База данных - это упорядоченный набор связанных данных.

Система управления базами данных (СУБД) - это набор программного обеспечения, которое упрощает процессы определения, создания, хранения, манипулирования, извлечения, совместного использования и удаления данных в базах данных.

В системах управления реляционными базами данных (СУБД) данные хранятся в виде отношений или таблиц, где каждый столбец или поле представляет атрибут, а каждая строка или кортеж представляет собой запись экземпляра.

Каждая строка уникально идентифицируется выбранным набором минимальных атрибутов, называемых primary key.

А foreign key - атрибут, являющийся первичным ключом связанной таблицы.

Представление классов в виде таблиц в СУБД

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

Например, класс 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, создается новое отношение, которое представляет ассоциацию. Например, рассмотрим следующую связь между сотрудником и проектом:

Schema for Works_On Table - WORKS_ON (EMPID, PID, HOURS, START_DATE)

SQL command to create Works_On association - СОЗДАТЬ ТАБЛИЦУ 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 
);

Отображение наследования в таблицы

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

Example

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

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

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

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

Модульное тестирование

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

Подсистема тестирования

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

Системное тестирование

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

Объектно-ориентированные методы тестирования

Тестирование серого ящика

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

• State model based testing - Сюда входят покрытие состояния, покрытие перехода состояния и покрытие пути перехода состояния.

• Use case based testing - Каждый сценарий в каждом варианте использования тестируется.

• Class diagram based testing - Каждый класс, производный класс, ассоциации и агрегаты тестируются.

• Sequence diagram based testing - Проверены методы в сообщениях на диаграммах последовательности.

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

Два основных подхода к тестированию подсистем:

• Thread based testing - Все классы, необходимые для реализации одного варианта использования в подсистеме, интегрированы и протестированы.

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

Категории системного тестирования

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

• Beta testing - Это осуществляется избранной группой сотрудничающих клиентов.

• Acceptance testing - Это выполняется заказчиком перед принятием результатов.

Гарантия качества программного обеспечения

Качество программного обеспечения

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

Гарантия качества

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

• Auditing
• Разработка стандартов и руководств
• Составление отчетов
• Обзор системы качества

Факторы качества

• Correctness - Правильность определяет соответствие требованиям к программному обеспечению.

• Usability - Удобство использования определяет, может ли программное обеспечение использоваться разными категориями пользователей (новичками, нетехническими и экспертами).

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

• Maintainability - Ремонтопригодность определяет легкость исправления ошибок и обновления модулей.

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

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

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

Показатели проекта

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

• Количество сценариев сценария
• Количество ключевых классов
• Количество классов поддержки
• Количество подсистем

Показатели продукта

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

• Methods per Class- Это определяет сложность класса. Если предполагается, что все методы класса одинаково сложны, то класс с большим количеством методов будет более сложным и, следовательно, более подверженным ошибкам.

• Inheritance Structure- Системы с несколькими маленькими решетками наследования более хорошо структурированы, чем системы с одной большой решеткой наследования. Как правило, дерево наследования не должно иметь более 7 (± 2) уровней, и дерево должно быть сбалансированным.

• Coupling and Cohesion - Модули, имеющие низкое сцепление и высокую когезию, считаются более сконструированными, поскольку они обеспечивают большую возможность повторного использования и ремонтопригодность.

• Response for a Class - Он измеряет эффективность методов, вызываемых экземплярами класса.

Метрики процесса

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

• Количество KLOC (килограмм строк кода)
• Эффективность устранения дефектов
• Среднее количество сбоев, обнаруженных во время тестирования
• Количество скрытых дефектов на один KLOC