São abstrações identificadas como cidadãos de primeira classe em um modelo. Podem ser:

Transcrição

1 Introdução Linguagens de Modelagem A modelagem é uma parte central de todas as atividades que levam à implantação de um bom software. É uma técnica de engenharia aprovada e bem aceita. Modelos são construídos para comunicar a estrutura e o comportamento do sistema, para visualizar e controlar a arquitetura do sistema, para gerenciar os riscos, para compreender melhor o sistema a ser elaborado, permitindo se descobrir oportunidades de simplificação e reuso. Além disto, modelos proporcionam um guia para a construção do sistema, permitindo a documentação das decisões tomadas. Linguagens de modelagem fornecem um vocabulário e regras para combinação das palavras deste vocabulário para a representação conceitual e física de um sistema, isto é, a modelagem do sistema. Linguagens de modelagem indicam como criar e ler modelos de um sistema, mas não indicam quais modelos devem ser criados nem quando eles serão criados, o que é responsabilidade do processo de desenvolvimento de software. Atualmente, o paradigma de desenvolvimento de sistemas mais usado é o orientado a objetos (OO). Este paradigma permite que desenvolvedores e usuários pensem no software como objetos físicos. Neste paradigma, o principal bloco de construção de todos os sistemas de software é o objeto ou a classe. E a linguagem de modelagem adotada mundialmente para a visualização, documentação, especificação e a construção de sistemas orientados a objetos é a UML. A Linguagem de Modelagem Unificada - UML A Linguagem de Modelagem Unificada (Unified Modeling Language - UML) é uma linguagem de propósito geral para a especificação, visualização, construção e documentação de artefatos de sistemas complexos de software. A linguagem UML é uniforme, desde a especificação de requisitos até a fase implantação: o mesmo conjunto de conceitos e notação pode ser usado em diferentes atividades de desenvolvimento. Apesar de a UML ser independente do processo de desenvolvimento, da linguagem de programação ou do ferramental, ela permite um processo orientado a casos de uso, incremental, iterativo e centrado na arquitetura e a comunidade mundial de software oferece uma lista grande de ferramentas de modelagem e geração de código para diversas linguagens de programação. Modelo Conceitual da UML Como uma linguagem de modelagem, o modelo conceitual da UML fornece blocos básicos de construção, regras de combinação destes blocos e mecanismos comuns. O vocabulário de UML incorpora três tipos de blocos básicos: itens, que representam elementos comportamentais e estruturais do sistema; relacionamentos, que especificam como esses itens se relacionam entre si; e diagramas, que agrupam coleções interessantes de itens. Blocos de Construção Itens São abstrações identificadas como cidadãos de primeira classe em um modelo. Podem ser: Itens estruturais São os substantivos, elementos conceituais ou físicos. Representam as partes estáticas do modelo, coletivamente chamados de classificadores. São as classes, interfaces, colaborações, casos de uso, classes ativas, componentes, artefatos e nós. Itens comportamentais São as partes dinâmicas dos modelos UML. São os verbos, representando comportamentos no tempo e no espaço. São as interações, as máquinas de estados e as atividades.

