P. 1
Portfólio Individual 2° Período de Análise de Sistemas - UNOPAR / 2011 - Adson Honori

Portfólio Individual 2° Período de Análise de Sistemas - UNOPAR / 2011 - Adson Honori

|Views: 7.961|Likes:
Publicado poradsonhonori
Portfólio Individual 2° Período de Análise de Sistemas - UNOPAR / 2011 - Adson Honori
Portfólio Individual 2° Período de Análise de Sistemas - UNOPAR / 2011 - Adson Honori

More info:

Categories:Types, School Work
Published by: adsonhonori on Mar 23, 2012
Direitos Autorais:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

05/13/2014

pdf

text

original

SISTEMA DE ENSINO PRESENCIAL CONECTADO ANÁLISE DE DESENVOLVIMENTO DE SISTEMAS ADSON JOSÉ HONORI DE MELO

Utilizando Casos de Uso, entendendo o Modelo EntidadeRelacionamento e aprofundando nos conceitos de Métodos Ágeis e Evolucionários de desenvolvimento de software.

Palmas 2011

ADSON JOSÉ HONORI DE MELO

Utilizando Casos de Uso, entendendo o Modelo EntidadeRelacionamento e aprofundando nos conceitos de Métodos Ágeis e Evolucionários de desenvolvimento de software.

Trabalho apresentado as disciplinas de Análise de Sistemas I, Engenharia de Software, Banco de Dados I, Linguagem e Tec. de Programação II e Seminários II da Universidade Norte do Paraná - UNOPAR Prof(s). : Polyanna Gomes Roberto Y. Nishimura Luís Claudio Perini Anderson Gonçalves

Palmas 2011

SUMÁRIO
1 2 2.1 2.2 2.2.1 2.2.2 2.2.3 2.2.3.1 2.2.3.2 2.2.3.3 2.2.3.4 2.2.3.5 2.2.4 2.2.4.1 2.2.4.2 2.2.4.3 2.2.4.3.1 2.2.4.3.2 2.2.5 2.3 2.3.1 2.3.2 2.3.3 2.3.4 2.3.5 2.4 2.4.1 2.4.2 2.4.3 2.4.4 2.4.5 2.5 2.5.1 2.5.2 2.5.3 2.5.3.1 3 INTRODUÇÃO ....................................................................................................................3 DESENVOLVIMENTO ........................................................................................................4 CASO DE USO – CONTROLAR USUÁRIO ......................................................................4 TÉCNICA DE MODELAGEM ENTIDADE E RELACIONAMENTO (MER) ........................7 CONCEITOS BÁSICOS DE MODELAGEM DE DADOS ...................................................7 ENTIDADES .......................................................................................................................9 ATRIBUTOS .......................................................................................................................9 COMPOSTOS E SIMPLES (ATÔMICOS)....................................................................... 10 MONOVALORADOS E MULTIVALORADOS ................................................................. 10 ARMAZENADOS E DERIVADOS ................................................................................... 10 VALORES NULLS (NULOS) ........................................................................................... 10 COMPLEXOS .................................................................................................................. 11 RELACIONAMENTOS E CARDINALIDADE ................................................................... 11 GRAU DE RELACIONAMENTO ..................................................................................... 11 NOMES DE PAPÉIS E RELACIONAMENTO RECURSIVO........................................... 12 CARDINALIDADE............................................................................................................ 13 RAZÕES DE CARDINALIDADE PARA RELACIONAMENTOS BINÁRIOS ................... 13 RESTRIÇÕES DE PARTICIPAÇÃO E DEPENDÊNCIAS DE EXISTÊNCIA .................. 14 ADMINISTRADOR DE DADOS ....................................................................................... 14 MÉTODOS ÁGEIS DE DESENVOLVIMENTO DE SOFTWARE .................................... 15 EXTREME PROGRAMMING OU XP .............................................................................. 15 SCRUM ............................................................................................................................ 18 FEATURE DRIVEN DEVELOPMENT – FDD.................................................................. 20 RATIONAL UNIFIED PROCESS – RUP ......................................................................... 21 METODOLOGIA DE DESENVOLVIMENTO DE SISTEMAS DINÂMICOS –DSDM ...... 23 MODELO EVOLUCIONÁRIO PARA DESENVOLVIMENTO DE SOFTWARE .............. 25 MODELO DE PROTOTIPAGEM ..................................................................................... 25 MODELO ESPIRAL ......................................................................................................... 26 MODELO INCREMENTAL E ITERATIVO ....................................................................... 28 DESENVOLVIMENTO BASEADO EM COMPONENTES – CBD ................................... 29 MODELO CONCORRENTE ............................................................................................ 30 DESENVOLVENDO EM .NET E C#................................................................................ 31 CONCEITOS ................................................................................................................... 31 PRINCIPAIS BENEFÍCIOS E CARACTERÍSTICAS ....................................................... 31 CENÁRIO DE ESTUDO – CONTROLAR DVD ............................................................... 32 COMPONENTES UTILIZADOS ...................................................................................... 33 CONCLUSÃO .................................................................................................................. 35

REFERÊNCIAS ..................................................................................................................................... 36

3

1 INTRODUÇÃO A tarefa de programar é legal e empolgante, mas desenvolver um software de qualidade é um desafio complexo e difícil. Entre a paixão pela programação, requisitos, boas idéias e um software de excelência, existem muito mais do que apenas códigos e sintaxes. Analisar e projetar, solucionar os problemas, dar características de fácil comunicação, revisão, implementação e evolução aos projetos de software é que realmente faz do Analista de Sistemas, figura ímpar no meio da tecnologia da informação. Segundo Larman (2007, p. 29), “A análise enfatiza uma investigação do problema e dos requisitos, em vez de uma solução. Por exemplo, se desejamos um novo sistema online de comercialização, como ele será usado? Quais as suas funções?”

Nesse sentido, a engenharia de software cuida da engenharia relacionada com todos os aspectos da criação de soluções de software computacional, desde o levantamento de requisitos até a manutenção do mesmo. Ela não aborda apenas questões técnicas, e sim, aspectos relacionados com gerência, teorias e métodos que venham a apoiar sua produção.

Os bancos de dados tão essenciais no cotidiano da sociedade moderna, representam aspectos do mundo real. São constituídos por uma coleção lógica e coerente de dados com algum significado inerente. É parte importante das grandes soluções de software em geral.

Portanto, neste trabalho, abordaremos a resolução de problemas específicos, sempre nos pautando e orientando pelos conceitos e técnicas expostos acima.

4

2 DESENVOLVIMENTO

2.1 CASO DE USO – CONTROLAR USUÁRIO Casos de Uso, são narrativas em texto, amplamente utilizadas para levantar os requisitos de determinada solução de software. Descreve a

