Prof.

Romário Lopes Alcântara - Unijuí - Universidade de Ijuí - Curso de Ciência da Computação e Engenharia de Software 1
Modelos e Métodos de Processo em Engenharia de Software - Capitulo 4 – Modelos de Processos Especializados

4 Modelos de Processos Especializados

Neste item será abordo de forma muito sucinta os seguintes tópicos, com o intuito
de dar um breve conhecimento a quem precisar saber sobre tais tópicos, devendo se
aprofundar bem no tema caso precise:

- Desenvolvimento Baseado em Componentes

- O modelo de métodos formais
- Desenvolvimento orientado a aspectos

4.1 Desenvolvimento Baseado em Componentes

Com o advento do uso de componentes previamente prontos o desenvolvimento do

software se tornou mais rápido e seguro pelo fato de que um retrabalho não seria feito e os
módulos utilizados já estavam bem testados, um fator bem importante da reuzabilidade de
partes do software,

Conforme Werner e Braga (2019) as autoras citam que como:

Histórico:
- 1969, McIlRoy já vislumbrava uma indústria de componentes de
software reutilizáveis
- linguagens de interconexão de módulos, em 1976
- abordagens até então se baseavam fortemente em código

Atualmente: novo impulso para DBC

- Internet
- Arquitetura cliente/servidor
- Modelos de componentes: CORBA, COM

As mesmas autoras citam que como objetivo e dificuldade tem-se:

Objetivo:
- Quebra de blocos monolíticos em componentes interoperáveis;
- Componentes são construídos/empacotados com o objetivo de serem
reutilizados em diferentes aplicações;
- Um componente provê um conjunto de serviços acessíveis através de
uma interface bem definida.

Dificuldade:
- O que é de fato um componente?
- Que tecnologias estão envolvidas?
- Como desenvolver componentes?

Mas o que é componentes afinal?

Conforme Masiero (2019) tem-se que componentes são:

(MMPES_ C4_Modelo de Processo Especializado)

Prof. Romário Lopes Alcântara - Unijuí - Universidade de Ijuí - Curso de Ciência da Computação e Engenharia de Software 2
Modelos e Métodos de Processo em Engenharia de Software - Capitulo 4 – Modelos de Processos Especializados

Um componente de software é uma unidade de composição com

interfaces contratualmente especificadas e dependências de contexto
explícitas. Um componente de software pode ser implantado
independentemente e está sujeito a composição por terceiros.

É uma unidade executável independentemente.

Os serviços oferecidos são disponibilizados somente por meio de uma

interface.

Modelos de Componentes

- CORBA (OMG)
- COM+ (MICROSOFT)
- EJB: Enterprise Java Beans (SUN)
- Serviços oferecidos:

Desenvolvimento de componentes para reuso

•Visão de longo prazo: haverá um mercado de fornecedores de

componentes.
•Componentes desenvolvidos internamente não são em geral usáveis
imediatamente
•Para ser reusável, o componente deve ser tratado e isso tem um custo:
documentação, validação e generalização.
•Mudanças: remover métodos específicos, tornar nome mais geral, tratar
exceções, definir uma interface de “configuração” e integrar com outros
componentes

Objetivos dos componentes

• Complexidade
- Princípio “dividir e conquistar”

• Funções e dados combinados

• Motivação: gestão da mudança

- “construir para mudar”
- Ênfase durante arquitetura e projeto nas dependências entre
componentes e gestão das dependências

• Devem ser facilmente substituíveis

• Gestão da mudança x reuso

Formas de componentes

• Em tempo de execução o componente possui conteúdo (estado)

- Além dos serviços providos pelo componente, a informação gerenciada
também é importante
- Na substituição do componente deve-se garantir os serviços e as
informações

(MMPES_ C4_Modelo de Processo Especializado)

Prof. Romário Lopes Alcântara - Unijuí - Universidade de Ijuí - Curso de Ciência da Computação e Engenharia de Software 3
Modelos e Métodos de Processo em Engenharia de Software - Capitulo 4 – Modelos de Processos Especializados

