Arquitetura de Aplicações em 2, 3, 4 ou N camadas

Transcrição

1 Arquitetura de Aplicações em 2, 3, 4 ou N camadas Fiz uma compilação de partes de textos e iremos aqui discutir cada um dos conceitos, mostrando as vantagens e desvantagens de aplicações em cada quantidade de camadas existentes, ou seja, toda sua evolução. Modelo Cliente/Servidor Cliente-servidor é um modelo computacional que separa clientes e servidores, sendo interligados entre si geralmente utilizando-se uma rede de computadores. Cada instância de um cliente pode enviar requisições de dado para algum dos servidores conectados e esperar pela resposta. Por sua vez, algum dos servidores disponíveis pode aceitar tais requisições, processá-las e retornar o resultado para o cliente. Apesar do conceito ser aplicado em diversos usos e aplicações, a arquitetura é praticamente a mesma. O modelo Cliente/Servidor, foi criado tendo como base a descentralização dos dados e recursos de processamento, em oposição ao modelo Centralizado utilizado na época em que o Mainframe dominava absoluto. No modelo Cliente/Servidor, conforme indicado pela figura abaixo, em uma rede de computadores, existem uma ou mais máquinas que atuam como Servidores, disponibilizando recursos para as demais máquinas, as quais atuam como Clientes. A máquina servidor é um host que está executando um ou mais programas de servidor que partilham os seus recursos com os clientes. Um cliente não compartilha de seus recursos, mas solicita o

2 conteúdo de um servidor ou função de serviço. Os clientes, portanto, iniciam sessões de comunicação com os servidores que esperam as solicitações de entrada. Modelo Cliente-Servidor Conforme pode ser visto na figura, temos Servidores para Arquivos, Banco de dados e outras funções, tais como: Servidores de impressão, Servidores Web, etc. Estas redes, tipicamente, são formadas por Servidores, os quais são equipamentos com um maior poder de processamento e armazenamento do que os clientes, os quais, na maioria dos casos, são Microcomputadores ligados em rede. Aplicações em 2 Camadas No início da utilização do modelo Cliente/Servidor, as aplicações foram desenvolvidas utilizando-se um modelo de desenvolvimento em duas camadas. Neste modelo, um programa, normalmente desenvolvido em um ambiente de desenvolvimento, como o Visual Basic, Delphi ou Power Builder, é instalado em cada Cliente. Este programa acessa dados em um servidor de Banco de dados, conforme ilustrado na figura abaixo:

3 2 Camadas No modelo de duas camadas, temos um programa que é instalado no Cliente, programa esse que faz acesso a um Banco de dados que fica residente no Servidor de Banco de dados. Na maioria dos casos, a máquina do Cliente é um PC rodando Windows, e a aplicação Cliente é desenvolvida utilizando-se um dos ambientes conhecidos, conforme citado anteriormente. Sendo a aplicação Cliente, um programa para Windows (na grande maioria dos casos), esta deve ser instalada em cada um dos computadores da rede, que farão uso da aplicação. É o processo de instalação normal, para qualquer aplicação Windows. No modelo de 2 camadas, a aplicação Cliente é responsável pelas seguintes funções: Apresentação: O Código que gera a Interface visível do programa, que é utilizada pelo usuário para acessar a aplicação, faz parte da aplicação Cliente. Todos os formulários, menus e demais elementos visuais, estão contidos no código da aplicação Cliente. Caso sejam necessárias alterações na interface do programa, faz-se necessária a geração de uma nova versão do programa, e todos os computadores que possuem a versão anterior, devem receber a nova versão, para que o usuário possa ter acesso as alterações da interface. Aí que começam a surgir os problemas no modelo de 2 camadas: Uma simples alteração de interface, é suficiente para gerar a necessidade de atualizar a aplicação, em centenas ou

4 milhares de computadores. O gerenciamento desta tarefa, é algo extremamente complexo e de custo elevado. Lógica do Negócio: Aqui estão as regras que definem a maneira como os dados serão acessados e processados, as quais são conhecidas como Lógica do Negócio. Fazem parte das Regras do Negócio, desde funções simples de validação da entrada de dados, como o cálculo do digito verificador de um CPF, até funções mais complexas, como descontos escalonados para os maiores clientes, de acordo com o volume da compra. Questões relativas a legislação fiscal e escrita contábil, também fazem parte da Lógica do Negócio. Por exemplo, um programa para gerência de Recursos Humanos, desenvolvido para a legislação dos EUA, não pode ser utilizado, sem modificações, por uma empresa brasileira.. Alterações nas regras do negócio são bastante freqüentes, ainda mais com as repetidas mudanças na legislação do nosso país. Com isso, faz-se necessária a geração de uma nova versão do programa, cada vez que uma determinada regra muda, ou quando regras forem acrescentadas ou retiradas. Desta forma, todos os computadores que possuem a versão anterior, devem receber a nova versão, para que o usuário possa ter acesso as alterações. Mais problemas com o modelo de 2 camadas: Qualquer alteração nas regras do negócio, é suficiente para gerar a necessidade de atualizar a aplicação, em centenas ou milhares de computadores. O gerenciamento desta tarefa, é algo extremamente complexo e de custo elevado. A outra camada, vem a ser o Banco de dados, o qual fica armazenado em Servidor da rede. Uma aplicação desenvolvida em Visual Basic, a qual acessa um Banco de dados em um servidor Microsoft SQL Server, é um típico exemplo de uma aplicação em 2 camadas. Com a evolução do mercado e as alterações da legislação, mudanças nas regras do negócio são bastante freqüentes. Com isso o modelo de duas camadas, demonstrou-se de difícil

