Parte i Cap. 1 – Enquadramento e

PARTE I CAP. 1 – ENQUADRAMENTO E CONCEITOS GERAIS 1.1. Introdução O objectivo deste livro é apresentar a linguagem de modelação UML e demonstrar a sua aplicação de forma a facilitar todo o desenvolvimento de software, quer seja directamente como técnica de modelação de software quer seja na sua utilização em metodologias de desenvolvimento ou em ferramentas de apoio. 1.2. O Impacto das Tecnologias de Informação Actualmente, as tecnologias de informação encontram-se na origem de mudanças significativas ao nível dos modelos de negócio das empresas, e constituem um elemento fundamental para a obtenção de vantagens estratégicas e competitivas. A implementação de sistemas de informação requer um investimento significativo (financeiro, tecnológico e de recursos humanos), pelo que estas intervenções deverão merecer apoio e comprometimento das administrações. Muito gestores não percebem por questões de formação e os técnicos de informática criaram imagem muito técnica. Isto contribui para a não consideração da informática como uma área estratégica dentro da empresa. A progressiva importância que os sistemas de informação têm nas organizações pode ser constatada através de diversas situações: - No passado era comum o responsável da informática depender hierarquicamente do director financeiro. Actualmente a área de informática está ao mesmo nível que os restantes departamentos. - A indústria de software é actualmente uma das mais importantes de todo o planeta - A crescente importância das empresas relacionadas com a Nova Economia levou ao Nasdaq - A importância destas empresas tem motivado a crescente preocupação dos governos em garantir o acesso livre ao mercado e a tentar evitar posições monopolistas. 1.3. Produto e Processo A importância das tecnologias de informação na nossa vida é sobretudo concretizada pelas funcionalidades que são implementadas ao nível do software, e que são disponibilizadas com o suporte de um conjunto de dispositivos diversos (hardware). O primeiro pode ser considerado o componente lógico dos sistemas de informação, o segundo o componente físico. Não existe uma definição rigorosa e inequívoca de software. para alguns é o resultado final de um processo, ao qual designam por “Engenharia de Software”. Se pensarmos que o desenvolvimento do software é um processo que deve ser baseado na aplicação de técnicas e práticas rigorosas, sistemáticas, eficientes e controláveis, é como nas outras engenharias. Pressupõe também a utilização de ferramentas de apoio a todo o processo. As características destas ferramentas podem ter um impacto apreciável no produto final. No entanto é de referir que a produção de software encerra em si mesma alguma subjectividade. Neste aspecto o processo mais de uma actividade artística. Podemos considerar pois que o ponto de equilíbrio correcto depende de cada caso, mas deve-se encontrar a meio caminho entre a aplicação de técnicas estruturadas (Engenharia) e introdução de factores de criatividade. São características fundamentais do software: - Flexibilidade: capacidade de evolução face aos requisitos de negócio - Fiabilidade - Implementação das necessidades das organizações - Nível de desempenho adequado - Facilidade de utilização 1.4. Sistemas de Informação A visão mais tradicional é que software é um conjunto de programas mais a respectiva documentação. O conceito mais abrangente de sistemas de informação é um conjunto integrado de recursos (humanos e tecnológicos) cujo objectivo é satisfazer adequadamente a totalidade das necessidades de informação de uma organização e os respectivos processos de negócio

(pretende representar uma sequência de actividades, que processam vários inputs e produzem vários outputs e que possuem objectivos – compras de matérias primas - ) É objectivo fundamental dos sistemas de informação garantir o alinhamento das tecnologias da informação com os objectivos estratégicos do negócio. Uma das mais antigas classificações dos SI é de Anthony – 1965, que os classifica em função do nível das actividades de gestão dentro da organização no qual o software tem impacto: - Operacional: operações do dia-a-dia e que implicam alterações na informação (facturação, controlo de encomendas, contabilidade geral, salários) - Táctico: análise da informação para suportar o processo de tomada de decisão e com impacto a curto prazo (análise de vendas, controle orçamental, contabilidade analítica, análise de qualidade) - Estratégico: questões de planeamento e com efeitos a médio e longo prazo (Previsão de vendas, Planeamento de recursos humanos, previsão de receitas e custos, modelação financeira). 1.5. Arquitectura de Sistemas de Informação Para facilitar a apresentação dos SI cada vez mais complexos. Em 1987 Zachman diz que arquitectura é o conjunto de representações descritivas (modelos) relevantes para a descrição de um objecto, de forma a que este possa ser construído de acordo com os requisitos (de qualidade) e mantido ao longo da sua vida útil. A framework de Zachman é uma estrutura lógica de classificação e apresentação dos modelos de uma organização relevantes para a respectiva gestão bem como para o desenvolvimento dos SI. Nesta perspectiva, modelar um sistema significa determinar e representar um conjunto de informação, sobre vários tópicos (colunas da matriz) relevante para vários intervenientes (linhas da matriz). São considerados 5 perfis: - Planner - Owner - Designer - Builder - Sub-contractor Os 2 primeiros são de cariz relacionado com as áreas de negócio e os outros de cariz informático. À medida que se desce aumenta o nível de detalhe. Cada perfil tem uma visão sobre os factores analisados: - Qual a constituição do sistema (What) – os dados? - Como é que o sistema funciona (How) – as funções? - Onde está localizado o sistema (Where) – as relações e as redes? - Quem são os interessados no sistema (Who) – as pessoas? - Quando ocorrem facto relevantes no sistema (When) – o tempo? - Porque é que o sistema funciona assim (Why) – as motivações? Uma outra abordagem alternativa baseia-se no framework de Index [Wurman97], e considera que a arquitectura de SI é um conjunto integrado e consistente de componentes, que são definidos de forma a garantir o respectivo alinhamento com os objectivos do negócio. Em blocos: - Arquitectura Aplicacional: sistema e aplicações - Arquitectura Tecnológica: infra-estrutura e máquinas - Arquitectura de Dados: conceitos e entidades - Arquitectura Organizacional: recursos humanos A definição destes componentes deve obedecer a uma sequência lógica. Como o componente que suporta os objectivos do negócio são as aplicações, estas devem ser escolhidas em primeiro lugar em paralelo com os dados. 1.6. Objectivos do Desenvolvimento de Sistemas de Informação Em 1983, Robert Block definiu um SI bem sucedido como aquele que é produzido dentro do prazo e nos custos estimados; é fiável e pode ser mantido facilmentea baixo custo; responde adequadamente aos requisitos definidos e satisfaz os utilizadores. Ao longo do tempo: 1970 – Automatização – computação mainframe; processamento Batch 1980 – Redução de custos – sistemas departamentais; procesaamento online; bases de dados relacionais 1985 – Autonomização do utilizador – computador pessoal; ferramentas de produtividade pessoal

1995 – Vantagem competitiva – Tecnologias OO; suporte À decisão; gestão do conhecimento 2000 – Driver do negócio – Internet; computação ubíqua Existe um conjunto de razões que levam as organizações a investir em SI: - Reduzir custos operacionais - Satisfazer requisitos de informação dos utilizadores - Contribuir para a criação de novos produtos e serviços - Melhorar o nível de serviço prestado - Melhorar e automatizar a relação com os parceiros de negócio - melhorar o desempenho de pessoas e máquinas 1.7. Problemas no Desenvolvimento de Sistemas de Informação Historicamente, o software tem apresentado de forma sistemática e contínua os mesmos problemas. Se pensarmos no impacto nas organizações temos 3 níveis: - Falta de qualidade: satisfação incompleta dos requisitos e problemas pós instalação - Desvios nos Prazos - Custos previamente definidos ultrapassados Daqui nasceu a famosa “crise no software” da década de 70 que foi reforçada por Fred Brooks no célebre artigo “No Silver Bullets”. Os problemas referidos são durante o processo de desenvolvimento, mas igualmente graves são os que acontecem após a instalação e entrada em produção. Podem ter impacto em 2 áreas críticas: questões financeiras e vidas humanas. Diversas causas estão na origem deste crónico falhanço: - Falta de empenhamento dos órgãos de topo - Falta de comprometimento e empenhamento dos utilizadores - Incompreensão do valor dos SI - Falta de entendimento e de sintonia entre informáticos e clientes utilizadores no âmbito dos requisitos do mesmo - Deficiências várias no processo de desenvolvimento - Falhas na coordenação do projecto - falta de qualidade e inadequação dos recursos envolvidos - Mudanças frequentes dos requisitos do negócio - Dificuldades na integração de componentes - Qualidade e desempenho deficientes do software - Incapacidade de identificar e controlar os riscos do projecto 1.8. Planeamento Estratégico de Sistemas de Informação No passado os SI eram só para melhorar eficiência. Hoje concentram-se na obtenção de vantagens competitivas. Um dos objectivos dos SI é a satisfação adequada dos requisitos de negócio, garantindo assim o correcto alinhamento com a estratégia da organização. É esse o âmbito do Planeamento Estratégico de SI, que define componentes e funciona como guia. aqui devem ser identificadas e prioritizadas as acções a desencadear para atingir a situação futura proposta. Só depois se avança para a Engenharia de Software. Podemos definir o PESI como um processo cuja finalidade é garantir o alinhamento dos SI com os objectivos do negócio. Este processo tem fases: Levantamento dos Objectivos Estratégicos --> Análise detalhada do negócio --> Análise da situação actual dos SI --> Proposta de situação futura dos SI --> Planeamento da Implementação. 1.9. Engenharia De Software Uma das primeiras definições foi dada por Fritz Bauer nos finais da década de 60 como sendo “ a definição e utilização de princípios de engenharia sólidos, de modo a desenvolver software económico, fiável e que trabalha eficientemente em máquinas reais. Inclui pois um conjunto de métodos, de ferramentas e procedimentos”. Uma das mais usadas é a do IEEE: é a aplicação de um processo sistemático, disciplinado, e quantificado ao desenvolvimento, operação e manutenção de software. As actividades associadas à Engenharia do Software podem ser agrupadas em 3 grandes fases: - Concepção

