RESENHA DO LIVRO ENGENHARIA DE SOFTWARE, DE IAN SOMMERVILLE

RESENHA DO LIVRO ENGENHARIA DE SOFTWARE, DE IAN SOMMERVILLE

CAPITULOS. 11, 12, 13 e 29

O que entendi sobre Projeto de Arquitetura é que si trata do primeiro estágio no processo de projetos. De acordo com o livro que os subsistemas estabelecem um framework para controlar a comunicação dos subsistemas, subsistemas são sistemas grandes divididos em subsistemas e que fornece algum conjunto de serviços. Esse também representa uma ligação critica entre processos de engenharia de projeto e requisitos. Existem três vantagens em projetar e documentar explicitamente uma arquitetura de software: Comunicação de stakeholders: que é um apresentação em alto nível do sistema que focaliza a discussão entre diferentes stakeholders. Já na Analise de sistemas: Tem um profundo efeito sobre o sistema, mostra se que o sistema pode atender aos requisitos críticos como, desempenho e facilidade de manutenção como também confiabilidade.

Reuso em larga escala: 

O reuso em larga escala de sistemas possuem arquiteturas de sistemas familiares.

Arquitetura de software serve para negociar requisitos de sistema e estruturar discussões com os clientes, desenvolvedores e gerentes. Considerada uma ferramenta essencial para gerenciamento de complexidade, ocultando detalhes e focando as abstrações principais do sistema. O estilo e estrutura da aplicação dependem dos requisitos não funcionais do sistema, por exemplo:
Se o desempenho for um requisito crítico a aplicação deve identificar operações criticas dentro de subsistemas e usar componentes de alta granularidade em detrimento dos de baixa granularidade para reduzir a comunicação entre eles.

Se a facilidade de manutenção for um requisito crítico, a arquitetura de sistemas deve ser projetada usando componentes de baixa granularidade e autocontidos que possam ser prontamente mudados. Existem conflitos potenciais entre algumas dessas arquiteturas, podemos citar o desempenho que precisa de alta granularidade e a facilidade de manutenção que necessita de baixa granularidade forem requisitos críticos terá que ser encontrada alguma solução eficiente. Um projeto de subsistemas é decomposição abstrata de um sistema de componentes em alta granularidade. Os diagramas de blocos são usados para representar um projeto de subsistemas. Esses diagramas de blocos são bons para comunicação entre stakeholders e para o planejamento do projeto, pois não estão abarrotados de detalhes, já para a arquitetura não são tão bons, pois não mostram relacionamento entre os componentes do sistema. O projeto de arquitetura tenta estabelecer uma organização de sistemas que satisfação os requisitos funcionais e os que são não funcionais do sistema. No decorrer deste processo de projeto de arquitetura os arquitetos de sistemas devem responder a algumas perguntas: Tem uma arquitetura genérica de aplicação que possa funcionar como um modelo para o sistema que está sendo projetado? Como o sistema será distribuído ao longo de vários processadores? Qual ou quais estilos de arquitetura são apropriados para o sistema? Qual será a abordagem fundamental usada para estruturar o sistema? Como as unidades estruturais de um sistema serão decompostas em módulos? Qual estratégia será utilizada para controlar a operação das unidades do sistema? Como o projeto de arquitetura será avaliado? Como a arquitetura do sistema deve ser documentada?
Projetando uma arquitetura de sistemas, é preciso decidir o que seu sistema e classes mais amplas de aplicação tem em comum, e decidir quanto conhecimento dessas arquiteturas de aplicação você pode reutilizar. A arquitetura de um sistema de software pode ser baseada em um modelo ou estilo de arquitetura especifico em alguns casos a arquitetura geral de um sistema pode ser uma arquitetura composta. Os modelos de arquitetura que podem ser desenvolvidos podem incluir: Um modelo estático de estrutura que mostra os subsistemas ou componentes desenvolvidos como unidades separadas. Um modelo dinâmico de processo que mostra como o sistema esta organizado em processos em tempo de execução.  A organização de um sistema reflete a estratégia básica usada para estruturá-lo. É necessário tomar decisões sobre o modelo geral organizacional de um sistema com antecedência no processo de projeto de arquitetura. A organização pode refletir diretamente na estrutura subsistema. Possuem três estilos organizacionais amplamente usados: Modelo de repositório
Os subsistemas que constituem um sistema devem trocar informações de mofo que possam trabalhar juntos eficientemente. Esse modelo é, portanto, adequado para aplicações em que os dados são gerados por um subsistema e usados por outro. O repositório é passivo e o controle é de responsabilidade dos subsistemas que o usam.

3 Modelo Cliente – Servidor

No modelo de arquitetura cliente – O servidor é um modelo em que o sistema é organizado como um conjunto de serviços e servidores e clientes associados que acessam e usam os serviços. Os clientes talvez precisem saber os nomes dos servidores disponíveis e os serviços que eles fornecem. No entanto os servidores não precisam saber a identidade do cliente ou quantos são. São acessados os serviços por meio de chamadas remotas de procedimento usando um protocolo request–eply, o cliente faz um pedido a um servidor e espera ate receber uma resposta.  A vantagem de um modelo cliente servidor é que ele é uma arquitetura distribuída. O uso efetivo de sistemas em rede pode ser feito com muitos processadores distribuídos. É fácil adicionar um novo servidor e integra-lo ao restante do sistema

4 O Modelo em Camadas

O modelo em camadas organiza um sistema em camadas, cada uma das quais fornecendo um conjunto de serviços. A abordagem em camadas apoia o desenvolvimento incremental de sistemas. A medida que uma camada é desenvolvida alguns serviços fornecidos por essa camada podem ser disponibilizados para os usuários. Essa arquitetura também é modificável e portável. Desde que sua interface permaneça inalterada, uma camada poderá ser substituída por outra equivalente. Uma desvantagem da abordagem em camadas é que a estruturação de sistemas dessa maneira pode ser difícil. As camadas mais internas podem fornecer recursos básicos, como gerenciamento de arquivos, necessários em todos os níveis. O desempenho também pode ser um problema devido aos vários níveis de interpretação de comandos algumas vezes exigidos.

5 Estilos de decomposição modular

Depois que a organização geral do sistema foi escolhida, precisa-se tomar uma decisão sobre a abordagem a ser usada na decomposição de subsistemas em módulos. Um modulo é normalmente um componente de sistema que fornece um ou mais serviços para outros módulos. Ele faz uso de serviços fornecidos por outros módulos. Tem duas estratégias principais que você pode usar ao decompor um subsistema em módulos.

Decomposição orientada a objetos e pipelining orientado a funções. Você deve evitar tomar decisões prematuras sobre a simultaneidade de um sistema.

...