exam07 2 - stankin/design-part-1 GitHub Wiki

Структурный и объектно-ориентированный подходы к проектированию в CASE-технологиях

Реферат к лекции 7. Понятия инженерии, CASE, проектирования.

Выполнил: Щепетильников Даниил, ИДБ-18-08

Проверила: Трунина Полина, ИДБ-18-08

Структурный подход

Определение

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

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

  • принцип "разделяй и властвуй" - принцип решения сложных проблем путем их разбиения на множество меньших независимых задач, легких для понимания и решения;
  • принцип иерархического упорядочивания - принцип организации составных частей проблемы в иерархические древовидные структуры с добавлением новых деталей на каждом уровне.

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

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

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

  • SADT (Structured Analysis and Design Technique);
  • DFD (Data Flow Diagrams);
  • ERD (Entity-Relationship Diagrams).

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

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

SADT

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

  • графическое представление блочного моделирования. Графика блоков и дуг SADT-диаграммы отображает функцию в виде блока, а интерфейсы входа/выхода представляются дугами, соответственно входящими в блок и выходящими из него. Взаимодействие блоков друг с другом описываются посредством интерфейсных дуг, выражающих "ограничения", которые в свою очередь определяют, когда и каким образом функции выполняются и управляются;
  • строгость и точность. Выполнение правил SADT требует достаточной строгости и точности, не накладывая в то же время чрезмерных ограничений на действия аналитика. Правила SADT включают:
  • ограничение количества блоков на каждом уровне декомпозиции (правило 3-6 блоков);
  • связность диаграмм (номера блоков);
  • уникальность меток и наименований (отсутствие повторяющихся имен);
  • синтаксические правила для графики (блоков и дуг);
  • разделение входов и управлений (правило определения роли данных).
  • отделение организации от функции, то есть исключение влияния организационной структуры на функциональную модель.

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

DFD

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

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

  • внешние сущности;
  • системы или подсистемы;
  • процессы;
  • накопители данных;
  • потоки данных.

ERD

Наиболее распространенным средством моделирования данных являются диаграммы "сущность-связь", также известные как ERD. С их помощью определяются важные для предметной области сущности, их атрибуты и связи друг с другом. ERD непосредственно используются для проектирования реляционных баз данных.

Нотация ERD была впервые введена П. Ченом и получила дальнейшее развитие в работах Баркера. Метод Баркера будет излагаться на примере моделирования деятельности компании по торговле автомобилями. Ниже приведены выдержки из интервью, проведенного с персоналом компании.

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

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

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

Первый шаг моделирования - извлечение информации из интервью и выделение сущностей.

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

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

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

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

Следующим шагом моделирования является идентификация связей.

Связь (Relationship) - поименованная ассоциация между двумя сущностями, значимая для рассматриваемой предметной области. Связь - это ассоциация между сущностями, при которой, как правило, каждый экземпляр одной сущности, называемой родительской сущностью, ассоциирован с произвольным (в том числе нулевым) количеством экземпляров второй сущности, называемой сущностью-потомком, а каждый экземпляр сущности-потомка ассоциирован в точности с одним экземпляром сущности-родителя. Таким образом, экземпляр сущности-потомка может существовать только при существовании сущности родителя.

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

Например, связь продавца с контрактом может быть выражена следующим образом:

  • продавец может получить вознаграждение за 1 или более контрактов;
  • контракт должен быть инициирован ровно одним продавцом.

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

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

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

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

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

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

Помимо перечисленных основных конструкций модель данных может содержать ряд дополнительных:

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

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

Определение

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

UML

Унифицированный язык моделирования (UML, Unified Modelling Language) - набор техник построения диаграмм, специально разработанные для объектно-ориентированной разработки, и ставшие промышленным стандартом для описания объектно-ориентированных систем. UML сформировался в работах Джеймса Рамбо, Гради Буча и Ивара Якобсона.

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

Создатели UML, Гради Буч и другие, предложили рассматривать архитектуру системы с пяти разных точек зрения:

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

Данный способ проектирования ИС также известен как "Модель 4 + 1". Особое значение среди перечисленных представлений имеет представление вариантов использования. Данное представление системы также является представлением для пользователя, оно описывает, что пользователь желает делать, работая с системой, и оно описывает поведение системы при этом.

Модель 4 + 1 даёт нам пять разных способов рассмотрения системы, поддерживаемых UML для визуализации каждого представления. Подобно тому, как фотография, генеалогическое древо и краткая биография дают нам разные взгляды на человека, представления UML показывают нам систему с разных точек зрения. Каждое предоставляет уникальную точку зрения, но ни одно из них не дает всей картины. Чтобы получить полное представление о системе, необходимо рассмотреть все точки зрения в совокупности.

Одним из преимуществ стандартизированного языка для построения диаграмм является то, что был разработан ряд CASE-инструментов для автоматизированной помощи разработчикам.

Теоретически CASE-инструментом может быть любая простая программа для рисования или отладки, но сегодня почти все CASE-инструменты охватывают весь жизненный цикл системы и обеспечивают автоматическую поддержку всех действий во время разработки, как технических, так и управленческих. Для объектно-ориентированных систем такие инструменты, как Rational RoseTM и TogetherTM, позволяют разработчикам создавать UML-модели системы, которые являются синтаксически правильными, согласованными друг с другом и которые могут быть усовершенствованы и использованы для создания исполняемого кода.

❌ Бедноватый набор известных CASE-технологий, о них же речь в вопросе. И какие из них настолько хорошо известны практически (не понаслышке), что их можно посоветовать применять в работе (хотя бы в ВКР)?

Ссылки