Artigo SQL Magazine 53 - Soluções Prontas de Modelagem com UML

Esse artigo faz parte da revista SQL Magazine edição 53. Clique aqui para ler todos os artigos desta edição

Projeto

Soluções Prontas de Modelagem com UML:

Modelagem de aplicações orientadas a objetos através de diagramas de caso de uso e de classes

Com o passar dos anos, o desenvolvimento de software orientado a objetos cada vez mais vem se consolidando como o padrão de desenvolvimento de software. Este paradigma de desenvolvimento vem se mostrando extremamente eficiente para desenvolvimento de aplicações simples, médias e complexas. Quando comparada a outros paradigmas de desenvolvimento, como o paradigma estrutural, a orientação a objetos faz uso de mecanismos de abstração para identificar no mundo real os objetos do sistema, fazendo um paralelo muito próximo do que realmente ocorre na realidade. Desta forma, o desenvolvimento de aplicações orientadas a objetos tende-se a se tornar mais natural, facilitando o processo de desenvolvimento de software como um todo.

Todo o processo de desenvolvimento de software pode ser exemplificado como uma série de atividades a serem seguidas e cada uma destas atividades compreende outra série de sub-atividades, e assim sucessivamente. A Figura 1 busca exemplificar de forma macro um processo de desenvolvimento de software moderno e orientado a objetos. Inicialmente existe um processo de análise de software onde os engenheiros de software fazem o levantamento de requisitos da aplicação, fazem uso de técnicas de gerência de requisitos para organizar estes requisitos e, com o material, coletado é feita então a validação destas informações, com uma participação efetiva do usuário. O principal artefato de software gerado nesta etapa é a documentação de sistema. A próxima etapa é o Projeto, onde o gerente de projetos irá propor um cronograma e os ciclos de desenvolvimento de acordo com a documentação de sistema gerada na etapa anterior. Após isso, é feita a codificação, onde é realizada a implementação dos requisitos. Nesta etapa é de extrema importância a utilização de alguma ferramenta de controle de versão, como o CVS (Concurrent Version System) ou SVN (Subversion). O artefato de software gerado nesta etapa é o código fonte, que na próxima etapa é testado, utilizando diferentes técnicas de teste, como os de unidade, cobertura e funcional. Ainda há a atividade de integração, onde o artefato de software gerado nesta atividade é integrado em uma nova versão do sistema. Importante destacar que estas atividades ocorrem dentro de um ciclo de desenvolvimento incremental e evolutivo, onde estas atividades são continuamente repetidas para cada ciclo de desenvolvimento da aplicação. Desta forma, por exemplo, pode-se imaginar que a atividade de testes acontece ao longo de todo o processo de desenvolvimento de software, não apenas ao seu final.

Este é um exemplo macro de um processo de desenvolvimento de software. Vários outros modelos existem e com várias outras possibilidades. É importante observar que o processo de desenvolvimento de software deve contemplar o que a equipe de desenvolvimento busca para seus produtos e, por isso, o processo de software deve ser modelado de acordo com a especificidade da empresa, produto, entre outras características e necessidades. 

Figura 1. Modelo de Processo de Software

Neste contexto, este artigo tem como objetivo apresentar na prática a utilização da UML (Unified Modeling Language) como linguagem de modelagem orientada a objetos para sistemas orientados a objetos. Observe que o foco principal do artigo dentro do processo de software apresentado acima é a análise, onde vários diagramas da UML constituem também a documentação de sistema. Não é o foco aqui tratar do processo de desenvolvimento que, para isso, poderia ser utilizado o Processo Unificado para sua descrição.

A UML começou a ser definida a partir de uma tentativa de Grady Booch e Jim Rumbaugh de combinar dois métodos populares de modelagem orientada a objeto: os métodos Booch e OMT (Object Modeling Language), respectivamente. Mais tarde, Ivar Jacobson, o criador do método Objectory, uniu-se aos dois (formando o famoso grupo dos três amigos), para a concepção da primeira versão da linguagem UML, que foi adotada em 1997 pela OMG (Object Management Group) e desde então tem ganhado milhares de adeptos.

A sua facilidade de percepção e grande possibilidade de abstração contribuíram para este sucesso, principalmente porque a UML auxilia a descrição passo a passo de um sistema orientado a objetos. A UML descreve uma linguagem de definição, e juntamente com o processo de software, contribui para o desenvolvimento de software.

Atualmente a maior revisão da linguagem é a 2.0 e define diversos diagramas, onde dentre os mais populares destacam-se:

·Diagramas Estruturais: Diagrama de Objetos, Diagrama de Classes, Diagrama de
Componentes, Diagrama de Instalação, Diagrama de Pacotes, Diagrama de Estrutura.

·Diagramas Comportamentais: Diagrama de Caso de Uso, Diagrama de Estados, Diagrama de Atividades.

·Diagramas de Iteração: Diagrama de Seqüência, Diagrama de Interatividade, Diagrama de Colaboração ou Comunicação, Diagrama de Tempo.

Nas seções seguintes são apresentados três estudos de caso, todos com o objetivo de contextualizar o desenvolvimento de software orientado a objetos com a utilização da UML. Para isso, o escopo de utilização da UML neste artigo é definido principalmente pelos Diagramas de Casos de Uso e de Classes, com uma atenção aos Diagramas de Seqüência e de Estados. Mesmo que a UML defina um grande número de diagramas, a utilização deles depende do que está sendo modelado e, principalmente, da complexidade do que se está modelando. Para a construção dos estudos de caso foi utilizada a ferramenta CASE StarUML (ver seção Links).

Estudo de Caso 1

Para o primeiro estudo de caso deste artigo, é considerado um Sistema de Controle Acadêmico. Antes de tudo, é necessário definir o escopo da aplicação, o seu mini-mundo. Para isso, utilizaremos a descrição de requisitos funcionais (RFs) que definem que funcionalidades a aplicação deve apresentar. Para este sistema, os requisitos funcionais estão descritos a seguir:

·RF01. O sistema deve permitir à secretaria cadastrar cursos contendo código, descrição e professor coordenador.

·RF02. O sistema deve permitir à secretaria cadastrar disciplinas de cursos, contendo código, descrição, carga horária, ementa, bibliografia e pré-requisitos.

·RF03. O sistema deve permitir à secretaria cadastrar alunos, contendo matrícula, nome, endereço, telefone e curso para o qual aprovado." [...] continue lendo...