Engenharia de Software, Notas de estudo de Análise de Sistemas de Engenharia

Baixe Engenharia de Software e outras Notas de estudo em PDF para Análise de Sistemas de Engenharia, somente na Docsity!

Apostila Engenharia de Software

Elielder Berwanger

Sumário

1. Processo de Software

Um processo de software pode ser visto como o conjunto de atividades, métodos, práticas e transformações que guiam pessoas na produção de software. Um processo eficaz deve, claramente, considerar as relações entre as atividades, os artefatos produzidos no desenvolvimento, as ferramentas, os procedimentos necessários, a habilidade, o treinamento e a motivação do pessoal envolvido.

1.1 Definição de Processos

Há vários aspectos a serem considerados na definição de um processo de software. No centro da arquitetura de um processo de desenvolvimento estão algumas atividades chaves: análise e especificação de requisitos, projeto, desenvolvimento e testes, que são a base sobre a qual o processo de desenvolvimento deve ser construído. Entretanto, a definição de um processo envolve a escolha de um modelo de ciclo de vida, o detalhamento (decomposição) de suas macro-atividades, a escolha de métodos, técnicas e roteiros (procedimentos) para a sua realização e a definição de recursos e artefatos necessários e produzidos.

Um processo de software não pode ser definido de forma universal. Para ser eficaz e conduzir à construção de produtos de boa qualidade, um processo deve ser adequado ao domínio da aplicação e ao projeto específico. Deste modo, processos devem ser definidos caso a caso, considerando-se as especificidades da aplicação, a tecnologia a ser adotada na sua construção, a organização onde o produto será desenvolvido e o grupo de desenvolvimento.

Em suma, o objetivo de se definir um processo de software é favorecer a produção de sistemas de alta qualidade, atingindo as necessidades dos usuários finais, dentro de um cronograma e um orçamento previsível.

A escolha de um modelo de ciclo de vida (ou modelo de processo) é o ponto de partida para a definição de um processo de desenvolvimento de software. Um modelo de ciclo de vida organiza as macro- atividades básicas, estabelecendo precedência e dependência entre as mesmas.

Um modelo de ciclo de vida pode ser entendido como passos ou atividades que devem ser executados durante um projeto. Para a definição completa do processo, a cada atividade, devem ser associados técnicas, ferramentas e critérios de qualidade, entre outros, formando uma base sólida para o desenvolvimento. Adicionalmente, outras atividades tipicamente de cunho gerencial, devem ser definidas, entre elas atividade de gerência e de controle e garantia da qualidade.

São fatores que influenciam a definição de um processo:

• Tipo de software (sistema de informação, sistema de tempo real, etc.);
• Paradigma (estruturado, orientado a objetos, etc.);
• Domínio da aplicação;
• Tamanho;
• Complexidade;
• Características da equipe...

Embora diferentes projetos necessitem de processos com características específicas para atender às suas particularidades, é possível estabelecer um conjunto de ativos de processo (sub-processos, atividades, sub-atividades, artefatos, recursos e procedimentos) a ser utilizado na definição de processos de software de uma organização. Essas coleções de ativos de processo de software constituem o chamado processo padrão de desenvolvimento de software. Processos para projetos específicos podem, então, ser definidos a partir da instanciação do processo de software padrão da organização,

levando em consideração suas características particulares. Esses processos instanciados são ditos processos de projeto.

De fato, o modelo de definição de processos baseado em processos padrão pode ser estendido para comportar vários níveis. Primeiro, pode-se definir um processo padrão da organização, contendo os ativos de processo que devem fazer parte de todos os processos de projeto da organização. Esse processo padrão pode ser especializado para agregar novos ativos de processo, considerando aspectos, tais como tecnologias de desenvolvimento, paradigmas ou domínios de aplicação. Assim, obtêm-se processos mais completos, que consideram características da especialização desejada. Por fim, a partir de um processo padrão ou de um processo especializado, é possível instanciar um processo de projeto, que será o processo a ser utilizado em um projeto de software específico. Para definir esse processo devem ser consideradas as particularidades de cada projeto.

Para apoiar a definição de processos, diversas normas e modelos de qualidade de processo de software foram propostas, dentre elas: ISO9001, ISO/IEC 12207, ISO/IEC 15504, CMM, CMMI e MPS.BR. O objetivo dessas normas e modelos de qualidade é apontar características que um bom processo de software tem de apresentar, deixando a organização livre para estruturar essas características segundo sua própria cultura.

2. Ciclo de vida

De maneira geral, o ciclo de vida de um software envolve as seguintes fases:

