Chaque élément d’architecture appartient à une ou plusieurs classes de l’ontologie. Ces classes d’éléments peuvent être définies de manière exten-sive en nommant explicitement un certaine nombre d’éléments. Les classes peuvent aussi être définies de manière intensive en définissant des propriétés communes à un ensemble d’éléments d’architecture, comme par exemple le fait d’être lié avec l’extérieur de l’édifice, ou d’avoir une fonction d’usage particulière. Chaque élément d’architecture est modulable par un ensemble de paramètres. L’ensemble de ces paramètres répondent à certains
invari-ants. Dans le cas d’un escalier, un des invariants est le fait que la hauteur de l’escalier doit correspondre au nombre de marches multiplié par la hau-teur de ces marches. Certains de ces paramètres sont covariants entre eux.
Dans l’exemple de l’escalier, une variation de la hauteur de l’escalier va en-trainer une variation de la hauteur des marches, une variation du nombre de marches, ou bien une variation des deux. Les éléments d’architecture sont en relation les unes avec les autres, ils forment entre eux un graphe de relations.
Ces relations peuvent définir des relations de propriété comme par exem-ple aCommeMatière,aCommePrix, aCommeFonction des relations spatiales comme par exemple est dessus, touche, est inclus ou bien des relations de composition comme par exemple aCommePartie. Un élément d’architecture peut être composé d’autres éléments d’architecture. Dans ce cas les invari-ants concernent l’ensemble des sous-éléments et la variation du paramètre d’un élément peut faire covarier le paramètre d’un autre élément.
5.3.1 Placement à l’intérieur d’une pièce
Les éléments d’architecture peuvent être reliés à une pièces par la relation inRoom. Une pièce peut quant à elle être reliée par la relation inverse hasEA à un ou plusieurs éléments d’architecture. Si l’on veut que le rôle hasEA soient caractérisé par un ensemble de paramètres, il est nécessaire, dans le formalisme de la DL, de créer un individu qui caractérise cette relation. Ces individus appartiennent au concept EAlink.
EAv ∃inRoom.Roomu ∀inRoom.Room (5.9) EAv ∃hasLink.(EAlinku ∃hasLink.Room) (5.10)
inRoom≡hasLink◦hasLink (5.11)
L’équation 5.9 définit comme nécessaire qu’un élément d’architecture soit lié à au moins une pièce. L’équation 5.10 définit comme nécessaire qu’un élément d’architecture soit lié par un individu du concept EAlink à une pièce. Quant à l’équation 5.11 elle définit le rôle inRoom comme la composition de deux rôles hasLink. On peut maintenant associer des paramètres à un individu EAlink :
EAlinkv ∃alignementX.Integeru ∃alignementY.Integer (5.12) Les individus EAlink doivent ainsi posséder deux valeurs d’alignement en-tières.
Figure 5.5 – Graphe d’instances des relations entre pièces et éléments d’ar-chitecture
5.3.2 Façades et éléments d’architecture
Dans cette section, les éléments d’architecture seront composés entre eux dans des façades. Ces façades seront connectées entre elles par leurs ex-trémités. Le terme façade est défini ici comme une succession d’éléments en série. Une façade peut être, par exemple, constituée de :
– un mur plein
– une succession de mur-fenêtre-mur-fenêtre-...
– un mur-fenêtre-mur-porte-mur-fenêtre-mur – une succession de pilier-vide-pilier-vide-...
– un vide
La description de ces façades en logique descriptive est faite dans la sec-tion 5.3.3 et dans la secsec-tion 5.3.4. Chaque façade est munie d’un paramètre décrivant sa longueur totale et d’un autre décrivant son orientation dans le plan.
A chaque façade sont associées deux extrémités. Ces extrémités sont re-liées entre elle par des arcs annotés par un vecteur de déplacement (∆x,∆y) et par un sous-concept du concept façade issu de la base de connaissance.
Ces arcs peuvent ensuite être représentés dans une matrice d’incidence asso-ciant les différentes extrémités entre elles. Comme les façades ne peuvent pas
s’intersecter, cette matrice doit correspondre à un graphe planaire. Prenons comme exemple un simple carré. Chacune des extrémités est reliée par un
Figure 5.6 – Carré munis de quatre extrémité
arc au deux autre extrémités, pour l’instant les arcs ne sont pas annotés par des concepts mais seulement par un vecteur (∆x,∆y). La matrice suivante décrit ces relations :
∅ (0,1) ∅ (-1,0) (0,-1) ∅ (-1,0) ∅
∅ (1,0) ∅ (0,-1)
(1,0) ∅ (0,1) ∅
(5.13)
La diagonale est composée d’ensembles vide ce qui indique que les extrémités ne sont pas connectées à elles-même. La première ligne indique que :
– il n’y a pas de relations entre l’extrémité 1 et l’extrémité 1,
– l’extrémité 1 est liée à l’extrémité 2 avec un déplacement de ∆x= 0 et
∆y= 1,
– il n’y a pas de relations entre l’extrémité 1 et l’extrémité 3,
– l’extrémité 1 est liée à l’extrémité 4 avec un déplacement de ∆x=−1 et ∆y= 0.
Avec cette notation, il est possible de décrire n’importe quel tracé de graphe.
Le forme de la figure 5.7 est ainsi représentable dans ce formalisme. Pour que
Figure 5.7 – Forme représentable
la matrice d’incidence représente un tracé correct, il faut que, pour chaque cycle du graphe, la somme des ∆x et la somme des ∆y soient nulles.
Une autre manière de représenter un plan architectural par un graphe est d’annoter non plus les arcs mais les sommets. Chaque sommet est ainsi annoté par une position (x, y) dans le plan. Pour passer d’une représenta-tion à une autre il suffit de parcourir le graphe avec un algorithme de type BFS (Breadth First Search), en assignant une position arbitraire au pre-mier sommet rencontré. Le passage d’une représentation par position à une représentation par déplacement se fait de manière similaire.
A une étape donnée du processus de conception, il est possible de définir certaines positions et certains déplacements de manière seulement partielle.
Pour ce faire, les positions et les déplacements peuvent être définis par des plages de valeurs admissible. Prenons la forme de la figure 5.8. Le point 1
Figure 5.8 – Forme partiellement définie
est situé à une position fixe. Le point 2 a une coordonnée en x fixe et une coordonnée en y libre. La position du point 3 est quant à elle contrainte dans le carré gris. De plus, on ajoute la contraintex1+y2 < x3. Par des méthodes de programmation linéaire, il est possible de calculer l’ensemble des formes admissible.
5.3.3 Modélisation par listes
Les listes d’éléments d’architecture permettent de représenter des succes-sions d’éléments d’architecture présents, par exemple sur des façades, ou le long de chemins. Chaque élément de la liste appartient à un sous-concept du concept ElementArchi. En logique descriptive, on peut représenter la liste
en utilisant des concepts et des rôles de la manière suivante[23] : OW LList v ∃isF ollowedBy.OW LList EmptyList v OW LList
EmptyList v ≤0hasContent EmptyList v ¬∃hasN ext.>
hasN ext v isF ollowedBy
(5.14)
Les relationshasN extethasContentsont fonctionnelles. La relationisF ollowedBy est transitive et a comme rang OW LList. Une liste contenant un mur, une porte et un mur est exprimée de la façon suivante :
OW LListu ∃hasContents.M uru ∃hasN ext.(
OW LListu ∃hasContents.P orteu ∃hasN ext.(
OW LListu ∃hasContents.M uru ∃hasN ext.EmptyList))
(5.15)
A chacun des éléments de la façade est associé un coefficient d’élasticité compris entre 0 et 1 borne incluse. La somme des coefficients devant être égal à 1. Ainsi, si la longueur totale de la façade est incrémentée d’une valeur
∆x, cette différence de longueur est répartie sur les différents éléments en fonction de leurs coefficient d’élasticité.
5.3.4 Modélisation par cycles
Un plan architectural peut-être décomposé en un ensemble de cycles élé-mentaires. Ces cycles sont obtenus en parcourant pour chacune des pièces la suite des murs la composant. Les cycles sont composés d’une suite de façades ou d’éléments d’architecture. Dans ce cas, la relationisF ollowedBy n’a plus de sens puisque chaque élément est suivi de tous les autres. Un cycle composé de quatre murs et d’une porte est défini de la manière suivante :
M emberCycle1 ≡P orteu ∃N ext.
(M uru ∃hasN ext.
(M uru ∃hasN ext.
(M uru ∃hasN ext.
(M uru ∃hasN ext.M emberCycle1))))
(5.16)
De cette manière, un cycle est une liste commençant par un individu donné et finissant par ce même élément. Un même cycle peut cependant être représenté de plusieurs manières différentes en fonction de l’individu qui est choisi pour débuter le cycle. Si nous prenons l’exemple le plus simple d’un cycle de deux
éléments, appartenant respectivement aux concepts C1 et C2, on définit les membres qui sont dans le cycle et qui appartiennent au concept C1 par :
M emberCycle1 ≡C1u ∃N ext.(
C2u ∃hasN ext.M emberCycle1) (5.17) et les membres qui sont dans le cycle et qui appartiennent au concept C2 par :
M emberCycle2 ≡C2u ∃N ext.(
C1u ∃hasN ext.M emberCycle2) (5.18) Pour définir un membre de ce cycle de manière univoque, il faut prendre la disjonction de ces deux définitions :
M emberCycle≡M emberCycle1tM emberCycle2 (5.19)
5.3.5 Positionnement et paramétrisation des éléments d’architecture
Le positionnement et la paramétrisation se fait selon un ensemble de règles :
– des règles de symétries : Si une règle de symétrie n’est pas respectée alors un individu permettant de rétablir la symétrie est proposé par un algorithme d’abduction.
– des règles de présence nécessaire : Si une certaine configuration est détectée et qu’elle nécessite la présence d’élément ou de relation absents alors l’élément ou la relation en question est proposé par un algorithme d’abduction.
– des règles de paramètres admissibles : Si une configuration est détec-tée et qu’elle nécessite qu’un ou plusieurs individus soient liés à des paramètres de certaines valeurs alors ces paramètres sont proposés à l’utilisateur.
– des règles de relations entre paramètres : Si une configuration est détec-tée et que les relations entre certains paramètres ne sont pas respecdétec-tées alors un ensemble de paramètres acceptable est proposé.
– des règles de respect de positions : Si une configuration est détectée et que les positions de différents élément ne sont pas acceptables alors un ensemble de positions acceptables est proposé.
L’ensemble des paramètres liés à un élément d’architecture doit respecter un ensemble d’invariants. En d’autres termes, certaines propriétés globales doivent être respectées. L’ensemble des paramètres liés à un élément d’ar-chitecture est partitionné en des sous ensembles de covariants. Modifier un
seul des éléments d’un ensemble de covariants nécessite de modifier les autres éléments de cet ensemble.
Les éléments d’architecture peuvent aussi être composés d’autres éléments d’architecture. Les invariants et les covariants d’un élément peuvent relier des sous-éléments d’architecture composant un même élément.