CENTRO DE CINCIAS EXATAS E TECNOLGIAS TECNOLOGIA EM ANLISE E DESENVOLVIMENTO DE SISTEMAS LEONARDO RUIZ OBERLE

ENGENHARIA DE SOFTWARE:
Resenha captulo 11

Londrina 2012

LEONARDO RUIZ OBERLE

ENGENHARIA DE SOFTWARE:
Resenha captulo 11

Trabalho de Engenharia de Software apresentado Universidade Norte do Paran - UNOPAR, como requisito parcial para a obteno de mdia bimestral na disciplina de Engenharia de Software Orientador: Prof. Luiz Cludio Perini

Londrina 2012

SUMRIO 1 Projeto de arquitetura.................................................................................................3 1.1 Decises do projeto de arquitetura......................................................................4 1.2 Organizao de sistema......................................................................................4 1.2.1 O modelo de repositrio................................................................................5 1.2.2 O modelo cliente-servidor.............................................................................5 1.2.3 O modelo em camadas.................................................................................6 1.3 Estilo de decomposio modular.........................................................................6 1.3.1 Decomposio orientada a objetos...............................................................6 1.3.2 Pipelining orientado a funes......................................................................7 1.4 Modelos de controle............................................................................................ 7 1.4.1 Controle centralizado.................................................................................... 7 1.4.2 Sistemas orientados a eventos.....................................................................8 1.5 Arquiteturas de referncia................................................................................... 8

1 PROJETO DE ARQUITETURA Projeto de arquitetura o primeiro estgio no processo de projeto e define um framework para controlar a comunicao entre todos os subsistemas que compe um grande sistema, e representa uma ligao crtica entre a engenharia de projeto e de requisitos. Projetar e documentar explicitamente uma arquitetura de software trazem 3 vantagens, que so: a facilidade de comunicao entre as partes interessadas, efeitos aos requisitos crticos da anlise, e a reutilizao de recursos. importante aos projetistas de software que seja levado em considerao aspectos do projeto no momento da anlise, para que as discusses para definio dos requisitos sejam direcionadas e foquem as abstraes principais do sistema. O estilo e a estutura da arquitetura do sistema depende de requisitos no funcionais do sistema, como desempenho, proteo, segurana, disponibilidade e facilidade de manutano. Se algum requisito no funcional um requisito crtito, a arquitetura deve ser adaptada para atender esse requisito. E se mais de um requisito crtico, muitas vezes pode causar conflitos potenciais na arquitetura, e deve ser encontrada alguma soluo eficaz, muitas vezes usando estilos de arquitetura diferente para cada parte do sistema. ideal que no haja informaes de projeto nas especificaes do sistema, mas isso no real em sistemas de mdio e grande porte, pois nesses casos, a arquitetura necessria para organizar a especificao. Nos grandes sistemas utilizada uma decomposio abstrata, separando o sistema em subsistemas, que por sua vez, podem ser desenvolvidos como sistemas independentes. Para descrever projetos de subsistemas, utilizado o diagrama de blocos, que mais utilizados para comunicao dos skateholders para o planejamento do projeto, e so muito pouco detalhados. O processo de dividir um sistema em subsistemas difcil, principalmente em se tratando do conflito entre os requisitos do sistema geral e dos subsistemas.