funcionalidade específica que um sistema, supostamente, deve desempenhar ou exibir, por meio da modelagem do diálogo que um usuário, um sistema externo ou outra entidade terá com o sistema desenvolvido. Pode também ser representado por um diagrama que utilize os conceitos da UML.

Cenário (Controlar usuário): O Aluno chega à biblioteca e solicita o cadastramento. O bibliotecário solicita a documentação para cadastro e começa a alimentar o sistema com os dados obrigatórios. O sistema checa pendências anteriores. Sistema efetua o cadastro. Bibliotecário solicita impressão em duas vias. O aluno assina uma via e o bibliotecário deve digitalizar e arquivar no sistema. O sistema deve oferecer as funcionalidades de consulta, edição, bloqueio e exclusão de dados cadastrais.

Nome do Caso de Uso Atores envolvidos Interessados e interesses Pré-condição Pós-condição

Controlar Usuário 1 – Bibliotecário 1 – Aluno: deseja cadastrar-se de forma rápida e eficiente; 2 – Bibliotecário: deseja ter controle total sobre o processo de cadastramento e gerenciamento de cadastrados. Bibliotecário autenticado no sistema. Aluno cadastrado com todos os dados obrigatórios, biblioteca com controle total da situação cadastral.

A) Fluxo de sucesso principal CADASTRAR: 1 – o bibliotecário pede novo cadastro, após checar documentos obrigatórios; 2 – o sistema solicita entrada de dados (CPF); 3 – [EV] o sistema checa, através do CPF, base de dados interna de outro programa à procura de pendências; 4 – o sistema solicita entrada de mais dados (nome, endereço, RG, nº de matrícula, curso, email); 5 – o sistema valida e confirma o cadastramento;

5

6 – o bibliotecário gera e imprimi, em duas vias, o protocolo da operação; 7 – o aluno assina e entrega uma via ao bibliotecário; 8 - o bibliotecário digitaliza e arquiva esta via como imagem no sistema.

Fluxo de exceções CADASTRAR: 3a – aluno com pendências na biblioteca: 3a.1 – sistema avisa que existem pendências na biblioteca; 3a.2 – bibliotecário solicita impressão das pendências; 3a.3 – sistema gera relatório e imprimi. 3a.4 – sistema salva estado do cadastro até que pendência seja resolvida.

B) Fluxo de sucesso principal CONSULTAR/EDITAR: 1 – o bibliotecário inicia a consulta; 2 – o bibliotecário entra com NOME ou CPF; 3 – [EV] o sistema procura o registro; 4 – o bibliotecário seleciona o registro; 5 – o sistema carrega na tela os dados; 6 – o bibliotecário edita as informações; 7 – o sistema grava.

Fluxo de exceções CONSULTAR/EDITAR: 3a – não cadastrado: 3a.1 – sistema avisa que não há registro de cadastro; 3a.2 – sistema pergunta se deseja cadastrar; 3a.3 – sistema chama módulo de cadastro;

C) Fluxo de sucesso principal CONSULTAR/EXCLUIR: 1 – o bibliotecário inicia a consulta; 2 – o bibliotecário entra com NOME ou CPF; 3 – [EV] o sistema procura o registro; 4 – o bibliotecário seleciona o registro; 5 – o sistema carrega na tela os dados; 6 – o bibliotecário solicita exclusão; 7 – o sistema pede confirmação para exclusão;

6

7 – o bibliotecário confirma; 8 – o sistema realiza a exclusão.

Fluxo de exceções CONSULTAR/EXCLUIR: 3a – não cadastrado: 3a.1 – sistema avisa que não há registro de cadastro; 3a.2 – sistema pergunta se deseja cadastrar; 3a.3 – sistema chama módulo de cadastro;

D) Fluxo de sucesso principal CONSULTAR/BLOQUEAR: 1 – o bibliotecário inicia a consulta; 2 – o bibliotecário entra com NOME ou CPF; 3 – [EV] o sistema procura o registro; 4 – o bibliotecário seleciona o registro; 5 – o sistema carrega na tela os dados; 6 – o bibliotecário solicita bloqueio; 7 – o sistema solicita o motivo; 7 – o bibliotecário informa e confirma bloqueio; 8 – o sistema realiza o bloqueio.

Fluxo de exceções CONSULTAR/ BLOQUEAR: 3a – registro não encontrado: 3a.1 – sistema avisa que não há registro de cadastro; 3a.2 – sistema pergunta se deseja cadastrar; 3a.3 – sistema chama módulo de cadastro;

7

Diagrama UML do Caso de Uso:

Figura 1 – Diagrama caso de uso - UML Ferramenta Astah (antigo JUDE)

2.2 TÉCNICA DE MODELAGEM ENTIDADE E RELACIONAMENTO (MER) É sem dúvida alguma, a técnica de modelagem mais difundida. Ela permite fazer um modelo conceitual dos dados do mundo real que estamos analisando. Seu criador, Peter Chen, elaborou a técnica no ano de 1976, que foi adaptada positivamente ao passar dos anos. O MER (Modelo EntidadeRelacionamento), baseia-se na idéia de que o mundo real consiste de entidades e de relacionamentos entre essas entidades. 2.2.1 CONCEITOS BÁSICOS DE MODELAGEM DE DADOS Quando pretendemos desenvolver aplicações que usam banco de dados relacionais devemos possuir os conceitos básicos sobre modelagem de dados. Não importa se a aplicação é muito simples; a correta modelagem dos seus

8

dados irá com certeza tornar sua aplicação mais robusta e mais fácil de manter. Os objetivos principais da modelagem de dados são: a) Representar o ambiente observado; b) Documentar e normalizar; c) Fornecer processos de validação; d) Observar processos de relacionamentos entre objetos.

Modelar implica em construir. Podemos definir as etapas envolvidas na construção de modelos em :

1 - Modelo conceitual - Representa as regras de negócio sem limitações tecnológicas ou de implementação, por isto é a etapa mais adequada para o envolvimento do usuário que não precisa ter conhecimentos técnicos. Neste modelo temos : a) Visão Geral do negócio; b) Facilitação do entendimento entre usuários e desenvolvedores; c) Possui somente as entidades e atributos principais; d) Pode conter relacionamentos n para m. 2 - Modelo Lógico – Abordam limites impostos por algum tipo de tecnologia de banco de dados (banco de dados hierárquico, banco de dados relacional ,etc.). Suas características são : a) Deriva do modelo conceitual e via a representação do negócio; b) Possui entidades associativas em lugar de relacionamentos n:m; c) Define as chaves primárias das entidades; d) Normalização até a 3ª forma normal; e) Adequação ao padrão de nomenclatura; f) Entidades e atributos documentados.

