Объектно-ориентированное проектирование и анализ программного обеспечения.

Введение

Методология разработки программного обеспечения

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

История

В первые годы объектно-ориентированных технологий, до середины 1990-х годов, существовало множество различных конкурирующих методологий разработки программного обеспечения и объектно-ориентированного моделирования, часто привязанных к конкретным поставщикам средств автоматизированного проектирования систем (CASE). Отсутствие стандартных нотаций, единой терминологии и четких руководств по процессам было главной проблемой того времени, что снижало эффективность коммуникации и замедляло процесс обучения. Среди известных ранних объектно-ориентированных методологий были разработки, созданные и вдохновленные такими признанными экспертами, как Грейди Буч, Джеймс Рэмбо, Ивар Якобсон (так называемые "Три Амиго"), Роберт Мартин, Питер Коад, Салли Шлер, Стивен Меллор и Ребекка Вирфс-Брок. В 1994 году "Три Амиго" из Rational Software начали совместную работу над созданием Унифицированного языка моделирования (UML). Позже, вместе с Филиппом Крухтеном и Уокером Ройсом (старшим сыном Уинстона Ройса), они успешно объединили свои собственные методологии – OMT, OOSE и методологию Буча – с различными идеями и опытом других лидеров отрасли в Rational Unified Process (RUP), всеобъемлющее итеративное и инкрементное руководство и фреймворк для изучения лучших отраслевых практик в области разработки программного обеспечения и управления проектами. С тех пор семейство Унифицированных процессов стало, пожалуй, самой популярной методологией и эталонной моделью для объектно-ориентированного анализа и проектирования.

Обзор

Жизненный цикл программного обеспечения обычно делится на этапы, начиная с абстрактного описания проблемы, затем проектированием, кодированием и тестированием, и, наконец, развертыванием. Самые ранние этапы этого процесса – анализ и проектирование. Фазу анализа также часто называют «сбором требований». В некоторых подходах к разработке программного обеспечения, известных как «водопадные модели», границы между этапами должны быть достаточно жесткими и последовательными. Термин «водопад» был введен для таких методологий, чтобы подчеркнуть, что прогресс происходит последовательно только в одном направлении, то есть, как только анализ завершен, только тогда начинается проектирование, и изменение модели анализа из-за проблем проектирования или изменение проекта из-за проблем кодирования было редким (и считалось источником ошибок). Альтернативой водопадным моделям являются итеративные модели. Это различие было популяризировано Барри Боемом в его влиятельной статье о спиральной модели для итеративной разработки программного обеспечения. В итеративных моделях можно параллельно выполнять работу на разных этапах модели. Например, можно – и это не считается источником ошибок – заниматься анализом, проектированием и даже кодированием в один день, и проблемы на одном этапе могут влиять на проблемы на другом. Основная идея итеративных моделей заключается в том, что разработка программного обеспечения – это процесс, требующий глубоких знаний, и что анализ нельзя полностью понять без понимания проблем проектирования, проблемы кодирования могут влиять на проектирование, тестирование может дать информацию о том, как следует изменить код или даже проект, и так далее. Хотя объектно-ориентированную разработку можно осуществлять с использованием водопадной модели, на практике большинство объектно-ориентированных систем разрабатываются итеративным подходом. В результате в объектно-ориентированных процессах «анализ и проектирование» часто рассматриваются одновременно. Объектно-ориентированная парадигма подчеркивает модульность и возможность повторного использования. Целью объектно-ориентированного подхода является соблюдение «принципа открытости/закрытости». Модуль считается открытым, если он поддерживает расширение, или если модуль предоставляет стандартизированные способы добавления нового поведения или описания новых состояний. В объектно-ориентированной парадигме это часто достигается путем создания нового подкласса существующего класса. Модуль считается закрытым, если он имеет четко определенный стабильный интерфейс, который должны использовать все другие модули, и который ограничивает взаимодействие и потенциальные ошибки, которые могут быть внесены в один модуль изменениями в другом. В объектно-ориентированной парадигме это достигается путем определения методов, которые вызывают сервисы объектов. Методы могут быть публичными или приватными, то есть определенные особенности поведения, уникальные для объекта, не доступны другим объектам. Это снижает вероятность многих распространенных ошибок в компьютерном программировании. Жизненный цикл программного обеспечения обычно делится на этапы, начиная с абстрактного описания проблемы, затем проектированием, кодированием и тестированием, и, наконец, развертыванием. Самые ранние этапы этого процесса – анализ и проектирование. Различие между анализом и проектированием часто описывается как «что» и «как». На этапе анализа разработчики работают с пользователями и экспертами в предметной области, чтобы определить, что должна делать система. Детали реализации на этом этапе должны быть в основном или полностью (в зависимости от конкретного метода) проигнорированы. Целью фазы анализа является создание функциональной модели системы, независимо от ограничений, таких как подходящая технология. В объектно-ориентированном анализе это обычно делается с помощью вариантов использования и абстрактных определений наиболее важных объектов. Последующий этап проектирования уточняет модель анализа и делает необходимые технологические и другие решения по реализации. В объектно-ориентированном проектировании акцент делается на описании различных объектов, их данных, поведения и взаимодействий. Модель проектирования должна содержать все детали, необходимые для реализации проекта в коде программистами.