2 Itens de agrupamento São as partes organizacionais dos modelos UML. São os pacotes. Itens anotacionais São as partes explicativas dos modelos UML. São as notas. Relacionamentos São os blocos relacionais, usados para reunir os itens. Podem ser: Dependência Relacionamento semântico entre dois itens, nos quais a alteração de um pode afetar a semântica do outro. Associação; Relacionamento estrutural entre dois itens, que descreve um conjunto de conexões entre objetos. Ele pode ser, inclusive, de Agregação (entre o todo e suas partes). Generalização Relacionamento de especialização/generalização, onde objetos filhos compartilham a estrutura e o comportamento dos objetos pais ; Realização Relacionamento semântico entre classificadores em que um classificador especifica um contrato que outro classificador garante executar. Diagramas Agrupam coleções interessantes de itens. Um diagrama é uma apresentação gráfica de um conjunto de elementos, geralmente representados como gráfico de vértices (itens) e arcos (relacionamentos). Cada diagrama constitui uma projeção de um determinado sistema. A UML possui treze diagramas: Diagrama de Classes, Diagrama de Objetos, Diagrama de Componentes, Diagrama de Estruturas Compostas, Diagrama de Casos de Uso, Diagrama de Seqüências, Diagrama de Comunicações (o Diagrama de Colaborações da versão1.4), Diagrama de Gráficos de Estados, Diagrama de Atividades, Diagrama de Implantação, Diagrama de Pacote, Diagrama de Temporização e Diagrama de Visão Geral da Interação. 1. Diagrama de Caso de Uso. Representa o conjunto de comportamentos de alto nível que o sistema deve executar para um determinado ator. É o diagrama mais simples, e não há necessidade de grandes detalhamentos. 2. Diagrama de Classes. Representa uma coleção de classes e seus inter-relacionamentos. 3. Diagrama de objetos. Representa um retrato, em tempo de execução, dos objetos do software e seus interrelacionamentos. 4. Diagrama de Colaboração. Representa uma coleção de objetos que trabalham em conjunto para atender algum comportamento do sistema. 5. Diagrama de Sequência. Representa uma perspectiva, orientada por tempo, da colaboração entre os objetos. 6. Diagrama de Atividades. Representa o fluxo de tarefas que podem ser executadas pelo sistema ou por um ator. 7. Diagrama de Estados. Representa um conjunto de estados que um objeto pode estar e os gatilhos que estimulam a transição do objeto de um estado para outro. 8. Diagrama de Componentes. Representa uma coleção de componentes de software e seus inter-relacionamentos. 9. Diagrama de Depuração. Representa uma coleção de componentes e mostra como esses são distribuídos em um ou vários nós de hardware.

3 10. Diagrama de Pacotes. Representa uma coleção de outros elementos de modelagem e diagramas. Para especificar como estes blocos de construção podem ser combinados para gerar modelos bem-formados, são necessárias as regras de construção. Regras de Construção Especificam o que deverá ser um modelo bem-formado, isto é, autoconsistente semanticamente e em harmonia com todos os modelos com ele relacionados. a) Regras para Nomes Quais nomes podem ser atribuídos aos blocos de construção; b) Regras para Escopo O contexto que determina o significado de um nome; c) Regras para Visibilidade Como os nomes podem ser vistos pelos outros; d) Regras para Integridade Como os itens se relacionam de maneira adequada e consistente; e) Regras para Execução O que significa executar ou simular um modelo dinâmico; Para estender a linguagem de maneira controlada, a UML oferece os mecanismos comuns. Mecanismos Comuns da UML Para tornar a construção do sistema mais simples e harmoniosa. a) Especificações Repertório semântico para determinar os detalhes do sistema (p.ex. atributos e operações de classe). b) Adornos Variedades específicas de símbolos básicos. c) Divisões comuns Dicotomias comuns da UML, como entre Interface / Implementação, Tipo / Papel e Classes / Objetos (e similares para outros blocos, como para Casos de Uso/Instâncias de Casos de Uso). d) Mecanismos de Extensão Permitem ampliar a UML de maneira controlada. Podem ser de três tipos: - Estereótipos: Permite a criação de novos tipos de blocos de construção derivados dos já existentes. - Valores atribuídos: estendem as propriedades dos blocos de informação, criando novas informações. - Restrições: ampliam a semântica dos blocos de construção da UML, permitindo alterar as regras existentes ou criar novas regras. A UML pode ser estendida através de extensões de peso leve ou de peso pesado. As primeiras estendem as metaclasses da UML ou restringem ainda mais os elementos existentes. As segundas permitem alterações mais profundas, como novas metaentidades ou alterações profundas nas metaentidades existentes (OMG, 2007). Este trabalho não tem a pretensão de estender a UML, por ser desnecessário em relação ao escopo. Os diagramas usados serão restringidos de acordo com o modelo conceitual da abordagem de leis, como pode ser visto no Capítulo 4 desta dissertação.

