Object Modeling for User-Centered Development and User Interface Design: The Wisdom Approach ARCH UML: Duarte Nuno Jardim Nunes.

Transcrição

1 UNIVERSIDADE DA MADEIRA ARCH UML: Object Modeling for User-Centered Development and User Interface Design: The Wisdom Approach Notação baseada no UML para documentar arquitecturas de software João Filipe Henriques Gouveia Supervisor: Professor Leonel Nóbrega Cê Duarte Nuno Jardim Nunes (Licenciado) Tese Submetida à Universidade da Madeira para a Obtenção do Grau de Doutor em Engenharia de Sistemas, especialidade de Informática Funchal Portugal April 2001 i

2 Resumo A arquitectura de um sistema intensivamente baseado em software é um dos principais recursos intelectuais das empresas que se dedicam à produção de software. A existência de documentação sobre a arquitectura contribui para a avaliação, reutilização, manutenção e comunicação entre os intervenientes no processo de desenvolvimento do software. Com este trabalho pretendeu- se definir uma linguagem de modelação para as descrições arquitecturais, permitindo uniformizar as notações usadas neste tipo de descrições. A estratégia seguida foi a de desenvolver a notação em conformidade com a linguagem de notação UML, beneficiando do facto de esta ser uma linguagem amplamente usada no desenho de software. Todavia foi assegurado que os constructos desta linguagem possuem a expressividade adequada para o fim a que se destinam, resultando numa nova linguagem para a família UML e não numa extensão à linguagem UML. Abstract The architecture of a software intensive system is one of the principals intellectual resources of companies that produce software. The existence of documentation about the architecture contributes to the evaluation, reusability, maintenance and communication between the participating in the development process. With this work was intended to define a modelling language for architectural descriptions, allowing standardizing the notations used in this type of descriptions. The followed strategy was to develop the notation in conformity with the UML notation, with the advantage of this language be broadly used in software design. However it was assured that the constructs of the language possesses the adequate expressivity to the end that are destined, resulting in a new language to the UML family and not an extension to the UML language. ii

3 Palavras Chave Arquitectura de Software Framework de Clements Vistas Módulos Camadas Componentes Conectores iii

4 Agradecimentos Em primeiro lugar gostaria de agradecer ao meu orientador, Professor Leonel Nóbrega. Agradeço pela sua ajuda, disponibilidade, paciência e principalmente o seu entusiasmo por este projecto. Também agradeço pela sua compreensão nos momentos mais difíceis deste projecto, sem a qual este trabalho não seria possível. Agradeço ao grupo que trabalhou comigo este ano, Denzil, Maria e Cristian, que contribuíram sempre com boas ideias para o trabalho. Gostaria também de agradecer aos meus pais, irmã e família, por estarem lá todos os dias, sempre que foi preciso. Penso que palavras não chegam para exprimir a minha gratidão. Agradeço aos meus amigos por me terem dado a força para cá chegar. Ricardo e João, foram muitas as horas, dias, e anos, alegrias e tristezas, vitórias e derrotas. Foram muitas as vezes que me tiveram de ouvir, e que me fizeram acreditar que era possível. Obrigado. iv

5 Índice 1. Introdução Problema Metodologia Conhecimento do domínio Unified Modeling Language (UML) O Metamodelo do UML Mecanismos de extensão Documentação de arquitecturas de software usando vistas Frameworks arquitecturais e documentação de arquitecturas Linguagens de descrição de arquitecturas ( ADL ) Estado da arte Documentação de arquitecturas de software utilizando a Framework de Clements Documentar Vistas Componente e Conector Documentar Tipos de Componentes Documentar ports e roles Documentar Conectores Documentar Sistemas Documentar propriedades Documentar Vistas Módulo Documentar Módulos Documentar Camadas Documentar Relações de dependência Documentar relações de agregação Documentar relações de generalização Documentar propriedades Documentar Vistas de Alocação Elementos de Software Elementos do Ambiente Relações Alocado- a Relações Migrar- para Propriedades requeridas/fornecidas...22 v

6 3.2 Linguagens de descrição de arquitecturas (ADL) e UML Conclusão Arch UML Níveis de análise Documentação de conceitos arquitecturais em UML Documentação de vistas módulos Documentação de vistas componentes e conectores Resultados experimentais Conclusões MetaModelo e modelos para o ArchUML Estrutura do Metamodelo Conceitos do Metamodelo e as suas propriedades O Merge dos conceitos no metamodelo Níveis do metamodelo do UML Criação de Modelos Conclusão Conclusões finais e trabalho futuro Bibliografia...56 vi

7 Índice de Figuras Figura 1: Componentes arquitecturais representado como classe UML...8 Figura 2: Componentes arquitecturais representados como componentes UML...8 Figura 3: Ports arquitecturais representados como Ports UML...9 Figura 4: Conectores arquitecturais como associações UML...10 Figura 5: Conectores arquitecturais como classes de associação UML...10 Figura 6: Conectores arquitecturais como classes UML...10 Figura 7: Conectores arquitecturais usando o conceito de classe UML estereotipada...11 Figura 8: Hierarquia de um tipo de componente...11 Figura 9: Documentação de um possível sistema...11 Figura 10: Documentação de propriedades usando valores marcados...12 Figura 11: Documentação de propriedades arquitecturais usando atributos UML...12 Figura 12: Documentação de propriedades arquitecturais considerando o aspecto semântico dos atributos UML...13 Figura 13: Documentação de propriedades arquitecturais usando tags e estereótipos...13 Figura 14: Possíveis representações de um módulo utilizando conceitos UML...14 Figura 15: Uma camada arquitectural representada como um pacote...15 Figura 16: As relações de "allowed- to- use" e "uses" representadas como uma dependência UML...16 Figura 17: As duas estratégias utilizadas para representar a relação de agregação...17 Figura 18: Os dois tipos de relação de Generalização...18 Figura 19: Elementos do ambiente como Nodes (client e server) e elementos de software como componentes UML (scheduler e planner) [5]...21 Figura 20: Representação de Módulos como classe (esquerda) e pacotes (direita)...26 Figura 21: Com a introdução do conceito de "Structured Classifier" é possível agora elementos como classes possuírem outros elementos [3]...26 vii