Arquiteturas de Sistema e de Componentes

• Arquiteturas de sistema
- Estrutura das partes que compõem uma instalação completa de software
(incluindo responsabilidades, interconexões, etc)

• Arquiteturas de componente
- Um conjunto de componentes de software, seus relacionamentos
estruturais e suas dependências de comportamento (nível de aplicação)

Arquiteturas de Componentes

• O quanto um sistema é acoplado

• Efeitos da modificação ou substituição de um componente
• Relacionamentos estruturais
- Associações e heranças entre especificações e interfaces
- Relacionamentos de composição entre componentes
• Dependências de comportamento
- Dependências entre componentes, componentes e interfaces e
interfaces

Processo de especificação

• Identificação de componente

- Identifica um conjunto inicial de interfaces de negócios (componentes de

negócios) e interfaces de sistema (componentes de sistema)
- Junta as interfaces em uma arquitetura de componente inicial
- Operações que deverão ser apoiadas pelo sistema.

• Interação de componente

- Examina como cada operação do sistema será alcançada, usando a

arquitetura de componente
- Operações são movidas entre interfaces
- Detalhes completos da estrutura do sistema
- Entendimento das dependências entre componentes

• Especificação de componente

- Especificação detalhada das operações e restrições

- Para cada interface, definição dos potenciais estados dos objetos
componentes num modelo de informação de interface e especificação das
pré-e pós-condições das operações e captura dos papéis de negócio como
restrições

Para finalizar esta etapa sobre Desenvolvimento Baseado a Componentes Werner e

Braga (2019) citam que o repositório dos componentes se tem:

- Base preparada para o armazenamento e recuperação de componentes;

- Recuperação efetiva: informações adicionais relativas ao componente;

(MMPES_ C4_Modelo de Processo Especializado)

Prof. Romário Lopes Alcântara - Unijuí - Universidade de Ijuí - Curso de Ciência da Computação e Engenharia de Software 4
Modelos e Métodos de Processo em Engenharia de Software - Capitulo 4 – Modelos de Processos Especializados

- Três tipos de repositório:

- Repositórios locais
- Repositórios específicos a um domínio
- Repositórios de referência

4.2 O Modelo de Métodos Formais

Conforme Wikipédia (2019) se tem:

Na ciência da computação e engenharia de software, métodos

formais são técnicas baseadas em formalismos matemáticos para
a especificação, desenvolvimento e verificação dos sistemas
de softwares e hardwares.

Seu uso para o desenvolvimento de software e hardware é motivado pela

expectativa de que, como em outras disciplinas de engenharia, possam
contribuir para a confiabilidade e robustez de um projeto executando
análises matemáticas apropriadas.

Entretanto, o alto custo do uso dos métodos formais faz com que, de modo
geral, sejam usados apenas no desenvolvimento de sistemas de alta-
integridade, nos quais há alta probabilidade de as falhas provocarem perda
de vidas ou sério prejuízo.

A mesma fonte acima cita que quanto aos seus usos tem-se:

Métodos formais podem ser aplicados em vários pontos através

do processo de desenvolvimento. (Por conveniência, nós usamos termos
comuns para o modelo cascata, embora qualquer processo de
desenvolvimento possa ser usado).

Especificação

Métodos formais podem ser usados para dar uma descrição do sistema a
ser desenvolvido, em qualquer nível de detalhe desejado. Esta descrição
formal pode orientar futuras atividades de desenvolvimento (veja seções
seguintes); além disso, é possível empregá-la na verificação dos
requerimentos de um sistema em desenvolvimento, e assim, atestar se
foram completamente e precisamente especificados.

Por anos, sentiu-se a necessidade de sistemas de especificação formal. No

relatório ALGOL 60, John Backus apresentou uma notação formal para a
sintaxe de linguagens de programação descritivas (Mais tarde, nomeada
de Forma Normal de Backus ou Forma Backus-Naur (BNF)). Backus
também descreveu a necessidade para uma notação referente à semântica
da linguagem de programação descritiva.

