Data to be entered in SIS II

Para que a base dados seja o mais genérica possível, foram adotados alguns padrões de desenho para a modulação da base dados IP-XACT. Na figura 3.12 é possível observar o diagrama UML do top-level da base dados IP-XACT, pois devido à complexidade que compõe cada elemento base do standard IP-XACT é impossível defini-lo numa só imagem legível.

Como é referido no apêndiceA, todos os elementos base do standard IP-XACT são identificados pelo campo mVlnv, onde este terá de ser único no repositório de IP. A classe CIP-XACT irá conter toda a informação comum entre os vários elemen- tos base do standard IP-XACT. Devido a este facto, a classe CIP-XACT irá ser composta por uma classe CVLNV, que tem como função identificar o elemento definido de acordo com o standard. Outro campo importante é referencia para a classe abstrata CTopLevel. Este atributo pode tomar o valor de vários tipos

Figura 3.12: Top-level UML da base dados IP-XACT

de objetos, tais como: CDesign, CComponent, CAbstractDefinition, CGenerator- Chain e CBusDefinition todos eles elementos base do standard IP-XACT. Este tipo de modulação segue o padrão e desenho Abstract Interface conhecido também por polimorfismo do sub-tipo. Assim sendo, a classe CTopLevel é composto só por funções puramente virtuais com o objectivo de poder invocar o comportamento de- finido pelo método, sem ter a implementação definida. Desta forma, consegue ler, escrever e validar um elemento base do standard IP-XACT sem ter conhecimento do tipo de elemento em questão, facilitando a interação do utilizador com a base de dados IP-XACT. Os outros objetos definidos na classe CIP-XACT referenciam dados importantes à organização da base dados IP-XACT, tal como o caminho onde o ficheiro se encontra definido, o nome do ficheiro, comentários do ficheiro XML e o tipo de elemento base a que a classe CIP-XACT se refere. Este último campo provoca uma certa redundância de informação pois através do apontador para elemento base do standard IP-XACT já é possível identificar o seu tipo mas esse processo tem um certo custo de processamento para o sistema.

Sempre que é necessário criar um elemento a partir de um ficheiro XML é chamado o método readTopXML(), onde o seu comportamento está definido no fluxograma da figura 3.13. Este método recebe como parâmetro de entrada um ficheiro XML que tem como responsabilidade ler o cabeçalho desse ficheiro, conseguindo assim identificar o tipo de elemento IP-XACT a que este se refere, assim como o seu

VLNV para que o elemento possa ser identificado. Assim sendo, só é carregado para a memória o tipo de elemento a que o ficheiro se refere e a sua identificação.

Figura 3.13: Fluxograma do método readTopXML

É impensável carregar para a memória toda a informação relativa a todos os ele- mentos presentes no repositório quando estes são em número elevado. Por isso, para aceder à informação do elemento IP-XACT é necessário chamar o método getElement(). Este método carrega para a memória toda a informação relativa ao elemento IP-XACT, isto é, sempre que este método é chamado é lido do fi- cheiro XML a informação relativa a esse elemento. Quando essa informação já não é necessária é chamado o método resetELemento(), que apaga essa informação da memória. Esta abordagem foi aplicada com o objectivo de não subcarregar a memória com toda a informação relativa ao elemento IP-XACT. A informação é somente carregada quando necessária. Com isto, é possível identificar o elemento através do VLNV sem que a sua informação seja carregada para a memória. O comportamento destes dois métodos está descrito no apêndice B.

Quando um elemento composto é parte integrante de um elemento IP-XACT é necessário defini-lo no diagrama de classe para a definição desse tipo de classes foi seguido o padrão de desenho por composição. Na figura 3.14 é possível observar a representação em UML do elemento portMap que faz parte do standard IP-XACT. O elemento portMap é constituído por elementos simples e elementos compostos,

sendo estes últimos representados por composição na classe CPortMap.

Figura 3.14: Representação UML do elemento portMap

Nem sempre é possível seguir o padrão de desenho por composição, pois em certos IP-XACT schemas pode ocorrer a definição de um elemento que pode ser defi- nido pela escolha de vários tipos. O caso citado é apresentado pelo schema da figura 3.15.

Describes port characteristics.

spirit:port

1 f.. type spirit:portType

F ull description string, ty pically for documentation

P ort sty le

Defines a port w hose ty pe resolv es to simple bits.

spirit:w ire

type spirit:portWireType

Defines a port that implements or uses a serv ice that can be implemented w ith functions or methods.

spirit:transactional

type spirit:portTransactionalType

spirit:portAccessType

Port access characteristics.

spirit:access

type spirit:portAccessType

Indicates how a netlister accesses a port. 'ref' means accessed by reference (default) and 'ptr' means accessed through a pointer.

spirit:portAccessType

type xs:string

If present, is a method to be used to get hold of the object representing the port. This is ty pically a function call or array element reference in sy stemC .

spirit:portAccessHandle

type xs:string

Figura 3.15: Representação de parcial do schema do elemento IP-XACT Port

um elemento transactional para a modelação deste tipo de elementos optou-se por usar o padrão de desenho Abstract Interface já adotado anteriormente. Seguindo este padrão, uma referência pode representar dois tipos de elementos distintos. A figura 3.16 representa o digrama UML desta modelação. Como é possível observar através do UML o atributo mPortStyleType da classe CPortType pode referenciar um objecto do tipo CWire ou um objecto CTransactional. Este padrão foi utilizado sempre que o elemento composto era precedido por um bloco escolha no schema.