Desenvolvimento de Software Centrado no Domínio

Transcrição

1 Desenvolvimento de Software Centrado no Domínio O caso da Distribuição do Serviço Docente João Sitefane Universidade Técnica de Lisboa, Instituto Superior Técnico 1 Introdução Hoje em dia, parte significativa da produção de novo software rege-se por um processo de desenvolvimento de software [Pfl01]. Este processo pode ser definido como uma série de actividades, realizadas com a finalidade de obter um produto de software que responda às necessidades do seu utilizador final. Todo o software está relacionado com alguma área de interesse do seu utilizador final. Esta área, juntamente com as entidades que a constituem, forma o domínio do software. De modo geral, durante um processo de desenvolvimento de software realizam-se as seguintes actividades: Análise. Engloba o levantamento e análise dos requisitos para o software; Desenho. Realização da descrição rigorosa e precisa do software a ser produzido. Esta descrição define um modelo onde estão presentes os vários componentes do software, as suas propriedades e as relações entre eles; Implementação. Transformação do desenho em código fonte; Teste. Verificação de que o programa desenvolvido na fase anterior apresenta o comportamento correcto e cumpre todos os requisitos estabelecidos; e, Manutenção. Visa corrigir novos problemas que são descobertos após o produto ser disponibilizado ao cliente, assim como a integração de novas funcionalidades derivadas do aparecimento de novos requisitos. 1.1 Definição do Problema Na actividade de desenho descreve-se a estrutura final que o software irá ter. Esta descrição assinala a passagem do espaço do problema para o espaço da solução. Contudo, quando o domínio do software é de complexidade bastante elevada, esta passagem pode ser feita de forma incorrecta, caso: 1) O desenho esteja desenquadrado com o domínio do software; ou, 2) A transformação do desenho em código revele-se numa tarefa demasiado complexa de realizar. Estas dificuldades determinam o insucesso do desenho e inviabilizam o sucesso das restantes actividades do processo. A superação destas dificuldades é facilitada caso a abordagem ao domínio seja feita com recurso a técnicas que facilitem o desenvolvimento de software em domínios de elevada complexidade. Para tal, o desenho centrado no domínio [Eva03] propõe um conjunto de princípios e linhas de orientação que devem estar presentes durante a actividade de desenho de software Distribuição do Serviço Docente A abordagem ao desenho centrado no domínio será discutida num contexto da aplicação Distribuição do Serviço Docente (DSD) [SK06], que se encontra integrada no sistema Fénix [PF05]. Esta aplicação foi desenvolvida com o objectivo de disponibilizar uma ferramenta informática, acessível a todos os departamentos do Instituto Superior Técnico (IST) [IST], a partir da qual fosse possível realizar o processo de distribuição do serviço docente, ou seja, afectar recursos humanos para o ensino de disciplinas. A figura 1 mostra a versão inicial do modelo de domínio da aplicação DSD. 1

2 Figura 1. Versão inicial do modelo de domínio da aplicação DSD. A principal limitação da aplicação está relacionada com a qualidade do seu desenho. O desenho, no seu estado actual, apresenta os seguintes problemas: Fraca ligação entre o desenho e o domínio. Alguns componentes do desenho não se enquadram de um modo natural e intuitivo com os demais componentes e com o próprio domínio da aplicação. Esta desconexão do desenho com o domínio faz com que, para alguns componentes, seja necessário olhar-se para a sua implementação para se conseguir ter uma ideia dos conceitos do domínio que representam; Sobreposição de conceitos. Existem noções do domínio que se encontram sobrepostas dentro do mesmo componente do modelo. Cada conceito do domínio deve estar decomposto numa unidade individual, para que se consiga identificar facilmente qual o conceito do domínio expresso por cada classe do modelo; e, Falta de flexibilidade. Após o desenvolvimento da aplicação houve uma evolução do domínio ao nível da estrutura curricular das disciplinas. Com a nova estrutura curricular de Bolonha [Bol99] surgiram novos tipos de aula (como, por exemplo, seminários), que dificilmente se conseguem representar com o modelo actual da aplicação. O modelo deve ser reestruturado de maneira a que se obtenha uma solução que permita representar os tipos de aula de um modo flexível e, ao mesmo tempo, facilmente extensível. A correcção destes problemas requer que sejam feitas reestruturações ao nível dos componentes da aplicação. Alguns componentes deverão ser eliminados, outros terão de ser criados. Relações entre componentes também serão modificadas. Assim, torna-se necessário reproduzir a descrição de como os diferentes componentes da aplicação operaram em conjunto, ou seja, torna-se necessário redesenhar o software. 1.2 Objectivos O objectivo principal consistiu em seguir a abordagem do desenho centrado no domínio durante o processo de revisão do desenho da aplicação DSD. Este objectivo foi decomposto nos seguintes objectivos instrumentais: 2

