A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

Prof. Thales Castro.  Porque modelar Software  A UML  Porque usar  Diagramas ◦ Diagrama de Caso de Uso.

Apresentações semelhantes


Apresentação em tema: "Prof. Thales Castro.  Porque modelar Software  A UML  Porque usar  Diagramas ◦ Diagrama de Caso de Uso."— Transcrição da apresentação:

1 Prof. Thales Castro

2  Porque modelar Software  A UML  Porque usar  Diagramas ◦ Diagrama de Caso de Uso

3  Qual a real necessidade? ◦ Muitos profissionais afirmam que conseguem determinar as necessidades do sistema “de cabeça”  Errado? ◦ Então, necessidade de se projetar a casa? ◦ Pedreiro/engenheiro conseguem construi-la sem um projeto? ◦ Ou um arquiteto consegue planejar um ambiente sem ter a planta do projeto?

4  Unified Modeling Language  Linguagem de modelagem visual ◦ IMPORTANTE: Não é uma linguagem de programação  Não proprietária  Permite a utilização de diagramas padronizados para: ◦ Visualização ◦ Especificação ◦ Construção ◦ Documentação ◦ Comunicação ◦ Testes

5  Desenvolver o modelo de uma aplicação antes de construí-la, é tão essencial quanto ter uma planta para a construção de uma casa. ◦ Melhor compreensão do sistema a ser desenvolvido ◦ “Visualização” do sistema antes da construção ◦ Diminui a possibilidade de erros ◦ Documentação das decisões tomadas  Ter um rigoroso padrão de linguagem de modelagem é um fator essencial para o sucesso de um projeto. ◦ Sistemas são dinâmicos;

6  Da união de três metodologias de modelagem: ◦ Método de Booch, de Grady Booch; ◦ Método OMT (Object Modeling Technique) de Ivar Jacobson; ◦ Método OOSE (Object Oriented Software Engineering) de James Rumbaugh.  Os “três amigos”.

7 UML BOOCHOMT OOSE  Diagrama de Estados  Diagrama de Objetos (Colaboração)  Diagrama de Processo (Desenvolvimento)  Diagrama de Módulos (Componentes)  Use Case  Subsistemas (Package)  Diagrama de Interações  MiniEspecificação  Diagrama de Estados  Diagrama de Classes

8  Modelagem de Sistemas (não apenas SW)  Estabelecer padronização de forma que métodos conceituais sejam operacionalizados  Criar uma linguagem de modelagem visual utilizável tanto pelo homem quanto pela máquina

9  Requisitos  Análise & Projeto  Programação  Testes Concentram, juntas, cerca de nove diagramas da UML

10  Composto por 9 Diagramas  Cada diagrama composto por uma série de itens  Itens dos diagramas relacionados através de conectores

11  Diagrama de Caso de Uso  Diagrama de Classes  Diagrama de Objetos  Diagrama de Pacotes  Diagrama de Estado  Diagrama de Sequencia  Diagrama de Colaboração  Diagrama de Atividade  Diagrama de Componente  Diagrama de Implantação

12 Diagramas da UML ESTRUTURAIS (ESTÁTICAS)COMPORTAMENTAIS (DINÂMICAS) Compreendem a estrutura do sistema como um todo Disponibilizam informações a respeito do comportamento do sistema

13 ESTRUTURAIS Diagrama de ClassesDiagrama de Objetos Diagrama de Componentes Diagrama de Pacotes Diagrama de Implantação

14 COMPORTAMENTAIS Diagrama de Caso de Uso Diagrama de Atividades Diagrama de Estados Diagrama de Sequencia Diagrama de Colaboração

15  Primeiro: o que é o “Caso de Uso”? Casos de uso são serviços ou funções fornecidas pelo sistema aos seus usuários  Disponibiliza a compreensão das funcionalidades e interações do sistema por qualquer pessoa  As funcionalidades sempre são desempenhadas pelos atores do sistema  Dentre todos,o mais “informal”

16  Componentes: Atores Casos de Uso Relacionamentos Extensões / Inclusões Generalizações

