Análise e Projeto de Sistemas

Objetivo da Disciplina

• Apresentar os conceitos básicos de análise e
modelagem de sistemas e a importância
destas práticas para os projetos de software.
Análise e Projeto de Sistemas • Apresentar parâmetros de comparação que
possibilitem a identificação da técnica
adequada para cada projeto.
• Capacitar o aluno a elaborar projetos
Aula expositiva 01 detalhados de sistemas através de técnicas
de análise praticadas no mercado, em
especial a Análise Orientada por Objetos
Professor José Luiz Bastos com a utilização do padrão UML (Unified
Modeling Language) e seus diagramas de
representação.
© 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr.

Ementa da Disciplina Ementa da Disciplina
1. FUNDAMENTOS DA ANÁLISE DE SISTEMAS 3. ANÁLISE ORIENTADA A OBJETOS E PADRÃO
1.1 Análise de sistemas e ciclo de vida dos sistemas. UML
1.2 Modelagem de sistemas. 3.1 Conceitos básicos da orientação a objetos.
1.3 Evolução da análise de sistemas. 3.2 Os três pilares da orientação a objetos.
3.3 Linguagem de modelagem unificada – UML.
2. ENGENHARIA DE REQUISITOS 3.4 Modelos da UML.
2.1 Técnicas envolvidas
2.2 Dificuldades 4. MODELAGEM DE SISTEMAS ATRAVÉS DA UML
2.3 Especificação e documentação 4.1 Diagrama de Casos de Uso.
4.2 Diagrama de Classes.
4.3 Diagrama de Seqüência de Casos de Uso.


Ementa da Disciplina Análise de Sistemas - Motivação
5. MODELAGEM DE SISTEMAS ATRAVÉS DA UML • Por que analisar? Por que não começar logo pela
5.1 Diagrama de Colaboração. implementacão?
5.2 Diagrama de Estados. • Análise de sistemas:
– A análise de sistemas é um processo de análise detalhada
5.3 Diagrama de Atividades.
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 requisitos
de 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.


1

Análise de Sistemas - Visão Geral Análise de Sistemas - Visão Geral

• Sistema? Sistemas de Informações
– Um grupo de itens que interagem entre si ou que
sejam interdependentes, formando um todo unificado,
orientado para atender objetivos específicos. • Um sistema de informações é um conjunto
– Um conjunto organizado de doutrinas, idéias ou de elementos inter-relacionados, processos,
princípios, habitualmente previstos para explicar a dados e tecnologia, cuja finalidade é
organização ou o funcionamento de um conjunto
alimentar os centros de decisões com as
sistemático.
– Exemplos:
informações necessárias à escolha de
• Sistema gravitacional diretrizes de ação que permitam atingir os
• Sistema digestivo objetivos da organização.
• Sistema rodoviário
• Sistema bancário



• Dados: Componentes de um Sistema de
Informações:
– São seqüências ordenadas de símbolos dos quais se
pode extrair informações. Porém, não contêm nenhum
significado quando analisados isoladamente.
• Hardware;
• Software;
• Informações: • Pessoas;
• Dados;
– São dados tratados, analisados ou processados, • Procedimentos.
capazes de transmitir algum conhecimento ao
receptor.


Classificação quanto à forma de processamento: Classificação quanto à forma de processamento:

• Sistemas em Tempo Real
• Sistemas Batch – Controla um ambiente pelo recebimento de dados, seu
– O usuário normalmente não interage com o computador por processamento e apresentação dos resultados com rapidez
terminal e as informações são processadas em lotes, de suficiente para afetar o ambiente naquele momento.
forma seqüencial.
• Sistemas Baseados em Conhecimento
– Esses sistemas estão associados ao campo da inteligência
• Sistemas On-Line artificial. Contêm grande quantidade de conhecimentos
– O usuário interage com o computador por terminal, os dados variados para utilização em determinadas tarefas.
de entrada são fornecidos diretamente do local onde eles
foram criados e os resultados do processamento são • Sistemas Especialistas
dirigidos diretamente para onde sejam necessários. – São sistemas baseados em conhecimento. Têm embutidos
o conhecimento e a capacidade que os tornam capazes de
funcionar como um especialista.


2


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, reais
e precisos;
Volumes manipulados: grandes;
Saídas: relatórios analíticos, alguns sintéticos;
Freqüência: periódica;
Exemplos: faturamento, estoque, contabilidade etc.



Sistemas de Apoio à Decisão
Sistemas de Planejamento e Controle Operacional
Nível tático (média gerência);
Nível tático (supervisão);
Apoia processos decisórios;
Apoia o planejamento e controle operacional;
Trabalha com análise matemática e estatística dos
Coleta informações sobre o realizado e compara com
dados;
o previsto;
Origem dos dados: operações internas e fontes
Origem dos dados: operações internas;
externas;
Grau de agregação dos dados: médio;
Grau de agregação dos dados: alto;
Volumes manipulados: médios;
Volumes manipulados: pequenos;
Saídas: relatórios consolidados;
Saídas: gráficos e tabelas;
Freqüência: periódica;
Freqüência: a pedido (ad hoc);
Exemplos: custos, planejamento e controle de
Exemplos: análise de investimentos, análise estatística,
produção, planejamento e controle de projetos.
simulação de cenários.


Sistemas de Planejamento Estratégico Princípios Gerais dos Sistemas:

Nível estratégico (alta administração); • Quanto mais especializado é um sistema,
Apoia análise de fatores críticos de sucesso da menos capaz ele é de se adaptar a
empresa: desempenho, mercado e concorrência; circunstâncias diferentes;
Trabalha com projeções a longo prazo e tendências • Quanto maior for um sistema, maior o
do mercado;
número de seus recursos que serão
Origem dos dados: operações internas e fontes
destinados à manutenção diária;
externas;
Grau de agregação dos dados: alto; • Os sistemas sempre fazem parte de
Volumes manipulados: pequenos; sistemas maiores e sempre podem ser
Saídas: gráficos e tabelas sofisticados; divididos em sistemas menores;
Freqüência: a pedido (ad hoc); • Os sistemas CRESCEM.
Exemplo: sistemas de informações executivas.

3

