Estudo de caso em UML



Documentos relacionados
Histórico da Revisão. Versão Descrição Autor. 1.0 Versão Inicial

Sumário. Uma visão mais clara da UML

Wilson Moraes Góes. Novatec

UNIVERSIDADE DO ESTADO DE SANTA CATARINA - UDESC DCC Departamento de Ciência da Computação Joinville-SC

2 Diagrama de Caso de Uso

Processo de Desenvolvimento Unificado

O Rational Unified Process (RUP) é um processo de desenvolvimento de software inspirado no

Laboratórios de Informática Regulamento

Concepção e Elaboração

Modelagem de Software Prof. Flávio de Oliveira Silva, Ph.D.

Engenharia de Requisitos Estudo de Caso

Tópicos em Engenharia de Software (Optativa III) AULA 2. Prof. Andrêza Leite (81 )

Diagrama de Caso de Uso e Diagrama de Sequência

ALESSANDRO RODRIGO FRANCO FERNANDO MARTINS RAFAEL ALMEIDA DE OLIVEIRA

PROCESSO DE DESENVOLVIMENTO DE SOFTWARE. Modelos de Processo de Desenvolvimento de Software

INF 2125 PROJETO DE SISTEMAS DE SOFTWARE Prof. Carlos J. P. de Lucena

Satélite. Manual de instalação e configuração. CENPECT Informática cenpect@cenpect.com.br

Análise e projeto de sistemas PROF. REGILAN SILVA

Especialização em Engenharia de Software com Ênfase em Software Livre ESL2/2008. Projeto Agenda Saúde Requisitos e Modelagem UML

Minicurso Computação em Nuvem Prática: Openstack

Projeto Disciplinar de Infra-Estrutura de Software ECOFROTA TRIBUNAL THEMIS

TI Aplicada. Aula 02 Áreas e Profissionais de TI. Prof. MSc. Edilberto Silva prof.edilberto.silva@gmail.com

UNIVERSIDADE FEDERAL DO PARANÁ UFPR Bacharelado em Ciência da Computação

Software de Controle de Acesso

Documento de Análise e Projeto VideoSystem

Introdução à Engenharia de Software

Tutorial Ouvidoria. Acesso, Utilização, Visualização das Manifestações e Resposta ao Manifestante

Histórico da Revisão. Data Versão Descrição Autor

UML 2. Guia Prático. Gilleanes T.A. Guedes. Novatec. Obra revisada e ampliada a partir do título Guia de Consulta Rápida UML 2

Sistema de Gerenciamento de Pet Shop. Documento de Requisitos

Especificações da oferta Gerenciamento de dispositivos distribuídos: Gerenciamento de ativos

Introdução a Computação

Engenharia de Software na Prática Hélio Engholm Jr.

Análise e Projeto Orientado a Objetos. Modelagem de Domínio

Projeto de Arquitetura

Baseado na portaria n 373 de 25 de fevereiro de 2011 do Ministério do Trabalho e Emprego;

Unified Modeling Language UML - Notações

INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DE SANTA CATARINA DEPARTAMENTO DE SAÚDE E SERVIÇOS CURSO TÉCNICO EM INFORMÁTICA

UML: Unified Modeling Language. Graduação em Informática 2008 Profa. Itana Gimenes

SABiO: Systematic Approach for Building Ontologies

TRABALHO DE DIPLOMAÇÃO Regime Modular ORIENTAÇÕES SOBRE O ROTEIRO DO PROJETO FINAL DE SISTEMAS DE INFORMAÇÕES

UML: Casos de Uso. Projeto de Sistemas de Software

Prof. Raul Sidnei Wazlawick UFSC-CTC-INE. Fonte: Análise e Projeto de Sistemas de Informação Orientados a Objetos, 2ª Edição, Elsevier, 2010.

Fase 1: Engenharia de Produto

Aula 2 Revisão 1. Ciclo de Vida. Processo de Desenvolvimento de SW. Processo de Desenvolvimento de SW. Processo de Desenvolvimento de SW

Manual do Teclado de Satisfação Online WebOpinião

Metodologia de Desenvolvimento de Sistemas

CASO DE USO. Isac Aguiar isacaguiar.com.br

