Conceitos utilizados para construção do framework

Nesta seção são apresentadas as tecnologias de desenvolvimento de software e orientação a objetos, modelagem através da linguagem UML concluindo com a definição e características de um framework.

2.2.1.1. Orientação a objetos

O termo orientação a objetos refere-se à organização de programas de computador em objetos discretos. O objetivo é aproximar a representação computacional o mais próximo da realidade. O conceito de objeto é uma abstração ou simplificação do objeto real. Um objeto é uma entidade que pode representar objetos concretos como carro, bola, cadeira, etc. Também pode representar entidades conceituais como estratégia de jogo, política de escalonamento de recursos, etc. (FERREIRA, 2005).

Um objeto possui uma identificação única e sua estrutura é representada por atributos que representam as características daquele objeto como cor, tamanho, etc. O comportamento é representado por um conjunto de operações que podem ser executadas sobre os atributos do objeto.

Os objetos que possuem a mesma estrutura e comportamento são agrupados em uma mesma classe. Um objeto é um instância de uma classe e cada objeto possui seu conjunto de valores de seus atributos (BOOCH;JACOBSON;RUMBAUGH, 1999).

A separação dos aspectos internos do objeto com os externos, os quais podem ser acessados por outros objetos, foi definida como encapsulamento. O encapsulamento é uma forma que evita que o programa torne-se tão interdependente que uma pequena mudança tenha grandes efeitos na aplicação. O encapsulamento permite que o objeto seja modificado internamente sem afetar outros objetos que o utilizam.

Outro conceito fundamental do desenvolvimento de software orientado a objetos está no conceito de herança, que permite que as classes sejam desenvolvidas em níveis de

especialização. A classe que herda de outra classe aproveita as definições de atributos e operações. Como exemplo, pode-se citar uma classe com veículo de transporte, sendo especializado em transporte terrestre, náutico ou aeronáutico, podendo ainda possuir mais níveis de especialização como por exemplo, em veículos terrestres sendo especializados em veículos de carga e passageiros e assim sucessivamente em função da necessidade e do objetivo do software que está sendo desenvolvido (SILVA, 2000).

O último conceito fundamental do desenvolvimento de software orientado a objetos é o conceito de polimorfismo, cuja palavra de origem grega significa: muitas formas. É principalmente útil quando não se sabe que objeto será necessário, mas se conhece apenas a “família”. Considerando o conceito de herança, portanto poderia se definir que será necessário um veículo de transporte o que possibilita que seja instanciado qualquer objeto descendente desta classe, flexibilizando o processo de desenvolvimento do software.

Outras características como a possibilidade de criação de classes abstratas, a implementação de interfaces para classes e a herança de múltiplas classes podem ser encontradas em (BOOCH;JACOBSON;RUMBAUGH, 1999) ou no site da OMG (Object

Management Group).

2.2.1.2. UML (Unified Modeling Language)

A linguagem UML nasceu da necessidade de uma notação padronizada para o desenvolvimento de software orientado a objetos principalmente nas fases de levantamento de requisitos, análise e design. Foi a junção de diversas técnicas de modelagem OMT(Object

Modeling Technique), Booch, entre outras, desenvolvida por Grady Booch, James Rumbaugh,

e Ivar Jacobson. Em 1997 foi submetida ao OMG (Object Management Group) a qual aprovou e ficou responsável pelo desenvolvimento e padronização da linguagem.

A UML é um conjunto de notações gráficas que auxiliam a visualização, especificação, construção e documentação de sistemas de software. Para novos sistemas a UML fornece diversos diagramas para projetar software, permitindo verificar se o projeto está completo e correto (BOOCH;JACOBSON;RUMBAUGH, 1999).

No total a UML possui treze diagramas que são classificados em estrutural e comportamental. Dentre os treze diagramas será apresentado a seguir apenas parte do diagrama de classe utilizado neste trabalho.

O diagrama de classes ilustra as especificações para as classes de software e de interface de uma aplicação e contém as seguintes informações: classes (associações e atributos), interfaces (com suas operações e constantes), métodos, informações do tipo do atributo.

Uma classe é a descrição de um tipo de objeto. Todos os objetos são instâncias de classes, onde a classe descreve as propriedades e comportamentos daquele objeto. Usam-se classes para classificar os objetos que são identificados no mundo real.

A representação gráfica em UML para uma classe possui três seções, sendo a primeira com o nome da classe, a segunda com os atributos e a terceira com as operações relativas a classe (Figura 4).

Figura 4 - Representação gráfica de uma classe. Adaptado de: (BOOCH;JACOBSON;RUMBAUGH, 1999)