Análise de Sistemas - Mais definições Problemas
• “A análise de sistemas é frustrante, repleta de relacionamentos
entre pessoas, indefinida e difícil. Resumindo, é fascinante.
• Depende da clareza do usuário:
Depois que você é fisgado, os velhos e fáceis prazeres da – É ele o responsável por mostrar ao analista, de
construção de sistemas nunca mais serão suficientes para maneira clara, quais requisitos o sistema deve
satisfazê-lo.” (DeMarco, 1989) atender.
• “Análise de sistemas é a atividade que tem como finalidade
realizar estudos de processos a fim de encontrar o melhor e • Depende do entendimento do analista:
mais racional caminho para que a informação possa ser
processada.” (Wikipedia) – É ele o responsável por identificar e analisar os
requisitos esperados pelo usuário.
• Análise de sistemas consiste em identificar, detalhar e – Deve documentar de forma clara o seu trabalho, para
documentar os processos de negócio para sua automatização que os consumidores do mesmo saibam identificar os
junto aos usuários. Essa análise deve produzir como resultado
requisitos esperados pelos usuários.
uma especificação completa de tudo que o sistema de
informação deve realizar.


Solução

• Técnicas para identificação e detalhamento
de requisitos

• Técnicas para modelagem de sistemas


Usuários Usuários

• Principais participantes do processo:
– O sistema está sendo desenvolvido PARA ELES. Cada projeto possui um elenco diferente de pessoas
– O sistema automatizará os processos de negócio envolvidas. Um analista de sistemas precisa ter aptidões
executados POR ELES. interpessoais (além do conhecimento da tecnologia), ou
– Comprometimento dos usuários é fundamental para o seja, deve falar com outras pessoas usando uma
sucesso do projeto “linguagem” diferente.


4

Usuários Usuários

Classificação por Tipo de Função
O analista de sistemas deve fazer reuniões regulares
com os usuários (também chamados de clientes ou
Operacionais
proprietários). O ideal seria ter um usuário dedicado
integralmente ao projeto. Alguns defendem que o usuário Têm visão local, isto é, não conhecem o processo de
deveria fazer o projeto. 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 Usuários

Supervisores
Executivos
Podem ou não ter uma visão local;
Não têm experiência operacional;
Geralmente conhecem as operações, pois muitos já
Têm iniciativa sobre o projeto;
foram usuários operacionais. Além disso, têm que
supervisionar os usuários operacionais;
Possuem uma visão global;
Orientados por considerações orçamentárias (ex.:reduzir
Têm preocupações estratégicas;
o quadro de funcionários ou aproveitá-los melhor);
Capazes de lidar com modelos abstratos.
Normalmente, agem como intermediários em relação aos
níveis mais elevados.


Usuários Usuários

Classificação por Nível de Experiência
Novato arrogante
Amador
Participou de alguns projetos;
Nunca trabalhou com um computador;
Possui ou trabalha com computadores;
Tem dificuldade para entender os modelos produzidos
pelos analistas; Por conhecer algumas ferramentas, gosta de opinar
sobre as tecnologias a serem usadas para implementar
Receia ser substituído pelo sistema ou ter sua o sistema (normalmente, tem certeza que opina certo,
importância minimizada. mas opina errado!).


5

Usuários Usuários
Classificação quanto ao conhecimento de
tecnologia:
Experiente – Baixo:
• Não compreende a linguagem técnica
Conhece a análise de sistemas; – Médio
• Tem algum conhecimento tecnológico
Tem experiência de outros projetos;
• Pode perder o foco e se preocupar com a solução
tecnológica
Discute sobre as ferramentas de modelagem sendo
utilizadas. – Alto
• Tem um bom conhecimento tecnológico
• Pode perder o foco e se preocupar muito com
solução tecnológica


Equipe do Projeto Equipe do Projeto

Gerente de Projeto Auditores, Controle de Qualidade e
Padronizadores
As principais funções de um gerente de projeto são:
Podem ser internos ou externos. Responsáveis por
Gerenciar e alocar recursos de toda a equipe técnica; garantir que o sistema será desenvolvido de acordo com
os vários padrões internos e externos da organização,
Prestar constas junto à administração superior;
especialmente aqueles voltados à segurança e ao
Encaminhar problemas identificados no decorrer do controle de qualidade do produto final.
projeto;

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


Equipe do Projeto
Equipe do Projeto

Alguns problemas dos Auditores que devem ser Analistas de sistemas
considerados:

Normalmente não se envolvem no projeto até que ele tenha sido • Analisam, detalham e documentam os
concluído. Nesse ponto, modificar o sistema é muito mais difícil; processos de negócios que serão
Às vezes não estão habituados com a notação utilizada;
automatizados
• Ajudam os usuários a encontrarem as
Geralmente, estão mais interessados na forma do que na
substância. soluções mais apropriadas
• Atuam como mediadores entre os diversos
Verificam conformidades com padrões:
Padrões governamentais
participantes do processo
Padrões internos da empresa
Padrões do processo de desenvolvimento


6


Um analista de sistemas deve ter: O analista desempenha as seguintes funções:

Mediador: como os usuários dificilmente chegam a um consenso, o
Habilidade de relacionamento social; analista deve usar a arte da diplomacia e da negociação. O sistema
deve ser feito da forma como os usuários solicitaram;
Conhecimento da tecnologia; Líder de projeto: Como o analista entrou antes no projeto,
freqüentemente também é o projetista e normalmente é uma pessoa
Conhecimento dos processos de negócio mais experiente, existe uma tendência natural de que ele assuma o
papel de gerente de projeto.

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


Projetistas de Sistemas
Arqueólogo e escriba: deve trazer à luz os detalhes e
documentar as atividades cujos detalhes passam de geração em • Arquitetos do sistema
geração de usuários;
• Recebem o resultado do trabalho dos analistas de sistemas
Inovador: não se limitar apenas a implementar as funções
atuais do sistema mas ajudar a encontrar produtos e mercados • Usam os requisitos levantados para desenhar a arquitetura do
novos; sistema que servirá de base para o trabalho dos
programadores
• Interação constante com os analistas
• Podem verificar a inviabilidade de alguns requisitos



Projetistas de Sistemas
Programador
• O analista de sistemas deve fornecer informações
suficientemente detalhadas para que o projetista elabore um • Responsável por codificar e testar (usando uma
projeto tecnologicamente bom. linguagem de programação) os módulos dos sistemas
modelados pelos projetistas.
• O projetista deve fornecer informações suficientes para que o
analista possa dizer se os requisitos dos usuários podem ser • Em um cenário ideal, o programador não deveria ter
completamente atendidos ou devem ser modificados. contato 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.