• Planejamento: O objetivo do planejamento de projeto é fornecer uma estrutura que possibilite ao gerente fazer estimativas razoáveis de recursos, custos e prazos. Uma vez estabelecido o escopo de software, uma proposta de desenvolvimento deve ser elaborada, isto é, um plano de projeto deve ser elaborado configurando o processo a ser utilizado no desenvolvimento de software. À medida que o projeto progride, o planejamento deve ser detalhado e atualizado regularmente. Pelo menos ao final de cada uma das fases do desenvolvimento (análise e especificação de requisitos, projeto, desenvolvimento e testes), o planejamento como um todo deve ser revisto e o planejamento da etapa seguinte deve ser detalhado. O planejamento e o acompanhamento do progresso fazem parte do processo de gerência de projeto.
• Análise e Especificação de Requisitos: Nesta fase, o processo de levantamento de requisitos é intensificado. O escopo deve ser refinado e os requisitos identificados. Para entender a natureza do software a ser construído, o engenheiro de software tem de compreender o domínio do problema, bem como a funcionalidade e o comportamento esperados. Uma vez identificados os requisitos do sistema a serem desenvolvidos, estes devem ser modelados, avaliados e documentados. Uma parte vital desta fase é a construção de um modelo descrevendo o que o software tem de fazer (e não como fazê-lo).
• Projeto: Esta fase é responsável por incorporar requisitos tecnológicos aos requisitos essenciais do sistema, modelados na fase anterior e, portanto, requer que a plataforma de desenvolvimento seja conhecida. Basicamente, envolve duas grandes etapas: projeto da arquitetura do sistema e projeto detalhado. O objetivo da primeira etapa é definir a arquitetura geral do software, tendo por base o modelo construído na fase de análise de requisitos. Esta arquitetura deve descrever a estrutura de nível mais alto da aplicação e identificar seus principais componentes. O propósito do projeto detalhado é detalhar o projeto do software para cada componente identificado na etapa anterior. Os componentes de software devem ser sucessivamente refinados em níveis de maior detalhamento, até que possam ser codificados e testados.

definidas no processo de software. Essa pode ser uma base bastante efetiva para a elaboração de estimativas, incluindo a alocação de recursos, já que é sempre mais fácil estimar porções menores de trabalho.

3.1 Atividades Típicas da Gerência de Projetos:

A gerência de projetos envolve a realização de diversas atividades, abaixo relacionadas:

• Determinação do escopo do software;
• Definição do processo de software do projeto;
• Realização de estimativas;
• Estimativa de tamanho;
• Estimativa de esforço;
• Estimativa (alocação) de recursos;
• Estimativa de tempo (elaboração do cronograma do projeto);
• Estimativa de custos;
• Gerência de riscos;
• Elaboração do plano de projeto.

3.2 O Planejamento e o Acompanhamento do Projeto

As atividades acima relacionadas são realizadas diversas vezes ao longo do projeto. Tipicamente, no início do projeto, elas têm de ser realizadas para produzir uma primeira visão gerencial sobre o projeto, quando são conjuntamente denominadas de planejamento do projeto. À medida que o projeto avança, contudo, o plano do projeto deve ser revisto, uma vez que problemas podem surgir ou porque se ganha um maior entendimento sobre o problema.

Essas revisões do plano de projeto são ditas atividades de acompanhamento do projeto e tipicamente são realizadas nos marcos do projeto. O marcos de um projeto é estabelecido durante a definição do processo e tipicamente correspondem ao término de atividades importantes do processo de desenvolvimento, tais como análise e especificação de requisitos, projeto e implementação. O propósito de um marco é garantir que os interessados tenham uma visão do andamento do projeto e concordem com os rumos a serem tomados.

Em uma atividade de acompanhamento do projeto, o escopo pode ser revisto, alterações no processo podem ser necessárias, bem como devem ser monitorados os riscos e revisadas as estimativas (de tamanho, esforço, tempo e custo).

3.3 Estimativas

Antes mesmo de serem iniciadas as atividades técnicas de um projeto, o gerente e a equipe de desenvolvimento devem estimar o trabalho a ser realizado, os recursos necessários, o tempo de duração e, por fim, o custo do projeto. Apesar das estimativas serem um pouco de arte e um pouco de ciência, esta importante atividade não deve ser conduzida de forma desordenada. As estimativas podem ser consideradas a fundação para todas as outras atividades de planejamento de projeto. Para alcançar boas estimativas de prazo, esforço e custo, existem algumas opções:

