Абстаркция и абсттрагирование

Абстаркция и абсттрагирование

Объектно-ориентированная технология основывается на объектной модели (object model), которая, согласно Г.Бучу, базируется на четырех главных принципах (главных в том смысле, что без любого из них модель не будет объектно-ориентированной): абстрагирование, инкапсуляция, модульность, иерархичность, полиморфизм.

Абстракция (abstraction) – выделяет существенные характеристики некоторого объекта, которые отличают от всех других объектов и четко определяют его концептуальные границы для наблюдателя.

Абстрагирование – процесс выявления абстракций.

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

Инкапсуляция (encapsulation) – процесс отделения друг от друга элементов объекта, определяющих его устройство и поведение.

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

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

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

Модульность (modularity) – это свойство системы, которая была разложена на внутренние связанные, но слабо связанные между собой модули.

Иерархия (hierarchy) – упорядочение абстракций, расположение их по уровням. (в другой литературе это понятие вводится как «наследование»)
Основными видами иерархических структур применительно к сложным системам являются

структура классов(иерархия «is-a» -- отношение «обобщение/специализация» или «наследование»)

структура объектов (иерархия «part of» -- часть от или отношение агрегации)

Полиморфизм (polymorphism) – наличие множества форм или реализаций конкретной функциональности

Под полиморфизмом (греч. Poly - много, morfos - форма) понимается свойство объектов принимать различные внешние формы в зависимости от обстоятельств.

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

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

 

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

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

Аналитическая модель

Чтобы понять, как работает бизнес заказчика нужно:

Определить понятия и сущности предметной области (моделирование сущностей предметной области, их атрибутов и при необходимости их взаимосвязей)

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

Описать бизнес-процессы (моделирование бизнес-процессов)

 

Аналитическая модель – это точное, четкое представление задачи, позволяющее отвечать на вопросы и строить решения.

На этапе проектирования должна использоваться аналитическая модель, а не исходная формулировка задачи.

Качество классов

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

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

 

 

Модели классов объектно-ориентированного анализа	entity (сущность) – класс программной системы, отображение некой сущности предметной области. Основное назначение хранение данных.
bounary (граничный класс)- класс программной системы, представляющий интерфейс между внешним пользователем (actor) и программной системой.
control (менеджер)- класс программной системы, отображающий элементы управления.
Модель классов бизнес-анализа	business entity (бизнес-сущность)– класс бизнес-анализа, служит для моделирования предметной области.
Модель классов объектно-ориентированного программирования	класс проектирования- класс програмной системы, основной вид модели.

 

 

Значения (tagged value)

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

• «стереотипы» (stereotype) – новый вид элемента модели, который обладает той же структурой, что и существующий элемент, но имеет дополнительные ограничения, другую интерпретацию и пиктограмму

• «именованные (помеченные) значения» (tagged value) – текстовая информация, прикрепляемая к любым типам элементов модели, представляющее пару «имя – значение». Имя в именованном значении называют тегом (tag). Именованные значения на диаграммах изображаются в форме строки текста, заключенного в фигурные скобки. При этом используется следующий формат записи: {тег = значение}. Теги встречаются в нотации языка UML, но их определение не является строгим, поэтому они могут быть указаны самим разработчиком.

• язык ограничений OCL (Object Constraint Language), который является составной частью языка UML. Ограничение (constraint) — некоторое логическое условие, ограничивающее семантику выбранного элемента модели. Как правило, все ограничения специфицируются разработчиком, на диаграммах изображаются в форме строки текста, заключенного в фигурные скобки.

 

 

Обеспечения

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

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

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

Когда оптимально использовать итеративную модель?

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

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

Модель IID предполагает разбиение жизненного цикла проекта на последовательность итераций, каждая из которых напоминает «мини-проект», включая все процессы разработки в применении к созданию меньших фрагментов функциональности, по сравнению с проектом в целом. Цель каждой итерации — получение работающей версии программной системы, включающей функциональность, определённую интегрированным содержанием всех предыдущих и текущей итерации. Результат финальной итерации содержит всю требуемую функциональность продукта. Таким образом, с завершением каждой итерации продукт получает приращение — инкремент — к его возможностям, которые, следовательно, развиваются эволюционно. Итеративность, инкрементальность и эволюционность в данном случае есть выражение одного и того же смысла разными словами со слегка разных точек зрения[2].

 

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

 

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

 

Различные варианты итерационного подхода реализованы в большинстве современных методологий разработки (RUP, MSF, XP).

 

Участники процесса разработки ПО – Пользователь, Заказчик, Разработчик, Руководитель проекта, Аналитик,

Тестировщик, Поставщик

 

Кодирование, тестирование)

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

Типовой проект включает в себя следующие этапы разработки программного обеспечения:

• анализ требований к проекту;
• проектирование;
• реализация;
• тестирование продукта;
• внедрение и поддержка.

Анализ требований к проекту

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

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

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

Реализация

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

Тестирование продукта

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

Внедрение и поддержка

Внедрения системы обычно предусматривает следующие шаги:

• установка системы,
• обучение пользователей,
• эксплуатация.

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

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

Отношения между Package.

Основные сущности, используемые на диаграмме: пакеты (1 и 2); их частные случаи, имеющие специальную нотацию (3 и 4); пакеты, имеющие внутреннюю структуру, т.е. содержащие в себе другие пакеты и/или классы, которые показываются через отношение владения (5, 6 и 7). Для элементов пакета может быть указана видимость: открытая (8) или закрытая (9). Пакеты могут включать в себя элементы других пакетов, используя различные отношения между пакетами. Включение всех элементов одного пакета в другой возможно с помощью отношения импорта, которое существует в двух вариантах (10 и 11). Если требуется включить в пакет только некоторые элементы другого пакета, то варианты отношения импорта (12 и 13) можно применить только к ним. Более сложное отношение слияния (14) позволяет из двух исходных пакетов получить третий, в котором будут содержаться не только сущности из исходных пакетов, но и отношения между этими сущностями.

