Conceitos de orientao a objetos e UML

Entendendo o paradigma atual de desenvolvimento de sistemas

De que se trata o artigo: Este artigo aborda a evoluo do desenvolvimento de sistemas chegando aos dias de hoje com o paradigma da orientao a objetos. Em seguida so apresentados os conceitos da orientao a objetos, sua aplicabilidade em diversas fases do desenvolvimento de sistemas, e conclui com a apresentao da UML como modelo utilizado para desenvolvimento de sistemas OO. Para que serve: Fornecer aos desenvolvedores ou estudantes da rea de sistemas a base necessria ao contexto de desenvolvimento atual o paradigma de orientao a objetos. Em que situao o tema til: Atualmente h uma disseminao de sistemas desenvolvidos sob o paradigma orientado a objetos, sem que alguns desenvolvedores tenham uma completa viso da importncia de toda a base de conceitos OO e da modelagem em UML. 1822, o matemtico ingls Charles Babbage estabelecia os princpios do funcionamento dos computadores eletrnicos no projeto

ste artigo inicia mostrando como evolumos at o paradigma atual da orientao a objetos. Em seguida, conceituaremos a base da orientao a objetos, com sua demonstrao por meio de exemplos. Ser apresentada uma viso geral da aplicabilidade em diversas fases do desenvolvimento de sistemas: levantamento, anlise, projeto de banco de dados e implementao. E por fim, evidenciaremos a proposta da UML como linguagem de modelagem, com a apresentao dos diagramas da verso atual.

O comeo de tudo
Ana Cristina Melo informatica@anacristinamelo.com.br
especialista em Anlise de Sistemas e professora de graduao e ps-graduao da Universidade Estcio de S. Atua em anlise e programao h 21 anos. Autora do livro Desenvolvendo aplicaes com UML do conceitual implementao, na segunda edio, e Exercitando modelagem em UML. Palestrante em alguns eventos, entre eles, Congresso Fenasoft, OD e Sepai.

A histria da computao teve incio na necessidade do homem em conseguir realizar clculos. O caminho foi longo, iniciado com o baco, muitos anos antes da era crist. A primeira mquina de calcular que apenas somava e subtraa vem surgir apenas em 1642, desenvolvida por Blaise Pascal. Em 1694, Gottfried Von Leibniz constri a primeira calculadora que podia executar as quatro operaes bsicas, e em

20 Engenharia de Software Magazine Conceitos de orientao a objetos e UML