8 Figura 22: As diferentes notações para representar decomposição: "ownership" (em cima), e agregação (em baixo)...28 Figura 23: A relação de "uses" usando uma dependência UML estereotipada...29 Figura 24: A relação de generalização com a propriedade indicando que tipo de herança é feita...30 Figura 25: Notação informal normalmente utilizada para representar camadas arquitecturais32 Figura 26: As alternativas para representar o conceito de camada arquitectural...32 Figura 27: O conceito de "Collaboration" pode ser utilizado para representar um conector arquitectural...34 Figura 28: Outras alternativas para representar conectores, utilizando o conceito de associação UML...34 Figura 29: A representação do conceito arquitectural "Filter"...37 Figura 30: As várias opções de representar o conceito arquitectural "Pipe"...37 Figura 31: As alternativas para representar o conceito arquitectural "Repositório"...38 Figura 32: As diferentes alternativas para representar o conceito arquitectural "Data Accessor"...38 Figura 33: Diferentes representações para o conceito arquitectural "DataConnector"...39 Figura 34: Diferentes representações para o conceito arquitectural "Publisher- Subscriber"...40 Figura 35: Representação do conceito "Cliente" centrando- se no conceito de Desktop...41 Figura 36: Representação do conceito arquitectural "Servidor" centrando- se no conceito de torre...41 Figura 37: Diferentes alternativas para representar o conceito "Request- Reply"...41 Figura 38: Diferentes representações encontradas para o conceito arquitectural "peer"...42 Figura 39: As diferentes alternativas para representar o conceito de unidade concorrente...44 Figura 40: As diferentes maneiras de representar o conceito arquitectural "comunicação"...44 Figura 41: Organização dos conceitos em pacotes...46 Figura 42: O pacotes "Styles" com os estilos arquitecturais e os conceitos relevantes em cada um deles...47 Figura 43: O merge dos diferentes pacotes...47 Figura 44: A especificação de um conector arquitectural...48 viii

9 Figura 45: Especificação do conceito "PublisherSubscriber"...49 Figura 46: O Sketch Code Generator permite gerar a especificação da linguagem...50 Figura 47: Criar um novo modelo no MetaSketch...51 Figura 48: Menu que nos permite criar um modelo ou um metamodelo...51 Figura 49: Escolha da linguagem que vai ser utilizada nos nossos modelos...52 Figura 50: Diagrama de Camadas no MetaSketch...52 Índice de Tabelas Tabela 1: Conceitos nas vistas Componente e Conector...5 Tabela 2: Conceitos nas vistas Módulo...5 Tabela 3: Conceitos nas vistas Alocação...5 Tabela 4: Conceitos a documentar nas vistas Módulo...25 Tabela 5: Conceitos a documentar no estilo Decomposição...27 Tabela 6: Conceitos a documentar no estilo Uses...28 Tabela 7: Conceitos a documentar no estilo Generalização...29 Tabela 8: Conceitos a documentar no estilo Camadas...30 Tabela 9: Conceitos a documentar nas vistas componentes e conectores...33 Tabela 10: Conceitos a documentar no estilo Pipe And Filter...36 Tabela 11: Conceitos a documentar no estilo Shared- Data...38 Tabela 12: Conceitos a documentar no estilo Publisher- Subscriber...39 Tabela 13: Conceitos a documentar no estilo Cliente- Servidor...40 Tabela 14: Conceitos a documentar no estilo Peer- to- peer...42 Tabela 15: Conceitos a documentar no estilo Processos Comunicantes...43 ix

10 1. Introdução Hoje em dia a arquitectura de software é cada vez mais importante no desenvolvimento de software por diferentes razões. Uma delas, é o facto de a arquitectura reflectir as decisões tomadas por uma equipa de arquitectos, decisões que são consequência de requisitos ou limitações impostas por todos os interessados no software a ser desenvolvido. Por essa razão a arquitectura torna- se num meio ideal para comunicar a essas pessoas de que forma a que as suas exigências são cumpridas. Para a correcta comunicação é então necessário proceder à documentação da arquitectura. Documentar uma arquitectura envolve escolher e documentar um conjunto de vistas, e em seguida documentar informação que se aplica a mais que uma vista. Diferentes notações têm sido utilizadas para documentar a informação de cada vista, sendo o UML, uma dessas notações. O UML tem sido largamente utilizado, pois é um standard da OMG adoptado por maior parte da indústria. No entanto não foi desenvolvido a pensar na documentação de arquitecturas de software, e por isso muitas vezes é necessário fazer mapeamento entre conceitos arquitecturais e conceitos UML, além de que existem conceitos não necessários à representação de arquitecturas, ou conceitos em falta para a sua representação. Já existem alguns trabalhos onde este tema é tratado para o UML 1.4. Em algumas vistas, já existe esse mapeamento para o UML 2.0. No entanto esses trabalhos limitam- se a apresentar estratégias para adaptar os conceitos UML aos conceitos arquitecturais, sem existir uma mudança real a nível do metamodelo do UML, nem a nível da notação. 1.1 Problema A hipótese desta tese é a de que é possível utilizar o UML para documentar qualquer arquitectura de software, utilizando uma Framework de vistas específica, e criar uma representação para os conceitos envolvidos na documentação. 1.2 Metodologia Inicialmente será feita uma análise aos diferentes tipos de vistas, de forma a identificar os conceitos e elementos mais significativos de cada uma delas. Identificados esses conceitos, analisarei as diferentes estratégias de representação actuais, de forma a perceber se são adequadas ou não. Posteriormente serão apresentadas alternativas, ou novas opções para a representação dos conceitos arquitecturais envolvidos, dando origem a novas notações. Paralelamente, deverá ser verificado se os conceitos UML podem de forma eficaz representar os conceitos arquitecturais envolvidos, tendo em conta o metamodelo do UML. 1