21. Вариант использования (Use Case). Абстрактный вариант использования.

Сценарий использования, вариант использования (англ. use case) — в разработке программного обеспечения и системном проектировании это описание поведения системы, когда она взаимодействует с кем-то (или чем-то) из внешней среды.

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

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

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

 

22. Диаграммы вариантов использования. Назначение. Основные элементы (Text Box, Use Case, Note, Anchor Note, Actor, Package)

Назначение:

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

• определение общих границ моделируемой предметной области;

• документирование общих требований к функциональному поведению системы;

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

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

Диаграмма прецедентов (диаграмма вариантов использования) в UML — диаграмма, отражающая отношения между актёрами и прецедентами и являющаяся составной частью модели прецедентов, позволяющей описать систему на концептуальном уровне^[1].

Прецедент — возможность моделируемой системы (часть её функциональности), благодаря которой пользователь может получить конкретный, измеримый и нужный ему результат. Прецедент соответствует отдельному сервису системы, определяет один из вариантов её использования и описывает типичный способ взаимодействия пользователя с системой. Варианты использования обычно применяются для спецификации внешних требований к системе. Для отражения модели прецедентов на диаграмме используются^[1]:

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

· актёр (англ. actor) — стилизованный человечек, обозначающий набор ролей пользователя (понимается в широком смысле: человек, внешняя сущность, класс, другая система), взаимодействующего с некоторой сущностью (системой, подсистемой, классом). Актёры не могут быть связаны друг с другом (за исключением отношений обобщения/наследования),

· прецедент — эллипс с надписью, обозначающий выполняемые системой действия (могут включать возможные варианты), приводящие к наблюдаемым актёрами результатам. Надпись может быть именем или описанием (с точки зрения актёров) того, «что» делает система (а не «как»). Имя прецедента связано с непрерываемым (атомарным) сценарием — конкретной последовательностью действий, иллюстрирующей поведение^[2]. В ходе сценария актёры обмениваются с системой сообщениями. Сценарий может быть приведён на диаграмме прецедентов в виде UML-комментария. С одним прецедентом может быть связано несколько различных сценариев.

 

Связи на диаграмме Вариантов Использования (Association, Unidirectional Association, Generalization, Extend use case, Include use case).

В языке UML имеется несколько стандартных видов отношений между актерами и вариантами использования:

· ассоциации (association relationship)

· включения (include relationship)

· расширения (extend relationship)

· обобщения (generalization relationship)

Ассоциация (association relationship) – единственное возможное отношение между актером и прецедентом. Каждая ассоциация подразумевает наличие взаимодействия и соответственно канала связи и интерфейса (граничного объекта, boundary) между актером и программной системой. Ассоциация бывает двунаправленной (сообщение посылается от актера к системе и от системы к актеру), а также однонаправленной (изображается линией со стрелкой). В случае, если стрелка направлена в сторону варианта использования, то это означает, что актер инициирует исполнение данного прецедента. Если стрелка направлена к актеру, то это показывает, что он получает от системы справочную информацию. Ассоциация может иметь некоторые дополнительные обозначения, например, имя и кратность.

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

Включение (include relationship) -- каждый экземпляр первого варианта использования всегда включает в себя функциональное поведение или выполнение второго варианта использования. В этом смысле поведение второго варианта использования является частью поведения первого варианта использования. Графически данное отношение обозначается пунктирной линией со стрелкой, направленной от базового варианта использования к включаемому варианту использования, которая помечается стереотипом <<include>>. Расширение (extend relationship) -- определяет взаимосвязь базового варианта использования с другим вариантом использования, функциональное поведение которого задействуется базовым не всегда, а только при выполнении дополнительных условий. Графически обозначается в форме пунктирной линии со стрелкой, направленной от расширяющего прецедента к базовому варианту использования и помеченой стереотипом <<extend>>.

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

Обобщение (generalization relationship) – аналогично наследованию и применяется в том случае, когда необходимо отметить, что дочерние варианты использования кроме присущего им специфического поведения обладают всеми особенностями поведения родительских вариантов использования. Стрелка отношения обобщения указывает на родительский вариант использования.

Абстаркция и абсттрагирование

Объектно-ориентированная технология основывается на объектной модели (object model), которая, согласно Г.Бучу, базируется на четырех главных принципах (главных в том смысле, что без любого из них модель не будет объектно-ориентированной): абстрагирование, инкапсуляция, модульность, иерархичность, полиморфизм.

Абстракция (abstraction) – выделяет существенные характеристики некоторого объекта, которые отличают от всех других объектов и четко определяют его концептуальные границы для наблюдателя.

Абстрагирование – процесс выявления абстракций.

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

Инкапсуляция (encapsulation) – процесс отделения друг от друга элементов объекта, определяющих его устройство и поведение.

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

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

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

Модульность (modularity) – это свойство системы, которая была разложена на внутренние связанные, но слабо связанные между собой модули.

Иерархия (hierarchy) – упорядочение абстракций, расположение их по уровням. (в другой литературе это понятие вводится как «наследование»)
Основными видами иерархических структур применительно к сложным системам являются

структура классов(иерархия «is-a» -- отношение «обобщение/специализация» или «наследование»)

структура объектов (иерархия «part of» -- часть от или отношение агрегации)

Полиморфизм (polymorphism) – наличие множества форм или реализаций конкретной функциональности

Под полиморфизмом (греч. Poly - много, morfos - форма) понимается свойство объектов принимать различные внешние формы в зависимости от обстоятельств.

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

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