O objetivo deste artigo é apresentar algumas boas práticas para elaboração de diagramas de casos de uso, classes e sequência, através de sua aplicação prática em um estudo de caso.
Para que serve
Em que situação o tema é útil
O tema é útil para aqueles que trabalham no desenvolvimento de projetos de software e têm interesse em entender algumas atividades realizadas antes da codificação do software propriamente dita.
Existem diversos pontos críticos causadores de inserção de defeitos durante o desenvolvimento de um software. Podemos citar requisitos, projeto e codificação como alguns exemplos. Somados a estes pontos críticos, tem-se um outro momento do desenvolvimento que merece uma atenção especial: a elaboração da solução para o problema através do diagrama de classes. Elaborar de forma criteriosa diagramas de classes é um fator de sucesso de projetos de software por que, além do fato de ser um momento propenso à inserção de defeitos no software, são neles em que são transformados os problemas do usuário em uma solução computacional, servindo como uma ponte entre requisitos e codificação. Se esta ponte for mal projetada, o software também será (ver Figura 1).
Figura 1. Inserindo defeitos no projeto.
A UML (Unified Modeling Language) apresenta uma série de diagramas para a modelagem de sistemas orientados a objetos. Os diagramas mais comuns são o diagrama de casos de uso (representa as funcionalidades de um sistema), o diagrama de classes (descreve as classes do modelo numa visão estática), o diagrama de seqüência, ou seu substituto na UML 2.0, o diagrama de comunicação (descrevem as funcionalidades através de uma visão dinâmica) e o diagrama de estados (apresenta o comportamento dinâmico de um objeto).
O objetivo desta matéria é trazer ao leitor algumas boas práticas para elaboração de diagramas de casos de uso, classes e sequência, através de sua aplicação prática em um estudo de caso.
Introdução a UML
Muito se fala sobre a curva de aprendizado associado à orientação a objetos. Esta curva de aprendizado é fruto da necessidade e troca de paradigma ao deixar de projetar e desenvolver estruturado para fazê-lo seguindo os princípios da orientação a objetos. Em alguns aspectos, a mudança pode ser até fácil. Aqueles que não trabalharam por muito tempo com o paradigma estruturado tendem a ter mais facilidade.
Neste contexto situamos a UML, linguagem de modelagem unificada. Até certo ponto podemos dizer que ela foi projetada para ajudar as pessoas a focarem nas vantagens provenientes do uso do paradigma orientado a objetos. UML é utilizada para visualizar, especificar, construir e documentar artefatos de software. Veremos agora o que significa cada um desses contextos de utilização.
• Visualizar: para muitos programadores, a distância entre pensar em uma solução para o problema e transformá-la em código é próxima de zero. Ele cria a solução e ele mesmo a desenvolve. Ainda assim, ele de alguma forma está modelando mentalmente o sistema que irá construir. Entretanto, existem sérios problemas com esta abordagem. Primeiro, comunicar o modelo criado mentalmente para outros desenvolvedores é uma tarefa cujo risco de perda de informação durante a comunicação é alto. E segundo, imagine que o projeto em questão é grande e a equipe envolvida não se restringe a um ou dois programadores. Teríamos sérias dificuldades na construção do sistema. Isso sem falar que não existiria documentação para o software e sua manutenção no futuro traria dor de cabeça, com certeza. Assim, o uso da UML provê uma notação comum para o entendimento compartilhado sobre o software que se está construindo.
• Especificar: a UML permite a construção de modelos precisos, não ambíguos e completos.
• Construir: os modelos construídos utilizando a UML podem ser conectados a uma série de linguagens de programação permitindo uma tradução entre os modelos construídos e o código. Este mapeamento permite também a engenharia reversa na qual os modelos são gerados a partir do código fonte. Vale uma ressalva aqui, UML não é uma linguagem visual de programação.
• Documentar: neste caso, os modelos criados durante o desenvolvimento fazem parte da documentação do software.
A Figura 2 fornece uma boa metáfora da importância da UML para a construção de software. Da mesma forma que precisamos de um projeto bem feito antes de construirmos um edifício, precisamos também para software. Perceba que a planta de uma casa facilita a comunicação entre os envolvidos na construção, permite uma avaliação do cliente e assim por diante.
Figura 2. Planta de uma construção
Como o próprio nome nos diz, a UML é uma linguagem de modelagem, não um método. Ou seja, ela nos diz o que podemos modelar, mas não como. Modelos servem para possibilitar o entendimento do ambiente no qual o sistema irá operar, a comunicação entre as pessoas envolvidas em um projeto, promover a melhor compreensão dos requisitos do projeto, promover a difusão deste conhecimento entre os envolvidos e, avaliar diferentes soluções através da modelagem da solução.
A UML possui dois grandes conjuntos de diagramas (ver Figura 3):
• Estrutural: modelam aspectos estáticos do software focando nas entidades participantes e seus relacionamentos. Os diagramas deste conjunto são: diagrama de classes, objetos, componentes e implementação.
•
Comportamental:
modelam aspectos dinâmicos do software focando, na maioria das vezes, como
as entidades interagem para prover uma determinada funcionalidade para o
usuário. Os diagramas deste conjunto são: diagrama de casos de uso, seqüência,
colaboração, estados e atividades. ...