1.1 DECISES DO PROJETO DE ARQUITETURA O projeto de arquitetura um processo criativo que tenta satisfazer os requisitos funcionais e no funcionais de um sistema, e por ser um processo criativo, ele difere para cada arquiteto. E baseado em seu conhecimento, eles procesam responder uma srie de perguntas sobre o sistema. E por mais que cada sistema seja nico, existem arquiteturas similares entre sistemas de um mesmo domnio de aplicao. E no momento de projetar a arquitetura de um sistema, o engenheiro precisa decidir o que pode ser reutilizado em diferentes partes do sistema. Alm disso, preciso decidir a arquitetura de distribuio do sistema, deciso esta que afeta o desempenho e a confiabilidade do sistema. A arquitetura de um sistema deve seguir um ou mais estilos de arquitetura. Um estilo de aruitetura um padro de organizao de sistema, como uma organizao cliente-servidor, ou uma arquitetura camadas. Neste momento, so decididas as prximas 3 questes do projeto: a escolha da esttrutura mais apropriada, a deciso de estratgia de decomposio do sistema, e decidir como a execuo de subsistemas controlada. A avaliao de um projeto de arquitetura verifica se o sistema atende os requisitos funcionais e no funcionais definidos na anlise. O produto do processo de projeto de arquitetura um documento que pode conter vrias representaes grficas do sistema, junto com uma descrio textual. Deve ser descrita a decomposio do sistema, a abordagem, e a descrio dos mdulos. Vrios modelos de arquitetura podem ser encontrados nesse documento. Existem algumas notaes para descrever a arquitetura de sistemas, como a ADL, que compreendida somente por especialistas em linguagem, e a UML, que a mias utilizada. 1.2 ORGANIZAO DE SISTEMA A organizao de um sistema a estratgia para estruturao do mesmo. necessrio tomar decises do modelo organizacional do do sistema antes do projeto de arquitetura. E mesmo refletindo diretamente na esestrutura do subsistema, eles possuem menos detalhes. Trs estilos organizacionais so muito

utilizados, e sero descritos a seguir. 1.2.1 O modelo de repositrio Os subsistemas devem trocar informaes e trabalhar juntos de forma eficiente. H somente um banco de dados compartilhado para todos os subsistemas, e podem trabalhar com uma quantidade muito grande de dados. uma maneira muito eficiente de compartilhar dados entre subsistemas, mas todos os subsistemas devem seguir o modelo de dados do repositrio, o que torna muito difcil sua integrao. Cada subsistema no precisa saber como o outro subsistema utiliza determinada informao, porm, traduzir um grande volume de dados que gerado de acordo com o modelo estabelecido do repostrio, pode ser dispendioso. As atividades de manuteno e backup so realizadas diretamente no repositio, o que se torna mais rpido e segura, mas pode existir dificuldades pois muitas vezes os requisitos so diferentes para cada subsistema. Novas ferramentas e mdulos podem ser integrados facilmente, seguindo o modelo do repositrio, mas pode ser difcil distribuir o repositrio em vrias mquinas, pois pode haver redundncias e inconsistncias. Neste modelo, o controle dos dados de responsabilidade dos subsistemas, tornando o repositrio passivo. 1.2.2 O modelo cliente-servidor Este modelo organizado em servidores que disponibilizam servios para outros subsistemas; clientes que acessam e utilizam esses servios disponibilizados pelos servidores; e uma rede que permite aos clientes acessarem os servios. Geralmente, o cliente necessita saber o nome dos servidores e dos servios que eles disponibilizam, no entanto o servidor no precisa conhecer o cliente. O cliente acessa os servios atravs de chamadas utilizando o protocolo de comunicao http. A vantagem de se utilizar este modelo, que ele torna o sistema distribudo, tornando fcil adicionar um novo servidor ou cliente.

1.2.3 O modelo em camadas Organiza o sistema em camadas, cada uma das quais fornecendo um cojunto de servios, que so utilizados para implementar a prxima camada, ou o prximo nvel (ex. Modelo OSI de protocolos de rede). Possui um sistema de gerenciamento de configurao que armazena informaes e servios para itens ou objetos de conigurao. Este modelo apoia o desenvolvimento incremental, e os recursos de uma camada podem ser utilizados pelo usurio medida em que desenvolvida. Uma grande vantagem deste modelo, que cada camada pode ser substituda por uma similar, uma altero somente afeta a camada adjacente. Mas de contrapartida, a estruturao de sistemas em camadas pode ser muito difcil. O desempenho tambm pode ser comprometido, devido a existirem vrios nveis de interpretao. 1.3 ESTILO DE DECOMPOSIO MODULAR Aps a deciso da organizao geral do sistema, preciso decidir a decomposio dos subsistemas em mdulos. Subsistemas e mdulos so diferentes: um subsistema no depende de outros subsistemas e so compostos de mdulos que definem interfaces para se comunicar com outros subsistemas; j um mdulo no considerado um sistema independente, e fornece servios a serem utilizados por outros mdulos, e podem ser divididos em componentes mais simples, que podem ser orientados a objetos ou a funes. 1.3.1 Decomposio orientada a objetos Neste modelo, o sistema dividido em um conjunto de objetos que chamam recursos de outros objetos. E cada objeto relacionado uma classe de ojetos, com seus atributos e operaes. Objetos so geralmente a representao de uma entidade do mundo real. Devido aos objetos serem de certa forma independentes, eles podem ser alterados sem afetar os outros objetos. De contrapartida, se algum