As classes possuem relações que podem ser de: associação, especializadas, dependência, realização ou uso (BOOCH;JACOBSON;RUMBAUGH, 1999). Apenas os tipos de relação utilizados no framework serão citados a seguir:

A diferença entre as relações de agregação e composição determinam no caso da composição que não existe o todo sem a parte, ou seja no exemplo da Figura 5 os objetos instanciados da classe Pedido não podem existir sem os objetos das classes Cliente e Itens do Pedido. Diferente da relação existente entre as classes Assinatura e Desempenho onde os objetos da classe Assinatura existem mesmo sem a existência de um objeto da classe Desempenho.

Figura 5 - Agregação e composição de classes. Adaptado de: (BOOCH;JACOBSON;RUMBAUGH, 1999)

A relação de herança exemplificada entre as classes da Figura 6, apresentam as classes especializdas Texto Criptografado e Texto Sem Criptografia, ou seja, todas são classes derivadas da classe Texto, portanto herdam os atributos Corpo e Posição como suas operações, sendo que as classes derivadas tem sua implementação especializada para cada objetivo.

Figura 6 - Herança de Classes

Adaptado de: (BOOCH;JACOBSON;RUMBAUGH, 1999)

2.2.1.3. Framework

O framework conceitual é o resultado do processo qualitativo de teorização e pode ser compreendido como uma rede de conceitos que juntos oferecem a compreensão abrangente de um fenômeno. Em outras palavras pode ser entendido como uma rede de conceitos organizados

para representar entidades do mundo real. A seguir são apresentadas algumas características de um framework (YOSEF, 2009):

 Um framework conceitual não é apenas um conjunto de conceitos, mas uma construção em que cada conceito tem seu papel integral;

 Apresenta uma intepretação da realidade;

 É indeterminista por natureza e, portanto, não permite prever um resultado;  Frameworks conceituais são criados sobre um determinado domínio e fornecem

uma compreensão da arquitetura de forma diferente de modelos quantitativos. Para exemplificar o uso de frameworks conceituais, Yosef (2009) apresenta em seu trabalho um framework para o desenvolvimento sustentável.

Outros frameworks conceituais são bastante utilizados na gestão empresarial. Como exemplo pode-se citar os frameworks de arquitetura corporativa TOGAF e Zachman, framework para análise de forças SWOT, frameworks de gestão e qualidade de dados DMBok, para gerenciamento de projetos ágeis como Scrum, entre outros (IIBA, 2011; CARVALHO;ABRANTES;CAMEIRA, 2011; DAMA, 2010).

O frequente uso do termo framework no Desenvolvimento de software segue os princípios de orientação a objetos. Abaixo são citados algumas referências sobre framework.

Hautamäki (2005) propôs como definição para framework um esqueleto de implementação de uma aplicação ou de um subsistema em um domínio de problema em particular. É composto por classes concretas ou abstratas e define um modelo de interação ou colaboração entre as instâncias de classes definidas pelo framework, citando a seguir as principais vantagens do uso de framework.

 Reusabilididade de código comum;

 Armazenamento da experiência do desenvolvimento;  Distribuição de trabalho entre equipes;

 Melhoria do ciclo de desenvolvimento de software;  Redução do trabalho de manutenção do software.

Hautamäki (2005) também cita os principais problemas com o uso de framework.  Dificuldade em criar framework reutilizável para domínios complexos;  Pode aumentar a curva de aprendizado;

 Trabalho com múltiplos framework integrados podem ser muito difícil;  Aplicações com grande quantidade de manutenções podem ser complexos;

 Validação e depuração de código é mais difícil;  Eficiência pode ser prejudicada;

 Não existem padrões para a definição e documentação específicas para

framework.

Diferente de uma biblioteca de classes onde a relação entre as classes fica a cargo da aplicação, em um framework já está definido o papel de relações entre as classes. Por outro lado os framework são mais dependentes do domínio do problema (TALIGENT, 1994).

Framework oferece infraestrutura de projeto permitindo ao desenvolvedor reduzir o esforço. As interconexões estabelecidas definem a arquitetura da aplicação. O desenvolvedor faz uso do framework estendendo e moldando as suas necessidades específicas (DIAS, 2004).

Pode-se concluir que o objetivo do framework é desenvolver diferentes aplicações de software para um domínio específico. Classes abstratas no framework é um repositório de conceitos gerais para o domínio da aplicação. Em contexto do desenvolvimento de framework pode se deixar propositalmente incompleto para que sua definição seja acabada no desenvolvimento da aplicação (SILVA, 2000).