7


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 Ciclo de vida de um projeto

• Mais integrantes? Definição:

– Testadores • “Um ciclo de vida de projeto bem definido
– Analistas de usabilidade oferece mecanismos para planejar e
– Engenheiros de processo
acompanhar atividades de forma mais
– Gestores de configuração
precisa, possibilitando a detecção de
– E por aí vai...
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 apresentado
na figura acima? De que forma esses
problemas podem ser solucionados ou pelo
menos minimizados?
2) Esse ciclo de vida pode ser considerado
realístico para projetos de software? Por
quê?
3) De que forma a fase de análise interfere e
sofre interferência das outras etapas?


8

Etapas do ciclo de vida de Fases
desenvolvimento de software
Concepçã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 uma
proposta de especificação.

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.

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

Transição Fase na qual o produto é colocado à disposição de uma
comunidade de usuários para testes finais, treinamento e uso
inicial.


Fluxos Modelos de ciclo de vida
Requisitos Visa obter um conjunto de requisitos de um produto,
Modelo Codifica-Remenda:
acordado entre cliente e fornecedor.

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

Desenho 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.
Implementação Visa detalhar e implementar o desenho através de
componentes de código e de documentação associada.

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


Modelos de ciclo de vida Modelos de ciclo de vida

Modelo Codifica-Remenda: Modelo em cascata:
• As fases são executadas em estrita
sequencia
• Provavelmente o mais usado
• Pouco realiza, não permite erros
• Não exige sofisticação técnica ou gerencial
• Pontos de controle bem definidos facilitam
• Alto risco gestão
• Impossível de gerir • Teoricamente é confiável e utilizável em
• Não permite assumir compromissos projetos de qualquer escala
confiáveis • Rígido e burocrático
• Baixa visibilidade para o usuário, que só
recebe o resultado no final do projeto


9


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



Modelo em espiral: Modelo de entrega evolutiva:
• Software é desenvolvido em uma série de
iterações • Combinação entre o modelo de Espiral e
• Cada nova iteração é um novo ciclo na Cascata
espiral
• Construção é feita de forma incremental
• Utilizado em processos ágeis, como o XP


Projeto – Empresas de pequeno porte Projeto – Empresas de grande porte

• Normalmente é iniciado após um acordo • Existe um processo formal de engenharia de
verbal entre os usuários e a equipe do software
projeto • Existem meios para verificar se o processo
• O desenvolvimento é feito logo após esse está sendo seguido
acordo verbal, geralmente sem a existência • Todos conhecem o processo
de análise. • O gerente é o responsável por organizar o
• Geralmente não existe um processo de projeto de acordo com o processo
desenvolvimento formal. Se existe,
geralmente não é seguido ou verificado.


10

Modelos Modelos

• A criação de um modelo corresponde à • É a partir das especificações dos clientes e
utilização de uma linguagem que possa ser usuários que os modelos serão construídos e
empregada por analistas e compreendida por a partir dos modelos que o produto será
usuários, para representar um sistema. desenvolvido, portanto, o envolvimento do
• Os modelos são os principais produtos da cliente é de fundamental importância nesta
análise e são fundamentais para se obter um etapa. Os modelos podem ser utilizados
produto de software de qualidade, dentro de também para a validação inicial do produto, o
prazos e custos preestabelecidos. que os torna ainda mais importantes.


Modelos

Observação Importante:

• Um analista de sistemas, além de saber Análise e Projeto de Sistemas
construir modelos, deve se aprofundar no
que está sendo modelado, seja um sistema
de matrícula, vendas, controle de estoque,
bancário, etc. Durante a modelagem, o Aula expositiva 02
analista muitas vezes se torna um
especialista na área.
Professor José Luiz Bastos


Fatores de insucesso em projetos de
Premissas
software
Por que os projetos de software são cancelados antes de serem concluídos?
Para desenvolver sistemas úteis, de alta qualidade e
que realmente satisfaçam as necessidades dos Fator de insucesso % dos projetos
usuários, é necessário considerar os seguintes Requisitos incompletos 13,1
aspectos: Falta de envolvimento dos usuários 12,4
Falta de recursos 10,6
Produtividade; Expectativas não-realistas 9,9
Falta de suporte executivo 9,3
Confiabilidade;
Alterações nos requisitos e especificações 8,7
Manutenibilidade. Falta de planejamento 8,1
O software não é mais necessário 7,5
Falta de gerenciamento de TI 6,2
Outros 14,2

11

Engenharia dos Requisitos Engenharia dos Requisitos

• Motivação • Princípios
• Os problemas têm que ser enunciados antes de serem • Boas especificações de requisitos são indispensáveis.
resolvidos. • Não representam custos supérfluos, mas investimentos
necessários.
• Nada é mais caro do que resolver os problemas errados.
• A participação dos usuários na engenharia de requisitos é
• A boa engenharia de requisitos reduz a instabilidade de fundamental para que suas necessidades sejam corretamente
sistemas de informação: atendidas pelo produto.
• Ajuda a obter os requisitos corretos em um estágio anterior • Uma boa especificação de requisitos custa tempo e
ao desenvolvimento. dinheiro;
• O custo de correção de defeitos cresce muito ao longo do • A ausência de uma boa especificação de requisitos custa
tempo. muito mais tempo e dinheiro.


Fase de Elaboração Levantamento dos Requisitos
• Fase na qual a especificação do produto é detalhada
o suficiente para modelar conceitualmente o domínio • Levantamento das funções, interfaces e
do problema, validar os requisitos em termos deste requisitos não-funcionais desejados para o
modelo conceitual e permitir um planejamento produto.
acurado da fase de construção.
• Requisitos levantados apenas em nível
necessário para o estabelecimento de um
• É dividida em duas iterações: entendimento inicial entre usuários, clientes e
desenvolvedores.
• Levantamento dos Requisitos: captura dos requisitos • Levantamento de requisitos focalizando os
junto aos usuários.
usuários.
• Análise dos Requisitos: detalhamento e validação dos
requisitos levantados junto aos usuários. • Método típico:
* oficinas de levantamento de requisitos.

Análise dos Requisitos Análise dos Requisitos

• Detalhamento e análise dos requisitos. • Foco na visão que os desenvolvedores têm
dos requisitos do produto, ainda dentro do
• Modelagem conceitual dos elementos espaço de problema e não do espaço de
relevantes do domínio do problema e uso solução.
desse modelo para validação dos requisitos e
planejamento detalhado da fase de
Construção. • Métodos típicos:
* oficinas de detalhamento de requisitos;
* entrevistas.


