Projeto Final - APGS Adriana P. de Medeiros Elaboração Projeto Final - APGS Adriana P. de Medeiros

Elaboração Objetivo da fase Análise e Projeto Documentação Modelo Conceitual Modelo de Projeto Diagramas de Sequência Diagrama de Estados Proposta de componentes Documentação

Objetivo Analisar o domínio do problema e estabelecer uma base arquitetural para o novo sistema Necessário: concluir os casos de uso de sistema construir o modelo conceitual construir o modelo de projeto construir os diagramas de sequência construir diagramas de estados (se necessário) preparar proposta de componentes para o sistema

Elaboração Análise e Projeto

UML: Perspectivas Múltiplas A UML descreve tipos puros de diagramas Diagrama de Classes, Diagrama de Sequência, etc. A mesma notação diagramática pode ser usada em três tipos de perspectivas e modelos: Perspectiva essencial ou conceitual Diagramas representam uma descrição de coisas no mundo real ou domínio de interesse Perspectiva de especificação Diagramas representam uma descrição de abstrações de software ou componentes com especificações e interfaces Perspectiva de implementação Diagramas representam uma descrição de implementação de software em uma tecnologia e linguagem específica (como Java)

Diagrama de Classes: Perspectivas Modelo Conceitual Conceitual Especificação (Tipos e Interfaces) Implementação Modelo de Projeto

Modelo Conceitual Ilustra as classes conceituais significativas em um domínio de problema Pode mostrar: objetos do domínio ou classes conceituais associações entre as classes conceituais atributos de classes conceituais Usando a notação UML, um modelo conceitual é ilustrado como um conjunto de diagramas de classes, nos quais não se definem operações

Durante a Modelagem Conceitual levantamos conceitos relativos Modelo Conceitual Um Modelo Conceitual é uma representação de classes conceituais do mundo real, não de componentes de software. Durante a Modelagem Conceitual levantamos conceitos relativos ao domínio de um problema. Devemos nos concentrar no negócio e não em detalhes de implementação.

Modelo Conceitual Modelos não são corretos ou incorretos; eles são mais úteis ou menos úteis [Fowler 97] Se modelamos um conceito de uma determinada maneira, devemos nos questionar quanto a sua utilidade e se a forma que modelamos é a que mais nos facilitará. Queremos: Representar abstrações Independência de implementações Facilidade de comunicação [Fowler 97] Fowler, M., Analysis Patterns – Reusable Object Models, Addison Wesley, 1997

Exemplo: Modelo Conceitual Pedido Funcionário nome idade * 1 número data preenche Organização * 1 1 Cargo 1..* LinhaDe ItemDePedido quantidade 1 1 Produto {incompleto} Livro CD DVD

Fonte: Livro “Utilizando UML e Padrões” - Craig Larman Dicas Se você não pensar em uma classe conceitual X como um número ou um texto no mundo real, então X provavelmente será uma classe conceitual, não um atributo Concentre-se nas associações cujo conhecimento do relacionamento deve ser preservado por algum tempo (associações “que devem ser conhecidas”) Relacione classes conceituais com uma associação, não com um atributo Fonte: Livro “Utilizando UML e Padrões” - Craig Larman

Modelo de Projeto Contém diversos tipos de diagramas, incluindo os diagramas de classes, de pacotes e de interação Um diagrama de classe de projeto ilustra as especificações para classes de software e interfaces em uma aplicação. Inclui: classes, associações e atributos informação de tipo de atributo métodos interfaces, com suas operações e constantes navegabilidade dependências

Visibilidade de Atributos e Operações Modelo de Projeto Considerar: Classes de Projeto Operações necessárias Visibilidade de Atributos e Operações Padrões de Projeto Pacotes Classes Abstratas Restrições Interfaces Diagramas de Sequência Diagramas de Estados

EspecificaçãoProduto Exemplo: Modelo de Projeto Pedido LinhaDeItemDePedido quantidade: Integer obterSubTotal () número: Integer data: Date 1 1..* contém criarLinhaDeItem(...) obterTotal () 1 descreve * EspecificaçãoProduto descricao: String preco: Moeda ...

Revisão: Classes Abstratas Não podem ser instanciadas São usadas quando não conhecemos a implementação de seus métodos A implementação é dada por suas subclasses

Exemplo Retângulo Triângulo Círculo Figura calcularArea() altura raio base Retângulo Triângulo raio Círculo Figura PI x raio x raio base x altura base x altura/2

Revisão: Interfaces Uma interface é uma coleção de operações usadas para especificar um serviço de uma classe ou componente Interfaces permitem separar a especificação de funcionalidade, em termos de operações, de sua implementação em termos de método Esta separação torna o cliente que usa uma interface independente da implementação desta interface Uma implementação particular de uma interface, como por exemplo uma classe ou componente, pode ser substituída por uma outra implementação sem que seja necessário mudar o cliente

Exemplo Cliente OU Cliente Conta Conta Transacao Transacao create() obterNumero() retirarDinheiro() depositarDinheiro() numero:Integer Cliente Transacao <<usa>> OU Conta create() obterNumero() retirarDinheiro() depositarDinheiro() numero:Integer <<interface>> Transacao retirarDinheiro() depositarDinheiro() Cliente <<usa>>

Revisão: Pacotes Mecanismo de propósito geral para organizar elementos de um modelo em grupos Cliente Regras de Negócio FormPedido Pedido Cliente GUI + Window + Form # EventHandler FormPedido Pedido

