模型视图结构

Qt之模型/视图

(2014-01-08 15:48:01)

转载▼

标签：

分类：Qt

qt

qt使用mvc

qtableview

qlistview

qtreeview

关于Qt中MVC的介绍与使用，助手中有一节模型/视图编程

（Model/View Programming）讲解的很清晰。

Qt包含一组使用模型/视图结构的类，可以用来管理数据并呈现给用户。这种体系结构引入的分离使开发人员更灵活地定制项目，并且提供了一个标准模型的接口，以允许广泛范围的数据源被使用到到现有的视图中。

模型- 视图- 控制器（MVC）是一种设计模式，由三类对象组成：

?模型：应用程序对象。

?视图：屏幕演示。

?控制器：定义了用户界面响应用户输入的方式。

在引入MVC之前，用户界面的设计往往是将这些对象组合在一起。MVC 的解耦带来了灵活性和重用性。

如果视图和控制器对象相结合，其结果是模型/视图结构，仍然分离了数据与呈现给用户的方式，但提供了基于相同原理的简单框架。这种分离使得它可以在几个不同的视图中显示相同的数据，并且实现新类型的视图，

而无需改变底层的数据结构。为了灵活地处理用户输入，则引入了委托的概念。在此框架引入委托的优点是：它允许项目数据显示和自定义编辑。

模型/视图结构

模型与数据源进行通信，在这个体系结构中为其它组件提供了一个接口。通信的性质依赖于数据源的类型以及模型的实现方式。

视图从模型中得到模型索引，这些都引用到数据项。通过为模型提供模型索引，视图可以从数据源中检索数据项。

在标准的视图里，委托呈现数据项目。当一个项目被编辑，委托与模型直接利用模型索引进行通信。

模型/视图/委托通信

模型、视图、委托使用信号和槽相互通信：

?模型的信号：通知视图关于改变由数据源保持的数据。

?视图的信号：提供了关于用户交互显示的项目信息。

?委托的信号：当编辑时告诉模型和视图编辑器的状态。

模型

所有的模型都基于QAbstractItemModel类。这个类定义了一个使用视图和委托来访问数据的接口。数据本身不是必须要存储在模型中，可以在一个数据结构或一个单独的类、文件、数据库、或其它一些应用组件。

QAbstractItemModel为数据提供了一个接口，它足够的灵活性来处理表格、列表、树形式的数据视图。然而，实现新的列表和类似于表的数据结构模型时，QAbstractListModel和QAbstractTableModel类是更好的起点，因为它们提供了适当的常用的功能的默认实现。这些类可以派生子类，用来提供支持特定种类的列表和表格的模型。

Qt提供了一些现成的模型，可以用来处理数据项：

?QStringListModel：用于存储简单的QString的列表项。

?QStandardItemModel：管理更复杂的树结构件，其中每一个项目可以包含任意数据。

?QFileSystemModel：提供有关本地文件系统的文件和目录信息。

?QSqlQueryModel、QSqlTableModel、QSqlRelationalTableModel：使用模型/视图约定来访问数据库。

如果这些标准模型不能满足要求，则可以继承化QAbstractItemModel、QAbstractListModel或QAbstractTableModel来创建自定义模型。

视图

提供了完整的实现为各种不同的视图：而QListView显示项目列表，QTableView中从一个表模型中显示数据，QTreeView则显示了层次列表的

数据模型项目。每个类是基于QAbstractItemView抽象基类。虽然这些类是准备使用的实现，他们也可以被子类化，以提供自定义的视图。

委托

QAbstractItemDelegate在模型/视图框架中代表抽象的基类。默认的委托实现由QStyledItemDelegate提供，这被Qt的标准视图用作默认的委托。然而，QStyledItemDelegate和QItemDelegate独立替代绘画，且为视图项提供编辑器。它们之间的区别在于QStyledItemDelegate使用当前样式来绘制项目。因此，建议实现自定义委托或当与Qt样式表一起使用时，使用QStyledItemDelegate作为基类。

排序

在模型/视图结构中有两种接近的排序方式，选择哪种方式取决于你的基础模型。

如果你的模型是可排序的，也就是说，如果重新实现了QAbstractItemModel::sort()方法，QTableView和QTreeView都提供了一个API，允许以编程方式排序来排序模型数据。此外，可以启用交互式排序（即允许用户将数据通过单击视图的标题进行排序），由QHeaderView::sortIndicatorChanged()信号分别连接到QTableView:: sortByColumn()槽或QTreeView::sortByColumn()槽。

另一种方法，如果模型没有所需的接口，或者如果想使用一个列表视图来显示数据，使用代理模型呈现数据视图之前应转换模型的结构。

方便的类

一些便利类都源于标准视图类的依赖Qt的项目为基础的项目视图和表类应用的好处。他们不打算被继承。

这些类的实例包括QListWidget，QTreeWidget和QTableWidget。

这些类比视图类灵活性差，且不能与任意的模型使用。建议使用模型/视图的方法来处理在项目视图中的数据，除非强烈需要一个基于项目的类。

如果想利用模型/视图提供的特性方法，同时使用一个基于项目的接口，可以考虑使用视图类，例如：QListView、QTableView、QTreeView与QStandardItemModel。

使用视图与现有的模型

QListView和QTreeView类是最合适的视图来使用QFileSystemModel。下面介绍的示例在树视图中显示一个目录，旁边列表视图中显示相同的信息。该视图共享用户的选择，这样选择的项目在两个视图中高亮显示。

代码如下：

int main(int argc,char*argv[])

{

QApplication app(argc,argv);

QSplitter*splitter=new QSplitter;

QFileSystemModel*model=new QFileSystemModel;

model->setRootPath(QDir::currentPath());

QTreeView*tree=new QTreeView(splitter);

tree->setModel(model);

tree->setRootIndex(model->index(QDir::currentPath()));

QListView*list=new QListView(splitter);

list->setModel(model);

list->setRootIndex(model->index(QDir::currentPath()));

splitter->setWindowTitle("Two views onto the same file system mod el");

splitter->show();

return app.exec();

}

上面的例子中，我们忽略提及如何处理选择的项目。下面将详细讲述在视图中处理所选的项目。

基本概念