recurso de um objeto tiver seu nome alterado, todas as chamdas a esse recurso devem ser alteradas. 1.3.2 Pipelining orientado a funes Neste modelo, cada estapa do processamento considerada uma transformao, que processam suas entradas e geram sadas, que podem ser executadas sequencial ou paralelamente. Neste modelo, possvel fazer a reutilizao de transformaes. uma arquitetura intuitiva, pois no mundo real, muito utilizado processamento de entrada e sada. A evoluo do sistema geralmente direta, e muito simples de implementar. Mas seu principal problema, que necessita de um formato comum para a transferncia de informaes entre as transformaes. 1.4 MODELOS DE CONTROLE Este modelo lida com o fluxo de controle entre subsistemas, e existem 2 estilso genricos de controle utilizados: o controle centralizado, onde um subsistema tem a responsabilidade de controlar os outros subsistemas; e o controle baseado em eventos, onde cada subsistema pode responder a eventos gerados externamente. 1.4.1 Controle centralizado Neste modelo, um subsistema reponsvel pelo controle dos outros subsistemas, e podem dividir-se em duas classes: o modelo chamada-retorno, tambm conhecido como top-down, onde o subsistema de controle aguarda o retorno da chamada e sua execuo volta ao ponto onde parou; e o modelo gerenciador, onde cada subsistema pode ser executado concorrentemente com os demais, e geralmente est em um loop contnuo, e ele decide em que momento os processos precisam ser iniciados ou parados, e muito utilizado em sistemas de tempo real.

1.4.2 Sistemas orientados a eventos Neste modelo, os processos so regidos pro eventos externos. So utilizados em sistemas com interfaces que possibilitam ao usurio uma gama de aes que so decididas no momento da execuo. Dois tipos de modelos de controle orientados a objetos sero abordados: modelos de broadcast, onde cada evento transmitido a todos os subsistemas, e qualquer subsistema que pode manipular aqueles dados podem responder a ele, mas isso pode causar um overhead de processamento. Uma vantagem que um subsistema pode ativar qualquer outro subsistema sem saber a identidade dele. Uma desvantagem que os subsistema nunca sabem se e quando um evento foi tratado. Modelos orientados a interrupes, onde interrups externas so detectadas por um tratador de interrupes e so repassadas por ele para o subsistema adequado para tratar aquele evento. So usados em sistemas de tempo real, quando um evento precisa de uma resposta imediata e eficiente. Mas so muito difceis de serem implementados. 1.5 ARQUITETURAS DE REFERNCIA Modelos de referncia so mais abstratos e descrevem uma classe maior de sistemas. E so utilizados, normalmente, para comunicar conceitos domnio e comparar ou avaliar possveis arquiteturas. Arquiteturas de referncia so meios de discusses de arquiteturas de somnios especficos, porisso, no so um roteiro de implementao. Uma proposta de modelo de referncia um modelo para ambientes CASE, que identifica os conjuntos de servios que ele deve fornecer. Os cinco nveis em um modelo CASE de referncia so: repositrio de dados, integrao de dados, gerenciamento de tarefas, mensagem, interface com o usurio. Este modelo mostra o que pode ser includo em qualquer ambiente CASE, embora nem todo recurso de uma arquitetura de referncia pode ser includos nos projetos reais.