Análise e Projeto de Sistemas

1

© 2008 José Luiz G. Bastos Jr.

Análise e Projeto de Sistemas

Aula expositiva 01

Professor José Luiz Bastos


Objetivo da Disciplina

• Apresentar os conceitos básicos de análise e modelagem de sistemas e a importânciadestas práticas para os projetos de software.

• Apresentar parâmetros de comparação quepossibilitem a identificação da técnicaadequada para cada projeto.

• Capacitar o aluno a elaborar projetosdetalhados de sistemas através de técnicasde análise praticadas no mercado, emespecial a Análise Orientada por Objetoscom a utilização do padrão UML (Unified Modeling Language) e seus diagramas de representação.


Ementa da Disciplina

1. FUNDAMENTOS DA ANÁLISE DE SISTEMAS1.1 Análise de sistemas e ciclo de vida dos sistemas.1.2 Modelagem de sistemas.1.3 Evolução da análise de sistemas.

2. ENGENHARIA DE REQUISITOS2.1 Técnicas envolvidas2.2 Dificuldades2.3 Especificação e documentação



3. ANÁLISE ORIENTADA A OBJETOS E PADRÃO UML

3.1 Conceitos básicos da orientação a objetos.3.2 Os três pilares da orientação a objetos.3.3 Linguagem de modelagem unificada – UML.3.4 Modelos da UML.

4. MODELAGEM DE SISTEMAS ATRAVÉS DA UML4.1 Diagrama de Casos de Uso.4.2 Diagrama de Classes.4.3 Diagrama de Seqüência de Casos de Uso.



5. MODELAGEM DE SISTEMAS ATRAVÉS DA UML5.1 Diagrama de Colaboração.5.2 Diagrama de Estados.5.3 Diagrama de Atividades.


Análise de Sistemas - Motivação

• Por que analisar? Por que não começar logo pelaimplementacão?

• Análise de sistemas:– A análise de sistemas é um processo de análise detalhada

das necessidades de informação de uma organização, das características e dos componentes dos sistemas de informação atualmente utilizados (se existirem) e dos requisitos dos sistemas de informação sendo propostos.

– Trata da análise detalhada dos componentes e requisitosde um sistema.

• Objetivos da Análise de Sistemas:– Padronizar, minimizar a redundância, evitar a ambigüidade e

reduzir a manutenção corretiva das

especificações do sistema.

2


Análise de Sistemas - Visão Geral

• Sistema?– Um grupo de itens que interagem entre si ou que

sejam interdependentes, formando um todo unificado, orientado para atender objetivos específicos.

– Um conjunto organizado de doutrinas, idéias ouprincípios, habitualmente previstos para explicar a organização ou o funcionamento de um conjuntosistemático.

– Exemplos:• Sistema gravitacional

• Sistema digestivo

• Sistema rodoviário

• Sistema bancário



Sistemas de Informações

• Um sistema de informações é um conjuntode elementos inter-relacionados, processos, dados e tecnologia, cuja finalidade éalimentar os centros de decisões com as informações necessárias à escolha de diretrizes de ação que permitam atingir osobjetivos da organização.



• Dados:

– São seqüências ordenadas de símbolos dos quais se pode extrair informações. Porém, não contêm nenhumsignificado quando analisados isoladamente.

• Informações:

– São dados tratados, analisados ou processados, capazes de transmitir algum conhecimento aoreceptor.



Componentes de um Sistema de Informações:

• Hardware;• Software;• Pessoas;• Dados;• Procedimentos.



Classificação quanto à forma de processamento:

• Sistemas Batch– O usuário normalmente não interage com o computador por

terminal e as informações são processadas em lotes, de forma seqüencial.

• Sistemas On-Line– O usuário interage com o computador por terminal, os dados

de entrada são fornecidos diretamente do local onde elesforam criados e os resultados do processamento sãodirigidos diretamente para onde sejam necessários.



Classificação quanto à forma de processamento:

• Sistemas em Tempo Real– Controla um ambiente pelo recebimento de dados, seu

processamento e apresentação dos resultados com rapidezsuficiente para afetar o ambiente naquele momento.

• Sistemas Baseados em Conhecimento– Esses sistemas estão associados ao campo da inteligência

artificial. Contêm grande quantidade de conhecimentosvariados para utilização em determinadas tarefas.

• Sistemas Especialistas– São sistemas baseados em conhecimento. Têm embutidos

o conhecimento e a capacidade que os tornam capazes de funcionar como um especialista.

3


Classificação quanto ao nível organizacional:



Sistemas de Processamento de Transações

� Nível operacional;� Apoia operações rotineiras da empresa;� Registra transações;� Origem dos dados: operações internas;� Grau de agregação dos dados: dados analíticos, reaise precisos;� Volumes manipulados: grandes;� Saídas: relatórios analíticos, alguns sintéticos;� Freqüência: periódica;� Exemplos: faturamento, estoque, contabilidade etc.



Sistemas de Planejamento e Controle Operacional

� Nível tático (supervisão);� Apoia o planejamento e controle operacional;� Coleta informações sobre o realizado e compara com o previsto;� Origem dos dados: operações internas;� Grau de agregação dos dados: médio;� Volumes manipulados: médios;� Saídas: relatórios consolidados;� Freqüência: periódica;� Exemplos: custos, planejamento e controle de produção, planejamento e controle de projetos.



Sistemas de Apoio à Decisão

� Nível tático (média gerência);� Apoia processos decisórios;� Trabalha com análise matemática e estatística dos dados;� Origem dos dados: operações internas e fontesexternas;� Grau de agregação dos dados: alto;� Volumes manipulados: pequenos;� Saídas: gráficos e tabelas;� Freqüência: a pedido (ad hoc);� Exemplos: análise de investimentos, análise estatística, simulação de cenários.



Sistemas de Planejamento Estratégico

� Nível estratégico (alta administração);� Apoia análise de fatores críticos de sucesso da empresa: desempenho, mercado e concorrência;� Trabalha com projeções a longo prazo e tendênciasdo mercado;� Origem dos dados: operações internas e fontesexternas;� Grau de agregação dos dados: alto;� Volumes manipulados: pequenos;� Saídas: gráficos e tabelas sofisticados;� Freqüência: a pedido (ad hoc);� Exemplo: sistemas de informações executivas.




Princípios Gerais dos Sistemas:

• Quanto mais especializado é um sistema, menos capaz ele é de se adaptar a circunstâncias diferentes;

• Quanto maior for um sistema, maior o número de seus recursos que serãodestinados à manutenção diária;

• Os sistemas sempre fazem parte de sistemas maiores e sempre podem ser divididos em sistemas menores;

• Os sistemas CRESCEM.

4


Análise de Sistemas - Mais definições

• “A análise de sistemas é frustrante, repleta de relacionamentosentre pessoas, indefinida e difícil. Resumindo, é fascinante. Depois que você é fisgado, os velhos e fáceis prazeres da construção de sistemas nunca mais serão suficientes parasatisfazê-lo.” (DeMarco, 1989)

• “Análise de sistemas é a atividade que tem como finalidaderealizar estudos de processos a fim de encontrar o melhor e mais racional caminho para que a informação possa ser processada.” (Wikipedia)

