v í Recepciona Encomenda
10: Como se traduz num diagrama de estados o processamento
paralelo de actividades numa classe de objectos?
6.3.2 Problemas Resolvidos
Desenhe os respectivos diagramas de estados de acordo com descrições seguintes.
Biblioteca
Considere o processo de disponibilização de obras descrito no capítulo 4. Além disso, considere que periodicamente as obras são analisadas e, em função do seu estado de conservação, podem ficar indisponíveis. As obras consideradas valiosas podem ser retiradas do circuito de empréstimo e colocadas em exposição.
Parque de Estacionamento
A cancela de entrada no parque de estacionamento possui diversos estados de funcionamento. Em utilização Normal o portão pode estar Aberta, Fechada ou ainda numa situação intermédia em que se detecta que o Veículo está Presente. Excepcionalmente, por motivos de segurança, a cancela pode ser Bloqueada ou ser colocada em Emergência permanecendo aberta.
102
l
Estados Biblioteca - Obral
í proposta Aquisição 1 l J Lança [ Nãc ( Cat \ Indisp \ , cusada V Expõe em Verifica Encomenda CatalogaD
Arruma Obra i j Disponível em Exposição 1 EmprestaT/
(
Emprestada Devolver
103Fundamentai de
Solução Parque de Estacionamento - Cancela de Entrada
f Funcionamento Normal Entrada Encerrada J Detecta veículo Veículo Veículo Presente l Retira Bilhete Aberta } Passa Funcionamento Passa Funcionamento Normal Funcionamento Excepção Emergência Cancela V J
c
Bloqueada Cancela V JDesenho do
CONCEITO E APLICAÇÃOO desenho do sistema permite definir a organização das diversas partes do sistema. Nos capítulos anteriores os modelos produzidos centraram-se numa actividade de análise onde é identificado o que deve estar no sistema e as suas relações.
O desenho procura determinar como é que o sistema cumpre com os requisitos. Nesta actividade o diagrama de classes é refinado com vista a aumentar a possibilidade de reutilização dos componentes que mais tarde derivarão das classes.
A reutilização é um objectivo do desenvolvimento orientado por
objectos, onde se procura produzir componentes reutilizáveis, que possam ser utilizados em diferentes aplicações, diminuindo assim os custos de desenvolvimento.
Este capítulo cobre algumas das possíveis, ao nível do desenho, para aumentar a possibilidade de reutilização. Um estudo mais completo pode ser encontrado em Bennet et (1999).
Sendo assim, neste capítulo iremos abordar a introdução de interfaces para classes, camadas (layers) no diagrama de classes e divisão do sistema utilizando pacotes.
7,2 DE DE DESENHO
Para efectuar o diagrama de classes com uma perspectiva de desenho é necessário introduzir, previamente, um conjunto de conceitos e mecanismos da UML.
7.2.1 Estereótipos
O estereótipo na UML é um mecanismo de extensibilidade que
permite aumentar a flexibilidade das classes, através de uma subclassificação. É possível criar qualquer tipo de estereótipo, sendo os mais utilizados os de interface e controlo. A representaçãc destes estereótipos é efectuada da seguinte forma:
do Sistema Estereótipo Controlo Acesso +VerificaAcesso() «interface» Gestão +Criar() +Apagar() +Ver<)
FIGURA - EXEMPLO DE ESTEREÓTIPOS
O estereótipo de «interface» classifica as classes que apenas disponibilizam um conjunto de operações visíveis externamente (públicas). O conceito de interface é abordado com mais detalhe na secção 7.2.4.
Uma classe com o estereótipo de «control» representa uma classe cujo objectivo é conter um conjunto de regras que controlam determinadas operações do sistema e que coordenam as interacções com as outras classes.
Por vezes as classes que são classificadas através de um também apresentam uma notação gráfica diferente,
assim a sua distinção imediata. Por exemplo, as classes da fig. 7.1 poderiam ser representadas por:
Gestão Controlo Acesso
Verifica
FIGURA 7,2 REPRESENTAÇÃO DE ESTEREÓTIPOS 7.2.2 Relação de Dependência
A relação de dependência surge quando uma classe recorre aos serviços disponibilizados por outra classe, numa relação de cliente/fornecedor de serviços. Por exemplo, quando um funcionário efectua ou consulta uma encomenda, este terá que aceder aos serviços de gestão disponibilizados pela classe Encomenda. Esta classe pode disponibilizar uma classe de interface que agrupa os serviços necessários.
Na figura 7.3 a relação de dependência surge quando a classe necessita dos serviços da classe Encomenda para que se possa gerir uma encomenda. Na prática, a interface
as operações Criar , Apagar e Ver da classe Encomenda. Caso os serviços disponibilizados sofram alguma alteração, então a classe que requer o serviço poderá também sofrer alterações, uma vez que é possível que esta seja confrontada com um novo comportamento.
Classe que apenas indica as operações disponibilizadas, sendo a classe que disponibiliza a interface responsável por efectuar as operações.
de Desenho do
FIGURA 7,3 - RELAÇÃO DE DEPENDÊNCIA
Normalmente utiliza-se a dependência quando queremos mostrar que um elemento de modelação utiliza os serviços de outro elemento.
7.2.3 Relação de Realização
Esta relação é quase uma mistura entre a relação de generalização e a de dependência, o que também se reflecte na sua notação (exemplo na fig. 7.4). O seu objectivo é mostrar que existe um contrato entre uma classe que especifica um serviço e uma outra classe que garante a realização do serviço.
Normalmente, a relação de realização será utilizada para especificar interfaces ou colaborações. Contudo, a utilização mais frequente é nas interfaces, um tema que é abordado em seguida. 7.2.4 Interfaces
As classes do sistema podem usufruir do conceito de interface, que permite separar o que é fornecido pela abstracção da classe da forma como é produzido. Na prática, uma interface é um grupo de
operações que são utilizadas para especificar um serviço. Este serviço funciona como um contracto entre a classe e os seus clientes que, por sua vez, constróem os seus serviços com base na interface estabelecida.
Ao efectuar esta separação, é possível efectuar alterações numa classe sem afectar as restantes, desde que não se altere a interface, reduzindo assim o impacto das alterações. Uma classe pode conter várias interfaces, fornecendo assim diferentes abstracções dos seus serviços, conforme o cliente.
A representação gráfica de uma interface consiste num círculo ou, em alternativa, numa classe, mas com o estereótipo de interface Ao contrário das classes normais, não é especificada a estrutura, não sendo representados os atributos, apenas as operações (fig. 7.4).
Encomenda -NumeroE : -Data : Date -TipoEncomenda : Long +Criar() +Apagar() +AdicionaProduto() +CalculaValorTotal()
FIGURA 7.4 - EXEMPLO DE E REALIZAÇÃO
No exemplo da figura 7.4, a classe Encomenda possui duas interfaces Gestão e Visualizar. A classe Funcionário a interface que permite criar, apagar e consultar
de Desenho do Sistema
encomendas. A classe apenas pode ver as encomenda logo está dependente da interface Visualizar que disponibiliza a operação Ver
O conceito de interface não é só aplicado a classes, mas também componentes, um tema abordado no Capítulo 8. O
esperado de uma interface pode ser detalhado através de de interacção (Capítulo 5), permitindo assim fornecer informação de forma a aumentar a sua compreensão e integraçãl pelas classes cliente.
Utiliza-se uma classe para representar uma interface quando se quer mostrar as suas operações e
assinaturas (parâmetros e valor de retorno).
7.2.5 Diagrama de Classes com níveis
Um diagrama de classes com 3 níveis é um diagrama de classes está dividido em 3 camadas de serviços:
1. Serviços de Interface ou services" - fornece