- Implementação - Manutenção Conceitos a saber: sistemas de informação; arquitecturas; planeamento estratégico; engenharia do software.

CAP. 2 – O PROCESSO DE DESENVOLVIMENTO DE SOFTWARE 2.1. Introdução A produção de software é frequentemente uma actividade não estruturada, por vezes caótica, sem orientações de natureza estratégica e sem planos de gestão e controle (build and fix – programar e corrigir). Roger Pressman apelidou de 4 Ps associados ao desenvolvimento de software: - Pessoas motivadas e comprometidas - Processo com técnicas e regras bem definidas - Produto de qualidade respondendo às necessidades dos utilizadores. - Projecto credível e controlado Em 1996 Barry Boehm identificou 7 questões que qualquer projecto deve responder (W5H2): - Porque é que o sistema vai ser desenvolvido (Why)? - O que vai/deve ser feito (What)? - Quando é que vai se feito (When)? - Quem é o responsável (Who)? - Onde é que as responsabilidades estão localizadas (Where)? - Como é que vai ser feito (How)? - Quanto vai custar em termos de recursos (How much)? 2.2. Processos e Metodologias O processo de desenvolvimento de software é um conceito de âmbito muito vasto e pretende designar uma sequência de actividades, normalmente agrupadas em fases e tarefas, que são executadas de forma sistemática e uniformizada, por intervenientes com responsabilidades bem definidas e que a partir de um conjunto de inputs produzem um conjunto de outputs. Tem 4 objectivos fundamentais: - Providenciar orientação sobre a sequência de actividades - Especificar os modelos descritivos do sistema que devem ser desenvolvidos - Dirigir as tarefas dos participantes/equipa - Providenciar critérios para monitorização. O conceito de metodologia acrescenta a esta definição a utilização de um conjunto de ferramentas, técnicas e notações, para além de diversos princípios e regras mais práticas: - Regras de elaboração de estimativas (custos, prazos) - Técnicas para efectuar medições - Procedimentos a seguir de forma a garantir qualidade - Programas de formação - Modelos de documentação O conceito de ciclo de vida pode ser encarada como sinónimo de processo. No UML e outras processo é afinal metodologia. Em meados da década de 90 havia mais de 1000 metodologias. As metodologias actualmente existentes tiveram essencialmente 2 origens distintas: - Evoluíram de experiências práticas - Resultaram de esforços de investigação 2.3. Modelos e Modelação Um modelo consiste na interpretação de um dado domínio do problema segundo uma determinada estrutura de conceitos. Um esquema é a especificação de um modelo usando uma determinada linguagem. quando é gráfica chamamo-lhe diagrama. Um modelo é sempre uma interpretação simplificada da realidade. Um modelo apresenta apenas uma visão ou cenário de um fragmento do mundo real --> vários modelos para compreender o sistema correspondente. 2.3.1. Importância da Modelação A modelação (ou modelização) é a arte e ciência de criar modelos de uma determinada realidade; facilita e promove a comunicação entre todos. A informática como as outras engenharias precisa também de adoptar notações e linguagens para representar os seus modelos. Os benefícios da modelização são:

- Ajudam a visualizar o sistema - Permitem especificar a estrutura ou o comportamento - Permitem controlar e guiar o processo de construção - Documentam as decisões tomadas 2.3.2. Princípios da modelação P1 – A escolha dos modelos a criar tem uma profunda influência no modo como o problema é encarado e consequentemente como a solução é obtida P2 – cada modelo deve poder ser expresso em diferentes níveis de precisão/abstracção P3 – Os melhores modelos reflectem a realidade Este princípio é um dos “calcanhares de Aquiles” das técnicas de modelação pois muitas vezes existe uma manifesta separação entre os modelos usados para descrever “o que o sistema faz” e outros que detalham a forma “como o sistema faz”. P4 – Nenhum modelo é suficiente por si só. Qualquer sistema não trivial é representado de forma mais adequada através de pequeno número de modelos, razoavelmente independentes (mas mantendo nível de integração). O UML baseia-se significativamente neste princípio. 2.4. Boas Práticas no Desenvolvimento de Software A complexidade do software é uma propriedade essencial, intrínseca à própria natureza do software e tem origem em 4 factores: - A complexidade do domínio do problema - A dificuldade de gerir o processo de desenvolvimento - A flexibilidade que é possível (ou não) implementar através do software - Os problemas de caracterizar o comportamento de sistemas discretos Assim, normalmente, os projectos ultrapassam custos e prazos. Há vários atributos de um sistema complexo: - É composto por outros subsistemas relacionados, e assim sucessivamente (hierarquia de elementos) - A selecção dos componentes elementares é arbitrária e depende de quem a efectua - Com muitos elementos, as relações intracomponentes são mais fortes do que as intercomponentes - Cada subsistema é normalmente composto por poucos componentes diferentes - Um sistema complexo que funciona é invariavelmente uma evolução de um sistema simples que já funcionou. Existe uma limitação natural da capacidade humana em lidar com a complexidade. Por isso Dijkstra sugeriu a aplicação do famoso princípio da decomposição hierárquica (divide and conquer) Também a aplicação de um mecanismo de abstracção favorece a eliminação da complexidade: o ser humano opta por “esquecer” os detalhes menos importantes. Outros princípios para lidar com a complexidade e obter software de qualidade são: - Desenvolvimento de forma iterativa - Efectuar gestão integrada dos requisitos - Utilizar arquitecturas baseadas em componentes reutilizáveis - Modelar o sistema através de diagramas gráficos - Efectuar a verificação sistemática da qualidade - Implementar um processo sistemático de controlo de alterações Cada uma destas melhores práticas tem impacto nas outras. Ainda há mais princípios: - Conseguir promover o envolvimento dos utilizadores - Utilizar abordagem orientada para a resolução de problemas - Definir e utilizar standards para o desenvolvimento e documentação - Justificar o desenvolvimento do software com actividade estratégica e investimento financeiro - Conceber sistemas de modo a facilitar a sua expansão e alteração 2.5. fases do Desenvolvimento de Software

Necessidade de aplicar um processo com fases bem definidas, que se subdividem em conceitos mais elementares (tarefas e actividades), isto desde que se verificou que a programação estruturada não era suficiente. A natureza sequencial obriga a que uma fase (ou tarefa ou actividade) tenha de estar terminada antes de outra começar. Nesta perspectiva, uma fase é constituída por uma sequência de tarefas, e estas por sua vez são formadas por actividades. Os 2 primeiros são abstractos e as actividades correspondem de facto a trabalho realizado, sendo pois a unidade mais elementar.Um processo divide-se em três grandes fases: - Concepção: identificar “o que é que o sistema deve fazer”. Inclui Planeamento e Análise - Implementação: identificar “o como fazer o sistema”. Inclui Desenho, Desenvolvimento, Testes e Integração e Instalação - Manutenção. Inclui Operação e Manutenção Há quem considere que o levantamento dos requisitos do sistema e a respectiva especificação são tarefas distintas, enquanto outros autores juntam ambas na tarefa de análise e consideram-na como duas actividades da referida tarefa (nossa opção). Há quem considere que o desenho é uma tarefa da concepção uma vez que as actividades são de definição e não de implementação. A nossa visão é que é definição do que se vai fazer, logo fica na implementação. As fases podem ser divididas em tarefas mais específicas: - Planeamento: identificação geral das necessidades e selecção de alternativas - Análise: Identificação detalhada das funcionalidades (Levantamento de Requisitos) e respectiva descrição (Especificação do Sistema) - Desenho: Definição detalhada da arquitectura global (módulos, tabelas, interface, máquinas, etc.) - Desenvolvimento: Programação - Testes (ou Integração): O sistema no seu global é verificado para obter aceitação do utilizador - Instalação: Disponibilização dos sistema para os seus utilizadores finais - Manutenção: O momento que corresponde ao tempo de vida útil do sistema e durante o qual são efectuadas todas as alterações. A manutenção sempre foi a tarefa que maior esforço e custos relativos apresenta. Mesmo com as melhores técnicas actuais continuamos quase na mesma (67%) 2.5.1. Tarefas Transversais - Gestão do Projecto Gestão dos recursos humanos, financeiros, controle de prazos. É este o nível que funciona como interface oficial para fora da equipa de projecto --> “gestor de projecto” - Gestão de Alterações É fundamental que estejam previstos mecanismos de controle das alterações 2.5.2. Planeamento Alguns autores não consideram no âmbito da Engenharia de Software. Outros consideram-na como transversal. A nossa perspectiva é que só temos um projecto depois do seu plano estar aprovado, e é esse o objectivo dessa tarefa. Existem várias circunstâncias particulares em que esta tarefa deve ser efectuada: - Num projecto que envolve a selecção de entidades para posterior implementação do software, a elaboração de cadernos de encargos e a avaliação de propostas - Apenas investigação inicial A grande preocupação desta fase é que a partir de um levantamento de alto nível das necessidades do negócio seja possível elaborar um plano de projecto. Para isso existem um conjunto de actividades que deverão ser realizadas: - Compreender a missão e organização da empresa - Identificar e envolver todos os interessados e afectados pela introdução do sistema - Obter uma visão de alto nível do funcionamento do sistema actual (caso exista) - Definir o âmbito do sistema - Elaboração de uma descrição de alto nível do problema - Identificar restrições, problemas e riscos do projecto

