42 :: TIdigital / Reportagem / UML

U M L
pense antes de codificar!
Compreender melhor o projeto e facilitar sua manipulao futura, reduzir custos de manuteno, auxiliar na identificao de problemas... Esses so apenas alguns argumentos para justificar as vantagens da modelagem antes da codificao
Por: Flvia Freire

Apesar de, nos dias de hoje, usarmos o computador, o palm ou o celular para fazermos anotaes, quem que nunca listou em um pedao de papel os afazeres para poder se organizar sem se esquecer de nada? No caso dos programadores, natural que, antes de sentar em frente ao computador, ele exponha suas ideias em forma de rabiscos, mesmo que de uma maneira que s ele possa entender. A fim de globalizar este ato, Grady Booch, Ivar Jacobson e James Rumbaugh uniram suas metodologias que, em 1990, eram as trs mais populares em modelagem de orientao a objetos, com o apoio da empresa Rational Software Corporation, hoje adquirida pela IBM, para criar uma linguagem unificada rigorosa para a modelagem de software. Dos mtodos Booch, OMT (Object Modeling Technique) e OOSE (ObjectOriented Software Engineering), respectivamente, surgiu em 1996 a primeira verso da UML (Unified Modeling Language). Logo, as grandes empresas comearam a contribuir para o projeto e, em 1997, a OMG (Object Management Group), ou Grupo de Gerenciamento de Objetos, adotou a UML como a linguagem padro para modelagem de software. o resultado de mais de duas dcadas de evoluo da cultura de modelagem desse tipo de software. Serve para descrever um software sob diferentes pontos de vista, permitindo destacar detalhes ou gerar vises mais globais. Descreve o mesmo que o cdigo, mas de uma forma que privilegia a compreenso, por permitir enxergar informaes de uma forma mais clara que no cdigo. til para a compreenso de um software e, principalmente, como instrumento de auxlio construo de software bem estruturado, diz Ricardo Pereira e Silva, autor dos livros Como Modelar com UML 2 e UML 2 em Modelagem Orientada a Objetos. Ao contrrio do que muitos pensam em um primeiro momento, a UML no uma linguagem de programao, e sim um linguagem visual utilizada para modelar sistemas computacionais por meio do paradigma de orientao a objetos. O objetivo principal da UML auxiliar na definio de requisitos, estrutura lgica, dinmica de processos, comportamento, entre outros, de um projeto, para s ento ele sair dos diagramas direto para o ambiente de desenvolvimento. Modelar um projeto significa descobrir os conceitos envolvidos anlise: o qu? -; e definir as classes de software que implementam os conceitos - projeto: como?. fcil concluir que, sem a boa modelagem de um projeto, no h nenhuma garantia de que o software correspondente seja de qualidade, isto , fiel aos conceitos,

explica Marcus Sampaio, doutor em informtica pela Universit de Montpellier II, da Frana. Marcus tambm professor do Centro de Engenharia Eltrica e Informtica, da Universidade Federal de Campina Grande, e considera a falta de preocupao de seus alunos com a modelagem um problema muito srio. Uma explicao possvel : enquanto a codificao tangvel, o mesmo no acontece com o projeto. Nossa constatao, na UFCG, que os alunos j vm com uma enorme dificuldade de discernir sobre o intangvel, ou sobre abstrao, de um modo geral. por isso que as disciplinas de projeto so colocadas mais para o final do curso, quando se espera que o aluno tenha amadurecido, diz. No caso das empresas, Marcus ressalta a importncia de ter desenvolvedores que saibam modelar e que modelem antes de programar. fundamental ter um desenvolvedor na empresa que tenha poder de abstrao e que saiba conversar no nvel do usurio. Programar, sem noo precisa de o qu? e como?, atividade de alto risco e custo. Ricardo diz que a codificao sem planejamento acarreta no risco de gerao de um produto mal estruturado. Consequncias inerentes: dificuldade de compreenso e, como decorrncia, de manuteno e baixo potencial de reusabilidade. Tudo isso tm impacto direto no custo do software ao longo de seu ciclo de vida, que se estende bem alm do perodo de desenvolvimento. O problema que quem trabalha dessa forma no se qualifica para o desenvolvimento de software de alta complexidade, correndo o risco de perder o controle do desenvolvimento quando diante de um desafio que ultrapasse algumas centenas de classes, por exemplo. Empresas que apenas possuam profissionais com essa caracterstica correm srio risco de perda de controle do processo de desenvolvimento diante de desafios que envolvam alta complexidade. Para Carlos Majer, professor da Unicid (Universidade Cidade de So Paulo), o interesse em modelar projetor depende da cultura de negcios da empresa. A empresa pressiona a equipe de desenvolvimento para apresentar um sistema o quanto antes. Esta presso muitas vezes envolve os elementos tempo e financeiro, fazendo com que o desenvolvedor tenha que liberar verses precoces do sistema. Em outros casos, pode ocorrer do prprio desenvolvedor no ter sido devidamente exposto ao assunto, o que evidencia a falta de treinamento adequado, muitas vezes caro e inacessvel, diz.

