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

e="MARGIN: 18pt 0cm 0pt; PAGE-BREAK-AFTER: auto; LINE-HEIGHT: normal; TEXT-ALIGN: left; mso-pagination: widow-orphan; mso-outline-level: body-text" align=left>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.

·         RF04. O sistema deve permitir ao departamento de recursos humanos (RH) cadastrar professores, contendo nome, endereço, telefone e titulação máxima (graduação, especialização, mestrado, doutorado) e cursos que esteja vinculado.

·         RF05. O sistema deve permitir à secretaria abrir turmas de disciplinas de cursos, informando ano e semestre, dias da semana e horários de realização.

·         RF06. O sistema deve permitir aos coordenadores de curso alocar professores a determinadas turmas.

·         RF07. O sistema deve permitir à secretaria matricular alunos em turmas.

·         RF08. O sistema deve permitir aos professores lançar avaliações (duas notas parciais, nota da prova final e freqüência) dos alunos das turmas que estejam sob sua responsabilidade.

·         RF09. O sistema deve permitir aos alunos consultar suas avaliações.

·         RF10. O sistema deve permitir à secretaria emitir diários de classes de turmas.

·         RF11. O sistema deve permitir à secretaria emitir históricos escolares de alunos.

·         RF12. O sistema deve efetuar o cálculo da aprovação de alunos em turmas, sendo que, para ser aprovado, deve-se ter freqüência mínima de 75%. Além disso, para aprovação sem prova final, a média das notas parciais deve ser maior ou igual a 70. Para reprovação direta, esta média deve ser menor que 30. Médias entre 30 (inclusive) e 70 (exclusive) colocam o aluno em prova final. Se média da prova final com a média anterior for menor que 50, o aluno está reprovado, caso contrário, aprovado. ...