Файл: ПРИМЕНЕНИЕ ОБЪЕКТНО-ОРИЕНТИРОВАННОГО ПОДХОДА ПРИ ПРОЕКТИРОВАНИИ ИНФОРМАЦИОННОЙ СИСТЕМЫ (CASE системы).pdf

ВВЕДЕНИЕ

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

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

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

1. Визуализировать систему в ее текущем или желаемом для заказчика состоянии.
2. Описать структуру или поведение системы.
3. Получить шаблон позволяет сконструировать систему.
4. Документировать принятые решения, используя полученные модели.

Для построения моделей в процессе проектирования используются специальные графические редакторы и более интеллектуальные CASEсистемы.

Программные пакеты CASE-технологий (Computer Aided System Engineering) - применяются для проектирования любых объектов и систем, диаграмм UML (Unified Modeling Language). Как необходимый элемент системного и структурно-функционального анализа, CASE – средства позволяют моделировать компоненты программного обеспечения, базы данных, деятельности и структуре организаций, их бизнес-процессов.

Применяются практически во всех сферах деятельности.

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

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

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

Задачи курсовой:

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

2. Проанализировать общие понятия объектно-ориентированного проектирования

3. Рассмотреть наиболее распространённые CASE системы, выделить их функции, свойства, возможности, различия.

4. Выполнить проектирование нескольких информационных систем в наиболее перспективных CASE системах проектирования.

ГЛАВА 1. АНАЛИЗ ОБЪЕКТНО-ОРИЕНТИРОВАННГО ПРОЕКТИРОВАНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ

1.1. Общие понятия проектирования информационных систем

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

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

Каждая система может быть описана с разных точек зрения, для чего используются различные модели, каждая из которых является семантически замкнутым абстракцией системы. модель может быть структурной, что подчеркивает организацию системы, или моделью поведения, отражает ее динамику. [2,3,5]

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

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

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

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

Различные точки зрения приводят к созданию различных систем. Мировоззрение разработчика ПО зависит от выбранной модели. Разработчики баз данных (БД) основное внимание уделят UML-моделям «сущность - связь», где поведение инкапсулированная в процедурах сохранения и хранилищах. Аналитик структурного подхода создал бы модель, в центре которой являются алгоритмы и передача данных от одного процесса к другому и тому подобное. Результатом работы разработчика объектно-ориентированной парадигмы проектирования будет система, архитектура которой основана на множестве классов и образцах взаимодействия, определяющие, кооперации этих классов в реализации определенных сценариев. Каждый из этих вариантов может оказаться пригодным для конкретного применения и методики разработки, хотя опыт подсказывает, что объектно-ориентированный точка зрения эффективной при создании гибких архитектур, даже для больших БД или сложных математических расчетов. Различные точки зрения приводят к созданию различных систем со своими преимуществами и недостатками[6].

Принцип 2. Каждая модель может быть представлена с разной степенью точности. Лучшей моделью является та, что позволяет выбрать необходимый уровень детализации ПО. Иногда простая и наскоро созданная модель программного интерфейса является приемлемым вариантом. В других случаях приходится работать на уровне битов (спецификация межсистемных интерфейсов и т.д.). В каждом случае лучшей моделью будет та, которая позволяет выбрать уровень детализации в зависимости от того, кто и с какой целью на нее смотрит. Для аналитика или пользователя наибольший интерес представляет вопрос «что делать», а для разработчика - «как сделать». В обоих случаях необходима возможность рассматривать систему на различных уровнях детализации в разное время. [2,7]

Принцип 3. Лучшие модели те, которые ближе к реальности. При объектно-ориентированном подходе создания ПО можно объединить все почти независимым видом системы в единое семантическое целое. «Ахиллесова пята» структурного анализа - несоответствие принятой в нем модели и модели системного проекта. Если этот разрыв не будет устранен, то поведение созданной системы со временем будет все больше и больше отличаться от задуманного. [1,2,3]

Принцип 4. Нельзя ограничиваться созданием только одной модели. Лучший подход при разработке любой нетривиальной системы - использовать совокупность нескольких моделей, почти независимых друг от друга.

Модели создаются и исследуются отдельно, хотя взаимосвязаны. Здесь ключевым моментом является определение «почти независимые» типы архитектурного понимания ПО.

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

При создании программ можно пользоваться различными стилями программирования. Их выделяют всего пять:

• процедурно-ориентированный – направленный на представление программы как множества поочередно вызываемых процедур;
• объектно-ориентированный – направленный на представление программы как набора взаимодействующих объектов;
• логико-ориентированный – направленный на выполнение целей, выраженных в терминах исчисления предикатов;
• ориентированный на правила – выполнение правил «если-то»;
• ориентированный на ограничения.

Среди основных современных методологий проектирования ИС называют следующие:

• SADT. Методология функционального моделирования работ, которая основана на структурном анализе и графическом представлении организации как системы функций. Тут выделяется функциональная, информационная и динамическая модели. В настоящее время методология известна как нотация (стандарт) IDEF0. Анализируемый процесс графически представляется в виде четырёхугольника, где сверху изображаются регламентирующие и управляющие воздействия, снизу – объекты управления, слева – входные данные, а справа – выходные.
• RAD. Методология быстрой разработки приложений. В RAD быстрая разработка приложений возможна за счёт применения компонентно-ориентированного конструирования. Методология применяется на проектах с ограниченным бюджетом, нечёткими требованиями к ИС, при сжатых сроках реализации. К ней прибегают, если пользовательский интерфейс можно продемонстрировать в прототипе, а проект разделить на функциональные элементы.
• RUP. В методологии RUP реализуются итерационный и наращиваемый (инкрементный) подходы. Построение системы происходит на базе архитектуры информационной системы, а планирование и проектное управление – на базе функциональных требований к ИС. Разработка общей информационной системы происходит итерациями, как комплекс отдельных небольших проектов со своими планами и задачами. Для итерационного цикла характерна периодическая обратная связь и адаптация к ядру ИС.

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

1.2. Объектно-ориентированное проектирование ИС

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