Baixe Apostila de UML e outras Notas de estudo em PDF para Engenharia de Produção, somente na Docsity! nl Linguagem de Modelagem Unificada LANGUAGE 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 2 Os conceitos que Coad, Yourdon, Pressman e tantos outros abordaram, discutiram e definiram em suas publicações foram que: • A orientação a objetos é uma tecnologia para a produção de modelos que especifiquem o domínio do problema de um sistema. • Quando construídos corretamente, sistemas orientados a objetos são flexíveis a mudanças, possuem estruturas bem conhecidas e provêm a oportunidade de criar e implementar componentes totalmente reutilizáveis. • Modelos orientado a objetos são implementados convenientemente utilizando uma linguagem de programação orientada a objetos. A engenharia de software orientada a objetos é muito mais que utilizar mecanismos de sua linguagem de programação, é saber utilizar da melhor forma possível todas as técnicas da modelagem orientada a objetos.. • A orientação a objetos não é só teoria, mas uma tecnologia de eficiência e qualidade comprovadas usada em inúmeros projetos e para construção de diferentes tipo de sistemas. A orientação a objetos requer um método que integre o processo de desenvolvimento e a linguagem de modelagem com a construção de técnicas e ferramentas adequadas 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 5 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. 6 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. 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 que disponibilizam interfaces genéricas de uso de outros softwares. 7 5.5. Testes Um sistema normalmente é rodado em testes de unidade, integração, e aceitação. Os testes de unidade são para classes individuais ou grupos de classes e são geralmente testados pelo programador. Os testes de integração são aplicados já usando as classes e componentes integrados para se confirmar se as classes estão cooperando uma com as outras como especificado nos modelos. Os testes de aceitação 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 usuário final e verificará se os resultados mostrados estão realmente de acordo com as intenções do usuário final. 6. A Notação da Linguagem de Modelagem Unificada – UML Tendo em mente as cinco fases do desenvolvimento de softwares, as fases de análise de requisitos, análise e design utilizam-se em seu desenvolvimento cinco tipos de visões, nove tipos de diagramas e vários modelos de elementos que serão utilizados na criação dos diagramas e mecanismos gerais que todos em conjunto especificam e exemplificam a definição do sistema, tanto a definição no que diz respeito à funcionalidade estática e dinâmica do desenvolvimento de um sistema. Antes de abordarmos cada um destes componentes separadamente, definiremos as partes que compõem a UML: • Visões: As Visões mostram diferentes aspectos do sistema que está sendo modelado. A visão não é um gráfico, mas uma abstração consistindo em uma série de diagramas. Definindo um número de visões, cada uma mostrará aspectos particulares do sistema, dando enfoque a ângulos e níveis de abstrações diferentes e uma figura completa do sistema poderá ser construída. As visões também podem servir de ligação entre a linguagem de modelagem e o método/processo de desenvolvimento escolhido. • Modelos de Elementos: Os conceitos usados nos diagramas são modelos de elementos que representam definições comuns da orientação a objetos como as classes, objetos, mensagem, relacionamentos entre classes incluindo associações, dependências e heranças. • Mecanismos Gerais: Os mecanismos gerais provém comentários suplementares, informações, ou semântica sobre os elementos que compõem os modelos; eles provém também mecanismos de extensão para adaptar ou estender a UML para um método/processo, organização ou usuário específico. • Diagramas: Os diagramas são os gráficos que descrevem o conteúdo em uma visão. UML possui nove tipo de diagramas que são usados em combinação para prover todas as visões do sistema. 10 7. Visões O desenvolvimento de um sistema complexo não é uma tarefa fácil. O ideal seria que o sistema inteiro pudesse ser descrito em um único gráfico e que este representasse por completo as reais intenções do sistema sem ambiguidades, sendo facilmente interpretável. Infelizmente, isso é impossível. Um único gráfico é incapaz de capturar todas as informações necessárias para descrever um sistema. Um sistema é composto por diversos aspectos: funcional (que é sua estrutura estática e suas interações dinâmicas), não funcional (requisitos de tempo, confiabilidade, desenvolvimento, etc.) e aspectos organizacionais (organização do trabalho, mapeamento dos módulos de código, etc.). Então o sistema é descrito em um certo número de visões, cada uma representando uma projeção da descrição completa e mostrando aspectos particulares do sistema. Cada visão é descrita por um número de diagramas que contém informações que dão ênfase aos aspectos particulares do sistema. Existe em alguns casos uma certa sobreposição entre os diagramas o que significa que um deste pode fazer parte de mais de uma visão. Os diagramas que compõem as visões contém os modelos de elementos do sistema. As visões que compõem um sistema são: • Visão "use-case": Descreve a funcionalidade do sistema desempenhada pelos atores externos do sistema (usuários). A visão use-case é central, já que seu conteúdo é base do desenvolvimento das outras visões do sistema. Essa visão é montada sobre os diagramas de use-case e eventualmente diagramas de atividade. • Visão Lógica: Descreve como a funcionalidade do sistema será implementada. É feita principalmente pelos analistas e desenvolvedores. Em contraste com a visão use-case, a visão lógica observa e estuda o sistema internamente. Ela descreve e especifica a estrutura estática do sistema (classes, objetos, e relacionamentos) e as colaborações dinâmicas quando os objetos enviarem mensagens uns para os outros para realizarem as funções do sistema. Propriedades como persistência e concorrência são definidas nesta fase, bem como as interfaces e as estruturas de classes. A estrutura estática é descrita pelos diagramas de classes e objetos. O modelamento dinâmico é descrito pelos diagramas de estado, sequencia, colaboração e atividade. 11 • Visão de Componentes: É uma descrição da implementação dos módulos e suas dependências. É principalmente executado por desenvolvedores, e consiste nos componentes dos diagramas. • 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, sequencia, 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: 12 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). O pacote tem uma grande similaridade com a agregação (relacionamento que será tratado em seguida). O fato de um pacote ser composto de modelos de elementos cria uma agregação de composição. Se este for destruído, todo o seu conteúdo também será. 8.5. Componentes Um componente pode ser tanto um código em linguagem de programação como um código executável 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. 15 8.6. Relacionamentos Os relacionamentos ligam as classes/objetos entre si criando relações lógicas entre estas entidades. Os relacionamentos podem ser dos seguintes tipos: • Associação: É uma conexão entre classes, e também significa que é uma conexão entre objetos daquelas classes. Em UML, uma associação é definida com um relacionamento que descreve uma série de ligações, onde a ligação é definida como a semântica entre as duplas de objetos ligados. • Generalização: É um relacionamento de um elemento mais geral e outro mais específico. O elemento mais específico pode conter apenas informações adicionais. Uma instância (um objeto é uma instância de uma classe) do elemento mais específico pode ser usada onde o elemento mais geral seja permitido. • Dependência e Refinamentos: Dependência é um relacionamento entre elementos, um independente e outro dependente. Uma modificação é um elemento independente afetará diretamente elementos dependentes do anterior. Refinamento é um relacionamento entre duas descrições de uma mesma entidade, mas em níveis diferentes de abstração. Abordaremos agora cada tipo de relacionamento e suas respectivas sub-divisões: 8.6.1 Associações Uma associação representa que duas classes possuem uma ligação (link) entre elas, significando por exemplo que elas "conhecem uma a outra", "estão conectadas com", "para cada X existe um Y" e assim por diante. Classes e associações são muito poderosas quando modeladas em sistemas complexos. Associações Normais O tipo mais comum de associação é apenas uma conexão entre classes. É representada por uma linha sólida entre duas classes. A associação possui um nome (junto à linha que representa a associação), normalmente um verbo, mas substantivos também são permitidos. Pode-se também colocar uma seta no final da associação indicando que esta só pode ser usada para o lado onde a seta aponta. Mas associações também podem possuir dois nomes, significando um nome para cada sentido da associação. Para expressar a multiplicidade entre os relacionamentos, um intervalo indica quantos objetos estão relacionados no link. O intervalo pode ser de zero para um (0..1), zero para vários (0..* ou apenas *), um para vários (1..*), dois (2), cinco para 11 (5..11) e assim por diante. É também possível expressar uma série de números como (1, 4, 6..12). Se não for descrito nenhuma multiplicidade, então é considerado o padrão de um para um (1..1 ou apenas 1). 16 No exemplo acima vemos um relacionamento entre as classes Cliente e Conta Corrente se relacionam por associação. Associação Recursiva É possível conectar uma classe a ela mesma através de uma associação e que ainda representa semanticamente a conexão entre dois objetos, mas os objetos conectados são da mesma classe. Uma associação deste tipo é chamada de associação recursiva. Associação Qualificada Associações qualificadas são usadas com associações de um para vários (1..*) ou vários para vários (*). O "qualificador" (identificador da associação qualificada) especifica como um determinado objeto no final da associação "n" é identificado, e pode ser visto como um tipo de chave para separar todos os objetos na associação. O identificador é desenhado como uma pequena caixa no final da associação junto à classe de onde a navegação deve ser feita. 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. 17 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: 20 • 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. • Generalizações Completa e Incompleta: Uma restrição simbolizando que uma generalização é completa significa que todas as subclasses já foram especificadas, e não existe mais possibilidade de outra generalização a partir daquele ponto. A generalização incompleta é exatamente o contrário da completa e é assumida como padrão da linguagem. 8.6.3. Dependência e Refinamentos Além das associações e generalizações, existem ainda dois tipos de relacionamentos em UML. O relacionamento de dependência é uma conexão semântica entre dois modelos de elementos, um independente e outro dependente. Uma mudança no elemento independente irá afetar o modelo dependente. Como no caso anterior com generalizações, os modelos de elementos podem ser uma classe, um pacote, um use-case e assim por diante. Quando uma classe recebe um objeto de outra classe como parâmetro, uma classe acessa o objeto global da outra. Nesse caso existe uma dependência entre estas duas classes, apesar de não ser explícita. 21 Uma relação de dependência é simbolizada por uma linha tracejada com uma seta no final de um dos lados do relacionamento. E sobre essa linha o tipo de dependência que existe entre as duas classes. As classes "Amigas" provenientes do C++ são um exemplo de um relacionamento de dependência. Os refinamentos são um tipo de relacionamento entre duas descrições de uma mesma coisa, mas em níveis de abstração diferentes e podem ser usados para modelar diferentes implementações de uma mesma coisa (uma implementação simples e outra mais complexa, mas também mais eficiente). Os refinamentos são simbolizados por uma linha tracejada com um triângulo no final de um dos lados do relacionamento e são usados em modelos de coordenação. Em grandes projetos, todos os modelos que são feitos devem ser coordenados. Coordenação de modelos pode ser usada para mostrar modelos em diferentes níveis de abstração que se relacionam e mostram também como modelos em diferentes fases de desenvolvimento se relacionam. 8.7. Mecanismos Gerais A UML utiliza alguns mecanismos em seus diagramas para tratar informações adicionais. • Ornamentos: Ornamentos gráficos são anexados aos modelos de elementos em diagramas e adicionam semânticas ao elemento. Um exemplo de um ornamento é o da técnica de separar um tipo de uma instância. Quando um elemento representa um tipo, seu nome é mostrado em negrito. Quando o mesmo elemento representa a instância de um tipo, seu nome é escrito sublinhado e pode significar tanto o nome da instância quanto o nome do tipo. Outros ornamentos são os de especificação de multiplicidade de relacionamentos, onde a multiplicidade é um número ou um intervalo que indica quantas instâncias de um tipo conectado pode estar envolvido na relação. • Notas: Nem tudo pode ser definido em uma linguagem de modelagem, sem importar o quanto extensa ela seja. Para permitir adicionar informações a um modelo não poderia ser representado de outra forma, UML provê a capacidade de adicionar Notas. Uma Nota pode ser colocada em qualquer lugar em um diagrama, e pode conter qualquer tipo de informação. 22 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 25 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 para aquelas que possuem um número 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 condições sendo satisfeitas) afetam estes estados ao passar do tempo. Diagramas de estado possuem um ponto de início e vários pontos de finalização. Um ponto de início (estado inicial) é mostrado como um círculo todo preenchido, e um ponto de finalização (estado final) é mostrado como um círculo em volta de um outro círculo menor preenchido. Um estado é mostrado como um retângulo com cantos arredondados. Entre os estados estão as transições, mostrados como uma linha com uma seta no final de um dos estados. A transição pode ser nomeada com o seu evento causador. Quando o evento acontece, a transição de um estado para outro é executada ou disparada. Uma transição de estado normalmente possui um evento ligado a ela. Se um evento é anexado a uma transição, esta será executada quando o evento ocorrer. Se uma transição não possuir um evento ligado a ela, a mesma ocorrerá quando a ação interna do código do estado for executada (se existir ações internas como entrar, sair, fazer ou outras ações definidas pelo desenvolvedor). Então quando todas as ações forem executadas pelo estado, a transição será disparada e serão iniciadas as atividades do próximo estado no diagrama de estados. 9.5. Diagrama de Sequência Um diagrama de sequência mostra a colaboração dinâmica entre os vários objetos de um sistema. O mais importante aspecto deste diagrama é que a partir dele percebe-se a sequência de mensagens enviadas entre os objetos. Ele mostra a interação entre os objetos, alguma coisa que acontecerá em um ponto específico da execução do sistema. O diagrama de sequência consiste em um número de objetos mostrado em linhas verticais. O decorrer do tempo é visualizado observando-se o diagrama no sentido vertical de cima para baixo. As mensagens enviadas por cada objeto são simbolizadas por setas entre os objetos que se relacionam. 26 Diagramas de sequência possuem dois eixos: o eixo vertical, que mostra o tempo e o eixo horizontal, que mostra os objetos envolvidos na sequência de uma certa atividade. Eles também mostram as interações para um cenário específico de uma certa atividade do sistema. No eixo horizontal estão os objetos envolvidos na sequência. Cada um é representado por um retângulo de objeto (similar ao diagrama de objetos) e uma linha vertical pontilhada chamada de linha de vida do objeto, indicando a execução do objeto durante a sequência, como exemplo citamos: mensagens recebidas ou enviadas e ativação de objetos. A comunicação 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 é síncrona, assíncrona ou simples. As mensagens podem possuir também números sequenciais, eles são utilizados para tornar mais explícito as sequência no diagrama. Em alguns sistemas, objetos rodam concorrentemente, cada um com sua linha de execução (thread). Se o sistema usa linhas concorrentes de controle, isto é mostrado como ativação, mensagens assíncronas, ou objetos assíncronos. Os diagramas de sequência podem mostrar objetos que são criados ou destruídos como parte do cenário documentado pelo diagrama. Um objeto pode criar outros objetos através de mensagens. A mensagem que cria ou destroi um objeto é geralmente síncrona, representada por uma seta sólida. 9.6. Diagrama de Colaboração Um diagrama de colaboração mostra de maneira semelhante ao diagrama de sequencia, a colaboração dinâmica entre os objetos. Normalmente pode-se escolher entre utilizar o diagrama de colaboração ou o diagrama de sequência. No diagrama de colaboração, além de mostrar a troca de mensagens entre os objetos, percebe-se também os objetos com os seus relacionamentos. A interação de mensagens é mostrada em ambos os diagramas. Se a ênfase do diagrama for o decorrer do tempo, é melhor escolher o diagrama de sequência, mas se a ênfase for o contexto do sistema, é melhor dar prioridade ao diagrama de colaboração. 27 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. 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. 30 10. Um processo para utilizar a UML A UML contém notações e regras que tornam possível expressar modelos orientados a objetos. Mas ela não prescreve como o trabalho tem que ser feito, ou seja, não possui um processo de como o trabalho tem que ser desenvolvido. Já que a UML foi desenvolvida para ser usada em diversos métodos de desenvolvimento. Para usar a UML com sucesso é necessário adotar algum tipo de método de desenvolvimento, especialmente em sistema de grande porte onde a organização de tarefas é essencial. A utilização de um processo de desenvolvimento torna mais eficiente calcular o progresso do projeto, controlar e melhorar o trabalho. Um processo de desenvolvimento descreve "o que fazer", "como fazer", "quando fazer", e "porque deve ser feito". Este também descreve um número de atividades que devem ser executadas em uma certa ordem. Quando são definidas e relacionadas as atividades de um processo, um objetivo específico é alcançado. Em seu uso normal, a palavra "processo" significa uma relação de atividades que devem ser executadas em uma certa ordem sem importar o objetivo, regras ou material a ser usado. No processo de desenvolvimento da engenharia de software, é necessário saber o objetivo final do processo, definir regras a serem seguidas e adotar um método fixo de desenvolvimento. Um método (processo) tradicional de desenvolvimento orientado a objetos é dividido em análise de requisitos, análise, design (projeto), implementação, e testes. A análise de requisitos captura as necessidades básicas funcionais e não-funcionais do sistema que deve ser desenvolvido. A análise modela o problema principal (classes, objetos) e cria um modelo ideal do sistema sem levar em conta requisitos técnicos do sistema. O design expande e adapta os modelos da análise para um ambiente técnico, onde as soluções técnicas são trabalhadas em detalhes. A implementação consiste em codificar em linguagem de programação e banco de dados os modelos criados. E as atividades de testes devem testar o sistema em diferentes níveis, verificando se o mesmo corresponde as expectativas do usuário. Existe um processo desenvolvido pela Rational Inc., mesma empresa que desenvolveu a UML, que monta duas visões do desenvolvimento de um sistema: visão gerencial e técnica. A visão técnica utiliza as tradicionais atividades de análise, design e implementação, enquanto a visão gerencial utiliza as seguintes fases no desenvolvimento de cada geração do sistema. 31 • Início: Define o escopo e objetivo do projeto; • Elaboração: Desenvolve o produto em detalhes através de uma série de interações. Isto envolve mais análise, design e programação; • Transição: Gera o sistema para o usuário final, incluindo as atividades de marketing, suporte, documentação e treinamento. Cada fase no ciclo é executada em séries de interações que podem sobrepor outras fases. Cada interação consiste tipicamente em atividades tradicionais como análise e design, mas em diferentes proporções dependendo da fase em que esteja a geração do sistema em desenvolvimento. Ferramentas modernas devem dar suporte não apenas para linguagens de modelagem e programação, mas devem suportar um método de desenvolvimento de sistemas também. 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 fácil integração com outras ferramentas. 11. O Futuro da UML Embora a UML defina uma linguagem precisa, ela não é uma barreira para futuros aperfeiçoamentos nos conceitos de modelagem. O desenvolvimento da UML foi baseado em técnicas antigas e marcantes da orientação a objetos, mas muitas outras influenciarão a linguagem em suas próximas versões. Muitas técnicas avançadas de modelagem podem ser definidas usando UML como base, podendo ser estendida sem se fazer necessário redefinir a sua estrutura interna. A UML será a base para muitas ferramentas de desenvolvimento, incluindo modelagem visual, simulações e ambientes de desenvolvimento. Em breve ferramentas de integração e padrões de implementação baseados em UML estarão disponíveis para qualquer um. A UML integrou muitas idéias adversas, e esta integração vai acelerar o uso do desenvolvimento de softwares orientados a objetos. 12. Um estudo de caso em UML Diante do apresentado no decorrer do trabalho, aplicaremos aqui grande parte dos conceitos abordados diante de uma aplicação da UML num problema fictício que poderá ser de grande ajuda no melhor entendimento das potencialidades da linguagem de modelagem unificada. O estudo de caso dará mais ênfase na fases de análise de requisitos, análise e design, já que as principais abstrações dos modelos do sistema se encontram nestas fases do desenvolvimento. 32 Tendo em mãos esta relação de atividades, já podemos modelar o diagrama de use-case do sistema. 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. 35 Analisamos e percebemos que existirão 8 classes no sistema e que se relacionarão segundo o diagrama de classes a seguir. 36 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) definida no diagrama de use-cases. Escolhemos o diagrama de sequência para dar mais ênfase a ordem cronológica das interações entre os objetos. Já se faz necessário utilizar idéias básicas da modelagem da interface do sistema como as janelas. Mas esses objetos de interface serão totalmente detalhados na fase de design. Nesta fase modela-se também o diagrama de estado das classes. Mas este se enquadra em situações onde o comportamento dos objetos é importante para aplicação. Em casos de modelagens de sistemas para equipamentos mecânicos. 12.3. Design Nesta fase começaremos a implementar em nossos modelos os melhoramentos e técnicas de como realmente cada funcão do sistema será concebida. Serão modelos mais detalhados com ênfase nas soluções para armazenamento dos dados, funções primordiais do sistema e interface com o usuário. A fase de design pode ser dividida em outras duas fases: • Design da arquitetura: Este é o design de alto nível onde os pacotes (subsistemas) são definidos, incluindo as dependências e mecanismos de comunicação entre eles. Naturalmente, o objetivo é criar uma arquitetura simples e clara, onde as dependências sejam poucas e que possam ser bidirecionais sempre que possível. • Design detalhado: Esta parte detalha o conteúdo dos pacotes, então todas classes serão totalmente descritas para mostrar especificações claras para o programador que 37 Criamos os diagramas de sequencia para funções do sistema, descritas no diagrama de use- cases, já possuindo os parâmetros para cada mensagem entre os objetos. 40 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. 41 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á 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. 42