Arquitetura de Sistemas de Software

Apresentação em tema: "Arquitetura de Sistemas de Software"— Transcrição da apresentação:

1 Arquitetura de Sistemas de Software

2 Introdução No ciclo de vida do desenvolvimento de software podemos encontrar diversas etapas e todas com seus propósitos muito bem definidos, porém, uma que podemos dizer com segurança ser de extrema importância é a arquitetura do software;

3 Introdução No ciclo de vida do desenvolvimento de software podemos encontrar diversas etapas e todas com seus propósitos muito bem definidos, porém, uma que podemos dizer com segurança ser de extrema importância é a arquitetura do software;

4 Introdução O que é Arquitetura de Software ?
A arquitetura de software é uma descrição do sistema que auxilia na compreensão de como o sistema irá se comportar;

5 Introdução O que é Arquitetura de Software ?
Arquitetura é um meio de se obter uma análise antecipada para garantir que a abordagem de design apresentada, produzirá um sistema que alcance os requisitos exigidos pelo cliente, tais como: desempenho, segurança, disponibilidade, integridade, flexibilidade e etc.

6 Introdução Por que devo documentar a arquitetura do sistema?
"Fazer negócios sem publicidade ou projetar uma arquitetura sem documentar, é como piscar para uma garota no escuro. Você sabe que está fazendo, mas ninguém mais sabe.“ (Steuart Henderson Britt)

7 Introdução Por que devo documentar a arquitetura do sistema?
"Fazer negócios sem publicidade ou projetar uma arquitetura sem documentar, é como piscar para uma garota no escuro. Você sabe que está fazendo, mas ninguém mais sabe.“ (Steuart Henderson Britt)

8 Introdução Por que devo documentar a arquitetura do sistema?
Por mais perfeita e adequada que seja sua arquitetura, será inútil para outras pessoas que não a conhecem e que não podem entendê-la bem o suficiente para manuseá-la. Portanto, a documentação se faz essencial para todos os casos.

9 Introdução Estrutura do documento Histórico de revisões Visão geral
Requisitos não-funcionais Mecanismos arquiteturais Fundamentação Visão de casos de uso Componentes Implantação

10 Introdução Histórico de revisões
Alguns dos principais objetivos que essa fase do documento pretende alcançar são: deixar explícito cada alteração feita no documento; controlar a versão do documento; deixar explícito o responsável pela alteração; controlar a veracidade do documento.

11 Introdução Nesta fase do documento, o responsável deve apresentar de forma clara a objetividade do trabalho a ser documentado. De forma sucinta, descrever do que se trata o documento e quais assuntos serão abordados no mesmo.

12 Introdução Visão Geral
A fase visão geral do documento, tem como objetivo, demonstrar de forma sucinta, os principais elementos que compõe a arquitetura do sistema. Geralmente essa etapa é apresentada com uma figura que deve servir como referência inicial para qualquer entidade que tenha ou pretende entender o sistema tecnicamente.

13 Introdução Requisitos Não-Funcionais
Nesta fase do documento, é necessário listar os requisitos não funcionais encontrados no sistema, tais como: portabilidade, usabilidade, desempenho e etc. O objetivo é colocar o nome do requisito e descrever com detalhes suas características.

14 Introdução Requisitos Não-Funcionais

15 Introdução Mecanismos Arquiteturais
Esta fase do documento, devemos listar os mecanismos arquiteturais encontrados no sistema, ou seja, identificar todos os mecanismos de análise, mecanismo de design e mecanismo de implementação. O intuito desta etapa é verificar e garantir que todas as preocupações técnicas relativas à arquitetura do sistema tenham sido capturadas

16

17 Introdução Fundamentação
Nesta fase, o arquiteto deve fundamentar todas as decisões importantes de design. Além disso, deve descrever as alternativas significativas rejeitadas no projeto. Esta seção pode indicar hipóteses, restrições, resultados de análises e experiências significativas para a arquitetura.

18 Introdução Visão de Caso de Uso
Esta fase, será responsável por apresentar os casos de uso ou cenários escolhidos para a validação da arquitetura apresentada. Casos de uso, backlog, requisitos de usuários ou qualquer outro nome que represente os itens relevantes para o funcionamento do sistema final, o intuito é exercitar e testar os principais aspectos de risco da arquitetura.

19 Introdução Componentes
Nesta fase, o arquiteto deve apresentar o diagrama de componentes. É recomendado como boas práticas de mercado o uso do modelo UML para criação do diagrama, que deve apresentar os possíveis componentes e suas dependências. Além disso, o arquiteto deve criar uma tabela detalhando as responsabilidades de cada componente.

20 Introdução Componentes

21 Introdução Implantação
Nesta fase, o arquiteto deve descreve as configurações de distribuição dos componentes de software na área física em que serão implantados.

22 Introdução Implantação

23 Introdução Existem diferentes maneiras e padrões para documentação da arquitetura de software, porém, pode-se concluir, que o importante é criar um documento que descreva com clareza os principais aspectos envolvidos no escopo do sistema. Além disso, pode-se customizar a documentação de forma que ela se torne exequível para realidade de cada projeto. O importante é documentar com seriedade e comprometimento com o seu trabalho.

24 Visão Geral Tem como foco principal a análise das necessidades dos usuários dentro de um possível sistema a ser desenvolvido; A mesma procura não se aprofundar em detalhes tecnológicos, mas sim se concentrar em que o cliente realmente precisa, levando em conta ainda as características do negócio em que o mesmo está inserido;

25 Visão Geral A Arquitetura de Sistemas de Informação oferece ainda uma visão genérica do sistema a ser criado, possibilitando a consideração de alternativas em um ponto no qual mudanças ainda possuem facilidades para sua implementação a um baixo custo. Decisões de impacto ainda podem ser tomadas neste ponto, já que o mesmo estará precedendo a construção do sistema;

26 Visão Geral O estudo de cenários e a utilização casos de uso relativos ao negócio do cliente são de fundamental importância, sobretudo para atestar que os analistas realmente compreenderam aquilo que o cliente tentou lhes transmitir.

27 Visão Geral Além de disporem de uma representação gráfica em que constam diferentes funcionalidades e agentes relacionados às mesmas (atores), é extremamente comum que casos de uso venham acompanhados por uma descrição textual.

28 Visão Geral Esta descrição textual costuma detalhar as diversas necessidades a serem atendidas, bem como regras para se tomar como base e prováveis comportamentos de exceção que possam influenciar neste processo.

29 Visão Geral Tudo isso contribui não apenas para um melhor trabalho dos profissionais elencados para a implementação de uma solução, como também para se chegar a um acordo consensual entre a área de tecnologia e aqueles que solicitaram o projeto.

30 Visão Geral Requisitos como desempenho, segurança, tolerância a falhas e facilidade de manutenção deverão ser colocados em pauta, sem que porém se avance no aspecto tecnológico da questão.

31 Visão Geral Se bem conduzida, este tipo de arquitetura pode levar o projeto a alcançar a satisfação do cliente. Assim sendo, um projeto bem definido conseguirá conquistar a confiança do cliente, ao mesmo tempo em que cumprirá os objetivos a que o mesmo se propôs.

32 Referências Bibliográficas