Школа IT-менеджмента АНХ при Правительстве РФ
Опубликован: 11.03.2005 | Доступ: свободный | Студентов: 12270 / 4597 | Оценка: 4.32 / 3.95 | Длительность: 13:56:00

Лекция 1: Современные технологии объектно-ориентированного анализа и проектирования информационных систем

Лекция 1: 123 || Лекция 2 >
Аннотация: Концепции объектно-ориентированного анализа и проектирования. Эволюция и краткая характеристика основных подходов к разработке информационных моделей бизнес-систем и бизнес-процессов. Особенности проектирования, анализа и формализации корпоративных систем. Основные этапы развития языка UML и принятые стандарты. Разработчики графической нотации и специфика ее использования в процессе создания масштабируемых программных систем.
Ключевые слова: информационные технологии, модель, функциональные требования, очередь, абстракция, физическая система, UML, объектно-ориентированный анализ и проектирование, объектно-ориентированное программирование, методология программирования, ООП, объект, декомпозиция, место, класс, программа, наследование, инкапсуляция, полиморфизм, ПО, иерархия, конкретизация, потомок, компьютер, рабочая станция, сервер, информация, пользователь, интерфейс, операции, надежность, программирование, предметная область, база данных, базы данных, object-oriented analysis, computer, software, engineering, CASE, СУБД, визуализация, БД, значение, синтаксис, entity-relationship diagram, ERD, функциональное моделирование, structured analysis, design technique, SADT, data flow diagram, DFD, связь, entity, произвольное, идентификатор, relationship, отношение, ассоциация, кратность, экземпляр сущности, нотация, ARIS, представление, IDEF0, IDEF2, IDEF1X, IDEF, FIPS, processing model, деятельность, activity, диаграмма, диапазон, автор, объектно-ориентированное моделирование, g.lite, OMT, OOS, совместная работа, unified, method, поддержка, OMG, Object, management, group, компонентная технология, CORBA, команда, digital, equipment, IBM, icon, Computing, MCI, Oracle, запрос, RTP, мощность, стандарт языка, ORB, visual, Java, power, Basic, Ada

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

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

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

Модель (model) - абстракция физической системы, рассматриваемая с определенной точки зрения и представленная на некотором языке или в графической форме.

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

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

Методология объектно-ориентированного программирования

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

Объектно-ориентированное программирование (ООП, Object-Oriented Programming) - совокупность принципов, технологий, а также инструментальных средств для создания программных систем на основе архитектуры взаимодействия объектов.

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

Основные принципы ООП: абстракция, наследование, инкапсуляция и полиморфизм.

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

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

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

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

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

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

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

В свою очередь класс "Персональный компьютер" может быть классом-предком для других классов, в частности "Рабочая станция", "Сервер" и "Ноутбук". С этой точки зрения все указанные классы наследуют свойства родительского класса "Персональный компьютер", а возможно и переопределяют некоторые из них. Описанная выше текстовая информация о соотношении классов в данном примере обладает одним серьезным недостатком, а именно, отсутствием наглядности. В этой связи возникает вопрос: а возможно ли представить иерархию наследования классов в визуальной форме? В понятийной логике для изображения понятий используются окружности или прямоугольники. С помощью этой графической нотации, иерархию классов для рассмотренного примера можно представить в виде вложенных прямоугольников или окружностей, каждый из которых соответствует отдельному классу (рис. 1.1).

Иерархия вложенности классов для примера общего класса "Компьютер"

Рис. 1.1. Иерархия вложенности классов для примера общего класса "Компьютер"

Подобное изображение обладает серьезным недостатком. Из представленного рисунка не ясно, изображена ли на нем иерархия понятий или декомпозиция класса "Компьютер" на его составные части. Как будет показано далее, использование нотации UML позволяет устранить данную неопределенность посредством введения в рассмотрение двух различных отношений: обобщения и агрегации (Лекция 6).

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

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

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

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

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

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

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

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

Лекция 1: 123 || Лекция 2 >
Евгений Сеничак
Евгений Сеничак

Здравствуйте!
Текущий курс изучает UML 1.5.
Современные версии UML 2.х. 
Разница существенна. Есть ли курс по более новым версиям UML?

Елена Михеенкова
Елена Михеенкова

В разделе Курсы и разделе Повышение квалификации есть курс Нотация и семантика языка UML. В курсах он бесплатный, а в повышение квалификации стоит 3000 руб. В чем различия?