4 Elaboração de um Modelo Conceitual Objetivos Criar um modelo conceitual inicial Distinguir entre atributos corretos e incorretos Adicionar conceitos de descrição, quando apropriado Comparar e contrastar os termos conceito, tipo, interface e classe Introdução O modelo conceitual é o artefato mais importante criado durante a análise O modelo conceitual ilustra os conceitos importantes do domínio do problema, suas associações e atributos Falaremos de associações e atributos nos próximos capítulos Levantar um conjunto rico e expressivo de conceitos (objetos) durante a análise ajuda muito a conduzir as fases de projeto e implementação É importante lembrar que os conceitos levantados aqui são do domínio do problema e não conceitos associados a software Modelos conceituais Ao fazer análise OO, a decomposição do domínio do problema utiliza objetos e não funções ou processos como na análise estruturada Exemplo de um modelo conceitual (com conceitos, associações e atributos) Apenas a parte diagramática está sendo mostrada UML permite associar descrições mais detalhadas dos conceitos, atributos, etc. Criar o modelo conceitual ajuda a elaborar o glossário, definindo os termos importantes do domínio do problema Muito importante para a comunicação entre os envolvidos (clientes e desenvolvedores)

5 Estratégias para identificar conceitos (objetos) Regra fundamental: é melhor ter conceitos demais (muitos conceitos de granularidade pequena) do que conceitos de menos no modelo conceitual Novos conceitos podem ser descobertos com tempo (quando se está identificando associações ou atributos, por exemplo) e a elaboração de um modelo conceitual é portanto uma atividade iterativa Na modelagem de dados para bancos de dados, há um critério de modelagem que diz que algo sobre o qual não precisamos lembrar nada não precisa entrar no modelo conceitual Com o ponto de visto de persistência, a regra faz sentido Mas na modelagem OO, objetos com apenas comportamento (sem atributos) também são importantes (embora raros) e não devem ser excluídos do modelo Usando a lista de categoria de conceitos Conceitos são comumente descobertos nas categorias da tabela seguinte Os exemplos são referentes aos domínios de uma loja de reserva de passagem aérea Categoria de Conceito Objetos físicos ou tangíveis Especificações, projetos ou descrições de coisas Lugares Transações (um momento notável) Detalhes de transação (Line item) Papeis de pessoas Coleções de outras coisas (containers) Coisas dentro das coleções Outros sistemas externos a nosso sistema Conceitos abstratos Organizações Eventos Processos (frequentemente não é representado como conceito, mas pode ocorrer) Regras e políticas Catálogos Registros de assuntos financeiros, de trabalho, de contratos, legais Instrumentos e serviços financeiros Manuais, livros Achando conceitos através de substantivos Exemplos Terminal Ponto De Venda (TPDV) Aeronave Especificação de produto Descrição de um vôo Loja Aeroporto Venda, Pagamento Reserva Item de detalhe de uma venda Caixa Piloto Loja, Prateleira Aeronave Item Passageiro Sistema de autorização de cartão de crédito Sistema de controle de tráfego aéreo Fome Acrofóbia (medo de altura) Departamento de vendas Voamos Baixo, Ltda. Venda, Roubo, Reunião Vôo, Desastre, Aterrissagem Fazer a venda de um produto Fazer uma reserva de lugar num vôo Política de devolução Política de cancelamento Catálogo de produtos Catálogo de peças Recibo, Plano de contas, Contrato de emprego Log de manutenção Linha de crédito Estoque Manual do empregado Manual de reparos Uma técnica simples para a identificação de conceitos é de isolar os substantivos nas descrições textuais dos Use Cases

6 Muitos dos substantivos serão conceitos ou atributos Exemplo: Use Case expandida "Comprar Item com Dinheiro Vivo" Ação do ator 1. O Use Case inicia quando um cliente chega a um caixa munido detpdv com itens a comprar 2. O caixa registra a identificação de cada item Se houver mais itens, o caixa pode informar a quantidade também 4. Ao completar a entrada dos itens, o caixa indica este fato ao TPDV 6. O caixa informa o total da venda ao cliente 7. O cliente efetua o pagamento com dinheiro, possivelmente maior que o total da venda 8. O caixa registra a quantidade de dinheiro recebida 10. O caixa deposita o dinheiro recebido e extrai o troco a devolver O caixa entrega o troco e o recibo impresso ao cliente 12. O cliente sai da loja com os itens comprados Resposta do sistema 3. Determina o preço do item e adiciona a informação ao total datransação de venda A descrição e preço do item corrente são exibidos 5. Calcula e apresenta o total da venda 9. Mostra o valor do troco ao cliente Gera um recibo impresso 11. Faz log da venda completada Alguns desses substantivos são conceitos (objetos), outros são atributos de conceitos Falaremos mais sobre as diferenças em outro capítulo Uma regra útil: Se pensarmos sobre um conceito X como número ou texto no mundo real, ele pode ser um atributo; caso contrário, sempre será um conceito Na dúvida, crie um conceito separado Exemplo: Destino é um atributo de um vôo ou um conceito separado? É um conceito separado (pensamos no destino como sendo um aeroporto) Conceitos candidatos para o domínio do TPDV Usando as técnicas acima, temos a seguinte relação de candidatos: TPDV Item Loja Venda Pagamento Catálogo de produtos Relatórios são objetos? Um recibo é um relatório Especificação de produto Item de detalhe de uma venda Caixa Cliente Gerente Deveria ser um conceito (objeto) A favor de excluir:

7 Um recibo é apenas um relatório de uma venda Incluí-lo no modelo conceitual não seria útil porque toda sua informação é derivada de outros objetos A favor de incluir Um recibo tem um papel importante nas regras de negócio porque permite que o cliente devolva itens comprados Na primeira iteração de desenvolvimento, os Use Cases não consideram a devolução do produto e não incluiremos o objeto Recibo Em outra iteração, poderá ser incluído Modelagem do mundo não real Em certos domínios de problema, os conceitos são muito abstratos Exemplo: domínio de redes de computadores ou telecomunicações Conceitos possíveis são: Mensagem, Conexão, Diálogo, Protocolo, etc. Modelando descrições Não se deve incluir como atributos descrições de conceitos a instâncias desses conceitos por dois motivos Repetição de informação A descrição some se não houver instância Exemplo: Não está correto incluir a descrição de um produto no conceito Produto É melhor criar um novo conceito DescriçãoDeProduto que descreve instâncias de Produtos Outro exemplo: O conceito Vôo deveria incluir toda a descrição do vôo? Não! Se nenhum vôo RG321 ocorrer, a descrição do vôo RG321 deve continuar em algum lugar: é um conceito à parte

8 Termos empregados na UML UML não emprega a palavra "conceito" As alternativas são tipo e classe A diferença entre tipo e classe é que um tipo é abstrato (sem implementação) enquanto a classe sempre inclui alguma implementação Portanto, o tipo é uma especificação e a classe é uma implementação (de um tipo) A diferença entre as duas coisas se torna mais importante durante a fase de Projeto Por enquanto, basta dizer que usaremos "conceito" para falar do domínio do problema e "classe" para falar de entidades de software Modelo Conceitual: Adição de Associações Objetivos Identificar associações num modelo conceitual Diferenciar associações de conhecimento e associações de entendimento de modelo Introdução Queremos associar conceitos de forma a: Satisfazer as necessidades de acesso a informação dos conceitos Deixar o modelo conceitual mais fácil de entender Associações Uma associação é um relacionamento estrutural entre conceitos que indica uma conexão interessante e útil

9 Critério de associações úteis: Associações "de conhecimento" (need-to-know) representam a conhecimento de um relacionamento que deve ser preservado por algum tempo Entre quais objetos precisamos ter memória de um relacionamento? Exemplo: Um "Item de detalhe de uma venda" tem uma associação com uma instância de uma Venda Caso contrário, não poderíamos calcular o total da venda, emitir o recibo, etc. Vão implicar em algum tipo de navegação no projeto e na implementação Outras associações que podem ser úteis são aquelas que melhoram o entendimento do modelo conceitual Notação UML para associações Associações são sempre bi-direcionais Não há informação de navegabilidade num modelo conceitual Conceitualmente, a navegabilidade existe nos dois sentidos Escolher o verbo para representar uma direção ou outra é arbitrário Prefere-se manter a voz ativa no verbo É melhor "Registra-a-atual" do que "É-registrada-por" Não há implicação sobre a existência de ponteiros, chaves estrangeiras, etc. A seta de direção de leitura é opcional e indica como ler o nome da associação A seta não possui informação semântica Pode haver informação de multiplicidade nas extremidades das associações

