Steam Reforming and Ammonia Production

§ Coad e Yourdon [Coad91]: uma abstracção de qualquer coisa no domínio de um problema, reflectindo a capacidade do sistema de manter informação sobre ele e de interagir com ele; é um encapsulamento de valores de atributos e dos seus serviços exclusivos.

§ Rumbaugh [Rumbaugh91]: um objecto é um conceito, abstracção ou coisa com fronteiras bem definidas e com significado para o problema em questão; promove a reutilização e funciona como uma base concreta para a respectiva implementação em software.

§ Shlaer e Mellor [Shlaer88]: um objecto é uma abstracção de um conjunto de coisas do mundo real de tal forma que todos os elementos do conjunto (instâncias) têm as mesmas características e respeitam as mesmas regras e políticas.

Resumidamente, e de forma a integrar estas diversas definições, podemos dizer que os objectos representam entidades físicas, conceptuais ou apenas necessárias para a representação em computa- dor (por exemplo, estruturas de dados); um objecto pode ser um concei- to, uma abstracção ou uma entidade, com fronteiras bem definidas e que tem um significado para um problema e respectiva solução; um objecto tem estado, comportamento e identidade.

Alguns autores enumeram as fontes onde pesquisar os possíveis candidatos a objectos, independentemente do problema a solucionar: § Shlaer e Mellor: entidades e coisas tangíveis, funções de pessoas,

organizações, incidentes, eventos, interacções, especificações. § Coad e Yourdon: estruturas, outros sistemas, dispositivos, coisas ou

acontecimentos memorizados, funções desempenhadas, procedi- mentos operacionais, locais geográficos, unidades organizacionais. Os atributos são propriedades nomeadas de um objecto que indicam os valores possíveis que esse atributo pode assumir ao longo do tempo; o estado de um objecto é definido pelo valor dos seus atributos.

O comportamento de um objecto é definido como o conjunto de acções que um objecto pode realizar de forma independente. Normalmente existem dois termos para referir os mecanismos utilizados para implementar este conceito: ao nível da análise o termos mais utilizado é o de operação ou serviço, enquanto o termo método se

refere normalmente à implementação de uma operação ao nível da programação. A maioria das operações realizadas responde a pergun- tas ou alteram o estado do objecto. Na prática, implementam um serviço e/ou funcionalidade que pode ser requerido por qualquer objecto que faça parte do universo do problema.

Para melhor compreendermos os conceitos de estado e de comporta- mento, utilizemos o exemplo de uma conta bancária. Neste caso, o seu estado é determinado pelos valores assumidos pelos atributos que são necessários para a caracterizar - titular, saldo - enquanto que o seu comportamento é determinado pelos serviços que disponibiliza para outros objectos interagirem com ela, nomeadamente depositar dinheiro, levantar dinheiro e consultar o saldo da conta.

As classes são descrições de grupos de objectos com propriedades (atributos), comportamento (operações) e relações comuns. É uma das concretizações do conceito abstracção no paradigma da orientação por objectos. Uma classe pode ser vista como template para um determi- nado objecto e todos os que lhe forem semelhantes, ou como uma fábrica, que produz tantos objectos idênticos quanto necessário.

Em geral, os atributos permitem identificar a classe, definir as características especiais da classe, definir o estado da classe, reter alguma informação sobre a classe e identificar o comportamento do objecto. Para especificar detalhadamente um atributo deve-se identificar o domínio dos seus valores, as unidades de medida, o valor por omis- são, o valor inicial, as condições de leitura e escrita e eventuais condi- ções relacionadas com outros atributos do objecto ou da classe.

Dado um enunciado de um problema, a análise orientada por objectos procura identificar os objectos concretos e as respectivas classes, a partir de todos os substantivos que dele sejam extraídos. O seu objec- tivo último será sempre identificar:

§ Um conjunto de classes que representem totalmente o domínio do problema.

§ Os atributos de cada classe.

§ A interface e os serviços de cada classe. § As diversas relações entre classes.

PARTE 2 – LINGUAGEM DE MODELAÇÃO UML

9 3

Cada metodologia propõe diferentes formas de chegar a esta informação, e normalmente referem alguns critérios. Por exemplo, [Coad91] indica um conjunto de questões a colocar, de modo a averi- guar se um substantivo do enunciado constitui um objecto ou classe: § A informação sobre o objecto tem que ser retida de modo a que o

