Baixe o app para aproveitar ainda mais
Prévia do material em texto
UNIVERSIDADE DO OESTE DE SANTA CATARINA ÁREA DAS CIÊNCIAS EXATAS E DA TERRA CURSO: ENGENHARIA DA COMPUTAÇÃO DISCIPLINA: ENGENHARIA DE SOFTWARE II CRÉDITOS: 4 HORAS/AULA: 60 PROFESSORA: ROGERIA RAMOS [rogeria.monteiro@unoesc.edu.br] PERÍODO LETIVO: 2º SEM DE 2013 FASE: 4ª Data de solicitação: 25 de setembro de 2013 Data de entrega: 15 de outubro de 2013 – publicado na Área de Colaboração do Portal de Ensino da Unoesc. Equipe: Mariana Rodrigues dos Santos, Oriel Antonio Gaida e Welenton Artur Webler Nota: ________ AVALIAÇÃO A1P2 Processo Unificado – Fase de Elaboração/Análise PROJETO FROTA DE TÁXIS ESTRUTURA DO TRABALHO E CRITÉRIOS DE AVALIAÇÃO 1. FASE DE CONCEPÇÃO 1.1. LEVANTAMENTO DE REQUISITOS 1.1.1. Visão Geral 1.1.2. Índice de Requisitos Funcionais 1.1.3. Índice de Requisitos Não Funcionais 1.1.4. Detalhamento dos Requisitos Funcionais 1.1.5. Glossário 1.2. ORGANIZAÇÃO DOS REQUISITOS EM CASOS DE USO 1.3. PLANEJAMENTO DOS CICLOS ITERATIVOS 2. FASE DE ELABORAÇÃO 2.1. ANÁLISE 2.1.1. Expansão de Caso de Uso 2.1.2. Identificação de Operações e Consultas de Sistema 2.1.3. Modelo Conceitual 2.1.4. Elaboração de Contratos CRITÉRIOS DE AVALIAÇÃO A NOTA DO TRABALHO VALE PARA TODOS OS INTEGRANTES DO GRUPO. Aplicação do modelo sugerido: todos os itens. Coerência, objetividade e completude: itens 2.1.2 e 2.1.3 e 2.1.4. Coerência com a técnica para elaborar os artefatos. DISTRIBUIÇÃO DA PONTUAÇÃO (TOTAL 10 PONTOS): ▪ Aplicação do modelo sugerido equivale a 1 ponto. ▪ Itens 2.1.2, 2.1.3 e 2.1.4 equivalem a 3 pontos, cada um. 1. FASE DE CONCEPÇÃO O processo unificado (PU ou UP) foi proposto por Grady Booch, James Rumbaugh e Ivar Jacobson (Jacobson, Booch & Rumbaugh, 1999), sendo o resultado de mais de trinta anos de experiência acumulada. O trio também foi que propôs a UML, Unified Modeling Language, como linguagem de linguagem de modelagem de sistemas unificada e não- proprietária. Segundo Wazlawick (2011, p. 4 e 5), o processo se fundamenta em três valores: a) É dirigido por casos de uso: o planejamento do desenvolvimento é feito em função dos casos de uso identificados, tratando-se prioritariamente os mais complexos; b) É centrado na arquitetura: o processo de desenvolvimento prioriza a construção de uma arquitetura de sistema que permita a realização dos requisitos. Essa arquitetura baseia-se na identificação de uma estrutura de classes, produzida a partir de um modelo conceitual. c) É iterativo e incremental: a cada ciclo de trabalho realizado, novas características são adicionadas a arquitetura do sistema, deixando-a mais completa e mais próxima do sistema final. O UP é dividido, basicamente, em quatro grandes fases, que são: concepção, elaboração, construção e transição. A fase de concepção incorpora o estudo de viabilidade, o levantamento dos requisitos e uma parte da sua análise. A fase de elaboração incorpora o detalhamento da analise requisitos, a modelagem de domínio e o projeto. A fase de construção corresponde à programação e testes, e a fase de transição consiste na instalação do sistema e migração de dados. Segundo Pressman (2011, p. 74), as fases do processo unificado não ocorrem em sequência, mas sim de forma concorrente e escalonada. “É provável que, ao mesmo tempo em que as fases de construção, transição e produção estejam sendo conduzidas, já se tenha iniciado o incremento de software seguinte.” (PRESMANN, 2011). O esquema abaixo demonstra o processo unificado, suas fases e iterações. Esquema 1: Processo Unificado com suas fases e iterações. Segundo Wazlawick (2011, p. 5), apesar de ser um processo prescritivo, o UP pode também ser realizado como um processo ágil, com poucos artefatos e burocracia, permitindo o desenvolvimento de software de forma eficiente, uma vez que o que interessa ao cliente é o software pronto e não uma pilha de documentos justificando por que não ficou pronto. A seção a seguir trata da fase de concepção, que é a primeira fase do processo unificado, na qual se procura levantar os principais requisitos e compreender o sistema de forma abrangente. Os principais objetivos dessa fase estão listados a seguir: 1. Estabelecer o escopo do projeto e condições de fronteira 2. Identificar os casos de uso críticos do sistema 3. Descrever pelo menos uma arquitetura candidata para os principais casos de uso 4. Apresentar estimativas globais de custo e prazo para o projeto global e estimativas detalhadas para a fase de elaboração 5. Levantar os principais riscos que podem comprometer o sucesso do projeto 1.1. LEVANTAMENTO DE REQUISITOS Na prática, requisito é o que o sistema tem que ter para atender plenamente ao propósito para o qual foi criado (FERNANDES, 2005). De acordo com NUNES, 2007 os requisitos, de modo geral, podem ser classificados em dois grandes grupos: os requisitos funcionais e os não funcionais, os quais serão vistos a seguir. A especificação de requisitos é um grande desafio para projetos de desenvolvimento de software. Nesta etapa os analistas de sistemas se relacionam com os usuários para entender, documentar, separar informações, conhecer o fluxo de trabalho e detalhar os objetivos a serem atingidos com o projeto que venha a responder as ansiedades e necessidades dos usuários e da organização. Uma grande quantidade de conhecimento dos usuários e técnicos é explicitada nesta etapa e este conhecimento precisa ser depositado em repositórios que facilitem a recuperação e agreguem valor ao processo. Percebe-se uma enorme dificuldade em listar, analisar, validar e gerenciar corretamente os requisitos (COSER, CARVALHO, KOVALESKI, 2006). Sobre as técnicas para se obter informações sobre funcionalidades esperadas do sistema, existem inúmeras. Entrevistas, questionários e observações são as mais comuns. A escolha entre uma ou mais de uma das técnicas fica a critério do analista. 1.1.1. Visão Geral Manoel Antonio é proprietário de uma frota de táxis na cidade de Joaçaba. Ele deseja um programa que apresente o valor de cada deslocamento e também, ao fim do dia, gostaria de uma funcionalidade que apresente o valor total recebido, de cada um dos veículos individualmente, assim como o valor recebido pela frota como um todo. Considerar que: a quantidade de km rodados marcada no taxímetro é a principal informação para que o valor do deslocamento seja apresentado; que há um valor mínimo a ser cobrado; que vários deslocamentos podem ser registrados em um único dia; que cada veículo tem um motorista sob responsabilidade; de cada motorista devem ser conhecidas as seguintes informações: nome completo, cpf, rg, número da CNH, validade da CNH, categoria da CNH e celular. 1.1.2. Índice de Requisitos Funcionais Os requisitos funcionais são aqueles que descrevem o comportamento do sistema, suas ações para cada entrada, ou seja, é aquilo que descreve o que tem que ser feito pelo sistema. São o cérebro do projeto, já que descrevem as funcionalidades que o sistema deve dispor. Para Wazlawick (2011, p. 24 e 25), os requisitos funcionais devem conter basicamente os seguintes elementos: a) A descrição de uma função a ser executada pelo sistema (usualmente entrada, saída ou transformação da informação); b) A origem do requisito (quem solicitou) e/ou quem vai executar a função em questão (usuário); c) Quais as informações que são passadas do sistema para o usuário e vice-versa quando a função for executada; d) Quais restrições lógicas (regras de negócio) ou tecnológicas se aplicam à função. As informaçõesde entrada e saída são importantíssimas para que a análise de requisitos ocorra de forma sistemática. Sem essas informações, os requisitos ficam muito vagos e pouco é aprendido sobre o sistema nessa fase. Sendo assim, seguem os requisitos funcionais elencados para este sistema: F01. Manter informações sobre taxímetro F02. Manter informações sobre táxi F03. Gerenciar táxi F04. Manter informações sobre motorista F05. Gerenciar frota de táxis 1.1.3. Índice de Requisitos Não Funcionais Os requisitos não funcionais são aqueles que expressam como deve ser feito. Em geral se relacionam com padrões de qualidade como confiabilidade, desempenho, robustez, etc. São muito importantes, pois definem se o sistema será eficiente para a tarefa que se propõe a fazer ou não. Um sistema ineficiente certamente não será usado. Neles também são apresentadas restrições e especificações de uso para os requisitos funcionais. Segundo Wazlawick (2011, p. 25), os requisitos não funcionais aparecem sempre ligados a requisitos funcionais e podem ser basicamente de dois tipos: lógicos ou tecnológicos. As restrições lógicas são as regras de negócio relacionadas a função em questão. Já as restrições tecnológicas dizem respeito à tecnologia para a realização da função, como, por exemplo, a interface, o protocolo de comunicação, restrições de segurança ou tolerância a falhas. Desta forma, os requisitos não funcionais destacados para este sistema são: Deve ser desenvolvido para o sistema operacional Windows Plataforma Desktop Níveis de acesso: Administrador, Motorista. 1.1.4. Detalhamento dos Requisitos Funcionais O detalhamento das informações que entram e saem do sistema é fundamental para a compreensão mais detalhada das funções. Segundo Wazlawick (2011, p. 29), “Sem esse detalhamento, o sistema pode parecer mais simples do que realmente é, o que explica por que, em muitos casos, os analistas esperam desenvolver um sistema em determinado tempo mas levam muito mais tempo, estourando prazos e orçamentos. As seções recomendadas nessa atividade são as seguintes: Descrição: descrição geral da função, do que ela deve fazer; Fontes: pessoas, sistemas ou documentos dos quais foram extraídas as informações; Usuários: descreve quais usuários poderão acessar aquela determinada função do sistema, auxilia na realização da hierarquia de usuários do sistema; Informações de entrada: informações que serão inseridas no sistema quando aquela função estiver sendo chamada; Informações de saída: informações que o sistema deverá apresentar para o usuário; Restrições lógicas: descreve as restrições lógicas das informações de entrada; Restrições tecnológicas: descreve as restrições da tecnologia que será utilizada para trocar informações com o sistema. F01. Manter informações sobre taxímetro Descrição Registrar as informações de um taxímetro associado a um determinado táxi. Os dados podem ser alterados a cada novo deslocamento. Fontes Cliente (Manoel Antonio) Usuários Administrador Informações de entrada valor mínimo, taxa por km rodado, km rodados por deslocamento completo, valor total do deslocamento, total de Km rodados, número de deslocamentos, número de referência. Informações de saída valor total do deslocamento Restrições ‘valor mínimo’ indica o valor mínimo a ser cobrado do passageiro lógicas independente da quantidade de km rodados. No momento, este valor é equivalente a R$ 4,00. ‘taxa por km rodado’ indica o valor a ser cobrado por cada km que o táxi se desloca a pedido de um passageiro. ‘km rodados’ indica a quantidade efetiva de deslocamento realizado pelo táxi a pedido de um passageiro, considerando o valor marcado ao chegar no destino. ‘valor total do deslocamento’ é calculado da seguinte forma: ‘valor mínimo’ + (‘taxa por km rodado’ * ‘km rodados’); a cada novo deslocamento (passageiro) o valor de ‘km rodados’ deve ser zerado. a cada registro de deslocamento: o o ‘número de deslocamentos’ deve ser acrescentado em uma unidade; o o ‘total de km rodados’ deve ser acrescentado do valor de ‘km rodados’. Restrições tecnológicas não existe **** F02. Registrar táxi Descrição Registrar as informações de táxi, associando um motorista e um taxímetro ao mesmo, permitindo a inclusão, alteração, exclusão e localização de um determinado táxi em uma lista correspondente à frota da empresa. Fontes Cliente (Manoel Antonio). Usuários Administrador Informações de entrada Taxímetro, Motorista, placa, marca, modelo, anoModelo Informações de saída Motorista, placa, marca, modelo, anoModelo Restrições lógicas cada táxi tem apenas um taxímetro que já está instalado no mesmo. cada táxi tem apenas um motorista responsável. Restrições tecnológicas não existe **** F03. Gerenciar táxi Descrição A partir da quantidade de km rodados deve ser possível obter o valor a ser pago pelo deslocamento. Após o registro de vários deslocamentos, deve ser apresentado o valor do faturamento diário do motorista, ou seja, qual foi o valor de todos os deslocamentos realizados em um dia Fontes Cliente (Manoel Antonio). Usuários Administrador, Motorista. Informações Táxi, data do dia de trabalho de entrada Informações de saída valor total dos deslocamentos, valor do faturamento diário Restrições lógicas ‘data do dia de trabalho’ refere-se ao dia de trabalho, ou seja, a cada dia de trabalho a frota completa pode estar prestando serviços ou apenas parte dela. Restrições tecnológicas não existe **** F04. Manter informações sobre motorista Descrição Registrar as informações do motorista de cada táxi permitindo a inclusão, alteração, exclusão e localização de um determinado motorista em uma lista dos funcionários da empresa. Fontes Cliente (Manoel Antonio). Usuários Administrador Informações de entrada nome completo, cpf, rg, número da CNH, validade da CNH, categoria da CNH e celular Informações de saída nome completo, cpf, rg, número da CNH, validade da CNH, categoria da CNH e celular Restrições lógicas um motorista é responsável por um veículo apenas, enquanto for funcionário da empresa. a CNH do motorista não pode estar vencida a CNH do motorista deve ser de categoria B, correspondente ao veículo que terá sob sua responsabilidade. Restrições tecnológicas não existe **** F05. Gerenciar Frota de Táxis Descrição Para cada dia da semana, é colocado em serviço um conjunto de táxis, correspondendo à frota completa ou parte dela. Ao final do dia, deve ser possível conhecer o valor arrecadado por cada um, assim como o faturamento total da frota. Fontes Cliente (Manoel Antonio). Usuários Administrador Informações de entrada Lista de táxis, data do dia de trabalho, número total de táxis, número de táxis em serviço. Informações de saída valor do faturamento diário por táxi, valor do faturamento diário da frota, data do dia de trabalho. Restrições lógicas ‘data do dia de trabalho’ refere-se ao dia de trabalho, ou seja, a cada dia de trabalho a frota completa pode estar prestando serviços ou apenas parte dela. Restrições tecnológicas Não existe. Quadro 1: Detalhamento dos requisitos funcionais. 1.2. ORGANIZAÇÃO DE REQUISITOS EM CASOS DE USO O Caso de Uso (Use Case) descreve uma sequência de ações que representam um cenário principal e cenários alternativos, com o objetivo de demonstraro comportamento de um sistema através de interações com atores (usuários). Os casos de uso devem representar processos de negócio de uma determinada empresa, devem ser monossessão, interativos e ter um resultado consistente. Quanto sua classificação, é necessário considerar a complexidade do UC, podendo ser feita classificando-o em Processo de Negócio, CRUD ou Relatório. Nome Tipo do UC Atores Descrição Referências Cruzadas UC1 Gerenciar a frota de Táxi Processo de Negócio Usuário Para cada dia da semana, é colocado em serviço um conjunto de táxis, correspondendo à frota completa ou parte dela. Ao final do dia, deve ser possível conhecer o valor arrecadado por cada um, assim como o faturamento total da frota. F01, F02, F03, F04, F05 UC2 Gerenciar Táxi Processo de Negócio Usuário A partir do registro do deslocamento (em Km) realizado por um táxi, deve ser possível determinar o valor a ser pago pelo cliente e também, ao final do dia, o valor total faturado por cada táxi. F01, F02, F03, F04 UC3 Registar Táxi Processo de Negócio Usuário Deve-se registrar cada táxi em particular com suas informações, associar um motorista responsável pelo mesmo e associar um taxímetro que estará em cada veículo. F02, F04 CRUD01 Manter Informações sobre taxímetro CRUD Usuário As informações sobre taxímetro devem ser registradas, observando os dados que deverão ter seus valores inicializados. F01 CRUD02 Manter Informações CRUD Usuário Cada motorista deve ter suas informações registradas. F04 sobre Motorista REL01 – Calcular o valor por um determinado deslocamento REL Usuário Deve-se informar o deslocamento, em km, realizado e a partir disso, o valor a ser pago pelo deslocamento deve ser fornecido. F02. Informações de Saída REL02 – Obter faturamento de um táxi num determinado período REL Usuário A cada deslocamento realizado por um determinado táxi, deve ser registrado o valor do deslocamento e, ao final do dia, o valor total faturado deve ser fornecido. F03. Informações de Saída REL03 – Obter faturamento da frota de táxis num determinado período REL Usuário Considerando todos os táxis que estão em serviço em um determinado dia, deve ser possível, ao final do dia, obter o valor total faturado por todos os veículos juntos. Quadro 2: Identificação e classificação de casos de uso. Segundo Wazlawick (2011, p. 37), o diagrama de casos de uso não é um dos diagramas mais úteis, mas é bastante popular para mostrar quais funções o sistema efetivamente executa. Nesse diagrama, as elipses representam casos de uso, os bonecos representam atores (usuários) e o retângulo representa a fronteira do sistema ou subsistemas. Fowler (2005, p. 106 e 107), descreve que a melhor maneira de pensar um diagrama de casos de uso é como um sumário gráfico do conjunto de casos de uso. Ele ainda destaca que pouco tempo e esforço deve ser aplicado a esse diagrama, concentrando-se mais na descrição textual dos casos de uso. O diagrama de casos de uso a seguir demonstra o sistema a ser desenvolvido, elaborado com o auxílio da ferramenta Astah Community versão 6.7. Diagrama 1: Diagrama de Casos de Uso UML do SisTáxi 1.3. PLANEJAMENTO DOS CICLOS ITERATIVOS Uma vez que os casos de uso tenham sido identificados, deve-se verificar se todos os requisitos funcionais do sistema tenham sido encaixados em pelo menos um caso de uso. Caso contrário, provavelmente ainda faltam casos de uso. Sendo o UP um processo interativo e incremental, espera-se que a cada ciclo de desenvolvimento sejam tratados um conjunto de casos de uso isoladamente, assim surgem os ciclos iterativos. Wazlawick (2010) define ciclos iterativos: “[...] são mini projetos baseados em casos de uso, conceitos e consultas. Estes mini projetos devem ser curtos e com tempo pré- determinado.”. No decorrer dessa fase, cada caso de uso relacionado será introduzido ao menos em um ciclo iterativo. Os critérios para alocação são tratar prioritariamente os processos de negócio, em seguida os CRUDs em por último os relatórios, tratando assim os mais complexos primeiro. Nada impede de que casos de uso de tipos diferentes, por exemplo, processos de negócio e relatórios, sejam inseridos no mesmo ciclo iterativo, estando eles relacionados. A partir da análise dos ciclos iterativos do sistema que está sendo tratado, chegamos ao Quadro 3, identificação e classificação de casos de uso. Ciclo Caso de Uso 1 UC1, REL03 2 UC2, REL02 3 UC3, REL01 4 CRUD1 5 CRUD2 Quadro 3: Identificação e classificação de casos de uso. 2. FASE DE ELABORAÇÃO É a segunda fase do UP cujo objetivo, segundo LARMAN (2008), é iniciar as iterações durante as quais a arquitetura central e de alto risco do software é programada e testada, a maioria dos requisitos é descoberta e estabilizada e os principais riscos são mitigados ou retirados. Segundo LARMAN (2008), a análise de domínio representa a investigação a fim de se identificar classes conceituais relacionadas com os requisitos da iteração corrente, criar um modelo de domínio inicial e modelar atributos e associações adequadas. Desta forma, um modelo de domínio ilustra importantes conceitos em um domínio. 2.1. ANÁLISE A subfase de análise da fase de elaboração se concentra na análise dos casos de uso significantes à arquitetura do sistema. Estes casos de uso, que representam um pouco um pouco mais de 10% do total de casos de uso definidos, são analisados visando a complementação do trabalho de análise arquitetural feito na fase de concepção. Assim, tendo como ponto de partida a arquitetura definida superficialmente durante a fase de concepção, este fluxo de análise poderá definir uma base sólida para a arquitetura do sistema de forma a se conseguir uma arquitetura executável. (SEABRA, 2001). A fase de análise, comporta três subatividades distintas (WAZLAWICK, 2011), as quais serão tratadas a seguir: a) Expansão dos casos de uso b) Construção ou refinamento do modelo conceitual c) Elaboração dos contratos das operações e consultas de sistema 2.1.1. Expansão de Casos de Uso – UC3 Registrar Táxi A expansão dos casos de uso representa a atividade de análise de requisitos, cujo modelo foi obtido do autor Wazlawick (2010). O objetivo dessa fase corresponde ao aprofundamento da análise de requisitos, realizando um exame detalhado dos processos envolvidos. Deve-se descrever o caso de uso passo a passo: como ele ocorre e como é a interação entre atores e o sistema. Deve-se evitar mencionar interfaces ou tecnologia, mas apenas dizer quais informações os atores passam ao sistema e quais informações o sistema passa aos atores (WAZLAWICK, 2011). NOME: UC3 – Registrar Táxi ATOR: Administrador FLUXO PRINCIPAL PASSO DESCRIÇÃO 1 O Administrador deseja registrar um novo táxi na frota, com seu respectivo motorista. 2 O Sistema apresenta todos os motoristas registrados. 3 O Administrador escolhe o motorista de interesse. 4 O Sistema apresenta todos os taxímetros registrados 5 O Administrador escolhe um taxímetro. 6 O Administrador informa os dados do táxi, tais como: placa, marca, modelo e anoModelo. 7 O Sistema registra o táxi. FLUXOS ALTERNATIVOS 3a – Motorista não cadastrado 3a.1 – O Administrador informa nome completo,cpf, rg, número da CNH, validade da CNH, categoria da CNH e celular do motorista. 3a.2 – O Sistema registra o novo motorista. 3a.3 – Retornar ao passo 2 do fluxo principal 5a – Taxímetro não cadastrado 5a.1 – O Administrador informa o valor mínimo, taxa por km rodado, km rodados por deslocamento completo, valor total do deslocamento, total de Km rodados, número de deslocamentos, número de referência. 5a.2 – O Sistema registra o novo taxímetro. 5a.3 – Retornar ao passo 4 do fluxo principal 2.1.2. Identificação de Operações e Consultas de Sistema – UC3 Registrar Táxi Walzlawick (2011, p. 73), define as operações e consultas de sistema: Operações de sistema são métodos que são ativados a partir de um evento de sistema, ou seja, como resposta a uma ação de um usuário. As operações de sistema, por definição, indicam um fluxo de informações do exterior para o interior do sistema e, portanto, de alguma forma, elas alteram as informações gerenciadas pelo sistema. Consultas de sistema são métodos que correspondem à simples verificação de informações já armazenadas. Essa informação pode ser apresentada exatamente como está ou ser modificada pela aplicação de funções. Mas, por definição, uma consulta de sistema não deve ser responsável por inserir, remover ou alterar informações armazenadas. A partir do caso de uso expandido, é possível encontrar as operações e consultas, marcando-as com [IN] para as operações e com [OUT] para as consultas, como vemos a seguir. Nome: UC3 – Registrar Táxi Ator: Administrador Fluxo Principal Passo Descrição 1 [IN] O Administrador deseja registrar um novo táxi na frota, com seu respectivo motorista. 2 [OUT] O Sistema apresenta todos os motoristas registrados. 3 [IN] O Administrador escolhe o motorista de interesse. 4 [OUT] O Sistema apresenta todos os taxímetros registrados 5 [IN] O Administrador escolhe um taxímetro. 6 [IN] O Administrador informa os dados do táxi, tais como: placa, marca, modelo e anoModelo. 7 [IN] O Sistema registra o táxi. Fluxos Alternativos 3a – Motorista não cadastrado 3a.1 – [IN] O Administrador informa nome completo, cpf, rg, número da CNH, validade da CNH, categoria da CNH e celular do motorista. 3a.2 – [IN] O Sistema registra o novo motorista. 3a.3 – Retornar ao passo 2 do fluxo principal 5a – Taxímetro não cadastrado 5a.1 – [IN] O Administrador informa o valor mínimo, taxa por km rodado, km rodados por deslocamento completo, valor total do deslocamento, total de Km rodados, número de deslocamentos, número de referência. 5a.2 – [IN] O Sistema registra o novo taxímetro. 5a.3 – Retornar ao passo 4 do fluxo principal A UML possui um diagrama que pode ser útil para representar a sequência dos eventos de sistema (operações e consultas) em um cenário de caso de uso. As linhas do tempo, representadas na vertical, correspondem ao/aos atores, a interface e ao sistema (controlador), respectivamente. As operações e consultas, na horizontal, são numeradas em ordem crescente, de forma que as linhas contínuas são as operações [IN] e as linhas pontilhadas são as consultas [OUT]. Tanto para o fluxo principal quanto para os fluxos alternativos, foram elaborados diagramas de sequência com o auxílio do Astah Community versão 6.7. Diagrama 1: Fluxo principal do caso de uso Registrar Táxi. Diagrama 2: Fluxo alternativo Motorista Não Cadastrado do caso de uso Registrar Táxi. Diagrama 3: Fluxo alternativo Taxímetro Não Cadastrado do caso de uso Registrar Táxi. A partir da análise dos diagramas de sequência dos fluxos de informações, temos o seguinte quadro de operações e consultas de sistema: Operações de Sistema Consultas de Sistema motoristaEscolhido(nomeMotoristasRegistrados) listarMotoristas() taximetroEscolhido(nroReferenciaTaximetros) listarTaximetros() registrarTaxi(placa, marca, modelo, anoModelo) novoMotorista(nome, cpf, rg, numeroCNH, validadeCNH, celular) registrarTaximetro(vlrMinimo, taxaKm, nroReferencia) 2.1.3. Modelagem Conceitual – UC3 Registrar Táxi O modelo conceitual deve descrever a informação que o sistema vai gerenciar. Trata-se de um artefato do domínio do problema e não do domínio da solução (WAZLAWICK, 2011). Não deve ser confundido com o diagrama de classes, da arquitetura do software, nem com o modelo de dados, do banco de dados. No desenvolvimento, apenas são representados aspectos estáticos da informação, modelados a partir de uma visão externa do sistema. O modelo conceitual dessa etapa do projeto é uma versão refinada do modelo conceitual preliminar, desenvolvido na etapa de concepção. Para o desenvolvimento, o diagrama de classes da UML é utilizado, com algumas restrições. Informalmente, podemos dizer que o modelo conceitual é um diagrama de classes sem métodos. Apenas conceitos, atributos e associações são representados. Com o auxílio da ferramenta Astah Community versão 6.7, usando o diagrama de classes da UML, foi desenvolvido o modelo conceitual a seguir: Figura 1: Modelo conceitual do sistema. 2.1.4. Elaboração de Contratos – UC3 Registrar Táxi A este ponto do UP, a análise produziu dois artefatos importantes: a) O modelo conceitual, que representa estaticamente a informação a ser gerenciada pelo sistema. b) Os casos de uso expandidos, que mostram como os usuário trocam informações com o sistema, sem mostrar, porém, como a informação é processada internamente ao sistema. Na elaboração dos diagramas de sequência, foram identificados as operações e consultas de sistema. Cada operação ou consulta implica a existência de uma intenção por parte do usuário. Essa intenção é capturada pelos contratos de operações e consultas de sistema, que correspondem a modelagem funcional do sistema. (WAZLAWICK, 2011). Um contrato de operação de sistema pode ter as seguintes seções: a) Pré-condições (opcional) b) Pós-condições (obrigatória) c) Exceções (opcional) Já um contrato para uma consulta de sistema pode ter duas seções: a) Pré-condições (opcional) b) Resultados (obrigatória) Contratos para o UC3 – Gerenciar Táxi: Operações de sistema: 1. RegistrarTaxiFP::motoristaEscolhido(nomeMotoristasRegistrados) a. Pré-condições i. Existe um motorista no cadastro com o atributo “nome” igual ao parâmetro nomeMotoristasRegistrados. b. Pós-condições i. Foi criada uma associação entre o Controlador e Motorista, denominada motoristaCorrente. 2. RegistrarTaxiFP::taximetroEscolhido(nroReferenciaTaximetros) a. Pré-condições i. Existe um taximetro no cadastro com o número de referência igual ao parâmetro nroReferenciaTaximetros. b. Pós-condições i. Foi criada uma associação entre Controlador e Taximetro, denominada taximetroCorrente. 3. RegistrarTaxiFP::registrarTaxi(placa, marca, modelo, anoModelo) a. Pré-condições i. Existe um motoristaCorrente. ii. Existe um taximetroCorrente. b. Pós-condições i. Foi criada uma instancia de Taxi chamada taxiCorrente. ii. Foi criada uma associação entre taxiCorrente e motoristaCorrente, denominada motoristaResponsavel. iii. Foi criada uma associação entre taxiCorrente e taximetroCorrente, denominada taximetroVinculado. iv. Os atributos de taxiCorrente foram alterados, tendo seus valores substituídos pelos parâmetros placa, marca, modelo, anoModelo. 4. RegistrarTaxiFAmotoristaNaoCadastrado::novoMotorista(nome, cpf, rg, numeroCNH, validadeCNH, celular) a. Pré-condições i. Não existe motorista cadastrado com o atributo cpf igual ao parâmetro cpf. b. Pós-condições i. Foi criada umainstancia de Motorista chamada de motoristaCorrente. ii. Foi criada uma associação entre Motorista e Controlador, denominada novoMotorista. iii. Os parâmetros nome, cpf, rg, numeroCNH, validadeCNH, celular foram atribuídos aos atributos de motoristaCorrente. 5. RegistrarTaxiFAtaximetroNaoCadastrado::registrarTaximetro(vlrMinimo, taxaKm, nroReferencia) a. Pré-condições i. Não existe taximetro cadastrado com o atributo nroReferencia igual ao parâmetro nroReferencia. b. Pós-condições i. Foi criada uma instancia de Taximetro chamada de taximetroCorrente. ii. Foi criada uma associação entre Taximetro e Controlador, denominada novoTaximetro. iii. Os parâmetros vlrMinimo, taxaKm, nroReferencia foram atribuídos aos atributos de taximetroCorrente. Consultas de sistema: 1. RegistrarTaxiFP::listarMotoristas() a. Pré-condições: i. Nenhuma. b. Resultados i. Retorna o atributo “nome” de todos os motoristas do cadastro. 2. RegistrarTaxiFP::listarTaximetros() a. Pré-condições i. Nenhuma. b. Resultados i. Retorna o atributo “nroReferencia” de todos os taxímetros do cadastro. Com os contratos feitos, a análise pode ser considerada concluída dentro do ciclo iterativo atual e passa-se para a fase de projeto. 2.2. PROJETO DE DOMÍNIO – UC3 Registrar Táxi No processo unificado um dos tipos de projeto é o projeto de camada de domínio, que corresponde ao conjunto de classes do sistema, e nesta camada que é será realizada toda a parte lógica do sistema. O projeto de domínio embasa as demais camadas (persistência, interface, segurança, etc.). Segundo Wazlawick (2004, p. 183 e 184) a camada de domínio é composta por duas atividades: A) Definir os diagramas de colaboração e definir um diagrama de colaboração para cada contrato identificado na análise. B) Elaborar o diagrama de classes de projeto, que se baseia no modelo conceitual adicionado de algumas informações que não eram identificadas nas fase de análise. Com base na afirmação de Wazlawick podemos dizer que para elaborar o projeto de camada de domínio é necessário ter em mãos dois artefatos da fase de análise que estejam corretos. Os artefatos são o modelo conceitual e os contratos das operações e consultas de sistemas. 2.2.1. Elaboração do Diagrama de Comunicação O diagrama de comunicação, também conhecido como diagrama de colaboração, permite realizar a modelagem dinâmica do sistema, diferentemente dos artefatos já concluídos, que são estáticos. Nessa fase, veremos como os objetos que fazem parte da arquitetura do sistema trocam mensagens para realizar suas responsabilidades. O diagrama de sequência tem a ênfase na visão do sistema no decorrer do tempo, enquanto o diagrama de comunicação tem a ênfase no contexto do sistema, ou seja nas classes participantes e nas interações entre elas (SOMMERVILLE, 2007). Ambos são conhecidos como diagramas de interação. Basicamente o diagrama de comunicação é composto por: 1. Objetos: representantes das classes que trocam mensagens entre si. 2. Interações entre objetos 3. Mensagens A passagem do tempo não é mais representada por linhas verticais (diagrama de sequência), mas sim através de uma numeração sequencial, podendo ser simples (1,2,3, ...) ou composta (1.1, 1.2, 1.2.1, …). O diagrama a seguir demonstra a troca de mensagens do caso de uso Registrar Taxi, do nosso sistema. Figura 2: Diagrama de comunicação 2.2.2. Diagrama de Classe de Projeto O diagrama de classes do projeto é realizado a partir do modelo conceitual e dos diagramas de colaboração desenvolvidos no ciclo. Pode-se dizer que o diagrama de classes e o modelo conceitual tem objetivos distintos, apesar um ser construído a partir do outro. (WAZLAWICK, 2004) As mudanças básicas a serem feitas no DCP durante o projeto da camada de domínio são: a) Adição de métodos. Na atividade de análise, apenas as operações e consultas de sistema foram determinadas e adicionadas na classe controladora. Na atividade de projeto os métodos delegados encontrados serão adicionados nas das demais classes; b) Adição da direção das associações. Na atividade de análise, as associações do modelo conceitual eram não direcionais. Na atividade de projeto será determinada a direção de navegação das associações em função da direção das mensagens nos diagramas de comunicação; c) Possível detalhamento dos atributos e associações. É possível que, na atividade de análise, nem todos os atributos tenham seus tipos definidos. Nesses casos, esses elementos poderão ser adicionados na atividade de projeto, na medida do necessário. Além disso, os tipos abstratos de dados definidos nos papéis de associações poderão ser substituídos por tipos concretos (por exemplo, trocar lista por array ou lista encadeada); d) Possível alteração na estrutura das classes e associações. Pode ser necessário criar novas classes para implementar certas estruturas de projeto, como estratégias, por exemplo. Assim, é possível que a estrutura de classes do DCP não corresponda exatamente à mesma estrutura do modelo conceitual em alguns casos; e) Possível criação de atributos privados ou protegidos. No modelo conceitual, todos os atributos devem ser públicos porque ali se está representado a informação disponível. Assim, não faz sentido que seja modelada alguma informação que não possa ser acessível fora da classe. Porém quando se inicia a descrição dos aspectos dinâmicos e de representação interna dos objetos, pode ser necessário trabalhar com atributos privados ou protegidos para encapsular estados internos que determinarão o funcionamento de alguns métodos. O diagrama a seguir demonstra o diagrama de classes do projeto para o sistema de controle dos táxis. Figura 3: Diagrama de classes do projeto. 2.3. PROJETO DE INTERFACE Segundo Wazlawick (2004, p. 257) o projeto da camada de interface pode ser dividido nas seguintes subcamadas: A) Apresentação: É uma camada com as classes que representam os objetos gráficos de interface onde sua função se resume a receber e enviar dados ao usuário. B) Aplicação: É uma camada que controla toda a lógica da interface. A interface é baseada em janelas, onde suas tarefas do projeto de interface tem como função determinar as janelas do sistema, e quais as possibilidades de navegação entre as janelas, fazer o projeto gráfico e associar o mesmo a controles e eventos de navegação, e determinar quais são os controles que estarão habilitados ao usuário em determinado momento. Para fazer o projeto de interface o projetista deverá saber qual o objetivo de cada janela, quais os fluxos alternativos cada janela irá atender de cada caso de uso. Segundo Sommerville (2007, p.241), o projeto de interface tem como princípios básicos a familiaridade de usuário, pois o sistema deve se basear na experiência do usuário que fará o uso do sistema. O sistema deve ser consistente, não deve surpreender o usuário com comportamentos não esperados, e por fim o sistema deve interagir de maneira coerente com cada tipo de usuário. 2.3.1. Elaboração do Diagrama de Estados de Navegação O diagrama de estados de navegação indica quais são as janelas que compõe o sistema e quais eventos permitem ao usuário navegar de uma para outra. Com o diagrama de estados de navegação pode-se ter uma clara visão de como se dará a navegação dentro da aplicação quando esta estiver finalizada. Cada evento que rotula as transições do diagrama será posteriormente associado a um controle (um botão, por exemplo) da janela na origem da transição. Figura 4: Diagrama de estados denavegação para o caso de uso abordado. 2.3.2. Projeto Gráfico da Tela Central Segundo WAZLAWICK (2004), para fazer o projeto gráfico de cada janela, o projetista deverá saber quais são os objetivos da janela e qual caso de uso ela realiza. É possível também que algumas janelas realizem apenas alguns fluxos alternativos de um caso de uso. O projetista deve ficar atento aos seguintes detalhes quando estiver projetando a aparência de uma janela: a) Quais são os eventos de navegação que saem da janela no diagrama de estados de navegação. A cada evento corresponderá a um controle na interface (possivelmente um botão). b) Quais as operações de sistema realizadas na janela. Para cada operação deverá haver um controle de ativação (possivelmente um botão) e um campo de entrada para cada um dos parâmetros (possivelmente caixas de texto, menus ou campos auto completar). c) Quais as consultas de sistema realizadas na janela. Para cada consulta verá haver um controle de ativação (possivelmente um botão) e um campo de entrada para cada um dos parâmetros (possivelmente caixa de texto, menus ou campos auto completar), além de campos para exibição de cada um dos resultados. d) Cada transação efetuada em uma janela deve ter um início e um fim com a possibilidade de desistência. Assim, o projetista deverá determinar controles associados aos eventos de controle de transação. Esses controles poderão ser compartilhados com eventos de navegação, operação ou consulta de sistema, ou poderão ser controles independentes. Figura 5: Projeto gráfico da tela central do sistema. A primeira interação que o usuário realizará com o sistema é na tela de login onde ele estará "entrando" no sistema e a tela que estará disponível para ele é a de registrar taxi. Após feito isso o usuário terá as seguintes opções a sua disposição: Cadastrar Motorista, Cadastrar Taxímetro ou então escolher um taxímetro e motorista já cadastrado, e inserir informações como placa do taxi, marca, modelo e ano modelo do taxi, e também salvar as informações ou encerrar o sistema. Relação entre os componentes do projeto gráfico e as operações e consultas do sistema: Botão "Cadastrar Motorista" Através do evento onClick ativa a navegação para "Cadastrar Motorista". Botão "Cadastrar Taxímetro" Através do evento onClick ativa a navegação para "Cadastrar Taxímetro". Botão "Salvar" Através do evento onClick ativa a função de salvar todas as informações inseridas no sistema. Botão "Encerrar" Através do evento onClick ativa a função de finalizar o sistema. Campo "Nome Motorista" Possibilita a escolha do nome de algum motorista já cadastrado. Campo "Número Taxímetro" Possibilita a escolha do número de algum taxímetro já cadastrado. Campos "Placa, Marca, Modelo, Ano Modelo" São campos para a inserção de informações sobre o táxi. 3.0 Glossário Sem termos desconhecidos para citar. REFERÊNCIAS COSER, M. A.; CARVALHO, H. G.; KOVALESKI, J. L. A gestão do conhecimento no apoio à gestão de requisitos em software. Disponível em: http://www.simpep.feb.unesp.br/anais/anais_13/artigos/125.pdf. Acesso em 26 mar. 2013. FERNANDES, DANIEL BATISTA. Análise de Sistemas Orientada ao Sucesso. Rio de Janeiro: Ciência Moderna, 2005. FOWLER, M. UML Essencial: Um Breve Guia Para a Linguagem-Padrão de Modelagem de Objetos. 3. ed. Porto Alegre: Bookman, 2005. PRESSMAN, R. S. Engenharia de Software: Uma Abordagem Profissional. 7. ed. Porto Alegre: AMGH, 2011. SEABRA, R. M. J. Análise e Projeto Orientado a Objetos Usando UML e o Processo Unificado. Belém, 2001. SOMMERVILLE, I. Engenharia de Software. 8. ed. São Paulo: Pearson Addison-Wesley, 2007. WAZLAWICK, R. S. Análise e Projeto de Sistemas de Informação Orientados a Objetos. Rio de Janeiro: Elsevier, 2004. WAZLAWICK, R. S. Análise e Projeto de Sistemas de Informação Orientados a Objetos. 2. ed. Rio de Janeiro: Elsevier, 2011.
Compartilhar