O relatório previu que uma nova notação, tão definitiva como a BNF, iria
aparecer em um futuro breve, porém isto nunca ocorreu.

(MMPES_ C4_Modelo de Processo Especializado)

Prof. Romário Lopes Alcântara - Unijuí - Universidade de Ijuí - Curso de Ciência da Computação e Engenharia de Software 5
Modelos e Métodos de Processo em Engenharia de Software - Capitulo 4 – Modelos de Processos Especializados

Desenvolvimento

Uma vez descrita, a especificação formal pode ser usada como guia
enquanto o sistema concreto é desenvolvido durante o processo de projeto
(i.e. implementado tipicamente em software, mas potencialmente em
hardware). Exemplos:

• Se a especificação formal está numa semântica operacional, o

comportamento observado do sistema concreto pode ser comparado com o
comportamento da especificação (a qual deve ser executável ou
simulável). Adicionalmente, os comandos operacionais da especificação
podem ser concebidos para a tradução direta em código executável.

• Se a especificação formal está numa semântica axiomática, as

precondições e precondições da especificação podem se
tornar afirmações no código executável.

Verificação

Uma vez desenvolvida, a especificação formal pode ser usada como base
para a comprovação das propriedades da especificação (e,
esperançosamente, por inferência, do sistema desenvolvido).

Prova Dirigida a Humanos

Às vezes, a motivação para provar a correção de um sistema não é a

necessidade óbvia de reassegurar a correção do sistema, mas um desejo de
entender melhor o sistema. Consequentemente, algumas provas de
correção são produzidas no estilo de prova matemática: manuscritas (ou
digitadas) usando linguagem natural, em um nível de informalidade
comum a provas dessa categoria. Uma “boa” prova é uma que seja legível
e inteligível por outros leitores humanos.

Críticos dessa abordagem afirmam que a ambiguidade inerente da

linguagem natural leva a erros indetectáveis; frequentemente, erros sutis
podem estar presentes em detalhes de baixo nível tipicamente
negligenciados por essas provas. Adicionalmente, o trabalho envolvido
em produzir uma boa prova requer um alto nível de sofisticação e
especialização matemática.

Prova automatizada

Em contraste, há interesse crescente em produzir provas de correção de

sistemas pelos meios automatizados. Técnicas automatizadas se
enquadram em duas categorias gerais:

• Prova do teorema automatizado, na qual o sistema tenta produzir

uma prova formal a partir do zero, dados uma descrição do sistema, um
conjunto de axiomas lógicos, e um conjunto de regras de inferência.

(MMPES_ C4_Modelo de Processo Especializado)

Prof. Romário Lopes Alcântara - Unijuí - Universidade de Ijuí - Curso de Ciência da Computação e Engenharia de Software 6
Modelos e Métodos de Processo em Engenharia de Software - Capitulo 4 – Modelos de Processos Especializados

• Verificação de Modelo, na qual o sistema verifica certas

propriedades por meio de uma pesquisa exaustiva de todos os estados
possíveis que um sistema poderia assumir durante sua execução.

Nenhuma dessas técnicas trabalha sem assistência humana. Provas de

teoremas automatizadas normalmente requerem orientação sobre quais
propriedades são “interessantes” o bastante para verificar; o verificador de
modelos pode passar muito tempo conferindo milhões de estados
desinteressantes se não tiver disponível um modelo suficientemente
abstrato.

Proponentes desses sistemas argumentam que os resultados obtidos

conferem maior certeza matemática do que provas produzidas pelo
homem, uma vez que todos os detalhes tediosos são verificados por
um algoritmo. O treinamento exigido para usar esses sistemas também é
menor do que aquele exigido para produzir boas provas matemáticas
manualmente, tornando as técnicas acessíveis para uma ampla variedade
de especialistas.