- Identificar alternativas de implementação, avaliá-las e seleccionar - Apresentar resultados e recomendações, com justificação técnica funcional e financeira - Elaborar e obter aprovação de um plano de projecto - Definir o processo de controlo do projecto O principal output desta tarefa será um plano de projecto, que deverá reflectir sustentadamente a visão que se tem nesta fase. 2.5.3. Análise Efectua o estudo detalhado do domínio do problema, e culmina na elaboração de um documento onde os requisitos funcionais da solução a implementar e outras questões relevantes (restrições, âmbito, fluxos de informação) são enumerados. Tem, normalmente dois grandes momentos ou sub-tarefas (realizados em simultâneo): - Levantamento de Requisitos Um requisito é uma funcionalidade ou condição que o sistema deverá possuir. Reuniões, observações, protótipos,... - Especificação do Sistema Não é tarefa fácil. As interpretações são subjectivas. O objectivo geral desta subtarefa é expressar sem ambiguidades o que os sistema deve fazer e não como fazer o sistema. A “Especificação de Requisitos” é um documento que deve ser visto como um contrato. 2.5.4. Desenho Pretende efectuar a definição do domínio da solução, com base na análise. Procede-se à especificação formal ou informal das características que a implementação do sistema deverá apresentar. Inclui arquitectura de computadores, tecnologias de bases de dados, etc., bem como ambiente e linguagem de programação a usar. Diz-se por vezes que é a fase de especificação técnica pois aqui se definem componentes aplicacionais, tecnológicos e dados. Factores como o desempenho, a segurança e a operacionalidade, custos e prazos, deverão se critérios para seleccionar alternativas. Planos de testes e de migração deverão ser previstos. 2.5.5. Implementação É a concretização do modelo do desenho. Os componentes aplicacionais são codificados e testados de forma isolada (testes unitários). Actualmente assiste-se, no contexto dos sistemas de informação cliente/servidor, à crescente utilização de ambientes de desenvolvimento bastante produtivos (designados por ambientes RAID – Rapid Application Development), baseados em infra-estruturas de objectos/componentes evoluídos, complexos e providenciando paradigmas de prototipagem de desenvolvimento visual (ex. ferramentas CASE). Cada vez mais as organizações compram produtos previamente desenvolvidos mais ou menos uniformizados funcionalmente (pacotes), o que levou a que a programação pura cedeu uma parte da sua importância em favor de esforços de integração (entre os diverso componentes “préfabricados”), sua parametrização e configuração. 2.5.6. Testes Os testes deverão ser executados em condições idênticas aquelas que o sistema real irá possuir. Podem ser classificados em diferentes categorias, segundo as características do sistema que avaliam: - Testes de carga: avaliam o sistema perante a utilização intensiva e aferem as capacidades de escalabilidade - Testes de desempenho: Analisam o tempo de resposta do sistema e verificam o nível de utilização dos recursos disponíveis - Testes de usabilidade: analisam a adequabilidade do desenho das interfaces homem-máquina - Testes funcionais: se os requisitos são satisfeitos Outra classificação é segundo o âmbito dos componentes do sistema: - Testes unitários - Testes de integração - Testes de sistema

- Testes de aceitação No caso de substituição de sistemas muitas vezes usa-se a estratégia do paralelo de sistemas (repetição das actividades do antigo sistema, no novo). A verificação deve ser acompanhada a diferentes níveis por ferramentas de debugging. 2.5.7. Instalação Envolve um conjunto de tarefas: - Configuração e parametrização do sistema - Instalação dos componentes aplicacionais necessários - Definição de perfis, de utilizadores e de níveis de segurança - Formação dos utilizadores do sistema - Elaboração de documentação de operação, administração e utilização do sistema - Definição e implementação de políticas de segurança (ex. backups) 2.5.8. Manutenção Com o tempo aparecem os bugs, para além de solicitações externas e internas relativamente a pedidos de alteração de requisitos. Novos requisitos (60%); Erros (18%); Melhorias (18%). É possível ver a tarefa de manutenção desencadeia uma nova iteração de todo o processo. 2.6. Processos de Desenvolvimento de Software Podemos distinguir genericamente duas grandes aproximações: - modelo em cascata - aproximação iterativa 2.6.1. Processos em Cascata São os mais tradicionais, em que as actividades a executar são agrupadas em tarefas, executadas sequencialmente, de forma a que uma tarefa só tem início quando a tarefa anterior tiver terminado. Baseia-se no pressuposto que o cliente participa activamente (e vai validando as várias tarefas) no projecto e que sabe muito bem o que quer. Mas, infelizmente, a salvaguarda não evita que o cliente fique desapontado. O modelo apresenta ainda outras limitações, como a compartimentação de esforços, o desencorajamento de comunicação, não se pode voltar atrás mesmo que as conclusões anteriores sejam modificadas com o evoluir do processo. De forma a evitar este problema foi criado o modelo em cascata revisto (ciclo). O risco desta abordagem é que, na ausência de um processo de gestão e controle bem definido, podemos passar o tempo num ciclo sem fim. Ambos os modelos anteriores apresentam o problema da extensão do período de tempo que decorre entre o início do projecto e a entrega do produto. Uma solução consiste na aplicação de técnicas de prototipagem logo no início do processo (prototipagem rápida). Não elimina a necessidade de todas as tarefas sequenciais, mas permite que o cliente veja e valide um modelo da interface (e das funcionalidades) que irá ter disponível, reduzindo também os problemas de comunicação. Aqui é preciso cuidado e saber resistir à pressão do cliente que quer passar a utilizar de imediato o protótipo. Além de se poder perder a visão global face ao imediatismo dos écrans. 2.6.2. Processos Iterativos e Incrementais São mais recentes e pretendem encorajar a comunicação. Iterativo Corresponde à ideia de melhorar (ou refinar) pouco-a-pouco (ex. trabalho artístico). Vantagens: - Os riscos e as dúvidas com maior importância são identificados no início do processo, nas primeiras iterações, quando é possível tomar medidas para os corrigir. - Encoraja a participação activa dos utilizadores - Testes contínuos e iterativos permitem avaliação contínua do estado do projecto - As inconsistências entre desenho e implementação são detectadas atempadamente

- O esforço dos elementos é distribuído ao longo do tempo - A equipa pode aprender com experiências anteriores Incremental Corresponde à ideia de aumentar (ou alargar) pouco-a-pouco o âmbito do sistema. ex. mansão a partir de 2 anexos. Iterativo e Incremental A principal consequência é que os produtos finais de todo o processo vão sendo amadurecidos e completados ao longo do tempo. Espiral É uma pequena variante do modelo iterativo e incremental. Propõe logo de seguida à tarefa de planeamento a realização de uma tarefa de prototipagem e de análise de risco.

CAP. 3 – EVOLUÇÃO DAS METODOLOGIAS DE DESENVOLVIMENTO DE SOFTWARE 3.1. Introdução Larry Constantine tentou identificar mecanismos que possibilitassem que a concepção inadequada de software fosse evitada desde o início, aquando da identificação dos requisitos. Em conjunto com Wayne Stevens e Glen Myers propôs o conceito de Composite Design, renomeado para “desenho estruturado” [Stevens74]. 3.2. A Programação Como Fonte de Inovação Depois do programa, veio o módulo. A ideia era agrupar num módulo dados e código, que estivessem relacionados de forma a limitar as interacções entre módulos À invocação de funções. No entanto era ainda possível aceder do exterior aos dados declarados dentro de um módulo. Para evitar isso foi proposto o conceito de tipo de dados abstracto (ADA) que permitem “esconder” totalmente partes da sua implementação (quer o nível de dados quer código), e disponibilizam para o exterior o que se designa por interface. Ligação muito forte entre dados e código. A evolução levou ao aparecimento das linguagens orientadas por objectos (Smalltalk, C++, Java, Object Pascal). A principal diferença para os tipos de dados abstracto é que as OO suportam a noção de herança 3.3. O Desenvolvimento Ad-Hoc Em face das potencialidades limitadas das LP, as primeiras aplicações foram construídas sem a utilização de uma metodologia de desenvolvimento formal, correspondendo ao que normalmente se designa por “programar e corrigir” (“build and fix”). Estes desenvolvimentos eram caracterizados por: - Envolvimento limitado dos utilizadores - Identificação de requisitos efectuada de forma inadequada - Fraca utilização de técnicas de análise e desenho - Inexistência de ferramentas de apoio a todo o processo - tarefas de desenvolvimento muito demoradas - Sistemas de acesso à informação pouco flexíveis Quando a complexidade aumentou, a situação ficou mais problemática, o que ainda foi agravado por: - Os informáticos eram reconhecidamente bons programadores, mas raramente tinham preocupação de compreender o negócio - Não eram aplicadas técnicas ou mecanismos de controlo e de gestão do projecto, e por isso estes ultrapassavam frequentemente custos e prazos estimados - A fraca qualidade do produto final implicava correcções frequentes 3.4. Metodologias Estruturadas Durante os anos 70 e 80 assistiu-se À introdução de técnicas estruturadas de decomposição funcional, com o objectivo de identificar os requisitos e introduzir técnicas baseadas nas melhores práticas ao processo de análise e desenho. 3.4.1. Contexto e Motivação O objectivo era prestar mais atenção ao processo global e menos à programação. A maioria das metodologias adoptaram o modelo em cascata. As metodologias estruturadas estavam orientadas segundo uma de 2 abordagens: - Mais orientada para a decomposição funcional do sistema e identificação dos respectivos processos (funcional) – funções, algoritmos e actividades - Mais centrada nos conceitos e nos dados das organizações (orgânica) Na análise funcional o suporte dado pelas LP da altura permitiam divisão do código em blocos e, assim, um certo encapsulamento. No entanto, a possibilidade dos dados serem globalmente visíveis e manipulados por todo o programa reduzia estas características e era pouco flexível a alterações. Na análise orgânica a atenção concentra-se nos dados, colocando os conceitos e as entidades manipuladas no negócio como elementos chave. A ideia é mesmo quando uma aplicação muda, os conceitos principais devem permanecer e continuar a ser utilizados.