17  Atores: ◦ Representam os papéis desempenhados pelos diversos usuários que poderão iteragir com o sistema ◦ Eventualmente, podem representar um HW ou um sistema  Logo, entidades externas são considerados atores do sistema ◦ SEMPRE deve possuir o nome do papel desempenhado

18  Componentes: GerenteCliente Funcionário Caixa Eletrônico Sistema de Vendas

19  Ocasionalmente, atores podem ser especializados Pessoa Física Jurídica

20  Casos de Uso (CDU ): ◦ Referem-se aos serviços, tarefas ou funções que podem ser utilizados pelos usuários do sistema ◦ Utilizados para expressar e documentar os comportamentos pretendidos para as funções do sistema ◦ Em geral, pode-se associar um CDU a uma tela  Pode-se, no entanto, definir que uma funcionalidade pode abranger mais de uma tela

21  Componentes: Cadastrar Usuários Fazer Login Abrir Conta

22  Associações: ◦ Representam os relacionamentos entre:  Atores X Atores  Atores X Casos de Uso  Casos de Uso X Casos de Uso (includes, extends e generalização) ◦ Demonstra que o Ator utiliza-se de alguma maneira da função do sistema representada no CDU

23  Associações: ◦ Associação representada por uma reta, ligando o Ator ao Caso de Uso ◦ Geralmente as extremidades contêm setas, indicando a navegabilidade da associação  Sentido que a iteração ocorre ou informações trafegam ◦ Associação pode possuir uma descrição própria  Necessidade de esclarecer a natureza da transmissão

24  Componentes: Usuário Realizar Login Cliente Abertura de Conta Gerente

25  Associações especiais: ◦ Especialização / Generalização ◦ Includes ◦ Extends

26  Especialização / Generalização: ◦ Existem características semelhantes ◦ Em algum momento, essas características apresentam diferenças ◦ Definir as características comuns no objeto “Pai” ◦ Características específicas ficam nos “Filhos”

27  Especialização / Generalização: Abertura Conta Especial Abertura de Conta Pessoa Física Jurídica Abertura Conta Poupança

28  Associações especiais: ◦ Especialização / Generalização ◦ Includes ◦ Extends

29  Includes: ◦ Serviços ou itens comuns ocorrem em vários CDU’s ◦ Comportamento comum é descrito em uma funcionalidade (CDU) separada ◦ Funcionalidades (CDU’s) que a desejem utilizar fazem a utilização de sua inclusão

30  Componentes: Cliente Realizar Saque Realizar Depósito Registrar Movimento >

31  Includes: ◦ Tais relacionamentos indicam obrigatoriedade  Execução do primeiro também obriga execução do segundo ◦ Pode ser comparado à chamada de uma sub-rotina ou função ◦ Deve ter sempre o texto include com linhas pontilhadas, apontando para o caso de uso a ser executado

32  Associações especiais: ◦ Especialização / Generalização ◦ Includes ◦ Extends

33  Extends: ◦ Comportamentos comuns também são descritos em uma funcionalidade (CDU) separada ◦ No entanto, existem cenários opcionais que somente ocorrerão em uma situação específica ◦ Normalmente existe um teste para indicar a necessidade de também executar um determinado CDU

34  Componentes: Cliente Encerrar Conta Realizar Saque Realizar Depósito >

35  Sistema bancário: ◦ O cliente pode pedir a abertura de uma Conta Corrente Comum. Esta abertura é geralmente feita por um funcionário, que pode disponibilizar a Conta Especial ou Conta Poupança, a depender do perfil do cliente ◦ Com a conta, o usuário pode consultar o saldo, realizar um depósito ou fazer um saque. Ao realizar, é cadastrado um movimento na conta; ◦ O cliente também pode encerrar a conta. Neste caso, a conta deve estar zerada ◦ Tanto no caso de abertura quanto de fechamento de conta, o funcionário do banco é responsável por fazer a atualização cadastral do funcionário

36

37 Prof. Thales Castro


Carregar ppt "Prof. Thales Castro.  Porque modelar Software  A UML  Porque usar  Diagramas ◦ Diagrama de Caso de Uso."

Apresentações semelhantes


Anúncios Google