Críticos notam que esses sistemas são como oráculos: eles fazem um
pronunciamento da verdade, ainda que dê nenhuma explicação daquela
verdade. Também há o problema do “verificando o verificador”; se o
programa que ajuda na verificação não for provado, pode haver razões
para duvidar da validade dos resultados obtidos.

Mas nem todos concordam, conforme Wikipédia (2019)

O campo dos métodos formais tem seus críticos. Provas de correção,

manuscritas ou assistidas por computador, precisam de tempo significante
(e, portanto, de dinheiro) para serem produzidas, com utilidade limitada e
voltadas apenas para assegurar a precisão.

Por essa razão, os métodos formais são mais frequentemente usados em

áreas onde os benefícios de se conseguir essas provas, ou o risco de haver
erros não detectados, compensam os recursos empregados.

Exemplo: na engenharia aeroespacial, erros não detectados podem

causar mortes, portanto métodos formais são mais populares nesta área em
comparação a outras.

Conforme Figueiredo (2004) quando Usar Métodos Formais:

• Análise de Requisitos:
- Ajudar a entender os requisitos do sistema.

• Design do Sistema:
- Decomposição e Refinamento.

• Verificação:
- Mostrar que um sistema satisfaz a sua especificação.

(MMPES_ C4_Modelo de Processo Especializado)

Prof. Romário Lopes Alcântara - Unijuí - Universidade de Ijuí - Curso de Ciência da Computação e Engenharia de Software 7
Modelos e Métodos de Processo em Engenharia de Software - Capitulo 4 – Modelos de Processos Especializados

• Validação
- Testes e depuração.

• Documentação

Em resumo os Métodos Formais têm as seguintes características:

• São técnicas baseadas em aspectos matemáticos para a descrição de

propriedades de sistemas.

• Ela pode ser usada em qualquer estágio do desenvolvimento de sistemas como

visto anteriormente.

• Um dos produtos concretos de sua aplicação é uma especificação formal.

• Especificação formal é mais precisa e, em geral, mais concisa do que as

informais.

4.3 Desenvolvimento Orientado a Aspectos

Conforme Soares et all (S/d) tem-se que

Sabe-se que no desenvolvimento de software existem propriedades que

não se enquadram em componentes da decomposição funcional, tais
como: tratamento de exceções, restrições de tempo real, distribuição e
controle de concorrência. Elas normalmente estão espalhadas em diversos
componentes do sistema afetando a performance ou a semântica da
aplicação.

Embora elas possam ser visualizadas e analisadas relativamente em

separado, sua implementação utilizando linguagens orientadas a objeto ou
estruturadas torna-se confusa e seu código encontra-se espalhado através
do código da aplicação, dificultando a separação da funcionalidade básica
do sistema dessas propriedades.

A programação orientada a aspectos é uma abordagem que permite a

separação dessas propriedades ortogonais dos componentes funcionais de
uma forma natural e concisa, utilizando-se de mecanismos de abstração e
de composição para a produção de código executável.

Atualmente conhece-se vários problemas de programação em que as

técnicas de programação orientadas a objetos ou de programação
estruturada não são suficientes para separar claramente todas as decisões
de projeto que o programa deve implementar.

Isto se deve ao fato de que as abordagens mais utilizadas concentram-se

em encontrar e compor unidades funcionais da decomposição do sistema,
enquanto que outras questões importantes não são bem localizadas no
projeto funcional.

(MMPES_ C4_Modelo de Processo Especializado)

Prof. Romário Lopes Alcântara - Unijuí - Universidade de Ijuí - Curso de Ciência da Computação e Engenharia de Software 8
Modelos e Métodos de Processo em Engenharia de Software - Capitulo 4 – Modelos de Processos Especializados

Exemplos disto podem ser propriedades que envolvem várias unidades

funcionais, tais como: sincronização, restrições de tempo, concorrência,
distribuição de objetos, persistência, etc.

Quando duas propriedades sendo programadas devem ser compostas de