sistema funcione adequadamente?

§ O objecto realiza operações que alteram atributos de outros objec- tos?

§ O objecto tem mais do que um atributo?

§ Outros objectos aparentemente idênticos disponibilizam operações idênticas?

§ O objecto produz ou consome informação essencial para o funciona- mento do sistema?

Noutras situações, são indicadas checklists de circunstâncias em que um potencial objecto não o deve ser, por exemplo:

§ Objectos ou classes com apenas um atributo. § Classes com apenas um objecto.

§ Objectos ou classes sem serviços aplicáveis, ou que não produzem um resultado visível para o problema em análise.

§ Objectos ou classes que não sejam relevantes para a solução do problema.

§ Objectos ou classes que de facto correspondem a atributos de outros objectos.

Se considerarmos novamente o enunciado do exemplo da gestão de compras, podemos verificar que a nossa pesquisa passa a incidir sobre outras palavras (substantivos em vez de verbos), devido à mudança de paradigma e aos conceitos base fundamentais que lhes estão subjacen- tes (objectos em vez de processos).

Pensemos no caso da gestão de compras de materiais de uma empresa. Sempre que algum funcionário tem necessidade de comprar bens para as suas actividades, este preenche uma requisição onde identifica os bens em questão (com base na consulta de uma lista anteriormente disponibilizada a todos os funcionários), a qual envia para o seu director. Este, depois de analisar o pedido, pode ou não autorizar o mesmo. Neste segundo caso, o requisitante recebe uma notificação, e o processo pára. No caso do pedido ser aprovado, o requisitante preenche uma encomenda que envia para o fornecedor por ele selec- cionado.

A entrada dos bens ocorre sempre no armazém, onde é conferido o material recebido com a guia de remessa que o acompanha, bem como a(s) encomenda(s) que lhe deram origem (uma encomenda pode ser satisfeita de várias vezes). Após a última entrega, que completa a encomenda, a empresa confere a factura que entretanto lhe foi sido enviada, relaciona-a com as encomendas respectivas, e se tudo estiver correcto, é emitido um meio de pagamento ao fornecedor (poderá ser em cheque ou por transferência bancária).

As operações realizadas por objectos podem ser identificadas pela pesquisa no enunciado do problema de verbos associados a cada ob- jecto. Essas operações podem ser agrupadas nas seguintes categorias: § Modificadores: operação que altera o estado de um objecto.

§ Selectores: operação que acede ao estado de um objecto.

§ Iteradores: operação que permite que todas as partes de um objecto sejam acedidas segundo uma ordem bem definida.

§ Construtor: cria um objecto e/ou inicializa o seu estado. § Destrutor: liberta o estado de um objecto ou destrói-o.

Os objectos funcionam como caixas negras, isto porque "escondem" os detalhes da sua implementação aos objectos que a utilizam; o acesso aos objectos é efectuado através da interface por eles disponibilizada, composta por operações e por atributos. Os objectos comunicam entre

PARTE 2 – LINGUAGEM DE MODELAÇÃO UML

9 5

si por mensagens, que não são mais do que a invocação de um método com o mesmo nome, no contexto do objecto receptor da mensagem.

Figura 3.7: Modelo de comunicação entre objectos por mensagens.

Na prática, este modelo não é mais do que a invocação de uma função, tal como nas abordagens tradicionais; a diferença é que esta invocação é realizada no contexto de um objecto, o que significa que tem em conta o seu estado, traduzido nos valores que os seus atributos assumem. Por isso, o mesmo método executado com os mesmos parâmetros sobre objectos diferentes, mas ambos instâncias da mesma classe, pode produzir resultados diferentes, como se verifica no exemplo se- guinte. Classe classeA { public: int x; int y;

int soma() { return (x + y ) ;} } ... classeA a; classeA b; a.x = 10 ; a.y = 20 ;

b. x = 5 ; b.y = 8 ; ...

a.soma => obtem-se o valor 30 b.soma => obtem-se o valor 13

Este conceito de comunicação por mensagens pode ser visto de forma tão abstracta que mesmo a soma de dois números pode ser encarada como uma operação de envio de uma mensagem a um objecto. Por exemplo na operação 3 + 4, 3 é o objecto receptor da mensagem, que é formada pelo selector + (que identifica o método a invocar no objecto receptor) e pelo objecto argumento 4. Uma mensagem é sempre formada por um selector e opcionalmente por um conjunto de parâme- tros.