3 Descrição e discussão dos princípios associados ao desenho centrado no domínio; Avaliação da aplicabilidade de cada princípio do desenho centrado no domínio à aplicação DSD; e, Reestruturação da aplicação DSD de acordo com as linhas de orientação do desenho centrado no domínio. 2 Desenho Centrado no Domínio Das diversas actividades do processo de desenvolvimento de software, o desenho corresponde à actividade durante a qual ocorre a passagem do espaço do problema para o espaço da solução. Quando o espaço do problema é de complexidade bastante elevada, a criação de software que represente uma mais-valia para o negócio do seu utilizador final pode tornar-se numa tarefa demasiado exigente. A equipa responsável pelo desenvolvimento pode ser incapaz de gerir o volume e a complexidade de informação associados à tarefa. O desenho centrado no domínio é a ferramenta adequada a usar para diminuir este tipo de sobrecarga. O desenho centrado no domínio pode ser encarado como um conjunto de princípios e linhas de orientação, desenvolvidos com o objectivo de acelerar e facilitar o processo da passagem do espaço do problema para o espaço da solução em domínios de elevada complexidade. 2.1 Relevância do Modelo de Domínio Todos os programas de software estão relacionados com alguma actividade ou área de interesse do seu utilizador final. A área associada a um programa, as entidades que a constituem e as relações existentes entre elas formam o domínio do programa. O modelo de domínio pode ser entendido como uma abstracção do domínio, construída com o intuito de resolver problemas associados a esse domínio. Um modelo bem definido estrutura, de forma simples e clara, toda a sua informação em torno do respectivo domínio. No desenho centrado no domínio, a importância do modelo de domínio pode ser medida através de três factores fundamentais: Ligação entre desenho e implementação. O modelo, o processo de desenho e a implementação devem estar interligados. É esta ligação que torna o modelo relevante e garante que todo o esforço que foi dispendido na construção do modelo é reflectido no produto final. Esta ligação também é importante durante a actividade de manutenção, uma vez que o código e restantes artefactos podem ser interpretados com base no modelo; Comunicação. O modelo deve ser o suporte para o uso de uma linguagem comum, usada por todos os membros da equipa. Devido à ligação existente entre o modelo e a implementação, os membros da equipa responsáveis pela implementação podem comunicar com os membros responsáveis pelo desenho e modelação através desta linguagem comum. Desta forma, evita-se a necessidade da existência de algum tipo de mecanismo de tradução entre os conceitos usados pelos membros das diferentes áreas da equipa de desenvolvimento; e, Partilha de conhecimento. O modelo pode ser visto como um acordo feito por todos os membros da equipa, onde se escolhe uma forma de pensar sobre o domínio, à medida que se definem conceitos e as relações entre eles. A linguagem comum resultante do modelo permite uma partilha eficaz de conhecimento entre todos os elementos da equipa. 2.2 Aplicação do Desenho Centrado no Domínio Os princípios do desenho centrado no domínio serão abordados nos próximos capítulos, divididos pelos seguintes contextos: Construção do modelo de domínio. Um modelo de domínio obtido através do desenho centrado no domínio está assente sobre um conjunto de blocos (entidades, valores, agregações, etc.) que permitem manter a implementação de software alinhada com o modelo; e, Refactorização. Este processo consiste em alterar um sistema de software para que a sua estrutura interna seja melhorada, sem modificar o seu comportamento externo. Trata-se de um 3