maneira diferente e ainda coordenarem-se é dito que elas são ortogonais
entre si. (Grifo Nosso).

A mesma fonte acima cita a diferença entre Aspectos versus Componentes

Uma propriedade de um sistema que deve ser implementada pode ser vista
como um componente ou como um aspecto:

- A propriedade pode ser vista como um componente se puder ser

encapsulada em um procedimento generalizado (objeto, método,
procedimento, API). Os componentes tendem a ser unidades da
decomposição funcional do sistema. Como exemplos, podem ser citados:
contas bancárias, usuários ou mensagens.

- Aspectos não são normalmente unidades da decomposição funcional do

sistema, mas sim propriedades que envolvem diversas unidades de um
sistema, afetando a semântica dos componentes funcionais
sistematicamente.

Pode-se citar vários exemplos de aspectos, tais como: controle de

concorrência em operações em uma mesma conta bancária, registro das
transações de uma determinada conta, política de segurança de acesso aos
usuários de um sistema, restrições de tempo real associadas à entrega de
mensagens.

Dada a definição de componentes e aspectos, é possível colocar o objetivo

da programação orientada a aspectos: oferecer suporte para o programador
na tarefa de separar claramente os componentes dos aspectos, os
componentes entre si e os aspectos entre si, utilizando-se de mecanismos
que permitam a abstração e composição destas, produzindo o sistema
desejado.

A programação orientada a aspectos estende outras técnicas de

programação (orientada a objetos, estruturada, etc.) que oferecem suporte
apenas para separar componentes entre si abstraindo e compondo-os para
a produção do sistema desejado.

Na figura 1 será mostrado a seguir um exemplo de aspecto.

(MMPES_ C4_Modelo de Processo Especializado)

Prof. Romário Lopes Alcântara - Unijuí - Universidade de Ijuí - Curso de Ciência da Computação e Engenharia de Software 9
Modelos e Métodos de Processo em Engenharia de Software - Capitulo 4 – Modelos de Processos Especializados

Figura 1 - Um exemplo de aspecto

Fonte: Soares Et All (S/d)

Entendendo a figura conforme Soares et All (S/d),

Tem-se na figura acima a definição de dois tipos de figura, ponto e linha.

A posição do ponto e da linha é definida através de duas coordenadas (x e
y). Deste modo ambas permitem acesso aos valores de x e y (sua posição)
através das funções getX() e getY(). Além disso, pode-se modificar a
posição de um ponto ou linha, modificando-se a posição na coorenada x
(setX), na coordenada y (setY) ou as duas ao mesmo tempo (incrXY).

Nota-se então que movimentar um ponto ou uma linha é feito da mesma

maneira nos dois tipos de figura. Com isso, percebe-se que existe um
aspecto movimento, definido tanto para linha quanto para o ponto. Ou
seja, deve-se encapsular o aspecto movimento em um só lugar.

Na verdade, o movimento está definido para uma figura e redefinido para

a outra. Assim um tratamento de exceção que diz, por exemplo, que não
se pode ter x ou y negativos é definido duas vezes. Da mesma forma para
os valores máximos de x e y.

Tendo assim então uma breve conclusão sobre este tema, conforme o exemplo
anterior conforme Soares et All (s/d),

É importante notar também as vantagens desta definiçao do aspecto

movimento em relação à reutilização de software.

Por exemplo: Suponha que sem a utilização de aspecto, x e y máximos

foram definidos como 1000 e foi implementado todo um tratamento de
exceção quanto a isso em cada classe. Suponha agora que alguém
pretende reaproveitar este código em outro software. Mas neste as
coordenadas máximas serão (1500, 1500).

(MMPES_ C4_Modelo de Processo Especializado)

Prof. Romário Lopes Alcântara - Unijuí - Universidade de Ijuí - Curso de Ciência da Computação e Engenharia de Software 10
Modelos e Métodos de Processo em Engenharia de Software - Capitulo 4 – Modelos de Processos Especializados