P R O J E TO
de sua mquina diferencial, capaz de realizar os clculos necessrios para elaborar uma tabela de logaritmos. A partir da, outras invenes abriram caminhos para o que temos hoje. O marco inicial se d com o primeiro computador eletrnico, o ENIAC (Eletrical Numerical Integrator and Calculator), surgido em 1945, e pesando cerca de 30 toneladas. At hoje os computadores ainda utilizam a arquitetura proposta por Von Neumann. Em 1951, surgia o primeiro computador fabricado comercialmente: o UNIVAC I, usado no censo americano por 12 anos seguidos. A partir da dcada de 40, descobre-se a importncia da computao, e essa passa a fazer parte da nossa histria. Contudo, numa primeira fase ningum pensava em software. Os esforos estavam voltados evoluo do hardware, buscando-se reduzir os problemas das primeiras mquinas. Assim, da primeira gerao de computadores vlvula, passamos para a segunda gerao, utilizando transistores. A primeira linguagem de programao surgida foi a linguagem de mquina, na dcada de 50 o Assembly. Nesse momento, a preocupao era restrita aos comandos, nem se pensava em anlise, muito menos em modelagem de requisitos. A partir de ento, surgem as linguagens de alto nvel, como Fortran, Algol e Cobol. Um rpido aumento na complexidade das demandas por software e a falta de tcnicas para definio de novos sistemas culminaram em diversos problemas, entre eles: estouro de oramento e prazo, softwares de baixa qualidade, requisitos no atendidos e cdigo de manuteno difcil. Estava definida a crise de software. A soluo para contornar a crise veio com o conceito da Engenharia de Software, em 1968. Objetivava-se trazer os princpios da Engenharia, com todo o seu planejamento e modelagem, para se resolver os problemas da rea ainda imatura. No mesmo ano de 68, Dijkstra escreve sobre a programao estruturada; tinha incio o marco do primeiro paradigma de desenvolvimento de sistemas. Mas enquanto novas linguagens surgiam Pascal, C , ainda no se tinha a definio de uma metodologia de desenvolvimento de sistemas, at 1978, quando Tom DeMarco escreve seu livro sobre anlise estruturada. Contudo, a dificuldade de manuteno dos diversos modelos gerados na fase de anlise e projeto, fez com que se percebesse, nas duas dcadas seguintes, que esse paradigma ainda no era a soluo para a velha crise de software. Naturalmente, logo se pensa que a orientao a objetos surgiu aps a anlise estruturada, como uma evoluo dessa metodologia, buscando-se as solues necessrias para um projeto confivel e de manuteno fcil. correto imaginar que o paradigma da orientao a objetos tornouse a soluo para acompanhar a demanda cada vez maior e freqente do mercado, mas o erro est no posicionamento histrico do conceito de orientao a objetos, pois este surgiu muito antes do conceito da programao estruturada. Em 1962, Ole-Johan Dahl e Kristen Nygaard criaram uma linguagem chamada Simula, baseada na linguagem Algol 60. O diferencial residia em seu objetivo: permitir o projeto de simulaes. Surgia a primeira linguagem orientada a objetos, apresentando os conceitos de classe e herana. Essa foi a semente que inspirou o desenvolvimento de uma nova linguagem, a primeira totalmente orientada a objetos o SmallTalk. Nela, no existem tipos primitivos, tudo representado em forma de objeto: nmeros, caracteres etc. Disponibilizada ao pblico no incio dos anos 80, SmallTalk solidificou para a comunidade os conceitos de classe, objeto, atributo, mtodo, encapsulamento, herana e mensagem. A partir da, novas linguagens surgiram, como o C++ (verso OO da linguagem C), Object Pascal (verso OO do Pascal), Eiffel e Java (criado a partir do C++). diga OO. Sendo assim, se um desses conceitos no for atendido, no podemos afirmar que determinada tecnologia possa ser nomeada como orientada a objetos. Isso aconteceu com a linguagem Visual Basic, que antes da sua verso .net no implementava todos os conceitos de orientao a objetos. Vejamos ento esses conceitos: Objeto: um objeto qualquer coisa existente no mundo real, em formato concreto ou abstrato, ou seja, que exista fisicamente ou apenas conceitualmente, e o qual se pode caracterizar e identificar comportamentos. Podemos afirmar que um objeto uma caixa-preta que recebe e envia mensagens, ou seja, num sistema orientado a objetos, os objetos trocam informaes por meio de mensagens. Num sistema orientado a objetos no modelamos apenas objetos de negcio. Muitas vezes, de acordo com a arquitetura utilizada, modelamos objetos computacionais, visuais ou no. Exemplo: ao levantarmos os requisitos para informatizar uma concessionria, encontraremos o objeto automovel (fsico), da mesma forma que podemos modelar o objeto venda (conceitual). Atributo: as caractersticas associadas aos objetos so chamadas de atributos. Para os objetos de negcio, comum usarmos o conceito de atributo. Para os objetos visuais, utilizamos o conceito de propriedade. Exemplo: atributos da classe Cargo: descricao e salario. Atributos da classe Automovel: modelo, cor, numeroPortas, ano, placa etc. Operao x Mtodo: o comportamento dos objetos representado pelas operaes. Contudo, a operao para um objeto representa apenas a definio do servio que ele oferece a outras estruturas. Quando tratamos da implementao dessa operao, ou seja, da sua representao em cdigo, estamos nos referindo ao seu mtodo. Os mtodos de uma classe manipulam somente as estruturas de dados daquela classe, ou seja, para se ter acesso aos dados de outra classe, isso deve ser feito por meio de mensagens. Exemplo: operaes da classe Cargo: cadastrar() e reajustarSalario(percentual: float). Ao modelarmos uma classe precisamos sempre considerar o contexto. Se no fosse isso, bastaria um famoso metodologista publicar as solues para todas as classes de negcio.

