introducao arquitetura software

8/7/2019 Introducao Arquitetura Software

1/10

I ntroduo a Arquitetura de Software

Allex M otta M elo da Rocha1

Fbrica de Software do CESUPA Centro Universitrio do Par

Av. Governador Jos Malcher, 1963 Belm PA Brasil

[email protected]

Resumo. Diversos fatores podem causar o insucesso de sistemas de software e

em alguns casos, at levar a falncia de um projeto. Identificar tais fatoresno comum. Este arti go tem como fi nali dade identif icar esses fatores, os

quais, mui tas vezes no so percebidos pelos pr ofi ssionai s envolvidos durante

o processo de desenvolvimento.

Abstract. Many factors that can cause the failure of software and in some

cases, even lead to bankruptcy of a project. Identifying such factors is not

common. This article aims to identify these factors, which often are not

perceived by the professionals involved in the development process.

1. I ntroduo

Arquitetura de software uma subrea da disciplina de Engenharia de Software,

cujo objetivo estudar os componentes do sistema, suas propriedades externas, e seus

relacionamentos com outros softwares.

Uma boa arquitetura pode possibilitar que um sistema satisfaa s exigncias

principais de um projeto, tais como: desempenho, confiabilidade, portabilidade,

manutenibilidade, interoperabilidade e etc., j uma arquitetura m elaborada pode ser

desastrosa.

Com o amadurecimento da engenharia, percebeu-se que uma boa arquitetura

um fator decisivo de sucesso para o projeto e o desenvolvimento do sistema, visto que

ela desempenha o papel de uma ponte entre requisitos e cdigo.

Easy PDF Creator is professional software to create PDF. If you wish to remove this line, buy it now.
http://www.pdfdesk.com/http://www.pdfdesk.com/


2/10

Segundo Varoto (2002), a arquitetura de software define o que o sistema em

termos de componentes computacionais e os relacionamentos entre estes componentes.

Similar a esta definio, Bass et al. [Bass98] diz que arquitetura de software so

as estruturas que incluem componentes, suas propriedades externas e os relacionamentos

entre eles, constituindo uma abstrao do sistema. Esta abstrao suprime detalhes de

componentes que no afetam a forma como eles so usados ou como eles usam outros

componentes, auxiliando o gerenciamento da complexidade.

2. Processo de Software

Segundo a ISO/IEC 15504, um processo a definio operacional de um

conjunto de atividades para alcanar um propsito especfico. Logo, Processo de

Software um conjunto coerente de atividades, cuja finalidade a construo de

software.

O RUP (Rational Unif ied Process, em portugus, Processo Unificado da

Rational) define quem est fazendo o que, quando e como o faz para alcanar os

objetivos pr-estabelecidos.

Um processo bem definido permite as organizaes desenvolverem sistemas

complexos de forma repetida e previsvel, ou seja, aprimorando-o a cada projeto. Sem

um processo bem definido, a equipe desenvolver de forma ad hoc(na engenharia, esse

termo utilizado para designar um projeto que no foi bem estruturado) e estar sujeita

a enfrentar problemas no desenvolvimento, o que pode levar falncia do projeto.

2.1 Fasesdo Processo de Software

O processo de software divido em trs fases genricas:

Definio: Planejamento e Anlise;

Desenvolvimento: Projeto, Implementao e Testes;

Manuteno ou Evoluo: Correo, Adaptao e Melhoramento Funcional.



3/10

2.2 Estrutura Genrica de Processo

Figura 2.1 Exemplo de Estrutura doProcesso.

2.3 Atividadesde Suporte

Gerncia de Projetos de Software;

Tcnicas de Reviso Formal;

Segurana da Qualidade (SQA);

Gerncia de Configurao do Software;

Preparao e produo de Documentao;

Gerncia da Reusabilidade;

Medidas;

Gerncia de Riscos.

3. PadresdeProjeto

Padres de Projeto (em ingls, Design Patterns) so solues documentadas para

resolver um problema recorrente.



4/10

Padres so aplicados para alcanar qualidade na engenharia de software usando

classes e mtodos em linguagens orientadas a objeto.

O livro Design Patterns, de Erich Gamma, John Vlissides, Ralph Jonhson e

Richard Helm, conhecidos como a gangue dos quatro (GoF Gang of Four), descreve

23 padres de projeto.

De acordo com a GoF, entende-se padres de projeto como descries de

objetos que se comunicam e classes que so adaptadas para resolver um problema

genrico de designem um contexto especfico.

A motivao para aprender e utilizar padres desenvolver software de melhor

qualidade, reutilizando o conhecimento, ou seja, usar o aprendizado de uma experincia

passada. Sem contar no fato que padres utilizam solues documentas, os quais tm um

nome, onde facilitam a comunicao, compreenso e documentao. Isso contribui com

um desenvolvimento eficiente com orientao a objetos.

Os padres possibilitam usar na prtica polimorfismo, herana, modularidade,

composio, abstrao para construir um cdigo reutilizvel e eficiente, de alta coeso e

baixo acoplamento.

Um padro documentado pelos seguintes itens:

Figura 3.1 Tabela com ositenssobre documentaode padro.

Segundo GoF, so classificados em 23 padres de projeto. Esses padres so

divididos por propsito, o qual responsvel pela criao de classes e objetos, alterao