在模型/视图结构中，模型提供了视图与委托访问数据的标准接口。在Qt 中，标准的接口由QAbstractItemModel类定义。无论多么数据项被存储在任何底层的数据结构中，QAbstractItemModel的所有子类所代表的数据作为包含视图项的分层结构。视图使用这个约定来访问模型中的数据项，但并不限制将该信息传达给用户的方式。

Model indexes

为确保数据被分开被访问，模型索引的概念被引入。可以通过模型索引来获得每条信息。视图与委托使用这些索引来请求显示的数据项。

因此，模型只需要知道如何获取数据，并通过模型管理的数据的类型可以被相当普遍定义。型号索引包含一个指向创建它们的模型的指针，在处理多个模型时可以防止混乱。

QAbstractItemModel*model=index.model();

模型索引提供临时参考信息，并且可以用于通过模型来检索或修改数据。由于模型可能重组其内部结构，模型的索引可能会变得无效，不宜存储。如果需要长期参考一条信息，必须创建一个持久性模型索引。这为模型保持最新信息提供了一个参考。临时模型索引由QModelIndex类提供，持久性模型索引由QPersistentModelIndex类提供。

取得对应于数据项的模型索引，模型中必须制定三个属性：一个行号、一个列号，以及父项的模型索引。

行和列

在最基本的形式中，模型可以被一个简单的表访问，表项位于行号和列号，这并不意味着底层数据存储在数据结构中，使用行号和列号只是一个惯例，以允许组件相互通信。我们可以通过指定行号和列号的模型索引有关的任何特定信息，通过下面的方式得到项目的索引：

QModelIndex index=model->index(row,column,...);

模型提供的接口简单，单级的数据结构如列表和表格不需要提供任何其他信息。但是，正如上面的代码所示，当获得一个模型索引时，我们需要提供更多的信息。

行和列

图中显示了一个基本的表模型，其中的每个项目的位置由一对行号和列号表示。我们通过模型索引（一个项目数据）行号和列号来获取。

QModelIndex indexA=model->index(0,0,QModelIndex());

QModelIndex indexB=model->index(1,1,QModelIndex());

QModelIndex indexC=model->index(2,1,QModelIndex());

父节点

由模型提供的类似于表的接口给数据项是理想的当在表格或列表视图中使用数据，行号和列号准确地映射到视图显示项目的方式。然而，结构，如树视图需要更模型为项目暴露一个更灵活的接口。因此，每个项目也可以是另一个表的父项，大致相同的方式，在一个树视图中的顶级项目可以包含另一个列表项。

当请求的一个模型项的索引时，必须提供有关该项目的父项目的一些信息。在模型外，指定一个项目的唯一途径是通过一个模型索引，所以父模型索引也必须如下给出：

QModelIndex index=model->index(row,column,parent);

父项，行和列

该图显示了一个树模型，其中每个项目都依赖于由一个父项，一个行号和一个列号。

项目的“A”和“C”表示模型顶层的兄弟姐妹：

项目“A”有很多孩子，可以通过如下方式由“A”索引得到“B”索引： QModelIndex indexB=model->index(1,0,indexA);

QModelIndex indexA=model->index(0,0,QModelIndex());

QModelIndex indexC=model->index(2,1,QModelIndex());

项目角色

模型中的项目可以为其他组件演绎不同的角色，允许为不同的情况提供不同类型的数据。例如，Qt::DisplayRole可以在用于访问视图中被显示为文本的字符串。通常情况下，包含数据的项目用于若干不同的角色，且标准角色被Qt::ItemDataRole定义。

我们可以通过模型索引传递给相应的项目向模型请求项目数据，并通过指定一个角色来获取想要的数据类型，如下：

QVariant value=model->data(index,role);

数据类型被称为模型的角色指示器。视图可以以不同的方式显示角色，因此，为每个角色提供相应的信息非常重要。

项目数据最常见的用途是覆盖在Qt::ItemDataRole中定义的标准角色。通过为每个角色提供相应的项目数据，模型可以为视图和委托提供有关项目应如何呈现给用户的指示，不同的视图可以根据需要来解释或忽略此信息。此外，也可以为应用程序的特定目的而定义附加的角色。

使用模型索引

为了演示如何将数据从一个模型中进行检索，使用模型索引，我们创建了一个QFileSystemModel，在窗体上没有视图以及显示文件和目录的名称。虽然这并不是使用模型的正常方式，它表明模型在处理模型索引上的约定。

我们用以下述方式构建了一个文件系统模型：

QFileSystemModel*model=new QFileSystemModel;

QModelIndex parentIndex=model->index(QDir::currentPath());

int numRows=model->rowCount(parentIndex);

在这种情况下，我们设置了一个默认QFileSystemModel，由该模型使用index()的特定实现来获取父索引，使用rowCount()函数来计算行号。

为简单起见，我们只关心模型中的第一列中的项目。我们检查每一行，依次获取每一行中的第一个项目的模型索引，以及读出所存储在该模型项目中的数据。

for(int row=0;row<

numRows;++row){

QModelIndex index=model->index(row,0,parentIndex);

为了获得一个模型索引，我们指定了行号、列号（第一列为零），以及所有我们想要的项目的父项目的模型索引。每个项目中的文本检索可以使用模型的

data()函数来获取。我们指定了模型索引和Qt::DisplayRole来获取数据项中的字符串。

QString text=model->data(index,Qt::DisplayRole).toString() ;

//Display the text in a widget.

}

使用模型

我们创建一个字符串列表模型作为例子，设置一些数据，并构造一个视图来显示模型的内容。这都可以在一个单一的函数执行：

int main(int argc,char*argv[])

{

QApplication app(argc,argv);

QStringList numbers;

numbers<<"One"<<"Two"<<"Three"<<"Four"<<"Five";

请注意，QStringListModel被声明为一个QAbstractItemModel。这使我们能够为模型使用抽象接口，并确保代码仍然有效，即使我们使用不同的模型替换了字符串列表模型。

由而QListView提供的列表视图足以展示字符串列表模型中的项目。我们构建视图，并设置模型可以使用下面代码：

QAbstractItemModel*model=new QStringListModel(numbers);

QListView*view=new QListView;

view->setModel(model);

视图正常显示方式

view->show();

return app.exec();

}

视图展现模型的内容，通过模型的接口访问数据。当用户试图编辑一个项目时，视图使用缺省代表提供一个编辑器部件。

上面的图显示QListView如何使用字符串列表模型表示数据。由于模型可编辑，视图会自动允许列表中的每个项目使用默认的委托进行编辑。