10 Como achar associações: a lista de associações comuns Os exemplos são dos domínios de uma Loja e da reserva de passagem aérea Categoria de Associação Exemplos A é uma parte física de B Gaveta-TPDV Asa-Aeronave A é uma parte lógica de B Item de detalhe de vanda-venda Trecho de vôo-rota de vôo A é fisicamente contido em B TPDV-Loja, Item-Prateleira Passageiro-Aeronave A é logicamente contido em B Descrição de item-catálogo Vôo-Schedule de vôo A é uma descrição de B Descrição de item-item Descrição de vôo-vôo A é uma linha de detalhe de uma transação ou relatório B Item de detalhe de vanda-venda Tarefa de manutenção-log de manutenção A é conhecido/logado/registrado/reportado/capturado por ou em B Venda-TPDV Reserva-Lista de passageiros A é um membro de B Caixa-Loja Piloto-Viação aérea A é uma subunidade organizacional de B Departamento-Loja manutenção-viação aérea A usa ou gerencia B Caixa-TPDV Piloto-Aeronave A se comunica com B Cliente-Caixa Agente de reserva-passageiro A está relacionado com uma transação B Cliente-Pagamento Passageiro-Ticket A é uma transação relacionada com outra transação B Pagamento-Venda Reserva-Cancelamento A é vizinho de B TPDV-TPDV Cidade-Cidade A pertence a B TPDV-Loja Aeronave-Viação aérea Algumas categorias de associações sempre são úteis num modelo conceitual A é uma parte física ou lógica de B A está fisicamente ou logicamente contido em B A é registrado em B Nível de detalhamento das associações Não inclua associações demais no modelo É muito mais importante achar conceitos do que associações

11 Nomes de associações Use uma frase com verbo que facilite a leitura quando juntada com os conceitos em cada extremidade Exemplo: Loja Estoca Item Associações são normalmente lidas da esquerda para a direita e de cima para baixo Associações múltiplas entre dois tipos Exemplo segue Associações e implementação Durante a análise associações não implicam em fluxos de dados ou informação de navegabilidade A implementação de uma associação será frequentemente uma referência entre dois objetos Porém, algumas associações da análise não serão implementadas Novas associações que forem implementadas (na fase de implementação) devem ser adicionadas ao modelo conceitual (foram esquecidas durante a modelagem conceitual) Associações no Domínio do TPDV Usam-se as duas técnicas mostradas acima para identificar associações Associações de conhecimento (que implicam que um objeto deve conhecer o outro) As seguintes associações são do tipo "conhecimento" Associação Por que implica em conhecimento

12 Para poder conhecer a venda corrente, TPDV Captura Venda calcular o total e imprimir um recibo Para poder saber se a venda foi paga, Venda Paga-com Pagamento comparar o valor recebido do cliente com o total e imprimir um recibo CatálogoDeProduto Registra Para poder obter uma especificação de EspecificaçãoDeItem item, dado um código UPC Usando a lista de associações comuns Categoria de Associação A é uma parte física de B A é uma parte lógica de B A é fisicamente contido em B A é logicamente contido em B A é uma descrição de B A é uma linha de detalhe de uma transação ou relatório B A é conhecido/logado/registrado/reportado/capturado por ou em B A é um membro de B A é uma subunidade organizacional de B A usa ou gerencia B A se comunica com B A está relacionado com uma transação B A é uma transação relacionada com outra transação B A é vizinho de B A pertence a B O modelo conceitual para o domínio TPDV Sistema TPDV não se aplica Item de detalhe de venda-venda TPDV-Loja Item-Loja Especificação de produto-catálogo de produtos Catálogo de produto-loja Especificaão de produto-item Item de detalhe de venda-venda Venda (completada)-loja (é logada por) Venda (atual)-tpdv (é capturada por) Caixa-Loja não aplicável Caixa-TPDV Gerente-TPDV Gerente-Caixa (mas provavelmente não aplicável no sistema) Cliente-Caixa Cliente-Pagamento Caixa-Pagamento Reserva-Cancelamento Pagamento-Venda TPDV-TPDV (mas provavelmente não aplicável no sistema) TPDV-Loja Ver modelo conceitual parcial (sem atributos) abaixo

