Modelos de arquitetura de software para sistemas distribuídos

Mostrar um pouco do resumo sobre os três estilos complementares de arquitetura que cobrem a Organização Geral, Decomposição Modular e Controle de Sistemas, além de entender o funcionamento da comunicação que as Arquiteturas de Referências utilizam para expor seu conceito e assim avaliar as Arquiteturas de Sistema. Também abordando modelos de arquitetura de software para sistemas distribuídos, mostrando as vantagens e desvantagens que a arquitetura de sistemas distribuídos tem a oferecer, os principais modelos de sistemas distribuídos, classificando-se em dois modelos, sistemas Cliente-Servidor e Sistemas de Objetos Distribuídos.

Os sistemas de aplicação que são criados para atender necessidades de negócio ou organizacionais.

E apresentar os processos utilizados para o gerenciamento de código e documento no desenvolvimento do sistema de software. Com isso podemos assimilar que o Gerenciamento de Configurações de software tem sido adotado em sistemas complexos, as quatro atividades fundamentais de gerenciamento de configurações, sendo planejamento de Gerenciamento de Configurações, Gerenciamento de Mudanças, gerenciamento de Versões e Construção de Sistemas.

2 PROJETO DE IMPLEMENTAÇÃO

O projeto de software orientado a objeto usando UML é destacar os interesses importante de implementação. Para alguns sistemas simples, o projeto e implementação se software é a engenharia de software, e todas as outras atividades são intercaladas com esse processo. No entanto, para grandes sistemas , o projeto e implementação de software é apenas parte de um conjunto de processos (engenharia de requisitos, verificação e validação etc.)envolvidos na engenharia de software.

O projeto de software é uma atividade criativa em que você identifica os componentes de software e seus relacionamentos com a base nos requisitos do cliente. O projeto e a implementação estão intimamente ligados e, ao elaborar um projeto, você deve levar em consideração os problemas de implementação.

Uma das decisões de implementação mais importantes que precisa ser tomada em um estagio inicial de um projeto de software é se você deve ou não comprar ou construir o software de aplicação. Atualmente, é possível comprar sistemas de prateleira (COTS, do inglês comercial off-the helf )em uma ampla variedade de domínios. Os sistemas podem ser adaptados e ajustados aos requisitos dos usuários.

2.1 PROJETO ORIENTADO A OBJETO UML

Em um sistema orientado a objetos é composto objetos interativos que amantem local e oferecem operações nesse estado. A representação do estado é privada e não pode ser acessada diretamente, de fora do objeto. Processos orientado a objetos envolvem projetar classes de objetos e os relacionamentos entre essas classes. Essas classes definem os objetos no sistemas e suas interações. Quanto o projeto é concebido como um programa em execução, os objetos são dinamicamente a partir dessas definições de classe.

Sistema orientados a objetos são mais fáceis de se mudar do que os sistemas desenvolvidos com abordagens funcionais. Para desenvolver um projeto de sistema desde o conceito até o projeto detalhado orientado a objeto, existem varis atitudes que você precisa tomar.

• Compreender e definir o contexto e as interações externas com o sistema.

• Projetar a arquitetura do sistema.

• Identificar os principais objetos do sistema.

• Desenvolver modelos de projeto.

• Especificar interfaces.

Como todas as atividades criativas, o projeto não é um processo sequencial claro. Você desenvolve um projeto tendo ideias, propondo soluções e refinando essas soluções assim que as informações ficam disponível.

2.1.1 Contexto e interações do sistema

O primeiro estagio de qualquer processo de projeto de software é o desenvolvimento de uma compreensão dos relacionamentos entre o software que esta sento projetado e seus ambientes externos.

O modelo de contexto de um sistema pode ser representado por associação. Esta simplesmente mostra que existe alguns relacionamentos entre as entidades na associação. Nesse momento a natureza dos relacionamentos é especificada.

Quando você modela as interações de um sistema, deve usar abordagem abstrata em muitos detalhes. Uma maneira de fazer um modelo de caso de uso. Cada caso de uso representa uma interação como sistema. Cada interação possível é nomeada em um elipse, e a entidade externa envolvida na interação é representada por um boneco de palito.

2.1.2 Projeto de Arquitetura

Uma vez as interações entre sistema de software e o ambiente do sistema, você pode usar essa informação como base para projetar a arquitetura do sistema. Certamente, você precisa combinar essa informação com seu conhecimento