5 manutenção e gerenciamento, além de apresentar um custo de propriedade muito elevado. Isto sem contar com o problema conhecido como DLL Hell (Inferno das DLLs), onde diferentes aplicativos, instalam diferentes versões da mesma DLL e um conflito é gerado. É o caso típico onde a instalação de um programa, faz com que um ou mais programas, instalados anteriormente, deixem de funcionar. Em resumo, como diria um famoso comediante: Uma verdadeira visão do Inferno. Inferno para o usuário, que não tem os programas funcionando como deveriam; inferno para a equipe de desenvolvimento que não tem o seu trabalho reconhecido e, normalmente, tem que trabalhar apenas apagando incêndios ; e inferno para a Administração/Gerência da rede que não consegue gerar os resultados esperados pela Administração da empresa, apesar dos elevados valores já investidos. Resumindo: Sistemas em camadas surgiram para: Melhor aproveitar os PCs da empresa Oferecer sistemas com interfaces gráficas amigáveis Em Integrar o desktop e os dados corporativos outras palavras, permitiram aumentar a escalabilidade de uso de Sistemas de Informação Os primeiros sistemas cliente-servidor eram de duas camadas Camada cliente trata da lógica de negócio e da UI Camada servidor trata dos dados (usando um SGBD) Pode parecer difícil de acreditar, mas um grande número de empresas ainda tem a maioria dos seus aplicativos baseados no

6 modelo Cliente/Servidor de 2 camadas. Em busca de soluções para os problemas do modelo de duas camadas, é que surge a proposta do modelo de 3 camadas. Aplicações em 3 Camadas Modelo em três camadas, derivado do modelo n camadas, recebe esta denominação quando um sistema cliente-servidor é desenvolvido retirando-se a camada de negócio do lado docliente. O desenvolvimento é mais demorado no início comparando-se com o modelo em duas camadas pois é necessário dar suporte a uma maior quantidade de plataformas e ambientes diferentes. Em contrapartida, o retorno vem em forma de respostas mais rápidas nas requisições, excelente performance tanto em sistemas que rodam na Internet ou em intranet e mais controle no crescimento do sistema. Como uma evolução do modelo de 2 camadas, surge, com o crescimento da Internet, o modelo de três camadas. A idéia básica do modelo de 3 camadas, é retirar as Regras do Negócio do cliente e centralizá-las em um determinado ponto, o qual é chamado de Servidor de Aplicações. O acesso ao Banco de dados é feito através das regras contidas no Servidor de Aplicações. Ao centralizar as Regras do Negócio em um único ponto, fica muito mais fácil a atualização destas regras. A figura, nos dá uma idéia geral do modelo em 3 camadas:

7 3 Camadas Todo o acesso do cliente ao Banco de dados, é feito de acordo com as regras contidas no Servidor de aplicações. O cliente não tem acesso direto ao Banco de dados, sem antes passar pelo servidor de aplicações. Com isso as três camadas são as seguintes: Apresentação: Continua no programa instalado no cliente. Alterações na Interface do programa, geram a necessidade de atualizar a aplicação em todos os computadores, onde esta está sendo utilizada. Porém cabe ressaltar, que alterações na interface, são menos freqüentes do que alterações nas regras do negócio. Lógica: São as regras do negócio, as quais determinam de que maneira os dados serão utilizados. Esta camada foi deslocada para o Servidor de aplicações. Desta maneira, quando uma regra do negócio for alterada, basta atualizá-la no Servidor de aplicações. Após a atualização, todos os usuários passarão a ter acesso a nova versão, sem que seja necessário reinstalar o programa em cada um dos computadores da rede. Vejam que ao centralizar as regras do negócio em um Servidor de aplicações, estamos facilitando a tarefa de manter a aplicação atualizada. Dados: Nesta camada temos o servidor de Banco de dados, no qual reside toda a informação necessária para o funcionamento da aplicação. Cabe ressaltar, novamente, que os dados somente são acessados através do Servidor de aplicação, e não diretamente pela aplicação Cliente. Resumindo: A arquitetura cliente/servidor em 2 camadas sofria de vários problemas: Falta de escalabilidade (conexões a bancos de dados) Enormes problemas de manutenção (mudanças na

8 lógica de aplicação forçava instalações) Dificuldade de acessar fontes heterogêneas (legado CICS, 3270, ) Inventou-se a arquitetura em 3 camadas Camada de apresentação (UI) Camada de aplicação (business logic) Camada de dados Problemas de manutenção foram reduzidos, pois mudanças às camadas de aplicação e de dados não necessitam de novas instalações no desktop Observe que as camadas são lógicas: Fisicamente, várias camadas podem executar na mesma máquina Quase sempre, há separação física de máquinas Com a introdução da camada de Lógica, resolvemos o problema de termos que atualizar a aplicação, em centenas ou milhares de computadores, cada vez que uma regra do negócio for alterada. Porém continuamos com o problema de atualização da aplicação, cada vez que forem necessárias mudanças na Interface. Por isso que surgiram os modelos de n-camadas. Agora vamos falar um pouco sobre o modelo de 4 camadas. Aplicações em 4 Camadas (Web Based) Como uma evolução do modelo de três camadas, surge o modelo de quatro camadas. A idéia básica do modelo de 4 camadas, é retirar a apresentação do cliente e centralizá-las em um determinado ponto, o qual na maioria dos casos é um servidor Web. Com isso o próprio Cliente deixa de existir como um programa que precisa ser instalado em cada computador da rede. O acesso a aplicação, é feito através de um Navegador, como o Internet Explorer ou o Netscape Navigator. A figura nos dá uma idéia geral do modelo em quatro camadas:

9 4 Camadas Para acessar a aplicação, o cliente acessa o endereço da aplicação, utilizando o seu navegador. Por exemplo Todo o acesso do cliente ao Banco de dados, é feito de acordo com as regras contidas no Servidor de aplicações. O cliente não tem acesso direto ao Banco de dados, sem antes passar pelo servidor de aplicações. Com isso as quatro camadas são as seguintes: Cliente: Nesta caso o Cliente é o Navegador utilizado pelo usuário, quer seja o Internet Explorer, quer seja o Netscape Navigator, ou outro Navegador qualquer. Apresentação: Passa para o Servidor Web. A interface pode ser composta de páginas HTML, ASP, ou qualquer outra tecnologia capaz de gerar conteúdo para o Navegador. Com isso alterações na interface da aplicação, são feitas diretamente no servidor Web, sendo que estas alterações estarão, automaticamente, disponíveis para todos os Clientes. Com isso não existe a necessidade de reinstalar a aplicação em todos os computadores da rede cada vez que uma alteração for feita na camada de apresentação. Fica muito mais fácil garantir que todos estão acessando a versão mais atualizada da aplicação. A única coisa que o cliente precisa ter instalado na sua máquina, é o Navegador. O