TIdigital / Reportagem / Frameworks Javascript :: 38 TIdigital / Capa / APIs :: 43

Grady Booch

Confira uma entrevista exclusiva com um dos autores da UML. Booch reconhecido internacionalmente por seu trabalho em arquitetura e engenharia de software. Faz parte do Centro de Pesquisa Thomas J. Watson da IBM, como chefe cientista de engenharia de software e trabalhou na Rational Software Corporation desde que foi fundada, em 1981. tambm autor de seis livros best-sellers.

TI: Como foi o trabalho de criao da UML, na Rational Software Corporation? Qual o propsito da UML? Booch: Quando o Jim, o Ivar e eu decidimos criar a UML, nossa inteno era unificar nossos trs mtodos (de maneira que o U se tornasse UML), para criar uma linguagem de visualizao, especificao, construo e documentao de artefatos de um sistema de software intensivo. Esta misso trouxe a UML de hoje. Devo lembrar que, naquele tempo em que trs de ns juntamos foras, havia uma indstria vibrante por mtodos, assim como o mundo do desenvolvimento estava comeando a se desvencilhar das linguagens de algoritmos, como Fortran, C e Cobol, para orientao a objetos, como Smalltalk e C++. Haviam muitas grandes ideias circulando, e a Rational simplesmente tomou a deciso empresarial de simplificar o mercado e faz-lo crescer juntando a melhor daquelas ideias e formando uma, de padro aberto. Deste modo, a UML nasceu, primeiramente dentro da Rational, e ento, muito rapidamente envolvendo virtualmente todos os principais atuantes do mercado de desenvolvimento de software, para lanar um verdadeiro padro global. TI: Muitos desenvolvedores web pulam o estgio de modelagem para ir direto para a fase de codificao. O que voc poderia dizer sobre a importncia de modelar um projeto antes de comear a codific-lo? Booch: No so apenas desenvolvedores web que fazem isso. um hbito comum. Pensar antes de fazer sempre uma boa opo, e modelar antes de codificar uma tima coisa a fazer tambm. A questo o quanto pensar e o quanto codificar. Se voc perceber que a UML uma linguagem para argumentar sobre o sistema, ento ela poderosa em termos de ajuda, considerando abstraes incisivas, tendo a separao apropriada das preocupaes, tendo uma distribuio balanceada de responsabilidades. Modelar particularmente importante quando consideramos preocupante as aes simultneas, que no acontecem facilmente j que sua cabea est focada no cdigo. Algumas vezes, contudo, as pessoas tendem a sub-modelar, e este no um bom caminho. Minha regra : se eu posso expressar e entender um projeto olhando diretamente o cdigo, tudo bem. Mas decises arquiteturais raramente podem ser feitas, e por isso, elas so candidatas primordiais para uma modelagem mais formal.

TI: Existem 14 diagramas da UML. Quais deles so os mais utilizados? Booch: Primeiramente, diagramas de classe, e ento, dependendo do seu domnio, diagramas de casos de uso e diagramas de sequncia ou de estado. TI: Como os desenvolvedores podem escolher a ferramenta ou diagrama UML corretos para um projeto para que seja criado um modelo que descreva corretamente a ideia do projeto? Booch: Escolher o modelo certo uma questo de entendimento de qual viso voc est tentando abstrair. O modelo 4+1 de Philip Kruchten o meu framework arquitetural favorito, e se voc comear com este, ele te leva para quais pontos de vista (quais modelos) voc deveria considerar. Para escolher a ferramenta, bem, eu sou parcial ;-), mas minha sugesto selecionar alguma coisa que justifique as suas razes, e no perca o caminho, para selecionar algo que se encaixe no seu trabalho. TI: fcil interpretar diagramas? Booch: Para mim como respirar. Eu posso olhar para um diagrama e rapidamente saber o que est acontecendo. Resumidamente, isto leva tempo e experincia, assim como com qualquer linguagem, para propriamente entend-la intuitivamente. TI: possvel modelar qualquer tipo de projeto com UML? Booch: Estou escrevendo um handbook, no trabalho, sobre arquitetura de software (www.booch.com/architecture). At agora no encontrei nenhuma espcie de sistema de software complexo que eu no pudesse modelar na UML. T I : O q u e h d e n o v o n a U M L 2 ? Vo c j e s t pensando nas prximas verses? O que voc melhoraria em uma verso futura da UML? Booch: A UML 2 trouxe uma variedade de elementos para a linguagem, particularmente em suporte de ModelDriven Development. Para o futuro? Bem, eu simplificaria o metamodelo e trabalharia para identificar os 20% da UML que se aplica aos 80% dos problemas de modelagem que as pessoas encontram em uso real.