一个模型的多个视图

一个模型可以为多个视图所使用。在下面的代码中，我们创建两个表视图，使用的均是创建好的同一个模型。

QTableView*firstTableView=new QTableView;

QTableView*secondTableView=new QTableView;

firstTableView->setModel(model);

secondTableView->setModel(model);

在模型/视图框架中使用信号和槽是指更改模型可以传递给所有相连的视图，以确保始终可以访问相同的数据，而不管所使用的视图。

上面的图显示了统一模型的两种不同的视图，每个都包含了一些选定的项目。尽管模型中的数据在视图显示一致，每个视图维护它自己的内部选择模型。这在某些情况下有用，但对于许多应用来说，则需要一个共享的选择模型。

视图共享选择

虽然视图类提供自己的默认选择模型很方便，但当我们使用多个视图到同一个模型时，通常需要所有的模型数据和用户的选择在所有视图显示一致。由于视图类允许其内部选择模型进行更换，那么可以使用如下方式实现视图之间的统一：

secondTableView->setSelectionModel(firstTableView->selectionModel ());

第二个视图给出了第一个视图的选择模型。这两种视图现在在同一个选择模型进行操作，保持了数据和所选项目的同步。

Qt之模型/视图（委托）

(2014-01-09 13:58:09)

转载▼

分类：Qt

标签：

qt

qt委托

qlistview委托

qtableview委托

qtreeview委托

概念

不同于模型- 视图- 控制器模式，模型/视图设计不包括用于管理与用户交互的一个完全独立的组件。一般情况，视图负责将模型数据呈现给用户以及处理用户输入。为了输入更加具有灵活性，则由委托来执行交互。这些组件提供输入功能，且在一些视图中还负责渲染个别项目。控制委托的标准接口在QAbstractItemDelegate类中定义。

委托能够通过实现的paint()和sizeHint()函数来展示它们的内容。然而，简单基础部件的委托可以继承QItemDelegate而不是QAbstractItemDelegate，并使用这些函数的默认实现。

委托编辑器可以通过使用小工具来管理编辑过程或直接处理事件来实现。

使用现有委托

Qt提供的标准视图中使用QItemDelegate提供编辑功能。委托接口的默认实现以一贯风格来呈现项目为每个标准视图：QListView、QTableView、QTreeView。

所有标准角色由所使用的标准视图中的默认委托处理。

视图使用委托是由itemDelegate()函数返回。setItemDelegate()函数允许你为标准视图设定一个自定义委托，为自定义视图设定委托时，有必要使用此功能。

一个简单的委托

这里实现的委托使用QSpinBox来提供编辑功能，主要用于模型处理整数。虽然为了这个目的我们设置了一个自定义的基于整数的表模型，我们可以很容易地使用QStandardItemModel来代替，因为自定义委托控制数据输入。我们构造了一个表视图来显示模型的内容，可以使用自定义的委托来进行编辑。

我们的委托继承于QItemDelegate，因为我们不想编写自定义显示功能。然而，仍然必须提供管理编辑器窗口小部件的功能：

class SpinBoxDelegate:public QStyledItemDelegate

{

Q_OBJECT

public:

SpinBoxDelegate(QObject*parent=0);

QWidget*createEditor(QWidget*parent,const QStyleOptionViewItem&op tion,

const QModelIndex&index)const;

void setEditorData(QWidget*editor,const QModelIndex&index)const; void setModelData(QWidget*editor,QAbstractItemModel*model,

const QModelIndex&index)const;

void updateEditorGeometry(QWidget*editor,

const QStyleOptionViewItem&option,const QModelIndex&index)const; };

提供了一个编辑器

在这个例子中，当表视图需要提供一个编辑器时，它将要求委托提供一个编辑器部件适用于修改该项目。createEditor()函数提供一切，委托需要能够建立一个合适的窗口小部件：

QWidget*SpinBoxDelegate::createEditor(QWidget*parent,

const QStyleOptionViewItem&,

const QModelIndex&)const

{

QSpinBox*editor=new QSpinBox(parent);

editor->setFrame(false);

editor->setMinimum(0);

editor->setMaximum(100);

return editor; }

注意，我们不需要一个指向编辑器的部件，因为当不再需要时，视图负责销毁它。

在编辑器上安装代理的默认事件过滤器，以确保它提供了用户所期望的标准编辑快捷方式。编辑器中可以添加额外的快捷键，以允许更复杂的行为。

可以根据视图提供的模型索引创建不同的编辑器。例如，如果有一个整数列和字符串列，我们可以返回一个QSpinBox或QLineEdit，这取决于哪一列正在被编辑。

委托必须提供一个函数将模型中的数据复制到编辑器中。在这个例子中，我们读出存储在显示角色中的数据，并在QSpinBox中设置的值相应。

void SpinBoxDelegate::setEditorData(QWidget*editor,

const QModelIndex&index)const

{

int value=index.model()->data(index,Qt::EditRole).toInt();

QSpinBox*spinBox=static_cast<QSpinBox*>(editor);

spinBox->setValue(value);

}

在这个例子中，我们知道编辑器部件是一个QSpinBox，但可以为模型中不同类型的数据提供不同的编辑器，在这种情况下，则需要在访问它的成员函数之前设置部件为适当的类型。

void SpinBoxDelegate::setModelData(QWidget*editor,QAbstractItemMode l*model,

const QModelIndex&index)const

{

QSpinBox*spinBox=static_cast<QSpinBox*>(editor);

spinBox->interpretText();

int value=spinBox->value();

model->setData(index,value,Qt::EditRole);

}

由于视图为委托管理编辑器部件，所以只需要以编辑器提供的内容来更新模型。在这种情况下，我们确QSpinBox是最新更新，并使用指定的索引包含的值来更新模型。

标准的QItemDelegate类通过发射closeEditor()信号来完成编辑视图。视图可确保编辑器部件被关闭和销毁。在这个例子中，我们只提供简单的编辑功能，所以我们需要永远不会发出这个信号。

所有的数据操作通过QAbstractItemModel提供的接口执行。这使得委托大多独立于它操纵的数据的类型，但为了使用某些类型的编辑器部件，则必须做出一些假设。在这个例子中，我们假设模型总是包含整数值，但我们仍然在不同类型的模型中使用此委托，因为的QVariant为意想不到的数据提供了合理的默认值。