11 2. Conhecimento do domínio Para a completa compreensão do tema, é necessário ter uma ideia geral sobre alguns conceitos básicos, como o UML, as ADL (architecture description languages) ou o conceito de vistas. Sendo assim esta secção apresenta de forma resumida os principais conceitos. 2.1 Unified Modeling Language (UML) Como é referido em [1] e [2], o UML é a linguagem mais utilizada da OMG para visualização, especificação e documentação de sistemas de software, além de processos de negócio e estruturas de dados. Num espaço curto de tempo, o UML emergiu como linguagem dominante da indústria. Foi aplicada num vasto leque de domínios, desde a aviação e sistemas de tempo real, ao comércio electrónico e jogos de computador. Além destes domínios, também teve uma grande influência nas ferramentas CASE, e está presente no ciclo de desenvolvimento de software, desde os requisitos até ao deployment. Os seus principais objectivos eram: [1] Fornecer um meio fácil de usar e visual para partilhar e desenvolver modelos baseados num conjunto comum e familiar de conceitos Fornecer mecanismos de extensibilidade e especialização dos conceitos principais de forma a satisfazer novas necessidades ou se adaptar a domínios em particular Suportar especificações que são independentes da tecnologia de implementação utilizada, dos métodos de desenvolvimento ou processos Fornecer uma base formal para compreender a linguagem que é precisa e acessível. Isto é atingido usando funcionalidades do metamodelo e expressando o significado operacional em linguagem natural e em OCL (Object Constraint Language) Encorajar o crescimento das ferramentas de objectos, ao fornecer um conjunto de conceitos que podem ser partilhado entre ferramentas e utilizadores sem perda de informação Suportar conceitos de desenvolvimento de alto nível, como frameworks, componentes e padrões, obtendo assim todos os benefícios da modelação de objectos e promovendo a reutilização Integrar as melhores práticas no domínio da modelação de objectos, como diferentes vistas baseadas nos diferentes níveis de abstracção, domínios, arquitecturas ou estados do ciclo de vida. O UML encontra- se definido por um conjunto de documentos controlados pela OMG, sendo que existe um problema quanto há semântica do UML, visto que esta está especificada informalmente e distribuída por vários locais O Metamodelo do UML O UML é definido usando uma arquitectura de camadas com 4 níveis, onde as relações entre camadas são do tipo instancia- de. As 4 camadas são as seguintes: [2] 2

12 M3 Meta object facility (MOF) define os conceitos básicos a partir dos quais meta- modelos específicos são criados ao nível do metamodelo(m2). Contem também um conjunto de regras que especificam a interoperabilidade semântica e o formato de partilha para qualquer um dos seus metamodelos. M3 define- se usando a si mesmo, logo não necessita de outro níveis superiores M2 MetaModelo define os diferentes metamodelos dos standards da OMG que partilham o MOF, como por exemplo o UML, o Common Warehouse Model (CWM) ou o Java Beans (EJB) M1 Modelo do domínio Instancias do domínio residem em M1 e normalmente correspondem a classes (ou objectos) ou informação de runtime M0 Informação especifica do domínio é onde os modelos do utilizador residem por instanciação de diferentes standards da tecnologia definida em M2. Nesta tese irei trabalhar ao nível do M2, para definir os conceitos necessários há representação de arquitecturas, e no nível do M1, para definir que tipo de representação devem ter as instâncias dos conceitos definidos em M Mecanismos de extensão Segundo [2], existem no UML 1.4 fornece dois mecanismos de extensão para definir variações do UML. Primeiro temos os Profiles, que são definidos como um conjunto de estereótipos, valores marcados, restrições e ícones de notação que especializam o UML para um domínio ou processo específico. Um estereótipo UML é uma forma de classificar elementos UML como se eles fossem instâncias de novos conceitos do metamodelo, sendo que esta é uma técnica eficiente. Normalmente é usado para indicar uma diferença no significado ou na utilização de um símbolo. Um valor marcado permite anexar informação a qualquer elemento do modelo. Uma restrição UML permite novas semânticas possam ser definidas, através de linguagem natural ou OCL, para diferentes elementos do modelo. Estes três conceitos são utilizados para estender o UML com novos tipos de elementos. Outro meio de extensão do UML seria utilizar directamente o MOF para criar novos conceitos ao nível de M2. Apesar de esta opção permitir uma maior flexibilidade, tem algumas desvantagens, nomeadamente, não existem regras relativamente ao mapeamento da notação e semântica quando o UML é estendido. 2.2 Documentação de arquitecturas de software usando vistas O conceito de vista é muito importante na arquitectura de software. Documentar uma arquitectura de software, envolve escolher e documentar as vistas mais relevantes para os interessados numa arquitectura. [3] Uma vista é uma representação de um conjunto de elementos que compõe o sistema, bem como as relações existentes entre eles. 3

