Algoritmos e Programação, Notas de estudo de Algoritmos e Programação

Baixe Algoritmos e Programação e outras Notas de estudo em PDF para Algoritmos e Programação, somente na Docsity!

U A P IU A P I

Bacharelado em Sistemas de Informação

Módulo II

Organização de Sistema Metodológico

Algoritmos e Programação II

PRESIDENTE DA REPÚBLICA Luiz Inácio Lula da Silva

MINISTRO DA EDUCAÇÃO Fernando Haddad

GOVERNADOR DO ESTADO Wellington Dias

REITOR DA UNIVERSIDADE FEDERAL DO PIAUÍ Luiz de Sousa Santos Júnior

SECRETÁRIO DE EDUCAÇÃO A DISTÂNCIA DO MEC Carlos Eduardo Bielschowsky

COORDENADORIA GERAL DA UNIVERSIDADE ABERTA DO BRASIL Celso Costa

SECRETÁRIO DE EDUCAÇÃO DO ESTADO DO PIAUÍ Antonio José Medeiros

COORDENADOR GERAL DO CENTRO DE EDUCAÇÃO ABERTA A DISTÂNCIA DA UFPI Gildásio Guedes Fernandes

SUPERITENDÊNTE DE EDUCAÇÃO SUPERIOR NO ESTADO Eliane Mendonça

DIRETOR DO CENTRO DE CIÊNCIAS HUMANAS E LETRAS Antônio Fonseca dos Santos Neto

COORDENADOR DO CUSO DE ADMINISTRAÇÃO A DISTÂNCIA Francisco Pereira da Silva Filho

COODENADORA DE MATERIAL DIDÁTICO DO CEAD/UFPI Cleidinalva Maria Barbosa Oliveira

DIAGRAMAÇÃO Emanuel Alcântara da Silva

B726c SANTOS, Magno Alves Algoritmos e Programação II / Magno Alves dos Santos Teresina: UFPI/UAPI

Inclui bibliografia

1 Algoritmo. 2 Linguagem Java, 3 Programação Orientada a Objetos. I. Universidade Federal do Piauí/Universidade Aberta do Piauí. II. Título.

CDU: 32

Sumário Geral

Unidade 1

A sociologia e a Sociologia

da Educação

A sociologia e a Sociologia

da Educação

Unidade 1

Unidade 1

Resumo

Unidade 1

Esta unidade tem como meta apresentar uma visão

geral sobre os elementos conceituais da programação

orientada a objetos. São abordados os fundamentos

da engenharia de software e da programação de

computadores. A anatomia de um programa em Java

é apresentada com suas características e funções

onde se deve aprender a criar, editar, compilar e

executar um dos primeiro programa em Java. Como

objetivo principal, esta unidade ensina, a gerar um

código simples dentro dos padrões mínimos exigido

pela engenharia software.

Fundamentos de

Programação Orientada

a Objetos

Fundamentos de

Programação Orientada

a Objetos

UNIDADE 1. FUNDAMENTOS DE PROGRAMAÇÃO

• ORIENTADA A OBJETOS UNIDADE 1. FUNDAMENTOS DE PROGRAMAÇÃO
• 01 – Introdução à engenharia de software
• 02 – Introdução à programação de computadores
• 03 – Histórico da Linguagem Java
• 04 - Instalação do Java e do NetBeans
• 05 – Primeiro Programa Java com a IDE NetBeans
• 06 – Entrada e Saída de Dados
• UNIDADE 2. ESTRUTURAS DE CONTROLE
• 07 – Estruturas de Decisão: if-then-else, switch
• 08 – Estruturas de Repetição: while, do-while, for
• 09 – Estruturas de Interrupção: break, continue, return
• UNIDADE 3. ARRANJOS E ARGUMENTOS
• 10 – Arranjos em Java
• 11 – Argumentos em Java
  • ORIENTADA A OBJETOS UNIDADE 4. PARADIGMA DE PROGRAMAÇÃO
• 12 – Classes, Objetos e Métodos
• 13 – Definição de Classe em Java
• 14 – Herança, Polimorfismo e Interface
• 15 – Tratamento e Exceções em Java
• A01 - EXERCÍCIOS ADICIONAIS APÊNDICES:
• A02 – PLANO DE ENSINO
• A03 - AGENDA DE ATIVIDADES
• REFERÊNCIAS BIBLIOGRÁFICAS
• ORIENTADA A OBJETOS
• 01 – Introdução à engenharia de software
• 02 – Introdução à programação de computadores
• 03 – Histórico da Linguagem Java
• 04 - Instalação do Java e do NetBeans
• 05 – Primeiro Programa Java com a IDE NetBeans
• 06 – Entrada e Saída de Dados

1.1.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*

Metodologias Orientadas a Objeto:

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

1.1.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)

1.2. 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.

1.2.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.

1.2.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ócios.

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.

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.

1.3. 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.

1.3.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.

1.3.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.

1.3.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:

• 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

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 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.

1.3.5. 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

8216

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.
• 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.

1.3.6. 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

17

apresentadas na lista de ações. o Possivelmente, um outro walkthrough deve ser agendado.

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

1.4.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.

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.
• 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.

Exercícios:

1. Discuta a visão em camadas tendo em vista no gerenciamento e desenvolvimento do software.
2. Qualidade do software é a característica para satisfazer necessidades declaradas e implícitas do contratante. Como mensurar estas características que do modo que possa ser comparada a padrões conhecidos?
3. Pesquisa na Internet exemplos de documentação de software como: a) Manual do Usuário, b) Manual de Administração do Sistema, c) Vídeo, Multimídia, Tutoriais, d) Demonstrações, e) Arquivos de Manutenção do Sistema, f) Manual de Operações/Operador, g) Help ON-Line, Wall Charts.
4. Apresente um algoritmo (em fluxograma ou em passos lógicos) do fluxo de desenvolvimento do software. Apresente as fases e atividades importantes para garantir a qualidade do software.