Аннотация: Концепции объектно-ориентированного анализа и проектирования. Эволюция и краткая характеристика основных подходов к разработке информационных моделей бизнес-систем и бизнес-процессов. Особенности проектирования, анализа и формализации корпоративных систем. Основные этапы развития языка UML и принятые стандарты. Разработчики графической нотации и специфика ее использования в процессе создания масштабируемых программных систем.
Компьютерные и информационные технологии без преувеличения можно назвать наиболее динамичной областью современных знаний, которые концентрируют в себе самые последние достижения в сфере науки и техники. Появление новых моделей процессоров и комплектующих, версий операционных систем и программного обеспечения происходит на фоне постоянного усложнения не только отдельных физических и программных компонентов, но и лежащих в их основе концепций. Разработка и совершенствование информационных систем приводит к необходимости поддержания единого стиля для различных версий программ при их постоянной доработке и модификации.
Что такое ООП? Самое простое объяснение в интернете
Трудоемкость создания современных приложений на начальных этапах проекта, как правило, оценивается значительно ниже реально затрачиваемых усилий, что служит причиной незапланированных расходов и затягивания окончательных сроков готовности программ. В процессе разработки приложений изменяются функциональные требования заказчика, что еще более отдаляет момент окончания работы программистов. Увеличение размеров программ вынуждает привлекать сверхштатных программистов, что, в свою очередь , требует дополнительных ресурсов для организации их согласованной работы. В разработке и внедрении современных корпоративных информационных систем принимает участие множество специалистов различной квалификации, для которых единообразное понимание архитектуры и функциональности является серьезной проблемой.
Таким образом, все эти особенности приводят к настоятельной необходимости моделирования структуры и процесса функционирования программных систем до начала написания соответствующего кода. При этом непременным условием успешного завершения проекта становится построение предварительной модели программной системы.
Модель (model) — абстракция физической системы , рассматриваемая с определенной точки зрения и представленная на некотором языке или в графической форме.
С точки зрения общих принципов системного анализа одна и та же физическая система может быть представлена несколькими моделями . При этом назначение отдельной модели системы определяется характером решаемой проблемы. Основное требование к модели программной системы — она должна быть понятна заказчику и всем специалистам проектной группы, включая бизнес-аналитиков и программистов. Именно для разработки такой нотации потребовались усилия группы специалистов ведущих фирм производителей программного и аппаратного обеспечения, которые привели к появлению языка UML .
Разработка и использование моделей языка UML осуществляется в рамках общей концепции объектно-ориентированного анализа и проектирования , которая, в свою очередь , является обобщением методологии объектно-ориентированного программирования .
Объектно-ориентированное программирование за 10 минут
Методология объектно-ориентированного программирования
Методология объектно-ориентированного программирования пришла на смену процедурной или алгоритмической организации структуры программного кода, когда стало очевидно, что традиционные методы процедурного программирования не способны справиться ни с растущей сложностью программ и их разработки, ни с повышением их надежности. Во второй половине 80-х годов возникла настоятельная потребность в новой методологии программирования , которая бы позволила решить весь этот комплекс проблем. Такой методологией стало объектно-ориентированное программирование ( ООП ).
Объектно-ориентированное программирование (ООП, Object-Oriented Programming) — совокупность принципов, технологий, а также инструментальных средств для создания программных систем на основе архитектуры взаимодействия объектов .
Распространение методологии ООП связано с процессом разработки программ. В частности, процедурно-ориентированная декомпозиция программ уступила место объектно-ориентированной, при которой в качестве отдельных структурных единиц программы рассматриваются не процедуры и функции, а классы и объекты с соответствующими свойствами и методами.
Как следствие, программа перестала быть последовательностью предопределенных на этапе кодирования действий, а преобразовалась в событийно управляемую. Последнее обстоятельство доминирует и при разработке широкого круга современных приложений. В этом случае каждая программа представляет собой бесконечный цикл ожидания заранее определенных событий. Инициаторами событий могут быть другие программы или пользователи, а при наступлении отдельного события программа выходит из состояния ожидания и реагирует на него вполне адекватным образом.
Основные принципы ООП : абстракция , наследование , инкапсуляция и полиморфизм .
Абстракция (abstraction) — характеристика сущности, которая отличает ее от других сущностей. Абстракция определяет границу представления соответствующего элемента модели и применяется для определения фундаментальных понятий ООП , таких как класс и объект .
Класс представляет собой абстракцию совокупности реальных объектов , которые имеют общий набор свойств и обладают одинаковым поведением. Объект в контексте ООП рассматривается как экземпляр соответствующего класса .
Объекты , которые не имеют идентичных свойств или не обладают одинаковым поведением, по определению, не могут быть отнесены к одному классу .
Принцип, в соответствии с которым знание о наиболее общей категории разрешается применять для более частной категории, называется наследованием .
Наследование тесно связано с иерархией классов , определяющей, какие классы следует считать наиболее абстрактными и общими по отношению к другим классам . При этом если общий или родительский класс (предок) обладает фиксированным набором свойств и поведением, то производный от него класс ( потомок ) должен содержать этот же набор свойств и подобное поведение, а также дополнительные, которые будут характеризовать уникальность полученного класса . В этом случае говорят, что производный класс наследует свойства и поведение родительского класса .
Для иллюстрации принципа наследования можно привести следующий пример. Общий класс » Компьютер «. Он определяется как абстракция свойств и поведения всех, реально существующих электронных вычислительных машин. При этом общими свойствами класса » Компьютер » могут быть такие, как наличие процессора, оперативной памяти, устройств ввода и вывода информации. Если в качестве производного рассмотреть класс «Персональный компьютер «, то все выделенные выше свойства будет содержать и этот класс . Можно сказать, что класс «Персональный компьютер » наследует свойства родительского класса » Компьютер «. Однако кроме перечисленных свойств классу-потомку будут присущи дополнительные, например, наличие системного блока и материнской платы с разъемом для установки микропроцессора.
В свою очередь класс «Персональный компьютер » может быть классом-предком для других классов , в частности » Рабочая станция «, » Сервер » и «Ноутбук». С этой точки зрения все указанные классы наследуют свойства родительского класса «Персональный компьютер «, а возможно и переопределяют некоторые из них.
Описанная выше текстовая информация о соотношении классов в данном примере обладает одним серьезным недостатком, а именно, отсутствием наглядности. В этой связи возникает вопрос: а возможно ли представить иерархию наследования классов в визуальной форме? В понятийной логике для изображения понятий используются окружности или прямоугольники. С помощью этой графической нотации, иерархию классов для рассмотренного примера можно представить в виде вложенных прямоугольников или окружностей, каждый из которых соответствует отдельному классу (рис. 1.1).
Рис. 1.1. Иерархия вложенности классов для примера общего класса «Компьютер»
Подобное изображение обладает серьезным недостатком. Из представленного рисунка не ясно, изображена ли на нем иерархия понятий или декомпозиция класса » Компьютер » на его составные части. Как будет показано далее, использование нотации UML позволяет устранить данную неопределенность посредством введения в рассмотрение двух различных отношений: обобщения и агрегации (Лекция 6).
Следующий принцип ООП — инкапсуляция . Инкапсуляция характеризует сокрытие отдельных деталей внутреннего устройства классов от внешних по отношению к нему объектов или пользователей.
Клиенту, взаимодействующему с объектом класса , необязательно знать, каким образом осуществлен тот или иной элемент класса . Конкретная реализация присущих классу свойств и методов, которые определяют его поведение, является собственным делом данного класса . Более того, отдельные свойства и методы класса могут быть невидимы за его пределами, это относится к базовой идее введения различных категорий видимости для элементов класса .
На примере с классом » Компьютер » нетрудно проиллюстрировать инкапсуляцию следующим образом. Основным субъектом, который взаимодействует с объектами этого класса , является пользователь . Вполне очевидно, что не каждый пользователь в совершенстве знает внутреннее устройство того или иного компьютера. К тому же, отдельные детали этого устройства сознательно скрыты в корпусе системного блока или монитора. А в случае нарушения работы компьютера, которое является причиной неадекватности его поведения, необходимый ремонт выполняет профессиональный специалист.
Инкапсуляция ведет свое происхождение от деления модулей в некоторых языках программирования на две части или секции: интерфейс и реализацию. При этом в интерфейсной секции модуля описываются все объявления функций и процедур, а возможно и типов данных, доступных за пределами модуля. Указанные процедуры и функции являются способами оказания услуг внешним клиентам. В другой секции модуля, называемой реализацией, содержится программный код, который определяет конкретные способы реализации объявленных в интерфейсной части процедур и функций.
Полиморфизм также один из основных принципов ООП . Под полиморфизмом (греч. Poly — много, morfos — форма) понимается свойство объектов принимать различные внешние формы в зависимости от обстоятельств. Применительно к ООП полиморфизм означает, что действия, выполняемые одноименными методами, могут различаться в зависимости от того, к какому из классов относится тот или иной метод.
К примеру, три объекта соответствующих классов : двигатель автомобиля, электрический свет в комнате и персональный компьютер . Для каждого из них можно определить операцию выключить() . Однако результат выполнения этой операции будет отличаться для каждого из рассмотренных объектов . Так для двигателя автомобиля выполнение операции выключить() означает прекращение подачи топлива и его остановку. Выполнение операции выключить() для электрического света в комнате означает простой щелчок выключателя, после чего комната погружается в темноту. В последнем случае для персонального компьютера выполнение операции выключить() может быть причиной потери данных, если производится нерегламентированным образом.
Полиморфизм объектно-ориентированных языков связан с перегрузкой функций, но не тождествен ей. Важно иметь в виду, что имена методов и свойств тесно связаны с классами , в которых они описаны. Это обстоятельство обеспечивает определенную надежность работы программы, поскольку исключает случайное применение метода для решения несвойственной ему задачи.
Наиболее существенным обстоятельством в развитии методологии ООП явилось осознание того, что процесс написания программного кода может быть отделен от процесса проектирования структуры программы. Прежде, чем начать программирование классов , их свойств и методов, необходимо определить сами эти классы . Более того, нужно дать ответы на следующие вопросы: сколько и какие классы нужно определить для решения поставленной задачи, какие свойства и методы необходимы для придания классам требуемого поведения, а также установить взаимосвязи между классами . Эта совокупность задач не столько связана с написанием кода, сколько с общим анализом требований к будущей программе, а также с анализом конкретной предметной области , для которой разрабатывается программа . Все эти обстоятельства привели к появлению специальной методологии, получившей название методологии объектно-ориентированного анализа и проектирования (ООАП).
Источник: intuit.ru
2. Объектно-ориентированное проектирование
Объектно-ориентированный подход к проектированию программных продуктов основан на:
- выделении классов объектов;
- установлении характерных свойств объектов и методов их обработки;
- создании иерархии классов, наследовании свойств объектов и методов их обработки.
Каждый объект объединяет как данные, так и программу обработки этих данных и относится к определенному классу. С помощью класса один и тот же программный код можно использовать для относящихся к нему различных объектов.
Объектный подход при разработке алгоритмов и программ предполагает:
- объектно-ориентированный анализ – анализ предметной области и выделение объектов, определение свойств и методов обработки объектов, установление их взаимосвязей;
- объектно-ориентированное проектирование – соединяет процесс объектной декомпозиции и представления с использованием моделей данных проектируемой системы на логическом и физическом уровнях, в статике и динамике.
Для проектирования программных продуктов разработаны объектно-ориентированные технологии, которые включают в себя специализированные языки программирования и инструментальные средства разработки пользовательского интерфейса.
2.1. Основные понятия объектно-ориентированного проектирования
Объектно-ориентированное программирование (ООП) принадлежит к числу ведущих компьютерных технологий, преследующих цель — повышение эффективности разработки программ.
По определению признанного авторитета в области объектно-ориентированных методов разработки программ Гради Буча «объектно-ориентированное программирование (ООП) — это методология программирования, которая основана на представлении программы в виде совокупности объектов, каждый из которых является реализацией определенного класса (типа особого вида), а классы образуют иерархию на принципах наследуемости».
Механизмы, поддерживаемые ООП, позволяют моделировать понятия предметной области более прямым и естественным путем.
И так, определяющим понятием ООП является объект – некая совокупность, объединяющая свойства, методы и события (рис. 2.1). Объект представляет собой конкретную реализацию класса, обладающую характеристиками состояния, поведения и индивидуальности. В ООП объекты – это отдельные фрагменты кода и данные, которые взаимодействуют друг с другом и окружающим миром, моделируя состояния и взаимодействие объектов реального мира.
Объекты принадлежат классам (типам) — множеству объектов, связанных определенной общностью структуры и поведения.
Свойства — это простые переменные, которые описывают состояние объекта. Например, ширина, высота, цвет и т.п. – это свойства объекта.
Методы – это процедуры и функции, определяющие то, что объект умеет делать (вычислять). Например, объект может иметь процедуру для вывода какого-то текста на экран. Эта процедура и есть метод объекта.
События – это процедуры и функции, которые вызываются при наступлении определенного события. Например, если изменилось какое-то свойство объекта, может быть сгенерировано соответствующее событие и вызвана процедура для обработки реакции на это событие.
Указанное объединение в едином объекте свойств, методов и событий называется инкапсуляцией.
Инкапсуляция — это определение данных и подпрограмм их обработки в виде целостной структурной единицы, защищающей данные от некорректного использования.
Она представляет собой технику, при которой информация прячется внутри структуры.
Пример: рассмотрим объект – «кнопка». Такой объект должен обладать следующим минимальным набором:
- Создать кнопку.
- Уничтожить кнопку.
- Нарисовать кнопку.
Другим принципом ООП является иерархическое упорядочение объектов (подзадач), получаемых в процессе декомпозиции.
О ОП преследует цель построения иерархического дерева взаимосвязей между объектами (подзадачами). Если структурная иерархия строится по простому принципу разделения целого на составные части (рис.2.2), то при создании объектно-ориентированной иерархии (ОО-иерархии) принимается другой взгляд на тот же исходный объект и в иерархии непременно отражается наследование свойств родительских (вышележащих) типов объектов дочерними (нижележащими) типами объектов (рис. 2.3).
Наследование — это такое отношение между объектами, когда один объект повторяет структуру и поведение другого.
С точки зрения программирования наследование — это свойство объектов, посредством которого экземпляры класса получают доступ к данным и методам классов-родителей без их повторного определения. Наследование позволяет различным типам данных совместно использовать один и тот же код, приводя к уменьшению его размера и повышению функциональности.
Принцип наследования действует в жизни повсеместно и повседневно. Млекопитающие и птицы наследуют признаки живых организмов, в отличие от растений, орел и воробей наследуют общее свойство птиц — умение летать. С другой стороны, львы, тигры, леопарды наследуют «структуру» и поведение, характерное для представителей отряда кошачьих и т.д.
Типы верхних уровней ОО-иерархии, как правило, не имеют конкретных экземпляров объектов. Не существует, например, конкретного живого организма (объекта), который бы сам по себе назывался «Млекопитающее» или «Птица». Такие типы называются абстрактными. Конкретные экземпляры объектов имеют, как правило, типы самых нижних уровней ОО-иерархий: «крокодил Гена» — конкретный экземпляр объекта типа «Крокодил», «кот Матроскин» — конкретный экземпляр объекта типа «Кошка домашняя».
Абстрагирование — метод решения задачи, при котором объекты разного рода объединяются общим понятием (концепцией), а затем сгруппированные сущности рассматриваются как элементы единой категории. Абстрагирование позволяет отделить логический смысл фрагмента программы от проблемы его реализации, разделив внешнее описание (интерфейс) объекта и его внутреннюю организацию (реализацию).
В ООП структурной единицей является выражение, задающее тип (называемое классом), которое позволяет использовать переменные данного типа — объекты. Представление данных обычно скрывается внутри объектов, и доступ к ним возможен только с помощью специальных подпрограмм, образующих интерфейс класса. Это позволяет отделять использование операций от их реализации и упрощает программирование. Кроме того, подпрограммы обработки данных объекта становятся такими же его компонентами, как и сами данные, что позволяет наделять объекты собственным поведением, реализуя их взаимодействие путем передачи сообщений в виде вызова интерфейсных подпрограмм. Таким образом, наследование состоит в том, что в определении нового класса (потомка) используется другой, ранее определённый класс (родитель).
Инкапсуляция и наследование — это два основных механизма ООП, обеспечивающие модульность, независимость реализации, повторное использование и естественность представления при моделировании объектов реального мира.
Еще одним основополагающим понятием ООП является полиморфизм.
Полиморфизм представляет собой свойство различных объектов выполнять одно и то же действие по-своему.
Например, действие «бежать» свойственно большинству животных. Однако каждое из них (лев, слон, крокодил, черепаха) выполняет это действие различным образом.
При традиционном (не объектно-ориентированном) подходе к программированию, животных перемещать будет программист, вызывая отдельную для конкретного животного и конкретного действия подпрограмму. При объектно-ориентированном подходе программист только указывает, какому объекту какое из присущих ему действий требуется выполнить, и (для рассматриваемого примера) однажды описанные объекты-животные сами будут себя передвигать характерным для них способом, используя входящие в его состав методы.
Таким образом, в данном случае действие «бежать» будет называться полиморфическим действием, а многообразие форм проявления этого действия — полиморфизмом.
Источник: studfile.net
Объектно-ориентированный дизайн и как его использовать для проектирования систем
С тех пор как интерфейсы программ, приложений и сайтов стали сложными, среди дизайнеров началось хаотичное деление на узкие специальности: появились системные и бизнес-аналитики, UX-дизайнеры, UI-дизайнеры, проектировщики и прототипировщики.
Рынок разделился: одни знали о проекте все, другие раскрашивали кнопки, и все были уверены, что любую проблему решит разработчик, у которого просто нет выбора. Разработчики действуют в конце производственной цепочки, и все недочеты в итоге валятся на них. Не удивительно, что теперь в глазах программистов дизайнер, проектировщик и менеджер — это люди, которые только и делают, что мешают работать.
В последние годы эти области начали сближаться. Проектирование соприкасается с дизайном, а дизайн — с версткой. В этом помогают, к примеру, дизайн-системы, storybook’и, созданные по правилам разработки интерфейсов, а также современные инструменты: Figma, Sketch, InVision Studio и другие.
Фокусироваться сперва нужно на том, как система работает, и только после на том, как она выглядит. Чтобы проектировщики, дизайнеры и разработчики одинаково мыслили и лучше понимали, как решать задачи клиента, я использую разные подходы, в том числе и объектно-ориентированный дизайн.
Мой подход основан на OOUX Софии В. Пратер (https://alistapart.com/article/object-oriented-ux/), но дополняет и расширяет его, основываясь на моем опыте применения.
Зачем нужен ООД
Объектно-ориентированный дизайн (ООД) — это методика проектирования, точка, в которой во время работы над продуктом сходятся все члены команды: дизайнеры, проектировщики, разработчики, SEO-специалисты и копирайтеры. В этом случае под дизайном я понимаю не столько внешний вид системы, сколько то, как она работает.
ООД помогает команде решить несколько важных задач.
Определиться, с чего начать
Вопрос «С чего начать?» возникает даже у самых опытных. Допустим, вам нужно разработать мобильное приложение по доставке котиков. Что вы сделаете в первую очередь? Можно начать рисовать экраны или продумывать структуру, а можно проектировать сущности.
Какие сущности есть в таком приложении? Наверняка там будут «пользователь», «заказ» и «котик». У «пользователя» есть имя и фамилия, а заказ можно сделать из двух мест: с экрана товара или с экрана со списком ранее оформленных заказов. Значит позже нужно подумать, как отразить это в интерфейсе.
ООД дает базис, от него можно оттолкнуться, чтобы собрать конструктор из методов, которые подходят именно для этого проекта.
Сэкономить
Проектирование — самый дешевый процесс в создании системы, на этом этапе принято развлекаться, генерировать идеи и смело отметать то, что не подошло.
Однако у проектирования есть очень дорогой и сложный подпроцесс — прототипирование. Зачастую в него вовлечена вся команда и эксперты со стороны клиента, прототипирование делается долго, а в процессе генерируется слишком много отвлеченных идей.
Не хочется чтобы наш дизайнер неделю проектировал, например, функцию отложенной оплаты, которая никогда не будет использоваться. ООД помогает от этого избавиться.
Создать MVP
У себя в компании мы часто работаем со стартапами — ребятами у которых нет денег, но есть сильное желание их заработать. Нам, в свою очередь, хочется сделать меньше и получить больше. Каким-то чудом у нас получается сойтись.
В работе со стартапами ООД помогает разобраться, что является MVP (минимально ценностным продуктом) проекта и в первую очередь сделать только то, что действительно нужно.
MVP — это продукт, который стоит максимально дешево, но уже может приносить пользу конечным пользователям.
Пример очень бюджетного MVP — стартап по продаже обуви Zappos, который невероятно взлетел, привлек много инвестиций и превратился в суперсервис. Но в самом начале у его основателя Ника Свинмерна не было ничего, кроме совсем простого сайта. Он размещал там фотографии обуви из местных магазинов, чтобы понять, есть ли на нее спрос. Когда кто-то делал заказ, Ник покупал эту пару и привозил клиенту. Свинмерн не вкладывался в инфраструктуру и оборудование, но смог создать у клиентов иллюзию полноценного сервиса и с минимальными затратами проверил, востребован ли его продукт.
Исключить хаотичные скачки
Спроектировать все возможные состояния самых сложных страниц, а потом понять, что сайт вообще не нужен — очень обидно. Хочется, чтобы таких ситуаций было меньше, и чтобы команда равномерно двигалась по уровню декомпозиции от большого к малому.
Чтобы не делать лишнюю работу, сначала проектируют объекты и только потом — способы взаимодействия с ними. Пока вы не решили, какие объекты вам нужны и не составили список, не нужно думать о том, что и как с ними делать.