O uso de padrões de software tem ao longo dos anos se consolidado na comunidade de Engenharia de Software como uma forma adequada de alcançar o reúso e de desenvolver sistemas de qualidade. Padrões de software são aplicáveis em diversas situações durante o desenvolvimento de sistemas orientados a objetos. Neste livro, descrevemos alguns padrões de software e seu contexto de uso. A lista a seguir resume os padrões de software descritos neste livro. É importante notar que os padrões de software descritos neste livro nem de perto esgotam o assunto tão vasto. Desse modo, também apresentamos na lista a seguir referências para estudo adicional sobre padrões de software em diferentes catálogos.
Model-View-Controller (MVC), padrão arquitetural para organizar aplicações que devem fornecer interfaces com o usuário, na maior parte das vezes gráficas (BUSCHMANN, 1996). Apresentamos esse padrão na Seção 11.1.3.
• • • • • •
Front Controller e View Helper, padrões de projeto utilizáveis na implementação do MVC em aplicações para Web. Veja a Seção 11.1.3. Esse é um padrão do catálogo JEE (ALUR et al, 2003).
Padrões Composite, Observer, Strategy, Factory Method, Mediator, Façade. descritos na
Seção 8.6. Esses padrões fazem parte do catálogo GoF, que documenta os 23 padrões de projeto clássicos da orientação a objetos (GAMMA et al., 2000). Outro padrão desse catálogo é o Proxy, que mencionamos na Seção 11.2.3, no contexto da distribuição de objetos.
DAO (Data Acess Object), padrão de projeto cuja finalidade é desacoplar a aplicação do mecanismo de armazenamento persistente específico utilizado. Esse é outro padrão do catálogo JEE (ALUR et al., 2003). Sua descrição é apresentada na Seção 12.2.3.
DTO (Data Transfer Object), padrão de projeto para transferência de informações entre nós de processamento. Esse é outro padrão do catálogo JEE (ALUR et al., 2003). Veja a Seção 11.2.3.
Padrões táticos do DDD (Entity, Value Object , Aggregate, Domain Service, Factory, Repository). Descritos na Seção 5.4.3.2. O livro de Eric Evans (EVANS, 2003) é a fonte principal de consulta acerca desses padrões e do DDD em geral.
Metamodel (MULLER, 1999) e Party (FOWLER, 1997; HAY, 1996), dois padrões de análise, ambos descritos na Seção 5.4.4.
1. Note que aqui o termo fase é utilizado para denotar análise e projeto. Mas é importante não confundir com o significado do termo fase utilizado na descrição do processo de desenvolvimento iterativo e incremental.
E
1. 2. 3. 1. 2. 3. 4.7
Modelagem de interações
Nossas capacidades intelectuais são bastante voltadas para dominar relações estáticas, e nossas capacidades de visualizar processos em evolução no tempo são relativamente pouco desenvolvidas. Por essa razão é que devemos fazer (como sábios programadores, conscientes de nossas limitações) o máximo para diminuir a distância conceitual entre o programa estático e o processo dinâmico, para fazer a correspondência entre o programa (distribuído no espaço) e o processo (distribuído no tempo) tão trivial quanto possível. – EDSGER W. DIJKSTRA.m capítulos anteriores, dois modelos são descritos: o de casos de uso (Capítulo 4) e o de classes de análise (Capítulo 5). Vamos resumir o que esses dois modelos fornecem de informação acerca de um sistema. O modelo de casos de uso detalha os requisitos funcionais do sistema e descreve as entidades do ambiente (atores) que interagem com ele. Este modelo nos informa também quais são as ações do sistema conforme percebidas pelos atores, e quais as ações do ator, conforme percebidas pelo sistema. Com esse modelo, podem ser respondidas questões a respeito do que o sistema deve fazer e para quem. No entanto, o modelo de casos de uso nada informa sobre qual deve ser o comportamento interno do sistema para que uma determinada funcionalidade se realize. Ou seja, para que um caso de uso seja realizado, produzindo um resultado de valor para o ator, as questões a seguir são relevantes. (Note que, para essas perguntas, não encontramos respostas no modelo de casos de uso de um sistema, não importa quão detalhado esse modelo seja.)
Quais são as operações que devem ser executadas internamente ao sistema? A que classes essas operações pertencem?
Quais objetos participam da realização desse caso de uso?
Por outro lado, o modelo de classes de análise fornece uma visão estrutural e estática inicial do sistema. A construção deste modelo resulta em um esboço das classes e de suas responsabilidades. No entanto, algumas questões também não são respondidas por esse modelo:
De que forma os objetos colaboram para que um determinado caso de uso seja realizado? Em que ordem as mensagens são enviadas durante essa realização?
Que informações precisam ser enviadas em uma mensagem de um objeto a outro? Será que há responsabilidades ou mesmo classes que ainda não foram identificadas?
A leitura dos parágrafos anteriores dá a entender que o modelo de casos de uso e o modelo de classes são representações incompletas do sistema. E de fato essa é a realidade. Para responder às questões levantadas nos parágrafos anteriores, o modelo de interações do sistema precisa ser criado. Esse modelo representa as mensagens (ver a Seção 1.2.2) trocadas entre os objetos para a execução de cenários dos casos de uso do sistema. A modelagem de interações é uma parte da modelagem dinâmica de um SSOO (a outra parte corresponde à modelagem de estados, que descrevemos no
7.1
Capítulo 9). A modelagem dinâmica é realizada com o propósito de entender de que forma o sistema irá se comportar em tempo de execução.
A construção do modelo de interações pode ser vista como uma consolidação do entendimento dos aspectos dinâmicos do sistema. Em particular, alguns aspectos iniciais relativos à dinâmica de interação entre objetos já é conhecida na modelagem de classes de análise. Entretanto, os aspectos dinâmicos identificados com aquela técnica ainda são incipientes e incompletos. Por meio da construção do modelo de interações, as classes, as responsabilidades e os colaboradores identificados previamente podem ser validados. Esse modelo permite ainda refinar o modelo de classes, pois as operações (e até alguns atributos) de cada classe são identificadas na construção do modelo de interações. Em resumo, estudar de que forma objetos interagem no decorrer do tempo fornece informações para completar a perspectiva estática e estrutural da modelagem.
Neste capítulo, apresentamos detalhes da modelagem de interações. Na Seção 7.1, começamos por descrever os elementos de modelagem utilizados nessa atividade. Nas Seções 7.2 e 7.3, apresentamos, respectivamente, os elementos de notação do diagrama de sequência e do diagrama de comunicação, dois dos principais diagramas de interação existentes na UML. Na Seção 7.4, finalizamos a descrição de detalhes de notação com apresentação de elementos gráficos úteis para modularização da modelagem de interações. Na Seção 7.5, passamos a descrever aspectos relativos à construção propriamente dita do modelo de interações de um SSOO. Na Seção 7.6, apresentamos uma contextualização da modelagem de interações em um processo de desenvolvimento. Na Seção 7.7, finalizamos este capítulo com a continuação da apresentação de aspectos da modelagem de interações de nosso estudo de caso, o SCA.