The software life cycle is typically divided up into stages, going from abstract descriptions of the problem, to designs, then to code and testing, and finally to deployment. The earliest stages of this process are analysis and design. The analysis phase is also often called "requirements acquisition". In some approaches to software development—known collectively as waterfall models—the boundaries between each stage are meant to be fairly rigid and sequential. The term "waterfall" was coined for such methodologies to signify that progress went sequentially in one direction only, i. e., once analysis was complete then and only then was design begun and it was rare (and considered a source of error) when a design issue required a change in the analysis model or when a coding issue required a change in design. The alternative to waterfall models are iterative models. This distinction was popularized by Barry Boehm in a very influential paper on his Spiral Model for iterative software development. With iterative models it is possible to do work in various stages of the model in parallel. So for example it is possible—and not seen as a source of error—to work on analysis, design, and even code all on the same day and to have issues from one stage impact issues from another. The emphasis on iterative models is that software development is a knowledge intensive process and that things like analysis can't really be completely understood without understanding design issues, that coding issues can affect design, that testing can yield information about how the code or even the design should be modified, etc. Although it is possible to do object oriented development using a waterfall model, in practice most object oriented systems are developed with an iterative approach. As a result, in object oriented processes "analysis and design" are often considered at the same time. The object oriented paradigm emphasizes modularity and re usability. The goal of an object oriented approach is to satisfy the "openclosed principle". A module is open if it supports extension, or if the module provides standardized ways to add new behaviors or describe new states. In the object oriented paradigm this is often accomplished by creating a new subclass of an existing class. A module is closed if it has a well defined stable interface that all other modules must use and that limits the interaction and potential errors that can be introduced into one module by changes in another. In the object oriented paradigm this is accomplished by defining methods that invoke services on objects. Methods can be either public or private, i. e., certain behaviors that are unique to the object are not exposed to other objects. This reduces a source of many common errors in computer programming. The software life cycle is typically divided up into stages going from abstract descriptions of the problem to designs then to code and testing and finally to deployment. The earliest stages of this process are analysis and design. The distinction between analysis and design is often described as "what vs. how". In analysis developers work with users and domain experts to define what the system is supposed to do. Implementation details are supposed to be mostly or totally (depending on the particular method) ignored at this phase. The goal of the analysis phase is to create a functional model of the system regardless of constraints such as appropriate technology. In object oriented analysis this is typically done via use cases and abstract definitions of the most important objects. The subsequent design phase refines the analysis model and makes the needed technology and other implementation choices. In object oriented design the emphasis is on describing the various objects, their data, behavior, and interactions. The design model should have all the details required so that programmers can implement the design in code.

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

Цель любой аналитической деятельности в жизненном цикле программного обеспечения – создать модель функциональных требований системы, независимую от ограничений реализации. Основное отличие объектно-ориентированного анализа от других форм анализа заключается в том, что объектно-ориентированный подход позволяет организовывать требования вокруг объектов, объединяющих как поведение (процессы), так и состояния (данные), смоделированные по аналогии с реальными объектами, с которыми взаимодействует система. В других, или традиционных, методологиях анализа эти два аспекта – процессы и данные – рассматриваются раздельно. Например, данные могут быть смоделированы с помощью ER-диаграмм, а поведение – с помощью блок-схем или структурных диаграмм. Распространенными моделями, используемыми в объектно-ориентированном анализе, являются варианты использования и объектные модели. Варианты использования описывают сценарии для стандартных функций предметной области, которые система должна выполнять. Объектные модели описывают имена, классовые отношения (например, «Круг является подклассом Фигуры»), операции и свойства основных объектов. Для лучшего понимания также могут быть созданы макеты или прототипы пользовательского интерфейса.

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

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