13 Estas mostram- nos quais as diferentes estruturas presentes no sistema, e permitem lidar com a complexidade inerente aos grandes sistemas, ao darem a hipótese de analisar apenas uma pequena parte do sistema. São também fundamentais para a análise dos diferentes atributos de qualidade que um sistema possui. Por exemplo, uma vista que mostra um sistema em camadas, pode ser utilizado para permitir que o sistema seja modificável (modificabilidade), enquanto uma vista que represente o sistema como um conjunto de processos comunicantes pode ser usado para analisar a performance do sistema. [3] Documentar as vistas implica a escolha de estratégias para representar os diferentes conceitos existentes. A escolha de determinada estratégia envolve fazer cedências entre os pontos fortes e fracos, mas não existe uma estratégia melhor para todos os objectivos da documentação. Diferentes factores devem ser levados em consideração na escolha de uma estratégia: [3] Equivalência semântica: deve ser possível mapear intuitivamente os conceitos utilizados no UML 2.0 para os conceitos arquitecturais necessários representar Claridade visual: deve ser possível identificar sem dificuldade os diferentes conceitos arquitecturais Completude: todos os conceitos arquitecturais devem estar representados no modelo UML Suporte de ferramentas: Nem todas as ferramentas suportam o UML da mesma forma, o que pode limitar a forma como se documenta as arquitecturas Frameworks arquitecturais e documentação de arquitecturas A escolha de um conjunto de vistas que represente a arquitectura não é feita de forma arbitrária. Neste momento existem diferentes tipos de taxonomias de vistas, como é referido em [4], que podem ser vistas como Frameworks. Uma das mais antigas e populares é a 4+1 de Kruchten, que tinha como critério de classificação os interesses específicos de cada um dos interessados. Mais recentemente Clements (et al.), refinou esta Framework, com base no conceito de estilo. Nesta Framework as vistas estão organizadas em 3 grandes grupos: módulos, componentes e conectores, alocação. Visto que a Framework de Clements é mais refinada que a de Kruchten, será sobre esta Framework que desenvolverei o trabalho. Analisando com mais detalhe a Framework de Clements, como é feito em [5], verifica- se que existem conceitos em cada um dos grupos de vistas que são necessários documentar e que podem ser agrupados em categorias: Elementos Relações Propriedades dos elementos e das relações Topologia Nas tabelas seguintes, para cada uma dos três grupos de vistas, indico os conceitos identificados em cada uma das categorias anteriores, tal como é feito em[5]. 4

14 Vista Componente e Conector Elementos Tipos de conector, tipos de componente Relações Anexos Propriedades dos elementos Nome, tipo, outras Propriedades das relações Relações através dos conectores Topologia Nada a considerar Tabela 1: Conceitos nas vistas Componente e Conector [5] Vista Módulos Elementos Módulos, Camadas Relações Generalização, Agregação e Dependência Propriedades dos elementos Nome, responsabilidades, entre outros Propriedades das relações Propriedades de visibilidade, restrições, propriedade de herança Topologia Nada a considerar Tabela 2: Conceitos nas vistas Módulo [5] Vista Alocação Elementos Elementos de software ou do ambiente Relações Alocado- a, migrar- para Propriedades dos elementos Propriedades requeridas e fornecidas Propriedades das relações Depende do estilo considerado Topologia Nada a considerar Tabela 3: Conceitos nas vistas Alocação [5] São estes os conceitos que terão que ser representados numa arquitectura de software utilizando a Framework de Clements. 2.3 Linguagens de descrição de arquitecturas ( ADL ) Segundo [6] as ADL são linguagens formais que podem ser usadas para representar uma arquitectura de um sistema de software, sendo utilizadas para ultrapassar as limitações das representações informais. Estas possuem algumas propriedades especiais que outras linguagens não possuem, sendo que estas propriedades nem sempre são as mesmas, variando consoante o ponto de vista de quem as define. No entanto existe alguns aspectos em comuns como: Fornecem capacidade de abstracção As vistas são predominantemente informação arquitectural A análise fornecida pela linguagem é baseada em informação arquitectural Assim, não existe uma diferença clara entre o que é uma ADL e uma não ADL, mas as ADL mostram uma clara vantagem sobre as outras quando se documenta uma arquitectura. Um 5

15 pequeno conjunto de requisitos é definido para que uma linguagem seja uma ADL, entre eles a capacidade para suportar a criação, validação e refinamento de arquitecturas, representar os estilos arquitecturais mais comuns e fornecer diferentes vistas do sistema. Exemplos de algumas ADL são Wright, UniCon ou a ACME. 3. Estado da arte Esta secção descreve os desenvolvimentos mais recentes na área da documentação das arquitecturas de software. O objectivo deste capítulo será então o de rever e discutir o trabalho desenvolvido neste tópico, justificando assim o objectivo principal da tese. Esta secção está dividida por tipos de vista segundo a Framework de Clements, ou seja, vista módulo, vista componente e conector, e vista de alocação. Em cada um dos tipos de vistas, são analisados os diferentes conceitos a serem representados numa arquitectura de software. Além disso existe uma secção onde se discute a possibilidade de utilizar o UML como uma linguagem universal, para a documentação de arquitecturas de software. 3.1 Documentação de arquitecturas de software utilizando a Framework de Clements Segundo a Framework de Clements, existem três grupos de vistas: componente e conector, módulo e alocação. Nesta secção apresento os conceitos necessários documentar em cada um destes grupos, indicando o seu significado arquitectural, e as diferentes estratégias utilizadas para a sua representação Documentar Vistas Componente e Conector Segundo [5], a vista componente e conector fornece uma imagem das entidades que estão em runtime e as suas potenciais interacções. São várias as entidades que podem estar presentes em runtime: processos, objectos, clientes, servidores, bases de dados ou caminhos de interacção. Os caminhos de interacção são particularmente importantes pois são capturados como conectores, e uma das decisões mais importantes de um arquitecto, é escolher de que forma é que vai ocorrer esta interacção, ou seja, escolher que tipo de conector estará presente na interacção entre os diferentes componentes. Este tipo de vista é muito utilizado para ter uma ideia inicial da arquitectura do sistema. No entanto, os diagramas utilizados são muitas vezes do tipo box- and- line que são ambíguos e inconsistentes. 6