4 processo contínuo e pode ocorrer sempre que seja possível extrair um modelo mais simples e focado nos conceitos do domínio. 3 Construção do Modelo de Domínio Para manter a implementação de software alinhada com o modelo de domínio é necessário aplicar as melhores práticas de desenho e modelação. Quando estas práticas não são aplicadas, torna-se difícil obter um modelo onde os conceitos do domínio estejam expressos de forma natural e intuitiva. Para tornar o desenho centrado no domínio resistente a este tipo de ocorrências, é necessário ter-se um profundo conhecimento dos princípios que suportam a construção de um modelo de domínio. Ao longo deste capítulo serão abordados alguns desses princípios: entidades, valores, serviços e fábricas. 3.1 Entidades e valores Alguns objectos devem ter uma identidade que os permite distinguir dos restantes objectos do modelo. Para este tipo de objectos tem de ser possível efectuar a distinção em relação a outros objectos que apresentem exactamente os mesmos atributos. Para ser possível efectuar esta distinção, é necessário associar uma identidade única a este tipo de objectos. Um objecto que é definido univocamente pela sua identidade é designado de entidade [Eva03]. As entidades têm características próprias dentro do modelo. As responsabilidades e associações que uma entidade possui devem ser baseadas na sua identificação e não nos valores dos seus atributos. Existem outros tipos de objectos, com características próprias, que também têm um papel relevante no modelo. Contudo, ao contrário das entidades, este tipo de objectos não tem uma identidade única e o seu principal propósito consiste em representar aspectos descritivos do domínio. Um valor [Eva03] é criado para representar os elementos do desenho que apenas se preocupam com o que são e não com quem são. Por exemplo, de um modo geral, uma cor ou um número correspondem a um valor. Não interessa saber qual o vermelho ou o 4 com o qual estamos a lidar, apenas interessa o seu valor. Assim, quando existe uma preocupação apenas com os atributos de um objecto, este deve ser classificado como valor. A separação entre entidade e valor (figura 2) pode ser obtida através do padrão de desenho Extract Class [FBB+99]. Este padrão é aplicável quando estamos na presença de classes com atributos que desviam-se do conceito que representam. Neste caso, os atributos não pertencentes à classe devem ser agrupados numa nova classe e deve ser criada uma relação de associação entre os dois elementos. Figura 2. Separação entre valor (Morada) e entidade (Cliente), através do padrão Extract Class. 3.2 Serviços Existem operações do domínio que não pertencem, de um modo natural, a uma entidade ou valor. Frequentemente, tenta-se solucionar este problema inserindo estas operações dentro de um objecto do modelo. Quando uma operação é inserida dentro de um objecto de forma forçada, este perde a sua clareza conceptual, tornando-se assim mais difícil perceber qual o conceito do domínio expresso no objecto. A solução para este tipo de problemas passa pela criação de um serviço. Um serviço [Eva03] é definido como uma operação, oferecida como uma interface presente no modelo, que não encapsula estado, ao contrário das entidades ou valores. Um serviço deve receber o seu nome com base na 4

5 actividade que vai desempenhar. Os seus parâmetros e resultado devem ser objectos do domínio. Um serviço está correctamente presente dentro de um modelo se respeitar três características fundamentais: A sua operação relaciona-se com um conceito do domínio que não faz parte natural de uma entidade ou valor; A sua interface é definida com base em outros elementos do modelo; e, A sua execução não mantém qualquer tipo de estado, ou seja, a execução de um serviço depende exclusivamente da informação que está guardada em outros objectos do domínio. 3.3 Fábricas A tarefa de criação de objectos é da responsabilidade da camada de domínio. Contudo, esta tarefa não deve ser exclusiva a cada objecto do domínio. Por vezes, é necessário a existência de mecanismos mais abstractos para a criação de objectos, que estejam desligados dos próprios objectos. Um elemento cuja responsabilidade consiste na criação de objectos é designado de fábrica [Eva03]. Tal como a interface de um objecto encapsula a sua implementação, permitindo saber o que faz o objecto sem revelar como o faz, uma fábrica encapsula a lógica necessária para a criação de objectos complexos ou agregações. Esta noção de fábrica está directamente relacionada com o padrão Abstract Factory [GHJV95], uma vez que este também tem o intuito de disponibilizar uma interface para a criação de famílias de objectos dependentes. Figura 3. Interacção de um cliente com uma fábrica. 3.4 Aplicação dos princípios Serviços A classe ValuationPhase é a mais longa do domínio da aplicação DSD (no sentido de que é a classe que apresenta mais linhas de código na sua implementação). Esta classe não representa o conceito de domínio mais complexo, mas mantém a lógica de duas operações complexas: Atribuição de docentes a disciplinas com base nos valores do ano lectivo anterior. Uma das formas possíveis de atribuir horas de ensino aos docentes de uma distribuição é através da cópia das horas de ensino apresentadas no ano lectivo anterior; e, Cópia de uma fase. Esta acção requer que sejam copiados todos os objectos contidos numa fase: o agrupamentos (ValuationGrouping), os respectivos docentes (ValautionTeacher) e disciplinas (CourseValuation) e as atribuições de docentes a disciplinas (ProfessorshipValuation).. Estas duas operações transcendem a classe ValuationPhase, na medida em que a sua lógica se foca toda sobre uma série de outras entidades do domínio (do interior e do exterior do módulo DSD). As operações não pertencem a ValuationPhase nem a qualquer outra classe; pertencem ao domínio da aplicação DSD e, por isso, deve estar presente no modelo sob a forma de serviços. Assim, criaram-se dois serviços, CopyValuationPhaseService e CopyLastYearRealDataService, para, respectivamente, a cópia de fases e atribuição de docentes a disciplinas com base nos valores do ano lectivo anterior. A criação destes serviços permitiu isolar as operações do domínio que não pertenciam, de um modo natural, à classe ValuationPhase. Como consequência, conseguiu-se melhorar a clareza conceptual apresenta pela classe. 5

