Escolar Documentos
Profissional Documentos
Cultura Documentos
Introduo Desenvolvimento de Softwares orientado a objetos UML A unificao dos mtodos para a criao de um novo padro Uso da UML Fases do Desenvolvimento de um Sistema em UML 1. Anlise de Requisitos 2. Anlise 3. Design (Projeto) 4. Programao 5. Testes 6. A Notao da Linguagem de Modelagem Unificada UML 7. Vises 8. Modelos de Elementos 1. Classes 2. Objetos 3. Estados 4. Pacotes 5. Componentes 6. Relacionamentos 7. Mecanismos Gerais 9. Diagramas 1. Diagrama Use-Case 2. Diagrama de Classes 3. Diagrama de Objetos 4. Diagrama de Estado 5. Diagrama de Sequncia 6. Diagrama de Colaborao 7. Diagrama de Atividade 8. Diagrama de Componente 9. Diagrama de Execuo 10. Um processo para utilizar a UML 11. O Futuro da UML 12. Um estudo de caso em UML - Sistema de Controle de Contas Correntes, Poupana e Aplicaes Pr-fixadas 1. Anlise de Requisitos 2. Anlise 3. Design 4. Implementao 5. Testes 13. Concluso
1. Introduo
O grande problema do desenvolvimento de novos sistemas utilizando a orientao a objetos nas fases de anlise de requisitos, anlise de sistemas e design que no existe uma notao padronizada e realmente eficaz que abranja qualquer tipo de aplicao que se deseje. Cada simbologia existente possui seus prprios conceitos, grficos e terminologias, resultando numa grande confuso, especialmente para aqueles que querem utilizar a orientao a objetos no s sabendo para que lado aponta a seta de um relacionamento, mas sabendo criar modelos de qualidade para ajud-los a construir e manter sistemas cada vez mais eficazes. Quando a "Unified Modeling Language" (UML) foi lanada, muitos desenvolvedores da rea da orientao a objetos ficaram entusiasmados j que essa padronizao proposta pela UML era o tipo de fora que eles sempre esperaram. A UML muito mais que a padronizao de uma notao. tambm o desenvolvimento de novos conceitos no normalmente usados. Por isso e muitas outras razes, o bom entendimento da UML no apenas aprender a simbologia e o seu significado, mas tambm significa aprender a modelar orientado a objetos no estado da arte. UML foi desenvolvida por Grady Booch, James Rumbaugh, e Ivar Jacobson que so conhecidos como "os trs amigos". Eles possuem uma extenso conhecimento na rea de modelagem orientado a objetos j que as trs mais conceituadas metodologias de modelagem orientado a objetos foram eles que desenvolveram e a UML a juno do que havia de melhor nestas trs metodologias adicionado novos conceitos e vises da linguagem. Veremos caractersticas de cada uma destas metodologias no desenvolver deste trabalho. Veremos como a UML aborda o carter esttico e dinmico do sistema a ser analisado levando em considerao, j no perodo de modelagem, todas as futuras caractersticas do sistema em relao utilizao de "packages" prprios da linguagem a ser utilizada, utilizao do banco de dados bem como as diversas especificaes do sistema a ser desenvolvido de acordo com as mtricas finais do sistema. No intuito deste trabalho definir e explicar os significados de classes, objetos, relacionamentos, fluxos, mensagens e outras entidades comuns da orientao a objetos, e sim apresentarmos como essas entidades so criadas, simbolizadas, organizadas e como sero utilizadas dentro de um desenvolvimento utilizando a UML.
A orientao a objetos requer um mtodo que integre o processo de desenvolvimento e a linguagem de modelagem com a construo de tcnicas e ferramentas adequadas
Cada um destes mtodos possui sua prpria notao (seus prprios smbolos para representar modelos orientado a objetos), processos (que atividades so desenvolvidas em diferentes partes do desenvolvimento), e ferramentas (as ferramentas CASE que suportam cada uma destas notaes e processos). Diante desta diversidade de conceitos, "os trs amigos", Grady Booch, James Rumbaugh e Ivar Jacobson decidiram criar uma Linguagem de Modelagem Unificada. Eles disponibilizaram inmeras verses preliminares da UML para a comunidade de desenvolvedores e a resposta incrementou muitas novas idias que melhoraram ainda mais a linguagem. Os objetivos da UML so: A modelagem de sistemas (no apenas de software) usando os conceitos da orientao a objetos; Estabelecer uma unio fazendo com que mtodos conceituais sejam tambm executveis; Criar uma linguagem de modelagem usvel tanto pelo homem quanto pela mquina.
A UML est destinada a ser dominante, a linguagem de modelagem comum a ser usada nas indstrias. Ela est totalmente baseada em conceitos e padres extensivamente testados provenientes das metodologias existentes anteriormente, e tambm muito bem documentada com toda a especificao da semntica da linguagem representada em meta-modelos.
4. Uso da UML
A UML usada no desenvolvimento dos mais diversos tipos de sistemas. Ela abrange sempre qualquer caracterstica de um sistema em um de seus diagramas e tambm aplicada em diferentes fases do desenvolvimento de um sistema, desde a especificao da anlise de requisitos at a finalizao com a fase de testes. O objetivo da UML descrever qualquer tipo de sistema, em termos de diagramas orientado a objetos. Naturalmente, o uso mais comum para criar modelos de sistemas de software, mas a UML tambm usada para representar sistemas mecnicos sem nenhum software. Aqui esto alguns tipos diferentes de sistemas com suas caractersticas mais comuns: Sistemas de Informao: Armazenar, pesquisar, editar e mostrar informaes para os usurios. Manter grandes quantidades de dados com relacionamentos complexos, que so guardados em bancos de dados relacionais ou orientados a objetos. Sistemas Tcnicos: Manter e controlar equipamentos tcnicos como de telecomunicaes, equipamentos militares ou processos industriais. Eles devem possuir interfaces especiais do equipamento e menos programao de software de que os sistemas de informao. Sistemas Tcnicos so geralmente sistemas real-time. Sistemas Real-time Integrados: Executados em simples peas de hardware integrados a telefones celulares, carros, alarmes etc. Estes sistemas implementam programao de baixo nvel e requerem suporte real-time. Sistemas Distribudos: Distribudos em mquinas onde os dados so transferidos facilmente de uma mquina para outra. Eles requerem mecanismos de comunicao sincronizados para garantir a integridade dos dados e geralmente so construdos em mecanismos de objetos como CORBA, COM/DCOM ou Java Beans/RMI. Sistemas de Software: Definem uma infra-estrutura tcnica que outros softwares utilizam. Sistemas Operacionais, bancos de dados, e aes de usurios que executam aes de baixo nvel no hardware, ao mesmo tempo em que disponibilizam interfaces genricas de uso de outros softwares. Sistemas de Negcios: descreve os objetivos, especificaes (pessoas, computadores etc.), as regras (leis, estratgias de negcios etc.), e o atual trabalho desempenhado nos processos do negcio.
importante perceber que a maioria dos sistemas no possuem apenas uma destas caractersticas acima relacionadas, mas vrias delas ao mesmo tempo. Sistemas de informaes de hoje, por exemplo, podem ter tanto caractersticas distribudas como real-time. E a UML suporta modelagens de todos estes tipos de sistemas.
5.2. Anlise
A fase de anlise est preocupada com as primeiras abstraes (classes e objetos) e mecanismos que estaro presentes no domnio do problema. As classes so modeladas e ligadas atravs de relacionamentos com outras classes, e so descritas no Diagrama de Classe. As colaboraes entre classes tambm so mostradas neste diagrama para desenvolver os "use-cases" modelados anteriormente, estas colaboraes so criadas atravs de modelos dinmicos em UML. Na anlise, s sero modeladas classes que pertenam ao domnio principal do problema do software, ou seja, classes tcnicas que gerenciem banco de dados, interface, comunicao, concorrncia e outros no estaro presentes neste diagrama.
5.4. Programao
Na fase de programao, as classes provenientes do design so convertidas para o cdigo da linguagem orientada a objetos escolhida (a utilizao de linguagens procedurais extremamente no recomendada). Dependendo da capacidade da linguagem usada, essa converso pode ser uma tarefa fcil ou muito complicada. No momento da criao de modelos de anlise e design em UML, melhor evitar traduzi-los mentalmente em cdigo. Nas fases anteriores, os modelos criados so o significado do entendimento e da estrutura do sistema, ento, no momento da gerao do cdigo onde o analista conclua antecipadamente sobre modificaes em seu contedo, seus modelos no estaro mais demonstrando o real perfil do sistema. A programao uma fase separada e distinta onde os modelos criados so convertidos em cdigo.
5.5. Testes
Um sistema normalmente rodado em testes de unidade, integrao, e aceitao. Os testes de unidade so para classes individuais ou grupos de classes e so geralmente testados pelo programador. Os testes de integrao so aplicados j usando as classes e componentes integrados para se confirmar se as classes esto cooperando uma com as outras como especificado nos modelos. Os testes de aceitao observam o sistema como uma " caixa preta" e verificam se o sistema est funcionando como o especificado nos primeiros diagramas de "use-cases". O sistema ser testado pelo usurio final e verificar se os resultados mostrados esto realmente de acordo com as intenes do usurio final.
<PAROU AQUI>
7. Vises
O desenvolvimento de um sistema complexo no uma tarefa fcil. O ideal seria que o sistema inteiro pudesse ser descrito em um nico grfico e que este representasse por completo as reais intenes do sistema sem ambiguidades, sendo facilmente interpretvel. Infelizmente, isso impossvel. Um nico grfico incapaz de capturar todas as informaes necessrias para descrever um sistema. Um sistema composto por diversos aspectos: funcional (que sua estrutura esttica e suas interaes dinmicas), no funcional (requisitos de tempo, confiabilidade, desenvolvimento, etc.) e aspectos organizacionais (organizao do trabalho, mapeamento dos mdulos de cdigo, etc.). Ento o sistema descrito em um certo nmero de vises, cada uma representando uma projeo da descrio completa e mostrando aspectos particulares do sistema. Cada viso descrita por um nmero de diagramas que contm informaes que do nfase aos aspectos particulares do sistema. Existe em alguns casos uma certa sobreposio entre os diagramas o que significa que um deste pode fazer parte de mais de uma viso. Os diagramas que compem as vises contm os modelos de elementos do sistema. As vises que compem um sistema so:
Viso "use-case": Descreve a funcionalidade do sistema desempenhada pelos atores externos do sistema (usurios). A viso use-case central, j que seu contedo base do desenvolvimento das outras vises do sistema. Essa viso montada sobre os diagramas de use-case e eventualmente diagramas de atividade. Viso Lgica: Descreve como a funcionalidade do sistema ser implementada. feita principalmente pelos analistas e desenvolvedores. Em contraste com a viso use-case, a viso lgica observa e estuda o sistema internamente. Ela descreve e especifica a estrutura esttica do sistema (classes, objetos, e relacionamentos) e as colaboraes dinmicas quando os objetos enviarem mensagens uns para os outros para realizarem as funes do sistema. Propriedades como persistncia e concorrncia so definidas nesta fase, bem como as interfaces e as estruturas de classes. A estrutura esttica descrita pelos diagramas de classes e objetos. O modelamento dinmico descrito pelos diagramas de estado, sequncia, colaborao e atividade. Viso de Componentes: uma descrio da implementao dos mdulos e suas dependncias. principalmente executado por desenvolvedores, e consiste nos componentes dos diagramas.
Viso de concorrncia: Trata a diviso do sistema em processos e processadores. Este aspecto, que uma propriedade no funcional do sistema, permite uma melhor utilizao do ambiente onde o sistema se encontrar, se o mesmo possui execues paralelas, e se existe dentro do sistema um gerenciamento de eventos assncronos. Uma vez dividido o sistema em linhas de execuo de processos concorrentes (threads), esta viso de concorrncia dever mostrar como se d a comunicao e a concorrncia destas threads. A viso de concorrncia suportada pelos diagramas dinmicos, que so os diagramas de estado, sequncia, colaborao e atividade, e pelos diagramas de implementao, que so os diagramas de componente e execuo. Viso de Organizao: Finalmente, a viso de organizao mostra a organizao fsica do sistema, os computadores, os perifricos e como eles se conectam entre si. Esta viso ser executada pelos desenvolvedores, integradores e testadores, e ser representada pelo diagrama de execuo.
8. Modelos de Elementos
Os conceitos usados nos diagramas so chamados de modelos de elementos. Um modelo de elemento definido com a semntica, a definio formal do elemento com o exato significado do que ele representa sem definies duvidosas ou ambguas e tambm define sua representao grfica que mostrada nos diagramas da UML. Um elemento pode existir em diversos tipos de diagramas, mas existem regras que definem que elementos podem ser mostrados em que tipos de diagramas. Alguns exemplos de modelos de elementos so as classes, objetos, estados, pacotes e componentes. Os relacionamentos tambm so modelos de elementos, e so usados para conectar outros modelos de elementos entre si. Todos os modelos de elementos sero definidos e exemplificados a seguir.
8.1. Classes
Uma classe a descrio de um tipo de objeto. Todos os objetos so instncias de classes, onde a classe descreve as propriedades e comportamentos daquele objeto. Objetos s podem ser instanciados de classes. Usam-se classes para classificar os objetos que identificamos no mundo real. Tomando como exemplo Charles Darwin, que usou classes para classificar os animais conhecidos, e combinou suas classes por herana para descrever a "Teoria da Evoluo". A tcnica de herana entre classes tambm usada em orientao a objetos. Uma classe pode ser a descrio de um objeto em qualquer tipo de sistema sistemas de informao, tcnicos, integrados real-time, distribudos, software etc. Num sistema de software, por exemplo, existem classes que representam entidades de software num sistema operacional como arquivos, programas executveis, janelas, barras de rolagem, etc. Identificar as classes de um sistema pode ser complicado, e deve ser feito por experts no domnio do problema a que o software modelado se baseia. As classes devem ser retiradas do domnio do problema e serem nomeadas pelo que elas representam no sistema. Quando procuramos definir as classes de um sistema, existem algumas questes que podem ajudar a identific-las: Existem informaes que devem ser armazenadas ou analisadas? Se existir alguma informao que tenha que ser guardada, transformada ou analisada de alguma forma, ento uma possvel candidata para ser uma classe. Existem sistemas externos ao modelado? Se existir, eles devero ser vistos como classes pelo sistema para que possa interagir com outros externos.
10
Existem classes de bibliotecas, componentes ou modelos externos a serem utilizados pelo sistema modelado? Se sim, normalmente essas classes, componentes e modelos contero classes candidatas ao nosso sistema. Qual o papel dos atores dentro do sistema? Talvez o papel deles possa ser visto como classes, por exemplo, usurio, operador, cliente e da por diante.
Em UML as classes so representadas por um retngulo dividido em trs compartimentos: o compartimento de nome, que conter apenas o nome da classe modelada, o de atributos, que possuir a relao de atributos que a classe possui em sua estrutura interna, e o compartimento de operaes, que sero o mtodos de manipulao de dados e de comunicao de uma classe com outras do sistema. A sintaxe usada em cada um destes compartimentos independente de qualquer linguagem de programao, embora pode ser usadas outras sintaxes como a do C++, Java, e etc.
8.2. Objetos
Um objeto um elemento que podemos manipular, acompanhar seu comportamento, criar, destruir etc. Um objeto existe no mundo real. Pode ser uma parte de qualquer tipo de sistema, por exemplo, uma mquina, uma organizao, ou negcio. Existem objetos que no encontramos no mundo real, mas que podem ser vistos de derivaes de estudos da estrutura e comportamento de outros objetos do mundo real. Em UML um objeto mostrado como uma classe s que seu nome (do objeto) sublinhado, e o nome do objeto pode ser mostrado opcionalmente precedido do nome da classe.
8.3. Estados
Todos os objetos possuem um estado que significa o resultado de atividades executadas pelo objeto, e normalmente determinada pelos valores de seus atributos e ligaes com outros objetos. Um objeto muda de estado quando acontece algo, o fato de acontecer alguma coisa com o objeto chamado de evento. Atravs da anlise da mudana de estados dos tipos de objetos de um sistema, podemos prever todos os possveis comportamentos de um objetos de acordo com os eventos que o mesmo possa sofrer.
11
Um estado, em sua notao, pode conter trs compartimentos. O primeiro mostra o nome do estado. O segundo opcional e mostra a varivel do estado, onde os atributos do objeto em questo podem ser listados e atualizados. Os atributos so aqueles mostrados na representao da classe, e em algumas vezes, podem ser mostradas tambm as variveis temporrias, que so muito teis em diagramas de estado, j que atravs da observncia de seus valores podemos perceber a sua influncia na mudana de estados de um objeto. O terceiro compartimento opcional e chamado de compartimento de atividade, onde eventos e aes podem ser listadas. Trs eventos padres podem ser mostrados no compartimento de atividades de um estado: entrar, sair e fazer. O evento entrar pode ser usado para definir atividades no momento em que o objeto entra naquele estado. O evento sair, define atividades que o objeto executa antes de passar para o prximo estado e o evento fazer define as atividades do objeto enquanto se encontra naquele estado.
8.4. Pacotes
Pacote um mecanismo de agrupamento, onde todos os modelos de elementos podem ser agrupados. Em UML, um pacote definido como: "Um mecanismo de propsito geral para organizar elementos semanticamente relacionados em grupos." Todos os modelos de elementos que so ligados ou referenciados por um pacote so chamados de "Contedo do pacote". Um pacote possui vrios modelos de elementos, e isto significa que estes no podem ser includos em outros pacotes.
Pacotes podem importar modelos de elementos de outros pacotes. Quando um modelo de elemento importado, refere-se apenas ao pacote que possui o elemento. Na grande maioria dos casos, os pacotes possuem relacionamentos com outros pacotes. Embora estes no possuam semnticas definidas para suas instncias. Os relacionamentos permitidos entre pacotes so de dependncia, refinamento e generalizao (herana).
12
O pacote tem uma grande similaridade com a agregao (relacionamento que ser tratado em seguida). O fato de um pacote ser composto de modelos de elementos cria uma agregao de composio. Se este for destrudo, todo o seu contedo tambm ser.
8.5. Componentes
Um componente pode ser tanto um cdigo em linguagem de programao como um cdigo executvel j compilado. Por exemplo, em um sistema desenvolvido em Java, cada arquivo.Java ou.Class um componente do sistema, e ser mostrado no diagrama de componentes que os utiliza.
8.6. Relacionamentos
Os relacionamentos ligam as classes/objetos entre si criando relaes lgicas entre estas entidades. Os relacionamentos podem ser dos seguintes tipos: Associao: uma conexo entre classes, e tambm significa que uma conexo entre objetos daquelas classes. Em UML, uma associao definida com um relacionamento que descreve uma srie de ligaes, onde a ligao definida como a semntica entre as duplas de objetos ligados. Generalizao: um relacionamento de um elemento mais geral e outro mais especfico. O elemento mais especfico pode conter apenas informaes adicionais. Uma instncia (um objeto uma instncia de uma classe) do elemento mais especfico pode ser usada onde o elemento mais geral seja permitido. Dependncia e Refinamentos: Dependncia um relacionamento entre elementos, um independente e outro dependente. Uma modificao um elemento independente afetar diretamente elementos dependentes do anterior. Refinamento um relacionamento entre duas descries de uma mesma entidade, mas em nveis diferentes de abstrao.
8.6.1 Associaes
Uma associao representa que duas classes possuem uma ligao (link) entre elas, significando, por exemplo, que elas "conhecem uma a outra", "esto conectadas com", "para cada X existe um Y" e assim por diante. Classes e associaes so muito poderosas quando modeladas em sistemas complexos.
13
Associaes Normais
O tipo mais comum de associao apenas uma conexo entre classes. representada por uma linha slida entre duas classes. A associao possui um nome (junto linha que representa a associao), normalmente um verbo, mas substantivos tambm so permitidos. Pode-se tambm colocar uma seta no final da associao indicando que esta s pode ser usada para o lado onde a seta aponta. Mas associaes tambm podem possuir dois nomes, significando um nome para cada sentido da associao. Para expressar a multiplicidade entre os relacionamentos, um intervalo indica quantos objetos esto relacionados no link. O intervalo pode ser de zero para um (0..1), zero para vrios (0..* ou apenas *), um para vrios (1..*), dois (2), cinco para 11 (5..11) e assim por diante. tambm possvel expressar uma srie de nmeros como (1, 4, 6..12). Se no for descrito nenhuma multiplicidade, ento considerado o padro de um para um (1..1 ou apenas 1).
No exemplo acima vemos um relacionamento entre as classes Cliente e Conta Corrente se relacionam por associao.
Associao Recursiva
possvel conectar uma classe a ela mesma atravs de uma associao e que ainda representa semanticamente a conexo entre dois objetos, mas os objetos conectados so da mesma classe. Uma associao deste tipo chamada de associao recursiva.
Associao Qualificada
Associaes qualificadas so usadas com associaes de um para vrios (1..*) ou vrios para vrios (*). O "qualificador" (identificador da associao qualificada) especifica como um determinado objeto no final da associao "n" identificado, e pode ser visto como um tipo de chave para separar todos os objetos na associao. O identificador desenhado como uma pequena caixa no final da associao junto classe de onde a navegao deve ser feita.
14
Associao Exclusiva
Em alguns modelos nem todas as combinaes so vlidas, e isto pode causar problemas que devem ser tratados. Uma associao exclusiva uma restrio em duas ou mais associaes. Ela especifica que objetos de uma classe podem participar de no mximo uma das associaes em um dado momento. Uma associao exclusiva representada por uma linha tracejada entre as associaes que so parte da associao exclusiva, com a especificao "{ou}" sobre a linha tracejada.
No diagrama acima um contrato no pode se referir a uma pessoa e a uma empresa ao mesmo tempo, significando que o relacionamento exclusivo a somente uma das duas classes.
Associao Ordenada
As associaes entre objetos podem ter uma ordem implcita. O padro para uma associao desordenada (ou sem nenhuma ordem especfica). Mas uma ordem pode ser especificada atravs da associao ordenada. Este tipo de associao pode ser muito til em casos como este: janelas de um sistema tm que ser ordenadas na tela (uma est no topo, uma est no fundo e assim por diante). A associao ordenada pode ser escrita apenas colocando "{ordenada}" junto linha de associao entre as duas classes.
Associao de Classe
Uma classe pode ser associada a uma outra associao. Este tipo de associao no conectada a nenhuma das extremidades da associao j existente, mas na prpria linha da associao. Esta associao serve para se adicionar informaes extra a associao j existente.
A associao da classe Fila com a associao das classes Cliente e Processo pode ser estendida com operaes de adicionar processos na fila, para ler e remover da fila e de ler o seu tamanho. Se operaes ou atributos so adicionados a associao, ela deve ser mostrada como uma classe.
15
Associao Ternria
Mais de duas classes podem ser associadas entre si, a associao ternria associa trs classes. Ela mostrada como um grade losango (diamante) e ainda suporta uma associao de classe ligada a ela, traaria-se, ento, uma linha tracejada a partir do losango para a classe onde seria feita a associao ternria.
No exemplo acima a associao ternria especifica que um cliente poder possuir 1 ou mais contratos e cada contrato ser composto de 1 ou vrias regras contratuais.
Agregao
A agregao um caso particular da associao. A agregao indica que uma das classes do relacionamento uma parte, ou est contida em outra classe. As palavras chaves usadas para identificar uma agregao so: "consiste em", "contm", " parte de".
Existem tipos especiais de agregao que so as agregaes compartilhadas e as compostas. Agregao Compartilhada: dita compartilhada quando uma das classes uma parte, ou est contida na outra, mas esta parte pode fazer estar contida na outra vrias vezes em um mesmo momento.
No exemplo acima uma pessoa pode ser membro de um time ou vrios times e em determinado momento. Agregao de Composio: uma agregao onde uma classe que est contida na outra "vive" e constitui a outra. Se o objeto da classe que contm for destrudo, as classes da agregao de composio sero destrudas juntamente j que as mesmas fazem parte da outra.
16
8.6.2. Generalizaes
A generalizao um relacionamento entre um elemento geral e um outro mais especfico. O elemento mais especfico possui todas as caractersticas do elemento geral e contm ainda mais particularidades. Um objeto mais especfico pode ser usado como uma instncia do elemento mais geral. A generalizao, tambm chamada de herana, permite a criao de elementos especializados em outros. Existem alguns tipos de generalizaes que variam em sua utilizao a partir da situao. So elas: generalizao normal e restrita. As generalizaes restritas se dividem em generalizao de sobreposio, disjuntiva, completa e incompleta.
Generalizao Normal
Na generalizao normal a classe mais especfica, chamada de subclasse, herda tudo da classe mais geral, chamada de superclasse. Os atributos, operaes e todas as associaes so herdadas.
Uma classe pode ser tanto uma subclasse quanto uma superclasse, se ela estiver numa hierarquia de classes que um grfico onde as classes esto ligadas atravs de generalizaes. A generalizao normal representada por uma linha entre as duas classes que fazem o relacionamento, sendo que coloca-se um seta no lado da linha onde encontra-se a superclasse indicando a generalizao.
Generalizao Restrita
Uma restrio aplicada a uma generalizao especifica informaes mais precisas sobre como a generalizao deve ser usada e estendida no futuro. As restries a seguir definem as generalizaes restritas com mais de uma subclasse: Generalizaes de Sobreposio e Disjuntiva: Generalizao de sobreposio significa que quando subclasses herdam de uma superclasse por sobreposio, novas subclasses destas podem herdar de mais de uma subclasse. A generalizao disjuntiva exatamente o contrrio da sobreposio e a generalizao utilizada como padro.
17
Generalizaes Completa e Incompleta: Uma restrio simbolizando que uma generalizao completa significa que todas as subclasses j foram especificadas, e no existe mais possibilidade de outra generalizao a partir daquele ponto. A generalizao incompleta exatamente o contrrio da completa e assumida como padro da linguagem.
18
Os refinamentos so um tipo de relacionamento entre duas descries de uma mesma coisa, mas em nveis de abstrao diferentes e podem ser usados para modelar diferentes implementaes de uma mesma coisa (uma implementao simples e outra mais complexa, mas tambm mais eficiente). Os refinamentos so simbolizados por uma linha tracejada com um tringulo no final de um dos lados do relacionamento e so usados em modelos de coordenao. Em grandes projetos, todos os modelos que so feitos devem ser coordenados. Coordenao de modelos pode ser usada para mostrar modelos em diferentes nveis de abstrao que se relacionam e mostram tambm como modelos em diferentes fases de desenvolvimento se relacionam.
9. Diagramas
Os diagramas utilizados pela UML so compostos de nove tipos: diagrama de use case, de classes, de objeto, de estado, de sequncia, de colaborao, de atividade, de componente e o de execuo.
19
Todos os sistemas possuem uma estrutura esttica e um comportamento dinmico. A UML suporta modelos estticos (estrutura esttica), dinmicos (comportamento dinmico) e funcional. A Modelagem esttica suportada pelo diagrama de classes e de objetos, que consiste nas classes e seus relacionamentos. Os relacionamentos podem ser de associaes, herana (generalizao), dependncia ou refinamentos. Os modelamentos dinmicos so suportados pelos diagramas de estado, sequncia, colaborao e atividade. E o modelamento funcional suportado pelos diagramas de componente e execuo. Abordaremos agora cada um destes tipos de diagrama:
20
O diagrama de use-cases acima demonstra as funes de um ator externo de um sistema de controle bancrio de um banco fictcio que foi modelado no estudo de caso no final deste trabalho. O diagrama especifica que funes o administrador do banco poder desempenhar. Pode-se perceber que no existe nenhuma preocupao com a implementao de cada uma destas funes, j que este diagrama apenas se resume a determinar que funes devero ser suportadas pelo sistema modelado.
21
Uma classe num diagrama pode ser diretamente implementada utilizando-se uma linguagem de programao orientada a objetos que tenha suporte direto para construo de classes. Para criar um diagrama de classes, as classes tm que estar identificadas, descritas e relacionadas entre si.
22
para aquelas que possuem um nmero definido de estados conhecidos e onde o comportamento das classes afetado e modificado pelos diferentes estados. Diagramas de estado capturam o ciclo de vida dos objetos, subsistemas e sistemas. Eles mostram os estados que um objeto pode possuir e como os eventos (mensagens recebidas, timer, erros, e condies sendo satisfeitas) afetam estes estados ao passar do tempo.
Diagramas de estado possuem um ponto de incio e vrios pontos de finalizao. Um ponto de incio (estado inicial) mostrado como um crculo todo preenchido, e um ponto de finalizao (estado final) mostrado como um crculo em volta de um outro crculo menor preenchido. Um estado mostrado como um retngulo com cantos arredondados. Entre os estados esto as transies, mostrados como uma linha com uma seta no final de um dos estados. A transio pode ser nomeada com o seu evento causador. Quando o evento acontece, a transio de um estado para outro executada ou disparada. Uma transio de estado normalmente possui um evento ligado a ela. Se um evento anexado a uma transio, esta ser executada quando o evento ocorrer. Se uma transio no possuir um evento ligado a ela, a mesma ocorrer quando a ao interna do cdigo do estado for executada (se existir aes internas como entrar, sair, fazer ou outras aes definidas pelo desenvolvedor). Ento quando todas as aes forem executadas pelo estado, a transio ser disparada e sero iniciadas as atividades do prximo estado no diagrama de estados.
23
citamos: mensagens recebidas ou enviadas e ativao de objetos. A comunicao entre os objetos representada como linha com setas horizontais simbolizando as mensagens entre as linhas de vida dos objetos. A seta especifica se a mensagem sncrona, assncrona ou simples. As mensagens podem possuir tambm nmeros sequenciais, eles so utilizados para tornar mais explcito as sequncia no diagrama. Em alguns sistemas, objetos rodam concorrentemente, cada um com sua linha de execuo (thread). Se o sistema usa linhas concorrentes de controle, isto mostrado como ativao, mensagens assncronas, ou objetos assncronos.
Os diagramas de sequncia podem mostrar objetos que so criados ou destrudos como parte do cenrio documentado pelo diagrama. Um objeto pode criar outros objetos atravs de mensagens. A mensagem que cria ou destroi um objeto geralmente sncrona, representada por uma seta slida.
24
O diagrama de atividade mostra o fluxo sequencial das atividades, normalmente utilizado para demonstrar as atividades executadas por uma operao especfica do sistema. Consistem em estados de ao, que contm a especificao de uma atividade a ser desempenhada por uma operao do sistema. Decises e condies, como execuo paralela, tambm podem ser mostrados na diagrama de atividade. O diagrama tambm pode conter especificaes de mensagens enviadas e recebidas como partes de aes executadas.
25
26
Componentes podem definir interfaces que so visveis para outros componentes. As interfaces podem ser tanto definidas ao nvel de codificao (como em Java) quanto em interfaces binrias usadas em run-time (como em OLE). Uma interface mostrada como uma linha partindo do componente e com um crculo na outra extremidade. O nome colocado junto do crculo no final da linha. Dependncias entre componentes podem ento apontar para a interface do componente que est sendo usada.
27
Cada fase no ciclo executada em sries de interaes que podem sobrepor outras fases. Cada interao consiste tipicamente em atividades tradicionais como anlise e design, mas em diferentes propores dependendo da fase em que esteja a gerao do sistema em desenvolvimento. Ferramentas modernas devem dar suporte no apenas para linguagens de modelagem e programao, mas devem suportar um mtodo de desenvolvimento de sistemas tambm. Isso inclui conhecimento das fases em um processo, ajuda online, e aconselhamentos do que fazer em cada fase do desenvolvimento, suporte a desenvolvimento interativo e fcil integrao com outras ferramentas.
28
29
Tendo em mos esta relao de atividades, j podemos modelar o diagrama de use-case do sistema.
30
12.2. Anlise
Na fase de anlise, tendo em mos o diagrama de use-case, podemos definir o diagrama de classes do sistema. Este primeiro diagrama da fase de anlise dever ser totalmente despreocupado de qualquer tipo de tcnica relacionada a implementao do sistema, ou seja, mtodos e atributos de acesso a banco de dados, estrutura de mensagens entre objetos, etc. no devero aparecer nesse primeiro diagrama, apenas os tipos de objetos bsicos do sistema. Analisamos e percebemos que existiro 8 classes no sistema e que se relacionaro segundo o diagrama de classes a seguir.
31
J temos em mos as funes primordiais do sistema (diagrama de use-cases) e o diagrama de classes da anlise do domnio do problema, partiremos agora para traar como estas classes iro interagir para realizar as funes do sistema. Lembramos que ainda nesta fase nenhum tipo de tcnica de implementao deve ser considerada. Para modelarmos como os objetos do sistema iro interagir entre si, utilizamos o diagrama de sequncia ou o de colaborao. E modelaremos um diagrama para cada funo (use-case)
32
definida no diagrama de use-cases. Escolhemos o diagrama de sequncia para dar mais nfase a ordem cronolgica das interaes entre os objetos. J se faz necessrio utilizar idias bsicas da modelagem da interface do sistema como as janelas. Mas esses objetos de interface sero totalmente detalhados na fase de design.
Nesta fase modela-se tambm o diagrama de estado das classes. Mas este se enquadra em situaes onde o comportamento dos objetos importante para aplicao. Em casos de modelagens de sistemas para equipamentos mecnicos.
12.3. Design
Nesta fase comearemos a implementar em nossos modelos os melhoramentos e tcnicas de como realmente cada funo do sistema ser concebida. Sero modelos mais detalhados com nfase nas solues para armazenamento dos dados, funes primordiais do sistema e interface com o usurio. A fase de design pode ser dividida em outras duas fases: Design da arquitetura: Este o design de alto nvel onde os pacotes (subsistemas) so definidos, incluindo as dependncias e mecanismos de comunicao entre eles. Naturalmente, o objetivo criar uma arquitetura simples e clara, onde as dependncias sejam poucas e que possam ser bidirecionais sempre que possvel. Design detalhado: Esta parte detalha o contedo dos pacotes, ento todas classes sero totalmente descritas para mostrar especificaes claras para o programador que ir gerar o cdigo da classe. Modelos dinmicos do UML so usados para demonstrar como os objetos se comportam em diferentes situaes.
Design da arquitetura
Uma arquitetura bem projetada a base para futuras expanses e modificaes no sistema. Os pacotes podem ser responsveis por funes lgicas ou tcnicas do sistema. de vital importncia separar a lgica da aplicao da lgica tcnica. Isso facilitar muito futuras mudanas no sistema. Em nosso caso de estudo, identificamos 4 pacotes (subsistemas):
33
Pacote da Interface do Usurio: Estaro contidas as classes para a criao da interface do usurio, para possibilitar que estes acessem e entrem com novos dados no sistema. Estas classes so baseadas no pacote Java AWT, que o padro Java para criao de interfaces. Este pacote coopera com o pacote de objetos do sistema, que contm as classes onde os dados esto guardados. O pacote de interface chama operaes no pacote de objetos do sistema para acessar e inserir novos dados. Pacote de Objetos do Sistema: Este pacote inclui classes bsicas, ou seja, classes que foram desenvolvidas exatamente para tornar o sistema em desenvolvimento funcional. Estas classes so detalhadas no design, ento so includos operaes e mtodos em sua estrutura e o suporte Persistncia adicionado. O pacote de objetos deve interagir com o de banco de dados e todas as suas classes devem herdar da classe Persistente do pacote de banco de dados Pacote de Banco de Dados: Este pacote disponibiliza servios para as classes do pacote de objetos fazendo com que os dados armazenados no sistema sejam gravados em disco. Pacote de Utilidades: Este contm servios que so usados por todos os outros pacotes do sistema. Atualmente a classe ObjId a nica no pacote, e usada para referenciar os objetos persistentes em todo o sistema.
Design detalhado
O propsito do design detalhado descrever as novas classes tcnicas do sistema, como classes de criao da interface, de banco de dados e para expandir e detalhar a descrio das classes de objetos, que j foram definidas na fase de anlise. Tudo isto feito com a criao de novos diagramas de classes, de estado, e dinmicos. Sero os mesmos diagramas criados na fase de anlise, mas um nvel de detalhamento tcnico mais elevado. As descries de use-cases provenientes da fase de anlise so usados para verificar se estes esto sendo suportados pelos diagramas gerados na fase de design, e diagramas de sequncia so usados para ilustrar como cada use-case tecnicamente implementada no sistema.
34
Criamos os diagramas de sequncia para funes do sistema, descritas no diagrama de usecases, j possuindo os parmetros para cada mensagem entre os objetos.
35
O layout das janelas deve ser criado com alguma ferramenta visual de acordo com a preferncia do desenvolvedor. Ferramentas visuais j geram o cdigo necessrio para a criao de janelas. Algumas ferramentas j suportam a adio de controladores de eventos para eventos disparados por usurios como cliques em botes. O ambiente gera um mtodo okbutton_Clicked que ser chamado quando o boto "OK" for pressionado. A aplicao resultante da interface de usurio uma janela principal com um menu de opes. Cada opo escolhida do menu mostrar uma janela nova que juntas sero responsveis por receber as informaes do usurio e executar a funo a qual se propem a fazer.
12.4. Implementao
A fase de construo ou implementao quando as classes so codificadas. Os requisitos especificam que o sistema deve ser capaz de rodar em diversos tipo de processadores e sistemas operacionais, ento a linguagem escolhida foi Java. Pelo fato de em Java cada arquivo poder conter uma e somente uma classe, podemos facilmente escrever um diagrama de componentes contendo um mapeamento das classes provenientes da viso lgica. Agora codificamos cada classe do pacote de objetos do sistema, a interface, o banco de dados e o pacote de utilidades. A codificao deve ser baseada nos modelos desenvolvidos nas fases de anlise de requisitos, anlise e design, mais precisamente nas especificaes de classes, diagramas de classes, de estado, dinmicos, de use-cases e especificao. Existiro algumas deficincias durante a fase de codificao. A necessidade da criao de novas operaes e modificaes em operaes j existentes sero identificadas, significando que o desenvolvedor ter que mudar seus modelos da fase de design. Isto ocorre em todos os projetos. O que mais importante que sejam sincronizados a modelagem de design com a codificao, desta forma os modelos podero ser usados como documentao final do sistema.
12.5. Testes
A aplicao dever ser testada. Deve-se verificar se o programa suporta toda a funcionalidade que lhe foi especificada na fase de anlise de requisitos com o diagrama de use-cases. A aplicao deve ser tambm testada da forma mais informal colocando-se o sistema nas mos dos usurios.
13. Concluso
O criao de uma linguagem para a comunidade de desenvolvedores em orientao a objetos era uma necessidade antiga. A UML realmente incorporou muitos recursos com do a linguagem uma extensibilidade muito grande. Os organizao da modelagem em vises e a diviso dos diagramas especificando caractersticas estticas e dinmicas do sistema tornou a UML fcil de ser utilizada e fez com que qualquer tipo de comportamento possa ser visualizado em diagramas. A modelagem visual orientada a objetos agora possui um padro, e esse padro extremamente simples de ser escrito a mo, sendo robusto para especificar e descrever a grande maioria das funes, relacionamentos e tcnicas de desenvolvimento orientado a objetos que hoje so utilizados. Novas tcnicas iro surgir e a UML tambm estar preparada j que tudo estar baseado nas idias elementares da orientao a objetos. Sem dvida alguma a UML facilitar s grandes empresas de desenvolvimento de software uma maior comunicao e aproveitamento dos modelos desenvolvidos pelos seus vrios analistas envolvidos no processo de produo de software j que a linguagem que ser
36
utilizada por todos ser a mesma, acabando assim com qualquer problema de interpretao e mal-entendimento de modelos criados por outros desenvolvedores. Os modelos criados hoje podero ser facilmente analisados por futuras geraes de desenvolvedores acabando com a diversidade de tipos de nomenclaturas de modelos, o grande empecilho do desenvolvimento de softwares orientados a objetos. Os fabricantes de ferramentas CASE agora suportaro a UML em seus softwares e a fase de codificao ser cada vez mais substituda pela gerao de cdigo automtico desempenhada pelas ferramentas CASE.
37