Aula UML - Unified Modeling Language

UML Unified Modeling Language Linguagem de Modelagem Unificada Requisitos, Casos de Uso no ArgoUML Professor: Cloves Rocha PhD Student in Computer Science MSc. in Computer Science

Agenda •Requisitos • Funcionais • Não-funcionais •Problemas •Possíveis Soluções •UML •Diagrama de Casos de Uso •Diagrama de Atividades •Diagramas de Caso de Uso no Rose •Diagramas de Atividades no Rose

De onde surgiu? • 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”. “Fundadores” da UML

A linguagem UML • UML (Unified Modeling Language) – Linguagem de Modelagem Unificada; • É uma linguagem de modelagem (visual), não uma linguagem de programação; • É uma linguagem de modelagem não proprietária; • Permite a utilização de diagramas padronizados para especificação e visualização de um sistema.

De onde surgiu? • A primeira versão foi lançada em 1996 • Em 1997 a UML foi adotada pela a OMG (Object Management Group – Grupo de gerenciamento de Objetos) como linguagem padrão de modelagem.

O que é modelagem? •Atividade de construir modelos que expliquem as características ou comportamentos de um sistema. •A UML pode ser usada com todos os processos durante o ciclo de desenvolvimento do projeto • Análise de requisitos; • Análise de sistema; • Design; • Programação e • Testes.

Por que usar UML? • 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. • Analisar o projeto sobre vários aspectos; • Diminui a possibilidade de erros.

Por que usar UML? • Bons modelos são essenciais para a comunicação entre os times de projetos e para assegurar a beleza arquitetural. • Facilita a programação; • Todo o time entende a modelagem, facilitando assim a manutenção.

Requisitos •Funcionais • Descrevem as funcionalidades que se espera que o sistema disponibilize, de uma forma completa e consistente. • Relacionados a Entradas, Funções, Saídas, Atores. •Não-funcionais • Referem-se às restrições nas quais o sistema deve operar ou propriedades emergentes do sistema (como viabilidade ou tempos de resposta). • Tipos • Produto (Eficiência, Portabilidade, Segurança, etc.); • Organizacionais (Padrões, Entrega, etc.); • Externos (Aspectos Éticos, Legais, etc.).

Problemas • Grande parte dos problemas de um projeto decorre de: •Falta / Ineficiente compreensão dos requisitos; •Pouco / Inexistente feedback do cliente; •Requisitos mal especificados.

Possíveis soluções •Feedback • Contar sempre com o cliente próximo na hora de especificar/validar um requisito. •Casos de Uso • Descrição e/ou Diagrama UML. •Prototipação • Ferramentas RAD (Rapid Application Development ); • Paper Prototype – rápida e feedback imediato.

UML A Unified Modeling Language (UML) é uma linguagem de modelagem não proprietária de terceira geração¹. A UML não é um método de desenvolvimento mas ele lhe auxilia a visualizar seu desenho e a comunicação entre objetos. Basicamente, a UML permite que desenvolvedores visualizem os produtos de seu trabalho em diagramas padronizados 1 - projetada para ser facilmente entendida

Porque adotar UML? • Padrão • Academia, Indústria, etc. • Notação Gráfica • Facilita a comunicação • Equipe-Clientes; • Equipe-Equipe. • Suporte de Ferramentas • Rational Rose, Visio, Poseidon, ArgoUML.

Requisitos Gerar nota de restituição Identificação: Nome: RF 018 Gerar nota de restituição Descrição: O usuário pode gerar uma nota que será enviada via correios para contribuintes que tenham direito a restituição. Na nota deve constar o endereço do imóvel correspondente e os dados do proprietário, além de informar os passos para realizar a solicitação de restituição do valor informado, juntamente com o valor a ser restituído. Usuários: DPLAN e ROOT • Essencial ▓ Importante • Desejável

Caso de Uso Identifica ç ã o Nome Status UC 18 Gerar nota de restituição Validado Referênci a s RF 018 Autor Glerter Alcântara Criado e m 23/08/2006 Revisado em Atores: Usuários DPLAN ou usuários ROOT Entradas: ∙ Seqüencial do imóvel (referente ao Corpo de Bombeiros). Pré-condições: 1. O servidor deve estar funcionando corretamente Fluxo de eventos: 1. O usuário escolhe a opção “gerenciar pagamento” na tela principal do sistema; 2. Em seguida escolhe a opção “gerar nota de restituição”; 3. Na tela seguinte, preenche o campo “seqüencial do imóvel” e confirma a operação clicando em “enviar”; 4. O sistema busca na base de dados informações referentes ao imóvel com seqüencial igual ao passado como parâmetro; 5. O sistema mostra na tela uma nota de restituição, com as informações do imóvel e do proprietário, o valor a ser restituído, a data atual e uma seqüência de passos a serem seguidos para efetivar a restituição. 6. O usuário é capaz de imprimir essa nota de restituição clicando em “imprimir” (opção que irá aparecer abaixo das informações da nota de restituição). FS 01 - Fluxo Secundário 1: Campo “seqüencial do imóvel” em branco 1. O sistema mostra uma mensagem na tela informando a obrigatoriedade do preenchimento do campo; 2. O sistema retorna para a tela “verificar pagamento”. FS 02 – Fluxo Secundário 2: Seqüencial inválido 1. O sistema mostra uma mensagem na tela informando que o seqüencial passado como parâmetro pelo usuário está num formato inválido ou possui caracteres inválidos; 2. O formulário é re-exibido com todas as informações já fornecidas. FS 03 – Fluxo Secundário 3: Imóvel não encontrado 1. O sistema mostra uma mensagem na tela informando que não foi encontrado nenhum imóvel com o seqüencial passado pelo usuário; 2. O sistema retorna para a tela “verificar pagamento”. FS 04 – Fluxo Secundário 4: Cancelamento da busca/verificação 1. O usuário pode cancelar a operação de busca/verificação; 2. O sistema retorna para a tela “gerenciar pagamento”; Saídas e pós condições: O sistema exibe na tela a situação do imóvel referido nos últimos cinco anos.