3.4.2. Conceitos Básicos - Processo (de negócio): Sequência de actividades, que processam vários inputs e produzem vários outputs (pode ser decomposto em subprocessos) - Fluxo de Informação: Representa toda a circulação de informação que ocorre na organização de forma a executar os processos de negócio - Repositório de Dados: Representam os conceitos sobre os quais importa à organização reter dados sobre - Entidade: Representa todos os conceitos de negócio, físicas ou abstractas, internas ou externas. - Estado de uma entidade: É representado por um conjunto de valores dos atributos da entidade podem assumir - Evento: Acontecimento desencadeado internamente ou externamente É relativamente fácil identificar estes conceitos numa situação concreta, o problema é descrever bem e organizadamente e objectivamente a situação. Ex. Compras de uma empresa: Ex. de processos (verbos), que são o mais relevante nas metodologias estruturadas, os primeiros a ser identificados e que conduzem toda a análise e especificação posterior.: preenche uma requisição; consulta uma lista; envia para o seu director; analisar o pedido; pode ou não autorizar;... 3.4.3. Técnicas e Notações Mais Utilizadas - Diagrama de Fluxo de Dados (data flow diagram): São especificações orientadas aos processos, em que se identificam graficamente processos, entidades externas, fluxos de informação e repositórios de dados. São os principais diagramas utilizados na modelação de processos. Estes diagramas podem ser construídos em vários níveis, uma vez que existe a possibilidade de especificar um processo através de um diagrama de maior detalhe. O diagrama de fluxo de dados de primeiro nível é nalgumas metodologias designado por diagrama de contexto. - Diagramas de entidade associação: Representam as relações estáticas de sistema, designadamente as entidades, com os seus atributos, e a forma como estas se encontram associadas. - Diagrama de transição de estados: Representam os estados em que um sistema ou uma entidade se pode encontrar ao longo do tempo, e dos eventos que desencadeiam as transições. Diagrama de ciclo de vida de entidade: Versão adaptada de um diagrama de estados para descrever a evolução de uma entidade ao longo da sua existência, designadamente as operações de criação, alterações e eliminação. - Dicionário de dados: São repositórios de definições de todos os elementos e conceitos utilizados e manipulados pela organização (dados, ficheiros, processos e entidades). - Matrizes entidade-processo: Demonstram as relações existentes entre as entidades e os processos - Fluxogramas: Expressam os passos de execução de algoritmos e processamentos realizados no sistema. É ainda de referir a técnica da normalização para eliminar redundâncias e garantir a integridade da informação nas estruturas/bases de dados. Qualquer relação expressa num diagrama entidade associação pode ser analisada na perspectiva de qualquer entidade e implica a caracterização segundo 2 conceitos adicionais: a cardinalidade (nº máximo de cada uma na relação) e a modularidade (nº mínimo de ocorrências de cada uma, o que permite identificar as obrigatórias e as opcionais). Estes diagramas melhoraram o rigor da especificação, no entanto continuam a apresentar algum grau de subjectividade até porque prevêem descrições em linguagem natural. Além disso a utilização de alguns termos e símbolos muito próximos da tecnologia impediu a compreensão por parte dos não técnicos. Os diagramas a que aludimos são notações semi-formais e não era possível garantir a sua correcção, pelo que foram propostas notações formais, que se caracterizavam por adoptar conceitos muito próximos da matemática, com o rigor e formalismos correspondentes. Algumas notações mais conhecidas são: - Redes de Petri: especialmente adequados a problemas de concorrência e com restrições anível de sincronização. Utiliza conceitos como transições, funções de input e de output.

- Linguagem Z: Com conceitos matemáticos e lógicos de 1ª ordem (conjuntos, tipos de dados, constantes, definições de estado, estado inicial, operções) 3.4.4. Principais Metodologias SSADM (Structured Sistems Analysis and Design Methodology). Proposta em 1981 por Learmoth. Propõe a modelação de um sistema segundo 3 perspectivas complementares: - a sua funcionalidade (diagrama de fluxo de dados) - a sua estrutura (diagrama de entidade associação) - a sua evolução ao longo do tempo (diagramas de ciclo de vida) É concebida para a análise e desenho não contemplando a implementação, testes e instalação. A sequência de actividades envolve: - A realização de um estudo de viabilidade - A análise de requisitos do negócio - A especificação dos mesmos requisitos - A especificação lógica do sistema - O desenho físico do sistema Stradis (Strutured analysis, design and implementation of information systems). Gane e Sarson nos finais da década de 70, baseada na filosofia de decomposição funcional top-down e suportada essencialmente pela utilização de diagramas de fluxo de dados. Yourdon Systems Method 1993, Edward Yourdon. É semelhante à Stradis pois recorre muito à decomposição funcional mas também atribui importância significativa às estruturas de dados. Engenharia de Informação James Martin em 1989. Integra muitos conceitos das outras. Ao contrário das outras tem uma preocupação estratégica com a definição dos sistemas de informação, o que é expresso nos diferentes estágios de evolução do processo: planeamento estratégico; análise de áreas de negócio; desenho de sistemas; implementação. 3.5. Metodologias Orientadas por Objectos As técnicas anteriores apresentavam vários problemas: - Não conseguem lidar adequadamente com o problema da complexidade e do tamanho crescente dos sistemas - Não resolvem o problema da crescente actividade de manutenção do software - Verifica-se com frequência a má compreensão dos requisitos do utilizador por parte dos técnicos - Permanece a dificuldade de lidar com alterações aos requisitos - A integração e reutilização de módulos e componentes não são fáceis - Os erros de concepção são descobertos tardiamente - A qualidade do software é baixa e o seu desempenho inadequado - Não é fácil identificar quem fez o quê, quando e porquê. O conceito de orientação por objectos baseia-se de facto numa nova forma de analisar o mundo. A abordagem seguida reproduz a forma como o ser humano se apercebe e expressa a realidade que o rodeia. Ele classifica e subdivide o mundo em diferentes objectos, com base nas diferenças e semelhanças existentes ao nível das características e comportamentos. Isso permite a reutilização dos objectos. A perspectiva de modelação muda, uma vez que o mesmo conceito base é utilizado ao longo de todas as fases do processo, promovendo a reutilização e o encapsulamento da informação, facilitando a manutenção. 3.5.1. Contexto e Motivação Simula nos finais dos 60; Smalltalk nos 70. Motivações principais para a realização de actividades de análise segundo o OO: - Poder tratar domínios de problemas mais complexos - Melhorar a interacção entre o analista e o especialista do problema - Aumentar a consistência interna dos resultados da análise

- Representar explicitamente aspectos comuns a diversos conceitos - Construir especificações capazes de resistir à mudança - Reutilizar resultados da análise - Conceber uma representação consistente para a análise e desenho. 3.5.2. Conceitos Básicos (Princípios e Restantes) Princípios Orientadores do Paradigma - Encapsulamento da Informação: é o processo de “esconder” todos os detalhes de um objecto que não contribuem para as suas características essenciais nem para a disponibilização de funcionalidades para o seu exterior. Pode ainda ser encarado como a localização de funcionalidades numa única abstracção auto-contida, que esconde a respectiva implementação e decisões de desenho através da disponibilização de uma interface pública. O conjunto de operações que são acessíveis do exterior constitui a interface do objecto. Esta característica permite a criação de objectos estáveis e reutilizáveis, reproduzindo o mundo real de forma correcta. - Herança: Representa a definição de relações entre classes através da qual uma subclasse (é especialização) partilha, acrescenta ou redefine operações e atributos a partir de uma ou mais superclasses.. É uma forma de aumentar a reutilização do que é comum, permitindo adicionalmente acrescentar detalhes específicos. Está ligado aos conceitos de generalização e especialização. Polimorfismo: É a capacidade de “esconder” várias implementações distintas através de uma única interface, isto é, representa a capacidade de objectos diferentes responderem de forma diferente à mesma mensagem. Abstracção: É a representação concisa duma ideia ou objecto mais complexa, incidindo sobre as características essenciais. Abstracções funcionais (processos); OO (objectos). As que não suportam os dois princípios do meio são considerados baseados em objectos e não OO. Existem ainda mais 3 noções importantes: - Modularidade - Concorrência - Persistência Outros Conceitos Chave do Paradigma da OO - Objecto: há várias definições que podemos resumir em: Representam identidades físicas, conceptuais ou apenas necessárias para a representação em computador (por ex. estruturas de dados); um objecto pode ser um conceito, uma abstracção ou uma entidade, com fronteiras bem definidas e que tem um significado para um problema e respectiva solução; um objecto tem estado, comportamento e identidade. - Atributos: São propriedades nomeadas de um objecto, que definem o estado. - Comportamento (operação ou serviço): Conjunto de acções que um objecto pode realizar de forma independente. - Classes (template/fábrica de objectos): São descrições de grupos de objectos com propriedades (atributos), comportamento (operações) e relações comuns. Em geral os atributos permitem identificar a classe, definir as características especiais da classe, definir o estado da classe, reter alguma informação sobre a classe e identificar o comportamento do objecto. Para especificar detalhadamente um atributo deve-se identificar o domínio dos seus valores, as unidades de medida, o valor por omissão, o valor inicial, as condições de leitura e escrita e eventuais condições relacionadas com outros atributos do objecto ou da classe. dado o enunciado de um problema, procura-se identificar os objectos concretos e as respectivas classes, a partir de todos os substantivos que dele sejam extraídos. O objectivo último é identificar: - Um conjunto de classes que representam totalmente o domínio do problema - Os atributos de cada classe - A interface e os serviços de cada classe - As diversas relações entre classes - Objectos concretos que seja necessário particularizar. Cada metodologia propõe diferentes formas de chegar à informação.