Revisão: Generalização de Pacotes GUI + Windows + Form # EventHandler WindowsGUI + GUI::Window + Form # GUI::EventHandler + VBForm MacGUI

Atendimento ao cliente Revisão: Subsistemas Um subsistema é simplesmente uma parte de um sistema e é usado para decompor um sistema complexo em partes “quase” independentes Sistema de Varejo Atendimento ao cliente Controle de Estoque Gestão da Loja

Revisão: Padrões de Projeto São descrições de objetos e classes comunicantes que são customizados para resolver um problema geral de projeto num contexto particular São classificados por dois critérios: Finalidade – o que o padrão faz Criação Estrutural Comportamental Escopo – especifica se o padrão se aplica a Classes Objetos

Revisão: Padrões de Projeto Analisar o uso de padrões de projeto para modelar problemas já conhecidos Criação Singleton, Factory Method, Abstract Factory, etc Estrutural Composite, Decorator, Façade, etc Comportamental Command, Observer, State, Strategy, etc  O uso dos padrões deve ser justificado

Diagrama de Sequência Diagramas de Sequência apresentam a interação entre um grupo de objetos de um sistema, através de mensagens ou controles, em um determinado cenário Servem para modelar o “funcionamento” do sistema, inclusive a concorrência entre objetos Enfatizam a ordem temporal das mensagens Úteis para compreensão da dinâmica, principalmente para iniciantes na OO

Aplicação Diagramas de Sequência são primariamente utilizados para a atribuição de responsabilidades a cada um dos objetos do sistema - operações Além de servir para descoberta das operações, serve para a modelagem da interação entre os objetos Completam o tripé da análise: Casos de Uso - comportamento externo (funcional) Diagramas de Classes - visão estática Diagramas de Sequência - visão dinâmica Internos

Construção Cada Caso de Uso provê vários cenários Um cenário é uma instância de um caso de uso O Diagrama de Classes mostra os objetos da aplicação Fazemos um Diagrama de Sequência mostrando a interação dos objetos em um determinado cenário, ou seja, para cada cenário de um Caso de Uso teremos um diagrama

Construção (cont.) Operações Objetos Cenário Interação Diagrama de Classes Caso de Uso Operações Diagrama de Sequência Objetos Cenário Interação

[refabricar_item = true] Exemplo Janela de Entrada de Pedido :Item_Estoque Atendente Informa dados :Pedido criar() * criar() :linha_Pedido verificar () [verfifica = true] retirar_item() refabricar_item() [refabricar_item = true] criar () :Item_Refabricação [verificar = true] criar () :Item_Entrega data_entrega

criarLinhaDeItem (esp, qtd) Exemplo : Registro : Catálogo Produto : Lista Especificações : Venda li :LinhaDeItem : Lista ItensDeVenda entrarItem(id, qtd) obterEspec(id) buscarEspec(id) criarLinhaDeItem (esp, qtd) criar(esp, qtd) adicionar(li)

Diagrama de Estados Mostra as sequências de estados que um objeto ou uma interação assume em sua vida, em resposta a estímulos recebidos, juntamente com suas respostas e ações Complementa a classe e relaciona os possíveis estados que os objetos da classe podem ter e quais eventos podem causar a mudança de estado (transição)

Exemplo Pedido enviado Alteração de pedido solicitada Cancelamento de pedido solicitado Registrando pedido Alterando pedido Cancelando pedido Pedido para análise requisitado Pedido cancelado Pedido será cancelado Pedido p/ aprovação Analisando pedido Aprovando pedido Pedido não pode ser atendido no momento Pedido já pode ser atendido Pedido será atendido Pedido atendido Colocando pedido em pendência Atendendo pedido

Proposta de Componentes Propor componentes para o novo sistema Especificar as classes para cada componente Definir as interfaces de cada componente Especificar as operações de cada interface (incluindo a assinatura de cada operação) apenas componentes considerados necessários pelo grupo  A proposta deve ser justificada

Referências The Unified Modeling Language User Guide By Booch, Grady / Rumbaugh, Jim / Jacobson, Ivar; ISBN 0201571684. Understanding UML: The Developer's Guide, Harmon, Paul / Watson, Mark; ISBN 1558604650. Utilizando UML e Padrões: Larman, Craig; ISBN 8536303581 Padrões de Projeto: Soluções Reutilizáveis de Software Orientado a Objetos, Gamma, Erich / Helm, Richard / Johnson, Ralph / Vlissides, John; ISBN 8573076100 http://hillside.net/patterns/

Documentação Gerada Introdução Modelagem de Negócio Requisitos Apresentação da empresa (o cliente) Objetivos gerais do projeto Estrutura do documento Modelagem de Negócio Características da empresa (descrição, estrutura organizacional, recursos de informática, expectativa do cliente e processo atual ) Processos de negócio (Casos de uso de negócio) Problemas identificados Necessidades detectadas Requisitos Diagrama de Casos de Uso e descrições Requisitos Suplementares Alternativas de Solução Descrição de cada alternativa Análise comparativa das alternativas Alternativa recomendada pela equipe Alternativa escolhida pelo usuário e critério de escolha

Documentação Gerada Análise e Projeto Modelo Conceitual (diagrama de classes conceituais) Modelo de Projeto - Diagrama de Classes de Projeto tipos de atributos e operações classes abstratas e interfaces padrões de projeto pacotes, etc. Justificativa para o uso de Padrões de Projeto Diagramas de Sequência apenas para os casos de uso de sistema principais - Diagrama de Estados (se necessário) - Proposta de Componentes Glossário Anexos