3 - Modelo Físico - Leva em consideração limites impostos pelo SGBD (Sistema Gerenciador de Banco de dados) e pelos requisitos não funcionais dos programas que acessam os dados. Características: a) Elaborado a partir do modelo lógico;

9

b) Pode variar segundo o SGBD; c) Pode ter tabelas físicas (log , lider , etc.); d) Pode ter colunas físicas (replicação). 2.2.2 ENTIDADES São representações abstratas de alguma coisa do mundo real. Por exemplo: a placa de um carro, o número de um pedido num restaurante, o José Ribamar funcionário da empresa, a disciplina de Ciências de uma escola, todos são entidades, que podem ser concretas, conceituais, fatos e etc.

Ao agrupamento de entidades afins, damos o nome de Conjunto de Entidades. Por exemplo: todos os veículos ou todos os funcionários da empresa. É muito importante saber que no MER, só se representam os Conjuntos de Entidades e nunca entidades individuais. Ainda, só merecem representação os conjuntos de entidades do mundo real que contenham dados de interessa da organização.

Durante o processo de modelagem costuma-se conceituar cada conjunto de entidades de modo a definir claramente todas as entidades que possam pertencer àquele conjunto. Exemplo: Veículo: conjunto que engloba todos os meios de transporte de propriedade da empresa. 2.2.3 ATRIBUTOS Para cada conjunto de entidades do modelo, guardam-se algumas informações pertinentes relacionadas aos seus elementos. Isto é feito através dos atributos. Exemplo: Veículo = (Placa + Marca + Cor + Data-aquisição + Quilometragem) ou Aluno = (Matrícula + Nome do Aluno + Data da Matrícula).

Nomes de atributos são diferentes de valores de atributos, por exemplo, Marca, é o nome, enquanto Ford, GM ou Fiat, são os valores do atributo.

Um atributo só pode aparecer numa única entidade do modelo. Todavia, nada impede que atributos de entidades diferentes tenham mesmo nome,

10

embora representando informações diferentes. Por exemplo, o atributo Nome pode aparecer na entidade Cliente onde ele indica nome do cliente, e pode também estar na entidade Funcionário, onde ele significa nome do funcionário. 2.2.3.1 COMPOSTOS E SIMPLES (ATÔMICOS) Atributos compostos podem ser divididos em subpartes menores, que representam a maioria de atributos básicos com significados diferentes. Por exemplo, em uma entidade empregado, temos um atributo endereço que pode ser subdividido em EnderecoRua, Cidade, Estado, CEP. Os atributos que não permitem subdivisões são conhecidos como atributos Simples ou Atômicos. Os atributos compostos podem formar uma hierarquia, exemplo: EnderecoRua, pode ser subdividido em três atributos simples (Rua, Número e Apartamento). 2.2.3.2 MONOVALORADOS E MULTIVALORADOS A maioria dos atributos tem um valor único para uma determinada entidade, são denominados monovalorados. Exemplo: Idade é um atributo monovalorado de uma pessoa. Atributos multivalorados são aqueles que têm mais de um valor. Exemplo: Titulação, pois uma pessoa pode ser graduada em dois ou mais cursos. Atributos multivalorados devem ter limite inferior e superior para restringir o número de valores permitidos a cada entidade individual. 2.2.3.3 ARMAZENADOS E DERIVADOS É a relação entre dois ou mais atributos. Exemplo: os atributos Idade e DataNascimento de uma pessoa. Para uma entidade pessoa em particular, o valor de idade pode ser determinado pela data corrente (hoje) e o valor de DataNascimento da pessoa. Assim, o atributo Idade é considerado derivado do atributo DataNascimento, que, por sua vez, é chamado de atributo armazenado. 2.2.3.4 VALORES NULLS (NULOS) Algumas situações apresentam entidades em que não se pode aplicar valores a um determinado atributo. Exemplo: Apartamento é um atributo que

11

só terá um valor se o endereço for de um edifício. Ou ainda, o atributo Titulação só aceitará valores de pessoas que possuam graduação acadêmica. 2.2.3.5 COMPLEXOS Atributos compostos e multivalorados poder ser aninhados de uma forma arbitrária. Representa-se essa organização arbitrária agrupando-se os componentes de um atributo composto entre parênteses (), separando-se os componentes por meio de vírgulas e mostrando os atributos multivalorados entre chaves {}. Esse escopo define os atributos complexos. Por exemplo, se uma pessoa pode ter mais de uma residência e cada uma delas vários telefones, um atributo EnderecoFone teria a estrutura a seguir:

{EnderecoFone({Fone(CodigodeArea,NumeroFone)}, Endereco(EnderecoRua(Numero, Rua, Apartamento), Cidade, Estado, CEP))} 2.2.4 RELACIONAMENTOS E CARDINALIDADE Assim como as entidades, os relacionamentos desempenham papel importante no MER. Eles acontecem quando um atributo de determinada tabela se relaciona com outra entidade. Por exemplo, o atributo Gerente, de Departamento, corresponde ao funcionário que gerencia o departamento; o atributo

DepartamentoControle, de Projeto, diz respeito ao departamento que controla o projeto; o atributo Supervisor, de Empregado, refere-se a outro empregado (aquele que supervisiona esse empregado); o atributo Departamento, de Empregado, corresponde ao departamento no qual o empregado trabalha, e assim

sucessivamente. 2.2.4.1 GRAU DE RELACIONAMENTO O grau de um tipo de relacionamento é o número de entidades que participam desse relacionamento. Temos o grau binário (2 relacionamentos) e ternário (3). Podemos encontrar relacionamentos de mais graus, mas os mais comuns são os binários. Um exemplo de relacionamento de grau ternário:

12

Figura 2 – Relacionamento de grau ternário Fonte: Nishimura (2009, p. 57)

Em Fornece, observem que em cada instância de relacionamento ri associa-se a três entidades – um fornecedor s, uma peça p e um projeto j. 2.2.4.2 NOMES DE PAPÉIS E RELACIONAMENTO RECURSIVO Cada tipo de entidade que participa de um relacionamento executa um papel particular no mesmo. O nome de papel significa o papel que uma entidade executa em cada instância de relacionamento, e ajuda a explicar o significado do relacionamento. Quando determinada entidade participa mais de uma vez em um tipo de relacionamento em papéis diferentes, temos o relacionamento recursivo. Exemplo de relacionamento recursivo:

13

Figura 3 – Relacionamento recursivo Fonte: Nishimura (2009, p. 60)

O tipo relacionamento Supervisão relaciona um empregado a um supervisor, no qual ambas as entidades, empregado e supervisor, são membros do mesmo tipo entidade Empregado. Assim, o tipo entidade Empregado participa duas vezes em Supervisão: uma no papel de supervisor (ou chefe), e outro, no papel de supervisionado. 2.2.4.3 CARDINALIDADE São restrições impostas para limitar as possibilidades de