更新编辑器的几何形状

管理编辑器的几何形状是委托的责任。当编辑器被创建，或者当项目视图的的位置、大小在视图中改变时，几何形状必须被设置。幸运的是，视图提供了视图选项物体内部所有必要的几何信息。

void SpinBoxDelegate::updateEditorGeometry(QWidget*editor, const QStyleOptionViewItem&option,const QModelIndex&)const {

editor->setGeometry(option.rect);

}

这种情况下，我们仅在项目区域中使用视图选项提供的位置信息。使用一些元素展现项目的委托不会直接使用该项目矩形。根据这个项目中的其他元素来设定编辑器的位置。

int main(int argc,char*argv[])

{

QApplication app(argc,argv);

QStandardItemModel model(4,2);

QTableView tableView;

tableView.setModel(&model);

SpinBoxDelegate delegate;

tableView.setItemDelegate(&delegate);

tableView.horizontalHeader()->setStretchLastSection(true);

for(int row=0;row< 4;++row){

for(int column=0;column< 2;++column){

QModelIndex index=model.index(row,column,QModelIndex()); model.setData(index,QVariant((row+1)*(column+1)));

}

}

tableView.setWindowTitle(QObject::tr("Spin Box Delegate"));

tableView.show();

return app.exec();

}

Qt之模型/视图（实时更新数据）

(2014-01-09 15:59:48)

转载▼

分类：Qt

标签：

qt

mvc

模型/视图

qt进度条

it

上两节简单介绍了Qt中对于模型/视图的编程，大部分助手里说的很清楚了，现在就开始实战部分吧！

在实际应用中，视图展示的数据往往并非一成不变的，那么如何实时更新成了一个很重要的问题！

功能：

（1）添加委托（进度条）

（2）显示文件名称、大小、进度、速度、剩余时间、状态等。

（3）可进行添加、更新、删除、清空等操作。

（4）实时更新数据

先看一个效果图：

委托（进度条）：

ProgressBarDelegate::ProgressBarDelegate(QObject *parent)

: QItemDelegate(parent)

{

}

void ProgressBarDelegate::paint(QPainter* painter, const QStyleOptionViewItem& option, const QModelIndex& index) const {

if(index.column() == 2)

{

int progress = index.model ()->data(index, Qt::DisplayRole).toInt (); QStyleOptionProgressBarV2 progressBarOption;

progressBarOption.state = QStyle:: State_Enabled;

progressBarOption.direction = QApplication:: layoutDirection ();

progressBarOption.rect = option.rect;

progressBarOption.fontMetrics = QApplication:: fontMetrics ();

progressBarOption.minimum = 0;

progressBarOption.maximum = 100;

progressBarOption.textAlignment = Qt:: AlignCenter;

progressBarOption.textVisible = true;

progressBarOption.progress = progress;

progressBarOption.text =

QString("%1%").arg(progressBarOption.progress);

QApplication:: style ()->drawControl(QStyle::CE_ProgressBar,

&progressBarOption, painter);

} else {

return QItemDelegate::paint (painter, option, index);

}

}

模型:

TableModel::TableModel(QObject *parent)

: QAbstractTableModel(parent), arr_row_list(NULL)

{

}

TableModel::~TableModel(void)

{

arr_row_list = NULL;

}

void TableModel::setHorizontalHeaderList(QStringList horizontalHeaderList) {

horizontal_header_list = horizontalHeaderList;

}

void TableModel::setVerticalHeaderList(QStringList verticalHeaderList)

软件架构 4+1 视图模型

RUP 4+1架构 软件需求分析的复杂性 图1 软件需求分类的复杂性

RUP 4+1架构 RUP4+1架构方法采用用例驱动，在软件生命周期的各个阶段对软件进行建模，从不同视角对系统进行解读，从而形成统一软件过程架构描述. 用例视图（Use Cases View），最初称为场景视图，关注最终用户需求， 为整个技术架构的上线文环境.通常用UML用例图和活动图描述。 逻辑视图（Logical view），主要是整个系统的抽象结构表述，关注系统提 供最终用户的功能，不涉及具体的编译即输出和部署，通常在UML中用类图， 交互图，时序图来表述，类似与我们采用OOA的对象模型。 开发视图(Development View)，描述软件在开发环境下的静态组织，从程 序实现人员的角度透视系统，也叫做实现视图(implementation view)。开发 视图关注程序包，不仅包括要编写的源程序，还包括可以直接使用的第三方SDK 和现成框架、类库，以及开发的系统将运行于其上的系统软件或中间件, 在UML

中用组件图，包图来表述。开发视图和逻辑视图之间可能存在一定的映射关系：比如逻辑层一般会映射到多个程序包等。 处理视图（Process view）处理视图关注系统动态运行时，主要是进程以及相关的并发、同步、通信等问题。处理视图和开发视图的关系：开发视图一般偏重程序包在编译时期的静态依赖关系，而这些程序运行起来之后会表现为对象、线程、进程，处理视图比较关注的正是这些运行时单元的交互问题，在UML中通常用活动图表述。 物理视图（Physical view ）物理视图通常也叫做部署视图(deployment view)，是从系统工程师解读系统，关注软件的物流拓扑结，以及如何部署机器和网络来配合软件系统的可靠性、可伸缩性等要求。物理视图和处理视图的关系：处理视图特别关注目标程序的动态执行情况，而物理视图重视目标程序的静态位置问题；物理视图是综合考虑软件系统和整个IT系统相互影响的架构视图。 RUP4+1架构方法从1995年提出后在业界获得广泛应用，并得以发展完善,在具体应用的时候结合公司环境和项目实际进行适当裁剪。 【参考资料】： 1.IBM developerwork 运用RUP 4+1视图方法进行软件架构设计 https://www.sodocs.net/doc/4d12194197.html,/developerworks/cn/rational/06/r-wenyu/index.html 架构蓝图--软件架构"4+1" 视图模型 https://https://www.sodocs.net/doc/4d12194197.html,/developerworks/cn/rational/r-4p1-view/ RUP4+1架构方法 https://www.sodocs.net/doc/4d12194197.html,/Leo_wl/archive/2010/12/09/1901715.html 2.

--软件架构+__4+1__+视图模型