• Postergar as estimativas até o mais tarde possível no projeto;
• Usar técnicas de decomposição;
• Usar um ou mais modelos empíricos para estimativas de custo e esforço;
• Basear as estimativas em projetos similares que já tenham sido concluídos.

A primeira opção, apesar de ser atraente, não é prática, pois estimativas devem ser providas logo no início do projeto (fase de planejamento do projeto). No entanto, deve-se reconhecer que quanto mais tarde for feita a estimativa, maior o conhecimento do projeto e menores as chances de se cometer erros. Assim, é fundamental revisar as estimativas na medida em que o projeto avança (atividades de acompanhamento do projeto).

Técnicas de decomposição, a segunda opção, usam, conforme discutido anteriormente, a abordagem “dividir para conquistar” na realização de estimativas, através da decomposição do projeto em módulos / funções (decomposição do produto) e atividades mais importantes (decomposição do processo).

Modelos empíricos, tipicamente, usam fórmulas matemáticas, derivadas em experimentos, para prever esforço como uma função de tamanho (linhas de código ou pontos de função). Entretanto, deve-se observar que os dados empíricos que suportam a maioria desses modelos são derivados de um conjunto limitado de projetos. Além disso, fatores culturais da organização não são considerados no uso de modelos empíricos, pois os projetos que constituem a base de dados do modelo são externos à organização. Apesar de suas limitações, modelos empíricos podem ser úteis como um ponto de partida para organizações que ainda não têm dados históricos, até que a organização possa estabelecer suas próprias correlações.

Finalmente, na última opção, dados de projetos anteriores armazenados em um repositório de experiências da organização podem prover uma perspectiva histórica importante e ser uma boa fonte para estimativas. Através de mecanismos de busca, é possível recuperar projetos similares, suas estimativas e lições aprendidas, que podem ajudar a elaborar estimativas mais precisas. Nesta abordagem, os fatores culturais são considerados, pois os projetos foram desenvolvidos na própria organização.

Vale frisar que essas abordagens não são excludentes; muito pelo contrário. O objetivo é ter várias formas para realizar estimativas e usar seus resultados para se chegar a estimativas mais precisas.

Quando se fala em estimativas, está-se tratando na realidade de diversos tipos de estimativas: tamanho, esforço, recursos, tempo e custos. Geralmente, a realização de estimativas começa pelas estimativas de tamanho. A partir delas, estima-se o esforço necessário e, na seqüência, alocam-se os recursos necessários, elabora-se o cronograma do projeto (estimativas de tempo) e, por fim, estima-se o custo do projeto.

4. Gerência da Qualidade

4.1 Documentação

A documentação produzida em um projeto de software é de suma importância para se gerenciar a qualidade, tanto do produto sendo produzido, quanto do processo usado para seu desenvolvimento.

No desenvolvimento de software, são produzidos diversos documentos, dentre eles, documentos descrevendo processos (plano de projeto, plano de qualidade etc.), registrando requisitos e modelos do sistema (documentos de especificação de requisitos, análise e projeto) e apoiando o uso do sistema gerado (manual do usuário, ajuda on-line, tutoriais etc.).

Uma documentação de qualidade propicia uma maior organização durante o desenvolvimento de um sistema, facilitando modificações e futuras manutenções no mesmo. Além disso, reduz o impacto da perda de membros da equipe, reduz o tempo de desenvolvimento de fases posteriores, reduz o tempo de manutenção e contribui para redução de erros, aumentando assim, a qualidade do processo e do produto gerado. Dessa forma, a criação da documentação é tão importante quanto à criação do

Um modelo de documento define a estrutura (seções, subseções, informações de cabeçalho e rodapé de página etc.), o estilo (tamanho e tipos de fonte, cores etc.) e o conteúdo esperado para documentos de um tipo específico. Documentos tais como plano de projeto, especificação de requisitos e especificação de projeto devem ter modelos de documentos específicos associados. Documentos padronizados são importantes, pois facilitam a leitura e a compreensão, uma vez que os profissionais envolvidos estão familiarizados com seu formato.

Quando não é possível ou desejável estabelecer uma estrutura rígida como um modelo de documento, roteiros dando diretrizes gerais para a elaboração de um artefato devem ser providos. Em situações onde não é possível definir uma estrutura, tal como no código-fonte, normas devem ser providas. Assim, tomando o exemplo do código-fonte, é extremamente pertinente a definição de um padrão de codificação, indicando nomes de variáveis válidos, estilos de endentação, regras para comentários etc.