13 Pode-se debater cada associação para verificar a utilidade de ser incluída no modelo Uma associação que implica conhecimento normalmente fica As demais ficam se esclarecerem o modelo Não há modelo único "correto" Podemos argumentar que algumas associações do modelo poderiam sumir Exemplos Nenhuma das associações seguintes implica em conhecimento Venda Entrada-por Caixa Isso mudaria se precisássemos da identificação do caixa no recibo TPDV Iniciado-por Gerente Venda Iniciada-por Cliente Loja Estoca Item LinhaDetalheVenda Registra-Venda-de Item Modelo Conceitual: Adição de Atributos Objetivos Identificar atributos num modelo conceitual Distinguir entre atributos corretos e incorretos

14 Introdução Precisamos identificar os atributos que servirão para satisfazer as necessidades de informação dos Use Cases sob consideração na iteração corrente. Atributos Um atributo é um valor de dado lógico de um objeto (ou instância de conceito) Os atributos são identificados primariamente localizando a necessidade de lembrar informação Exemplo: Uma Venda tem atributos data e hora Notação UML para atributos Os tipos podem ser opcionalmente mostrados Atributos válidos Manter os atributos de tipos simples Atributos são normalmente de tipos básicos Boolean, Date, Number, String (ou Text), Time Podem ser de outros tipos comuns tais como Endereço, Cor, Geométricos (Point, Rectangle,...), Fone, CPF, UPC (Universal Product Code), SKU (Stock Keeping Unit), CEP Não se deve representar associações como atributos Repetição de um exemplo anterior em que um destino de vôo não é um atributo

15 Valores puros de dados Um valor é puro quando não possuem identidade Não precisamos distinguir entre instâncias de mesmo valor Exemplos: não precisamos distinguir entre Instâncias separadas do Number 5 Instâncias separadas do String "mamãe" Instâncias separadas de Fone contendo o mesmo número de telefone Instâncias separadas de Endereço contendo o mesmo endereço Por outro lado, duas Pessoas chamadas "Sicrano da Silva" devem ser distinguida (têm identidade diferente), apesar do nome igual Resultado: apenas um valor puro de dado pode ser representado como atributo Não usar chaves estrangeiras como atributos Na construção de esquemas lógicos de bancos de dados, é comum usar chaves estrangeiras como atributos Isso não deve ser feito num modelo conceitual (OO ou não) Exemplo Uso de tipos não primitivos Pode-se escolher entre usar tipos não primitivos que representem valores puros como associação ou como atributo, conforme o desejo do analista ou a situação particular O importante é que a comunicação das idéias sobre o modelo esteja clara Exemplo Modelagem de quantidades e unidades Cuidado! Certos atributos parecem "números" mas podem ter algo mais associado

16 Valores financeiros podem ter uma moeda, além do valor Uma quantidade pode ter uma unidade (velocidade em km/s), além do valor Atributos para o sistema TPDV Só estamos considerando os Use Cases da primeira iteração Para achar os atributos, lêem-se os requisitos, Use Cases da iteração, outros documentos explicativos Muitos atributos poderão não ser descobertos na análise e serão identificados apenas no projeto ou na implementação Podemos ver o modelo conceitual final com os atributos abaixo

17 Construção do Glossário Objetivos Expressar termos num glossário Introdução Um glossário é um documento simples que descreve termos A definição de termos do domínio do problema é importantíssimo para manter limpa a comunicação entre desenvolvedores e clientes Para reduzir o risco de falahas de entendimento Para ajudar a introduzir novos membros na equipe no meio do projeto O glossário é elaborado em paralelo com outras fases e é elaborado ao longo da vida do projeto Pode incluir definições de tipos, business rules, Use Cases, atributos, etc. Eu particularmente não gosto de repetir informação aqui que esteja em outro lugar Exemplo: descrição de atributos que poderão estar em outro documento Serve como dicionário particular do projeto Exemplo de glossário (incompleto) para o domínio TPDV Termo Categoria Comentário Comprar Itens Use Case Descrição do processo que envolve a compra de itens por um cliente numa loja EspecificaçãoProduto.descrição atributo Uma descrição curta de um item de venda Item tipo Um item à venda numa Loja Pagamento tipo Um pagamento em dinheiro vivo LinhaDetalheVenda.quantidade atributo A quantidade de um tipo de item comprado Venda tipo Uma transação de venda LinhaDetalheVenda tipo O detalhamento da venda de um item particular numa Venda Loja tipo O lugar onde vendas de itens ocorrem Venda.total atributo O valor total de uma Venda EspecificaçãoProduto.UPC atributo O Universal Product Code do item