Baixe o app para aproveitar ainda mais
Prévia do material em texto
1 Modelagem Orientada a Objetos com UML (Overview) Prof. Edson dos Santos Cordeiro 2 Introdução... ?A UML (Unified Modeling Language) é uma linguagem para especificação, construção, visualização e documentação de sistemas de software. ?A notação UML é uma união de sintaxe gráfica de vários métodos. ?O resultado é uma única, comum e ampla linguagem de modelagem utilizável por desenvolvedores de software orientado a objetos. 3 Introdução... ?Os esforços são concentrados em um metamodelo comum, que unifica as semânticas, e em uma notação comum que fornece uma interpretação humana destas semânticas. ?O uso do termo metamodelo se justifica considerando que se trata de uma linguagem para especificar modelos. ?Este metamodelo fornece uma declaração única e comum da sintaxe e semântica dos elementos da UML. 4 Introdução... ?Todos os métodos abordam a modelagem de sistemas (OO) com competência, porém, existem pontos fracos e fortes em cada método. ?A existência de muitos métodos OO gera alguns problemas: ?diferenças casuais e desnecessárias entre os métodos confundindo os usuários (analista, projetistas, etc.); ? falta de um padrão estável, maduro, “completo” que permita a modelagem de sistemas e produção de ferramentas com recursos mais úteis. 5 Introdução... ?“A UML é apenas uma linguagem e, portanto, é somente uma parte de um método para desenvolvimento de software. ?UML é independente do processo, apesar de ser perfeitamente utilizada em processo orientado a casos de uso, centrado na arquitetura, interativo e incremental”. 6 Introdução... ?O que é uma linguagem? ?Definição de linguagem: tudo quanto serve para expressar idéias, sentimentos, modos de comportamentos, ... Todo o sistema de signos que serve de meio de comunicação entre indivíduos... (Aurélio, 1986). ?Linguagem de modelagem (no contexto da informática) disponibiliza uma série de representações (notações) e regras que permitem o projeto de sistemas no âmbito conceitual e físico. ?Linguagem de modelagem é um meio pelo qual pode- se abstrair e projetar sistemas de informação e consequentemente promover a compreensão de suas diversas estruturas. 7 Introdução... ?A UML é uma linguagem destinada a: ?Visualizar ?Especificar ?Construir ?Documentar 8 Introdução... domínio Modelo de análise Modelo de projeto ?UML aborda: 9 Introdução... ?A UML é uma integração de técnicas de diversos métodos (OOSE, OMT E BOOCH). ?OOSE: abordagem orientada a use case que fornece excelente suporte para especificação de requisitos. ?OMT: é especialmente expressivo para a análise de sistemas de informação, contribuiu com o Diagrama de Classes e Diagrama de Estados. ?BOOCH: utiliza a idéia de Diagrama de Estados, Diagrama de Classes, Diagrama de Objetos. 10 Introdução... ?O método Fusion também colaborou com o Grafo de Interação de Objetos. ?O Statecharts de Harel, contribuiu para a criação do Diagrama de Atividades. UML OMT (Rumbaugh) OOSE (Jacobson) ? Diagrama de Estados ? Diagrama de Classes ? Diagrama de Objetos (Diagrama de Colaboração) ? Diagrama de Processos (Diagrama de Deployment) ? Diagrama de Módulos (Diagrama de Componentes) ? Diagrama Use Cases ? Subsistema (Package) ? Diagrama de Classes ? Diagrama de Estados BOOCH FUSION (Coleman) Statecharts (Harel) ? Grafo de Interação de Objetos ? Diagrama de Statecharts (Diagrama de Atividades) 11 Processo de Desenvolvimento em UML ?O Processo de Desenvolvimento de Software com a UML está estruturado, segundo o tempo, em quatro fases: ?Concepção: especifica da visão do sistema; ?Elaboração: planejamento das atividades necessárias e dos recursos requeridos e a especificação do sistema e design da sua arquitetura; ?Construção: desenvolvimento do produto como uma série de interações incrementais; ?Transição: fornecimento do produto para o usuário (fabricação, distribuição e treinamento). 12 Visões do Sistema: Rose... ?A ferramenta ROSE, que implementa a UML, especifica o sistema segundo quatro visões: ?Use Case View: descreve o sistema como um conjunto de transações do ponto de vista dos atores externos. Esta visão é inicialmente criada na fase de concepção do ciclo de vida e direciona o resto do processo. ?Logical View: contém a coleção de packages, classes e relacionamentos. Esta visão é inicialmente criada na fase de elaboração e refinada na fase de construção. 13 Visões do Sistema: Rose ?Component View: contém módulos e subsistemas. Esta visão é inicialmente criada na fase de elaboração e refinada na fase de construção. ?Deployment View: contém a parte física do sistema e a conexão entre estas partes. Esta visão é criada na fase de elaboração do processo. 14 Principais Técnicas... ?Use Case View ?Diagrama de Use Case; ?Descrição do Use Case; ?Diagrama de Seqüência; ?Diagrama de Colaboração. ?Logical View ?Diagrama de Classes; ?Diagrama de Estados. ?Component View ?Diagrama de Componentes. ?Deployment View ?Diagrama Deployment. 15 Visões Use Case View Logical View 16 Diagrama de Use Case - DCU ?Tipicamente usado para especificar ou caracterizar a funcionalidade e o comportamento de um sistema de aplicação, interagindo com um ou mais atores externos. ?Os use cases são desenvolvidos de acordo com os eventos que ocorrem entre os agentes externos e o sistema. 17 DCU - Casos de Uso ?O que são requisitos: ? “Requisitos são uma descrição das necessidades ou desejos para um produto. ?O objetivo básico para a fase de requisitos é identificar e documentar o que é realmente necessário, em uma forma que comunica claramente essa informação ao cliente e aos membros da equipe de desenvolvimento. ?O desafio é definir os requisitos de maneira não ambígua, de modo que os riscos sejam identificados e não aconteçam surpresas quando o produto for finalmente liberado” 18 DCU - Casos de Uso ?Defina o que o sistema deverá fazer (Requisitos Funcionais): ?Calcular valor total (soma dos itens) da nota fiscal; ?Emitir recibo após a efetivação da venda; ?Entrada e baixa automática de estoque; ?Enviar e-mail para clientes aniversariantes; ?Emitir diariamente relação de clientes devedores; ?Fazer backup dos arquivos após o expediente; ?... 19 DCU - Casos de Uso Ref. Função R1.1 Registrar a venda em andamento - itens comprados. R1.3 Capturar a informação do item adquirido através de código de barra ou entrada do código manual. R1.2 Calcular venda: valor itens, imposto, desconto. Funções básicas do sistema: R1.4 Efetuar a baixa do item após completar a venda. R1.5 Registrar as vendas completadas. R1.6 Fazer “log in” com id e senha para usar o sistema. R1.7 Prover um mecanismo de armazenamento. R1.8 Exibir a descrição e o preço do item registrado. 20 DCU - Casos de Uso Ref. Função R2.1 Tratar pagamento em dinheiro, capturar a quantidade recebida e calcular troco. Funções de pagamento R2.2 Tratar pagamento com crédito, capturar informação através de leitora de cartão ou manual. R2.3 Tratar pagamento com cheque, capturar número da conta e cheque através de entrada manual. R2.4 Registrar o pagamento de prestações em contas a receber mediante autorização do setor de crédito. 21 DCU - Casos de Uso ?“Um caso de uso é um documento narrativo que descreve a seqüência de eventos de um ator (um agente externo) que usa um sistema para completar um processo”. ?Casos de uso ilustram as “relações” que o sistema manterá com agentes externos. ?Agentes externos podem ser pessoas, outros sistemas, etc. 22 DCU - Casos de Uso ?As “relações” definem as ações que o agente externo exigirá do sistema a ser desenvolvido e, consequentemente, o comportamento (resposta) que o sistema deverá emitir. ?Casos de uso não podem ser enquadrados como especificação de requisitos (funções e atributos) do sistema e sim como ilustrações de situações (contextos) da realidade onde o sistema será implantado. Não existe um formato ideal de caso de uso. 23 DCU - Casos de Uso: Exemplo Caso de uso: nome do caso de uso. Atores: lista de atores (agentesexternos). Descrição: descrição, seqüencial, dos eventos do caso de uso. Caso de uso: Comprar itens. Atores: cliente, caixa. Descrição:um cliente chega a um ponto de pagamento, com os itens que deseja comprar. O caixa registra os itens de compra e recebe o pagamento. Ao término, o cliente deixa a loja com os itens. 24 DCU - Casos de Uso ?A seqüência típica de eventos (seqüência mais comum) é parte importante do caso de uso expandido. ?Sua finalidade é demonstrar de forma detalhada uma narrativa da interação (“diálogo”) entre o sistema e o agente (ator) obedecendo a seqüência em que ocorrem. Agente Sistema Solicitação 1 Resposta solicitação 1 Solicitação 2 Resposta solicitação 2 25 DCU - Casos de Uso 1. Este caso começa quando um cliente chega a um ponto de pagamento com vários itens que deseja comprar. 2. O caixa registra o identificador de cada item. Se houver mais de um exemplar do mesmo item, o caixa entra com a quantidade. 4. Ao término da entrada de itens, o caixa indica ao Terminal que a entrada de itens está completa. 6. O caixa informa ao cliente o total da venda. 7. O cliente paga em dinheiro. Possivelmente o valor é maior que o total da venda. 8. O caixa registra o pagamento recebido. 10. O caixa deposita o dinheiro e retira o troco. O troco e recibo são entregues ao cliente. 12. O cliente sai com os itens comprados. 3. Determina o preço do item e acrescenta a informação sobre o item à transação corrente de venda. A descrição e o preço do item corrente são exibidos. 5. Calcula e apresenta o total da venda corrente. 9. Exibe o valor do troco a ser devolvido. 11. Registra a venda completada. Ação do agente (ator) Resposta do sistema 26 DCU - Casos de Uso: Seqüência Alternativa ?Linha 2: identificador inválido fornecido. Indicar erro. ?Linha 7: o cliente não tem dinheiro suficiente. Cancela a transação da venda. 27 DCU - Casos de Uso: Modelo (sugestão) - Caso de uso: <nome do caso de uso> - Seção: <nome da seção> Caso de uso: <nome do caso de uso> Atores: <atores envolvidos> Finalidade: <finalidade do caso de uso> Visão geral: <caso de uso de alto nível> - Seqüência típica de eventos Ação do ator Resposta do sistema ... ... - Seqüência alternativa <Número da linha>:<Descrição da exceção> 28 DCU - Casos de Uso ?O caso de uso pode ser descrito em qualquer editor de texto (Notepad, Winword, Bloco de Notas etc); ?É possível associar um documento, por exemplo, um arquivo texto contendo um caso de uso a um modelo na Rational Rose. 29 DCU - Casos de Uso 30 Diagrama de Use Case ?Os agentes externos e qualquer outro sistema que possa interagir com o sistema que está sendo modelado são chamados de atores. ?Um ator modela um tipo de objeto que interage diretamente com o sistema. Cada ator deve ter um nome, como AtorCliente. AtorCliente <<Actor>> 31 Diagrama de Use Case ?Um ator pode: ?apenas fornecer informações ao sistema; ?apenas receber informações do sistema; ?fornecer e receber informações do sistema. ?Perguntas para identificar um ator: ?quem se beneficiará do uso do sistema? ?quem utilizará o sistema? ?quem suportará e manterá o sistema? ?uma pessoa representa vários papéis? ?quem fornecerá informações ao sistema? ?Quem receberá informações do sistema? 32 Diagrama de Use Case ?Criar um ator no Rational Rose: ?Crie os atores: estudante, professor e funcionário. 33 Diagrama de Use Case ?A construção dos diagramas de casos de uso pode iniciar-se através dos casos de uso definidos na etapa anterior. ?Os diagramas de casos de uso demonstram as funções que o sistema desempenhará (casos de uso) e os agentes envolvidos neste processo. ---------------------------------------------------------------- Casos de uso Diagrama de Casos de uso ---------------------------------------------------------------- 34 Diagrama de Use Case ?Um use case é uma seqüência de transações realizadas pelo sistema em resposta ao disparo de um evento. ?Um use case modela a diálogo entre um ator e o sistema. ?Nomes de use cases freqüentemente iniciam com um verbo. ?Um use case é mostrado como uma elipse contendo um nome como CadastrarCliente. CadastrarCliente 35 Diagrama de Use Case ?Criar um use case no Rational Rose: ?crie os uses case: matricular aluno, manter informações do professor e aluno. 36 Exemplo de Use Case e Atores 37 Exemplo de Use Case e Atores Fronteira Comprar itens Log in (iniciar uso) Reembolsar itens compradosCaixa Cliente Atores (agentes) Casos de uso 38 Diagrama de Use Case ?Relacionamentos permitidos nos use cases: Relacionamento De um Use Case para Associação Um ou mais atores Generalização Um use case 39 Construindo o DCU 1. Após as funções o do sistema terem sido listadas (requisitos funcionais), identifique atores e casos de uso. 2. Escreva todos os casos de uso em um formato de alto nível. 3. Desenhe um diagrama de caso de uso. 4. Relacione os casos de uso e ilustre os relacionamentos no diagrama de casos de uso. 40 Visões Use Case View Logical View 41 Diagrama de Classes ?Um Diagrama de Classes é uma representação gráfica para descrições genéricas do sistema. Pode ser usado na: ?Análise: Mostrar regras e responsabilidades comuns de entidades que fornecem o comportamento do sistema e, ?Projeto: Capturar a estrutura das classes que formam a arquitetura do sistema. ?Uma classe captura a estrutura e o comportamento comum de um conjunto de objetos. 42 Diagrama de Classes ?Alguns elementos modelados no diagrama de classes: ?Atributos: Informações do objeto da classe. ?Operações: Serviços fornecidos pela classe. ?Visibilidade (atributos e operações): ?public: os elementos são acessíveis por todas as classes; ?private: os elementos são acessíveis somente pela própria classe e classes friends (C++); ?protected: os elementos são acessíveis somente pela própria classe, subclasses ou pelas classes friends (C++); e ? implemented: os elementos são acessíveis somente pela própria classe. 43 Diagrama de Classes ?Criar uma classe no Rational Rose: ?crie as classes: Disciplina, Turma e Sala 44 Diagrama de Classes Descrição Carga horária Disciplina setDescricao setCargaHoraria getDescricao getCargaHoraria Nome da classe Atributos Operações 45 Diagrama de Classes ?Definindo os atributos no Rational Rose: ?crie os atributos descrição e carga horária para a classe disciplina. 46 Diagrama de Classes ?Definindo as operações no Rational Rose: ?crie as operações get e set Descrição e get e set Carga horária. 47 Diagrama de Classes ?Definindo a visibilidade dos atributos: 48 Diagrama de Classes ?Relacionamentos: ?Os relacionamentos, entre classes, existentes na UML são: ?Generalização; ?Dependência; ?Associação e, ?Agregação. 49 Diagrama de Classes ?Generalização (Herança): ?Um relacionamento de generalização entre classes mostra que a subclasse compartilha a estrutura e/ou comportamento definido em uma ou mais superclasses. Representa o relacionamento “é-um(a)” entre as classes. superclasse subclasse 50 Diagrama de Classes ?Dependência: ?Um relacionamento de dependência entre duas classes mostra que a classe cliente depende da classe servidora, para sua existência. Funcionário Dependente 51 Diagrama de Classes ?Associação: ?Um relacionamento de associação representa uma conexão semântica entre duas classes e é o relacionamento mais utilizado. Pode ser bidirecional ou unidirecional e é representado por uma linha ligando as classes Fornecedor Pedido Cliente Pedido Associação unidirecional 52 Diagrama de Classes ?Agregação: ?Um relacionamento de agregação é uma forma especial de associação, que é usada para mostrar que um tipo de objeto é composto de outro objeto. Um relacionamento de agregação é também chamado de “todo-parte”. Classe TodoClasse Parte 53 Diagrama de Classes ?A agregação pode ser implementada na UML como agregação por referência ou por valor: ?Valor: A agregação por valor indica que o tempo de vida das partes são dependentes do tempo de vida do todo. Quando a agregaçãoé por valor, o “objeto todo” declara uma instância atual do “objeto parte” dentro do corpo do próprio “objeto todo” (losango cheio). ?Referência (default): significa que o “objeto todo” mantém um ponteiro ou uma referência para suas partes (losango vazio). 54 Diagrama de Classes ?Exemplo de agregação por referência e por valor. Aluno Curso DetalhePedido Pedido Referência Valor 55 Diagrama de Classes ?A multiplicidade especifica o número de instâncias de uma classe em relação a outra em uma associação. ?0..1 Zero ou uma instância. ?1 Somente uma instância. ?0..* Zero ou mais instâncias. ?* (Default) número mínimo e máximo de instâncias são ilimitados. ?1..* Uma ou mais instâncias. 56 Diagrama de Classes ?<literal>..* Número exato ou mais instâncias. ?<literal> O número exato de instâncias. ?<literal>..<literal> Faixa de instâncias especificadas. ?<literal>..<literal>,<literal> Número exato de instâncias ou o número de instâncias estará na faixa especificada. ?<literal>..<literal>, <literal>.. <literal> Número de instâncias estará em uma das faixas especificadas. <literal> é qualquer inteiro maior ou igual a 1 57 Bibliografia ?Larman, Graig. Utilizando UML e padrões. Bookman, 2000. ?Booch, G.; Rumbaugh, J.; Jacobson I. UML: guia do usuário. Campus, 2000. ?Prado, A. F. Projeto Orientado a Objetos. UFSCar. ?Quatrani, Terry. Modelagem visual com Rational Rose 2000 e UML. Ciência Moderna, 2001.
Compartilhar