Файл: Применение объектно-ориентированного подхода при проектировании информационной системы (подробно).pdf

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

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

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

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

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

Реализация – он использует либо компонентную разработку, либо Rapid Application Development (RAD).

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

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

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

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

2.2. Виды разработки объектно-ориентированных систем

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

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

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

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

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

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

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

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

Некоторые из известных ранних объектно-ориентированных методологий были вдохновлены такими гуру, как Грэди Буч, Джеймс Румбо, Ивар Якобсон , Роберт Мартин , Питер Коуд , Салли Шлаер, Стивен Меллор и Ребекка Вирфс-Брок.

В 1994 году Three Amigos of Rational Software начали совместную работу по разработке унифицированного языка моделирования (UML). Позже, вместе с Филиппом Крухтеном и Уокер Ройсом (старший сын Уинстона Ройса ), они провели успешную миссию по объединению своих методологий, методов OMT , OOSE и Booch с различными знаниями и опытом других лидеров отрасли в Rational Unified Process (RUP), всеобъемлющее итеративное и инкрементное руководство по процессам и рамки для изучения лучших практик в области разработки программного обеспечения и управления проектами. С тех пор UML стала, вероятно, самой популярной методологией и эталонной моделью для объектно-ориентированного анализа и проектирования.

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

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

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

UML состоит из:

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

На объектах выполняются следующие операции:

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

UML используется для следующих целей:

• Моделирование бизнес-процесса;
• Описание архитектуры системы;
• Отображение структуры приложения;
• Захват системного поведения;
• Моделирование структуры данных;
• Построение подробных спецификаций системы;
• Эскиз идей;
• Создание кода программы;
• Статические модели.

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

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

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

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

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

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

3.1. Проектирование UML

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

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

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

UML не является одним из методов разработки, но он был разработан для совместимости с ведущими объектно-ориентированными методами разработки программного обеспечения своего времени, например OMT, Booch method, Objectory и особенно RUP, изначально предназначенных для использовать, когда работа началась в Rational Software.

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

UML-диаграммы представляют два разных вида системной модели:

1. Статическое (или структурное) представление: подчеркивает статическую структуру системы, используя объекты, атрибуты, операции и отношения. Он включает диаграммы классов и диаграммы составной структуры.
2. Динамическое (или поведенческое) представление: подчеркивает динамическое поведение системы, показывая сотрудничество между объектами и изменениями внутренних состояний объектов. Это представление включает диаграммы последовательности, диаграммы деятельности и диаграммы состояний машины.

Модели UML можно обменять между инструментами UML с помощью формата XML Metadata Interchange (XMI).

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

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

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