• Análise de sistemas consiste em identificar, detalhar e documentar os processos de negócio para sua automatizaçãojunto aos usuários. Essa análise deve produzir como resultadouma especificação completa de tudo que o sistema de informação deve realizar.


Problemas

• Depende da clareza do usuário:– É ele o responsável por mostrar ao analista, de

maneira clara, quais requisitos o sistema deveatender.

• Depende do entendimento do analista:– É ele o responsável por identificar e analisar os

requisitos esperados pelo usuário.– Deve documentar de forma clara o seu trabalho, para

que os consumidores do mesmo saibam identificar osrequisitos esperados pelos usuários.

© 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr.

Solução

• Técnicas para identificação e detalhamentode requisitos

• Técnicas para modelagem de sistemas


Usuários

• Principais participantes do processo:– O sistema está sendo desenvolvido PARA ELES.– O sistema automatizará os processos de negócio

executados POR ELES.

– Comprometimento dos usuários é fundamental para o sucesso do projeto


Cada projeto possui um elenco diferente de pessoasenvolvidas. Um analista de sistemas precisa ter aptidõesinterpessoais (além do conhecimento da tecnologia), ouseja, deve falar com outras pessoas usando uma“linguagem” diferente.

Usuários

5


O analista de sistemas deve fazer reuniões regularescom os usuários (também chamados de clientes ouproprietários). O ideal seria ter um usuário dedicadointegralmente ao projeto. Alguns defendem que o usuáriodeveria fazer o projeto.

Usuários


Classificação por Tipo de Função

� Operacionais

� Têm visão local, isto é, não conhecem o processo de forma global;

� Responsáveis por executar as funções do sistema;

� Têm uma visão física do sistema, ou seja, imaginam o funcionamento do sistema considerando a tecnologia de implementação.

Usuários


� Supervisores

� Podem ou não ter uma visão local;

� Geralmente conhecem as operações, pois muitos jáforam usuários operacionais. Além disso, têm quesupervisionar os usuários operacionais;

� Orientados por considerações orçamentárias (ex.:reduziro quadro de funcionários ou aproveitá-los melhor);

� Normalmente, agem como intermediários em relação aosníveis mais elevados.

Usuários


� Executivos

� Não têm experiência operacional;

� Têm iniciativa sobre o projeto;

� Possuem uma visão global;

� Têm preocupações estratégicas;

� Capazes de lidar com modelos abstratos.

Usuários


Classificação por Nível de Experiência

� Amador

� Nunca trabalhou com um computador;

� Tem dificuldade para entender os modelos produzidospelos analistas;

� Receia ser substituído pelo sistema ou ter suaimportância minimizada.

Usuários


� Novato arrogante

� Participou de alguns projetos;

� Possui ou trabalha com computadores;

� Por conhecer algumas ferramentas, gosta de opinarsobre as tecnologias a serem usadas para implementaro sistema (normalmente, tem certeza que opina certo, mas opina errado!).

Usuários

6


� Experiente

� Conhece a análise de sistemas;

� Tem experiência de outros projetos;

� Discute sobre as ferramentas de modelagem sendoutilizadas.

Usuários


Usuários

Classificação quanto ao conhecimento de tecnologia:– Baixo:

• Não compreende a linguagem técnica

– Médio• Tem algum conhecimento tecnológico• Pode perder o foco e se preocupar com a solução

tecnológica– Alto

• Tem um bom conhecimento tecnológico

• Pode perder o foco e se preocupar muito com solução tecnológica


Gerente de Projeto

As principais funções de um gerente de projeto são:

� Gerenciar e alocar recursos de toda a equipe técnica;

� Prestar constas junto à administração superior;

� Encaminhar problemas identificados no decorrer do projeto;

�Gerentes de níveis mais altos se concentram nos aspectosmais abstratos do sistema.

Equipe do Projeto


Auditores, Controle de Qualidade e Padronizadores

Podem ser internos ou externos. Responsáveis porgarantir que o sistema será desenvolvido de acordo com os vários padrões internos e externos da organização, especialmente aqueles voltados à segurança e aocontrole de qualidade do produto final.

Equipe do Projeto


Alguns problemas dos Auditores que devem ser considerados:

� Normalmente não se envolvem no projeto até que ele tenha sidoconcluído. Nesse ponto, modificar o sistema é muito mais difícil;

� Às vezes não estão habituados com a notação utilizada;

� Geralmente, estão mais interessados na forma do que nasubstância.

�Verificam conformidades com padrões:

Padrões governamentais

Padrões internos da empresa

Padrões do processo de desenvolvimento

Equipe do Projeto


Equipe do Projeto

Analistas de sistemas

• Analisam, detalham e documentam osprocessos de negócios que serãoautomatizados

• Ajudam os usuários a encontrarem as soluções mais apropriadas

• Atuam como mediadores entre os diversosparticipantes do processo

7


Um analista de sistemas deve ter:

� Habilidade de relacionamento social;

� Conhecimento da tecnologia;

� Conhecimento dos processos de negócio

� Mente lógica e organizada (visualizar o sistema sob diferentes perspectivas), ou seja, raciocínio lógico e abstrato

Equipe do Projeto


O analista desempenha as seguintes funções:

� Mediador: como os usuários dificilmente chegam a um consenso, o analista deve usar a arte da diplomacia e da negociação. O sistemadeve ser feito da forma como os usuários solicitaram;

� Líder de projeto: Como o analista entrou antes no projeto, freqüentemente também é o projetista e normalmente é uma pessoamais experiente, existe uma tendência natural de que ele assuma o papel de gerente de projeto.

Equipe do Projeto


� Arqueólogo e escriba: deve trazer à luz os detalhes e documentar as atividades cujos detalhes passam de geração emgeração de usuários;

� Inovador: não se limitar apenas a implementar as funçõesatuais do sistema mas ajudar a encontrar produtos e mercadosnovos;

Equipe do Projeto


Projetistas de Sistemas

• Arquitetos do sistema

• Recebem o resultado do trabalho dos analistas de sistemas

• Usam os requisitos levantados para desenhar a arquitetura do sistema que servirá de base para o trabalho dos programadores

• Interação constante com os analistas

• Podem verificar a inviabilidade de alguns requisitos

Equipe do Projeto


Projetistas de Sistemas

• O analista de sistemas deve fornecer informaçõessuficientemente detalhadas para que o projetista elabore um projeto tecnologicamente bom.

• O projetista deve fornecer informações suficientes para que o analista possa dizer se os requisitos dos usuários podem ser completamente atendidos ou devem ser modificados.

Equipe do Projeto


Programador

• Responsável por codificar e testar (usando umalinguagem de programação) os módulos dos sistemasmodelados pelos projetistas.

• Em um cenário ideal, o programador não deveria tercontato com o analista, já que se baseia apenas no trabalho feito pelo projetista.

• Há programadores que são responsáveis apenas por dar manutenção em um sistema.

Equipe do Projeto

8


Programador

Segundo Zvegintzov (1987) - (autor do artigo Software Maintenance News):

Até o presente momento, o principal profissional da computação era alguém que podia

aprender o suficiente sobre as necessidades das empresas para expressá-las na

linguagem dos computadores. No futuro, quando nossa sociedade tornar-se