Conceitos fundamentais de orientao a objetos

Os conceitos da orientao a objetos surgiram da necessidade em se enfatizar unidades discretas, e obter a reutilizao de cdigo, mantendo-se a qualidade do software. O ncleo do pensamento OO predomina num foco sobre os dados, em vez dos processos, compondo mdulos auto-suficientes os objetos , encerrando em sua estrutura todo o conhecimento dos dados e dos processos para manipulao desses dados. O que se obtm de principal na modelagem orientada a objetos a possibilidade de se abstrair diretamente os conceitos do mundo real, sem subterfgios para se chegar soluo computacional. Os conceitos fundamentais de orientao a objetos so o contrato que estabelece toda e qualquer implementao que se

Edio 08 Engenharia de Software Magazine 21

Desta forma, no teremos necessariamente os mesmos atributos e operaes para a classe aluno, modelada num sistema acadmico de uma escola de nvel mdio, e a mesma classe aluno, modelada num sistema acadmico de uma Universidade. No garantia termos os mesmos atributos e operaes nem se considerarmos dois sistemas acadmicos modelados para distintas Universidades. Exemplo: Vamos tomar por base a classe Automovel. Se estivermos no contexto de uma concessionria, teremos operaes como: cadastrar, alterarProprietario etc. Em contrapartida, se estivermos no contexto de um simulador para auto-escola, seu comportamento deve reproduzir o objeto real, com operaes como: ligar, aumentar marcha, reduzir marcha, acelerar etc. Estado: so os valores assumidos pelos atributos de um objeto. Exemplo: em um determinado objeto cargo, o estado do seu atributo salario o valor R$ 5000,00. Mensagem: a solicitao que um objeto faz a outro, invocando a execuo de um determinado servio. Por exemplo, para que um objeto possa calcular a folha de pagamento, ele precisa saber o salrio de cada funcionrio. Assim, ele passa uma mensagem ao objeto cargo, solicitando a execuo do servio obterSalario, que nada mais do que uma operao do objeto cargo. Encapsulamento: o conceito de encapsulamento nos remete ao fato de que a utilizao de um sistema orientado a objetos no deve depender de sua implementao interna, e sim de sua interface. Isso garante que os atributos e os mtodos estaro protegidos, s podendo ser acessados pela interface disponibilizada pelo objeto, ou seja, sua lista de servios. Essa proteo garante que os usurios de uma classe no sejam influenciados por quaisquer alteraes feitas em seu contedo. Na prtica, imagine uma classe Produto que possua a operao obterPrecoVenda: float. Essa operao pblica, tornandose um servio disponibilizado a outras classes. Em qualquer rotina que se queira mostrar o preo de venda de um produto, basta instanciar um objeto Produto, e passar uma mensagem para executar o servio, ou seja, chamar a execuo da operao obterPrecoVenda. Suponha que as rotinas A, B, C e D usem esse servio e que at ontem esse valor de venda fosse obtido apenas com um clculo simples:

precoVenda = precoCusto * (1 + lucro/100)

Esse clculo est na implementao de uma operao, ou seja, o seu mtodo, e fica encapsulado (escondido). Suponha agora que hoje foi colocada uma nova verso da classe Produto, na qual esse clculo passa a ser:
precoVenda = precoCusto * (1 + lucro/100) precoVenda = precoVenda * (1 descontoMes/100)