Como a implementação anterior não utilizou a abordagem de aspectos,

todo o tratamento de exceção anteriormente previsto para as coordenadas
(1000, 1000) deverá ser redefinido para cada classe.

Entretanto se a abordagem de aspecto houvesse sido considerada para a

definição de movimento, bastaria redefinir apenas em único local, na
definição do aspecto.

Deste modo percebe-se que a orientação a aspectos propõe sobre a

orientação a objetos algo como o que a orientação a objetos propôs sobre
a programação estruturada, ou seja, elementos comuns devem ser
encapsulados em um só local para uma melhor definição e
manutenibilidade.

A mesma fonte faz dois últimos relatos importantes,

Por que usar o paradigma de orientação a aspectos?

Uma vantagem na utilização da orientação a aspectos está na diminuição

do tamanho do código dos componentes (visto que uma parte do código
fica na definição dos aspectos), diminuindo sua complexidade. Por estar
centralizado em uma única unidade, alterações são muito mais simples,
não é preciso reescrever inúmeras classes. É claro que um código mais
conciso facilita sua manutenibilidade e reuzabilidade.

Por que “ninguém” usa este paradigma?

Apesar de apresentar uma proposta inovadora no desenvolvimento de

software pode-se dizer que a Orientação a Aspectos, apesar de sua
constante evolução, ainda deixa a desejar em alguns pontos tais como:

- Não há um meio claro para se definir o que deve e o que não deve ser
um aspecto em um projeto de software.
- A falta de metodologias ainda é um fator limitante deste paradigma.

Sendo assim então uma nova forma de se pensar software.

4.5 Síntese
Neste Quarto capitulo do estudo sobre Modelos de Processos Especializados o
objetivo é mostrar que existem diferentes modelos para abordar um sistema.

4.6 Referências
Neste capitulo foi utilizada a seguinte bibliografia / referência:

Figueiredo, Jorge. Métodos Formais. Disponível em:

http://www.dsc.ufcg.edu.br/~abrantes/CursosAnteriores/MF041/MF-Aula3.pdf Acesso em:
14 Out. 2019

(MMPES_ C4_Modelo de Processo Especializado)

Prof. Romário Lopes Alcântara - Unijuí - Universidade de Ijuí - Curso de Ciência da Computação e Engenharia de Software 11
Modelos e Métodos de Processo em Engenharia de Software - Capitulo 4 – Modelos de Processos Especializados

Masiero, Paulo C. Desenvolvimento de Software Baseado em Componentes.

Disponível em
https://edisciplinas.usp.br/pluginfile.php/130351/mod_resource/content/1/DSBC_UML_Co
mponents_1-2-3.pdf Acesso em: 14 Out 2019.

Werner, Cláudia Maria Lima e Braga, Regina Maria Maciel. Desenvolvimento

Baseado em Componentes. COPPE/UFRJ - Programa de Engenharia de Sistemas.
Universidade Federal do Rio de Janeiro. Disponível em:
http://reuse.cos.ufrj.br/prometeus/publicacoes/SBES2000_TutorialDBC_Apresentacao.pd
f Acesso em: 14 Out. 2019.

Wikipédia. Métodos Formais. Disponível em

https://pt.wikipedia.org/wiki/M%C3%A9todos_formais. Acesso em: 14 Out. 2019

Soares, Alexandre Henrique Vieira. Rocha, Anderson de Rezende. Alves, Flávio

Luis. Alves, Júlio César. Programação Orientada a Aspectos. Disponível em:
<https://www.ic.unicamp.br/~rocha/college/src/aop.pdf> Acesso em 14 out. 2019.

Observações Finais:

Na estruturação dos capítulos se procurou seguir as normas da ABNT atual,

estruturando da melhor forma possível, facilitando o entendimento aos alunos e procurando
sempre respeitar os direitos autorais conforme Lei Federal nº 9.610 de 19 de fevereiro de
1998.

(MMPES_ C4_Modelo de Processo Especializado)