16 Segundo a análise feita em [3], os conceitos arquitecturais necessários documentar numa vista componente e conector são os seguintes: Componentes Conectores Ports Sistemas Propriedades Sendo assim vamos analisar cada um destes conceitos do ponto de vista arquitectural, seguindo- se a comparação com os conceitos UML e respectivas estratégias de representação. As descrições dos conceitos arquitecturais desta secção são baseadas em [5], enquanto as representações desses mesmos conceitos em UML são baseados em[3] Documentar Tipos de Componentes A nível arquitectural, os tipos de componentes são elementos de uma vista C&C, e representam as unidades principais de processamento ou bases de dados. Cada componente possui um nome, que deve indicar qual a sua função. Este nome também deve permitir relacionar o elemento gráfico com a documentação de suporte existente. Além disso um componente tem que ter um tipo associado (por exemplo cliente, servidor, filtro, objecto ou base de dados) definido pela sua natureza computacional e pela sua forma (como um componente filtro que transforma os dados recebidos nas suas interfaces de input e transmite o resultado através das suas interfaces de output). Os componentes podem representar estruturas complexas, que podem ser descritas como uma colecção de outros componentes e conectores. De referir ainda que, numa vista componente e conector, não aparecem os tipos de componentes, mas sim instâncias dos tipos de componentes. [5] A descrição de um tipo de componente inclui o número e tipos de interface que o componente suporta, bem como as propriedades requeridas por este. As interfaces de um componente designam- se de ports, para realçar a sua natureza runtime e diferenciar de outras interfaces como a das classes Documentação de Componentes utilizando conceitos do UML 2 Segundo [3], existem duas estratégias para representar componentes: Estratégia 1: Uso de classes UML Estratégia 2: Uso de componentes UML A utilização do conceito de classe deve- se ao facto de estas serem entidades primárias, muito úteis para capturar abstracções, pois é possível descrever a estrutura, propriedades, o 7

17 comportamento e a semântica de uma classe. Além disso a relação entre componente/ instância e classe/instância é algo semelhante, exceptuando o facto de que, enquanto as instâncias UML podem apenas incluir as partes definidas numa classe, as instâncias de componentes podem refinar essas partes, adicionando novas estruturas não definidas no seu tipo. Figura 1: Componentes arquitecturais representado como classe UML [3] A utilização do conceito componente UML, advém do facto de no UML 2, este ter sido revisto e colocado como subclasse do conceito de classe UML, evitando assim os problemas que surgiam no UML 1.4 onde estes podiam ser confundidos com unidades de implementação, e pelo facto de terem um poder de expressividade semelhante ao das classes, com a vantagem de poderem ter packageable elements. Figura 2: Componentes arquitecturais representados como componentes UML [3] Documentar ports e roles Tanto os componentes como os conectores possuem interfaces, respectivamente designadas por ports e roles, e são pontos de interacção de um componente ou conector com o ambiente circundante Documentação de ports utilizando conceitos do UML 2 Segundo [3], a estratégia para representar o conceito de ports é utilizar o conceito UML Ports, pois este possui toda a expressividade necessária, podendo ser definidos múltiplos 8

18 ports para cada componente e várias instâncias para cada tipo de port. O conceito UML port, é representado por um quadrado, como é mostrado na figura 3. No entanto, segundo [7], um port UML é ponto de possível interacção dos componentes, que podem ter associados interfaces UML. Isto é um problema pois no conceito arquitectural os ports são as interfaces. As interfaces dos conectores, os roles, não são representados em nenhuma parte da documentação consultada. Figura 3: Ports arquitecturais representados como Ports UML [3] Documentar Conectores A nível arquitectural, os tipos de conectores são os mecanismos de interacção, que vão desde simples chamadas de procedimentos entre objectos, a algo muito complexo que pode ser decomposto num conjunto de outros componentes e conectores. Cada conector deve ter um tipo associado, que define a natureza da interacção suportada por este. Além disso, o tipo de conector também define a forma que o conector assume. Isto é relevante pois determina algumas características da interacção, como número de componentes envolvidos numa relação, número e tipo de interfaces (no caso dos conectores são designadas por roles) que suporta, e propriedades requeridas. Esta interacção proporcionada pelos conectores, é muitas vezes descrita como um protocolo, que descreve padrões de eventos ou acções que podem ocorrer numa dada interacção. Parte da descrição de um tipo de conector deve ser caracterizada pelo número e tipo de roles, que as instâncias desse tipo pode ter. Ainda é de referir que, um role define a expectativa de um participante na interacção. Por exemplo, um role de invocar serviços pode requerer que um invocador de serviços inicialize a conexão antes de realizar o pedido de serviço Documentação de conectores utilizando conceitos do UML 2 Segundo [3], o conceito de conector UML não se adequa pois falta- lhe expressividade, capacidade de associar informação semântica ou capacidade para documentar claramente as suas interfaces (roles). Assim sendo são apresentadas três estratégias para documentar este conceito: 1. Uso de associações UML 2. Uso de classes de associação UML 3. Uso de classes UML 9

19 A primeira estratégia era usada pois tinha como vantagem o facto de ser visualmente apelativa, pois era fácil de diferenciar os diferentes elementos (componentes e conectores), mas mantinha os problemas que o conceito de conector UML apresentava. Figura 4: Conectores arquitecturais como associações UML [3] A utilização de classes de associação UML, a segunda estratégia, permitia ultrapassar a incapacidade de associar informação semântica, além de ser possível representar a estrutura interna e interfaces dos conectores. O problema seria que nem sempre seria claro onde é que os ports e roles estariam ligados, ficando a arquitectura mais difícil de ler. Figura 5: Conectores arquitecturais como classes de associação UML [3] A terceira estratégia passa pela utilização de classes UML. Esta estratégia resolveria a desvantagem da segunda estratégia, ao clarificar onde é que os ports e roles estariam ligados, mas tornaria mais difícil a distinção entre componentes e conectores, como mostra a figura 6. Para isso é sugerido que se utilize uma classe estereotipada de forma a mudar a visualização da classe e assim criar um conector com uma forma diferente de um componente. Figura 6: Conectores arquitecturais como classes UML [3] 10