44 :: TIdigital / Reportagem / UML

Interpretando diagramas UML

P r i m e i r o , t e m q u e s a b e r m o d e l a r, p a r a e n t o conseguir interpretar. Como disse Grady Booch, preciso uma certa experincia para olhar os diagramas e j saber como o projeto ser desenvolvido. Uma das intenes dos criadores da linguagem era que estes diagramas pudessem ser passados de mo sem que o autor tivesse que expliclos ao desenvolvedor. o que se espera como rotina de trabalho em um ambiente de desenvolvimento. Isso, porm, no obtido apenas com a linguagem UML. Assim como uma empresa precisa adotar regras para codificao ou testes, tambm deve estabelecer padres de modelagem, para que a modelagem feita por um possa ser compreendida por todos. Outra questo a ser definida pelas empresas o nvel de detalhamento adotado nas especificaes de projeto: modelagens mais detalhadas so mais independentes de outras fontes de infor mao e, consequentemente, permitem que o programador faa seu trabalho de forma mais independente, relata Ricardo.

Conhea os diagramas
Com a UML, os projetos so definidos atravs de diagramas. Com a ltima verso da linguagem, adotada pela

OMG (www.omg.com) em 2005, a UML passou a oferecer 13 tipos de diagramas que podem se complementar, cada um fornecendo uma viso do projeto a ser desenvolvido, e trouxe uma srie de melhorias. A UML 2 acrescenta quatro novos diagramas (de Pacotes, de Estrutura Composta, de Viso Geral de Interao e de Temporizao), o que produz um acrscimo significativo de expressividade. Alm disso, h melhoras significativas nos diagramas j existentes. Neste caso, cabe destacar a introduo da noo de agrupamento de mensagens no diagrama de Sequncia, que permite a representao de laos e execues condicionais, similares a comandos de linguagens procedurais. Outro destaque deve ser feito ao tratamento de software orientado a componentes, que melhorou bastante, dado que na primeira verso da linguagem o tratamento da abordagem era muito pobre sinttica e semanticamente, explica o professor Ricardo. Para Marcus Sampaio, a UML 2.0 mantm os objetivos da UML 1.0, mas com novidades A principal a introduo de facilidades para a comunicao entre ferramentas (padro XMI), diz. Com a verso 2.0 da UML, os diagramas foram divididos em Estruturais, Comportamentais e de Interao. Observe a figura abaixo que mostra todos os diagramas da UML, de forma hierrquica:

Diagrama UML

Diagrama Estrutura

Diagrama Comportamento

Diagrama de Classes

Diagrama Instalao Diagrama Estrutura Composta

Diagrama de Objetos

Diagrama Casos de Uso

Diagrama Atividades

Diagrama de Pacotes

Diagrama Componentes

Diagrama Interao

Diagrama Estados

Diagrama Temporizao

Diagrama Sequncia

Diagrama Viso Geral Interao

Diagrama Comunicao

TIdigital / Capa / APIs :: 45

d iagramas e sTruTurais
Diagramas de Classes, de Instalao, de Objetos, de Pacotes, de Estrutura Composta e de Componentes. Diagrama de Classes: permite representar as classes do sistema, suas caractersticas (atributos) e aes (mtodos). Voc consegue expor as relaes existentes entre as classes utilizando o conceito de orientao a objetos, o que uma grande vantagem para os desenvolvedores que utilizam linguagens de programao orientadas a objetos, to comum nos dias de hoje. Diagrama de Instalao: descreve a configurao de elementos de suporte ao processamento, componentes de software, processos e objetos existentes nesses elementos. Ou seja, ilustra os componentes de hardware e software e sua interao com outros elementos de suporte ao processamento. Diagrama de Objetos: uma boa opo para explicar relacionamentos complexos entre classes. Mostra os objetos que foram instanciados das classes. Os nomes dos objetos so sublinhados e todas as instncias so mostradas. Tambm usado como parte dos diagramas de Colaborao, onde mostrada a colaborao dinmica entre os objetos do sistema. O Diagrama de Objetos fornece uma viso dos valores armazenados
EntryStation
Atributes