12

Técnicas para Levantamento e Análise de Técnicas para Levantamento e Análise de
Requisitos Requisitos
• Freqüentemente, falhas de comunicação e de
entendimento entre a equipe de • Metodologia mais utilizada pelas empresas:
desenvolvimento e clientes envolvidos • Entrevista individual entre o analista de sistemas e os
usuários.
resultam em erros de especificação cuja
• Vantagens:
posterior correção em sistemas já • Praticidade e fácil aplicação.
construídos compromete prazos e custos • Desvantagens:
previstos. • 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
Metodologia JAD

• Técnicas de dinâmica de grupo: • Benefícios:
• Eficazes na agilização do processo; • Redução da necessidade de manutenção nos aplicativos
• Redução nas falhas de comunicação; desenvolvidos com o seu auxílio;
• Metodologia JAD*: • Redução de custos;
• Maior satisfação dos usuários, pois as aplicações atendiam ao
• Uma abordagem usando um líder NEUTRO para
que eles realmente desejavam;
orientar usuários através de um processo interativo
e flexível, obtendo-se CONSENSO sobre um • Maior entrosamento entre a área de Sistemas de Informações
assunto pré-determinado. e os Departamentos Usuários;
• Menor necessidade de modificações durante o processo de
desenvolvimento;
• Nivelamento das expectativas de ambas as partes entre outros.
*Joint Application Design
• Metodologia desenvolvida nos anos 70 pela IBM – Canadá;
• Objetivo inicial: levantamento de requisitos e desenho de
interfaces de sistema;

Metodologia JAD Metodologia JAD

• Com o passar do tempo, JAD passou a ser
utilizado: • Componentes básicos de um JAD:
• Em todas as fases do cliclo de desenvolvimento de software • Patrocinador do projeto:
e não apenas durante o levantamento de requisitos (Joint
Application Development);
• Possui poder de decisão e fornece os recursos
necessários para o projeto.
• Planejamento de projetos em geral;
• Planejamento estratégico;
• Líder da sessão:
• Tomada de decisões, de qualquer natureza, que necessita • Responsável por conduzir a sessão de forma
de um consenso entre várias pessoas das diversas áreas de NEUTRA.
uma organização (Workshops). • Documentador:
• Responsável por redigir as decisões tomadas em
ata;


13

Metodologia JAD Metodologia JAD

• Componentes básicos de um JAD: • Por que usar JAD?
• Usuários finais: • Redução do tempo de desenvolvimento do software;
• Conhecedores do negócio da aplicação; • Aumento da qualidade do software;
• Aumento da produtividade;
• Definem as necessidades do sistema em nível
• Redução do custo;
apropriado de detalhes;
• Maior motivação e comprometimento da equipe;
• Desenvolvedores:
• Redução de alteração de requisitos;
• Tomam conhecimentos das necessidades dos • Visão global do sistema pelos envolvidos;
usuários finais e da aplicação durante a sessão de
JAD;
• Respondem questões técnicas;


Metodologia JAD Oficina de Requisitos

• Sucesso de um JAD depende:
• Liderança da sessão de forma eficiente; • Definição do Local:
• Participação de usuários finais, executivos e ☺ Afastado do local de trabalho, onde os
desenvolvedores;
participantes não possam ser interrompidos;
• Alcance da sinergia do grupo durante a sessão.
☺ Sem interferências externas (celular, bip, etc...);
☺ Baixo nível de ruído;
☺ Mesas arrumadas em “U” (se possível);
☺ Serviço de café.


Principais Problemas no Principais Problemas no
Desenvolvimento de Sistemas Desenvolvimento de Sistemas

Demanda reprimida
Problemas de Produtividade
O backlog dos sistemas pode ser dividido em três
Os dois aspectos mais importantes desse problema categorias:
são:
• Visível:
A demanda reprimida (backlog) por novos sistemas;
Sistemas solicitados oficialmente pelos usuários e que
O tempo necessário para construir um novo sistema. foram aceitos e tiveram suas verbas aprovadas pela
gerência. Ainda não foram iniciados por falta de
recursos humanos (analistas, programadores etc.).


14


• Invisível: Tempo de desenvolvimento

Sistemas que os usuários sabem que precisam, mas não Existe a preocupação com a perda de oportunidades de
se dão ao trabalho de solicitar oficialmente, porque ainda negócios, devido à incapacidade de desenvolver os
estão aguardando outros projetos. sistemas de apoio necessários no tempo necessário.
Muitos projetos nem são terminados. Dentre os principais
• Desconhecido: motivos para estouro de tempo em projetos, podemos
citar:
Sistemas que os usuários ainda não sabem que precisam
mas que emergirão logo que sejam concluídos outros Problemas técnicos;
sistemas dos backlogs visível e invisível.



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

Inexperiência da equipe; Contratação de mais programadores e analistas de
sistemas;
Falta de tempo para análise e projeto;
Contratação de programadores e analista de sistemas
Escasso envolvimento por parte da gerência ou mais talentosos, oferecendo-lhes melhores condições de
usuários. trabalho;



Razões para os analistas terem ciência dos
Deixar que usuários desenvolvam seus próprios problemas de produtividade:
sistemas;
A produtividade e qualidade do trabalho dos
Melhores linguagens de programação; programadores está diretamente ligada ao serviço feito
pelo analista;
Ferramentas automatizadas de desenvolvimento.
Algumas das técnicas de aumento de produtividade
têm importância direta para os analistas;


15


Problemas de Confiabilidade

A produtividade da análise é um problema politicamente Os erros em sistemas podem passar desapercebidos (ex.:
sensível; uma impressão de relatório não formatada corretamente)
ou causar graves acidentes (problema em sistema de
Usuários e gerente têm ansiedade pelo início da tráfego aéreo).
programação;
Os erros em software são difíceis de serem extintos
Usuários não entendem a importância da especificação. porque:

É difícil descobrir como solucionar o erro;



A figura 1 mostra o número de erros encontrados em
Deve-se encontrar todos os pontos de correção;
função do tempo decorrido (YOURDON, 1990).
Alta probabilidade de introduzir novos erros (efeitos
colaterais);

Nem sempre são reportados pelos usuários;

Dificuldade de reproduzir o erro.

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