1 UML (UNIFIED MODELING LANGUAGE)

Prof. Marcelo Machado Cunha

EMF. Eclipse Modeling Framework. José G. de Souza Júnior. direção: Dr. Denivaldo Lopes

UNIVERSIDADE FEDERAL DO PARANÁ. CURSO: Ciência da Computação DATA: / / 2013 PERÍODO: 4 o.

ATIVIDADES PRÁTICAS SUPERVISIONADAS

Universidade Católica de Petrópolis Análise Orientada a Objetos. Introdução

Projeto Pé na Dança. Bruno Barros Comunicador Visual /

FMR Faculdade Marechal Rondon Gestão de Sistemas de Informação Prof. Ms. Elvio Gilberto da Silva

Softwares Aplicativos Banco de Dados

UML Aula III Diagramas de Estado, Atividades, Componentes e Instalação

ALGORITMOS. Supervisão: Prof. Dr.º Denivaldo Lopes

Políticas de Segurança. Everson Santos Araujo

PLANO DE ENSINO. CURSO: Sistemas de Informação PERÍODO LETIVO: SEMESTRE: 4º. C/H SEMANAL Análise, Projeto e Implementação de Sistemas I

TCE-Login. Manual Técnico

Organização Curricular do Curso Superior de Tecnologia em Sistemas para Internet

Uma Introdução à Engenharia de Software

3. Fase de Planejamento dos Ciclos de Construção do Software

Instrução de Trabalho. Criar Imagem

INF 2125 PROJETO DE SISTEMAS DE SOFTWARE Prof. Carlos J. P. de Lucena

Nota de Aplicação. Vijeo Citect Configuração Control / View-only Client

APOO Análise e Projeto Orientado a Objetos. Requisitos

BEM VINDO (A) À ACTVS SOFTWARE E APOIO A GESTÃO

Manual de Instalação ( Client / Server ) Versão 1.0

Análise e Projeto Orientados por Objetos

Faculdade Pitágoras. Engenharia de Software. Prof.: Julio Cesar da Silva.

Tutorial Wireless para Windows 7 IA UNESP V5

Pontifícia Universidade Católica

Nota de Aplicação. ATV61/71 Em rede Ethernet - Função FDR 1.0. Suporte Técnico Brasil. Versão:

ORGANIZAÇÃO CURRICULAR

3 Um Framework Orientado a Aspectos para Monitoramento e Análise de Processos de Negócio

BEM VINDO. Gestor. O que é o ProdutivoApp...2. Tipos de usuários...2. Dashboard (tela principal)...3. Menu Categorias...4. Menu Atividades...

UNIVERSIDADE DE MOGI DAS CRUZES Centro de Ciências Exatas e Tecnológicas

Manual de Operação do Leitor de Cartões

Autores/Grupo: TULIO, LUIS, FRANCISCO e JULIANO. Curso: Gestão da Tecnologia da Informação. Professor: ITAIR PEREIRA DA SILVA GESTÃO DE PESSOAS

PROCEDIMENTOS PARA A UTILIZAÇÃO DO SISTEMA DE SOLICITAÇÃO DE ORDEM DE SERVIÇO (SOSI) STI Unesp - Campus Experimental de Ourinhos

RUP. Evolução. Principais Características do RUP. Principais Características do RUP RUP

Engenharia de Software

FACULDADE DE ENGENHARIA DE COMPUTAÇÃO. PROJETO FINAL I e II PLANO DE TRABALHO <NOME DO TRABALHO> <Nome do Aluno> <Nome do Orientador>

Laboratório - Exploração do FTP

Notas de Aula 04: Casos de uso de um sistema

Conteúdo Programático

Documento de Visão REPOSITÓRIO DE ARQUIVOS V1.0

Informática I. Aula 6. Aula 6-12/09/2007 1

1. Tela de Acesso pg Cadastro pg Abas de navegação pg Abas dados cadastrais pg Aba grupo de usuários pg.

SIMARPE Sistema de Arquivo Permanente

Aplicação Prática de Lua para Web

SISTEMAS OPERACIONAIS LIVRES. Professor Carlos Muniz

Transcrição:

Laboratory of Software Engineering and Computer Network Engineering for a better life Estudo de caso em UML Denivaldo Lopes LESERC (Laboratório de Engenharia de Software e Rede de Computadores) Web Site: http://www.leserc.dee.ufma.br/ Contato: denivaldo.lopes AT dee.ufma.br 1

Sumário Sistema de controle de acesso a um prédio Diagramas de caso de uso Diagrama de seqüência Diagramas de colaboração Diagrama de classe Diagrama de atividade Diagrama de implantação 2

Abordagem UML é uma linguagem de modelagem. UML não é um método de modelagem. UML não especifica uma abordagem de modelagem, cada um é livre para escolher um processo. Um método serve para canalizar e ordenar a criatividade de pessoas que são responsáveis pela modelagem de uma aplicação. UML por si só não garante um resultado satisfatório de desenvolvimento do sistema. 3

Abordagem O valor não está no método, mas nas pessoas que se servem do método. A abordagem que usaremos é seguinte: Caso de uso Arquitetura Iterativo e Incremental <<Centrado na>> <<dirigido por>> <<No transcorrer>> Processo genérico Grupo A Empresa B 4

Determinação das necessidades O contato com o contratante: as necessidades do sistema são determinadas à partir das informações recolhidas durante os encontros com os funcionários de informática e os futuros utilizadores do sistemas. Os usuários dizem o que querem Os prof. de informática levantam as necessidades que os usuários desejam realizar. Evitar conversas sobre hardware e linguagens de programação. Centrar a discussão no problema e na lógica do negócio. 5

Representação das necessidades As necessidades podem ser expressas na forma de caso de uso Utilizador A Utilizador C Conjunto de Necessidades Utilizador B 6

Análise do domínio A modelagem através de caso de uso segue um critério de decomposição funcional. Evite fazer a decomposição através da arquitetura do sistema, para não engessar o sistema. Os aspectos estáticos devem ser expressos por diagramas de classe Os aspectos dinâmicos devem ser expressos por diagramas de colaboração e atividade 7

Controle de acesso de um prédio O espaço a proteger é um prédio de dois níveis com uma área de 250 m2 O prédio é dividido em 4 zonas Compartimentos: Salas de escritório Laboratórios Administração Deve haver direitos de acesso Um administrador do sistema Guardas Usuários O sistema deve permitir semanas tipo (configuração do acesso a salas em função do horário, dia da semana) 8

Descrição do caso de uso Representação das categorias de usuários Supervisor Portador de cartão Guarda Ator Supervisor Guarda Usuário Caso de uso Configura o sistema Usa o sistema Validação de uma solicitação de acesso 9

Caso de uso supervisor configuração Identificação Controle de acesso Portador de cartão Guarda Supervisão 10

Caso de uso: configuração Identificação :Supervisor :Sistema Login(senha) verificação Autorização 11

Caso de uso: configuração Modificações das informações relativas a uma porta :Supervisor :Sistema Modificação de uma porta Lista de porta Escolha de uma porta Informações da porta Modificação das informações Informação da porta Salvar informações 12

Caso de uso: configuração Modificações das informações relativas a uma pessoa :Supervisor :Sistema Modificação de uma pessoa Lista de pessoas Escolha de uma pessoa Informações da pessoa Modificação das informações Informação da pessoa Salvar informações 13

Caso de uso: configuração Modificações das informações relativas a um grupo de pessoas :Supervisor :Sistema Modificação de um grupo de pessoas Lista de grupos Escolha de um grupo de pessoas Informações do grupo Modificação das informações Informações do grupo de pessoas Salvar informações 14

Caso de uso: configuração Modificações das informações relativas a um grupo de portas :Supervisor :Sistema Modificação de um grupo de portas Lista de grupos Escolha de um grupo de portas Informações do grupo Modificação das informações Informações do grupo de portas Salvar informações 15

Caso de uso: configuração Busca de uma pessoa em função do cartão :Supervisor :Sistema Busca de uma pessoa (cartão) Informações das pessoas 16

Caso de uso: configuração Busca de portas autorizadas para uma pessoa :Sistema :Supervisor Busca de portas autorizadas Lista de pessoas Escolha de uma pessoa Lista de portas Escolha de uma porta Informações da porta 17

