projeto jedi - engenharia de software - java - 264 páginas

Módulo 4Engenharia de Software

Lição 1Introdução à Engenharia de Software

Versão 1.0 - Jul/2007

JEDITM

AutorMa. Rowena C. Solamo

EquipeJaqueline AntonioNaveen AsraniDoris ChenOliver de GuzmanRommel FeriaJohn Paul PetinesSang ShinRaghavan SrinivasMatthew ThompsonDaniel Villafuerte

Necessidades para os ExercíciosSistemas Operacionais SuportadosNetBeans IDE 5.5 para os seguintes sistemas operacionais:

• Microsoft Windows XP Profissional SP2 ou superior• Mac OS X 10.4.5 ou superior• Red Hat Fedora Core 3 • Solaris™ 10 Operating System (SPARC® e x86/x64 Platform Edition)

NetBeans Enterprise Pack, poderá ser executado nas seguintes plataformas:• Microsoft Windows 2000 Profissional SP4• Solaris™ 8 OS (SPARC e x86/x64 Platform Edition) e Solaris 9 OS (SPARC e

x86/x64 Platform Edition) • Várias outras distribuições Linux

Configuração Mínima de HardwareNota: IDE NetBeans com resolução de tela em 1024x768 pixel

Sistema Operacional Processador Memória HD Livre

Microsoft Windows 500 MHz Intel Pentium III workstation ou equivalente

512 MB 850 MB

Linux 500 MHz Intel Pentium III workstation ou equivalente

512 MB 450 MB

Solaris OS (SPARC) UltraSPARC II 450 MHz 512 MB 450 MB

Solaris OS (x86/x64 Platform Edition)

AMD Opteron 100 Série 1.8 GHz 512 MB 450 MB

Mac OS X PowerPC G4 512 MB 450 MB

Configuração Recomendada de Hardware

Sistema Operacional Processador Memória HD Livre

Microsoft Windows 1.4 GHz Intel Pentium III workstation ou equivalente

1 GB 1 GB

Linux 1.4 GHz Intel Pentium III workstation ou equivalente

1 GB 850 MB

Solaris OS (SPARC) UltraSPARC IIIi 1 GHz 1 GB 850 MB

Solaris OS (x86/x64 Platform Edition)

AMD Opteron 100 Series 1.8 GHz 1 GB 850 MB

Mac OS X PowerPC G5 1 GB 850 MB

Requerimentos de SoftwareNetBeans Enterprise Pack 5.5 executando sobre Java 2 Platform Standard Edition Development Kit 5.0 ou superior (JDK 5.0, versão 1.5.0_01 ou superior), contemplando a Java Runtime Environment, ferramentas de desenvolvimento para compilar, depurar, e executar aplicações escritas em linguagem Java. Sun Java System Application Server Platform Edition 9.

• Para Solaris, Windows, e Linux, os arquivos da JDK podem ser obtidos para sua plataforma em http://java.sun.com/j2se/1.5.0/download.html

• Para Mac OS X, Java 2 Plataform Standard Edition (J2SE) 5.0 Release 4, pode ser obtida diretamente da Apple's Developer Connection, no endereço: http://developer.apple.com/java (é necessário registrar o download da JDK).

Para mais informações: http://www.netbeans.org/community/releases/55/relnotes.html

Engenharia de Software 2

http://java.sun.com/j2se/1.5.0/download.html

http://www.netbeans.org/community/releases/55/relnotes.html

http://www.netbeans.org/community/releases/40/relnotes.html

http://developer.apple.com/java

JEDITM

Colaboradores que auxiliaram no processo de tradução e revisãoAécio JúniorAlexandre MoriAlexis da Rocha SilvaAllan Souza NunesAllan Wojcik da SilvaAnderson Moreira PaivaAnna Carolina Ferreira da RochaAntonio Jose R. Alves RamosAurélio Soares NetoBruno da Silva BonfimCarlos Fernando GonçalvesDaniel Noto PaivaDenis Mitsuo Nakasaki

Fábio BombonatoFabrício Ribeiro BrigagãoFrancisco das ChagasFrederico DubielJacqueline Susann BarbosaJoão Vianney Barrozo CostaKleberth Bezerra G. dos SantosKefreen Ryenz Batista LacerdaLeonardo Ribas SegalaLucas Vinícius Bibiano ThoméLuciana Rocha de OliveiraLuiz Fernandes de Oliveira Junior Marco Aurélio Martins Bessa

Maria Carolina Ferreira da SilvaMassimiliano GiroldiMauro Cardoso MortoniMauro Regis de Sousa LimaPaulo Afonso CorrêaPaulo Oliveira Sampaio ReisRonie DotzlawSeire ParejaSergio TerzellaThiago Magela Rodrigues DiasVanessa dos Santos AlmeidaWagner Eliezer Rancoletta

Auxiliadores especiais

Revisão Geral do texto para os seguintes Países:

• Brasil – Tiago Flach• Guiné Bissau – Alfredo Cá, Bunene Sisse e Buon Olossato Quebi – ONG Asas de Socorro

Coordenação do DFJUG

• Daniel deOliveira – JUGLeader responsável pelos acordos de parcerias• Luci Campos - Idealizadora do DFJUG responsável pelo apoio social• Fernando Anselmo - Coordenador responsável pelo processo de tradução e revisão,

disponibilização dos materiais e inserção de novos módulos• Rodrigo Nunes - Coordenador responsável pela parte multimídia• Sérgio Gomes Veloso - Coordenador responsável pelo ambiente JEDITM (Moodle)

Agradecimento Especial

John Paul Petines – Criador da Iniciativa JEDITM

Rommel Feria – Criador da Iniciativa JEDITM


JEDITM

1. Objetivos

Quando pessoas pensam sobre computadores, o primeiro detalhe que vêem em suas mentes são as máquinas físicas – monitor, teclado, mouse e CPU. No entanto, o software é o que permite utilizá-los. Um software de computador inclui um conjunto de programas que executa no interior de um computador, de qualquer tamanho e arquitetura, que estão sendo processados por programas e apresentados aos usuários como cópias hard ou soft. É construído por engenheiros de software através do emprego de um processo de software que produz produtos de alta qualidade de trabalho que identifica as necessidades das pessoas que irão usar o sistema.

Atualmente, o software é uma importante tecnologia em nossas vidas porque as afeta praticamente em todos os aspectos, incluindo governo, comércio e cultura. Nessa lição, discutiremos sobre engenharia de software como uma disciplina em construção de um software de computador com qualidade. Uma camada de visão será usada para esboçar conceitos necessários à compreensão da engenharia de software. Em seguida, obteremos uma compreensão sobre as pessoas envolvidas no esforço de desenvolvimento de software. Ao final, explicaremos a necessidade de documentação e de como organizar e documentar produtos de trabalho de engenharia de software.

Ao final desta lição, o estudante será capaz de:

• Ter uma visão de camadas sobre a Engenharia de Software• Obter qualidade dentro do esforço do desenvolvimento• Conhecer as técnicas e garantias de Qualidade de Software• Conhecer o processo de software• Compreender o desenvolvimento de sistemas• Definir as pessoas envolvidas no esforço do desenvolvimento• Conhecer as diversas formas e benefícios de documentação


JEDITM

2. Engenharia de Software – Uma visão em camadas

Engenharia de Software é uma disciplina que aplica princípios da engenharia de desenvolvimento na qualidade do software em um determinado tempo e com um custo efetivo. Usando uma abordagem sistemática e metodológica para produzir resultados que possam ser quantificados. Faz uso de medição e métricas para avaliar a qualidade, não somente do software, mas também do processo. Utilizada para avaliar e gerenciar projetos de desenvolvimento de software.

Engenharia de Software é vista de modo diferente pelos diversos profissionais. Pressman sugere uma visão da engenharia de software como uma camada tecnológica1. Essa visão consiste em quatro camadas: foco na qualidade, processo, método e ferramentas. A Figura 1 ilustra essa visão da engenharia de software.

Figura 1: Engenharia de Software – Uma camada de visão

2.1. Foco na Qualidade

Essa camada busca um total foco na qualidade. É uma cultura onde o compromisso em melhoria continua no processo de desenvolvimento do software é sustentado. Permite o desenvolvimento de mais abordagens efetivas para engenharia de software.

2.2. Processo

Define uma estrutura, que consiste em áreas de processos chave, que define e permite a entrega racional e a tempo de um software. Áreas de processos chave são a base para o gerenciamento de projeto de software. Estabelecem que métodos técnicos sejam aplicados, quais ferramentas são usadas, que produtos de trabalho precisam ser produzidos, e que marcos são definidos. Incluem a garantia que a qualidade será mantida, e que a mudança é devidamente controlada e gerenciada.

2.3. Método

Métodos definem procedimentos sistemáticos e ordenados de construção de software. Eles proporcionam uma estrutura global interna onde as atividades do engenheiro de software são realizadas. Essas atividades incluem um conjunto amplo de tarefas, tais como, análise de requisitos, design, construção do programa, teste e manutenção.

Metodologia é a ciência de pensamento sistemático, usando os métodos ou procedimentos para uma disciplina em particular. Existem várias metodologias da engenharia de software que são usadas atualmente. Algumas delas estão enumeradas abaixo:

Metodologias Estruturadas:

• Informações de Engenharia• Desenvolvimento do Ciclo de Vida do Software/Ciclo de Vida do Projeto• Metodologia de Desenvolvimento de Aplicação Rapid• Metodologia de Desenvolvimento de Aplicação Joint• Método CASE*

1 Pressman, Roger S., Software Engineering, A Practitioner's Approach, Sixth Edition, (Singapore: McGraw-Hill Internal Edition, 2005), p. 53-54


Foco na Qualidade

Processo

Método

Ferramentas

JEDITM

Metodologias Orientadas a Objeto:

• Método Booch • Método Coad e Yourdon • Método Jacobson • Método Rambaugh • Método Wirfs-Brock

2.4. Ferramentas

Promovem o suporte aos processos e métodos. Ferramentas CASE (Computer Aided Software Engineeing) proporcionam um sistema de suporte ao projeto de desenvolvimento, onde as informações criadas por uma ferramenta podem ser usadas por outras. Podem ser automáticas ou semi-automáticas.

Muitas ferramentas são usadas para desenvolver modelos. Modelos são patterns (padrões) de algo que foi criado ou são simplificações. Existem dois modelos que geralmente são desenvolvidos por um engenheiro de software, especialmente, o modelo de sistema e o modelo de software. O modelo de sistema é uma representação acessível de um sistema complexo que precisa ser estudado, enquanto o modelo de software é chamado de blueprint do software que precisa ser construído. Assim como as metodologias, vários modelos de ferramentas são usados para representar sistemas e softwares. Alguns estão descritos abaixo.

Abordagem de Modelos de Ferramentas Estruturada:

• Diagrama de Entidade-Relacionamento• Diagrama de Fluxo de Dados• Pseudocódigo• Fluxograma

Abordagem de Modelo de Ferramenta Orientada a Objeto:

• Linguagem de Modelagem Unificada (UML)


JEDITM

3. Qualidade dentro do Esforço de Desenvolvimento

Conforme mencionado anteriormente, a qualidade é a mente que influencia todo engenheiro de software. Focando na qualidade em todas as atividades de engenharia de software, reduz-se custo e melhora-se o tempo de desenvolvimento pela minimização de um novo trabalho de correção. Para proceder dessa forma, um engenheiro de software tem que definir explicitamente que qualidade de software é ter um conjunto de atividades que assegurarão que todo produto de trabalho da engenharia de software exibe alta qualidade, fazer controle de qualidade e atividades garantidas, o uso de métricas para desenvolver estratégias para melhorar o produto de software e o processo.

3.1. O que é qualidade?

Qualidade é a característica total de uma entidade para satisfazer necessidades declaradas e implícitas. Essas características ou atributos têm que ser mensuráveis de modo que possam ser comparados por padrões conhecidos.

3.2. Como definimos qualidade?

Três perspectivas são usadas na compreensão da qualidade, especialmente, olhamos para a qualidade do produto, do processo e no contexto do ambiente de negócios2.

Qualidade do Produto

Significa coisas diferentes para cada pessoa. É relativo para uma pessoa analisar qualidade. Para os usuários finais, o software tem qualidade se fornecer o que desejam e quando desejam o tempo todo. Também julgam baseados na facilidade de usar e de aprender como usá-lo. Normalmente avaliam e categorizam com base em características externas, tal como, número de falhas por tipo. Falhas podem ser categorizadas como: insignificantes, importantes e catastróficas. Para que outros possam desenvolver e manter o software, estes devem ficar de olho nas características internas em vez das externas. Exemplos que incluem erros e falhas encontradas durante as fases de análise de requisitos, design, e codificação são normalmente feitos anteriormente ao carregamento dos produtos para os usuários finais.

Como engenheiros de software, devemos construir modelos baseados em como os requisitos dos usuários externos serão relacionados com os requisitos internos dos desenvolvedores.

Qualidade do Processo

Existem várias tarefas que afetam a qualidade do software. Às vezes, quando uma tarefa falha, a qualidade do software falha. Como engenheiros de softwares, devemos validar a qualidade no processo de desenvolvimento do software. Regras de processo sugerem que pela melhoria do processo de desenvolvimento do software, também há melhora da qualidade do produto resultante. Algumas regras de processo são demonstradas abaixo:

• Capability Maturity Model Integration(CMMI). Foram formulados pelo Software Engineering Institute (SEI). É um processo meta-modelo que é baseado em um conjunto de sistemas e competências da engenharia de software que devem existir dentro de uma organização. Como a mesma atinge diferentes níveis de capacidade e maturidade desses processos de desenvolvimento.

• ISO 9000:2000 para Software. É um padrão genérico, aplicado para qualquer organização que queira melhorar a qualidade global dos produtos, sistemas ou serviços que proporciona.

• Software Process Improvement e Capability Determination (SPICE). É um padrão que define um conjunto de requisitos para avaliação do processo de software. O objetivo desse padrão é auxiliar organizações a desenvolver uma análise objetiva da eficácia de qualquer processo de software definido.

Qualidade no contexto do ambiente de negócio

2 Pfleeger, Shari Lawrence, Software Engineering Theory and Practice, International Edition, (Singapore: Prentice-Hall, 1999), p. 10-14


JEDITM

Nessa perspectiva, qualidade é visualizada em termos de produtos e serviços sendo proporcionado pelo negócio em que o software é usado. Melhorando a qualidade técnica dos processos de negócio, agrega-se valor ao negócio, por exemplo, valor técnico do software traduz o valor do negócio. Também é importante medir o valor do software em termos de terminologias de negócio, tal como, “quantos pedidos de venda foram processados hoje?”, valor do dólar sobre o retorno em cima dos investimentos (ROI), etc. Se o software não agrega valor ao negócio, qual a necessidade de tê-lo em primeiro lugar?

3.3. Como endereçamos os pontos importantes sobre qualidade?

Podemos endereçar os pontos importantes sobre qualidade em:

1. Uso de padrões de Qualidade. Padrões de qualidade são um conjunto de princípios, procedimentos, metodologias e regras, para resumir, sobre qualidade no processo, tais como, CMMI, ISO 9000:2000 para Software e SPICE.

2. Compreender pessoas envolvidas no processo de desenvolvimento incluindo usuários finais e participantes. Sustenta um ambiente de colaboração e comunicação efetiva.

3. Compreender as tendências sistemáticas na natureza humana. Tal como, as pessoas tendem a ser contrárias ao risco quando existe uma perda potencial, são indevidamente otimistas em seus planos e projeções, e preferem usar julgamentos intuitivos ao invés de modelos quantitativos.

4. Engajamento para a qualidade. Uma mente focada sobre qualidade é necessária para descobrir erros e defeitos assim que possam ser endereçados imediatamente.

5. Requisitos de usuários administradores porque mudarão ao longo do tempo. Requisitos é a base, definindo as características da qualidade de software.


JEDITM

4. Técnicas e Garantias de Qualidade de Software

Garantia de qualidade de Software é um subconjunto da engenharia de software que assegura que todos os produtos de trabalho sejam realizados, e que cumpram com as exigências e padrões estabelecidos pelos usuários. Considera-se como uma das atividades mais importantes que é aplicada durante todo o processo do desenvolvimento do software. O objetivo é detectar defeitos antes do software ser entregue como um produto acabado para o usuário final. Isto abrange uma aproximação eficaz da gerência de qualidade, tecnologia de engenharia de software (métodos e ferramentas), técnicas formais de revisão, várias estratégias de teste, controle de documentação de software e alterações feitas, um procedimento para assegurar a conformidade com os padrões de desenvolvimento de software, e um mecanismo para mensurá-los e documentá-los.

4.1. Qualidade de Software

Um software possui qualidade se ele estiver ajustado para uso, isto é, se estiver trabalhando corretamente. Para que ele trabalhe corretamente, ele deve estar em conformidade com os requisitos funcionais e de performance (características externas dos usuários), padrões explicitamente documentados de desenvolvimento (padrões de qualidade), e características implícitas (características internas aos desenvolvedores) que são esperadas por todo desenvolvimento profissional de software.

Três pontos importantes enfatizados para definir a qualidade do software.

1. Requisitos de Software são a base para a qualidade do software. É necessário explicitar, especificar e priorizar.

2. Padrões definem um de critérios de desenvolvimento que irão mostrar a maneira com a qual o software será desenvolvido.

3. Características implícitas deverão ser identificadas e documentadas; elas influenciam na maneira de como o software será desenvolvido assim como sua manutenibilidade.

4.2. Características para uma Boa Engenharia de Software

Para definir uma boa engenharia de software, dê uma olhada nas características específicas que o software apresenta. Algumas delas estão enumeradas abaixo:

• Usabilidade. É a característica do software de apresentar facilidades entre a comunicação dos usuários com o sistema.

• Portabilidade. É a capacidade do software ser executado em diferentes plataformas e arquiteturas.

• Reusabilidade. É a habilidade do software de se transferir de um sistema para outro.

• Manutenibilidade. É a habilidade do software de se envolver e adaptar-se às alterações em um curto espaço de tempo. É caracterizado pela fácil atualização e manutenção.

• Dependência. É a característica do software ser confiável e de segurança.

• Eficiência. É a capacidade do software utilizar os recursos com maior eficiência.

4.3. Atividades da Garantia de Qualidade de Software

Garantia de Qualidade de Software é composta por uma variedade de atividades com o objetivo de construir software com qualidade. Isto envolve dois grupos de desenvolvedores e a equipe de SQA (Software Quality Assurance). A equipe de SQA tem responsabilidade em garantir plenamente à qualidade, supervisionar, manter, analisar e reportar defeitos. As atividades envolvidas são as seguintes:

1. A equipe de SQA prepara o Plano de SQA. Isto se dá durante a fase de planejamento de projeto. Identificam-na:


JEDITM

• Avaliação a ser executada;

• Auditorias e revisões a serem executadas;

• Padrões que devem ser aplicados;

• Procedimentos de erros reportados e monitorados;

• Documentos que devem ser produzidos; e

• Conjunto de respostas que se fizer necessário.

2. A equipe de SQA participa na descrição do processo de desenvolvimento de software. O time de desenvolvedores escolhe o processo de desenvolvimento e a equipe de SQA deve verificar se ele se enquadra na política organizacional e nos padrões de qualidade.

3. A equipe de SQA revisa as atividades de engenharia de software empregadas pelo time de desenvolvedores para checar a conformidade com o processo de desenvolvimento de software. Eles monitoram e seguem desvios do processo do desenvolvimento do software. Documentam-no e asseguram-se de que as correções sejam feitas.

4. A equipe de SQA revê o trabalho para verificar se estão conforme o padrão definido. Eles monitoram e marcam defeitos e falhas encontrados em cada trabalho.

5. A equipe de SQA assegura-se que os desvios nas atividades de software e no processo de produção estejam seguramente baseados na definição de procedimentos e padrões de operação.

6. A equipe de SQA envia desvios e desconformidades aos padrões para os gerentes ou a quem for de interesse.

4.4. Técnicas Formais de Revisão

Produtos de trabalho são as saídas esperadas como resultado da execução de tarefas no processo de desenvolvimento de software. Esses resultados contribuem para o desenvolvimento de software com qualidade. Conseqüentemente, devem ser mensurados e verificados novamente se vão ao encontro das exigências e dos padrões. As alterações nos produtos de trabalho são significativas; elas podem ser monitoradas e controladas. A técnica de checar a qualidade dos produtos de trabalho é a técnica formal de revisão. Formal Technical Reviews (FTR) são executadas em vários pontos do processo do desenvolvimento do software. Ela serve para descobrir erros e defeitos que podem ser eliminados antes do software ser enviado para o usuário final. Especificamente, seus objetivos são:

1. Descobrir erros em funções, na lógica ou na execução para toda a representação do software;

2. Verificar se o software sob a revisão encontra-se de acordo com os requisitos do usuário;

3. Assegurar-se que o software esteja de acordo com os padrões definidos;

4. Conseguir que o software seja desenvolvido de uma maneira uniforme; e

5. Desenvolver projetos mais gerenciáveis.

Um guia geral de condução das técnicas formais de revisão está listado abaixo.

• Revisar o produto de trabalho e NÃO o desenvolvedor do produto de trabalho. O objetivo da revisão e descobrir erros e defeitos para melhorar a qualidade do software. O tom da revisão pode ser brando, porém construtivo.

• Planejar e cumprir a agenda. Revisões não devem durar mais de duas horas.

• Minimizar os debates e discussões. É inevitável que os problemas sejam levantados e isso não cause efeito nas pessoas. Lembre a todos que não é hora de resolver os problemas que serão apenas documentados, uma outra reunião deve ser agendada para resolvê-los.

• Indique áreas de problema, mas não às tente resolvê-las. Mencione e esclareça áreas de problema. Entretanto, não é hora de resolver problemas, deverão ser resolvidos em uma outra reunião.

• Tome nota. É uma boa prática tomar nota do que foi dito e suas prioridades para que elas


JEDITM

possam ser vistas por outros revisores. Isto ajudará a esclarecer os defeitos e ações a serem tomadas.

• Mantenha o número dos participantes a um mínimo e insista em preparar-se para a revisão. Escrever comentários e observações pelos revisores é uma boa técnica.

• Forneça uma lista de verificação para o produto de trabalho que é provável ser revista. A lista de revisão provê uma estrutura que conduza a revisão. Isto também ajuda os revisores a manterem o foco na questão.

• Programe as revisões como parte do processo de desenvolvimento de software e assegure-se de que os recursos sejam fornecidos para cada revisor. Preparação prevê interpretações em uma reunião. Isto também ajuda os revisores a manterem o foco na questão.

• Sumário da revisão. Verifica a eficácia do processo da revisão.

Duas técnicas formais de revisão do produto de trabalho usadas na indústria são Fagan's Inspection Method e Walkthroughs.

4.4.1. Método de Inspeção de Fagan

Introduzido por Fagan em 1976 na IBM. Originalmente foi utilizado para verificar códigos de programas. Entretanto, pode ser estendido para incluir outros produtos de trabalho como técnicas de documentos, modelo de elementos, projetos de códigos e dados etc. Isto é gerenciado por um moderador que é responsável por supervisionar a revisão. Isto requer uma equipe de inspetores designados a verificar se as regras do produto de trabalho vão de encontro à lista de interesse preparada. É mais formal que o walkthrough. A seguir estão descritas regras determinadas na qual cada participante deverá aderir:

• As inspeções são realizadas em um número de pontos no processo do planejamento do projeto e do desenvolvimento dos sistemas.

• Todas as classes com defeito são documentadas e os produtos do trabalho são inspecionados não somente a nível lógico, de especificações ou de funções de erros.

• A inspeção é realizada por colegas em todos os níveis exceto o chefe.

• As inspeções são realizadas em uma lista prescrita das atividades.

• As reuniões de inspeção são limitadas a duas horas.

• As inspeções são conduzidas por um moderador treinado.

• Inspetores são designados a especificar regras para aumentar a eficácia. As listas de verificação dos questionários a serem perguntados pelos inspetores são usadas para definir tarefas e estimular a encontrar defeitos. Os materiais são inspecionados minuciosamente para que seja encontrado o máximo número de possíveis erros.

• Estatísticas com os tipos de erros são vitais, são utilizadas para obter análises de uma maneira similar à análise financeira.

Conduzir inspeções requer muitas atividades. Elas estão categorizadas a seguir:

• Planejamento. O moderador deve se preparar para a inspeção. Decide quem serão os inspetores e as regras que estes devem obedecer, quem e quando desempenharão seus papéis e distribuir a documentação necessária.

• Uma rápida apresentação. 30 minutos de apresentação do projeto dos inspetores é o suficiente. Isto pode ser omitido se todos estiverem bem familiarizados com o projeto.

• Preparando. Cada inspetor terá de 1 a 2 horas sozinho para inspecionar o produto de trabalho. Ele irá executar as regras passadas a ele com base na documentação provida pelo moderador. Ele irá tentar descobrir defeitos no produto de trabalho. Ele não deverá reparar defeitos ou criticar o desenvolvedor do produto de trabalho.

• Realizando a reunião. Os participantes das reuniões são inspetores, moderadores e desenvolvedores do produto de trabalho. Os desenvolvedores do produto de trabalho estão presentes para explicar o produto de trabalho, e responder às perguntas que os inspetores fizerem. Nenhuma discussão se o defeito é ou não real é permitida. Uma lista de defeitos deve ser produzida pelo moderador.


JEDITM

• Refazendo o produto de trabalho. A lista de defeitos deve ser atribuída a uma pessoa para repará-la. Normalmente, esta é o desenvolvedor do produto de trabalho.

• Acompanhando os reajustes. O moderador assegura-se que os defeitos nos produtos de trabalho sejam endereçados e solucionados. Mais tarde este deve ser inspecionado por outro inspetor.

• Realizando uma reunião ocasional de análise. Isto é opcional, momento onde é dada a possibilidade aos inspetores de expressarem sua visão pessoal sobre erros e melhorias. A ênfase é dada à maneira que a inspeção foi feita.

4.4.2. Walkthrough

O walkthrough é menos formal que a inspeção. Aqui, o produto de trabalho e sua documentação correspondente são entregues para um time de revisores, normalmente em torno de 3 pessoas, onde comentários de sua exatidão são apresentados. Ao contrário da inspeção onde um é o moderador, o desenvolvedor do produto de trabalho coordena o walkthrough. Um escrivão também deve estar presente para documentar a lista de ações. Uma lista de ações deve ser feita a fim de melhorar a qualidade do produto final a qual inclui ajustes dos defeitos, resoluções dos problemas etc.

Alguns passos devem ser seguidos para obter sucesso no walkthrough. Eles estão listados abaixo:

• Nenhum gerente deve estar presente.

• Enfatizar que o walkthrough é para detecção de erros e não para correção.

• Manter o interesse do grupo.

• Nenhuma contagem ou atribuição de nota.

• Criticar o produto; não a pessoa.

• Sempre documentar a lista de ações.

Conduzir o walkthrough, é similar à inspeção, requer muitas atividades. Elas estão categorizadas como se segue:

• Antes do walkthrough

• O desenvolvedor do produto de trabalho agenda o walkthrough, preferivelmente, com um dia de antecedência ou dois no máximo.

• Distribuir o material necessário para o produto de trabalho dos revisores.

• Pede-se especificamente que cada revisor traga pelo menos dois comentários positivos do walkthrough e um comentário negativo sobre o produto do trabalho.

• Durante o walkthrough

• O desenvolvedor do produto de trabalho faz uma rápida apresentação do seu produto de trabalho. Este passo pode ser ignorado caso os revisores conheçam bem o produto de trabalho.

• Solicitar comentários aos revisores. Às vezes, problemas são levantados e apresentados, mas não devem ser solucionados durante o walkthrough. Os problemas deverão ser incluídos em uma lista de ações.

• Uma lista de ações deve ser produzida até o fim do walkthrough.

• Após o walkthrough

• O desenvolvedor do produto de trabalho recebe a lista de ações.

• Pede-se para enviar os estados das ações com o objetivo de resolver erros ou discrepâncias apresentadas na lista de ações.

• Possivelmente, um outro walkthrough deve ser agendado.


JEDITM

5. O Processo de Software

O processo de software provê uma estratégia que as equipes de desenvolvimento empregam para construir software com qualidade. Ele é escolhido baseado na maturidade do projeto e aplicação, métodos e ferramentas utilizadas e gerência e produtos que são exigidos. Pressman fornece uma representação gráfica do processo de software. De acordo com ele, esta representação fornece a estrutura que um plano compreensivo de desenvolvimento de software pode estabelecer. Consiste em estrutura de atividades, conjunto de tarefas e atividades guarda-chuva3.

Figura 2: Processo de Software Pressman

Estrutura de Atividades

Estas atividades são executadas por pessoas envolvidas no processo de desenvolvimento aplicado a qualquer projeto de software independente do tamanho, composição da equipe ou complexidade do problema. Também são conhecidos como fases do processo de desenvolvimento de software.

Conjunto de Tarefas

Cada uma das atividades na estrutura do processo define um conjunto de tarefas. Estas tarefas devem ter marcos, produtos que podem ser entregues ou produtos finais e pontos de garantia de qualidade de software (Pontos de SQA). Eles são modificados e ajustados a uma característica específica do projeto de software e dos requisitos de software.

Atividades Guarda-chuva

Estas são atividades que dão suporte às atividades estruturais ao longo do progresso do projeto de software como a gerência de projeto, gerência de configuração, gerência de requisitos, gerência de riscos, revisão técnica formal, etc.

5.1. Tipos de Modelos de Processo de Software

Existem vários tipos de modelos de processo de software. Os mais comuns são discutidos nesta seção.

Modelo Linear Seqüencial

Também conhecido como modelo cascata ou ciclo de vida clássico. Este é o primeiro modelo formalizado. Outros modelos de processo são baseados em sua abordagem de desenvolvimento

3 Pressman, Software Engineering A Practitioner's Approach, p. 54-55


Estrutura do Processo Comum

Atividades guarda-chuva

Estrut.de Atividades n

Estrut. de Atividades 2Estrutura de Atividades 1

Cj.Tarefas 1:TarefasMarcosEntregáveisPontos de SQA

Cj.Tarefas 1:TarefasMarcosEntregáveisPontos de SQA

Conj. Tarefas 1:TarefasMarcosEntregáveisPontos de SQA

JEDITM

de software. Ele sugere uma abordagem sistemática e seqüencial para o desenvolvimento de software. Ele inicia pela análise do sistema, progredindo para a análise do software, projeto, codificação, teste e manutenção. Ele prega que uma fase não pode iniciar enquanto a anterior não seja finalizada. A Figura 3 mostra este tipo de modelo de processo de software.

Figura 3: Modelo Linear Seqüencial

As vantagens deste modelo são:

• É o primeiro modelo de software formulado.

• Fornece a base para outros modelos de processo de software.

As desvantagens deste modelo são:

• Projetos de software reais dificilmente seguem restritamente um fluxo seqüencial. De fato, é muito difícil decidir quando uma fase termina e a outra começa.

• O envolvimento do usuário final só ocorre no início (engenharia de requisitos) e no final (operação e manutenção). Ele não mapeia o fato dos requisitos mudarem durante o projeto de desenvolvimento de software.

• Às vezes os usuários finais têm dificuldades de estabelecer todos os requisitos no início. Logo, isto atrasa o desenvolvimento do software.

Modelo de Prototipação

Para auxiliar o entendimento dos requisitos dos usuários, protótipos são construídos. Protótipos são softwares desenvolvidos parcialmente para permitir aos usuários e desenvolvedores examinarem características do sistema proposto e decidir se devem ser incluídos no produto final. Esta abordagem é mais bem adaptada nas seguintes situações:

• Os clientes definem um conjunto de objetivos gerais para o software, mas não identificam detalhes de entrada, processamento ou requisitos de saída.

• O desenvolvedor não tem certeza da eficiência do algoritmo, da adaptabilidade da tecnologia ou a forma que a interação homem-computador deve ser.

A Figura 4 mostra este modelo de processo.


Engenharia deRequisitos

Engenhariade Projetos

Codificação

Testes

Operaçãoe

Manutenção

JEDITM

Figura 4: Modelo de Prototipação

A vantagem deste modelo de processo é:

• Os usuários têm participação ativa na definição dos requisitos de interação homem-computador do sistema. Vêem a aparência atual do software.

As desvantagens deste modelo de processo são:

• Os clientes podem erroneamente aceitar o protótipo como uma versão funcional. Isto compromete a qualidade do software porque outros requisitos de software não são alvos de manutenção.

• Os desenvolvedores ficam tentados a implementar um protótipo funcional sem pensar em futuras expansões ou manutenções.

Modelo de Desenvolvimento Rápido de Aplicações (RAD)

Este é um processo de desenvolvimento de software linear seqüencial que enfatiza um ciclo de desenvolvimento extremamente curto. Baseia-se em uma abordagem de construção modular. É melhor utilizado em projetos de software onde os requisitos já estão bem entendidos, o escopo do projeto já está bem definido e uma grande carteira com recursos disponíveis. Todos esperam comprometer-se com a abordagem de desenvolvimento rápido.

Neste modelo de processo, o projeto de software é definido baseado na decomposição funcional do software. Partições funcionais são associadas a diferentes equipes e são desenvolvidas em paralelo. A Figura 5 mostra este modelo de processo.

Figura 5: Desenvolvimento Rápido de Aplicações


Entrevista dosClientes

Desenvolvedores constroem ou

revisam protótipos

Clientes testamo protótipo

Engenhariade

Requisitos


Codificação

Testes

Fim-Turno

Partição Funcional 1- Equipe

Engenhariade

Requisitos


Codificação

Testes

Fim-Turno

Partição Funcional 2 - Equipe

Engenhariade

Requisitos


Codificação

Testes

Fim-Turno

Partição Funcional 3 - Equipe

60 a 90 Dias

JEDITM

A vantagem deste modelo é:

• Um sistema totalmente funcional é criado em um curto espaço de tempo.

As desvantagens deste modelo são:

• Para um projeto de larga escala este processo requer um número suficiente de desenvolvedores para formar o número certo de equipes.

• Desenvolvedores e clientes devem se comprometer com as atividades relâmpagos necessárias para desenvolver um software em um curto espaço de tempo.

• Não é um bom modelo de processo para sistemas que não são modularizáveis.

• Não é um bom modelo de processo para sistemas que requerem alta performance.

• Não é um bom modelo de processo para sistemas que fazem uso de novas tecnologias ou têm alto grau de interoperabilidade com programas já existentes como os sistemas legados.

Modelo de Processo Evolucionário

Este modelo de processo reconhece que um software envolve mais de um período de tempo. Ele permite o desenvolvimento de uma versão mais crescentemente complexa de software. A abordagem é naturalmente iterativa. Alguns modelos de processo evolucionário específicos são: Modelo Incremental, Modelo Espiral e Modelo Baseado em Montagem de Componentes.

Modelo Incremental

Este modelo de processo combina os elementos do modelo linear seqüencial com a interatividade do modelo de prototipação. As seqüências lineares são definidas de maneira que cada seqüência produza um incremento de software. Diferente da prototipação, o incremento é um produto operacional. A Figura 6 mostra este modelo de processo.

Figura 6: Modelo de Processo Incremental

Modelo Espiral

Foi originalmente proposto por Boehm. É um modelo de processo de software evolucionário


Engenhariade

Requisitos

Engenhariade Projeto

Codificação

Testes

Entrega doPrimeiro

Incremento

Primeiro Incremento

Engenhariade

Requisitos


Codificação

Testes

Fim-Turno

Segundo Incremento

Engenhariade

Requisitos


Codificação

Testes

Fim-Turno

Terceiro Incremento

PrimeiroIncremento de SW

SegundoIncremento

de SW


TerceiroIncremento

de SW


SegundoIncremento

de SW

JEDITM

acoplado à naturalidade iterativa da prototipação com o controle e os aspectos sistemáticos do modelo linear seqüencial. Ele disponibiliza potencial para desenvolvimento rápido de versões incrementais do software. Uma importante característica deste modelo é que sua análise de risco faz parte da sua estrutura de atividades. Porém, isto requer experiência em estimativa de riscos. A Figura 7 mostra um exemplo do modelo espiral.

Figura 7: Modelo Espiral

Modelo de Montagem Baseada em Componentes

É similar ao Modelo de Processo Espiral. No entanto, este usa a tecnologia de objetos onde a ênfase é a criação das classes que encapsulam dados e métodos utilizados para manipular os dados. A reusabilidade é uma das características de qualidade que sempre é checado durante o desenvolvimento do software. A Figura 8 mostra o Modelo de Montagem Baseada em Componentes.

Figura 8: Modelo de Montagem Baseada em Componentes

Modelo de Desenvolvimento Concorrente


Análise de risco

Planejamento

Comunicação

Análise & Projeto

Codificação & Distribuição

AvaliaçãoABCD

A. Projeto Inicial do SoftwareB. Manutenção do Novo SoftwareC. Melhoramento do SoftwareD. Desenvolvimento de outro sistema inter-relacionado

Análise de Risco

Planejamento

Comunicação

Análise OO & Projeto

Codificação & Distribuição

AvaliaçãoABCD

A. Projeto Inicial do SoftwareB. Manutenção do Novo SoftwareC. Melhoramento do SoftwareD. Desenvolvimento de outro sistema inter-relacionado

DeterminarClasses

Candidatas

Verificar Classes na Biblioteca

Utilize asClasses

ConstruirNova Classe

Colocar NovasClasses naBiblioteca

Construir a enésima Iteração

do Software

JEDITM

O Modelo de Desenvolvimento Concorrente é também conhecido como engenharia concorrente. Ele utiliza os diagramas de estado para representar a relação de concorrência entre tarefas associadas na estrutura de atividades. Ele é representado esquematicamente por uma série de tarefas técnicas maiores e estados associados. A necessidade do usuário, a decisão gerencial e a revisão de resultados dirigem a progressão geral do desenvolvimento. A Figura 9 mostra o modelo de desenvolvimento concorrente.

Figura 9: Modelo de Desenvolvimento Concorrente

Métodos Formais

É uma abordagem da engenharia de software que incorpora um conjunto de atividades guiadas por uma especificação matemática do software. Eles fornecem um mecanismo para remover vários problemas que dificultariam o uso de outros paradigmas de engenharia de software. Serve como um meio de verificar, descobrir e corrigir erros que de outra forma não seriam detectados.

5.2. Fatores que Afetam a Escolha do Modelo de Processo

• Tipo do Projeto

• Métodos e Ferramentas a serem utilizadas

• Requisitos e Pessoas-Chaves do Negócio

• Senso Comum e Julgamento


Início DesenvolverModelo

ExaminarModelo

Entrar comNovas Linhas

Bases

RevisarModelo

AguardarMudanças

Fim

Atividades de Análise

JEDITM

6. Entendendo Sistemas

O projeto de software que necessita ser desenvolvido revolve em torno dos sistemas. Os sistemas consistem em um grupo de entidades ou componentes, Juntos interagem para dar forma aos inter-relacionamentos específicos, organizados por meio da estrutura, e trabalhando para conseguir um objetivo comum. Compreender sistemas fornece um contexto para todo o projeto com a definição dos limites dos projetos. Surge a pergunta, "O que é incluído no projeto? O que não é?" Em definição de limites do sistema, um Engenheiro de Software descobre o seguinte:

• As entidades ou o grupo das entidades que são relacionadas e organizadas de alguma maneira dentro do sistema fornecem a entrada, realizam atividades ou recebem a saída;

• Atividades ou ações que devem ser executadas pelas entidades ou pelo grupo das entidades a fim conseguir a finalidade do sistema;

• Uma lista de entrada; e

• Uma lista de saída.

Como exemplo, a Figura 10 mostra os limites do sistema do estudo de caso. Mostra elementos deste sistema com o uso do diagrama do contexto.

Figura 10: Limites do sistema de aplicação da sociedade do clube

As entidades que são envolvidas neste sistema são os candidatos, a equipe de funcionários do clube e o treinador. São representadas como caixas retangulares. São relacionadas umas com as outras executando determinadas atividades dentro deste sistema. As principais atividades executadas são o envio dos formulários de aplicação, programar as simulações de saídas e a atribuição do pretendente a um grupo. São representados por um círculo no meio que define a funcionalidade da informação mantendo a sociedade do clube. Para executar estas ações, uma lista das entradas é necessária. Especificamente, formulários de aplicação e a programação das simulações de saídas. São representados por uma seta com o nome dos dados que estão sendo passados. A ponta da seta indica o fluxo dos dados. Os resultados mais importantes que se espera deste sistema são os relatórios da sociedade e as listas de grupos. Outra vez, são representados por uma seta com o nome dos dados que estão sendo passados. A ponta da seta indica o fluxo dos dados. O objetivo deste sistema é segurar a aplicação da sociedade do clube.

Princípios Gerais de Sistemas

Alguns princípios gerais dos sistemas são discutidos abaixo. Isto ajudará ao Engenheiro de Software a estudar o sistema onde o projeto do software revolve.

• Mais especializado um sistema, menos capaz é de adaptar-se a circunstâncias diferentes. As mudanças teriam um impacto grande no desenvolvimento de tais sistemas. Cada um deve ser cuidadosamente certificado que não há nenhuma mudança dramática no ambiente ou nas exigências quando o software está sendo desenvolvido. As partes interessadas e os colaboradores devem estar cientes dos riscos e dos custos das mudanças


ATIVIDADES:submeter aplicação

agendar simulações de saídaassociar candidatos a grupo

Candidato

Equipe doClube

Treinador

Equipe doClube

ENTIDADES ENTIDADES

formulário de

requerimento

Agendamento dassimulações desaída

relatório desócios

lista degrupos

ENTRADAS SAÍDAS

JEDITM

durante o desenvolvimento do software.

• Maior o sistema é, mais os recursos devem ser devotados à sua manutenção diária. Como um exemplo, o custo de manter um mainframe é muito caro comparado a manter diversos computadores pessoais.

• Os sistemas são sempre parte de sistemas maiores, e podem sempre ser divididos em sistemas menores. Este é o princípio o mais importante que um Engenheiro de Software deve compreender. Porque os sistemas são compostos da versão menor do subsistema e do vice, os sistemas de software podem ser desenvolvidos em uma maneira modular. É importante determinar os limites dos sistemas e de suas interações de modo que o impacto de seu desenvolvimento seja mínimo e possa ser controlado.

Componentes de um Sistema Automatizado

Há dois tipos de sistemas, a saber, sistemas sintéticos e sistemas automatizados. Os sistemas sintéticos são considerados também sistemas manuais. Não são perfeitos. Terão sempre áreas para aumentar a exatidão e melhorias. Estas áreas para a exatidão e as melhorias podem ser direcionadas por sistemas automatizados.

Os sistemas automatizados são exemplos dos sistemas. Consiste em componentes que suporta a operação de um sistema domínio-específico. No geral, consiste no seguinte:

1. Hardware. Esse componente é o dispositivo físico.

2. Software. Esse componente é o programa executado pela máquina.

3. Pessoal. Esse componente é responsável pelo uso do hardware e software. Provêem dados como entrada, e interpretam a saída (informação) para as decisões diárias.

4. Processos. Este componente representa a política e os procedimentos que governam a operação do sistema automatizado.

5. Dados e Informação. Este componente fornece a entrada (dados) e a saída (informação).

6. Conectividade. Este componente permite a conexão de um sistema computadorizado com um outro sistema. Conhecido também como componente de rede.

A Figura 11 mostra a relação dos cinco primeiros componentes.

Figura 11: Componentes de um Sistema Automatizado

A Figura 12 representa uma ilustração de um domínio-específico da aplicação de um sistema automatizado. Demonstra o sistema automatizado que processa a aplicação da sociedade do clube.


1COMPUTADOR

HARDWARE

2COMPUTADOR

SOFTWARE

4PROCEDIMENTO

MANUALEntrada

4PROCEDIMENTO

COMPUTADORIZADO

Processando

4PROCEDIMENTO

MANUALSaída

3PESSOAL

3PESSOAL

Entrar DadosMonitorar Atividades

Ler Processos ManuaisRevisar Informações

Tomar DecisõesMudar Regras Processuais5

DADOS

5INFORMAÇÃO

JEDITM

Figura 12: Sistema computadorizado da aplicação da sociedade do clube

A informação da aplicação da sociedade do clube é incorporada ao sistema. O pretendente é programado para a simulação de tentativa de saída. Esta programação é recuperada do armazenamento. Uma vez que um pretendente é atribuído a um grupo, esta informação está incorporada no sistema de modo que o relatório da lista do grupo seja produzido.


FASE ENTRADA FASE PROCESSAMENTO FASE DE SAÍDA

FASE DE Aplicações da Programação das Listas do Grupo ARMAZENAMENTO Socie dade simulações de saída

Sociedade ClubeAplicação

Listas do Grupo

Relatórios para a Sociendade do

Clube

JEDITM

7. Entendendo as Pessoas no Esforço de Desenvolvimento

Para ajudar na promoção da idéia comum de qualidade na equipe de desenvolvimento, devemos entender as pessoas envolvidas no processo, particularmente, seus interesses a respeito do sistema e o software que precisa ser desenvolvido. Nesta seção, há dois grupos principais envolvidos no esforço de desenvolvimento de software, especificamente, usuários finais e equipe de desenvolvimento.

7.1. Usuários finais

Usuários finais são pessoas que irão utilizar o produto final. Muitos dos requisitos virão deste grupo. Eles podem ser divididos em dois grupos de acordo com o envolvimento dentro da organização e desenvolvimento, a saber: aqueles envolvidos diretamente e aqueles envolvidos indiretamente.

Aqueles que estão diretamente envolvidos

A Tabela 1 mostra a categorização dos usuários finais de acordo com as funções que eles executam no sistema.

Operacionais Supervisores Executivos

Executam as funções operacionais do sistema.

Executam ações de supervisão sobre as operações diárias do sistema. Eles são em geral avaliados e motivados pela performance de seus orçamentos.

Normalmente possuem iniciativa e servem como financiadores do projeto de desenvolvimento do sistema.

São normalmente mais concentrados com o componente de interface humana do sistema:• Que tipo de teclado irão

utilizar?• Que tipo de tela de

apresentação o sistema terá?• Haverá muito brilho e haverá

caracteres de fácil leitura?

São normalmente mais concentrados na eficiência operacional das funções que precisam ser executadas como a quantidade de saídas em menor tempo.

São menos concentrados nas operações do dia-a-dia. São mais concentrados nas estratégias de lucros e prejuízos a longo prazo.

Têm uma visão local do sistema. Também tendem a ter a mesma visão local e física do sistema similar aos usuários operacionais, mas com à atenção voltada a performance.

Estão mais interessados na visão global do sistema.

Tendem a pensar no sistema em termos físicos.

São os que têm mais contato com os engenheiros de software.

Geralmente trabalham com modelos abstratos do sistema assim como termos físicos. Possuem maiores interesse em resultados.

Tabela 1: Categorias de Trabalho

Guias Gerais e os Usuários Finais

• O mais alto nível de gerência provavelmente pouco se importa com a tecnologia de computadores. Seria melhor perguntar-lhes sobre o resultado global e performance que os sistemas fornecem. São bons candidatos para entrevistas a respeito de leiautes de relatórios e design de código.

• Os objetivos e prioridades da gerência podem entrar em conflito com os dos supervisores e usuários operacionais. Isto pode ser percebido baseado nos diferentes níveis de preocupações. Como engenheiro de software, tenta-se descobrir áreas comuns. Mais sobre o assunto pode ser visto no capítulo 3 – Engenharia de Requisitos.


JEDITM

• Gerentes podem não fornecer recursos, fundos ou tempo que usuários precisam para construir um sistema efetivo. Restrições financeiras e de recurso irão ocorrer. É importante priorizar os requisitos. Mais sobre isto pode ser visto no capítulo 3 – Engenharia de Requisitos.

Aqueles que estão indiretamente envolvidos

Freqüentemente, este grupo inclui auditores, portadores comuns e grupo de garantia de qualidade. O objetivo geral deste grupo é certificar que o sistema está sendo desenvolvido de acordo com uma variedade de definições como:

• Padrões contábeis desenvolvidas pelas operações de contas da organização ou firma.

• Padrões desenvolvidos por outros departamentos dentro da organização ou pelo cliente ou pelo usuário que irá herdar o sistema

• Vários padrões impostos pelas agências governamentais reguladoras.

Alguns possíveis problemas que podemos encontrar com este grupo. Como engenheiro de software, manter atenção sobre eles e mapeá-los em conformidade.

• Eles não se envolvem no projeto até que se atinja o fim, em particular, o grupo de garantia de qualidade. É importante que eles envolvam-se em todas as atividades que se exija sua experiência e opinião.

• Eles fornecem notação necessária e forma do documento. Eles podem precisar de definição para apresentação e documentação do sistema.

• Eles estão mais interessados em substância do que em formulários.

7.2. Equipe de Desenvolvimento

A equipe de desenvolvimento é responsável pela construção do software que irá dar suporte ao sistema de domínio-específico. Consistem em: analista de sistemas, projetista, programadores e testadores.

Analista de Sistemas

Sua responsabilidade é entender o sistema. Dentro do sistema, ele identifica o que o cliente quer e documenta e prioriza os requisitos. Isto envolve detalhamento do sistema para determinar requisitos específicos que serão a base do projeto de software.

Projetista

Seu trabalho é transformar uma tecnologia livre de arquitetura em uma estrutura interna para que os programadores possam trabalhar. Normalmente, o analista de sistema e o projetista são a mesma pessoa, mas isto é diferenciado pelo foco nas funções e habilidades requeridas.

Programadores

Baseados no projeto do sistema, os programadores escrevem o código do software utilizando uma linguagem de programação.

Testadores

Para cada produto funcional, deve-se realizar uma revisão de modo a encontrar: falhas ou erros. Isto sustenta a cultura de qualidade necessária ao desenvolvimento de software com qualidade. Isto garante que o produto funcional irá de encontro com os requisitos e padrões definidos.


JEDITM

8. Documentação no Esforço de Desenvolvimento

8.1. O que é documentação?

É um conjunto de documentos ou informações do produto que descrevem o sistema. Cada documento é desenhado para executar uma função específica, como:

• REFERÊNCIA, como por exemplo, especificações técnicas ou funcionais.

• INSTRUCIONAL, como por exemplo, tutoriais, demonstrações ou protótipos.

• MOTIVACIONAL, como por exemplo, brochuras, demonstrações ou protótipos.

Há vários tipos de documentação e informações funcionais do produto. Alguns são citados abaixo:

• Características e Funções do Sistema

• Sumário Gerencial e do Usuário

• Manual do Usuário

• Manual de Administração do Sistema

• Vídeo

• Multimídia

• Tutoriais

• Demonstrações

• Guia de Referência

• Guia de Referência Rápida

• Referências Técnicas

• Arquivos de Manutenção do Sistema

• Modelos de Teste do Sistema

• Procedimentos de Conversão

• Manual de Operações/Operador

• Help On-Line

• Wall Charts

• Layout de Teclado ou Templates

• Jornais

Bons documentos não geram sistemas complicados. No entanto, eles podem ajudar de outra forma. A tabela seguinte mostra como a documentação ajuda no processo de desenvolvimento de software.

Se o manual do usuário for desenvolvido durante....

Então, o manual pode...

A definição do produto • Clarear procedimentos e regras• Identificar elementos não amigáveis• Aumentar as chances de satisfação do cliente

O projeto e codificação • Clarear problemas e erros• Identificar causas de inconsistências• Forçar o projetista a tomar decisões mais cedo

A distribuição e uso do sistema • Ajudar os usuários a se adaptarem ao sistema• Alertar sobre problemas no sistema• Negar responsabilidades

Tabela 2: Significância dos Documentos

Existem dois principais propósitos da documentação. Especificamente, eles:

• Fornecem um argumento racional e permanente para a estrutura do sistema ou comportamento através dos manuais de referência, guia do usuário e documentos de arquitetura do sistema.


JEDITM

• Servem como documentos transitórios que são parte de uma infra-estrutura envolvida em uma execução de um projeto real como: cenários, documentação do projeto interno, relatório de reuniões e problemas.

8.2. Critérios para Medição da Usabilidade de Documentos

Um documento útil aumenta o entendimento do sistema solicitado e o atual comportamento e estrutura. Serve como comunicação entre as versões arquiteturais do sistema. Fornece uma descrição de detalhes que não pode ser diretamente inferida a partir do próprio software ou a partir dos produtos funcionais. Alguns critérios para medição da usabilidade dos documentos estão listados abaixo:

1. Disponibilidade. Usuários devem saber da existência dos documentos. Devem estar presentes no momento e local quando for necessário.

2. Adequação. Devem ser adequados às tarefas e interesses do usuário. Devem ser precisos e completos. Documentos relacionados devem estar localizados em um manual ou livro.

3. Acessibilidade. Devem estar em folhas ofício (8.5in x 11in) para fácil manuseio, armazenamento e recuperação. Deve ser fácil encontrar informações que o usuário deseja. Cada item da documentação deve ter um único nome para referência e referência cruzada, um propósito ou objetivo e um usuário alvo (a quem se destina o documento). Encaminhamentos para outros manuais e livros deverão ser evitados.

4. Legibilidade. Devem ser compreensíveis sem explicações adicionais. Não devem possuir abreviações. Se for necessário, devem vir acompanhados de legenda. Devem ser escritos com fluência e em estilo e formatação de fácil leitura.

8.3. Importância dos Documentos e Manuais

Os documentos e manuais são importantes, pois são utilizados:

• Para diminuir custos. Com bons manuais, necessitam-se menos de treinamento, suporte e manutenção do sistema.

• Como ferramentas de venda e marketing. Bons manuais diferenciam seus produtos – um pobre manual significa um pobre produto – especialmente para produtos de software “fora de prateleira”.

• Como entregáveis tangíveis. Gerenciamento e usuários sabem pouco sobre jargões da computação, programas e procedimentos, mas podem encontrar isso no manual do usuário.

• Como obrigações contratuais.

• Como coberturas de segurança. No caso de falta de pessoas, manuais e documentos técnicos servem como backup escrito.

• Como auxílio a teste e implementação. É importante incluir os seguintes itens como parte do manual do usuário – modelos e scripts de teste do sistema, procedimentos burocráticos e automatizados, treinamentos práticos para novos usuários e auxílio a projeto.

• Para comparar sistemas antigos e novos.


JEDITM

9. Exercícios

9.1. Especificação de escopo

1. Modele o escopo do Sistema de Informações Técnicas. Utilize a Figura 10 como guia.

2. Modele o escopo de um Sistema de Manutenção de Equipes e Times. Utilize a Figura 10 como guia.

9.2. Praticando o Walkthrough

1. Revise o escopo do modelo do Sistema de Informações Técnicas através de um walkthrough. Prepare uma lista de ações.

2. Revise o escopo do modelo do Sistema de Manutenção de Equipes & Times através de um walkthrough. Prepare uma lista de ações.

9.3. Trabalho sobre Projeto

O objetivo do trabalho sobre projeto é reforçar o conhecimento e habilidade adquirida nesta lição. Particularmente, são:

1. Definição de Escopo do Sistema

2. Criação de Modelo de Escopo de Sistema

3. Execução de Walkthrough

PRODUTOS:

1. Modelo de Escopo do Sistema

2. Lista de Ações



Lição 2Engenharia de Software Orientada a Objetos


JEDITM

1. Objetivos

Engenharia de Software Orientada a Objetos é o uso de tecnologias de objetos na construção de software. Tecnologia de objetos é um conjunto de princípios que direciona a construção de software usando método orientado a objetos.

Este abrange toda uma estrutura de atividades incluindo análise, desenvolvimento, teste, escolha de metodologias, linguagens de programação, ferramentas, bancos de dados e aplicações para a engenharia de software.

Nesta lição veremos o básico para o entendimento da orientação a objetos através de uma explanação sobre os conceitos fundamentais tais como objetos e classes, abstração, encapsulamento, modularidade e hierarquia. Faremos também uma apresentação geral dos modelos de processos orientados a objetos que seguem uma montagem baseada em componentes. Faremos também uma introdução sobre análise orientada a objetos e atividades de desenvolvimento, listando algumas metodologias, e sobre produtos de trabalho. Finalmente, faremos uma discussão sobre a Linguagem de Modelagem Unificada (UML - Unified Modeling Language) e a atividade de modelagem.


• Entender os conceitos de Orientação a Objetos• Entender os processos gerais de modelagem orientada a objeto• Ver de uma forma geral as atividades de análise e modelagem orientada a objeto• Entender a UML (Unified Modeling Language - Linguagem de Modelagem Unificada) e

entender a atividade de modelagem


JEDITM

2. Revisão dos Conceitos de Orientação a Objetos

Objetos são representações de entidades que podem ser físicas (tal como um clube formado de sócios e atletas), conceituais (time da seleção) ou abstratas (lista encadeada). Isto permite que os engenheiros de software representem os objetos do mundo real no desenvolvimento de software. Tecnicamente falando, eles são definidos como algo que representa um objeto do mundo real que possui limite bem definido e identidade que encapsula estado e comportamento.

Atributos e relacionamentos de um objeto definem o seu estado. Esta é uma das condições possíveis para que um objeto exista, e que normalmente, com o passar do tempo, modificam-se. Em um sistema, os valores armazenados nos atributos e as ligações do objeto com outros objetos definem seu estado. Operações, métodos e máquinas de estado, por outro lado, definem os comportamentos. Estes determinam como um objeto age e reage aos pedidos de mensagem de outros objetos. É importante que cada objeto seja identificado unicamente no sistema mesmo se eles tiverem os mesmos valores de atributos e comportamentos. A Figura 1 mostra um exemplo de objetos com os estados e comportamentos que indica um estudo de caso existente, a Liga Ang Bulilit.

Três objetos estão representados - 2 atletas e 1 técnico. Nesta figura, eles são ilustrados como círculos onde atributos são encontrados no círculo interno cercado por métodos. Objetos são unicamente identificados através dos Identificadores tal como o caso dos dois atletas, Joel e Arjay. Note que os atributos estão envolvidos por métodos. Isto sugere que apenas o objeto pode modificar o valor dos seus atributos. A modificação dos valores dos atributos pode ser gerada através de uma requisição, chamada de mensagem, por outro objeto. Na figura, o técnico (JP) indica um atleta (Joel) para a equipe através da execução do método assignToSquad(). Este método envia uma mensagem de requisição, updateSquad("Treinando"), para o atleta (Joel) atualizando o valor do seu atributo squad.

Uma classe é uma descrição de um conjunto de objetos que compartilham os mesmos atributos, relacionamentos, métodos, operações e semântica. Esta é uma abstração que se concentra nas características relevantes de todos os objetos enquanto descartamos outras características. Objetos são instâncias de classes. Neste exemplo, Joel e Arjay são instâncias da classe atletas, enquanto JP é uma instância da classe técnico.

Figura 1: Exemplo de Aplicação de Objetos do Clube de Sócios e Atletas


submitApplication()

updateSquad()

AthleteID:3556Name: Joel Santos

Status: NEWSquad: None

submitApplication()

updateSquad()

AthleteID:3557Name: Arjay Solamo

Status: NEWSquad: None

assignToSquad()

updateSport()

CoachID:9786Name: JP PetinesSport: Basketball

updateSquad("Treinando")

ATRIBUTOS

MENSAGEM

MÉTODOS

JEDITM

Quatro princípios básicos estão genericamente associados com orientação a objetos os quais são abstração, encapsulamento, modularidade e hierarquia. Estes conceitos estão inter-relacionados e cooperam entre si.

Abstração

Abstração está definida como uma características essencial de uma entidade que distingue esta de todas as outras espécies de entidades1. Este é um tipo de representação que inclui apenas as coisas que são importantes ou interessantes de um ponto de vista particular. Este é um domínio e dependente da perspectiva, ou seja, o que é importante em um contexto e que pode não necessariamente ser em outro. Isto nos permite gerenciar a complexidade do sistema nos concentrando apenas nas características que são essenciais ou importantes para o sistema, e ignoramos ou descartamos as características que não são neste momento. Objetos são representados através dessas características que são consideradas relevantes para o propósito em questão, e são desconsideradas as características que não são.

Exemplos de abstração incluídos neste estudo de caso são:

• Um candidato apresentar-se no clube da associação para entrar na equipe.• A equipe do clube agenda um evento para treinamentos.• O técnico indica um atleta para a seleção.• A seleção pode estar treinando ou competindo.• Times são formados a partir de uma seleção.

Encapsulamento

Encapsulamento é também conhecido como ocultação de informação. São características embutidas dentro de uma caixa-preta abstrata que oculta a implementação destas características atrás de uma interface. Isto permite que outros objetos interajam com ele sem ter conhecimento de como a implementação realiza a interface. Esta interação é realizada através das mensagens de interface do objeto. Esta interface é um conjunto pré-definido de operações utilizadas por outros objetos que se comunicam com ele. Isto garante que os dados e os atributos do objetos são acessíveis através das operações do objeto. Nenhum outro objeto pode acessar diretamente estes atributos e alterar seus valores.

Considere a interação entre os objetos na Figura 1 onde o treinador (JP) associa um atleta (Joel) a um time. updateSquad() é uma mensagem da interface que altera o valor do atributo time do atleta (Joel). Observe que a alteração somente ocorrerá quando o treinador (JP) executa assignToSquad() que dispara uma requisição a updateSquad(“Treinamento”) do atributo do time de (Joel). O treinador (JP) não precisa saber como o atleta (Joel) atualiza seu time mas ele assegura-se que o método é executado.

O encapsulamento reduz o efeito dominó que as mudanças podem causar nos programas, onde a alteração na implementação de um objeto pode causar alterações em outros objetos e assim por diante. Com o encapsulamento, a implementação de um objeto pode ser alterada sem mudar a implementação de outros objetos uma vez que a interface permanece inalterada. Logo, o encapsulamento oferece dois tipos de proteção de objetos: proteção contra corrupção do seu estado interno e proteção contra alteração de código quando a implementação de outro objeto é alterada.

Modularidade

Modularidade é uma decomposição física e lógica de coisas grandes e complexas em componentes pequenos e fáceis de gerenciar. Estes componentes podem ser desenvolvidos independentemente bem como suas interações serem bem compreendidas. O conceito de pacotes, subsistemas e componentes em orientação a objetos comporta modularidade. Eles serão melhor explicados em seções à frente nesta lição.

A modularidade, como abstração, é outro caminho de gerenciar a complexidade. Isto por que ela

1 Object-oriented Analysis and Design using the UML, Student's Manual , (Cupertino, CA: Rational software Corporation, 2000), p. 2-15


JEDITM

quebra algo que é grande é complexo em componentes pequenos e gerenciáveis, isto facilita a tarefa do engenheiro de software de gerenciar e desenvolver software através da gerência e desenvolvimento destes pequenos componentes para, então, iterativamente integrá-los.

Por exemplo, o caso de estudo "Liga Ang Bulilit" pode ser dividido em subsistemas menores como mostra a Figura 2.

Figura 2: Subsistemas da Liga Ang Bulilit

Generalização é uma forma de associação onde uma classe compartilha a estrutura e/ou o comportamento com uma ou mais classes. Ela define a hierarquia das abstrações nas quais a subclasse herda de uma ou mais superclasses. É um tipo de relacionamento.

Herança é o mecanismo pelo qual elementos mais específicos incorporam a estrutura e o comportamento de elementos mais gerais. Uma subclasse herda atributos, operações e relacionamentos de uma superclasse. A Figura 3 mostra a superclasse Seleção que será herdada pelas subclasses Treinamento e Competição.

Figura 3: Hierarquia de Esquadras Elaboradas

Polimorfismo é a habilidade de esconder diversas implementações diferentes debaixo da mesma interface. Ele possibilita que a mesma mensagem seja tratada por diferentes objetos. Considere as classes definidas na Figura 5 que serão usadas para discutirmos o polimorfismo. A superclasse Pessoa possui duas subclasses Estudante e Empregado.


Liga Ang BulilitSistema de Times e Seleções

Sistema deManutenção dosSócios do Clube

Sist. Manutençãodas Informações

do Treinador

Sistema deManutenção de

Times e Seleções

Seleção

NomeListaDeMembros

listarMembros()mudarTécnico()

Treinamento Competição

JEDITM

Figura 4: Exemplo de Polimorfismo

Em Java, considere a classe abaixo para implementar esta estrutura.

public class Pessoa { String nome; public String obterNome(){ System.out.println("Nome da Pessoa:" + nome); return nome; }}public class Estudante extends Pessoa { public String obterNome(){ System.out.println("Nome do Estudante:" + nome); return nome; }}public class Empregado extends Pessoa { public String obterNome() { System.out.println("Nome do Empregado:" + nome); return nome; }}

Observe que tanto Estudante como Empregado possuem implementações diferentes do método obterNome(). Considere no seguinte método principal onde o atributo ref é uma referência para a classe Pessoa. A primeira vez que o método ref.obterNome() for chamado, executará a versão de Estudante já que a referência está apontada a este objeto. A segunda vez que o método ref.obterNome() for chamado, executará o método de Empregado pois agora a referência aponta para este objeto.

public static main(String[] args) { Pessoa ref; Estudante objetoEstudante = new Estudante(); objetoEstudante.nome = "aluno"; Empregado objetoEmpregado = new Empregado(); objetoEmpregado.nome = "colaborador"; ref = objetoEstudante; // Referência de Pessoa aponta ao objetoEstudante String temp = ref.obterNome(); // o método obterNome da classe // Estudante é chamado System.out.println(temp); ref = objetoEmpregado; // Referência de Pessoa aponta ao objetoEmpregado temp = ref.obterNome(); // o método obterNome da classe Empregado é chamado System.out.println(temp);}

Agregação é um tipo especial de relação entre duas classes. É um modelo de relacionamento parte-todo entre um agregado (todo) e suas partes. A Figura 5 mostra um exemplo de agregação. Aqui, a equipe é composta de atletas.

Figura 5: Agregação de Equipe


Pessoa

Estudante Empregado

Equipe Atletas

JEDITM

3. Modelo de Processo Orientado a Objetos

A orientação a objeto abordada em desenvolvimento de software segue como base o Processo Modelo; move-se através de um trajeto espiral evolucionário; é naturalmente iterativo, e suporta reusabilidade; focaliza no uso de uma arquitetura centrada se identificando com a base da arquitetura do software.

A Arquitetura de Software define toda estrutura do software; os modos como a estrutura provê integridade conceitual de um sistema. Envolve tomar decisões de como o software é construído, e, normalmente, controla o desenvolvimento iterativo e incremental do sistema.

Para administrar o modo de desenvolvimento em uma arquitetura centrada, um mecanismo para organizar os produtos do trabalho é usado. É chamado pacote. Um pacote é um elemento modelo que pode conter outros elementos modelo. Permite-nos modularizar o desenvolvimento do software, e serve como uma unidade de gerenciamento de configuração.

Um subsistema é uma combinação de pacotes (pode conter outros elementos modelo), e uma classe (possui um comportamento). Permite definir os subsistemas do software. É realizado por uma ou mais interfaces que definem o comportamento do sistema.

Um componente é uma parte substituível e quase independente de um sistema que cumpre uma função clara no contexto de uma arquitetura bem definida. Pode ser um código fonte, código em tempo de execução ou um código executável. É uma realização física de um projeto abstrato. Os subsistemas podem ser usados para representar componentes no projeto; um modelo de um subsistema e de componente é mostrado na figura 6.

Figura 6: Subsistemas e Modelo de Componente


<<subsystem>>Nome do Componente

Interface doComponente

JEDITM

4. Análise e Projeto Orientado a Objeto

Duas importantes estruturas de atividades em qualquer processo de desenvolvimento de software são: a Análise do Sistema e o Projeto do Software. Esta seção discute brevemente a Análise e as fases do projeto de orientação a objeto. A abordagem será expandida mais tarde no decorrer dos capítulos.

4.1. Análise Orientada a Objeto

O objetivo principal da Análise Orientada a Objeto é desenvolver uma série de modelos que descrevam como o software de computador trabalhará para satisfazer um conjunto de requisitos definidos pelo cliente. A intenção é definir um conjunto de classes, suas relações e comportamentos que são relevantes para o sistema que está sendo estudado; desde que os requisitos do cliente influenciem a criação dos modelos, esta fase também é conhecida como engenharia de requisitos.

Dois modelos maiores são desenvolvidos durante esta fase, o modelo de requisitos e o modelo de análise. Ambos descrevem a informação, a função e o comportamento dentro do contexto do sistema, e são modelados como classes e objetos.

Existem cinco princípios básicos de análise aplicados nesta fase.

1. Domínio de informações é modelado. O sistema é analisado em busca de dados importantes que são necessários dentro do sistema.

2. Função de módulo é descrita. O sistema é analisado para identificar funções importantes que definem o que precisa ser feito dentro do sistema.

3. Comportamento modelo é representado. Usando os dados e funções importantes, o comportamento do sistema é analisado para entender sua dinâmica natural. Isto também inclui suas interações com seu ambiente.

4. Modelos divididos para expor maiores detalhes. Os elementos modelo são refinados e redefinidos para mostrar os detalhes que conduzirão ao projeto do software.

5. Primeiros modelos representam a essência do problema, embora mais tarde forneçam detalhes de implementação. O desenvolvimento iterativo dos modelos deve facilitar um plano de transição para a fase de projeto.

4.1.1. Metodologias de Análise Orientadas a Objeto

Existem vários métodos que são usados em Análise de Orientação a Objeto; eles estão listados brevemente abaixo.

1. Método de Booch. Este método abrange ambos "processo de desenvolvimento micro" e um "processo de desenvolvimento macro".

2. Método de Coad e Yourdon. Este é freqüentemente visto como um dos mais fáceis métodos de análise de orientação a objeto para aprender.

3. Método de Jacobson. Este método também é conhecido como Engenharia de Software de Orientação a Objeto. É diferenciado de outros por ênfase pesada no caso de uso.

4. Método de Rambaugh. Também conhecido como a Técnica de Modelagem de Objeto que cria três modelos, modelo objeto, modelo dinâmico e um modelo funcional.

5. Método de Wirfs-Brock. Não faz uma distinção clara entre análise e tarefas de projeto. É um processo contínuo que começa com a avaliação da especificação do cliente e termina com um projeto proposto.

Todos estes métodos seguem um conjunto comum de etapas para analisar um sistema. Cada uma destas etapas elaboradas indica o modo de como que os produtos do trabalho são desenvolvidos no capítulo de engenharia de requisitos.

ETAPA 1. Identifique os requisitos do cliente para o sistema orientado a objeto. Exige identificação de casos de uso ou cenários, e construção dos modelos de requisitos.


JEDITM

ETAPA 2. Selecionar classes e objetos usando os requisitos modelo como a diretriz.

ETAPA 3. Identificar atributos e operações para cada uma das classes.

ETAPA 4. Definir estruturas e hierarquias que organizarão as classes.

ETAPA 5. Construir uma relação de objeto modelo.

ETAPA 6. Construir um comportamento de objeto modelo.

ETAPA 7. Revisar na Análise modelo de Orientação a Objeto os requisitos e estruturas.

4.1.2. Análise Principal de Produtos de Trabalho Orientadas a objeto

Dois modelos principais são desenvolvidos durante esta fase do processo de desenvolvimento de software. Eles são os Modelo de Requisitos e Modelo de Análise. Seu desenvolvimento será elaborado no capítulo de Engenharia de Requisitos.

1. Requisitos Modelo. É um modelo que se empenha em descrever o sistema e seu ambiente. Consistem em um caso de uso modelo (diagramas de caso de uso e especificações), documentos e glossário adicional.

2. Análise Modelo. É o mais importante modelo para ser desenvolvido nesta fase porque serve como uma fundação para o desenvolvimento do software necessário para sustentar o sistema. Consiste em um objeto modelo (diagramas de classe) e comportamento modelo (diagramas de seqüência e de colaboração).

4.2. Projeto Orientado a Objeto

O objetivo da fase Projeto Orientado a Objetos é transformar o modelo de análise num modelo de análise orientado a objeto, que serve como um projeto para construção do software. Ele descreve a organização específica dos dados através da especificação e redefinição dos atributos, e também define os detalhes procedimentais das operações das classes. Como na análise, existem cinco princípios-guia de projeto que podem ser aplicados nesta fase.

1. Unidades lingüísticas modulares

2. Algumas interfaces

3. Pequenas interfaces e baixo acoplamento

4. Interface explícita

5. Encapsulamento de Informações

4.2.1. Metodologias de Projeto Orientado a Objeto

Existem vários métodos que são utilizados no projeto orientado a objeto, e eles correspondem às metodologias que foram enumeradas na metodologia de análise orientada a objeto. Elas são descritas abaixo.

1. Método Booch. Similar a sua metodologia de análise, envolve um processo de “micro-desenvolvimento” e um processo de "macro-desenvolvimento".

2. Método Coad e Yourdon. Refere-se não somente a aplicação, mas também a infra-estrutura da aplicação.

3. Método Jacobson. Enfatiza a rastreabilidade do modelo de análise da Engenharia de Software Orientado a Objetos.

4. Método Rambaugh. Inclui uma atividade de projeto que utiliza dois níveis diferentes de abstração. São eles: o projeto de sistema, que tem foco no layout dos componentes necessários para completar o produto, e o projeto de objetos, que tem foco no layout detalhado dos objetos.

5. Método Wirfs-Brock. Define tarefas contínuas na qual a análise leva diretamente ao projeto.


JEDITM

Todas estas metodologias têm um conjunto de passos comuns que são realizados no projeto. Em cada um destes passos são elaborados produtos que são produzidos no capítulo Engenharia de Projetos.

PASSO 1. Definir os subsistemas de software através da definição dos subsistemas relacionados (projeto de entidades), subsistema de controle (projeto de controladores) e subsistemas de interação humana (projeto de fronteiras). Estes passos devem ser guiados baseados na arquitetura escolhida.

PASSO 2. Definir os Projetos de Classes e Objetos.

PASSO 3. Definir o Projeto para Troca de Mensagens.

4.2.2. Principais produtos de um Projeto Orientado a Objetos

Existem diversos produtos que são desenvolvidos durante esta fase. Eles são brevemente descritos abaixo. No geral, são chamados de Modelo de Projeto. O desenvolvimento destes produtos será elaborado no capítulo de Engenharia de Projeto.

1. Arquitetura de Software. Refere-se à estrutura geral do software. Inclui também as formas nas qual a estrutura fornece integridade conceitual para um sistema. É modelada utilizando diagramas de pacotes.

2. Projeto de Dados. Refere-se ao projeto e à organização dos dados. Inclui projeto de código para acesso aos dados e projeto de banco de dados. Utiliza diagramas de classes e diagramas de seqüência.

3. Projeto de Interface. Refere-se ao projeto de interação do sistema com seu ambiente, particularmente os aspectos de interação humana. Inclui os projetos de interface visual. Os formatos de relatórios e formulários são também incluídos. Utiliza diagramas de classe e diagramas de transição de estado.

4. Projeto de Componentes. Refere-se à elaboração e projeto de classes de controle. Este é o projeto mais importante por que os requisitos funcionais são representados através das classes de controle. Utilizam diagramas de classe, diagramas de atividade e diagramas de transição de estado.

5. Projeto de Distribuição. Refere-se ao projeto de como o software será distribuído para uso operacional. Utiliza o diagrama de distribuição.


JEDITM

5. Linguagem de Modelagem Unificada (UML)

A Linguagem de Modelagem Unificada (UML) é uma linguagem padrão para especificar, visualizar, construir e documentar todos os produtos de trabalho ou artefatos de sistemas de software. Antigamente a UML possuia terminologias diferentes conforme mostrado na Tabela 1.

UML Classes Associação Generalização Agregação

Booch Classe Uso Heranças Conteúdo

Coad Classe & Objeto Exemplode Conexão

Especificação-Geral

Parte-completa

Jacobson Objeto Associaçãode Conhecimento

Heranças Consistir de

Odell Tipo do Objeto Relacionamento Subtipo Composição

Rambaugh Classe Associação Generalização Agregação

Shlaer/Mellor Objeto Relacionamento Subtipo n/a

Tabela 1: Diferentes terminologias da UML

Entretanto, a notação foi unificada por Booch, Rambaugh e Jacobson. A OMG (Object Management Group) é um grupo que mantém um conjunto de padrões que define a utilização da UML, realizando uma padronização técnica dos modelos de projeto. Atualmente, outros participantes colaboram com esta padronização e definição da UML.

UML não é um método ou metodologia. Não é indicada para um processo particular. Não é uma linguagem de programação. É basicamente um padrão de ferramentas de modelagem usado por desenvolvedores em seus trabalhos de software, como foi mostrado nos modelos.

5.1. Modelando a Atividade

O desenvolvimento do software é uma atividade complexa e é extremamente difícil realizar a tarefa necessária se todos os detalhes não estiverem em um único local. Em qualquer projeto de desenvolvimento, o objetivo é produzir produtos úteis do trabalho, o foco principal de atividades da análise do projeto está em modelos. Um modelo é um teste padrão de algo a ser criado. Ele é abstrato e visível. O software não é tangível para os usuários e por sua natureza, é abstrato. Entretanto, é construído por uma equipe que precisa de cada modelo descrito.

Um modelo é uma representação de algo no mundo real. Particularmente, são:

• Mais rápidos de se construir e representam os objetos reais.• São usados na simulação para entender melhor o que representam. • Podem ser modificados conforme uma tarefa ou um problema.• Utilizado para representar melhor os detalhes dos modelos selecionados e para examinar os

que foram rejeitados; é basicamente uma abstração dos objetos reais.

Um modelo útil tem uma determina quantidade de detalhe e de estruturas, mostra claramente o que é importante para uma determinada atividade. Geralmente, os desenvolvedores modelam a situação complexa dentro de um sistema de atividade humana. Devem modelar somente as partes que são importantes ao invés de refletir toda a situação. Por esta razão, necessitam ser ricos em detalhes sobre a parte tratada. Os modelos da fase de análise (modelos de análise de requisitos), devem ser exatos, completos e sem ambigüidades. Sem isto, o trabalho da equipe do desenvolvimento será muito mais difícil. Ao mesmo tempo, não deve incluir decisões prematuras sobre como o sistema será construído para atender as exigências do usuário. Caso contrário, a


JEDITM

equipe de desenvolvimento pode, mais tarde, achar que suas ações são controladas. A maioria dos modelos está no formato de diagramas que podem ser acompanhados por descrições textuais, lógicas, processos de especificações matemáticas ou de dados.

Analistas de sistemas e gerentes de projetos usam diagramas para criar modelos de sistemas. Os diagramas são usados amplamente para:

• entender a estrutura de objetos e seus relacionamentos.

• compartilhamento de plano com outros

• solicitação de planos e novas possibilidades

• testes de planos e construir prognósticos

Aqui se encontram as várias técnicas de modelagem que podem ser encontradas. Algumas regras gerais são listados abaixo. Modelagem técnicas deve ser:

• Únicas. Mostrar somente o que precisa ser mostrado.

• Internamente compatível. Os diagramas devem suportar ao outro.

• Completo. Mostrar tudo aquilo que precisa ser mostrado.

• Representados hierarquicamente. Dividindo o sistema em componentes menores. Em seguida, mostrar os detalhes de sub-níveis.

A UML fornece um conjunto de diagramas usados para modelar sistemas. Os diagramas são representados por quatro elementos principais.

• Símbolos. Representam as figuras descritas nos diagramas. São figuras abstratas e podem ser conectados com outros símbolos (por exemplo, uma classe é representada por um retângulo).

• Símbolos bidimensionais. São similares aos símbolos exceto que têm os compartimentos que podem conter outros símbolos, símbolos ou cadeias. Um símbolo não possui outros símbolos.

• Caminhos. Representam uma ligação de um símbolo a outro. Normalmente representam um fluxo de dados.

• Cadeias. São usadas para representar descrições, nomes, entre outros dados textuais, nos símbolos ou caminhos.

A especificação de UML fornece uma definição formal de como usar diagramas de UML. Fornece a gramática de UML (sintaxe) que inclui o significado dos elementos e as regras de como os elementos são combinados (semântica).

Um único diagrama ilustra ou documenta um determinado aspecto de um sistema. Um modelo, que sendo utilizado por outra pessoa, fornece uma visão completa do sistema em um determinado estágio e perspectiva. Por exemplo, os modelos desenvolvidos durante a fase de análise dão uma visão completa do sistema através do domínio do problema.

Capturar essencialmente o aspecto do sistema tais como funções, dados, entre outros. Consiste em diversos diagramas para a segurança de que todos os aspectos do domínio do problema estão contemplados. Os modelos, desenvolvidos durante a fase do projeto, dão uma visão completa do sistema a ser construído. É uma visão do domínio da solução provê a possibilidade de transformar os diagramas em componentes do sistema tais como, projetos de diálogo para as janelas de interação com o usuário, os elementos da base de dados para as funções de controle e deste modo continuamente.

Os modelos que são produzidos durante o desenvolvimento do projeto modificam durante o desenvolvimento do mesmo. Normalmente, são dinâmicos em determinados aspectos:

• Nível de Abstração. Conforme o projeto se desenvolve, o modelo usado vai para um estágio menos abstrato e mais concreto. Por exemplo, é possível começar com classes que representam o tipo dos objetos que encontraremos no sistema tal como atletas, ônibus, seleção e equipe. Com o tempo, do começo ao fim do projeto, se pode definir para as classes


JEDITM

os atributos e as operações. As classes também devem suportar classes adicionais tais como corretores, que representarão a plataforma de distribuição do objetivo.

• Grau de Formalidade. O grau de formalidade com que as operações, os atributos e as restrições são definidos com o desenvolvimento do projeto. Inicialmente, os atributos são classificados e podem ser facilmente definidos usando o português estruturado ou qualquer outra língua utilizada pela equipe de desenvolvimento. Com o tempo, chega o fim do projeto e inicia-se a fase de implementação. Atributos e operações são definidas utilizando a linguagem de programação escolhida, neste caso Java. Por exemplo, na fase de análise, uma usa-se “Athlet” como o nome da classe que conterá as informações dos atletas. Na fase do projeto, pode ser uma classe persistente que captura a informação sobre detalhes de um atleta e ser nomeado como classe, “DBAthlet”.

• Nível de detalhamento. Enquanto o projeto progride, os diferentes modelos representam a mesma visão mas mostram um nível mais aprofundado de detalhamento. Os modelos ficam mais detalhados ao se avançar no processo de desenvolvimento. Por exemplo, o primeiro diagrama caso de uso pode mostrar somente os diagramas de Casos de Uso óbvios são aparentes em uma primeira visão. Na segunda visão, o diagrama de Caso de Uso pode ser elaborado com maiores detalhes, e Casos de Uso adicionais podem surgir. Após a terceira visão no projeto, pode-se incluir uma descrição mais elaborada na qual os usuários interagem com os novos Casos de Uso e com os relacionamentos de outros Casos de Uso.

Todas as fases de um projeto consistem em um número de visões, e esse número dependerá da complexidade do sistema que está sendo tomado. Enquanto o projeto progride, o nível do abstração, o grau de formalidade e o nível do detalhamento devem ser estabelecidos corretamente de modo que os trabalhos estejam corretamente modelados.


JEDITM

6. Diagramas Básicos em UML

Existem nove diagramas que são especificados na UML. Eles são brevemente discutidos nesta seção. Os seus usos serão apresentados em detalhes posteriormente assim que os produtos sejam produzidos durante as fases do processo de desenvolvimento.

6.1. Diagrama de Caso de Uso

Fornece a base da comunicação entre usuários finais e desenvolvedores no planejamento do projeto de software. Ele captura as funções na visão do usuário que podem ser pequenas ou grandes. Ele alcança um objetivo particular para o usuário. Ele tenta modelar o sistema mostrando os atores externos e suas conexões com a funcionalidade do sistema. A figura seguinte mostra um exemplo de Diagrama de Caso de Uso.

Figura 7: Exemplo de Diagrama de Caso de Uso

6.2. Diagrama de Classe

Mostra a estrutura estática do domínio das abstrações (classes) do sistema. Ele descreve os tipos de objetos no sistema e os vários tipos de relacionamentos estáticos que existem entre eles. Mostra os atributos e operações de uma classe e checa a maneira com que os objetos colaboram entre si.

Esta ferramenta de modelagem produz o diagrama mais importante do sistema, pois é usado para modelar um entendimento do domínio da aplicação (essencialmente parte do sistema de atividades humanas), e os objetos também são entendidos como partes do sistema resultante. A figura seguinte mostra um exemplo de diagrama de classe.


JEDITM

Figura 8: Exemplo de Diagrama de Classe

6.3. Diagrama de Pacote

Mostra a divisão de sistemas grandes em agrupamentos lógicos de pequenos subsistemas. Ele mostra agrupamentos de classes e dependências entre elas. Uma dependência existe entre dois elementos se mudanças na definição de um elemento pode causar mudanças em outros elementos. A figura seguinte mostra um exemplo de diagrama de pacote.

Figura 9 Exemplo de Diagrama de Pacote

6.4. Diagrama de Atividade

Mostra o fluxo seqüencial das atividades. É usado tipicamente para indicar o comportamento da operação, fluxo de eventos ou a trilha de evento do Caso de Uso. Complementa o diagrama de


JEDITM

Caso de Uso , mostrando o fluxo de trabalho do método. Ele encoraja a descoberta de processos paralelos, ajudando assim a eliminar seqüências desnecessárias no processo do método. Complementa o diagrama de classe por mostrar o fluxo de cada uma das operações (similar ao mapa de fluxo). A figura seguinte mostra um exemplo de um diagrama de atividade.

Figura 10 Exemplo de Diagrama de Atividade

6.5. Diagrama de Seqüência

Indica o comportamento dinâmico colaborativo entre objetos para a seqüência de mensagem enviada entre eles, em uma seqüência de tempo. A seqüência de tempo é mais fácil de visualizar em um diagrama de seqüência, do topo até a base. Escolha o diagrama de seqüência quando a seqüência de operações necessita ser mostrada. A figura 11 mostra um exemplo de diagrama de seqüência.

Figura 11 Exemplo de Diagrama de Seqüência


JEDITM

6.6. Diagrama de Colaboração

Indica os objetos reais e as ligações que representam as “redes de objetos” que estão colaborando. A seqüência de tempo é indicada pela numeração do índice da mensagem das ligações entre os objetos. O diagrama de colaboração é mais apropriado quando os objetos e suas ligações facilitam o entendimento da interação entre os objetos, e a seqüência de tempo não é importante. A figura seguinte mostra um exemplo de diagrama de colaboração.

Figura 12: Exemplo de Diagrama de Colaboração

6.7. Diagrama de Estado

Mostra todos os possíveis estados que objetos da classe podem assumir e quais eventos causaram sua mudança. Mostra como os estados dos objetos mudam de acordo com o resultado de eventos que são controlados pelo objeto. Bom para ser usado quando uma classe tem comportamento de ciclo de vida complexo. A figura seguinte mostra um exemplo do diagrama de estado.

Figura 13: Exemplo de Diagrama de Estado


JEDITM

6.8. Diagrama de Componentes

Mostra os componentes do software em termos de códigos fonte, códigos binários, ligação de bibliotecas dinâmicas etc. A figura 14 é um exemplo de diagrama de componentes.

Figura 14: Amostra do diagrama de componentes

6.9. Diagrama de Implementação

Mostra a arquitetura física do hardware e de software do sistema. Ele realça a relação física entre software e componentes de hardware no sistema. Componentes no diagrama tipicamente representam os módulos físicos de código e correspondem exatamente ao diagrama de pacotes. A figura seguinte é um exemplo do Diagrama de Implementação.

Figura 15: Amostra do Diagrama de Implementação

6.10. Criando um projeto UML utilizando o NetBeans

O módulo de UML está disponível com o NetBeans Update Center (tools – Update Center).

Figura 16: Update Center Wizard do NetBeans

Após instalado este módulo, para criar um projeto UML, siga os seguintes passos:

1. Ao acessar File | New Project para criar um novo projeto, uma nova categoria UML será


JEDITM

mostrada.

Figura 17: Categoria UML na Janela New Project

● Platform-Independent Model – Utilizado exclusivamente para modelos UML, sem relacionamento com a linguagem.

● Java-Platform Model – Regras de negócio são aplicadas em linguagem Java.

● Reverse Engineer a Java Project – Transforma um projeto feito em Java no modelo de classe UML, este projeto deve estar disponível na palheta Project do NetBeans.

2. Conheça e teste todas as opções disponíveis. Utilizaremos a opção Java-Platform Model. Ao ser pressionado o botão Next, a janela seguinte irá solicitar o nome do projeto, a localização do projeto e a pasta do projeto. Pressionando o botão Finish a seguinte janela será mostrada.

Figura 18: Criação de um novo diagrama

O projeto solicita a criação de um dos oito diagramas (atividades, classe, colaboração, componente, desenvolvimento, seqüência, estado e caso de uso) para o início do projeto, selecionaremos Class Diagram. Informaremos ClasseSistema ao nome do diagrama (Diagram Name) e em seguida pressionaremos o botão Finish e o projeto será criado.

3. A janela de projeto conterá os seguintes arquivos conforme a seguinte figura:


JEDITM

Figura 19: Janela Projects

4. Para criar uma nova classe, pressione o botão direito do mouse sobre o projeto (UMLProject1) e selecione a opção Add | Element e será mostrada a seguinte janela:

Figura 20: Janela New Element Wizard

Selecionamos Class, para Element Name modificaremos para Funcionario e em seguida pressionamos o botão Finish.

5. Na pasta Model o novo elemento será criado, arraste com o botão do mouse para a área de trabalho e obteremos a figura descrita abaixo.

Figura 21: Área de trabalho no NetBeans


JEDITM

6. Para adicionar atributos a classe Funcionario, pressione o botão direito do mouse em cima do elemento (na área de Projects | Model | Funcionario) e selecione Add | Attribute (para novos métodos selecione Add | Operation) ou pressione Alt + Shift + A (para métodos Alt + Shift + O) selecionando a figura que representa a classe Funcionario.

7. Pressione um duplo clique sobre o atributo para alterar as propriedades deste, a janela Properties (no canto inferior direito) permite uma alteração mais refinada (se o atributo for estático por exemplo).

8. O último passo, após tudo pronto é a geração dos códigos fontes em Java. Selecione a classe Funcionario, pressione o botão direito do mouse e selecione a opção Generate Code... e como resultado teremos a seguinte classe.

public class Funcionario { private String nome; private double salario; public Funcionario() { } public String getNome() { return nome; } public void setNome(String val) { this.nome = val; } public double getSalario() { return salario; } public void setSalario(double val) { this.salario = val; }}



Lição 3Engenharia de Requisitos


JEDITM

1. Objetivos

Projetar e construir um sistema de computador é desafiante, criativo e simplesmente divertido e prazeroso. Entretanto, desenvolver um bom programa que resolva o problema errado, não serve a ninguém. É importante compreender as necessidades e requisitos do usuário, de modo que resolvamos o problema correto e construamos o sistema correto.

Neste capítulo, discutiremos os conceitos e as dinâmicas da engenharia de requisitos. É uma fase de desenvolvimento de programa que consiste em sete tarefas ou atividades distintas que tem a meta de compreender e documentar os requisitos da parte interessada. Dois modelos importantes serão construídos: modelo de requisitos, que é o modelo de domínio de sistema ou problema e o modelo de análise, que serve como o modelo de base do programa (modelo de solução). A Matriz de Requisitos Rastreáveis (RTM, sigla em inglês para Requirement Traceability Matrix) será introduzida para ajudar os engenheiros de programa a administrar os requisitos e, também, as métricas de requisitos e seus significados serão discutidos.


• Aprender os conceitos e dinâmicas da engenharia de requisitos• Aprender como construir o modelo de requisitos• Aprender como construir o modelo de análise• Aprender como manter a trilha dos requisitos usando a Matriz de Rastreabilidade de

Requisitos (MRR)• Aprender as métricas de requisitos e seus significados


JEDITM

2. Conceitos de Engenharia de Requisitos

Engenharia de Requisitos permite que os desenvolvedores de programas compreendam o problema que estão resolvendo. Abrange um conjunto de tarefas que conduzem a uma compreensão do impacto do negócio que o programa deverá ter, o que o cliente deseja e como o usuário final interagirá com o programa. Provê um mecanismo apropriado para as necessidades de compreensão da parte interessada, analisando requisitos, determinando viabilidade, negociando uma solução razoável, especificando as soluções claramente, validando especificação e administrando requisitos como eles são transformados em um sistema.

Significado para o Cliente, Usuários finais, Time de Desenvolvimento de Programa e às outras Partes Interessadas

Engenharia de Requisitos fornece o contrato básico entre usuários finais e desenvolvedores, sobre o que o programa deve fazer. É uma instrução clara quanto ao escopo e aos limites do sistema a ser analisado e estudado. Fornece às partes interessadas uma oportunidade de definir seus requisitos compreensíveis à equipe de desenvolvimento. Isto pode ser obtido por diferentes documentos, artefatos ou produtos de trabalho, tais como: modelos de caso de uso, modelos de análise, características e lista de funções, cenários de usuário etc.

Projetando e construindo um programa de computador elegante que resolve o problema errado é um desperdício. Esta é a razão porque é importante compreender o que o cliente quer, antes de começar a projetar e construir um sistema baseado em computador. A engenharia de requisitos constrói uma ponte entre o projeto e a construção. Permite ao time de desenvolvimento de programa examinar:

• o contexto de trabalho do programa a ser executado

• as necessidades específicas que o projeto e a construção devem suprir

• as prioridades que guiam a ordem na qual o trabalho será completado

• os dados, funções e comportamentos que terão um impacto profundo no projeto resultante

Engenharia de requisitos é uma outra parte da engenharia de software, deve ser adaptada de acordo com as necessidades do processo, projeto, produto e pessoas que estão trabalhando. Esta é uma atividade que é iniciada a partir da concepção do modelo de software e que pode ser utilizada na fase de desenho e construção.


JEDITM

3. Tarefa de Engenharia de Requisitos

São sete tarefas distintas para a Engenharia de Requisitos a saber: concepção1, elucidação2, elaboração, negociação, especificação, validação e negociação. É importante manter em mente que estas tarefas podem ocorrer em paralelo e todas são adaptadas às necessidades do projeto. Todas objetivam definir o que o cliente deseja e servem para estabelecer uma fundamentação sólida para o design e a construção das necessidades do cliente.

3.1. Concepção

Em geral, a maioria dos projetos de software iniciam quando há um problema a ser resolvido ou uma oportunidade identificada. Como exemplo, considere que um negócio descubra uma necessidade ou um novo mercado ou um potencial serviço. Na concepção, o escopo do problema e sua natureza são definidos. Engenharia de Software faz um conjunto de perguntas livres de contexto com a intenção de estabelecer uma compreensão básica do problema, o que as pessoas querem de solução, a natureza da solução e a eficiência da compreensão preliminar e a colaboração entre o usuário final e o desenvolvedor.

Iniciando a Engenharia de Requisitos

Desde a investigação preliminar do problema, uma aproximação ou entrevista com P&R (perguntas e respostas) é uma técnica apropriada para entender o problema e sua natureza. Enumeramos a abaixo alguns passos recomendados para iniciar a fase de requisitos.

Passo 1: Identificar as partes interessadas

Uma parte interessada é qualquer um que se beneficie direta ou indiretamente do sistema que está sendo desenvolvido. O gerente de operações de negócio, o gerente de produtos, as pessoas de marketing, clientes internos e externos, usuários finais e outras pessoas comuns para entrevistar. É importante, nesta etapa, criar uma lista de pessoas que contribuem com a entrada de requisitos. A lista dos usuários crescerá com mais ou menos pessoas que começam a se envolver na elucidação.

Passo 2: Reconhecimento de múltiplos pontos de vista

É importante recordar que diferentes partes interessadas tem uma visão diferente do sistema. Cada um obtém diferentes benefícios quando o sistema é um sucesso; cada um corre diferentes riscos se o sistema falhar. Nesta etapa, deve-se categorizar todas as informações e requisitos da partes interessadas. Deve-se, também, identificar os requisitos que são inconsistentes e conflitantes com outros. Deve ser organizado de tal maneira que as partes interessadas possam decidir por um conjunto de requisitos exigidos para o sistema.

Passo 3: Trabalho para a colaboração

O sucesso da maioria dos projetos depende da colaboração. Para conseguir isto, é necessário procurar áreas dentro das exigências que são comuns às partes interessadas. Entretanto, o desafio está na resolução de inconsistências e conflitos. A colaboração não significa que um comitê decida as exigências do sistema. Em muitos casos, para resolver conflitos um líder de equipe, normalmente um gerente de negócio ou um desenvolvedor sênior, decide que exigências são incluídas quando o software é desenvolvido.

Passo 4: Fazendo as primeiras perguntas

Para definir o espaço e a natureza do problema, as perguntas são feitas aos clientes e às partes interessadas. Essas perguntas podem ser categorizadas. Como por exemplo: Motivação da parte interessada ou do cliente:

1. Quem está solicitando este trabalho?2. Por que estão solicitando tal trabalho?

1 Ato ou efeito de conceber2 Ato ou efeito de esclarecer ou explicar


JEDITM

3. Quem são os usuários finais do sistema? 4. Quais são os benefícios quando o sistema for desenvolvido com sucesso? 5. Existe alguma outra maneira para fornecer a solução do problema? Quais são as

alternativas?

Percepção do cliente e da parte interessada:

1. Como se pode caracterizar um bom produto de software? 2. Quais são os problemas que o software deverá solucionar? 3. Qual é o ambiente de negócio do cliente e/ou da parte interessada? 4. Há alguma restrição ou exigência que afete o modo que a solução é alcançada?

Eficácia da comunicação:

1. Estamos perguntando para as pessoas corretas as questões corretas?2. As respostas estão sendo “oficialmente” formalizadas? 3. As perguntas são relevantes ao problema? 4. Sou eu quem faz perguntas demais? 5. Qualquer um pode fornecer informação adicional? 6. Há qualquer outra coisa que eu necessito saber?

Inicializando o trabalho

O produto principal do trabalho é uma ou duas páginas do produto solicitado que é um sumário contendo a descrição do problema e a sua natureza.

3.2. Elucidação

Após a concepção, o próximo passo é a elucidação. Ajuda o cliente a definir o que foi requerido. Entretanto, esta não é uma tarefa fácil. Entre os problemas encontrados na elucidação são citados abaixo:

1. Problemas de escopo. É importante que os limites do sistema estejam definidos clara e corretamente. É importante evitar o uso demasiado de detalhes técnicos porque é possível confundir mais do que esclarecer os objetivos do sistema.

2. Problemas de entendimento. Em alguns momentos é difícil aos clientes e usuários possuir uma completa definição do que necessitam. Algumas vezes eles tem fraco entendimento da capacidade e limitações de seus ambientes computacionais, ou não possuem um entendimento completo do domínio do problema. Por vezes podem até omitir informações que acreditam ser óbvias.

3. Problemas de volatilidade. É inevitável que os requisitos mudem com o tempo.

Para ajudar a superar estes problemas, engenheiros de software devem abordar a pesquisa de requisitos de uma forma organizada e sistemática.

Recolhendo requisitos colaborativos

Ao contrário da concepção onde abordamos o uso de perguntas e respostas, a elucidação combina os elementos de solução de problemas, elaboração, negociação e especificação dando um formato à elucidação de requisitos. Requer a cooperação do grupo de usuários-finais e desenvolvedores para esclarecer os requisitos. Trabalham juntos para:

• Identificar o problema

• Propor elementos de solução

• Negociar diferentes abordagens

• Especificar um conjunto de requisitos de soluções

Desenvolvimento de Aplicações em Conjunto

Joint Application Development – JAD é uma técnica de recolhimento colaborativo popular para esclarecer os requisitos.

As tarefas envolvidas na elucidação podem ser categorizadas em três grupos, a saber, preparação


JEDITM

para sessão JAD, sessão JAD e pós-sessão JAD.

Preparação para sessão JAD

1. Se não existe uma requisição, peça a um participante para escrever uma.

2. Marque o lugar, a data e hora da reunião.

3. Selecione um facilitador.

4. Convide aos participantes que serão parte das equipes de desenvolvimento, os clientes e outros participantes.

5. Distribua a requisição para todos os participantes antes da reunião.

6. A cada participante é pedido que faça o seguinte:

• uma lista de objetos que são parte do ambiente que cerca o sistema;

• uma lista de outros objetos que são produzidos pelo sistema;

• uma lista dos objetos usados pelo sistema para realizar as suas funções;

• uma lista de serviços (processos ou funções) que manipulam ou interagem com os objetos;

• uma lista de restrições, tais como custo, tamanho e regras de negócio; e

• uma lista de critérios de performance, tais como velocidade ou precisão.

Observe que não se espera que as listas sejam exaustivas mas espera-se que reflitam a percepção que a pessoa tem do sistema.

Tarefas na Reunião

1. O primeiro tópico que precisa ser resolvido é a necessidade e a justificativa do novo produto. Todo mundo deve concordar que o produto é justificável.

2. Cada participante apresenta sua lista ao grupo.

3. Após a apresentação de todos os participantes, uma lista consolidada é criada. Ela elimina questões redundantes, adiciona novas idéias que porventura apareçam durante a discussão, mas não exclui nada.

4. A lista consensual em cada tópico (objetos, serviços, restrições e performance) é definida. A lista consolidada da tarefa anterior é diminuída, aumentada, ou reescrita para refletir o produto ou sistema a ser desenvolvido.

5. Um vez que a lista consensual está definida, a equipe é dividida em sub-equipes. Cada uma irá trabalhar para desenvolver as mini-especificações para uma ou mais entradas da lista consensual. A mini-especificação é simplesmente um detalhamento do item da lista utilizando palavras e frases.

6. Cada sub-equipe, então, apresenta a sua mini-especificação para todos os presentes. Inclusões, exclusões e maiores detalhamentos podem ser feitos. Em alguns casos, serão descobertos novos objetos, serviços, restrições ou requisitos de performance que serão adicionados às listas originais.

7. Em alguns casos, surgem questões que não poderão ser resolvidas durante a reunião. Uma lista de pendências é mantida e estas serão trabalhadas mais tarde.

8. Após se completar cada mini-especificação, cada presente faz uma lista de critérios de validação do produto ou sistema e apresenta a lista à equipe. Uma lista consensual de critérios de validação é criada.

9. A um ou mais participantes é associada a tarefa de escrever um esboço da Ata de Reunião com todas as questões levantadas na reunião.

Tarefas Pós-Reunião

1. Compilar a Ata de Reunião com todos os itens discutidos na reunião.

2. Priorizar os requisitos. Pode-se usar a Técnica Qualidade da Função ou a Técnica de MoSCoW.


JEDITM

Desenvolvimento com Qualidade da Função

É uma técnica que enfatiza o entendimento do que é importante para o usuário. Então, estes valores são desenvolvidos através do processo de Engenharia. Identifica três tipos de requisitos:

Implantando as Funções de Qualidade

É uma técnica que enfatiza o entendimento do que é importante para o cliente. Então, utilizar estes valores por toda parte nos processos da engenharia de software. Para tal, são identificados três tipos de requisitos:

1. Requisitos Normais – Estes requisitos refletem diretamente nos objetivos expressados para um produto ou sistema durante as reuniões com os clientes. Isso significa que se os requisitos estão presentes, o cliente está satisfeito.

2. Requisitos Esperados – Estes requisitos são implícitos para o produto ou sistema e podem ser tão fundamentais que os clientes não os expressam explicitamente. A ausência destas necessidades podem causar uma significativa insatisfação. Exemplo dos requisitos esperados seriam as facilidades de interação entre homem e máquina, a maior parte das operações realizadas corretamente e confiáveis, além da facilidade de instalação das aplicações.

3. Requisitos de Excitação – Estes requisitos refletem as características que vão além das expectativas do cliente e provam ser muito satisfatórios quando presentes.

Com diversas reuniões com a equipe, análises de valor são conduzidas para determinar a prioridade relativa dos requisitos baseados em três implantações, definidas como: implantação de funções, implantação de informação e implantação de tarefas. Implantação de funções são usadas para determinar o valor de cada função que é necessária para o sistema. Implantação de informação identifica cada dado e evento que o sistema deve consumir e produzir. Implantação de tarefas examina o comportamento do produto ou sistema com o contexto do ambiente. Para cada análise de valor, cada requisito é categorizado em três tipos de requisitos.

Técnica de MoSCoW

Cada requisito pode lidar classes de prioridades opostas, como definidas na Tabela 1. Durante o processo de engenharia de software, uma pequena reunião pede ser conduzida para rever as probabilidades e redefinir prioridades.

Classificação Significado

Deve Ter Este requisito será incluído no produto entregue.

Pode Ter O plano do projeto atual indica que este requisito será incluído. Se as circunstâncias mudarem, este pode ser deixado de fora.

Talvez Tenha O plano do projeto atual não indica que este requisito será incluído. Se as circunstâncias mudarem, este pode ser incluído.

Não Pode Ter Este requisito não será incluído no produto entregue.

Tabela 1: Classificação de Prioridades

Produto do trabalho de Esclarecimento

A saída da atividade de esclarecimento pode variar dependendo do tamanho do sistema ou do produto a ser construído. Para a maioria dos sistemas, os produtos da saída ou do trabalho incluem:

✔ Uma indicação da necessidade e da praticabilidade✔ Uma indicação limitada do espaço para o sistema ou o produto✔ Uma lista do cliente, dos usuários, e das outras partes interessadas que participaram do✔ esclarecimento das necessidades.✔ Uma descrição do ambiente técnico do sistema✔ Uma lista de prioridade dos requisitos, preferencialmente, nos termos das funções, objetos

e confinamentos do domínio que se aplicam a cada um.


JEDITM

3.3. Elaboração

A informação obtida pela equipe durante o levantamento e esclarecimento é expandida e refinada durante a elaboração. Esta tarefa de exigência de engenharia tem o foco em definir, redefinir e refinar os modelos, a saber, os modelos de requisitos (domínio do sistema ou problema) e modelo de análise (domínio da solução). Tenta modelar “O QUE” ao invés de “COMO”.

Modelo de Requisitos é criado usando metodologias que centralizam no usuário os cenários que definem a maneira como o sistema é usado. Descreve como os usuários finais e os atores interagem com o sistema.

Modelo da Análise é derivado do Modelo de Requisitos onde cada cenário é analisado para obter as classes de análise, isto é, o domínio das entidades de negócio que são visíveis ao usuário final. Os atributos de cada classe da análise são definidos e as responsabilidades que são exigidas por cada classe são identificadas. Os relacionamentos e a colaboração entre as classes são identificadas e uma variedade de diagramas suplementares de UML é produzida. O resultado final da elaboração é um modelo de análise que define o domínio informativo, funcional e o comportamento do problema. O desenvolvimento destes modelos será discutido no Modelo de Requisitos e Análise e na seção Especificação de Requisitos nesta lição.

Produto do trabalho de Elaboração

O Modelo de Requisitos e o Modelo da Análise são os produtos principais de trabalho desta tarefa.

3.4. Negociação

Na negociação, os clientes, as partes interessadas e a equipe do desenvolvimento do software negociam os conflitos. Os conflitos aumentam quando os clientes estão pedindo mais do que o desenvolvimento de software pode conseguir com os limitados recursos de sistema liberados. Para resolver estes conflitos, requisitos são classificados, os riscos associados com cada exigência são identificados e analisados, as estimativas de esforço do desenvolvimento e os custos são feitas, e prazo de entrega é definido.

O objetivo da negociação é desenvolver um plano de projeto que se adeqüe às exigências do usuário ao refletir acontecimentos do mundo real tais como o tempo, pessoas e o orçamento. Ele significa que o cliente obtém o sistema ou o produto que satisfaz à maioria das necessidades, e a equipe do software é capaz de trabalhar realisticamente para alcançar os prazos e orçamentos definidos nas reuniões.

A Arte de Negociação

Negociação é um meio de estabelecer colaboração. Para o sucesso de um projeto de desenvolvimento de software, colaboração é a chave. Abaixo estão algumas diretrizes da negociação com as partes interessadas.

1. Lembre que a negociação não é nenhuma competição. Todo o mundo deve chegar a um acordo. Em algum nível, todos devem sentir que as preocupações foram enviadas, ou que alcançaram algo.

2. Tenha uma estratégia. Escute o que as partes querem alcançar. Decidam como juntos farão tudo acontecer.

3. Escute efetivamente. Mostre que está escutando e que está preocupado. Tente não formular a resposta ou uma reação enquanto o outro está falando. Pode-se adquirir algo que pode ajudar uma negociação futura.

4. Focalize no interesse da outra parte. Não leve posições duras para evitar conflito.

5. Não leve para o lado pessoal. Focalize no problema que precisa ser resolvido.

6. Seja criativo. Não tenha nenhum medo de "sair da caixa".

7. Esteja pronto para assinar. Uma vez que foi estabelecido um acordo, este deve ser assinado e passado para outros assuntos.


JEDITM

Especificação

Uma especificação é o artefato final ou produto do trabalho produzido pelo engenheiro de software durante engenharia de requisitos. Serve como uma base para software subseqüente da engenharia de atividades, particularmente, o desenho e a construção do software. Mostra os aspectos informais, funcionais e de comportamento do sistema. Pode ser escrito como um documento, um conjunto de modelos gráficos, um modelo matemático formal, um protótipo ou qualquer combinação destes. Os modelos servem como suas especificações.

Validação

São avaliados os produtos de trabalho produzidos como conseqüência dos requisitos, acessados para a qualidade durante o processo de validação. Examina a especificação para assegurar que todas as exigências de software foram claramente declaradas e que foram descobertas inconsistências, omissões, e erros foram corrigidos. Confere a conformidade e trabalha os padrões de produtos estabelecidos no projeto de software.

A equipe de revisão que valida as exigências consiste em engenheiros de software, clientes, usuários, e outros participantes do projeto. Procuram por erros em conteúdo ou interpretação, áreas onde uma maior clareza é requerida, informação perdida, inconsistências, conflitos e exigências irreais.

Lista de Verificação de Validação de Requisitos

A medida que os modelos são construídos, são examinados em termos de consistência, omissão, e ambigüidade. As exigências são priorizadas e se agrupam dentro de pacotes que serão implementados como incrementos de software e serão entregues ao cliente. Perguntas como as sugeridas por Pressman são listados abaixo para servir como uma diretriz para validar os produtos de trabalho da engenharia de requisitos.

1. Cada exigência é consistente com o objetivo geral para o sistema ou o produto?

2. Todas as exigências são especificadas no nível apropriado de abstração? Isto é, algumas exigências fornecem um nível de detalhe técnico que não é apropriado no estágio?

3. A exigência é realmente necessária ou representa uma característica que possa não ser essencial ao objetivo do sistema?

4. Cada exigência é limitada e clara?

5. Cada exigência tem a atribuição? Isto é, uma fonte (geralmente, um indivíduo específico) é anotada para cada exigência?

6. Algumas exigências entram em conflito com outras exigências?

7. Cada exigência é realizável no ambiente técnico que abrigará o sistema ou o produto?

8. Cada exigência é testável, uma vez implementada?

9. O modelo da exigência reflete corretamente a informação, a função e o comportamento do sistema a ser construído?

10. O modelo das exigências foi “dividido” de uma maneira que exponha uma informação progressivamente mais detalhada sobre o sistema?

11. O padrão das exigências é utilizado para simplificar o modelo das exigências? Todos os padrões foram validados corretamente? Todos os padrões são consistentes com as exigências do cliente?

Estas e outras perguntas devem ser feitas e respondidas para assegurar-se de que todos os produtos do trabalho reflitam as necessidades do cliente, de modo que forneça uma fundação sólida para o projeto e a construção.

3.5. Gerência

É o conjunto das atividades que ajudam a equipe de projeto a identificar, controlar e traçar as


JEDITM

exigências e suas mudanças em qualquer fase, enquanto o projeto progride. O gerenciamento das exigências começa uma vez que estas são identificadas. A cada exigência é atribuído um identificador único.

Uma vez que os requisitos tenham sido identificados, tabelas da Matriz de Rastreabilidade são desenvolvidas.

Matriz de Rastreabilidade de Requisitos

Requirements Traceability Matrix – RTM será discutida na seção Matriz de Rastreabilidade de Requisitos nesta lição e ajudará aos engenheiros de software a gerenciar os requisitos durante o progresso do processo de desenvolvimento.


JEDITM

4. Modelo e Análise de Requisitos

Durante a elaboração, a informação obtida durante a concepção e a elucidação é ampliada e refinada para produzir dois importantes modelos: de requisitos e de análise. O modelo de requisitos determina o modelo de sistema ou o domínio do problema. Nesta seção, iremos discutir sobre o modelo de requisitos e como este pode ser construído.

4.1. O Modelo de Requisitos

O Rational Rose define o Modelo de Requisitos como ilustrado na Figura 13. Este modelo consiste em três elementos, especificamente, Modelo de Caso de Uso, Especificações Suplementares, e Glossário.

Figura 1: Modelo de Requisitos

Modelo de Caso de Uso

Este modelo é usado para descrever o que o sistema deverá fazer. Ele serve como um contrato entre clientes, usuários finais e desenvolvedores de sistema. Para clientes e usuários finais, este modelo é usado para validar o que o sistema deverá ter para atender às suas expectativas. Para os desenvolvedores, usado para garantir que o que estão construindo o esperado. O Modelo de Caso de Uso consiste em duas partes, a saber, o diagrama de caso de uso e a especificação de casos de uso.

1. Diagrama de caso de uso consiste de atores e casos de uso. Ele apresenta a funcionalidade que o sistema proverá aos usuários para se comunicarem com o sistema. Cada caso de uso no modelo é descrito em detalhes usando as especificações de caso de uso.

2. Especificações de caso de uso. São documentos textuais que especificam as propriedades dos casos de uso tais como fluxo de eventos, pré-condições, pós-condições etc. O diagrama da ferramenta UML usado para definir o Modelo de Caso de Uso é o Diagrama de Caso de Uso.

O instrumento de diagramação UML utilizado para definir o Modelo de Caso de Uso é chamado de Diagrama de Caso de Uso.

Especificações Complementares

Contém aqueles requisitos que não mapeiam um caso de uso específico. Podem ser requisitos não funcionais tais como: manutenção de códigos fonte, usabilidade, confiabilidade,

3 Object-oriented Analysis and Design Using the UML , Rational Rose Corporation, 2000, páginas 3-5


Modelo de Caso de Uso

Ator AtorCasos de Uso

Especificações dos Casos de Uso

Especificação Suplementar

Glossário

JEDITM

performance, e sustentabilidade, ou restrições de sistema que restringem nossas escolhas na construção da solução para o problema, tais como sistemas que devem ser desenvolvidos em Solaris e Java. É um importante complemento para o Modelo de Caso de Uso pois possibilita uma especificação completa dos requisitos do sistema a ser desenvolvido.

Glossário

Define uma terminologia comum para todos os modelos. É usado pelos desenvolvedores para estabelecer um dialeto comum com os clientes e usuários finais. Deve haver um único glossário para todo o sistema.

4.2. Modelagem de Cenário

O Modelo de Caso de Uso é um mecanismo para captura de comportamentos desejados do sistema sem especificar como o comportamento será implementado. O ponto de vista dos atores interagindo com o sistema será usado na descrição dos cenários. Cenários são instâncias de funcionalidade que o sistema fornece. Ele captura as interações específicas que ocorrem entre os produtores e consumidores de dados, e o próprio sistema. É importante observar que a construção do modelo é um processo interativo de refinamento.

Diagrama de Caso de Uso de UML

Como mencionado na seção anterior, o Diagrama de Caso de Uso é utilizado como instrumento de modelagem para o Modelo de Caso de Uso. A Tabela 2 mostra a notação básica.

Notação Básica Nome Significado

Ator-nome

Ator

Representar um conjunto coerente de papéis que usuários interpretam quando interagem com os casos de uso. Ele efetua chamadas ao sistema que por sua vez entrega um de seus serviços. Pode ser uma pessoa, um dispositivo, ou um outro sistema. Atores são nomeados com a utilização de substantivos.

Caso de Uso

Descrever as funções que o sistema executa quando interage com atores. É uma seqüência de ações que proporcionam um resultado observável para os atores. É descrito utilizando-se frases verbo-substantivo.

ou AssociaçãoMostrar a relação ou associação entre um ator e o caso de uso, ou entre os casos de uso.

Tabela 2: Notação Básica do Diagrama de Caso de Uso

O Modelo de Caso de Uso pode ser refinado com a utilização de estereótipos em associações e generalização de atores e casos de uso. Na UML, estereótipos são elementos de modelagem especiais que representam um elemento de forma particular. São representados por uma palavra-chave envolta em chaves angulares (<< e >>) tais como <<extend>> e <<include>>. Generalização ou especialização seguem os mesmos conceitos que foram discutidos na seção Conceitos de orientação à objeto. A Tabela 3 mostra a notação estendida do Diagrama de Caso de Uso em UML.

Notação Básica Nome Significado Extend Mostrar que um caso de uso provê uma funcionalidade

adicional que pode ser requerida por outro caso de uso.

Include Mostrar que quando um caso de uso é utilizado, outros (incluídos) também serão utilizados.

Generalização

do Ator

Pode haver casos no qual seria melhor mostrar um super-ator que comunica com um caso de uso em lugar de todos os atores que comunicam com o mesmo caso de uso, particularmente, quando todos eles interagirem com um sistema de mesma funcionalidade.


Verbo Substantivo

<<extend>>

<<include>>

JEDITM


Generalização

do Caso de Uso

Pode haver casos de uso semelhantes onde a funcionalidade comum é representada melhor generalizando toda a funcionalidade em um super caso de uso.

Tabela 3: Notação Estendida do Diagrama de Caso de Uso

Desenvolvendo o Modelo de Caso de Uso

PASSO 1: Identifique os atores

Identifique os atores externos que irão interagir com o sistema. Pode ser uma pessoa, um dispositivo ou outro sistema. Como exemplo, a Figura 2 identifica os atores para a Manutenção de As sociação ao Clube do estudo de caso.

Figura 2: Atores de Manutenção de Associação ao Clube

Dois atores foram identificados, a saber, funcionários do clube e treinador.

PASSO 2: Identifique os casos de uso

Identifique casos de uso que o sistema precisa executar. Lembre-se que casos de uso são seqüências de ações que dão um resultado observável aos atores. Como exemplo, a Figura 3 identifica os casos de uso iniciais.

Figura 3: Casos de Uso de Manutenção de Associação ao Clube

Os seguintes casos de uso foram identificados.

• Adiciona Registro de Atleta• Edita Registro de Atleta• Apaga Registro de Atleta• Atualiza Status de Atleta

PASSO 3: Associe casos de uso com atores

A Figura 4 mostra a primeira iteração do modelo de caso de uso. Os casos de uso identificados são atribuídos aos dois atores.


JEDITM

Figura 4: Primeira Iteração do Modelo de Caso de Uso de Associação ao Clube

PASSO 4: Refine e redefina o modelo

Este caso de uso pode ser refinado usando a notação melhorada. A segunda iteração do modelo de caso de uso é mostrada na Figura 5. Opcionalmente, numere os casos de uso.

Figura 5: Segunda Iteração do Modelo de Caso de Uso de Associação ao Clube

Na segunda iteração, a elaboração é feita pela introdução do caso de uso Manutenção de Registro de Atleta. Isto é gerenciado pelos funcionários do clube. Estereótipos sobre associados são usados para incluir ou estender este caso de uso.

O caso de uso Manutenção de Registro de Atleta é estendido para ter as seguintes opções:

• 1.1 Adicionar Registro de Atleta


JEDITM

• 1.2 Editar Registro de Atleta

• 1.3 Remover Registro de Atleta

Toda vez que o caso de uso Atualizar Registro de Atleta é executado, um Editar Registro de Atleta é também executado.

Além disso, um outro caso de uso foi adicionado para especificar que determinados atores podem visualizar o registro do atleta (Caso de Uso Visualizar Registro de Atleta).

A modelagem é um processo iterativo. A decisão de quando parar a iteração é subjetiva e é tomada por quem modela. Para ajudar nesta decisão, responda às perguntas encontradas no Checklist de Requisitos para a Validação de Modelos.

PASSO 5: Para cada caso de uso, escreva a especificação do caso de uso

Para cada caso de uso encontrado no Modelo de Casos de Uso, a especificação de caso de uso deve ser definida. A especificação de caso de uso é um documento onde os detalhes internos do caso de uso são especificados. Ela pode conter quaisquer das seções listadas abaixo. Contudo, as cinco primeiras são as seções recomendadas.

1. Nome. Este é o nome do caso de uso. Deve ser o mesmo que é encontrado no Modelo de Caso de Uso.

2. Breve Descrição. Descreve o papel e o propósito do caso de uso em poucas linhas.

3. Pré-condições. Nele são especificadas as condições necessárias antes da execução do caso de uso.

4. Linha de Eventos. Esta é a parte mais importante para a análise dos requisitos. São os eventos que descrevem o que o caso de uso irá fazer. Neste ponto, os cenários são identificados.

5. Pós Condições. Nesse item são especificadas as condições existentes após a execução do caso de uso.

6. Relacionamentos. Nesta seção, outros casos de usos são associados à corrente de acontecimentos usados na especificação deste caso de uso. Normalmente, eles são casos de uso entendidos <<extends>> ou incluídos<<include>>.

7. Requisitos Especiais. Eles contém outros requisitos que não estão especificados nos diagramas que são semelhantes a requisitos não funcionais.

8. Outros Diagramas. Diagramas adicionais podem ajudar a esclarecer os requisitos. São utilizados como projetos protótipos, utilizados para esboça o dialogo dos usuários e o sistema, etc.

A linha de Eventos possui as informações mais importantes para o funcionamento da modelagem dos casos de usos. Descrevem o que o caso de uso irá fazer; NÃO como o projeto sistema irá executar. Fornece uma descrição da seqüência de ações necessária para o sistema dispor o serviço esperado pelo ator;

Um cenário é uma instância da funcionalidade do sistema. Ele também é descrito em paralelo a um Caso de Uso. A linha de Eventos de um caso de uso consiste em uma linha básica e várias linhas alternativas. Uma linha básica, normalmente, a execução mais simples do caso de uso, temos uma linha básica e constantemente modifica os endereços de linhas alternativas, onde os casos excepcionais serão tratado no caso de situações de erros.

Existe duas maneira de demonstrar uma linha de evento – textual e gráfica. Para demonstrar graficamente uma linha de evento, é usado um Diagrama de Atividade da UML. Ele é usado similarmente a um fluxograma. Porém, são utilizados para modelar cenários de casos de uso. Utiliza-se a seguinte notação indicada na Tabela 4.


JEDITM


Estado de Atividade

Ela representa a execução de uma atividade ou uma execução interna de uma linha de trabalho. Atividades pode ser representados utilizando frases com verbos-substantivos .

Transição Mostra qual atividade será executada após a outra. Uma seta aponta a direção da próxima execução.

Decisão

É utilizado para avaliar condições. O símbolo é semelhante ao utilizado em um fluxograma. Ele é usado para guardar as condições que determinem quais fluxos alternativos serão executados.

Barras de Sincronização

São usados para mostrar sub-fluxos. É utilizado para ilustrar execuções concorrentes em uma linha de trabalho.

Tabela 4: Símbolos do Diagrama de Atividades

A Figura 6 é um exemplo de diagrama de atividade. Ilustra como atletas são inicialmente escalados para uma equipe. A Diretoria recebe os formulários preenchidos pelos atleta s e prepara o teste simulado. Durante os testes, o comitê de s eleção avalia o desempenho dos atleta s . Se o atleta joga bem, é imediatamente colocado na Equipe de Competição. Caso contrário, é colocado na Equipe de Treinamento. A Diretoria manterá os registros dos atleta em arquivos apropriados.

Figura 6: Recrutamento de Atletas

O Diagrama de Atividades pode ser modificado para o Diagrama Swimlane. Neste diagrama, atividades são alinhadas com base na responsabilidade dos atores para aquela atividade. A Figura7 mostra o diagrama de atividades modificado, onde os atores responsáveis pela atividade são grafados acima da atividade.


Verbo Substantivo

JEDITM

Figura 7: Atribuição inicial utilizando o Diagrama de Swimlane

Para auxiliar os engenheiros a definir o fluxo eventos, a lista de dicas é apresentada abaixo.

1. Para reforçar a responsabilidade do ator, inicie a descrição com “Quando o ator...”

2. Descrever a troca de dados entre o ator e o caso de uso.

3. Tentar não descrever os detalhes das interfaces, a menos que seja necessário.

4. Responda a todas as perguntas “porque”. Os designers utilizarão essas respostas para identificar os Casos de Testes.

5. Evite terminologias tais como “Por exemplo,...”, “processo” e “informação”.

6. Descreva quando o caso de uso inicia e termina.

Passo 6: Refinar e Redefinir as especificações dos Casos de Uso

Similar ao desenvolvimento do Diagrama de Caso de Uso, pode-se refinar e redefinir suas especificações. Isto também é feito iterativamente. O momento de interromper a iteração depende da modelagem. O analista pode responder às perguntas presentes no Modelo de Validação de Requisitos para determinar quando encerrar as atividades de refinar e redefinir as especificações do caso de uso.

4.3. Modelo de Validação dos Requisitos

Assim como qualquer produto, em qualquer fase é preciso fazer uma validação dos requisitos. Abaixo, está uma lista das questões que servem de base para se criar o modelo de validação de requisitos. É importante notar que essa lista serve como um guia. O engenheiro pode adicionar ou retirar questões dependendo das circunstâncias e necessidades do desenvolvimento do projeto.


JEDITM

Modelo de Validação para o Caso de Uso

1. É possível entender o Diagrama de Caso de Uso?

2. É possível ter uma idéia clara de todas as funcionalidades do sistema?

3. É possível ver os relacionamentos entre as funcionalidades que o sistema precisa executar?

4. Todas as funcionalidades foram cumpridas?

5. O Diagrama de Caso de Uso contém algum comportamento inconsistente?

6. O Diagrama de Caso de Uso pode ser dividido em pacotes? Estão divididos apropriadamente?

Lista de Validação para o Ator

1. Todos os possíveis atores foram identificados?

2. Todos os atores identificados estão associados a pelo menos um Caso de Uso?

3. Um ator especifica um grupo? É necessário criar o grupo ou separar os atores?

4. Os atores possuem nomes intuitivos e descritivos?

5. Usuários e Cliente entendem os nomes dos atores?

Validação para o Caso de Uso

1. Todos os casos de uso estão associados a atores ou outros casos de uso?

2. Os casos de uso são independentes?

3. Existe algum caso de uso que apresenta um comportamento similar ou fluxo de eventos?

4. Foi dado a todo casos de uso um nome único, intuitivo e explicativo?

5. Clientes e Usuários estão prontos para entender os nomes e as descrições dos casos de uso?

Checklist de Validação da Especificação de Caso de Uso

1. Podemos ver claramente o que o caso de uso deseja executar?

2. O objetivo do caso de uso está claro?

3. A descrição do caso de uso está clara e bem definida? Podemos entender? Incorpora o que o caso de uso está pretendendo fazer?

4. Está claro quando o fluxo de eventos inicia? Quando termina?

5. Está claro como o fluxo de eventos se inicia? Quando termina?

6. Podemos entender claramente as interações do ator e a troca de informação?

7. Há algum caso de uso complexo?

Verificação de Validação do Glossário

1. O termo está claro e conciso?

2. Os termos usados na especificação de caso de uso?

3. Os termos usados de maneira consistente no sistema? Há sinônimos?


JEDITM

5. Especificação de Requisitos

Na seção anterior, o modelo de requisitos foi introduzido e discutido. Nessa seção, veremos o modelo de análise que fornece um modelo base para as funções do software, o que irá ou não fornecer. Esse é o ponto principal que será desenvolvido na fase de engenharia de requisitos, pois serve de base para o projeto e construção do software. Aprenderemos como o modelo de análise pode ser derivado do modelo de requisitos.

5.1. O Modelo de Análise

O modelo de análise está ilustrado na Figura 8. Consiste de dois elementos, particularmente, Modelo de Análise e Modelo Comportamental.

Figura 8: Modelo de Análise – Diagrama de Classe, de Seqüência e de Colaboração

Para criar o modelo de análise, os seguintes documentos de entrada são necessários.

• Modelo de Requisitos

• Documento de Arquitetura de Software (Opcional)

Modelo de Análise

É criado utilizando-se o Diagrama de Classe da UML. Este é o diagrama mais importante a ser desenvolvido, pois serve como entrada principal para a fase de projeto da engenharia. Consiste de Classes de Análise que representam um primeiro modelo conceitual para os aspectos do sistema que tenham responsabilidades e comportamentos. É usado para obter o primeiro esboço dos objetos que queremos que o sistema suporte sem decidir quantos deles serão suportados pelo hardware e quantos pelo software. Raramente sobrevive inalterado a fase de Engenharia do Projeto.

Modelo comportamental

Utiliza a criação de eventos ou o Diagramas de Interação da UML, consiste nos diagramas de Seqüência e de Colaboração. Representa os aspectos dinâmicos do sistema. Isto mostra a


JEDITM

interação e a colaboração entre classes de análise.

5.2. Técnica de Análise do Caso de Uso

É uma técnica derivada do Modelo de Análise e do Modelo de Requisitos. Aqui, o Modelo de Caso de Uso é analisado gramaticalmente para extrair classes de análise. São analisados a estrutura e comportamento das classes de análise. E então são documentados. Deve capturar o aspecto informador, funcional e de comportamento do sistema.

Desenvolvendo o Modelo de Análise

Passo 1: Valide o Modelo do Caso de Uso.

O modelo de Caso de Uso é validado para conferir as exigências. Por vezes captura uma informação adicional que pode ser necessária para o entendimento do comportamento interno do sistema. Também é possível encontrar algumas exigências incorretas ou mal compreendidas. Em tal caso, deve ser atualizado o fluxo original de eventos, isto é, é necessário retornar à fase de análise do modelo de requisitos.

Pode-se utilizar uma aproximação de "Caixa Branca" descrevendo e entendendo o comportamento interno do sistema que precisa ser executado. Como um exemplo, considere as frases seguintes. Qual está clara?

1. O comitê de seleção obtém os formulários de aplicação.2. O comitê de seleção recorre ao formulário de aplicação dos candidatos que são marcados

como falso e armazenados na gaveta do gabinete de arquivamento com o título "Candidatos para aplicar o teste".

Passo 2: Para cada caso de uso, localizar as classes de análise.

Uma vez que o Modelo de Caso de Uso é validado, as classes de análise de candidatas são identificadas e são descritas em alguns frases.

Uma classe é uma descrição de conjuntos de objetos que compartilham os mesmos atributos, operações, relações e semântica. É uma abstração que enfatiza características pertinentes e suprime outras características. Dizemos que um objeto é um exemplo de uma classe. Uma classe é representada por uma caixa retangular com três compartimentos. O primeiro contém o nome da classe. O segundo contém uma lista de atributos. O último contém uma lista de operações (métodos). Veja na Figura 9 um exemplo de uma classe. Neste exemplo, o nome da classe é Athlet. Os atributos são mostrados no segundo compartimento que incluem id, lastname, firstname, mi, address, postalCode, telephone, bday, gender e status. Os métodos são listadas no terceiro compartimento que inclui addAthlete(), editAthlete(), deleteAthlete() e updateStatus().

Figura 9: Representação de uma classe

Três perspectivas são utilizadas para identificar as classes de análise. São o limite entre o sistema


JEDITM

e seu ator, a informação e os usos de sistemas, e a lógica de controle do sistema. Oferecem um modelo mais robusto porque isolam coisas que provavelmente iriam mudar em um sistema. Em UML, eles são determinados estereótipos e são descritos na Tabela 5.

Esteriótipo Representação Significado Fronteira

ou

É usado como modelo de interação entre um ambiente de sistemas e trabalhos internos. Esclarece sistemas de fronteiras e auxilia o projetista ao permitir um bom ponto de partida para identificar serviços relacionados. Isola forças externas de mecanismos internos e vice-versa. Faz o intermédio entre a interface e algo fora do sistema. Existem três tipos: interface-usuário, interface-sistema e interface-dispositivo.

Controle

ou

A maior parte da funcionalidade do sistema é executada por essa classe. Proporciona comportamento que:• É independente do ambiente.• Define controle lógico e transações dentro de um caso

de uso.• Requer pequenas mudanças se a estrutura interna ou o

comportamento das classes de entidade mudar.• Obtém usuários ou um conjunto com o conteúdo de

diversas classes de entidade, e portanto necessita coordenar o comportamento dessas classes de entidade.

• Não é realizado da mesma forma toda vez que o mesmo é ativado.

Proporciona coordenar os comportamentos do sistema. Separar as classes fronteira com as de entidade.

Entidade

ou

Representa depósitos de informações no sistema. É usado para guardar e atualizar informações sobre algum fenômeno, tal como um evento, uma pessoa ou algum objeto da vida real. As suas principais responsabilidades são armazenar e gerenciar informações do sistema. Representa os conceitos chaves do sistema sendo desenvolvido.

Tabela 5: Três estereótipos em UML

Identificando Classes de Fronteira

Usando o Diagrama de Caso de Uso, uma classe fronteira existe para todo conjunto ator/caso de uso. Um exemplo é mostrado na Figura 10. A RegistroAtletaUI é considerada a classe de fronteira entre o ator Pe s s oa Clube e o caso de uso Manter Registro Atleta.

Figura 10: Sócio de clube - Exemplo de Classes Fronteira


JEDITM

Identificando Classe de Controle

Usando o Diagrama de Caso de Uso, existe uma classe de controle para todo caso de uso. Um exemplo é mostrado na Figura 11. Quatro classes de controle foram identificadas, nomeadas, ManutencaoRegistroAtleta, AdicionaAtleta, EditaAtleta e ExcluiAtleta.

Figura 11: Sócio do Clube - Exemplo de Classes de Controle

Identificando Entidades de Classes

Utilizando a especificação do caso de uso, entidades de classes podem ser encontradas:

• usando o fluxo de eventos do caso de uso como entrada

• pegando abstrações chaves dos casos de uso

• filtrando substantivos

Alguém pode empregar técnicas utilizadas para descobrir entidades em diagramas de Entidade-Relacionamento (DER). Um exemplo de entidades de classes derivadas do casos de uso Adicionar Registro de Atleta são mostradas na Figura 12. São entidade de classes Atleta, S e gurança e StatusAtleta.

Figura 12: Exemplo de entidades de classes Sócios do Clube


JEDITM

Passo 3: Modelar o comportamento das classes de análise.

Para modelar o comportamento das classes de análise, modelamos a natureza dinâmica dentre as classes de análise. Utiliza-se os digramas de eventos ou interação da UML, especificamente, Seqüência e Colaboração. Quando modelamos o comportamento do sistema, nível-objeto é usado ao invés de nível-classe para permitir cenários e eventos que utilizam mais de uma instância de uma classe. Dois elementos básicos de modelagem são usados: objetos e mensagens.

Objetos são instâncias de uma classe. Eles podem ser Objetos Nomeados ou Objetos Anônimos. Figura 13 mostra exemplo de objetos.

Figura 13: Exemplo de Objetos

Objetos Nomeados são identificados colocando seus nomes antes do nome da classe; são separados por dois-pontos (:). no diagrama, Timmy:Atleta é considerado um objeto nomeado. Objetos anônimos não possuem nomes; para representá-los, colocamos dois-pontos antes do nome da classe. :Treinador é um exemplo de objeto anônimo.

Mensagens são uma forma de comunicação entre objetos. Possuem o seguinte formato.

* [condição] : ação( lista de parâmetros ) : tipoValorRetorno

Tabela 6 mostra uma descrição de cada componente da mensagem. Somente o componente ação é obrigatório.

Componentes da Mensagem Significado

* Representar qualquer número de repetições da ação.

[condição] Representar uma condição que deve ser verdadeira antes que uma ação possa ser realizada.

ação(lista de parâmetros) Representar uma ação que deve ser realizada por um objeto. A ação, opcionalmente, pode conter uma lista de parâmetros.

tipoValorRetorno Caso uma ação retornar um valor, precisamos especificar o tipo desse valor.

Tabela 6: Componentes da Mensagem

Exemplos de mensagens são mostrados a seguir.

1. s ubmitApplication()

Essa mensagem significa que uma aplicação foi submetida.

2. [athleteIsHere = ye s] playBa s eketball(athlete) : void

Essa mensagem significa que, se atleta está aqui no teste, ele joga basquetebol.

3. * [for each athlete] isAthleteHere(athlete) : boolean

Essa mensagem verifica, para cada atleta, se o atleta está aqui. Retorna SIM se ele estiver aqui; caso contrário, retorna NÃO.

Descrevendo os Diagramas de Seqüência

O Diagrama de Seqüência é usado para modelar interações entre objetos, o qual mapeia interações seqüenciais para interações de objeto. Ele mostra explicitamente a seqüência de


Pedro:Diretoria Clube

:SelecaoComite

Timmy:Atleta :Treinador

Objetos Nomeados

Objetos Anônimo

JEDITM

mensagens sendo passadas de um objeto para outro. É usado para especificar interação de tempo real e cenários complexos. Similar aos diagramas de caso de uso, há uma notação básica e uma notação aprimorada. Figura 14 Mostra a notação básica do diagrama de seqüência.

Figura 14: Notação Básica do Diagrama de Seqüência

Objetos Cliente são diferenciados dos Objetos Fornecedor. Objetos Cliente são os objetos enviando mensagens. São os que pedem um serviço para executar a ação especificada na mensagem. Objetos Fornecedor são os receptores das mensagens; eles são requisitados para executar a ação especificada pela mensagem. Objetos são dispostos horizontalmente. Cada objeto deve ter uma linha de vida. Ela representa a existência do objeto em um instante em particular. Uma mensagem é mostrada como uma linha horizontal com uma seta, a partir da linha de vida de um objeto para a linha de vida de outro objeto. Uma mensagem reflexiva mostra uma seta que começa e termina na mesma linha de vida. Cada seta é rotulada com um número seqüencial e a mensagem. Uma mensagem de retorno é mostrada como uma linha horizontal pontilhada, com a mensagem return opcionalmente seguida pelo valor de retorno.

Figura 15 mostra a notação aprimorada do Diagrama de Seqüência. Ela usa os conceitos de criação e término de objeto, ativação e desativação de objeto, e mensagens customizadas.

Figura 15: Notação Aprimorada do Diagrama de Seqüência

Colocando um objeto no topo do diagrama implica que o objeto existe antes do cenário iniciar. Se um objeto é criado durante a execução do cenário, posicione o objeto no ponto em que ele foi criado. Para mostrar que um objeto terminou, posicione um X no ponto onde o término ocorreu.

Para mostrar a ativação e a desativação de um objeto, usamos o foco de controle. Ele representa o tempo relativo em que o fluxo de controle é focado no objeto, assim representar o tempo de um objeto é direcionar mensagens. Isso é mostrado como um grande retângulo sobre a linha de vida do objeto. O topo do retângulo indica quando um objeto se torna ativo; a parte de


1*[condition]: Action

Objeto Cliente Objeto Fornecedor

Mensagem

Bill:Client

Esse é um exemplo

Mensagem ReflexivaObject Lifeline

1.1[condition]: Action

Numeração hierárquicade mensagem

Retorna Mensagem

2 : return done

:Supplier

1*[condition]: Action

Timeout

Bill:Client

:Supplier

Retorno

2 : return done

Ativação

Desativação

Criação

X

Término

Síncrona

Assíncrona

JEDITM

baixo do retângulo indica quando um objeto se tornou inativo.

Mensagens podem ser customizadas para serem mensagens síncronas ou assíncronas. Mensagens síncronas são usadas quando o objeto cliente espera pela resposta do objeto Fornecedor antes de retomar a execução. Mensagens Assíncronas são usadas quando o objeto cliente não precisa esperar pela resposta do objeto Fornecedor. Para diferenciar entre mensagens síncronas e assíncronas, olhe para a ponta da seta. Se a ponta da seta é preenchida, então é síncrona. Se a ponta da seta é uma linha, então é assíncrona.

Timeout é usado quando o cliente abandona a mensagem se o objeto Fornecedor não responder em um dado período de tempo.

Desenvolvendo o Diagrama de Seqüência

Usamos o fluxo de eventos definidos em uma especificação de caso de uso, para ajudar-nos a definir os diagramas de seqüência. Como foi mencionado, a modelagem do comportamento é feita em nível de objeto em lugar de nível de classe. Isto significa que, para todo cenário definido no fluxo de eventos devemos ter um diagrama de seqüência. No exemplo seguinte, a adição bem sucedida do registro do atleta do Caso de Uso Adicionar Registro do Atleta, deverá ser usada. Neste caso, o fluxo básico é considerado.

1. Enfileirar os objetos participantes da análise no topo do diagrama. Como regra, sempre colocar o objeto de controle entre os objetos de limite e objetos de entidade. Lembrar que o objeto de controle serve como um intermediário entre estes tipos de objetos. De preferência, todos os atores são colocados ou no princípio ou fim da linha. Um exemplo é mostrado na Figura 16. Neste exemplo, foram identificados três objetos de análise e um ator. Especificamente, eles são AthleteR e c ordUI, A d d Athlete, Athlete e Club S taff. Observado que a classe de controle A d d Athlete está colocada entre os objetos AthleteR e c ordUI e Athlete. Serve como o objeto intermediário entre o limite e a entidade. O objeto Club S taff é o ator principal deste cenário.

Figura 16: Formação de Classes e Atores

2. Desenhar uma linha tracejada vertical abaixo de cada objeto para representar a linha de vida do objeto. A Figura 17 ilustra um exemplo;

Figura 17: Com Linha de Vida do Objeto


JEDITM

3. Desenhar as mensagens síncrona que ocorrem de um objeto para outro. Como regra, nenhuma mensagem deve ser enviada entre o objeto fronteira e o objeto entidade. Devem se comunicar indiretamente através do objeto de controle. Figura 18 mostra um exemplo.

Figura 18: Com Mensagens enviadas para os Objetos

Aqui, o objeto Club Staff entra com a informação do atleta e do guarda através do objeto de fronteira AthleteRecordUI enviando as mensagens enterAthleteData() e enterGuardianData(). Para dizer que um registro do atleta está salvo, o assistente do clube envia uma mensagem submitAthleteRecord() para o objeto de controle AddAthlete. Essa classe, para seguir o fluxo, envia uma mensagem, addAthlete(), para o objeto de entidade Athlete para que possa adicionar o registro.

4. Desenhar as mensagens de retorno. Um exemplo é exibido na Figura 19. O objeto de entidade Athlete retorna o estado de feito para o objeto de controle AddAthlete. Semelhantemente, o objeto de controle AddrAtleta retorna o estado de feito para o objeto de fronteira AthleteRecordUI.

Figura 19: Com Mensagens de Retorno


JEDITM

5. Enumerar as mensagens de acordo com a ordem cronológica de sua invocação. Figura 20 mostra um exemplo.

Figura 20: Com Números de Mensagem

A numeração das mensagens é como segue:

1. enterAthleteData()2. enterGuardianData()3. submitAthleteRecord()4. saveAthleteRecord()5. addAthlete()6. return done7. return done

6. Inserir nas mensagens as seguintes especificações: repetição, condições, lista dos parâmetros e tipo do retorno. Figura 21 mostra uns exemplos.

Figura 21: Com Mensagens Elaboradas

As mensagens elaboradas são como segue:


JEDITM

a) enterAthleteData() a mensagem foi elaborada para incluir os seguintes parâmetros: lastname, firstname, mi, address, postalCode, telephone, bday e gender.

b) enterGuardianData() a mensagem foi elaborada para incluir os seguintes parâmetros: lastname, firstname, mi, address, postalCode e telephone.

c) submitAthleteRecord() a mensagem foi elaborada para incluir os seguintes parâmetros: athlete e guardian, o objeto que representa as informações do atleta e responsável, respectivamente.

d) saveAthleteRecord() a mensagem foi elaborada para incluir os seguintes parâmetros: athlete e guardian, o objeto que representa as informações do atleta e responsável, respectivamente. Também, foram identificadas duas condições que devem ser verdadeiras para que a mensagem seja executada. Elas são [isAthleteInfoComplete = yes] e [isGuardianInfoComplete = yes], que significa que o registro do atleta é salvo somente se as informações do atleta e do responsável, estão completas.

e) addAthlete() a mensagem foi elaborada para incluir os seguintes parâmetros: athlete e guardian, o objeto que representa as informações do atleta e responsável, respectivamente.

7. Opcionalmente, podemos aprimorar o diagrama de seqüência utilizando a notação estendida. A Figura 22 mostra um exemplo.

Figura 22: Diagrama de Seqüência Estendido para Add Athlete Record

Este pode não ser o único diagrama de seqüência para o caso de uso Add Athlete Record. Outros cenários para este Caso de Uso são: informações incompletas do atleta, informações incompletas do responsável, recorde do atleta já existe, etc. Para cada cenário identificado, um diagrama de seqüência correspondente é criado.

Descrevendo o Diagrama de Colaboração

O Diagrama de Colaboração é utilizado para modelar um padrão de interação entre objetos. Ele modela a participação dos objetos nas interações pelas ligações entre cada um deles e pelas mensagens trocadas entre si. Ele valida o diagrama de classes demonstrando a necessidade para cada associação. Modela efetivamente a mensagem no objeto receptor, o que define uma interface


JEDITM

para aquele objeto. A Figura 23 mostra a notação do diagrama de colaboração.

Figura 23: Diagrama de Colaboração

A notação utilizada no Diagrama de Colaboração é similar ao Diagrama de Seqüência exceto que não modelamos as mensagens em ordem cronológica. Somente mostramos as interações das mensagens.

Desenvolvendo os Diagramas de Colaboração

Diagramas de Colaboração podem ser derivados dos Diagramas de Seqüência. Similarmente ao Diagrama de Seqüência, o nível do objeto é usado na modelagem. Conseqüentemente, para todo Diagrama de Seqüência, um Diagrama de Colaboração será criado. No exemplo a seguir, o cenário da adição bem sucedida de um registro de atleta do Caso de Uso Add Athlete (Adicionar Atleta) é usado.

1. Desenhar os atores e objetos participantes. Figura 24 mostra um exemplo.

Figura 24: Atores e Objetos

Novamente, os objetos da análise At hl et e R e c o r d UI, A d d At hl et e e At hl et e são usados com o Cl u b S t a ff.

2. Se os objetos trocam mensagens como mostrado nos Diagramas de Seqüência, desenhar uma linha conectando-os, o que significa uma associação. As linhas representam as ligações. Por exemplo, a Figura 25 demonstra um caso. O Cl u b S t a ff troca mensagens com o At hl et e R e c o r d UI. O At hl et e R e c o r d UI troca mensagens com o A d d Athl et e . E para terminar, o A d d Athl et e troca mensagens com o At hl et e .

Figura 25: Atores e Objetos com as ligações

3. Colocar as mensagens nas linhas de associação. É mostrado um exemplo na Figura 26. As mensagens são representadas como setas com a mensagem escrita sobre elas. Como exemplo, a mensagem número 1 é a mensagem enterAthleteData() com seus parâmetros correspondentes. A definição completa da mensagem deve ser escrita.


JEDITM

Figura 26: Diagrama de Colaboração para inclusão um registro Atleta

Este é o diagrama de colaboração do cenário realizado com sucesso para a inclusão de um Atleta no Caso de Uso Incluir Atleta. Similar ao Diagrama de Seqüência, o Diagrama de Colaboração é criado para cada seqüência que for identificada.

Passo 4: Para cada classe de análise resultante, identificar as responsabilidades.

Uma responsabilidade é algo que um objeto fornece a outros objetos ou atores. Pode ser uma ação que o objeto pode realizar ou um conhecimento que um objeto pode conter e fornecer a outros objetos. Pode ser derivado de mensagens obtidas de eventos ou diagramas de interação.

Nos diagramas de colaboração, as mensagens de entrada são a responsabilidade da classe. Para se obter as responsabilidades das classes de análise do Caso de Uso Incluir Atleta, precisamos utilizar os diagramas de colaboração. A Figura 27 mostra as responsabilidades das classes do Caso de Uso Incluir Atleta utilizando diagramas de colaboração. Neste exemplo, as responsabilidades são e n t e r Athl et e D at a (), e n t e r G u a r dia n D at a () e s u b mit Athl et e R e c o r d (). A responsabilidade de A d d At hl et e é s a v e A t hl et e R e c o r d (). Finalmente, as responsabilidades de At hl et e são a d d Athl et e (), e dit Athl et e (), d el e t e A t hl et e () e U p d at e S t atu s ().

Figura 27: Identificação da Responsabilidade


JEDITM

Para ajudar a identificar a responsabilidade da classe, utilize os seguintes guias.

1. Verificar se as classes têm responsabilidades consistentes. Se parecer que as responsabilidades são disjuntas, divida o objeto em duas ou mais classes. Atualizar os Diagramas de Seqüência e Colaboração para refletir as mudanças.

2. Verificar se existem classes com responsabilidades similares. Se houver classes com as mesmas responsabilidades, combine-as. Atualizar os Diagramas de Seqüência e Colaboração para refletir as mudanças.

3. A melhor distribuição das responsabilidades pode ser evidente ao se trabalhar com outro diagrama. Em tal caso, é melhor e mais fácil não modificar e não atualizar diagramas precedentes. Ajuste os diagramas sem pressa e corretamente, mas não fique ansioso tentando otimizar as interações da classe.

4. Não há nenhum problema se uma classe tiver uma responsabilidade, pergunte-se se é uma classe realmente necessária. É necessária para justificar sua existência?

Compilar todas as responsabilidades vistas em todos os Diagramas de Colaboração em uma única definição da classe.

Etapa 5: Para classes resultantes de cada análise, identificar os atributos.

Um atributo é uma informação que um objeto possui ou conhece sobre si mesmo. É usado para armazenar informação. Identificar atributos especifica a informação que uma classe de análise é responsável por manter. São especificados usando o seguinte formato:

atributo : tipo_de_dado = valor_padrão {constraints}

Tabela 7 dá a descrição de cada componente da especificação do atributo. O tipo de dados do atributo é requerido.

Componente do atributo Significadoatributo É o nome do atributo. Ao nomear um atributo certifique-se de que descreve

o valor que contém.

tipo_de_dado Especifica o tipo do atributo. Preferivelmente, use os tipos de dados definidos na Linguagem de Programação Java. Evite utilizar os tipos de dados definidos pelo usuário.

valor_padrão É o valor padrão conferido ao atributo quando um objeto é instanciado.

constraints Representa as restrições adicionais aplicadas aos valores possíveis do atributo tais como escalas numéricas.

Tabela 7: Especificações do atributo

Abaixo estão alguns exemplos de especificação de atributos.

1. NumeroConta: Numérico – um atributo nomeado NumeroConta contém um valor numérico.

2. Temperatura: Numérico {4 ca s a s decimais} – um atributo nomeado Temperatura contém um valor numérico com um formato de quatro casas decimais.

3. NumeroSequencia: Inteiro = 0 {atribuído s eqüencialmente pelo si stema} – um atributo nomeado Numero Sequencia contém um inteiro com um valor padrão igual a 0. Sucessivamente, lhe será conferido um número atribuído seqüencialmente pelo sistema.

Para ajudar a descobrir e especificar atributos, pode-se usar o roteiro abaixo.

1. Fontes de atributos possíveis são conhecimentos, exigências e glossário do domínio do sistema.

2. Atributos são usados no lugar de classes quando:• Somente o valor da informação, não sua posição, é importante.• A informação é possuída exclusivamente pelo objeto ao qual pertence; nenhum outro

objeto referencia a informação.• A informação é alcançada somente pelas operações que recuperam, alteram ou executam

transformações simples na informação; a mesma não tem nenhum comportamento real a


JEDITM

não ser o de fornecer seu valor.3. Se a informação tiver comportamento complexo, ou for compartilhada por dois ou mais

objetos, a mesma deve ser modelada como uma classe separada. 4. Atributos dependem do domínio.5. Atributos devem suportar pelo menos um caso do uso.

No exemplo da Figura 28, são mostrados os seguintes atributos identificados. Semelhante ao passo anterior, todos os atributos vistos nos diagramas de colaboração devem ser reunidos em uma única classe de análise. Como um exemplo, a análise classe Athlete tem os seguintes atributos: id, lastname, firstname, mi, address, postalCode, telephone, bday, gender, e status.

Figura 28: Identificação dos atributos

Passo 6: Para cada classe de análise resultante, identifique as associações.

Uma associação representa as relações estruturais entre objetos de classes diferentes. Conecta instâncias de duas ou mais classes em um momento de duração. Pode ser:

1. Associação Unária – relação de objetos da mesma classe.

2. Associação Binária – relação de dois objetos de classes diferentes.

3. Associação Ternária – relação de três ou mais objetos de classes diferentes.

A Figura 29 mostra exemplos dos tipos de associações. O primeiro exemplo mostra uma associação unária onde um gerente administra zero ou muitos empregados e um empregado está sendo administrado por um gerente. O segundo exemplo mostra uma associação binária onde um atleta pertence a zero ou a um time enquanto um time tem muitos atletas.

Figura 29: Tipos de Associações


JEDITM

Agregação é uma forma especial de associação que modela uma relação de parte-inteira entre um agregado e sua parte. Algumas situações onde uma agregação é apropriada são:

• Um objeto é fisicamente composto de outros objetos.

• Um objeto é uma coleção lógica de outros objetos.

• Um objeto contém outros objetos fisicamente.

Agregação é modelada na Figura 30 que mostra uma outra maneira de modelar o atleta e sua relação com o time. Um time é uma agregação de zero ou muitos atletas. O fim da ligação tem um símbolo na forma de diamante que representa “partes” ou “componentes” do agregado ou inteiro.

Figura 30: Agregação

Multiplicidade é o número de objetos de uma classe que podem ser associados com um objeto de outra classe. É indicado por uma expressão de texto na linha da associação. Responde às seguintes perguntas:

• A associação é opcional ou obrigatória?

• Qual é o número mínimo e máximo de instâncias que podem se conectar a uma instância de um objeto?

É possível que haja uma associação múltipla na mesma classe. Entretanto, devem representar o relacionamento entre objetos, distintos, da mesma classe. As especificações da multiplicidades são descritas na Tabela 8:

Multiplicidade DescriçãoNão especificado. Utilizado quando não se conhece o número de exemplos associados há um objeto.Somente um. Utilizado quando um único objeto está associado a outro.

Nenhum ou vários. Utilizado quando nenhum ou vários objetos estão associados com o outro. É chamada de associação opcional.

Um ou vários. Utilizado quando um ou vários objetos estão associado com outro.

Nenhum ou um. Utilizado quando nenhum ou um objeto está associado com outro. É conhecida, também, como associação imperativa.Escala Especificada. Utilizado quando o número dos objetos tiver um tamanho especifico.Múltiplo, Deslocado.

Tabela 8: Especificações de Multiplicidade

Para ajudar na identificação das associações, as seguintes instruções podem ser seguidas:

1. Começar estudando as ligações nos diagramas de colaboração. Eles indicam que classes necessitam comunicar-se;

2. Ligações reflexivas não necessariamente são instâncias de associações unárias. Um objeto pode emitir uma mensagem para ele mesmo. O relacionamento unário é necessário quando dois objetos da mesma classe necessitam comunicar-se;

3. Focar somente nas associações necessárias para compreender o caso do uso;4. Dê nome às associações, porém não use verbos ou nomes de funções;5. Faça uma breve descrição da associação para indicar como esta é usada, ou que

relacionamentos representa.

Em nosso exemplo, as associações identificadas são mostradas na Figura 31.


1

0..**

2,4..6

2-4

1..*

0..1

JEDITM

Figura 31: Identificação de Associação

Uma classe de fronteira AthleteRecordUI interage com apenas uma classe de controle AddAthlete. Uma classe de controle AddAthlete interage com apenas uma classe de entidade Athlete. Um Athlete tem apenas um Guardian e um Athlete Statu s . Um Athlete Status pode ser designado para zero ou mais Athletes.

Passo 7: Unificar classes de análise em um diagrama de classe.

Unificar classes de análise significa assegurar que cada classe de análise represente conceitos bem definidos, sem sobreposição de responsabilidades. É filtrar classes de análise para assegurar que um número mínimo de conceitos sejam criados.

Para ajudar na unificação de classes de análise em um único diagrama de classe, as seguintes linhas de direção podem ser usadas.

1. O nome da classe de análise deve capturar exatamente a função desempenhada pela classe no sistema. Deve ser único, e duas classes não devem ter o mesmo nome.

2. Una classes que tenham um comportamento semelhante.

3. Una classes de entidade que tenham atributos similares, mesmo se seus comportamentos definidos sejam diferentes; agregue os comportamentos das classes unificadas.

4. Quando uma classe é atualizada, qualquer documentação suplementar deve ser atualizada, quando necessário. Algumas vezes, uma atualização nos requisitos originais pode ser requerida. No entanto, isso deve ser controlado, pois os requisitos são o contrato com o usuário/cliente, e quaisquer mudanças devem ser verificadas e controladas.

5. Avalie o resultado. Tenha certeza que:

• As classes de análise atendem aos requisitos funcionais encontrados no sistema

• As classes de análise e seus relacionamentos são consistentes com a colaboração que eles


JEDITM

oferecem.Observando o diagrama de classe unificado, atributos e responsabilidades foram refinados para dar uma definição clara das classes. Lembre-se que classes de análise raramente sobrevivem depois da fase de projeto. O principal foco nesse ponto é que dados (como os representados pelos atributos) e as operações (como representado pelas responsabilidades) são representados e distribuídos pelas classes. Serão reestruturados e refinados durante a fase de projeto. Use a Lista de Validação que será discutido na seção seguinte para checar o Modelo de Análise. A Figura 32 mostra o diagrama de classe unificado de Cl u b M e m b e r s hi p M aint e n a n c e .

Fi g u ra 32 : Di a g ra m a d e C l a s s e d o C l u b M e m b e r s hi p M aint e n a n c e


JEDITM

5.3. Lista de validação do modelo de análise

Similar ao Modelo de Requisitos, uma validação é requerida. As perguntas a seguir podem ser usadas como direcionamento.

Modelo do objeto

1. Todas as classes analisadas são classificas, identificadas, definidas e documentadas?

2. O número de classes é razoável?

3. A classe tem um nome indicativo de seu papel?

4. As classes abstratas estão bem definidas?

5. Todos os atributos e responsabilidades estão bem definidos nas classes? São acoplados funcionalmente?

6. A classe pode ser requerida?

Modelo de Comportamento

1. Todos os cenários foram seguramente modelados? (Incluindo casos excepcionais)

2. A interação dos diagramas é clara?

3. Os relacionamentos são claros e consistentes?

4. As mensagens são bem definidas?

5. Todos os diagramas atendem às exigências?


JEDITM

6. Matriz de Rastreabilidade de Requisitos (MRR)

A Matriz de Rastreabilidade de Requisitos (MRR) é uma ferramenta para gerência de requisitos que pode ser usada não somente na engenharia de requisitos mas ao longo de todo processo de engenharia de software. Ela tenta tornar mais transparente ou “caixa-branca” a abordagem de desenvolvimento.

A abordagem “caixa-branca” se refere ao desenvolvimento dos requisitos do sistema sem considerar a implementação técnica daqueles requisitos. Da mesma forma como a UML, esta abordagem usa o conceito de perspectivas. Existem três, a saber, conceitual, de especificação e de implementação. Porém, em termos de requisitos, lidamos apenas com a conceitual e de especificação.

A Perspectiva Conceitual lida com os “conceitos de um domínio”. A Perspectiva de Especificação trata com as interfaces. Como um exemplo, conceitos dentro do domínio do estudo de caso são atletas, treinadores, equipes e times. Interfaces tratam com “como” os conceitos (elementos do sistema) interagem um com o outro tal como promovendo ou rebaixando um atleta.

6.1. Componentes da Matriz de Rastreabilidade de Requisitos

Existem muitas variações sobre os componentes que formam a MRR. Aqueles listados na Tabela 9 são os elementos iniciais recomendados da MRR.

Componente da MRR Descrição

MRR ID Um número identificador único para um requisito específico. Escolha um código que seja facilmente identificável.

RequisitosUma sentença estruturada descrevendo os requisitos no formato de “deve”, isto é, “o sistema deve...”, “ o usuário deve...” ou “um item selecionado deve...”

Notas Notas adicionais sobre o requisito.

Solicitante Pessoa que solicitou o requisito.

Data Data e hora que o requisito foi requisitado pelo requerente.

Prioridade Prioridade dada a um requisito. Pode-se usar um sistema de prioridade numérico, a Quality Function Deployment, ou a técnica MoSCoW.

Tabela 9: Componentes Iniciais da MRR

Enquanto os elementos acima são os iniciais da MRR, pode-se customizar a matriz para ligar os requisitos com outros produtos do trabalho ou documentos. Esta é realmente onde a potência da MRR é refletida. Pode-se adicionar outros elementos. Um exemplo é mostrado na Tabela 10.

Componente Adicional da MRR Descrição

MRR IDRelacionado

Especificar se o corrente MRR ID é direta ou indiretamente relacionado a outro requisito.

Especificação Trabalho (ET)

Descrever o que relaciona os requisitos diretamente a um parágrafo específico dentro da Especificação de Trabalho (ET). Uma ET é um documento que especifica a natureza do engajamento da equipe de desenvolvimento com seus clientes. Ela lista os produtos do trabalho e o critério que definirá a qualidade dos produtos do trabalho. Ela ajuda a guiar a equipe de desenvolvimento na sua abordagem para entrega dos requisitos.

Tabela 10: Componentes Adicionais da MRR

Os componentes e o uso da MRR devem ser adaptados para as necessidades do processo, do projeto e do produto. Eles crescem a medida que o projeto se desenvolve. Como engenheiros de


JEDITM

software, pode-se utilizar todos os componentes, remover componentes ou adicionar componentes quando houver necessidade.

Considere um exemplo da MRR para o desenvolvimento do sistema para a Liga Ang Bulilit: Club Membership Maintenance conforme mostrado na Tabela 11. A organização é centrada em caso de uso.

MRR ID Requisito Notas Solicitante Data Prioridade

Caso de Uso 1.0

O sistema deve ser capaz de manter informação pessoal de um atleta.

RJCS 12/06/05 Deve ter

Caso de Uso 2.0

O sistema deve ser capaz de permitir ao treinador mudar o estado de um atleta.


Caso de Uso 3.0

O sistema deve ser capaz de ver a informação pessoal do atleta. RJCS 12/06/05 Deve ter

Caso de Uso 1.1

O sistema deve ser capaz de adicionar um registro do atleta. RJCS 13/06/05 Deve ter

Caso de Uso 1.2

O sistema deve ser capaz de editar um registro do atleta. RJCS 13/06/05 Deve ter

Caso de Uso 1.3

O sistema deve ser capaz de excluir um registro do atleta. RJCS 13/06/05 Deve ter

Tabela 11: Exemplo Inicial da MRR (RTM - sigla em inglês) para a Manutenção dos Sócios do Clube


JEDITM

7. Métrica de Requisitos

Medir requisitos focaliza-se geralmente em três áreas: processo, produto e recursos. Os requisitos trabalham produtos que podem ser avaliados, olhando-se primeiro o número de requisitos. À medida que cresce o número, obtemos uma indicação de como o projeto de software é grande . o tamanho do requisito pode ser uma boa entrada para estimar o esforço de desenvolvimento de programa. Também, como os progressos de desenvolvimento de software, o tamanho de requisito pode ser capturado. Com o andamento do projeto e desenvolvimento, temos uma compreensão mais profunda do problema e a solução que poderia levar a descoberta dos requisitos que não são aparentes durante o processo de Engenharia de Requisitos.

Similarmente, pode-se medir o número de vezes que os requisitos mudaram. Um grande número de mudanças indica um pouco de instabilidade e incerteza em nossa compreensão do que o sistema deveria fazer ou como deveria se comportar. Em tal caso, os requisitos deveriam ser completamente compreendidos e, possivelmente, repetir a fase de engenharia de requisitos.

Os requisitos podem ser usados pelos projetistas e testadores. Podem ser usados para determinar se eles estão prontos para lhes ser entregues. O Teste de Perfil de Requisitos é uma técnica empregada para determinar a prontidão em entregar os requisitos aos projetistas ou testadores4.

Os projetistas são solicitados a avaliar cada requisito em uma escala de 1 a 5, baseado em um sistema como especificado em Tabela 12.

Taxa do Projeto de Sistema Descrição

1Significa que o projeto corresponde completamente aos requisitos, e requisitos similares foram solicitados em projetos anteriores. Logo, não terá problemas com este projeto.

2Significa que existem aspectos novos de requisitos ao projeto; entretanto, não são radicalmente diferentes de requisitos de projetos concluídos com sucesso em projetos anteriores.

3Significa que há aspectos de requisitos que são muito diferentes dos requisitos projetados anteriormente; entretanto, compreende-se e são confiáveis para desenvolver um bom projeto.

4 Significa que há partes de requisitos que não são compreendidas; não são confiáveis para o desenvolvimento de um bom projeto.

5 Significa que não é possível compreender estes requisitos e não se pode desenvolver um bom projeto com eles.

Tabela 12: Descrição da escala dos projetistas de sistema

Os testadores são solicitados a avaliar cada requisito em uma escala de 1 a 5 baseado em um sistema como especificado na Tabela 13.

Taxa de teste do sistema Descrição

1Significa que os requisitos foram compreendidos completamente, e que já foram testados requisitos similares em projetos anteriores; é provável que não existirão problemas em testar o código.

2Significa que existem alguns aspectos dos requisitos são novos ao projeto; entretanto, não são radicalmente diferentes dos requisitos testadas com sucesso em projetos anteriores.

3 Significa que alguns aspectos dos requisitos são muito diferentes dos requisitos testados anteriormente; entretanto, compreende-se e é confiável testá-los.

4 Pfleeger, Software Engineering Theory and Practice, pp. 178-179


JEDITM

Taxa de teste do sistema Descrição

4 Significa que existe alguns aspectos dos requisitos que não são compreensíveis; não é confiável que se planeje um teste para este requisito.

5 Significa que este requisito não é compreensível e não pode ser desenvolvido.

Tabela 13: Descrição da escala de verificação do sistema

Se o resultado do perfil de requisitos resultar em 1 ou 2, os requisitos podem ser passados aos projetistas e testadores. Se não, os requisitos necessitam ser reescritos. Será necessário retornar à fase de Engenharia de Requisitos.

A avaliação é subjetiva. Entretanto, as contagens podem oferecer informações úteis que irão incentivar a qualidade dos requisitos antes que o projeto prossiga.


JEDITM

8. Exercícios

8.1. Criar o Modelo de Exigências

1. Criar um Modelo de Exigências do Sistema de Informação Técnica

• Desenvolver os Diagramas de Caso de Uso

• Para cada Caso de Uso, desenvolver a Especificação do Caso de Uso

• Criar o Glossário

2. Criar um Modelo de Exigências do Sistema de Manutenção Squad & Team

• Desenvolver os Diagramas de Caso de Uso

• Para cada caso de uso, desenvolver a Especificação do Caso de Uso

• Criar o Glossário

8.2. Criar o Modelo de Análise

1. Criar um Modelo de Análise do Sistema de Informação Técnica

• Desenvolver os Diagramas de Seqüência de todo o cenário definido nas especificações de Caso de Uso

• Criar o Diagrama de Colaboração para cada Diagrama de Seqüência

• Criar o Diagrama de Classes das classes analisadas

2. Criar o modelo de análise do Sistema de Manutenção Squad & Team

• Desenvolver o Diagrama de Seqüência de todo o cenário definido na especificação de Caso de Uso

• Criar os Diagramas de Colaboração para cada Diagrama de Seqüência

• Criar o Diagrama de Classes para as classes analisadas

8.3. Atribuição do Projeto

O objetivo da atribuição do projeto é reforçar o conhecimento e habilidades adquiridas neste capítulo. Particularmente, são estas:

1. Desenvolver o modelo de exigências

2. Desenvolver o modelo de análise

3. Desenvolver a matriz de rastreabilidade de requisitos

PRINCIPAIS TRABALHOS PRODUZIDOS:

1. O Modelo de Requisitos

• Diagrama de Caso de Uso

• Especificação de Caso de Uso

2. O Modelo de Análise

• Diagrama de Classes

• Diagrama de Seqüência

• Diagrama de Colaboração

3. Lista de Ações

4. Matriz de Rastreabilidade de Requisitos



Lição 4Engenharia de Projetos


JEDITM

1. Objetivos

Exigências distintas de engenharia que criam modelos com foco na descrição de dados, função e comportamento, engenharia de projeto focada na criação de representações ou modelos que estão concentrados na arquitetura do software, estrutura de dados, interfaces e componentes que são necessários para implementação do software. Neste capitulo iremos aprender os conceitos e princípios dos projetos, projetos de dados, projetos de interface, projetos de nível de componentes. Iremos aprender quais elementos do RTM são modificados e adicionados para localizar produtos de trabalho através de requerimentos. A métrica de projetos também será discutida.


• Aprender os conceitos e dinâmicas da engenharia de projeto• Aprender a como desenhar a arquitetura de um software• Aprender como desenvolver o modelo de dados • Aprender a como desenhar interface, particularmente, as telas e diálogos• Aprender a como projetar os componentes de um software • Aprender a como utilizar os requisitos de rastreamento • Aprender sobre as Métricas de Projeto


JEDITM

2. Conceito de Engenharia de projetos

Engenharia de projeto é fase que mais desafia a experiência de engenheiros de software no desenvolvimento de projetos. É necessário criatividade para formulação de produtos ou sistemas onde os requisitos (obtidos do usuário final pelo desenvolvedor) e o aspecto técnico são unidos. É a última fase da engenharia de software que cria modelos, configura o estágio final da construção e testes.

Nela são usadas várias técnicas e princípios com a finalidade de definir um dispositivo, processo ou sistema, em detalhe suficiente permitir sua construção física.

Produz um modelo de projeto que traduz o modelo de análise dentro de um impressão suficiente para construir e testar um software.

O projeto de processos é um trabalho interativo de refinamento, tendendo de um alto nível de abstração para um baixo nível de abstração. Cada representação deve ser localizada antes de uma exigência específica como documentado no RTM para assegurar qualidade do projeto. Especificamente, o projeto deve:

• implementar explicitamente todas as especificações como inserido no modelo de análise e, ao mesmo tempo, todas as exigências implícitas desejadas pelo usuário final ao desenvolvedor;

• seja legível e compreensível por quem gerar o código;

• proveja acima de tudo uma ilustração do software sobre a perspectiva dos dados, função e comportamento de uma perspectiva da implementação.

Pressman sugestiona uma lista de diretrizes de qualidade como as enumeradas abaixo1.

1. O projeto deverá ter uma arquitetura reconhecível que seja criada usando estilos arquitetônicos conhecidos ou padrões que consistem em bons componentes de projeto e isso pode ser criado de uma maneira evolutiva.

2. O projeto deve ser modular e logicamente particionado em subsistemas e elementos.

3. O projeto deve consistir em uma única representação de dados, arquitetura, interfaces e componentes.

4. O projeto da estrutura de dados deverá conduzir ao projeto das classes apropriadas que são derivadas de padrões de projetos (design patterns) conhecidos.

5. O projeto de componentes deverá ter características de funcionalidades diferentes.

6. O projeto deverá ter interfaces que reduzam a complexidade das ligações entre componentes e o ambiente.

7. O projeto é derivado de usos de métodos repetitivos para obter informações durante a fase de engenharia de requisitos.

8. O projeto deverá usar uma notação que indique seu significado.

As diretrizes anteriores levam a um bom projeto devido a aplicação de princípios fundamentais de projetos, metodologia sistemática e revisão completa.

2.1. Conceitos de projeto

Os conceitos de projeto fornecem ao engenheiro de software uma base na qual podem ser aplicados métodos de projeto. Provê um ambiente de trabalho (framework) necessário para criação de certos produtos do trabalho.

2.1.1. Abstração

Quando projetamos um sistema modular, muitos níveis de abstração são usados. Como engenheiros de software, definimos níveis diferentes de abstrações quando projetamos este documento sobre software. No nível mais alto de abstração, declaramos uma solução que usa termos abrangentes. Quando interagimos em um nível mais baixo de abstração, é definida uma

1 Pressman, Software que Cria a Aproximação de Um Médico, page262-263,


JEDITM

descrição detalhada. São criados dois tipos de abstrações, isto é, de dados e processuais.

Abstração de dados se refere a coleções de dados que descrevem a informação requerida pelo sistema.

Abstração processual se refere a seqüências de comandos ou instruções que estão limitadas a ações específicas.

2.1.2. Modularidade

Modularidade é a característica do software que permite o gerenciamento do desenvolvimento e manutenção. O software é decomposto em pedaços chamados de módulos. Possuem nomes e componentes endereçáveis que, quando unidos, trabalham juntos satisfazendo requisitos. Projetos são modularizados de forma que podemos facilmente desenvolver um plano de incremento do software, acomodando facilmente as alterações testes e depuração efetiva e manutenção do sistema com pequenos efeitos colaterais. Em aproximação a orientação a objetos eles são chamados de classes.

Modularidade conduz a ocultar informação. Informações que escondem meios, que escondem os detalhes do módulo (atributos e operações) ou classificam de tudo outros que não têm nenhuma necessidade por tal informação. Módulos ou classes se comunicam com interfaces, mas , obrigam o acesso aos dados através de processos. Isto limita ou controla a propagação das mudanças, ocorrência de erros quando terminamos as modificações nos módulos ou classes.

Modularidade sempre leva a independência funcional. Independência funcional é a característica dos módulos ou classes que endereçam a funções específicas definidas pelos requisitos. É alcançada definindo-se módulos que fazem uma única tarefa ou função e têm justamente uma interação com outros módulos. Bons projetos usam dois critérios importantes: coesão e acoplamento.

Acoplamento é o grau de interconectividade entre os objetos representado pelo número de ligações que um objeto tem e pelo grau de interação com os outros objetos. Para a orientação a objetos, dois tipos de acoplamento são utilizados.

1. Acoplamento por Interação é a medida do número de tipos de mensagem que um objeto envia a outro objeto, e o número de parâmetros passado com estes tipos de mensagem. Um bom acoplamento por interação é conseguido com um mínimo possível para evitar mudança através da interface.

2. Acoplamento por Herança é o grau que uma subclasse de fato necessita das características (atributos e operações) herdadas da sua classe base. Um número mínimo de atributos e operações que são herdados desnecessariamente.

Coesão é a medida com que um elemento (atributo, operação ou classe dentro de um pacote) contribui para um único propósito. Para projetos orientados a objetos, são utilizados três tipos de coesão.

1. Coesão de operações é o grau que uma operação enfoca um único requisito funcional. O bom projetista produz operações altamente coesas.

2. Coesão de classes é o grau que uma classe enfoca um único requisito.

3. Coesão especializada endereça a semântica coesão de herança. A definição de herança deve refletir verdadeiramente o melhor compartilhamento sintático da estrutura.

2.1.3. Refinamento

Refinamento é também conhecido como o processo de elaboração. O refinamento da completa abstração permite à engenharia de software especificar o comportamento e os dados de uma classe ou módulo, contudo, suprime o detalhamento de níveis baixos. Isto ajuda a engenharia de software a criar um completo modelo evolutivo do projeto. O refinamento auxilia a engenharia de software a descobrir detalhes no avanço do desenvolvimento.


JEDITM

2.1.4. Refatoramento

Refatoramento é a técnica que simplifica o projeto dos componente sem várias das funcionalidades e comportamentos. Este é um processo de variação de software de modo que o comportamento externo fica o mesmo e a estrutura interna é melhorada. Durante a refatoração, o modelo de projeto é checado em busca de redundâncias, elementos de projeto não utilizados, ineficiência ou algoritmos desnecessários, mal construção ou estruturas de dados inadequadas ou um outro projeto falho. Estes são corrigidas para produzir um melhor projeto.

2.2. Modelo de Projeto

O trabalho produzido na fase de Engenharia de Projeto é o Modelo de Projeto que consiste de projeto de arquitetura, projeto de dados, projeto de interface e projeto a nível de componentes.

2.2.1. Projeto de arquitetura

Refere-se à total estrutura do software. Isto inclui o caminho no qual fornece a integridade conceitual para o sistema. Representa camadas, subtipos e componentes. Este é o modelo utilizado no diagrama de pacotes da UML.

2.2.2. Projeto de dados

Refere-se ao projeto e à organização dos dados. As classes de entidades são definidas na fase de engenharia de requisitos e são refinadas para criar o projeto da lógica do banco de dados. Classes persistentes são desenvolvidas para acessar dados do servidor de banco de dados. Este é modelado é usado no diagrama de classes.

2.2.3. Projeto de interface

Refere-se ao projeto da interação do sistema com o seu ambiente, particularmente, os aspectos da interação humana. Isto inclui os diálogos e projeto de telas. Relatórios e formas de layouts são incluídos. Este utiliza o diagrama de classes e o diagrama de transição de estados.

2.2.4. Projeto a nível de componentes

Refere-se ao projeto do comportamento interno de cada classe. De particular interesse são as classes de controle. Este é muito importante para o projeto pois as funcionalidades requeridas são representadas pelas classes. Este utiliza o diagrama de classes e o diagrama de componentes.

2.2.5. Projeto a nível de implementação

Refere-se ao projeto de como o software poderá ser implementado para uso operacional.

Software executável, subsistemas e componente são distribuídos para o ambiente físico que suporte o software. O diagrama implementação poderá ser utilizado para representar este modelo.


JEDITM

3. Arquitetura de Software

Não existe uma definição geral aceita para o termo Arquitetura de Software. É interpretado diferentemente em relação ao contexto. Alguns podem descrever em termos de estruturas de classes pelo modo que são agrupados. Outros costumam descrever toda organização de um sistema em um subsistema. Buschmann define da seguinte forma:

“A arquitetura de software descreve um subsistema e os componentes de um software e as relações entre eles. Subsistemas e componentes são tipicamente especificados de diferentes visões para mostrar as propriedades funcionais e não funcionais de um sistema. A arquitetura de software de um sistema é um artefato. Sendo o resultado da atividade de projeto do software”.

Esta definição é discutida neste capítulo. A arquitetura de software é uma camada estruturada dos componentes de software e pela maneira ao qual estes componentes interagem, bem como a estrutura de dados utilizada por estes componentes. Isso envolve tomar decisões em como a aplicação é construída e, normalmente, controla o desenvolvimento iterativo e incremental.

Definir a arquitetura é importante por diversas razões. Primeiro, a representação da arquitetura de software permite a comunicação entre os envolvidos (usuários finais e desenvolvedores). Segundo, permite projetar as decisões que terão um efeito significativo em todo produto do trabalho da engenharia de software referente à interoperabilidade da aplicação. Por último, fornecem uma visão intelectual de como o sistema é estruturado e como os componentes trabalham em conjunto.

É modelado usando um Diagrama de Pacote da UML. Um pacote é um elemento de modelo que pode conter outros elementos. Também é um mecanismo utilizado para organizar os elementos do projeto e permitir que os componentes de software possam ser modularizados.

3.1. Descrevendo o Diagrama de Pacote

O Diagrama de Pacote mostra de forma particionada um grande sistema em agrupamentos lógicos de pequenos subsistemas. Apresenta um agrupamento de classes e dependências entre elas. Uma dependência existe entre dois elementos caso as mudanças para definição de um elemento possa causar alteração em outros elementos. A Figura 1 mostra a notação básica de um diagrama de pacote.

Figura 1: Notação Básica para o Diagrama de Pacote

Pacotes são representados como pastas. Se um pacote é representado como um subsistema, o estereótipo de um subsistema é indicado por (<<subsistema>>). As dependências são representadas por setas pontilhadas sendo o indicador da seta uma linha aberta. Como no exemplo, o Subsistema Cliente é dependente do Subsistema Fornecedor. Os pacotes são realizados por interfaces. A interface pode ser canônica, como representado por um círculo descrito pela Interface do Subsistema Cliente, ou pode ser uma definição de classe como descrito pela Interface do Subsistema Fornecedor (estereotipo é <<interface>>). Observa-se que o relacionamento de um pacote é ilustrado com um linha pontilhada sendo o indicador da seta um triângulo sem preenchimento interno.


Subsistema Cliente

<<subsistema>>

Subsistema Fornecedor

<<subsistema>><<interface>>

SubsistemaFornecedorInterface

Pacote

RepresentaçãoCanônica

Representação de Classe

Dependência Realiza

JEDITM

3.2. Subsistemas e Interfaces

Um subsistema é a combinação de um pacote (também pode conter outros elementos de modelo) e uma classe (que possui comportamento e interage com outros elementos do modelo). Pode ser utilizado para particionar o sistema em partes que possibilite ser independentemente ordenado, configurado e entregue. Permite que os componentes sejam desenvolvidos de modo independente enquanto as interfaces não se alterem. Pode ser implantado através de um conjunto computacional distribuído (cluster/grid) e alterados sem quebrar outras partes do sistema, além de prover um controle restrito da segurança por meio de recursos chaves.

Tipicamente agrupa elementos do sistema para compartilhar propriedades comuns. Encapsula o conjunto de responsabilidades de forma inteligível para poder assegurar sua integridade e sua capacidade de manutenção. Como exemplo, um subsistema pode conter interfaces de interação homem-máquina que lidam como as pessoas interagem com a aplicação. Outro subsistema poderia lidar com o gerenciamento dos dados.

As vantagem de se definir um subsistema são as seguintes:

• Permitir o desenvolvimento em unidades menores..

• Aumentar a reusabilidade de componentes.

• Permitir que os desenvolvedores lidem com as partes complexas do sistema.

• Facilitar o suporte as manutenções.

• Prover a portabilidade.

Cada subsistema deve ter um limite claro e interfaces bem definidas com outros subsistemas.

Suporta portabilidade: Cada subsistema deve ter fronteiras claras e interfaces totalmente definidas com outros subsistemas.

Interfaces definem um conjunto de operações que são executadas por um subsistema. Permite a separação da declaração de comportamento da execução do comportamento. Servem como um contrato para ajudar na independência do desenvolvimento dos componentes por um time de desenvolvedores e garante que os componentes trabalhem em conjunto. A especificação da interface define a natureza precisa da interação dos subsistemas com o resto do sistema, mas não descreve a sua estrutura interna.

Figura 2: Subsistemas e Interfaces

Conforme mostrado na Figura 2, uma interface é composta por um ou mais subsistemas. Este é o segredo de ter componentes plug-and-play. A implementação do subsistema pode mudar sem mudar drasticamente outros subsistemas, desde que a definição da interface não mude.

Cada subsistema provê serviços para outros subsistemas. Há dois estilos de uso de subsistemas de comunicação; eles são conhecidos como comunicação cliente-servidor e comunicação ponto-


Interface

x()w()

Classe A1

x()

Classe A2

w()

<<subsistema>>Subsistema A

Classe B1

w()y()

Classe B2

X()

<<subsistema>>Subsistema B

Classe B3

z()

JEDITM

a-ponto. Eles são mostrados na Figura 3.

Figura 3: Estilos de Comunicação de Subsistemas

Numa comunicação cliente-servidor, o subsistema cliente precisa conhecer a interface do subsistema servidor. A comunicação é somente num sentido. O subsistema cliente requisita serviços do subsistema servidor; nunca ao contrário. Na comunicação ponto-a-ponto, cada subsistema conhece a interface do outro subsistema. Nesse caso, o acoplamento é mais forte. A comunicação acontece nos dois sentidos, uma vez que qualquer dos subsistemas pode requerer serviços dos outros.

Em geral, a comunicação cliente-servidor é mais simples de implementar e manter, uma vez que o acoplamento não é tão forte como na comunicação ponto-a-ponto.

Há duas abordagens na divisão de programas em subsistemas. Elas são conhecidas como de camadas e de particionamento. A de camadas enfoca os subsistemas como se representados por diversos níveis de abstração ou camadas de serviço, enquanto que a de particionamento enfoca os diferentes aspectos da funcionalidade do sistema como um todo. Na prática, ambas as abordagens são usadas de forma que alguns subsistemas são definidos em camadas e outros em partições.

As camadas de arquiteturas são comumente utilizadas para estruturas de alto nível num sistema. A estrutura geral é detalhada na Figura 4.

Figura 4: Estruturas Gerais da Camada de Arquitetura

Cada camada da arquitetura representa um ou mais subsistemas que podem diferenciar-se entre si pelos diferentes níveis de abstração ou por abordagem diferente de sua funcionalidade. A camada superior solicita serviços da camada inferior a ela. Essas camadas, por sua vez, podem utilizar serviços da próxima camada. Em uma Arquitetura em Camadas Abertas, subsistemas podem requisitar serviços de camadas abaixo. Para Arquitetura em Camadas Fechadas, camadas requisitam serviços de camadas diretamente abaixo delas e não podem pular camadas.

Arquitetura em Camadas Fechadas minimiza dependências entre camadas e reduz o impacto da mudança de interface de qualquer camada. Arquitetura em Camadas Abertas possibilita um desenvolvimento de códigos mais compactos pois serviços de todas as camadas de baixo nível são


Layer 1

Layer 2

Layer n-1

Layer n

. . .

Open Architecture

Layer 1

Layer 2

Layer n-1

Layer n

. . .

Closed Architecture

JEDITM

acessados diretamente por qualquer camada acima sem necessidade de programação de código extra para passagem de mensagens através de camadas intervenientes. Por outro lado, há uma quebra no encapsulamento das camadas, aumentando as dependências entre as camadas e a dificuldade de alteração quando uma camada precisar ser modificada.

Algumas camadas, dentro de uma arquitetura de camadas, podem ser decompostas por causa de sua complexidade. O particionamento é obrigatório na definição dos componentes decompostos. Como exemplo, considere a Figura 5.

Figura 5: Exemplo de Camada e Particionamento

Utiliza uma arquitetura de quatro camadas. Consiste no seguinte:

1. Camada de Banco de Dados. Responsável pelo armazenamento e recuperação de informações do repositório. No exemplo, banco de dados Atleta.

2. Camada de Domínio. Responsável pelos serviços ou objetos que são compartilhados pelas diferentes aplicações. Especificamente utilizada em sistemas distribuídos. Neste exemplo, é o Domínio Atleta.

3. Camada de Aplicação. Responsável em executar aplicações que representam a lógica do negócio. No exemplo, representada pelos subsistemas de manutenção e pesquisa de Atleta.

4. Camada de Apresentação. Responsável pela apresentação dos dados ao usuário, dispositivos ou outros sistemas. No exemplo, representada pelos subsistemas HCI de manutenção e pesquisa de Atleta.

3.2.1. Um Exemplo de Arquitetura em Camada

Arquiteturas em camadas são utilizadas amplamente na prática. Java 2 Enterprise Edition (J2EETM) adota uma abordagem multi-camada e um catálogo de padrões associado tem sido desenvolvido. Esta seção mostra uma introdução da plataforma J2EE.

A plataforma J2EE representa um padrão para implementação e distribuição de aplicações coorporativas. É projetada para fornecer suporte no lado cliente e no lado servidor no desenvolvimento de aplicações distribuídas e multi-camadas. Aplicações são configuradas como segue:

1. Client-tier provê a interface do usuário que suporta um ou mais tipos de cliente, tanto fora como dentro de um firewall corporativo.

2. Middle-tier módulos que fornecem serviços de cliente através de containers WEB na camada WEB e serviços de componentes de lógica de negócio através de Enterprise JavaBean (EJB) Container na camada EJB.

3. Back-end provê os sistemas de informações coorporativas para o gerenciamento de dados que é suportado por APIs padrões.

A Figura 6 descreve os vários componentes e serviços que formam um típico ambiente J2EE.


Athlete Database

Athlete Domain

Athlete Maintenancesubsystem

Athlete Findsubsystem

Athlete HCI Maintenance subsystem

Athlete HCI Findsubsystem

JEDITM

Figura 6: Arquitetura Java 2 Enterprise Edition (J2EE)

Para maiores detalhes referentes à plataforma J2EE, acesse o site, http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e para aprender como projetar aplicações corporativas.

3.3. Desenvolvendo o Projeto de arquitetura

Na construção da arquitetura do software, os elementos de projeto são agrupados em pacotes e subsistemas. Interfaces são definidas. Os relacionamentos dentro desses são ilustrados pela definição de dependências. Como um exemplo, O modelo de análise do Sistema de Manutenção de Sócios de Clube será usado como foi desenvolvido no capítulo anterior.

PASSO 1: Se o modelo de análise ainda não foi validado, validar o modelo de análise.

devemos assegurar que os atributos e responsabilidades são distribuídos para as classes, e assegurar que uma classe define uma única abstração lógica e local. Se existem problemas com o modelo de análise, regresse à fase de requesitos da engenharia. Pode ser usado o checklist de validação do modelo de análise.

PASSO 2: Análise relacionada do pacote de agrupamento das classes.

Como foi mencionado anteriormente, pacotes são mecanismos que nos permitem agrupar modelos de elementos. Decisões de empacotamento são baseadas no critério de empacotamento com um número diferente de fatores que incluem configurações unitárias, alocação de recursos, agrupamento de tipos de usuários, e representação de um produto e serviço existente utilizado pelo sistema. A seguir, veremos um guia de como agrupar classes.

3.3.1. Guia de Empacotamento de Classes

1. Empacotamento de classes limite

• Se os sistemas de interface são parecidos para serem alterados ou substituídos, as classes limite deveriam ser separadas do restante do projeto.

• Se nenhuma mudança da interface principal for planejada, as classes limite deveriam ser colocadas juntamente com a entidade e classes de controle com as quais estão funcionalmente relacionadas.

• Classes de limites mandatórias que não são funcionalmente relacionadas com qualquer entidade ou classes de controle, estão agrupadas separadamente.


Cliente

Cliente

Cliente

Cliente

Firewall

Web Container

(Servlets, JSPPages, HTML,

XML)

Enterprise JavaBean(EJB)

Container

(Session Bean,Entity Bean,

Message-drive Bean)

JNDI,JMS,

JavaMail EntepriseInformation

Systems

(RDBMS,ERP,

LegacyApplications)

Cliente Intermediário EIS

http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e

JEDITM

• Se a classe limite é relacionada em um serviço opcional, agrupe-os em um subsistema separado com as classes que colaboram para prover o serviço mencionado. Desta forma, o subsistema é mapeado para um componente opcional da interface, podendo prover o serviço usando a classe limite.

2. Funcionalidade de Empacotamento das Classes Relacionadas

• Se uma mudança em uma única classe afeta uma mudança em outra classe, elas são funcionalmente relacionadas.

• Se a classe é removida do pacote e tem grande impacto para o grupo de classes, a classe é funcionalmente relacionada às classes impactadas.

• Duas classes são funcionalmente relacionadas se elas possuem um grande número de mensagens que podem enviar para uma outra.

• Duas classes são funcionalmente relacionadas se elas interagem com o mesmo ator, ou são afetadas pelas mudanças realizadas pelo mesmo ator.

• Duas classes são funcionalmente relacionadas se possuem relacionamento entre si.

• Uma classe é funcionalmente relacionada a outra classe que cria uma instância sua.

• Duas classes que são relacionadas a atores diferentes não deveriam estar no mesmo pacote.

• Classes mandatórias e opcionais não deveriam estar na mesma classe.

Após tomar a decisão de como agrupar as classes de análise, as dependências do pacote são definidas. Dependências de Pacote são também conhecidas como visibilidade. Estas definem o que é e não é acessível dentro do pacote. Tabela 1 demonstra os símbolos de visibilidade que são colocados junto ao nome da classe dentro do pacote.

Visibilidade dos Símbolos

Descrição

+ Representa um elemento do modelo público que pode ser acessado fora do pacote.

- Representa um elemento do modelo privado que não pode ser acessado fora do pacote.

# Representa elementos do modelo protegido que pode ser acessado através do proprietário do elemento do modelo ou através da herança.

Tabela 1: Visibilidade dos Símbolos do Pacote

Um exemplo de visibilidade do pacote é ilustrado na Figura 7. Classes dentro do pacote podem colaborar com uma outra. Dessa forma, elas são visíveis. Com exemplo, classes no Pacote A, tais como ClassA1, ClassA2 e ClassA3, podem colaborar com uma outra desde que a mesma resida no mesmo pacote. Entretanto, quando classes residem em pacotes diferentes, elas são inacessíveis a menos que tenham sido definidas como públicas. ClassB1 é visível porque é definida como pública. ClassB2, por outro lado, não é visível.

Figura 7: Visibilidade do Pacote


JEDITM

Acoplamento de Pacote define de que modo dependências são definidas entre pacotes. Devem aderia às mesmas regras.

1. Pacotes não podem ser acoplado em cruz

2. Pacotes em camadas inferiores não devem ser dependente de pacotes de uma camada superior. Camadas serão discutida em um dos passos.

3. Em geral, pacotes não devem pular camadas. Entretanto, exceções podem ser feitas e devem ser documentadas.

4. Pacotes não devem ser dependente de subsistemas. Eles devem ser dependentes de outros pacotes ou de interfaces de subsistema.

A decisão de empacotamento para o Sistema de Manutenção de Sócios do Clube é ilustrada na Figura 8.

Figura 8: Decisão de empacotamento do Sistema de Manutenção de Sócios de Clube

PASSO 3: Identificando o projeto de Classes e Subsistemas

As classes da análise são exploradas para determinar se podem ser projetos de classes ou subsistemas. É possível que as classes da análise sejam expandidas, dobradas, combinadas e removidas do projeto. Nesse ponto, decisões tem que ser tomadas sobre as seguintes perguntas:

• Quais classes da análise são realmente classes? Quais que não são?

• Quais classes da análise são subsistemas?

• Quais componentes existentes? Quais componentes precisam de ser desenhados e implementados?

Uma classe da análise é uma classe de projeto se ela é uma classe simples ou se representa uma lógica de abstração única. Se uma classe da análise é complexa, pode ser refinada para tornar-se:

• uma parte de outra classe

• uma classe agregada

• um grupo de classes que herdam de uma mesma classe

• um pacote

• um subsistema

• uma associação ou relacionamento entre elementos de design


JEDITM

A seguir algumas orientações para auxiliar na identificação de subsistemas.

1. Colaboração do Objeto. Se os objetos de uma classe colaboram somente entre si e a colaboração produz um resultado visível, eles deverão fazer parte de um subsistema.

2. Opcionalidade. As associações entre classes são opcionais ou características que podem ser removidas, melhoradas ou substituídas por outras alternativas, encapsule as classes dentro de um subsistema.

3. Interface do Usuário. A divisão de classes boundary e classes entity relacionadas, em subsistemas separados é chamado subsistema horizontal enquanto que o agrupamento de todas em um subsistema é chamado subsistema vertical. A decisão por subsistemas horizontais ou verticais depende do acoplamento entre interfaces do usuário e as entidades. Se classes boundary são utilizadas para exibir informações de classes entidade, a escolha é pelo subsistema vertical.

4. Ator. Se dois atores diferentes utilizam a mesma funcionalidade de uma classe, modele dois subsistemas diferentes para permitir que cada ator possa mudar seus requisitos independentemente.

5. Acoplamento e Coesão de Classe. Organize classes com alto grau de acoplamento dentro de subsistemas. Separe em linhas os acoplamentos fracos.

6. Substituição. Represente diferentes níveis de serviços de um recurso particular como subsistemas separados, todos devem implementar a mesma interface.

7. Distribuição. Se uma funcionalidade deve residir em um nó particular, assegure que aquela funcionalidade do subsistema esteja mapeada dentro de um nó individual.

8. Volatilidade. Encapsule dentro de um subsistema todas as classes que podem mudar num período de tempo.

Os possíveis subsistemas são:

1. Classes da Análise que fornecem serviços complexos ou utilitários e boundary classes.

2. Produtos existentes ou sistemas externos tais como software de comunicação, suporte ao acesso à base de dados, tipos e estruturas de dados, utilitários e aplicações específicas.

No caso do Sistema de Manutenção de Associados do Clube, os subsistemas inicialmente identificados são as classes boundary AthleteRecordUII, ViewAthleteUI e UpdateStatusUI.

PASSO 4: Definição da interface dos subsistemas.

Interfaces são grupos de operações (públicas) visíveis externamente. Em UML, elas não contém estrutura interna, atributos, associações ou detalhes da implementação das operações. Elas equivalem a uma classe abstrata que não tem atributos, associações e possuem somente operações abstratas. Elas permitem a separação da declaração do comportamento de sua implementação.

Intefaces definem um conjunto de operações que são realizadas por um subsistema. Servem como um contrato que ajuda no desenvolvimento independente de componentes pela equipe de desenvolvimento e assegura que os componentes poderão trabalhar em conjunto.

A Figura 9 mostra os subsistemas definidos para o Sistema de Manutenção dos Sócios do Clube. A interface está definida pela inserção de um estereótipo <<interface>> no compartimento do nome da classe. Para diferenciá-la de uma classe boundary, o nome da classe de interface começa com a letra 'I'. A Aplicação do Subsistema implementa a Interface IAthletRecordUI.


JEDITM

Figura 9: Identificação de Subsistemas no Sistema de Manutenção de Sócios do Clube

PASSO 5: Camada de subsistemas e classes.

A definição de camadas da aplicação é necessária para realizar de modo organizado o projeto e desenvolvimento do software. Elementos de Projeto (classes e subsistemas) precisam ser alocados em camadas específicas da arquitetura. Em geral, a maioria das classes de apresentação tendem a aparecer no nível mais alto, classes de controle no nível intermediário e classes entidade aparecem abaixo. Este estrutura é conhecida como arquitetura em três camadas e é mostrada na Figura 10.

Figura 10: Arquitetura em Três Camadas

Há muitos estilos e padrões de arquitetura que são mais complexos e detalhados do que a simples arquitetura de três camadas. Normalmente, são projetados baseando-se nas exigências tecnológicas, tais como, o sistema a que será distribuído/utilizado, se o sistema suporta a simultaneidade, se o sistema está considerando uma aplicação baseada na WEB. Para simplificar, este estudo de caso usa a arquitetura de três camadas. Quando as classes dentro das camadas são elaboradas, há chances de camadas e pacotes adicionais serem usados, definidos e refinados.

Os tópicos a seguir são um guia prático para definir as camadas de uma arquitetura:

1. Considere a visibilidade. As dependências entre classes e subsistema ocorrem somente dentro da camada atual e da camada diretamente abaixo dela. Passando disto, a dependência deve ser justificada e documentada;

2. Considere a volatilidade. Normalmente, as camadas superiores são afetadas por mudanças


ApresentaçãoLógica de Negócio

Base de Dados

JEDITM

nas exigências, enquanto as camadas mais baixas são afetadas pela mudança do ambiente e da tecnologia;

3. Número de camadas. Os sistemas pequenos devem ter 3 ou 4 camadas, enquanto sistemas maiores devem ter de 5 a 7 camadas.

Para o Sistema de Manutenção dos Sócios do Clube, as camadas são descritas na Figura 11. Observe que as classes de análise que estão identificadas como subsistemas são substituídos por uma definição de interface do subsistema. Para esclarecimento, a realização da interface não é demonstrada.

Figura 11: Definindo as Camadas do Sistema de Manutenção dos Sócios do Clube

3.4. Lista de Verificação e Validação da Arquitetura do Software

Como qualquer outro produto de trabalho, a Arquitetura do Software deve ser validada. Use as seguintes perguntas como um checklist.

Camadas:

1. Para sistemas menores, há mais de quatro camadas?

2. Para sistemas maiores, há mais de sete camadas?

Subsistemas e Interfaces:

1. A divisão dos subsistemas está feita de maneira lógica e consistente através da arquitetura do software?

2. O nome da interface descreve o papel do subsistema dentro do sistema principal?

3. A descrição da interface é concisa e clara?

4. Todas as operações que o subsistema necessita para executar estão identificadas? Há alguma operação ausente?

Pacotes

1. Os nomes dos pacotes estão descritivos?

2. A descrição dos pacotes combina com suas responsabilidades?


JEDITM

4. Padrões de Projeto

Padrões de projeto (Design Patterns) descrevem soluções comprovadas para problemas recorrentes. Isto alavanca o conhecimento e o entendimento de outros desenvolvedores. Eles são soluções reusáveis para problemas comuns. Endereçam problemas individuais mas podem ser combinados de diferentes formas para obter uma solução integrada para um sistema inteiro.

Padrões de projeto não são frameworks. Frameworks são sistemas de software parcialmente completos que podem ser utilizados em um tipo específico de aplicação. Um sistema aplicativo pode ser customizado para as necessidades da organização pela complementação dos elementos incompletos e adição de elementos específicos da aplicação. Isso envolveria a especialização de classes e a implementação de algumas operações. É, essencialmente, uma mini-arquitetura reusável que provê uma estrutura e um comportamento comum a todas as aplicações deste tipo.

Padrões de projeto, por outro lado, são mais abstratos e gerais do que os frameworks. São uma descrição do modo que um problema pode ser resolvido, mas não é, em si, a solução. Não pode ser diretamente implementado; uma implementação exitosa é um exemplo de um padrão de projeto. É mais primitivo do que um framework. Um framework pode usar vários padrões; um padrão não pode incorporar um framework.

Padrões podem ser documentados usando-se vários templates alternativos. O template padrão determina o estilo e estrutura da descrição do padrão, e este varia na ênfase que eles colocam sobre diferente aspectos do padrão. Em geral, uma descrição de padrão inclui os seguintes elementos:

1. Nome. O nome de um padrão deve ser significativo e refletir o conhecimento incorporado pelo padrão. Pode ser uma simples palavra ou uma frase curta.

2. Contexto. O contexto de um padrão representa as circunstâncias ou pré-condições sob as quais ele pode ocorrer. Deve ser bastante detalhado para permitir que a aplicabilidade do padrão seja determinada.

3. Problema. Provê uma descrição do problema que o padrão endereça. Identifica e descreve os objetivos a ser alcançados dentro de um específico contexto e forças restritivas.

4. Solução. É a descrição dos relacionamentos estático e dinâmico entre os componentes do padrão. A estrutura, os participantes e suas colaborações são todas descritas. Uma solução deve resolver todas as forças em um dado contexto. Uma solução que não resolve todas as forças, é falha.

O uso de padrões de projeto requer uma cuidadosa análise do problema que deve ser resolvido e o contexto no qual ele ocorre. Todos os participantes da equipe de desenvolvimento devem receber treinamento adequado. Quando um projetista está contemplando o uso de padrões de projeto, certos itens devem ser considerados. As seguintes questões provêem um guia para resolver estes itens.

1. Existe um padrão que endereça um problema similar?

2. O padrão dispara uma solução alternativa que pode ser mais aceitável?

3. Existe uma outra solução mais simples? Não devem os padrões ser usados apenas porque foram criados?

4. O contexto do padrão consistente com aquele do problema?

5. As conseqüências de uso do padrão são aceitáveis?

6. As restrições impostas pelo ambiente de software conflitariam com o uso do padrão? Como usamos o padrão?

Os seguintes passos fornecem um guia para o uso de um padrão de projeto selecionado.

1. Para obter uma visão geral completa, leia o padrão.

2. Estude a estrutura, os participantes e as colaborações do padrão em detalhe.

3. Examine as amostras de código para ver o padrão em uso.


JEDITM

4. Nomeie os participantes do padrão (isto é, Classes) que são mais significativas para a aplicação.

5. Defina as classes.

6. Escolha nomes específicos da aplicação para as operações.

7. Codifique ou implemente as operações que desempenham responsabilidades e colaborações dentro do padrão.

É importante notar neste momento que um padrão não é uma solução prescritiva para o problema. Ele deve ser visto como um guia sobre como encontrar uma solução adequada para um problema.

Como um exemplo, existe um conjunto de padrões de projeto comuns para a plataforma J2EE. Este seção discute de forma abreviada alguns deste padrões. Para encontrar mais sobre Padrões de Projeto para J2EE, é possível verificar neste endereço WEB:

http://java.sun.com/blueprints/patterns/index.html

4.1. Composite View

4.1.1. Contexto

O Padrão Composite View permite o desenvolvimento de uma visão mais gerenciável através da criação de um template para manusear os elementos de página comuns de uma visão. Para uma aplicação web, uma página contém uma combinação de conteúdos dinâmicos e elementos estáticos tais como cabeçalho, rodapé, logomarca, background e assim por diante. O template captura as características comuns.

4.1.2. Problema

Dificuldade de modificar e gerenciar o layout de múltiplas visões devido à duplicação de código. Páginas são construídas usando código de formatação diretamente sobre cada visão.

4.1.3. Solução

Use este padrão quando uma visão é composta de múltiplas sub-visões. Cada componente do template pode ser incluído dentro do todo e o layout da página pode ser gerenciado independentemente do conteúdo. Esta solução prove a criação de uma visão composta através da inclusão e substituição de componentes dinâmicos modulares.

Ele promove a reusabilidade de porções atômicas da visão pelo encorajamento de um projeto modular. É usado para gerar páginas contendo a visualização dos componentes que podem ser combinados numa variedade de modos. Este cenário ocorre para uma página que mostra diferentes informações ao mesmo tempo, tal como as encontradas em home pages de muitos endereços na web, onde é possível encontrar notícias, informações sobre o tempo, cotações de ações, etc.

Um benefício de usar este padrão é que o projetista da interface pode prototipar o layout da página, conectando conteúdo estático em cada componente durante o desenvolvimento do projeto.

Um benefício do uso deste padrão é que o projetista de interfaces pode desenvolver o protótipo do layout da página adicionando conteúdos estáticos em cada componente. Com o progresso do desenvolvimento do projeto, o conteúdo estático é substituído pelas sub-visões (subview) atômicas.

Este padrão tem um inconveniente. Há uma sobrecarga (overhead) associada a ela. É um meio termo entre flexibilidade e performance. Figura 12 mostra um exemplo de um layout de página. A página consiste das seguintes visões (views).


JEDITM

Figura 12: Exemplo do padrão Composite View

Este formulário pode ser uma tela web da aplicação e é definida no arquivo a seguir:

<screen name=� main� > <parameter key=� banner� value=� /cabecalho.jsp� /> <parameter key=� footer� value=� /rodape.jsp� /> <parameter key=� sidebar� value=� /barraLateral.jsp� /> <parameter key=� body� value=� /conteudo.jsp� /></screen>

A Figura 13 mostra o diagrama de classes que representa o padrão enquanto a Figura 14 mostra a colaboração das classes.

Figura 13: Diagrama de Classes do padrão Composite View

Figura 14: Diagrama de Seqüência do padrão Composite View

A Tabela 2 descreve as responsabilidades de cada uma das classes.

Classe DescriçãoCompositeView É uma agregação de múltiplas visões (views).ViewManager Gerencia a inclusão de porções dos fragmentos do template dentro da composição da


JEDITM

Classe Descriçãovisão.

IncludedView É uma sub-visão, uma porção atômica de uma visão maior e mais completa. Esta visão (includeView) pode consistir em várias visões.

Tabela 2: Classes do Padrão Composite View

4.2. Front Controller

4.2.1. Contexto

O padrão Front Controller provê um controlador centralizado para administrar pedidos. Recebe todo o cliente que chega com um requisito, envia cada pedido para um manipulador de pedido apropriado e apresenta uma resposta apropriada para o cliente.

4.2.2. Problema

O sistema precisa de um ponto de acesso centralizado para manipulação do pedido na camada de apresentação e apoiar a integração de recuperação de dados do sistema, administração da visão e navegação. Quando alguém tiver o acesso à visão, diretamente, e sem passar por um manipulador de pedido centralizado, podem acontecer problemas como:

• Cada visão pode prover seu próprio serviço de sistema que pode resultar em duplicação de código.

• A navegação de visão é de responsabilidade da camada de visão e pode resultar em conflito com o conteúdo e a navegação de visão.

Adicionalmente, controle distribuído é mais difícil manter pois freqüentemente serão feitas mudanças em lugares diferentes no software.

4.2.3. Solução

Um controlador é utilizado como um ponto de contato inicial para controlar um pedido. É usado para administrar a manipulação de serviços como invocar serviços de segurança para autenticação e autorização, enquanto delega o processo empresarial, administrando a visão apropriada, controlando erros e administrando a seleção de estratégias de criação de conteúdo. Centraliza os controles de decisão e construção. São mostrados os Dagrama de Classe e Seqüência para este padrão na Figura 15 e Figura 16.

Figura 15: Diagrama de Classe do padrão Front Controller

Figura 16: Diagrama de Seqüência do padrão Front Controller


JEDITM

As regras para as classes estão listadas na Tabela 3.

Class Description

Controller É o ponto de contato inicial para controlar todos os pedidos no sistema. Pode delegar um objeto de Helper.

Dispatcher É responsável pela administração da visão e navegação, administra a escolha da próxima visão para apresentar ao usuário e o mecanismo para vetorização controlada como um recurso. Pode ser encapsulado dentro de um controlador ou um componente separado que trabalha em coordenação com o controlador. Usa o objeto RequestDispatcher e encapsula alguns métodos adicionais.

Helper É responsável por auxiliar uma visão ou o controlador completa do processo. Possui numerosas responsabilidades que incluem junção de dados requeridos pela visão e armazenando de dados no modelo intermediário.

View Representa e exibe informação ao cliente.

Tabela 3: Classes do padrão Front Controller

Como exemplo de implementação de um Front Controller, um servlet pode ser utilizado para representar o controlador. Um trecho do código é mostrado abaixo. No método processRequest(), um objeto do tipo RequestHelper (Helper) é utilizado para executar o comando que representa a requisição do cliente. Depois do comando ser executado, um objeto RequestDispatcher é utilizado para se obter a próxima visão.

catch (Exception e) { request.setAttribute(resource.getMessageAttr(), "Exception occurred: " + e.getMessage()); page=resource.getErrorPage(e); } // Seqüência da Mensagem 2 no exemplo do Diagrama de Seqüência. // Envia o controle para a visão dispatch(request, response, page); ... ... private void dispatch(HttpServletRequest request, HttpServletResponse response, String page) throws javax.servlet.ServletException, java.io.IOException { RequestDispatcher dispatcher = getServletContext().getRequestDispatcher(page); dispatcher.forward(request,response); }}

4.3. Data Access Object (DAO)

4.3.1. Contexto

O Padrão de Projeto Data Access Object (DAO) separa a interface cliente de seu mecanismo de acesso a dados. Ele adapta o acesso a um recurso de dados específico a uma interface cliente genérica. Ele permite trocar o mecanismo de acesso a dados independentemente do código que os utiliza.

4.3.2. Problema

Os dados podem ser provenientes de diferentes mecanismos de acesso tais como bancos de dados relacionais, mainframe ou sistemas legados, serviços externos B2B, LDAP, etc. Este mecanismo pode variar dependendo do tipo de armazenamento. Permite manutenibilidade do código através da separação do mecanismo de acesso das camadas de visão e processamento. Quando o tipo de armazenamento muda, basta mudar o código que especifica o mecanismo de acesso.


JEDITM

4.3.3. Solução

Utilizar o padrão Data Access Object para abstrair e encapsular todo o acesso a fonte de dados. Deve ser implementado o mecanismo de acesso necessário para manipular a fonte de dados. A fonte de dados pode ser um sistema de banco dados relacional, um serviço externo como B2B, um repositório LDAP etc.

O diagrama de classes deste padrão é descrito na Figura 17.

Figura 17: Diagrama de Classes para o padrão Data Access Object (DAO)

A Tabela 4 mostra as classes que são utilizadas na persistência.

Classe Descrição

Business Object Representa os dados do cliente. É o objeto que requer acesso à fonte de dados para obter e armazenar os dados.

DataAccessObject É o objeto primário deste padrão. Ele abstrai a implementação de acesso aos dados para os BusinessObjects, e assim deixa o acesso transparente à fonte de dados.

DataSource Representa a fonte de dados que pode ser um RDBMS, OODBMS, arquivo XML ou um arquivo texto. Pode também ser outro sistema (legado ou mainframe), serviço B2B ou um repositório LDAP.

TransferObject Representa o transportador dos dados. É utilizado para retornar os dados para o cliente ou o cliente pode utilizá-lo para atualizar os dados na fonte de dados.

Tabela 4: Classes do Padrão de Projeto Data Access Object (DAO)

O Diagrama de Seqüência deste padrão é ilustrado na Figura 18.


JEDITM

Figura 18: Objeto de Acesso a Dados (Data Access Object - DAO) Diagrama de Seqüência

A visão dinâmica mostra as interações entre as classes que compõem esse padrão. Especificamente, quatro interações podem ser observadas no diagrama acima. As interações estão listadas abaixo.

1. Um BusinessObject precisa criar um DataAccessObject para um determinado DataSource. Isto é necessário para recuperar ou armazenar dados do negócio. No diagrama, é a mensagem número 1.

2. Um BusinessObject deve requisitar a recuperação de dados. Isto é feito através do envio de uma mensagem getData() para o DataAccessObject o qual, deverá requisitar a fonte de dados (data source). Um TransferObject é criado para manter os dados recuperados do DataSource. No diagrama, é representado pela mensagem número 2 e suas sub-mensagens.

3. Um BusinessObject deve modificar o conteúdo do TransferObject. Isto simula a modificação dos dados. No entanto, os dados ainda não são modificados na fonte de dados. Isso é representado pelas mensagens número 3 e 4.

4. Para salvar dados na fonte de dados, uma mensagem setData() deve ser enviada para o DataAccessObject. O DataAccessObject recupera os dados do TransferObject e prepara-o para ser atualizado. Apenas agora, ele irá enviar a mensagem setData() para a DataSource atualizar seus registros.

4.3.4. Estratégia do Objeto de Acesso a Dados

O padrão DAO pode ser desenvolvido de forma bastante flexível adotando o Padrão Abstract Factory e o Padrão Factory Method. Se o meio de armazenamento envolvido não estiver sujeito a mudanças de uma forma de implementação para outra, o padrão Factory Method pode ser usado. O diagrama de classe é apresentado na Figura 19.

Figura 19: Estratégia Factory Method

Se o meio de armazenamento envolvido for sujeito a mudança de uma forma de implementação para outra, o padrão Abstract Factory pode ser usado. Ele pode crescer aos poucos e utilizar a implementação do Factory Method. Nesse caso, essa estratégia disponibiliza um objeto fábrica DAO abstrata que pode construir vários tipos de fábricas DAOs concretas. Cada fábrica suporta diferentes tipos de persistência de armazenamento. Quando uma fábrica concreta é obtida para uma implementação específica, ela é usada para produzir DAOs suportados e implementados nessa implementação. O diagrama de classe é representado na Figura 20.


JEDITM

Figura 20: Padrão Abstract Factory

Neste digrama de classees, DAOFactory é uma abstração de um objeto Data Access Factory que é herdado e implementado por diferentes DAOFactories para suportar o acesso de armazenamento específico da implementação. Os DAOFactories concretos criam objetos de acesso a dados que implementam as interfaces de objetos data access.

Um exemplo de uma implementação de uma DAOFactory é mostrado através dos códigos abaixo. O primeiro código mostra a definição de uma classe abstrata DAOFactory.

public abstract class DAOFactory { //Lista de tipos DAO public static final int DEFAULT = 1; public static final int MYSQL = 2; public static final int XML = 3; ... ... // As fábricas concretas devem implementar estes métodos. public abstract AthleteDAO getAthleteDAO(); public abstract AthleteStatusDAO getAthleteStatusDAO(); ... ... public static DAOFactory getDAOFactory(int whichFactory) { switch(whichFactory) { case DEFAULT: return new DefaultDAOFactory(); case MYSQL: return new MySQLDAOFactory(); case XML: return new XMLDAOFactory(); ... default: return null; } }}

Cada um dos tipos identificados de DAO deve ser implementado. Neste exemplo, o DefaultDAOFactory é implementado; o outro é similar à exceção dos recursos específicos de cada implementação tais como drivers, database URL etc.

// Implementação padrão do DAOFactoryimport java.sql.*;public class DefaultDAOFactory extends DAOFactory {


JEDITM

public static final String DRIVER = “sun.jdbc.odbc.JdbcOdbcDriver”; public static final String URL = “jdbc:odbc:AngBulilitLiga”; ... ... // método para a conexão public static Connection createConnection() { // Utilize o DRIVER e a URL para criar a conexão ... } public AthleteDAO getAthleteDAO() { // DefaultAthleteDAO implementa AthleteDAO return new DefaultAthleteDAO; } public AthleteStatusDAO getAthleteStatusDAO() { // DefaultAtleteStatusDAO implementa AthleteStatusDAO return new DefaultAthleteStatusDAO; } ...}

AthleteDAO é uma definição de interface e é codificado como segue:

//Interface para todo AthleteDAOpublic interface AthleteDAO { public int insertAthlete(Athlete a); public int deleteAthlete(Athlete a); public int updateAthlete(Athlete a); public Athlete findAthleteRecord(String criteria); public RowSet selectAthlete(String criteria); ...}

A classe DefaultAthleteDAO implementa todos os métodos da interface AthleteDAO. O esqueleto do código desta classe é mostrado abaixo.

import java.sql.*;public class DefaultAthleteDAO implements AthleteDAO { public DefaultAthleteDAO() { //inicialização } public int insertAthlete(Athlete a) { // Executa a inserção dos dados do atleta aqui. // retorna 0 se bem sucedido ou -1 se não. } public int updateAthlete(Athlete a) { // Executa a modificação dos dados do atleta aqui. // retorna 0 se bem sucedido ou -1 se não. } public int deleteAthlete(Athlete a) { // Executa a exclusão dos dados do atleta aqui. // retorna 0 se bem sucedido ou -1 se não. } ... ...}

O objeto de transferência Athlete é implementado usando o seguinte código. É utilizado pelo DAO para emitir e receber dados da base de dados.

public class Athlete { private int athleteID; private String lastName; private String firstName; // Outros atributos de atleta inclui Guardian

// encapsulamento dos atributos


JEDITM

public void setAthleteID(int id) { athleteID = id; } public int getAthleteID() { return athleteID; } ...}

Uma parte do código do cliente que mostra o uso de um objeto de uma classe é mostrada abaixo.

... ... // cria a DAO Factory necessária DAOFactory dFactory = DAOFactory.getDAOFactory(DAOFactory.DEFAULT); // Cria a AthleteDAO AthleteDAO = athDAO = dFactory.getAthleteDAO(); ... // Insere um novo atleta // Assume que atleta é uma instância de AthleteTransferObject int status = athDAO.insertAthlete(ath);

4.4. Model-View-Controller

4.4.1. Problema

As aplicações corporativas precisam suportar múltiplos tipos de usuário através de vários tipos de interfaces. Para uma aplicação isto requer um HTML a partir de cada cliente WEB, um WML para cada cliente wireless, uma Interface Java Swing para os administradores e um serviço baseado em XML para os fornecedores. Isto exige que o padrão obedeça o que segue abaixo:

• Os mesmos dados corporativos precisam ser acessados por diferentes visões.

• Os mesmos dados corporativos precisam ser atualizados através de diferentes interações.

• O suporte a múltiplos tipos de visões e interações não devem causar impacto nos componentes que integram o núcleo da funcionalidade da aplicação da empresa.

4.4.2. Contexto

A atual aplicação apresenta conteúdo aos usuários em numerosas páginas contendo vários dados.

4.4.3. Solução

O Model-View-Controller (MVC) é um padrão de projeto amplamente utilizado para aplicações interativas. Ele divide funcionalidade entre objetos envolvidos na manutenção e apresentação de dados para minimizar o grau de acoplamento entre estes objetos. É dividido em três partes chamadas model (modelo), view (visão) e controller (controle).

1. Model (modelo). Representa os dados corporativos e as regras de negócio que governam o acesso e a alteração a estes dados. Serve como um software aproximador do processo no mundo real, isto é, como aplicação das técnicas de modelagem para simplificar o mundo real quando da definição do modelo.

2. View (visão). Traduz o conteúdo de um modelo. Acessa os dados corporativos através do modelo e especifica como estes dados são apresentados aos atores. É responsável pela manutenção da consistência em sua apresentação quando há alterações no modelo em espera. Ele pode ser acionado através do modelo push, onde as visões registram a si próprias no modelo para as notificações de alterações, ou do modelo pull, onde a visão é responsável por chamar o modelo quando se faz necessário a recuperação do dado atual.

3. Controller (controlador). Traduz interações com a visão dentro das ações executadas pelo model (modelo). Em uma GUI de um cliente stand-alone aparecem para poder controlar os


JEDITM

pressionamentos de botões ou seleções em menus. Em uma aplicação WEB, aparecem como requisições HTTP do tipo GET e POST. As ações executadas sobre o modelo podem ativar dispositivos, processos de negócio ou mudar o estado do modelo.

A Figura 21 mostra o Padrão de Projeto Model-View-Controller.

Figura 21: Padrão de Projeto MVC

As estratégias pelas quais o MVC pode ser implementado são as seguintes:

• Para clientes baseados em WEB como os navegadores, usar Java Server Pages (JSP) para renderizar a visão, Servlet como controlador, e os Enterprise JavaBeans (EJB) como o modelo.

• Para controlador Centralizado, ao invés de se ter vários servlets como controladores, um servlet principal é usado para fazer o controle mais gerenciável. O padrão Front Controller pode ser um padrão útil para esta estratégia.


MODELO

Representa os dados de negócio. Representa lógica

de negócio. Mantém o estado da aplicação.

CONTROLADOR

Define o comportamento daaplicação. Transfere comandos do usuário para alterações do

Modelo. Seleciona Visões para apresentação.

VISÃO

Exibe o modelo. Acessa dados de negócio. Transmite as ações dos

usuários para o Controlador

Pesquisa Estado

Mudança de Estado

Seleciona Visão

Notifica Mudança

Ações do Usuário

Chamada de MétodoEvento

JEDITM

5. Projeto de Dados

Também conhecido como arquitetura de dados, é uma tarefa de engenharia de software que cria um modelo dos dados em uma representação mais próxima da implementação. As técnicas usadas aqui se aproximam do campo de estudo de análise e projeto de banco de dados, normalmente discutida em um curso de banco de dados. Não discutiremos como fazer análise, projeto e implementação de bancos de dados. Para este curso, assumiremos que o banco de dados foi implementado usando o sistema relacional. O projeto lógico do banco de dados é ilustrado usando o diagrama de classes da Figura 22.

Figura 22: Projeto Lógico do Banco de Dados da Liga Ang Bulilit

Para o Sistema de Manutenção de Sócios do Clube, três tabelas foram definidas. A tabela Atleta contém os dados do atleta. A tabela Responsável (Guardian) contém os dados referentes ao responsável pelo atleta. Para simplificar, assume-se que só existe um responsável por atleta. A tabela StatusAtleta contém o esquema de códigos para o status do atleta.

Para acessar os dados em um sistema de banco de dados, nossos programas devem ser capazes de se conectar ao servidor de banco de dados. Esta seção discute o conceito de persistência e ensina como modelar classes de persistência. Em termos da nossa arquitetura de software, outra camada, a camada de persistência, é criada sobre a camada de banco de dados.

Persistência significa fazer que um elemento exista mesmo após a finalização da aplicação que o criou. Para classes que precisam gerar objetos persistentes, precisamos identificar:

• Granularidade. É o tamanho do objeto persistente.

• Volume. É o número de objetos para manter persistente.

• Duração. Define quanto tempo manter o objeto persistente.

• Mecanismo de Acesso. Define se o objeto é mais ou menos constante, isto é, se permitimos modificações ou atualizações.

• Confiança. Define como o objeto sobreviverá se um erro acontecer.


JEDITM

Há muitos padrões de desenho que podem ser utilizados para modelar a persistência. Serão discutidos dois padrões de persistência nas próximas seções.

5.1. Padrão JDBC

Esta seção discute o padrão de uso do mecanismo persistente escolhido para a Administração do Sistema do Banco de Dados Relacional (Relational Database Management System - RDBMS) que são classes Java Database Connectivity (JDBC). Há duas visões para este padrão, estática e dinâmica.

5.1.1. Visão estática do Padrão de Projeto de Persistência

A visão estática é um modelo de objeto do padrão. Ilustrado através do Diagrama de Classe. Figura 23 mostra o padrão para as classes persistentes.

Figura 23: O Padrão JDBC e Static View

Tabela 5 mostra as classes que são usadas neste padrão.

Classe Descrição

PersistentClient Classe que pede dados para o banco de dados. Normalmente, estas são classes de controle que perguntam algo de uma classe de entidade. Trabalha com um DBClass.

DBClass Classe responsável para ler e escrever dados persistentes. Também é responsável para ter acesso o banco de dados de JDBC que usa a classe de DriverManager.

DriverManager Classe que devolve uma conexão ao DBClass. Uma vez que uma conexão esteja aberta o DBClass pode criar declaração de SQL que será enviada ao RDBMS subjacente e será executada usando a classe Statement.

Statement Classe que representa uma declaração de SQL. A declaração de SQL é a linguagem de acesso ao dados do banco de dados. Qualquer resultado devolvido pela declaração de SQL é colocado na classe ResultSet.

ResultSet Classe que representa os registros devolvidos por uma consulta.

PersistentClassList Classe utilizada para devolver um conjunto de objetos persistentes como resultado de uma consulta ao banco de dados. Um registro é equivalente a um PersistentClass na lista.

Tabela 5: Classes do Padrão JDBC

DBClass é responsável por criar outro exemplo de classe persistente. Isto é entendido como


JEDITM

mapeamento OO para RDBMS. Possui o comportamento para conectar com RDBMS. Toda classe que precisa ser persistente terá um DBClass correspondente.

Visão dinâmica do Padrão de Persistência

A visão dinâmica do padrão de persistência mostra como as classes da visão estática interagem umas com as outras. O Diagrama de Seqüência é utilizado para ilustrar este comportamento dinâmico. Há vários comportamentos dinâmicos que são visto neste padrão, especificamente, eles são JDBC Initialization, JDBC Create, JDBC Read, JDBC Update e JDBC Delete.

1. JDBC Initialization. A inicialização deve acontecer antes que qualquer classe persistente possa ter acesso. Significa que a pessoa precisa estabelecer conexão com o RDBMS subjacente. Envolve o seguinte:

• Carga do driver apropriado

• Conexão com o banco de dados

O Diagrama de Seqüência da inicialização do JDBC é mostrado na Figura 24.

Figura 24: Inicialização JDBC

A DBClass carrega o driver apropriado chamando o método getConnection(url, usuario, senha). Esse método procura estabelecer uma conexão de acordo com a URL do banco de dados. O DriverManager tenta selecionar o driver apropriado a partir do conjunto de driver JDBC registrado.

2. JDBC Create. Esse comportamento cria um registro. Executa um comando INSERT da SQL. Isso assume que a conexão foi estabelecida. O Diagrama de Seqüência é mostrado na Figura25.

Figura 25: Criação JDBC

Descrição do Fluxo do Diagrama de Seqüência:

• O PersistentClient solicita a DBClass para criar uma nova classe.

• A DBClass cria uma nova instância da PersistentClass(new()) e atribui os valores para a PersistentClass

• A DBClass então, cria uma nova expressão usando createStatement() da Connection.

• O Statement é executado via método executeUpdate(String):int. Um registro é inserido no


JEDITM

banco de dados.

3. JDBC Read. Esse comportamento obtêm registros do banco de dados. Executa um SELECT da SQL. Isso também assume que a conexão foi estabelecida. O Diagrama de Seqüência é mostrado na Figura 26.

Figura 26: JDBC Read

• O PersistentClient pergunta à DBClass para obter registros do banco de dados. A String searchCriteria considera quais registros devem ser retornados.

• A DBClass cria um Statement a partir do comando SELECT utilizando o método createStatement() da Connection.

• O Statement é executado via executeQuery() e retorna um ResultSet.

• A DBClass instancia uma PersistentClassList para guardar os registros representados no ResultSet.

• Para cada registro no ResultSet, a DBClass instancia uma PersistentClass.

• Para cada campo do registro, atribui o valor do campo (getString()) para o atributo apropriado na PersistentClass(setData()).

• Depois de obter todos os dados e mapear-los para os atributos da PersistentClass, adiciona a PersistentClass em uma PersistentClassList.

4. JDBC Update. Executa um comando UPDATE da SQL. Isso muda os valores de um registro no banco de dados. Isso assume que uma conexão foi estabelecida. O Diagrama de Seqüência é mostrado na Figura 27.

Figura 27: JDBC Update

• PersistentClient solicita ao DBClass (classe de banco de dados) a atualização de registro.


JEDITM

• O DBClass recupera os dados apropriados do PersistentClass (classe permanente ou constante). O PersistentClass deve fornecer a rotina do acesso para todos os dados existentes que o DBClass necessita. Isto fornece o acesso externo a determinados atributos constantes que seriam de outra maneira confidenciais. Este é o preço que se paga, para extrair o conhecimento existente fora da classe que os encapsula.

• A conexão criará uma declaração UPDATE (comando de atualização).

• Uma vez que o comando é construído, a atualização estará sendo executada e a base de dados é atualizada com os dados novos da classe.

5. JDBC Delete. Executa o comando DELETE (comando de exclusão) do SQL. Elimina os registros na base de dados. Ele assume que a conexão foi estabelecida.

O Diagrama de Seqüência é mostrado na Figura 28.

Figura 28: JDBC Delete

• Client solicita ao DBClass para deletar o registro.

• O DBClass cria um comando DELETE e executa o método executeUpdate().

5.2. Desenvolvendo o modelo de projeto dos dados.

No desenvolvimento do modelo de projeto de dados, um modelo deve ser realizado. No seguinte exemplo, usaremos o JDBC para modelar o projeto dos dados da sociedade de um clube.

PASSO 1: Definir a visão estática dos elementos de dados que necessitam ser modelados

Usando a ferramenta de molde de projeto , modelamos as classes de colaboração.Figura 29 O DBAthlete é a classe utilizada para conexão e execução dos comandos SQL. Outras classes, PCLAthlete, Athlete e Guardian.

Figura 29: Visão estática do DBAthlete


JEDITM

PASSO 2: Modelar todo comportamento das classes em um Diagrama de Seqüência.

Todas as Visualizações dinâmicas do JDBC devem ser modeladas para determinar como as DBClasses e as Classes Persistentes irão colaborar usando os Diagramas de Seqüência. Os Diagramas que se seguem ilustram as funções JDBC de Leitura (Figura 30), Criação (Figura 31), Atualização (Figura 32) e Exclusão (Figura 33).

Figura 30: DBAthlete JDBC Read

Figura 31: JDBC Create DBAthlete


JEDITM

Figura 32: JDBC Update DBAthlete

Figura 33: JDBC Delete DBAthlete

PASSO 3: Documentar as definições das classes de de dados.

Identifique os atributos e operações de cada classe. Veja os exemplos na Figura 34.

Figura 34: Definição da Classe Athlete e das classes persistentes


JEDITM

PASSO 4: Modificar a arquitetura do software para incluir os dados das classes.

Deve estar na camada de banco de dados. Em sistemas simples, esta se torna parte da camada de lógica empresarial. É possível modificar decisões tomadas. Neste momento, classes de entidade são substituídas pelo DBClasses, Classes Persistentes e Projeto de Banco de Dados. A modificação é mostrada na Figura 35.

Figura 35: Modificação da Arquitetura de software para o Modelo de Dados


JEDITM

6. Projeto de interface

É interessante lidar com elementos projetados para facilitar a comunicação do software com os humanos, dispositivos e outros sistemas que inter-operam entre si. Nesta seção, poderemos concentrar em projetados de elementos que interagem com as pessoas, particularmente, formulários de pré-impressão, relatórios e telas.

Um bom projeto de formulários, relatórios e telas são críticos para determinar como o sistema será aceito pelo usuário final, estabelecendo o seu sucesso ou fracasso. Com a Engenharia de Software, queremos diminuir a ênfase em relatórios e formulários e aumentar a ênfase em telas.

Quando usamos relatórios?

• Relatórios são utilizados para examinar um caminho e efetuar controles.

• Relatórios são usados para conformidades com agências externas.

• Relatórios são usados para grandes volumes de navegação .

Quando usamos formulários?

• Formulários são usados para se tornarem documentos.

• Formulários são usados se necessitar de transações personalizadas mas não se tem acesso as estações de trabalho.

• Formulários são usados se são documentos jurídicos importantes.

Quando usamos telas?

• Telas são usadas para selecionar um simples registro do banco de dados.

• Telas são usadas para pequenos volumes de saída.

• Telas são usadas para intermediar passos ao longo de um processo interativo.

6.1. Projeto de Relatórios

Relatórios podem ser colocados num papel comum, formulários contínuos, telas-bases ou microfilmagem ou microfichas. A seguir damos os passos no projeto dos relatórios.

6.1.1. Considerações no Projeto de Relatórios

1. Número de Cópias e Volume. Deve haver um equilíbrio entre o número de cópias geradas com o número de páginas.

• Quantas cópias de relatórios serão geradas?

• Na média quantas páginas serão geradas?

• O usuário pode ficar sem relatórios?

• Com qual freqüência o usuário arquiva uma cópia? É realmente necessária?

2. Geração de relatório

• Quando os usuários necessitam de relatórios?

• Qual o período de interrupção de entrada ou processamento de dados antes do que os relatórios sejam gerados?

3. Freqüência dos relatórios

• Com que freqüência os usuários necessitam dos relatórios?

4. Figuras no relatório

• O usuário requisitou e faz a geração de relatórios para gerar tabelas, figuras, gráficos entre outros.

5. Mídia


JEDITM

• Onde os relatórios serão produzidos? Em uma tela CRT, formulário contínuo comum, formulário de pré-impressão, papel timbrado, Microfilme ou microficha, mídia de armazenamento, etc.

6.1.2. Princípios de Layout de relatórios

1. Aderir para saída padrão da zona de dados para o layout do relatório. As zonas de dados são cabeçalho, linhas de detalhes, rodapé e sumários.

2. Considere as dicas a seguir no projeto de cabeçalho de relatórios.

• Sempre incluir datas nos relatórios e número de páginas.

• Descreva claramente o relatório e conteúdo.

• Identifique os cabeçalho de coluna nos itens de dados listados.

• Alinhe o cabeçalho da coluna com o comprimento dos itens de dados.

• Remova nomes de empresas do interior do relatório para finalidades de segurança.

3. Considere as dicas a seguir no projeto da linha de detalhe.

• Uma linha deve representar um registro de informação. Detalhes adequados on-line. Se mais de uma linha é necessária, campos alfa numéricos são agrupados na primeira linha e campos numéricos são agrupados nas linhas seguintes.

• Os campos importantes são colocados no lado esquerdo.

• As primeiras cinco linhas e as últimas cinco linhas são utilizadas para os cabeçalhos e rodapés. Não usar estes espaços.

• É uma boa idéia para agrupar o número de detalhes por página para valor monetário semelhante a 10's, 20's e 50's.

• Se for tendência partes do relatórios, representar desenhos tal como gráficos.

• Agrupe Itens relacionados, semelhantes a Vendas Atuais com Venda Finais por Ano ou número de Clientes, Nome e Endereço.

• Para representar números semelhantes a moeda, poderá ser apropriado incluir marcas de pontuação e sinais.

• Evitar imprimir dados repetitivos.

4. Considere as dicas a seguir no projeto do rodapé do relatório.

• Coloque o total de páginas, totais principais e tabelas de código-valor nesta área.

• Também é bom colocar um indicador sem seguinte.

5. Considere as dicas a seguir no projeto do sumário de páginas.

6.1.3. Desenvolvimento do Layout dos Relatórios

PASSO 1: Definir o padrão do layout do relatório.

Como um exemplo, o seguinte é o padrão para definir os relatórios do Sistema Club Membership Maintenance.

• Título de relatório. Deve conter o título do relatório, data de geração, nome de clube e número de página.

• Corpo de relatório. Deve ter os dados descritivos à direita e no lado esquerdo os dados numéricos.

• Rodapé. Instruções ou explicação de cada código enquanto que a última página contém os principais totais e a indicação de final do relatório.

• Dados importantes são posicionados no documento da esquerda para a direita.

• Códigos devem ser explicados quando utilizados.


JEDITM

• Datas utilizam o formato de DD/MM/YY.

• Usar logotipos em documentos distribuídos externamente.

PASSO 2: Prepare os Planos de Relatório.

Os padrões são usados como guia para o implementação. Para representar dados que aparecerão nas colunas do relatório use as convenções de formato seguintes.

Formato Descrição

9 Isto significa um dado numérico. O número 9 indica os dígitos. Exemplos:

9.999 – O número em milhar

999,99 – uma centena com duas casas decimais

A Indica uma letra do alfabeto. A-Z ou a-z. Símbolos não são permitidos.

X Indica um tipo alfanumérico. Símbolos são permitidos.

DD/MM/YY Indica data no formato dia/mês/ano

HH:MM:SS Indica hora no formato hora:minuto:segundo

Tabela 6: Convenções de Formato

Figura 36 é um exemplo de layout de relatório seguindo as convenções do formado de datas especificados na Tabela 6. Este é um relatório de uma listagem geral da base de Athletes por estado.

Ang Bulilit Liga Club

Lista de Sócios por Estado

Realizado em: DD/MM/YYYY

Pág. 99

Estado: XXXXX

No. Nome Sobrenome

9999 Xxxxxxxx Xxxxxxxx



Número Total no estado XXXXX de sócios : 9999

Figura 36: Exemplo de Layout do relatório

6.2. Projeto de Formulários

Formulários são normalmente utilizados para entrada de dados quando uma workstation não estiver disponível (não confundir com formulário de tela, estamos tratando de formulários em papel). Às vezes é usado como um documento de turnaround. Os seguintes passos definem o projeto de formulários.

6.2.1. Guias gerais no layout do Formulários

1. Instruções devem aparecer no formulário exceto quando a mesma pessoa irá utilizá-lo inúmeras vezes. As instruções gerais são colocadas na parte superior. Devem ser breves. Devem ser colocadas instruções específicas antes dos artigos correspondentes.

2. Utilizar palavras familiares. Evite não usar "não", "exceto" e "a menos que". Utilize orações positivas, ativas e curtas.

3. O espaço de resposta deve ser suficiente para que o usuário possa entrar com toda a


JEDITM

informação necessária confortavelmente. Se o formulário será utilizado como em uma máquina de escrever, 6 ou 8 linhas por polegada é uma medida suficiente. Para espaços de resposta manuscritos, 3 linhas por polegada com 5 a 8 caracteres por polegada é uma medida suficiente.

4. Use as seguintes diretrizes para tipos das fontes.

• Gothic

• Simples, squared off, sem serifs

• Fácil ler, até mesmo quando comprimido

• Letras maiúsculas são desejáveis para títulos

• Italic

• Serifs e itálica

• Difícil para ler em grandes quantidades de textos longos

• Bom para destacar um trabalho ou frase

• Roman

• Serifs

• Melhor para grandes quantidades

• Bom para instruções

5. Letras minúsculas são mais fáceis de ler do que maiúsculas. Porém, um tamanho de fonte pequeno não deve ser utilizado. Use letras maiúsculas para chamar a atenção a certas declarações.

6.2.2. Desenvolvendo os Layouts do Formulário

PASSO 1: Defina os padrões a serem utilizados para os projeto dos formulários.

Um exemplo de um padrão para projeto de formulários é listado abaixo.

• Tamanho de papel não deve ser maior que 8 1/2” x 11.”

• Esquema de cores:

• Cópias brancas vão para os candidatos.

• Cópias amarelas vão para a diretoria do clube.

• Cópias vermelhas vão para o treinador.

• Devem ser posicionados dados importantes do lado esquerdo do documento.

• Datas devem utilizar o formato DD/MM/YY.

• Logotipos são utilizados externamente para distribuir documentos.

• Cabeçalho deve incluir Número de Página e Título.

• Deixar espaço para grampear o papel.

• Seguir 3 linhas por polegada.

PASSO 2: Prepare Amostras de Formulários.

Utilizando o formato padrão definido no passo 1, projetar o layout dos formulários. Redesenhe caso seja necessário.

6.3. Desenho de Telas e Diálogos

As classes de fronteira são refinadas para definir telas que os usuários utilizarão e a interação (diálogo) das telas com outros componentes do software. Em geral, há duas metáforas usadas no desenho de interfaces de usuário.

1. Metáfora do Diálogo é uma interação entre o usuário e o sistema através do uso de menus, teclas de função ou a entrada de um comando através de uma linha de comando. Tal


JEDITM

metáfora é largamente usada na abordagem estruturada de desenvolvimento de interfaces de usuário que são mostradas em terminais a caractere ou de modo texto.

2. Metáfora da Manipulação Direta é uma interação entre o usuário e o sistema usando interfaces de usuário gráficas (GUI). Tais interfaces são orientadas a eventos, isto é, quando um usuário, digamos, que clique um botão (evento), o sistema responderá. Ele dá ao usuário a impressão de estar manipulando objetos na tela.

Para desenvolvimento orientado a objeto usando ambientes integrados de programação visual, usamos a metáfora da manipulação direta. Contudo, ao desenhar interfaces, várias recomendações devem ser seguidas.

6.3.1. Recomendações para o Desenho de Telas e Interfaces

1. Vá pela regra: UMA IDÉIA POR TELA. Se a idéia principal mudar, outra tela deverá aparecer.

2. Padronize o layout da tela. Isto envolve definir orientações de estilo que devem ser aplicadas a todos os tipos de elementos de tela. Orientações de estilo garantem a consistência da interface. A consistência ajuda os usuários a aprender a aplicação mais depressa uma vez que a funcionalidade e a aparência são as mesmas em diferentes partes da aplicação. Isto se aplica aos comandos, ao formato dos dados como apresentados ao usuário, como formato de datas, ao layout das telas, etc. Diversos fabricantes de software oferecem orientações de estilo que você poderá usar. Orientações de estilo comuns são listadas abaixo:

• Orientações de Desenho Java Look and Feel (http://java.sun.com)

• As Orientações para Desenho de Software da Interface Windows (Windows Interface Guidelines for Software Design - http://msdn.microsoft.com)

• As Orientações para Interface Humana Macintosh (Macintosh Human Interface Guidelines - http://developer.apple.com)

3. Ao apresentar itens de dados ao usuário, lembre-se sempre do seguinte:

• Eles devem ser rotulados ou nomeados, e com os mesmos nomes em toda a aplicação. Como exemplo, suponha que você tenha um item de dado que representa um número de identificação de aluno. Você pode escolher usar o nome 'ID do Aluno'. Em todas as telas onde aparecer este item, use o nome 'ID do Aluno' como rótulo; não mude o rótulo para 'Número do Aluno' ou 'Nº do Aluno'.

• Tanto quanto possível, eles devem se localizar no mesmo ponto em todas as telas, particularmente, nas telas de entrada de dados.

• Eles devem ser mostrados da mesma forma como no caso da apresentação de datas. Se o formato das datas seguir o formato 'DD-MM-AAAA', então todas as datas deverão ser apresentadas neste formato. Não mude o formato.

4. Para controladores que requeiram um tempo maior para processar, mantenha o usuário informado do que está acontecendo. Use mensagens ou indicadores de barra do tipo "XX% completado".

5. Se possível, é recomendável informar ao usuário do próximo passo. O desenho de diálogos do tipo assistente é sempre uma boa abordagem.

6. Apresente mensagens de erro e telas de ajuda significativas. EVITE A IRREVERÊNCIA!

6.3.2. Desenvolvendo o Desenho de Telas e Diálogos

PASSO 1: Prototipação da interface de usuário.

Um protótipo é um modelo que parece, e até certo ponto, comporta-se como o produto final, mas não apresenta certas funcionalidades. É como o modelo de escala de um arquiteto para um novo prédio. Há diversos tipos de protótipos.

1. Protótipos horizontais oferece um modelo da interface de usuário. Ele lida com a apresentação apenas ou camada visual da arquitetura do software. Basicamente, este tipo de protótipo mostra a seqüência de telas quando o usuário interage com o software.


JEDITM

Nenhuma funcionalidade é emulada.

2. Protótipos verticais tomam um sistema funcional do sistema todo e o desenvolvem em cada camada: interface de usuário, alguma funcionalidade lógica e banco de dados.

3. Protótipos descartáveis são protótipos que são posteriormente descartados depois de servir ao seu propósito. Este tipo de protótipo é feito durante a fase de engenharia de requisitos. Tanto quanto possível, evitamos criar tais protótipos.

O uso de um Ambiente de Programação Visual fornece suporte aos protótipos de desenvolvimento. NetBeans e Java Studio Enterprise 8 oferecem meios de criar visualmente os nossos protótipos.

Para demonstrar o Passo 1, imagine que estamos construindo um protótipo de tela para a manutenção de um registro de atleta. A tela principal, cujo nome é Athlete (Atleta) (Figura 37), permite-nos manusear um único registro de atleta. Quando um usuário clica o Find Button (Botão Procurar), a tela Find an Athlete (Procurar um Atleta) (Figura 38) aparece. Esta tela é usada para especificar o critério de busca que determina quais registros de atletas serão recuperados da base de dados. Quando o critério tiver sido pressionado o botão OK, a tela com a Athlete List (Lista de Atletas) (Figura 38) será mostrada contendo a lista de atletas que satisfaz ao critério de busca. O usuário poderá selecionar o registro colocando a barra de seleção sobre o nome. Quando o botão OK for pressionado, retornaremos à tela Athlete (Atleta) onde os atributos do atleta escolhido serão mostrados nos elementos de tela apropriados.

Figura 37: Tela principal de Athlete

Figura 38: Exemplo da Tela de FindAthleteRecordUI e AthleteListUI


JEDITM

Nos passos seguintes, serão tratadas telas como únicos objetos. Na realidade, podem ser uma instância de uma subdivisão de classe como Diálogo. Por exemplo, veja a Figura 39.

Figura 39: Exemplo da Tela dos Comandos FindAthleteRecordUI e AthleteListUI

Em Java, é possível utilizar os componentes AWT e SWING. Eles são importados na classe que os usa utilizando as seguintes instruções:

importe java.awt.*; importe javax.swing.*;

PASSO 2: Para cada tela, realize o projeto da classe da tela.

Este passo exigiria-nos uma modelagem da tela como uma classe. Como por exemplo, a Figura40 que mostra a definição da classe para a tela de Atleta. O nome da classe é AthleteRecordUI. Tem um estereótipo <<screen>>.



JEDITM

Neste exemplo, assumimos que estaremos utilizando a bibliotecas de Abstract Windowing Toolkit (AWT) como componentes de apoio. Também é necessário modelar as telas "Find an Athlete" e "Athlete List" como classes; elas são nomeadas, respectivamente, para FindAthleteRecordUI e AthleteListUI. Empacotar todas as telas para formar o subsistema. Este subsistema deve implementar a interface IAthleteRecordUI para a classe limite. Veja a Figura 41.


PASSO 3: Para cada classe de tela, modele o comportamento da tela com outras classes.

O comportamento da classe de tela relativa a outras classe é conhecido como projeto de diálogo. Os diagramas de colaboração e de seqüência são utilizados nesta etapa. Como no nosso exemplo, há três funcionalidades principais para gerenciar um registro de um atleta que deve suportar registro do nome, adição, edição e deleção do atleta. Considere o diagrama de colaboração modelado na Figura 42. O primeiro diagrama de colaboração modela como o sistema gerencia o registro do atleta e consiste nas classes AthleteRecordUI, MaintainAthleteRecord e DBAthlete. Isto é mostrado pelo segundo diagrama de colaboração da figura. Classes adicionais são identificadas e definidas para suportar recuperação de um registro de um atleta a partir da base de dados quando as funcionalidades de edição e deleção assim necessitam. Estas classes são FindAthleteRecordUI, FindAthleteRecord e AthleteListUI.

Figura 42: Diagrama de Colaboração Formal com AthleteRecordUI

Uma vez que os objetos da colaboração são identificados, precisamos modelar o comportamento destes objetos quando as funcionalidades (adição, edição e deleção do registro do atleta) são executadas. Utilizamos o Diagrama de Seqüência para modelar este comportamento. A Figura 43 mostra o Diagrama de Seqüência formal da adição de um registro de um atleta.


JEDITM

Figura 43: Diagrama de Seqüência Formal da Adição de um Registro de um Atleta

Ambos os diagramas de Seqüência para alteração e exclusão de um registro de atleta irão requerer a recuperação de um registro da base de dados. Antes de alterar ou excluir, o Diagrama de Seqüência da Figura 44 deverá ser executado.

Figura 44: Diagrama de Seqüência de Recuperação de um Recorde de Atleta Modificado

O Diagrama de Seqüência modificado para editar e excluir um recorde de atleta é mostrado na Figura 45 e Figura 46 respectivamente.


JEDITM

Figura 45: Diagrama de Seqüência de Alteração de um Recorde de Atleta Modificado

Figura 46: Diagrama de Seqüência de Exclusão de um Recorde de Atleta Modificado

PASSO 4: Para cada classe de tela, modelar seu comportamento interno.

O Diagrama de Estado é utilizado para modelar o comportamento interno da tela. Isso basicamente modela o comportamento da tela quando um usuário faz alguma coisa nos elementos da tela como pressionar o Botão OK.

Descrevendo o gráfico do Diagrama de Estado

O Gráfico do Diagrama de Estado mostra os possíveis estados que um objeto pode ter. Isso também identifica os eventos que causam a mudança de estado de um objeto. Isso mostra como o estado de um objeto muda de acordo com os eventos que são tratados pelo objeto. Figura 47 mostra a notação básica de um diagrama.

Figura 47: Notação Básica do Gráfico do Diagrama de Estado

O estado inicial, representado pelo círculo sólido, significa o ponto inicial da transição. Um objeto não pode permanecer no seu estado inicial mas precisa se mover para um estado


JEDITM

nomeado. O estado é representado como um objeto retangular com as bordas arredondas e com um nome de estado dentro do objeto. Uma transição é representada por uma linha com uma seta na ponta. Uma transição pode ter um texto de transição que mostra o evento causador da transição, qualquer condição de guarda que precise ser avaliada durante o disparo do evento, e a ação que precisa ser executada quando o evento é disparado. O evento pode ser uma operação definida na classe. O estado final, como representado pelo círculo com outro círculo preenchido dentro, significa o fim do diagrama.

Similar ao outro diagrama na UML, há uma notação melhorada ou estendida que pode ser usada quando está se definindo o estado da classe. A Figura 48 mostra essas notações.

Figura 48: Notação aperfeiçoada do Diagrama de Estados

Concurrent States (Estados Concorrentes) significa que o comportamento de um objeto pode ser melhor explicado pelo produto correspondente como dois conjuntos distintos de sub-estados, cada estado da qual pode ser entrado ou saído independentemente dos sub-estados do outro conjunto. Nested States (Estados Aninhados) permitem modelar um complexo estado através da definição de diferentes níveis de detalhes. Estados podem ter ações e atividades internas. Ações internas de um estado definem qual operação pode ser executada ao entrar num estado, qual operação pode ser executada ao se sair de um estado, e qual operação poder ser executada enquanto estiver em um determinado estado.

Figura 49 Mostra o gráfico do diagrama de estado da classe AthletRecordUI. Quando uma tela é exibida pela primeira vez, mostrará uma tela de inicialização onde a maioria das caixas de texto estarão vazias. Alguns campos podem ter valores padrões, como gênero, com um valor padrão 'Masculino' e situação com o valor padrão 'Novo'. Esse é o estado inicial. Quando um usuário insere um valor em qualquer caixa de texto (isso dispara um evento enterTextField()), o estado da tela irá mudar para o valor informado (With Entered Values) onde este valor é refletido no elemento da tela. Quando um usuário pressiona o Botão Cancelar (que dispara o evento clickCancelButton()), o estado da tela irá mudar para o estado mostra a confirmação saída (Show Exit Confirmation). Nesse estado, uma mensagem numa caixa de diálogo será exibida questionando caso o usuário deseja realmente sair. Se a resposta do usuário for SIM (answerYES), sairemos da tela. Senão, retornaremos ao estado anterior.


JEDITM

Figura 49: Diagrama de Estado da AthleteRecordUI

Figura 50 Mostra o gráfico do diagrama de estado FindAthletRecordUI e Figura 51 mostra o gráfico do diagrama de estado AthleteListUI.

Figura 50: Diagrama de Estado de FindAthleteRecordUI


JEDITM

Figura 51: Diagrama de Estado de AthleteListUI

PASSO 5: Documentar as classes

A documentação é similar a documentar as classes de bancos de dados (DBClasses) e classes de Persistência (Persistent Classes). Identifique todas as operações e atributos da lista abaixo. A Figura 52 mostra todas as definições das classes utilizadas.

Figura 52: Refinamento das definições de Classes


JEDITM

Também ajudaria a listar a ação na tabela. Esta tabela é denominada de Tabela Evento-Ação. Ela é usada se o mapa de estado é complexo. Do ponto de vista do programador, esta tabela é mais fácil de usar do que um mapa de estado rotulado com ações. Ela pode auxiliar na validação do mapa de estado e para testar o código quando ele é implantado. As colunas da Tabela Evento-Ação são as seguintes:

● Estado atual do objeto que está sendo modelado. Para melhor referência, os estados são numerados.

● O evento é uma ação que pode ocorrer.

● As ações associadas com a combinação do estado e do evento.

● Próximo estado do objeto depois que o evento ocorre. Se mais de um estado variável é usado, é utilizada outra coluna.

A Figura 53 mostra um mapa de diagrama de estado da tela AthleteRecordUI , com os estados numerados e a Tabela 7 mostra o Evento-Ação desta tela.

Figura 53: Mapa de Diagrama de Estado AthleteRecordUI

Estado Atual

Evento Ação Próximo Estado

- Acesso a tela AthleteRecordUI

Exibe uma parte vazia da tela Athlete, exceto para os elementos da tela identificados com valores padrões.

1

1 enterTextField() Exibe o valor marcado dentro de um campo de texto. 22 clickStatusComboBox() Indica a lista do status do Atleta. 33 selectFromList() Exibe o status do atleta selecionado no campo mostrado. 22 enterTextField() Exibe o valor marcado dentro de um campo texto. 22 clickCancelButton() Indica uma caixa de diálogo de confirmação de saída. 55 AnswerYES Abandona a tela Athlete sem salvar nenhum dos dados

mostrados na tela.-

5 AnswerNO Fecha a caixa de diálogo de confirmação de saída. 2Tabela 7: Tabela Evento-Ação da tela AthleteRecordUI


JEDITM

PASSO 6: Modifique a arquitetura de software.

Os subsistemas de fronteira são substituídos pelas classes das telas ou interfaces do usuário. Se classes adicionais de controle forem definidas, adicione-as à arquitetura. Figura 54 mostra a arquitetura de software modificada.

Figura 54: Arquitetura de Software Modificada da Elaboração do Projeto de Interface do Usuário


JEDITM

7. Projeto a nível de Componente

Define a estrutura de dados, algorítimos, características de interface e mecanismo de comunicação alocados para cada componente de software. Um componente é um bloco de construção para o desenvolvimento de software. É uma parte substituível e quase independente de um software que satisfaz uma função clara no contexto de um arquitetura bem definida.

Na engenharia de software orientada a objeto, um componente é um conjunto de classes de colaboração que satisfazem um requisito funcional em particular do software. Ele pode ser desenvolvido independentemente. Cada classe no componente deve ser definida de forma completa para incluir todos os atributos e operações relacionadas à implementação. É importante que todas as interfaces e mensagens que permitem a comunicação e colaboração das classes do componente sejam bem definidas.

7.1. Princípios Básicos do Projeto de Componentes

Quatro princípios básicos são usados para o projeto de componentes. Eles são usados para guiar o engenheiro de software no desenvolvimento de componentes que são mais flexíveis e maleáveis para alterar e reduzir a propagação dos efeitos colaterais quando uma mudança acontecer.

1. Princípio Abre-Fecha. Quando da definição de módulos ou componentes, eles devem ser abertos para extensão, devem ser modificáveis. O engenheiro de software deve definir um componente tal que ele possa ser estendido sem a necessidade de se modificar a estrutura e o comportamento internos do componente. Abstrações na linguagem de programação suportam esse princípio.

2. Princípio da Subtituição Liskov. A classe ou subclasse derivada pode ser uma substituta para a classe base. Se uma classe é dependente da classe base, essa classe pode usar qualquer classe derivada como uma substituta para a classe base. Esse princípio reforça que qualquer classe derivada deve estar de acordo com qualquer contrato implícito entre a classe base e qualquer componente que a utilize.

3. Princípio da Dependência. As classes devem depender da abstração; não do concreto. Quanto mais um componente depender de outros componentes concretos, mais difícil será extendê-los.

4. Princípio da Segregação de Interface. Engenheiros de software são encorajados a desenvolver interfaces específicas do cliente ao invés de uma única interface genérica. Apenas operações específicas de um cliente em particular devem ser definidas na interface específica do cliente. Isso minimiza a herança de operações irrelevantes para o cliente.

7.2. Guias de Projeto no nível de Componente

Esse guia é aplicado ao projeto do componente, sua interface, suas dependências e herança.

1. Componente

• Nomes arquiteturais do componente devem vir do domínio do problema e serem facilmente compreendidos pelos participantes, particularmente, os usuários finais. Como um exemplo, um componente chamado Athlete é claro para qualquer um que esteja lendo o componente.nomes específicos. Como exemplo, PCLAthlete é uma lista de classes persistentes para atletas.

• Utilize estereótipos para identificar a natureza de componentes como <<table>>, <<database>> ou <<screen>>.

2. Interfaces

• A representação canônica da interface é recomendada quando o diagrama se torna complexo.

• Elas devem fluir do lado esquerdo do componente implementado.

• Mostra apenas as interfaces que são relevantes para o componente sendo considerado.


JEDITM

3. Dependências e Herança

• Dependências devem ser modeladas da esquerda para direita.

• Herança deve ser modelada do nível mais baixo (subclasses ou classes derivadas) para o topo (superclasses ou classe base).

• Interdependência de componentes são modeladas da interface para interface ao invés do componente para o componente.

7.3. Diagrama de Componentes

O Diagrama de Componentes é usado para modelar componentes de software, suas interfaces, dependências e hierarquias. Figura 55 mostra a notação desse diagrama.

Figura 55: Notação de Diagrama de Componentes

Um componente é representado por uma caixa retangular com o símbolo do componente dentro. A dependência é descrita pelas setas pontilhadas. A dependência pode ser nomeada. O componente Cliente (Client Component) é dependente do componente Fornecedor (Supplier Component).

7.4. Desenvolvendo o Componente de Software

Todas as classes identificadas até então devem ser elaboradas, incluindo as telas e classes de modelos de dados. Nessa seção, o MaintainAthleteRecordController será usado como exemplo mas o modelo de componente deve ser feito para todas as classes.

O MaintainAthleteRecordController é uma classe abstrata que representa, em geral, o comportamento de manter um registro do atleta (athlete). É estendida por um tipo de manutenção – adicionando um registro, editando um registro ou deletando um registro. Figura 56 mostra a hierarquia do tipo de manutenção registro de atleta que é modelado durante a fase de requisitos de engenharia. A relação é “é-um-tipo”; AddAthleteController é um tipo de MaintainAthleteRecordController.

Figura 56: Hierarquia de MaintainAthleteRecordController

Desenvolver o modelo de componente envolve os seguintes passos.

PASSO 1: Refinar todas as classes.

As classes são refinadas de uma maneira que elas possam ser traduzidas em um programa. Refatoração pode ser necessária antes de continuarmos. Esse passo envolve uma série de sub-passos.

PASSO 1.1: Se necessário, redefinir os Diagramas de Seqüência e colaboração para refletir a interação das classes atuais.

PASSO 1.2: Distribuir operações e refinar a operação de assinatura da classe. Utilizar os tipos de dados e convenções de nomenclaturas da linguagem de programação sendo utilizada. Figura 58


JEDITM

mostra a elaboração da operação de assinatura do AddAthleteController. Uma breve descrição é anexada a operação.

PASSO 1.3: Refinar atributos de cada classe. Utilizar tipos de dados e convenções de nomenclaturas da linguagem de programação utilizada. Figura 58 mostra a elaboração dos atributos do AddAthleteController. Uma breve descrição é anexada ao atributo.

PASSO 1.4: Identificar a visibilidade dos atributos e operações. Os símbolos de visibilidade são enumerados na Tabela 8.

Símbolos de Visibilidade

Descrição

+ ou public Público (PUBLIC): O atributo ou a operação são acessados diretamente pela instância de uma classe.

- ou private Particular (PRIVATE): O atributo ou a operação são acessados somente por uma instância da classe que os inclui.

# ou protected Protegido (PROTECTED): O atributo ou a operação podem ser usados por qualquer instância da classe que os inclui ou por uma subclasse desta mesma classe.

~ Pacote (PACKAGE): O atributo ou a operação estão acessíveis somente para serem instâncias de uma classe no mesmo pacote.

Tabela 8: Visibilidade do atributo ou da operação

Os símbolos de visibilidade são colocados antes do nome do atributo ou da operação. Veja Figura57 como exemplo:

Figura 57: Definição Da Classe Do Controlador

PASSO 1.5: Documente a classe. Particularmente, identifique as pré-condições (pre-conditions) e


JEDITM

as pós-condições (post-conditions). As pré-condições são as circunstâncias que devem existir antes que a classe possa ser usada. As pós-condições são as circunstâncias que existe depois que a classe foi usada. Também inclua a descrição dos atributos e das operações.

PASSO 2: Se necessário, refine o empacotamento das classes.

No nosso exemplo, decidiu-se que nenhum reempacotamento é necessário.

PASSO 3. Defina os componentes do software.

Defina os componentes usando o diagrama de componentes. A Figura 58 mostra os componentes do software do Sistema de Manutenção de Sócios do Clube. Não inclui os componentes que serão reutilizados.

Figura 58: Diagrama de Componentes do Club Membership Maintenance

Os nomes dos pacotes segue a convenção usada pela Linguagem de Programação Java. O pacote abl.athlete manuseia o Sistema de Manutenção de Sócios do Clube. A lista a seguir contém seus pacotes e arquivos:

• Pacote de interface do usuário (abl.athlete.ui)

• AthleteRecordUI.java, AthleteListUI.java e FindAthleteRecordUI.java

• Controladores (abl.athlete.con)

• MaintainAthleteRecord.java, AddAthlete.java, EditAthlete.java, DeleteAthlete.java e FindAthleteRecord.java

• Classes de Bancos de Dados (abl.athlete.dbclass)

• DBAthlete.java

• Classe de Persistência (abl.athlete.pc)

• Athlete.java e Guardian.java

O ABL Database é o servidor do banco de dados que contém os dados que são necessários para as aplicações.


JEDITM

8. Projeto a Nível de Implementação

Cria um modelo que mostra a arquitetura física do hardware e software do sistema. Destaca o relacionamento físico entre o software e hardware. Os componentes identificados no projeto a nível de componentes são distribuídos para o hardware.

8.1. Notação do Diagrama de Implementação

O Diagrama de Implementação é composto de comunicações associadas. Representariam os computadores. São representados como caixas em três dimensões. As comunicações associadas mostram as conexões de rede. Figura 59 ilustra um Diagrama de Implementação.

Figura 59: Notação do Diagrama de Implementação

8.2. Desenvolvimento do Modelo de Implementação

Desenvolver o diagrama de implementação é muito simples. Apenas distribua os componentes identificados no projeto a nível de componentes para reside o node. Figura 59 Ilustra o diagrama de Implementação para o Sistema de Manutenção de Sócios do Clube.


Cliente Atleta Computador

ABL Servidor de BD

JEDITM

9. Itens de Validação do Modelo de Projeto

Validação é necessária para ver se o modelo de projeto:

• satisfaz aos requisitos do sistema

• é consistente com o guia de projeto

• serve como uma boa base para a implementação

9.1. Componente de Software

1. O nome do componente de software reflete claramente o seu papel dentro do sistema?

2. As dependências estão definidas?

3. Existe algum elemento do modelo dentro do componente de software visível do lado de fora?

4. Se o componente de software tem uma interface, a operação definida na interface mapeada para o elemento do modelo dentro do componente de software?

9.2. Classe

1. O nome da classe reflete claramente seu papel dentro do sistema?

2. O significado da classe é uma única bem definida abstração?

3. As operações e atributos dentro da classe são funcionalmente acoplados?

4. Existem quaisquer atributos, operações ou associações que necessitam ser generalizadas?

5. Todos os requisitos específicos sobre a classe estão endereçados?

6. A classe exibe o comportamento requerido que o sistema necessita?

9.3. Operação

1. Podemos entender a operação?

2. A operação provê o comportamento que a classe necessita?

3. A assinatura da operação correta?

4. Os parâmetros definidos corretamente?

5. As especificações da implementação da operação estão corretas?

6. A assinatura da operação está em conformidade com os padrões da linguagem de programação alvo?

7. A operação é necessária ou é usada pela classe?

9.4. Atributo

1. O significado do atributo é algo conceitual e único?

2. O nome do atributo é descritivo?

3. O atributo é necessário ou usado pela classe?


JEDITM

10. Mapeando os Produtos do Projeto para a Matriz de Rastreabilidade de Requisitos

Uma vez finalizados os componentes de software, necessitamos ligá-los à MRR do projeto. Isso assegura que o modelo está relacionado a um requisito. Também auxilia o engenheiro de software no rastreamento do progresso do desenvolvimento. A Tabela 9 mostra os elementos recomendados da MRR que devem ser adicionados à matriz.

Componentes de Projeto da MRR

Descrição

ID do Componente de Software

O nome do pacote do componente de software que pode ser independentemente implementado, como abl.athlete (componente de software que trata das inscrições dos sócios do clube)

ClasseO nome da classe que é implementada a qual é parte do componente de software, como abl.athlete.AthleteRecordUI (uma classe JAVA responsável pela interface com o ator no processamento do registro do atleta).

Documentação da Classe

O Nome do Documento da classe. É um arquivo que contém a especificação da classe.

Estados

O estado da classe. Usuários podem definir um conjunto de estados da classe, tal como:

• PCA – projeto da classe em andamento

• CEA – codificação em andamento

• TEA – teste em andamento

• FEITO

Tabela 9: Elementos do Modelo de Projeto da MRR


JEDITM

11. Métricas de Projeto

Na engenharia de software orientado a objetos a classe é a unidade fundamental. Medidas e métricas para uma classe individual, hierarquia de classes e a colaboração de classes são importantes para a engenharia de software especialmente para assegurar a qualidade do projeto.

Existem vários tipos de métricas para o software orientado a objetos, porém a mais largamente utilizada é a métrica CK proposta por Chidamber e Kemerer. Consiste numa métrica de projeto baseada em seis classes que são listadas abaixo:

1. Complexidade de Métodos por Classe (WMC). Isso é computado como sendo a soma da complexidade de todos os métodos de uma classe. Assuma que existam n métodos definidos em uma classe. Calcula-se a complexidade de cada método separadamente e depois se encontra a soma. Existem muitas métricas que podem ser utilizadas, mas a mais comum é a complexidade ciclomática. Isto é discutido no capítulo de Teste de Software. O número de métodos e suas complexidades indicam:- A quantidade de esforço necessária para a implementação e teste da classe- Quanto maior a quantidade de métodos, mais complexa será a arvore de herança- Assim como o número de métodos cresce dentro de uma classe, esta se tornará mais

complexa.

2. Profundidade da Arvore de Heranças (DIT). É definido pelo comprimento máximo desde a classe mais alta até a sub-classe mais baixa. Considere a hierarquia de classes na Figura 60, o valor de DIT é igual a 5. Com o crescimento desse número, é possível ver que o número de métodos herdados pela classe mais baixa irá aumentar. Isto pode nos levar a algum problema em potencial para predizer o comportamento da classe e no aumento da complexidade de projeto. Em contrapartida, um grande número implica que mais métodos serão reutilizados.

3. Número de filhas (NOC). As filhas de uma classe são as classes imediatamente subordinadas à ela. Considere a hierarquia de classes na Figura 60, o NOC para a class4 é igual a 2. Com o aumento do número de filhas, o reuso também será aumentado. Contudo, um cuidado deve ser dado para que a abstração representada pela classe mais alta não seja diluído por suas filhas, que não são propriamente participantes da classe base. É claro que com o aumento do número de classes filhas, o número de testes também será maior.

4. Acoplamento entre os Objetos das Classes (CBO). É o número de colaborações que uma classe realiza com outro objeto. Com o aumento deste número, a reusabilidade desta classe diminuirá. Isto também complica futuras modificações e testes. É por esta razão que o CBO deve ser mantido ao mínimo possível.

5. Resposta de uma Classe (RFC). É o número de métodos que são executados em resposta a uma mensagem dada a um objeto da classe. Com o aumento deste número, aumenta também a complexidade dos testes, pois as possíveis seqüências de testes serão maiores.

6. Falta de Coesão nos Métodos (LCOM). É o número de métodos que acessa um atributo na classe. Se este número for alto, os métodos são acoplados juntos neste atributo. Isto aumenta a complexidade do projeto da classe. É indicado manter o LCOM no mínimo possível.

Figura 60 Amostra de Hierarquia de Classes.


JEDITM

12. Exercícios

12.1. Criando o modelo de Projeto de Dados

1. Criar o Modelo de Projeto de Dados do Sistema de Informações de Técnicos

• Criar a visão estática das classes persistentes

• Modelar o comportamento dinâmico das classes persistentes o que inclui inicialização, criação, leitura, atualização e remoção

2. Criar o Modelo de Projeto de Dados do Sistema de Manutenção de Sócios do Clube

• Criar a visão estática das classes persistentes

• Modelar o comportamento dinâmico das classes persistentes o que inclui inicialização, criação, leitura, atualização e remoção

12.2. Criar o Projeto de Interface

1. Projetar os layouts dos Relatórios dos itens abaixo e utilizar os padrões como definidos neste capítulo

• Lista dos sócios por Status

• Lista dos sócios que estarão saindo ou se graduando no próximo ano

• Lista dos sócios que não pagaram a taxa de nova matrícula

2. Remodelar o Formulário da Aplicação para acomodar as informações adicionais dos atletas que os proprietários dos clubes queiram. Utilizar os padrões como definidos neste capítulo

3. Refinar o projeto de telas da tela Atleta como mostrado na Figura 38 para incluir informações adicionais necessárias para os proprietários de clubes

• Criar um novo protótipo de tela

• Definir a tela como uma classe

• Modelar o comportamento da tela

4. Criar o projeto de telas e caixas de diálogo do Sistema de Informação de Técnicos

• Criar o protótipo de tela



5. Criar o projeto de telas e caixas de diálogo do Sistema de Manutenção de Sócios do Clube.

• Criar o protótipo de tela



12.3. Criando o Projeto de Controle

1. Refinar as classes de controle do Sistema de Informações de Técnicos

• Refinar e redefinir as classes de controle

• Modelar o comportamento das classes de controle com as telas e as classes persistentes

• Modelar os componentes utilizando o diagrama de componentes

2. Refinar as classes de controle do Sistema de Manutenção de Sócios do Clube


JEDITM

• Refinar e redefinir as classes de controle

• Modelar o comportamento das classes de controle com as telas e as classes persistentes

• Modelar os componentes utilizando o diagrama de componentes

3. Definir o diagrama de componentes de software

• Refinar a arquitetura de software reempacotando as classes

• Definir o diagrama de componentes de cada pacote na arquitetura de software

12.4. Atribuições do Projeto

O objetivo das atribuições do projeto é reforçar o conhecimento e as habilidades adquiridas neste capítulo. Particularmente, são:

1. Traduzir o Modelo de Análise num Modelo de Projeto

2. Desenvolver o Modelo de Projeto de Dados

3. Desenvolver o Modelo de Projeto de Interface

4. Desenvolver o Projeto de Componentes de Software

5. Desenvolver a Arquitetura de Software

MAIORES PRODUTOS DE TRABALHO A SEREM ELABORADOS:

1. Arquitetura de Software

2. Modelo de Projeto de Dados

3. Modelo de Projeto de Interfaces

4. Modelo de Classes de Controle

5. Modelo de Projeto de Componentes de Software (IMPORTANTE!)

6. Matriz de Rastreabilidade de Requisitos

7. Lista de Ações



Lição 5Implementação


JEDITM

1. Objetivos

Classes são escritas de acordo com o que está especificado no projeto. A tradução de um projeto pode ser uma tarefa complicada. Primeiro, o projetista do sistema pode não apontar as características da plataforma e do ambiente de programação. Segundo, os códigos devem ser escritos de tal forma que sejam compreensíveis não só pelo programador que os fez, mas também pelos outros (outros programadores e testadores). Terceiro, o programador deve se aproveitar das características da organização do projeto, das estruturas de dados e das construções específicas da linguagem de programação enquanto cria um código de fácil manutenção e reutilizável. Este capítulo não pretende ensinar cada linguagem de programação, visto que isto é reservado para um curso de programação. Este capítulo oferece algumas dicas de programação que devem ser adotadas na criação de códigos. Ele também mostra algumas boas práticas de engenharia de software que todo programador deve sempre ter em mente.


• Conhecer dicas de programação• Conhecer práticas de engenharia de software para escrever códigos• Oferecer exemplos de implementação do projeto, particularmente, pacotes, classes de

bancos de dados e classes persistentes, e interfaces gráficas com o usuário


JEDITM

2. Padrões e Procedimentos de Programação

O desenvolvimento de software envolve equipes. Uma variedade de tarefas, executadas por diferentes pessoas, são necessárias para se gerar um produto de qualidade. Algumas vezes, a escrita de um código envolve diversas pessoas. Então, torna-se necessário um bom senso de cooperação e coordenação. É importante que os outros sejam capazes de entender o código que foi escrito, o por quê foi escrito e como se integra ao software que está sendo desenvolvido. Foi por esta razão que padrões e procedimentos de programação foram definidos e podem ser usados consistentemente.

Padrões e procedimentos de programação são importantes por diversas razões. Primeiro, eles ajudam o programador a organizar o raciocínio e a evitar a ocorrência de erros. A maneira de se documentar o código-fonte, tornando-o claro e de fácil compreensão, ajuda o programador a escrever e a manter estes códigos. Também ajuda na localização de falhas e dá dicas na hora de se fazer alterações, pois fica mais fácil localizar a seção do código onde a alteração deve ser aplicada. Da mesma forma, auxilia na tradução do código do projeto para o código-fonte, mantendo a correspondência entre os componentes de projeto com os componentes de implementação. Segundo, pode dar assistência aos outros participantes da equipe, tais como os testadores, os integradores e os responsáveis pela manutenção do software. Permite que a comunicação e a coordenação seja clara entre as equipes de desenvolvimento do software.

As pessoas envolvidas no desenvolvimento do software devem definir os padrões específicos de implementação a serem adotados. Estes podem ser:

1. A plataforma onde o software será desenvolvido e usado. Isto inclui os requisitos mínimos e recomendados para o hardware e o software. Para o software, incluir as versões. As atualizações (upgrades) geralmente não são recomendadas. Entretanto, se as atualizações forem necessárias, o impacto deve ser citado e analisado.

2. Os padrões na documentação do código-fonte. Isto será discutido nas dicas de documentação da programação.

3. Os padrões a serem utilizados para a correspondência dos códigos do projeto com os códigos-fonte. O modelo de projeto não tem valor nenhum se a modularidade do projeto não se reflete na implementação. Características do projeto, tais como baixo acoplamento, alta coesão e interfaces bem definidas, também devem ser características da classe. O objetivo principal do software pode permanecer o mesmo durante todo o seu ciclo de vida, mas sua natureza e características podem mudar com o tempo, à medida que os requisitos do usuário são modificados e evoluções são identificadas. Inicialmente, as mudanças são refletidas no projeto. Entretanto, estas também serão repassadas para os componentes de nível mais baixo. A correspondência do projeto com o código-fonte nos permite localizar o código-fonte que precisa ser modificado.


JEDITM

3. Dicas de Programação

Programação é uma habilidade criativa. O programador tem a flexibilidade de implementar o código. O componente do projeto é utilizado como uma dica da função e objetivo do componente. Dicas específicas de linguagem não são discutidas aqui. Dicas Padrões de Programação Java, visite o endereço http://java.sun.com/docs/codeconv/index.html. Esta seção discutirá várias dicas que se aplicam à programação de modo geral.

3.1. Usando Pseudo-códigos

O projeto geralmente oferece um framework para cada componente. É um esboço do que deve ser feito no componente. O programador adiciona sua criatividade e experiência para elaborar as linhas de código que implementam o projeto. Ele tem a flexibilidade de escolher uma construção particular da linguagem de programação para usar, como usá-la, como o dado será representado, e assim por diante.

Pseudo-códigos podem ser usados para adaptar o projeto à linguagem de programação escolhida. Um exemplo é o inglês estruturado que descreve o fluxo de código. Adotando-se construções e representações de dados, sem se envolver imediatamente com as especificidades de um comando ou bloco de comandos, o programador pode experimentar e decidir qual é melhor implementação. Códigos podem ser reorganizados ou reconstruídos com o mínimo de reescrita.

3.2. Dicas para as Estruturas de Controle

A estrutura de controle é definida pela arquitetura do software. No software orientado a objetos, é baseada em mensagens sendo enviadas entre os objetos de classes, no estado do sistema e nas mudanças nas variáveis. É importante que a estrutura da classe reflita a estrutura de controle do projeto. A modularidade é uma característica de projeto que deve ser traduzida como uma característica da classe. Construindo a classe em blocos modulares (métodos), o programador pode esconder detalhes da implementação em diferentes níveis, tornando todo o sistema fácil de entender, testar e manter. Acoplamento e coesão são outras características de projeto que também devem ser traduzidas em características da classe.

3.3. Dicas de Documentação

A Documentação da classe é um conjunto de descrições escritas que explicam ao leitor o que estas fazem e como fazem. Dois tipos de documentações podem ser criadas:

Documentação Interna

É um documento descritivo diretamente escrito no código-fonte. É direcionado a alguém que terá que ler o código-fonte. Uma informação resumida é oferecida para descrever suas estruturas de dados, algoritmos e fluxos de controle. Geralmente, esta informação é colocada no início do código. Esta seção do código-fonte é conhecida como bloco cabeçalho de comentário. Ele age como uma introdução ao código-fonte e identifica os seguintes elementos:

• Nome do Componente

• Autor do Componente

• Data em que o Componente foi criado ou teve sua última modificação

• Lugar onde o Componente se aplica no sistema em geral

• Detalhes da estrutura de dados, do algoritmo e do fluxo de controle do componente

Opcionalmente, pode-se adicionar um histórico das revisões que foram feitas no componente. O elemento de histórico consiste de:

• Quem modificou o componente?

• Quando o componente foi modificado?

• Qual foi a modificação?

As documentações internas são criadas para as pessoas que irão ler o código.


http://java.sun.com/docs/codeconv/index.html

JEDITM

Dicas para se escrever códigos

1. Use nomes de variáveis e métodos que sejam significativos.

2. Use formatação para melhorar a legibilidade dos códigos, tais como recuo e divisão em blocos.

3. Em alguns blocos de comandos, coloque comentários adicionais para esclarecer os leitores.

4. Tenha métodos separados para entrada (input) e saída (output).

5. Evite o uso de GOTO's. Evite escrever códigos que saltam de repente de um lugar para outro.

6. A escrita de código também é interativa, por exemplo, geralmente alguém começa com um rascunho. Se o fluxo de controle está complexo e difícil de entender, pode-se reestruturar.

Documentação Externa

Todos os outros documentos que não são parte do código-fonte mas estão relacionados ao código-fonte são conhecido como documentos externos. Este tipo de documentação é para aqueles que não precisam necessariamente ler os códigos das classes. Descrevem como os componentes interagem uns com os outros, incluindo classes de objetos e suas heranças hierárquicas. Para um sistema orientado a objeto, identifica as pré-condições e pós-condições do código-fonte.


JEDITM

4. Implementando Pacotes

Os pacotes oferecem um mecanismo de reuso do software. Um dos objetivos dos programadores é criar componentes de software reutilizáveis de tal forma que códigos não tenham que ser escritos repetidamente. A Linguagem de Programação Java oferece um mecanismo para a definição de pacotes. Na realidade, são diretórios que são utilizados para organizar as classes e interfaces. O Java oferece uma convenção para que os nomes de pacotes e classes sejam únicos. Com centenas de milhares de programadores Java espalhados pelo mundo, o nome que alguém pode utilizar para a sua classe pode coincidir com o nome de uma classe desenvolvida por outros programadores. Os nomes dos pacotes devem ser formados por caracteres ASCII, todos em minúsculas. Devem seguir a Convenção de Nomes de Domínio da Internet conforme especificado no formato X.500.

A seguir estão os passos da definição de um pacote em Java.

1. Defina uma classe public. Se a classe não for pública, somente poderá ser usada por outras classe no mesmo pacote. Considere o código da classe persistente Athlete mostrada no código abaixo.

package abl.athlete.pc;public class Athlete{ private int athleteID; private String lastName; private String firstName; ... // restante dos atributos public void setAthleteID(int id) { //métodos modificadores (set) athleteID = id; } ... // outros métodos modificadores public int getAthleteID() { // métodos acessores (get) return athleteID; } ... // outros métodos acessores}

2. Escolha um nome para o pacote. Adicione a palavra-chave package no arquivo do código-fonte para uma definição de classe reutilizável. Neste exemplo, o nome do pacote é abl.athlete.pc que é o nome do pacote para classes persistentes e listas de classes. No exemplo é:

package abl.athlete.pc;

Colocando a palavra-chave package no início do arquivo fonte indica que a classe definida no arquivo faz parte do pacote especificado.

3. Compile a classe para que seja colocada na devida estrutura de diretório de pacotes. A classe compilada torna-se disponível para o compilador e o interpretador. Quando um arquivo Java contendo um pacote é compilado, o arquivo resultante *.class é colocado no diretório especificado pelo comando package. No exemplo, o arquivo athlete.class é colocado no diretório pc dentro do diretório athlete que está dentro do diretório abl. Se estes diretórios não existirem, o compilador os criará.

4. Para reutilizar a classe, simplesmente importe o pacote. O código mostrado no código abaixo é um exemplo de importação da classe Athlete que é utilizada pela classe DBAthlete.

import abl.athlete.pc.*; // Todas as classes públicas deste pacote // estão disponíveis para uso em DBAthletepublic class DBAthlete { private Athlete ath; // Define uma referência para um objeto Athlete ... // restante do código}


JEDITM

5. Implementando Controladores

Implementar controladores é como escrever classes nos módulos anteriores. Uma boa prática de programação é a utilização de classes abstratas e interfaces. Esta seção serve como uma revisão de classes abstratas e interfaces. A utilização de classes abstratas e interfaces aumenta consideravelmente a capacidade do software de ser reutilizável e gerenciável. Também permite ao software ter capacidades 'plug-and-play'. Esta seção serve como uma revisão de classes abstratas e interfaces em Java1.

5.1. Classes Abstratas

Suponha que queiramos criar uma superclasse que tenha certos métodos com alguma implementação, e outros métodos que serão implementados pelas suas subclasses.

Por exemplo, queremos criar uma superclasse chamada LivingThing (SerVivo). Esta classe terá alguns métodos como breath (respirar), eat (comer), sleep (dormir) e walk (andar). Entretanto, há alguns métodos nesta superclasse que não poderemos generalizar o seu comportamento. Tomemos, por exemplo, o método walk. Todos os seres vivos não se locomovem do mesmo jeito. Veja os seres humanos, por exemplo. Os humanos andam em duas pernas, enquanto que outros seres vivos, como os cachorros, andam em quatro patas. Entretanto, há várias características que os seres vivos têm em comum, e este é o motivo para querermos criar uma superclasse genérica para isso.

Figura 1: Classe Abstrata

A fim de implementarmos isto, podemos criar uma superclasse que tenha alguns métodos com implementação e outros sem. Este tipo de classe é denominada classe abstrata.

Uma classe abstrata é uma classe que não pode ser instanciada. Geralmente aparece no topo de uma hierarquia de classes na programação orientada a objeto, definindo os vários tipos de ações possíveis com os objetos de todas as subclasses.

Os métodos da classe abstrata que não têm implementação são chamados métodos abstratos. Para criar um método abstrato, simplesmente escreva a declaração do método sem conteúdo nenhum e use a palavra-chave abstract. Por exemplo:

public abstract void someMethod();

Criaremos um exemplo de classe abstrata.

public abstract class LivingThing { public void breath(){ System.out.println("Living Thing breathing..."); } public void eat(){ System.out.println("Living Thing eating..."); } /** * método abstrato walk * Este método será implementado pelas subclasses de LivingThing */ public abstract void walk();

1 O uso do texto do curso JEDI Introdução à Programação teve autorização prévia dos seus autores.


JEDITM

}

Quando uma classe estende a classe abstrata LivingThing, será obrigada a implementar o método abstrato walk(), caso contrário está subclasse deverá ser uma classe abstrata também e, portanto, não poderá ser instanciada. Por exemplo:

public class Human extends LivingThing { public void walk(){ System.out.println("Human walks..."); }}

Se a classe Human não implementasse o método walk(), ocorreria a seguinte mensagem de erro:

Human.java:1: Human is not abstract and does not override abstract method walk() in LivingThingpublic class Human extends LivingThing ^1 error

Dicas de Codificação:

Use classes abstratas para definir vários tipos de comportamentos no topo das hierarquia das classes na programação orientada a objetos, e use as suas subclasses para implementar os detalhes da classe abstrata.

5.2. Interfaces

Uma interface é um tipo de bloco especial que contém apenas a assinatura de métodos (e provavelmente constantes). As interfaces definem as assinaturas de um conjunto de métodos, sem o corpo.

As interfaces definem uma maneira pública e padrão para especificar o comportamento das classes. Elas permitem que as classes, independentemente de sua localização na hierarquia de classes, implementem comportamentos comuns. As interfaces implementam o polimorfismo também, pois uma classe pode chamar um método de uma interface e a versão apropriada deste método será executada dependendo do tipo do objeto passado na chamada ao método da interface.

5.3. Por que usamos Interfaces?

Devemos usar interfaces quando queremos que classes não relacionadas implementem métodos parecidos. Através das interfaces podemos observar similaridades entre as classes não relacionadas sem que tenhamos que forçar um relacionamento artificial na classe.

Vamos tomar como exemplo a classe Line que contém métodos que calcula o tamanho da linha e compara o objeto Line com objetos da mesma classe. Suponha que tenhamos outra classe MyInteger que contém métodos que compara um objeto MyInteger com objetos da mesma classe. Como podemos ver aqui, ambas as classes têm métodos parecidos que os comparam com outros outros objetos do mesmo tipo, entretanto eles não estão relacionados entre si. Para que possamos forçar uma maneira de se ter certeza de que estas duas classes implementam alguns métodos com assinaturas parecidas, podemos usar uma interface para isso. Podemos criar uma classe interface, por exemplo, a interface Relation que terá algumas declarações de métodos de comparação. A nossa interface Relation pode ser declarada como:

public interface Relation { public boolean isGreater( Object a, Object b); public boolean isLess( Object a, Object b); public boolean isEqual( Object a, Object b);}

Uma outra razão para utilizar uma interface na programação de um objeto é revelar a interface de


JEDITM

programação de um objeto, sem revelar a sua classe. Como poderemos ver mais tarde na seção Interface versus Classes, podemos utilizar uma interface como um tipo de dado.

Finalmente, precisamos utilizar interfaces para modelar heranças múltiplas o que permite que uma classe tenha mais de uma superclasse. A herança múltipla não está presente no Java, mas está presente em outras linguagens orientadas a objeto como o C++.

5.4. Interface versus Classes Abstratas

A seguir termos as principais diferenças entre uma interface e uma classe abstrata: os métodos de uma interface não têm corpo, uma interface somente pode definir constantes e uma interface não tem nenhum relacionamento direto de herança com qualquer classe particular, elas são definidas independentemente.

5.5. Interface versus Classe

Uma característica comum entre uma interface e uma classe é que ambas são tipos. Isto significa que uma interface pode ser utilizada em lugares onde uma classe pode ser utilizada. Por exemplo, dada uma classe Person e uma interface PersonInterface, as seguintes declarações são válidas:

PersonInterface pi = new Person();Person pc = new Person();

Entretanto, não se pode instanciar uma interface. Um exemplo disso é:

PersonInterface pi = new PersonInterface(); //ERRO DE COMPILAÇÃO!!!

Outra característica comum é que ambas, interface e classe, podem definir métodos. Entretanto, uma interface não possui código de implementação, o que ocorre na classe.

5.6. Criando Interfaces

Para criar uma interface escrevemos:

public interface [InterfaceName] { // alguns métodos sem corpo}

Como um exemplo, criaremos uma interface que defina relacionamentos entre dois objetos conforme a “ordem natural” dos objetos.

public interface Relation { public boolean isGreater(Object a, Object b); public boolean isLess(Object a, Object b); public boolean isEqual(Object a, Object b);}

Para utilizar a interface, usamos a palavra-chave implements. Por exemplo:

/** * Esta classe define um seguimento de linha */public class Line implements Relation { private double x1; private double x2; private double y1; private double y2; public Line(double x1, double x2, double y1, double y2) { this.x1 = x1; this.x2 = x2; this.y1 = y1; this.y2 = y2; } public double getLength() { double length = Math.sqrt((x2-x1)*(x2-x1) + (y2-y1)* (y2-y1));


JEDITM

return length; } public boolean isGreater(Object a, Object b) { double aLen = ((Line)a).getLength(); double bLen = ((Line)b).getLength(); return (aLen > bLen); } public boolean isLess(Object a, Object b) { double aLen = ((Line)a).getLength(); double bLen = ((Line)b).getLength(); return (aLen < bLen); } public boolean isEqual(Object a, Object b) { double aLen = ((Line)a).getLength(); double bLen = ((Line)b).getLength(); return (aLen == bLen); }}

Quando sua classe tenta implementar uma interface, sempre tenha certeza de que todos ps métodos da interface foram implementados ou, caso contrário, será mostrado o seguinte erro:

Line.java:4: Line is not abstract and does not override abstract method isGreater(java.lang.Object,java.lang.Object) in Relationpublic class Line implements Relation ^1 error


Utilize interfaces para criar algumas definições padrões de métodos em várias classes diferentes. Uma vez que um conjunto padrão de definições de métodos esteja criado, é possível escrever um único método para manipular todas as classes que implementam a interface.

5.7. Relacionamento de uma Interface com uma Classe

Como vimos na seção anterior, uma classe pode implementar uma interface se ela tiver código de implementação para todos os métodos definidos na interface.

Outro aspecto para observar sobre o relacionamento de interfaces com classe é que uma classe só pode ESTENDER UMA superclasse, mas pode IMPLEMENTAR VÁRIAS interfaces. Um exemplo de uma classe que implementa várias interfaces é:

public class Person implements PersonInterface, LivingThing, WhateverInterface { //algum código aqui}

Outro exemplo de uma classe que estende uma superclasse e implementa uma interface é:

public class ComputerScienceStudent extends Student implements PersonInterface, LivingThing { // algum código aqui}

Note que uma interface não faz parte do patrimônio hierárquico da classe. Classes não relacionadas podem implementar a mesma interface.

5.8. Herança entre Interfaces

Interfaces não são parte da hierarquia da classe. Entretanto, interfaces podem ter relacionamentos de herança entre si. Por exemplo, suponha que tenhamos duas interfaces StudentInterface e PersonInterface. Se StudentInterface estende PersonInterface, ele vai herdar todas as declarações de métodos em PersonInterface.


JEDITM

public interface PersonInterface { ...}public interface StudentInterface extends PersonInterface { ...}

Uma interface formaliza o polimorfismo. Ela define o polimorfismo de maneira declarativa, sem relação com a implementação. Esta é a chave para a capacidade “plug-and-play” de uma arquitetura. É um tipo especial de bloco contendo apenas assinaturas de métodos (e possivelmente constantes). As interfaces definem as assinaturas de um conjunto de métodos sem o corpo.


JEDITM

6. Implementando Conectividade com Banco de Dados usando Java (JDBC)

A maioria das aplicações utilizam um sistema de banco de dados relacional como repositório de dados. Uma linguagem denominada Structured Query Language (SQL) é utilizada quase que universalmente nestes sistemas. Ela é utilizada para fazer perguntas, isto é, requisitar informações que satisfaçam um determinado critério. Java permite que o programador escreva código que utilize os comandos SQL para acessar as informações em um sistema de banco de dados relacional. A engenharia do banco de dados que implementa os dados da aplicação não faz parte do escopo deste curso e normalmente é discutida em um curso de banco de dados. Esta seção discute como Java utiliza o JDBC para se conectar e requisitar serviços a um servidor de banco de dados. No exemplo, mostraremos um trecho de código que recupera registros de atletas do banco de dados. O código assume que Athlete e PCLAthlete já estejam implementados.

Os trechos de código a seguir são uma implementação de DBAthlete. Identifique em PCLAthlete onde são carregados os registros de atletas que satisfazem um critério baseado na entrada do usuário. O comando import java.sql importa o pacote que contém as classes e interfaces que manipulam bancos de dados relacionais em Java.

O construtor da classe tenta se conectar ao banco de dados. Se conseguir, comandos SQL podem ser enviados ao banco de dados. As linhas seguintes especificam a URL (Uniform Resource Locator – Localizador de Recurso Uniforme) do banco de dados que ajuda a classe a localizar o banco de dados, nome do usuário e senha. A URL especifica o protocolo de comunicação (JDBC), o subprotocolo (ODBC) e o nome do banco de dados (ABLDatabase). O nome do usuário e a senha também são especificados para logar no banco de dados; no exemplo, o nome do usuário é "postgre" e a senha é "postgres1".

String url = "jdbc:odbc:ABLDatabase";String username = "postgre";String password = "postgres1";

A definição de classe do driver do banco de dados deve ser carregada antes que se possa conectar ao banco de dados. A seguinte linha carrega o driver. Neste exemplo, o driver de banco de dados padrão ponte JDBC-ODBC é utilizado para permitir que qualquer classe Java acesse qualquer fonte de dados ODBC. Para mais informações do sobre o driver JDBC e os bancos de dados suportados, visite o seguinte site: http://java.sun.com/products/jdbc.

Class.forName("sun.jdbc.odbc.JdbcOdbcDriver");

Para estabelecer uma conexão, um objeto de conexão é criado. Ele gerencia a conexão entre o banco de dados e a classe Java. Ele também fornece suporte para a execução de comandos SQL. No exemplo, o seguinte comando fornece esta conexão.

connection = DriverManager.getConnection(url, username, password);

O método inicial que é invocado para começar a recuperação de registros de atletas do banco de dados é o método getAthleteRecord(). O código deste método é mostrado abaixo. O objeto selectStmt é utilizado para definir o comando SELECT que especifica quais registros serão recuperados do banco de dados. O método privado prepareSelectStmt() gera o comando select com o critério apropriado. O objeto statement é utilizado para enviar comandos SQL ao banco de dados e é instanciado utilizando-se o método createStatement() do objeto connection. O método executeQuery() do objeto statement é utilizado para executar o comando SELECT conforme especificado no objeto selectStmt. O resultado da pergunta é colocado e referenciado em rs que é um objeto ResultSet.

O objeto PCLAthlete é carregado pela execução do método populatePCLAthlete() que utiliza como entrada o ResultSet. Para cada registro no conjunto de resultados, um objeto athlete é instanciado e tem seus atribuídos preenchidos com os dados do atleta. O método getPCLAthlete() retorna uma referência para a lista de atletas gerada.


http://java.sun.com/products/jdbc

JEDITM

import java.sql.*;import java.util.*;public class DBAthlete { private Connection connection; private PCLAthlete athleteList; public DBTeam() { // Para conectar ao Banco de Dados... String url = "jdbc:odbc:ABLDatabase"; String username = "postgre"; String password = "postgres1"; try { Class.forName("sun.jdbc.odbc.JdbcOdbcDriver"); connection = DriverManager.getConnection(url, username, password); } catch (ClassNotFoundException e) { ... } catch (SQLException e) { ... } } // para executar o comando SELECT public void getAthleteRecord(String searchCriteria) throws SQLException { String selectStmt = prepareSelectStmt(searchCriteria); Statement statement = connection.createStatement(); ResultSet rs = statement.executeQuery(selectStmt); populatePCLAthlete(rs); statement.close(); } // para gerar o comando SELECT com o critério de pesquisa private String prepareSelectStmt(String searchCriteria) throws SQLException { String query = "SELECT * FROM athlete, guardian " query = query + "WHERE athlete.guardianID = guardian.guardianID"; query = query + " AND " + searchCriteria + ";" ; return query; } // para preencher a lista persistente da classe. private void populatePCLAthlete(ResultSet rs) throws SQLException { .... athleteList = new PCLAthlete(); .... // dentro de um bloco try e catch ResultSetMetaData rsmd = rs.getMetaData(); do { athleteList.add(getNextMember(rs, rsmd); } while (rs.next()) } // para gerar um objeto atleta a ser adicionado a PCLAthlete private Athlete getNextMember(ResultSet rs, ResultSetMetaData rsmd) throws SQLException { Athlete a = new Athlete(); // Construtor para converter string em integer a.setAthleteID(rs.getString(1)); a.setLastName(rs.getString(2)); a.setFirstName(rs.getString(3)); ... // preencher os atributos para o objeto atleta a return a; } // retorna uma referência para a lista de atletas (PCLAthlete) public PCLAthlete getPCLAthlete() throws SQLException { return athleteList; }}


JEDITM

7. Implementando a Interface Gráfica do Usuário

Mesmo sem conhecer sobre as APIs de interface gráfica do usuário (GUI), ainda é possível criar muitas de classes diferentes. Entretanto, os projetos tendem a ser estranhos e pouco atraentes para os usuários. Ter uma boa GUI afeta a utilização da sua aplicação. Isto resulta em facilidade no uso para os usuários de seu projeto. Java oferece ferramentas como o Abstract Windowing Toolkit (AWT) e o Swing para desenvolver aplicações com GUIs interativos. A seção seguinte fornece uma discussão de Abstract Windowing Toolkit e Swing2.

A biblioteca Java Fundation Classe (JFC), é uma parte importante do Java SDK, se refere a uma coleção de APIs que simplificam o desenvolvimento de aplicações Java com GUI. Originalmente consiste de cinco APIs, incluindo o AWT e o Swing. As outras três APIs são Java2D, Accessibility, e Drag and Drop. Todas estas APIs ajudam os desenvolvedores no projeto e implementação de aplicações visualmente incrementadas.

Ambos AWT e Swing fornecem componentes GUI que podem ser usados na criação de aplicações e applets Java. Conheceremos mais sobre applets em outras lições. Ao contrário de alguns componentes AWT que utilizam código nativo, o Swing é totalmente escrito utilizando a linguagem de programação Java. Como resultado, o Swing fornece uma implementação independente de plataforma garantindo que as aplicações distribuídas em diferentes plataformas terão a mesma aparência. O AWT, entretanto, faz com que a aparência de uma aplicação executada em duas máquinas diferentes sejam passíveis de comparação. A API Swing é construída sobre um número de APIs que implementam várias partes do AWT. Como resultado, os componentes AWT ainda podem ser usados com os componentes Swing.

7.1. Componentes GUI AWT

Classes Window Fundamentais

No desenvolvimento de aplicações GUI, os componentes GUI tais como botões e campos de texto são colocados em contêineres. Esta é a lista das classes contêineres que são encontradas no pacote AWT.

Classe Descrição

Component Uma classe abstrata para objetos que podem ser mostrados na tela e interagir com o usuário. É a raiz de todas as classes AWT.

contêiner Uma subclasse abstrata da classe Component. Um componente que pode conter outros componentes.

Panel Estende a classe contêiner. Um quadro ou janela sem a barra de título, a barra de menu e as bordas. Superclasse da classe Applet.

Window Estende a classe contêiner. Um janela de alto nível, o que significa que não pode estar contida dentro de qualquer outro objeto. Não tem bordas ou barra de menu.

Frame Estende a classe Window. Uma janela com título, barra de menu, borda e cantos redimensionáveis. Tem quatro construtores, dois dos quais têm as seguintes assinaturas:

Frame()Frame(String title)

Tabela 1: Classes Contêineres AWT

Para definir o tamanho da janela, o método override setSize é usado.

void setSize(int width, int height)

Redimensiona o componente para a largura e altura fornecidos como parâmetros.

void setSize(Dimension d)

Redimensiona este componente para d.width e d.height baseado na Dimension d especificado.

2 O uso do texto do curso JEDI Introdução à Programação II teve autorização prévia dos seus autores.


JEDITM

Por padrão, uma janela não está visível a menos que seja definida sua visibilidade como true. Aqui está a sintaxe para o método setVisible.

void setVisible(boolean b)

No projeto de aplicações GUI, objetos Frame geralmente são usados. Aqui está um exemplo da criação de tal aplicação.

import java.awt.*;public class SampleFrame extends Frame { public static void main(String args[]) { SampleFrame sf = new SampleFrame(); sf.setSize(100, 100); // Tente remover esta linha sf.setVisible(true); // Tente remover esta linha }}

Observe que o botão fechar do quadro não funciona ainda pois nenhum mecanismo de tratamento de evento foi adicionado ao programa ainda. Conheceremos sobre tratamento de eventos em futuras lições.

Gráficos

Diversos métodos gráficos podem ser encontrados na classe Graphics. Aqui está uma lista com alguns destes métodos.

drawLine() drawPolyline() setColor()fillRect() drawPolygon() getFont()drawRect() fillPolygon() setFont()clearRect() getColor() drawString()

Tabela 2: Alguns métodos da classe Graphics

Relacionada a esta classe, temos a classe Color, que tem três construtores.

Formato do Construtor DescriçãoColor(int r, int g, int b) Os valores inteiros são de 0 a 255.

Color(float r, float g, float b) Os valores float são de 0.0 a 1.0.

Color(int rgbValue) O intervalo de valor vai de 0 a 224-1 (preto a branco).

Vermelho (red): bits 16-23

Verde (green): bits 8-15

Azul (blue): bits 0-7

Tabela 3: Construtores de Color

Aqui está um exemplo de programa que utiliza alguns dos métodos da classe Graphics.

import java.awt.*;public class GraphicPanel extends Panel { public GraphicPanel() { setBackground(Color.black); //constante na classe Color } public void paint(Graphics g) { g.setColor(new Color(0,255,0)); //verde g.setFont(new Font("Helvetica",Font.PLAIN,16)); g.drawString("Hello GUI World!", 30, 100); g.setColor(new Color(1.0f,0,0)); //vermelho g.fillRect(30, 100, 150, 10); } public static void main(String args[]) { Frame f = new Frame("Testing Graphics Panel"); GraphicPanel gp = new GraphicPanel();


JEDITM

f.add(gp); f.setSize(600, 300); f.setVisible(true); }}

Para que um painel se torne visível, ele deve ser colocado dentro de uma janela visível, como um Frame.

Mais Componentes AWT

Aqui está uma lista dos controles AWT. Controles são componentes tais como botões ou campos de texto que permitem ao usuário interagir com a aplicação GUI. São subclasses da classe Component.

Label Button ChoiceTextField Checkbox ListTextArea CheckboxGroup Scrollbar

Tabela 4: Componentes AWT

O seguinte programa cria uma moldura contendo controles dentro dela.

import java.awt.*;public class FrameWControls extends Frame { public static void main(String args[]) { FrameWControls fwc = new FrameWControls(); fwc.setLayout(new FlowLayout()); fwc.setSize(600, 600); fwc.add(new Button("Test Me!")); fwc.add(new Label("Labe")); fwc.add(new TextField()); CheckboxGroup cbg = new CheckboxGroup(); fwc.add(new Checkbox("chk1", cbg, true)); fwc.add(new Checkbox("chk2", cbg, false)); fwc.add(new Checkbox("chk3", cbg, false)); List list = new List(3, false); list.add("MTV"); list.add("V"); fwc.add(list); Choice chooser = new Choice(); chooser.add("Avril"); chooser.add("Monica"); chooser.add("Britney"); fwc.add(chooser); fwc.add(new Scrollbar()); fwc.setVisible(true); }}

7.2. Gerenciadores de Layout

A posição e o tamanho dos componentes dentro de cada contêiner é determinado pelo gerenciador de layout. Os gerenciadores de layout determinam o layout dos componentes no contêiner. Estes são alguns gerenciadores de layout incluídos no Java.

1. FlowLayout2. BorderLayout3. GridLayout4. GridBagLayout5. CardLayout

O gerenciador de layout pode ser definido utilizando o método setLayout da classe contêiner. O método tem a seguinte assinatura.


JEDITM

void setLayout(LayoutManager mgr)

Caso se opte pela não utilização de qualquer gerenciador de layout, é possível passar o valor null como parâmetro para este método. Entretanto, todos os componentes devem ser posicionados manualmente utilizando o método setBounds da classe Component.

public void setBounds(int x, int y, int width, int height)

O método que controla a posição é baseado nos parâmetros x e y, e o tamanho do componente nos parâmetros width e height. Isto pode se tornar difícil e tedioso caso se tenham muitos objetos Component dentro do objeto contêiner. Este método deverá ser chamado para cada componente.

Nesta seção, veremos os três primeiros gerenciadores de layout.

Gerenciador FlowLayout

O FlowLayout é o gerenciador padrão para a classe Panel e suas subclasses, incluindo a classe Applet. Ele posiciona os componentes no sentido esquerda pra direita e de cima para baixo, começando do canto esquerdo superior. Imagine-se digitando em um editor de textos. É assim que o gerenciador FlowLayout funciona. Ele tem três construtores que estão listados abaixo.

Construtores do FlowLayout

FlowLayout() Cria um novo objeto FlowLayout com alinhamento central e 5 unidades de espaçamento horizontal e vertical aplicadas aos componentes por padrão.

FlowLayout(int align)Cria um novo objeto FlowLayout com o alinhamento especificado e 5 unidades de espaçamento horizontal e vertical aplicadas aos componentes por padrão.

FlowLayout(int align, int hgap, int vgap) Cria um novo objeto FlowLayout com o primeiro parâmetro como alinhamento e o valor de hgap em unidades de espaçamento horizontal e o valor de vgap em unidades de espaçamento vertical aplicadas aos componentes.

Tabela 5: Construtores do FlowLayout

O espaçamento se refere ao espaço entre os componentes e é medido em pixels. O parâmetro de alinhamento deve ser um dos seguintes:

1. FlowLayout.LEFT2. FlowLayout.CENTER3. FlowLayout.RIGHT

Qual é a saída esperada para a seguinte classe?

import java.awt.*;public class FlowLayoutDemo extends Frame { public static void main(String args[]) { FlowLayoutDemo fld = new FlowLayoutDemo(); fld.setLayout(new FlowLayout(FlowLayout.RIGHT, 10, 10)); fld.add(new Button("ONE")); fld.add(new Button("TWO")); fld.add(new Button("THREE")); fld.setSize(100, 100); fld.setVisible(true); }}

Temos na Figura 2 um exemplo de saída executado na plataforma Windows.


JEDITM

Figura 2: Saída do código exemplo no Windows

Gerenciador BorderLayout

O BorderLayout divide o Contêiner em cinco partes - norte, sul, leste, oeste e centro. Cada componente é adicionado a uma região específica. As regiões norte e sul esticam horizontalmente enquanto as regiões leste e oeste ajustam-se verticalmente. A região central, por outro lado, ajusta-se horizontal e verticalmente. Este é o layout padrão dos objetos Window, incluindo os objects das subclasse de Window do tipo Frame e Dialog.

Construtores de BorderLayout

BorderLayout() Cria um novo objeto BorderLayout sem espaços entre os diferentes componentes.

BorderLayout(int hgap, int vgap) Cria um novo objeto BorderLayout com espaçamento horizontal hgap unidades e espaçamento vertical com o valor de vgap em unidades aplicados entre os diferentes componentes.

Tabela 6: Construtores de BorderLayout

Assim como o gerenciador FlowLayout, os parâmetros hgap e vgap também se referem ao espaçamento entre os componentes dentro do contêiner.

Para adicionar um componente em uma região específica, use o método add e passe dois parâmetros: o componente a ser adicionado e a região onde o componente deverá ser posicionado. Observe que apenas um componente pode ser colocado em uma região. Quando se adiciona mais de um componente a uma região em particular, será mostrado apenas o último componente adicionado. A seguinte lista fornece as regiões válidas e campos pré-definidos na classe BorderLayout.

1. BorderLayout.NORTH2. BorderLayout.SOUTH3. BorderLayout.EAST4. BorderLayout.WEST5. BorderLayout.CENTER

Aqui está um exemplo de uma classe que demonstra como o BorderLayout funciona.

import java.awt.*;public class BorderLayoutDemo extends Frame { public static void main(String args[]) { BorderLayoutDemo bld = new BorderLayoutDemo(); bld.setLayout(new BorderLayout(10, 10)); // pode ser removido bld.add(new Button("NORTH"), BorderLayout.NORTH); bld.add(new Button("SOUTH"), BorderLayout.SOUTH); bld.add(new Button("EAST"), BorderLayout.EAST); bld.add(new Button("WEST"), BorderLayout.WEST); bld.add(new Button("CENTER"), BorderLayout.CENTER); bld.setSize(200, 200); bld.setVisible(true); }}

Aqui está uma amostra da saída desta classe. A segunda figura mostra o efeito do redimensionamento da janela.


JEDITM

Figura 3: Saída do código exemplo

Gerenciador GridLayout

Com o gerenciador GridLayout, os componentes também são posicionados da esquerda para a direita e de cima para baixo assim como no gerenciador FlowLayout. Além disso, o gerenciador GridLayout divide o contêiner em um determinado número de linhas e colunas. Todas estas regiões terão o mesmo tamanho. Ele sempre ignora o tamanho definido para o componente.

A seguir estão os construtores disponíveis para a classe GridLayout.

Construtores de GridLayout

GridLayout()Cria um novo objeto GridLayout com uma única linha e uma única coluna, por padrão.

GridLayout(int rows, int cols) Cria um novo objeto BorderLayout com o número de linhas e colunas especificado.

GridLayout(int rows, int cols, int hgap, int vgap) Cria um novo objeto BorderLayout com o número de linhas e colunas especificado. O espaçamento no valor de hgap em unidades horizontais e vgap unidades verticais é aplicado aos componentes.

Tabela 7: Construtores de GridLayout

Tente esta classe.

import java.awt.*;public class GridLayoutDemo extends Frame { public static void main(String args[]) { GridLayoutDemo gld = new GridLayoutDemo(); gld.setLayout(new GridLayout(2, 3, 4, 4)); gld.add(new Button("ONE")); gld.add(new Button("TWO")); gld.add(new Button("THREE")); gld.add(new Button("FOUR")); gld.add(new Button("FIVE")); gld.setSize(200, 200); gld.setVisible(true); }}

Esta é a saída da classe. Observe o efeito do redimensionamento da janela.


JEDITM


Layouts Complexos e Painéis

Pode-se criar layouts mais complexos, combinando os diferentes gerenciadores de layout com a utilização de painéis. Lembre-se que um Panel é um contêiner e um Component ao mesmo tempo. É possível inserir Components no Panel e depois adicionar o Panel em uma região específica de um contêiner. Observe esta técnica utilizada no exemplo seguinte.

import java.awt.*;public class ComplexLayout extends Frame { public static void main(String args[]) { ComplexLayout cl = new ComplexLayout(); Panel panelNorth = new Panel(); Panel panelCenter = new Panel(); Panel panelSouth = new Panel(); // Painel na posição Norte // Panels usam FlowLayout por padrão panelNorth.add(new Button("ONE")); panelNorth.add(new Button("TWO")); panelNorth.add(new Button("THREE")); // Painel na posição Centro panelCenter.setLayout(new GridLayout(4,4)); panelCenter.add(new TextField("1st")); panelCenter.add(new TextField("2nd")); panelCenter.add(new TextField("3rd")); panelCenter.add(new TextField("4th")); // Painel na posição Sul panelSouth.setLayout(new BorderLayout()); panelSouth.add(new Checkbox("Choose me!"), BorderLayout.CENTER); panelSouth.add(new Checkbox("I'm here!"), BorderLayout.EAST); panelSouth.add(new Checkbox("Pick me!"), BorderLayout.WEST); // Adicionando os painéis para o Frame // Frames usam BorderLayout por padrão cl.add(panelNorth, BorderLayout.NORTH); cl.add(panelCenter, BorderLayout.CENTER); cl.add(panelSouth, BorderLayout.SOUTH); cl.setSize(300,300); cl.setVisible(true); }}

Aqui está a saída da classe.


JEDITM


7.3. Componentes GUI Swing

Assim como o pacote AWT, o pacote Swing provê classes para a criação de aplicativos GUI. O pacote é encontrado em javax.swing. A diferença principal entre este dois é que os componentes Swing são totalmente escritos usando Java enquanto que o último não é. Como resultado, classes GUI escritas usando classes do pacote Swing possuem a mesma aparência e comportamento mesmo quanto executadas em sistemas operacionais diferentes. Mais ainda, Swing provê componentes mais interessantes para escolha de cores e o painel de opções.

O nome dos componentes GUI Swing são semelhantes aos nomes dos componentes GUI AWT. Uma diferença óbvia é na convenção de nomeação dos componentes. Basicamente, os nomes dos componentes Swing são simplesmente os nomes dos componentes AWT mas com o prefixo adicional J. Por exemplo, um componente no AWT é a classe Button. O componente correspondente para isto no pacote Swing é a classe JButton. Abaixo está a lista de alguns dos componentes GUI Swing.

Componente DescriçãoJComponent A classe raiz para todos os componentes Swing, excluindo os contêineres top-level

JButton Um botão. Corresponde à classe Button no pacote AWT

JCheckBox Um item que pode ser selecionado ou não pelo usuário. Corresponde à classe Checkbox no pacote AWT

JFileChooser Permite ao usuário selecionar um arquivo. Corresponde à classe FileChooser no pacote AWT

JTextField Permite editar uma linha única de texto. Corresponde à classe TextField no pacote AWT

JFrame Estende e corresponde à classe Frame no pacote AWT mas os dois são levemente incompatíveis em termos da adição de componentes para este contêiner. É necessário se obter o conteúdo do painel corrente antes de se adicionar um componente

JPanel Estende a classe JComponent. Uma classe de contêiner simples mas não top-level. Corresponde à classe Panel no pacote AWT

JApplet Estende e corresponde à classe Applet no pacote AWT. Também é incompatível com a classe Applet em termos da adição de componentes para este contêiner

JOptionPane Estende a classe JComponent. Provê uma maneira fácil de mostrar caixas de diálogo

JDialog Estende e corresponde à classe Dialog no pacote AWT. Geralmente usado para informar algo ao usuário ou solicitar uma entrada do usuário.

JColorChooser Estende a classe JComponent. Permite ao usuário selecionar uma cor.


JEDITM

Tabela 8: Alguns componentes Swing

Para a lista completa dos componentes Swing, favor consultar a documentação API.

Definindo Contêineres Top-Level

Conforme mencionado, os contêineres top-level como o JFrame e o JApplet no Swing são incompatíveis com os no AWT. Isto ocorre em termos da adição de componentes ao contêiner. Em vez de adicionar diretamente um componente no contêiner como nos contêineres AWT, primeiro devemos obter o panel de conteúdo do contêiner. Para fazer isto, teremos que utilizar o método getContentPane do contêiner.

Um Exemplo JFrame

import javax.swing.*;import java.awt.*;public class SwingDemo { private JFrame frame; private JPanel panel; private JTextField textField; private JButton button; private contêiner contentPane; public void launchFrame() { // Inicialização frame = new JFrame("My First Swing Application"); panel = new JPanel(); textField = new JTextField("Default text"); button = new JButton("Click me!"); contentPane = frame.getContentPane(); // Adicione componentes ao painel– usa FlowLayout por padrão panel.add(textField); panel.add(button); // Adicione componentes ao contentPane– usa BorderLayout por padrão contentPane.add(panel, BorderLayout.CENTER); frame.pack(); // faz com que o tamanho do quadro seja baseado nos componentes frame.setVisible(true); } public static void main(String args[]) { SwingDemo sd = new SwingDemo(); sd.launchFrame(); }}

Observe que o pacote java.awt ainda é importado pois os gerenciadores de layout sendo usados são definidos neste pacote. Além disso, o fato de se dar um título ao quadro e o empacotamento dos componentes dentro do quadro também é aplicável aos quadros AWT.


Observe o estilo de codificação aplicado neste exemplo, ao contrário dos exemplos para o AWT. Os componentes são declarados como campos, um método launchFrame é definido, e a inicialização e adição dos componentes são todos feitos no método launchFrame. Simplesmente não estendemos mais a classe Frame. A vantagem de se utilizar este estilo se tornará aparente quando chegarmos a trabalhar com tratamento de eventos.

Aqui está um exemplo de saída.


JEDITM


Um Exemplo JOptionPane

import javax.swing.*;public class JOptionPaneDemo { private JOptionPane optionPane; public void launchFrame() { optionPane = new JOptionPane(); String name = optionPane.showInputDialog("Hi, what's your name?"); optionPane.showMessageDialog(null, "Nice to meet you, " + name + ".", "Greeting...", optionPane.PLAIN_MESSAGE); System.exit(0); } public static void main(String args[]) { new JOptionPaneDemo().launchFrame(); }}

Observe como é simples solicitar dados do usuário. Este é o resultado da execução desta classe.


7.4. Usando AWT e Swing no Sun Java™ Studio Enterprise 8

1. Pressione um duplo clique no ícone do Java Studio Enterprise 8 em seu computador

Figura 8: Iniciando o Java Studio Enterprise 8

2. Iniciar um novo projeto para a criação da interface com o usuário. Para isso, selecionar File -> New Project. A caixa de diálogo New Project mostrada na Figura 9 aparecerá.


JEDITM

Figura 9: Selecionando o Tipo do Projeto

3. Desta caixa de diálogo, selecionar General -> Java Application. Pressionar o botão Next e a caixa de diálogo New Java Application aparecerá.

Figura 10: Caixa de Diálogo New Java Application

4. Na caixa de diálogo New Java Application, informa o nome do projeto e o diretório que será usado para manter todos arquivos relacionados ao projeto. Figura 10 mostra um exemplo. O nome do projeto é AthleteDB e o diretório é /home/noel/TestHD/JStudio.

5. O Java Studio Enterprise apresentará a inicialização padrão mostrada na Figura 11.


JEDITM

Figura 11: Tela Padrão de Inicialização

6. Para adicionar um quadro, selecionar File -> New File -> Java GUI Forms -> JFrame Form. Figura 12 e Figura 13 mostram como fazer isto.

Figura 12: Selecionando a opção New File


JEDITM

Figura 13: Selecionando Java GUI Forms e JFrame Form

7. Pressionar o botão Next. A caixa de diálogo New JFrame Form conforme mostrado Figura 14 irá aparecer. Informe o nome da classe. Neste caso, o nome da tela é AForm. Então, pressione o botão Finish.

Figura 14: Caixa de Diálogo New JFrame Form

8. O Design View inicia-se e é mostrado na Figura 15.


JEDITM

Figura 15: Inicialização do Design View

9. O Palette Manager está localizado na janela superior direita e abaixo está o Component Properties. O Palette Manager contém objetos dos pacotes Swing, AWT, Layouts, e Beans.

Figura 16: Palette Manager

10.Para utilizar o Palette Manager utilizando o estilo DragNDrop para a janela de Design, certifique-se que o Selection Mode está habilitado. É o primeiro ícone ao lado do Design Tab. Figura 17 mostra o Design Tab. O botão de seleção deve estar destacado; é o botão com a seta e a caixa.

Figura 17 Selection Model Habilitado

11.O Component Inspector consiste de um visão geral dos objetos GUIs adicionados ao Frame. Figura 18 mostra o Component Inspector. É parte da janela rotulada Inspector. Uma Visão de


JEDITM

Árvore dos componentes é usada para mostrar a lista dos componentes.

Figura 18: Component Inspector

12.Para construir ou salvar o projeto, selecionar Build -> Build Main Project. Isto é mostrado em Figura 19.

Figura 19: Opção Build

13.O Build Output é gerado no Output Tab na parte de baixo do programa. Isto é mostrado na Figura 20.


JEDITM

Figura 20: Build Output

14.Para executar o projeto específico, clique Run -> Run File -> Run "AForm.java". Isto é mostrado na Figura 21.

Figura 21: Opção Run


JEDITM

Esboçando o Formulário Athlete da Aplicação Exemplo

1. Clique com o botão direito em JFrame no Component Inspector. Vai ser aberto um menu contendo o seu layout assim como outras propriedades. O GridLayout estará selecionado por padrão. Veja a Figura 22 para ver como isto é feito.

Figura 22: Definindo o Layout

2. Dê uma olhada no Properties Tab abaixo do Palette Manager, as propriedades para o GridLayout estão ilustrados e também podem ser modificadas. Figura 23 mostra uma instância do Properties Tab.

Figura 23: Properties Tab

3. Para adicionar um Panel, clique com o botão direito no nome do quadro na janela do Component Inspector. Neste exemplo, é o JFrame1. Selecionar Add From Palette -> AWT -> Panel. Figura 24 mostra isto.


JEDITM

Figura 24: Adicionando um Panel

4. Para renomear o painel, clique com o botão direito no nome do painel na janela do Component Inspector. Selecionar Rename. Informar o novo nome do painel. Figura 25 mostra isto.

Figura 25 Renomeando um Panel5. Adicione Labels utilizando o estilo DragNDrop. Clique no ícone Selection Mode e no ícone

Label. Então, clique e arraste-o à janela Design. Note a mensagem no rodapé do programa


JEDITM

mostrando Add Label to p1. Figura 26 mostra isto.

Figura 26: Adicionando um Label

6. O Component Inspector mostra agora que o Label label1 foi adicionado ao Panel p1 e o Properties Tab agora mostra os Properties, Events, e Code para aquele label. Figura 27 mostra isto.

Figura 27 Exemplo de Label1 e Propriedades


JEDITM

7. A adição de GUIs ao Design também pode ser feito clicando-se com o botão direito o quadro ou painel no Component Inspector. Isto é mostrado na Figura 28.

Figura 28: Clicando com o botão direito em Frame ou Panel

8. Continue adicionando e modificando as propriedades dos sucessivos objetos Labels, TextFields, TextArea, Buttons e os Checkboxes ao Panel p1 e faça o mesmo no Panel p2. É possível também realizar um DragNDrop entre os quadros. Um exemplo de AForm.java é mostrado na Figura 29 com componentes de janela adicionais.

Figura 29 Exemplo AForm.java


JEDITM

9. Para testar o formulário, clique o ícone Test Form no Design Panel para ver o layout corrente. Figura 30 e Figura 31 mostram o que acontece.

Figura 30: Clicando no Ícone Test Form

Figura 31: Executando o Test Form

10.Clique com o botão direito no GridBagLayout no Component Inspector. Selecione Customize para arrumar os layouts utilizando o estilo DragNDrop também. A janela Customizer será


JEDITM

mostrada. Figura 32 mostra um exemplo.

Figura 32: GridBagLayout Customizer

11.Realize um DragNDrop nos componentes para às suas posições corretas conforme a disposição mostrada na Figura 33.

Figura 33: Novas Posições


JEDITM

12.Feche-o e clique no ícono Test Form para ver as diferenças. A tela deve se parecer com a tela na Figura 34.

Figura 34: Novo GridBagLayout

13.Observe que tudo está centralizado. Volte ao GridBagLayout -> Customize para editar os valores associados a cada um, assim como outras modificações necessárias. O layout final quando o AForm.java é executado (BUILD ou Shift+F6) deve se parecer com a Figura 35.

Figura 35: Novo Layout do Form


JEDITM

14.Para adicionar diálogos ao formulário, vá para Component Inspector, clique com o botão direito em Other Components. Selecione Swing -> JDialog. Faça o mesmo processo para os layouts.

Figura 36: Adicionando um Dialog

15.Para habilitar o evento para o botão Find no Athlete Form, clique com o botão direito em seu nome no Component Inspector. Selecione Events -> Action -> actionPerformed.

Figura 37: Habilitando Eventos para o Form


JEDITM

16.Isto irá selecionar o tab Source ao lado do tab Design na janela Design. Modifique o código de tal maneira que o Diálogo Find An Athlete seja visível. Faça o mesmo para os botões OK e Cancel no Diálogo.

Figura 38: Setando o Diálogo Find Athlete como Visível

17.Teste o formulário. Do Formulário Athlete, clique o Botão Find. Ele deve mostrar o Formulário Find An Athlete. Deste formulário, clique no botão OK. Será mostrado o Formulário Athlete List.

Figura 39 Testando todos os formulários

18.Reconstrua e Execute.


JEDITM

8. Controlando a Versão do Software

É muito difícil controlar o desenvolvimento do software sem a ajuda de um Sistema de Versionamento. Esta seção introduz o Sistema de Versionamento Concorrente (CVS) e como é usado no JavaTM Studio Enterprise 8, assume que existe um servidor CVS disponível para armazenar os pacotes de software.

8.1. O que é CVS?

CVS é a abreviatura Concurrent Versioning System. É um sistema aberto de controle de versão e colaboração. Colocado de forma simplesmente, é um pacote de software que gerencia o desenvolvimento de software feito por um time. Usando-o, pode-se registrar a história dos arquivos fontes e documentos.

8.2. Colaboração com CVS

Para que os times sejam capazes de colaborar e obter atualizações de seus trabalhos, o seguinte deve ser feito:

• Inicialização de um repositório CVS. Um repositório é um armazenamento persistente que coordena o acesso multi-usuário aos recursos sendo desenvolvidos por um time.

• Especificação da localização do repositório CVS.

• Entrega do trabalho naquele repositório.

Após executar estes passos, os participantes do time podem atualizar as versões dos recursos do projeto que eles estão desenvolvendo.

8.3. Setando o repositório CVS no Sun Java™ Studio Enterprise 8

Inicializar o repositório CVS no Sun Java™ Studio Enterprise 8. Inicicializando o repositório CVS no JSE8 é simples. Suponhamos que desejamos compartilhar a classe mostrada abaixo com os outros participantes do time. Figura 40 mostra isto no Java Studio Enterprise 8. Para iniciar, selecione Versioning Version Manager. → Clique Add e o New Generic CVS wizard aparece e permite que sejam informadas as configurações de versionamento necessárias. No Version Control System Profile, escolha CVS e especifique o caminho do repositório no campo Repository Path. Além disso, deve ser especificado o CVS Server Type. Isto é importante de modo a permitir que outros participantes do time tenham acesso aos recursos do projeto. O valor padrão é local. Pode ser necessário a ajuda do administrador de repositório para preencher as informações necessárias. Figura 41 mostra a inicialização do CVS.

package welcome;import javax.swing.JOptionPane;public class Main { public static void main(String[] args) { JOptionPane.showMessageDialog( null, "Welcome\nto\nJEDI\nProject"); System.exit(0); }}


JEDITM

Figura 40: Exemplo de Código a ser Compartilhado

Figura 41:Inicializando o Repositório


JEDITM

8.4. Checkout no Repositório CVS

Da opção CVS sob Versioning, podemos achar a opção CVS Checkout. Isto leva à página CVS Checkout, que pode ser usada para especificar os módulos em que serão realizados checkout. Ao informar checkout em todo o repositório selecione a caixa All e para dar checkout em componentes específicos, selecione a caixa Module(s) e informe o caminho para o diretório no Modules field. Além disso, pode-se pressionar o botão Select para escolher em uma lista de todos os módulos no repositório.

8.5. Atualizações e Colaboração

Os participantes do time pode ver o repositório selecionando Window Versioning Versioning.→ → Isto irá abrir uma janela no canto superior esquerdo que mostrará o conteúdo do repositório. No canto superior direito, devem ser adicionadas as contas para os seus companheiros de time para que eles tenham acesso ao repositório. Quaisquer atualizações ou modificações feitas pelos outros participantes do time podem ser vistas através do log de histórico como mostrado na Figura 42. Pressione com o botão direito no repositório e este mostrará o que for necessário. Esta janela também mostrará ferramentas que o ajudarão a testar os módulos modificados pelos outros participantes do time. Pressionando em Tools após clicar com o botão direito em repositório será mostrada a opção de criar testes. (Veja teste Junit)

Figura 42 Janela de Versionamento

Usando o Sun Java™ Studio Enterprise 8 com certeza vai tornar a colaboração entre os times mais fácil nos projetos de software. Nenhuma ferramenta de software extra é necessária: tudo o que é necessário é de um repositório de trabalho, participantes de time que irão ajudá-lo em seu projeto e o Sun Microsystems Java™ Studio 8!


JEDITM

9. Mapeando Produtos de Implementação com a Matriz de Rastreabilidade de Requisitos

Normalmente, não são acrescentados elementos adicionais à MRR durante a fase de implementação. Ao contrário, monitoramos o desenvolvimento de cada componente de software definido na coluna Classes. Entretanto, durante o desenvolvimento, classes adicionais podem ter sido desenvolvidas. Elas devem ser incluídas nesta coluna, debaixo do pacote apropriado.

Podemos usar a MRR para determinar quantas destas classes foram implementadas, integradas e testadas.


JEDITM

10. Métricas de Implementação

Já que as características de uma classe devem corresponder às características do projeto, as métricas utilizadas para a implementação são as métricas para o projeto. Outras métricas consideradas na fase de implementação são utilizadas para projetos posteriores similares. Eles servem como dados históricos que podem ser utilizados para estimativas de outros projetos.

1. Linhas de Códigos (LDC). Este é o número de linhas de código que são utilizadas. Pode ser para uma classe, componente ou o software inteiro. É utilizado posteriormente no gerenciamento de projetos similares.

2. Número de Classes. Este é o número total de classes criadas.

3. Número de Páginas de Documentação. O número total de documentação produzida.

4. Custo. O custo total do desenvolvimento do software.

5. Esforço. Este é o número total de dias ou meses em que o projeto foi desenvolvido.


JEDITM

11. Exercícios

11.1. Definindo o Formato da Documentação Interna

1. Defina o Bloco de Comentário Cabeçalho que será utilizado para a Documentação Interna da classe. Como um guia, a seguir temos os componentes recomendados:

• Nome do Componente

• Autor do Componente

• Data da última criação ou modificação do Componente

• Lugar onde o componente se encaixa no sistema em geral

• Detalhes da estrutura de dados, algoritmo e fluxo de controle do componente

Às vezes, ajuda se colocarmos informações históricas sobre a classe. Os componentes recomendados são:

• Quem modificou o componente?

• Quando o componente foi modificado?

• Qual foi a modificação?

O formato deve incluir como ele será escrito tal como o espaçamento, rótulos serão em letra maiúscula, etc. Mostre um exemplo de código fonte.

2. Usando o Bloco de Comentário Cabeçalho definido no exercício 1 para a Documentação Interna, implemente o AthleteRecordUI, FindAthleteRecordUI, AthleteListUI e FindAthleteRecord projetados no capítulo anterior. Se o Banco de Dados não pode ser implementado neste ponto, todos os métodos do controlador que utilizarem objetos da camada de persistência e banco de dados deverão ser codificados para mostrar uma mensagem descrevendo o que o método deveria fazer. Como um exemplo, para o método public getAthleteRecord(String searchCriteria) o programador pode simplesmente mostrar uma caixa de diálogo mostrando ao usuário que este método retornaria uma lista de registros de atletas conforme especificado pelo valor no searchCriteria.

11.2. Desenvolvimento de um Projeto

O objetivo do desenvolvimento de um projeto é reforçar o conhecimento e as habilidades obtidas neste capítulo. Particularmente, são eles:

1. Definição do bloco de comentário cabeçalho

2. Acompanhamento da implementação usando a Matriz de Rastreabilidade de Requisitos

PRODUTOS MAIORES DE TRABALHO:

1. Software Implementado

2. Arquivos de Instalação e Configuração



Lição 6Teste de Software


JEDITM

1. Objetivos

Sistemas são testados para detectar defeitos ou falhas antes de serem entregues aos usuários finais. Um fato conhecido é a dificuldade em se localizar e corrigir falhas, uma vez que o sistema esteja em uso. Nesta lição discutiremos métodos e técnicas para desenvolver casos de teste.

Estratégias de teste também serão apresentadas para que possamos entender as etapas necessárias para planejar as séries de passos que resultarão em uma construção bem sucedida do sistema.


• Utilizar métodos e técnicas no desenvolvimento de testes• Utilizar métodos de projeto de casos de teste• Aprender a como testar classes• Entender o desenvolvimento voltado para testes• Aprender a testar sistemas• Utilizar testes de métricas


JEDITM

2. Introdução ao Teste de Software

Um sistema é testado para demonstrar a existência de uma falha ou defeito, pois o objetivo de se testar é descobrir possíveis erros. Em um sentido mais amplo, um teste é bem sucedido somente quando uma falha é detectada ou é resultante de uma falha no procedimento de teste. Identificação de Falha é o processo para a identificação e localização da causa da falha. Correção e Remoção de Falha é o processo de efetuar mudanças no software e no sistema para remover falhas.

Teste de Software abrange uma série de atividades com o objetivo principal de descobrir falhas e defeitos. Especificamente, tem os seguintes objetivos:

• Projetar um caso de teste com certa probabilidade de encontrar falhas ainda não descobertos;

• Executar a classe com a intenção de encontrar erros.

2.1. Princípios de Teste de Software

1. Todos os testes devem ser seguidos de acordo com os requisitos.

2. Testes devem ser planejados muito antes dos testes começarem.

3. O Princípio de Pareto aplica-se nos casos de teste. Este princípio indica que 80% de todos os erros descobertos durante os testes serão provavelmente seguidos de 20% em todos os módulos ou classes do projeto.

4. Testes começam em pequenas partes e devem progredir de forma a se atingir as grandes partes do sistema.

5. Testes devem ser realizados de forma exaustiva e da maneira mais completa possível o que possibilitará boas chances de se construir um sistema com um mínimo de falhas.

6. Para ser mais eficaz, um terceiro grupo independente (normalmente um grupo de teste de software) deve conduzir os testes.

Estratégias de Teste de Software integram métodos no projeto de caso de testes em uma série bem planejada de etapas que resultarão em uma implementação de sucesso do projeto. É um mapa do caminho para ajudar os usuários finais, desenvolvedores e grupo de garantia de qualidade a conduzir o teste. Tem como objetivo assegurar que o projeto construído execute uma função específica (verificação), e que esteja seguindo as exigências do cliente (validação).

Testes são executados por uma variedade de pessoas. Os desenvolvedores são responsáveis por testar unidades individuais antes de realizarem a integração destas unidades ao projeto. Entretanto, devem ter interesse em demonstrar que o código está livre de falhas. O Grupo da Garantia de Qualidade pode ser encarregado de executar o teste, o objetivo principal é descobrir o máximo de falhas possível e encaminhar para que os desenvolvedores corrijam os erros descobertos.

Os testes começam com um único componente utilizando as técnicas da caixa-branca e caixa-preta para produzir os casos de teste. Para o desenvolvimento orientado a objeto, o bloco de construção é a classe. Uma vez que a classe seja verificada, a integração da classe através de comunicação e colaboração com outras classes também serão analisadas. Podem ocorrer instâncias nos quais o subsistema de um teste será executado novamente para assegurar que a correção da falha não gere erros adicionais ou novos erros. Finalmente, o sistema é testado como um todo.

A fim de se ter uma maneira organizada de testar o projeto, uma especificação de teste precisa ser desenvolvida, normalmente, pelo líder do grupo de garantia de qualidade. Se não houver nenhum grupo de garantia de qualidade, o líder do projeto deve formular um. Especificação de Teste é uma estratégia completa que define testes específicos para serem conduzidos. Inclui também os procedimentos sobre como conduzir o teste. Pode ser utilizado para seguir o progresso do grupo de desenvolvimento e definir os caminhos do projeto.


JEDITM

3. Métodos do Projeto do Caso de Teste do Software

Existem duas maneiras de se testar um projeto. Testar o funcionamento interno do projeto, Verificar se as operações internas executam como especificado, e se todos os componentes internos foram adequadamente testados. E testar o projeto como um todo, isto é, saber como o sistema irá trabalhar e testar se está conforme as funcionalidades especificadas nos requisitos. A primeira maneira representa a caixa-branca e a segunda representa o teste da caixa-preta.

3.1. Técnicas do Teste de Caixa-Branca

Também conhecido como teste da caixa de vidro. É uma técnica de projeto de caso de teste que utiliza a estrutura interna do controle do componente como foram definidos seus métodos para produzir os casos de teste. Seu objetivo é assegurar que operações internas executem de acordo com as especificações do componente. Garantir que nenhum erro lógico, compreensões incorretas ou erros tipográficos foram cometidos. Os casos de teste devem:

• Testar os trajetos independentes do componente para que sejam verificados ao menos uma vez.

• Testar as decisões lógicas para ambas condições, verdadeiro e falso.

• Testar os laços em seus limites e dentro de seus limites operacionais.

• Testar as estruturas internas de dados para sua validação.

• Testar os trajetos nos componentes que são considerados “fora do objetivo final”.

Existem diversas técnicas que podem ser empregadas na definição de casos de teste usando o método da caixa-branca.

3.1.1. Teste Básico do Trajeto

É a técnica do teste da caixa-branca que permite que o projetista do caso de teste produza uma medida lógica da complexidade baseada na especificação processual de um componente de projeto. Esta medida da complexidade é utilizada como um guia para definir a base da série dos trajetos de execução que serão testados.

Etapas para Produzir Casos de Teste utilizando o Teste Básico do Trajeto

ETAPA 1. Utilizar uma especificação do procedimento como entrada para produzir trajetos básicos para execução do trajeto.

A especificação do procedimento pode ser elaborada em pseudo-código, fluxograma ou código-fonte próprio. Para classes, o projeto processual da operação ou do método será usado. Como exemplo, suponha que o pseudo-código a seguir seja algum método de alguma classe.

while (condition1) do statement1; statement2; do case var1 condition1: statement3 condition2: statement4; statement5; condition3: if (condition2) then statement6; else statement7 statement8 endif endcase statement9;endwhile


JEDITM

ETAPA 2. Desenhar o Gráfico do Fluxo da Especificação Processual.

O gráfico do fluxo descreve o fluxo lógico do controle da especificação processual. Usa nodes, bordas e regiões. Os nodes representam uma ou mais instruções. Pode ser traçado por sequências ou condições. As bordas são as ligações dos nodes. Representam um fluxo de controle similar ao gráfico do fluxo. As regiões são áreas limitadas pelas bordas e pelos nodes. Figura 1 mostra um exemplo de código procedural do gráfico de fluxo. O gráfico normalmente não mostra o código. É colocado para finalidade de esclarecimentos.

Figura 1: Gráfico de Fluxo

ETAPA 3. Calcular a Complexidade do Código.

A complexidade ciclomática é utilizada para determinar a complexidade do código processual. É um número que especifica trajetos independentes no código, que é a base do caminho. Pode ser calculado de três maneiras.

1. O número de regiões do gráfico de fluxo.

2. O número de predicados dos nodes mais um, isto é, V(G) = P + 1

3. O número de bordas menos os nodes mais 2, isto é, V(G) = E – N + 2

No exemplo:

O número de regiões é 5.

O número de predicados é 4.

O número de bordas é 13.

O número de nodes é 10.


1enquanto(condição1) faça

11

9instrução9

8instrução7instrução87

instrução6

6condição3se (condição2) então4

condição1instrução3 5

condição2instrução4instrução5

3faça caso var1

2instrução1;instrução2

JEDITM

Figura 2: Valores da complexidade ciclomática

Utilizando a fórmula:

• V(G) = 5 (regiões)

• V(G) = 4 (predicados) + 1 = 5

• V(G) = 13 (bordas) – 10 (nodes) + 2 = 5

ETAPA 4. Determinar caminho básico de trajetos da execução.

A complexidade ciclomática fornece o número de trajetos independentes no código, linearmente. No exemplo acima, 5 trajetos lineares independentes são identificados.

Trajeto 1: node-1, node-2, node-3, node-4, node-9

Trajeto 2: node-1, node-2, node-3, node-5, node-9

Trajeto 4: node-1, node-2, node-3, node-6, node-8, node-9

Trajeto 3: node-1, node-2, node-3, node-6, node-7, node-9

Trajeto 5: node-1, node-11

ETAPA 5: Documentar os casos de teste baseados no trajeto identificado da execução.

Casos de teste são preparados para forçar a execução de cada trajeto. Condições ou predicados de nodes devem ser corretamente ajustados. Cada caso de teste é executado e comparado com o respectivo resultado. Exemplo:

TRAJETO 1 - Caso de Teste:


1

Nó 3 é contado com 2 predicados. Isto é equivalente a duas instruções aninhadas.

REGIÃO 5- Parte externaondfe o nó 11 pertence

REGIÃO 4

REGIÃO 3REGIÃO 2

REGIÃO 1

11

9instrução9

8instrução7instrução87

instrução6

condição3se (condição2) então64

condição1instrução3 5

condição2instrução4instrução5

faça caso var13

2instrução1;instrução2

enquanto(condição1) faça

JEDITM

Para node-1, condição2 deve avaliar como VERDADEIRO (Identifica os valores necessários)Para node-3, avaliação da var1 deve conduzir ao node-4 (Identifica valor de var1)Resultados esperados: deve produzir necessariamente resultado para node-9.

3.1.2. Estrutura de Controle de Teste

Estrutura de Controle de Teste é uma técnica de teste caixa-branca que testa três tipos de controles da classe, a saber: testes de condição, testes de repetição e testes de fluxo de dados.

1. Testes de Condição. Método de projeto do caso de teste que testa condições lógicas contidas em uma especificação processual. Focaliza em testar cada condição na classe fornecendo a combinação possível dos valores. Um exemplo, considerando a seguinte condição de um método:

se ((resultado < 0) && (numeroDeTeste != 100))

Os casos de teste que podem ser gerados são mostrados na Tabela 1.

Caso de Teste resultado < 0 numeroDeTeste != 100 combinação1 T T T

2 T F F

3 F T F

4 F F F

Tabela 1: Estrutura de Controle de Casos de Teste

2. Teste de Repetição. É um método de projeto de caso de teste que foca exclusivamente na validade dos construtores iterativos ou da repetição. Existem quatro classes de iteração: simples, concatenada, aninhada e não-estruturada. São mostradas na Tabela 2.

Iteração SimplesFAÇA ENQUANTO

InstruçãoFIM ENQUANTO

Iteração ConcatenadaFAÇA ENQUANTO

InstruçãoFIM ENQUANTOFAÇA ENQUANTO


Iteração AninhadaFAÇA ENQUANTO

InstruçãoFAÇA ENQUANTO


FIM ENQUANTO

Iteração não estruturadaFAÇA ENQUANTO

Instrução:rótulo1FAÇA ENQUANTO

Instrução:rótulo2SE <condição>

VÁ PARA rótulo1FIM SEVÁ PARA rótulo2

FIM ENQUANTOFIM ENQUANTO

Tabela 2: Estrutura de Iteração ou Repetição

Para uma iteração simples, os casos de teste podem ser produzidos pelas seguintes possíveis execuções de iteração ou repetição.

• Salte o laço.

• Somente uma passagem através do laço.

• Duas passagens através do laço.

• m passagens através do laço, onde m < n

• n – 1, n, n + 1 passagens através do laço


JEDITM

Para iterações aninhadas, os casos de teste podem ser produzidos pelas seguintes possíveis execuções de iteração ou repetição.

• Comece com o laço mais interno.

• Conduza testes de laço simples para o laço mais interno ao prender o laço exterior em seus valores de parâmetros mínimos da iteração. Adicione o outro teste para valores fora de limite ou valores excluídos.

• Trabalhe de dentro para fora, conduzindo testes para laço seguinte mas mantendo todos os laços exteriores restantes em valores mínimos e em outros aninhados com valores “típicos”.

• Continue até todos os laços serem testados.

Para a Iteração Concatenada, os casos de teste podem ser produzidos pelas seguintes possíveis execuções de iteração ou repetição.

• Se os laços são independentes, o teste para laços simples pode ser utilizado.

• Se os laços são dependentes, o teste para laços aninhados pode ser utilizado.

Para Iteração não estruturada, os casos de testes não devem ser produzidos desde que seja o melhor para replanejar o laço e pode ser que não seja uma boa forma de iteração ou construção de repetição.

3. Teste de fluxo de dados. É um método de produção de caso de teste que seleciona os trajetos de acordo com a localização das definições e utilizações de variáveis no código.

3.2. Técnicas de Teste de caixa-preta

É um teste de projeto focado nos aspectos do projeto em relação aos seus requisitos funcionais. Engenheiros de software devem testar os requisitos funcionais do projeto por meio da entrada de dados. Isto define uma série de casos de teste que poderão indicar a ausência ou a incoerência de alguma função, erros de interfaces, erros na estrutura dos dados, erros no acesso externo às bases de dados, erros de performance, e erros de inicialização e término da aplicação.

3.2.1. Testes Baseados em Gráficos

Técnica de teste caixa-preta que usa os objeto que foram modelados durante o projeto e seus relacionamentos. Entender a dinâmica de como estes objetos se comunicam e colaboram uns com os outros é a forma que podem gerar casos de teste.

Desenvolvendo casos de teste usando Testes Baseados em Gráficos

PASSO 1: Criar um gráfico dos objetos do software e identificar os relacionamentos entre esses objetos.

Figura 3: Diagrama de Colaboração para encontrar um atleta

Utilizando nodes e bordas, crie o gráfico dos objetos do sistema. Os nodes representam os objetos. Propriedades podem ser usadas para descrever os nodes e bordas. Para engenharia de software orientada a objetos, o diagrama de colaboração é uma excelente forma de entrada de


JEDITM

dados para os testes baseados em gráficos, pois não se faz necessário a criação de gráficos. O diagrama de colaboração na Figura 3 é usado como um exemplo.

PASSO 2: Utilizar os gráficos para definir casos de teste.

Os casos de teste são:

Caso de Teste 1:

• A classe FindAthleteUI envia uma solicitação para pesquisar uma lista de atletas baseada em um critério de busca. A solicitação é enviada para FindAthleteRecord.

• FindAthleteRecord envia uma mensagem para DBAthlete para processar o critério de busca.

• DBAthlete solicita ao servidor de banco de dados que execute a instrução SELECT. Isto preenche a classe PCLAthlete com as informações do atleta. Retorna a referência de PCLAthlete para AthleteListUI.

• AthleteListUI lista os nomes dos atletas.

Dicas para os Testes Baseados em Gráficos:

1. Identificar o ponto de inicio e término do gráfico. Estes poderão ser os nodes de entrada e saída.

2. Nomear os nodes e especifique as propriedades.

3. Estabelecer seus relacionamentos através das bordas. Especifique suas propriedades.

4. Criar casos de teste e garantir que cobra todos os nodes e as bordas.

3.2.2. Teste de Equivalência

É um teste caixa-preta que utiliza as entradas de dados do código. Isto divide a entrada de dados em grupos para que os casos de teste possam ser desenvolvidos. Casos de teste são utilizados para descobrir erros que reflitam uma classe de erros. Isto, contudo, diminui os esforços no processo de teste. Para isto se faz uso das classes de equivalência, que são regras que validam ou invalidam a entrada de dados.

Dicas para Identificar as Classes de Equivalência

1. Condição de entrada é especificada como um comprimento do valor. Caso de Teste consiste em uma entrada válida e 2 classes de equivalência inválidas.

2. Condição de entrada requer um valor especifico. Caso de Teste consiste em uma classe válida e duas classes inválidas de equivalência.

3. Condição de entrada especificam o membro de um grupo. Caso de Teste consiste em uma classe válida e uma inválida.

4. Condição de entrada é um Boolean. Caso de Teste consiste em uma classe válida e uma inválida.

Como exemplo, considere uma mensagem de texto para o registro de um telefone móvel em um serviço para obter relatórios de tráfego. Assuma que a mensagem possui a seguinte estrutura:

Número do servidor de Serviço

(Número do servidor provedor do serviço)

Código do Serviço

(Código único que diz ao provedor de serviços qual serviço esta sendo solicitado)

Número do Telefone Móvel

(O número de telefone para o qual as informações serão enviada)

765 234 09198764531

Condições de entrada associados com cada elemento de dado:


JEDITM

Número do servidor de ServiçoCondição de entrada 1: valor correto

Condição de entrada 2: valor incorreto

Código do ServiçoCondição de entrada 1: valor correto

Condição de entrada 2: valor incorreto

Número do Telefone Móvel

Condição de entrada 1: valor correto

Condição de entrada 2: número faltando

Condição de entrada 3: tamanho incorreto

3.2.3. Teste de Limite de Valor

É um teste caixa-preta que faz uso dos limites dos valores para se criar casos de teste. A maioria das falhas no projeto ocorrem no limite dos valores de entrada.

Dicas na criação de casos de teste utilizando Teste de Limite de Valor

1. Se a condição de entrada especificar um comprimento por n e m, o caso de teste pode ser feito da seguinte forma:

• usando valores n e m

• somente valores acima de n e m

• somente abaixo de n e m•

2. Se a condição de entrada especificar o número de valores, o caso de teste pode ser:

• usando o valor mínimo

• usando o valor máximo

• usando somente valores acima do valor mínimo

• usando somente valores acima do valor máximo


JEDITM

4. Testando Classes

Testes de projeto podem ser realizados em várias etapas ou tarefas. Testes de projeto se preocupam com testes individuais (testes de unidade) ou com seus relacionamentos uns com os outros (teste de integração de sistema). Nesta sessão iremos discutir os conceitos e métodos que permitem realizar testes em classes.

4.1. Teste de Unidade

É o nível básico dos testes. Tem como intenção testar os menores blocos de código. Este é o processo no qual se executa cada módulo para confirmar se desenvolve o que sua função determina. Essa parte envolve testar as interfaces, estruturas de dados locais, condições limites, caminhos independentes e erro ao lidar com caminhos.

O ambiente no qual os testes de unidade podem ser realizados é mostrado na Figura 4. Para testar os módulos, são utilizados um driver e um stub. Um driver é uma classes que aceita testes de dados de entrada, envia os dados recebidos aos componentes a serem testados e mostra um resultado relevante. Um stub é uma classe que realiza o suporte a atividades como manipulação de dados, pesquisa do estado dos componentes a serem testados e impressão. Se o driver e stub necessitarem de um grande esforço para serem desenvolvidos, os testes de unidade podem ser atrasados até o teste de integração.

Figura 4 Ambiente de Teste de Unidade

Para se criar testes de unidade que sejam eficazes, faz-se necessário entender o comportamento da unidade no sistema que se está testando. Isto geralmente é feito decompondo os requisitos do sistema em pedaços simples que podem ser testados independentemente. É importante que os requisitos do projeto possam ser transformados em casos de teste.

Na engenharia de software orientada a objetos, o conceito de encapsulamento é utilizado para definir a classe; os dados (atributos) e funções (métodos e operações) são agrupados numa mesma classe. As menores unidades de teste são as operações definidas nessas classes. Contrária a forma de se realizar testes, operações definidas na classe não podem ser separadas para que o teste seja realizado. Isto deve ser testado no contexto dos objetos da classe instanciada. Como um exemplo, considere o diagrama de classe mostrado na Figura 5.

Figura 5: Modelo de Hierarquia de Classe


JEDITM

O método draw() é definido na classe Shape. Todas as subclasses da classe Shape conterão este método por meio de herança. Quando uma subclasses utiliza o método draw(), ele é executado juntamente com os atributos privados e outros métodos no contexto da subclasse. O contexto no qual o método é usado varia dependendo de que subclasse o executa. Consequentemente, é preciso testar o método draw() em todas as subclasses que o utilizam. Como o número de subclasses é definido para a classe base, mais testes serão necessários.

4.2. Teste de Integração

Após os testes de unidade, todas as classes devem ser testadas em integração. O Teste de Integração do Sistema verifica se cada componente interage de maneira satisfatória quando agregados e se todas as interfaces estão corretas. Softwares orientados a objetos não possuem uma hierarquia óbvia de controle de sua estrutura, que é uma característica no modo convencional em se desenvolver sistemas. As formas tradicionais de teste de integração (de cima-para-baixo ou de baixo-para-cima) possuem uma relevância muito reduzida nesses projetos. Entretanto, existem duas abordagens que podem ser empregadas na performance dos testes de integração.

4.3. Teste de Aproximação baseado em Thread

Teste de Integração é baseado num grupo de classes que colaboram ou interagem quando uma entrada necessita ser processada ou um evento foi ativado. Uma thread é um caminho para a comunicação entre essas classes que precisam processar uma única entrada ou responder a um evento. Todas as possíveis threads precisam ser testadas. Diagramas de Seqüência e de Colaboração podem ser utilizados como base para estes testes. Como um exemplo, considere o Diagrama de Seqüência que recupera o registro de um atleta, como mostrado na Figura 6. No Teste de Integração, somente, siga a ordem em que há interação entre os objetos por meio de suas mensagens.

Figura 6: Recuperando um registro de Atleta

A seqüência de testes poderá envolver os seguintes passos:

1. A comissão irá clicar no Find Button do Athlete Record User Interface.

2. A tela de FindAthleteRecordUI será exibida.

3. A comissão insere os critérios de pesquisa.

4. A comissão pressiona o botão OK que instanciará o controlador FindAthleteRecord.5. O controlador FindAthleteRecord se comunicará com o DBAAthelte para popular a

PCLAthleteList.


JEDITM

6. A tela AthleteListUI será exibida contendo uma lista com os atletas que satisfazem os critérios utilizados na pesquisa.

7. A comissão selecionará o atleta que se deseja recuperar.

8. A comissão pressiona o botão OK ou pressiona enter.

9. A tela AthleteRecordUI deverá ser mostrada contendo as informações do atleta nos campos apropriados.

4.4. Teste de Aproximação baseado em Uso

Os testes de integração começam por identificar as classes independentes. Classes Independentes são aquelas classes que não usam, ou usam pouco, outras classes. As classes independentes são testadas primeiro. Após o teste dessas classes, o próximo conjunto de classes a ser testado e chamado de Classes Dependentes. As Classes Dependentes são aquelas que fazem uso das Classes Independentes. Como um exemplo, considere as classes mostradas na Figura 7. As classes Athlete e PCLAthlete podem ser consideradas como classes independentes. Seus métodos podem ser testados independentemente. Se os testes forem satisfatórios, a classe DBAthlete poderá ser testada.

Figura 7: Cluster DBAthlete

Para auxiliar na integração, Clustering pode ser usado. Clustering é o processo que define um grupo de classes que podem ser integradas e testadas juntas. Estas são chamadas de clusters porque são consideradas como sendo uma unidade. No exemplo, as três classes combinadas podem ser identificadas como sendo um Cluster DBAthlete.

4.5. Teste de Regressão

Algumas vezes quando algum erro é corrigido, é necessário refazer o teste dos componentes. O Teste de Regressão é uma reexecução de alguma parte do componente para assegurar que mudanças realizadas na correção dos erros não produziram erros não-intencionais. Um novo teste ocorre para as funções do sistema que foram afetadas, componentes que foram modificados e os que podem ser afetados por uma mudança.


JEDITM

5. Metodologia de Desenvolvimento voltada para o Teste

Desenvolvimento voltado para o Teste (TDD) é um método de desenvolvimento que adota a abordagem de primeiro testar e refazer. Esta abordagem de se testar primeiro é uma técnica de programação que envolve análise, projeto, codificação e teste em conjunto. Dois passos básicos estão envolvidos nessa abordagem:

• Escrever somente o necessário para se descrever o próximo incremento de comportamento.

• Escrever somente o código necessário para se passar no teste.

Assim como o implica o nome, o teste é desenvolvido antes.

Refatoração, por outro lado, significa melhorar um código já existente. É um modo sistemático de se melhorar um código eliminando as partes redundantes ou duplicadas. Este é um processo no qual se altera a estrutura interna do código sem que sejam feitas alterações no comportamento do projeto. Muitos programadores utilizam refatoração em seus códigos regularmente tendo por base um senso comum.

No desenvolvimento voltado para testes, cada novo teste gera novas informações que ajudam a tomar as decisões de projeto. Muitas vezes, aquele que não realiza o projeto tem problemas ate que ele seja utilizado. Testes nos permitem descobrir problemas no sistema.

5.1. Benefícios do Desenvolvimento Voltado para Testes

Existem vários benefícios. Alguns deles são enumerados abaixo.

1. Permitir o desenvolvimento simples de incremento. Um dos benefícios imediatos do uso do TDD é que essa prática gera um sistema quase que imediatamente. A primeira iteração do projeto é bastante simples e pode não conter muitas funcionalidades, entretanto as funcionalidades serão incrementadas com o contínuo desenvolvimento. Isso é menos arriscado do que construir o sistema inteiro e esperar que suas partes funcionem juntas.

2. Envolver um processo de desenvolvimento mais simples. Desenvolvedores ficam mais concentrados porque o único detalhe com o qual precisam se preocupar deve ser passar no próximo teste. Concentrar-se numa pequena parte do projeto, colocar para funcionar, e partir para próxima etapa.

3. Prover um constante teste de regressão. A modificação em um módulo pode ter conseqüências não esperadas no resto do projeto. TDD executa um grupo de testes de unidade toda vez que uma mudança é realizada. Isto significa que toda modificação no código que pode gerar um erro não esperado em outra parte do projeto será detectado imediatamente e corrigido. Outro benefício dos constantes testes de regressão é que sempre teremos um sistema funcionando a cada iteração do desenvolvimento. Isto lhe permite parar com o desenvolvimento do sistema a qualquer hora e rapidamente fazer modificações nos requisitos.

4. Melhorar a comunicação. Os testes de unidade servem como uma linguagem comum que pode ser usada na comunicação do comportamento exato de um componente sem ambigüidades.

5. Melhorar no entendimento do comportamento do sistema. Escrever os testes de unidade antes de escrever o código ajuda ao desenvolvedor a se concentrar em entender os requisitos. Ao escrever testes de unidade, o desenvolvedor adiciona critérios de sucesso ou falha no comportamento do projeto. Cada um desses critérios adicionados servem para perceber como o sistema deve se comportar. Com a adição de mais testes de unidade para as novas características ou correções, um conjunto de testes representa o comportamento do sistema.

6. Centralizar o conhecimento. Os testes de unidade servem como um repositório que provê informação sobre as decisões de projeto que vierem a serem tomadas em algum módulo. Os testes de unidade provêem um lista dos requisitos enquanto o código-fonte realiza a


JEDITM

implementação dos requisitos. Usar essas duas fontes como informação torna muito mais fácil para o desenvolvedor entender o módulo e realizar as mudanças que não irão introduzir falhas no projeto.

7. Melhorar o projeto. Fazer com o que o desenvolvedor escreva os testes de unidade antes da codificação ajuda o mesmo a entender melhor o comportamento do projeto como um todo e ajudar a pensar no sistema do ponto de vista do usuário.

5.2. Passos de Desenvolvimento voltados para Teste

Desenvolvimento voltado para testes é basicamente composto dos seguintes passos:

1. Escrever um teste que defina como o sistema deverá se comportar. Como um exemplo, suponha que “Ang Bulilit Liga” tenha as seguintes exigências, “O software deve calcular a média de lançamento de cada atleta por jogo e por temporada.” Existe um número de comportamentos que o software precisa ter para que possa implementar as exigências dadas:

• O software deverá identificar um atleta.

• Deverá haver um modo para que seja realizada a entrada dos dados para que a média possa ser calculada.

• Deverá haver uma maneira para identificar o jogo.

• Deverá haver uma forma de receber a média de lançamento em um determinado jogo.

• Deverá haver uma forma de receber a média de toda a temporada.

Após serem feitas algumas suposições de que os atletas poderão ser identificados pelos seus ids e data dos jogos, podemos escrever o caso de teste. Como um exemplo, uma parte de um teste de unidade é mostrada no código abaixo.

Athlete timmy = PCLAthleteList.getAthlete(3355);AthleteStatistics timmyStatistics = new AthleteStatistics(timmy);// Adicionando a média de lançamento para as tentativas de 1 a 9// último jogo 8/9/2004.timmyStatistics.addShootingAverage("8/9/2004",1,9);// Adicionando a média de lançamento para as tentativas de 4 a 10// último jogo 8/16/2004.timmyStatistics.addShootingAverage("8/16/2004",4,10);// Adicionando a média de lançamento para as tentativas de 7 a 10// último jogo 8/25/2004.timmyStatistics.addShootingAverage("8/25/2004",7,10);// Calculando a média para o dia 16/08float gameShootingAverage = timmyStatistics.getGameShootingAverage("8/16/2005");// Calculando a média para a temporadafloat seasonShootingAverage = timmyStatistics.getSeasonShootingAverage();//checando a média para o jogoassertEquals(200, gameShootingAverage);//checando a média para a temporadaassertEquals(214, seasonShootingAverage);

2. Fazer com que o teste rode de forma mais fácil e rápida possível. Não é necessário preocupar-se com o código-fonte; deve fazer com que funcione. No exemplo de caso utilizado, o código-fonte que estamos fazendo referência é a classe AthleteStatistics que contém o método que calcula a média de um atleta em um jogo ou em uma temporada. Uma vez o teste escrito, ele é executado para verificar a possível existência de falhas. A classe falha pois o código para a implementar o comportamento ainda não foi escrito. Uma vez que


JEDITM

o teste de unidade foi verificado, o código para implementar o comportamento é desenvolvido e o teste de unidade é novamente executado para assegurar que o software funciona como o esperado. Uma classe inicial AthleteStatistics é mostrada abaixo.

public class AthleteStatistics{ private Athlete a; private Statistics stats; // Construtor com um atleta como parâmetro public AthleteStatistics(Athlete theAthlete){ // Lugar para inicialização dos atributos do atleta a = theAthlete; stats = new Statistics(); } public void addShootingAverage(String dateOfGame, int shots, int attempts) { // Lugar onde o código para adição das estatísticas de um jogo. } public float getGameShootingAverage(String dateOfGame) { // Cálculos. } public float getSeasonShootingAverage(){ // Cálculos. }}

3. Arrumar o código-fonte. Agora que o código se encontra-se funcionando corretamente, refazer o código e remover qualquer duplicidade ou qualquer outro problema que foi introduzido para que o teste pudesse ser feito. Os desenvolvedores devem saber que escrever o código em primeiro lugar não é uma boa prática de implementação, não devem ter medo de refazer. Ao corromper o código, o teste de unidade emitirá imediatamente um aviso.

5.3. Testando Classes Java com JUnit

JUnit é utilizado para realizar os chamados testes unitários. Isso significa que é utilizado para escrever e organizar casos de teste para cada classe separadamente. Os casos de teste poderiam ser escritos sem a ajuda do Junit. Porém os testes do JUnit, além de serem mais fáceis de codificar, permitem ao programador uma maior flexibilidade para que possa agrupar pequenos testes, permitindo que execuções simultâneas sejam realizadas para facilitar o processo de depuração. Esta sessão irá discutir como o JUnit é utilizado com o Java Studio™ Enterprise 81.

5.3.1. Testes de Unidade com JUnit

Os testes de unidades com o JUnit podem ser realizados de acordo com os seguintes passos:

1. Construir uma subclasse da classe TestCase..

2. Criar um método chamado setUp() para iniciar dados (atributos ou construtor) antes do teste.

3. Escrever quantos métodos para o teste forem necessários.

4. Criar um método chamado tearDown() se necessitar que alguma informação seja apagada após o teste.

Para executar vários testes ao mesmo tempo, é preciso criar uma suite de testes. O JUnit possui um objeto, TestSuite, que pode rodar inúmeros testes ao mesmo tempo assim como testar várias outras suites.

5.3.2. Utilizando o JUnit no Java™ Studio Enterprise 8 da Sun

Criar testes no Java™ Studio Enterprise 8 da Sun é muito simples. Utilize o modelo mostrado na

1 Foi mantido o Software Java Studio™ Enterprise 8 conforme no original em inglês, entretanto, esta seção para as vídeo-aulas utilizará o software NetBeans (N.T.).


JEDITM

Figura 8 como a classe a ser testada. Crie um novo teste selecionando Tools JUnit Tests → → Create Tests na barra de menus. Tenha certeza de que a classe a testar está devidamente selecionada. De outro modo, os testes para uma classe podem ser criados com um clique direito do mouse sobre o nome da classe e selecionando Tools JUnit Tests Create Tests→ → .

Figura 8: Modelo de código a ser testado

Na janela Create Tests, selecionar as opções de Code Generation para a realização do teste. A IDE gera um modelo com as opções que foram especificadas. Neste caso, nada será marcado com a exceção da opção Public. O nome da classe para o teste pode, inclusive, ser modificado (Figura9). As configurações do JUnit podem ser modificadas no JUnit Module Settings (Módulo de Configuração do JUnit) ou ainda na própria janela para a criação de testes. Pressionar o botão OK irá gerar uma estrutura básica de testes (Figura 10).

Figura 9: Janela do Junit para a criação de testes

Os métodos podem ser escritos utilizando-se expressões de testes da classe Assert (Classjunit. framework.Assert). Figura 11 nos mostra alguns métodos escritos para testar o código da Figura


JEDITM

1. Para executar o teste, selecione Run Test “project-name”→ na barra de menus. A saida do teste será gerado pela IDE.

Figura 10: Teste gerado pela IDE

Se ocorrer alguma falha nos testes o erro será mostrado e, em seguida, o que causou o erro. Neste caso, o testSampleMethod1 falhou, pois o que era esperado foi diferente do que foi obtido. Já o testSampleMethod2 não falhou, por isso, nenhuma mensagem de erro foi mostrada.

A suite de testes pode ser editada de forma a adicionar novos testes fora do arquivo. Outras suites de testes podem ser incluídas no nosso teste. Outros métodos como setUp() e tearDown() podem ser incluídos nos testes. Estes métodos são chamados de testes de fixação pois os mesmo são executados antes ou depois dos testes.

Figura 11 Caso de teste no JUnit utilizando assertEquals()


JEDITM

Partes do projeto são mostradas nos códigos seguintes.

/* * SampleClass.java */public class SampleClass { public String sampleMethod1(int i) { return "The number is: " + i + "!"; } public int sampleMethod2(int x, int y) { return x+y; }}/* * SampleClassTest.java */import junit.framework.*;public class SampleClassTest extends TestCase { public SampleClassTest(String testName) { super(testName); } public static Test suite() { TestSuite suite = new TestSuite(SampleClassTest.class); return suite; } public void testSampleMethod1() { SampleClass sample = new SampleClass(); String obtained = sample.SampleMethod1(100); String expected = "I got " + 100 + "!"; assertEquals("SampleClass.SampleMethod1(100)", expected, obtained); } public void testSampleMethod2() { SampleClass sample = new SampleClass(); int obtained = sample.SampleMethod2(100,1); int expected = 101; assertEquals("SampleClass.SampleMethod2(100,1)", expected, obtained); }}


JEDITM

6. Testando o Sistema

O teste de sistema é preocupa-se em testar um sistema inteiro baseado em sua especificação. O software a ser testado é comparado com a sua especificação funcional. Depois do teste de integração, o sistema é testado como um todo com foco na funcionalidade e exatidão. Isto deve incluir testes como o de performance, que testa o tempo de resposta e utilização de recursos; teste de estresse, que testa o software sujeito a quantidade, freqüência e volume de dados, pedidos e respostas anormais; teste de segurança, que testa os mecanismos de proteção do software; teste de recuperação, que testa o mecanismo de recuperação do software quando ele falha; etc.

No contexto de engenharia de software orientada a objeto, os requisitos de teste são derivados dos artefatos de análise ou produtos que usem UML, como diagramas de classe, de seqüência e de colaboração. Para derivar os casos de teste de sistema, o uso do diagrama de caso de uso é uma boa fonte. Eles representam as funcionalidades de alto nível providas ao usuário pelo sistema. Conceitualmente, a funcionalidade pode ser vista como um conjunto de processos, que são executados horizontalmente pelo sistema, e de objetos, como componentes de subsistema que são executados verticalmente. Cada funcionalidade não usa cada objeto; entretanto, cada objeto pode ser usado por muitas requisições funcionais. Esta transição de visão funcional para orientada à objeto é conseguida com casos e cenários.

Entretanto, estes casos não são independentes. Eles não têm apenas as dependências de extensão e inclusão. Têm também dependências seqüenciais que vêm da lógica do negócio em que o sistema se apóia. Quando planejamos casos de teste, precisamos identificar nas possíveis seqüências de execução como elas podem disparar diferentes falhas.

Um cenário é uma instância de um caso de uso ou um caminho completo de um caso de uso. Os usuários finais do sistema completo podem percorrer muitos caminhos enquanto executam a funcionalidade especificada no caso de uso. Cada caso de uso deve ter um fluxo básico e um fluxo alternativo. O fluxo básico cobre o fluxo normal do caso de uso. O fluxo alternativo cobre o comportamento de uma exceção ou de um caminho opcional, levando em consideração o comportamento normal do sistema.

A seção seguinte fornece os passos para derivar os casos de teste dos casos de uso. Ela consiste em uma adaptação de Heumann2.

6.1. Gerando Casos de Teste de Sistema

PASSO 1: Utilizar RTM e priorizar os casos de uso.

Muitos projetos de desenvolvimento de software podem ser obrigados a entregar o software tão rápido quanto possível e com um pequeno time de desenvolvedores. Neste caso, priorizar quais funcionalidades devem ser desenvolvidas e testadas primeiro é muito crucial. A importância é estimada com base na freqüência com que cada função do sistema é usada. O RTM é uma boa ferramenta para determinar quais funcionalidades devem ser desenvolvidas e testadas primeiro.

RTM ID Requisito Anotações Solicitante Data Prioridade

Caso de Uso 1.0

O sistema deve ser capaz de dar manutenção nas informações pessoais de um atleta.


Caso de Uso 2.0

O sistema deve ser capaz de permitir ao treinador mudar o status de um atleta.


Caso de Uso 3.0

O sistema deve ser capaz de exibir as informações pessoais de um atleta. RJCS 12/06/05 Deve ter

Caso de Uso 1.1

O sistema deve ser capaz de adicionar o registro de um atleta. RJCS 13/06/05 Deve ter

2 Heuman, J. Generating Test Cases for Use Cases. The Rational Edge, Rational Rose Software, 2001.


JEDITM

RTM ID Requisito Anotações Solicitante Data Prioridade

Caso de Uso 1.2

O sistema deve ser capaz de editar o registro de um atleta. RJCS 13/06/05 Deve ter

Caso de Uso 1.3

O sistema deve ser capaz de excluir o registro de um atleta. RJCS 13/06/05 Deve ter

Tabela 3: Amostra Inicial de RTM para a Manutenção dos Membros de um Clube

Considere o RTM formulado durante a análise mostrado na Tabela 3. Os usuários devem decidir fazer o Caso de Uso 1.0 e seus sub-casos de uso antes do resto.

PASSO 2: Para cada caso de uso, crie os cenários.

Para cada caso de uso, começando da prioridade maior para a menor, crie um conjunto suficiente de cenários. Ter uma descrição detalhada de cada cenário como suas entradas, pré-condições e pós-condições pode ser muito útil nos estágios futuros da geração de testes. A lista de cenários deve incluir o fluxo básico e, pelo menos, um fluxo alternativo. Quanto mais fluxos alternativos, mais compreensiva será a modelagem e, conseqüentemente, testes mais completos. Como exemplo, considere a lista de cenários para incluir um atleta ao sistema na Tabela 4.

Cenário ID Nome do Cenário

SCN-01 Dados de um atleta adicionados com sucesso

SCN-02 Dados de um atleta estão incompletos

SCN-03 Dados de um atleta são inválidos

SCN-04 Entrada duplicada

SCN-05 Sistema indisponível

SCN-06 Sistema falha durante a entrada

Tabela 4: Lista de cenários para incluir o registro de um atleta

PASSO 3: Para cada cenário, obter pelo menos um caso de teste e identificar as condições de execução.

As pré-condições e o fluxo de eventos de cada cenário podem ser examinadas para identificar as variáveis de entrada e as restrições que trazem o sistema a um estado específico representado pelas pós-condições. Uma matriz é apropriada para uma documentação clara dos casos de teste para cada cenário. Como exemplo, considere a matriz mostrada na Tabela 5.

Caso de Teste ID Cenário Dados do

AtletaNão está na

Base de DadosResultados Esperados

TC-01 Dados de um atleta adicionados com sucesso V V Mostrar mensagem:

Registro de atleta incluído.

TC-02 Dados de um atleta estão incompletos I V Mensagem de erro: Dados

incompletos.

TC-03 Dados de um atleta são inválidos I V Mensagem de erro:

dados inválidos.

TC-04 Entrada duplicada V IMensagem de erro: Registro deste atleta já existe.

TC-05 Sistema indisponível V I Mensagem de erro: Sistema indisponível.


JEDITM

Caso de Teste ID Cenário Dados do

AtletaNão está na

Base de DadosResultados Esperados

TC-06 Sistema falha durante a entrada V ISistema falha, mas deve ser capaz de recuperar os dados.

Tabela 5: Amostra de matriz de caso de teste para adicionar o registro de um atleta

A matriz de teste representa um framework de teste sem envolver valores específicos de dados. O V indica válido, o I indica inválido e N/A indica não aplicável. Esta matriz é um passo intermediário e provê um bom método para documentar as condições que estão sendo testadas.

PASSO 4: Para cada caso de teste, determinar os valores para os dados.

Uma vez que todos os testes foram identificados, eles devem ser completados, revisados e validados para garantir a acurácia e identificar os casos de teste redundantes ou ausentes. Se isto é alcançado, o próximo passo é determinar os valores para cada V e I. Antes de distribuir o aplicativo, ele deve ser testado usando dados reais para ver se outros problemas, como performance, são identificados. A Tabela 6 mostra algumas amostras de valores.

Caso de Teste ID Cenário Dados do Atleta Não está na

Base de Dados Resultado Esperado

TC-01Dados de um atleta adicionados com sucesso

Johnny De la CruzLot 24 block 18 St. Andrewsfield, Quezon City24/9/1998MasculinoStatusResponsável:Johnny De la Cruz, Sr.-mesmo endereço-555-9895

V Mostrar mensagem: Registro de atleta incluído.

TC-02Dados de um atleta estão incompletos

Sem responsável V Mensagem de erro: Dados incompletos.

TC-03Dados de um atleta são inválidos

Falta data de nascimento V Mensagem de erro: dados inválidos.

TC-04 Entrada duplicada

Johnny De la CruzLot 24 block 18 St. Andrewsfield, Quezon City24/9/1998MasculinoStatusResponsável:Johnny De la Cruz, Sr.-mesmo endereço-555-9895

IMensagem de erro: Registro deste atleta já existe.

Tabela 6: Amostra de matriz de caso de teste para adicionar o registro de um atleta com valores

6.2. Testes de validação

Começam depois do ápice do teste de sistema. Consiste numa série de casos de teste caixa-preta que demonstram conformidade com os requisitos. O software é completamente integrado como um sistema e erros de interface entre componentes de software foram descobertos e corrigidos. O foco é nas ações visíveis ao usuário e nas saídas reconhecíveis pelo usuário.

Um Critério de Validação é um documento contendo todos os atributos do software visíveis ao usuário. Ele é a base para um teste de validação. Se um software exibe estes atributos, então o software atende aos requisitos.


JEDITM

6.3. Testes Alfa & Beta

Uma série de testes de aceitação que permitem ao usuário final validar todos os requisitos. Podem ir desde testes informais a testes executados de forma planejada e sistemática. Este teste permite aos usuários finais descobrir erros e defeitos que só eles podem encontrar. Um Teste Alfa é conduzido em um ambiente controlado, geralmente no ambiente de desenvolvimento. Usuários finais são solicitados a usar o sistema como se estivessem trabalhando naturalmente, enquanto os desenvolvedores estão anotando erros e problemas de utilização. Testes Beta, ao contrário, são conduzidos em um ou mais ambientes do usuário e os desenvolvedores não estão presentes. Neste caso, são os próprios usuários finais que anotam todos os erros e problemas de utilização. Eles encaminham estes erros para os desenvolvedores, para que façam os consertos.


JEDITM

7. Mapeando os Produtos do Teste de Software RTM

Quando um componente é implementado, a especificação de teste e os casos de teste devem ser desenvolvidos. Precisamos estar atentos a ele e, ao mesmo tempo, termos certeza de que cada teste é mapeado para um requisito. Componentes RTM adicionais são adicionados. Abaixo temos a lista dos elementos recomendados para teste de software RTM.

Componentes de Teste de Software RTM

Descrição

Especificação de Testes O nome do arquivo que contém o plano de como testar os componentes do software.

Casos de Teste O nome do arquivo que contém os casos de teste para serem executados como parte da especificação de teste.

Tabela 7: Elementos de Teste de Software RTM

Estes componentes devem ser relacionados a um componente de software definido no RTM.


JEDITM

8. Métricas de Teste

As métricas usadas para medir a qualidade de um projeto orientado a objeto mencionadas na Engenharia de Projeto também podem prover uma indicação da quantidade de esforço de teste necessária para testar software orientado a objeto. Além disso, outras métricas podem ser consideradas para encapsulamento e herança. Exemplos de tais métricas seguem abaixo:

1. Falta de Coesão nos Métodos - Lack of Cohesion in Methods (LCOM). Se o valor do LCOM é alto, mais estados da classe precisam ser testados.

2. Porcentagem Public e Protected - Percent Public and Protected (PAP). Esta é a medida da porcentagem dos atributos de classe que são public ou protected. Se o valor do PAP é alto, aumenta a probabilidade de efeitos colaterais em outras classes por lidar com um alto acoplamento.

3. Acesso Público a Data Members - Public Access To Data Members (PAD). Esta é uma medida do número de classes ou métodos que acessam atributos de outras classes. Se o valor do PAD é alto, poderão ocorrer muitos efeitos colaterais.

4. Número de Classes Raiz - Number of Root Classes (NOR). Se o número de classes root aumenta, o esforço de teste também aumenta.

5. Número de Filhos - Number of Children (NOC) – e Profundidade de Árvore de Herança - Depth of the Inheritance Tree (DIT). Métodos de superclasses devem ser novamente testados para cada subclasse.


JEDITM

9. Exercícios

9.1. Especificando um Caso de Teste

1. Usando o Teste de Fluxo Básico, escreva os casos de testes que devem ser feitos para o método Obter o Registro de um Atleta. Determine a complexidade ciclomática do código para determinar o número de caminhos independentes. Cada um destes caminhos tornar-se-á um caso de teste.

9.2. Especificando Casos de Teste de Sistema

1. Escreva os casos de teste de sistema para o Sistema de Manutenção das Informações de Treinadores.

2. Escreva os casos de teste de sistema para o Sistema de Manutenção das Informações de Equipes.

9.3. Atividades de Projeto

O objetivo das atividades de projeto é reforçar o conhecimento e as habilidades adquiridos neste capítulo. Particularmente, eles são:

1. Definir os casos de teste.

2. Definir os casos de teste de sistema.

3. Rastrear a revisão e teste usando a Matriz de Rastreabilidade de Requisitos.

PRODUTOS PRINCIPAIS:

1. Casos de Teste

2. Casos de Teste de Sistema

3. Resultados dos Testes



Lição 7Introdução ao Gerenciamento do Projeto de

Software


JEDITM

1. Objetivos

O desenvolvimento de software para computador envolve uma variedade de fases, atividades e tarefas. Algumas dessas atividades são realizadas iterativamente até que o software fique pronto e entregue aos usuários finais para sua utilização.

Entretanto, antes que o desenvolvimento possa começar, usuários e desenvolvedores precisam estimar qual será a duração do projeto e quanto ele irá custar. Não é intenção deste capítulo discutir detalhadamente o gerenciamento do projeto de software. Isto está reservado para o Curso de Gerenciamento do Projeto de Software. A discussão nesta lição será realizada em torno dos conceitos de gerenciamento de projeto que auxiliarão a gestão do gerenciamento de projetos de software baseado em classes.


• Conhecer conceitos de gerenciamento básico de projeto de software• Entender definição e identificação do problema• Saber como organizar o projeto• Saber como agendar atividades do projeto• Saber como alocar recursos para o projeto• Aprender métricas de software• Saber calcular estimativas de custo e esforço para um projeto• Entender gerenciamento de risco• Entender gerenciamento de configuração de software


JEDITM

2. Gerenciamento do Projeto de Software

Gerenciamento do projeto de software é definido como o processo de gerenciar, alocar e disponibilizar recursos para o desenvolvimento do software que atenda aos requisitos. É a integração sistemática da técnica, recursos humanos e financeiros para atingir metas e objetivos do desenvolvimento de software de uma maneira eficiente e vantajosa. A Figura 1 mostra o processo de gerenciamento de projeto.

Figura 1: Processo de Gerenciamento de Projeto

Consiste em oito(8) tarefas.

Identificação do ProblemaÉ a tarefa onde um projeto proposto é identificado, definido e justificado. Um projeto proposto pode ser um novo produto, implementação de um novo processo ou um aprimoramento de um recurso existente.

Definição do ProblemaÉ a tarefa onde o propósito do projeto é esclarecido. A declaração da missão do projeto de software é a principal saída desta tarefa. Ela deverá especificar como o gerenciamento de projeto deverá ser utilizado para evitar perda de prazos, agendamentos mal elaborados, alocação inadequada de recursos, falhas de coordenação, baixa qualidade e conflito de prioridades.

Planejamento do ProjetoEsta tarefa define o Plano de Projeto. Descreve uma série de ações ou passos necessários para o desenvolvimento do produto de trabalho ou meta de acompanhamento. Isto é especificado como uma inicialização do projeto e executa estes objetivos. Componentes comuns do plano de projeto são incluídos nos objetivos do projeto, definição do projeto, time e critérios de performance ou critérios de validação.

Organização do ProjetoÉ a tarefa que especifica como integrar as funções dos recursos humanos no projeto. Ele é usualmente realizado concorrentemente com o planejamento do projeto. Requer habilidade de direção, orientação e supervisão da equipe do projeto. É necessário tornar claras as expectativas de cada pessoa da equipe e identificar como suas funções contribuirão no conjunto de metas globais do projeto.

Alocação de RecursosÉ a tarefa de alocar recursos para o projeto tais como, dinheiro, pessoas, equipamentos, ferramentas, instalações, informações, técnicas, com o propósito de atingir as metas e objetivos


JEDITM

do software.

Cronograma do ProjetoÉ a tarefa de alocar recursos para que todos os objetivos do projeto sejam alcançados dentro de um espaço de tempo razoável. Envolve a definição de períodos de tempo específicos para tarefas dentro da agenda de trabalho. Utiliza técnicas como: análise de disponibilidade de recursos (humano, material, dinheiro) e técnicas elaboração de cronogramas de PERT, CPM e Gráficos de Gantt.

Acompanhamento, Prestação de contas e ControleTarefa que envolve verificação de conformidade dos resultados do projeto com o planejamento e as especificações de desempenho elaborados. Controle envolve identificação e tomada de ações apropriadas para correção de desvios inaceitáveis em relação ao desempenho esperado. Inclui o processo de avaliação da relação entre o desempenho planejado e o real, no que diz respeito aos objetivos do projeto. As variáveis a serem medidas, as escalas de medição e a abordagem para realizar as medições deverão ser claramente especificadas durante a atividade de planejamento. Ações corretivas podem requerer reagendamento, realocação de recursos ou aceleração do desempenho para determinada tarefa.

Término do ProjetoÉ a tarefa que envolve a submissão do relatório final, a colocação em funcionamento do novo equipamento ou o sinal para liberação de uma versão. Ela pode dar início a um projeto subsequente ou complementar.


JEDITM

3. Identificação e Definição do Problema

O desenvolvimento de um projeto começa sua identificação e definição. O propósito desta tarefa é informar as decisões tomadas quanto a aprovação, rejeição e priorização de projetos. Ela requer que o estudo da requisição de produto e uma proposta sejam dadas para oferecer uma imagem clara do projeto proposto e as razões por trás dele.

O principal produto deste trabalho é a Proposta de Projeto. Ela tipicamente vem de uma variedade de fontes tais como clientes ou requisitos de usuários, conselhos de engenharia, requisitos legais ou regulatórios, pesquisas de mercado e novas tecnologias. Ela deverá indicar informações históricas, escopo e limites iniciais do projeto, capacidade técnica, custo/benefício e risco. Ela não inclui detalhes dos requisitos, planejamento e design. Criar uma proposta de projeto requer uma série de passos.

1. Definir a necessidade.

2. Identificar abordagens alternativas parar atender à necessidade.

3. Recomendar no mínimo duas alternativas.

4. Obter a aprovação.

Uma equipe pode ser estabelecida para fazer a proposta do projeto. Ela deverá incluir especialistas das seguintes áreas funcionais:

• Software/Hardware

• Suporte de Rede

• Centro de Processamento de Dados

• Segurança de Dados

• Administração de Banco de Dados

• Clientes e Usuários

• Auditores Internos e Externos

• Outros interessados ou grupos de suporte

Todas as deliberações da proposta de projeto devem ser documentadas no plano de desenvolvimento ou arquivo do projeto. A estrutura da proposta de projeto pode ser vista abaixo.

I. Sumário Executivo A. Escopo do projeto B. Objetivos do Negócio e do Sistema de Informação

i. Objetivos do Negócio a) Objetivo primário b) Objetivo secundário

ii.Objetivos do Sistema de Informação a) Objetivo primário b) Objetivo secundário

II. Critérios de sucesso III. Alternativas IV. Cronograma V. Custos VI. Benefícios VII. Risco VIII. Recomendações

Sumário ExecutivoEle oferece uma introdução para o projeto que inclui informações de suporte indicando o início do projeto e o sumário do trabalho a ser realizado. Ele responde às questões de porque o projeto é importante, qual é a oportunidade de negócio ou necessidade que irá atender e qual é o suporte de informações pertinente.

EscopoDefine os limites do projeto. Descreve as funções e processos que estarão envolvidos no projeto.


JEDITM

Responde à questão de qual é a realização final esperada desta proposta, o que estará incluído no projeto, o que não estará incluído no projeto, quem é o cliente e que solicitou o desenvolvimento do projeto.

Objetivos do Negócio e do Sistema de InformaçãoOferece alvos específicos e define resultados mensuráveis. Ao definir objetivos é utilizado o princípio SMART – Specific (específico), Measurable (mensurável), Attainable (atingível), Result-oriented (orientado a resultado) and Time-oriented (orientado ao prazo) e M&M’s – Measurable (mensurável) and Manageable (gerenciável). Resultados mensuráveis em termos de tempo, custo e desempenho. Responde à seguinte questão: qual é o resultado desejado ou benefícios do projeto e qual é a estratégia, tática ou objetivos operacionais suportados por este projeto.

Critério de SucessoIdentifica os principais resultados que deverão ser atingidos para que o projeto esteja completo. Oferece medidas específicas para utilização no julgamento de sucesso. Deverá dar suporte aos objetivos do projeto. Responde às questões de como saberemos quando o projeto está completo, quem irá julgar o sucesso do projeto e como irá julgar esse sucesso.

AlternativasDefine soluções alternativas para o problema do negócio ou necessidade. A alternativa pode ser “fazer ou comprar” ou abordagem técnica tais como codificação tradicional, desenvolvimento orientado a objetos ou ferramenta CASE, integração das edições, reengenharia de processo de negócio. Cada alternativa deverá ser avaliada para determinar um cronograma. Responde às questões de quais os principais produtos, qual relação lógica entre os principais produtos, que pressupostos serão utilizados para definir o cronograma, qual é a dimensão razoável do cronograma baseado no tamanho, esforço, dependências e compromissos.

CustosRepresenta um custo estimado para o desenvolvimento do software. Ele é representado como uma gama de valores. Responde às questões de quais são os custos associados com o esforço requerido para produzir cada um dos principais subprodutos, quais são os custos associados com hardware e software, quais são ou outros custos não laborais que devem ser considerados e qual é o custo operacional que precisa ser identificado e considerado.

BenefíciosPodem ser benefícios de curto ou longo prazo. Inclui potenciais economias, recuperações, posicionamento de produtos ou da empresa, aumento de quantidade ou qualidade, crescimento de produtividade e outros benefícios tangíveis ou intangíveis.

RiscosIdentifica riscos de cada alternativa e como os riscos podem ser reduzidos. Deverá ser analisado com base na probabilidade de ocorrência e impacto.

RecomendaçõesA equipe da proposta de projeto deverá trabalhar junto para selecionar a melhor alternativa que ofereça maior equilíbrio em termos de cronograma, custo/benefício e riscos do projeto. Deverá atender aos objetivos do projeto da melhor forma possível.


JEDITM

4. Organização do Projeto

A organização do projeto integra as funções das pessoas em um projeto. É necessário identificar claramente as expectativas de cada pessoa e que seja comunicado como sua função contribuirá no conjunto de metas e objetivos do projeto para que haja colaboração. Esta tarefa exige a compreensão da estrutura de desenvolvimento de sistemas da empresa. Figura 2 ilustra esta estrutura.

Figura 2: Organização da Estrutura de Desenvolvimento de Sistema

Comitê DiretivoDefine alguns problemas da empresa que têm grande efeito no desenvolvimento do projeto. Ele é composto pela cúpula gerencial (Presidente, CEO ou Diretor Administrativo ou Parceiro), linha de Gerentes (Vice-presidentes ou Chefes de Divisão), Gerentes (Planejamento da Empresa, Controladores), MIS ou gerentes EDP e opcionalmente Consultores. Suas funções consistem em:

• formalizar a composição da equipe do projeto;

• revisar e aprovar os planos de projeto e recomendações;

• aprovar e alocar recursos para o projeto;

• sincronizar o esforço de desenvolvimento do sistema com as demais atividades da organização;

• averiguar regularmente o progresso do projeto;

• resolver situações de conflito;

• aprovar requisições de alterações críticas; e

• liberar versões operacionais do sistema para o usuário.

Equipe de ProjetoComposta de dois grupos, denominados, desenvolvedores e usuários finais. Desenvolvedores consistem de gerente de projeto, analistas, projetistas, programadores e membros do controle de qualidade. O grupo de usuários finais consiste de EDP e Equipe MIS, equipe de usuários, colaboradores casuais e consultores. É um pequeno grupo com um líder ou gerente. Eles regularmente interagem para que as metas sejam atingidas. Requer espírito de equipe, contribuição e coordenação.

4.1. Estrutura da Equipe de Projeto

A estrutura da equipe pode ser organizada como democrática descentralizada, controlada descentralizada e controlada centralizada.

Democrática Decentralizada (DD)A estrutura de equipe não tem um líder permanente. Preferencialmente, haverá coordenadores para tarefas de curta duração que serão substituídos depois por outros que podem ser necessários para coordenar outras tarefas. Decisões são tomadas pelo consenso do grupo. A comunicação é principalmente horizontal.


JEDITM

Controlada Descentralizada (CD)A estrutura de equipe tem um líder permanente que primariamente coordena as tarefas. Ela tem um líder secundário responsável por subtarefas. Decisões são tomadas pelo consenso do grupo mas a implementação é feita pelos subgrupos. A comunicação durante a implementação é horizontal mas o controle é vertical.

Controlada Centralizada (CC)A estrutura de equipe tem um líder responsável pela coordenação da equipe e tomada de decisões de alto nível. A comunicação entre o líder e os membros da equipe é vertical.

A decisão de qual estrutura empregar dependerá das características do projeto. Utilize a Tabela 1 para determinar a estrutura da equipe a ser utilizada para um projeto.

Características do Projeto DD CD CCNível de Dificuldade do Problema Alto Baixo Baixo

Tamanho do Software (Linhas de Código ou Pontos por Função) Pequeno Grande Grande

Duração da Equipe Longa Curta Curta

Modularidade do Programa Baixa Alta Alta

Requisito de Confiabildade do Sistema (Reliability) Alta Alta Baixa

Rigidez na Data de Entrega Flexível Flexível Rígido

Grau de Sociabilidade Alta Baixa Baixa

Tabela 1: Característica do Projeto versus Estrutura da Equipe

4.2. Gráfico de Responsabilidade do Projeto

É uma matriz que consiste de colunas de áreas funcionais ou individuais, e linhas com ações requeridas. Ele representa a necessidade de comunicar expectativas e responsabilidades entre o pessoal envolvido no desenvolvimento do software. Evita problemas encontrados na comunicação e na possibilidade de indefinição de obrigações. Ele responde às seguintes questões:

• Quem faz o que?

• Quanto tempo levará?

• Quem informará quem sobre algo?

• Quem deverá aprovar o que?

• Quem é responsável por cada resultado?

• Quais interfaces pessoais são necessárias?

• Qual suporte é necessário para quem e quando?

Um modelo de matriz de responsabilidade do projeto é mostrada na Tabela 2.

Atividade Presid. Líder Proj. Analista Progr. 05/Nov 06/Nov 07/Nov 08/Nov

1. Tarefa Reunião Conjunta1.1 Redigir pedido do produto R T1.2 Marcar reunião conjunto R R T1.2.1 Marcar data e hora I R R T1.2.2 Marcar lugar I R R T1.2.3 Identificar particip. e facilitadores C I R E

1.3 Convidar participantes R E

1.4 Distribuir pedido do produto C R

Tabela 2: Matriz de Responsabilidade do Projeto

Legenda:• Código de Responsibilidade: R-Responsável I-Informa C-Consulta S-Suporte

• Código Tarefa: T-Terminada E-Execução A-Atrasada


JEDITM

5. Cronograma do Projeto

Cronograma do Projeto é a tarefa que descreve o processo de desenvolvimento do software para um projeto particular. Enumera fases ou estágios do projeto, e divide cada um dentro de tarefas ou atividades discretas que serão executadas, identifica as interações entre as partes do trabalho e estima o tempo para cada tarefa ou atividade ser executada. É uma sequência de atividades planejadas no tempo sujeitas a relacionamentos de precedências, restrições de tempo e limitações de recursos com a finalidade de atingir objetivos específicos.

É um processo da equipe que dá início à formulação do programa de trabalho. É um processo iterativo que deve ser flexível para acomodar mudanças. Há certos princípios básicos utilizados na criação do cronograma do projeto. Alguns deles estão enumerados abaixo:

1. Compartimentalização. O produto e o processo são decompostos em atividades e tarefas tangíveis.

2. Interdependência. Cada atividade ou tarefa compartimentalizada deve ser determinada. Tarefas podem ocorrer em sequência ou em paralelo. Tarefas podem ocorrer independentemente.

3. Alocação de Tempo. Cada tarefa deverá ser alocada em algum número de unidades de trabalho (pessoa/dia ou homem/dia). Cada tarefa deverá ter uma data de início e fim sujeitas às interdependências e pessoas responsáveis pela tarefa (part-time ou full-time).

4. Validação de Esforço. Em nenhum momento o número de pessoas alocadas é maior que o número de pessoas disponíveis.

5. Definição de Responsabilidade. Cada tarefa deverá ter um dono. Ele deverá ser um membro da equipe.

6. Definição de Resultado. Cada tarefa deverá ter um resultado definido. Os produtos do trabalho são combinados em entregas.

7. Definição de Milestones. Cada tarefa ou grupo de tarefas deverão ser associadas com um marco do projeto. Milestones do projeto são pontos de revisão para qualidade e para aprovação do patrocinador do projeto.

O Cronograma do Projeto identifica conjuntos de atividades ou tarefas, marcos e entregas.

1. Conjuntos de Atividades ou Tarefas. Uma coleção de atividades da engenharia de software, marcos e entregas que deverão ser realizadas para completar um projeto em particular. É a parte do projeto que tem lugar sobre um período de tempo. É descrito como um verbo no gerúndio.

2. Milestones. Uma indicação de que alguma coisa foi completada. Faz referência a um momento particular no tempo. Significa pontos de realização dentro do cronograma do projeto. Ele não é a duração do trabalho. Exemplos de milestones de projeto são aprovação do usuário, aprovação do projeto do sistema e data de recuperação do investimento no sistema.

3. Entregáveis. Uma lista de itens que um cliente espera ver durante o desenvolvimento do projeto. Pode incluir documentos, demonstrações de funcionalidades, demonstrações de subsistemas, demonstrações de precisão, confiabilidade, segurança ou velocidade.

5.1. Estrutura de Divisão do Trabalho do Projeto (WBS)

A WBS - Work Breakdown Structure é uma ferramenta que permite aos gerentes de projeto definir o conjunto de tarefas, milestones e entregáveis. É uma abordagem de análise sistemática de detalhamento do projeto como um conjunto discreto de unidades de trabalho. As tarefas e os milestones podem ser usados no projeto para acompanhar o desenvolvimento e a manutenção. Dois métodos são utilizados na definição da estrutura de divisão do trabalho. São denominados Análise da Divisão do Trabalho, Decomposição top-down e Integração bottom-up.

Análise da Divisão do Trabalho - Work Breakdown Analysis


JEDITM

A Análise da Divisão do Trabalho consiste dos seguintes passos:

1. Dividir o projeto em blocos de atividades relacionadas.

2. Organizar os blocos dentro de uma lógica hierárquica.

• A análise inicia pela identificação das maiores fases e dos principais subprodutos que cada uma produz.

• Dividir cada atividade e definir subatividades e produtos do trabalho destas.

• Continuar a subdividir uma atividade até obter uma atividade que não possa ser subdividida. Esta atividade atômica é chamada de unidade de trabalho ou pacote.

3. Definir a Unidade de Trabalho ou Pacote. A unidade de trabalho ou pacote é de responsabilidade de uma pessoa. Deverá ser executada sem interrupção alguma até estar finalizada. Sua duração e custo podem ser medidos e requerem uso contínuo de um conjunto de recursos.

Processo WBS de Decomposição top-down e Integração bottom-upEste método define duas principais atividades como especifica seu nome, decomposição top-down e integração bottom-up.

1. Decomposição top-down

• Identifica de 4-7 componentes principais do trabalho, não importando a sequência.

• Identifica entregáveis intermediários e finais para cada grupo.

• Executa decomposição funcional até que uma tarefa tenha um dono, define claramente os entregáveis, estimativas confiáveis e que possam ser verificadas.

• Utiliza um verbo para designar uma tarefa no nível mais elementar. O número recomendado de níveis é quatro (4).

• Múltiplas iterações são requeridas.

2. Integração bottom-up

• Todas as tarefas possíveis são consideradas (Brainstorm).

• Organiza tarefas em agrupamentos de 4-7 refletindo como o projeto será gerenciado.

5.2. Formato de Cronograma da Divisão do Trabalho

Há dois formatos comuns que podem ser utilizados para representar a WBS, denominados diagrama gráfico ou hierárquico e esquema de tópicos.

Diagrama Gráfico ou Hierárquico

Um exemplo de um diagrama hierárquico da Tarefa Reunião Conjunta Prévia da Engenharia de Requisitos é mostrada na Figura 3.


Reunião Conjunta prévia

Registrar o pedido do produto

Marcar reunião conjunta previamente

Convidar Participantes

Distribuir requisição de produtos para todos os participantes

Marcar data e hora

Marcar Local Identificar facilitadores e participantes

JEDITM

Figura 3: Diagrama Hierárquico

Esquema de Tópicos (Outline Format)Um exemplo de esquema de tópicos é mostrado abaixo.

1. Tarefa - Reunião Conjunta Prévia

1.1 Redigir pedido do produto

1.2 Marcar reunião conjunta prévia

1.2.1 Marcar data e hora

1.2.2 Marcar lugar

1.2.3 Identificar facilitadores e participantes

1.3 Convidar participantes

1.4 Distribuir pedido do produto para todos os participantes

Gráfico de GANTTEste é um modo fácil de escalonar tarefas. Ele é um diagrama que consiste de barras que indicam a duração da tarefa. A dimensão horizontal indica o tempo, enquanto que a dimensão vertical indica a tarefa. Tabela 3 mostra um exemplo de gráfico de GANTT.

1 2 3 4 5 6

1. Tarefa Reunião conjunta prévia

1.1 Redigir pedido do produto


1.2.1 Marcar data e hora

1.2.2 Marcar lugar

1.2.3 Identificar facilitadores e participantes

1.3 Convidar participantes

1.4 Distribuir pedido do produto

Tabela 3: Exemplo de Gráfico de GANTT


JEDITM

6. Alocação de Recursos do Projeto

É o processo de alocar ou destinar dinheiro, pessoas, equipamentos, ferramentas, facilidades, informações, habilidades e outros para tarefas identificadas no projeto. Eles serão necessários para atingir os objetivos e metas do software. Há três restrições principais que devem sempre ser consideradas em um projeto de desenvolvimento de software. São elas:

• Restrições de Tempo

• Restrições de Recursos

• Restrições de Desempenho

6.1. Base de Dados de Disponibilidade de Recursos

O gerente de projeto deverá utilizar a base de dados de disponibilidade de recursos para gerenciar os recursos alocados para cada grupo de tarefas. A base de dados de disponibilidade de recursos especifica quais recursos são necessários diante dos recursos que estão disponíveis. A Tabela 4 mostra um exemplo.

Tipo Rec. Recurso ID Habilidades Data Neces. Duração No

RecursosTipo 1 Gerente Projeto Planejamento

Gerenciamento1/1/XX 10

meses1

Tipo 2 Analista DesenvolvimentoAnálise eModelagem

25/12/XX Indefinido 2

Tipo 3 Projetista Desenvolvimento Software Arquitetura e Componentes

Agora 36 meses

2

… … … … … …

… … … … … …

… … … … … …

Tipo n-1 Operador Conhecimento de Equipamentos Imediato Indefinido 4

Tipo n Programador Ferramentas Software 9/2/XX 12 meses 5

Tabela 4: Base de Dados da Disponibilidade de Recursos

Há diversos fatores que devem ser considerados quando da alocação de recursos. Alguns deles são listados abaixo.

• Limitações na disponibilidade do recurso

• Restrições de precedências

• Restrições de subdivisões de atividades

• Atividades imprevistas

• Data de término do projeto

• Substituição de recursos

• Assinalamento parcial de recursos

• Atividades mutuamente exclusivas

• Disponibilidade variável de recursos

• Variação na duração das atividades

Alocação de recursos para um grupo de tarefas do Projeto.

Grupo de Tarefas do Projeto Recursos1. Tarefa reunião conjunta prévia

1.1 Redigir pedido do produto Usuários finais que irão redigir o pedido do produto


JEDITM

Grupo de Tarefas do Projeto RecursosComputador Material de escritório


1.2.1 Marcar data e hora Líder do projeto

1.2.2 Marcar lugar Líder do projeto

1.2.3 Identificar facilitadores e participantes Líder do projeto

1.3 Convidar participantes Equipe AdministrativaEmailMaterial de escritório

1.4 Distribuir pedido do produto Líder do projetoComputadorMaterial de escritório


JEDITM

7. Métricas de Software

Referem-se a uma variedade de indicadores utilizados em software de computadores. Esses indicadores podem ser aplicados ao processo de software com o objetivo de melhoria contínua do processo. Podem ser utilizadas através do projeto para auxiliar em estimativas, controle de qualidade, avaliação de produtividade e controle do projeto. Podem ainda ser utilizadas pelos engenheiros de software para assegurar a qualidade dos produtos e auxiliar na tomada de decisões táticas conforme o projeto evolui.

Métricas de Software são utilizadas como indicadores para propiciar melhor compreensão do processo de software, do projeto ou do software. Permitem aos engenheiros de software tomar decisões de como prosseguir com o esforço de desenvolvimento.

Categorias de MétricasEstas são as linhas gerais de duas categorias métricas:

1. Métricas Diretas. No processo de software elas podem ser o custo e o esforço dispendido. No software, podem ser linhas de código (LOC – Lines of Codes) produzidas, número de classes, velocidade de execução, espaço em memória e defeitos reportados em um período de tempo.

2. Métricas Indiretas. Podem ser medidas de produtos tais como funcionalidade, qualidade, complexidade, eficiência, confiabilidade, manutenibilidade, etc.

Exemplos de métricas que são aplicadas a projetos de software são brevemente enumeradas abaixo.

1. Métricas de Produtividade. Productivity Metrics. Referem-se a medição de saídas ou resultados do processo de software.

2. Métricas de Qualidade. Referem-se às medidas que indicam com que precisão o software se aproxima dos requisitos. Também conhecidas como capacidade do software para uso.

3. Métricas Técnicas. Refere-se à medição das características do produto tais como complexidade, grau de colaboração, modularidade, etc.

4. Métrica Orientada a Tamanho. É utilizado para coletar medidas diretas do software produzido e qualidade baseada nas linhas de código (LOC) produzidas.

5. Métrica Orientada a Função. É utilizado para coletar medidas diretas do software produzido e de qualidade baseada nas funcionalidades ou utilidade dos programas.

6. Métrica Orientada a Recursos Humanos. Oferece medidas coletadas sobre a maneira como as pessoas desenvolvem software de computador e a percepção humana sobre a eficiência de métodos e ferramentas.

Diferentes fases ou atividades do desenvolvimento de projetos requerem diferentes métricas. Cada capítulo oferece as métricas que normalmente são utilizadas para auxiliar os engenheiros de software a garantir a qualidade do software e do processo.

7.1. Métrica Orientada a Tamanho – Linhas de Código (LOC)

Um medida direta utilizada para métrica de software é Linhas de Código (LOC). Ela é uma métrica orientada ao tamanho utilizada para estimar esforço e custo. É importante que as métricas de outros projetos sejam colocadas em uma tabela para servir de referência durante a realização da estimativa. Tabela 5 mostra um exemplo disto.

Projeto Esforço(em pessoas-mês)

Custo(em P)

KLOC(mil linhas de cód.)

Págs(de Doc.)

Erros Pessoas

Projeto Um 24 120 12.1 365 29 3Projeto Dois 62 450 27.2 1224 86 5Projeto Três 43 213 20.2 1050 64 6


JEDITM

Projeto Esforço(em pessoas-mês)

Custo(em P)

KLOC(mil linhas de cód.)

Págs(de Doc.)

Erros Pessoas

Projeto Quatro 36 30 15 17 10 5… … … … … … …

Tabela 5: Histórico de Métricas de Software

Nesta tabela, esforço em pessoas-mês especifica o número de meses em que o projeto foi desenvolvido, custo é o dinheiro gasto na produção do software, KLOC são as linhas de código produzidas, páginas é o número de páginas de documentação, erros é o número de erros reportados depois que o software foi entregue para o cliente e pessoas é o número de pessoas que desenvolveram o software.

Alguém poderia derivar métricas desta tabela. Exemplos de cálculos são mostrados abaixo.

Produtividade = KLOC / pessoas-mês

Qualidade = erros / KLOC

Custo = Custo / KLOC

Documentação = Páginas / KLOC

7.2. Métrica orientada por Função: Pontos por Função (PF)

Outra métrica comumente utilizada é a métrica de Pontos por Função (PF). É focada na funcionalidade ou utilidade do programa. Utiliza um relacionamento empírico baseado em mensurações contáveis de domínio de informação e estimativas de complexidade do software.

Calculando Ponto por Função

PASSO 1. Determinar o valor de domínio da informação usando a tabela mostrada na Tabela 6.

Preencher a coluna de quantidade e multiplicar o valor pelo fator de peso escolhido. Como exemplo, se o número de entrada for 3 e a entrada de dado for simples, escolha o fator de peso 3, multiplicando, 3 x 3 = 9.

Domínio de Informação Fator de PesoParâmetro de Medição Qtde. Simples Média Complexa

Número de Entradas Externas x 3 4 6 = Número de Saídas Externas x 4 5 7 = Número de Consultas Externas x 3 4 6 = Número de Arquivos x 7 10 15 = Número de Interfaces Externas x 5 7 10 =Total Geral

Tabela 6: Cálculo do Domínio de Informação

Encontre a soma (Total Geral).

PASSO 2. Determinar o valor de ajuste de complexidade.

Para determinar o valor de ajuste de complexidade, utilize a escala na Tabela 7 para responder às questões especificadas a seguir.

0

Sem Influência

1

Casual

2

Moderada

3

Média

4

Significativa

5

Essencial

Tabela 7: Escala de ajuste de complexidade

1. Sistema exige cópia de segurança e recuperação confiáveis?

2. Exige a comunicação entre os dados?

3. Existem funções de processamento distribuído?


JEDITM

4. Performance é crítica?

5. Sistema irá rodar em ambiente operacional conhecido e bastante utilizado?

6. Sistema requer entrada de dados on-line?

7. Entrada de dados on-line requer múltiplas telas e operações ?

8. Arquivos principais são atualizados on-line?

9. Entradas, saídas, arquivos ou consultas são complexos?

10. Processamento interno é complexo?

11. Código modelado pode ser reusável?

12. Procedimentos de instalação e migração foram incluídos no projeto?

13. Sistema foi projetado para múltiplas instalações em diferentes organizações?

14. Sistema foi projetado para facilitar alterações e utilização pelo usuário?

PASSO 3. Calcular o ponto de função.

Utilize a fórmula indicada abaixo.

Ponto de Função = Quantidade Total X [0.65 + 0.01 X soma(Fi)]

Pode-se utilizar outros tipos de métricas orientadas a tamanho. Exemplos disso são listados abaixo.

Produtividade = PP / pessoa-mês

Qualidade = Defeitos / PF

Custo = Custo / PF

Documentação = Páginas de Documentação / PF

7.3. Harmonizando Métricas de PF e LDC

Para harmonizar as métricas LDC e PF, utilizamos a tabela 81.

Linguagem de Programação LDC/PF (Média)Linguagem Assembly 337COBOL 77Java 63Perl 60Ada 154Visual Basic 47SQL 40C 162C++ 66

Tabela 8: Harmonização de LDC e PF

1 Pressman, Software Engineering: A Practitioner's Approach, p. 657)


JEDITM

8. Métricas de Software

Avaliações de ProjetoSão necessárias para auxiliar engenheiros de software a determinar o esforço e o custo requeridos na construção do software. Para fazer a avaliação, é necessário experiência, acesso a uma boa série histórica de dados, e comprometimento para quantificar medidas quando dados qualitativos é tudo o que existe.

Pode-se usar LDC e PF para o provimento de estimativas de custo e esforço. Ambos têm variáveis para quantificar o "tamanho" de cada elemento de software. Ambos têm métricas de baseline coletadas de projetos anteriores e utilizadas em conjunto com variáveis de estimativa para o cálculo de projeções de esforço e custo.

Como exemplo, considere as estimativas de projeto de um sistema de manutenção de associados de um clube. Utilize LDC e PF para determinar as estimativas de custo e esforço. Calculamos primeiro o PF.

Domínio de Informação Fator de PesoParâmetro de Medição Qtd Simples Média Complexa

Número de Entradas Externas 2 x 3 4 6 6 Número de Saídas Externas 5 x 4 5 7 20 Número de Consultas Externas 3 x 3 4 6 9 Número de Arquivos 2 x 7 10 15 14 Número de Interfaces Externas 2 x 5 7 10 10

Qtd-Total 59

1. O sistema exige cópia de segurança e recuperação confiáveis? 3

2. É exigida comunicação de dados? 3

3. Existem funções de processamento distribuído? 1

4. A performance é crítica? 2

5. O sistema irá rodar em ambiente operacional conhecido e muito utilizado? 3

6. O sistema requer entrada de dados on-line? 4

7. A entrada de dados on-line requer múltiplas telas e operações ? 2

8. Os arquivos principais são atualizados on-line? 2

9. As entradas, saídas, arquivos ou consultas são complexos? 1

10.O processamento interno é complexo? 1

11.O código modelado pode ser reusável? 4

12. Procedimentos de instalação e migração foram incluídos no projeto? 3

13.O sistema foi projetado para múltiplas instalações em diferentes organizações? 1

14.O sistema foi projetado para facilitar alterações e facilidade de uso pelo usuário? 1

Total = 31

PF = 59 X [0.65 + 0,01 X 31] = 56,64 PF

O projeto utiliza JAVA extensivamente. A LDC estimada é calculada a seguir:

LDC = 56,64 * 63 = 3568,32 LDC

Estimativas Derivadas: Assuma que a Manutenção do Título do Clube é similar ao projeto 4.

Estimativas de Custo são calculadas a seguir:

Custo de Produção de uma única LDC (do banco de dados): Custo / KLDC

Custo/KLDC = P30000/15000LDC = P2,00/LDC

Custo do projeto = 3568,32 * 2,00 = P7136,64


JEDITM

Estimativas de Esforço são calculadas a seguir:

Número de LDC produzidas em um mês (do banco de dados): KLOC/Esforço

KLDC/Esforço = 15000LDC / 8 meses = 1875 LDC / mês

Esforço do projeto = 3568,32 / 1875 = 1,9 ou 2 meses


JEDITM

9. Escrevendo o Plano de Projeto

O plano de projeto é um documento que contém o plano de desenvolvimento do software. Não é necessário ser extenso e complexo. Seu propósito é ajudar a estabelecer a viabilidade do desenvolvimento do software. O plano se concentra em declarações genéricas de "O Quê" vai ser feito e declarações específicas de "Quanto vai custar" e "Quanto tempo" vai levar para ser feito. Os detalhes serão apresentados no decorrer do desenvolvimento. O plano de projeto teria a seguinte estrutura.

I. Introdução

A. Histórico

B. Objetivos e Escopo do Projeto

C. Dados e Funções Principais

D. Questões de Performance

E. Restrições e Limitações

II. Estimativas do Projeto

A. Estimativas de Esforço

B. Estimativas de Custo

III. Cronograma do Projeto

IV. Recursos do Projeto

V. Organização do Projeto

9.1. Histórico

Consiste em dois ou mais parágrafos discutindo brevemente o histórico do sistema. Identifica os dados principais, informações utilizadas e os processos principais dentro do sistema em condições gerais. Identifica estudos prévios feitos com o histórico do sistema.

9.2. Declaração de Problema

Define um conjunto de problemas ou áreas de melhoria que podem ser vistas dentro do histórico do sistema.

9.3. Objetivos do Projeto

Declaração do que será alcançado ou será feito. Define as metas globais do projeto sem considerar como estas metas serão alcançadas. Deveria ser SMART (Esperto):

Specific – Específico Measurable – Mensurável Attainable – Atingível Result-oriented – Orientado a resultado Time-bound – De tempo limitado

9.4. Estimativas do Projeto

Identifica os dados primários, funções e comportamento que caracterizam o problema e, mais importante, tenta limitar estas características de uma maneira quantitativa. Declaração do que será e não será feito.

9.5. Cronograma do Projeto


JEDITM

Envolve a tarefa de períodos de tempo a tarefas específicas dentro de um horário de trabalho. Para cada atividade identificada no WBS, terá:

Entregável. É o produto de trabalho que precisa ser desenvolvido. Dono. Responsável que assegura que a tarefa seja finalizada e foram conhecidos os entregáveis. Recursos. São as pessoas responsáveis por realizar a tarefa. Recursos técnicos. São os equipamentos, ou seja, as ferramentas que são necessárias para fazer o trabalho e criar o entregável. Custo. É quanto gasta para realizar a atividade. Linha do Tempo. Em quanto tempo o trabalho será terminado.

9.6. Recursos do Projeto

Lista os recursos necessários. Banco de dados de Disponibilidade de Recurso.

9.7. Organização do Projeto

Identifica as pessoas necessárias para realizar o projeto e os papéis que eles precisam desempenhar.


JEDITM

10. Gerenciamento de Risco

Gerenciamento de Risco consiste em etapas que ajudam engenheiros de software a entender e gerenciar incertezas no processo de desenvolvimento de software. Um risco é considerado um problema potencial, ou seja, ele pode ou não acontecer. É melhor identificá-lo, avaliar sua probabilidade de ocorrer, estimar seu impacto e estabelecer um plano de contingência caso ele ocorra. Várias coisas podem acontecer durante o progresso do desenvolvimento de software. É por essa razão que entender os riscos envolvidos e ter medidas que os evitem, influenciará o quão bem o projeto é gerenciado.

Duas importantes características de risco são sempre analisadas e identificadas em um gerenciamento de risco. Riscos sempre envolvem incertezas. Isto significa que riscos podem ou não acontecer. Se um risco torna-se realidade, ocorrerão perdas e consequências negativas. O nível de incerteza e grau de perda associados a cada risco são identificados e documentados.

Existem diferentes categorias de riscos que engenheiros de software precisam entender. Elas devem ser consideradas como problemas potenciais que podem surgir. Entendê-los permitirá a criação de um plano de contingência com o impacto mínimo no desenvolvimento do projeto.

1. Riscos de Projeto. Esses riscos estão associados ao plano do projeto. Se tal risco vier a se tornar realidade, poderiam causar problemas referentes a atrasos, orçamento e recursos humanos.

2. Riscos Técnicos. Esses riscos estão associados a aspectos relativos a implementação do software. Caso vierem a se tornar realidade, a implementação do projeto torna-se dificultosa. Podem ser problemas de modelagem e interface, problemas relativos a componentes, banco de dados e problemas de infraestrutura.

3. Riscos de Negócio. Esses riscos estão associados com a viabilidade do software. Se tal risco vier a acontecer, no contexto do negócio o software, será um problema. Pode ser a construção de um software que não atenda às necessidades, que não seja utilizado, ou que perca orçamento e patrocínio de área demandante.

4. Riscos Conhecidos. Esses riscos podem ser detectados com avaliação cuidadosa do plano de projeto, análise do ambiente de negócios, ou outras boas fontes de informação.

5. Riscos Previsíveis. Esses riscos ocorreram com projetos similares e a expectativa é que possam ocorrer novamente.

6. Riscos Imprevisíveis. Esses riscos não são detectados.

10.1. A Tabela de Risco

A Tabela de Risco é uma ferramenta que permite ao engenheiro de software identificar e gerenciar riscos inerentes ao projeto de desenvolvimento de software. A Tabela 9 mostra um exemplo de tabela de risco.

Riscos Identificados Categoria Probabilidade Impacto MMGREstimativa do tamanho do projeto pode ser muito baixa

TP 60% 2

Um número grande de grupos de usuários finais não estão identificados

TP 30% 3

Componentes não podem ser reutilizados TP 70% 2Membros do comitê patrocinador não estão interessados no projeto

IN 40% 3

Prazo do projeto não é negociável IN 50% 2Rotação de recursos será alta TE 60% 1… … … … …

Tabela 9: Exemplo de Tabela de Risco

A primeira coluna lista todos os riscos possíveis, inclusive aqueles que muito provavelmente não


JEDITM

irão acontecer. Cada risco é então categorizado. A categorização identifica os tipos de risco, enumerados abaixo de forma genérica.

1. Tamanho do Produto. São os riscos relacionados com o tamanho geral do software que precisa ser desenvolvido.

2. Impacto no Negócio. São os riscos relacionados às restrições de mercado e gerenciamento.

3. Característica do Cliente. São os riscos relacionados aos requisitos do usuários final e a habilidade da equipe de desenvolvimento de entender-se e comunicar-se com os mesmos.

4. Definição de Processo. São os riscos relacionados ao processo de software e como as pessoas envolvidas no esforço de desenvolvimento estão organizadas.

5. Ambiente de Desenvolvimento. São os riscos relacionados à disponibilidade e qualidade das ferramentas utilizadas no desenvolvimento do software.

6. Tecnologia. São os riscos relacionados à complexidade do sistema e ao grau de inovação que faz parte do software.

7. Tamanho e Experiência da Equipe. São os riscos relacionados à técnica em geral e experiência em projetos dos engenheiros de software.

O valor provável do risco é identificado como valor percentual dele ocorrer. A seguir, o seu impacto quando verificada sua ocorrência. É estimado utilizando os seguintes valores.

1. Catastrófico. Resultaria em fracasso no atendimento dos requisitos e a não aceitação do software.

2. Crítico. Resultaria em fracasso no atendimento de requisitos relacionados com a degradação de performance do sistema a um ponto em que seu sucesso seja questionável.

3. Marginal. Resultaria em fracasso no atendimento de requisitos, o que acarretaria degradação da missão secundária.

4. Desprezível. Resultaria em inconveniências e problemas de uso.

A última coluna contém plano de MMGR(Mitigação, Monitoração e Gerenciamento de Risco) de cada risco. Tem os seguintes componentes:

1. Identificador (ID) do Risco. É um número único de identificação atribuído ao risco.

2. Descrição. Breve descrição do risco.

3. Contexto de Risco. Define a condição pela qual o risco pode ser concretizado.

4. Mitigação e Monitoração. Define os passos necessários a serem executados a fim de mitigar e monitorar o risco.

5. Plano de Contingência. Define os passos necessários a serem executados quando o risco é concretizado.

10.2. Lista de Identificação de Risco

Pode-se utilizar a lista abaixo para determinação dos riscos inerentes ao projeto de desenvolvimento de software.

Riscos de Tamanho do Produto

O tamanho do produto é diretamente proporcional ao risco do projeto. Como engenheiros de software, devemos prestar atenção no seguinte:

• O quão grande foi estimado o software em termos de linhas de código e pontos por função?

• Qual a quantidade de programas, arquivo e transações?

• Qual o tamanho do banco de dados?

• Qual a quantidade de usuários estimada?

• Quantos componentes são reutilizados?


JEDITM

Riscos de Negócio

• Qual é o valor de negócio do software para a empresa ou departamento?

• Qual é a visibilidade do software para a alta direção?

• Quão razoável é a data de entrega?

• Qual a quantidade de clientes?

• Quantos produtos e sistemas interagem com o software?

• Qual o tamanho da documentação do produto?

• Que qualidade tem a documentação do produto?

• Quais são as restrições governamentais inerentes ao desenvolvimento do projeto?

• Qual o custo associado a uma entrega tardia?

• Qual o custo associado a produto defeituoso?

Riscos Relacionados ao Cliente

• Como é o relacionamento de trabalho com o cliente?

• Qual é o nível técnico do cliente para definir seus requisitos?

• Os clientes estarão dispostos a perder tempo para coleta de requisitos?

• Os clientes estarão dispostos a participar de revisões técnicas formais?

• Qual é o nível de conhecimento dos clientes em termos de aspectos tecnológicos do software?

• O cliente conhece o processo de desenvolvimento do software e o seu papel nesse desenvolvimento?

Riscos de Processo – Problemas de Processo

• A alta direção apóia ou tem compromisso total com o esforço de desenvolvimento do software?

• A empresa tem a descrição do processo de software a ser utilizada no projeto?

• A equipe conhece o processo de desenvolvimento do software?

• O processo de software foi utilizado antes em outros projetos pelo mesmo grupo de pessoas?

• A empresa desenvolveu ou adquiriu cursos de treinamento para os gerentes e equipe técnica?

• Existem padrões de engenharia de software publicados que serão utilizados pelos desenvolvedores e gerentes?

• Existem esboços e exemplos de entregáveis?

• As revisões técnicas formais de especificação de requisitos, modelagem e código são feitas regularmente? Têm procedimentos definidos?

• As revisões técnicas formais de procedimentos de teste e casos de teste são feitas regularmente? Têm procedimentos definidos?

• Os resultados de cada revisão técnica formal são documentados, incluindo erros encontrados e recursos utilizados? Têm procedimentos definidos?

• Têm procedimentos que assegurem que o trabalho efetuado no projeto esteja em conformidade com os padrões de engenharia de software?

• Têm gerenciamento de configuração para manter consistência entre sistema/requisitos de software, modelagem, casos, e casos de teste?

• Existem documentos para declaração de trabalho, especificação de requisitos e plano de desenvolvimento de software de cada subcontrato?

Riscos de Processo – Problemas Técnicos

• Existe algum mecanismo que facilite uma clara comunicação entre cliente e desenvolvedor?

• Existem métodos específicos utilizados para análise de software?

• Existem métodos específicos para modelagem de componentes?


JEDITM

• Existem métodos específicos para modelagem de arquitetura e dados?

• Os códigos são escritos em linguagem de alto nível? Qual o percentual?

• Padrões de codificação e documentação são observados?

• Existem métodos específicos para modelagem de casos de teste?

• Ferramentas de software são utilizadas para suporte de planejamento e rastreamento de atividades?

• Ferramentas de gerenciamento de configuração de software são utilizadas para controlar e rastrear atividades de mudança através do processo de software?

• Ferramentas CASE são utilizadas?

• As métricas de qualidade foram coletadas para todos os projetos de software?

• Existem métricas de produtividade coletadas para projetos de software anteriores?

Riscos Tecnológicos

• A empresa é recente em tecnologia?

• Será necessário criar novos algoritmos ou novas tecnologias de entrada e saída?

• O software precisa utilizar hardware novo ou sem suporte?

• O software precisa utilizar um sistema de banco de dados não testado na área de aplicação?

• Será necessário definir interface de usuário especializada?

• Serão necessários novos métodos de teste, análise e modelagem?

• Será necessário utilizar métodos não convencionais de desenvolvimento de software, tais como métodos formais, abordagens baseadas em inteligência artificial e redes neurais artificiais?

Riscos do Ambiente de Desenvolvimento

• Existem ferramentas de gerenciamento de projeto de software?

• Existem ferramentas para análise e modelagem?

• Existem ferramentas de teste?

• Existem ferramentas de configuração de software?

• As ferramentas de software estão integradas entre si?

• Será necessário treinamento dos membros da equipe de desenvolvimento para usar as ferramentas de desenvolvimento?

• Existem ajudas on-line ou grupos de suporte?

Risco Associado ao Tamanho e Experiência da Equipe

• A rotatividade da equipe é alta?

• Temos recursos com expertise?

• O número de recursos da equipe de desenvolvimento é suficiente?

• Será necessário hora extra?

• Haverá problemas de comunicação?


JEDITM

11. Gerenciamento de Configuração de Software

Gerenciamento de Configuração de Software é uma atividade guarda-chuva que dá suporte ao software durante o seu ciclo de vida. Pode ocorrer a qualquer tempo como produto dos trabalhos que são desenvolvidos ou que sofreram manutenção. É focado no gerenciamento de mudanças no processo de desenvolvimento de software. Consiste na identificação e controle da mudança, assegurando que esteja sendo adequadamente implementada e reportando-a aos que possam ser afetados pela mudança. O gerenciamento de configuração efetua o gerenciamento de itens chamados Itens de configuração de Software (ICS) ou unidades, os quais podem ser programas de computador (tanto códigos-fonte como executáveis), documentos (sejam técnicos ou do usuário) e dados.

Os possíveis módulos que servem como unidades ou itens de configuração de software são listados a seguir. São baseados nas atividades ou fases da engenharia de software que são produzidas.

1. Fase de Planejamento de Software

a) Plano de Projeto de Software

2. Requisitos de Engenharia

a) Especificações de Sistema

b) Modelos de Requisitos

c) Modelos de Análise

d) Protótipos de Telas

3. Engenharia de Modelagem

a) Modelagem do Banco de Dados

b) Modelagem de Telas e Caixas de Diálogo

c) Modelagem de Relatórios

d) Modelagem de Formulários

e) Arquitetura de Software

f) Modelagem de Componentes

g) Modelagem Distribuição

4. Implementação

a) Listagem de Código-Fonte

b) Executável ou Código Binário

c) Módulos Ligados

5. Testes

a) Especificações de Teste

b) Casos de Teste

6. Manuais

a) Manuais de Usuário

b) Manuais Técnicos

c) Procedimentos e Instalação de Engenharia de Software

7. Padrões e Procedimentos de Engenharia de Software

11.1. Baseline


JEDITM

O gerenciamento de ICSs envolve o conceito de baseline (linha de partida). Uma baseline é um conceito de gerenciamento de configuração de software que auxilia engenheiros de software a efetuar o controle de mudança. É a especificação ou produto que tenha sido formalmente revisado e acordado para ser a base de desenvolvimentos futuros. Somente pode ser alterada através de um procedimento formal de mudança. Figura 4 mostra a dinâmica do gerenciamento de baseline dos ICSs.

Figura 4: Dinâmica de Baseline de ICSs

Uma tarefa de engenharia de software desenvolve um módulo que torna-se um item ou unidade de configuração de software. Passa pela revisão técnica formal para detecção de erros e falhas. Uma vez que o módulo passe na verificação ou seja aceitável, torna-se uma baseline e é salva no banco de dados do projeto. Às vezes, este módulo é extraído do banco de dados do projeto como entrada de alguma outra tarefa de engenharia de software. Observe que "atualizar" uma ICS envolve controles e procedimentos. Durante a execução de uma tarefa de ES (Engenharia de Software), é possível que a ICS tenha sido modificada. Neste caso, a ICS modificada irá passa por uma outra revisão técnica formal. Se aprovada ou aceitável, a versão modificada torna-se a nova baseline.

11.2. Tarefas de Configuração de Software

O gerenciamento de configuração de software tem a responsabilidade do controle de mudança. O gerenciamento identifica os itens de configuração e as várias versões do software. Também audita os itens de configuração do software a fim de assegurar que os mesmos tenham sido propriamente desenvolvidos e que os relatórios de mudança sejam aplicados na configuração. Cinco tarefas são executadas: Identificação de mudança, controle de versão, controle de mudança, auditoria e relatório de configuração.

Identificação de MudançaÉ o processo de identificação de itens que alteram o processo de desenvolvimento de software. Tal processo identifica de forma específica os itens de configuração de software (ICS) e atribui um nome e identificador únicos.

Controle de VersãoÉ o conjunto de procedimentos e ferramentas utilizados para gerenciar as diferentes versões de objetos de configuração que são criados durante o processo de desenvolvimento de software. Uma versão é uma coleção de ICS que pode ser utilizada de forma quase independente.

Controle de MudançaConsiste em procedimentos manuais e ferramentas automatizadas que proporcionam o mecanismo para o controle de mudança. Tem o seguinte subconjunto de tarefas:

• Uma requisição de mudança é submetida e avaliada para estimar o mérito técnico, potenciais efeitos colaterais e impacto geral nos outros itens de configuração.

• Um relatório de mudança é criado para identificar a decisão final no status e prioridade da mudança.


SCI

Tarefas SE

Rev. TécnicaFormal

SCI SCIModificada

Extraído comControles SCM Deve ser

revisada

Nova Baseline

JEDITM

• Uma Ordem de Engenharia de Mudança (OEM) é criada para descrever a mudança a ser efetuada, as restrições e os critérios para revisão e auditoria.

• Os ICS são conferidos para modificação.

• É, então, verificado numa revisão posterior e passado ao controle de versão.

Auditoria de ConfiguraçãoÉ o processo de avaliar a ICS por características que geralmente não são consideradas durante um revisão técnica formal. Atende às seguintes questões:

• A mudança especificada na OEM foi efetuada? Existem modificações adicionais que foram executadas?

• A revisão técnica formal avaliou a correção técnica do produto?

• Os procedimentos de engenharia de software foram observados?

• Os procedimentos de GQS foram observados?

• Todos os ICSs foram apropriadamente atualizados?

Relatório InformativoÉ o processo de informar às pessoas que são afetadas pela mudança. Responde às seguintes questões:

• O que aconteceu?

• Quem fez?

• Quando aconteceu?

• O que mais será afetado?


JEDITM

12. Exercícios

O objetivo da tarefa é reforçar os conhecimentos e habilidades obtidas nesta lição.

1. Contacte outros alunos do JEDI e crie um grupo de trabalho.

2. Como exercício, o grupo deve criar o plano de projeto para seu projeto.



Lição 8Ferramentas de Desenvolvimento de Software


JEDITM

1. ObjetivosA implementação requer uma variedade de ferramentas. Assegurar que estejam disponíveis em versões compatíves e com licenças suficientes é parte do gerenciamento de projeto. Muitas dessas ferramentas foram construídas e implementadas para tornar o trabalho de engenharia de software mais fácil e organizado.


• Conhecer as diferentes ferramentas disponíveis no auxílio ao processo de desenvolvimento de software


JEDITM

2. Tipos de Ferramentas

2.1. Case

Ferramentas Computer-Aided Software Engineering (CASE) permitem que o analista crie modelos do sistema e do projeto. Existem hoje diversas ferramentas que dão suporte à Unified Modeling Language (UML). A principal característica é o repositório de projetos que permite a manutenção dos caminhos entre as descrições textuais e estruturais de todas as classes, atributos, operações, estados, etc, para a representação em diagramas.

Outras ferramentas CASE dão suporte a geradores de código. Isso assegura que a implementação reflita os diagramas construídos. Existem ferramentas que geram automaticamente o código em linguagem Java, Visual Basic, C++ e instruções SQL. Exemplos de ferramentas CASE são ArgoUML, JUDE, umlet, Rational Rose e Dia.

2.2. Compiladores, Interpretadores e Suporte à Execução

Todo código-fonte deve ser traduzido para um código que o computador possa entender. Em Java, o código-fonte é compilado para um formato de bytecode que é interpretado pela Java Virtual Machine (JVM). O ambiente é suportado pela maioria dos navegadores; isso quer dizer que é possível executar programas em Java utilizando simplesmente um navegador.

2.3. Editores Visuais

Criar interfaces gráficas para o usuário pode ser difícil quando feito manualmente. Editores Visuais permitem a criação dessas interfaces simplesmente arrastando e soltando componentes nos formulários e configurando os parâmetros que controlam sua aparência em uma janela de propriedades. NetBeans suporta esse tipo de edição visual.

2.4. Integrated Development Environment (IDE)

Integrated Development Environment (IDE) incorpora um editor multijanela, mecanismos para gerenciar arquivos que compoem os projetos, atalhos para compilar os códigos e um depurador para ajudar ao programador a localizar erros durante a execução do código. Alguns IDEs têm editores visuais. Esse tipo de ferramenta permite à engenharia de Software gerenciar os códigos-fontes em uma única interface e, ao mesmo tempo, testar e depurar. NetBeans é exemplo de uma IDE.

2.5. Gerenciamento de Configurações

Configuration Management Tools são ferramentas que dão suporte ao rastreamento de mudanças e dependências entre componentes e versões de códigos-fontes e arquivos-fontes que são usados para produzir um pacote de software. Esse tipo de ferramenta suporta o processo de gerenciamento de configuração de software. Um exemplo dessa ferramenta é o Concurrent Version System (CVS).

2.6. Ferramentas de Gerenciamento de Banco de Dados

Uma quantidade considerável de software é necessária para um sistema de gerenciamento de banco de dados de larga escala. Se o suporte para o modo de operação cliente-servidor é necessário, componentes separados de cliente e servidor devem ser instalados. Como quando o ODBC ou o JDBC é usado, bibliotecas especiais adicionais ou pacotes Java (DriverManager específico de um fornecedor) devem estar instalados ou disponíveis durante a execução. ObjectStore PSE Pro inclui um pós-processador que é usado para processar arquivos de classe Java para fazê-los persistentes.

2.7. Ferramentas de Teste

São ferramentas que identificam métodos de testes e geram casos de teste. Ferramentas de teste automático estão disponíveis para alguns ambientes como o suporte do NetBeans para o JUnit. O


JEDITM

que é mais desejável é que os programadores desenvolvam suas próprias ferramentas para testar classes e subsistemas.

2.8. Ferramentas de Instalação

Essas ferramentas permitem a criação de arquivos executáveis de instalação que quando são executados automatizam a criação de diretórios, extração de arquivos e a configuração de parâmetros ou entradas de registro.

2.9. Ferramentas para Conversão

Esse tipo de ferramenta é necessária quando um sistema existente precisa transferir seus dados para outro sistema. Hoje em dia, novos softwares substituem sistemas existentes. Pacotes como o Data Junction fornecem ferramentas automáticas para extrair dados de uma grande variedade de sistemas e os formata para um novo padrão.

2.10. Gerador de Documentação

Essas são ferramentas que permitem a geração de documentação técnica ou para o usuário. O Java tem o javadoc que processa os arquivos-fonte Java e gera documentação HTML no estilo da documentação API a partir de comentários especiais com tags embutidas no código fonte.

2.11. Software para Gerenciamento de Projeto

Ferramentas softwares para gerenciamento de projetos suportam o gerenciamento de projetos. Permitem que o gerente de projeto planeje a agenda do projeto, gerencie recursos, como tempo e pessoas, e acompanhe o progresso. MS Project é um exemplo dessa ferramenta.



Apêndice AInstalando o Java Studio Enterprise


JEDITM

1. Instalando o Java Studio Enterprise 8 em um ambiente Linux

1.1. Notas de pré-instalação

Collaboration Runtime

O Collaboration Runtime usa a porta 5222 por padrão. Se você tem o Java Studio Enterprise 7 Collaboration Runtime e quer usar ambos Java Studio Enterprise 7 e 8 Collaboration Runtimes ao mesmo tempo, inicie o Java Studio Enterprise 7 Collaboration Runtime antes de iniciar a instalação da versão 7 do IDE. Fazer isso assegura que o instalador use uma porta diferente para o Collaboration Runtime.

Arquivo de Log da Instalação e Diretório Temporário

Se você quer um arquivo de log para o relatório da instalação, você precisa iniciar o instalador de uma janela de terminal usando os seguintes comandos.

> cd /installer-location> ./jstudio_ent8_linux-jds.bin -is:log log-file-name

Se você quer especificar um diretório temporário para sua instalação, use os seguintes comandos na linha de diálogo do comando.

> cd /installer-location> ./jstudio_ent8_linux-jds.bin -is:tempdir temp-directory

1.2. Instalação do Software Java Studio Enterprise

Há duas formas de instalar o Software Java Studio Enterprise 8 na sua máquina Linux – por uma mídia ou um arquivo de download.

Instalação por uma Mídia

1. Insira a mídia Java Studio Enterprise 8 no seu drive CD/DVD.

2. Digite os seguintes comandos em uma janela de terminal:

> cd /media-drive/volume-label > ./installer.sh

3. Siga as instruções na subseção Próximos Passos da Instalação.

Instalação por arquivo de Download

1. Faça o Download do arquivo instalador do Java Studio Enterprise.

2. Digite os seguintes comandos em uma janela de terminal:

> chmod +x installer-label> ./installer-label

3. Siga as instruções na subseção Próximos Passos da Instalação.

1.3. Próximos Passos da Instalação

1. Selecione Next na página de boas vindas do wizard de instalação

2. Leia o acordo de licença e clique Next.

3. Para a página Select Features, use a seguinte tabela para guiá-lo na seleção de propriedades a instalar.

Se EntãoDeseja utilizar a instalação do Sun Java System Application Server 8.1 Platform Edition, Update

Desmarque o checkbox Sun Java(tm) System Application Server 8.1 PE UR2, e clique Next.


JEDITM

Se Então

Release 2 com a instalação do IDEForneça as informações necessárias sobre o seu servidor de aplicações na página Application Server Selection, e clique Next.

Não deseja instalar o Collaboration Runtime Desmarque o checkbox Collaboration Runtime, e clique Next.

Deseja instalar todas as propriedades Clique Next.

4. Escolha qual Java Development Kit (JDK) você quer usar para a instalação deste IDE na página do Java Development Kit Selection e clique Next.

5. Verifique as configurações na página Start Copying Files e clique Next para começar a instalação.

6. Marque o checkbox Start Sun Java(TM) Studio Enterprise 8 se você quiser lançar a IDE após a instalação wizard terminar.

7. Clique Finish.

Notas Pós-Instalação

A IDE instalada pode ser executada usando um comando digitado a ser executado em uma janela de terminal.

> cd /location-of-IDE-executable> ./runide.sh

Referência

http://docs.sun.com/source/819-2807/chap_linux_installing.html


http://docs.sun.com/source/819-2807/chap_linux_installing.html


Apêndice BSolução dos Exercícios


JEDITM

1. Lição 1 - Introdução à Engenharia de Software

Especificando Limites

1. Guia do Modelo de Limites para o Sistema de Informações de Treinadores

Entidades:

• Treinador fornecendo a informação

Atividades:

• Gerenciar Informações de Treinadores: Adicionar Registro de Treinador, Editar Registro de Treinador e Apagar Registro de Treinador

Saída:

• Lista das equipes do treinador

2. Guia do Modelo de Limites para o Sistema de Gerenciamento de Equipes e Esquadrões

Entidades:

• Treinador

• Equipe de Funcionários do Clube

Atividades:

• Criar Times

• Designar Treinadores

• Gerenciar Esquadrão de Competição

• Designar um atleta para uma equipe

• Promover um atleta

• Rebaixar um atleta

• Remover um atleta

• Gerenciar Esquadrão de Treinamento


• Mover um atleta para outra equipe


Saída:

• Listar Equipes do Esquadrão de Competição

• Listar Equipes do Esquadrão de Treinamento

• Listar Esquadrões Masculinos

• Listar Esquadrões Femininos

• Listar Número de Equipes por Esquadrão

• Listar o número de membros por equipe e Esquadrão

• Listar competições e lugares onde a equipe já jogou.

Praticando o Passo a Passo

1. Guia para a Lista de Ações

• Utilize o Modelo de Documento de Lista de Ações, dos Padrões de Documentação do Projeto JEDI, como um guia.

• Certifique-se que a descrição da ação seja escrita como um frase com verbo e sujeito, como por exemplo “adicionar entidade equipe de funcionários do clube ao modelo”.

• Certifique-se que as ações sejam designadas a uma pessoa e que seja definido um prazo de entrega.


JEDITM

2. Lição 3 – Engenharia de Software

Criando o Modelo de Requisitos

1. Guia do Modelo de Requisitos para o Sistema de Informações de Treinadores


Possíveis Atores:

• Treinador


Possíveis Casos de Uso:

• Gerenciar Registro de Treinador

• Adicionar Registro de Treinador

• Editar Registro de Treinador

• Apagar Registro de Treinador

• Listar as Equipes do Treinador

• Especificações do Caso de Uso

Possíveis Cenários para Gravação de Registro de Treinador:

• Informações do Treinador Incompletas

• Decidir o que ocorre com as demais informações que serão afetadas quando um registro de treinador for removido do sistema

2. Guia do Modelo de Requisitos do Sistema de Gerenciamento de Equipes e Esquadrões


Possíveis Atores:

• Treinador

• Comitê de Seleção


Possíveis Casos de Uso:

• Criar Equipes para um Esquadrão

• Designar Treinador para a Equipe

• Produzir as seguintes listas:

• Equipes de Competição

• Equipes de Treinamento

• Esquadrões Masculinos

• Esquadrões Femininos

• Número de equipes por Esquadrão

• Número de membros por equipe e Esquadrão

• Mover um atleta de um esquadrão de treinamento para um esquadrão de competição

• Gerenciar Esquadrão de Competição


• Promover um atleta

• Rebaixar um atleta


• Listar Competições


JEDITM

• Gerenciar Esquadrão de Treinamento


• Mover um atleta de uma equipe para outra equipe

• Remover um atleta de uma equipe

Criando o Modelo de Análise

1. Guia do Modelo de Análise para o Sistema de Informações de Treinadores

Possíves Classes Limite:

• CoachInformationForm

• ListTeamForm

Possíveis Classes de Controle:

• MaintainCoachInformationController

• AddCoachRecord

• EditCoachRecord

• DeleteCoachRecord

• ListTeamController

Possíveis Classes de Entidade:

• Treinador

• Equipe

2. Modelo de Análise do Gerenciamento de Esquadrões e Equipe

Possíveis Classes de limite:

• FormularioManutencaoEsquadrao

• FormularioManutencaoEquipe

• FormularioManutencaoRelatorio

Possíveis Classes de controle:

• ControladorManutencaoEsquadrao

• Colocar um Atleta em um Esquadrão

• Mover um Atleta do Esquadrão de Treinamento para o Esquadrão de Competição

• Manter o Esquadrão de Competição

• Criar equipes com Nível

• Editar equipes com Nível

• Designar um Atleta a uma Equipe

• Promover um Atleta

• Rebaixar um Atleta

• Remover um Atleta

• Manutencao do Esquadrão de Treinamento

• Criar equipes

• Editar equipes

• Designar um Atleta a uma equipe

• Mover um Atleta para outra Equipe

• Remover um Atleta

• Gerar Relatórios e Listagens


JEDITM

• Listar Equipes do Esquadrão de Competição

• Listar Equipes do Esquadrão de Treinamento

• Listar Esquadrões e Equipes Masculinas

• Listar Esquadrões e Equipes Femininas

• Listar Número de Equipes por Esquadrões

• Listar Número de Atletas por Equipe e Esquadrão

Possíveis Classes de Entidade:

• Treinador

• Esquadrao

• Equipe

• Atleta

• Equipe

• Serie de Equipe

• Esporte

• Posição


JEDITM

3. Lição 4 – Engenharia de Projeto

Criando o Modelo de Projeto de Dados

1. Orientações sobre o Modelo de Projeto de Dados do Sistema de Informações de Treinadores

Possíveis Classes Persistentes:

• DBTreinador, PCLTreinador, PCTreinador

• DBListaEquipeTreinador, PCLEquipe, PCEquipe

2. Orientações sobre o Modelo de Projeto de Dados do Sistema de Gerenciamento de Equipes e Esquadrões.

Possíveis Classes Persistentes:

• DBEsquadrao, PCLEsquadrao, PCEsquadrao

• DBEquipe, PCLEquipe, PCEquipe

• DBDesignacaoEquipe, PCLAtletaEquipe, PCAtletaEquipe

• DBDesignacaoEsquadrao, PCAtletaEsquadrao, PCAtletaEsquadrao

Criando o Projeto de Interface

1. Orientações sobre o Projeto de Layout do Relatório

• Lista de Membros por Status

• Decidir detalhes tais como status, numero do membro, nome do Atleta

• Decidir agrupamentos:

• Agrupar por Esquadrão e status

• Agrupar por status e Esquadrão

• Decidir a ordem

• Ordenar alfabeticamente pelo sobrenome por esquadrão

• Lista de Membros que vão sair ou graduar-se no próximo ano

• Decidir detalhes tais como número do membro, nome do atleta, aniversário

• Decidir a ordem

• Ordenar alfabeticamente pelo sobrenome

• Ordenar por Aniversário

• Lista de Membros que ainda não pagaram a taxa de renovação

• Decidir detalhes tais como número do membro, nome do atleta, status

• Decidir a ordem

• Ordenar alfabeticamente pelo sobrenome

2. Orientações para o Revisão do Projeto do formulário de aplicação

• Dados relacionados a aplicação tais como:

• Número da Aplicação

• Data da Aplicação

• Pagamento da taxa de Aplicação, que inclui:

• Número do Recibo oficial

• Data de Pagamento

• Informacões Adicionais do Atleta


JEDITM

• Telefone

• Sexo

• Esportes preferidos e posições

• Informações do Guardião

• Nome do Guardião

• Endereço

• Telefone

3. Orientações do Revisão do Projeto da Tela do Atleta

• Verifique o projeto de banco de dados para mais detalhes do formato

• Incluir o seguinte:

• Dados relacionados à aplicação

• Número da Aplicação (campo texto)

• Data da Aplicação (campo texto)

• Dados Adicionais do Atleta

• Sexo (botões radio ou listas drop-down)

• Status (lista drop-down)

• Nível de habilidade (lista drop-down)

• Dados do Guardião

• Nome (campo texto)

• Telefone (campo texto)

• Endereço (campo texto)

• Modificação dos seguintes campos:

• Esportes e Posições

• Deve estar apto a receber múltiplas entradas.

• Possível uso de um list box ou combo box.

• Remover campo:

• Ano do último pagamento de inscrição

• Adicionar um botão para ir a função “Achar Atleta ou Aplicação”. Neste caso, outra janela e layout de diálogo deverá ser feito para essa função.

4. Orientações sobre o projeto da janela e sobre o projeto do diálogo do Sistema de Informações de Treinadores

Para o FormularioTreinador:

• Incluir os seguintes campos de dados; verifique o design de banco de dados para mais detalhes:

• ID do Treinador

• Nome do Treinador

• Endereço do Treinador

• Número SSS

• Telefone

• Email

• Celular


JEDITM

• Incluir os seguintes botões:

• Salvar

• Deletar

• Cancelar

• Encontrar Treinador

Par o FormularioListaTime:

• Decidir o critério utilizado para listar as Equipes, tais como:

• ID do Treinador (lista drop-down ou campo texto)

• Nome do Treinador (campos texto)

• Decidir os detalhes a serem mostrados, tais como:

• Código da Equipe

• Nome do Time

• Tipo do Esquadrão

5. Orientações sobre projeto da janela e sobre o projeto do diálogo do Sistema de Gerenciamento de Equipes e Esquadrões

• Usar os protótipos de tela especificados na Figura 9 . Dinâmica de Designação da Equipe no estudo de casos, Ang Bulilit Liga.

Para o MaintainSquadForm(Manutenção do formulário esquadrão):

• Lista de treinamento esquadrão. (window list)

• Lista de competição esquadrão. (window list)

• Permitir o arraste do nome do atleta do esquadrão de treinamento para o esquadrão de competição

• Salvar a lista atual esquadrão. (através de um menu option ou um botão em algum lugar)

• Desfazer as mudanças feitas na lista esquadrão. ( através de um menu option ou um botão em algum lugar)

Para o MaintainTeamForm (Manutenção do formulário):

• Lista de Times (window list)

• Permitir o arraste do nome do atleta do esquadrão para o Times

• Permitir o arraste do nome do atleta do esquadrão para o Times

• Permitir o arraste do nome do atleta do esquadrão para o esquadrão

• Salvar a lista atual esquadrão. (através de um menu option ou um botão em algum lugar)

• Desfazer as mudanças feitas nas listas Times (através de um menu option ou um botão em algum lugar)

Para a GenerateReportForm(Geração do formulário):

Para cada relatório, decidir no seguinte:

• Critérios da lista

• Detalhes a serem impressos

• agrupamentos

• ordem

Criando o Design de Controle

1. Controle do design de classes do sistema de dicas de informação treinador.

Para a MaintainCoachInformationController(Manutenção do controlador de informações do treinador:


JEDITM

• Assegurar que as seguintes funcionalidades sejam apresentadas:

• Adicionar registro de treinador

• Editar um registro de treinador

• Apagar um registro de treinador

Para o ListTeamController(Controlador de lista Times):

• Assegurar que o sistema de listas de times seja atribuído ao treinador. Pesquisa por critérios pode ser baseada em:

• especificando o TreinadorID(CoachID)

• Especificando o nome do treinador

• TODOS

2. Controle de classes de Esquadrão & Manutenção do guia de Times

É possível que se tenha vários controladores de classes para este sub-sistema.

Para o MaintainSquadController(Controlador de manutenção Esquadrão):

• Assegurar de que as seguintes funcionalidades serão apresentadas:

• Trocar um atleta para um esquadrão.

• Mudar um atleta do esquadrão de treinamento para o esquadrão de competições.

Para o MaintainCompetingSquadController(Controlador de competições esquadrão):

• Assegurar de que as seguintes funcionalidades serão apresentadas:

• Criação de times com notas que incluam identificadores de membros e posições em que estão jogando, e o treinador designado para os mesmos.

• Editar times com notas que incluam possíveis mudanças de membros e posições em que estão jogando, e o treinador designado para o mesmo.

• Promover um atleta.

• Desqualificar um atleta.

• Remover um atleta de um time e colocá-lo num esquadrão.

Para o MaintainTrainingSquadController(Controlador de treinamento do esquadrão):• Assegurar de que as seguintes funcionalidades serão apresentadas:

• Criação de times com notas que incluam identificadores de membros e posições em que estão jogando, e o treinador designado para os mesmos.

• Editar times com notas que incluam possíveis mudanças de membros e posições em que estão jogando, e o treinador designado para o mesmo.

• Mover um atleta de um time para outro.• Remover um atleta de um time e retorná-lo para o esquadrão.

Guia de design de componentes

• Usar o diagrama de pacotes para mostrar os componentes do sistema.

• Assegurar de que as seguintes funcionalidades serão representadas como parte de um componente.

• Manter informação dos treinadores

• Manter Esquadrões• Manter Times


JEDITM

4. Lição 5 – Implementação

Definição para a formatação da documentação interna

1. Comentário para cabeçalho. Assegurar de que as seguintes funcionalidades serão apresentadas.

• Nome do componente• Autor do componente • Data da criação ou ultima modificação do componente • Lugar onde o componente se enquadra no sistema geral• Detalhes da estrutura dos dados,algoritmos e fluxo de controle• Para o histórico de revisão:

• Quem modificou o componente?• Quando o componente foi modificado?• Qual foi a modificação feita no componente?

2. Dicas de implementação

• Implenetar RegistroAtletaUI, EncontrarRegistroAtletaUI e ListaAtletaUI. Use o protótipo de tela como guia.

• Implementar EncontrarRegistroAtleta(controlador) com message dialog boxes para que os métodos que necessitem acessar objetos de persistência ou da camada do Banco de Dados.

• Assegurar que a definição de comentário de cabeçalho está presente no código.

• Tentar integrar todos os usuários da interface gráfica com seus correspondentes controladores.


JEDITM

5. Lição 6 – Teste de Software

Especificando um teste case

1. Caso de teste para procura de registro de atletas

Possíveis direções:

• Recuperação com sucesso de um único atleta da base de dados.

• Recuperação com sucesso de mais de um atleta da base de dados.

• Um registro não existente de um atleta.

• Base de dados não está acessível.

Especificando as especificações de teste

1. Especificação de teste para o sistema de informação dos treinadores

Faça uso de uma boa estratégia de teste na especificação dos testes para o sistema de informação dos treinadores. A seguir temos a sugestão de um teste de fluxo:

• Classes de teste de persistência

• Classes de teste da base de dados

• Teste de persistência com a classe de teste da base de dados

• Teste usuário-interface

• Teste das classes de controle

• Teste de usuário-interface com o teste classe e teste de controle

• TESTE TUDO.

O grupo que estará testando os programas podem precisar de criar classes do topo e dirigentes.

2. Especificação de testes para o Sistema de manutenção de Esquadrões e Times

Faça uso de uma boa estratégia de teste na especificação dos testes para o sistema de informação dos treinadores. A seguir temos a sugestão de um teste de fluxo:

• Classes de teste de persistência

• Classes de teste da base de dados

• Teste de persistência com a classe de teste da base de dados

• Teste usuário-interface

• Teste das classes de controle

• Teste de usuário-interface com o teste classe e teste de controle

• TESTE TUDO.

O grupo que estará testando os programas podem precisar de criar classes do topo e dirigentes.


JEDITM

Parceiros que tornaram JEDITM possível

Instituto CTSPatrocinador do DFJUG.

Sun MicrosystemsFornecimento de servidor de dados para o armazenamento dos vídeo-aulas.

Java Research and Development Center da Universidade das FilipinasCriador da Iniciativa JEDITM.

DFJUGDetentor dos direitos do JEDITM nos países de língua portuguesa.

Banco do BrasilDisponibilização de seus telecentros para abrigar e difundir a Iniciativa JEDITM.

PolitecSuporte e apoio financeiro e logístico a todo o processo.

BorlandApoio internacional para que possamos alcançar os outros países de língua portuguesa.

Instituto Gaudium/CNBBFornecimento da sua infra-estrutura de hardware de seus servidores para que os milhares de alunos possam acessar o material do curso simultaneamente.


projeto jedi - engenharia de software - java - 264 páginas

Documents