Manutenibilidade
Sobre a curva na figura 1 é importante notar:
A correção de erros é apenas um dos aspectos da
Inicialmente o nº de erros encontrados é pequeno (usuários sem
segurança para apontar erros), como indica T1;
manutenção de sistemas. A manutenção também está
vinculada a fatores como:
À medida que os usuários se familiarizam com sistema os erros são
percebidos e reportados (entre T1 e T2); Modificações no hardware;

Após um tempo (após T2) o nº de erros encontrados começa a Novos dispositivos;
diminuir (sistema começa a tornar-se mais estável);
Necessidade de melhorar o desempenho;
O número de erros volta a crescer devido a correções ou modificações
que introduzem novos erros (após T3); Garantir maior confiabilidade;

A curva nunca atinge zero. Alterações dos requisitos.

16


A manutenção de um sistema deve ser sempre Outros Problemas – Portabilidade
acompanhada de modificações na especificação do
sistema. Entretanto, isso nem sempre ocorre devido a Consiste em escrever sistemas que podem ser
fatores como: transferidos para outras plataformas;

Analista alocado para outro projeto; Apesar de não ser um problema da alçada do analista,
ele deve especificar que há essa necessidade;
Urgência na implantação das modificações;
A portabilidade geralmente provoca ineficiência já que
Inexistência de uma política que valorize a recursos disponíveis de determinada plataforma não são
manutenção da especificação. aproveitados.



Principais causas dos Problemas
Outros Problemas – Segurança

À medida que os sistemas de informações crescem em Ausência de Planejamento de Sistemas;
número e importância, o risco de violações aumenta.
Ausência de Administração de Dados;
A segurança de sistemas de informações consiste
basicamente em: Não utilização de Métodos e Técnicas Formais
de Desenvolvimento;
Impedir o acesso de pessoas não autorizadas;
Não utilização de Técnicas e Ferramentas;
Conceder acesso a certas funcionalidades apenas a
algumas pessoas. Adoção de Metodologias não ambientadas à
realidade da empresa;


Principais causas dos Problemas(cont.) Nota Especial Sobre Qualidade

Falta de definição precisa dos objetivos e A qualidade de um sistema pode ser mensurada
requisitos do sistema; considerando a eficácia e a eficiência obtidas:

Dificuldade de comunicação e/ou falta de Eficácia = Resultados Obtidos / Resultados Pretendidos
entrosamento entre as pessoas envolvidas no
processo, causada por problemas de linguagem Eficiência = Resultados Obtidos / Recurso Consumido
ou rivalidade entre usuários;

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


17

Principais Problemas no Identificação, análise e gerência de
Desenvolvimento de Sistemas requisitos

Problemas que denotam falta de qualidade em 1 Técnicas de Entrevistas e de Coleta de Dados
sistemas:
Por que e para que fazemos entrevistas ?
Não contribuem para os objetivos da empresa;
Para coletar informações armazenadas em cérebros sobre o
comportamento de um sistema atual ou um novo sistema;
Não atendem às necessidades dos usuários;
Para verificar como compreendemos o comportamento de
Não são confiáveis; um sistema;

Para elaborar um estudo de viabilidade de desenvolvimento
São ineficientes; de um sistema.

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


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

2 Tipos de Entrevistas 3 Problemas ao Entrevistar Usuários

Entrevista em forma de reunião pessoal; Entrevistar a pessoa errada no momento errado;

Entrevista em forma de questionários abertos e fechados; Fazer perguntas erradas e obter respostas erradas;

Gravação de descrição de expectativas do usuário em relação Criar ressentimentos recíprocos.
ao sistema.


4 Diretrizes para a realização de entrevistas

Desenvolva um plano geral de entrevista; 5 Possíveis Formas de Resistência na Entrevista
Certifique-se de que você tem autorização para falar com os
Você está tomando muito o meu tempo;
usuários;
Você está ameaçando o meu emprego;
Planejar a entrevista para fazer uso eficiente do tempo;

Utilize ferramentas automatizadas que sejam adequadas, mas não Você não conhece nossa empresa e ainda quer nos dizer como deve
abuse; ser feito o novo sistema?

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


18


6 Outros Problemas a Enfrentar
5 Possíveis Formas de Resistência na Entrevista(cont.)
Uma discussão que focalize mais os problemas de
Você está tentando mudar o modo como as coisas são feitas implementação do que os problemas de requisitos;
aqui;
Confusão entre sintomas e problemas;
Nós, usuários, não queremos este sistema;
O usuário pode ser incapaz de explicar o que ele quer que o
Por que você está desperdiçando nosso tempo com esta sistema faça ou pode mudar de opinião;
entrevista?
Desentendimento entre usuários de mesmo nível, subordinados e
chefes.



7 Formas Complementares de Coleta de Dados Requisitos Funcionais: Descrevem a funcionalidade
ou os serviços que se espera que o sistema forneça.
Demonstrações feitas pelos fornecedores; Descrevem a função de sistema detalhadamente, suas
entradas e saídas, excessões, etc. Exemplos:
Visitas a outras empresas com sistemas semelhantes;
“O sistema deve permitir que cada professor realize o
Coleta de dados em manuais, formulários, relatórios, listagens de lançamento de notas das turmas nas quais lecionou”;
programas, etc.;
“O sistema deve permitir que um aluno realize a sua
Pesquisa externa em instituições como IEEE e ACM. matrícula nas disciplinas oferecidas em um semestre”;

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



Requisitos Não Funcionais:
Requisitos Não Funcionais: São aqueles que não
dizem respeito diretamente às funções específicas
Requisitos não
fornecidas pelo sistema. Eles podem estar relacionados funcionais

a propriedades de sistemas emergentes, como
confiabilidade, tempo de resposta e espaço em disco. Requisitos do Requisitos Requisitos
produto organizacionais externos
Alternativamente, podem definir restrições para o
sistema, como por exemplo, a capacidade dos
Facilidade Confiabili Portabili Interopera
dispositivos de E/S e as representações de dados de uso
Eficiência
dade dade bilidade
Legais Éticos

utilizados nas interfaces de sistema.
Desempe Privacida Seguran
Espaço
nho de ça

Implemen
Entrega Padrões
tação


19

