Лекции по проектировании информационных систем для студентов, обучающихся по специальности «Прикладная информатика в экономике»


ФУНКЦИОНАЛЬНО-ОРИЕНТИРОВАННОЕ И ОБЪЕКТНО- ОРИЕНТИРОВАННОЕ ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННЫХ СИСТЕМ



бет20/31
Дата18.10.2022
өлшемі0.58 Mb.
#462896
түріЛекции
1   ...   16   17   18   19   20   21   22   23   ...   31
doc 165

ФУНКЦИОНАЛЬНО-ОРИЕНТИРОВАННОЕ И ОБЪЕКТНО- ОРИЕНТИРОВАННОЕ ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННЫХ СИСТЕМ




ФУНКЦИОНАЛЬНО-ОРИЕНТИРОВАННОЕ ПРОЕКТИРОВАНИЕ

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



  1. декомпозиция всей системы на некоторое множество иерархически подчиненных функций;

  2. представление всей информации в виде графической нотации.

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


Несомненным достоинством функциональных моделей является реализация структурного подхода к проектированию ЭИС по принципу «сверху-вниз», когда каждый функциональный блок может быть декомпозирован на множество подфункций и т.д., выполняя, таким образом, модульное проектирование ЭИС. Для функциональных моделей характерны процедурная строгость декомпозиции ЭИС и наглядность представления.

Как видно из рис. 7.2, одной из функций аналитического учета товаров на складе является организация товародвижения. Далее эта функция декомпозируется на следующие подфункции:



    • приемка товара;

    • отпуск товара;

    • ведение БД «Движение товаров»;

    • инвентарный контроль.

Рис. 7.2. Фрагмент диаграммы иерархии функций для задачи аналитического учета товаров на складе


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

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


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

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


Для более регламентированных задач больше подходят функциональные модели, для более адаптивных бизнес-процессов (управления рабочими потоками, реализации динамических запросов к информационным хранилищам) – объектно- ориентированные модели.
Однако в рамках одной и той же ЭИС для различных классов задач могут требоваться различные виды моделей, описывающих одну и ту же проблемную область. В таком случае должны использоваться комбинированные модели проблемной области. В полной мере комбинированный подход к моделированию проблемной области еализован в инструментальном средстве ARIS-Toolset (Architecture of Integrated Information Systems), содержащем множество различных методологий, соответствующих различным взглядам на проектируемую систему: объекты, функции, организационная структура.


ОБЪЕКТНО-ОРИЕНТИРОВАННОЕ ПРОЕКТИРОВАНИЕ

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


В связи с этим система объектно-ориентированных моделей последовательно разворачивается по направлению от модели общего представления функциональности ИС к модели динамического взаимодействия объектов, на основе которой могут быть сгенерированы классы объектов в конкретной программно-технической среде.
В настоящее время для объектно-ориентированного моделирования проблемной области широко используется унифицированный язык моделирования UML (Unified Modeling Language), который разработан группой ведущих компьютерных фирм мира OMG (Object Management Group) и фактически является стандартом по объектно-ориентированным технологиям.
Язык UML реализован многими фирмами-производителями программного обеспечения в рамках CASE-технологий, например Rational Rose (Rational), Natural Engineering Workbench (Software AG), ARIS Toolset (IDS prof. Scheer) и др.


Система объектно-ориентированных моделей в соответствии с нотациями UML включает в себя следующие диаграммы:

  1. диаграмму прецедентов использования (Use-case diagram), которая отображает функциональность ЭИС в виде совокупности выполняющихся последовательностей транзакций;

  2. диаграмму классов объектов (Class diagram), которая отображает структуру совокупности взаимосвязанных классов объектов функционально-ориентированного подхода;

  3. диаграммы состояний (Statechart diagram), каждая из которых отображает динамику состояний объектов одного класса и связанных с ними событий;

  4. диаграммы взаимодействия объектов (Interaction diagram), каждая из которых отображает динамическое взаимодействие объектов в рамках одного прецедента использования;

  5. диаграммы деятельностей (Activity diagram), которые отображают потоки работ во взаимосвязанных прецедентах использования (могут декомпозироваться на более детальные диаграммы);

  6. диаграммы пакетов (Package diagram), которые отображают распределение объектов по функциональным или обеспечивающим подсистемам (могут декомпозироваться на более детальные диаграммы);

  7. диаграмму компонентов (Component diagram), которая отображает физические модули программного кода;

  8. диаграмму размещения (Deployment diagram), которая отображает распределение объектов по узлам вычислительной сети.



Диаграмма прецедентов использования

Диаграммы использования описывают функциональность ИС, которая будет видна пользователям системы. «Каждая функциональность» изображается в виде
«прецедентов использования» (use case) или просто прецедентов.
Прецедент - это типичное взаимодействие пользователя с системой, которое при этом:

    1. описывает видимую пользователем функцию,

    2. может представлять различные уровни детализации,

    3. обеспечивает достижение конкретной цели, важной для пользователя.

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



Рис. 11.4. Связи на диаграммах прецедентов

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


Диаграммы классов объектов (Class diagram)

Диаграммы классов объектов (Class diagram) отображают статическую структуру классов объектов. Эта диаграмма рассматривает внутреннюю структуру проблемной области, иерархию классов объектов, статические связи объектов.


На Рис. 11.1 приведено графическое изображение класса «Заказ» в нотации UML.

Рис. 11.1. Изображение класса в UML


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

Между классами возможны различные отношения (Рис. 11.2):





  1. зависимости, которые описывают существующие между классами отношения использования;

  2. обобщения, связывающие обобщенные классы со специализированными;

  3. ассоциации, отражающие структурные отношения между объектами классов.

Рис. 11.2. Отображение связей между классами


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


    1. Достарыңызбен бөлісу:
1   ...   16   17   18   19   20   21   22   23   ...   31




©dereksiz.org 2024
әкімшілігінің қараңыз

    Басты бет