Сопоставление и взаимосвязь сруктурного и объектно-ориентированного программирования

Термин CASE (Computer Aided Software Engineering) появился в индустрии разработки программного обеспечения в начале 1980-х годов. Довольно быстро он стал обозначать графические средства анализа и проектирования программного обеспечения, отражая надежды и упования создать на основе визуального моделирования универсальный процесс разработки программного обеспечения. Пик развития этих средств приходится на начало 1990-х годов, когда они стали использоваться на базе платформы IBM Mainframe для автоматизации бизнеса крупных компаний. CASE-системы предоставляли мощные средства генерации кода, являясь не только инструментами анализа и проектирования, но и средами разработки программного обеспечения. CASE-средства интегрировали многообразные и разрозненные средства разработки под Mainframe-платформой - инструменты разработки пользовательского интерфейса и баз данных, средства взаимодействия основного приложения с операционной системой и пр. Типичное крупное Mainframe-приложение состояло из тестов примерно на 3-5 разных языках программирования, для которых существовало (и активно использовалось в других приложениях) множество альтернативных вариаций. Одна из самых известных систем такого рода - ADW (Application Developing Workbench). В итоге было разработано много промышленных информационных систем с использованием этих CASE-средств, успешно работающих и по сей день. В результате данные CASE-системы до сих пор поддерживаются и развиваются, чтобы созданные на их основе информационные системы могли успешно функционировать и модернизироваться под современные бизнес-потребности. Почти все подобные CASE-системы и, в частности, ADWб, в настоящее время куплены компанией Computer Associates International.

С середины 1990-х годов, в связи с прекращением распространения Mainframe-платформ, развитие этих CASE-систем прекратилось, и стали появляться CASE-системы для персональных компьютеров. Современные CASE-пакеты не являются комплексными средами разработки, а заняли нишу средств анализа и проектирования, и в основном используются без средств кода генерации, а лишь как инструменты для построения проектных спецификаций.

Предметно-ориентированные (domain-specific) программные инструменты поддержки визуального моделирования предназначены для определенных областей разработки программного обеспечения и тоже могут быть коробочными, как, например, пакет WebRatio для моделирования web-приложений. Однако предметно-ориентированные инструменты могут создаваться и отдельными компаниями для своих собственных проектов, особенно в рамках линеек программных продуктов (product lines). Это особенно удобно, поскольку во-первых, такие средства могут хорошо решать задачи именно того процесса, той компании, для которых они создаются. А во-вторых, сейчас на рынке имеются развитые среды для разработки средств визуального моделирования, самые известные из которых - Microsoft Visio, Microsoft DSL Tools и Eclipse/GMF. Эти и другие пакеты делают задачу создания собственного графического редактора посильной для обычных, рядовых компаний-разработчиков.

 

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

В структурном анализе и проектировании используются различные модели, которые описывают следующие действия:

функциональную структуру системы;

последовательность выполняемых действий;

передачу информации между функциональными процессами;

отношения между данными.

Наиболее распространенными моделями первых трех групп являются:

функциональная модель SADT (Structured Analysis and Design Technique);

модель IDEF3;

DFD (Data Flow Diagrams) - диаграммы потоков  данных.

Метод SADT [17] представляет собой совокупность правил и процедур, предназначенных для построения функциональной модели объекта какой-либо предметной области. Функциональная модель SADT отображает функциональную структуру объекта, т.е. производимые им действия и связи между этими действиями.

Метод SADT разработан Дугласом Россом (SoftTech, Inc.) в 1969 году для моделирования искусственных систем средней сложности. Данный метод успешно использовался в военных, промышленных и коммерческих организациях США для решения широкого круга задач, таких, как долгосрочное и стратегическое планирование, автоматизированное производство и проектирование, разработка программного обеспечения для оборонных систем, управление финансами и материально-техническим снабжением и др. Метод SADT поддерживается Министерством обороны США, которое было инициатором разработки семейства стандартов IDEF (Icam DEFinition), являющегося основной частью программы ICAM (интегрированная компьютеризация производства), проводимой по инициативе ВВС США. Метод SADT реализован в одном стандарте этого семейства - IDEF0, который был утвержден в качестве федерального стандарта США в 1993 г., его подробные спецификации можно найти на сайте http://www.idef.com.

Модели SADT (IDEF0) традиционно используются для моделирования организационных систем (бизнес-процессов). Следует отметить, что метод SADT успешно работает только при описании хорошо специфицированных и стандартизованных бизнес-процессов в зарубежных корпорациях, поэтому он и принят в США в качестве типового метода. Достоинствами применения моделей SADT для описания бизнес-процессов являются:

полнота описания бизнес-процесса (управление, информационные и материальные потоки, обратные связи);

жесткие требования метода, обеспечивающие получение моделей стандартного вида;

соответствие подхода к описанию процессов стандартам ISO 9000.

Метод моделирования IDEF3 [22], являющийся частью семейства стандартов IDEF, был разработан в конце 1980-х годов для закрытого проекта ВВС США. Этот метод предназначен для таких моделей процессов, в которых важно понять последовательность выполнения действий и взаимозависимости между ними. Хотя IDEF3 и не достиг статуса федерального стандарта США, он приобрел широкое распространение среди системных аналитиков как дополнение к методу функционального моделирования IDEF0 (модели IDEF3 могут использоваться для детализации функциональных блоков IDEF0, не имеющих диаграмм декомпозиции). Основой модели IDEF3 служит так называемый сценарий процесса, который выделяет последовательность действий и подпроцессов анализируемой системы.