pelos objetos de um diagrama de Classes em um determinado momento da execuo de um processo. Os diagramas mostram apenas os mtodos e propriedades que retornam objetos. Diagrama de Pacotes: pode ser chamado tambm de Diagrama de Mdulos. Pacote representa um grupo de classes, ou elementos, e dependente de outros pacotes. O Diagrama de Pacotes mostra pacotes ou pedaos do sistema e relaes entre pacotes. Ele mais utilizado para ilustrar a arquitetura do projeto mostrando o agrupamento de suas classes. No preciso seguir uma hierarquia, ele pode ser utilizado em qualquer fase do processo de modelagem. Diagrama de Estrutura Composta: mostra o relacionamento entre os elementos e especifica funcionalidades. Diagrama de Componentes: descreve as dependncias entre componentes de software, como de cdigo fonte, cdigo binrio e executveis. Destaca a funo de cada mdulo para facilitar a reutilizao e auxilia no processo de engenharia reversa, por meio da organizao dos mdulos do sistema e seus relacionamentos. Ele mostra apenas o que relevante em um subsistema de implementao. Este diagrama representado na forma de tipos e no na forma de instncias.

private int stationID private boolean isOperating public EntryStation( ) public int getStationID( ) public void setSationID( int val ) public boolean getlsOperating( ) public void validateEntryStation( ) public void stlsOperating( boolean val )
Operations

Cashier station have limited founds.

ATM
Atributes

private float cashOnHand private float dispensed public ATM( ) public float getCashOnHand( ) public void set CashOnHand( float val ) public float getDisensed( ) public void setDispensed( float val )
Operations redefined from EntryStation Operations

CashierStation
Atributes

public CashierStation( ) public int verifyCard( )

Operations

public float verifyAmountAvailable( ) public int getStationID( ) public void setStationID( int val ) public boolean getlsOperating( ) public void validateEntryStation( ) public void setlsOperating( boolean val )
* Operations redefined from EntryStation

User
Atributes Operations

public int getStationID( ) public void setStationID( int val ) public boolean getlsOperating( ) public void validateEntryStation( ) public void setlsOperating ( boolean val )
1..* Account Verification 1 Qualifiers

public User( )

Branch
Atributes

Consortium
Atributes Operations

private char connected

Operations

A branch belongs to a Member Institution.

public Consortium( ) public void validateAccountInfo( )

public Branch( ) public char getConnected( ) public void setConnected( char val )

Diagrama de Classes