6 3.4.2 Fábricas Na aplicação DSD, quando se cria uma nova fase (ValuationPhase), é necessário criar a árvore de agrupamentos e sub-agrupamentos de docentes e disciplinas (ValuationGrouping) que retratam as divisões existentes nos departamentos ao nível de secções, áreas científicas e grupos de competência. A lógica necessária para realizar essa tarefa é despoletada pelo pelo método construtor da classe ValuationPhase e estende-se por várias classes do domínio. Com esta solução, toda a complexidade envolvida na construção de agrupamentos está dependente de ValuationPhase. Assim, além de representar um conceito do domínio (a fase de uma distribuição), ValuationPhase tem de se preocupar em manter a lógica de criação de uma rede complexa de outros objectos do domínio. Seria vantajoso usar-se o conceito de fábrica para encapsular numa entidade toda a lógica necessária para a criação de agrupamentos e sub-agrupamentos de disciplinas. Esta motivação revela-se suficiente para criar uma nova fábrica ValuationGroupingFactory responsável pela criação de novos agrupamentos. 4 Refactorização A refactorização consiste no processo de alterar um sistema de software para que a sua estrutura interna seja melhorada, sem modificar o seu comportamento externo [FBB+99]. Quando se efectua uma refactorização está-se a melhorar o desenho de software que já foi escrito. O processo de refactorização é contínuo e pode ocorrer desde o início do desenvolvimento de um projecto. Para tal, existe um conjunto princípios que devem ser iterativamente aplicados, para que, em cada iteração, seja possível extrair um modelo mais simples e claro e mais focado nos conceitos do domínio. Ao longo deste capítulo serão abordados alguns desses princípios: interfaces reveladoras de intenção e decomposição de conceitos. 4.1 Interfaces reveladoras de intenção Num modelo de domínio, uma classe é caracterizada através do seu nome, juntamente com os nomes dos seus atributos e dos métodos que disponibiliza. O conjunto destes nomes define a interface do objecto, ou seja, define a forma como ele se apresenta e comunica com as outras entidades do domínio. As classes e seus métodos e atributos devem ser nomeados de forma a descrever correctamente os seus propósitos, sem referência aos meios através dos quais realizam as suas actividades. Um objecto que pertença a uma classe que respeite estas características contém uma interface reveladora de intenção [Eva03]. Estas características evitam a necessidade de perceber-se a estrutura interna de um objecto, para conseguirem usá-lo. Os nomes presentes nas interfaces dos objectos devem ser intuitivos, para que o respectivo conceito de domínio seja facilmente inferido por qualquer pessoa. Existem diversos padrões de refactorização que podem ser aplicados para a obtenção de interfaces reveladoras de intenção, como é o caso do Rename Method [FBB+99]. De acordo com este padrão, deve renomear-se qualquer método cujo nome não revele correctamente a sua intenção. Esta linha de raciocínio também pode ser generalizada para o nome de classes dos seus atributos. A figura 4 exemplifica a transformação de uma classe para a obtenção de uma interface reveladora de intenção. Figura 4. Exemplo de interface reveladora de intenção. 6