Caso de uso: configuração Modificações de direitos de acesso de um grupo de pessoas :Supervisor :Sistema Modificação do acesso de um grupo de pessoas Lista o grupo de pessoas Escolha de um grupo de pessoas Informações de um grupo de pessoas Escolha de um acesso a um grupo de portas Informações sobre o acesso Modificações das informações Informações sobre o acesso Salvar informações 18

Caso de uso: configuração Modificações de um tipo de semana :Supervisor :Sistema Modificação de uma semana tipo Lista de semanas tipo Escolha de uma semana tipo Informações de uma semana tipo Modificações das informações Informações sobre a semana tipo Salvar informações 19

Caso de uso: configuração Busca dos direitos de acesso de uma pessoa por uma porta específica :Supervisor :Sistema Busca de direitos de acesso de uma pessoa por uma porta Lista de portas Escolha de porta Lista de pessoas Escolha de pessoas Informações sobre o acesso 20

Caso de uso: supervisão O guarda utiliza a supervisão Identificação :Guarda :Sistema Login(senha) verificação Autorização 21

Caso de uso: supervisão Relatório de eventos :Guarda :Sistema Relatório de alarmes (período) Lista de alarmes 22

Caso de uso: supervisão Relatório de eventos :Guarda :Sistema Relatório de eventos (período) Eventos 23

Caso de uso: supervisão Abertura manual de uma porta :Guarda :Sistema Abertura manual de uma porta Lista de portas Escolha de uma porta Abertura da porta Registro do evento 24

Caso de uso: supervisão Alarme de incêndio :Guarda :Sistema Incêndio Abertura de todas as portas 25

Caso de uso: controle de acesso O portador de cartão utiliza o controle de acesso :Portador de Cartão :Sistema Apresenta seu cartão Verifica os direitos de acesso [direitos de acesso OK] Abertura de porta 26

Resumo de Caso de uso Caso de uso Configuração Configuração Configuração Configuração Configuração Configuração Configuração Configuração Supervisão Supervisão Supervisão Supervisão Supervisão Controle de acesso Cenários principais Identificação Modificação de informações relativas a uma porta Modificação de informações relativas a uma pessoa Modificação de informações relativas a um grupo de pessoas Procura de uma pessoa em função do cartão Modificação de direitos de acesso de um grupo de pessoas sobre um grupo de portas Modificação de uma semana tipo Apresentação de direitos de acesso de uma pessoa por uma porta específica Identificação Relatório de eventos Detecção de alarmes Abertura manual de uma porta Incêndio Autorização de passagem 27

Exercício Propor diagramas de colaboração, diagramas de classe e diagrama de implantação 28

Diagrama de colaboração referente a identificação 1:nome=LerNome() 2:senha=LerSenha() :Supervisor :Login 3:Verificar(senha) Supervisor: Pessoa Diagrama de classe preliminar Login Pessoa 29

Diagrama de estado-transição Espera nome Nome lido Espera senha [nome e senha incorreto] [nome e senha OK] 30

Diagrama de colaboração referente a modificação das informações de uma porta 2:Ler() 3:Escrever() :Supervisor p:porta 1:selecionar() :Porta 31

Pesquisa de portas habilitadas para uma pessoa específica 1:p=Selecionar() :Pessoa 1:[i=1...n] g=selecionar() p: Pessoa :Supervisor 3:Ler informações :Grupo de Portas g: Grupo de Portas :Porta 32

Modificação de direitos de acesso de um grupo de pessoas a um grupo de portas 1:gPessoas=Selecionar() :GrupoDePessoas 3:Lista de acesso gpessoa: GrupoDePessoas 2:gPortas= Selecionar() :Supervisor 4: a=acesso(gportas) 5:Leitura() 6:Salvar() :Acesso :GrupoDePortas a:acesso gportas: GrupoDePortas 33

Controle de Acesso: autorização de passagem 1:Acesso(num. de cartão) :Porta 2:p=selectionar( num. cartão) :Portador de cartão :Pessoa cartão: Cartão 5:Éválida (Hora) 3:ListarAcesso() 4:ListarAcessoNa(gPortas) p:pessoa :GrupoDePessoas gportas:grupodeportas :Acesso 34

Diagrama de classe (parcial) Porta Pessoa Nome GrupodePortas Nome Acesso Cartão Validade NúmeroCartão GrupodePessoas Nome 35