As rotinas A, B, C e D recebero uma exceo em virtude da regra de clculo ter sido alterada? No, eu respondo. transparente para essas rotinas (e precisa ser assim) que houve alterao na forma de clculo do preo de venda. Se estivermos diante de um componente (por exemplo, uma dll), absolutamente nada ser preciso fazer com essas rotinas. Se estivermos com as rotinas dentro do mesmo pacote que a classe, basta recompilar tudo. Herana: ao refinarmos a modelagem de um sistema comum encontrarmos caractersticas redundantes entre objetos. Essa redundncia pode ser evitada pela separao dos atributos e operaes numa classe comum, identificada como superclasse. Essa classe comum (superclasse) passa a ser a generalizao de outras classes que encerram em si apenas os atributos e operaes especficos a cada uma. Exemplo: Suponha que temos duas classes: Cliente e Funcionario. So atributos dessas classes: Cliente (cpf, nome, dataNascimento, endereco, dataPrimeiraCompra) e Funcionario (cpf, nome, dataNascimento, endereco, dataAdmissao, funcao). Imagine que existem operaes que validam o CPF, retornam a idade de um cliente ou funcionrio, ou formatam o endereo. E que todas essas funes apaream em duplicidade nas classes Cliente e Funcionrio. Numa situao dessas, o que se espera na orientao a objetos que essa redundncia seja eliminada com a herana. Assim, cria-se uma superclasse Pessoa, e a ela so atribudos todos os atributos e operaes comuns Cliente e Funcionario. Sobram nas subclasses (Cliente e Funcionario) somente os atributos e operaes especficos a cada um. Na prtica, ao se usar uma subclasse, tem-se acesso a todos os elementos das classes ascendentes, como se tivessem sido criadas na prpria classe filha. Veja na Tabela 1 o resultado desse processo. Quando uma subclasse possui mais do que uma superclasse dito que temos uma herana mltipla.

A herana no precisa se limitar aos objetos de negcio. Pelo contrrio, um dos maiores ganhos que ns temos com a orientao a objetos a possibilidade de se estender todo esse conceito de utilizao para todos os componentes do nosso sistema. Exemplo: podemos criar uma classe para um relatrio, com o logotipo da empresa, dados de identificao do cabealho e do rodap, e a partir dessa classe, herdar todos os outros relatrios do sistema, particularizando em cada um, as caractersticas especficas. Imagine o esforo necessrio para se trocar o logo e incluir o nome do usurio logado em todos os 1000 relatrios de um sistema: calculo uns dois minutos. Polimorfismo: uma operao pode ter implementaes diferentes em diversos pontos da hierarquia de classes. Isso significa que ela ter a mesma assinatura (mesmo nome, lista de argumentos e retorno), porm implementaes diferentes (mtodos). Isso o polimorfismo (poli = muitas; morphos = forma). Exemplo: H uma operao calcularSalario() que pertence classe Funcionario. Herdamos de Funcionario a classe Professor, o que resulta automaticamente na herana de calcularSalario(). Contudo o clculo do salrio de um professor no o mesmo Classes Cliente Atributos Antes da herana cpf nome dataNascimento endereco dataPrimeiraCompra cpf nome dataNascimento endereco dataAdmissao funo Aps a herana Pessoa cpf nome dataNascimento endereco dataPrimeiraCompra dataAdmissao funcao

Funcionario

Cliente Funcionrio

Tabela 1. Estrutura de classes antes e aps remodelar com herana.

22 Engenharia de Software Magazine Conceitos de orientao a objetos e UML

P R O J E TO
que o clculo do salrio de um funcionrio, o que nos leva a ter a mesma operao, porm com mtodos diferentes. Camada Apresentao (interface) Negcio (domnio) Persistncia Responsabilidade Apresentao dos dados e interfaceamento entre o usurio e o sistema Lgica do sistema, implementao das regras de negcio Acesso ao banco de dados

Camadas lgicas x camadas fsicas

