Успешное внедрение CASE-средств должно обеспечить такие выгоды как:

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

· положительное воздействие на некоторые или все из перечисленных факторов: производительность, качество продукции, соблюдение стандартов, документирование;

· приемлемый уровень отдачи от инвестиций в CASE-средства.

 

27. CASE-средства проектирования баз данных

ER-модели широко используются в практике создания БД. Они применяются при ручном и автоматизированном проектировании с использованием CASE-средств, поддерживающих весь цикл разработки СБД или отдельные его стадии. Ктаким средствам относятся: ProKit*WORKBENCH, Design / IDEF, CASE Oracle (Designer / 2000), Power Designer (S-Designor), ERWin, SILVERRUN, ERStudio и другие.

CASE-средства являются сравнительно новым направлением в информационных технологиях. Первая версия инструментария Oracle появилась в 1989 г. поддерживают концептуальное проектирование, позволяют осуществить логическое и физическое проектирование путем автоматической генерации БД для целевой СУБД. Но следует обратить внимание на различия в терминологии. Во многих CASE-системах ER-модель называется логической моделью, а представление логической структуры целевой БД – физической моделью.

 

При сравнении CASE-систем кроме используемой методологии ER-моделирования, необходимо учитывать критерии:

· число и перечень поддерживаемых целевых СУБД;

· поддержку распределенных БД;

· поддержку коллективной работы при проектировании;

· построение концептуальной ER-модели по описанию структуры существующей БД – реверс-инжиниринг;

· автоматизируемые функции проектирования и степень их автоматизации;

· качество и жесткость проектных решений;

· надежность работы;

· документирование проекта;

· открытость системы (возможность стыковки с другими средствами);

· удобство графического редактора;

· количественные ограничения;

· возможность автоматической оценки объема памяти для проектируемой БД;

· возможность автоматической генерации процедур;

· наличие средств моделирования хранилищ данных;

· требования к ресурсам компьютера;

· операционную среду;

· стоимость системы.

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

 

28. CASE-средства моделирования

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

Можно привести следующие причины, побуждающие прибегать к их использованию.

· Изучение методов проектирования.

· Общение с экспертами организации.

· Получение общего представления о системе

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

В то же время практическое внедрение CASE-технологии в организациях-разработчиках ПО связано с рядом проблем. Они достаточно полно изложены в американском стандарте IEEE Std. 1348-1995. Цель приведенных в стандарте рекомендаций — предоставить руководство, позволяющее повысить вероятность успешного внедрения CASE-технологии. Эти рекомендации достаточно актуальны и ценны, поскольку отражают опыт, накопленный многими зарубежными пользователями и разработчиками CASE-средств.

 

29. Сущность объектно-ориентированного подхода к проектированию ИС

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

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

· уменьшение сложности программного обеспечения;

· повышение надежности программного обеспечения;

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

· обеспечение возможности повторного использования отдельных компонентов программного обеспечения.

 

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

· Абстрагирование — это выделение существенных характеристик некоторого объекта, которые отличают его от всех других видов объектов.

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

· Модульность — это свойство системы, связанное с возможностью ее декомпозиции на ряд внутренне связных, но слабо связанных между собой модулей.

· Иерархия — это ранжированная или упорядоченная система абстракций, располагающая их по уровням.

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

· Параллелизм — свойство объектов находиться в активном или пассивном состоянии и различать активные и пассивные объекты между собой.

· Устойчивость — свойство объекта существовать во времени и/или в пространстве.

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

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

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

Цели проведения анализа:

1) Понять проблему или проблемы, которые программная (или иная) система должна решить.

2) Задать значимые вопросы о проблеме и о системе.

3) Обеспечить основу для ответов на вопросы о специфических свойствах проблемы и системы.

4) Определить, что система должна делать.

5) Определить, что система не должна делать.

6) Убедиться, что система удовлетворит потребности ее пользователей и определить критерии ее приемки. Это особенно важно, когда система разработана по контракту для внешнего клиента.

7) Обеспечить основу для разработки системы.

 

Практические требования к процессу анализа и поддерживающей нотации следуют из приведенного списка целей:

· возможность участия в анализе и обсуждении результатов неспециалистов в области ПО;

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

· масштабируемость решения;

· нотация не должна допускать неоднозначного толкования;

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

 

Основные этапы ООА:

- Построение информационной модели, абстрагирование реальных сущностей в терминах объектов и атрибутов.

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

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

 

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

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

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

Таким образом, процесс объектно-ориентированного проектирования состоит из циклического выполнения четырех основных шагов:

- Определение классов и объектов на определенном уровне абстракции.

- Определение семантики классов.

- Определение (идентификация) связей между классами и объектами.

- Реализация классов.

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

 

32. Объектно-ориентированная реализация

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

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