irreversivelmente computadorizada, o principal profissional será alguém que possa

aprender o suficiente sobre sistemas computadorizados para expressá-los em linguagem

humana. Sem essa pessoa, teremos perdido o controle de nossa sociedade. Esse alguém

é o engenheiro às avessas. Os mantenedores de software são os engenheiros às avessas

da sociedade.

Equipe do Projeto


Equipe do Projeto


Equipe do Projeto

• Mais integrantes?

– Testadores– Analistas de usabilidade– Engenheiros de processo

– Gestores de configuração– E por aí vai...


Ciclo de vida de um projeto

Definição:

• “Um ciclo de vida de projeto bem definidooferece mecanismos para planejar e acompanhar atividades de forma maisprecisa, possibilitando a detecção de problemas de forma rápida (YOURDON, 1990)”.


Etapas do ciclo de vida clássico


Questões

1) Quais são os problemas do ciclo de desenvolvimento de sistemas apresentadona figura acima? De que forma essesproblemas podem ser solucionados ou pelomenos minimizados?

2) Esse ciclo de vida pode ser consideradorealístico para projetos de software? Porquê?

3) De que forma a fase de análise interfere e sofre interferência das outras etapas?

9


Etapas do ciclo de vida de desenvolvimento de software


Fases

Fase na qual o produto é colocado à disposição de umacomunidade de usuários para testes finais, treinamento e usoinicial.

Transição

Fase na qual é desenvolvida (desenhada, implementada e testada) uma liberação completamente operacional do produto, que atende aos requisitos especificados.

Construção

Fase na qual a especificação do produto é detalhada o suficiente para modelar conceitualmente o domínio do problema, validar os requisitos em termos deste modeloconceitual e permitir um planejamento acurado da fase de construção.

Elaboração

Fase na qual necessidades dos usuários e conceitos da aplicação são analisados o suficiente para justificar a especificação de um produto de software, resultando em umaproposta de especificação.

Concepção


Fluxos

Visa detalhar e implementar o desenho através de componentes de código e de documentação associada.

Implementação

Visa verificar os resultados da implementação, através do planejamento, desenho e realização de baterias de testes.

Testes

Visa formular um modelo estrutural do produto, que sirva de base para a implementação, definindo os componentes a desenvolver e a reutilizar, assim como as interfaces entre eles.

Desenho

Visa detalhar, estruturar e validar os requisitos, em termosde um modelo conceitual do problema, de forma que estespossam ser usados como base para o planejamento e acompanhamento detalhados da construção do produto.

Análise

Visa obter um conjunto de requisitos de um produto, acordado entre cliente e fornecedor.

Requisitos


Modelos de ciclo de vida

Modelo Codifica-Remenda:



Modelo Codifica-Remenda:

• Provavelmente o mais usado• Não exige sofisticação técnica ou gerencial• Alto risco• Impossível de gerir• Não permite assumir compromissos

confiáveis



Modelo em cascata:• As fases são executadas em estrita

sequencia• Pouco realiza, não permite erros• Pontos de controle bem definidos facilitam

gestão• Teoricamente é confiável e utilizável em

projetos de qualquer escala• Rígido e burocrático• Baixa visibilidade para o usuário, que só

recebe o resultado no final do projeto

10



Modelo em cascata com realimentação:• E possível voltar à fase anterior• Mais fexível



Modelo em espiral:



Modelo em espiral:• Software é desenvolvido em uma série de

iterações• Cada nova iteração é um novo ciclo na

espiral• Construção é feita de forma incremental• Utilizado em processos ágeis, como o XP



Modelo de entrega evolutiva:

• Combinação entre o modelo de Espiral e Cascata


Projeto – Empresas de pequeno porte

• Normalmente é iniciado após um acordoverbal entre os usuários e a equipe do projeto

• O desenvolvimento é feito logo após esseacordo verbal, geralmente sem a existênciade análise.

• Geralmente não existe um processo de desenvolvimento formal. Se existe, geralmente não é seguido ou verificado.


Projeto – Empresas de grande porte

• Existe um processo formal de engenharia de software

• Existem meios para verificar se o processoestá sendo seguido

• Todos conhecem o processo• O gerente é o responsável por organizar o

projeto de acordo com o processo

11


Modelos

• A criação de um modelo corresponde àutilização de uma linguagem que possa ser empregada por analistas e compreendida porusuários, para representar um sistema.

• Os modelos são os principais produtos da análise e são fundamentais para se obter um produto de software de qualidade, dentro de prazos e custos preestabelecidos.


Modelos

• É a partir das especificações dos clientes e usuários que os modelos serão construídos e a partir dos modelos que o produto serádesenvolvido, portanto, o envolvimento do cliente é de fundamental importância nestaetapa. Os modelos podem ser utilizadostambém para a validação inicial do produto, o que os torna ainda mais importantes.


Modelos

Observação Importante:

• Um analista de sistemas, além de saber construir modelos, deve se aprofundar no que está sendo modelado, seja um sistemade matrícula, vendas, controle de estoque, bancário, etc. Durante a modelagem, o analista muitas vezes se torna um especialista na área.



Aula expositiva 02



Para desenvolver sistemas úteis, de alta qualidade e que realmente satisfaçam as necessidades dos usuários, é necessário considerar os seguintesaspectos:

� Produtividade;

� Confiabilidade;

� Manutenibilidade.

Premissas


14,2Outros

6,2Falta de gerenciamento de TI

7,5O software não é mais necessário

8,1Falta de planejamento

8,7Alterações nos requisitos e especificações

9,3Falta de suporte executivo

9,9Expectativas não-realistas

10,6Falta de recursos

12,4Falta de envolvimento dos usuários

13,1Requisitos incompletos

% dos projetosFator de insucesso

Por que os projetos de software são cancelados antes de serem concluídos?

Fatores de insucesso em projetos de software

12


Engenharia dos Requisitos

• Motivação • Os problemas têm que ser enunciados antes de serem

resolvidos.

• Nada é mais caro do que resolver os problemas errados.

• A boa engenharia de requisitos reduz a instabilidade de sistemas de informação:

• Ajuda a obter os requisitos corretos em um estágio anterior ao desenvolvimento.

• O custo de correção de defeitos cresce muito ao longo do tempo.


Engenharia dos Requisitos

• Princípios• Boas especificações de requisitos são indispensáveis.

• Não representam custos supérfluos, mas investimentos necessários.

• A participação dos usuários na engenharia de requisitos éfundamental para que suas necessidades sejam corretamente atendidas pelo produto.

• Uma boa especificação de requisitos custa tempo e dinheiro;

• A ausência de uma boa especificação de requisitos custa muito mais tempo e dinheiro.


Fase de Elaboração

• Fase na qual a especificação do produto é detalhada o suficiente para modelar conceitualmente o domínio do problema, validar os requisitos em termos deste modelo conceitual e permitir um planejamento acurado da fase de construção.

• É dividida em duas iterações:

• Levantamento dos Requisitos: captura dos requisitos junto aos usuários.

• Análise dos Requisitos: detalhamento e validação dos requisitos levantados junto aos usuários.


Levantamento dos Requisitos

• Levantamento das funções, interfaces e requisitos não-funcionais desejados para o produto.