Por ex. ver [Coad91] e checklists para saber quando um objecto potencial não o é, na pg.93. ex. funcionário; requisição; bens; armazém. As operações realizadas por objectos podem ser identificadas pela pesquisa no enunciado do problema de verbos associados a cada objecto. Essas operações podem ser agrupadas em: - Modificadores: operação que altera o estado do objecto. - Selectores: Operação que acede ao estado de um objecto - Iteradores: operação que permite que todas as partes de um objecto sejam acedidas segundo uma ordem bem definida - Destrutor: Liberta o estado de um objecto ou elimina-o. Uma mensagem é sempre formada por um selector e opcionalmente por um conjunto de parâmetros. A interface é o conjunto de operações e atributos disponibilizados por uma classe, que consoante a visibilidade pode ser pública (visível por todos os objectos do sistema), privada 8só visível pela própria classe) ou protegida (pela classe e subclasses). Entre as diversas classes podem ser estabelecidas diferentes tipos de relações: - Associação: Representam as relações estruturais entre objectos de classes diferentes (ter). Subdivide-se em: - Agregação: Relação entre o todo e as partes (uma empresa tem empregados) - Composição: O corpo humano tem uma perna - Dependência: Relação em que uma mudança de estado num objecto (ocorrida pela recepção de uma mensagem) pode implicar o envio de uma mensagem a outro objecto. - Generalização/Especialização: Relações entre classes que partilham a estrutura e comportamento; implementam o conceito de herança (ser). Um cão é um animal. Subsistema é um conjunto de classes (ou outros subsistemas) que colaboram entre si para realizar um conjunto de responsabilidades (no UML é o pacote). 3.5.3. Técnicas e Notações Mais Utilizadas Ver UML mais à frente. 3.5.4. Principais Metodologias Ao longo das décadas de 80 e 90_ - Método de Booch (1991): baseia-se na ideia da repetição de actividades de um processo de desenvolvimento de modo a refinar o modelo em sucessivas iterações. As suas principais actividades estão orientadas para a identificação de classes e objectos e respectivas características e para a determinação das relações entre classes. - OMT (Object Modelling Technique)- James Rumbaugh (1991): concentrou-se na análise e desenho de software. 3 modelos essenciais: - estático ou de objectos (rep. classes, objectos, relações) - dinâmico (comportamento dos objectos e sistema global) - funcional (diagrama de fluxo de informação) - OOSE (Object Oriented Software Engineering) – Ivar Jacobson (1992) Resulta da evolução do modelo Objectory e a sua maior contribuição foi a introdução da noção de caso de utilização. - OOAD (Object Oriented Analysis and Design) – Peter Code e Edward Yourdon (1991) vantagem: simplicidade (de conceitos, actividades e diagramas) - Identificar objectos utilizando critérios simples (substantivos) - Definir uma estrutura de relações generalização-especilaização - Definir uma estrutura de relações de associação (whole-part) - Identificar assuntos (subsistemas) - Definir os atributos - Definir os serviços - Método de Wirfs-Brock Não efectua distinção clara entre análise e desenho e a sua principal contribuição foi a definição de diagrama designado por CRC cards (Class-Responsibility-Colaboration) que procura identificar as classes dos sistema, a sua interface e as relações entre elas. - Rational (cap.10)

3.6. Outras Metodologias As metodologias não estão isentas de críticas e aspectos menos positivos: - Complexidade nos conceitos, técnicas e aplicação - Desconhecimento global e falta de competências dos informáticos para a sua execução com qualidade - Ferramentas difíceis de utilizar - Constatação da ausência de melhorias no processo e produto final - Concentração na análise da situação actual e não no futuro - Tempo - Rigidez Como reacção apareceram um conjunto de metodologias que usam um formalismo muito menor. Código fonte é tudo em documentação e as principais actividades são programar e testar. Concentram-se na satisfação das necessidades das pessoas e não na definição dos processos. É iterativo. Não há designação formal para elas ainda mas usa-se o termo lightweight. XP – Extreme Programming e DSDM – Dynamic System Development Method. São aconselháveis para sistemas pequenos e com requisitos incertos ou voláteis e com técnicos e utilizadores motivados. 3.7. Comparação de Metodologias É tarefa complexa devido a: - Não existem metodologias iguais - Muitas metodologias são influenciadas ou concebidas para linguagens de programação específicas - Muitas metodologias assumem contexto particular de aplicação - A abrangência varia fortemente Hoje em dia reconhecem-se vantagens das OO relativamente às estruturadas, porque apresentam: - Um único paradigma consistente ao longo de todo o processo, mais próximo do processo de cognição humano - Facilitam a reutilização - Modelos que reflectem o mundo real - Não existe separação entre dados e processos - Os detalhes de implementação estão escondidos (encapsulamento) - Maior facilidade de tarefas de manutenção - O sistema é mais estável Às vezes o problema é encontrar objectos e classes apropriados pois os informáticos continuam a pensar funcionalmente. 3.7.1. Gestão de Requisitos e Facilidade de Manutenção No desenvolvimento estruturado, o sistema consiste num conjunto de dados que são usados (leitura ou escrita) por inúmeras funções. é pois uma malha arbitrária de inúmeras interdependências entre funções e dados. No OO, dados e funções são agregados conjuntamente numa entidade lógica (o objecto) que providencia uma interface bem definida para outros objectos comunicarem com ele. O sistema corresponde a uma malha de interdependências entre objectos. É evidente que as OO facilitam a gestão de alterações de requisitos. Ex alteração da estrutura de dados implicava alterar todas as funções; no OO desde que interface não mudasse era fácil. 3.7.2. Representação da Realidade Nas abordagens OO, as entidades do mundo real são captadas directamente por objectos. Nas estruturadas o foco é no desenho da base de dados ou, alternativamente, na definição dos processos/funções que acedem e manipulam essas bases. Difícil especializar contas bancárias. 3.7.3. Outros Aspectos Outras vantagens:

- Providencia blocos de construção de alto nível que reduzem os custos de desenvolvimento, pela promoção da reutilização e encapsulamento de software. Este facto permite reduzir as interdependências e facilita manutenção posterior. - Facilita transferência de conhecimento através da adopção de “padrões de desenho”, reduzindo custos de aprendizagem - Providencia framework (aplicacional ou de middleware) para facilitar a extensão do sistema, reduzindo o custo de novas versões - Reduz o custo de alteração do sistema. Todavia há que ter alguns cuidados na sua aplicação: - Exige uma nova forma de pensar o processo de desenvolvimento - Deve ser usada em todas as fases do ciclo de vida do software - A gestão da empresa tem de “comprar” a mudança para a filosofia OO (ex. redução de custos de manutenção) - A migração deve ser devidamente planeada.

Parte 2 – Linguagem de Modelação UML O UML O UML (Unified Modelling Language) é uma linguagem diagramática, utilizável para especificação, visualização e documentação de sistemas de software. Tem as seguintes características principais: - É independente do domínio de aplicação (sistemas cliente/servidor tradicionais, sistemas baseados na web, de informação geográficos, de tempo real, etc.). - É independente do processo ou metodologia - É independente das ferramentas de modelação - Apresenta mecanismos potentes de extensão - Agrega um conjunto muito significativo de diferentes diagramas/técnicas dispersos por diferentes linguagens (diagramas de casos de utilização, de classes, de objectos, de colaboração, de actividades, de estados, de componentes, e de instalação). O objectivo principal do UML é promover e facilitar a comunicação entre um grupo variado de intervenientes. CAP. 4 – UML – VISÃO GERAL 4.1. Introdução O UML é uma linguagem para especificação, construção, visualização e documentação de artefactos de um sistema de software. O UML providencia as seguintes particularidades principais - Semântica e notação para tratar um grande número de tópicos actuais de modelação - Semântica para tratar tópicos de modelação futura (tecnologia de componentes, computação distribuída, frameworks e Internet) - Mecanismos de extensão - Semântica e sintaxe para facilitar a troca de modelos entre ferramentas distintas É independente das linguagens de programação, das ferramentas CASE e dos processos de desenvolvimento. Os novos elementos introduzidos no UML são: - Mecanismos de extensão - Elementos para modelar processos e threads - Elementos para modelar concorrência e distribuição - Padrões de desenho e colaborações - Diagramas de actividades (para modelação de processos de negócio) - Refinamento - Interfaces e componentes - Linguagem de restrições (OCL) O UML providencia os seguintes tipos de diagramas: - De casos de utilização - De classes e de objectos - De comportamento - De estados (statechart) - De actividades - De interacção ( de sequência e de colaboração) - De arquitectura - De componentes - De instalação 4.2. Visão Histórica fase da fragmentação – fase da unificação – fase da standardização – fase da industrialização. Actualmente assiste-se à divulgação e adopção generalizada do UML como “a” linguagem de modelação de software segundo a abordagem orientada por objectos. Há 2 aspectos importantes que se obtêm com o UML: - Terminam as diferenças, geralmente inconsequentes, entre as linguagens de modelação dos anteriores métodos

- Unifica as distintas perspectivas entre diferentes tipos de sistemas (ex. modelação de negócio, modelação de software), fases de um processo e conceitos internos. 4.3. Tipos e Elementos Básicos A estrutura de conceitos do UML é razoavelmente abrangente consistindo num conjunto variado de notações, as quais podem ser aplicados em diferentes domínios de problemas e diferentes níveis de abstracção. A estrutura de conceitos do UML pode ser vista através do seguinte conjunto de noções: - “Coisas” ou elementos básicos, com base nos quais se definem os modelos - Relações, que relacionam os elementos - Diagramas, que agrupam os elementos Os principais elementos de estrutura são: - Classes - Interfaces - Nós - Classes activas - Actores - Componentes - Casos de utilização - Colaborações Há outros elementos básicos: - De comportamento: - Estados - Mensagens - De agrupamento: - Pacotes - De Anotação - “Isto é uma anotação” 4.4. Tipos de Relações São conceitos gerais (com sintaxe (notação) e semântica bem definidas) que permitem o estabelecimento de interdependências entre os elementos básicos associação 0-1 * -------------------tem vive realização -------------------|> dependência ------------------> transição de estado _____________________> generalização _____________________|> 4.5. Tipos de Diagramas São conceitos que traduzem a possibilidade de agrupar elementos básicos e suas relações de uma forma lógica ou de uma forma estrutural. Há vários tipos, cada um utilizando um subconjunto dos elementos, com diferentes tipos de relações que tenham sentido para cada caso. Com base no 4º principio de modelação (ver cap.2) “Nenhum modelo é suficiente por si só. Qualquer sistema não trivial é melhor representado através de pequeno número de modelos razoavelmente independentes, o UML define diferentes tipos de diagramas que permitem visões complementares: - Diagramas de Casos de Utilização, que representam a visão do sistema na óptica do utilizador.