Requisitos de Usuário:
Requisitos de Sistema:
São os requisitos que descrevem os requisitos funcionais e não
funcionais de modo compreensível pelos usuários do sistema que São descrições mais detalhadas dos requisitos de
não têm conhecimentos técnicos detalhados. Como redigí-los ? usuários. Estes requisitos podem ser descritos utilizando-
se:
Utilize um formato-padrão e certifique-se de que todas as
definições de requisitos estejam conforme este formato; (1) Linguagem natural estruturada – depende de formulários padrão;
Utilize a linguagem de modo consistente. Em particular, faça uma (2) Linguagem de descrição de projeto – usando linguagens de
distinção entre os requisitos obrigatórios e os que são desejáveis; programação como exemplo para descrever os requisitos;
Evite, tanto quanto possível, o uso de jargões de informática. (3) Notações gráficas – usando diagramas em geral (casos de uso,
Contudo, inevitavelmente, ocorerrá que termos técnicos detalhados, atividades, seqüência, etc);
utilizados no domínio da aplicação do sistema, sejam incluidos nos
requisitos do usuário. (4) Especificações matemáticas – como uma máquina de estados
finitos (de acordo com a transição de estados).

Observações Sobre os Requisitos:

Volatilidade dos requisitos: atualmente, a Documento de Requisitos:
volatilidade é mais uma regra que uma exceção. Os
requisitos mudam rapidamente atualmente, novos O documento de requisitos – às vezes chamado ER -
requisitos podem ser adicionados e outros removidos Especificação de Requisitos de software – é a
durante o processo. declaração oficial do que é exigido dos desenvolvedores
de sistema. Ele deve incluir os requisitos de usuário para
É importante ressaltar que, com a complexidade um sistema e uma especificação detalhada dos
dos sistemas atuais, é impossível pensar em todos os requisitos de sistema (SOMMERVILE, 2003).
detalhes do sistema a princípio.


Usuários do Documento de Requisitos:
Requisitos de um Documento de Requisitos:
Especificam os requisitos e os lêem para verificar
Clientes do Sistema se eles atendem a suas necessidades. Especificam
as mudanças nos requisitos. Segundo Heninger (1980), um documento de requisitos de software deveria
satisfazer a seis princípios:
Utilizam o documento de requisitos para planejar
Gerentes um pedido de proposta para o sistema e para
planejar o processo de desenvolvimento.
Deveria especificar somente o comportamento externo do sistema;

Deveria especificar as restrições à implementação;
Engenheiros de Sistema Utilizam os requisitos para compreender que
sistema deve ser desenvolvido.
Deveria ser fácil de ser modificado;
Engenheiros de teste de Deveria servir como uma ferramenta de referência para os responsáveis pela
Utilizam os requisitos para desenvolver testes de
Sistema validação para o sistema. manutenção do sistema;
Deveria registrar a estratégia sobre o ciclo de vida do sistema;
Engenheiros de Utilizam os requisitos para ajudar a compreender Deveria caracterizar respostas aceitáveis para eventos indesejáveis.
manutenção de Sistema o sistema e as relações entre suas partes.


20

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

Referências Bibliográficas:
Análise e Projeto de Sistemas
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. Aula expositiva 03
Addison Wesley, 2003.

YOURDON, Edward. Análise Estruturada Moderna. 3ª ed. São Paulo:
Campus, 1990. Professor José Luiz Bastos


Análise Orientada a Objetos -
Sistemas orientados a objetos
Objetivos
• Apresentar para os alunos o significado de ser • “Sob um ponto de vista superficial, dizer que
orientado a objetos e os conceitos que permeiam um software é orientado a objetos significa
este paradigma de desenvolvimento de sistemas, a
dizer que o software é organizado como uma
saber: objetos, classes, mensagens, abstração,
encapsulamento, herança e polimorfismo, bem como coleção de objetos separados que
a importância de cada um deles para este incorporam tanto a estrutura quanto o
paradigma. comportamento dos dados, contrastando
• A UML – Linguagem de Modelagem Unificada – é com a programação convencional, em que a
uma linguagem de modelagem de sistemas estrutura e o comportamento dos dados
orientados a objetos que se consagrou no mercado apresentam pouco vínculo entre si.”
como padrão e que será apresentada como forma de
representação destes sistemas.


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

• “Isso corresponde a dizer que os elementos – Engenharia: Arte de aplicar conhecimentos científicos
e empíricos e certas habilitações específicas à criação
da OO são independentes, ou que devem ser de estruturas, dispositivos e processos que se utilizam
criados da forma mais independente para converter recursos naturais em formas
possível, para que possam ser reutilizados adequadas ao atendimento das necessidades
posteriormente.” humanas;

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


21

Introdução a OO Filosofia (2/4) Introdução a OO Filosofia (3/4)

– Qualidade de software: Um dos principais objetivos – Fatores de qualidade externos:
da Engenharia de Software é ajudar a produção de – Correção;
software de boa qualidade; – Robustez;
– Extensibilidade;
– Reusabilidade;
– Fatores de qualidade do software: – Eficiência;
– Compatibilidade;
• Externos;
– Facilidade de uso;
• Internos. – Portabilidade;
– Integridade;
– Verificabilidade;

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


Introdução a OO Filosofia (4/4)
Introdução a OO Paradigma (1/10)
• Custos de manutenção de software: Cerca de 70% • Normalmente o desenvolvimento de software
do custo de um software é manutenção;
é feito dentro de um projeto;
• Exemplo de distribuição: • Todo projeto tem uma data de início, uma
– Mudanças na especificação: 41,8%;
– Mudanças no formato dos dados: 17,4%;
data de fim, uma equipe e outros recursos;
– Consertos de emergências: 12,4%; • Foco de análise, ótica:
– Depuração: 9,0%;
– Construção, desenvolvimento, implementação.
– 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 (2/10) Introdução a OO Paradigma (3/10)

• Projeto tem por objetivo construir a ponte • Projeto estruturado top-down:
entre a especificação de uma aplicação e a – Produz uma arquitetura baseada somente na função
implementação sob o modelo computacional; do sistema;
– Cada componente do sistema refina ou decompõe
• Métodos de projeto: funções;
– Projeto estruturado top-down; – Decomposição pára quando o nível de abstração da
– Projeto orientado por dados. 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.

22


• 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 • Projeto orientado por dados:
vários serviços que oferecem; – Atenção voltada para as Estruturas de Dados
envolvidas na Especificação da Aplicação;
• Exemplo: Um sistema operacional oferece – Exemplo: serviço de cadastro de usuários em um
serviços de: sistema:
• Usuário, Grupo de usuários, Perfil de usuários –>
– Gerência de processamento;
Estruturas de Dados;
– Gerência de memória;
– Entrada e saída;
– Interpretação de comandos; • Entretanto, foco inteiramente voltado para
– Impressão.
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;