• Requisitos levantados apenas em nível necessário para o estabelecimento de um entendimento inicial entre usuários, clientes e desenvolvedores.

• Levantamento de requisitos focalizando os usuários.

• Método típico: * oficinas de levantamento de requisitos.


Análise dos Requisitos

• Detalhamento e análise dos requisitos.

• Modelagem conceitual dos elementos relevantes do domínio do problema e uso desse modelo para validação dos requisitos e planejamento detalhado da fase de Construção.


Análise dos Requisitos

• Foco na visão que os desenvolvedores têm dos requisitos do produto, ainda dentro do espaço de problema e não do espaço de solução.

• Métodos típicos: * oficinas de detalhamento de requisitos;* entrevistas.

13


Técnicas para Levantamento e Análise de Requisitos

• Freqüentemente, falhas de comunicação e de entendimento entre a equipe de desenvolvimento e clientes envolvidosresultam em erros de especificação cuja posterior correção em sistemas jáconstruídos compromete prazos e custos previstos.

$$$


Técnicas para Levantamento e Análise de Requisitos

• Metodologia mais utilizada pelas empresas:• Entrevista individual entre o analista de sistemas e os

usuários.

• Vantagens:• Praticidade e fácil aplicação.

• Desvantagens:• Lentidão do processo;• Comprometimento:

• Da qualidade dos requisitos resultantes;• Da convergência de interesses entre os usuários;• Consenso na priorização dos requisitos.


Técnicas para Levantamento e análise de Requisitos

• Técnicas de dinâmica de grupo:• Eficazes na agilização do processo;• Redução nas falhas de comunicação;• Metodologia JAD*:

• Uma abordagem usando um líder NEUTRO para orientar usuários através de um processo interativo e flexível, obtendo-se CONSENSO sobre um assunto pré-determinado.

*Joint Application Design

• Metodologia desenvolvida nos anos 70 pela IBM – Canadá;• Objetivo inicial: levantamento de requisitos e desenho de

interfaces de sistema;© 2008 José Luiz G. Bastos Jr.

Metodologia JAD

• Benefícios:• Redução da necessidade de manutenção nos aplicativos

desenvolvidos com o seu auxílio;

• Redução de custos;

• Maior satisfação dos usuários, pois as aplicações atendiam ao que eles realmente desejavam;

• Maior entrosamento entre a área de Sistemas de Informações e os Departamentos Usuários;

• Menor necessidade de modificações durante o processo de desenvolvimento;

• Nivelamento das expectativas de ambas as partes entre outros.


Metodologia JAD

• Com o passar do tempo, JAD passou a ser utilizado:• Em todas as fases do cliclo de desenvolvimento de software

e não apenas durante o levantamento de requisitos (Joint Application Development);

• Planejamento de projetos em geral;• Planejamento estratégico;• Tomada de decisões, de qualquer natureza, que necessita

de um consenso entre várias pessoas das diversas áreas de uma organização (Workshops).


Metodologia JAD

• Componentes básicos de um JAD:• Patrocinador do projeto:

• Possui poder de decisão e fornece os recursos necessários para o projeto.

• Líder da sessão:• Responsável por conduzir a sessão de forma

NEUTRA.• Documentador:

• Responsável por redigir as decisões tomadas em ata;

14


Metodologia JAD

• Componentes básicos de um JAD:• Usuários finais:

• Conhecedores do negócio da aplicação;

• Definem as necessidades do sistema em nível apropriado de detalhes;

• Desenvolvedores:

• Tomam conhecimentos das necessidades dos usuários finais e da aplicação durante a sessão de JAD;

• Respondem questões técnicas;


Metodologia JAD

• Por que usar JAD?• Redução do tempo de desenvolvimento do software;• Aumento da qualidade do software;• Aumento da produtividade;• Redução do custo;• Maior motivação e comprometimento da equipe;• Redução de alteração de requisitos;• Visão global do sistema pelos envolvidos;


Metodologia JAD

• Sucesso de um JAD depende:• Liderança da sessão de forma eficiente;• Participação de usuários finais, executivos e

desenvolvedores;• Alcance da sinergia do grupo durante a sessão.


Oficina de Requisitos

• Definição do Local:☺ Afastado do local de trabalho, onde os

participantes não possam ser interrompidos;

☺ Sem interferências externas (celular, bip, etc...);

☺ Baixo nível de ruído;

☺ Mesas arrumadas em “U” (se possível);

☺ Serviço de café.


Problemas de Produtividade

Os dois aspectos mais importantes desse problemasão:

� A demanda reprimida (backlog) por novos sistemas;

� O tempo necessário para construir um novo sistema.

Principais Problemas no Desenvolvimento de Sistemas


Demanda reprimida

O backlog dos sistemas pode ser dividido em trêscategorias:

• Visível:

Sistemas solicitados oficialmente pelos usuários e queforam aceitos e tiveram suas verbas aprovadas pelagerência. Ainda não foram iniciados por falta de recursos humanos (analistas, programadores etc.).


15


• Invisível:

Sistemas que os usuários sabem que precisam, mas nãose dão ao trabalho de solicitar oficialmente, porque aindaestão aguardando outros projetos.

• Desconhecido:

Sistemas que os usuários ainda não sabem que precisam mas que emergirão logo que sejam concluídos outros sistemas dos backlogs visível e invisível.



Tempo de desenvolvimento

Existe a preocupação com a perda de oportunidades de negócios, devido à incapacidade de desenvolver ossistemas de apoio necessários no tempo necessário.Muitos projetos nem são terminados. Dentre os principaismotivos para estouro de tempo em projetos, podemoscitar:

� Problemas técnicos;



� Problemas gerenciais;

� Inexperiência da equipe;

� Falta de tempo para análise e projeto;

� Escasso envolvimento por parte da gerência ou usuários.



O tempo necessário para criar um sistema pode ser reduzido através de algumas técnicas:

� Contratação de mais programadores e analistas de sistemas;

� Contratação de programadores e analista de sistemasmais talentosos, oferecendo-lhes melhores condições de trabalho;



� Deixar que usuários desenvolvam seus própriossistemas;

� Melhores linguagens de programação;

� Ferramentas automatizadas de desenvolvimento.



Razões para os analistas terem ciência dos problemas de produtividade:

� A produtividade e qualidade do trabalho dos programadores está diretamente ligada ao serviço feitopelo analista;

� Algumas das técnicas de aumento de produtividadetêm importância direta para os analistas;


16


� A produtividade da análise é um problema politicamentesensível;

� Usuários e gerente têm ansiedade pelo início da programação;

� Usuários não entendem a importância da especificação.



Problemas de Confiabilidade

Os erros em sistemas podem passar desapercebidos (ex.: uma impressão de relatório não formatada corretamente) ou causar graves acidentes (problema em sistema de tráfego aéreo).

Os erros em software são difíceis de serem extintosporque:

� É difícil descobrir como solucionar o erro;



� Deve-se encontrar todos os pontos de correção;

� Alta probabilidade de introduzir novos erros (efeitoscolaterais);

� Nem sempre são reportados pelos usuários;

� Dificuldade de reproduzir o erro.



A figura 1 mostra o número de erros encontrados emfunção do tempo decorrido (YOURDON, 1990).