10 acesso ao Banco de dados, é feito através do Servidor de aplicações. Lógica: São as regras do negócio, as quais determinam de que maneira os dados serão utilizados. Esta camada está no Servidor de aplicações. Desta maneira, quando uma regra do negócio for alterada, basta atualizá-la no Servidor de aplicações. Após a atualização, todos os usuários passarão a ter acesso a nova versão, sem que seja necessário reinstalar o programa em cada um dos computadores da rede. Vejam que ao centralizar as regras do negócio em um Servidor de aplicações, estamos facilitando a tarefa de manter a aplicação atualizada. Dados: Nesta camada temos o servidor de Banco de dados, no qual reside toda a informação necessária para o funcionamento da aplicação. Com o deslocamento da camada de apresentação para um Servidor Web, resolvemos o problema de termos que atualizar a aplicação, em centenas ou milhares de computadores, cada vez que a interface for alterada. Neste ponto a atualização das aplicações é uma tarefa mais gerenciável, muito diferente do que acontecia no caso do modelo em duas camadas. Os servidores de Aplicação, servidor Web e servidor de Banco de dados, não precisam, necessariamente, ser servidores separados, isto é, uma máquina para fazer o papel de cada um dos servidores. O conceito de servidor de Aplicação, Web ou Banco de dados, é um conceito relacionado com a função que o servidor desempenha. Podemos ter, em um mesmo equipamento, um Servidor de aplicações, um servidor Web e um servidor de Banco de dados. Claro que questões de desempenho devem ser levadas em consideração. Resumindo: A arquitetura em 3 camadas original sofre de problemas: A instalação inicial dos programas no desktop é cara

11 O problema de manutenção ainda persiste quando há mudanças à camada de apresentação Não se pode instalar software facilmente num desktop que não está sob seu controle administrativo Em máquinas de parceiros Em máquinas de fornecedores Em máquinas de grandes clientes Em máquinas na Internet Então, usamos o Browser como Cliente Universal Conceito de Intranet A camada de aplicação se quebra em duas: Web e Aplicação Evitamos instalar qualquer software no desktop e portanto, problemas de manutenção Evitar instalação em computadores de clientes, parceiros, fornecedores, etc. Às vezes, continua-se a chamar isso de 3 camadas porque as camadas Web e Aplicação freqüentemente rodam na mesma máquina (para pequenos volumes) Arquitetura em N Camadas Os problemas remanescentes: Não há suporte a Thin Clients (PDA, celulares, smart cards, quiosques, ) pois preciso usar um browser (pesado) no cliente Dificuldade de criar software reutilizável: cadê a componentização? Fazer aplicações distribuídas multicamadas é difícil. Tem que: Implementar persistência (impedance mismatch entre o mundo OO e o mundo dos BDs relacionais) Implementar tolerância a falhas com failover

12 Implementar gerência de transações distribuídas Implementar balanceamento de carga Implementar resource pooling etc. As empresas não querem contratar PhDs para implementar sistemas de informação! O truque é introduzir middleware num servidor de aplicação que ofereça esses serviços automaticamente Além do mais, as soluções oferecidas (J2EE,.Net) são baseadas em componentes As camadas podem ter vários nomes: Apresentação, interface, cliente Web Aplicação, Business Dados, Enterprise Information System (EIS) N Camadas Fontes:

13 m Mapa Mental de UML Diagramas, Fases e Detalhes Resolvi juntar os mapas mentais que encontrei sobre UML nesse post para ficar mais fácil. Quem tiver mais e quiser contribuir com a coleção, fique a vontade para me enviar. Diagramas de Estrutura Diagramas de Comportamento Fases do UML Detalhes dos Diagramas

14 UML - Diagramas Estruturais UML - Diagramas de Comportamento

15 UML - Fases UML - Detalhes dos Diagramas

16 Introdução diagramas a UML e seus A Unified Modelling Language (UML) é uma linguagem ou notação de diagramas para especificar, visualizar e documentar modelos de software orientados por objetos. O UML não é um método de desenvolvimento, o que significa que não lhe diz o que fazer primeiro ou o que fazer depois ou como desenhar o seu sistema, mas ajuda-o a visualizar o seu desenho e a comunicar com os outros. O UML é controlado pelo Object Management Group (OMG) e é a norma da indústria para descrever graficamente o software. O UML está desenhado para o desenho de software orientado por objetos e tem uma utilização limitada para outros paradigmas de programação. A UML é composta por muitos elementos de modelo que representam as diferentes partes de um sistema de software. Os elementos UML são usados para criar diagramas, que representam um determinada parte, ou um ponto de vista do sistema. Objetivos Os objetivos da UML são: especificação, documentação, estruturação para sub-visualização e maior visualização lógica do desenvolvimento completo de um sistema de informação. A UML é um modo de padronizar as formas de modelagem. Para que usar UML? Ajudar a conceber nossas idéias, em relação ao sistema que estivermos projetando Pensar antes de codificar; Apresentar nossas idéias ao grupo de forma que todos possam interagir e discutir um determinado ponto