Padrões organizacionais, sejam de processo sejam de produto, são muito importantes, pois eles fornecem um meio de capturar as melhores práticas de uma organização e facilitam a realização de atividades de avaliação da qualidade, que podem ser dirigidas pela avaliação da conformidade em relação ao padrão. Além disso, sendo organizacionais, todos os membros da organização tendem a estar familiarizados com os mesmos, facilitando a manutenção dos artefatos ou a substituição de pessoas no decorrer do projeto. Para aqueles artefatos tidos como os mais importantes no planejamento da documentação, é saudável que haja um padrão organizacional associado.

Dada a importância de padrões organizacionais, eles devem ser elaborados com bastante cuidado. Uma boa prática, conforme já sugerido para a definição de processos padrão, consiste em usar como base padrões gerais propostos por instituições nacionais ou internacionais voltadas para a área de qualidade de software.

4.4 Revisões

Para se controlar a qualidade em um projeto de software, uma abordagem bastante usada consiste em se realizar revisões. Nas revisões, processos, documentos e outros artefatos são revisados por um grupo de pessoas, com o objetivo de verificar se os mesmos estão em conformidade com os padrões organizacionais estabelecidos e se o propósito de cada um deles está sendo atingido, incluindo o atendimento a requisitos do cliente e usuários. Assim, o objetivo de uma revisão é detectar erros e inconsistências em artefatos e processos, sejam eles relacionados à forma, sejam em relação ao conteúdo, e apontá-los aos responsáveis pela sua elaboração.

O processo de revisão começa com o planejamento da revisão, quando uma equipe de revisão é formada, tendo à frente um líder. A equipe de revisão deve incluir os membros da equipe que possam efetivamente úteis para atingir o objetivo da revisão. Muitas vezes, a pessoa responsável pela elaboração do artefato a ser revisado integra a equipe de revisão.

Dando início ao processo de revisão propriamente dito, normalmente, o autor do artefato apresenta o mesmo e descreve a perspectiva utilizada para a sua construção. Além disso, o propósito da revisão deve ser previamente informado e o material a ser revisado deve ser entregue com antecedência para que cada membro da equipe de revisão possa avaliá-lo. Uma vez que todos estejam preparados, uma reunião é convocada pelo líder. Essa reunião deverá ser relativamente breve (duas horas, no máximo), uma vez que todos já estão preparados para a mesma. Durante a reunião, o líder orientará o processo de revisão, passando por todos os aspectos relevantes a serem revistos. Todas as considerações dos demais membros da equipe de revisão devem ser discutidas e as decisões registradas, dando origem a uma ata de reunião de revisão, contendo uma lista de defeitos encontrados.

4.5 Gerência de Configuração

Durante o processo de desenvolvimento de software, vários artefatos são produzidos e alterados constantemente, evoluindo até que seus propósitos fundamentais sejam atendidos.

Ferramentas de software, tais como compiladores e editores de texto, e processos também podem ser substituídos por versões mais recentes ou mesmo por outras, no caso de ferramentas. Porém, caso essas mudanças não sejam devidamente documentadas e comunicadas, poderão acarretar diversos problemas, tais como: dois ou mais desenvolvedores podem estar alterando um mesmo artefato ao mesmo tempo; não se saber qual a versão mais atual de um artefato; não se refletir alterações nos artefatos impactados por um artefato em alteração. Esses problemas podem gerar vários transtornos como incompatibilidade entre os grupos de desenvolvimento, inconsistências, retrabalho, atraso na entrega e insatisfação do cliente. Assim, para que esses transtornos sejam evitados, é de suma importância o acompanhamento e o controle de artefatos, processos e ferramentas, através de um processo de gerência de configuração de software, durante todo o ciclo de vida do software.

A gerência de configuração de software visa estabelecer e manter a integridade dos itens de software ao longo de todo o ciclo de vida do software, garantindo a completeza, a consistência e a correção de tais itens, e controlando o armazenamento, a manipulação e a distribuição dos mesmos. Para tal, tem de identificar e documentar os produtos de trabalho que podem ser modificados, estabelecer as relações entre eles e os mecanismos para administrar suas diferentes versões, controlar modificações e permitir auditoria e a elaboração de relatórios sobre o estado de configuração.

Pelos objetivos da gerência de configuração de software, pode-se notar que ela está diretamente relacionada com as atividades de garantia da qualidade de software.

As atividades da gerência de configuração de software podem ser resumidas em:

• Planejamento: Um plano deve ser elaborado descrevendo as atividades da gerência de configuração, procedimentos e responsáveis pela execução dessas atividades.
• Identificação da configuração: Refere-se à identificação dos itens de software e suas versões a serem controladas, estabelecendo linhas básicas.
• Controle de versão: Combina procedimentos e ferramentas para administrar diferentes versões dos itens de configuração criados durante o processo de software.
• Controle de modificação: Combina procedimentos humanos e ferramentas automatizadas para controlar as alterações feitas em itens de software. Para tal, o seguinte processo é normalmente realizado: solicitação de mudança, aprovação ou rejeição da solicitação, registro de retirada para alteração (check-out), análise, avaliação e realização das alterações, revisão e registro da realização das alterações (check-in).
• Auditoria de configuração: Visa avaliar um item de configuração quanto a características não consideradas nas revisões, tal como se os itens relacionados aos solicitados foram devidamente atualizados.
• Relato da situação da configuração: Refere-se à preparação de relatórios que mostrem a situação e o histórico dos itens de software controlados. Tais relatórios podem incluir, dentre outros, o número de alterações nos itens, as últimas versões dos mesmos e identificadores de liberação.

5. Levantamento/Análise de Requisitos

Uma das principais medidas do sucesso de um software é o grau no qual ele atende aos objetivos e requisitos para os quais foi construído. De forma geral, a engenharia de requisitos de software é o processo de identificar todos os envolvidos, descobrir seus objetivos e necessidades e documentá-los de

• Análise de Requisitos: Visa a estabelecer um conjunto acordado de requisitos consistentes e sem ambigüidades, que possa ser usado como base para o desenvolvimento do software. Para tal, diversos tipos de modelos são construídos. Geralmente, a análise de requisitos inclui também a negociação para resolver conflitos detectados.
• Documentação de Requisitos: É a atividade de representar os resultados da engenharia de requisitos em um documento, contendo os requisitos do software.
• Verificação e Validação de Requisitos: A verificação de requisitos avalia se o documento de especificação de requisitos está sendo construído de forma correta, de acordo com padrões previamente definidos, sem conter requisitos ambíguos, incompletos ou, ainda, requisitos incoerentes ou impossíveis de serem testados. Já a validação diz respeito a avaliar se esse documento está correto, ou seja, se os requisitos e modelos documentados atendem às reais necessidades e requisitos dos usuários/cliente.
• Gerência de Requisitos: Se preocupa em gerenciar as mudanças nos requisitos já acordados, manter uma trilha dessas mudanças, gerenciar os relacionamentos entre os requisitos e as dependências entre o documento de requisitos e os demais artefatos produzidos no processo de software, de forma a garantir que mudanças nos requisitos sejam feitas de maneira controlada e documentada.

É possível notar que, das cinco atividades do processo de engenharia de requisitos anteriormente listadas, as três últimas são, na realidade, instanciações para a engenharia de requisitos de atividades genéricas já discutidas anteriormente, a saber: documentação, garantia da qualidade e gerência de configuração. Assim sendo, somente as duas primeiras atividades (Levantamento e Análise de Requisitos) são discutidas.

5.3 Levantamento de Requisitos

O levantamento de requisitos é uma atividade complexa que não se resume somente a perguntar às pessoas o que elas desejam e também não é uma simples transferência de conhecimento. Várias técnicas de levantamento de requisitos são normalmente empregadas pelos engenheiros de requisitos (ou analistas de sistemas), dentre elas entrevistas, questionários, prototipação, investigação de documentos, observação, dinâmicas de grupo etc.

Um requisito é uma característica de um projeto, uma propriedade ou um comportamento de um sistema. Ao estabelecer os requisitos do sistema, você esta declarando um contrato, estabelecido entre as coisas externas ao sistema e o próprio sistema, declarando o que se espera que seja feito pelo sistema.

5.4 Análise de Requisitos

A análise de requisitos (muitas vezes chamada análise de sistemas) é, em última instância, uma atividade de construção de modelos. Um modelo é uma representação de alguma coisa do mundo real, uma abstração da realidade, e, portanto, representa uma seleção de características do mundo real relevantes para o propósito do sistema em questão. Modelos são fundamentais no desenvolvimento de sistemas. Tipicamente eles são construídos para:

• Possibilitar o estudo do comportamento do sistema;
• Facilitar a comunicação entre os componentes da equipe de desenvolvimento, clientes e usuários;
• Possibilitar a discussão de correções e modificações com o usuário;
• Formar a documentação do sistema.

Um modelo enfatiza um conjunto de características da realidade, que corresponde à dimensão do modelo. Além da dimensão que um modelo enfatiza, modelos possuem níveis de abstração. O nível de abstração de um modelo diz respeito ao grau de detalhamento com que as características do sistema são representadas. Em cada nível há uma ênfase seletiva nos detalhes representados. No caso do desenvolvimento de sistemas, geralmente, são considerados três níveis:

