В процессе разработки приложений изменяются функциональные требования заказчика, что еще более отдаляет момент окончания работы программистов.
Таким образом, все эти особенности приводят к настоятельной необходимости моделирования структуры и процесса функционирования программных систем до начала написания соответствующего кода. При этом непременным условием успешного завершения проекта становится построение предварительной модели программной системы.
Модель (model) - абстракция физической системы, рассматриваемая с определенной точки зрения и представленная на некотором языке или в графической форме.
Основное требование к модели программной системы - она должна быть понятна заказчику и всем специалистам проектной группы, включая бизнес-аналитиков и программистов.
Процедурно-ориентированная декомпозиция программ уступила место объектно-ориентированной, при которой в качестве отдельных структурных единиц программы рассматриваются не процедуры и функции, а классы и объекты с соответствующими свойствами и методами.
Как следствие, программа перестала быть последовательностью предопределенных на этапе кодирования действий, а преобразовалась в событийно управляемую. Последнее обстоятельство доминирует и при разработке широкого круга современных приложений. В этом случае каждая программа представляет собой бесконечный цикл ожидания заранее определенных событий. Инициаторами событий могут быть другие программы или пользователи, а при наступлении отдельного события программа выходит из состояния ожидания и реагирует на него вполне адекватным образом.
В понятийной логике для изображения понятий используются окружности или прямоугольники.
Наиболее существенным обстоятельством в развитии методологии ООП явилось осознание того, что процесс написания программного кода может быть отделен от процесса проектирования структуры программы. Прежде, чем начать программирование классов, их свойств и методов, необходимо определить сами эти классы. Более того, нужно дать ответы на следующие вопросы: сколько и какие классы нужно определить для решения поставленной задачи, какие свойства и методы необходимы для придания классам требуемого поведения, а также установить взаимосвязи между классами. Эта совокупность задач не столько связана с написанием кода, сколько с общим анализом требований к будущей программе, а также с анализом конкретной предметной области, для которой разрабатывается программа. Все эти обстоятельства привели к появлению специальной методологии, получившей название методологии объектно-ориентированного анализа и проектирования (ООАП).
При проектировании базы данных возникает необходимость в предварительной разработке концептуальной схемы или модели, которая отражала бы общие взаимосвязи предметной области и особенности организации соответствующей информации.
Предметная область (domain) - часть реального мира, которая имеет существенное значение или непосредственное отношение к процессу функционирования программы. Другими словами, предметная область включает в себя только те объекты и взаимосвязи между ними, которые необходимы для описания требований и условий решения конкретной задачи.
Если разрабатывается база данных для обслуживания пассажиров крупного аэропорта, то в проектировании концептуальной схемы базы данных должны принимать участие штатные сотрудники аэропорта. Эти сотрудники хорошо знают весь процесс обслуживания пассажиров или данную предметную область. Сложность моделирования предметной области и разработки корпоративных информационных систем привело к появлению новой методологии объектно-ориентированный анализ и проектирование.
Объектно-ориентированный анализ и проектирование (ООАП, Object-Oriented Analysis/Design) - технология разработки программных систем, в основу которых положена объектно-ориентированная методология представления предметной области в виде объектов, являющихся экземплярами соответствующих классов .
В рамках ООАП исторически рассматривались три графических нотации:
Таким образом, все эти особенности приводят к настоятельной необходимости моделирования структуры и процесса функционирования программных систем до начала написания соответствующего кода. При этом непременным условием успешного завершения проекта становится построение предварительной модели программной системы.
Модель (model) - абстракция физической системы, рассматриваемая с определенной точки зрения и представленная на некотором языке или в графической форме.
Основное требование к модели программной системы - она должна быть понятна заказчику и всем специалистам проектной группы, включая бизнес-аналитиков и программистов.
Процедурно-ориентированная декомпозиция программ уступила место объектно-ориентированной, при которой в качестве отдельных структурных единиц программы рассматриваются не процедуры и функции, а классы и объекты с соответствующими свойствами и методами.
Как следствие, программа перестала быть последовательностью предопределенных на этапе кодирования действий, а преобразовалась в событийно управляемую. Последнее обстоятельство доминирует и при разработке широкого круга современных приложений. В этом случае каждая программа представляет собой бесконечный цикл ожидания заранее определенных событий. Инициаторами событий могут быть другие программы или пользователи, а при наступлении отдельного события программа выходит из состояния ожидания и реагирует на него вполне адекватным образом.
В понятийной логике для изображения понятий используются окружности или прямоугольники.
Наиболее существенным обстоятельством в развитии методологии ООП явилось осознание того, что процесс написания программного кода может быть отделен от процесса проектирования структуры программы. Прежде, чем начать программирование классов, их свойств и методов, необходимо определить сами эти классы. Более того, нужно дать ответы на следующие вопросы: сколько и какие классы нужно определить для решения поставленной задачи, какие свойства и методы необходимы для придания классам требуемого поведения, а также установить взаимосвязи между классами. Эта совокупность задач не столько связана с написанием кода, сколько с общим анализом требований к будущей программе, а также с анализом конкретной предметной области, для которой разрабатывается программа. Все эти обстоятельства привели к появлению специальной методологии, получившей название методологии объектно-ориентированного анализа и проектирования (ООАП).
При проектировании базы данных возникает необходимость в предварительной разработке концептуальной схемы или модели, которая отражала бы общие взаимосвязи предметной области и особенности организации соответствующей информации.
Предметная область (domain) - часть реального мира, которая имеет существенное значение или непосредственное отношение к процессу функционирования программы. Другими словами, предметная область включает в себя только те объекты и взаимосвязи между ними, которые необходимы для описания требований и условий решения конкретной задачи.
Если разрабатывается база данных для обслуживания пассажиров крупного аэропорта, то в проектировании концептуальной схемы базы данных должны принимать участие штатные сотрудники аэропорта. Эти сотрудники хорошо знают весь процесс обслуживания пассажиров или данную предметную область. Сложность моделирования предметной области и разработки корпоративных информационных систем привело к появлению новой методологии объектно-ориентированный анализ и проектирование.
Объектно-ориентированный анализ и проектирование (ООАП, Object-Oriented Analysis/Design) - технология разработки программных систем, в основу которых положена объектно-ориентированная методология представления предметной области в виде объектов, являющихся экземплярами соответствующих классов .
В рамках ООАП исторически рассматривались три графических нотации:
- диаграммы "сущность-связь" (Entity-Relationship Diagrams, ERD),
- диаграммы функционального моделирования (Structured Analysis and Design Technique, SADT),
- диаграммы потоков данных (Data Flow Diagrams, DFD).
Недостаток рассмотренных нотаций связан с отсутствием явных средств для объектно-ориентированного представления моделей сложных систем, а также сложных алгоритмов обработки данных. Поскольку на рассмотренных типах диаграмм не указываются характеристики времени выполнения отдельных процессов и передачи данных между процессами, то модели систем, реализующих синхронную обработку данных, не могут быть адекватно представлены в этих нотациях. Все эти особенности методов структурного системного анализа ограничили возможности широкого применения соответствующих нотаций и послужили основой для разработки унифицированного языка моделирования UML.
