Aula 06

Prévia do material em texto

Universidade Paulista (UNIP)
Instituto de Ciências Exatas e Tecnológicas (ICET)
Disciplina: Engenharia de Software
Tema: UML
Prof. MSc. Vladimir Camelo
Unified Modeling Language (UML)
Projeto da Arquitetura de Software
Para se desenvolver um projeto deve-se levar em consideração os requisitos arquiteturais que motivam e justificam as tomadas de decisão por parte de um projetista. Por trás disto, também estão metas de qualidade desejadas para o sistema a ser desenvolvido, bem como cenários de uso, estilos arquiteturais existentes e padrões de projeto.
O projeto arquitetural é uma fase iterativa do processo de desenvolvimento de sistema e que possibilita a tomada de decisões, levando em consideração os requisitos arquiteturais e cenários de uso. Pode-se também fazer uso de técnicas de análise arquitetural para entender o comportamento de atributos de qualidade. Tais técnicas podem acrescentar informações aos estilos arquiteturais de modo a possibilitar o raciocínio qualitativo e quantitativo do sistema.
Dimensões e Regras de Projeto
Projetos inovadores são, geralmente, desenvolvidos para resolver novos tipos de problemas ou mesmo prover solução a algum problema com requisitos bem específicos. Nesse sentido, a comunidade de engenharia de software e, mais especificamente, de arquitetura de software, tem procurado organizar o conhecimento de projeto de sistemas de software. Uma forma de fazer isto é desenvolvendo um vocabulário, englobando conceitos e padrões de projetos que possam ser facilmente compreendidos e reutilizáveis. Como resultado deste esforço, tem-se:
A possibilidade de desenvolver um projeto de sistema a partir de blocos estruturais.
Entendimento e antecipação das propriedades de um projeto.
Redução do esforço necessário para compreender o projeto de outra pessoa.
Um exemplo de organização de conhecimento por meio de um vocabulário é a codificação de estruturas de controle do fluxo de instruções em um algoritmo, onde são dispostas estruturas sequenciais, de decisão e repetição. Isto oferece um entendimento sobre os padrões de fluxo de controle no qual é feito uso desses blocos estruturais. Uma forma de organizar o conhecimento a ser utilizado no projeto arquitetural é obtendo um conjunto de soluções de projeto em termos de dimensões de projeto. Cada dimensão nesse conjunto solução descreve uma característica do sistema ou decisão de projeto.
Vantagens
Comunicação de stakeholders: A arquitetura é uma apresentação de alto nível do sistema e pode ser usada como um foco de discussão por uma série de diferentes stakeholders.
Análise de sistema: Tornar explícita a arquitetura do sistema, em um estágio inicial de seu desenvolvimento, requer alguma análise. As decisões de projeto de arquitetura têm um efeito profundo sobre a possibilidade de o sistema atender ou não aos requisitos críticos, como desempenho, confiabilidade e manutenibilidade. 
Reuso em larga escala: Um modelo de uma arquitetura de sistema é uma descrição compacta e gerenciável de como um sistema é organizado e como os componentes interoperam. A arquitetura do sistema geralmente é a mesma para requisitos semelhantes e, por isso, pode apoiar o reuso de software em grande escala. 
Cada arquiteto de software trabalha de uma maneira diferente, tendo como base suas experiências adiquiridas, mas todos eles desenvolvem três atividades em comum:
Estruturação do sistema: O sistema é decomposto em subsistemas principais e a comunicação entre estes é identificada.
Modelagem de controle: É estabelecido um modelo dos relacionamentos de controle entre as partes do sistema.
Decomposição modular: Os subsistemas identificados são decompostos em módulos.
Diferença entre Subsistema e Módulo
Um Subsistema é um sistema cuja operação não depende dos serviços fornecidos por outros subsistemas. São compostos por módulos. um Módulo é geralmente um componente de sistema que fornece um ou mais serviços para outros serviços, mas não é considerado um sistema independente. Um módulo precisa de outro para formar um subsistema. Diferentes modelos arquiteturais podem ser produzidos durante o processo de projeto. Cada modelo apresenta diferentes perspectivas sobre a arquitetura.
Modelo Estrutural Estático mostra os principais componentes do sistema;
Modelo de Processo Dinâmico mostra a estrutura do processo do sistema (processos em run-time “tempo de execução”);
Modelo de Interface define as interfaces de subsistemas (serviços oferecidos);
Modelos de Relacionamentos mostra como vai ser a relação entre os subsistemas para que forme o sistema final.
A Estrutura e o Estilo específico escolhido para uma aplicação podem depender dos requisitos não funcionais do sistema.
Desempenho: Se o desempenho for um requisito importante, isso sugere que a arquitetura deve ser projetada dentro de um pequeno número de subsistemas.
Proteção: Se a proteção for um requisito fundamental, isso vai sugerir que uma estrutura em camadas para a arquitetura deve ser utilizada com os itens mais importantes protegidos nas camadas mais internas e com um alto nível de validação de proteção aplicado a essa camada.
Segurança: Se a segurança for o requisito mais importante, sugere que as operações relacionadas com a segurança fiquem todas em um único subsistema ou em um pequeno número de subsistemas. Essa opção reduz os custos e os problemas de validação de segurança.
Disponibilidade: Se esse for o requisito fundamental, sugere que a arquitetura seja projetada para incluir componentes possíveis de substituição e atualização, sem a interrupção do sistema.
Facilidade de Manutenção: Esse requisito sugere que a arquitetura deve ser projetada utilizando componentes com poucas divisões, que possam ser rapidamente modificados. Dessa maneira os dados compartilhados devem ser evitados.
Estruturação do Sistema
A primeira fase da atividade de projeto de arquitetura é geralmente voltada para a decomposição do sistema em um conjunto de subsistemas. Um projeto de arquitetura pode ser representado como um diagrama de blocos e de linhas. Mas certamente não devem ser as únicas representações de arquitetura a serem utilizadas. Modelos mais específicos da estrutura podem ser desenvolvidos, os quais mostram como os subsistemas compartilham dados, distribuição e como atuam como interface entre si.
Modelos – Padrão
Modelo de Repositório: É um modelo de sistema com base em um banco de dados compartilhado. Esse modelo é adequado a aplicações em que os dados são gerados por um subsistema e utilizados por outro. Exemplos de sistemas com modelo repositório são os Sistemas de Comando e Controle, Sistemas de Informações Gerenciais, Conjuntos de ferramentas CASE e os Sistemas de CAD.
Vantagens e desvantagens de um Modelo repositório
Possibilita de maneira eficiente compartilhar grandes quantidades de dados. Não há necessidade de transmitir os dados explicitamente de um subsistema para outro. Contudo, os subsistemas devem concordar com o modelo de dados de repositório. Pode ser difícil ou impossível integrar novos subsistemas, se seus modelos de dados não se adequarem ao esquema estabelecido.
Os subsistemas que produzem dados não precisam saber como estes são utilizados por outro subsistema.
Contudo, a evolução pode ser difícil, uma vez que um grande volume de informações é gerado de acordo com um modelo de dados estabelecido.
As atividades como backup, segurança, controle de acesso e recuperação a partir de erros, são centralizados e de responsabilidade do gerente de repositório. As ferramentas podem focalizar suas principais funções, em vez de se ocuparem com essas questões. * * Contudo, diferentes subsistemas podem ter diferentes requisitos para políticas de proteção, recuperação e backup. O modelo de repositório impõe a mesma política a todos os subsistemas.
O modelo de compartilhamento é visível por meio de esquema de repositório. É simples e direto integrar novas ferramentas, considerando que eles são compatíveis com o modelo dedados estabelecidos.
Contudo, pode ser difícil distribuir o repositório em uma série de máquinas. Embora seja possível distribuir um repositório logicamente centralizado, pode haver problemas de redundância e inconsistência de dados.
Modelo Cliente-Servidor: É um modelo de sistema distribuído, que mostra como os dados e o processamento são distribuídos em uma série de processadores. A vantagem mais importante do Modelo Cliente-Servidor é que ele é uma arquitetura distribuída, permitindo o uso efetivo de sistemas de rede com muitos processadores distribuídos.
Principais componentes deste modelo
Um conjunto de servidores em stand-alone, que oferece serviços a outros sistemas.
Um conjunto de clientes que solicita os serviços oferecidos pelos servidores. Estes são, normalmente, subsistemas em si.
Uma rede que permite aos clientes acessar esses serviços.
Modelo de Máquina Abstrata: Modela a interface de subsistemas e organiza um sistema em uma série de camadas, cada uma das quais fornecem um conjunto de serviços. À medida que uma camada é desenvolvida, alguns serviços fornecidos por aquela camada podem se tornar disponíveis para os usuários. Se sua interface for preservada, uma camada poderá ser substituída por outra. Quando as interfaces em camadas se modificam, somente a camada adjacente é afetada.
Modelo de Controle: Controlam os subsistemas de modo que seus serviços sejam fornecidos no local certo e no tempo certo. Em nível de arquitetura dizem respeito ao controle de fluxo entre subsistemas.
Duas abordagens gerais de controle podem ser identificadas: 
Controle Centralizado: Um subsistema tem a responsabilidade geral pelo controle, e iniciar e interromper os outros subsistemas, os modelos de Controle Centralizado se dividem em duas classes:
Modelo de retorno de chamadas: Esse é o modelo de sub-rotina top-down, em que o controle começa na parte superior de uma hierarquia de sub-rotina e, por meio de chamadas de sub-rotina, passa para vários níveis mais fortes na árvore. O modelo de sub-rotina aplica-se apenas a sistemas sequenciais.
Modelo gerenciador: Neste modelo um componente é designado como um gerenciador do sistema e controla o início, a interrupção e a coordenação de outros processos de sistema. Um processo é um subsistema ou um módulo que pode ser executado em paralelo com outros processos. Pode ser aplicado a sistemas concorrentes. Uma variação desse modelo também pode ser aplicada em sistemas sequenciais, em que uma rotina de gerenciamento chama determinados subsistemas.
A natureza rígida e restrita do modelo retorno de chamadas é, ao mesmo tempo, um ponto forte e fraco. É um ponto forte porque é relativamente simples analisar fluxos de controle e concluir como o sistema responderá a estrada específica. É um ponto fraco porque é difícil lidar com as exceções feitas à operação normal. O modelo gerenciador é, frequentemente, utilizado em sistemas em tempo real simples, que não tem restrições de tempo muito rígidas. De modo geral o controlador está em um loop contínuo, verificando sensores e outros processos para eventos e mudanças de estado. Por esta razão, esse modelo é, algumas vezes, chamado de loop de eventos.
Sistemas Orientados a Eventos: São baseados em eventos gerados externamente. O termo evento, não significa somente um sinal binário, ele pode ser um sinal capaz de assumir uma gama de valores. Existem tipos diferentes de sistemas orientados a eventos, que podem ser desenvolvidos. Os dois principais modelos de controle orientado a objeto:
Modelo de transmissão: Onde um evento é, em principio, transmitido para todos os subsistemas. Qualquer subsistema que puder manipular esse evento responderá a ele.
Modelo orientado a interrupções: Eles são exclusivamente utilizados em sistemas de tempo real, em que interrupções externas são detectadas por um manipulador de interrupções.
Decomposição em módulos
É o processo do projeto de arquitetura que decompõe os subsistemas em módulos. Não há uma distinção rígida entre a decomposição de sistemas e a decomposição em módulos. Contudo os componentes em módulos são geralmente menores do que os subsistemas, e isso permite que sejam utilizados modelos alternativos de decomposição. Modelos utilizados na decomposição de um sistema em módulos:
Modelo orientado a objeto: É decomposto em um conjunto de objetos que se comunicam. Uma decomposição orientada a objeto diz respeito a classes de objetos, seus atributos e suas operações. Quando ela é implementada, os objetos são criados a partir dessas classes e algum modelo de controle é utilizado para coordenar as operações de objetos. Suas vantagens é que uma vez que os objetos são inadequadamente acoplados, a implementação de objetos pode ser modificada, sem afetar outros objetos.
Modelo de fluxo de dados: É decomposto em módulos funcionais que aceitam a entrada de dados e os transformam em dados de saída. Em um modelo de fluxo de dados, as transformações funcionais processam suas entradas e produzem saídas. Os dados fluem de uma para outra e são transformados à medida que se movimentam ao longo da sequencia. As transformações podem ser executadas sequencialmente ou em paralelo. As vantagens dessa arquitetura é que ela suporta o reuso de transformações e ela é intuitiva, no sentido de que muitas pessoas pensam em seu trabalho em termos de processamento de entrada e saída, ela é simples de ser implementada, e a evolução do sistema pela adição de novas transformações é geralmente simples e direta.
Arquitetura de domínio específico
Existem dois tipos de modelo de arquitetura de domínio específico:
Modelos Genéricos: Modelos genéricos são abstrações a partir de uma série de sistemas reais. Talvez, o exemplo mais conhecido de um modelo genérico de arquitetura seja um modelo de compilador. Eles devem ter os seguintes módulos: Um analisador léxico, uma tabela de símbolos e um analisador sintático
Modelos de Referência: Os modelos de referência são, de modo geral, derivados de um estudo do domínio da aplicação. Eles representam uma arquitetura idealizada que inclui todas as características que o sistema pode incorporar