• Conceitual: Considera características do sistema independentes do ambiente computacional (hardware e software) no qual o sistema será implementado. Essas características são dependentes unicamente das necessidades do usuário. Modelos conceituais são construídos na atividade de análise de requisitos.
• Lógico: Características dependentes de um determinado tipo de sistema computacional. Essas características são, contudo, independentes de produtos específicos. Tais modelos são típicos da fase de projeto.
• Físico: Características dependentes de um sistema computacional específico, isto é, uma linguagem e um compilador específico, um sistema gerenciador de bancos de dados específico, o hardware de um determinado fabricante etc. Tais modelos podem ser construídos tanto na fase de projeto quanto na fase de implementação.

Conforme apontado acima, nas primeiras etapas do processo de desenvolvimento (levantamento de requisitos e análise), o engenheiro de software representa o sistema através de modelos conceituais. Nas etapas posteriores, as características lógicas e físicas são representadas em novos modelos.

Para a realização da atividade de análise, uma escolha deve ser feita: o paradigma de desenvolvimento. Paradigmas de desenvolvimento estabelecem a forma de se ver o mundo e, portanto, definem as características básicas dos modelos a serem construídos. Por exemplo, o paradigma orientado a objetos parte do pressuposto que o mundo é povoado por objetos, ou seja, a abstração básica para se representar as coisas do mundo são os objetos. Já o paradigma estruturado adota uma visão de desenvolvimento baseada em um modelo entrada-processamento-saída. No paradigma estruturado, os dados são considerados separadamente das funções que os transformam e a decomposição funcional é usada intensamente.

Exercício:

Desenvolver a análise preliminar do sistema agenda.

5.5 Especificação da Lógica dos Processos

A especificação dos processos, por conseguinte, não é apenas um levantamento descritivo de formatos e nomes. Ao contrário, depende de compreender e relatar claramente os mecanismos internos de funcionamento da atividade. A atenção nesta tarefa é crítica, pois, a partir dela, em etapas posteriores, serão descritos os programas de computador que automatizarão o processo. Especificações incompletas, incorretas ou confusas vão comprometer a programação e, naturalmente, provocar erros nos sistema.

A maior dificuldade para especificar a lógica dos processos, além da sua natural complexidade, é a própria ambigüidade da língua portuguesa que permite milhares de construções diferentes para o mesmo assunto. Essa característica contribui para que se evite a descrição da lógica em linguagem natural. Foi necessário, portanto, criar uma linguagem alternativa para substituir o português.

A primeira preocupação para descrever a lógica de um processo é procurar entender os passos seqüenciais de sua construção. A lógica de um processo baseia-se em dois princípios: relacionar todas as instruções necessárias para executar o processo e colocá-las (as instruções) na ordem correta.

7. Dicionário de Dados

O dicionário de dados pode ser visto como um depósito central que descreve e define o significado de toda a informação usada na construção de um sistema. O conteúdo de um dicionário de dados é composto pela:

• Especificação dos fluxos de dados;
• Especificação de arquivos;
• Especificação de processos;
• O seu conteúdo deve ser preciso, conciso e não redundante;

Cada ocorrência deve contemplar, pelo menos, os seguintes aspectos:

• Nome;
• Tipo;
• Descrição, conjunto de dados que caracterizam o campo;
• Pseudônimos (outros nomes possíveis);
• Especificação;
• Comentários significativos, que poderão incluir volume, freqüência, política de partilha e segurança dos dados.

Junto com o modelo de entidade e relacionamento, é necessário que se mantenha um documento com a explicação de todos os objetos nele criados. Este documento, que pode ser chamado de dicionário de dados, permite que os analistas obtenham informações sobre todos os objetos do modelo de forma textual, contendo explicações por vezes difíceis de incluir no diagrama. É válido lembrar que o objetivo do documento é ser claro e consistente.

8. UML

A UML (Unified Modeling Language) é uma linguagem padrão para a elaboração da estrutura de projetos de software. A UML poderá ser empregada para a visualização, a especificação, a construção e a documentação de artefatos que façam uso de sistemas complexos de software.

A UML é adequada para a modelagem de sistemas, cuja abrangência poderá incluir desde sistemas de informação corporativos a serem distribuídos a aplicações baseadas em Web e até sistemas complexos embutidos de tempo real. É uma linguagem muito expressiva, abrangendo todas as visões necessárias ao desenvolvimento e implantação desses sistemas.