H uma certa confuso quando se fala em camadas. A garantia de encapsulamento e autonomia do objeto est pautada no conceito das camadas lgicas. As camadas lgicas (layers) so implementadas independentes da arquitetura do sistema, ou seja, de suas camadas fsicas (tiers). Dessa forma, as trs camadas continuaro a existir mesmo se estiverem implementadas num sistema cliente/servidor (two-tier) ou numa arquitetura web (three-tier). Podemos ter as trs camadas lgicas implementadas at mesmo em um nico computador, stand-alone, com base de dados local, mas ainda assim teremos trs camadas lgicas distintas. A diviso das camadas lgicas mostrada na Tabela 2. A camada de apresentao normalmente representada pela interface grfica, podendo ser representada por qualquer outra forma de entrada de dados. Ao receber uma solicitao do usurio, essa camada se responsabiliza em convert-lo em aes reconhecveis pela prxima camada, a de negcio. Ao receber as respostas da camada de negcio, a camada de apresentao cuida em exibi-las para o usurio. Pode se apresentar de forma mltipla. Exemplo: a rotina da camada de negcio que processa um contra-cheque pode ter sada em duas camadas de apresentao: em uma interface grfica, para utilizao interna, e em uma interface web, para acesso via internet. A camada de negcio tem por objetivo receber as solicitaes da camada de apresentao, e realizar camada de persistncia as solicitaes que se faam necessrias, para processar e devolver o pedido original. Essa camada fica responsvel por todo processamento, clculo e validao inerente aos requisitos da aplicao. A camada de persistncia tem por objetivo receber as solicitaes da camada de negcio, e para realiz-las, prepara e executa as queries necessrias para acesso ao banco de dados. Somente essa camada deve conhecer as fontes de dados e a estrutura das tabelas envolvidas com ela. Isso garante a no propagao de acesso aos dados, o que muitas vezes no s torna a manuteno difcil, como gera erros exponenciais, quando da abrangncia errada de uma alterao.

Tabela 2. Responsabilidades das camadas lgicas de um sistema orientado a objetos

Na Figura 1 exemplificamos como as informaes transitam entre as camadas. Suponha um usurio que via interface grfica queira consultar o salrio lquido de um funcionrio cujo cdigo 100. Ele faz essa solicitao por meio da interface (camada de apresentao). Esta instancia um objeto Funcionrio (objFunc) e faz a chamada do mtodo busca, passando como parmetro o cdigo do funcionrio (100). A solicitao dirigida camada de negcio, que nada pode fazer enquanto no obtiver os dados do banco de dados. Assim, ela repassa o objeto, ainda vazio, camada de persistncia, solicitando que seja feita a busca da persistncia do referido objeto. A camada de persistncia, por sua vez, a nica que conhece a estrutura do banco, prepara uma query de consulta, para recuperar do BD os dados necessrios. De posse dessas informaes, cabe a essa camada associar o contedo retornado do BD aos atributos do objeto (objFunc) e, em seguida, devolvlo camada chamadora. Contudo, para se chegar ao valor do salrio lquido preciso um clculo, cuja regra pertence apenas camada de negcio. Sendo assim, ao retornar segunda camada, esta de posse do valor do salrio bruto, j pode proceder ao clculo que devolver o valor do salrio lquido. O

objeto, agora completo, ento devolvido camada de apresentao, onde seu contedo j pode ser exibido ao usurio.

Aplicabilidade da orientao a objetos

Ao se falar em orientao a objetos, pouco se imagina que a mesma tenha aplicabilidade em diversas fases do desenvolvimento de sistemas: levantamento de requisitos, anlise, implementao e projeto de banco de dados. Durante o levantamento de requisitos fomos beneficiados com o caso de uso. Voc pode pensar imediatamente: Mas o caso de uso orientado a objetos? E a resposta direta: No! A verdade que ele no tem nenhuma referncia orientao a objetos, a no ser ter sido criada por Ivar Jacobson  um dos trs autores da UML , em sua metodologia orientada a objetos (OOSE Object Oriented System Engineering). Seu formato e subdiviso em sees no possuem nenhuma similaridade com os conceitos de classe, herana etc, contudo sua importncia faz coro com as vantagens do paradigma OO. A Engenharia de Requisitos se preocupa desde a identificao do requisito at sua modelagem e especificao. Nas fases de

