Advertisement
Guest User

Untitled

a guest
Nov 21st, 2019
109
0
Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 5.41 KB | None | 0 0
  1. Aluno: Rainer Resende
  2.  
  3. Aula de Análise de sistemas
  4.  
  5. 1- Uml resumindo é uma linguagem de notação que significa que é uma forma de escrever, ilustrar e se comunicar em projetos de sistemas. Essa é uma linguagem unificada, ou seja, é uma linguagem única e simples para que qualquer um que a ler poderá entender facilmente.
  6.  
  7. 2- A finalidade do UML é deixar as coisas mais claras unificando elas e deixando tudo mais padronizado de forma que todos os receptores da mensagem possam entender o padrão usado. Então ele ajuda na facilidade de projetar o sistema.
  8.  
  9. 3- Os diagramas usados são diagramas de Atividades, de Casos de uso, de classes, de sequencias e de instalação
  10.  
  11. 4- O Diagrama de Caso de Uso serve para representar como os casos de uso interagem entre si no sistema e com os usuários (atores), ou seja, como as funcionalidades se relacionarão umas com as outras e como serão utilizadas pelo usuário, durante o uso do sistema.
  12.  
  13. 5- Um ator é quem fará a execução do caso de uso (quem executará a funcionalidade que está especificada no caso de uso). Atores podem ser de dois tipos: humano e sistêmico.
  14. Um ator humano é uma pessoa física, que no diagrama deve possuir como nome o papel que a pessoa executa no contexto empresarial onde o sistema será utilizado. Por exemplo: Cliente, Fornecedor, Atendente.
  15. Um ator sistêmico é um sistema, ou módulo de um sistema, ou componente de um sistema, que realizará a execução da funcionalidade que está especificada pelo caso de uso. No diagrama deve possuir seu nome de fato (se o ator é o sistema “Disparador de rotinas batch” por exemplo, este deve ser o nome do ator sistêmico).
  16.  
  17. 6- Um caso de uso, como elemento num diagrama, é a elipse (ou bolinha). O que tem “dentro da bolinha” são fluxos (ou cenários). Os fluxos compõem a especificação do caso de uso, “o que tem dentro da bolinha”.
  18. Na especificação de um caso de uso, de relevante temos os fluxos (Principal, Alternativo e Exceção). Cada fluxo possui uma série de passos (steps), e uma lógica sequencial que demonstra, passo a passo, como o fluxo é executado.
  19.  
  20. 7- Associação –
  21. Nos modelos UML, uma associação é um relacionamento entre dois classificadores, como classes ou casos de uso, que descreve as razões para o relacionamento e as regras que o regem.
  22.  
  23.  
  24. Inclusão –
  25. Na modelagem UML, um relacionamento de inclusão é aquele no qual um caso de uso (o caso de uso base) inclui a funcionalidade de outro caso de uso (o caso de uso de inclusão). O relacionamento de inclusão suporta a reutilização da funcionalidade em um modelo de caso de uso.
  26. Extensão –
  27. Na modelagem UML, é possível utilizar um relacionamento de extensão para especificar que um caso de uso (extensão) estende o comportamento de outro caso de uso (base). Esse tipo de relacionamento revela detalhes sobre um sistema ou aplicativo que normalmente estão ocultos em um caso de uso.
  28. Generalização –
  29. Em modelagem UML, um relacionamento de generalização é um relacionamento no qual um elemento de modelo (o filho) é baseado em outro elemento de modelo (o pai). Os relacionamentos de generalização são utilizados em diagramas de classe, componente, implementação e caso de uso para indicar que o filho recebe todos os atributos, operações e relacionamentos definidos no pai.
  30.  
  31. 8 – Este tipo de representação é bastante útil no desenvolvimento de sistemas e de softwares de computação, pois define todas as classes que o sistema precisa ter e serve de base para a construção de outros diagramas que definem o tipo de comunicação, sequência e estados dos sistemas.
  32. O diagrama de classes é a parte central da Linguagem de Modelagem Unificada (UML – Unfied Modelling Language). Ele representa as principais finalidades da UML, tendo a função de separar os elementos de design da codificação do sistema.
  33. 9 – Representação de um domínio do sistema, através de objetos e suas interações
  34. 10 – Associação - (Associação – conector sem pontas) – É um tipo de relacionamento usado entre classes. Aplicável a classes que são independentes (vivem sem dependência umas das outras), mas que em algum momento no ciclo de vida do software (enquanto ele está em execução) podem ter alguma relação conceitual.
  35. Generalização - (Herança – conector com seta em uma das pontas) – É um tipo de relacionamento onde a classe generalizada (onde a “ponta da seta” do conector fica) fornece recursos para a classe especializada (herdeira). Excetuando conceitos mais avançados (como padrões de projeto, interfaces, visibilidades específicas etc.), tudo que a classe mãe (generalizada) tem, a filha (especializada) terá.
  36. Agregação - (Agregação – conector com um “diamante” vazado na ponta) – É um tipo de relacionamento onde a classe agregada usa outras classes para “existir”, mas pode viver sem ela. Por exemplo, a classe “CorpoHumano” possui uma agregação com a classe “Mao”. Sem a “Mao” a classe “CorpoHumano” pode existir. Mais detalhe neste post completo sobre Agregação.
  37. 11 - A regra de sobreposição força uma subclasse (também conhecida como uma instância de supertipo) a ter grupos de entidades sobrepostas. Já as Restrições de disjunções - será necessário decidir se uma instância de supertipo pode ser simultaneamente um membro de dois ou mais subtipos. A regra da disjunção força subclasses a terem grupos de entidades disjuntas.
Advertisement
Add Comment
Please, Sign In to add comment
Advertisement