Diagrama de caso de uso O Diagrama de Caso de Uso descreve a funcionalidade proposta para o novo sistema. Um Caso de Uso representa uma unidade discreta da interação entre um usuário (humano ou máquina) e o sistema. • Capturar o comportamento; • Particiona o sistema em funcionalidades; • Elementos • Atores • Casos de Uso • Relacionamentos

Diagrama de caso de uso •Caso de uso • Na Engenharia de Software, um caso de uso (ou use case) é um tipo de classificador representando uma unidade funcional coerente provida pelo sistema. gerarRelatório Os casos de uso foram propostos inicialmente por Ivar Jacobson em sua metodologia de desenvolvimento de sistemas orientados a objetos OOSE. Posteriormente foi incorporado à UML tornando seu uso uma prática frequente na identificação de requisitos de um sistema.

Diagrama de caso de uso • Ator(es) • Tipicamente, um ator representa um papel que um ser humano, um dispositivo de hardware ou até outro sistema desempenha com o sistema. Matricula r Alun o

Diagrama de caso de uso • Relações: • Entre atores • Entre casos de uso MatricularAluno

Diagrama de caso de uso • Entre casos de Uso • Include, Extend, Generalization.

Diagrama de atividades • O Diagrama de atividade é um diagrama definido pela Linguagem de Modelagem Unificada(UML), e representa os fluxos conduzidos por processamentos. É essencialmente um gráfico de fluxo, mostrando o fluxo de controle de uma atividade para outra.

Exemplo de Caso de uso Identificação UC_01 Função Retirar Dinheiro do caixa eletrônico Atores Cliente, Caixa eletrônico Prioridade Essencial Pré-condição Cliente precisa ter em mãos o cartão do banco Pós-condição Dinheiro sacado com sucesso Fluxo Principal •Cliente insere cartão no dispositivo ∙Cliente digita a senha ∙Máquina autoriza login [FS001] ∙Cliente digita o montante ∙Máquina checa o saldo [FS002] ∙Máquina debita o dinheiro sacado do saldo inicial ∙Máquina dispõe cédulas para cliente ∙Máquina mostra na tela no novo saldo ∙Máquina ejeta cartão ∙Cliente retira cartão Fluxo Secundário [FS001] ∙Senha digitada é inválida ∙Máquina ejeta cartão ∙Cliente retira cartão Fluxo Secundário [FS002] ∙Saldo é menor que o montante requerido ∙Máquina mostra na tela o saldo ∙Máquina ejeta o cartão ∙Cliente retira o cartão • Realizar um saque no caixa eletrônico

Exemplo • Um sistema de Banco: • O cliente poderá: • Sacar, Depositar, Transferir e Tirar Extrato; • Para cada operação o cliente deve se autenticar; • Qualquer funcionário poderá: • Tirar Extrato do cliente; • Solicitar Cartão de crédito para cliente; • O Gerente pode fazer qualquer operação dos funcionários; • Somente o Gerente pode cadastrar ou descadastrar conta.

Resposta Sacar Depositar Transferi r Tirar Extrato Autenticar Cadastrar Conta Descadastrar Conta Solicitar Cartão Tirar Extrato do cliente Autenticação Inválida <<include>> <<Include>> <<include>> <<include>> <<extends>>

Tarefa 1 •Um sistema de controle de hospital • A atendente pode acionar a emergência • Existem dois tipos de emergência: cardíaca e pulmonar. • A atendente pode cadastrar, procurar e atualizar uma emergência. • O gerente pode fazer tudo que a atendente faz. • O gerente pode remover uma emergência • Para cada tarefa, o usuário (qualquer que seja) deve se autenticar no sistema.

Resposta 1 Cadastrar Remover Emergência Emergência Cardíaca Emergência Pulmonar Procurar Atualizar Autenticar Autenticação Inválida

Obrigado! Thank you! Dúvidas? <?php print("ACESSO AO MATERIAL");

Aula UML - Unified Modeling Language

Mais conteúdo relacionado

Mais procurados

Semelhante a Aula UML - Unified Modeling Language

Mais de Cloves da Rocha

Último

Aula UML - Unified Modeling Language