7 4.2 Decomposição de conceitos Num extremo, os domínios de elevada complexidade podem originar a aglomeração de conceitos dentro da mesma classe. No outro extremo, a divisão exagerada de conceitos por vários objectos dificulta a percepção de como todos aqueles pequenos pedaços funcionam em conjunto. É importante que exista um equilíbrio entre os elementos do modelo e os conceitos do domínio que representam. Uma classe do modelo deve corresponder a uma abstracção de um conceito do domínio. Os elementos de domínio (entidades, valores e serviços) devem ser decompostos em unidades coesas, com o intuito de obter-se uma divisão que espelhe de forma correcta e consistente as fronteiras e relações existentes entre os conceitos do domínio. A decomposição de conceitos pode ser obtida através dos padrões Extract Method e Extract Subclass [FBB+99]. De acordo com o padrão Extract Method, quando existem fragmentos de código que podem ser agrupados, então estes devem ser isolados dentro de um novo método. Caso estes fragmentos estejam presentes em vários métodos, então a criação do novo método permite eliminar situações de replicação de código. Por sua vez, o padrão Extract Subclass pode ser usado quando estamos na presença de classes com atributos usados apenas por algumas instâncias. Neste caso, deve ser criada uma subclasse que herda as características essenciais da classe e implementa as suas próprias características específicas (figura 5). Figura 5. Decomposição de conceitos através do padrão Extract Subclass. Neste cenário, a classe Produto continha o atributo promoção, apenas usado por produtos em promoção. Para saber se um produto estava ou não em promoção era necessário testar o valor desse atributo. Deste modo, Produto representava dois conceitos do domínio, consoante o valor dos seus atributos. Uma solução mais coerente com o domínio seria criar uma especialização de produto, ProdutoPromocional, com as suas características próprias, como o valor de promoção. Assim, obtém-se uma solução elegante para a separação entre os conceitos produto e produto promocional. 4.3 Aplicação dos princípios Interfaces reveladoras de intenção Renomearam-se todas as classes do módulo da aplicação (o que, por sua vez, implicou a renomeação da maior parte dos métodos e atributos), como forma de obter interfaces reveladoras da intenção. Este conjunto de alterações permitiu fortalecer a ligação entro o desenho da aplicação e o domínio correspondente Decomposição de conceitos A decomposição de conceitos foi aplicada sobre várias classes do modelo de domínio da aplicação DSD. O primeiro caso de decomposição de conceitos foi feito sobre TSDTeacher. Esta classe representa dois conceitos, o docente real e o docente a contratar, consoante apresente ou não uma ligação com Teacher. Esta sobreposição de conceitos replica pelos métodos da classe a necessidade de se averiguar qual o tipo de docente (figura 6). 7