20 Figura 7: Conectores arquitecturais usando o conceito de classe UML estereotipada [3] Documentar Sistemas Na documentação de vistas componente e conector de sistemas é necessário considerar dois tipos de informação: primeiro, definição de tipos de componentes e conectores, e segundo, topologia das instâncias dos tipos dos componentes e conectores que formam o sistema. A forma de documentação destes elementos já foi abordada nas secções anteriores. No entanto há que ter em conta algumas considerações ao documentar sistemas. Em primeiro lugar é necessário que os tipos e hierarquias de tipo de componentes e conectores, sejam documentados usando diagramas de classes ou diagramas de componentes. Através da generalização é possível mostrar tipos e subtipos, onde os subtipos podem ser representados como classes. É necessário também estar documentado as interfaces, atributos e modelos comportamentais para cada um dos tipos de componente ou conector considerado. Figura 8: Hierarquia de um tipo de componente [3] Em segundo lugar, será necessário documentar a topologia das instâncias de componentes e conectores considerados no primeiro ponto, através de um diagrama de instâncias. [3] Figura 9: Documentação de um possível sistema [3] 11

21 Documentar propriedades As propriedades arquitecturais são utilizadas para capturar informação semântica sobre um sistema e os seus elementos que vai para além da estrutura [3]. Alguns elementos podem ter diferentes tipos de propriedades associadas, como é o caso de o nome e tipo de elemento. Outras podem ser escolhidas para uma particular utilização das vistas componente e conector. Algumas propriedades podem ser importantes para a construção do sistema, ou para a sua análise ou ainda para a comunicação com os diferentes interessados. Alguns exemplos dessas propriedades são: fiabilidade, performance, recursos requeridos, funcionalidade e segurança. Os ports e roles (interfaces de componentes e conectores, respectivamente) podem ter algumas propriedades importantes associadas com o seu uso, e também devem ser explicitadas. [3] Documentar propriedades das vistas C&C utilizando conceitos do UML 2 Segundo [3], existe um conceito UML propriedade, mas indica que este não é uma boa solução para representar propriedades arquitecturais pois não podem ser utilizadas para representar directamente propriedades arquitecturais. Sugerem então 3 alternativas: 1. Uso de valores marcados (tagged value) 2. Uso de atributos para representar propriedades 3. Uso de estereótipos para representar propriedades A primeira estratégia, valores marcados, como se pode observar na figura 10 consiste na definição de uma propriedade como um par (nome,valor) (neste caso (multithreaded,yes)). No entanto há desvantagens: não há documentação explícita do valor do tipo, e um valor marcado apenas pode ser definido para uma instância e não pode ser partilhada por várias instâncias. Figura 10: Documentação de propriedades usando valores marcados [3] A segunda estratégia seria a utilização de atributos UML, mas estes são estruturais e não semânticos, como acontecem com as propriedades arquitecturais, e poderia levar a confusões. É sugerido utilizar um atributo estereotipado para indicar que o atributo seria semântico. Figura 11: Documentação de propriedades arquitecturais usando atributos UML [3] 12

22 Figura 12: Documentação de propriedades arquitecturais considerando o aspecto semântico dos atributos UML [3] A terceira estratégia apresentada, sugere a utilização de tag e estereótipos. O objectivo seria criar uma extensão de classe (se for esse o conceito a ser utilizado para representar o elemento onde se encontra a propriedade), através de um estereótipo, que possuiria uma tag correspondente há propriedade que se deseja incluir. Exemplo de tal é a figura 13, onde temos um estereótipo de classe, PipelineFilter, com uma propriedade throughput. Nas suas instâncias podíamos definir valores para esta propriedade, como se mostra também na figura 13. Figura 13: Documentação de propriedades arquitecturais usando tags e estereótipos [3] Documentar Vistas Módulo A vista de módulos é utilizada para mostrar as estruturas/módulos de um sistema de software e as relações entre essas estruturas/módulos. Ao vermos os módulos que compõem o sistema é possível decompô- los em outros módulos, mais pequenos e fáceis de manusear. Além disso a decomposição dos módulos dá uma ideia de como é que o código estará dividido e que serviços cada parte fornecerá a outras partes. Isto leva- nos a ter uma vista onde é possível analisar o impacto de alterações sobre o sistema. Segundo a análise feita em [5], os conceitos arquitecturais necessários documentar numa vista de módulos são os seguintes: Módulo Dependência Agregação Generalização Camada 13

23 Para a vista módulos os documentos existentes utilizam o UML 1.4, podendo estes servir como base de partida para a pesquisa do UML 2.0. Assim há que analisar as estratégias utilizadas neste momento, e mais há frente verificar se estas estratégias se mantêm válidas com o UML 2.0. As secções da vista módulo é baseada em[5] Documentar Módulos A nível arquitectural, um módulo é definido como uma unidade de implementação de software que fornece um conjunto de funcionalidades coerentes Os módulos são caracterizados ao enumerar um conjunto de responsabilidades, muitas delas fazendo parte das propriedades dos módulos. Este conceito de responsabilidade inclui o conjunto de funcionalidades que este deve fornecer. Além disto, os módulos podem ser agregados e decompostos. Diferentes tipos de vistas de módulos podem mostrar diferentes conjuntos de módulos, agregados ou decomposto consoante o estilo escolhido. [5] Documentação de módulos actualmente Segundo [5], existem 3 estratégias para documentar módulos: 1. Uso de classes UML 2. Uso de pacotes UML 3. Uso de subsistemas UML As razões fornecidas para a utilização destas estratégias são: o conceito de classe UML é uma especialização do conceito de módulo arquitectural e logo indicado para representar tal; os pacotes UML são utilizados quando a capacidade de conter ou agrupar outros elementos é importante, como na representação de camadas; os subsistemas UML são utilizados quando é necessário especificar interfaces e comportamento dos módulos. A figura 14 mostra as diferentes formas de representar o conceito de módulo. Figura 14: Possíveis representações de um módulo utilizando conceitos UML [5] Documentar Camadas As camadas, são conjuntos coesos de unidades de software, como por exemplo módulos, que podem ser invocados ou acedidos [5]. Segundo [8], cada camada divide o software em partes, 14