Диаграммы потоков данных (Data Flow Diagrams - DFD) [6] представляют собой иерархию функциональных процессов, связанных потоками данных. Цель такого представления - продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами.

Для построения DFD традиционно используются две различные нотации, соответствующие методам Йордона-ДеМарко и Гейна-Сэрсона. Эти нотации незначительно отличаются друг от друга графическим изображением символов. В соответствии с данными методами модель системы определяется как иерархия диаграмм потоков данных, описывающих асинхронный процесс преобразования информации от ее ввода в систему до выдачи потребителю. Практически любой класс систем успешно моделируется при помощи DFD-ориентированных методов. Они с самого начала создавались как средство проектирования информационных систем (тогда как SADT - как средство моделирования систем вообще) и имеют более богатый набор элементов, адекватно отражающих специфику таких систем (например, хранилища данных являются прообразами файлов или баз данных, внешние сущности отражают взаимодействие моделируемой системы с внешним миром).

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

Наиболее распространенным средством моделирования данных (предметной области) является модель «сущность-связь»  (Entity-Relationship Model - ERМ) [12]. Она была впервые введена Питером Ченом в 1976 г. Эта модель традиционно используется в структурном анализе и проектировании, однако, по существу, представляет собой подмножество объектной модели предметной области. Одна из разновидностей модели «сущность-связь»  используется в методе IDEF1Х, входящем в семейство стандартов IDEF и реализованном в ряде распространенных CASE-средств (в частности, AllFusion ERwin Data Modeler).

 

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

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

Концептуальной основой объектно-ориентированного анализа и проектирования программного обеспечения является объектная модель. Ее основные принципы (абстрагирование, инкапсуляция, модульность и иерархия) и понятия (объект, класс, атрибут, операция, интерфейс и др.) наиболее четко сформулированы Гради Бучем в его фундаментальной книге [2] и последующих работах.

Большинство современных методов объектно-ориентированного анализа и проектирования [5], [9], [14], [20] основаны на использовании языка UML. Унифицированный язык моделирования UML (Unified Modeling Language) [3], [19], [21] представляет собой язык для определения, представления, проектирования и документирования программных систем, организационно-экономических систем, технических систем и других систем различной природы. UML содержит стандартный набор диаграмм и нотаций самых разнообразных видов.

UML - это преемник того поколения методов объектно-ориентированного анализа и проектирования, которые появились в конце 1980-х и начале 1990-х годов. Создание UML фактически началось в конце 1994 г., когда Гради Буч и Джеймс Рамбо начали работу по объединению их методов Booch и OMT (Object Modeling Technique) под эгидой компании Rational Software. К концу 1995 г. они создали первую спецификацию объединенного метода, названного ими Unified Method, версия 0.8. Тогда же в 1995 году к ним присоединился создатель метода OOSE (Object-Oriented Software Engineering) Ивар Якобсон. Таким образом, UML является прямым объединением и унификацией методов Буча, Рамбо и Якобсона, однако дополняет их новыми возможностями. Главными в разработке UML были следующие цели:

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

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

обеспечить независимость от конкретных языков программирования и процессов разработки;

обеспечить формальную основу для понимания этого языка моделирования (язык должен быть одновременно точным и доступным для понимания, без лишнего формализма);

стимулировать рост рынка объектно-ориентированных инструментальных средств;

интегрировать лучший практический опыт.

UML находится в процессе стандартизации, проводимом OMG (Object Management Group) - организацией  по стандартизации в области  объектно-ориентированных методов  и технологий, в настоящее время принят в качестве стандартного языка моделирования и получил широкую поддержку в индустрии ПО. UML принят на вооружение практически всеми крупнейшими компаниями - производителями программного обеспечения (Microsoft, Oracle, IBM, Hewlett-Packard, Sybase и др.). Кроме того, практически все мировые производители CASE-средств, помимо IBM Rational Software, поддерживают UML в своих продуктах (Oracle Designer, Together Control Center (Borland), AllFusion Component Modeler (Computer Associates), Microsoft Visual Modeler и др.). Полное описание UML можно найти на сайтах http://www.omg.org и http://www.rational.com.

Стандарт UML версии 1.1, принятый OMG в 1997 году, содержит следующий набор диаграмм:

Структурные (structural) модели:

диаграммы классов (class diagrams) - для моделирования статической структуры классов системы и связей между ними;

диаграммы компонентов (component diagrams) - для моделирования иерархии компонентов (подсистем) системы;

диаграммы размещения (deployment diagrams) - для моделирования физической архитектуры системы.

Модели поведения (behavioral):

диаграммы вариантов использования (use case diagrams) - для моделирования функциональных требований к системе (в виде сценариев взаимодействия пользователей с системой);

диаграммы взаимодействия (interaction diagrams):

диаграммы последовательности (sequence diagrams) и кооперативные диаграммы (collaboration diagrams) - для моделирования процесса обмена сообщениями между объектами;

диаграммы состояний (statechart diagrams) - для моделирования поведения объектов системы при переходе из одного состояния в другое;

диаграммы деятельности (activity diagrams) - для моделирования поведения системы в рамках различных вариантов использования, или потоков управления.

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

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

Диаграмма вариантов использования является самым общим представлением функциональных требований к системе. Для последующего проектирования системы требуются более конкретные детали, которые описываются в документе, называемом «сценарием варианта использования» или «потоком событий» (flow of events). Сценарий подробно документирует процесс взаимодействия действующего лица с системой, реализуемого в рамках варианта использования [11]. Основной поток событий описывает нормальный ход событий (при отсутствии ошибок). Альтернативные потоки описывают отклонения от нормального хода событий (ошибочные ситуации) и их обработку.