23

Conceitos OO
Introdução a OO Paradigma (10/10) Projeto OO
• Implicações: • Projeto OO é o método que produz
– Necessidade de técnicas de organização de software arquiteturas de software baseadas nos
que privilegiem: objetos que o sistema manipula;
• Extensibilidade; • A propriedade básica do método:
• Reusabilidade; – Evite perguntar: O que o sistema faz?
– Necessidade de técnicas que suportem o – Melhor perguntar: Sobre o que o sistema faz o que?
desenvolvimento sistemático de software, garantindo:
• Correção;
• Robustez; • Olhar primeiro para o dado é a regra que
– Fatores externos de qualidade são primordiais, mas só favorece a reusabilidade;
podem ser alcançados por meio de fatores internos: • Descrição de objetos deve ser: completa,
• Modularidade; precisa, não ambígüa e independente de
• Orientação por objetos. representação física.

Conceitos OO Conceitos OO
Tipos abstratos de dados 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.


Tipos abstratos de dados Programação OO
• A representação das estruturas de dados do • Programação OO é a construção de sistemas
TAD fica completamente encapsulada; de software como uma coleção estruturada
de implementações de tipos abstratos de
• A representação das estruturas de dados do
dados;
TAD não faz parte de sua definição;
• Tipos abstratos de dados:
• O adjetivo abstrato de um tipo abstrato de – Módulos, pacotes, são construídos com base em
dados enfatiza o fato de as estruturas de abstrações de dados (classes);
dados que representam o tipo não fazerem • Coleção:
parte da definição, isto é, da interface do – Metodologia baseada na montagem bottom-up de
classes existentes;
tipo.
• Estruturada:
– Relação Cliente-servidor e de hierarquia entre
classes.


24

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


Encapsulação Classes (1/16)
• Encapsulação consiste em ocultar o • Classe éum conceito de softwareque descreve a
funcionamento interno de uma classe; implementação de um TAD;
• Uma classe define:
• O acesso aos serviços oferecidos é feito via
– A estrutura de dados que representa o TAD;
interface, independentemente do – A implementação das operações, métodos, sobre esta
funcionamento interno de uma classe; 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 (2/16) Classes (3/16)
• Classes suportam os conceitos de: • Abstração é correlacionada aos objetivos de
– Abstração; quem se abstrai;
– Encapsulação; – A abstração do TAD Pessoa depende de seu uso no
– Proteção de dados; sistema;
– Polimorfismo; • Pessoa sob a perspectiva de um médico:
– Hierarquia.

• Pessoa sob a perspectiva de cadastro de dados:


25

• Encapsular consiste em incluir, proteger em • Proteção de dados visa garantir o acesso
uma cápsula, classe; apenas sobre operações e atributos
• Encapsular é ocultar do usuário o disponibilizados pela interface da classe;
funcionamento interno de uma 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: • Todos os atributos e operações de uma
– Visível por todos os pacotes; classe podem ser acessados pelas
operações da mesma classe;
• Acesso protegido:
• O acesso aos atributos é, em geral, privado
– Visível somente por classes e subclasses do mesmo pacote
e sub-pacotes; ou protegido;
• O acesso às operações que fazem parte da
• Acesso protegido ao pacote: interface da classe é público.
– Visível somente por classes e subclasses do mesmo pacote;

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


• Um atributo é uma propriedade de uma • Um atributo derivado é um atributo cujo
classe que descreve um conjunto de valores valor pode ser calculado baseado no valor de
que as instâncias da classe, objetos, podem outro(s) atributo(s);
atribuir a essa propriedade; • Geralmente não é um atributo persistido;
• Representa uma propriedade persistida, em • É uma decisão de performance x memória
geral; requerida.
• Uma classe pode ter um número qualquer de
atributos, inclusive zero.


26

• Um atributo estático é um atributo cujo valor • Um atributo não estático possui um valor
é compartilhado por todas as instâncias, único para cada objeto, instância da classe;
objetos, da classe; • O acesso a um atributo não estático é
• O acesso a um atributo estático é dependente de objeto.
independente de objeto.


• Uma operação é um serviço que pode ser • Uma operação abstrata é aquela que não
requisitado por qualquer objeto da classe possui um método que a implemente na
para obter um comportamento; classe;
• Uma classe pode ter um número qualquer de • Uma classe que possui uma ou mais
operações, inclusive zero. operações abtratas é dita classe abstrata.


• Uma operação estática é independente de • As classes, no contexto dos sistemas, não
objeto e acessa apenas atributos estáticos; trabalham sozinhas;
• O acesso a operações estáticas é • As classes colaboram umas com as outras
independente de objeto. através de relacionamentos;
• O comportamento do sistema é obtido
através da interação entre objetos(instâncias
das classes);


27

Classes (16/16) 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.


Objetos (2/2) Tipos de estruturas (1/2)
• Os objetos provêem o comportamento, • Classe abstrata:
devendo ser criados apropriadamente; – É uma classe que não possui instâncias diretas, ou
seja, objetos. Apenas suas classes descendentes
• Cada objeto representa uma parte do possuem;
comportamento geral da aplicação: – São úteis para definir uma estrutura comum a várias
– Objetos (transientes) de computação; classes;
– Objetos (persistentes) de banco de dados; – Facilitam a reutilização de código;
– Objetos de interface; – Uma operação abstrata numa classe define apenas a
sua forma, não a sua implementação.


Tipos de estruturas (2/2) Relacionamentos
• Interfaces: O propósito de uma interface é • Classes isoladas não compõem um Sistema OO;
encapsular um conjunto de operações • Os objetos, instâncias de classes, provêem o
oferecidas pela classe; comportamento, devendo ser criados
apropriadamente;
• É comum apresentarmos na interface apenas
• A interação entre os objetos define o comportamento
parte das operações; de um Sistema OO;
• A interface especifica a assinatura destas • Interação entre objetos envolve comunicação entre o
operações. mesmos;
• Classes devem definir como é feita a interação:
Como?
– Através de Relacionamentos.


28