combinações de entidades que podem participar do conjunto de relacionamentos correspondente. Se por exemplo, numa empresa, existe uma regra onde diz que cada empregado tem de trabalhar exatamente para um departamento, teríamos portanto, de descrever essa restrição no esquema. Temos dois tipos principais de restrições. 2.2.4.3.1 RAZÕES DE CARDINALIDADE PARA RELACIONAMENTOS BINÁRIOS Especifica o número máximo de instâncias de relacionamento em que uma entidade pode participar. As razões possíveis para esse tipo de

14

cardinalidade são: 1:1 – 1:N – N:1 – M:N. Onde N representa qualquer número de entidades relacionadas (zero ou mais). 2.2.4.3.2 RESTRIÇÕES DE PARTICIPAÇÃO E DEPENDÊNCIAS DE EXISTÊNCIA Determina se a existência de uma entidade depende de sua existência relacionada à outra entidade, pelo tipo relacionamento. Essa restrição determina o número mínimo de instâncias de relacionamento em que cada entidade pode participar. Há dois tipos de restrições de participação: total e parcial. 2.2.5 ADMINISTRADOR DE DADOS O administrador de bancos de dados (DBA) executa uma função estratégica na empresa, considerando que o maior bem de uma organização hoje são os dados, que estão sobre sua gerência. Para se entender o tamanho da responsabilidade do DBA com os dados da organização, perdas ocasionais de dados, dependendo de seu volume e importância, podem causar sérios prejuízos à empresa e inclusive levá-la à falência. Podemos resumir sua atuação em 3 grandes grupos e breves descrições (as atribuições dentro desses escopos devem variar de organização para organização), a saber:

a) Criação/Manutenção de estruturas de bancos de dados: Segue metodologias de desenvolvimento pré-estabelecidas,

interagindo com modeladores de sistema/dados, analistas de sistemas. b) Monitoração e otimização de performance: Inclui a otimização tanto lógica (implementação de novos processos de software, métodos de acesso a dados, entre outros) como a física (dimensionamento de hardware (servidores e interfaces de redes) c) Criação/Manutenção de políticas de segurança de acesso: Abrange a política de segurança da corporação, que deve ser solicitada ao administrador de segurança.

15

2.3 MÉTODOS ÁGEIS DE DESENVOLVIMENTO DE SOFTWARE As definições modernas de desenvolvimento de software ágil, evoluíram a partir da metade de 1990 como parte de uma reação contra métodos "pesados", caracterizados por uma pesada regulamentação, regimentação e micro gerenciamento, que inviabilizavam o desenvolvimento de soluções de pequeno e médio porte sem características de softwares para ambientes críticos.

Velocidade e dinamismo, são dois pontos importantes da técnica, onde graças aos métodos ágeis, o cliente é inteiramente o piloto do seu projeto e obtém muito rapidamente uma primeira produção do seu software.

Em 2001, membros proeminentes da comunidade se reuniram em Snowbird e adotaram o nome métodos ágeis, tendo publicado o Manifesto ágil, documento que reúne os princípios e práticas desta metodologia de

desenvolvimento. A essência do manifesto diz que: a) Indivíduos e interações, mais do que processos e instrumentos; b) Desenvolvimento de software em vez de documentação exaustiva; c) Colaboração com o cliente em vez de negociação contratual; d) Abertura à mudança em vez de seguir um plano rígido.

Todos os métodos têm limites e uma aplicabilidade específica. Métodos ágeis, são muito bons para softwares menores e menos complexos, mas não são adequados quando tratamos de aplicações críticas de grande escala, com equipe de desenvolvimento descentralizada em lugares diferentes ou que ainda tenham importantes interações com outros sistemas a nível de hardware ou software. 2.3.1 EXTREME PROGRAMMING OU XP A XP foi desenvolvida por Kent Beck, dono e presidente da First Class Software Inc, onde seus dois maiores interesses e objetivos são padrões e programação extrema. A XP foi concebida a partir da ideia que desenvolver software

16

é difícil, e desenvolver software de qualidade no prazo combinado é ainda mais complexo.
“A XP é uma maneira leve, eficiente, de baixo risco, flexível, previsível, científica e divertida de desenvolver software” Kent

Características marcantes: a) As equipes de desenvolvimento trabalham diretamente com o cliente em ciclos muito curtos de uma a duas semanas, no máximo; b) As entregas de versões do software acontecem muito cedo e a uma freqüência elevada para maximizar o impacto das reações dos utilizadores; c) A equipe de desenvolvimento trabalha em colaboração total com base programação aos pares; d) O código é testado e limpo ao longo de todo o processo de desenvolvimento; e) Indicadores permitem medir o adiantamento do projeto para permitir a atualização do plano de desenvolvimento.

Ciclo de vida de um projeto XP: Um projeto XP atravessa algumas fases durante o seu ciclo de vida, que são: exploração, planejamento inicial, iterações do release, produção, manutenção e morte.

a) A fase de exploração é anterior à construção do sistema. Nela, investigações de possíveis soluções são feitas e verifica-se a viabilidade de tais soluções. Os programadores elaboram possíveis arquiteturas e tentam visualizar como o sistema funcionará considerando o ambiente tecnológico (hardware, rede, software, performance, tráfego onde o sistema irá rodar). Com isso, os programadores e os clientes vão ganhando confiança, e quando eles possuírem estórias suficientes, já poderá começar a construir o primeiro release do sistema.

17

b) A fase de planejamento inicial deve ser usada para que os clientes concordem em uma data para lançamento do primeiro release. O planejamento funciona da seguinte forma: Os programadores, juntamente com o cliente, definem as estórias (use case simplificados) a serem implementadas e as

descrevem em cartões. Os programadores assinalam certa dificuldade para cada estória e, baseados na sua velocidade de implementação, dizem quantas estórias podem implementar em uma iteração. Depois, os clientes escolhem as estórias de maior valor para ser implementada na iteração isso é chamado planejamento de iteração. O processo então se repete até terminar as iterações do release.

c) Na fase das iterações do release são escritos os casos de teste funcionais e de unidade. Os programadores vão seguindo mais ou menos o seguinte fluxo de atividades na seguinte ordem (Em cada iteração): escrita dos casos de testes; projeto e refatoramento; codificação; realização dos testes; e integração. À medida que esse fluxo vai sendo seguido, o sistema vai sendo construído segundo os princípios, valores e práticas