Fontes: Ricardo Pereira e Silva, Marcus Sampaio, Carlos Majer e Guia Prtico UML 2 (http://migre.me/2qtr)

46 :: TIdigital / Reportagem / UML

d iagramas c omPorTamenTais
Diagramas de Casos de Uso, de Atividades e de Estados. Diagrama de Casos de Uso: neste diagrama identificamse os atores (participantes do caso de uso) e suas relaes com os casos de uso (funcionalidades). muito utilizado para a comunicao entre os colaboradores do sistema (desenvolvedores, analistas e usurios-chave), permitindo um nvel de abstrao macro que permite visualizar o que deve ser desenvolvido. Desta forma, o time sabe o que precisa ser feito. Apesar disto, este tipo de diagrama no mostra como deve ser feito. Diagrama de Atividades: adequado para representar o comportamento de algoritmos, processos d e n e g c i o e c a s o s d e u t i l i z a o . Re p r e s e n t a u m a srie de aes ou atividades, em que as transies so desencadeadas devido a simples concluso dessas aes ou atividades. Diagrama de Estados: descreve as sequncias de estados que um objeto ou uma interao pode passar ao longo da sua existncia em resposta a estmulos recebidos, em conjunto com as suas respostas e aes.

Update Customer Database Bank Computer

Service ATMs Technician Employees

<<implementation>> Deposity Money Bank Teller

Withdraw Money

<<extend>>

Deposit Cash at ATM

<<extend>> Loan Office Withdraw Cash from ATM uses Customer

<<extend>> Process a Loan Apply for Loan

Diagrama de Casos de Uso

Fontes: Ricardo Pereira e Silva, Marcus Sampaio, Carlos Majer e Guia Prtico UML 2 (http://migre.me/2qtr)

c omo consTruir os diagramas da uml?

E x is t em d iver s os s of t w a r es p a r a mod ela g em U M L . Alguns destes editores at interpretam os diagramas e geram o cdigo, mas sem garantias j que preciso uma reviso manual. Conhea algumas ferramentas para edio de diagramas: ArgoUML: software livre de modelagem UML que suporta todos os padres de diagramas da UML 1.4. Roda em qualquer platafor ma Java e est disponvel em dez idiomas. O ArgoUML j ultrapassou 80 milhes de downloads e usado por desenvolvedores do mundo inteiro. Site oficial: http://argouml.tigris.org

Jude: software para modelagem UML, gratuito e multiplatafor ma. Suporta UML, Diagrama de Entidade d e Re l a c i o n a m e n t o , F l o w c h a r t , C R U D , D i a g r a m a de Mapas e de Dados. Per mite converter modelos. Site oficial: http://jude.change-vision.com Microsoft Office Visio 2007: ajuda a visualizar, explorar e comunicar informaes complexas, que vo de textos e tabelas a diagramas do Visio que comunicam informaes. Em vez de imagens estticas, pode-se criar diagramas do Visio conectados aos dados que exibem dados. Possui uma ampla variedade de diagramas para compreender, atuar a respeito e compartilhar informaes sobre sistemas, recursos e processos organizacionais.

TIdigital / Capa / APIs :: 47

d iagramas

de

i nTerao
Diagrama de Viso Geral de Interao: uma variao do Diagrama de Atividades que fornece uma viso geral dentro de um sistema ou processo de negcio. Diagrama de Comunicao: antes conhecido como Diagrama de Colaborao, complementa o Diagrama de Sequncia. As infor maes mostradas no Diagrama de Comunicao so praticamente as mesmas apresentadas nos de Sequncia, s que sem se preocupar com a temporalidade do processo, concentrando-se em como os objetos esto vinculados e quais mensagens trocam entre si durante o processo.

Diagramas de Temporizao, de Sequncia, de Viso Geral de Interao e de Comunicao. Diagrama de Temporizao: descreve a mudana no estado ou condio de uma instncia de uma classe ou seu papel durante um tempo. Normalmente utilizado para demonstrar a mudana no estado de um objeto no tempo em resposta a eventos externos. Diagrama de Sequncia: ilustra interaes entre objetos em um determinado perodo de tempo. Segundo Marcus Sampaio, pode ser visto como uma especializao de Diagrama de Casos de Uso, exprimindo uma ou diversas sequncias de mensagens trocadas entre os usurios e o sistema.

<<jsp>> : TelaLogin

: LoginAction

: LoginService

: UsuarioDAO

: Usuario

1: [Entra com login e senha] valida() : void 1.1 : valida(login:String, senha:String) : Usuario 1.1.1 : findByLoginAndSenha(login:String, senha:String) : Usuario 1.1.1.1 : [Se encontrou no BD] new()

1.1.1.2 : [Se encontrou no BD] set*()

Retorna Usuario ou Null Retorna Usuario ou Null

Se validado OK ento permite acesso ao recurso, seno exibe novamente a TelaLogin

Diagrama de Seqncia

Fontes: Ricardo Pereira e Silva, Marcus Sampaio, Carlos Majer e Guia Prtico UML 2 (http://migre.me/2qtr)

Site oficial: http://office.microsoft.com/pt-br/visio Rational Rose: uma fer ramenta CASE que auxilia nos processos de constr uo de um sof tware profissional. Foi criada pela Rational, posterior mente adquirida pela I B M e n o g r a t u i t a . Pe r m i t e a m o d e l a g e m c o m n o v e diagramas da UML (Casos de Uso, Classe, Componentes, Desenvolvimento, Objetos, Sequncia Colaborao, Estados e Atividades). Permite tambm a constr uo de modelos de dados com possibilidade de exportao para constr uo da base de dados ou realizao de engenharia reversa de uma base de dados existente. D suporte a Visual Studio. Site oficial: www.ibm.com/software/rational

VisualParadigm: fer ramenta integrada para UML avanado que suporta o ciclo de desenvolvimento do software (anlise, projeto, implementao, teste e depurao). Per mite projetar todos os tipos de diagramas UML, reverter o mecanismo de cdigo e gerar documentao. Possui exemplos e modelos passo-a-passo. Site oficial: http://www.visual-paradigm.com yUML: fer ramenta gratuita que per mite criar diagramas UML de forma simples, podendo ser includos em uma pgina web. H alguns diagramas prontos, que podem ser personalizados de acordo com suas necessidades. Site oficial:http://www.yuml.me