UNIVERSIDADE DE CAXIAS DO SUL
RODRIGO BOITO
ESTRATÉGIAS ARQUITETURAIS PARA O SISTEMA ERP DO PROJETO DO NUSIS
CAXIAS DO SUL 2013
UNIVERSIDADE DE CAXIAS DO SUL
CENTRO DE COMPUTAÇÃO E TECNOLOGIA DA INFORMAÇÃO SISTEMAS DE INFORMAÇÃO
RODRIGO BOITO
ESTRATÉGIAS ARQUITETURAIS PARA O SISTEMA ERP DO PROJETO NUSIS
Trabalho de Conclusão de Curso para obtenção do Grau de Bacharel em Sistemas de Informação da Universidade de Caxias do Sul.
Orientadora Prof. Ms Iraci Cristina Silveira de Carli
CAXIAS DO SUL 2013
RODRIGOBOITO
ESTRATÉGIAS ARQUITETURAIS PARA O SISTEMA ERP DO PROJETO NUSIS
Trabalho de Conclusão de Curso para obtenção do Grau de Bacharel em Sistemas de Informação da Universidade de Caxias do Sul.
Orientadora Prof. Ms Iraci Cristina Silveira de Carli
Aprovado em 01/07/2013
Banca Examinadora
_________________________________ Prof. Ms. Iraci Cristina Silveira De Carli
_________________________________ Prof. Dr. Daniel Luis Notari
_________________________________ Prof. Ms. Marcos Eduardo Casa
Dedico este trabalho aos meus pais Sérgio Antônio Boito e Anilse Masiero Boito que não mediram esforços para que eu pudesse chegar até aqui e minha esposa, companheira e amiga Andréia Morello.
AGRADECIMENTOS
Primeiramente gostaria de agradecer a Deus, pela saúde e pela vida que eu tenho, por estar numa família com princípios éticos que me educou de uma maneira em que eu pudesse chegar nesse momento especial. Agradeço a Universidade de Caxias do Sul que além me dar totais condições e me abrir muitas portas, me trouxe conhecimentos para a vida através da convivência que tive com diversas pessoas.
Agradeço aos meus pais e ao meu irmão que sem eles com certeza eu não chegaria até aqui.
Agradeço a minha companheira Andréia Morello que apesar de às vezes não aceitar muito as minhas ausências, principalmente na elaboração deste trabalho, sempre esteve comigo em todos os momentos.
Não posso deixar de agradecer a minha orientadora que me instigou a buscar cada vez mais neste trabalho e soube me orientar de uma forma que eu pudesse chegar ao objetivo desejado.
Por fim agradeço aos meus colegas de trabalho que entenderam minhas ausências e me possibilitaram mais tempo para a realização desta pesquisa.
RESUMO
A partir do aumento da complexidade dos softwares tornou-se necessária a definição de arquiteturas de software. Decisões tomadas na fase de iniciação do software, minimizam o esforço empenhado para uma mudança, do que quando a arquitetura já foi implementada.
Uma questão muito importante nas decisões arquiteturais é atingir os atributos de qualidade desejáveis para o produto tais como, desempenho, manutenibilidade, confiabilidade que não estão diretamente relacionados às funcionalidades do sistema e com papel importante durante o seu desenvolvimento. Implicando na escolha de estruturas arquiteturais, em alternativas de projeto e na forma de implementação.
Avaliar uma arquitetura de software em grandes sistemas é algo complexo. É difícil comparar e até entender em um curto espaço de tempo. Além disso, cada interessado tem necessidades diferentes. A aplicação de métodos de análise arquitetural podem diminuir os riscos na definição da arquitetura de software. Eles compreendem etapas que auxiliam nas escolhas e cada atributo de qualidade é escrito através de cenários, assim como sua priorização.
Neste trabalho serão apresentadas as estruturas arquiteturais que juntam formam uma arquitetura de software, seus componentes e conectores, padrões de projeto, métodos de análise arquitetural, frameworks de desenvolvimento. A partir destes estudos será definida a arquitetura candidata para o ERP do NUSIS. O software será baseado na Web e a fim de demonstrar que os atributos de qualidade podem ser atendidos pela arquitetura proposta, foi desenvolvido um protótipo de software seguindo as características da arquitetura proposta.
Palavras chave: Arquitetura de Software, atributos de qualidade, métodos de análise arquitetural, ERP, WEB, ATAM, Spring Framework
ABSTRACT
With the increasing complexity of software has become necessary to define software architectures. Decisions taken in the inception phase of the software, committed effort to minimize the change than when the architecture has been implemented.
A very important issue is the architectural decisions achieve the desirable quality attributes for the product such as performance, maintainability, reliability, which are not directly related to system functionality and important function during development. Implying the choice of architectural structures in design alternatives and the way of implementation.
Evaluate a software architecture for large systems is complex. It is difficult to compare and to understand in a short time. In addition, each stakeholder has different needs. The application of methods of architectural analysis can reduce the risks in the definition of software architecture. They include steps that assist in choices and each quality attribute is written through scenarios, and its prioritization.
This work present the architectural structures that together constitute a software architecture, its components and connectors, design patterns, architectural analysis methods, development frameworks. From these studies will set the candidate architecture for ERP NUSIS. The software is web-based and to demonstrate that quality attributes can be satisfied by the proposed architecture, we developed a prototype software following characteristics of the proposed architecture.
Keywords: software architecture, quality attributes, architectural analysis methods, ERP, WEB
LISTA DE ILUSTRAÇÕES
Figura 1 – Modelo de Qualidade para Qualidade Externa e Interna ... 23
Figura 2 – Qualidade em Uso NBR ISO/IEC 9126 Parte 1... 24
Figura 3 – Estruturas Arquiteturais ... 25
Figura 4 – Exemplos de Módulos em notações UML ... 27
Figura 5 – Diagrama de Pacotes da arquitetura Lógica em camadas ... 29
Figura 6 – Arquitetura de um Projeto Orientado a Objetos ... 31
Figura 7 – Representação de camadas em UML ... 32
Figura 8 – Sistema Cliente-Servidor ... 33
Figura 9 – Arquitetura de Repositório ... 36
Figura 10 – Visão de Desenvolvimento da arquitetura JEE em múltiplas camadas ... 38
Figura 11 – Visão de Implantação de um sistema Bancário ... 39
Figura 12 – Decomposição de um sistema interativo ... 40
Figura 13 – Evolução das arquiteturas e software de interfaces com usuário ... 41
Figura 14 – Modelo Visão Controlador ... 42
Figura 15 – Arquitetura Seeheim... 44
Figura 16 – Arquitetura Arch/Slinky ... 45
Figura 17 – Arquitetura PAC ... 46
Figura 18 – Arquitetura PAC - Amodeus ... 47
Figura 19 – Componentes básicos do Spring ... 53
Figura 20 – Análise Arquitetural ... 57
Figura 21 – Etapas de SAAM ... 58
Figura 22 – Contexto para o CBAM ... 62
Figura 23 – Estrutura típica de um ERP ... 69
Figura 24 – Visão de Implantação da arquitetura candidata ... 72
Figura 25 – Padrão Front Controller no Contexto do Spring ... 74
Figura 26 – Ciclo de Vida de uma requisição ... 75
Figura 27 – Diagrama de Uso da arquitetura candidata ... 77
Figura 28 – Visão em camadas da arquitetura candidata ... 78
Figura 29 – Visão de Desenvolvimento da arquitetura candidata ... 79
Figura 30 – Árvore de Utilidade ... 80
Figura 31 – Cenário de Desempenho ... 81
Figura 33 – Cenário de Interoperabilidade ... 83
Figura 34 – Cenário de Segurança ... 84
Figura 35 – Cenário de Modificabilidade ... 85
Figura 36 – Árvore de utilidade para o Protótipo do NUSIS ... 85
Figura 37 – Configuração das dependências no Maven ... 88
Figura 38 – Casos de Uso do Protótipo ... 89
Figura 39 – Diagrama de Classes de Análise para o protótipo ... 90
Figura 41 – Modelo de diagrama de classes para o NUSIS ... 91
Figura 42 – Caso de Uso Cadastrar Tabela de Preços ... 92
Figura 43 – Formulário com a funcionalidade para Reajuste de Preços ... 92
Figura 44 – Caso de Uso Cadastrar Pedido Venda ... 93
Figura 45 – Diagrama de Sequência para Interoperabilidade... 93
Figura 46 – Integração Sistema de Pedidos com Sistema de Estoque... 94
Figura 47 – Caso de uso Cadastrar Usuários ... 94
Figura 48 – Interface para Login do usuário ... 95
Figura 49 – E-mail enviado após queda do Banco de Dados ... 96
Figura 50 – Página de erro Sistema indisponível ... 96
Figura 51 – Código fonte do Controlador ... 97
Figura 52 – Código fonte da classe de persistência ... 98
Figura 53 – Entidade mapeamento do Objeto Relacional ... 98
LISTA DE TABELAS
Tabela 1 – Padrões de Projeto ... 48
Tabela 2 – Vantagens e Desvantagens entre os Frameworks citados... 51
Tabela 3 – Papeis da equipe de avaliação... 60
Tabela 4 – Interessados e as necessidades de comunicação servidos pela arquitetura ... 63
Tabela 5 – Interessados e as visões arquiteturais mais úteis ... 64
Tabela 6 – Vantagens e limitações de arquiteturas de sistemas interativos ... 65
Tabela 7 – Fases do ATAM ... 67
LISTA DE ABREVIATURAS E SIGLAS
ATAM Architecture Tradeoff Analysis Method CBAM Cost Benefit Analysis Method
CCTI Centro de Ciências e Tecnologia de Informação
DAO Data Access Object
DTO Data Transfer Object EJB Enterprise Java Bean
ERP Enterprise Resource Planning HTTP Hyper Text Transfer Protocol
IEC International Electrotechnical Comission ISO International Organization for Standardization JDBC Java Database Connectivity
JMS Java Message Service JSON JavaScript Object Notation
MVC Model-View-Controller
NBR Norma Brasileira
NUSIS Núcleo de Sistemas de Informação OXM Object Extensive Markup Language PAC Presentation-Abstraction-Control
RMI Remote Method Invocation
RUP Rational Unified Process
SAAM Software Architecture Analysis Method SEI Software Engineering Institute
SUMÁRIO
1. INTRODUÇÃO ... 16
1.1 PROBLEMA DE PESQUISA ... 17
1.2 QUESTÕES DE PESQUISA ... 18
1.3 OBJETIVOS ... 18
1.4 METODOLOGIA E ORGANIZAÇÃO DO TRABALHO ... 18
2. ARQUITETURA DE SOFTWARE ... 20
2.1 ARQUITETURA DE SOFTWARE NO PROCESSO DE DESENVOLVIMENTO DE SOFTWARE ... 21
2.2 ARQUITETURA DE SOFTWARE E QUALIDADE ... 22
2.2.1 Qualidade Interna e Externa ... 23
2.2.2 Qualidade em Uso ... 24 2.3 ESTRUTURAS ARQUITETURAIS ... 25 2.3.1 Módulos ... 26 2.3.1.1 Estrutura de Decomposição ... 27 2.3.1.2 Estrutura de Usos ... 28 2.3.1.3 Camadas ... 28
2.3.1.4 Estrutura de Classe ou generalização ... 30
2.3.2 Componentes e Conectores ... 32
2.3.2.1 Estrutura Cliente-Servidor... 33
2.3.2.2 Concorrência ... 34
2.3.2.3 Processos ... 35
2.3.2.4 Dados Compartilhados ou Repositório ... 35
2.3.3 Alocação ... 36
2.3.3.1 Estrutura Desenvolvimento ... 37
2.3.3.2 Estrutura de Implantação ... 38
2.3.3.3 Atribuição de Trabalho... 39
2.4 ARQUITETURA DE SOFTWARE PARA SISTEMAS INTERATIVOS ... 40
2.4.1 MVC (Modelo Visão Controlador) ... 41
2.4.2 Arquitetura Seeheim ... 43 2.4.3 Arquitetura Arch/Slinky ... 44 2.4.4 Arquitetura PAC ... 46 2.4.5 Arquitetura PAC-Amodeus ... 46 2.5 PADRÕES DE PROJETO ... 48 2.6 FRAMEWORKS ... 49
2.6.1 Spring Framework ... 52
2.6.1.1 Container ... 53
2.6.1.2 AOP (Aspect-Oriented Programming) ... 54
2.6.1.3 Instrumentação ... 54
2.6.1.4 Acesso a dados e Integração... 54
2.6.1.5 Web ... 55
2.6.1.6 Testes ... 55
2.6.1.7 Portfólio do Spring ... 55
2.7 MÉTODOS DE ANÁLISE ARQUITETURAL ... 56
2.7.1 SAAM (Software Architecture Analysis Method) ... 57
2.7.2 ATAM (Architecture Tradeoff Analysis Method) ... 59
2.7.3 CBAM (Cost Benefit Analysis Method) ... 61
2.8 DOCUMENTANDO ARQUITETURAS DE SOFTWARE ... 62
2.9 CONSIDERAÇÕES FINAIS ... 64
3. DEFINIÇÃO DA ARQUITETURA CANDIDATA PARA O NUSIS ... 67
3.1 PRINCIPAIS FATORES DE NEGÓCIO ... 68
3.1.1 ERP do NUSIS ... 69 3.2 APRESENTAÇÃO DA ARQUITETURA ... 70 3.2.1 Estrutura de Implantação ... 71 3.2.1.1 Camada de Segurança ... 72 3.2.1.2 Camada Web ... 73 3.2.1.2.1 Spring Web MVC ... 74 3.2.1.3 Camada de Negócio ... 75 3.2.1.4 Camada de Persistência ... 76 3.2.1.5 Camada de Integração ... 76 3.2.2 Estrutura de Usos ... 77 3.2.3 Estrutura em Camadas ... 78 3.2.4 Estrutura de Desenvolvimento ... 79
3.3 ATRIBUTOS DE QUALIDADE NA ÁRVORE DE UTILIDADE ... 79
3.3.1 Cenários de Atributos de Qualidade ... 81
3.3.1.1 Cenário de Desempenho... 81
3.3.1.2 Cenário de Disponibilidade ... 82
3.3.1.3 Cenário de Interoperabilidade ... 83
3.3.1.4 Cenário de Segurança ... 83
3.3.1.5 Cenário de Modificabilidade ... 84
3.3.2 Árvore de Utilidade para o Protótipo do NUSIS ... 85
4. PROTÓTIPO PARA SIMULAÇÃO DOS CENÁRIOS PROPOSTOS NO ATAM 88 4.1 DESEMPENHO ... 92 4.2 INTEROPERABILIDADE ... 93 4.3 SEGURANÇA ... 94 4.4 DISPONIBILIDADE ... 95 4.5 MODIFICABILIDADE ... 96 4.6 CONSIDERAÇÕES FINAIS ... 99 5. CONCLUSÃO ... 100 REFERÊNCIAS BIBLIOGRÁFICAS ... 102
1. INTRODUÇÃO
Na década de 90 quando aconteceu a expansão da internet, muitos desenvolvedores passaram a desenvolver WebApps, aplicativos que poderiam ser executados a partir de um navegador, permitindo acesso de qualquer local. Em consequência disto, este tipo de software ganhou cada vez mais importância no mundo corporativo. Em decorrência do aumento da importância, passaram a executar funções, antes somente executadas por softwares chamados desktop. Deixando de ser um mero sistema de hipertexto para ganhar capacidade computacional. Proporcional a isso os problemas tornaram-se maiores aumentando o grau de complexidade da aplicação. Em virtude do aumento da complexidade dos WebApps se tornou também necessária a definição de uma arquitetura de software. (Pressmann, 2006).
Arquitetura de software é a organização fundamental do sistema representada por suas estruturas, seus relacionamentos com o ambiente, e pelos princípios que conduzem seu design e evolução. Dita o que pode e o que não pode ser feito durante todo o ciclo de vida do software. Além disso, a partir dessas decisões permite a avaliação de uma implementação do sistema a partir de um projeto arquitetural. Por fim a arquitetura de software também serve como facilitadora da comunicação entre os vários interessados no sistema, pois ela traduz em suas diversas visões as preocupações de cada membro da equipe (Barbosa, 2009).
O projeto arquitetural é muito importante no processo de desenvolvimento, pois orienta a implementação dos atributos de qualidade do software e auxilia no entendimento de uma solução complexa. Para se chegar à qualidade desejada no software é importante o conhecimento de um conjunto de requisitos arquiteturais. Estes requisitos constituem propriedades desejadas ou apresentadas por uma arquitetura de software. De posso dos requisitos o arquiteto, busca identificar quais as estruturas arquiteturais são mais adequadas ao sistema que será desenvolvido (Mendes 2002).
A definição dos requisitos arquiteturais segundo Mendes (2002) não é tarefa fácil. A medida que a complexidade de sistemas aumenta estes requisitos arquiteturais passam a ser um aspecto de maior significado quando comparado à escolha de algoritmos ou estruturas de dados.
Para garantir que os requisitos arquiteturais sejam levados em conta é necessário a avaliação dos mesmos através de métodos de análise arquitetural. Desta forma é possível
tentar determinar algumas decisões ou modificações, antes da arquitetura ser construída, ou seja, é importante que a arquitetura seja tratada ainda na fase de concepção. (Mendes, 2002).
1.1 PROBLEMA DE PESQUISA
A Universidade de Caxias do Sul possui um Núcleo de Avaliação, Seleção, Desenvolvimento e Aplicação de Sistemas de Informação (NUSIS), no qual existe um projeto com o intuito de disponibilizar sistemas de informação para empresas de pequeno porte. O objetivo é criar um ambiente para alunos desenvolverem sistemas podendo aplicar em situações reais. O desenvolvimento produzirá sistemas de diversos tipos e, a partir de sua como: Sistemas Estratégicos, Base de dados, Portais Corporativos, ERP (Enterprise Resource Planning). Esse último fará parte do objeto de estudo.
Os requisitos funcionais ainda não foram elicitados, o que se tem conhecimento é que o sistema será modularizado por área funcional. Os atributos de qualidade serão definidos e especificados ao longo deste trabalho.
O ERP será uma aplicação baseada na Web, consolidando o conteúdo desenvolvido nas disciplinas dos cursos do CCTI (Centro de Computação e Tecnologia da Informação). Utilizando o paradigma de orientação de objetos e como linguagem Java.
O processo de desenvolvimento será o Processo Unificado Ágil, iterativo, incremental e evolutivo. É centrado na arquitetura e orientado por casos de uso e utiliza como técnica de modelagem a UML (Unified Modeling Language).
O software será desenvolvido por equipes diferentes em momentos diferentes, sempre formadas por alunos em estágio ou desenvolvendo trabalhos de conclusão. Esta forma caracteriza uma alta rotatividade da equipe, além da pouca experiência da mesma em desenvolvimento de sistemas.
Uma das atividades para o desenvolvimento do ERP do Projeto do NUSIS são as estratégias para definição de arquiteturas de software na fase de concepção. Essas estratégias darão subsídios para o desenvolvimento do sistema com os atributos e a qualidade exigidos. Os critérios para garantir a qualidade do software serão definidos ao longo do trabalho.
1.2 QUESTÕES DE PESQUISA
Baseado no problema de pesquisa descrito anteriormente foi criada a seguinte questão de pesquisa:
Quais são as estratégias, em relação à arquitetura de software, mais apropriadas ao projeto do ERP do Nusis na fase de concepção?
1.3 OBJETIVOS
O objetivo deste trabalho é propor estratégias para arquitetura de software a ser utilizada no sistema de ERP do projeto do NUSIS. Entre as estratégias está a definição de uma arquitetura candidata, bem como a definição dos atributos de qualidade desejados para o ERP.
A avaliação dessa arquitetura se dará através da aplicação de um método de Análise Arquitetural.
Essas estratégias serão desenvolvidas na fase de concepção e direcionarão o desenvolvimento de iterações, inclusive no levantamento de requisitos funcionais que poderão surgir durante o projeto, apesar de já serem conhecidos alguns requisitos do sistema.
A fim de demonstrar que a arquitetura candidata pode atender aos atributos de qualidade desejados um protótipo de software deverá ser desenvolvido a partir da arquitetura candidata gerada.
1.4 METODOLOGIA E ORGANIZAÇÃO DO TRABALHO
Para a realização deste trabalho a metodologia seguirá os seguintes passos:
Primeira etapa: Levantamento do material bibliográfico sobre Arquiteturas de Software. Realizando comparações a fim de trazer as melhores estratégias para a definição da arquitetura candidata do ERP do NUSIS.
Segunda Etapa: Elicitação dos atributos de qualidade desejados para o sistema a fim de levantar as estratégias da arquitetura candidata que será proposta para o ERP do NUSIS.
Analisando outros sistemas com características similares e em levantamento com os coordenadores do projeto. Buscando bibliografia que possa abalizar o que é importante para um sistema desse tipo.
Terceira Etapa: Analisar as estratégias arquiteturais levantadas para a utilização no ERP do NUSIS. Confrontar com os atributos que serão necessários para o ERP e que serão definidos durante o projeto.
Quarta etapa: Análise da arquitetura candidata a partir da utilização de um Método de Análise Arquitetural.
Quinta etapa: Desenvolver um protótipo de software utilizando a arquitetura candidata proposta. O protótipo deverá ser desenvolvido na linguagem Java utilizando o processo unificado centrado na arquitetura e deverá abordar um caso de uso ou mais, o suficiente para atender aos atributos de qualidade desejados.
O trabalho está organizado em quatro capítulos, onde no capítulo 1 é apresentada a introdução compreendendo a contextualização do assunto, problema de pesquisa, questão de pesquisa, objetivos e metodologia do trabalho.
No capítulo 2, são apresentados estudos bibliográficos realizados sobre qualidade de software, arquitetura de software composta por estruturas arquiteturais, padrões de projeto, arquitetura de interface com usuários, requisitos arquiteturais, métodos de análise arquitetural e documentação da arquitetura.
No capítulo 3, baseado no método de análise arquitetural, são apresentados os atributos de qualidade para o projeto do ERP do Nusis, bem como decisões como a utilização de um framework de desenvolvimento.
No capítulo 4, será apresentado o protótipo de software que visa garantir que os atributos de qualidade sejam atendidos.
2. ARQUITETURA DE SOFTWARE
Não há uma definição universal para arquitetura de software e existem muitos termos de diversos autores. O SEI (Software Engineering Institute) apresenta inúmeras definições para esse assunto, a definição a seguir é coerente com o que será apresentado ao longo da pesquisa.
“A arquitetura de software de um programa ou sistema computacional é a estrutura ou estruturas do sistema, que envolvem elementos de software, propriedades externamente visíveis desses elementos e o relacionamento entre eles” (Bass, 2006 p.21).
Para Larman (2007) arquitetura de software tem a ver com ideias grandes e complexas, utilizando padrões, responsabilidades e conexões de um sistema ou sistema de sistemas (Larman, 2007).
Não é possível dizer se uma arquitetura de software é boa ou ruim, sem analisar a qual propósito ela se insere. Arquiteturas são mais ou menos aptas para determinados projetos (Bass, 2006). Segundo Bass (2006) existem algumas recomendações que devem ser seguidas para a definição de uma boa arquitetura, assim como a definição dos atributos funcionais e a priorização dos atributos de qualidade de software, dando subsídios para a escolha de estruturas arquiteturais.
Em conjunto com as estruturas arquiteturais está à exigência da qualidade do produto final, dessa forma o projetista deve decidir a arquitetura na camada de interface que mais se adequa aos atributos de qualidade desejados para o software a ser desenvolvido (Mendes, 2002).
Um processo de desenvolvimento centrado na arquitetura considera a arquitetura de software como fator preponderante no processo. Esse processo pode iniciar com o arquiteto de posse de um conjunto de requisitos arquiteturais, buscando identificar quais estruturas arquiteturais, padrões arquiteturais, padrões de projeto, arquitetura de interface, as utilizando para satisfazer aos atributos de qualidade desejados (Mendes, 2002).
Uma maneira de aplicar as estruturas e padrões é com a adoção de um framework de desenvolvimento. O framework já possui várias decisões e padrões de projeto embutidos nele, além de elevar o nível de qualidade da aplicação, um alto grau de reutilização de código e aumento na produtividade (Barreto, 2006).
Como forma de auxiliar o desenvolvimento da arquitetura, estão os métodos de análise arquitetural, os quais dão subsídios para que as escolhas se tornem menos arriscadas e
minimizando o esforço de mudanças, já que a arquitetura ainda não foi implementada (Mendes, 2002).
Para Bass (2006) a arquitetura de software desempenha um papel preponderante no desenvolvimento de sistema e na organização que o produz. Ela serve como um modelo para o desenvolvimento de um sistema definindo as atribuições de trabalho que devem ser realizadas pelas equipes de projeto e implementação, e é o principal meio para se chegar aos atributos de qualidade, porém até mesmo a arquitetura mais perfeita se tornaria inútil se os interessados não a entenderem. Faz-se necessária então a geração de uma documentação com detalhes suficientes que tornem essa arquitetura entendível a todos os interessados.
2.1 ARQUITETURA DE SOFTWARE NO PROCESSO DE DESENVOLVIMENTO DE SOFTWARE
A arquitetura de software é trabalhada nas diversas fases do Processo Unificado: iniciação, elaboração, construção e transição. Cada uma dessas fases pode conter uma ou mais iterações (Booch, 2000).
Entre os objetivos da fase de iniciação está a definição do escopo do projeto (requisitos e as restrições mais importantes) e a síntese de uma possível arquitetura (estimando os custos, programação e recursos) (Scott, 2003). O foco desta pesquisa é a fase de concepção na disciplina de análise e design, que tem como objetivo realizar uma síntese arquitetural. A finalidade da síntese arquitetural é detalhar o fluxo de trabalho construindo e avaliando um conceito de arquitetura candidata mostrando o que existe para satisfazer seus principais requisitos (Scott, 2003).
Na fase de elaboração a meta é estabelecer uma linha de base para a arquitetura, a fim de fornecer uma base para o esforço na fase de construção. Entre os objetivos desta fase estão diminuir e tratar os riscos, estabelecer a arquitetura base derivada do tratamento dos cenários significativos do ponto de vista da arquitetura (Booch, 2000).
A fase de construção deve esclarecer os requisitos restantes e concluir o desenvolvimento a partir de uma arquitetura base. Como objetivos tem, minimizar os custos de desenvolvimento, atingir a qualidade adequada, concluir a análise, design, desenvolvimento e testes de todas as funcionalidades necessárias (Booch, 2000).
Para se chegar a uma arquitetura candidata na fase de concepção, é necessário tomar algumas decisões. Para facilitar a tomada de decisões convém a utilização de padrões arquiteturais, bem como padrões de projeto e existem inúmeros. Para Gamma (2000) padrões de projeto tornam mais fácil reutilizar projetos e arquiteturas bem-sucedidas. Ajudam a escolher alternativas que tornam um sistema reutilizável e a evitar alternativas que comprometam a reutilização. Padrões arquiteturais expressam o esquema ou organização estrutural fundamental de sistemas de software ou hardware (Masiero, 2001).
2.2 ARQUITETURA DE SOFTWARE E QUALIDADE
Segundo Sommerville (2011) a arquitetura de software afeta diretamente aos atributos de qualidade do sistema. A norma ISO/IEC 9126 que trata da qualidade do produto de software pode apoiar o processo de definição destes atributos2. Ela está dividida em quatro partes:
I. Modelo de Qualidade II. Métricas Externas III. Métricas Internas
IV. Métricas Qualidade em Uso
Para a definição de um esboço de arquitetura será utilizada a primeira parte, Modelos de Qualidade. Ela lista os atributos de qualidade do software e é composta de duas subpartes: qualidade interna e externa e qualidade em uso.
A primeira parte trata especificamente de seis categorias as quais são dividas em subcategorias resultantes dos atributos internos do software. A segunda parte especifica quatro características de qualidade em uso, sendo o efeito combinado das seis categorias especificadas na primeira parte. Essas características podem ser aplicáveis para todos os tipos de software como sistemas de computadores e firmwares e podem trazer uma terminologia consistente para tratar de qualidade do produto de software (NBR ISO/IEC 9126, 2003).
2.2.1 Qualidade Interna e Externa
Os requisitos de qualidade externa são analisados derivados das necessidades de qualidade dos usuários. Esses requisitos são utilizados como metas para a validação de vários estágios de desenvolvimento. A qualidade externa é vista quando o software estiver sendo executado e pode ser analisada em um ambiente simulado onde a maioria dos erros podem ser descobertos e corrigidos (NBR ISO/IEC 9126, 2003).
Os requisitos de qualidade internos especificam o nível de qualidade sob o ponto de vista interno do produto. São utilizados para especificar as propriedades dos produtos intermediários incluindo modelos estáticos e dinâmicos, outros documentos e código-fonte. Podem ser utilizados para definir estratégias de desenvolvimento e critérios de avaliação durante o desenvolvimento (NBR ISO/IEC 9126, 2003).
A norma 9126 define um modelo de qualidade de software onde podem ser definidas as metas de qualidade do produto de software final e os intermediários. São categorizadas seis características (funcionalidade, confiabilidade, usabilidade, eficiência, manutenibilidade e portabilidade) onde cada uma delas é dividida em mais sub-características podendo ser medidas por métricas internas e externas, como ilustra a Figura 1 (NBR ISO/IEC 9126, 2003).
Figura 1 – Modelo de Qualidade para Qualidade Externa e Interna
Fonte: ISO/IEC 9126-1, 2003.
O atributo funcionalidade é a capacidade do produto em prover soluções que atendam às necessidades implícitas e explicitas, quando o software estiver sendo executado sob condições especificas.
Confiabilidade de um software é a capacidade que ele tem de executar as funções requisitadas, mantendo um nível de desempenho adequado e nas condições especificadas.
A usabilidade é a característica que trata diretamente como o usuário vai se relacionar com o software especificado. Essa característica está focada na capacidade de compreensão, aprendizado, operação e atratividade ao usuário.
Eficiência é a capacidade do produto de software apresentar desempenho apropriado, relativo à quantidade de recursos usados, sob as condições especificadas.
Manutenibilidade é a capacidade do software de ser modificado, podendo incluir correções, novas funcionalidades, mudança nos requisitos, melhorias ou adaptações por mudanças no ambiente.
A portabilidade trata da capacidade do software de ser transferido de um ambiente para outro, podendo ser um ambiente organizacional, de hardware ou de software. (NBR ISO/IEC 9126, 2003).
2.2.2 Qualidade em Uso
A qualidade em uso é a visão da qualidade na perspectiva do usuário. Ela trata da capacidade do software de permitir que os usuários atinjam as metas especificadas como eficácia, produtividade, segurança e satisfação. Os atributos de qualidade em uso são ilustrados pela Figura 2 (NBR ISO/IEC 9126, 2003).
Figura 2 – Qualidade em Uso NBR ISO/IEC 9126 Parte 1
Fonte: ISO/IEC 9126-1, 2003
a) Eficácia – Capacidade do usuário de atingir as metas especificadas com acurácia e completitude no contexto especificado
b) Produtividade – É capacidade do software de permitir que o usuário utilize os recursos apropriados em relação à eficácia obtida. Nessa característica os recursos podem ser tempos para concluir uma tarefa, esforço do usuário, materiais ou custos financeiros. c) Segurança – Capacidade do software de apresentar a segurança adequada em relação a
riscos de danos às pessoas, negócios, software ou propriedades ou ambiente.
d) Satisfação – Capacidade do produto de satisfazer ao usuário. Nesse caso são as respostas que o usuário dá em relação à interação com o produto (NBR ISO/IEC 9126, 2003).
2.3 ESTRUTURAS ARQUITETURAIS
Propor uma arquitetura candidata adequada aos atributos de qualidade do software exige a tomada de muitas decisões sobre as estruturas arquiteturais. Uma estrutura arquitetural permite que um profissional determine características dos subsistemas e conectores do sistema, topologia da arquitetura, restrições e mecanismos de interação entre os elementos (Bass, 2006).
A seguir serão apresentadas as estruturas arquiteturais. Bass (2006) as divide em três grupos: estrutura de módulos, componentes e conectores, e alocação. Conforme mostra Figura 3, estes três grupos são divididos em sub-características (Bass, 2006).
Figura 3 – Estruturas Arquiteturais
Para Bass (2006), estes são três grandes tipos de decisão que envolvem um projeto arquitetural e podem responder as seguintes perguntas:
O sistema será estruturado como um conjunto de unidade de código (Módulos)? O sistema será estruturado como um conjunto de elementos em tempo de execução
(Componentes) e suas interações (Conectores)?
Como o sistema irá se relacionar com as estruturas “não software” em seu ambiente (CPU´s, sistema de arquivos, redes, equipes de desenvolvimento)?
2.3.1 Módulos
Quando os arquitetos se deparam com sistemas de grande porte e complexos, geralmente eles dividem este sistema em partes menores. Estas partes são denominadas módulos. Compreender a modularidade de um sistema é entender cada parte separadamente, tornando mais fácil a manutenibilidade. A modularidade ajuda a isolar a fonte do problema a um único componente. Um sistema modular implica em módulos com uma alta coesão e baixo nível de acoplamento. Isso permite considerar os módulos como caixas-pretas possibilitando lidar com cada funcionalidade do sistema de forma independente (Mendes, 2002).
Na estrutura em módulos é dada menos ênfase em relação ao funcionamento do software em tempo de execução. Estruturas modulares nos permitem responder a alguns questionamentos como: Qual é a principal funcionalidade de cada módulo? Quais módulos vão se comunicar com outros por relacionamento de generalização ou especialização? (Bass, 2006).
A UML fornece uma variedade de formas para se representar diferentes tipos de módulos. A Figura 4 mostra alguns exemplos. A classe A e D são especializações orientadas a objetos de um módulo. O Pacote B que pode ser utilizado onde o agrupamento de funcionalidades é necessário, como na representação de camadas e classes. O subsistema que pode ser usado se uma especificação de interface é requerida.
Figura 4 – Exemplos de Módulos em notações UML
Fonte: Bass, 2006
Bass (2006) divide a estrutura modular em estrutura de decomposição, estruturas de uso, estruturas de camadas e estruturas de classes (Bass, 2006).
2.3.1.1 Estrutura de Decomposição
Quando os sistemas a serem desenvolvidos são complexos e exigem que uma grande equipe de desenvolvimento esteja alocada para tal, deve-se pensar em decomposição. Os módulos maiores do sistema são divididos em submódulos e assim recursivamente até que fiquem suficientemente pequenos para serem facilmente compreendidos. O Arquiteto enumera quais serão as funções desempenhadas por cada unidade do software e muitas vezes são usadas como base para a organização do projeto de desenvolvimento incluindo a estrutura de documentação, integração e planos de teste (Bass, 2006)
Segundo Bass (2006), um módulo pode definir um grupo de procedimentos, alguns públicos outros privados e ainda um conjunto privado de estrutura de dados. Dessa forma a interface do módulo revela somente o que é suscetível a mudanças, os detalhes ocultos das interfaces dos módulos são secretos, esse é o princípio do ocultamento da informação. As interfaces públicas podem ser acionadas de qualquer outro módulo, por um conjunto de procedimentos de acesso e permitem que um módulo interaja com uma informação encapsulada de outro módulo. Abaixo são listadas as metas especificas para a decomposição:
Cada módulo deve ser simples o bastante para que possa ser plenamente entendido Deve ser possível modificar um módulo sem ter conhecimento da implementação dos
outros módulos e sem afetá-los (Bass, 2006).
O uso da técnica de ocultamento de informação traz maiores benefícios quando são necessárias modificações na fase de testes e após quando for necessária manutenção. Como a maior parte dos dados e procedimentos estão ocultas de outras partes do software, erros oriundos das modificações são menos prováveis de serem propagados para outros locais do software (Pressman, 2006).
2.3.1.2 Estrutura de Usos
As unidades dessa estrutura também são os módulos, procedimentos ou recursos das interfaces dos módulos. A estrutura de uso pode ser utilizada por engenheiros de sistemas que facilmente podem estender e adicionar funcionalidades ou a partir das quais subconjuntos funcionais podem ser extraídos. Isso possibilita um desenvolvimento incremental.
A estrutura de decomposição não fornece nenhuma informação sobre a interação no software em tempo de execução. Para esses casos a responsável por essas interações é a estrutura de uso, preocupando-se com as relações entre os módulos através dos procedimentos que são invocados por eles. A estrutura de usos tem a responsabilidade de ditar quais os procedimentos estão autorizados ou não a utilizar outros procedimentos (Bass, 2006).
2.3.1.3 Camadas
Quando as relações da estrutura de uso são cuidadosamente controladas, surge um sistema de camadas que nada mais é que um conjunto coerente de funcionalidades relacionadas (Bass, 2003).
O conceito camadas se tornou mais visível a partir de década de 90 com o surgimento dos sistemas cliente-servidores. Os sistemas funcionavam em duas camadas onde a camada cliente era responsável por mostrar a interface com o usuário e algum código da aplicação e a camada servidor era normalmente um banco de dados relacional.
Uma camada é um elemento de uma grande parte do sistema como classes, pacotes e subsistemas e com responsabilidade coesiva. Essas camadas trabalham de tal forma que as mais altas solicitam serviços para as mais baixas (Larman, 2007).
Segundo Bass (2003), em uma estrutura estritamente em camadas, a camada n só pode utilizar serviços da camada n-1. As camadas geralmente são pensadas como abstrações escondendo detalhes de implementação abaixo das camadas superiores, gerando portabilidade, a Figura 5 ilustra uma estrutura em camadas. Para Larman (2007) em sistemas de informação as camadas mais altas podem solicitar informação de várias camadas mais baixas, nesse caso a camada de IU poderia solicitar um serviço diretamente para as camadas de serviços técnicos, essa forma é denominada uma estrutura em camadas relaxada. Cada camada devem ter interesses semelhantes e são geralmente dividas em três camadas principais, interface com usuário, regras de negócio e persistência.
Figura 5 – Diagrama de Pacotes da arquitetura Lógica em camadas
Fonte: Larman, 2007
Interface com Usuário (IU) – como o nome já diz essa camada oferece condições para que o usuário execute as tarefas no sistema (Larman, 2007). Essa camada tem a responsabilidade de traduzir ações do usuário em comandos que possam interagir com as camadas de domínio e a camada de fonte de dados (Fowler, 2006).
Regras de Negócio – Essa camada contém objetos de software que representam os conceitos de domínio que satisfazem os requisitos da aplicação (Larman, 2007). Envolve cálculos baseados na entrada de dados e nos dados armazenados, validação de qualquer dado proveniente da camada de aplicação e com a compreensão exata de qual lógica executar dependendo dos dados recebidos da camada de apresentação (Fowler, 2007).
Persistência (Fonte de Dados) – são objetos com propósitos gerais oferecendo serviços técnicos de apoio assim como conexão com o banco de dados e registro de erros. Essa camada geralmente independe da aplicação e podem ser reusáveis em outros sistemas (Larman, 2007). Para Fowler, esta camada na maioria das aplicações é um banco de dados responsável, antes de tudo, pelo armazenamento de dados persistentes (Fowler, 2007).
Um projeto em camadas tem o objetivo de organizar a estrutura lógica de forma coesa e com separação de interesses. Dessa forma cada camada tem responsabilidades distintas sendo as camadas inferiores de baixo nível e as superiores mais específicas da aplicação. O acoplamento ocorre das camadas superiores para as inferiores o que possibilita a reutilização das camadas inferiores em outras aplicações como, por exemplo, a utilização em plataforma web (Larman, 2007).
2.3.1.4 Estrutura de Classe ou generalização
As unidades modulares nesta estrutura são chamadas de classes. Este ponto de vista se baseia no conceito de herança onde objetos que tem comportamento e capacidades semelhantes podem herdar atributos de outros objetos. Essas são denominadas subclasses. A estrutura de classes permite o reuso e adição incremental de novas funcionalidades (Bass, 2006).
Para Sommerville (2006), a abordagem orientada a objetos é comum hoje em dia, principalmente para desenvolvimento de sistemas interativos. Isto significa desenvolver o sistema pensando em um modelo de objetos, utilizando objetos e programando em linguagem orientada a objetos, como Java ou C++. “A decomposição orientada a objetos diz respeito às classes de objetos, seus atributos e suas operações” (Sommerville, 2006).
Mendes faz uma analogia considerando uma empresa que possui diversos departamentos como, por exemplo, vendas, contabilidade, onde cada departamento possui seu pessoal e tarefas associadas. Cada departamento possui seus próprios dados e cada pessoa que faz parte dele atua sobre os seus dados. Dessa forma, ao dividir a empresa em departamento se torna mais fácil compreender suas necessidades e melhora o seu controle. A abordagem orientada a objetos permite a organização de programas ao mesmo tempo em que ajuda a
manter a integridade dos dados do sistema. Em um projeto orientado a objetos, os projetistas podem encapsular dados, dessa forma teríamos a ocultação de informações (Mendes, 2002).
A estrutura arquitetural de classes enxerga o sistema como um conjunto de objetos que se comunicam através de canais de comunicação. Nesse caso quando um objeto necessita se comunicar com outro, este deve conhecer a identidade do objeto ao qual enviará a mensagem, conforme ilustra a Figura 6, onde existe uma troca de informação entre os objetos (Mendes, 2002).
Figura 6 – Arquitetura de um Projeto Orientado a Objetos
Fonte: Mendes, 2002
Uma desvantagem em ter a obrigatoriedade de conhecer a identidade dos objetos para se comunicar pode ser em relação ao reuso, pois em cada mudança deve-se alterar a especificação das classes. Além disso, se a manutenibilidade for um atributo de qualidade considerado importante deve-se pensar que qualquer manutenção necessária deve afetar um número reduzido de objetos. Ainda no quesito atributos de qualidade se for levado em conta o desempenho do sistema em cada cenário de uso mais frequente deveria ocorrer em um número menor de objetos. Minimizando a comutação de contexto, o que poderia vir a comprometer o desempenho do sistema (Mendes, 2002).
2.3.2 Componentes e Conectores
Nessa estrutura os elementos são componentes em tempo de execução e os conectores são o veículo de comunicação entre esses componentes. A estrutura componentes e conectores permite responder as seguintes questões: Quais são os principais componentes de execução e como eles interagem? Quais partes do sistema podem rodar em paralelo? (Bass, 2006)
Segundo Bass (2006) existe um grande número de alternativas para documentar esta estrutura em UML. Para ele uma candidata para representar a estrutura componentes e conectores é demonstrada na Figura 7.
Figura 7 – Representação de camadas em UML
Fonte: Bass, 2006
Bass (2006) divide esta estrutura em diferentes padrões:
a) Cliente-servidor onde os componentes são os clientes e servidores e os conectores são os protocolos e mensagens que eles compartilham para realizar os trabalhos do sistema.
b) Concorrência que permite ao arquiteto determinar onde o paralelismo pode ocorrer, nesse caso as unidades são threads lógicas. As threads lógicas podem ser executadas separadas das threads físicas. É utilizada no início do projeto para identificar os requisitos as questões que envolvem execução simultânea.
c) Processos que permitem aos engenheiros de software darem desempenho e alta disponibilidade para o software através de visão física de como o software está implementado.
d) Dados Compartilhados ou Repositório compreende a criação, armazenamento e acesso aos dados. Mostra como os dados são produzidos e consumidos por elementos de software em tempo de execução e são utilizadas para assegurar um bom desempenho e integridade dos dados.
2.3.2.1 Estrutura Cliente-Servidor
A estrutura cliente-servidor é uma boa prática quando o sistema é composto por um grupo de cliente e servidores. Basicamente consiste na separação de interesses (manutenibilidade) para uma distribuição física e balanceamento de carga (desempenho em tempo de execução) (Bass, 2006).
A utilização do termo Cliente-Servidor não necessariamente se refere a um mapeamento 1:1, em geral se refere processos lógicos e não a computadores físicos nos quais esses processo são executados (Sommerville, 2006)
Coulouris (2007) cita também que servidores podem ser clientes de outros servidores, servidores web e a maioria dos outros serviços de internet são clientes do serviço DNS (Domain Name System). A Figura 8 demonstra um sistema multiusuário baseado na internet para fornecimento de uma biblioteca de filmes e fotos.
Figura 8 – Sistema Cliente-Servidor
Segundo Mendes (2002) a tecnologia cliente-servidor é tradicionalmente implementada de duas formas:
a) Arquitetura Cliente-Servidor de duas camadas (two-tier-client-server) – esse tipo de sistema exige uma interface cliente para executar a aplicação e um servidor de banco de dados para gerenciar as transações. É fácil de ser gerenciado, mas quando o volume de transações é baixo, além de exigir que o cliente execute uma grande quantidade de funcionalidades tornando-o grande e complexo.
b) Arquitetura Cliente-Servidor de Múltiplas camadas (multi-tier-client-server) – Nessa arquitetura o problema que acontece na arquitetura cliente-servidor de duas camadas foi resolvido, com ela a parte da lógica específica da aplicação é movida para uma camada central. Essa camada é composta de um servidor de aplicação que é responsável pela mediação entre clientes e recursos. Com isso os projetistas podem buscar um melhor desempenho da aplicação e a diminuição das funcionalidades que antes eram executadas pelos clientes (Mendes, 2002).
2.3.2.2 Concorrência
Bass (2006) define concorrência por processamento de diferentes fluxos de eventos em diferentes threads ou pela criação de threads adicionais para processar um conjunto diferente de atividades.
Para Fowler (2006) a concorrência é um dos aspectos mais problemáticos no desenvolvimento de software, sempre que se têm múltiplos processos ou threads manipulando os mesmos dados, pode-se deparar com problemas de concorrência. Para ele é muito difícil levantar todos os possíveis cenários que podem ocasionar erros e, além disso, é difícil de testar. (Fowler, 2006).
Segundo Bass (2006), na visão de concorrência podem ser modeladas atividades paralelas e sincronização. Esta modelagem vem a ajudar na identificação de problemas como deadlocks (ocorrem quando duas ou mais tarefas bloqueiam uma à outra permanentemente), questões de consistência de dados, entre outros. Nesta estrutura os componentes são instancias de módulos e os conectores são as threads virtuais (descreve a execução do sistema ou parte dela), que não devem ser confundidas com threads de sistema ou processos que implicam em outras propriedades como alocação de memória e processadores (Bass, 2006).
Fowler (2006) cita duas soluções importantes para problemas de concorrência: isolamento e imutabilidade. Por meio de isolamento somente um agente ativo pode alterar o dado, isto é, se o usuário “a” estiver editando um arquivo o usuário “b” pode visualizar, mas não podem alterá-lo. Para Fowler (2006), só se tem problema de concorrência quando dados que estiverem sendo compartilhados puderem ser modificados, uma maneira de evitar conflitos é não permitir que os dados imutáveis sejam alterados. Para ele a identificação de dados como imutáveis ou quase todo o tempo como imutáveis, pode-se relaxar a preocupação com a concorrência.
Quando existem dados mutáveis que não se pode isolar, Fowler (2006) cita duas formas: bloqueio otimista e pessimista.
a) Bloqueio Otimista – caso dois usuários queiram editar um arquivo, ambos fazem uma cópia do arquivo e podem editar livremente. O primeiro que terminar, grava o seu trabalho, já o segundo quando tenta gravar sua confirmação é rejeitada, pois o sistema percebe um conflito.
b) Bloqueio Pessimista – no caso do pessimista o primeiro que edita o arquivo já inviabiliza que o segundo possa editar, até que o primeiro finalize suas modificações (Fowler, 2006).
2.3.2.3 Processos
Essa unidade se preocupa com os aspectos dinâmicos da execução do sistema. As unidades são processos ou threads físicas, que são conectadas umas as outras por comunicação, sincronização e/ou operações de exclusão. Esta relação mostra como os componentes e conectores são anexados (Bass, 2006). A Estrutura de Processo não é objeto desta pesquisa.
2.3.2.4 Dados Compartilhados ou Repositório
Para Mendes (2006) uma estrutura de dados compartilhados ou repositório possui dois componentes básicos, um conjunto de dados compartilhados e um conjunto de clientes independentes que tem acesso e atualizam este repositório (Mendes, 2006).
Segundo Pressman (2006) nesta estrutura o repositório de dados fica no centro e dá suporte a outros componentes que atualizam, adicionam, retiram ou modifica os dados contidos no repositório, um exemplo típico é ilustrado na Figura 9.
Figura 9 – Arquitetura de Repositório
Fonte: Pressman, 2006
Mendes (2002) e Pressman (2006) citam duas variantes em relação à arquitetura de repositório, passivo e ativo. No repositório passivo o software-cliente tem acesso aos dados independentemente de quaisquer mudanças nos dados ou nas ações dos outros clientes. (Pressman, 2006). Já no repositório ativo que também pode ser chamado de Quadro Negro a base de dados compartilhada notifica os clientes que estão conectados, a respeito das mudanças ocorridas e que possam interessar a eles (Mendes, 2002).
Como mostrou a Figura 9, a topologia da arquitetura de repositório é tipicamente em estrela e tem como principal característica o suporte que oferece a qualidade de integração (Mendes, 2002).
2.3.3 Alocação
A estrutura de alocação estabelece um relacionamento entre os elementos de software e um ou mais elementos de ambientes externos, onde o software é criado ou executado. Ela responde as seguintes questões: Em quais arquivos cada elemento deve ser armazenado durante o desenvolvimento, testes e construção do sistema? Qual é a atribuição de elementos
de software para as equipes de desenvolvimento? Em qual processador cada elemento de software deve executar? (Bass, 2006).
Bass (2006) divide a estrutura de alocação em: Desenvolvimento, Implantação e Atribuição de Trabalho.
2.3.3.1 Estrutura Desenvolvimento
A estrutura de desenvolvimento mostra como o software é atribuído no hardware disponível e os elementos de comunicação. Como vão residir os elementos de software fisicamente. Essa estrutura permite ao engenheiro pensar em desempenho, integridade de dados, disponibilidade e segurança. Particularmente em sistemas distribuídos ou paralelos (Bass, 2006). Para Kruchten (2000) a estrutura de desenvolvimento mostra como vários executáveis e outros componentes em tempo de execução são mapeados para plataformas adjacentes ou nós de computação abordando questões de instalação, implantação e desempenho.
A estrutura de desenvolvimento ajuda a determinar a alocação de componentes de software no hardware disponível, pode se utilizar táticas como replicação, oferendo auxilio na obtenção de alto desempenho ou confiabilidade com a implantação de replicas em diferentes processadores (Bass, 2006).
Para se representar uma visão de desenvolvimento se utiliza um diagrama como um gráfico de nós ligados por associações de comunicação. Os nós contem componentes que por sua vez, podem conter objetos aos quais indicam que objetos fazem parte dele. Um nó é um objeto físico em tempo de execução que representa os recursos de processamento, geralmente tendo o mínimo de memória e frequentemente a capacidade de processamento. Eles podem ser conectados por associação a outros nós, a qual indica o caminho de comunicação entre eles. A associação pode ter um estereótipo para indicar a natureza do caminho da comunicação (por exemplo, o tipo de canal ou rede). Na visão demonstrada na Figura 10, existem quatro camadas físicas representadas por camada cliente, web, componentes de negócio e informações corporativas. A camada cliente é responsável pela apresentação tanto no browser (comunicando-se com a camada web) como em aplicações desktop ou aplicações clientes Java (que se comunicam diretamente com a camada de negócio). A camada web que roda como um servidor web lidando com requisições e respostas dos clientes invocando JEE
servlets ou Java Server Pages (JSP). Camada de Componentes de Negócio que compreendem a lógica de negócio para a aplicação e a camada de sistemas de informações corporativas, que consiste de uma ou mais base de dados e aplicação de retaguarda como mainframes e sistemas legados (Bass, 2006).
Figura 10 – Visão de Desenvolvimento da arquitetura JEE em múltiplas camadas
Fonte: Bass, 2006
2.3.3.2 Estrutura de Implantação
A estrutura de implantação se preocupa em como os elementos de software serão mapeados na estrutura de arquivos no desenvolvimento do sistema. Isso é crítico para as atividades de desenvolvimento e construção de processos (Bass, 2006).
Kruchten (2000) descreve a visão de implantação como uma organização estática dos módulos do software como: código fonte, arquivos de dados, componentes, executáveis, entre outros. Referindo-se a um ambiente de desenvolvimento seriam pacotes e camadas já em um ambiente de configuração, como propriedades e estratégias de liberação.
Segundo Bass (2006) a estrutura de implantação exibe, se a arquitetura está em conformidade com as decisões de design que foram descritas por ela. Significa que a visão de implantação deve ser divida nos elementos prescritos, aos quais devem interagir uns com os
outros cumprindo com as suas responsabilidades, conforme foi descrito na arquitetura. Normalmente a visão de implantação é representada em camadas, sendo que estas camadas podem variar de acordo com as exigências da aplicação. Na Figura 11 é demonstrado um sistema de banco com quatro camadas. A camada superior contém serviços específicos dos aplicativos. A camada de negócio contém a lógica de negócio que pode ser utilizada em diversos aplicativos. A camada middleware contém componentes como construtores de interface com o usuário, interfaces com banco de dados, serviços de sistemas operacionais, entre outros. A camada mais inferior diz respeito a componentes como sistemas operacionais e interfaces para hardware específico (RUP).
Figura 11 – Visão de Implantação de um sistema Bancário
Fonte: RUP, 2002
2.3.3.3 Atribuição de Trabalho
Esta estrutura tem a responsabilidade de atribuir as equipes apropriadas a implementação e integração dos módulos. Também em grandes projetos de desenvolvimento distribuído pode-se utilizar a estrutura de atribuição de trabalho para designar o desenvolvimento de certos tipos de funcionalidades especificas a apenas uma única equipe, ao
invés de tê-las implementadas por todas que precisam dela. Esses tipos de funcionalidades compreendem programas e dados que são privados e certamente subdivido em equipes de trabalho. Nesses casos o arquiteto deverá possuir conhecimento suficiente a respeito das competências de cada equipe, a fim de atribuir corretamente o trabalho a ser executado (Bass, 2006).
2.4 ARQUITETURA DE SOFTWARE PARA SISTEMAS INTERATIVOS
Sistemas Interativos requerem uma equipe de projeto atuando em uma diversidade de tarefas estruturadas em um processo. Um sistema interativo pode ser decomposto em duas grandes partes de software: software de aplicação e software de interface com o usuário. O software de aplicação diz respeito a toda funcionalidade do sistema enquanto que a interface com o usuário tem a responsabilidade de mediar à comunicação entre o usuário e a aplicação. A decomposição de um sistema interativo é elucidada na Figura 12 (Mendes, 2002).
Figura 12 – Decomposição de um sistema interativo
Fonte: Mendes, 2002
Para Pressman (2006), muitos autores sugerem um projeto de arquitetura que desacople a interface do usuário do comportamento da aplicação com o argumento que manter a interface, aplicação e navegação separadas simplifica a implementação e aumenta o reuso. Para ele a arquitetura Modelo-Visão-Controlador (MVC) é uma das arquiteturas que possuem esse princípio.
Mendes (2002) cita que o desenvolvimento dessas arquiteturas coincidiram com o desenvolvimento de diversos tipos de ferramentas (bibliotecas de classe do MVC) e de sistemas de janelas (Arquitetura Seeheim). Os frameworks de aplicação derivaram de um extensão lógica de bibliotecas de classes, além de toolkits e toolkits virtuais. Esses duas
variantes de desenvolvimento evoluíram até chegar numa junção chamada de PAC-Amodeus. O processo evolutivo das arquiteturas de softwares interativos é ilustrado na Figura 13.
Figura 13 – Evolução das arquiteturas e software de interfaces com usuário
Fonte: Mendes, 2002
A seguir serão apresentadas as principais arquiteturas de sistemas interativos segundo Mendes (2002), além de outras arquiteturas com menor importância que também serão discutidas.
2.4.1 MVC (Modelo Visão Controlador)
Segundo Fowler (2006) o MVC é um dos padrões mais citados. Surgiu como um framework desenvolvido por Trygve Reenskaug para a plataforma Smaltalk no final dos anos 70. A partir de então tem tido um papel influente na maioria dos frameworks com interface para usuário.
Mendes (2002) menciona que MVC é um modelo baseado em agentes. Os agentes tem um estado, possuem conhecimento bem como, são capazes de inicializar ou reagir a eventos.
Na arquitetura MVC um agente é visto sobre três perspectivas funcionais, Figura 14: Modelo – Este modelo representa o conhecimento do domínio da aplicação e contém
os componentes do sistema que fazem o trabalho real. Por exemplo, o comportamento do aplicativo principal de um sistema de finanças pessoais com as contas, clientes, transações.
Visão – Dependendo do usuário essa camada pode prover diferentes perspectivas. Portanto devem oferecer distintas visões do modelo. Tal visão atua como um filtro destacando alguns atributos para um usuário e suprimindo para outro. Por exemplo, um usuário iniciante não possui as mesmas informações que um usuário administrador. No exemplo do aplicativo de finanças, enquanto uma visão mostra uma listagem de uma determinada conta na outra exibe apenas um gráfico pizza. Em ambas as visões usam os mesmos dados, entretanto exibindo de formas diferentes.
Controlador – O controlador atua como uma interface entre o modelo associado com a sua visão e os dispositivos de interface do usuário. Na atual interpretação é considerado mediador entre o modelo e a visão. Fazendo com que a visão seja responsável pelos dispositivos de entrada e saída e o controlador por mudanças de estado exibição e as ações na interface do usuário e vice-versa. Por exemplo, no aplicativo de finanças pessoais, executando uma rotina na interface do usuário vai refletir nos dados desse aplicativo. Da mesma forma uma alteração da base de dados por aplicativos externos também irá alterar a interface do usuário (Larman, 2007).
Figura 14 – Modelo Visão Controlador
Fonte: Fowler, 2006
Fowler (2006) considera duas separações principais no padrão MVC: separar a apresentação do modelo e separar o controle da vista.
a) Separar a apresentação do modelo – é umas das mais importantes e fundamental para um bom projeto de software por algumas razões, principalmente por se referirem a preocupações diferentes. Quando se está desenvolvendo uma visão, a preocupação é construir uma boa interface com o usuário, já quando se está trabalhando no modelo o pensamento é com as políticas de negócio, inclusive com interações com banco de
dados. Além disso a separação da apresentação do modelo permite desenvolver interfaces completamente diferentes, o mais notável disso é que o mesmo modelo poderia ser fornecido para clientes ricos, navegador web, desktop e mesmo dentro de uma única interface web poderiam ter diferentes páginas de clientes em diferentes pontos de uma aplicação.
b) Separar a vista do Controlador – Fowler (2006) considera uma divisão menos importante. Isto seria útil quando o sistema possuísse uma visão com dois controladores. Porém na prática a maioria dos sistemas tem apenas uma visão por controlador, dessa forma esta separação não era implementada. Ela se torna útil para sistemas com interface web.
O componente controlador no MVC utiliza um mecanismo de notificação para assegurar que as mudanças no modelo sejam refletidas na visão e vice versa. Como os valores da interface com o usuário mudam estes poderiam mudar os dados no modelo. Além disso, ações de usuário na interface certamente mudarão o comportamento do modelo, e por sua vez também implicaria em mudança nos dados do modelo. Quando uma mudança é percebida na interface esta deveria ser percebida em todas as visões de modelo e não somente na visão que inicializou a mudança. O modelo assim notifica todas suas visões, que por sua vez podem consultar o modelo por informações e atualiza-las se necessário (Fowler, 2006).
2.4.2 Arquitetura Seeheim
Segundo Mendes (2002), vários autores citam a arquitetura Seeheim como uma das mais conhecidas arquiteturas de interface. A arquitetura Seeheim é composta de três componentes: apresentação, diálogo e interface de aplicação. O componente de controle de diálogo tem a responsabilidade do processamento e sequenciamento do diálogo, em sua essência é um organizador do tráfego entre os componentes de apresentação e os componentes específicos da aplicação. O componente de interface com a aplicação possui uma visão da interface sob a perspectiva da aplicação e uma visão da aplicação sob a perspectiva da interface. Isso quer dizer que é encarregada de tratar a comunicação existente entre a interface e o restante do sistema interativo. O componente de apresentação lida com a representação da interface com os usuários, isto é, dispositivos de entrada e saída, layout de tela, entre outros. Pode se notar Figura 15 que demonstra a arquitetura Seeheim que existe uma pequena caixa
que possibilita um desvio da informação desviando o fluxo para outro caminho. Isso pode ocorrer para desviar o fluxo do componente de controle a fim de melhorar o desempenho. (Mendes, 2002).
Figura 15 – Arquitetura Seeheim
Fonte: Mendes, 2002
A arquitetura Seeheim tem a vantagem de abordar explicitamente o problema de independência de diálogo, contudo tem uma desvantagem que é a complexidade dos três componentes em sistemas de grande porte (Mendes, 2002).
2.4.3 Arquitetura Arch/Slinky
Para Mendes (2002) esta arquitetura pode ser vista como uma extensão da arquitetura Seeheim. Ela é composta por cinco elementos que serão vistos a seguir e é ilustrada na Figura 16.
a) Componente específico de domínio – É responsável pela manipulação dos dados e outras funções orientadas ao domínio. As funções são expostas ao usuário através da interface (Mendes, 2002).
b) Componente adaptador de domínio – Agrega dados específicos de domínio em estruturas de níveis mais elevados, faz a checagem semântica dos dados e aciona tarefas de diálogo do domínio e relata erros semânticos. É similar à interface na arquitetura Seeheim (Mendes, 2002).
c) Componente de diálogo – É responsável por mediar componentes específicos do domínio com componentes específicos da apresentação. Além disso, assegura a consistência entre múltiplas e visões e sequenciamento de tarefas (Mendes, 2002).
d) Componente de apresentação – Fornece um conjunto de objetos para o componente de diálogo e pode ser visto como um componente lógico de interação (Mendes, 2002). e) Componente do toolkit de interação – Responsável por implementar interação física
entre o usuário e o computador, lida com entradas e saídas e pode ser chamado de componente físico de interação (Mendes, 2002).
Figura 16 – Arquitetura Arch/Slinky
Fonte: Mendes, 2002
A arquitetura Arch/Slinky tem a meta de estabelecer um equilíbrio entre o desenvolvimento e as funcionalidades exigidas por um sistema. Essa arquitetura foi projetada objetivando minimizar efeitos de futuras modificações no toolkit de interação, diálogo de interface com o usuário e domínio de aplicação, além da atribuição de funções heterogêneas a componentes distintos para que qualquer modificação cause o mínimo impacto possível a outros componentes do sistema. Com tudo isso essa arquitetura não atende a alguns critérios como: desempenho do sistema, simplicidade conceitual, reuso de código, atendimento de requisitos funcionais, qualidade da interface com o usuário, entre outros (Mendes, 2002).