apresentados nas seções anteriores. Depois de terminado o primeiro release, já se terá uma idéia melhor das tecnologias e do domínio do problema de modo que as iterações poderão ser mais curtas nos releases subseqüentes e já se podem fazer estimativas mais confiáveis com o que se aprendeu das iterações passadas. Depois do final do primeiro release, considera-se o início da fase de produção onde cada release subseqüente do sistema, depois de construído, é colocado para rodar em um ambiente que simula o ambiente de produção para ver seu comportamento em termos de performance. Pode-se fazer testes de aceitação adicionais para simular o

funcionamento real do sistema no ambiente alvo.

18

d) A fase de manutenção pode ser considerada como uma característica inerente a um projeto XP. Em XP você está simultaneamente produzindo novas funcionalidades, mantendo o sistema existente rodando, incorporando novas pessoas na equipe e melhorando o código. Mecanismos como:

refatoramento, introdução de novas tecnologias, e introdução de novas idéias de arquitetura podem ser utilizados em um projeto XP. É importante ressaltar que a manutenção dada em um sistema que já está em produção deve ser feita com muita cautela, pois uma alteração errada pode paralisar o

funcionamento do sistema resultando em prejuízos para o cliente. e) A fase de morte corresponde ao término de um projeto XP. Existem duas razões para se chegar ao final de um projeto, uma boa e a outra ruim. A boa razão é quando o cliente já está satisfeito com o sistema existente e não enxerga nenhuma funcionalidade que possa vir a ser implementada no futuro. A má razão para a morte em XP seria o projeto ter se tornado economicamente inviável, devido a dificuldades de adicionar funcionalidades a um custo baixo e devido a uma alta taxa de erros. 2.3.2 SCRUM Criado por Jeff Sutherland e Ken Shawaber na década de 90, a técnica faz parte do modelo de desenvolvimento ágil de software que fornece métodos para se definir o planejamento, os principais papéis de pessoas e a forma de trabalho do time. A idéia do SCRUM é justamente definir papéis bem específicos para as pessoas envolvidas no projeto e como cada pessoa vai agir, ou seja, o que cada uma vai ter que fazer para o projeto seguir em frente com sucesso.

Os principais papéis são: a) o ScrumMaster, que mantém os processos (normalmente no

19

lugar de um gerente de projeto) b) o Proprietário do Produto, ou Product Owner, que representa os stakeholders e o negócio c) a Equipe, ou Team, um grupo multifuncional com cerca de 7 pessoas e que fazem a análise, projeto, implementação, teste etc.

Características marcantes: a) Processo ágil para gerenciar e controlar o desenvolvimento de projetos; b) Roupagem para outras práticas de engenharia de software. Como XP ou FDD; c) Processo que controla o caos resultante de necessidades e interesses conflitantes; d) Aumenta a comunicação e maximiza a cooperação; e) Detecta e remove qualquer impedimento que atrapalhe o desenvolvimento de um produto; f) Escalabilidade desde projetos pequenos ater grande projetos nas organizações.

Ciclo de vida de um projeto SCRUM: O ciclo de vida do Scrum tem o seu ciclo composto por uma série de iterações bem definidas, cada uma com duração de duas a quatro semanas, chamada Sprints. Antes de cada Sprint, realiza-se uma reunião de planejamento (Sprint Planning Meeting) em que os membros do time têm contato com o Product Owner (pessoa que define os itens que compõem o Product Backlog) para selecionar e estimar os itens do Product Backlog ((lista das funcionalidades priorizadas do produto) que acreditam conseguir entregar ao final da Sprint.

A próxima fase é a execução da Sprint. Durante a execução o time controla o andamento do desenvolvimento realizando Reuniões Diárias (Daily Meeting) de não mais que 15 minutos de duração, e observando o seu progresso usando um gráfico chamado Sprint Burndown.

20

Ao final de cada Sprint, deve-se realizar uma Reunião de Revisão (Sprint Review), em que o time demonstra o produto gerado na Sprint e valida se o objetivo foi atingido. Logo em seguida, realiza-se a Reunião de Retrospectiva (Sprint Retrospective), uma reunião de lições aprendidas, com o objetivo de melhorar o processo para a próxima reunião. 2.3.3 FEATURE DRIVEN DEVELOPMENT – FDD A FDD nasceu num projeto em Cingapura, entre 1997 e 1999, a partir do Método Coad (uma metodologia completa para Análise, Desenho e Programação Orientados por Objetos, desenvolvida por Peter Coad nas décadas de 1980 e 1990) e das técnicas de gerenciamento iterativo, incremental e enxuto de projetos, utilizadas por Jeff De Luca, um gerente de projetos australiano. Seu lema é "Resultados freqüentes, tangíveis e funcionais".

Características marcantes: a) Fornece a estrutura suficiente para equipes maiores; b) Enfatiza a produção de software de qualidade; c) Entrega resultados freqüentes, tangíveis e funcionais; d) Realiza trabalho significativo desde o início, antes de tornar-se altamente iterativa; e) Fornece informação de estado e progresso de forma simples e compreensível; f) Fácil aceitação de clientes, gerentes e desenvolvedores.

Ciclo de vida da FDD: a) Desenvolver um Modelo Abrangente: pode envolver

desenvolvimento de requisitos, análise orientada por objetos, modelagem lógica de dados e outras técnicas para

entendimento do domínio de negócio em questão. O resultado é um modelo de objetos (e/ou de dados) de alto nível, que guiará a equipe durante os ciclos de construção. b) Construir uma Lista de Funcionalidades: decomposição funcional do modelo do domínio, em três camadas típicas: áreas de

21

negócio, atividades de negócio e passos automatizados da atividade (funcionalidades). O resultado é uma hierarquia de funcionalidades que representa o produto a ser construído (também chamado de product backlog, ou lista de espera do produto). c) Planejar por Funcionalidade: abrange a estimativa de

complexidade e dependência das funcionalidades, também levando em consideração a prioridade e valor para o negócio/cliente. O resultado é um plano de desenvolvimento, com os pacotes de trabalho na seqüência apropriada para a construção. d) Detalhar por Funcionalidade: já dentro de uma iteração de construção, a equipe detalha os requisitos e outros artefatos para a codificação de cada funcionalidade, incluindo os testes. O projeto para as funcionalidades é inspecionado. O resultado é o modelo de domínio mais detalhado e os esqueletos de código prontos para serem preenchidos. e) Construir por Funcionalidade: cada esqueleto de código é preenchido, testado e inspecionado. O resultado é um incremento do produto integrado ao repositório principal de código, com qualidade e potencial para ser usado pelo cliente/usuário. 2.3.4 RATIONAL UNIFIED PROCESS – RUP O Processo Unificado é um processo de engenharia de software desenvolvido por três dos principais gurus da indústria de software: Ivar Jacobson, James Rumbaugh e Grady Booch, sendo o resultado de mais de 30 anos de experiência acumulada. É o primeiro processo de desenvolvimento a explorar integralmente as capacidades do padrão UML e baseia-se nas práticas comuns aos projetos de software com mais alto ROI (retorno do investimento) do mercado. Processo de Software Unificado (Rational Unified Process) = Processo + Métodos + Linguagem (UML).