Figura 1 – Erros descobertos em função do tempo



Sobre a curva na figura 1 é importante notar:

� Inicialmente o nº de erros encontrados é pequeno (usuários semsegurança para apontar erros), como indica T1;

� À medida que os usuários se familiarizam com sistema os erros sãopercebidos e reportados (entre T1 e T2);

� Após um tempo (após T2) o nº de erros encontrados começa a diminuir (sistema começa a tornar-se mais estável);

� O número de erros volta a crescer devido a correções ou modificaçõesque introduzem novos erros (após T3);

� A curva nunca atinge zero.



Manutenibilidade

A correção de erros é apenas um dos aspectos da manutenção de sistemas. A manutenção também estávinculada a fatores como:

� Modificações no hardware;

� Novos dispositivos;

�Necessidade de melhorar o desempenho;

� Garantir maior confiabilidade;

�Alterações dos requisitos.


17


A manutenção de um sistema deve ser sempreacompanhada de modificações na especificação do sistema. Entretanto, isso nem sempre ocorre devido a fatores como:

� Analista alocado para outro projeto;

� Urgência na implantação das modificações;

� Inexistência de uma política que valorize a manutenção da especificação.



Outros Problemas – Portabilidade

� Consiste em escrever sistemas que podem ser transferidos para outras plataformas;

� Apesar de não ser um problema da alçada do analista, ele deve especificar que há essa necessidade;

� A portabilidade geralmente provoca ineficiência já querecursos disponíveis de determinada plataforma não sãoaproveitados.



Outros Problemas – Segurança

À medida que os sistemas de informações crescem em número e importância, o risco de violações aumenta.

A segurança de sistemas de informações consiste basicamente em:

� Impedir o acesso de pessoas não autorizadas;

� Conceder acesso a certas funcionalidades apenas a algumas pessoas.



Principais causas dos Problemas

� Ausência de Planejamento de Sistemas;

� Ausência de Administração de Dados;

� Não utilização de Métodos e Técnicas Formais de Desenvolvimento;

� Não utilização de Técnicas e Ferramentas;

� Adoção de Metodologias não ambientadas àrealidade da empresa;



Principais causas dos Problemas(cont.)

� Falta de definição precisa dos objetivos e requisitos do sistema;

� Dificuldade de comunicação e/ou falta de entrosamento entre as pessoas envolvidas no processo, causada por problemas de linguagemou rivalidade entre usuários;

� Falta de precisão e clareza na especificação dos sistemas.



Nota Especial Sobre Qualidade

� A qualidade de um sistema pode ser mensuradaconsiderando a eficácia e a eficiência obtidas:

Eficácia = Resultados Obtidos / Resultados Pretendidos

Eficiência = Resultados Obtidos / Recurso Consumido


18


Problemas que denotam falta de qualidade emsistemas:

� Não contribuem para os objetivos da empresa;

� Não atendem às necessidades dos usuários;

� Não são confiáveis;

� São ineficientes;

� Têm manutenção constante, difícil e onerosa.



1 Técnicas de Entrevistas e de Coleta de Dados

� Por que e para que fazemos entrevistas ?

� Para coletar informações armazenadas em cérebros sobre o comportamento de um sistema atual ou um novo sistema;

� Para verificar como compreendemos o comportamento de um sistema;

� Para elaborar um estudo de viabilidade de desenvolvimento de um sistema.

Identificação, análise e gerência de requisitos


2 Tipos de Entrevistas

� Entrevista em forma de reunião pessoal;

� Entrevista em forma de questionários abertos e fechados;

� Gravação de descrição de expectativas do usuário em relação ao sistema.



3 Problemas ao Entrevistar Usuários

� Entrevistar a pessoa errada no momento errado;

� Fazer perguntas erradas e obter respostas erradas;

� Criar ressentimentos recíprocos.



4 Diretrizes para a realização de entrevistas

� Desenvolva um plano geral de entrevista;

� Certifique-se de que você tem autorização para falar com os usuários;

� Planejar a entrevista para fazer uso eficiente do tempo;

� Utilize ferramentas automatizadas que sejam adequadas, mas não abuse;

� Tente descobrir em que informações o usuário está mais interessado;



5 Possíveis Formas de Resistência na Entrevista

� Você está tomando muito o meu tempo;

� Você está ameaçando o meu emprego;

� Você não conhece nossa empresa e ainda quer nos dizer como deveser feito o novo sistema?


19


5 Possíveis Formas de Resistência na Entrevista(cont.)

� Você está tentando mudar o modo como as coisas são feitas aqui;

� Nós, usuários, não queremos este sistema;

� Por que você está desperdiçando nosso tempo com esta entrevista?



6 Outros Problemas a Enfrentar

� Uma discussão que focalize mais os problemas de implementação do que os problemas de requisitos;

� Confusão entre sintomas e problemas;

� O usuário pode ser incapaz de explicar o que ele quer que o sistema faça ou pode mudar de opinião;

�Desentendimento entre usuários de mesmo nível, subordinados e chefes.



7 Formas Complementares de Coleta de Dados

� Demonstrações feitas pelos fornecedores;

� Visitas a outras empresas com sistemas semelhantes;

� Coleta de dados em manuais, formulários, relatórios, listagens de programas, etc.;

� Pesquisa externa em instituições como IEEE e ACM.



Requisitos Funcionais: Descrevem a funcionalidadeou os serviços que se espera que o sistema forneça. Descrevem a função de sistema detalhadamente, suasentradas e saídas, excessões, etc. Exemplos:

� “O sistema deve permitir que cada professor realize o lançamento de notas das turmas nas quais lecionou”;

� “O sistema deve permitir que um aluno realize a suamatrícula nas disciplinas oferecidas em um semestre”;

� “O sistema deve permitir que o aluno consulte todo o seuhistórico de disciplinas cursadas”.



Requisitos Não Funcionais: São aqueles que nãodizem respeito diretamente às funções específicasfornecidas pelo sistema. Eles podem estar relacionadosa propriedades de sistemas emergentes, comoconfiabilidade, tempo de resposta e espaço em disco. Alternativamente, podem definir restrições para o sistema, como por exemplo, a capacidade dos dispositivos de E/S e as representações de dados utilizados nas interfaces de sistema.



Requisitos Não Funcionais:

Requisitos organizacionais

Requisitos externos

Requisitos do produto

EficiênciaConfiabili

dadePortabili

dadeInteropera

bilidadeÉticosLegais

Facilidade de uso

EntregaImplemen

taçãoPadrões

Desempenho

EspaçoPrivacida

deSeguran

ça

Requisitos não funcionais


20


Requisitos de Usuário:

São os requisitos que descrevem os requisitos funcionais e nãofuncionais de modo compreensível pelos usuários do sistema quenão têm conhecimentos técnicos detalhados. Como redigí-los ?

� Utilize um formato-padrão e certifique-se de que todas as definições de requisitos estejam conforme este formato;

� Utilize a linguagem de modo consistente. Em particular, faça umadistinção entre os requisitos obrigatórios e os que são desejáveis;

� Evite, tanto quanto possível, o uso de jargões de informática. Contudo, inevitavelmente, ocorerrá que termos técnicos detalhados, utilizados no domínio da aplicação do sistema, sejam incluidos nosrequisitos do usuário.