架构蓝图--软件架构"4+1" 视图模型 级别：初级 Philippe Kruchten, 高级技术专员 2005 年1 月01 日 本文基于多个并发视图的使用情况来说明描述软件密集型系统架构的模型。使用多重视图允 许独立地处理各"风险承担人"：最终用户、开发人员、系统工程师、项目经理等所关注的问 题，并且能够独立地处理功能性和非功能性需求。本文分别对五种视图进行了描述，并同时 给出了捕获每种视图的表示方法。这些视图使用以架构为中心的、场景驱动以及迭代开发过 程来进行设计。 引言 我们已经看到在许多文章和书籍中，作者欲使用单张视图来捕捉所有的系统架构要点。通过仔细地观察这些图例中的方框和箭头，不难发现作者努力地在单一视图中表达超过其表达限度的蓝图。方框是代表运行的程序吗？或者是代表源代码的程序块吗？或是物理计算机吗？或仅仅是逻辑功能的分组吗？箭头是表示编译时的依赖关系吗？或者是控制流吗？或是数据流吗？通常它代表了许多事物。是否架构只需要单个的架构样式？有时软件架构的缺陷源于过早地划分软件或过分的强调软件开发的单个方面：数据工程、运行效率、开发策略和团队组织等。有时架构并不能解决所有"客户"（或者说"风险承担人"，USC 的命名）所关注的问题。许多作者都提及了这个问题：Garlan & Shaw 1、CMU 的Abowd & Allen、SEI 的Clements。作为补充，我们建议使用多个并发的视图来组织软件架构的描述，每个视图仅用来描述一个特定的所关注的方面的集合。 回 架构模型 软件架构用来处理软件高层次结构的设计和实施。它以精心选择的形式将若干结构元素进行装配，从而满足系统主要功能和性能需求，并满足其他非功能性需求，如可靠性、可伸缩性、可移植性和可用性。Perry 和Wolfe 使用一个精确的公式来表达，该公式由Boehm 做了进一步修改： 软件架构＝{元素，形式，关系/约束} 软件架构涉及到抽象、分解和组合、风格和美学。我们用由多个视图或视角组成的模型来描述它。为了最终处理大型的、富有挑战性的架构，该模型包含五个主要的视图（请对照图1）：?逻辑视图（Logical View），设计的对象模型（使用面向对象的设计方法时）。 ?过程视图（Process View），捕捉设计的并发和同步特征。 ?物理视图（Physical View），描述了软件到硬件的映射，反映了分布式特性。 ?开发视图（Development View），描述了在开发环境中软件的静态组织结构。 架构的描述，即所做的各种决定，可以围绕着这四个视图来组织，然后由一些用例（use cases）或场景(scenarios)来说明，从而形成了第五个视图。正如将看到的，实际上软件架构部分从这些场景演进而来，将在下文中讨论。 图1 －"4＋1"视图模型

5.bim5d模型视图

五.模型视图 业务背景 多专业模型整合后,需要对模型进行查看\浏览\剖切等操作,指导现场施工模型视图主要内容： 1、通过楼层\专业构件类型过滤显示模型 2、显示图元树 3、显示机电系统 4、构件属性 5、模型信息 6、视点 7、查看组合构件明细 8、轴网显示\轴网设置 9、显示施工场地 10、模型观测视角 11、纹理贴图\实体 12、漫游 13、在模型上按路线行走 14、排砖 15、在模型上测量 16、三维剖面操作 17、切面操作 18、查看钢筋三维 19、专项方案查询 20、高级工程量查询 21、导出IGMS文件、导出3DS文件 22、模型界面右侧工具条 23、小地图 24、右键功能 备注：

在进行操作前，需要导入模型，导入模型参见【项目资料】。模型信息在操作前需要导入进度计划、预算书、图纸等，导入参见【项目资料】、【时间视图】、【合约视图】 1. 通过楼层\专业构建类型过滤操作步骤 （1）、勾选‘首层’ （2）、去掉土建、钢筋和粗装修专业勾选，查看机电模型 2. 显示图元树 点击模型界面右边栏的【图元树】中的构件，模型界面会选中并定位到该构件；

在图元树窗口点击右键，选择【选择同名称图元】，会选中图元树中所有构件名称相同的构件； 在图元树窗口点击右键，选择【选择同类型图元】，会选中图元树中所有该类型的构件；

在模型界面选择一个构件，右键选择【同步选择状态到图元树】（右键前要先打开图元树窗口），会在图元树中选中该构件；

备注： 图元树材质设置参见【工具栏】3. 显示机电系统 点击【视图】—【系统】

4. 属性 点击模型界面右边栏的【选择】按钮，选择模型中的一个梁，在属性窗口下查看属性； 5. 视点 点击【保存视点】，把当前模型界面所显示的图形保存为一个视点，方便查看和编辑

模型视图结构

Qt之模型/视图 (2014-01-08 15:48:01) 转载▼ 标签： 分类：Qt qt qt使用mvc qtableview qlistview qtreeview 关于Qt中MVC的介绍与使用，助手中有一节模型/视图编程 （Model/View Programming）讲解的很清晰。 Qt包含一组使用模型/视图结构的类，可以用来管理数据并呈现给用户。这种体系结构引入的分离使开发人员更灵活地定制项目，并且提供了一个标准模型的接口，以允许广泛范围的数据源被使用到到现有的视图中。 模型- 视图- 控制器（MVC）是一种设计模式，由三类对象组成： ?模型：应用程序对象。 ?视图：屏幕演示。 ?控制器：定义了用户界面响应用户输入的方式。 在引入MVC之前，用户界面的设计往往是将这些对象组合在一起。MVC 的解耦带来了灵活性和重用性。 如果视图和控制器对象相结合，其结果是模型/视图结构，仍然分离了数据与呈现给用户的方式，但提供了基于相同原理的简单框架。这种分离使得它可以在几个不同的视图中显示相同的数据，并且实现新类型的视图，

而无需改变底层的数据结构。为了灵活地处理用户输入，则引入了委托的概念。在此框架引入委托的优点是：它允许项目数据显示和自定义编辑。 模型/视图结构 模型与数据源进行通信，在这个体系结构中为其它组件提供了一个接口。通信的性质依赖于数据源的类型以及模型的实现方式。 视图从模型中得到模型索引，这些都引用到数据项。通过为模型提供模型索引，视图可以从数据源中检索数据项。 在标准的视图里，委托呈现数据项目。当一个项目被编辑，委托与模型直接利用模型索引进行通信。 模型/视图/委托通信 模型、视图、委托使用信号和槽相互通信： ?模型的信号：通知视图关于改变由数据源保持的数据。 ?视图的信号：提供了关于用户交互显示的项目信息。 ?委托的信号：当编辑时告诉模型和视图编辑器的状态。