Relacionamentos Associações (1/2)
• As classes colaboram umas com as outras • Associações são relacionamentos
através de relacionamentos; persistentes entre classes, objetos;
• O comportamento do sistema é obtido • Conceitualmente associações representam
através da interação entre objetos(instâncias relações conceituais entre classes;
das classes); • Exemplo:
• Relacionamentos: – Um pessoa trabalha para uma companhia;
– Associações; – A companhia tem vários escritórios.
– Agregações e Composições;
– Herança;
– Dependência.


Associações (2/2) Agregações (1/2)
• Relacionamento entre duas ou mais classes: • Agregação é uma forma especial de
– Associação binária conecta duas classes; associação onde o todo está relacionado às
suas partes;
• Relacionamento entre três ou mais classes: – Ex.: A frase “parte de” é utilizada para descrever o
– Associação n-ária possui três ou mais classes ligadas relacionamento: Grupo de usuários x Usuário.
pelo relacionamento;

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


Agregações (2/2) Composições (1/2)
• Uma agregação representa uma propriedade • Composição é uma forma especial de
fraca, pois uma classe parte pode estar agregação onde o todo está relacionado às
contida em outras agregações; suas partes;
• O todo é chamado de classe forte e a parte – Ex.: A frase “é composto por” é utilizada para
de classe fraca; descrever o relacionamento: Tela x Botões;
• Os ciclos de vida de objetos todo e parte são
independentes, ou seja, um não depende do • O todo é chamado de classe forte e a parte
outro para existir. de classe fraca;
• Os ciclos de vida de objetos todo e parte são
• Agregações reflexivas são agregações de dependentes, ou seja, a parte depende do
uma classe com ela própria (não é uma todo para existir.
agregação do objeto com ele mesmo).

29

Composições (2/2) Herança (1/3)
• Agregação por composição indica ciclos de • Relacionamento entre classes onde uma
vida dependentes: classe compartilha a estrutura e o
– criar um objeto todo e então criar um objeto comportamento de uma ou mais classes;
relacionado parte;
• Define uma hierarquia de abstrações na qual
– Excluir um objeto todo e então excluir um objeto
relacionado parte; a subclasse herda de uma ou mais
superclasses:
– Herança simples;
• Composições reflexivas são composições
– Herança múltipla;
de uma classe com ela própria (não é uma
composição do objeto com ele mesmo). • Uma herança é um relacionamento do tipo “é
um tipo de”.


Herança (2/3) Herança (3/3)
• A subclasse herda os atributos, operações e • Como identificar necessidade de heranças?
relacionamentos da superclasse; – Procure por similaridades entre as classes;
• Cada subclasse pode definir novos atributos – Siga a regra: a subclasse é um tipo da superclasse;
– Evite herança de implementação, siga a regra;
e/ou operações;
– A herança deve ser total, pela subclasses;
• Cada subclasse pode redefinir operações da
• Caso a regra não seja satisfeita, utilize
superclasse;
composição.
• Cada subclasse pode participar de
relacionamentos específicos.


Dependência Polimorfismo (1/10)
• Indica que a mudança em uma classe pode • Um mesmo objeto pode ser de vários tipos;
causar mudanças na outra; – Exemplo: Uma Pessoa pode ser um Estudante ou um
Professor;
• Fatores que levam à dependência entre • Não é viável exigir que todos os outros objetos
classes: saibam todos os possíveis tipos de um determinado
– Troca de mensagens entre os objetos das classes; objeto;
– Uma classe tem como atributo outra classe; • Todos os outros objetos devem reconhecer o objeto
• Uma classe aparece como parâmetro na através de um único tipo;
assinatura da operação de outra classe. • Trechos de código para tratamento de diferentes
tipos são eliminados;
• Através do polimorfismo, instâncias de várias
classes são tratadas de forma única em um sistema.


30

Polimorfismo (2/10) Polimorfismo (3/10)
• Cada tipo reimplementa • Polimorfismo:
alguma parte da interface – Universal:
em comum; • Paramétrico:
– Implícito;
• Outros objetos do – Explícito;
sistema acessam a • Inclusão;
interface em comum – Ad-hoc:
de forma única; • Sobrecarga;
• Coerção.

• O comportamento do
objeto serádefinido pela
reimplementação contida
no objeto.

• Polimorfismo Universal: • Polimorfismo Ad-hoc:
– A mesma definição de função atua da mesma forma – Há um número finito de entidades distintas, todas com
sobre objetos de diferentes tipos; o mesmo nome, mas códigos distintos;
– Código único atua com todos os tipos de parâmetros; – Cada função é escolhida de acordo com o contexto;
– Associação de funções polivalentes; – Exemplo: Operador + (soma inteiro, real, concatena
– Exemplo: strings).
• write(x) do Pascal.


• Polimorfismo Paramétrico Explícito: • Polimorfismo Paramétrico Implícito:
– Função atua da mesma forma sobre objetos de – Função atua da mesma forma sobre objetos de
diferentes tipos; diferentes tipos;
– Os tipos dos argumentos são passados como – Os tipos desses objetos são identificados pelo
parâmetros; compilador, que os passa implicitamente à função;
– Associado a função polivalente; – Exemplo:
– Exemplo: • write(x) do Pascal, se x é inteiro imprime inteiro.
• printf do C.


31

• Polimorfismo de Inclusão: • Polimorfismo de Sobrecarga: Um mesmo
– Modela subtipos e herança; identificador denota várias funções que
operam sobre objetos de tipos distintos, sem
– O subtipo está incluído no tipo; estrutura comum;
– Exemplo:
– Onde o objeto de um tipo for • boolean pesquisa(int[] tabela, int x);
esperado, um objeto do subtipo • boolean pesquisa(char[] tabela, char x);
deve ser aceito;
• Polimorfismo de Coerção:Conversão
– Exemplo: automática de tipo para satisfazer o contexto;
• desenhar(Figura umaFigura).

– Exemplo: sqrt(6)


Conceitos OO
Polimorfismo (10/10)
• Polimorfismo é uma
técnica para aumentar
o grau de reuso;

• Semântica de referência
tem papel importante
em polimorfismo:
– Tipo estático;
– Tipo dinâmico;

• Polimorfismos de
sobrecarga e de
inclusão são inerentes
a POO.

© 2008 José Luiz G. Bastos Jr.

32

Análise e Projeto de Sistemas

Mais conteúdo relacionado

Mais procurados

Destaque

Semelhante a Análise e Projeto de Sistemas

Análise e Projeto de Sistemas