Arquitetura (Diagrama de Implantação) 1 <<TCP/IP>> Nó 1 <<processador>> <<dispositivo>> <<processador>> PC supervisor Leitor de cartões PC guarda 1 35 2 36

Exposição do exercício feito pelos alunos 37

Exercício Propor o modelo UML de um sistema que gerencia a admissão de candidatos em um curso de pósgraduação. Realizar em grupos de 3 pessoas. Nota: A descrição do domínio deve ser pesquisada. 38

Implicações dos tipos de associação As escolhas feitas na modelagem implicam em várias conseqüências, tanto ao nível da flexibilidade, da extensibilidade, da inteligibilidade dos modelos quanto da criação e destruição de objetos. Os valores da multiplicidade exprimem restrições que influenciam na criação e na destruição dos objetos. A multiplicidade deve ser respeitada seja: Estaticamente. Dinamicamente. 39

Implicações dos tipos de associação Estaticamente: e os valores de multiplicidade devem ser verificados a todo momento, mesmo em regime transitório; Dinamicamente: os valores de multiplicidade devem ser verificados em regime estabelecido, isto implica que as multiplicidades podem não ser respeitadas durante fases transitórias. 40

Implicações dos tipos de associação Exemplo de restrições: Associação 1-1 A 1 1 B A criação de um objeto A requer um objeto B. A criação de um objeto B requer um objeto A. A destruição de uma instância de B ou de A é possível si uma nova instância substituir o objeto A ou B em sua relação com uma instância da classe oposta. 41

Implicações dos tipos de associação Exemplo de restrições: Associação 1-1 A 1 1 A criação de um objeto A requer um objeto B. A criação de um objeto B requer um objeto A. A destruição de um objeto A implica na destruição do objeto B. A destruição de uma instância de B é possível se uma nova instância substitui o objeto B na sua relação com uma instância do tipo A. B 42

Implicações dos tipos de associação Exemplo de restrições: Associação 1-n A 1 1..* A criação de um objeto A requer um objeto B. A criação de um objeto B requer um objeto A. A destruição de um objeto A implica na destruição de todos os objetos B. A destruição de uma instância de B é possível se uma nova instância substitui o objeto B ou se esta instância de B não for a última instância de B associado à A. B 43

Implicações dos tipos de associação Exemplo de restrições: Associação 0 ou 1-1 A 0..1 1 A criação de um objeto A requer um objeto B. A destruição de uma instância de B é possível se uma nova instância substituir o objeto B ou se o objeto B não estiver associado a um objeto do tipo A. B 44

Implicações dos tipos de associação Exemplo de restrições: Associação 1-n A 0..1 1 A criação de um objeto A requer um objeto B. A destruição de uma instância de B é possível se uma nova instância substituir o objeto B ou se um objeto B não está associado a um objeto do tipo A. B 45

Implicações dos tipos de associação Exemplo de restrições: Associação 1-0..n A 1 0..1 A criação de um objeto B requer um objeto A. A destruição de um objeto A é possível e implica na destruição do objeto B associado se ele existe, a menos que uma nova instância substitua este objeto A na sua relação com um objeto B. B 46

Implicações dos tipos de associação Exemplo de restrições: Associação 1-0..n A 1 0..* A criação de um objeto B requer um objeto A. A destruição de um objeto A implica na destruição de todos os objetos B associados a A. B 47

Implicações dos tipos de associação Exemplo de restrições: Associação 0-1..n 0..1 0..* Nenhuma condição. A B 48

Implicações dos tipos de associação Exemplo de restrições: Associação 1-0..n A 0..1 0..* A destruição de um objeto A implica na destruição de todos os objetos B associados à A. B 49

Implicações dos tipos de associação Exemplo de restrições: Associação 0..n-0..n 0..* 0..* nenhuma condição. A B 50

Implicações dos tipos de associação Exemplo de restrições: Associação 0..n-0..n A 0..* 0..* Erro de modelagem: a multiplicidade do lado da composição não deve ser superior à 1. B 51

Bibliografia Pierre-Alain Muller e Nathalie Gaertner, Modélisation objet avec UML, Eyrolles, 5ed., 2004. 52