17 Aumentar a participação e envolvimento do time; Documentar nossas idéias quando elas já estiverem bem consolidadas para que novos integrantes e novos colaboradores possam acelerar sua compreensão dos sistemas desenvolvidos pelo grupo; Tipos de Diagramas Diagramas servem para capturar diferentes visões do sistema: Estrutural: estática Diagrama Diagrama Diagrama Diagrama de de de de Classes Objetos Componentes Implantação Comportamental: dinâmica Diagrama Diagrama Diagrama Diagrama Diagrama de de de de de Casos de Uso Seqüência Atividades Estados Colaboração Diagramas Estáticos Diagrama de Classes Diagramas de classe mostram as diferentes classes que fazem um sistema e como elas se relacionam. Os diagramas de classe são chamados diagramas estáticos porque mostram as classes, com seus métodos e atributos bem como os relacionamentos estáticos entre elas: quais classes conhecem quais classes ou quais classes são parte de outras classes, mas não mostram a troca de mensagens entre elas.

18 Na UML, atributos são mostrados com pelo menos seu nome, e podem também mostrar seu tipo, valor inicial e outras propriedades. Atributos podem também ser exibidos com sua visibilidade: + indica atributos ou métodos públicos (significa que ele pode ser acessado de qualquer lugar da classe ou sub-classe); # indica atributos ou métodos protegidos (significa que ele só pode ser acessado de dentro da própria classe ou em suas classes-filha); indica atributos ou métodos privados (significa que ele só pode ser acessado de dentro da própria classe.); ~ pacote. As operações também são exibidas com pelo menos seu nome, e podem também mostrar seus parâmetros e valores de retorno. Uma observação a ser feita é que quando se tem um atributo ou método estáticos, eles irão aparecer sublinhados no diagrama. Já os métodos abstratos irão aparecer em itálico. Classes podem ter modelos, um valor que é usado para uma classe ou tipo não especificado. O tipo de modelo é especificado quando uma classe é iniciada (isto é um objeto é criado). Modelos existem no C ++ moderno e foram introduzidos no Java 1.5 onde eles são chamados de genéricos. Existem alguns tipos de relacionamentos no diagrama de classes que veremos abaixo:

19 Generalização A herança é um dos conceitos fundamentais da programação orientada por objetos, nos quais uma classe ganha todos os atributos e operações da classe que herda, podendo sobrepor ou modificar algumas delas, assim como adicionar mais atributos ou operações próprias. EM UML, uma associação Generalização entre duas classes colocaas numa hierarquia representando o conceito de herança de uma classe derivada de uma classe base. Em UML, Generalizações são representadas por uma linha conectando duas classes, com uma seta no lado da classe base. Generalização Associação Um associação representa um relacionamento entre classes, e fornece a semântica comum e a estrutura para muitos tipos de conexões entre objetos.