Requisitos de Sistema:

São descrições mais detalhadas dos requisitos de usuários. Estes requisitos podem ser descritos utilizando-se:

(1) Linguagem natural estruturada – depende de formulários padrão;

(2) Linguagem de descrição de projeto – usando linguagens de programação como exemplo para descrever os requisitos;

(3) Notações gráficas – usando diagramas em geral (casos de uso, atividades, seqüência, etc);

(4) Especificações matemáticas – como uma máquina de estadosfinitos (de acordo com a transição de estados).



Observações Sobre os Requisitos:

� Volatilidade dos requisitos: atualmente, a volatilidade é mais uma regra que uma exceção. Os requisitos mudam rapidamente atualmente, novosrequisitos podem ser adicionados e outros removidosdurante o processo.

� É importante ressaltar que, com a complexidadedos sistemas atuais, é impossível pensar em todos osdetalhes do sistema a princípio.



Documento de Requisitos:

O documento de requisitos – às vezes chamado ER -Especificação de Requisitos de software – é a declaração oficial do que é exigido dos desenvolvedoresde sistema. Ele deve incluir os requisitos de usuário paraum sistema e uma especificação detalhada dos requisitos de sistema (SOMMERVILE, 2003).



Usuários do Documento de Requisitos:

Clientes do Sistema

Gerentes

Engenheiros de Sistema

Engenheiros de teste de Sistema

Engenheiros de manutenção de Sistema

Especificam os requisitos e os lêem para verificar se eles atendem a suas necessidades. Especificam

as mudanças nos requisitos.

Utilizam o documento de requisitos para planejar um pedido de proposta para o sistema e para

planejar o processo de desenvolvimento.

Utilizam os requisitos para compreender que sistema deve ser desenvolvido.

Utilizam os requisitos para desenvolver testes de validação para o sistema.

Utilizam os requisitos para ajudar a compreender o sistema e as relações entre suas partes.



Requisitos de um Documento de Requisitos:

Segundo Heninger (1980), um documento de requisitos de software deveriasatisfazer a seis princípios:

� Deveria especificar somente o comportamento externo do sistema;

� Deveria especificar as restrições à implementação;

� Deveria ser fácil de ser modificado;

� Deveria servir como uma ferramenta de referência para os responsáveis pelamanutenção do sistema;

� Deveria registrar a estratégia sobre o ciclo de vida do sistema;

� Deveria caracterizar respostas aceitáveis para eventos indesejáveis.


21


Referências Bibliográficas:

HENINGER, K. L.. Specifying software requirements for complex

systems. New techniques and their applications. IEEE Transactions on

Software Engineering. SE-6[1]. P.2-13. (Cap. 5).

SOMMERVILLE, Ian. Engenharia de Software. 6ª ed. São Paulo.

Addison Wesley, 2003.

YOURDON, Edward. Análise Estruturada Moderna. 3ª ed. São Paulo:

Campus, 1990.




Aula expositiva 03



Análise Orientada a Objetos -Objetivos

• Apresentar para os alunos o significado de ser orientado a objetos e os conceitos que permeiameste paradigma de desenvolvimento de sistemas, a saber: objetos, classes, mensagens, abstração, encapsulamento, herança e polimorfismo, bem como a importância de cada um deles para esteparadigma.

• A UML – Linguagem de Modelagem Unificada – éuma linguagem de modelagem de sistemasorientados a objetos que se consagrou no mercadocomo padrão e que será apresentada como forma de representação destes sistemas.


Sistemas orientados a objetos

• “Sob um ponto de vista superficial, dizer que um software é orientado a objetos significa dizer que o software é organizado como uma coleção de objetos separados que incorporam tanto a estrutura quanto o comportamento dos dados, contrastando com a programação convencional, em que a estrutura e o comportamento dos dados apresentam pouco vínculo entre si.”


Sistemas orientados a objetos

• “Isso corresponde a dizer que os elementos da OO são independentes, ou que devem ser criados da forma mais independente possível, para que possam ser reutilizados posteriormente.”


Introdução a OO Filosofia (1/4)

– Engenharia: Arte de aplicar conhecimentos científicos e empíricos e certas habilitações específicas à criação de estruturas, dispositivos e processos que se utilizam para converter recursos naturais em formas adequadas ao atendimento das necessidades humanas;

– Engenharia de software: Procura gerar valores através dos recursos de processamento de informação.

22



– Qualidade de software: Um dos principais objetivos da Engenharia de Software é ajudar a produção de software de boa qualidade;

– Fatores de qualidade do software:• Externos;

• Internos.



– Fatores de qualidade externos:– Correção;– Robustez;– Extensibilidade;– Reusabilidade;– Eficiência;– Compatibilidade;– Facilidade de uso;– Portabilidade;– Integridade;– Verificabilidade;

• Fatores de qualidade internos:– Modularidade;– Legibilidade;– Manutenibilidade.



• Custos de manutenção de software: Cerca de 70% do custo de um software é manutenção;

• Exemplo de distribuição:– Mudanças na especificação: 41,8%;– Mudanças no formato dos dados: 17,4%;– Consertos de emergências: 12,4%;– Depuração: 9,0%;– Mudanças no hardware: 6,2%;– Atualização de documentação: 5,5%;– Melhoria na eficiência: 4%;– Outras: 3,4%;

Lintz, B. P. & Swanson, E. B., Software Maintenance: A User/Management Tug of War, Data Management, pp. 26-30, april 1979.


Introdução a OO Paradigma (1/10)

• Normalmente o desenvolvimento de software

é feito dentro de um projeto;• Todo projeto tem uma data de início, uma

data de fim, uma equipe e outros recursos;• Foco de análise, ótica:

– Construção, desenvolvimento, implementação.



• Projeto tem por objetivo construir a ponte entre a especificação de uma aplicação e a implementação sob o modelo computacional;

• Métodos de projeto:– Projeto estruturado top-down;– Projeto orientado por dados.



• Projeto estruturado top-down:– Produz uma arquitetura baseada somente na função

do sistema;– Cada componente do sistema refina ou decompõe

funções;– Decomposição pára quando o nível de abstração da

função refinada for diretamente implementável;

• Logo:– Top-down é a decomposição da função do sistema

como uma árvore de subfunções;– Cada função é implementada como uma rotina;– Top-down é baseado somente na abstração de

comandos e expressões.

23





• Projeto estruturado top-down:– Vantagens:

• Disciplina o pensamento de forma lógica e organizada;

• Permite o desenvolvimento de forma ordenada;

• Oferece uma maneira sistemática para quebrar a aparente complexidade inicial;

– Desvantagens:• Não leva em consideração a natureza evolutiva dos

sistemas de software;

• O uso da função negligencia o aspecto Estrutura de Dados.



• Sistemas são mais bem descritos pelos vários serviços que oferecem;

• Exemplo: Um sistema operacional oferece serviços de:– Gerência de processamento;– Gerência de memória;– Entrada e saída;– Interpretação de comandos;

– Impressão.



• Projeto orientado por dados:– Atenção voltada para as Estruturas de Dados

envolvidas na Especificação da Aplicação;– Exemplo: serviço de cadastro de usuários em um