24 sendo que essas partes são designadas de máquinas virtuais, com uma interface pública, que fornecem um conjunto de serviços coesos. Além disso, as máquinas virtuais são criadas de forma a interagirem entre si de acordo com uma relação de ordem estrita, ou seja, se (A,B) estão em relação, diz- se que a camada B está por baixo da camada A, e isso significa que: A implementação da camada A tem permissão para usar qualquer funcionalidade pública fornecida pela máquina virtual da camada B As funcionalidades públicas na camada B podem ser utilizadas pelo software na camada A. Por uso, entenda- se relação de uses como definida por Parnas em 1979: Uma unidade de software A usa uma unidade B se a correcção de A depende da correcta implementação de B. Esta relação é definida como allowed- to- use. Além da relação de uso entre camadas, há que ter em conta mais algumas considerações. Em alguns diagramas as camadas podem utilizar não só a camada imediatamente abaixo, como outras que se encontrem mais abaixo. Além disso, nenhum diagrama deve permitir que uma camada utilize, sem restrições, recursos de uma camada superior. Se assim fosse destruir- se- ia as propriedades positivas que as camadas trazem para uma arquitectura. [8] Documentação de camadas actualmente Neste momento, a documentação existente utiliza o UML 1.4. Sendo assim não inclui muitos dos novos e úteis conceitos do UML 2. No entanto, em [8] é nos apresentada duas estratégias: 1. Utilização de pacotes UML 2. Utilização de estereótipos UML A utilização do conceito de pacote UML deve- se ao facto de este ser um elemento que permite conter outros elementos, como pacotes ou classes. A relação entre camadas, a relação allowed- to- use seria representada como uma dependência estereotipada. É sugerido a utilização de estereótipos, alterando a representação do pacote, para um rectângulo com sombra, de forma a diferenciar pacotes UML do conceito arquitectural de camada. Figura 15: Uma camada arquitectural representada como um pacote Documentar Relações de dependência A relação de A depends on B ou A depende de B, define uma dependência entre A e B. Esta relação é normalmente usada nas fases iniciais de processo de design, onde a forma precisa desta relação ainda está para ser definida. Quando a decisão é tomada, esta relação é 15

25 normalmente substituída por outra mais específicas como, uses no caso dos módulos e permitido- utilizar (allowed- to- use) no caso das camadas. Outras relações mais específicas podem ser definidas como, partilha- dados- com e calls. Sendo assim, não só é importante documentar a relação mais geral, dependência, como também ter em conta as mais específicas, uses e allowed- to- use. As relações de uses, A uses B, implicam que um módulo A, precise da correcta implementação de outro módulo B, para que A satisfaça os seus próprios requisitos e assim funcione correctamente. Esta relação poderá ter uma propriedade que descreve com mais detalhe que tipo de utilização um módulo faz de outro. As relações de allowed- to- use, definem uma relação binária entre módulos, ou seja, definem pares (A,B) de tal modo que a A é permitido usar B. Se A pode usar B, significa também que a camada onde se encontra o módulo A, poderá usar a camada onde se encontra o módulo B. Nestas relações existe também restrições de ordem topológica. Se uma camada A está acima de uma camada B, então a camada B não se pode encontrar acima de A. Cada pedaço de software está alocado apenas a exactamente uma camada. [5] Documentação de relações de dependência actualmente Actualmente as relações de dependência e suas derivadas (allowed- to- use e uses) são representadas através do conceito de dependência, sendo as derivadas representadas com uma dependência estereotipada [5] Figura 16: As relações de "allowed- to- use" e "uses" representadas como uma dependência UML [5] Documentar relações de agregação A relação de agregação ou é- parte- de ( is- part- of ) define uma relação de parte/todo entre um submódulo (a parte), e o modulo agregador (o todo). Na sua forma mais geral a relação é- - parte- de indica apenas agregação, com pouca implicação semântica. Em geral um módulo pode ser agregado por vários módulos. Esta relação pode ter formas mais fortes, como a decomposição. A relação de decomposição, que é uma especialização da agregação, poderá ter uma propriedade de visibilidade, que define se os submódulos são apenas visíveis ao módulo que os agrega ou também para outros módulos. Além disso, esta relação não permite ciclos, ou seja, nenhum módulo pode conter os seus antepassados, e também nenhum módulo pode ter mais que um pai. [5] 16

26 Documentação de relações de agregação actualmente Em [5] é apresentados duas estratégias para representar relações de agregação: 1. Uso do conceito aggregation kind 2. Uso de Pacotes Na primeira estratégia, a utilização do conceito de aggregation kind, é a forma mais comum de representar agregações, e representa- se colocando um símbolo em forma de diamante numa extremidade de uma associação. A segunda estratégia, a utilização de pacotes, advém do facto de estes elementos possuírem a capacidade de conter outros elementos. A figura 17 demonstra a utilização destas duas estratégias. Figura 17: As duas estratégias utilizadas para representar a relação de agregação [5] Documentar relações de generalização A relação de é- um ( is- a ), ou de generalização define uma relação entre um módulo mais específico, o filho, e o módulo mais geral, o pai. O filho pode ser utilizado nos contextos que o pai é utilizado. Generalização implica herança de interfaces e implementação. Sendo assim estas relações tem propriedades que permitem indicar se a herança é de interfaces ou de implementação. [5] Documentação de relações de generalização actualmente Para o caso do conceito de generalização, o que se verifica é que o conceito UML é adequado para a representação do conceito arquitectural. Caso seja necessário diferenciar a herança de interfaces, da herança de implementação, é sugerido que se utilize uma label indicando essa propriedade, como se mostra na figura