4+1 视图模型

developerWorks 中国 > Rational > 架构蓝图--软件架构 "4+1" 视图模型 级别： 初级 Philippe Kruchten , 高级技术专员 2005 年 1 月 01 日 本文基于多个并发视图的使用情况来说明描述软件密集型系统架构的模型。使用多重视图允许独立地处理各"风险承担人"：最终用户、开发人员、系统工程师、项目经理等所关注的问题，并且能够独立地处理功能性和非功能性需求。本文分别对五种视图进行了描述，并同时给出了捕获每种视图的表示方法。这些视图使用以架构为中心的、场景驱动以及迭代开发过程来进行设计。 引言 我们已经看到在许多文章和书籍中，作者欲使用单张视图来捕捉所有的系统架构要点。通过仔细地观察这些图例中的方框和箭头，不难发现作者努力地在单一视图中表达超过其表达限度的蓝图。方框是代表运行的程序吗？或者是代表源代码的程序块吗？或是物理计算机吗？或仅仅是逻辑功能的分组吗？箭头是表示编译时的依赖关系吗？或者是控制流吗？或是数据流吗？通常它代表了许多事物。是否架构只需要单个的架构样式？有时软件架构的缺陷源于过早地划分软件或过分的强调软件开发的单个方面：数据工程、运行效率、开发策略和团队组织等。有时架构并不能解决所有"客户"（或者说"风险承担人"，USC 的命名）所关注的问题。许多作者都提及了这个问题：Garlan & Shaw 1、CMU 的 Abowd & Allen 、SEI 的 Clements 。作为补充，我们建议使用多个并发的视图来组织软件架构的描述，每个视图仅用来描述一个特定的所关注的方面的集合。 架构模型 软件架构用来处理软件高层次结构的设计和实施。它以精心选择的形式将若干结构元素进行装配，从而满足系统主要功能和性能需求，并满足其他非功能性需求，如可靠性、可伸缩性、可移植性和可用性。Perry 和 Wolfe 使用一个精确的公式来表达，该公式由 Boehm 做了进一步修改： 软件架构 ＝ {元素，形式，关系/约束} 软件架构涉及到抽象、分解和组合、风格和美学。我们用由多个视图或视角组成的模型来描述它。为了最终处理大型的、富有挑战性的架构，该模型包含五个主要的视图（请对照图 1）： ? 逻辑视图（Logical View ），设计的对象模型（使用面向对象的设计方法时）。 ? 过程视图（Process View ），捕捉设计的并发和同步特征。 ? 物理视图（Physical View ），描述了软件到硬件的映射，反映了分布式特性。

软件体系结构 4+1模型案例

案例教学1：4+1视图方法进行软件体系结构设计 要开发出用户满意的软件并不是件容易的事，软件体系结构师必须全面把握各种各样的需求、权衡需求之间有可能的矛盾之处，分门别类地将不同需求一一满足。本文从理解需求种类的复杂性谈起，通过具体案例的分析，展示了如何通过RUP的4+1视图方法，针对不同需求进行体系结构设计，从而确保重要的需求一一被满足。 1、呼唤体系结构设计的多重视图方法 灵感一闪，就想出了把大象放进冰箱的办法，这自然好。但希望每个体系结构设计策略都依靠灵感是不现实的--我们需要系统方法的指导。 需要体系结构设计的多重视图方法，从根本上来说是因为需求种类的复杂性所致。以工程领域的例子开道吧。比如设计一座跨江大桥：我们会考虑"连接南北的公路交通"这个"功能需求"，从而初步设计出理想化的桥墩支撑的公路桥方案；然后还要考虑造桥要面临的"约束条件"，这个约束条件可能是"不能影响万吨轮从桥下通过"，于是细化设计方案，规定桥墩的高度和桥墩之间的间距；另外还要顾及"大桥的使用期质量属性"，比如为了"能在湍急的江流中保持稳固"，可以把大桥桥墩深深地建在岩石层之上，和大地浑然一体；其实，"建造期间的质量属性"也很值得考虑，比如在大桥的设计过程中考虑"施工方便性"的一些措施。 和工程领域的功能需求、约束条件、使用期质量属性、建造期间的质量属性等类似，软件系统的需求种类也相当复杂，具体分类如图1所示。

图1 软件需求分类的复杂性 2、超市系统案例：理解需求种类的复杂性 例子是最好的老师。为了更好地理解软件需求种类的复杂性，我们来分析一个实际的例子。在表1中，我们列举了一个典型的超市系统的需求子集，从这个例子中可以清晰地看到需求可以分为两大类：功能需求和非功能需求。

模型-视图-提供器 模式

引言 随着像https://www.sodocs.net/doc/4d12194197.html,和Windows窗体这样的用户界面创建技术越来越强大，让用户界面层做多于它本应做的事是很常见的。没有一个清晰的职责划分，UI层经常沦为一个包含实际上应属于程序其他层的逻辑的容器。有一个称为模型(Model)-视图(View)-提供器(Presenter)(MVP)的设计模式，特别适合解决这个问题。为了表明我的观点，我将为Northwind数据库中的客户建一个遵循MVP模式的显示屏幕(display screen)。 为什么在UI层包含太多的逻辑是很糟糕的？在既不手动运行应用程序，也不维护丑陋的自动执行UI组件的UI运行者脚本(runner script)的情况下，位于应用程序UI层中的代码是非常难于调试的。虽然这本身就是一个很大的问题，一个更大的问题是在应用程序的公共视图之间会有大量的重复代码。当执行某一特定业务的功能在UI层的不同部分之间拷贝，通常很难找到好的可选重构方法。MVP设计模式使得将UI层中的逻辑和代码重构为更加易于测试的新型的、可重用的代码更加容易。 图1演示了组成一个范例应用程序的主要层。注意对于UI和表现(Pesentation)有着各自的包(Package)。你可能会想它们是一样的，但是实际上项目中的UI层应该只包含各种不同的UI元素――窗体和控件。典型地，在一个Web窗体项目中是https://www.sodocs.net/doc/4d12194197.html, Web窗体、用户控件、服务器控件的集合；在Windows项目中，它是Windows 窗体、用户控件以及第三方库(Libraries)的集合。这一额外的层就是将显示和逻辑分隔开的层。在表现层，你拥有实际上实现UI行为的对象――诸如验证显示，从UI层收集用户输入等等。