- Diagramas de Classes, que permitem especificar a estrutura estática de um sistema segundo a abordagem orientada por objectos - Diagramas de Interacção Entre Objectos (de sequência e de colaboração) e diagramas de transição de estados e de actividades que permitem especificar dinâmica ou comportamento do sistema - Diagramas de Componentes e Diagramas de Instalação, que dão visão da disposição dos componentes físicos (software e hardware) de um sistema. 4.5.1. Diagramas de Casos de Utilização Descreve a relação entre actores e casos de utilização de um dado sistema. Dá visão global de alto nível do sistema. São usados preferencialmente na fase de especificação dos requisitos e na modelação de processos de negócio. 4.5.2. Diagramas de Modelação da Estrutura Os diagramas de classes descrevem a estrutura estática de um sistema, em particular as entidades existentes, as suas estruturas internas, e relações entre si. Um diagrama de objectos ... em determinado momento. 4.5.3. Diagramas de Modelação do Comportamento Os padrões de interacção entre objectos são representados por diagramas de interacção, que podem assumi formas complementares, cada um focando aspectos distintos: diagramas de sequência e diagramas de colaboração. Diagramas de Sequência Ilustram interacções entre objectos num determinado período de tempo (objectos são representados pela sua “linha de vida” e interagem por trocas de mensagens) Diagramas de Colaboração Ilustram interacções entre objectos com ênfase para a representação das ligações entre objectos. Como não aparece o tempo, a sequência de mensagens e actividades concorrentes é determinada pelo uso de números sequenciais, com diferentes níveis hierárquicos. As colaborações são entidades de modelação principais e constituem a base para a representação visual de padrões de desenho (design patterns) Diagramas de Transição de Estado Descrevem as sequências de estados que um objecto ou um interacção pode passar ao longo da sua existência em resposta a estímulos recebidos, conjuntamente com as suas resposta e acções. Diagramas de Actividades São caso particular do anterior, no qual a maioria dos estados são substituídos pelos conceitos correspondentes e acções ou actividades, e no qual as transições são desencadeadas devido à conclusão de acções nos estados originais. O objectivo é representar fluxos por processamento interno, em contraste com o diagrama anterior que se usa mais para eventos externos. Diagramas De Arquitectura Descrevem aspectos da fase de implementação de um sistema de software. Apresentam-se de duas formas: - Diagramas de Componentes Descrevem as dependências entre componentes de software - Diagramas de Instalação (deployment diagrams) Descrevem a configuração de elementos de suporte de processamento, e de componentes de software, processos e objectos existentes nesses elementos. 4.6. Mecanismos Comuns (aos vários diagramas) 4.6.1. Notas (Anotações) São os adornos mais importantes que existem autonomamente. Uma nota ilustra um comentário e não tem qualquer impacto semântico. Não altera pois o significado do modelo. É normal usar-se para descrever informalmente: requisitos, restrições, observações, revisões ou explicações. Deve ter-se em atenção:

- Localização: perto dos elementos que descrevem - Visibilidade: escondidas ou visíveis - Extensão: usar referências (URLs, etc.) - Evolução 4.6.2. Mecanismos de Extensão São os Estereótipos; Marcas e Restrições. No seu uso deve-se: - Introduzir um número reduzido - Escolher nomes curtos e com significado, para os 2 primeiros - Usar texto livre para especificação das restrições, sempre que a precisão possa ser relaxada. - Deve ser realizada por especialistas em UML, principalmente no caso dos estereótipos Estereótipos É um metatipo. Permite definir novos tipos de elementos sem se alterar o metamodelo do UML «» A definição de um estereótipo tem de ter em conta os seguintes aspectos: - Propriedades (pode providenciar o seu próprio conjunto de marcas) - Semântica (pode providenciar as suas próprias restrições) - Notação (pode providenciar o seu próprio ícone) - A classe base do metamodelo, que vai ser estendida Marcas Com Valor Cada elemento em UML tem um conjunto de propriedades. Por exemplo: as classes têm um nome, uma lista de atributos e uma lista de operações; as associações têm um nome e dois ou mais elementos participantes. Enquanto que os estereótipos permitem adicionar novos elementos UML, as marcas com valor permitem adicionar novas propriedades aos elementos. Deve ser entendida como metadata (isto é dados que descrevem dados) pois o seu valor aplicase ao próprio elemento e não às suas instâncias. { } Restrições (constraints) Permitem adicionar ou alterar a semântica assumida por omissão de qualquer elemento UML. { } A condição pode ser especificada numa linguagem formal ou informal. 4.7. Tipos de Dados É uma abstracção utilizada de forma implícita no UML. Não são elementos do modelo e por conseguinte não lhe são associados estereótipos, marcas com valor ou restrições. Um tipo primitivo não tem subestrutura. - Primitivos: Integer, String, Time - Enumerados: Boolean, AggregationKind, VisibilityKind - Outros: Expression, Mapping, Name, Multiplicity 4.8. Organização dos Artefactos – pacotes Um pacote (package) é em UML um elemento meramente organizacional. Permite agregar diferentes elementos de um sistema em grupos de forma que semântica ou estruturalmente faça sentido. A necessidade é evidente em sistemas de média/grande dimensão, impossíveis de modelar de uma “só vez”. Os benefícios são: - Facilita a gestão e procura de artefactos - Evita conflito de nomes ( X::A é diferente de X::Y::A, e diferente de Z::A ) - Providencia um mecanismo de controlo de acessos (visibilidade) 4.8.1. Representação Gráfica Os pacotes são representados por uma pasta (tabbed folder) com duas zonas complementares: um pequeno rectângulo (designado por tabulador ou tab), normalmente com o nome do pacote; e um rectângulo maior onde normalmente se especificam os elementos constituintes. Há várias formas alternativas e o + significa visibilidade (dos elementos) pública, - é privada e # protegida. Pode-se ainda especificar hierarquias e marcas, estereótipos e restrições.

4.8.2. Relações Entre Pacotes Importação; Exportação e Generalização. Visibilidade - pública: o elemento pode ser usado/referenciado por qualquer outro elemento independentemente do local onde é definido - privada: pode ser usado/referenciado por elementos definidos no mesmo pacote - protegida: pode ser usado/referenciado por um elemento definido no mesmo pacote ou num outro pacote que seja uma especialização (através da relação de herança) do primeiro. Também se pode definir relação de friend entre 2 pacotes (é uma relação de dependência entre pacotes, com estereótipo «friend»). Contudo esta relação deve ser evitada porque viola os princípios do encapsulamento e da minimização de dependências. Importação e Exportação Um pacote faz a exportação, por definição, de todos os seus elementos públicos. mas tal facto não implica que um elemento definido noutro pacote possa aceder/referenciar um elemento exportado num outro pacote. Para que tal acontecesse deveria existir explicitamente uma relação de importação entre esses dois pacotes. A relação de importação é uma relação de dependência entre pacotes, especificando que o pacote base importa todos os elementos públicos definidos no pacote destino. É representada por uma linha dirigida, a tracejado, com estereótipo «import». Não é transitiva. Não é simétrica. Preferencialmente, os elementos exportados por cada pacote devem ser do tipo interface. Generalização É semelhante à homóloga existente entre classes, e é usada para especificação de famílias de pacotes, típicas em sistemas complexos ou flexíveis (significativamente parametrizáveis, multiplataforma, multi-linguagem). Permite especializar pacotes. 4.8.3. Tipos de Pacotes Ao contrário dos exercícios académicos, em situações reais de modelação de sistemas de software de média/grande dimensão, realizadas por equipas, torna-se necessário tipificar os próprios pacotes. A especificação UML propõe 5 estereótipos standard: - «system» : pacote que representa o sistema inteiro. Agrega os outros. - «subsystem» : representa uma parte do sistema - «facade» : pacote com elementos (tipicamente classes e interfaces) que constituem a fachada (ou a interface de programação) - «framework» : é uma arquitectura de classes e interfaces com inúmeros pontos de variabilidade ou de extensão e com estruturas de objectos padronizadas, conhecidas por padrões de desenho. O desenvolvimento de sistemas baseados em frameworks e em componentes de software é um tópico emergente extremamente actual. - «stub»: um adaptador (stub) é usado quando se pretende partir um sistema em diferentes pacotes por motivos de divisão de trabalho. Em geral os pacotes mais usados são sistema ou subsistema. 4.8.4. Modelação de Grupos de Elementos Algumas formas clássicas de organização dos artefactos de projectos em termos de pacotes: - Organização por casos de utilização: ex. ICONIX - Organização por tipos de modelos: ex. RUP

CAP. 5 – UML – CASOS DE UTILIZAÇÃO 5.1. Introdução A engenharia de requisitos preocupa-se em capturar, armazenar e gerir requisitos. Um requisito é uma especificação de uma determinada acção ou condição que o sistema deve satisfazer. Um requisito funcional descreve uma dada acção (ou função) que o sistema deve suportar. Um requisito não funcional descreve um aspecto (não funcional) que o sistema deve satisfazer. Requisitos não funcionais têm a ver com aspectos gerais do sistema, tais como: desempenho, robustez, fiabilidade, distribuição, segurança, integração com Internet, abertura, ou suporte de standards. O UML inclui os diagramas de casos de utilização (use cases) que permitem a especificação de requisitos funcionais segundo uma aproximação focada principalmente nos utilizadores do sistema. Esta abordagem facilita a comunicação. A relação entre casos de utilização e requisitos não é pacífica. Há alguns aspectos importantes na especificação de requisitos, que têm a ver com a sua apresentação, organização e nível de detalhe. Quanto aos 2 primeiros há autores que advogam diagramas (de casos de utilização) seguidamente cada caso em particular deve ser especificado em detalhe através de descrição textual e, opcionalmente, através de um ou mais diagramas de colaboração e/ou desenhos de protótipos de interfaces homem-máquina (ex. screenshots). Quando os requisitos são descritos textualmente, recomenda-se normalmente que sejam numerados sequencialmente segundo, pelo menos, duas sequências distintas: uma para os requisitos funcionais e outra para os requisitos não funcionais. Por outro lado, quando os requisitos são baseados nos casos de utilização, deve usar-se o elemento pacote do UML como elemento estruturante. Em geral é preferível a descrição de casos de utilização de forma não muito detalhada, variando entre uma a 5 páginas. 5.2. Casos de Utilização É uma sequência de acções que um ou mais actores realizam num sistema de modo a obterem um resultado particular. O modelo de casos de utilização permite capturar os requisitos de um sistema através de um detalhe de todos os cenários que os utilizadores podem realizar. mais que iniciar a modelação de requisitos do sistema, os casos de utilização dirigem/conduzem todo o processo de desenvolvimento. É representado por uma oval, com uma frase (verbo no infinitivo) que representa uma acção. Deve descrever o que faz o sistema mas não como o faz. É pois a visão do utilizador. 5.2.1. Casos de Utilização e Cenários Um cenário (2fluxo de acções”) é uma determinada sequência de acções que ilustra um comportamento do sistema; é uma instância de um caso de utilização. Deve-se especificar o comportamento de um caso de utilização descrevendo textualmente um mais fluxos de situação em linguagem não-técnica. deve incluir: - Como e quando o caso de utilização começa e termina - Quando é que o caso de utilização interactua com os actores - que objectos são trocados - Cenário principal, e - Cenários alternativos (situações de excepção) ex. 5.1 Especificação textual do caso de utilização “Validar Utilizador”: Nome; Cenário Principal; Cenário Alternativo 1 (Cliente cancela operação); cenário alternativo 2 (PIN Inválido). Um aspecto importante é o nível de detalhe, que varia muito consoante o tipo de projecto. Normalmente é textual e pode ser complementada por diagramas de interacção ou até protótipos de interfaces. Deve evitar-se linguagem técnica, aspectos tecnológicos, referir explicitamente pessoas (sim papéis) , departamentos específicos, componentes de interface (botões, menus, etc.) ou referências a dispositivos de hardware.