5/10

da estrutura do programa e controle de seu comportamento, e por escopo, que cuida da

classe e do objeto, conforme ilustra a figura 3.2.

Figura 3.2 Classificaodos23 padressegundoGoF.

4. Projeto da Arquitetura do Software

4.1 DosRequisitospara Cdigo

So divididos em trs nveis: nvel 1, o qual consiste no levantamento de

requisitos; nvel 2, caracterizado pela arquitetura, que divido em dois subnveis, com o

uso de padres de arquitetura e de projeto; nvel 3, responsvel pela parte da

implementao e codificao.

Figura 4.1 Divisoda arquitetura em trsnveis.



6/10

4.2 Arquitetura em Camadas

A arquitetura em camadas tem como objetivo estruturar o cdigo em camadas,

de forma a obter melhor reuso e extensibilidade.

Figura 4.2 Demonstraodouso da arquitetura em camadas.

4.2.1 M odel-View-Controller

Tambm conhecido pela sigla MVC, um dos padres da arquitetura de software

mais utilizados na atualidade. Esse padro divide a aplicao iterativa em trs

componentes: o modelo (model) contendo as funcionalidades e os dados, a viso (view)

mostrando informaes para o usurio e o controle (controller) manipulando as

entradas. Sendo assim, as modificaes feitas no layout (viso) no interferem na

manipulao de dados, estes podero ser reorganizados sem alterar o layout. O objetivo

permitir que uma mesma lgica de negcios possa ser acessada e visualizada atravs de

diferentes interfaces, como mostra a figura 4.1.



7/10

Figura 4.3 Estrutura do M VC.

Figura 4.4 Arquitetura em Camadase M VC sem a interface negcios-dados.

Figura 4.5 Arquitetura em Camadase M VC com a interface negcios-dados.



8/10

5. VisoGeral do RUP

O Processo Unificado da Rational foi construdo envolvendo as seis melhores

prticas para fornecer um processo bem definido, como podemos observar na figura 5.1.

Figura 5.1 Asseis melhoresprticasda Engenharia.

O RUP um processo de desenvolvimento de software que assegura a produo

de software de qualidade de forma repetida e previsvel, com isso, se ganha tempo e

facilita no desenvolvimento do projeto, visto que as tarefas so divididas de formas

iterativas.

O RUP tem como objetivo garantir a produo de software de alta qualidade que

atenda s necessidades dos seus usurios finais dentro de um cronograma e custos

previstos.



9/10

6. Concluso

A arquitetura de software uma disciplina em ascendncia nas reas acadmicas

e no mercado, na qual tm sido realizados diversos estudos com o intuito de melhorar a

qualidade dos produtos que so desenvolvidos.

O objetivo principal da arquitetura de software satisfazer os requisitos

necessrios para atender o negcio. Tais requisitos ocorrem em momentos distintos

durante o desenvolvimento do sistema. Por isso, importante saber em qual fase do

processo a viso de um esquema deve ser utilizada.

No entanto, a arquitetura deve satisfazer os requisitos necessrios para o sistema.

Dentre os requisitos, h aqueles que so identificados pelos participantes que so

responsveis pelo negcio e desejam uma soluo computacional para o problema que

enfrentam. Estes requisitos esto ligados s funcionalidades que o sistema deve atender.

Porm, h outros requisitos implcitos, denominados requisitos no funcionais ou

atributos de qualidade que devem ser identificados e compreendidos pelos arquitetos,

analistas e projetistas de sistemas.

7. Referncias

Visesem arquitetura de software, por Ane Cristina Varoto.

Disponvel em: < http://www.ime.usp.br/dcc/posgrad/teses/ane.pdf >. Acesso em 25 mar.

2008.

Padrese F rameworksdeSoftware.

Disponvel em: < http://www.icmc.sc.usp.br/~rtvb/apostila.pdf>. Acesso em 25 mar. 2008.

Arquitetura deSoftware.

Disponvel em: < http://pt.wikipedia.org/wiki/Arquitetura_de_software >. Acesso em 26

mar. 2008.

http://www.ime.usp.br/dcc/posgrad/teses/ane.pdfhttp://www.icmc.sc.usp.br/~rtvb/apostila.pdfhttp://pt.wikipedia.org/wiki/Arquitetura_de_softwarehttp://www.pdfdesk.com/http://www.pdfdesk.com/http://pt.wikipedia.org/wiki/Arquitetura_de_softwarehttp://www.icmc.sc.usp.br/~rtvb/apostila.pdfhttp://www.ime.usp.br/dcc/posgrad/teses/ane.pdf


10/10

Ad hoc.

Disponvel em: < http://pt.wikipedia.org/wiki/Ad_hoc >. Acesso em 26 mar. 2008.

M odel-View-Controller.

Disponvel em: < http://pt.wikipedia.org/wiki/MVC >. Acesso em 27 mar. 2008.

Easy PDF Creator is professional software to create PDF If you wish to remove this line buy it now
http://pt.wikipedia.org/wiki/Ad_hochttp://pt.wikipedia.org/wiki/MVChttp://www.pdfdesk.com/http://www.pdfdesk.com/http://pt.wikipedia.org/wiki/MVChttp://pt.wikipedia.org/wiki/Ad_hoc

introducao arquitetura software

Documents