exam08 6 - stankin/design-part-1 GitHub Wiki

Понятия фреймворка и метамодели. Использование фреймворков в качестве CASE-средств.

Реферат к лекции 8 Проектирование программного продукта

Выполнил: Жмуренко Виктор, ИДБ-18-08

Проверила: Жикина Валерия, ИДБ-18-08

Понятия фреймворка и метамодели.

Метамодель (мета – обозначает находящийся вне, за пределами, сверх) — это модель, которая описывает структуру, принципы действия другой модели.

К основным метамоделям распределения данных и управляющей логики можно отнести: MVC, MVP и MVVM

MVC расшифровывается как модель-представление-контроллер (от англ. model-view-controller). Это фундаментальный паттерн, который нашел применение во многих технологиях, дал развитие новым технологиям и каждый день облегчает жизнь разработчикам. MVC предполагает разделение данных приложения, пользовательского интерфейса и управляющей логики на три отдельных компонента: Модель, Представление и Контроллер – таким образом, что модификация каждого компонента может осуществляться независимо.

Контроллер

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

Модель

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

Представление

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

Наиболее распространенные виды MVC-паттерна, это:

  • Model-View-Controller (MVC)
  • Model-View-Presenter (MVP)
  • Model-View-View Model (MVVM)

Model-View-Presenter

Рис. 2.MVP

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

Признаки презентера:

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

Реализация:

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

Пример использования: Windows Forms.

Model-View-View Model

Рис. 3. MVVM

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

Признаки View-модели:

  • Двухсторонняя коммуникация с представлением;
  • View-модель — это абстракция представления. Обычно означает, что свойства представления совпадают со свойствами View-модели / модели
  • View-модель не имеет ссылки на интерфейс представления (IView). Изменение состояния View-модели автоматически изменяет представление и наоборот, поскольку используется механизм связывания данных (Bindings)
  • Один экземпляр View-модели связан с одним отображением.

Реализация:

При использовании этого паттерна, представление не реализует соответствующий интерфейс (IView). Представление должно иметь ссылку на источник данных (DataContex), которым в данном случае является View-модель. Элементы представления связаны (Bind) с соответствующими свойствами и событиями View-модели. В свою очередь, View-модель реализует специальный интерфейс, который используется для автоматического обновления элементов представления. Примером такого интерфейса в WPF может быть INotifyPropertyChanged.

Пример использования: WPF

Model-View-Controller

Рис. 4. MVC

Основная идея этого паттерна в том, что и контроллер, и представление зависят от модели, но модель никак не зависит от этих двух компонент.

Признаки контроллера:

  • Контроллер определяет, какие представление должно быть отображено в данный момент;
  • События представления могут повлиять только на контроллер.контроллер может повлиять на модель и определить другое представление.
  • Возможно несколько представлений только для одного контроллера;

Реализация:

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

Пример использования: MVC ASP.NET

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

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

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

Классификация фреймворков

Рис. 1. Классификация фреймворков

По месту применения:

  • Инфраструктурные фреймворки (System Infrastructure Frameworks) упрощают процесс разработки инфраструктурных элементов, таких как, например операционные системы, применяются внутри организации и не продаются.

  • Фреймворки уровня промежуточного ПО (Middleware Frameworks) применяются для встраивания приложений и компонентов.

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

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

По способу использования:

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

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

  • Наиболее используемые в практике подход – принцип серого ящика (grey box), являющийся комбинацией обоих подходов.

По масштабу применения:

  • Фреймворки уровня приложений (application frameworks) предоставляют функционал по реализации типовых приложений (GUI, базы данных и т.д).

  • Фреймворки уровня домена (Domain Frameworks) применяются для создания приложений в определённой предметной области.

  • Вспомогательные фреймворки (Support Frameworks) применяются для решения частных задач.

Использование фреймворков в качестве CASE-средств.

CASE-средства (Computer - Aided Software Engineering) — это методы и технологии, которые позволяют проектировать различные информационные системы (в частности, базы данных) и автоматизировать их создание.

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

В таком случае, фреймворк состоит из двух знаний:

  1. Работы, которые необходимо совершить, чтобы создать информационную систему.
  2. Сведения об объекте, которые выражаются в виде набора элементов, необходимые для создания информационной системы.

Следовательно, можно сделать вывод, что фреймворк – это динамика, т.е. процесс конфигурирования системы [3]. Определив, что собой представляет фреймворк, рассмотрим требования, предъявляемые к CASE-средству, которое должно проектировать процесс конфигурирования информационной системы (процесс настройки фреймворка). Можно выделить два основных требования: 1.CASE-средство должно описывать процесс, т.е. работы по созданию объекта. 2.CASE-средство должно учитывать содержание данных работ, т.е. свойства объекта.

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

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

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

Ко второму направлению можно отнести CASE-средства, основанные на методологиях управления проектами [4]. Примерами таких CASE-средств являются следующие: SE Companion, Microsoft Project, Open Plan, Primavera Project Planner Enterprise и др. Данные средства позволяют создавать модель работ по созданию объекта.

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

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

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

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

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

После того как спроектированные работы декомпозированы на действия и заполнены содержанием, CASE-средство должно создать информационную систему. Реализация предложенной концептуальной модели CASE-средства позволит решить проблему по проектированию конфигурирования фреймворков (конфигурируемых ИС), и тем самым облегчит работу конечного пользователя по созданию информационной системы для своих нужд.

Список литературы

  1. Литература – «Основы проектирования информационных систем» И.Ю. Коцюба, Чунаев А.В., А.Н. Шиков
  2. Mikko Korpela, Anja Mursu, H.A. Soriyan. Information Systems Development as an Activity, Computer Supported Cooperative Work. – P. 111-128
  3. Vaclav Repa. Methodology Framework for Information Systems Development, CITSA 2004 Conference, Orlando, Florida, July 2004.
  4. CASE-средства. Общая характеристика и классификация [Электронный ресурс] // URL: http://citforum.ru/database/case/glava3_2.shtml.