软件架构4+1视图模型

Paper published in IEEE Software 12 (6) November 1995, pp. 42-50 架构蓝图——软件架构“4+1”视图模型 Philippe Kruchten Rational Software Corp. 摘要 本文基于多个并发视图的使用情况来说明描述软件密集型系统架构的模型。使用多重视图允许独立地处理各"风险承担人"：最终用户、开发人员、系统工程师、项目经理等所关注的问题，并且能够独立地处理功能性和非功能性需求。本文分别对五种视图进行了描述，并同时给出了捕获每种视图的表示方法。这些视图使用以架构为中心的、场景驱动以及迭代开发过程来进行设计。 关键字：software architecture, view, object-oriented design, software development process 引言 我们已经看到在许多文章和书籍中，作者欲使用单张视图来捕捉所有的系统架构要点。通过仔细地观察这些图例中的方框和箭头，不难发现作者努力地在单一视图中表达超过其表达限度的蓝图。方框是代表运行的程序吗？或者是代表源代码的程序块吗？或是物理计算机吗？或仅仅是逻辑功能的分组吗？箭头是表示编译时的依赖关系吗？或者是控制流吗？或是数据流吗？通常它代表了许多事物。是否架构只需要单个的架构样式？有时软件架构的缺陷源于过早地划分软件或过分的强调软件开发的单个方面：数据工程、运行效率、开发策略和团队组织等。有时架构并不能解决所有“客户”（或者说“风险承担人”，USC的命名）所关注的问题。许多作者都提及了这个问题：Garlan&Shaw1、CMU的Abowd&Allen、SEI的Clements。作为补充，我们建议使用多个并发的视图来组织软件架构的描述，每个视图仅用来描述一个特定的所关注的方面的集合。 架构模型 软件架构用来处理软件高层次结构的设计和实施。它以精心选择的形式将若干结构元素进行装配，从而满足系统主要功能和性能需求，并满足其他非功能性需求，如可靠性、可伸缩性、可移植性和可用性。Perry和Wolfe使用一个精确的公式来表达，该公式由Boehm做了进一步修改： 软件架构= {元素，形式，关系/约束} 软件架构涉及到抽象、分解和组合、风格和美学。我们由多个视图或视角组成的模型来描述它。为了最终处理大型的、富有挑战性的架构，该模型包含五个主要的视图（请对照图1）： ●逻辑视图（Logical View），设计的对象模型（使用面向对象的设计方法时）。 ●过程视图（Process View），捕捉设计的并发和同步特征。

架构蓝图--软件架构 4+1 视图模型

架构蓝图--软件架构 "4+1" 视图模型 本文基于多个并发视图的使用情况来说明描述软件密集型系统架构的模型。使用多重视图 允许独立地处理各"风险承担人"：最终用户、开发人员、系统工程师、项目经理等所关注 的问题，并且能够独立地处理功能性和非功能性需求。本文分别对五种视图进行了描述， 并同时给出了捕获每种视图的表示方法。这些视图使用以架构为中心的、场景驱动以及迭 代开发过程来进行设计。 引言 我们已经看到在许多文章和书籍中，作者欲使用单张视图来捕捉所有的系统架构要点。通过仔细地观察这些图例中的方框和箭头，不难发现作者努力地在单一视图中表达超过其表达限度的蓝图。方框是代表运行的程序吗？或者是代表源代码的程序块吗？或是物理计算机吗？或仅仅是逻辑功能的分组吗？箭头是表示编译时的依赖关系吗？或者是控制流吗？或是数据流吗？通常它代表了许多事物。是否架构只需要单个的架构样式？有时软件架构的缺陷源于过早地划分软件或过分的强调软件开发的单个方面：数据工程、运行效率、开发策略和团队组织等。有时架构并不能解决所有"客户"（或者说"风险承担人"，USC 的命名）所关注的问题。许多作者都提及了这个问题：Garlan & Shaw1、CMU 的 Abowd & Allen、SEI 的 Clements。作为补充，我们建议使用多个并发的视图来组织软件架构的描述，每个视图仅用来描述一个特定的所关注的方面的集合。 架构模型 软件架构用来处理软件高层次结构的设计和实施。它以精心选择的形式将若干结构元素进行装配，从而满足系统主要功能和性能需求，并满足其他非功能性需求，如可靠性、可伸缩性、可移植性和可用性。Perry 和 Wolfe 使用一个精确的公式来表达，该公式由 Boehm 做了进一步修改： 软件架构＝ {元素，形式，关系/约束} 软件架构涉及到抽象、分解和组合、风格和美学。我们用由多个视图或视角组成的模型来描述它。为了最终处理大型的、富有挑战性的架构，该模型包含五个主要的视图（请对照图 1）： ?逻辑视图（Logical View），设计的对象模型（使用面向对象的设计方法时）。 ?过程视图（Process View），捕捉设计的并发和同步特征。 ?物理视图（Physical View），描述了软件到硬件的映射，反映了分布式特性。 ?开发视图（Development View），描述了在开发环境中软件的静态组织结构。 架构的描述，即所做的各种决定，可以围绕着这四个视图来组织，然后由一些用例（use cases）或场景(scenarios)来说明，从而形成了第五个视图。正如将看到的，实际上软件架构部分从这些场景演进而来，将在下文中讨论。 图 1 － "4＋1"视图模型

Rational Rose的四种视图模型

https://www.sodocs.net/doc/4d12194197.html,/art/201007/215560.htm .1 Rational Rose的四种视图模型 在Rational Rose建立的模型中包括四种视图，分别是用例视图(Use Case View)、逻辑视图(Logical View)、构件视图(Component View)和部署视图(Deployment View)。创建一个Rational Rose工程的时候，会自动包含这四种视图，如图5-1所示。 每一种视图针对不同的模型元素，具有不同的用途。在下面的几个小节中将分别对这四种视图进行说明。.1.1 用例视图（2） 用例图(Use Case Diagram)。在用例视图中，用例图显示了各个参与者、用例以及它们之间的交互。在用例图下可以连接与用例图相关的文件和URL地址。在浏览器中选择某个用例图，右键单击，可以看到在该用例图中允许创建的元素，如图5-7所示。 类图(Class Diagram)。在用例视图下，允许创建类图。类图提供了结构图类型的一个主要实例，并提供了一组记号元素的初始集，供所有其他结构图使用。在用例视图中，类图主要提供了各种参与者和用例中对象的细节信息。与在用例图下相同，在类图下可以创建连接类图的相关文件和URL地址。在浏览器中选择