5.2.2. Relações entre Casos de Utilização Generalização; Inclusão e Extensão. Potenciam significativamente a reutilização de especificação de requisitos. Generalização Permite definir casos à custa de outros já existentes, pelo mecanismo de especialização, ou alternativamente, permite definir casos mais abstractos a partir de casos concretos pelo mecanismo da redução ou generalização. Inclusão («include») Corresponde a uma relação típica de delegação, isto é, o caso base incorpora o comportamento do outro caso relacionado. Usa-se para evitar a descrição dos mesmos fluxos inúmeras vezes. Ex: Obter Extracto de conta e Realizar Pagamentos include Validar Utilizador. A questão importante é como indicar, em que ponto da especificação, o caso de utilização relacionado deve ser incorporado no caso base. Este é um aspecto essencial na compreensão e domínio dos casos de utilização. Deve ser efectuada na especificação textual do caso de utilização. Ex. 5.2. Especificação textual do caso de utilização “Obter Extracto de Conta” Nome; Cenário Principal; Incluir caso de utilização “Validar Utilizador”;... Extensão («extend») O caso base incorpora implicitamente o seu comportamento num local especificado indirectamente pelo caso que é usado. Ou seja, o caso destino pode ser estendido com o comportamento de outro(s) caso(s). Permite representar: - A parte de um caso que um utilizador vê como opcional, ou como existindo várias alternativas - Um subfluxo de acções que é executado apenas se determinadas condições se verificarem - Vários fluxos de acções que podem ser inseridos num determinado ponto de extensão, de forma controlada, através de uma interacção explícita com um actor. O caso de utilização de destino é estendido num ou mais pontos (pontos de extensão), ou seja são pontos de entrada do caso de utilização que lhe dá algum nível de configurabilidade e versatilidade. Ex. escolher nº de dias no Obter Extracto de Conta. Textual: Nome: Obter Extracto de Conta; Pontos de Extensão: Nº de Dias; Cenário Principal; Cenário Alternativo 1. 5.3. Diagramas de Casos de Utilização Ilustra um conjunto de casos de utilização, de actores e suas relações. As aplicações mais comuns são: - Para modelar o contexto de um sistema - Para modelar os requisitos de um sistema A ligação entre um actor e um caso de utilização corresponde a um estereótipo de comunicação («communicate»). É representada por linha a cheio. 5.3.1. Actores É o conceito que representa, em geral mas nem sempre (ex. outro sistema informático, hardware, ou tempo), um papel que um utilizador desempenha relativamente ao sistema em análise. 5.3.2. Casos de Utilização Abstractos e Concretos Abstracto: é um caso que não apresenta uma relação de comunicação com qualquer actor ( o seu nome é representado a itálico). São tipicamente casos envolvidos em relações de generalização, inclusão ou extensão com outros casos de utilização. O objectivo é dar ao modelo um nível elevado de reutilização e de flexibilidade. 5.4. Proposta de Metodologia (parece fácil mas não é) 1) Identificar os actores do sistema 2) Identificar, para cada actor, os seus casos de utilização principais 3) Com base nos casos de utilização originai, identificar, factorizar e colocar em evidência casos de utilização que sejam recorrentes em mais que um dos casos originais. Nessa situação, cria-se

o novo caso (em geral abstracto) e os originais envolvidos estabelecem uma relação de inclusão com o dito caso. Repetir o processo até não se conseguir identificar qualquer outro caso a reutilizar. 4) Para flexibilidade e versatilidade, definir pontos de extensão (ou de variabilidade) e conjuntamente definir um ou mais casos abstractos que os permitam estender nesses pontos. 5) Especificar textualmente cada caso segundo um determinado formato previamente definido. ex: Máquina de bebidas 1) Cliente; agente do fornecedor; dono da máquina. 2) Comprar bebida; Repor bebidas; Retirar dinheiro 3) Repor bebidas e Retirar dinheiro envolvem Abrir Máquina e Fechar Máquina (inclusão) 4) Repor bebidas tem um ponto de extensão: encher prateleira (abstracto – vários algoritmos – ex. de acordo com vendas)

CAP. 6 – UML – MODELAÇÃO DA ESTRUTURA 6.1. Introdução Consiste na identificação de classes e suas respectivas relações. Uma classe consiste num estrutura que permite criar objectos semelhantes (em estado e comportamento). O UML providencia os seguintes elementos que permitem a especificação da estrutura ou estática de um sistema de software: - Classes - Relações - Interfaces - Objectos. Com base nestes elementos podem fazer-se 2 tipos de diagramas com fins complementares: - Diagramas de Classes - Diagramas de Objectos 6.2. Classes É a descrição de um conjunto de objectos que partilham os mesmos atributos, operações, relações e a mesma semântica. Corresponde a algo tangível ou a uma abstracção conceptual. É representada por um rectângulo, com uma, duas ou três secções. Na 1ª - nome da classe; na 2ª - lista de atributos; 3ª - lista de métodos. Opcionalmente pode ter 4ª - outra informação (ex. lista de responsabilidades que a classe assume) O nome pode vir na forma simples ou completa ( pacote::nome). Os atributos podem ter apenas o nome ou, adicionalmente, os respectivos tipos, visibilidade e outras qualificações. visibility name [multiplicity] : type-expression = initial-value {property-string} A multiplicidade por omissão é 1..1 (exactamente 1). Nas operações (métodos) podem ver-se só os nomes ou também as assinaturas, visibilidade, outras qualificações (ex. abstracta ou polimórfica). visibility name (parameter-list) : return-type-expression {property-string} Podem definir-se subsecções dentro da 2ª ou 3ª secções de forma a organizar melhor, com base na noção de estereótipo. 6.3. Relações Estabelece a ligação entre elementos e é representada graficamente por um determinado tipo de linha. Os 3 tipos de relações mais importantes são: - Dependências - Generalizações - Associações 6.3.1. Relação de Dependência Indica que a alteração na especificação de um elemento pode afectar outro elemento que a usa, mas não necessariamente o oposto. Linha dirigida a tracejado. No contexto de classes, usam-se dependências para ilustrar que uma classe usa outra como argumento na assinatura de uma das suas operações ou como tipo na definição dos seus atributos. Por clareza não se usa normalmente nos diagramas, pois é implícito. Usa-se mais com pacotes e notas. 6.3.2. Relação de Generalização É uma relação entre um elemento geral (superclasse,...) e um elemento mais específico. is-a ou is-a-kind-of. Representa-se por linha dirigida a cheio com um triângulo a branco num extremo. No contexto das classes usam-se para ilustra relações de herança. A herança providencia mecanismo natural e potente de organização dos programas de software, ao permitir: - Que cada subclasse herde o estado e comportamento de uma superclasse - Subclasses pode adicionar o seu próprio estado e comportamento - As subclasses podem ainda alterar os métodos herdados, providenciando especializações

Os benefícios da herança têm a ver com: - Possibilidade de reutilização de código - Definição de frameworks (programas com estruturas quase completas) através de classes abstractas que definem comportamentos genéricos e/ou estilos de desenho comuns. Por omissão uma relação de generalização representa uma decomposição disjunta ou exclusiva. No entanto outras semânticas podem ocorrer se especificadas: - Generalização disjunta (disjoint): especifica que uma classe descendente de X pode apenas ser descendente de uma das subclasses de X - Sobreposta (overlapping) Uma classe descendente de X pertence ao produto cartesiano das subclasses de X - Completa (complete): completamente especificada ou não. ex. com e sem etiqueta. 6.3.3. Relação de Associação Especifica que objectos de uma classe estão ligados a objectos de outra. ex. “posse” entre utilizador e password. É representada por linha a cheio complementada por um conjunto de “adornos” que complementam a informação: - O nome - O papel de cada participante - A multiplicidade - O tipo de agregação Podem ainda incluir os menos comuns navegação, visibilidade e qualificação Multiplicidade Traduz o nº de instâncias de uma classe que se podem relacionar com uma única instância da outra. muitos (*); um ou mais (1..*), exactamente 1 (1), zero ou um (0..1), determinado nº (3), determinada gama (2..6) ou listas (0..3,5..7,10..*) Navegação Traduz a forma como a partir de uma instância de uma classe se pode aceder a uma ou mais instâncias de outra classe relacionada pela associação. Por omissão é bidireccional. Mas pode interessar ser unidireccional (ex: utilizador e password). Agregação (Simples) Traduz que existe uma relação do tipo “is-part-of” ou “has-a”, isto é, uma instância de uma dada classe possuir ou ser composta por várias instâncias de outra classe. O adorno é um losango junto do elemento agregador ou “o todo”. Ex: PC e CPU, teclado, ... Composição (Agregação Composta) É uma variante da anterior, em que é adicionada a seguinte semântica: (1) forte pertença do “todo” em relação à “parte” (2) tempo de vida delimitado (as partes não podem existir sem o todo) O adorno é um losango a cheio. Ex. Empresa e Departamentos Associações Qualificadas Um qualificador é um atributo (da associação), ou lista de atributos, cujos valores servem para partir o conjunto de instâncias associadas a uma instância ao longo de uma associação. É representado por pequeno rectângulo junto do extremo de uma associação. É colocado no extremo da classe origem da associação. Uma instância da classe de origem, conjuntamente com um valor do qualificador, permite seleccionar univocamente um subconjunto das instâncias da classe destino. A multiplicidade afecta o extremo destino. Os valores comuns são: 0..1 1 * . Ex. Banco (qualificador – nº conta) e Pessoa; Tabuleiro Xadrez – linha/coluna --> Quadrado. Associações Reflexivas