27 Figura 18: Os dois tipos de relação de Generalização [5] Documentar propriedades Apesar de ao longo desta análise ter- se referido já algumas maneiras de representar as propriedades dos conceitos envolvidos, é necessário olhar de uma forma mais pormenorizada para as formas de representação de cada uma delas. Sendo assim analisa- se as propriedades das relações e dos elementos das vistas módulos. Propriedades das relações: As propriedades das relações são diversas e dependem do tipo de relação que se está a analisar. No caso de relações de agregação, existe uma propriedade que indica se um submódulo é visível fora do módulo em que este está agregado. No caso das relações de dependência, estas podem ter restrições associadas de forma a especificar com maior detalhe o que é a relação entre os módulos. No caso da generalização (is- a) pode existir uma propriedade indicando se é uma herança de implementação ou de interfaces [5] Propriedades dos módulos: As propriedades dos módulos, podem variar consoante a necessidade do que se quer representar, mas geralmente incluem: Nome, Responsabilidades, Visibilidade das interfaces. O nome de um módulo pode sugerir diferentes coisas, entre elas a sua funcionalidade ou posição na hierarquia de decomposição. As responsabilidades de um módulo é uma maneira 18

28 de identificar qual a sua função dentro do sistema. O nome pode nos dar um indicativo da sua função, mas as responsabilidades assegura- nos com maior certeza da função do módulo. A visibilidade das interfaces indica de forma precisa o que é que esse módulo pode fazer dentro do sistema. [5] Propriedades das camadas: Se o elemento for uma camada terá: Nome da camada, Conteúdo da camada, Regras que determinam que software uma camada pode usar e as suas excepções, Coesão de uma camada A cada camada deverá ser atribuída um nome. Deverá ser indicado também quais os módulos que pertencem a uma dada camada. Além disso também deveremos ter regras de forma a identificar quais são as camadas, que uma camada pode utilizar, e quais as excepções às regras. Por fim, a coesão da camada fornece uma descrição da máquina virtual representada por essa camada. [5] [8] Documentação de propriedades actualmente Segundo [5], existem diferentes estratégias para documentar as propriedades dos diferentes elementos apresentados anteriormente, módulos, relações e camadas. No caso dos módulos, as propriedades necessárias representar são o nome, as suas interfaces e responsabilidades. O nome de um módulo é representado pelo nome do elemento escolhido para representar, neste caso, o nome da classe. As interfaces de um módulo são representadas pelo conceito UML interface. As responsabilidades são representadas com anotações. No caso das relações, só no caso da generalização é que se refere a utilização de uma label como forma de representar as diferentes propriedades, como se observa na figura 24. Para as restantes relações não há indicação de como representar propriedades. Por fim, no caso de o elemento ser uma camada, existem várias propriedades a ter em conta, nomeadamente, o nome da camada, a coesão da camada, e as suas interfaces. O nome da camada é dado pelo nome do elemento utilizado, como por exemplo o nome de o pacote. A coesão da camada tem a ver com o facto de os serviços fornecidos pela camada serem úteis como um grupo num outro contexto, além do que ele foi desenvolvido. Esta propriedade está dependente das regras de utilização entre camadas. É uma propriedade que não é directamente representada, mas sim inferida a partir do conhecimento do domínio e da experiência. As interfaces são representadas pelo conceito de interface UML Documentar Vistas de Alocação A vista de alocação documenta de que forma é que o hardware utilizado pelo sistema e a estrutura da equipa interagem. Isto tipo de documentação também é importante. É através da 19

29 documentação das interacções do hardware com a arquitectura que é possível analisar a performance do sistema; é através da relação entre estrutura da equipa e arquitectura que é possível planear as actividades do projecto. Sendo assim estas vistas apresentam um mapeamento dos elementos das vistas módulos e componentes e conectores, para elementos do ambiente (hardware, sistema de ficheiros, pessoas) Segundo a análise feita em [5], os conceitos a documentar numa vista de alocação são os seguintes: Elementos de software Elementos do ambiente Relação Alocado- a Relações migrar para Propriedades requeridas/fornecidas Elementos de Software Os elementos de software vêm das vistas módulos e componentes e conectores, e podem ser por exemplo, um processo de uma vista C&C ou um módulo de uma vista módulo. Estes possuem propriedades que dependem do propósito da alocação, mas que se podem classificar em propriedades requeridas e propriedades fornecidas. Exemplos destas propriedades poderão ser: aspectos de hardware (processamento, memória, tolerância a falhas) ou requisitos do ambiente de desenvolvimento [5] Documentação de elementos de software actualmente No UML 1.4 não existe o conceito de elemento de software. Sendo assim teremos de recorrer a outros conceitos que possam de alguma forma representa- lo. A notação para estes elementos varia consoante o estilo que se esteja a considerar. No caso de um estilo de deployment, estes podem ser representados através de componente UML. Para os outros estilos não são apresentadas outras possibilidades. [5] Um exemplo de esta notação pode ser encontrado na figura Elementos do Ambiente Um elemento do ambiente representa elementos como um processador, um disco, um item de configuração (ficheiro ou directório), pessoas ou um grupo de desenvolvimento, dependendo do estilo da vista que se considera. Tal como os elementos de software, possuem diferentes propriedades que variam consoante o propósito da alocação. Algumas destas propriedades são: propriedades do CPU, propriedades da memória, largura de banda, requisitos de recursos e restrições a serem satisfeitas, características fornecidas pelos ambientes de desenvolvimento ou um conjunto de capacidades de um grupo de pessoas. [5] 20