A UML é apenas uma linguagem para especificação, construção e documentação de artefatos de software e, portanto, é somente uma parte de um método para desenvolvimento de software.

A UML é uma linguagem destinada a:

• Ajudar a conceber nossas idéias, em relação ao sistema que estivermos projetando;
• Pensar antes de codificar;
• Apresentar nossas idéias ao grupo de forma que todos possam interagir e discutir um determinado ponto;
• Aumentar a participação e envolvimento do time (grupo);
• Documentar nossas idéias quando elas já estiverem bem consolidadas para que novos integrantes e novos colaboradores possam acelerar sua compreensão dos sistemas desenvolvidos pelo grupo

A UML é um padrão para desenvolvimento de software que reúne melhores práticas de metodologia de sistemas. Diversos diagramas auxiliam na visualização do problema e a concepção da solução, permitindo uma visão macro dos objetos e seus relacionamentos;

É uma linguagem visual para especificação (modelagem) de sistemas orientados a objetos, fornece representação gráfica para os elementos essenciais do paradigma de objetos como classes, atributos, objetos, troca de mensagens, etc. Grandes sistemas necessitam de uma série de especificações e geralmente tais documentos são longos e muito detalhados. A modelagem proporcionada pela UML permite simplificar o entendimento de um sistema, ao transformar suas complexidades em objetos gráficos simples, onde a lógica interna de seu funcionamento é abstraída.

A manutenção que ocorrer nos posteriores ciclos de desenvolvimento fica mais fácil de ser efetuada já que a mesma ocorre inicialmente num nível lógico, e não no código (programa), de forma que se pode evoluir os diagramas que serão alterados e verificar suas conseqüências, antes de se preocupar com a fase de desenvolvimento.

Algumas das diferentes formas de representação dos processos são citadas abaixo:

• Diagrama de Casos de Uso
• Descrição de Casos de Uso
• Diagrama de Classes
• Diagrama de Objetos
• Diagrama de Seqüência
• Diagrama de Colaboração
• Diagrama de Estados
• Diagrama de Atividades
• Diagrama de Componentes
• Diagrama de Implantação

8.1 Diagrama de Casos de Uso

Modelo gráfico que agrupa determinados casos de usos e atores de um determinado sistema, de forma a visualizar-se de maneira rápida e fácil o relacionamento entre eles, servindo de documento para comunicação entre os participantes do projeto.

Aplica-se os diagramas de casos de uso na modelagem da visão de caso de uso do sistema. Na maior parte, isso envolve a modelagem dos requisitos do comportamento dos elementos. Esses diagramas fazem com que sistemas, subsistemas e classes fiquem acessíveis e compreensíveis, por apresentarem uma visão externa sobre como esses elementos podem ser utilizados no contexto.

• Tem o objetivo de auxiliar a comunicação entre os analistas e o cliente.
• Descreve um cenário que mostra as funcionalidades do sistema do ponto de vista do usuário.
• O cliente deve ver no diagrama de casos de uso as principais funcionalidades de seu sistema.
• Basicamente é composto por: o Atores: Pessoas que desempenham algum papel no sistema, entidades externas, como outros sistemas, que interagem com o sistema sendo projetado; o Casos de Uso: Processos ou funções que o sistema deve realizar de forma automática ou mesmo manual, geralmente associada a descrições textuais; o Relacionamentos: De dependência, generalização e associação.

Técnicas básicas de modelagem:

Ou, através da interface de pesquisa de contatos, acessando a opção editar contato.

Pré-requisito

O ator deverá estar logado no sistema;
O ator deverá possuir acesso a interface;
Para a situação de edição, o ator deverá realizar uma pesquisa para depois selecionar a opção de editar que irá carregar a interface de cadastro.

Interação

O sistema irá carregar a interface de edição/lançamento de contatos conforme processo de ativação (ver observação).

Para o lançamento/edição de um contato o sistema irá disponibilizar os seguinte campos para preenchimento:

a) (id) Código do contato – Campo obrigatório que servirá para identificar um contato como sendo único no sistema, para novos lançamentos o código será gerado automaticamente pelo sistema (numérico com precisão de 10 dígitos, auto-incremento); b) (name) Nome do contato – Campo obrigatório que referencia o contato a ser cadastrado, será utilizado para consultas e interfaces de pesquisa (texto para 100 caracteres); c) (address) Endereço – Campo facultativo, informação adicional sobre o contato (texto para 150 caracteres com auto-redimensionamento); d) (city) Cidade – Campo facultativo, para identificar a cidade do contato (código da cidade numérico – ver caso de uso Manter cidade); e) (personal) Contato Privado – Campo obrigatório, informações adicional sobre o contato, identifica se o contato é pessoal ou público, caso seja identificado como público todos os usuários poderão visualizá-lo e alterá-lo (booleano – verdadeiro para privado e falso para não privado); f) (user) Usuário – Campo obrigatório, para identificar o usuário responsável pelo cadastro da informação (código do usuário numérico – ver caso de uso Manter usuário); g) (phones) Telefones – Campo facultativo, grade com a identificação dos telefones vinculados ao contato, onde poderão ser adicionados novos itens ao contato (dados do telefone – ver caso de uso Manter telefone); Para o processo de inclusão/edição de contatos o ator deverá informar todos os campos que possuem definição de obrigatório, caso contrário ver EX01.

Após o preenchimento dos campos o usuário deverá selecionar a opção salvar, para que o sistema atualize as informações, ver EX02.

Exceções / Fluxos Alternativos

EX01 – Caso algum campo obrigatório não seja preenchido, o sistema irá disponibilizar uma interface que irá avisar o usuário sobre o campo que deve ser preenchido;
EX02 – O sistema irá validar os dados (EX01) e irá salvar as informações, caso ocorra algum erro o sistema irá disponibilizar uma interface contendo a descrição do erro, ou, irá disponibilizar uma interface contendo a confirmação de que as informações foram salvas com sucesso.

Observações

Informações adicionais ao processo de acessar o sistema e de alterar a senha deverão ser verificadas no caso de uso Controle de Acesso.

Caso o processo de ativação seja através do menu principal, na opção de adicionar um novo contato. O sistema irá carregar a interface de cadastro com todos os campos limpos.

Caso o processo de ativação seja através da interface de pesquisa, o sistema irá carregar a interface com todos os campos preenchidos para edição.

EMPRESA DE DESENVOLVIMENTO

Nome: Nome: Assinatura: Assinatura:

Cargo: Cargo: Descrição de Caso de Uso Manter Contato do sistema Agenda.

Exercício:

Desenvolver uma descrição de caso de uso para o sistema agenda.

8.3 Diagrama de Classes

Os diagramas de classes são os diagramas encontrados com maior freqüência na modelagem de sistemas orientados a objetos. Um diagrama de classe mostra um conjunto de classes, interfaces e colaborações e seus relacionamentos.

Os diagramas de classes são importantes não só para a visualização, a especificação e a documentação de modelos estruturais, mas também para a construção de sistemas executáveis por intermédio de engenharia de produção e reversa.

Ao construir uma casa, você começa com um vocabulário que inclui blocos de construção básicos, como paredes, piso, janelas, portas, tetos e vigas. Esses itens são amplamente estruturais (as paredes têm altura, largura e espessura), mas também são de alguma forma comportamental (tipos diferentes de paredes podem suportar diferentes cargas, as portas abrem e fecham, existem restrições em relação ao vão de um piso sem suportes). De fato, você não pode considerar essas características estruturais e comportamentais de maneira independente. Em vez disso, ao construir sua casa, é necessário considerar como estes itens interagem. Assim, o processo de determinar a arquitetura da casa envolve a reunião desses itens de uma maneira única e agradável para satisfazer a todos os requisitos funcionais e não funcionais. As plantas do projeto que você criar para visualizar sua casa e para especificar detalhes destinados aos construtores contratados são, na verdade, apresentações gráficas desses itens e de seus relacionamentos.

A modelagem do vocabulário de um sistema envolve uma decisão a respeito de quais abstrações fazem parte do sistema considerado e quais estão fora dos limites do sistema..

As relações entre as classes podem ser associações, agregações ou heranças. As classes possuem além de um nome possuem atributos e operações. Uma relação indica um tipo de dependência entre as classes, essa dependência pode ser forte com no caso da herança ou da agregação ou mais fraca como no caso da associação, mas indicam que as classes relacionadas cooperam de alguma forma para cumprir um objetivo para o sistema.

A UML permite diferentes níveis de abstração aos diagramas, dependendo da etapa do desenvolvimento do sistema em que se encontram. Assim, os diagramas de classe podem exibir nas fases iniciais da análise apenas o nome das classes, e em uma fase seguinte os atributos e operações. Finalmente, em uma fase avançada do projeto pode exibir os tipos dos atributos, a visibilidade, a multiplicidade das relações e diversas restrições.

Exercício:

Desenvolver o diagrama de classes para o sistema agenda.