某个类图，右键单击，可以看到在该类图中允许创建的元素，如图5-8所示。 协作图(Collaboration Diagram)。在用例视图下，也允许创建协作图，来表达各种参与者和用例之间的交互协作关系。与在用例图下相同，在协作图下可以创建连接与协作图相关的文件和URL地址。在浏览器中选择某个协作图，右键单击，可以看到在该协作图中允许创建的元素，如图5-9所示。 序列图(Sequence Diagram)。在用例视图下，也允许创建序列图，和协作图一样表达各种参与者和用例之间的交互序列关系。与在用例图下相同，在序列图下也可以创建连接与序列图相关的文件和URL地址。在浏览器中选择某个序列图，右键单击，可以看到在该序列图中允许创建的元素，如图5-10所示。

PROE模型的视图管理

第9章模型的视图管理 在实际应用中，为了设计更加方便、进一步提高工作效率或为了更清晰地了解模型的结构，可以建立各种视图并加以管理，这就要用到Pro/ENGINEER的“视图管理”功能。在Pro/ENGINEER的“视图管理器”中，可以管理“简化表示”视图、“样式”视图、“分解”视图、“定向”视图，以及这些视图的组合视图。 9.1 定向视图 定向（Orient）视图功能可以将组件以指定的方位进行摆放，以便观察模型或为将来生成工程图做准备。图9.1.1是装配体asm_exercise2.asm定向视图的例子，下面说明创建定向视图的操作方法。 1．创建定向视图 Step1. 将工作目录设置至D:\proewf4.1\work\ch09\ch09.01，打开文件asm_exercise2.asm。 Step2. 选择下拉菜单命令；在“视图管理器”对话框的 选项卡中单击按钮，命名新建视图为view_course，并按回车键。 Step3. 选择命令，系统弹出“方向”对话框；在下拉列表中选取，如图9.1.2所示。 Step4. 定向组件模型。 （1）定义放置参照1：在下面的下拉列表中选择，再选取图9.1.3中的模型表面。该步操作的意义是使所选模型表面朝前，即与屏幕平行且面向操作者。 （2）定义放置参照2：在下面的列表中选择，再选取图中的模型表面，即将所选模型表面放置在右边。 Step5. 单击按钮，关闭“方向”对话框，再单击“视图管理器”对话框的 按钮。 图9.1.1 定向视图

2．设置不同的定向视图 用户可以为装配体创建多个定向视图，每一个都对应于装配体的某个局部或层，在进行不同局部的设计时，可将相应的定向视图设置到当前工作区中，操作方法是在“视图管理器”对话框的 选项卡中选择相应的视图名称，然后双击；或选中视图名称后，选择 命令。 9.2 样式视图 样式（Style）视图可以将指定的零部件遮蔽起来，或以线框和隐藏线等样式显示。 图9.2.1是装配体asm_exercise2.asm样式视图的例子，下面说明创建样式视图的操作方法。 1．创建样式视图 Step1. 将工作目录设置至D:\proewf4.1\work\ch09\ch09.02，打开文件asm_exercise2.asm。 Step2. 选择下拉菜单命令，在视图管理器对话框的选项卡中单击按钮，输入样式视图的名称style_course，并按回车键。 Step3. 系统弹出图9.2.2所示的“编辑”对话框，此时选项卡中提示“选取将被遮蔽的元件”，在模型树中选取bottle_asm。 图9.2.1 样式视图 图9.1.3 定向组件模型 选取此表面为“前” 选取此表面为“右” 图9.1.2 “方向”对话框 按所选的参照定向 定义旋转中心或默认方向 动态平移、缩放和旋转

软件架构_4+1_视图模型

架构蓝图——软件架构“4+1”视图模型在现代软件开发中，软件架构是进行团队开发的基础，因此兼顾不同角色的多重架构视图是必不可少的。那么什么是软件架构视图呢？Philippe Kruchten 在《Rational统一过程引论》中写道：一个架构视图是对于从某一视角或某一点上看到的系统所作的简化描述，描述中涵盖了系统的某一特定方面，而省略了与此方面无关的实体。 软件架构用来处理软件高层次结构的设计和实施。它以精心选择的形式将若干结构元素进行装配，从而满足系统主要功能和性能需求，并满足其他非功能性需求，如可靠性、可伸缩性、可移植性和可用性。Perry 和 Wolfe 使用一个精确的公式来表达，该公式由 Boehm 做了进一步修改： 软件架构＝ {元素，形式，关系/约束} 由于角色和分工不同，整个软件团队以及客户等软件项目涉众各自需要掌握的技术或技能存在很大差异，为了完成各自的工作，需要了解整个软件架构决策的不同子集。如果所有的架构设计决策都混在一起，不同的角色都会看到一个过于复杂的架构，谁也难以理解也不愿意认真阅读。所以软件架构工程师应当提供不同的软件架构视图，以便交流和传递设计思想。 软件架构是一个复杂的整体，软件架构工程师不可能在一个视角、一下子讲清楚，而利用多重软件架构视图的方法，可以一次只围绕少数概念和技术展开，分别着重研究软件架构的不同方面，使问题得以清晰公和简化，利于软件架构工程师完成架构设计工作。 1995年，Rational公司的Philippe Kruchten在《IEEE Software》上发表题为《Architectural Blueprints — The “4+1” View Model of Software Architecture》（架构蓝图——软件架构“4+1”视图模型）的论文，提出使用多个并发的视图来组织软件架构的描述，每个视图仅用来描述一个特定的所关注的方面的问题的集合。这个观点引起了业界的极大关注，后来被Rational统一过程（RUP）采纳，现在已经成为架构设计的结构标准。 RUP4+1架构方法采用用例驱动，在软件生命周期的各个阶段对软件进行建模，从不同视角对系统进行解读，从而形成统一软件过程架构描述.