20 Associações são o mecanismo que permite objetos comunicarem-se entre si. Elas descrevem a conexão entre diferentes classes (a conexão entre os objetos atuais é chamada conexão do objeto, ou link. Associações podem ter um regra que especifica o propósito da associação e pode ser uni ou bidirecional (indicando se os dois objetos participantes do relacionamento podem mandar mensagens para o outro, ou se apenas um deles sabe sobre o outro). Cada ponta da associação também possui uma valor de multiplicidade, que dita como muitos objetos neste lado da associação pode relacionar-se com o outro lado. Em UML, associações são representadas como linhas conectando as classes participantes do relacionamento, e podem também mostrar a regra e a multiplicidade de cada um dos participantes. A multiplicidade é exibida como um intervalo [min máx] de valores não negativos, com uma estrela (*) no lado máximo representando infinito. Associação Agregação Agregações são um tipo especial de associação no qual as duas classes participantes não possuem em nível igual, mas fazem um relacionamento todo-parte. Uma Agregação descreve como a classe que possui a regra do todo, é composta (tem) de outras classes, que possuem a regra das partes. Para Agregações, a classe que age como o todo sempre tem uma multiplicidade de um. Em UML, Agregações são representadas por uma associação que

21 mostra um romboide no lado do todo. Agregação Composição Composições são associações que representam agregações muito fortes. Isto significa que Composições formam relacionamentos todo-parte também, mas o relacionamento é tão forte que as partes não pode existir independentes. Elas existem somente dentro do todo, e se o todo é destruído as partes morrem também. Em UML, Composições são representadas por um romboide sólido no lado do todo. Composição Interfaces Interfaces são classes abstratas que significam instâncias que não podem ser diretamente criadas delas. Elas podem conter operações mas não podem conter atributos. Classes podem derivar de interfaces (através da realização de uma associação) e instâncias podem então ser feitas destes diagramas. Tipos de Dados Tipos de dados são primitivos uma vez que são tipicamente construídos numa linguagem de programação. Exemplos comuns são inteiros e lógicos. Eles não podem ser relacionados à classes mas classes pode se relacionar com eles. Enumerações

22 Enumerações são uma lista simples de valores. Um exemplo típico é uma enumeração para dias da semana. As opções de uma enumeração são chamadas Literais de Enumeração. Como tipos de dados, elas não podem ter relacionamentos para classes mas classes podem relacionar-se com elas. Pacotes Pacotes representam um espaço de nomes numa linguagem de programação. Num diagrama eles são usados para representar partes de um sistema que contém mais de uma classe, talvez centenas de classes. 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 duas 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(passou a se chamar comunicação na uml 2.0), onde a colaboração dinâmica entre os objetos do sistema são mostrados.

23 Diagrama de Objetos Diagrama de Componentes Diagramas de componente mostram os componentes do software (sejam componentes de tecnologias como KParts, componentes CORBA ou Java Beans ou apenas seções do sistema que são claramente distintas) e os artefatos de que eles são feitos como arquivos de código-fonte, bibliotecas de programação ou tabelas de bancos de dados relacionais. Componentes podem possui interfaces (isto é classes abstratas com operações) que permitem associações entre componentes.

24 Diagrama de Componentes Diagrama de Implantação O Diagrama de instalação/implantação é definido pela Linguagem de Modelagem Unificada (Unified Modeling Language UML), descreve os componentes de hardware e software e sua interação com outros elementos de suporte ao processamento. Representa a configuração e a arquitetura de um sistema em que estarão ligados seus respectivos componentes, sendo representado pela arquitetura física de hardware, processadores etc. Nó: Representa uma peça física de equipamento na qual o sistema será implantado. Artefatos: Qualquer pedaço físico de informação usada ou produzida por um sistema. Especificação de implantação: Especifica um conjunto de propriedades que determina os parâmetros de execução de um artefato que está instalado em um nó.

25 Diagrama de Implantação Diagramas Dinâmicos Diagrama de Casos de Uso Diagramas de Caso de Uso descrevem relacionamentos e dependências entre um grupo de Caso de Uso e os Atores participantes no processo. É importante observar que Diagramas de Caso de Uso não são adequados para representar o desenho, e não podem descrever os mecanismos internos de um sistema. Diagramas de Caso de Uso são feitos para facilitar a comunicação com os futuros usuários do sistema, e com o cliente, e são especialmente úteis para determinar os recursos necessários que o sistema deve ter. Diagramas de Caso de Uso dizem o quê o sistema deve fazer, mas não fazem e não podem especificar como isto será conseguido. Um Caso de Uso descreve do ponto de vista dos atores um grupo de atividades num sistema que produz um resultado concreto e tangível. Casos de Uso são descrições de interações típicas entre os

26 usuários de um sistema e o sistema propriamente dito. Eles representam a interface externa do sistema e especificam um conjunto de exigências do que o sistema deve fazer (lembre-se: somente o quê, não como). Quando trabalhar com Casos de Uso, é importante lembrar-se de algumas regras simples Cada Caso de Uso está relacionado com no mínimo um ator; Cada Caso de Uso possui um iniciador (isto é um ator); Cada Caso de Uso liga-se a um resultado relevante (um resultado com valor de negócio ). Casos de Uso também podem ter relacionamentos com outros Casos de Uso. Os três tipos mais comuns de relacionamento entre Casos de Uso são: <<inclui-se>> que especifica que um Caso de Uso toma lugar dentro de outro Caso de Uso <<estende>> que especifica que em determinadas situações, ou em algum ponto (chamado um ponto de extensão) um Caso de Uso será estendido por outro. Generalização especifica que um Caso de Uso herda as características do Super Caso de Uso, e pode sobrepor algumas delas ou adicionar novas de maneira semelhante a herança entre classes. Ator Um ator é uma entidade externa (fora do sistema) que interage com o sistema participando (e frequentemente iniciando) um Caso de Uso. Atores podem ser pessoas reais (por exemplo usuários do sistema), outro sistema de computador ou eventos externos. Atores não representam as pessoa física ou sistemas, mas sua regra. Isto significa que quando uma pessoa interage com o sistema de diferentes maneiras (assumindo diferentes regras)

27 ela será representada por diversos atores. Por exemplo um pessoa que fornece suporte ao cliente por telefone e recebe ordens do cliente para o sistema pode ser representado por um ator da Equipe de Suporte e um ator Representante de Vendas Descrição do Caso de Uso Descrição do Caso de Uso são narrativas de texto do Caso de Uso. Elas usualmente tomam a forma de uma nota ou um documento que é de alguma maneira ligado ao Caso de Uso, e explana o processo ou atividades que tomarão lugar no Caso de Uso. Caso de Uso Diagrama de Sequência É usado para mostrar uma seqüência de atividades. Mostra o fluxo de trabalho (workflow) a partir de um ponto inicial até um ponto final, detalhando as decisões do caminho tomado durante a execução das tarefas. Este diagrama possui várias aplicações, desde a definição do fluxo básico de um programa

28 até a definição de um processo com as suas tomadas de decisões e ações. Diagramas de Sequência mostram a troca de mensagens (isto é chamada de método) entre diversos Objetos, numa situação específica e delimitada no tempo. Objetos são instâncias de classes. Diagramas de Sequência colocam ênfase especial na ordem e nos momentos nos quais mensagens para os objetos são enviadas. Em Diagramas de Sequência objetos são representados através de linhas verticais tracejadas, com o nome do Objeto no topo. O eixo do tempo é também vertical, aumentando para baixo, de modo que as mensagens são enviadas de um Objeto para outro na forma de setas com a operação e os nomes dos parâmetros. Diagrama de Sequência Diagramas de Atividade O Diagrama de Atividade descreve a sequência de atividades num sistema com a ajuda as Atividades. Diagramas de Atividade são uma forma especial de Diagramas de Estado, que somente (ou principalmente) contém Atividades.

29 Os diagramas de modelagem de um fluxograma, executáveis por atividade não são importantes somente para a aspectos dinâmicos de um sistema ou mas também para a construção de sistemas meio de engenharia de produção reversa. Alguns conceitos: Atividades: Comportamento a ser realizado. Sub-atividade: Execução de uma sequência não atómica de atividades. Transição: Fluxo de uma atividade para outra. Ação: Transformação. Decisão: Dependendo de uma condição, mostra as diferentes transições. Raia: Diferenciação de unidades organizacionais. Bifurcação (Fork): Separa uma transição em várias transições executadas ao mesmo tempo. Sincronização (Join): Concatenação de transições vindas do Fork. Objecto: O objecto da atividade. Envio de sinal: Transição pra um meio externo, por exemplo, um hardware. Recepção de sinal: Recepção do envio. Região: Agrupamento de uma ou mais atividades. Exceção: Atividades que ocorrerem em decorrência de uma excepção.

30 Diagrama de Atividades Diagramas de Estado Modela o comportamento de um objeto individual. Especifica as seqüências de estados pelos quais um objeto passa durante seu tempo de vida em resposta a eventos. Diagramas de Estado mostram os diferentes estados de um Objeto durante sua vida, e o estímulo que faz com que o Objeto mude seu estado. Diagramas de Estado veem Objetos como máquinas de estado automatismos finitos que podem ser um de um conjunto estados finitos e que podem mudar seu estado através de um um conjunto finito de estímulos. Por exemplo um tipo ou de de de

31 Objeto ServidorRede pode estar em um dos seguintes estados durante sua vida: Pronto Ouvindo Trabalhando Parado e os eventos que podem fazer com que o Objeto mude de estado são Objeto é criado Objeto recebe mensagem ouvir Um Cliente solicita uma conexão através da rede Um Cliente termina um pedido O pedido é executado e terminado Objeto recebe mensagem parar etc Estado Estados são os blocos construídos dos Diagramas de Estado. Um Estado pertence a exatamente uma classe e representa um resumo dos valores dos atributos que uma classe pode tomar. Um Estado UML descreve o estado interno de um objeto para uma classe em particular Observe que nem toda mudança em um dos atributos de um objeto pode ser representada por um Estado mas somente aquelas mudanças que podem afetar significativamente o trabalho do objeto Existem dois tipos especiais de Estados: Inicial e Final. Eles são especiais porque nenhum evento pode fazer com que um Objeto retorne para seu estado Inicial, e da mesma maneira nenhum evento pode tirar um Objeto de seu estado Final uma vez que ele já o tenha alcançado.

32 Diagrama de Estados Diagramas de Colaboração Diagramas de Colaboração mostram as interações que ocorrem entre os objetos participantes numa situação específica. Isto é mais ou menos a mesma informação mostrada pelos Diagramas de Sequência, mas neste a ênfase é colocada em como as interações ocorrem no tempo, enquanto os Diagramas de Colaboração colocam os relacionamentos entre os objetos e sua topologia em destaque. Em Diagramas de Colaboração as mensagens enviadas de um objeto para outro são representadas por setas, mostrando o nome da mensagem, parâmetros, e a sequência da mensagem. Diagramas de Colaboração são especialmente indicados para mostrar um fluxo ou situação específica do programa e são um dos melhores tipos de diagrama para rapidamente demonstrar ou explanar um processo na lógica do programa.

33 Diagrama de Colaboração Fontes: ics.html#about-uml 02_29.pdf Handbook de TI Modelos de Ciclo de Vida Modelos de ciclo de vida descrevem as etapas do processo de desenvolvimento de sistemas e as atividades a serem realizadas

34 em cada etapa. A definição dessas etapas e atividades possibilitam prover marcos e pontos de controle para avaliação da qualidade e gerência do projeto (Park 91). O estudo do processo de desenvolvimento provocou o surgimento de várias propostas de ciclo de vida que incluem desde o simples modelo artesanal de codificar e consertar (Connors 92), (Pressman 92) até o modelo espiral (Boehm 88). Inicialmente, o desenvolvimento de software era algo feito em pequena escala com equipes pequenas ou, até mesmo, apenas com esforço individual. Neste momento, a ênfase do processo estava na etapa de programação. Neste escopo o desenvolvimento de software caracterizou-se pelo codificar e consertar, também chamado de desenvolvimento artesanal ou ad-hoc, que consiste em se partir diretamente para a codificação, seguida de correção. Esse ciclo é repetido até se completar o projeto (Connors 92). O aumento da complexidade e tamanho dos sistemas gerou algumas propostas de ciclo de vida levando em conta o desenvolvimento de sistemas em grande escala envolvendo grandes equipes. Isto acarretou uma mudança de enfoque com ênfase no desenvolvimento de sistemas e não apenas de programas. O termo modelo do ciclo de vida é utilizado para descrever um modelo que visa descrever um grupo de atividades e a forma como elas se relacionam. Os modelos mais sofisticados incluem ainda uma descrição de quando e como se deve mover de uma actividade para a próxima e os deliverables que devem ser produzidos em cada etapa. A razão pela qual estes modelos são tão conhecidos é o fato de ajudarem as equipes de desenvolvimento, e em particular os gestores, a obter uma visão geral do projecto de forma a ser possível segui-lo passo a passo, saber que deliverables foram especificados, o alocamento de recursos e os objectivos propostos. Estes modelos de ciclo de vida ou modelos de processos são tipicamente produzidos a partir de uma perspectiva de que poderão existir vários modelos para o mesmo processo. Nenhum

35 modelo é capaz de dar uma visão completa de um determinado processo. Cascata É composto por uma sequência de atividades, onde a próxima atividade só inicia quando a atual é finalizada, ou seja, o resultado de uma etapa é utilizado na etapa seguinte. Esse processo tem uma característica por ser guiado por documentos, sendo assim, cada etapa gera uma documentação. Modelo Cascata Vantagens: Fácil de gerenciar: Etapas bem definidas e sem sobreposição; Eficiente em casos nos quais o domínio de aplicação é bem entendido; Eficiente no desenvolvimento de projetos em quais vários sistemas similares foram construídos anteriormente. Desvantagens: Dificuldade de serialização proposta pelo modelo; Em função da dificuldade de se obter todos os requisitos do sistema no início do projeto, geralmente esse

36 processo resulta em um atraso para o início da fase de projeto, cumulativa ao prazo final; Raramente as fases de execução seguem um fluxo tão seqüencial e sem interações, portanto o planejamento não é de qualidade total; Obtenção do produto final apenas no final do projeto, deixando margens de correção menores. Iterativo e Incremental Modelo Iterativo Neste modelo é criado um protótipo do software, geralmente sem um processo formal de desenvolvimento, utilizada para elucidar ou validar os requisitos do produto. Seria basicamente vários ciclos de cascatas em miniatura. Assim você consegue ter um feedback do cliente de forma mais rápida. Existem três tipos de modelos incrementais: 1. E v o l u t i v o s O n d e p r o d u t o s d e c a d a e t a p a d e desenvolvimento são aproveitados em cada nova etapa; 2. Descartáveis Produtos das etapas de desenvolvimento são descartados e cada novo protótipo é construído no início; 3. Operacional Requisitos são elucidados através de protótipos e o produto final é construído paralelamente

37 a construção dos protótipos; Vantagens: Disponibilidade de partes prontas do sistema mais cedo; Facilidade nos testes: Geralmente, testar cada incremento é mais fácil do que testar o software pronto e tudo de uma vez só; Feedback do cliente a cada incremento feito; A aprendizagem do desenvolvedor numa linguagem é favorecida: Pode se optar em resolver as partes mais fáceis antes, enquanto ele aprende a linguagem, e deixar as partes mais complexas do sistema para depois. Desvantagens: A possibilidade de o sistema ser dividido em partes como pré-requisito, já que nem sempre um sistema pode ser dividido; Dificuldade na integração das partes desenvolvidas; Negociação com o cliente a respeito do pagamento do produto de software final pode ser problemática, uma vez que o desenvolvimento em passos incrementais costuma induzir o cliente a acrescentar requisitos e funcionalidades que não estavam previstas no escopo inicial do projeto, o que resulta no encarecimento do desenvolvimento do produto final. Espiral O modelo original em espiral organiza o desenvolvimento como um processo iterativo em que vários conjuntos de fases se sucedem até se obter o sistema final. Um ciclo se inicia com a determinação de objetivos, alternativas e restrições (primeira tarefa) onde ocorre o comprometimento dos envolvidos e o estabelecimento de uma estratégia para alcançar os objetivos. Na segunda tarefa, análise e avaliação de alternativas, identificação e solução de riscos, executa-se uma análise de

38 risco. Prototipação é uma boa ferramenta para tratar riscos. Se o risco for considerado inaceitável, pode parar o projeto. Na terceira tarefa ocorre o desenvolvimento do produto. Neste quadrante pode-se considerar o modelo cascata. Na quarta tarefa o produto é avaliado e se prepara para iniciar um novo ciclo. Modelo Espiral O modelo espiral é, atualmente a abordagem mais realística para desenvolvimento de software em grande escala, e usa uma abordagem que capacita a empresa que presta o serviço, e o cliente a entender e reagir aos riscos em cada etapa evolutiva. Este tipo de modelo exige considerável experiência na determinação de riscos e depende dessa experiência para ter sucesso. Cada ciclo da espiral envolve alguns passos para que o mesmo seja concluído, dentre os quais: Determinar objetivos, alternativas e incertezas; Identificar e resolver riscos;

39 Avaliar as alternativas; Desenvolver os produtos de entrega para aquela interação e verificar seu grau de correção; Planejar a próxima interação. Vantagens: Possibilidade de combinar o modelo espiral com outros modelos de ciclo de vida; Ajuda a aumentar a qualidade pelo planejamento e análise dos riscos em cada fase; Maior visibilidade para a gerência, sobretudo na gerência de riscos. Desvantagens: Gerência de processo mais complexa; Necessidade de maior experiência da equipe de desenvolvimento, sobretudo dos responsáveis pela gerência; Maior experiência da equipe e maior esforço para o desenvolvimento podem aumentar consideravelmente os custos. RAD Rapid application development (RAD), também conhecido como Desenvolvimento Rápido de Aplicação, é um modelo de processo de desenvolvimento de software iterativo e incremental que enfatiza um ciclo de desenvolvimento extremamente curto (entre 60 e 90 dias). O termo foi registrado por James Martin em 1991 e tem substituído gradativamente o termo de prototipação rápida que já foi muito utilizada no passado. Não é exatamente um modelo e se baseia em que um modelo de ciclo de vida formal é ineficiente e muitas revisões e documentações geradas pelos modelos em cascata e em espiral são perda de tempo, a formalidade dificulta a comunicação com

40 o cliente, não há um modelo de ciclo de vida bem definido: há uma seqüência de integrações evolucionárias ou protótipos que são revisados com o cliente (os requisitos são levantados a partir destas iterações). Abrange as seguintes fases: Modelagem do negócio O fluxo de informação entre as funções do negócio é modelado; Modelagem dos dados O fluxo de informação é refinado num conjunto de objetos de dados; Modelagem do processo Os objetos de dados são tranformados para conseguir o fluxo de informação necessário para implementar uma função do negócio. Descrições do processamento são criadas; Geração da aplicação O RAD considera o uso de técnicas de quarta geração. O processo RAD trabalha para reusar componentes de programas existentes ou criar componentes reusáveis; Teste e entrega Os componentes novos devem ser testados e todas as interfaces devem ser exaustivamente exercitadas. Desvantagens: Se uma aplicação não puder ser modularizada de modo que cada função principal seja completada em menos de 3 meses, não é aconselhável o uso do RAD; Para projetos grandes (mas escaláveis) o RAD exige recursos humanos suficientes para criar o número correto de equipes, isso implica em um alto custo com a equipe; O envolvimento com o usuário tem que ser ativo; Comprometimento da equipe do projeto; O RAD não é aconselhável quando os riscos técnicos são altos e não é indicada quando se está testando novas tecnologias ou quando o novo software exige alto grau de interoperabilidade com programas de computador existentes. Falta de prazo pode implicar em qualidade

41 reduzida, e há necessidade de habilidade maior dos desenvolvedores, e suporte maior da gerência e dos clientes. Desenvolver pode economizar recursos se comparado a comprar; Custo do conjunto de ferramentas e hardware para rodar a aplicação; Mais difícil de acompanhar o projeto(pois não existe os marcos clássicos); Menos eficientes; Perda de precisão científica (falta de métodos formais); Pode acidentalmente levar ao retorno das práticas caóticas no desenvolvimento; Funções reduzidas (reuso, timeboxing ); Funções desnecessárias (reuso de componentes); Problemas legais; Requisitos podem não se encaixar (conflitos entre desenvolvedores e clientes); Padronização (aparência diferente entre os módulos e componentes); Sucessos anteriores são difíceis de se reproduzir. Desenvolvimento em Componentes O desenvolvimento baseado em componentes incorpora características de tecnologias orientadas a objetos no modelo espiral. A atividade de engenharia começa com a identificação de classes candidatas. Se a classe existe, ela será reutilizada. Se a classe não existe, ela será desenvolvida nos moldes do paradigma de orientação a objetos. Modelo de Prototipagem O paradigma de prototipagem começa com a definição dos requisitos. Um projeto rápido é realizado e concentra-se na representação daqueles aspectos que ficarão visíveis pelo

42 cliente. O protótipo é criado e avaliado e é ajustado para satisfazer as necessidades do cliente. Prototipagem Idealmente, o protótipo serve como um mecanismo para identificação dos requisitos do software. A prototipagem pode ser problemática, pois o cliente vê o que parece ser uma versão executável do software, ignorando que o protótipo apenas consegue funcionar precariamente. O modelo pode assumir três formas: Um protótipo em papel ou sistema, apresentando apenas a interação usuário-sistema (prototipagem descartável); Um protótipo que implementa algumas funções exigidas pelo sistema; Um protótipo que executa superficialmente todas as funções desejadas pelo sistema, sendo que sofrerá sucessivos refinamentos (prototipagem evolucionária). Fonte: Wikipedia Handbook de TI e-ciclo-de-vida-por-que-precisamos-deles-no-desenvolvimento

43 Levantamento Requisitos e Análise de Na engenharia de sistemas e engenharia de software, análise de requisitos engloba todas as tarefas que lidam com investigação, definição e escopo de novos sistemas ou alterações. Análise de requisitos é uma parte importante do processo de projeto de sistemas, na qual o engenheiro de requisitos e o analista de negócio, juntamente com engenheiro de sistema ou desenvolvedor de software, identificam as necessidades ou requisitos de um cliente. Uma vez que os requisitos do sistema tenham sido identificados, os projetistas de sistemas estarão preparados para projetar a solução. As descrições das funções que um sistema deve incorporar e das restrições que devem ser satisfeitas são os requisitos para o sistema. Isto é, os requisitos de um sistema definem o que o sistema deve fazer e as circunstâncias sob as quais deve operar. Em outras palavras, os requisitos definem os serviços que o sistema deve fornecer e dispõem sobre as restrições à operação do mesmo. Requisitos são, normalmente, classificados em requisitos funcionais e não funcionais.

44 Requisitos funcionais Os requisitos funcionais são aqueles que fazem parte do sistema, como um relatório específico, um campo a mais em um cadastro, etc. Eles normalmente têm a finalidade de agregar valor ao usuário ou facilitar o trabalho que ele desenvolve. Requisitos funcionais serão implementados no próprio sistema e da junção desses requisitos o corpo do sistema será montado. Ou seja, como o próprio nome indica, apontam as funções que o sistema deve fornecer e como o sistema deve se comportar em determinadas situações. Requisitos não-funcionais Requisitos não-funcionais são aqueles relacionados ao ambiente onde o sistema está inserido. Um servidor mais robusto, um firewall, ou um usuário especializado em determinado procedimento pode ser visto como requisitos não-funcionais. Eles não devem ser ignorados por não fazerem parte diretamente do sistemas, mas devem ser considerados por compor o ambiente onde o software irá rodar. Ou seja, descrevem restrições sobre as funções oferecidas, tais como restrições de tempo, de uso de recursos etc. Alguns requisitos não funcionais dizem respeito ao sistema como um todo e não a funcionalidade específica. Dependendo da natureza, os requisitos não funcionais podem ser classificados de diferentes maneiras, tais como requisitos de desempenho, requisitos de portabilidade, requisitos legais, requisitos de conformidade etc. Os processos de engenharia de requisitos variam muito de uma organização para outra, mas, de maneira geral, a maioria dos processos de Engenharia de Requisitos é composta das seguintes atividades: Levantamento (ou Descoberta ou Elicitação) de Requisitos

45 Nesta fase, os usuários, clientes e especialistas de domínio são identificados e trabalham junto com os engenheiros de requisitos para descobrir, articular e entender a organização como um todo, o domínio da aplicação, os processos de negócio específicos, as necessidades que o software deve atender e os problemas e deficiências dos sistemas atuais. Esta etapa é composta por diversas técnicas que visam obter do cliente as informações necessárias para desenvolver o projeto do sistema de informação. Essas técnicas podem ser: Entrevistas não estruturadas: Informal ou sem agenda pré-definida; Entrevistas estruturadas: Com uma agenda pré-definida; Observação do comportamento: Observar os usuários em seu ambiente de trabalho; Aprendizagem com o usuário: Analisa e discute com o usuário a maneira como é feito o trabalho; Prototipagem: Desenvolvimento de um modelo que simulará o sistema real; Brainstorming: Reunião com várias pessoas onde todos discutem um tema central; Análise de textos: O usuário descreve as necessidades textualmente. (técnica muito usada atualmente); Reutilização de requisitos: Reaproveitamento de padrões ou requisitos de outros sistemas. Análise de Requisitos Visa a estabelecer um conjunto acordado de requisitos consistentes e sem ambiguidades, que possa ser usado como base para o desenvolvimento do software. Para tal, diversos tipos de modelos são construídos. Documentação de Requisitos É a atividade de representar os resultados da Engenharia de Requisitos em um documento (ou conjunto de documentos), contendo os requisitos do software.

46 Fonte: luis.blog.br / Wikipédia / Handbook de TI Ciclo de Vida do Software O ciclo de vida de um software descreve as fases pelas quais o software passa desde a sua concepção até ficar sem uso algum. O conceito de ciclo de vida de um software é muitas vezes confundido com o de modelo de processo. Existem várias propostas e denominações para as fases do ciclo de vida de um software. Nossa proposta identifica 4 fases que são delimitadas por eventos típicos em diversos ciclos de vida. Cada fase inclui um conjunto de atividades ou disciplinas que devem ser realizadas pelas partes envolvidas. Essas fases são: Definição Desenvolvimento Operação Retirada Fase de Definição A fase de definição do software ocorre em conjunto com outras atividades como a modelagem de processos de negócios e análise de sistemas. Nesta atividade, diversos profissionais buscam o conhecimento da situação atual e a identificação de problemas para que possam elaborar propostas de solução de sistemas computacionais que resolvam tais problemas. Dentre as propostas apresentadas, deve-se fazer um estudo de viabilidade, incluindo análise custo-benefício, para se decidir qual solução será a escolhida.