Figura 1. Exemplo da troca de mensagens entre as camadas lgicas de uma aplicao

Edio 08 Engenharia de Software Magazine 23

modelagem e especificao que o caso de uso vem a ser uma poderosa ferramenta, pois nos permite a comunicao com o usurio, sem que tenhamos a superficialidade de um DFD, ou o excesso de tcnica de um pseudo-cdigo. Dentro de um sistema orientado a objetos, o caso de uso se torna a base para todo o processo de desenvolvimento, visto que a partir do mesmo gerada a primeira verso do modelo de classes, a identificao das trocas de mensagens entre objetos, por meio da modelagem de um diagrama de seqncias, e a gerao dos casos de teste que iro garantir a qualidade do produto final. Numa viso de mais alto nvel do sistema, temos o diagrama de casos de uso. Numa viso de mais baixo nvel, com os detalhes necessrios para que todos os requisitos sejam documentados e modelados, temos os cenrios dos casos de uso. A modelagem de um sistema na fase de anlise tornou-se um processo mais transparente com a utilizao da UML. Diagramas de classe passam a concentrar todas as informaes necessrias sobre os dados (antes modelados com diagramas de entidade-relacionamento) e sobre as funcionalidades (antes modelados com diagramas de fluxo de dados). No s conseguimos que essa fase seja mais transparente, como conseguimos que a transio da fase de anlise para a fase de projeto seja feita de forma automtica. A partir de um modelo de classes, no s geramos um script de banco de dados, como conseguimos gerar automaticamente a estrutura das classes na linguagem de programao escolhida. Da mesma forma, a partir de uma estrutura de banco de dados e de um cdigo j implementado, podemos automaticamente atualizar nosso modelo, pelo processo de engenharia reversa, garantindo que toda a documentao esteja atualizada. Para que essa transparncia e praticidade aconteam imprescindvel que um sistema modelado em UML tenha a sua implementao numa linguagem orientada a objetos. O mesmo j no uma verdade absoluta quando se fala da modelagem de casos de uso. Hoje comum encontrarmos equipes de desenvolvimento que vm utilizando casos de uso para a modelagem e especificao dos requisitos, porm tendo as fases de anlise e projeto voltadas para a metodologia de anlise essencial. Atualmente um padro de mercado a aplicabilidade da orientao a objetos

em todas as fases do desenvolvimento de sistemas, exceto no projeto de banco de dados, que continua sendo feito sobre bancos relacionais. Essa passagem da modelagem OO para o projeto de bancos relacionais conhecida como modelagem objeto-relacional. Contudo, o ideal (que esperamos para um futuro prximo) seria o projeto de banco de dados acompanhar a modelagem OO, ou seja, termos a nossa disposio um banco de objetos. Na realidade, o banco, ou alguns bancos, objetos-relacionais j esto disponveis no mercado, como o Oracle, DB2, Postgress, Cach etc. Tudo comeou com o surgimento dos bancos de objetos, padro definido pela OMG (Object Management Group) que cuidava de apresentar um modelo de dados orientado a objeto. Contudo os bancos BDOO criados sobre este padro trouxeram a facilidade de se implementar modelos complexos, mas deixaram a desejar quanto ao desempenho. Numa corrida para no perder o filo do mercado, os fabricantes de bancos relacionais se reuniram, buscando um padro alternativo, que veio a se chamar objeto-relacional ou relacional-estendido. Assim nasceu a verso 3 do SQL. Com isso, algumas verses recentes dos bancos BDR, atualizadas sobre o padro 3, j oferecem ao mercado a possibilidade de modelar suas bases de dados no modelo OO. O que falta ento? Acredito sinceramente que patrocnio. Patrocnio das empresas de mercado em apostar nessa nova forma de persistir seus dados, pressionando assim os fabricantes a investirem mais no suporte de seus produtos como bancos objeto-relacionais.