22

Características marcantes: a) Dirigido por casos de uso (use cases); b) Centrado na arquitetura; c) Iterativo e incremental;

Ciclo de vida do RUP: O ciclo de vida adotado no RUP é tipicamente evolutivo. Contudo, uma forma de organização em fases é adotada para comportar os ciclos de desenvolvimento, permitindo uma gerência mais efetiva de projetos complexos. a) Concepção: nesta fase, é estabelecido o escopo do projeto e suas fronteiras, determinando os principais casos de uso do sistema. Esses casos de uso devem ser elaborados com a precisão necessária para se proceder estimativas de prazos e custos. As estimativas devem ser globais para o projeto como um todo e detalhadas para a fase seguinte. Assim, a ênfase nesta etapa recai sobre o planejamento e, por conseguinte, é necessário levantar requisitos do sistema e preliminarmente analisá-los. Ao término dessa fase, são examinados os objetivos do projeto para se decidir sobre a continuidade do

desenvolvimento; b) Elaboração: o propósito desta fase é analisar mais

refinadamente o domínio do problema, estabelecer uma arquitetura de fundação sólida, desenvolver um plano de projeto para o sistema a ser construído e eliminar os elementos de projeto que oferecem maior risco. Embora o processo deva sempre acomodar alterações, as atividades da fase de elaboração asseguram que os requisitos, a arquitetura e os planos estão suficientemente estáveis e que os riscos estão suficientemente mitigados, de modo a se poder prever com precisão os custos e prazos para a conclusão do

desenvolvimento. c) Construção: durante esta fase, um produto completo é desenvolvido de maneira iterativa e incremental, para que esteja pronto para a transição à comunidade usuária.

23

d) Transição:

nesta

fase,

o

software

é

disponibilizado

à

comunidade usuária. Após o produto ter sido colocado em uso, naturalmente surgem novas considerações que vão demandar a construção de novas versões para permitir ajustes do sistema, corrigir problemas ou concluir algumas características que foram postergadas. É importante realçar que dentro de cada fase, um conjunto de iterações, envolvendo planejamento, levantamento de requisitos, análise, projeto e implementação e testes, é realizado. Contudo, de uma iteração para outra e de uma fase para a próxima, a ênfase sobre as várias atividades muda, como mostra a figura 1, em que a cor preta indica grande ênfase, enquanto a cor branca indica muito pouca ênfase. Na fase de concepção, o foco principal recai sobre o entendimento dos requisitos e a determinação do escopo do projeto (planejamento e levantamento de requisitos). Na fase de elaboração, o enfoque está na captura e modelagem dos requisitos (levantamento de requisitos e análise), ainda que algum trabalho de projeto e implementação seja realizado para prototipar a arquitetura, evitando certos riscos técnicos. Na fase de construção, o enfoque concentra-se no projeto e na implementação, visando evoluir e rechear o protótipo inicial, até obter o primeiro produto operacional. Finalmente, a fase de transição concentra-se nos testes, visando garantir que o sistema possui o nível adequado de qualidade. Além disso, usuários devem ser treinados, características ajustadas e elementos esquecidos adicionados.
2.3.5 METODOLOGIA DE DESENVOLVIMENTO DE SISTEMAS DINÂMICOS –DSDM

DSDM é uma metodologia de desenvolvimento de software originalmente baseada em "Desenvolvimento Rápido de Aplicação" (RAD). Emprega uma metodologia de desenvolvimento iterativo e incremental que enfatiza o envolvimento constante do usuário e tem foco na entrega de softwares dentro do prazo e com custo estimados através do controle e ajuste de requisitos ao longo do desenvolvimento.

24

Características marcantes: a) Envolvimento ativo do usuário; b) Poder de decisão da equipe DSDM; c) Entrega freqüente; d) O critério mais importante para aceitação é adequação à tarefa requisitada; e) Teste integrado ao ciclo de vida.

Ciclo de vida da DSDM: a) Análise de Viabilidade: durante este estágio do projeto, a viabilidade de uso do DSDM é examinada. Os artefatos para este estágio são Relatório de Viabilidade e Protótipo da Viabilidade. São estendidos até o Planejamento de Definições Gerais até o resto do projeto, e além deste um controle de Risco identifica os riscos mais impactantes do projeto. b) Estudo de Negócio: levantamento dos requisitos primários. Examina-se a influência dos processos do negócio, usuários envolvidos e seus respectivos desejos e necessidades. c) Iteração do Modelo Funcional: os requisitos identificados nos estágios anteriores serão convertidos em modelos funcionais. Este modelo consiste tanto do funcionamento do protótipo quanto do modelo. Prototipar é uma saída para técnicas de projeto em que neste estágio auxilia num verdadeiro

envolvimento do usuário no projeto. O protótipo desenvolvido é revisado por diferentes grupos. De forma a garantir qualidade, os testes são efetuados ao longo de cada iteração. d) Iteração de desenho e construção: O maior intuito desta Iteração do DSDM é integrar os componentes funcionais de fases anteriores em um sistema que satisfaça as necessidades do usuário. Ele também controla os requisitos não funcionais que foram definidos para o Sistema. Novamente Testes vem a ser uma atividade fundamental no andamento deste estágio. e) Implantação: na fase de Implantação, o sistema testado e mais a

25

documentação de usuário é entregue aos usuários e treinos a estes futuros usuários são aplicados. O sistema para ser entregue deve ter seus requisitos revisados de acordo com o que foi definido nas etapas iniciais do projeto. 2.4 MODELO EVOLUCIONÁRIO PARA DESENVOLVIMENTO DE SOFTWARE Este modelo busca o desenvolvimento de software evoluindo a partir de protótipo inicial. Todos os conceitos e ideias vão sendo materializado em requisitos à medida que o protótipo evolui, até atingir o produto idealizado.

O objetivo é trabalhar com o Cliente em toda a fase do desenvolvimento, a partir das especificações iniciais. Entretanto os requisitos devem ser bem compreendidos.