sistema:• Usuário, Grupo de usuários, Perfil de usuários –>

Estruturas de Dados;

• Entretanto, foco inteiramente voltado para Estrutura de dados também pode não ser a solução;

• Tipos abstratos de dados provêem o equilíbrio necessário.





• Tipos abstratos de dados = Estrutura de dados+ serviços específicos(métodos ou funções);

• Tipos abstratos de dados utilizados como elemento principal de modularização favorecem:– Reusabilidade;– Extensibilidade;

24



• Implicações:– Necessidade de técnicas de organização de software

que privilegiem:• Extensibilidade;

• Reusabilidade;

– Necessidade de técnicas que suportem o desenvolvimento sistemático de software, garantindo:

• Correção;

• Robustez;

– Fatores externos de qualidade são primordiais, mas sópodem ser alcançados por meio de fatores internos:

• Modularidade;

• Orientação por objetos.


Conceitos OO Projeto OO

• Projeto OO é o método que produz arquiteturas de software baseadas nos objetos que o sistema manipula;

• A propriedade básica do método:– Evite perguntar: O que o sistema faz?

– Melhor perguntar: Sobre o que o sistema faz o que?

• Olhar primeiro para o dado é a regra que favorece a reusabilidade;

• Descrição de objetos deve ser: completa, precisa, não ambígüa e independente de representação física.


Conceitos OO Tipos abstratos de dados

• O comportamento dos objetos é definido pelo seu tipo abstrato;

• Descrição de um TAD deve compreender:– Interface do TAD;– Comportamento do TAD;

• Um tipo abstrato de dados é uma classe de estrutura de dados descrita por uma interface externa: – Lista de serviços disponíveis;– Propriedades destes serviços.




• A representação das estruturas de dados do TAD fica completamente encapsulada;

• A representação das estruturas de dados do TAD não faz parte de sua definição;

• O adjetivo abstrato de um tipo abstrato de dados enfatiza o fato de as estruturas de dados que representam o tipo não fazerem parte da definição, isto é, da interface do tipo.



Conceitos OO Programação OO

• Programação OO é a construção de sistemas de software como uma coleção estruturada de implementações de tipos abstratos de dados;

• Tipos abstratos de dados:– Módulos, pacotes, são construídos com base em

abstrações de dados (classes);

• Coleção:– Metodologia baseada na montagem bottom-up de

classes existentes;

• Estruturada: – Relação Cliente-servidor e de hierarquia entre

classes.

25


Conceitos OO Sistemas OO


Conceitos OO Sistemas OO

• As classes formam o núcleo de um programa OO;• Os objetos provêem o comportamento, devendo ser

criados apropriadamente;• Cada objeto implementa uma parte do

comportamento geral da aplicação:– Objetos (transientes) de computação;

– Objetos (persistentes) de banco de dados;

– Objetos de interface;

• O programa principal fica reduzido à função de criar e iniciar objetos principais e iniciar a computação.


Conceitos OO Encapsulação

• Encapsulação consiste em ocultar o funcionamento interno de uma classe;

• O acesso aos serviços oferecidos é feito via interface, independentemente do funcionamento interno de uma classe;


Conceitos OO Classes (1/16)

• Classe éum conceito de softwareque descreve a implementação de um TAD;

• Uma classe define:– A estrutura de dados que representa o TAD;

– A implementação das operações, métodos, sobre esta estrutura;

– Uma interface explícita;

• Classe é apenas um molde para criação de TAD;• Uma classe é a representação de um conjunto de

objetos que compartilham os mesmos atributos, operações, relacionamentos e semântica.



• Classes suportam os conceitos de:– Abstração;– Encapsulação;– Proteção de dados;

– Polimorfismo;– Hierarquia.



• Abstração é correlacionada aos objetivos de quem se abstrai;– A abstração do TAD Pessoa depende de seu uso no

sistema;• Pessoa sob a perspectiva de um médico:

• Pessoa sob a perspectiva de cadastro de dados:

26



• Encapsular consiste em incluir, proteger em uma cápsula, classe;

• Encapsular é ocultar do usuário o funcionamento interno de uma classe.



• Proteção de dados visa garantir o acesso apenas sobre operações e atributos disponibilizados pela interface da classe;

• Modificadores de acesso:– Acesso público (public);– Acesso protegido (protected);– Acesso protegido ao pacote (sem modificador de

acesso especificado);– Acesso privado (private);



• Acesso público:– Visível por todos os pacotes;

• Acesso protegido:– Visível somente por classes e subclasses do mesmo pacote

e sub-pacotes;

• Acesso protegido ao pacote:– Visível somente por classes e subclasses do mesmo pacote;

• Acesso privado:– Visível somente a própria classe.



• Todos os atributos e operações de uma classe podem ser acessados pelas operações da mesma classe;

• O acesso aos atributos é, em geral, privado ou protegido;

• O acesso às operações que fazem parte da interface da classe é público.



• Um atributo é uma propriedade de uma classe que descreve um conjunto de valores que as instâncias da classe, objetos, podem atribuir a essa propriedade;

• Representa uma propriedade persistida, em geral;

• Uma classe pode ter um número qualquer de atributos, inclusive zero.



• Um atributo derivado é um atributo cujo valor pode ser calculado baseado no valor de outro(s) atributo(s);

• Geralmente não é um atributo persistido;• É uma decisão de performance x memória

requerida.

27



• Um atributo estático é um atributo cujo valor é compartilhado por todas as instâncias, objetos, da classe;

• O acesso a um atributo estático éindependente de objeto.



• Um atributo não estático possui um valor único para cada objeto, instância da classe;

• O acesso a um atributo não estático édependente de objeto.



• Uma operação é um serviço que pode ser requisitado por qualquer objeto da classe para obter um comportamento;

• Uma classe pode ter um número qualquer de operações, inclusive zero.



• Uma operação abstrata é aquela que não possui um método que a implemente na classe;

• Uma classe que possui uma ou mais operações abtratas é dita classe abstrata.



• Uma operação estática é independente de objeto e acessa apenas atributos estáticos;

• O acesso a operações estáticas éindependente de objeto.



• As classes, no contexto dos sistemas, não trabalham sozinhas;

• As classes colaboram umas com as outras através de relacionamentos;

• O comportamento do sistema é obtido através da interação entre objetos(instâncias das classes);

28




Conceitos OO Objetos (1/2)

• Objetos são conceitos de software que modelam entidades da aplicação;

• Objetos são abstrações de dados;• Objetos tem estado (estrutura interna);• Objetos são manipulados apenas por

operações;• Objetos são instâncias de classes;

– Recordando: Uma classe é a representação de um conjunto de objetos que compartilham os mesmos atributos, operações, relacionamentos e semântica.


Conceitos OO Objetos (2/2)

• Os objetos provêem o comportamento, devendo ser criados apropriadamente;

• Cada objeto representa uma parte do comportamento geral da aplicação:– Objetos (transientes) de computação;– Objetos (persistentes) de banco de dados;– Objetos de interface;


• Classe abstrata:– É uma classe que não possui instâncias diretas, ou

seja, objetos. Apenas suas classes descendentes possuem;

– São úteis para definir uma estrutura comum a várias classes;