Veja na Figura 2 a diferena que temos na implementao da classe Funcionario em uma tabela relacional e em uma tabela de objetos. Espera-se que toda a navegao atravs dos relacionamentos entre as classes de um banco objeto-relacional seja feita por meio da notao de ponto (dot notation). A notao de ponto a forma existente para acessar as propriedades (atributos) ou mtodos de um objeto. Desta forma, no necessrio que a query estabelea explicitamente o relacionamento entre os objetos, visto que este relacionamento j foi previamente definido na definio da classe.

O nascimento da UML
Ao falarmos no comeo do desenvolvimento de sistemas, vimos que a anlise estruturada s surgiu aps a programao estruturada. O mesmo ocorreu com a orientao a objetos (talvez esteja a a origem de todos os problemas computacionais). No incio da dcada de 90 havia mais de 50 mtodos disputando o mercado para se tornar o mtodo principal para a orientao a objetos. Contudo, a maior parte desses mtodos cometia um grave pecado: ser uma extenso dos mtodos estruturados. Os maiores prejudicados eram os usurios que no conseguiam encontrar uma soluo nica e devidamente discutida. Nessa poca, mesmo com contribuies valiosas de outros metodologistas, trs metodologias comearam a dominar o mercado: OMT Object Modeling Technique de James Rumbaugh, mtodo Booch de Grady Booch e OOSE Object-Oriented Software Engineering de Ivar Jacobson. Booch, ciente dos problemas em se ter

Figura 2. Exemplo contrapondo o mapeamento objeto-relacional x transio direta para BDOR

24 Engenharia de Software Magazine Conceitos de orientao a objetos e UML

P R O J E TO
aquela diversidade de mtodos, props ao mercado a unio das metodologias, o que foi rechaado pela maioria. Pouco depois, James Rumbaugh abandonou a General Electric e se juntou Booch na Rational Software, produzindo o mtodo unificado, na sua verso 0.8. Jacobson, ao perceber a similaridade do seu mtodo com o mtodo unificado, logo se uniu a eles. O que nasceu ainda como um mtodo, teve a mudana de perspectiva, passando a ser uma linguagem de modelagem, desacoplando o processo de desenvolvimento. Nascia a UML Unified Modeling Language na sua verso 0.9. Em 1996, a UML j era vista pelas organizaes como uma tima estratgia para seus negcios. A OMG (Object Management Group) emitiu uma RFP (Request for Proposals), que objetivava receber propostas de padronizao para uma metodologia de desenvolvimento orientado a objetos. Respostas foram recebidas da comunidade de engenharia de software e de grandes empresas (Digital, HP, IBM, Microsoft, Oracle e Unisys, entre outras) fortalecendo a proposta da UML. Em janeiro de 1997, a Rational lanou a verso 1.0 da UML como proposta para padronizao na OMG. Entre janeiro e julho novas contribuies foram recebidas, e em 14 de novembro de 1997, a UML 1.1 era adotada como padro pelo OMG. A manuteno da UML passou a ser responsabilidade da RTF (Revision Task Forces), pertencente OMG, sob a direo de Cris Kobryn, centralizando os comentrios e pedidos de reviso da comunidade. Novas verses foram publicadas a partir da, conforme a Tabela 3. Diagrama de objetos (Object Diagram) apresenta objetos e valores de dados. Corresponde a uma instncia do diagrama de classes, mostrando o estado de um sistema em um determinado ponto do tempo. Diagrama de componentes (Component Diagram) mostra as dependncias entre componentes de software, apresentando suas interfaces. Diagrama de estrutura composta (Composite Structure Diagram) usado para mostrar a composio de uma estrutura. til em estruturas compostas de estruturas complexas ou em projetos baseados em componentes Diagrama de pacotes (Package Diagram) usado para organizar elementos de modelo e mostrar dependncias entre eles Diagrama de implantao (Deployment Diagram) mostra a arquitetura do sistema em tempo de execuo, as plataformas de hardware, artefatos de software e ambientes de software (como sistemas operacionais e mquinas virtuais) Diagramas comportamentais (dinmicos): Diagrama de casos de uso (Use Case Diagram) mostra os casos de uso, atores e seus relacionamentos que expressam a funcionalidade de um sistema. Diagrama de atividades (Activity Diagram) representa a execuo de aes ou atividades e os fluxos que so disparados pela concluso de outras aes ou atividades. Diagrama de mquina de estados (Statechart Diagram) representa as aes ocorridas em resposta ao recebimento de eventos. Diagramas de interao: Verso da UML 1.1 1.2 1.3 1.4 1.5 2.0 2.1.1 2.1.2 Publicao Novembro de 1997 Julho de 1998 Maro de 2000 Maio de 2001 Maro de 2003 Julho de 2005 Agosto de 2007 Novembro de 2007 Tipo de reviso Estrutural Somente contedo Somente contedo Estrutural Somente contedo Estrutural Somente contedo Somente contedo