O modelo evolucionário pode trazer diversas vantagens, tais como antecipar o produto final para avaliação do Cliente, manter uma comunicação entre os desenvolvedores e usuários para solucionar problemas técnicos e antecipar o treinamento dos usuários. 2.4.1 MODELO DE PROTOTIPAGEM A prototipagem é um modelo de processo que possibilita ao desenvolvedor criar um modelo do software que deve ser construído. Assim, uma prévia avaliação tanto do cliente, quanto do desenvolvedor pode ser feita. Este modelo pode ser usado como um modelo de processo independente, ou como uma técnica, que pode ser implantada no contexto de qualquer um dos modelos de processo existentes. A vantagem da prototipagem é auxiliar o engenheiro de software e o cliente, a entenderem melhor o que deve ser construído, quando os requisitos estão confusos. Características marcantes: a) Utilizado quando o cliente não definiu detalhadamente os requisitos de entrada, processamento e saída; b) Possibilita ao desenvolvedor criar uma versão do software com

26

um pequeno investimento inicial; c) Prévia avaliação tanto do cliente, quanto do desenvolvedor; d) A construção do protótipo demonstra a viabilidade do sistema. e) Redução dos riscos e das incertezas do desenvolvimento;

Ciclo de vida:

Figura 4 – Ciclo de vida Prototipação Fonte: Pfleeger – Engenharia de Software (2004, p. 43)

O desenvolvimento começa com um conjunto simples de requisitos fornecidos pelos clientes e usuários. As alternativas são exploradas. Examinam-se as telas, tabelas, relatórios e outras saídas do sistema, diretamente utilizadas pelos clientes e usuários. Feita a decisão do que os clientes e usuários realmente querem, os requisitos são revisados. Havendo consenso de como deveriam ser os requisitos, o desenvolvedor se volta para as atividades de requisitos, afim de reconsiderar e alterar a especificação. Então, o sistema é codificado, e as alternativas, discutidas, de novo com uma possível iteração entre requisitos e projeto.

2.4.2 MODELO ESPIRAL O modelo em espiral foi proposto por Boehm em 1988, como forma de integrar os diversos modelos existentes à época, eliminando suas dificuldades e explorando seus pontos fortes. Este modelo foi desenvolvido para abranger as

27

melhores características tanto do ciclo de vida clássico como da prototipação, acrescentando, ao mesmo tempo, um novo elemento - a análise de riscos - que falta a esses modelos.

Características marcantes: a) Modelo iterativo e sistemático; b) Versões utilizáveis ao final de cada iteração; c) Acompanhamento de toda vida do software, mesmo depois de entregue; d) Análise de riscos.

Ciclo de vida:

Figura 5 – Ciclo de vida Espiral Fonte: Pressman 2006

O ciclo se subdivide em regiões que abrigam conjuntos de tarefas que crescem proporcionalmente ao risco e ao tamanho do projeto. Iniciado o processo, ele passa por todas as regiões e depois volta à primeira, executando novamente as regiões seguindo uma espiral até que se tenha o produto desejado.

a) Comunicação com o Cliente: mantém contato direto afim de levantar informações úteis ao sistema; b) Planejamento: define custo e tempo de desenvolvimento, além

28

de realizar uma análise de risco, onde estes são avaliados para que o desenvolvimento não se torne inviável na próxima etapa do modelo; c) Modelagem: responsável pela criação da representação

conceitual da aplicação; d) Construção: cuida da implementação e testes; e) Implantação: responsável pela instalação, suporte e feedback do incremento desenvolvido. 2.4.3 MODELO INCREMENTAL E ITERATIVO Este modelo é uma extensão do modelo espiral sendo porém mais formal e rigoroso. Dividi-se o trabalho em partes menores ou iterações. Cada iteração resultará num incremento. Iterações são passos em fluxo de trabalho e incrementos são crescimentos do produto.

O princípio subjacente ao processo incremental e iterativo é que a equipe envolvida possa refinar e alargar paulatinamente a qualidade, detalhe e âmbito do sistema envolvido.

Características marcantes: a) Análise e medições como guia do processo de aprimoramento; b) Desenvolvimento incremental e iterativo; c) Refinamento e qualidade paulatinamente no decorrer do projeto.

Ciclo de vida: a) Inicialização: cria uma versão base do sistema. O objetivo desta implementação inicial é criar um produto para que o usuário possa avaliar. Ele deve oferecer um exemplo dos aspectos chave do problema e prover uma solução que seja simples o bastante para que possa ser compreendida e implementada facilmente. b) Iterativa: envolve o re-projeto e implementação das tarefas da lista de controle do projeto e a análise da versão corrente do

29

sistema. O objetivo para o projeto de implementação de qualquer iteração é ser simples, direto e modular, preparado para suportar re-projeto neste estágio ou como uma tarefa a ser adicionada na lista de controle do projeto. c) Lista de controle do projeto: a lista de controle do projeto é modificada à luz dos resultados da análise que englobam as práticas de modularidade, usabilidade, reusabilidade, eficiência e obtenção dos objetivos. 2.4.4 DESENVOLVIMENTO BASEADO EM COMPONENTES – CBD O modelo CBD propõe-se a ser uma maneira prática e radicalmente diferente de construir aplicações oferecendo técnicas imensamente melhores de desenvolvê-las, mais baratas, rápidas e que se adaptaria naturalmente com a emergente tecnologia de objetos distribuídos.

Características marcantes: a) Separação clara entre especificação e implementação; b) Reusabilidade de componentes; c) Encapsulamento de dados e processos; d) Independência da tecnologia de componentes; e) Incorpora características de tecnologias Orientadas a Objetos no Modelo Espiral;

Ciclo de vida: a) Nível de domínio do problema: foco no entendimento do problema, Envolve o desenvolvimento de mind-maps

(representação estruturada de termos relacionados), diagrama de contexto e cenários. b) Nível de especificação do componente: descreve o

comportamento do sistema, visível externamente, de forma não ambígua. Inicialmente, especificamos de forma informal as entradas, as mudanças no objeto e as saídas retornadas.Depois é necessária a especificação formal das operações.

30

c) Nível de projeto do componente: a ênfase nesse estágio é definir uma estrutura interna que satisfação os requisitos

comportamentais, tecnológicos e de engenharia de software. 2.4.5 MODELO CONCORRENTE As fases de um processo de desenvolvimento não ocorrem seqüencialmente, e sim, concorrentemente. O mecanismo pelo qual o processo ocorre é baseado em eventos que sinalizam alterações de estado dentro de cada fase. O modelo representa atividades simultâneas de todos os membros da equipe de desenvolvimento, e os eventos que alteram o estado são gerados por necessidades do usuário, decisões da gerência, e resultados de revisões técnicas.

Por exemplo, a fase de Especificação pode estar em um dentre diversos estados: em desenvolvimento, completo, revisado, e controlado no repositório. A criação, e toda revisão à especificação original, ativa a fase de Desenvolvimento, de forma que há um ciclo constante entre os estados.

Embora o modelo apresente complexidade elevada, é bem adaptado a situações reais de desenvolvimento, onde realmente existe uma divisão temporal menos discreta entre as fases em execução.