– Facilitam a reutilização de código;– Uma operação abstrata numa classe define apenas a

sua forma, não a sua implementação.

Conceitos OO Tipos de estruturas (1/2)


• Interfaces: O propósito de uma interface éencapsular um conjunto de operações oferecidas pela classe;

• É comum apresentarmos na interface apenas parte das operações;

• A interface especifica a assinatura destas operações.

Conceitos OO Tipos de estruturas (2/2)


Conceitos OO Relacionamentos

• Classes isoladas não compõem um Sistema OO;• Os objetos, instâncias de classes, provêem o

comportamento, devendo ser criadosapropriadamente;

• A interação entre os objetos define o comportamentode um Sistema OO;

• Interação entre objetos envolve comunicação entre o mesmos;

• Classes devem definir como é feita a interação:Como?– Através de Relacionamentos.

29


• As classes colaboram umas com as outrasatravés de relacionamentos;

• O comportamento do sistema é obtidoatravés da interação entre objetos(instânciasdas classes);

• Relacionamentos:– Associações;– Agregações e Composições;– Herança;– Dependência.

Conceitos OO Relacionamentos


Conceitos OO Associações (1/2)

• Associações são relacionamentospersistentes entre classes, objetos;

• Conceitualmente associações representamrelações conceituais entre classes;

• Exemplo:– Um pessoa trabalha para uma companhia;– A companhia tem vários escritórios.


Conceitos OO Associações (2/2)

• Relacionamento entre duas ou mais classes:– Associação binária conecta duas classes;

• Relacionamento entre três ou mais classes:– Associação n-ária possui três ou mais classes ligadas

pelo relacionamento;

• Associações reflexivas são associações de uma classe com ela própria (não é umaassociação do objeto com ele mesmo).


Conceitos OOAgregações (1/2)

• Agregação é uma forma especial de associação onde o todo está relacionado àssuas partes;– Ex.: A frase “parte de” é utilizada para descrever o

relacionamento: Grupo de usuários x Usuário.


Conceitos OOAgregações (2/2)

• Uma agregação representa uma propriedadefraca, pois uma classe parte pode estarcontida em outras agregações;

• O todo é chamado de classe forte e a parte de classe fraca;

• Os ciclos de vida de objetos todo e parte sãoindependentes, ou seja, um não depende do outro para existir.

• Agregações reflexivas são agregações de uma classe com ela própria (não é umaagregação do objeto com ele mesmo).


Conceitos OO Composições (1/2)

• Composição é uma forma especial de agregação onde o todo está relacionado àssuas partes;– Ex.: A frase “é composto por” é utilizada para

descrever o relacionamento: Tela x Botões;

• O todo é chamado de classe forte e a parte de classe fraca;

• Os ciclos de vida de objetos todo e parte sãodependentes, ou seja, a parte depende do todo para existir.

30


Conceitos OO Composições (2/2)

• Agregação por composição indica ciclos de vida dependentes: – criar um objeto todo e então criar um objeto

relacionado parte;– Excluir um objeto todo e então excluir um objeto

relacionado parte;

• Composições reflexivas são composiçõesde uma classe com ela própria (não é umacomposição do objeto com ele mesmo).


Conceitos OO Herança (1/3)

• Relacionamento entre classes onde umaclasse compartilha a estrutura e o comportamento de uma ou mais classes;

• Define uma hierarquia de abstrações na quala subclasse herda de uma ou maissuperclasses:– Herança simples;

– Herança múltipla;

• Uma herança é um relacionamento do tipo “éum tipo de”.



• A subclasse herda os atributos, operações e relacionamentos da superclasse;

• Cada subclasse pode definir novos atributose/ou operações;

• Cada subclasse pode redefinir operações da superclasse;

• Cada subclasse pode participar de relacionamentos específicos.



• Como identificar necessidade de heranças?– Procure por similaridades entre as classes;– Siga a regra: a subclasse é um tipo da superclasse;– Evite herança de implementação, siga a regra;

– A herança deve ser total, pela subclasses;

• Caso a regra não seja satisfeita, utilize composição.


Conceitos OO Dependência

• Indica que a mudança em uma classe podecausar mudanças na outra;

• Fatores que levam à dependência entre classes:– Troca de mensagens entre os objetos das classes;– Uma classe tem como atributo outra classe;

• Uma classe aparece como parâmetro naassinatura da operação de outra classe.


Conceitos OOPolimorfismo (1/10)

• Um mesmo objeto pode ser de vários tipos;– Exemplo: Uma Pessoa pode ser um Estudante ou um

Professor;

• Não é viável exigir que todos os outros objetossaibam todos os possíveis tipos de um determinadoobjeto;

• Todos os outros objetos devem reconhecer o objetoatravés de um único tipo;

• Trechos de código para tratamento de diferentestipos são eliminados;

• Através do polimorfismo, instâncias de váriasclasses são tratadas de forma única em um sistema.

31



• Cada tipo reimplementaalguma parte da interface em comum;

• Outros objetos do sistema acessam a interface em comumde forma única;

• O comportamento do objeto serádefinido pelareimplementação contidano objeto.



• Polimorfismo:– Universal:

• Paramétrico:

– Implícito;

– Explícito;

• Inclusão;

– Ad-hoc:• Sobrecarga;

• Coerção.



• Polimorfismo Universal:– A mesma definição de função atua da mesma forma

sobre objetos de diferentes tipos;– Código único atua com todos os tipos de parâmetros;

– Associação de funções polivalentes;– Exemplo:

• write(x) do Pascal.



• Polimorfismo Ad-hoc:– Há um número finito de entidades distintas, todas com

o mesmo nome, mas códigos distintos;– Cada função é escolhida de acordo com o contexto;

– Exemplo: Operador + (soma inteiro, real, concatenastrings).



• Polimorfismo Paramétrico Explícito:– Função atua da mesma forma sobre objetos de

diferentes tipos;– Os tipos dos argumentos são passados como

parâmetros;– Associado a função polivalente;

– Exemplo:• printf do C.



• Polimorfismo Paramétrico Implícito:– Função atua da mesma forma sobre objetos de

diferentes tipos;– Os tipos desses objetos são identificados pelo

compilador, que os passa implicitamente à função;– Exemplo:

• write(x) do Pascal, se x é inteiro imprime inteiro.

32



• Polimorfismo de Inclusão:– Modela subtipos e herança;

– O subtipo está incluído no tipo;

– Onde o objeto de um tipo for esperado, um objeto do subtipodeve ser aceito;

– Exemplo: • desenhar(Figura umaFigura).



• Polimorfismo de Sobrecarga: Um mesmoidentificador denota várias funções queoperam sobre objetos de tipos distintos, semestrutura comum;– Exemplo:

• boolean pesquisa(int[] tabela, int x);

• boolean pesquisa(char[] tabela, char x);

• Polimorfismo de Coerção:Conversãoautomática de tipo para satisfazer o contexto;

– Exemplo: sqrt(6)



• Polimorfismo é umatécnica para aumentaro grau de reuso;

• Semântica de referênciatem papel importanteem polimorfismo:

– Tipo estático;– Tipo dinâmico;

• Polimorfismos de sobrecarga e de inclusão são inerentesa POO.

Documents

Análise e Projeto de Sistemas