#casosdeuso

Un caso de uso describe una secuencia de interacciones entre un sistema y un actor externo para una funcionalidad determinada. Hay distintos pero todos tienen estos elementos: -Identificar único. -Un título que indique el objetivo de un caso de uso. -Un detonante que genere la secuencia de pasos. -La precondición que se debe cumplir para iniciar un caso de uso. -La postcondición que debe tener el sistema luego de ejecutar el caso de uso. -Los pasos entre el actor externo y el sistema. Hay que comentar que un actor puede ser una persona, un sistema externo o un dispositivo de hardware. Ahora vamos a ver un ejemplo donde podemos crear uno para la funcionalidad de una aplicación web. Supongamos que tenemos una aplicación web en la cual ofrecemos el servicio de suscripción de streaming para poder ver las carreras de motos GP en vivo y en offline. La funcionalidad que queremos es que el usuario pueda suscribirse a la misma. En la siguiente página hay la tabla de este caso , es un ejemplo simple pero muy didáctico donde puedes ver cómo es un caso de uso simple pero muy claro.

Ejemplo de caso de uso

Diferencia entre un caso de uso y una historia de usuario

Arquitetura Multi-Cloud – Aula 4 – CI/CD em multicloud.

Professor: Rodrigo Vale.

Problemas que devem ser resolvidos:

 - Tratar a limitação de escala;

- Centralizar o monitoramento.

 Metodologia Twelve Factor App:

 Esta metodologia foi criada para ensinar os desenvolvedores a criarem aplicativos prontos para o Cloud.

 1.       Codebase: Código em um sistema de controle. (Repositorio central)

2.       Dependencies: As dependências devem ser declaradas e isoladas.

3.       Config: Configurações podem variar entre ambientes diferentes. (A sua aplicação tem que ser capaz de ser alterada por meio de um arquivo de configuração externo ao código)

4.       Baking services: A base de código não difere bibliotecas e APIs. (O Aplicativo precisa ser capaz de migrar de serviços sem a necessidade de recompilar o código)

5.       Build, release and run: Separar estritamente os builds e executar em estágios.

6.       Processos de 12 fatores não gravam estado.

7.       Port binding: A porta a qual o aplicativo esta conectado ou disponível também é salva na config.

8.       Concurrency: Concorrencia é simples e confiável. (

9.       Disposability: Devem ser iniciados ou parados o mínimo possível. (O processo de recuperação ao ultimo estado valido precisa ocorrer de forma simples e rápida)

10.   Dev/prod parity: São planejadas para implantações continuas, mantendo menos disparidades entre os ambientes de produção e desenvolvimento.

11.   Logs: Tratar logs como fluxo de eventos. (O log precisa fazer parte do ciclo de eventos de todos os processos, não é mais um arquivo que só será acessado em caso de falha)

12.   Admin Process: Executar tarefas de gerenciamento, como processos únicos. (Migração de bancos de dados ou execução de scripts). – Toda atividade que se torna rotineira, esta deve ser tratada como uma atividade de operação.

  [Resumo]

  Arquitetura Multi-Cloud: Aula 3 – Casos de uso

Professor: Rodrigo Vale.

 “As decisões nem sempre são tomadas para satisfarer a melhor tecnologia”.

 - Estudo de caso 1:

 Empresa tradicional que possui um próprio DC:

 Estudo de caso 2:

Uma empresa Startup de automação de tratores.

Evolução 1: Uso de um provedor de cloud menor para entregar os dados Brutos.

Evolução 2: Transformação dos dados no pequeno provedor de Cloud.

[Resumo]