8 If(getTeacher() == null){ // código para docente a contratar... } else { // código para docente real... } Figura 6. Exemplo da lógica presente nos métodos de TSDTeacher, como consequência da classe representar dois conceitos do domínio. Se, no futuro, surgir um terceiro conceito de docente, então a lógica de distinção entre docentes ficará ainda mais complexa. Este problema foi solucionado com a decomposição de conceitos. Criaram-se dois novos tipos de docente, TSDRealTeacher e TSDVirtualTeacher, como resultado da especialização de TSDTeacher (figura 7). Assim, as noções de docente real e virtual ficam isoladas nos respectivos objectos do domínio. Figura 7. Decomposição de TSDTeacher. O segundo caso de decomposição de conceitos foi feito sobre ValuationCompetenceCourse e ValuationCurricularCourse. Estas classes criam uma abstracção em relação ao tipo das disciplinas (reais ou criadas pelos utilizadores) que estão nos agrupamentos. Tal como no caso de TSDTeacher, a sobreposição de conceitos existentes nestas classes origina a replicação de código pelos métodos das classes (como ilustrado na figura 6). À semelhança da motivação para a criação de TSDVirtualTeacher, o conceito de uma disciplina virtual (criada pelos utilizadores) deveria consistir numa especialização de TSDCourse. Por este motivo, eliminaram-se as classes ValuationCompetenceCourse e ValuationCurricularCourse do modelo e definiu-se o conceito de disciplina virtual numa nova subclasse de TSDCourse: TSDVirtualCourseGroup (figura 8). Figura 8. Criação de TSDVirtualCourseGroup. O terceiro caso de decomposição de conceitos foi feito sobre TSDCourse. Nesta classe guardava-se a informação sobre estimativas feitas, para quatro tipos de aula: teóricas, práticas, teórico-práticas e laboratoriais. Esta variedade de tipos de aula originou a multiplicação de métodos semelhantes (figura 5.9). 8

9 public Integer gettotalnumberoftheoreticalstudents(){... } public Integer gettotalnumberofpraticalstudents(){... } public Integer gettotalnumberoftheopratstudents(){... } public Integer gettotalnumberoflaboratorialstudents(){... } Figura 9. Exemplo da multiplicação de métodos pelo tipo de aula existentes. Para evitar esta multiplicação de código criou-se uma nova classe, TSDCurricularLoad, que representa a carga curricular de um tipo de aula para a disciplina. Com a introdução desta classe e a aplicação do padrão Parameterize Method [FBB+99] foi possível reduzir o número de métodos existentes, através da criação de métodos parametrizados (figura 10). public Integer gettotalnumberofstudentspershifttype(shifttype shifttype){... } Figura 10. Aplicação do padrão Parameterize Method para a criação de métodos parametrizados. A solução adoptada aumenta a flexibilidade apresentada pelo modelo, uma vez que para a criação de um novo tipo de aula basta criar uma relação de TSDCourse com um novo tipo de TSDCurricularLoad (figura 11). Figura 11. Decomposição de TSDCourse. 5 Resultados 5.1 Redesenho da aplicação DSD Foi feita a revisão do desenho da aplicação DSD, de acordo com as linhas de orientação do desenho centrado no domínio. A figura 12 mostra a situação do modelo de domínio da aplicação após as modificações introduzidas. Figura 12. Versão final do modelo de domínio da aplicação DSD. 9

10 As figuras 1 e 12 mostram o antes e o depois do modelo de domínio da aplicação. As alterações introduzidas permitiram obter as seguintes (principais) vantagens: A construção do modelo de domínio permitiu identificar o papel desempenhado por cada entidade do modelo. A criação de fábricas e serviços permitiu isolar as operações do domínio que não pertenciam, de um modo natural, a uma entidade ou valor. Como consequência, conseguiu-se melhorar a clareza conceptual apresenta pelas classes do modelo; e, A refactorização permitiu alterar a estrutura interna do modelo e, assim, extrair um modelo mais simples, claro e focado nos conceitos do domínio. A ligação entre o desenho e o domínio foi fortalecida com recurso a interfaces reveladoras de intenção e a decomposição de conceitos permitiu eliminar a sobreposição de conceitos e aumentar a flexibilidade apresentadas pelo modelo. 5.2 Implementação do novo desenho da aplicação DSD Foi implementado o novo desenho da aplicação DSD, que fica assim alinhado com os princípios do desenho centrado no domínio. O novo desenho permitiu ultrapassar os problemas apresentados pela versão inicial: 1) Fraca ligação entre o desenho e o domínio; 2) Sobreposição de conceitos; 3) Falta de clareza conceptual; e, 4) Falta de flexibilidade. Referências [Bol99] Declaração dos Ministros Europeus da Educação: The Bologna Declaration of 19 June Bolonha, [Eva03] Evans, Eric: Domain-Driven Design: Tackling Complexity in the Heart of Software. Addison Wesley, [FBB+99] Fowler, Martin, Beck, Kent, Brant, John, Opdyke, William, & Roberts, Don: Refactoring: Improving the Design of Existing Code. Addison Wesley, [GHJV95] Gamma, Erich, Helm, Richard, Johnson, Ralph, & Vlissides, John: Design Patterns: Elements of Reusable Object-Oriented Software. Addison Wesley, [IST] Instituto Superior Técnico. [PF] Projecto Fénix. [PF05] Projecto Fénix. Overview do sistema Fénix, [Pfl01] Pfleeger, Shari: Software Engineering: Theory and Practice (2nd Edition). Prentice Hall, [SK06] Sitefane, João & Kassamali, Anil: Fénix Departamento. Relatório de Trabalho Final de Curso, Instituto Superior Técnico, Universidade Técnica de Lisboa,