Quando estabelece uma relação estrutural consigo própria. Acontece quando uma classe tem objectos que desempenham diferentes papéis. ex. ocupante do carro : condutor e passageiro. Classes-Associação A associação pode também ter os seus próprios atributos (e eventualmente operações), devendo por conseguinte ser modelada também como uma classe. Ex. classe-associação Tarefa que é traduzida da associação entre pessoa e empresa. Representa-se por linha a tracejado a ligá-la à linha da associação. Associações N-Árias (N>=3) São pouco comuns, mas às vezes proporcionam melhor clareza. Esta associação é representada por losango com linhas para todas as classes participantes. A multipliciade é mais complexa e representa o número de tuplos (instâncias) numa associação quando os outros N-1 valores são fixos. Ex: Tarefa (Pessoa – Empresa – Tipo Tarefa). Podem ser decompostas em binárias através de estereótipos ou anotações. 6.4. Interfaces É um contrato na forma de uma colecção de especificações de métodos que providencia um mecanismo para separação clara entre a vista externa e a interna de um determinado elemento. É realizada ou implementada por uma ou mais classes. Este conceito apresenta os seguintes benefícios ao nível de programação: - Captura de semelhanças entre classes não relacionadas - Declaração de métodos que uma ou mais classes esperam implementar - Um objecto pode ser visto de diferentes perspectivas (diferentes tipos) consoante as circunstâncias. Representação Gráfica Como uma classe mas com o estereótipo «interface». Alternativamente pode ser um círculo. Relações Entre Interfaces, Classes e Componentes Tal como nas classes, uma interface pode participar em relações do tipo generalização, associação, e dependência. Adicionalmente pode participar em relações do tipo realização. Uma relação de realização estabelece-se entre uma interface e uma classe ou entre uma interface e um componente. Pode representar-se na forma compacta ou expandida. Em função do acesso ao componente (ou à classe), assim são providenciadas diferentes funcionalidades. Fundamental no desenvolvimento de software em componentes porque podemos evoluir o componente desde que continue a suportar os mesmos interfaces antigos. 6.5. Instâncias e Objectos Uma instância é uma manifestação concreta de uma abstracção, à qual um conjunto de operações pode ser aplicado, e que tem um estado que regista os efeitos das operações realizadas. Objecto não é bem a mesma coisa que instância (+ geral). Um objecto é uma instância de uma classe, herdando todos os atributos e métodos definidos na própria classe e possuindo uma representação de execução própria, a qual se pode designar genericamente por estado, bem como uma identificação única no contexto da execução. Também é representado por rectângulo com 1,2 ou 3 secções. São, contudo, sublinhados no nome e sufixados pelo nome das classes respectivas: Nome-do-objecto : Nome-da-classe Operações Os objectos podem efectuar operações definidas nas suas classes. ex: fac.CalculaIvaTotal() Estado O estado de um objecto é dado pelos valores assumidos pelo conjunto de atributos de um objecto. É dinâmico e até pode ser associado a máquina de estados.

termo:Termo

ar:Docente

[em discussão]

nome = “Abel Rodrigues” id:NIF = 123456789 t: TipoDocente = “PCA”

Objectos Activos Ex. são Processos, fluxos de execução, agentes de software e aplicações, que apresentam uma visão da dinâmica de um sistema. Têm a particularidade de terem controlo sobre o seu próprio fluxo de execução. Representam-se com linhas de maior espessura. Objectos Compostos É constituído por outros (sub)objectos. Em geral reflectem relações de agregação. São representados como objectos normais, com a excepção dos seus atributos serem substituídos por outros objectos, usando sublinhado ou através de uma representação gráfica. A vantagem é de maior clareza e simplicidade dos diagramas produzidos. 6.6. Diagramas de Classes e Diagramas de Objectos DC – ilustra um conjunto de classes, interfaces, colaborações e respectivas relações, em geral de dependências, generalizações e de associação. São compostos para modelar a estrutura de um sistema. São também designados por “vista do desenho estático do sistema” e são usados tipicamente em 3 situações: - Modelar o vocabulário do sistema - modelar colaborações simples - modelar o desenho de um esquema de uma base de dados DO – ilustra um conjunto de objectos e respectivas relações num determinado momento. Permite captar “fotografia” do sistema. 6.7. Exemplos e Recomendações Ex. 6.1. Diagrama de Classes/Objectos do Sistema de Gestão de Automóveis

0..1 Pessoa

*

0..1 Veiculo modelo matrícula cor

1 Motor numero cilindrada combustível

CAP. 7 – UML – MODELAÇÃO DO COMPORTAMENTO 7.1. Introdução Em qualquer sistema minimamente interessante, os objectos não estão estáticos, mas interagem entre si por troca de mensagens. A modelação do comportamento de um sistema de software consiste em 2 tipos distintos de especificações: - Modelação do comportamento interobjectos (diagramas de interacção) - Modelação do comportamento intra-objecto, ou seja na identificação dos estados em que o objecto pode estar ao longo do seu ciclo de vida, dos eventos envolvidos, ebm como dos seus algoritmos (diagramas de estados e actividades) O UML providencia os seguintes elementos, que permitem a especificação do comportamento dum sistema: - objectos - interacções - mensagens - estados - eventos - sinais - actividades 7.2. Interacções É a especificação do comportamento de um conjunto de instâncias, representado pela sua troca de mensagens, num determinado contexto, e com vista à concretização de um objectivo. As interacções são usadas para modelar o fluxo de controlo de uma operação, classe, componente, caso de utilização ou sistema na sua globalidade. Sempre que existe uma ligação (link) entre instâncias, pode ocorrer uma ou mais interacções. Uma mensagem define uma comunicação particular entre instâncias. Expls de comunicações: - invocar uma operação; - lançar um sinal; - construir ou destruir uma instância A mensagem especifica não só o tipo de comunicação mas também os papéis do emissor e do receptor, a acção lançada e o papel da ligação. 7.2.1. Objectos e Ligações Os diagramas de interacção podem ser considerados uma extensão dos diagramas de objectos. Uma ligação (link) entre objectos traduz a existência de uma relação semântica ou estrutural entre as suas respectivas classes. Ligação representa-se por linha a cheio, não dirigida. 7.2.2 Mensagens e Estímulos Um estímulo é uma comunicação entre 2 objectos que veicula informação com a expectativa que determinada actividade seja realizada. Ex. invocação de uma operação, envio de um sinal, criação ou destruição de instância. Uma mensagem é a especificação de um estímulo, ou seja, especifica os papéis que os objectos emissor e receptor devem acordar para que uma acção seja realizada. 7.2.3. Representação de Mensagens Um estímulo é representado por uma linha sólida dirigida. Há variantes para ilustrar diferentes tipos de comunicação: - Simples – Fluxo de controlo simples. Cada seta mostra o próximo passo numa determinada sequência. Usa-se quando não é relevante mostrar o tipo de comunicação. _____________> - Síncrona – Invocação de método ou outro fluxo de controlo, dentro do fluxo corrente. Pode ser usado em situações normais de invocação de operações. Também entre objectos activos concorrentes, quando invoca um sinal e espera que o comportamento destino termine. ________seta a cheio - Assíncrona – alternativa à simples, numa sequência procedimental ___________meia seta - Retorno – retorno de uma invocação de método tomada de decisão, fork, joint - Especificar workflows ou processos de negócio: Identificação dos actores e correspondente colaboração com o sistema --> pistas e modelação dos fluxos de objectos. Ex. 7.5 DA da operação de Fibonacci; 7.6 Da da disseminação de eventos no WebDEI

CAP. 8 – UML – MODELAÇÃO DA ARQUITECTURA 8.1. Introdução É a aparte mais limitada, mal explorada e compreendida do UML. Os diagramas de arquitectura (ou de implementação) descrevem aspectos da fase de implementação e instalação de um sistema de software, designadamente: - Estrutura e dependências de código fonte e de módulos executáveis - Respectiva instalação nas diferentes plataformas computacionais subjacentes. Apresentam-se em 2 formas: - Diagramas de Componentes - Diagramas de Instalação Os 1ºs são usados na perspectiva dos seus componentes digitais, explicitando principalmente as suas múltiplas dependências. Os 2ºs são usados na perspectiva dos seus componentes físicos, explicitando as suas dependências de comunicação. Permitem ainda identificar quais são os componentes instalados em cada nó computacional. 8.2. Componentes e Nós Um componente é uma peça básica na implementação de um sistema. ex. ficheiros de código (fonte, binário ou executável) ou ficheiros de documentos relativos ao negócio. Há 3 tipos distintos: - Componentes de Instalação: Base dos sistemas executáveis (DLL, executáveis, controlos ActiveX, classes Java) - Componentes de Trabalho: Ficheiros de código fonte, de dados, documentos. São a base dos de instalação - Componentes de Execução: criados como resultado da execução dum sistema (processos, Threads, agentes de software)