Docsity
Docsity

Prepare-se para as provas
Prepare-se para as provas

Estude fácil! Tem muito documento disponível na Docsity


Ganhe pontos para baixar
Ganhe pontos para baixar

Ganhe pontos ajudando outros esrudantes ou compre um plano Premium


Guias e Dicas
Guias e Dicas

Linguagem de modelagem unificada em Português, Notas de estudo de Metodologias de Desenvolvimento de Software

UML - UML - UML - UML

Tipologia: Notas de estudo

Antes de 2010
Em oferta
30 Pontos
Discount

Oferta por tempo limitado


Compartilhado em 28/04/2008

lpcnew-1
lpcnew-1 🇧🇷

5

(6)

10 documentos

1 / 37

Documentos relacionados


Pré-visualização parcial do texto

Baixe Linguagem de modelagem unificada em Português e outras Notas de estudo em PDF para Metodologias de Desenvolvimento de Software, somente na Docsity! NL Linguagem de Modelagem Unificada UNIFIED MODELING Em Port ês LANGUAGE oreugu 1. Introdução 2. Desenvolvimento de Softwares orientado a objetos 3. UML – A unificação dos métodos para a criação de um novo padrão 4. Uso da UML 5. Fases do Desenvolvimento de um Sistema em UML 1. Análise de Requisitos 2. Análise 3. Design (Projeto) 4. Programação 5. Testes 6. A Notação da Linguagem de Modelagem Unificada – UML 7. Visões 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 Sequência 6. Diagrama de Colaboração 7. Diagrama de Atividade 8. Diagrama de Componente 9. Diagrama de Execução 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, Poupança e Aplicações Pré-fixadas 1. Análise de Requisitos 2. Análise 3. Design 4. Implementação 5. Testes 13. Conclusão 2 3. UML – A unificação dos métodos para a criação de um novo padrão A UML é uma tentativa de padronizar a modelagem orientada a objetos de uma forma que qualquer sistema, seja qual for o tipo, possa ser modelado corretamente, com consistência, fácil de se comunicar com outras aplicações, simples de ser atualizado e compreensível. Existem várias metodologias de modelagem orientada a objetos que até o surgimento da UML causavam uma guerra entre a comunidade de desenvolvedores orientado a objetos. A UML acabou com esta guerra trazendo as melhores idéias de cada uma destas metodologias, e mostrando como deveria ser a migração de cada uma para a UML. Falaremos sobre algumas das principais metodologias que se tornaram populares nos anos 90: • Booch – O método de Grady Booch para desenvolvimento orientado a objetos está disponível em muitas versões. Booch definiu a noção de que um sistema é analisado a partir de um número de visões, onde cada visão é descrita por um número de modelos e diagramas. O Método de Booch trazia uma simbologia complexa de ser desenhada a mão, continha também o processo pelo qual sistemas são analisados por macro e micro visões. • OMT – Técnica de Modelagem de Objetos (Object Modelling Technique) é um método desenvolvido pela GE (General Electric) onde James Rumbaugh trabalhava. O método é especialmente voltado para o teste dos modelos, baseado nas especificações da análise de requisitos do sistema. O modelo total do sistema baseado no método OMT é composto pela junção dos modelos de objetos, funcional e use-cases. • OOSE/Objectory – Os métodos OOSE e o Objectory foram desenvolvidos baseados no mesmo ponto de vista formado por Ivar Jacobson. O método OOSE é a visão de Jacobson de um método orientado a objetos, já o Objectory é usado para a construção de sistemas tão diversos quanto eles forem. Ambos os métodos são baseados na utilização de use-cases, que definem os requisitos iniciais do sistema, vistos por um ator externo. O método Objectory também foi adaptado para a engenharia de negócios, onde é usado para modelar e melhorar os processos envolvidos no funcionamento de empresas. Cada um destes métodos possui sua própria notação (seus próprios símbolos para representar modelos orientado a objetos), processos (que atividades são desenvolvidas em diferentes partes do desenvolvimento), e ferramentas (as ferramentas CASE que suportam cada uma destas notações e processos). Diante desta diversidade de conceitos, "os três amigos", Grady Booch, James Rumbaugh e Ivar Jacobson decidiram criar uma Linguagem de Modelagem Unificada. Eles disponibilizaram inúmeras versões preliminares da UML para a comunidade de desenvolvedores e a resposta incrementou muitas novas idéias que melhoraram ainda mais a linguagem. Os objetivos da UML são: • A modelagem de sistemas (não apenas de software) usando os conceitos da orientação a objetos; • Estabelecer uma união fazendo com que métodos conceituais sejam também executáveis; • Criar uma linguagem de modelagem usável tanto pelo homem quanto pela máquina. 5 A UML está destinada a ser dominante, a linguagem de modelagem comum a ser usada nas indústrias. Ela está totalmente baseada em conceitos e padrões extensivamente testados provenientes das metodologias existentes anteriormente, e também é muito bem documentada com toda a especificação da semântica 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 característica de um sistema em um de seus diagramas e é também aplicada em diferentes fases do desenvolvimento de um sistema, desde a especificação da análise de requisitos até a finalização 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 também é usada para representar sistemas mecânicos sem nenhum software. Aqui estão alguns tipos diferentes de sistemas com suas características mais comuns: • Sistemas de Informação: Armazenar, pesquisar, editar e mostrar informações para os usuários. Manter grandes quantidades de dados com relacionamentos complexos, que são guardados em bancos de dados relacionais ou orientados a objetos. • Sistemas Técnicos: Manter e controlar equipamentos técnicos como de telecomunicações, equipamentos militares ou processos industriais. Eles devem possuir interfaces especiais do equipamento e menos programação de software de que os sistemas de informação. Sistemas Técnicos são geralmente sistemas real-time. • Sistemas Real-time Integrados: Executados em simples peças de hardware integrados a telefones celulares, carros, alarmes etc. Estes sistemas implementam programação de baixo nível e requerem suporte real-time. • Sistemas Distribuídos: Distribuídos em máquinas onde os dados são transferidos facilmente de uma máquina para outra. Eles requerem mecanismos de comunicação sincronizados para garantir a integridade dos dados e geralmente são construídos em mecanismos de objetos como CORBA, COM/DCOM ou Java Beans/RMI. • Sistemas de Software: Definem uma infra-estrutura técnica que outros softwares utilizam. Sistemas Operacionais, bancos de dados, e ações de usuários que executam ações de baixo nível no hardware, ao mesmo tempo em que disponibilizam interfaces genéricas de uso de outros softwares. • Sistemas de Negócios: descreve os objetivos, especificações (pessoas, computadores etc.), as regras (leis, estratégias de negócios etc.), e o atual trabalho desempenhado nos processos do negócio. É importante perceber que a maioria dos sistemas não possuem apenas uma destas características acima relacionadas, mas várias delas ao mesmo tempo. Sistemas de informações de hoje, por exemplo, podem ter tanto características distribuídas como real-time. E a UML suporta modelagens de todos estes tipos de sistemas. 6 5. Fases do Desenvolvimento de um Sistema em UML Existem cinco fases no desenvolvimento de sistemas de software: análise de requisitos, análise, design (projeto), programação e testes. Estas cinco fases não devem ser executadas na ordem descrita acima, mas concomitantemente de forma que problemas detectados numa certa fase modifiquem e melhorem as fases desenvolvidas anteriormente de forma que o resultado global gere um produto de alta qualidade e performance. A seguir falaremos sobre cada fase do desenvolvimento de um sistema em UML: 5.1. Análise de Requisitos Esta fase captura as intenções e necessidades dos usuários do sistema a ser desenvolvido através do uso de funções chamadas "use-cases". Através do desenvolvimento de "use-case", as entidades externas ao sistema (em UML chamados de "atores externos") que interagem e possuem interesse no sistema são modelados entre as funções que eles requerem, funções estas chamadas de "use-cases". Os atores externos e os "use-cases" são modelados com relacionamentos que possuem comunicação associativa entre eles ou são desmembrados em hierarquia. Cada "use-case" modelado é descrito através de um texto, e este especifica os requerimentos do ator externo que utilizará este "use-case". O diagrama de "use-cases" mostrará o que os atores externos, ou seja, os usuários do futuro sistema deverão esperar do aplicativo, conhecendo toda sua funcionalidade sem importar como esta será implementada. A análise de requisitos também pode ser desenvolvida baseada em processos de negócios, e não apenas para sistemas de software. 5.2. Análise A fase de análise está preocupada com as primeiras abstrações (classes e objetos) e mecanismos que estarão presentes no domínio do problema. As classes são modeladas e ligadas através de relacionamentos com outras classes, e são descritas no Diagrama de Classe. As colaborações entre classes também são mostradas neste diagrama para desenvolver os "use-cases" modelados anteriormente, estas colaborações são criadas através de modelos dinâmicos em UML. Na análise, só serão modeladas classes que pertençam ao domínio principal do problema do software, ou seja, classes técnicas que gerenciem banco de dados, interface, comunicação, concorrência e outros não estarão presentes neste diagrama. 5.3. Design (Projeto) Na fase de design, o resultado da análise é expandido em soluções técnicas. Novas classes serão adicionadas para prover uma infra-estrutura técnica: a interface do usuário e de periféricos, gerenciamento de banco de dados, comunicação com outros sistemas, dentre outros. As classes do domínio do problema modeladas na fase de análise são mescladas nessa nova infra-estrutura técnica tornando possível alterar tanto o domínio do problema quanto à infra-estrutura. O design resulta no detalhamento das especificações para a fase de programação do sistema. 5.4. Programação Na fase de programação, as classes provenientes do design são convertidas para o código da linguagem orientada a objetos escolhida (a utilização de linguagens procedurais é extremamente não recomendada). Dependendo da capacidade da linguagem usada, essa conversão pode ser uma tarefa fácil ou muito complicada. No momento da criação de modelos de análise e design em UML, é melhor evitar traduzi-los mentalmente em código. Nas fases anteriores, os modelos criados são o significado do entendimento e da estrutura do sistema, então, no momento da geração do código onde o analista conclua antecipadamente sobre modificações em seu conteúdo, seus modelos não estarão mais demonstrando o real perfil do sistema. A programação é uma fase separada e distinta onde os modelos criados são convertidos em código. 7 • Visão de concorrência: Trata a divisão do sistema em processos e processadores. Este aspecto, que é uma propriedade não funcional do sistema, permite uma melhor utilização do ambiente onde o sistema se encontrará, se o mesmo possui execuções paralelas, e se existe dentro do sistema um gerenciamento de eventos assíncronos. Uma vez dividido o sistema em linhas de execução de processos concorrentes (threads), esta visão de concorrência deverá mostrar como se dá a comunicação e a concorrência destas threads. A visão de concorrência é suportada pelos diagramas dinâmicos, que são os diagramas de estado, sequência, colaboração e atividade, e pelos diagramas de implementação, que são os diagramas de componente e execução. • Visão de Organização: Finalmente, a visão de organização mostra a organização física do sistema, os computadores, os periféricos e como eles se conectam entre si. Esta visão será executada pelos desenvolvedores, integradores e testadores, e será representada pelo diagrama de execução. 8. Modelos de Elementos Os conceitos usados nos diagramas são chamados de modelos de elementos. Um modelo de elemento é definido com a semântica, a definição formal do elemento com o exato significado do que ele representa sem definições duvidosas ou ambíguas e também define sua representação gráfica 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 são as classes, objetos, estados, pacotes e componentes. Os relacionamentos também são modelos de elementos, e são usados para conectar outros modelos de elementos entre si. Todos os modelos de elementos serão definidos e exemplificados a seguir. 8.1. Classes Uma classe é a descrição de um tipo de objeto. Todos os objetos são instâncias 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 herança para descrever a "Teoria da Evolução". A técnica de herança entre classes é também usada em orientação a objetos. Uma classe pode ser a descrição de um objeto em qualquer tipo de sistema – sistemas de informação, técnicos, integrados real-time, distribuídos, software etc. Num sistema de software, por exemplo, existem classes que representam entidades de software num sistema operacional como arquivos, programas executáveis, janelas, barras de rolagem, etc. Identificar as classes de um sistema pode ser complicado, e deve ser feito por experts no domínio do problema a que o software modelado se baseia. As classes devem ser retiradas do domínio do problema e serem nomeadas pelo que elas representam no sistema. Quando procuramos definir as classes de um sistema, existem algumas questões que podem ajudar a identificá-las: • Existem informações que devem ser armazenadas ou analisadas? Se existir alguma informação que tenha que ser guardada, transformada ou analisada de alguma forma, então é uma possível candidata para ser uma classe. • Existem sistemas externos ao modelado? Se existir, eles deverão 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 conterão classes candidatas ao nosso sistema. • Qual o papel dos atores dentro do sistema? Talvez o papel deles possa ser visto como classes, por exemplo, usuário, operador, cliente e daí por diante. Em UML as classes são representadas por um retângulo dividido em três compartimentos: o compartimento de nome, que conterá apenas o nome da classe modelada, o de atributos, que possuirá a relação de atributos que a classe possui em sua estrutura interna, e o compartimento de operações, que serão o métodos de manipulação de dados e de comunicação de uma classe com outras do sistema. A sintaxe usada em cada um destes compartimentos é independente de qualquer linguagem de programação, 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 máquina, uma organização, ou negócio. Existem objetos que não encontramos no mundo real, mas que podem ser vistos de derivações 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 ligações com outros objetos. Um objeto muda de estado quando acontece algo, o fato de acontecer alguma coisa com o objeto é chamado de evento. Através da análise da mudança de estados dos tipos de objetos de um sistema, podemos prever todos os possíveis comportamentos de um objetos de acordo com os eventos que o mesmo possa sofrer. 11 Um estado, em sua notação, pode conter três compartimentos. O primeiro mostra o nome do estado. O segundo é opcional e mostra a variável do estado, onde os atributos do objeto em questão podem ser listados e atualizados. Os atributos são aqueles mostrados na representação da classe, e em algumas vezes, podem ser mostradas também as variáveis temporárias, que são muito úteis em diagramas de estado, já que através da observância de seus valores podemos perceber a sua influência na mudança de estados de um objeto. O terceiro compartimento é opcional e é chamado de compartimento de atividade, onde eventos e ações podem ser listadas. Três eventos padrões 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 próximo 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 propósito geral para organizar elementos semanticamente relacionados em grupos." Todos os modelos de elementos que são ligados ou referenciados por um pacote são chamados de "Conteúdo do pacote". Um pacote possui vários modelos de elementos, e isto significa que estes não podem ser incluídos 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 não possuam semânticas definidas para suas instâncias. Os relacionamentos permitidos entre pacotes são de dependência, refinamento e generalização (herança). 12 Associação Exclusiva Em alguns modelos nem todas as combinações são válidas, e isto pode causar problemas que devem ser tratados. Uma associação exclusiva é uma restrição em duas ou mais associações. Ela especifica que objetos de uma classe podem participar de no máximo uma das associações em um dado momento. Uma associação exclusiva é representada por uma linha tracejada entre as associações que são parte da associação exclusiva, com a especificação "{ou}" sobre a linha tracejada. No diagrama acima um contrato não pode se referir a uma pessoa e a uma empresa ao mesmo tempo, significando que o relacionamento é exclusivo a somente uma das duas classes. Associação Ordenada As associações entre objetos podem ter uma ordem implícita. O padrão para uma associação é desordenada (ou sem nenhuma ordem específica). Mas uma ordem pode ser especificada através da associação ordenada. Este tipo de associação pode ser muito útil em casos como este: janelas de um sistema têm que ser ordenadas na tela (uma está no topo, uma está no fundo e assim por diante). A associação ordenada pode ser escrita apenas colocando "{ordenada}" junto à linha de associação entre as duas classes. Associação de Classe Uma classe pode ser associada a uma outra associação. Este tipo de associação não é conectada a nenhuma das extremidades da associação já existente, mas na própria linha da associação. Esta associação serve para se adicionar informações extra a associação já existente. A associação da classe Fila com a associação das classes Cliente e Processo pode ser estendida com operações de adicionar processos na fila, para ler e remover da fila e de ler o seu tamanho. Se operações ou atributos são adicionados a associação, ela deve ser mostrada como uma classe. 15 Associação Ternária Mais de duas classes podem ser associadas entre si, a associação ternária associa três classes. Ela é mostrada como um grade losango (diamante) e ainda suporta uma associação de classe ligada a ela, traçaria-se, então, uma linha tracejada a partir do losango para a classe onde seria feita a associação ternária. No exemplo acima a associação ternária especifica que um cliente poderá possuir 1 ou mais contratos e cada contrato será composto de 1 ou várias regras contratuais. Agregação A agregação é um caso particular da associação. A agregação indica que uma das classes do relacionamento é uma parte, ou está contida em outra classe. As palavras chaves usadas para identificar uma agregação são: "consiste em", "contém", "é parte de". Existem tipos especiais de agregação que são as agregações compartilhadas e as compostas. • Agregação Compartilhada: É dita compartilhada quando uma das classes é uma parte, ou está contida na outra, mas esta parte pode fazer estar contida na outra várias vezes em um mesmo momento. No exemplo acima uma pessoa pode ser membro de um time ou vários times e em determinado momento. • Agregação de Composição: É uma agregação onde uma classe que está contida na outra "vive" e constitui a outra. Se o objeto da classe que contém for destruído, as classes da agregação de composição serão destruídas juntamente já que as mesmas fazem parte da outra. 16 8.6.2. Generalizações A generalização é um relacionamento entre um elemento geral e um outro mais específico. O elemento mais específico possui todas as características do elemento geral e contém ainda mais particularidades. Um objeto mais específico pode ser usado como uma instância do elemento mais geral. A generalização, também chamada de herança, permite a criação de elementos especializados em outros. Existem alguns tipos de generalizações que variam em sua utilização a partir da situação. São elas: generalização normal e restrita. As generalizações restritas se dividem em generalização de sobreposição, disjuntiva, completa e incompleta. Generalização Normal Na generalização normal a classe mais específica, chamada de subclasse, herda tudo da classe mais geral, chamada de superclasse. Os atributos, operações e todas as associações são herdadas. Uma classe pode ser tanto uma subclasse quanto uma superclasse, se ela estiver numa hierarquia de classes que é um gráfico onde as classes estão ligadas através de generalizações. A generalização 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 generalização. Generalização Restrita Uma restrição aplicada a uma generalização especifica informações mais precisas sobre como a generalização deve ser usada e estendida no futuro. As restrições a seguir definem as generalizações restritas com mais de uma subclasse: • Generalizações de Sobreposição e Disjuntiva: Generalização de sobreposição significa que quando subclasses herdam de uma superclasse por sobreposição, novas subclasses destas podem herdar de mais de uma subclasse. A generalização disjuntiva é exatamente o contrário da sobreposição e a generalização é utilizada como padrão. 17 Todos os sistemas possuem uma estrutura estática e um comportamento dinâmico. A UML suporta modelos estáticos (estrutura estática), dinâmicos (comportamento dinâmico) e funcional. A Modelagem estática é suportada pelo diagrama de classes e de objetos, que consiste nas classes e seus relacionamentos. Os relacionamentos podem ser de associações, herança (generalização), dependência ou refinamentos. Os modelamentos dinâmicos são suportados pelos diagramas de estado, sequência, colaboração e atividade. E o modelamento funcional é suportado pelos diagramas de componente e execução. Abordaremos agora cada um destes tipos de diagrama: 9.1. Diagrama Use-Case A modelagem de um diagrama use-case é uma técnica usada para descrever e definir os requisitos funcionais de um sistema. Eles são escritos em termos de atores externos, use- cases e o sistema modelado. Os atores representam o papel de uma entidade externa ao sistema como um usuário, um hardware, ou outro sistema que interage com o sistema modelado. Os atores iniciam a comunicação com o sistema através dos use-cases, onde o use- case representa uma sequência de ações executadas pelo sistema e recebe do ator que lhe utiliza dados tangíveis de um tipo ou formato já conhecido, e o valor de resposta da execução de um use-case (conteúdo) também já é de um tipo conhecido, tudo isso é definido juntamente com o use-case através de texto de documentação. Atores e use-cases são classes. Um ator é conectado a um ou mais use-cases através de associações, e tanto atores quanto use-cases podem possuir relacionamentos de generalização que definem um comportamento comum de herança em superclasses especializadas em subclasses. O uso de use-cases em colaborações é muito importante, onde estas são a descrição de um contexto mostrando classes/objetos, seus relacionamentos e sua interação exemplificando como as classes/objetos interagem para executar uma atividade específica no sistema. Uma colaboração é descrita por diagramas de atividades e um diagrama de colaboração. Quando um use-case é implementado, a responsabilidade de cada passo da execução deve ser associada às classes que participam da colaboração, tipicamente especificando as operações necessárias dentro destas classes juntamente com a definição de como elas irão interagir. Um cenário é uma instância de um use-case, ou de uma colaboração, mostrando o caminho específico de cada ação. Por isso, o cenário é um importante exemplo de um use- case ou de uma colaboração. Quando visto a nível de um use-case, apenas a interação entre o ator externo e o use-case é vista, mas já observando a nível de uma colaboração, toda as interações e passos da execução que implementam o sistema serão descritos e especificados. 20 O diagrama de use-cases acima demonstra as funções de um ator externo de um sistema de controle bancário de um banco fictício que foi modelado no estudo de caso no final deste trabalho. O diagrama especifica que funções o administrador do banco poderá desempenhar. Pode-se perceber que não existe nenhuma preocupação com a implementação de cada uma destas funções, já que este diagrama apenas se resume a determinar que funções deverão ser suportadas pelo sistema modelado. 9.2 Diagrama de Classes O diagrama de classes demonstra a estrutura estática das classes de um sistema onde estas representam as "coisas" que são gerenciadas pela aplicação modelada. Classes podem se relacionar com outras através de diversas maneiras: associação (conectadas entre si), dependência (uma classe depende ou usa outra classe), especialização (uma classe é uma especialização de outra classe), ou em pacotes (classes agrupadas por características similares). Todos estes relacionamentos são mostrados no diagrama de classes juntamente com as suas estruturas internas, que são os atributos e operações. O diagrama de classes é considerado estático já que a estrutura descrita é sempre válida em qualquer ponto do ciclo de vida do sistema. Um sistema normalmente possui alguns diagramas de classes, já que não são todas as classes que estão inseridas em um único diagrama e uma certa classes pode participar de vários diagramas de classes. 21 Uma classe num diagrama pode ser diretamente implementada utilizando-se uma linguagem de programação orientada a objetos que tenha suporte direto para construção de classes. Para criar um diagrama de classes, as classes têm que estar identificadas, descritas e relacionadas entre si. 9.3. Diagrama de Objetos O diagrama de objetos é uma variação do diagrama de classes e utiliza quase a mesma notação. A diferença é que o diagrama de objetos mostra os objetos que foram instanciados das classes. O diagrama de objetos é como se fosse o perfil do sistema em um certo momento de sua execução. A mesma notação do diagrama de classes é utilizada com 2 exceções: os objetos são escritos com seus nomes sublinhados e todas as instâncias num relacionamento são mostradas. Os diagramas de objetos não são tão importantes como os diagramas de classes, mas eles são muito úteis para exemplificar diagramas complexos de classes ajudando muito em sua compreensão. Diagramas de objetos também são usados como parte dos diagramas de colaboração, onde a colaboração dinâmica entre os objetos do sistema são mostrados. 9.4. Diagrama de Estado O diagrama de estado é tipicamente um complemento para a descrição das classes. Este diagrama mostra todos os estados possíveis que objetos de uma certa classe podem se encontrar e mostra também quais são os eventos do sistemas que provocam tais mudanças. Os diagramas de estado não são escritos para todas as classes de um sistema, mas apenas 22 9.7. Diagrama de Atividade Diagramas de atividade capturam ações e seus resultados. Eles focam o trabalho executado na implementação de uma operação (método), e suas atividades numa instância de um objeto. O diagrama de atividade é uma variação do diagrama de estado e possui um propósito um pouco diferente do diagrama de estado, que é o de capturar ações (trabalho e atividades que serão executados) e seus resultados em termos das mudanças de estados dos objetos. Os estados no diagrama de atividade mudam para um próximo estágio quando uma ação é executada (sem ser necessário especificar nenhum evento como no diagrama de estado). Outra diferença entre o diagrama de atividade e o de estado é que podem ser colocadas como "swimlanes". Uma swimlane agrupa atividades, com respeito a quem é responsável e onde estas atividades residem na organização, e é representada por retângulos que englobam todos os objetos que estão ligados a ela (swimlane). Um diagrama de atividade é uma maneira alternativa de se mostrar interações, com a possibilidade de expressar como as ações são executadas, o que elas fazem (mudanças dos estados dos objetos), quando elas são executadas (sequência das ações), e onde elas acontecem (swimlanes). Um diagrama de atividade pode ser usado com diferentes propósitos inclusive: • Para capturar os trabalhos que serão executados quando uma operação é disparada (ações). Este é o uso mais comum para o diagrama de atividade. • Para capturar o trabalho interno em um objeto. • Para mostrar como um grupo de ações relacionadas podem ser executadas, e como elas vão afetar os objetos em torno delas. • Para mostrar como uma instância pode ser executada em termos de ações e objetos. • Para mostrar como um negócio funciona em termos de trabalhadores (atores), fluxos de trabalho, organização, e objetos (fatores físicos e intelectuais usados no negócio). O diagrama de atividade mostra o fluxo sequencial das atividades, é normalmente utilizado para demonstrar as atividades executadas por uma operação específica do sistema. Consistem em estados de ação, que contém a especificação de uma atividade a ser desempenhada por uma operação do sistema. Decisões e condições, como execução paralela, também podem ser mostrados na diagrama de atividade. O diagrama também pode conter especificações de mensagens enviadas e recebidas como partes de ações executadas. 25 9.8. Diagrama de Componente O diagrama de componente e o de execução são diagramas que mostram o sistema por um lado funcional, expondo as relações entre seus componentes e a organização de seus módulos durante sua execução. O diagrama de componente descreve os componentes de software e suas dependências entre si, representando a estrutura do código gerado. Os componentes são a implementação na arquitetura física dos conceitos e da funcionalidade definidos na arquitetura lógica (classes, objetos e seus relacionamentos). Eles são tipicamente os arquivos implementados no ambiente de desenvolvimento. Um componente é mostrado em UML como um retângulo com uma elipse e dois retângulos menores do seu lado esquerdo. O nome do componente é escrito abaixo ou dentro de seu símbolo. Componentes são tipos, mas apenas componentes executáveis podem ter instâncias. Um diagrama de componente mostra apenas componentes como tipos. Para mostrar instâncias de componentes, deve ser usado um diagrama de execução, onde as instâncias executáveis são alocadas em nodes. A dependência entre componentes pode ser mostrada como uma linha tracejada com uma seta, simbolizando que um componente precisa do outro para possuir uma definição completa. Com o diagrama de componentes é facilmente visível detectar que arquivos .dll são necessários para executar a aplicação. 26 Componentes podem definir interfaces que são visíveis para outros componentes. As interfaces podem ser tanto definidas ao nível de codificação (como em Java) quanto em interfaces binárias usadas em run-time (como em OLE). Uma interface é mostrada como uma linha partindo do componente e com um círculo na outra extremidade. O nome é colocado junto do círculo no final da linha. Dependências entre componentes podem então apontar para a interface do componente que está sendo usada. 9.9. Diagrama de Execução O diagrama de execução mostra a arquitetura física do hardware e do software no sistema. Pode mostrar os atuais computadores e periféricos, juntamente com as conexões que eles estabelecem entre si e pode mostrar também os tipos de conexões entre esses computadores e periféricos. Especifica-se também os componentes executáveis e objetos que são alocados para mostrar quais unidades de software são executados e em que destes computadores são executados. O diagrama de execução demonstra a arquitetura run-time de processadores, componentes físicos (devices), e de software que rodam no ambiente onde o sistema desenvolvido será utilizado. É a última descrição física da topologia do sistema, descrevendo a estrutura de hardware e software que executam em cada unidade. O diagrama de execução é composto por componentes, que possuem a mesma simbologia dos componentes do diagrama de componentes, nodes, que significam objetos físicos que fazem parte do sistema, podendo ser uma máquina cliente numa LAN, uma máquina servidora, uma impressora, um roteador, etc., e conexões entre estes nodes e componentes que juntos compõem toda a arquitetura física do sistema. 27 12.1. Análise de Requisitos De acordo com nossa proposta o sistema implementará funções básicas que serão desempenhadas pela Administração do banco e pelos seus clientes. As principais funções do sistema são: • Cadastrar novo cliente • Excluir ou editar cliente • Cadastrar dependente • Excluir ou editar dependente • Abrir conta corrente • Fechar conta corrente • Abrir poupança • Fechar poupança • Movimentar conta corrente • Aplicar em pré-fixados • Consultar histórico de conta corrente ou poupança • Cadastrar Agência • Excluir ou Editar Agência Tendo em mãos esta relação de atividades, já podemos modelar o diagrama de use-case do sistema. 30 12.2. Análise Na fase de análise, tendo em mãos o diagrama de use-case, podemos definir o diagrama de classes do sistema. Este primeiro diagrama da fase de análise deverá ser totalmente despreocupado de qualquer tipo de técnica relacionada a implementação do sistema, ou seja, métodos e atributos de acesso a banco de dados, estrutura de mensagens entre objetos, etc. não deverão aparecer nesse primeiro diagrama, apenas os tipos de objetos básicos do sistema. Analisamos e percebemos que existirão 8 classes no sistema e que se relacionarão segundo o diagrama de classes a seguir. 31 Já temos em mãos as funções primordiais do sistema (diagrama de use-cases) e o diagrama de classes da análise do domínio do problema, partiremos agora para traçar como estas classes irão interagir para realizar as funções do sistema. Lembramos que ainda nesta fase nenhum tipo de técnica de implementação deve ser considerada. Para modelarmos como os objetos do sistema irão interagir entre si, utilizamos o diagrama de sequência ou o de colaboração. E modelaremos um diagrama para cada função (use-case) 32 Chegamos a um diagrama de classes mais evoluído com a inclusão de persistência. Criamos os diagramas de sequência para funções do sistema, descritas no diagrama de use- cases, já possuindo os parâmetros para cada mensagem entre os objetos. 35 O layout das janelas deve ser criado com alguma ferramenta visual de acordo com a preferência do desenvolvedor. Ferramentas visuais já geram o código necessário para a criação de janelas. Algumas ferramentas já suportam a adição de controladores de eventos para eventos disparados por usuários como cliques em botões. O ambiente gera um método ‘okbutton_Clicked’ que será chamado quando o botão "OK" for pressionado. A aplicação resultante da interface de usuário é uma janela principal com um menu de opções. Cada opção escolhida do menu mostrará uma janela nova que juntas serão responsáveis por receber as informações do usuário e executar a função a qual se propõem a fazer. 12.4. Implementação A fase de construção ou implementação é quando as classes são codificadas. Os requisitos especificam que o sistema deve ser capaz de rodar em diversos tipo de processadores e sistemas operacionais, então 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 visão lógica. Agora codificamos cada classe do pacote de objetos do sistema, a interface, o banco de dados e o pacote de utilidades. A codificação deve ser baseada nos modelos desenvolvidos nas fases de análise de requisitos, análise e design, mais precisamente nas especificações de classes, diagramas de classes, de estado, dinâmicos, de use-cases e especificação. Existirão algumas deficiências durante a fase de codificação. A necessidade da criação de novas operações e modificações em operações já existentes serão 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 codificação, desta forma os modelos poderão ser usados como documentação final do sistema. 12.5. Testes A aplicação deverá ser testada. Deve-se verificar se o programa suporta toda a funcionalidade que lhe foi especificada na fase de análise de requisitos com o diagrama de use-cases. A aplicação deve ser também testada da forma mais informal colocando-se o sistema nas mãos dos usuários. 13. Conclusão O criação de uma linguagem para a comunidade de desenvolvedores em orientação a objetos era uma necessidade antiga. A UML realmente incorporou muitos recursos com dão a linguagem uma extensibilidade muito grande. Os organização da modelagem em visões e a divisão dos diagramas especificando características estáticas e dinâmicas do sistema tornou a UML fácil 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 padrão, e esse padrão é extremamente simples de ser escrito a mão, sendo robusto para especificar e descrever a grande maioria das funções, relacionamentos e técnicas de desenvolvimento orientado a objetos que hoje são utilizados. Novas técnicas irão surgir e a UML também estará preparada já que tudo estará baseado nas idéias elementares da orientação a objetos. Sem dúvida alguma a UML facilitará às grandes empresas de desenvolvimento de software uma maior comunicação e aproveitamento dos modelos desenvolvidos pelos seus vários analistas envolvidos no processo de produção de software já que a linguagem que será 36 utilizada por todos será a mesma, acabando assim com qualquer problema de interpretação e mal-entendimento de modelos criados por outros desenvolvedores. Os modelos criados hoje poderão ser facilmente analisados por futuras gerações 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 suportarão a UML em seus softwares e a fase de codificação será cada vez mais substituída pela geração de código automático desempenhada pelas ferramentas CASE. 37
Docsity logo



Copyright © 2024 Ladybird Srl - Via Leonardo da Vinci 16, 10126, Torino, Italy - VAT 10816460017 - All rights reserved