Tabela 3. Histrico das verses da UML

uma variao do diagrama de atividades que mostra de uma forma geral o fluxo de controle dentro de um sistema ou processo de negcios. Cada n ou atividade dentro do diagrama pode representar outro diagrama de interao.
Podemos afirmar que possvel se completar a modelagem de um sistema de pequeno ou mdio porte, com sucesso, com apenas trs diagramas (casos de uso, classes e seqncias), tendo o suporte, dependendo do contexto, de trs outros diagramas (objetos, atividades e mquina de estados). O paradigma da orientao a objetos veio definitivamente ocupar um espao que h muito se necessitava no mercado de desenvolvimento. Cabe aos desenvolvedores entenderem a importncia de se respeitar todos os seus conceitos, para que se obtenha o melhor do que ele nos prope.

Diagramas da UML
O que h de mais relevante na UML o fato de que a linguagem de modelagem nos oferece diversas ferramentas, ficando sob nossa responsabilidade a forma e a ordem como elas sero utilizadas. Alm disso, a UML possui mecanismos de extensibilidade, que permitem a adequao da linguagem aos diversos sistemas existentes no mercado, sem que se perca o entendimento comum ao se usar um mesmo modelo. A verso atual da UML contempla 13 diagramas, divididos em duas categorias: Diagramas estruturais (estticos): Diagrama de classes (Class Diagram) apresenta classes conectadas por relacionamentos. Usado para exibir entidades do mundo real, alm de elementos de anlise e projeto.

Links UML Site www.uml.org Artigo What is Object-Oriented Software?, escrito por Terry Montlick http://www.softwaredesign.com/objects.html ODMG Site www.odmg.org

D seu voto sobre este artigo, atravs do link: www.devmedia.com.br/esmag/feedback

Edio 08 Engenharia de Software Magazine 25

e ta

d i o

S Diagrama de seqncias (Sequence Diagram) mostra as interaes que correspondem a um conjunto de mensagens trocadas entre objetos e a ordem que essas mensagens acontecem. S Diagrama de comunicao (Communication Diagram) o antigo diagrama de colaborao, que mostra objetos, seus inter-relacionamentos e o fluxo de mensagens entre eles S Diagrama temporal (Timing Diagram) mostra a mudana de estado de um objeto numa passagem de tempo, em resposta a eventos externos. S Diagrama de viso geral de interao (Interaction-Overview Diagram)

D seu feedback sobre esta edio! A Engenharia de Software Magazine tem que ser feita ao seu gosto. Para isso, precisamos saber o que voc, leitor, acha da revista!
D s

Feedback eu
sobre e s