Características marcantes: a) Fases do projeto ocorrem concorrentemente; b) Adaptado a situações reais sem definição temporal exata entre as fases de desenvolvimento; c) Muito utilizado para aplicações Cliente/Servidor; d) Simultaneidade.

31

2.5 DESENVOLVENDO EM .NET E C#

2.5.1 CONCEITOS O Visual Studio é o IDE (Ambiente de Desenvolvimento Integrado) no qual os desenvolvedores trabalham para criar programas em uma dentre várias linguagens, incluindo Visual C#, para o .NET Framework. Utilizaremos as versões do Visual Studio 2010 Express e o .NET Framework 4.0 neste trabalho.

O .NET Framework é um ambiente para desenvolvimento e execução que permite o funcionamento conjunto e perfeito de linguagens de programação e bibliotecas diferentes, tendo em vista a criação de aplicativos para Windows, Web, dispositivos móveis e Office. C# é uma destas linguagens, orientada a objeto, de tipo seguro, simples, mas poderosa, que permite aos programadores criar uma variedade de aplicativos. 2.5.2 PRINCIPAIS BENEFÍCIOS E CARACTERÍSTICAS a) Para Desenvolvedores: Construir customizações para SharePoint; Desenvolver aplicações para Windows 7, utilizando seus recursos (Multitouch, Pin Bar, etc.); Compreender de forma mais simples códigos e arquitetura já existentes; -

Identificar por testes, os impactos de alterações no código;
Customizar o Visual Studio para atender às suas necessidades.

b) Para Testers:
Aproveitar uma colaboração profunda com o time de desenvolvimento;

-

Avançar (Fast Forward) por testes manuais; Reproduzir bugs em um ambiente virtualizado; Automaticamente, incluir contexto aos bugs; Total visibilidade do progresso do teste.

32

c) Para Gerentes de projeto: Novo dashboard mantém o time em sincronia; Ágeis templates ajudam no processo de estimativa; Rastreabilidade de requisitos mantém as partes interessadas informadas; Visual Studio Team Web Access auxilia na emissão de relatórios; Novos relatórios ajudam a permitir gerenciamento proativo de projeto. 2.5.3 CENÁRIO DE ESTUDO – CONTROLAR DVD Dentro de uma aplicação de vídeo locadoras, encontramos várias ações praticadas por possíveis atores (atendente, gerente e cliente), lembrando sempre que, para ser um ator, é necessário que haja interação com o sistema. As ações são: locação, reserva, pagamentos, controle de fornecedores, controle de clientes e, controle de DVD, este último, foco deste cenário de estudo.

Figura 6 – Diagrama UML

33

2.5.3.1 COMPONENTES UTILIZADOS Os componentes e controles são à base do desenvolvimento rápido de aplicativos. São objetos reutilizáveis que expõe um ou mais interfaces para clientes de uma maneira padronizada.

Nomear os componentes corretamente e de forma intuitiva é a maneira mais inteligente e fácil para evitar transtornos em futuras manutenções do software. Exemplo: txbGenero.Text = “ação” (observem que neste caso estamos usando a propriedade Text. Para dar o nome, podemos usar a abreviação txb de textBox, que referencia o tipo de componente mais o nome da finalidade dele, Gênero do filme) Tela Principal do Sistema: a) Menu Strip: destinado a criação de menus, com ele criamos nossa barra de menus principal do sistema (Cadastrar, Cadastrar/Alterar, Financeiro, Reservas e Locações); b) StatusStrip: barra de status inferior, por meio da qual passamos valiosas informações ao usuário do sistema;

Figura 7 – Tela "Principal do Sistema"

34

Formulário de Cadastro do DVD: a) Label: propriedade mais usada é Text, onde colocamos o nome que aparecerá na tela de nosso formulário, identificando os conteúdos que deverão ser inseridos nos TextBox; b) TextBox: armazena texto dos mais variados tipos; c) RichTextBox: indicado para texto maiores, podemos alterar o tipo, estilo de letra; d) RadioButton: utilizado para selecionar um item entre vários, em nosso formulário, decidiremos se o DVD é duplo ou não; e) ComboBox: lista de opções possíveis para selecionar,

usaremos para informar a quantidade de DVD's para cada título cadastrado, seleção de fornecedores e o gênero do filme; f) Button: componente visual com finalidade de executar alguma tarefa, em nosso programa, pode executar a inserção de uma imagem de capa, acionar o leitor de código de barras ou ações básicas de sistemas (gravar, editar, cancelar); g) PictureBox: exibição de imagens, mostrará a imagem de capa selecionada pelo atendente; Telas resultantes do Cadastro de DVD:

Figura 8 – Tela "Cadastro de DVD"

35

3 CONCLUSÃO Definitivamente, para nos tornarmos bons analistas de sistemas, demanda-se muito estudo e exige-se um grau elevado de conhecimento em diversas frentes da tecnologia e das relações humanas.

Neste contexto, vimos quão são importantes os conceitos e técnicas abordados neste documento: Casos de Uso, Engenharia de Software, Banco de Dados e Programação Orientada a Objetos, são conteúdos obrigatórios no saber destes profissionais de informática, que nortearão suas carreiras e darão os subsídios necessários para o sucesso de suas empreitadas.

E finalmente, desenvolvimentos de softwares são uma arte! Produzilos com ética, rapidez, eficiência, inteligência, economia, robustez e, principalmente, qualidade, é o que se espera dos profissionais que dominam e praticam todos os conceitos abordados neste trabalho.

36

REFERÊNCIAS TANAKA, Simone Sawasaki. Análise de sistemas I: curso superior de tecnologia em análise e desenvolvimento de sistemas 2. São Paulo: Pearson Education do Brasil, 2009. 182 p. LARMAN, Craig. Utilizando UML e padrões: uma introdução à análise e ao projeto orientados a objetos e ao desenvolvimento iterativo. 3. ed. Porto Alegre: Bookman, 2008. PFLEEGER, Shari Lawrence. Engenharia de software: teoria e prática. 2. ed. São Paulo: Pearson, 2003. NISHIMURA, Roberto Yukio. Banco de Dados I: sistemas II. São Paulo: Pearson Prentice Hall, 2009. FLORES, Emerson Ricardo. Linguagens e Técnicas de Programação II - Análise e Desenvolvimento de Sistemas 2. São Paulo: Pearson Prentice Hall, 2009. UML and C++ - A Practical Guide to Object-Oriented Development, São Paulo, MAKRON Books, 2001. WIKPÉDIA http://pt.wikipedia.org CISNEIROS, Hugo. Modelo de Desenvolvimento http://www.devin.com.br/modelo-scrum/, 2009. MSDN, http://msdn.microsoft.com Ágil SCRUM.

You're Reading a Free Preview

Descarregar
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->