Ferramentas CASE (UML)

Um leitor me perguntou há algum tempo sobre ferramentas CASE que podem ser utilizadas para desenhar diagramas da UML.

 

Interface do JUDE

Antes da listinha, segue uma definição simples e direta (wikipédia neles!) sobre Ferramenta CASE:

Ferramentas CASE (do inglês Computer-Aided Software Engineering) é uma classificação que abrange todas ferramentas baseada em computadores que auxiliam atividades de engenharia de software, desde análise de requisitos e modelagem até programação e testes. Podem ser consideradas como ferramentas automatizadas que tem como objetivo auxiliar o desenvolvedor de sistemas em uma ou várias etapas do ciclo de desenvolvimento de software

Dentro das ferramentas frees, posso destacar o JUDE, pela sua interface gráfica, facilidade de uso e boa geração de código e o STAR UML, por abrir arquivos criados pelo Rational Rose, que é pago.
Segue a listinha de ferramentas para modelagem e desenho de diagramas:

• Rational Rose (www.ibm.com)

• OMondo (www.omondo.com)

• ArgoUML (www.argouml.tigris.org)

• Jude (http://jude.change-vision.com)

• Enterprise Architect (www.sparxsystems.com)

• Dia (http://live.gnome.org/Dia)

• Star UML (www.staruml.sourceforge.net) 

Básicos sobre UML - Parte 03 (final)

Ultima parte, contendo um resumo dos ultimos diagramas.

4.4 Diagrama de seqüências
Juntamente com os diagramas de colaboração, são considerados Diagramas de Interações, aos quais são utilizados para demonstrar os aspectos dinâmicos do sistema.

Segundo Booch, Rumbaugh e Jacobson,

“Um diagrama de interação mostra uma interação, formada por um conjunto de objetos e seus relacionamentos, incluindo as mensagens que poderão ser enviadas entre eles.”

Dizem os mesmos que, um diagrama de seqüência é responsável pela organização estrutural da comunicação que os objetos possuem e são utilizados para modelagem dos aspectos dinâmicos do sistema.
Nesse diagrama, os objetos são mostrados como uma caixa sobre uma linha vertical, que representa a “linha da vida” desse objeto.
As mensagens trocadas entre os objetos são representadas através de flechas entre as linhas da vida dos objetos.
A ordem dos fatos é dada da parte superior à parte inferior da página. As setas são rotuladas com o nome das mensagens trocadas (métodos invocados).
Um objeto é representado como uma caixa retangular vertical, que percorre sua linha correspondente.
Quando existe um retorno à mensagem enviada, é representado com uma seta diferenciada.
Os diagramas de seqüência são muito bem utilizados quando existe programação concorrente, ou seja, quando o programa se divide em duas ou mais linhas de execução.



4.5 Diagrama de colaborações
Diferentemente do diagrama de seqüências, um diagrama de colaboração enfatiza a organização dos objetos que estão participando de uma mesma interação.
Dentro desse diagrama, os objetos são mostrados, e como em um diagrama de seqüências, são utilizadas flechas para indicarem que uma mensagem foi enviada.
No rótulo das mensagens, é indicada, por números, a ordem que as mensagens acontecem e isso torna o diagrama útil para mostrar as ligações entre os objetos.



4.6 Diagrama de gráfico de estados
Diagramas de estado são utilizados para descrever o comportamento de um sistema, ou apenas de seus objetos.

Segundo Segundo Martin Fowler,

“Eles descrevem todos os estados possíveis em que um objeto particular pode estar e como o estado do objeto muda como resultado de eventos que o atingem.”

Booch, Rumbaugh e Jacobson que em geral, os objetos de gráfico de estados são utilizados para modelar objetos reativos, onde um objeto reativo é aquele que possui seu comportamento definido por suas respostas aos eventos que são ativados externamente de seu contexto.
Um determinado estado de um objeto é uma situação durante a qual esse objeto aguarda algum evento, ou realiza alguma atividade.



4.7 Diagrama de atividades
Um diagrama de atividades é basicamente um gráfico de fluxo (ou fluxograma, como é conhecido), e são empregados para fazer a modelagem das etapas de um processo qualquer.
A grande vantagem na utilização dos diagramas de atividades é o fato de suportar e atender o comportamento paralelo.
Podem ser demonstradas nesse diagrama separações entre ações (fork), que possuem uma entrada e mais de uma saída. Intercalações (merge) são o contrário, podem possuir varias entradas e uma saída.


4.8 Diagrama de componentes
Esse diagrama mostra as dependências dos componentes de um sistema.
Um componente possue um nome, pode ter relacionamento, dependências, generalização e associação. São muito semelhantes às classes, porém com algumas pequenas diferenças.

Segundo Booch, Rumbaugh e Jacobson, classes representam abstrações lógicas e os “componentes representam o pacote físico de componentes lógicos e, se encontram em um nível diferente de abstração”.

Booch, Rumbaugh e Jacobson diferenciaram os componentes em três tipos:

Componentes de implantação – são considerados aqui os componentes necessários para a formação de um sistema executável, como bibliotecas e executáveis.

Componentes do produto do trabalho – são o produto do desenvolvimento, como arquivos de código fonte.

Componentes de execução – São criados como conseqüência da execução de um sistema, como instancias de DLLs.

4.9 Diagrama de implantação
São utilizados para modelar a topografia física em que o sistema será executado, ou seja, o hardware.
Esses diagramas são basicamente diagramas de classes que exibem toda a arquitetura sob a qual esse sistema trabalhará.

A definição dada por Booch, Rumbaugh e Jacobson é auto-explicativa:

“O diagrama de implantação é um diagrama que mostra a configuração de nós de processamento em tempo de execução e os componentes que neles existem.”

Básicos sobre UML - Parte 02

Dando continuidade, vamos a alguns diagramas da UML e um rápido resumo sobre eles:


4. DIAGRAMAS

Segundo José Davi Furlan (1998),

“Um diagrama é uma apresentação gráfica de uma coleção de elementos de modelo, frequentemente mostrado como um gráfico conectado de arcos (relacionamentos) e vértices (outros elementos de modelos).”

Os diagramas são, basicamente, desenhos explicativos que permitem a visualização de um sistema. Seja da perspectiva do usuário que esse sistema terá, seja da perspectiva do desempenho que esse sistema oferecerá.
A UML, teoricamente, não restringe um diagrama de possuir qualquer relacionamento e conjunto de itens, mas, praticamente existem poucas combinações comuns para uso cotidiano.

Booch, Rumbaugh e Jacobson definiram nove diagramas para a UML:

1. Diagrama de classes;
2. Diagrama de objetos;
3. Diagrama de casos de uso;
4. Diagrama de seqüências;
5. Diagrama de colaborações;
6. Diagrama de gráfico de estados;
7. Diagrama de atividades;
8. Diagrama de componentes;
9. Diagrama de implantação;

Na construção da especificação técnica e funcional do módulo TISS do Sistema de Gerenciamento Colméia, serão utilizados os diagramas de casos de uso, de classes, e de seqüências. Portanto, serão mais bem detalhados ao longo desse capítulo.
Para melhor entendermos os diagramas, o próximo tópico será destinado a uma breve introdução sobre programação orientada a objetos.

4.1 DIAGRAMA DE CLASSES
O diagrama de classes é amplamente utilizado principalmente em modelos de sistemas orientados a objetos. A UML permite que um diagrama de classes exiba classes, interfaces e colaborações e todos os seus relacionamentos. Também mostram atributos e operações de cada classe e a maneira que os objetos estão conectados.
Os diagramas de classe também são importantes para a documentação de um sistema, e podem ser utilizados para a criação do código fonte do por meio de engenharia reversa, com o auxílio de várias ferramentas disponíveis hoje no mercado.



4.2 DIAGRAMA DE OBJETOS
De acordo com Martin Fowler, “Um diagrama de objetos é um instantâneo dos objetos de um sistema num determinado ponto do tempo”.

Em outras palavras, quer dizer que mostra como estão, em um determinado momento, instanciados os objetos do sistema e também seus relacionamentos.
O diagrama de objetos é responsável pela visualização de instancias de objetos, e não de suas classes.
Costumeiramente são utilizados para ajudar na visualização de como o sistema resolverá conexões complexas entre os objetos instanciados, representando assim um quadro estático de seu sistema. Servem para auxiliar na visualização, especificação, construção e documentação de certas instâncias encontradas no sistema, e seus relacionamentos.



4.3 DIAGRAMA DE CASOS DE USO
Segundo Martin Fowler, “Um caso de uso é um conjunto de cenários amarrados por um objetivo comum de um usuário”.

De acordo com Booch, Rumbaugh e Jacobson, “Um diagrama de caso de uso é um diagrama que mostra um conjunto de casos de uso e atores e seus relacionamentos”.

Levando em conta que um cenário é uma seqüência de etapas que um usuário tem de percorrer utilizando um sistema, um diagrama de casos de uso descreve um conjunto desses cenários juntamente com a interação de seu usuário.
Os casos de uso costumam conter, além dos próprios casos de uso, atores e seus relacionamentos de dependência, generalização e associação.
São utilizados na modelagem da visão estática de um sistema, onde é descrito seu comportamento perante o usuário e outros atores.
Comumente são utilizados durante a modelagem dos requisitos do sistema, onde envolvem a especificação sobre o que esse sistema deverá fazer e como deverá se comportar.
Atores representam uma entidade externa ao sistema, como um usuário, por exemplo. Os atores interagem com o sistema através de casos de uso, onde este representa as ações que serão executadas pelo sistema.


Para o próximo post, fica o restante dos diagramas.

Até lá!

Básicos sobre UML - Parte 01

Vou tentar postar algumas coisas que fiz durante a faculdade, pois assim creio que irei ajudar os novos estudantes.

Para iniciar, escolhi um assunto bem gostoso para quem está seguindo para a infeliz área de desenvolvimento: A UML.

Principal referência:
BOOCH, Grady & Rumbaugh, James & Jacobson, Ivar. UML – Guia do usuário. Rio de Janeiro: ed. Campus, 2000.

Vou dividir esse tema em 3 partes. A primeira parte segue abaixo, nos próximos dois posts relacionados a esse assunto, tratarei os diagramas.


1. Introdução

A primeira coisa que precisamos saber a respeito de UML é conhecer o significado dessa sigla. UML significa “Unified Modeling Language” - Linguagem Unificada de Modelagem.
A Linguagem Unificada de Modelagem é uma linguagem gráfica, constituída por um conjunto integrado de diagramas que ajudam no desenvolvimento de sistemas, que proporciona uma padronização para criação de especificações, designs de arquitetura, construções, simulações, testes e documentações.
A UML foi desenvolvida inicialmente para promover a comunicação e aumentar a produtividade no desenvolvimento de sistemas orientados a objeto, mas essa não é sua única utilidade atualmente, sendo que ela atende todos os tipos de desenvolvimento de sistemas.

2. Modelagem

Como na Engenharia Civil, para construirmos uma ponte basta começarmos batendo alguns pregos e lançando um pouco de concreto no local. A ponte poderá, com sorte, ser erguida, mas com certeza não se adequará às normas de segurança exigidas e demorará muito tempo para ser construída. Para isso é necessário um planejamento, uma equipe competente trabalhando no projeto e um rigoroso planejamento.
No desenvolvimento de softwares os problemas são muito parecidos e, se você não está disposto a ter muito retrabalho e muitos gastos, é necessária a utilização da modelagem.
Assim como na engenharia, construímos modelos arquiteturais para auxiliar na visualização de um resultado final, ou até mesmo para cálculos e previsões de efeitos de catástrofes, como um tremor ou, no nosso caso, um problema de comunicação com um banco de dados, por exemplo.
Segundo Booch, Rumbaugh e Jacobson, “um modelo é uma simplificação da realidade”.
É através da modelagem que podemos criar simulações e fazer melhor entendimento do problema como um todo, podemos visualizar o sistema como ele é, ou como deverá ser e, além disso, os modelos servem para documentar o sistema em questão.
Para uma modelagem eficiente, é necessário tomarmos certos cuidados na escolha dos modelos que serão utilizados.

3. Termos e conceitos

Para um melhor entendimento dos diagramas propostos pela UML, precisamos definir alguns conceitos, como classes, dependências, generalização, entre outros.
Em todos os diagramas serão apresentados os relacionamentos entre os itens que compõem esse diagrama. Um relacionamento é uma conexão representada por diferentes tipos de linhas que ligam um item ou mais a outro(s).
Os principais relacionamentos que encontraremos serão: a dependência, a associação e a generalização.

3.1 Classes e objetos
Uma classe é uma forma abstrata de se visualizar algum objeto do mundo real. Um objeto é a forma física/concreta dessa abstração. Todos os objetos são instancias de classes, que por sua vez, são responsáveis por descrever as propriedades e o comportamento daquele objeto.

3.2 Dependência
De acordo com Booch, Rumbaugh e Jacobson, “uma dependência é um relacionamento de utilização, determinando as modificações na especificação de um item”.
Em outras palavras, dependência é um relacionamento entre dois itens, onde um é dependente e o outro independente.
É normalmente representada graficamente com linhas tracejadas que, saindo do item dependente, apontam o item que é independente.

3.3 Generalização
È um relacionamento onde existe um elemento genérico (classe mãe) e tipos mais específicos deste elemento (classes filhos).
Resumindo em outras palavras, as classes filhos herdam todas as peculiaridades da classe mãe, mas mantém suas particularidades.
É representada graficamente com linhas sólidas que apontam para a classe genérica (mãe).

3.4 Associação
É uma conexão entre as classes. É um relacionamento que indica a ligação de objetos de um elemento a objetos de outro elemento.
São representadas nos diagramas por uma linha sólida que é conectada a outro(s) elemento(s) ou a si mesmo.
Em muitas situações é interessante determinarmos a quantidade de objetos que serão associados por uma instancia. Essa determinação é chamada de Multiplicidade.
Essa indicação é feita colocando-se a quantidade dos elementos ao lado das associações correspondentes, como um (1), zero ou um (0..1), muitos (0..*) e um ou mais (1..*), podendo ser indicado pelo numero exato (50, por exemplo).
Uma associação também pode indicar que uma das classes do relacionamento é uma parte, ou está contida em outra classe, colocando-as em um mesmo nível. Esse tipo de associação é chamado de Agregação.
Uma agregação é representada por uma linha sólida com um diamante aberto na extremidade do todo.