A interface é o conjunto de operações e atributos disponibilizados por uma classe, que consoante a visibilidade se pode dividir em três partes: pública (visível para todos os objectos do sistema); protegida (só visível pelas suas subclasses); privada (faz parte da interface mas não é visível para nenhuma outra classe do sistema, só está disponível na implemen- tação da própria classe).

PARTE 2 – LINGUAGEM DE MODELAÇÃO UML

9 7

Entre as diversas classes de um sistema podem ser estabelecidas diferentes tipos de relações:

§ Associação: representam relações estruturais entre objectos de classes diferentes, e cuja informação que tem que ser preservada durante algum tempo; é expressa pelo verbo ter; podem-se sub- dividir em

§ Agregação: é a conhecida relação entre o todo e as partes (whole-

part); um exemplo possível é a relação "uma empresa tem empre-

gados".

§ Composição: forma de agregação em que a relação de pertença é forte e com tempos coincidentes; o objecto agregador é responsável pela criação e destruição do objecto que entra na sua composição; uma concretização desta relação é dizer que "o corpo humano tem uma perna".

§ Dependência: relação em que uma mudança de estado num objecto (ocorrida pela recepção de uma mensagem) pode implicar o envio de uma mensagem a outro objecto; por exemplo, um automó- vel, para andar, precisa de se abastecer na bomba de gasolina. § Generalização/Especialização: relações entre classes que

partilham a estrutura e comportamento; implementam o conceito de herança, que pode ser simples (uma classe tem apenas uma superclasse) ou múltipla (uma classe pode ter várias superclasses); esta relação é expressa pelo verbo ser, como no caso "um cão é um animal".

Algumas abordagens orientadas por objectos procuram definir conceitos que permitem agrupar classes; por exemplo, Wirfs-Brock considerou que um sub-sistema é um conjunto de classes (ou de outros sub- sistemas) que colaboram entre si para realizar um conjunto de responsabilidades. Não existem na prática, mas permitem a criação de entidades conceptuais úteis. Coad e Yourdon definem o conceito de assunto (subject) de forma idêntica. NO caso do UML, o utiliza-se o conceito de pacote com um fim idêntico. O principal objectivo deste tipo de conceitos é facilitar a compreensão da globalidade do sistema, ao agrupar outros conceitos relacionados.

3.5.3 Técnicas e Notações mais Utilizadas

A proliferação das metodologias que tinham como base os conceitos da orientação por objectos levou ao aparecimento de diversas notações e técnicas de modelação, que muitas vezes são partilhadas entre várias delas. Os recentes esforços de unificação permitiram que algumas des- sas técnicas se tenham destacado.

As principais notações utilizadas estão praticamente todas presentes na metodologia da Rational, e fazem parte da linguagem de modelação UML, pelo que serão apresentadas detalhadamente nos capítulos que constituem a Parte 2 deste livro. Resumidamente, indicamos de seguida as principais notações a considerar:

§ Diagrama de casos de utilização § Diagrama de classes § CRC (Class-Relationship-Collaboiration) cards § Diagrama de pacotes § Diagrama de estados § Diagramas de interacção § Diagrama de actividades § Diagrama de eventos § Diagrama de contexto § Diagrama de fluxo de dados.

Independentemente dos nome dos diagramas utilizados por cada metodologia, cada uma apresenta notações para modelar a visão estática do sistema (a estrutura dos objectos, relações de agregação e de especialização, e a comunicação entre objectos) e outras notações para os conceitos dinâmicos (interacções, mudanças de estado, se- quências de acções e mecanismos de temporização).

PARTE 2 – LINGUAGEM DE MODELAÇÃO UML

9 9

3.5.4 Principais Metodologias

Ao longo das décadas de 1980 e de 1990 surgiram inúmeras propostas de metodologias, sobretudo concentradas nas tarefas de análise e desenho, utilizando os conceitos relacionados com o paradigma da orientação por objectos. Sem pretender ser exaustivo, enumeramos de seguida algumas das metodologias mais significativas, quer pela sua utilização, quer pela relevância dos conceitos abordados.