Beruflich Dokumente
Kultur Dokumente
ENGENHARIA DE SOFTWARE II
Simone Maria Viana Romano
ENGENHARIA DE SOFTWARE
Sumrio
INFORMAES IMPORTANTES .................................................................................................................... 7
OBJETIVOS: .................................................................................................................................................. 7
Sugesto de Livros, Revistas e Sites ............................................................................................................... 7
Softwares ......................................................................................................................................................... 7
Quantidade de aulas semanais e Quantidade de faltas permitidas ............................................................... 7
Abono de Faltas .............................................................................................................................................. 8
Contato ............................................................................................................................................................ 8
Avisos .............................................................................................................................................................. 8
Contedo das Avaliaes ................................................................................................................................ 8
Forma de Avaliao........................................................................................................................................ 8
Disciplinas, Dias e Horrios que me encontro na Fatec ............................................................................... 8
Erros da Apostila: ........................................................................................................................................... 8
TRABALHO SEMESTRAL................................................................................................................................. 9
TAREFA 01 - REVISO DE ENGENHARIA DE SOFTWARE I (VALOR : 0,5) ........................................... 10
DESENVOLVIMENTODESOFTWARE.................................................................................................. 14
1BIMESTRE
REQUISITOSDESOFTWARE................................................................................................................................... 16
IMPORTNCIA DOS REQUISITOS............................................................................................................... 17
QUALIDADE DOS REQUISITOS ................................................................................................................... 18
TIPOS DE REQUISITOS .................................................................................................................................. 19
EXEMPLO DE REQUISITOS FUNCIONAIS ............................................................................................... 20
EXEMPLO DE REQUISITOS NO FUNCIONAIS ...................................................................................... 20
EXEMPLO DE REQUISITOS DE DOMINIO ............................................................................................... 20
PROBLEMAS COMUNS NOS REQUISITOS ............................................................................................... 20
CLASSES DE REQUISITOS .......................................................................................................................... 20
ENGENHARIADEREQUISITOS............................................................................................................................... 21
OBJETIVOS DA ENGENHARIA DE REQUISITOS ...................................................................................... 22
TAREFA 02 - QUESTES DE REQUISITOS (0,5) ...................................................................................... 23
ELICITAODEREQUISITOS................................................................................................................................. 26
OBJETIVOS DA ELICITAO DE REQUISITOS ........................................................................................ 28
PASSOS PARA A ELICITAO DE REQUISITOS....................................................................................... 28
QUESTES QUE PRECISAM SER RESPONDIDAS ..................................................................................... 29
DOCUMENTAO DO ELICITAO DE REQUISITOS ............................................................................ 29
IDENTIFICAO E ELICITAO DE REQUISITOS .................................................................................. 30
IDENTIFICAO DOS REQUISITOS ......................................................................................................... 30
PROBLEMAS NA IDENTIFICAO DOS REQUISITOS ............................................................................ 31
EXEMPLO DE DECLARAO DO PROBLEMA ........................................................................................ 31
CARACTERSTICAS DA ELICITAO DE REQUISITOS.......................................................................... 31
DIFERENA ENTRE UMA BOA E UMA M ELICITAO DE REQUISITOS ......................................... 32
TAREFA 03 ELICITAO DE REQUISITOS (0,5) ................................................................................... 33
TCNICAS PARA ELICITAO DE REQUISITOS ................................................................................... 34
ETNOGRAFIA ................................................................................................................................................. 36
ENTREVISTAS ................................................................................................................................................ 37
Etapas ............................................................................................................................................................ 37
Forma de Entrevistar .................................................................................................................................... 37
Perguntas que devem ser respondidas .......................................................................................................... 37
BRAINSTORMING .......................................................................................................................................... 38
BRAINSWRITING ........................................................................................................................................... 39
EXERCCIOS ................................................................................................................................................ 40
JAD ....................................................................................................................................................................... 41
ENGENHARIA DE SOFTWARE
ENGENHARIA DE SOFTWARE
CONCEITO ....................................................................................................................................................... 92
UTILIZAO ................................................................................................................................................... 93
NOTAO ....................................................................................................................................................... 94
VANTAGENS ....................................................................................................................................................... 94
FASES DO DESENVOLVIMENTO UML ....................................................................................................... 94
COMPONENTES DA UML ...................................................................................................................................... 95
MODELOS DE ELEMENTOS ......................................................................................................................... 95
CLASSES ....................................................................................................................................................... 95
OBJETOS ...................................................................................................................................................... 95
ESTADOS ...................................................................................................................................................... 96
PACOTES ...................................................................................................................................................... 96
COMPONENTES .......................................................................................................................................... 96
RELACIONAMENTOS .................................................................................................................................. 97
MECANISMOS GERAIS ............................................................................................................................. 101
DIAGRAMAS ..................................................................................................................................................... 101
DIAGRAMAS ESTRUTURAIS (ESTTICOS) ............................................................................................. 101
DIAGRAMAS COMPORTAMENTAIS (DINMICOS) ............................................................................... 102
EXERCCIOS .............................................................................................................................................. 103
DIA PORTABLE ............................................................................................................................................... 105
MICROSOFT VISIO 2003 ............................................................................................................................... 107
DIAGRAMA DE MODELO UML ............................................................................................................................ 107
ENGENHARIA DE SOFTWARE
ENGENHARIA DE SOFTWARE
ENGENHARIA DE SOFTWARE
INFORMAES IMPORTANTES
OBJETIVOS:
Aplicar um processo de desenvolvimento de software, nfase na definio e
elicitao dos requisitos:
Apresentar e discutir o Ciclo de Requisitos de Software: Identificao,
Elicitao, Anlise, Especificao e Validao;
Apresentar e discutir as atividades de Identificao e elicitao de requisitos;
Apresentar e discutir as atividades da anlise de requisitos de software;
Apresentar as principais tcnicas para especificao de requisitos de software;
Apresentar as principais tcnicas para validao de requisitos de software;
Apresentar as principais tcnicas para processo de gerenciamento de
mudana de requisitos de software.
EMENTA:
Contexto atual das empresas em relao aos projetos de tecnologia de
informao. Modelagem de Negcio para o desenvolvimento de software.
Conceitos, evoluo e importncia da Engenharia de Requisitos. Entendendo e
analisando os problemas e as necessidades dos usurios, clientes e
envolvidos no projeto. Tcnicas de elicitao. Requisitos, seus tipos e matriz
de rastreabilidade. Definio do sistema a partir dos requisitos.
Gerenciamento de requisitos
Sugesto de Livros, Revistas e Sites
ENGENHARIA DE SOFTWARE Fundamentos, Mtodos e Padres 3 Edio
Editora GEN LTC Autor: Wilson de Pdua Paula Filho 2010;
ESPECIFICAO DE SISTEMAS DE SOFTWARE UTILIZANDO ANALISE E
PROJETO ESTRUTURADOS Editora UNICAMP Autor: Thelma C. dos Santos
Chiossi e Regina Lcia O. Moraes 2006;
ENGENHARIA DE SOFTWARE 6 Edio Editora MH - MCGRAW
HILL/NACIONAL Autor: Roger S. Pressman 2006;
AURUM, A., WOHLIN, C., Engineering and Managing Software Requirements,
Springer-Verlag, 2005.
REVISTAS E SITES:
Revista Engenharia de Software: www.devmedia.com.br;
http://engenhariadesoftware.blogspot.com/;
http://www.sigsoft.org/;
http://rildosan.blogspot.com/;
http://www.yuml.me;
http://www.wthreex.com/rup/;
http://www.engenharia-software.com
http://www.facebook.com/connect/uiserver.php?app_id=318148321616976&
method=permissions.request&redirect_uri=http%3A%2F%2Fapps.facebook.c
om%2Fpromonlogicalisestag%2F%3Ffb_source%3Dsearch%26ref%3Dts%26f
ref%3Dts&response_type=none&display=page&auth_referral=1
Softwares
ENGENHARIA DE SOFTWARE
Abono de Faltas
Abono de faltas somente com atestado mdico.
No final do semestre, no caso do aluno ter nota e ter entregue no mnimo
70% das atividades poder eliminar as faltas em excesso da seguinte forma:
para cada 2 horas/aula excedida dever ser entregue manuscrito um relatrio
de apresentao de TCC (DEIXAR NA SECRETARIA).
Contato
Email: simone_viana@yahoo.com.br e/ou simone@fatecpg.com.br
Obs. O email: simonemviana@gmail.com usado somente para envio
de formulrios no Google Docs no h acesso da caixa postal.
TODOS OS EMAILS ENVIADOS PELO YAHOO OU PELO FATECPG SERO
RESPONDIDOS EM UM PRAZO DE 48 HORAS. CASO NO HAJA RESPOSTA,
FAVOR ENVIAR NOVAMENTE.
Solicito que todos deixem o email atualizado na secretaria da Fatec
pois por este email que consta no seu cadastro que eu entro em
contato, avisando faltas, reposies, assuntos gerais, etc.
Avisos
Na pgina de ENGENHARIA DE SOFTWARE sempre ter avisos pertinentes ao
contedo da disciplina.
Contedo das Avaliaes
Sempre o contedo das avaliaes ser o apresentado at uma semana antes
das provas bimestrais, podendo ter eventualmente uma reviso antes da
avaliao.
Forma de Avaliao
Haver duas provas bimestrais que podero ser dissertativas ou objetivas
com valor de 10,0 pontos;
Haver tarefas avaliativas em sala de aula que pode ter valor at 3,0 pontos
que sero acrescidos a nota do bimestre;
Estas tarefas podero ser feitas em laboratrio, em casa com data de entrega
estipulada ou em sala de aula, realizadas em grupo ou individualmente,
participao em sala de aula, relatrios a partir de vdeos assistidos, estudos
de casos, entre outros.
ATENO!!!! CASO O ALUNO FALTE INDEPENDENTE DE TER
ATESTADO OU TER ATESTADO NO SER ACEITO A TAREFA POIS O
MESMO NO ASSISTIU A AULA.
Disciplinas, Dias e Horrios que me encontro na Fatec
Engenharia de Software II quinta-feira (13h10 as 16h40);
quarta-feira (19h as 22h30);
Banco de Dados quarta-feira (13h10 as 16h40);
quinta-feira (19h as 22h30);
Laboratrio de Banco de Dados quarta e quinta-feira (16h50 as 18h30)
Sbado (8h as 11h30).
Erros da Apostila:
Caso seja encontrado erro na apostila, favor enviar por email.
Obrigada!
ENGENHARIA DE SOFTWARE
TRABALHO SEMESTRAL
ENGENHARIA DE SOFTWARE
10
1.
a)
b)
c)
d)
e)
ENGENHARIA DE SOFTWARE
11
ENGENHARIA DE SOFTWARE
12
ENGENHARIA DE SOFTWARE
13
ENGENHARIA DE SOFTWARE
14
ENGENHARIA DE SOFTWARE
15
ESCOPO
O QUE EST
SENDO
PROJETADO!!!!
ENGENHARIA DE SOFTWARE
16
REQUISITOS DE SOFTWARE
ENGENHARIA DE SOFTWARE
17
ENGENHARIA DE SOFTWARE
18
ENGENHARIA DE SOFTWARE
19
TIPOS DE REQUISITOS
ENGENHARIA DE SOFTWARE
20
CLASSES DE REQUISITOS
ENGENHARIA DE SOFTWARE
21
RECORDANDO!!!!!
A especificao de um requisito
funcional deve determinar O QUE
o sistema deve fazer sem a
preocupao de COMO fazer.
ENGENHARIA DE REQUISITOS
A Engenharia de Requisitos o processo pelo qual os requisitos
de um produto de software so coletados, analisados, documentados e
gerenciados ao longo de todo o ciclo de vida do software (AURUM;
WOHLIN, 2005).
Pode ser descrita como o processo de descobrir, analisar,
documentar e verificar as funes e restries do sistema
(SOMMERVILLE, 2003).
Em resumo, podemos dizer que tratamento de requisitos envolve
atividades
de
desenvolvimento
(Levantamento,
Anlise
e
Documentao de Requisitos), gerncia (Gerncia de Requisitos) e
controle da qualidade (Verificao, Validao e Garantia da Qualidade
de Requisitos).
ENGENHARIA DE SOFTWARE
22
obteno
de
ENGENHARIA DE SOFTWARE
23
ENGENHARIA DE SOFTWARE
24
ENGENHARIA DE SOFTWARE
25
ENGENHARIA DE SOFTWARE
26
ELICITAO DE REQUISITOS
A parte mais rdua na construo de um
software consiste exatamente em identificar o
que construir. Nenhuma outra parte do trabalho
compromete tanto o resultado do trabalho se
elaborado de forma incorreta. Nenhuma outra
parte oferece tanta dificuldade para efetuar
correes posteriores." Fred Brook
Uma das partes mais crticas do processo de desenvolvimento de
software a elicitao (levantamento) de requisitos.
H estudos que indicam que os requisitos detectados depois
do software implementado ou erros de anlise custam at vinte
vezes mais caros que qualquer outro tipo de erro.
FASES DE UMA ELICITAO DE REQUISITOS
Um projeto de elicitao de requisitos tm as seguintes fases:
ENGENHARIA DE SOFTWARE
27
Qualquer pessoa ou organizao que tenha interesse, ou seja, afetado pelo projeto. A palavra
deriva de stake (interesse, participao, risco) e holder (aquele que possui).
ENGENHARIA DE SOFTWARE
28
ENGENHARIA DE SOFTWARE
29
que
tenha
sido
ENGENHARIA DE SOFTWARE
30
Quanto a
performance, qual
tempo de
resposta
adequado?
Quais
funcionalidades
ele deve ter?
Quanto
usabilidade, o
software identifica
visualmente a
empresa e possui
interface
amigvel?
O que o software
deve fazer?
Quais so os
requisitos de
segurana que o
software
precisa?
ENGENHARIA DE SOFTWARE
31
REQUISITOS FUNCIONAIS:
o Sistema deve registrar as principais aes de cada usurio;
o O sistema deve fornecer um relatrio do aproveitamento do
aluno;
O relatrio de aproveitamento do aluno deve conter o
tempo de uso do software, o nmero de exerccios
feitos, o nmero de acertos e o de erros.
o O sistema deve fornecer um relatrio do aproveitamento da
turma.
O relatrio de aproveitamento da turma deve conter a
mdia e o desvio-padro dos seguintes dados: tempo de
uso do software, nmero de exerccios feitos, nmero de
acertos e erros de cada exerccio.
REQUISITOS NO-FUNCIONAIS:
o O sistema deve usar grficos comparativos do aproveitamento
do aluno com a mdia da turma;
o O sistema deve usar cores na construo dos grficos;
o O tempo de resposta na elaborao do relatrio no pode ser
superior a 15 segundos.
ENGENHARIA DE SOFTWARE
32
Figura 12 Diferena entre uma boa e uma m elicitao (Fonte: extrado da Web)
ENGENHARIA DE SOFTWARE
33
ENGENHARIA DE SOFTWARE
34
Tipos de Tcnicas
Existem vrias tcnicas para a elicitao de requisitos, todas elas
possuem seus prprios conceitos, vantagens e desvantagens. Dentre
elas,
destacam-se
(KENDALL;
KENDALL,
2010;
KOTONYA;
SOMMERVILLE, 1998; AURUM; WOHLIN, 2005):
WORKSHOP DE REQUISITOS: idealizado para encorajar o
consenso acerca dos requisitos da aplicao e acerca das aes
a serem tomadas em um curto intervalo de tempo. Formato:
reunio intensiva (mximo 2 dias) com pessoas chaves visando
criar ou revisar as principais funcionalidade do sistema em
desenvolvimento, com a participao de um mediador;
QUESTIONRIOS: o uso de questionrios possibilita ao
analista
obter
informaes
como
postura,
crenas,
comportamentos e caractersticas de vrias pessoas que sero
afetas pelo sistema;
Quem so os usurios (ou perfis de usurio)?
Quem o cliente?
Eles tm necessidades diferentes em relao ao sistema?
Onde mais pode ser encontrada uma soluo para este problema?
Estas questes nos foram a ouvir antes de sair propondo uma soluo
para o problema.
OBSERVAO: consiste em observar o comportamento e o
ambiente dos indivduos de vrios nveis organizacionais.
Utilizando-se essa tcnica, possvel capturar o que realmente
feito e qual tipo de suporte computacional realmente
necessrio. Ajuda a confirmar ou refutar informaes obtidas
com outras tcnicas e ajuda a identificar tarefas que podem ser
automatizadas e que
no foram identificadas pelos
interessados;
ENGENHARIA DE SOFTWARE
35
ENGENHARIA DE SOFTWARE
Exemplo: Casos
(sentenas).
36
de
Uso
Lista
de
Caractersticas
ETNOGRAFIA
Tcnica de observao que pode ser utilizada para compreender os
requisitos sociais e organizacionais, ou seja, entender a poltica
organizacional bem como a cultura de trabalho com objetivo de
familiarizar-se com o sistema e sua histria. Os cientistas sociais e
antroplogos usam tcnicas de observao para desenvolver um
entendimento completo e detalhado de culturas particulares.
Nesta tcnica, o analista se insere no ambiente de trabalho em que o
sistema ser utilizado. O trabalho dirio observado e so anotadas as
tarefas reais em que o sistema ser utilizado. O principal objetivo da
etnografia que ela ajuda a descobrir requisitos de sistema implcitos,
que refletem os processos reais, em vez de os processos formais, onde as
pessoas esto envolvidas.
Etnografia particularmente eficaz na descoberta de dois tipos de
requisitos:
1. Os requisitos derivados da maneira como as pessoas realmente
trabalham, em vez da maneira pelas quais as definies de processo
dizem como elas deveriam trabalhar;
2. Os requisitos derivados da cooperao e conscientizao das
atividades de outras pessoas.
Alguns itens importantes que devem ser executados antes, durante e
depois do estudo de observao:
Antes, necessrio identificar as reas de usurio a serem
observadas; obter a aprovao das gerncias apropriadas para
executar as observaes; obter os nomes e funes das pessoas
chave que esto envolvidas no estudo de observao; e explicar
a finalidade do estudo;
Durante, necessrio familiarizar-se com o local de trabalho
que est sendo observado. Para isso preciso observar os
agrupamentos organizacionais atuais; as facilidades manuais e
automatizadas;
coletar
amostras
de
documentos
e
procedimentos escritos que so usados em cada processo
especfico que est sendo observado; e acumular informaes
estatsticas a respeito das tarefas, como: frequncia que
ocorrem, estimativas de volumes, tempo de durao para cada
pessoa que est sendo observada. Alm de observar as
operaes normais de negcios acima importante observar as
excees;
ENGENHARIA DE SOFTWARE
37
ENTREVISTAS
Tcnica amplamente utilizada, que consiste em conversas
direcionadas com um propsito especfico e com formato perguntaresposta. Seu objetivo descobrir problemas a serem tratados, levantar
procedimentos importantes e saber a opinio e as expectativas do
entrevistado sobre o sistema. Deve ser bem planejada e preparada
cuidadosamente para saber quem foi entrevistado, definir os objetivos da
entrevista, preparar antecipadamente as questes que sero formuladas
(ou parte delas).
Etapas
Apresentar-se;
Repassar a agenda (objetivos, patrocinador, motivo da escolha do
entrevistado);
Postura do entrevistador: credibilidade, iseno, discrio; no criar
ressentimentos;
Deixar o entrevistado falar (reduo da interferncia);
Direcionar a discusso para os objetivos;
Evitar perguntas fechadas;
No ultrapassar o tempo;
Notar sinais de impacincia.
Forma de Entrevistar
ENGENHARIA DE SOFTWARE
38
BRAINSTORMING
Representantes de diferentes grupos de interessados engajam-se em
uma discusso informal para rapidamente gerarem o maior nmero
possvel de ideias focadas em um objetivo claro e pr-definido.
Regras devem ser seguidas em uma sesso de Brainstorm:
No permitir crticas ou debate;
Deixar a imaginao voar;
Gerar tantas ideias quanto for possvel;
Mudar e combinar ideias;
Sesso consiste em duas fases: GERAO DE IDEIAS e
CONSOLIDAO;
Processo relativamente no estruturado que pode ou no
produzir a mesma qualidade ou nvel de detalhe de outros
processos.
TECNICAS PARA CONDUZIR
Isso no possvel...
No temos tempo para...
Tudo isso j foi tentado...
No momento no estamos em condies...
ENGENHARIA DE SOFTWARE
39
Exemplos:
1) Contexto: automao de iluminao.
Aspecto surgido no brainstorming: Configurao de iluminao
automtica.
Sentena descritiva: O dono de casa deve poder definir uma
programao da iluminao da casa baseado nos horrios do dia.
2) Contexto: Sistema de entrada de ordens de venda.
Aspecto surgido no brainstorming: Rapidez.
Sentena descritiva: O tempo de resposta deve ser suficientemente
bom para no interferir na realizao das aes do processo de venda.
3) Contexto: Sistema de rastreamento de falhas.
Aspecto surgido no brainstorming: Notificao automtica.
Sentena descritiva: Todos os grupos cadastrados devem ser
notificados por email quando houver alguma modificao no processo
de fabricao.
BRAINSWRITING
Dividir os participantes em grupos de 4 ou 5 pessoas. Os grupos
recebem uma questo.
O trabalho:
- Escrever a sua opinio sobre a questo;
- Ao terminar, colocar a folha no centro da mesa;
- Pegar a folha de respostas de outro integrante do grupo;
- Criticar as colocaes encontradas;
ENGENHARIA DE SOFTWARE
40
ENGENHARIA DE SOFTWARE
41
J AD
Tradicionalmente, JAD tem sido um mtodo utilizado por profissionais
de processamento de dados e usurios para definio de requisitos de
sistemas. Por isto o nome JAD Joint Application Design (ou
Development). Atualmente, o JAD tem sido um mtodo utilizado por todos
que desejam trabalhar em projetos, sejam da rea de informtica ou no,
ou que queiram tomar decises que afetem mltiplas reas da
organizao. O conceito de JAD surgiu na IBM em 1977, e entrou no Brasil
na dcada de 80, mas s comeou a ser utilizado efetivamente, aps
alguns nomes de peso na anlise de sistemas avalizarem tal
metodologia. Tcnica que rene determinado nmero de pessoas em
sesses bem estruturadas para, com tempo e esforo reduzidos,
consolidar um objetivo pr-determinado.
Figura 13 JAD
Figura 14
ENGENHARIA DE SOFTWARE
42
PREPARAO
- OBJETIVOS
ENGENHARIA DE SOFTWARE
43
- AGENDA
2002
DE: Yyyyyy Patrocinador do projeto Cargo
REF.: Projeto XPTO Sesso de Trabalho
Foi selecionado para participar da Sesso de Mapeamento de Processos do
projeto XPTO.
Esta Sesso integra o mtodo JAD, j apresentado, que vem sendo utilizado
com sucesso por grandes empresas. O seu tempo ser mais produtivo do que se
voc participasse de entrevistas individuais.
Voc foi selecionado pela sua habilidade, relao com o assunto e
capacidade de contribuir com ideias criativas e indispensveis produo de um
trabalho de alto nvel. Voc ter meu completo apoio e suporte.
A Sesso ter a durao de trs dias, de 27/05/2002 at 29/05/2002, com
realizao na parte da manh de cada dia, das 9:00h s 13:00h, na Sala Nxxx do
SENAI Artes Grficas, localizado na Rua So Francisco Xavier N xx, bairro da Tijuca.
Veja em anexo, a agenda de convocao detalhando a Finalidade,
Objetivos, Escopo (Tpicos), Lder da Sesso, Participantes, Documentos a Levar e
Informaes Necessrias, Restries e Eventuais Observaes.
Quaisquer dvidas devero ser imediatamente encaminhadas ao Sr.
Xxxxxx,.
Grato pela sua cooperao,
Yyyyyy Patrocinador do Projeto XPTO.
ENGENHARIA DE SOFTWARE
44
Introduo:
Breve reviso do mtodo JAD (s se no for conhecido);
Horrios, intervalos, facilidades, etc.;
Apresentao dos participantes;
Apresentao da agenda, esclarecendo o que ser tratado em
cada etapa.
ENGENHARIA DE SOFTWARE
45
Abordagem da Sesso:
Roteiro passo a passo das etapas especficas (dirigidas aos
produtos metodolgicos) para se alcanar os objetivos da sesso.
Reviso das Pendncias:
Atualizao do Controle de Pendncias documentando o item,
data de registro, situao, responsvel pela soluo, data de
trmino prevista.
Reviso Geral:
Reviso do material produzido na sesso, verificando se est
coeso e de acordo com o que estava previsto.
Avaliao e Encerramento da Sesso:
Avaliao dos participantes sobre o
mtodo
desempenho do lder, para melhoria contnua.
usado
e o
ENGENHARIA DE SOFTWARE
46
SESSO
OBJETIVOS
ENGENHARIA DE SOFTWARE
47
ENGENHARIA DE SOFTWARE
48
ENGENHARIA DE SOFTWARE
49
ENGENHARIA DE SOFTWARE
50
ENGENHARIA DE SOFTWARE
51
REVISO
ENGENHARIA DE SOFTWARE
52
O CLIENTE (PATROCINADOR)
ENGENHARIA DE SOFTWARE
53
EQUIPE
ENGENHARIA DE SOFTWARE
54
No
No
No
No
No
No
No
No
No
se irrite;
se ofenda;
brigue;
monopolize;
seja o dono da verdade;
faa o tipo sabido
leve tudo na brincadeira;
ignore algum participante;
permita uma dupla em debate.
DOCUMENTADOR OU ESCRIBA
O DISCO QUEBRADO
ENGENHARIA DE SOFTWARE
55
ENGENHARIA DE SOFTWARE
56
ENGENHARIA DE SOFTWARE
57
O MAL-EDUCADO
papel
para
cada
ENGENHARIA DE SOFTWARE
58
ESPECIFICAO DE REQUISITOS
No documento da especificao de requisitos descrevemos os
requisitos funcionais (obrigatrios) e requisitos no-funcionais
(opcionais). Obs. H um outro exemplo de especificao de requisitos
no Anexo A.
Onde:
Caso de Uso: nome do caso de uso;
Objetivo: breve descrio do caso de uso;
Atores: envolvidos naquele caso de uso;
Condio de incio: o que dispara a funcionalidade no contexto do
sistema;
Fluxo Principal: interao entre sistema e ator para que o objetivo
seja atingido;
Fluxo alternativo: apoio do fluxo principal para que seja possvel
atingir os objetivos secundrios.
Regras de negcio: restries nas funcionalidades.
PASSOS PARA ESPECIFICAR OS REQUISITOS
ENGENHARIA DE SOFTWARE
59
Excluir Cliente
Editar cliente
ENGENHARIA DE SOFTWARE
60
VISO E ESCOPO
O documento que deve ser criado deve ter a viso e o escopo do
programa a ser desenvolvido deve apresentar e deixar claro o que ser
feito. Deve ser focado a no cliente, levantando os requisitos principais
na viso macro, sem detalhamento para que o cliente perceba o que
est sendo feito. Os objetivos so levantamentos com reunies
semanais at fechar pois depois comea o levantamento de requisitos.
Nesta viso temos os objetivos principais e as prioridades dele.
Para seguir uma linha de raciocnio que definido pelo cliente ou
representantes deste cliente (stakeholders envolvidos no projeto).
Para que quando for levantar os requisitos no sair da viso sabendo
que vai ser feito e o que no vai ser feito (documento do escopo), onde
s poder ser feito o que est definido.
Deve ter nvel alto de abstrao e dever ter se haver ou no:
manuais, treinamentos e se for um sistema grande dever ser dividido
em subsistemas e depois poder ser integrado. A equipe precisa
lembrar o processo de usabilidade (caso parar um o outro permanece
funcionando) e tambm poder ser reutilizado.
O escopo deve conter tudo que o projeto deve fazer. importante
verificar se todo o escopo est sendo mantido (PLANEJAMENTO,
DEFINIO, VERIFICAO E CONTROLE DO ESCOPO).
importante criar uma estrutura analtica do projeto (EAP) onde
so definidos os blocos de trabalho para completar o projeto como um
todo.
EXERCCIOS
ENGENHARIA DE SOFTWARE
61
ENGENHARIA DE SOFTWARE
62
VERIFICAR :
Estamos construindo
certo o produto??
ENGENHARIA DE SOFTWARE
63
TIPOS DE DEFEITO
ENGENHARIA DE SOFTWARE
64
OMISSO
AMBIGUIDADE
INCONSISTNCIA
FATO INCORRETO
INFORMAO ESTRANHA
DOCUMENTO DE REQUISITOS
Por ser o primeiro artefato tangvel a ser produzido pois descreve
todas as caractersticas e as funes que o software a ser desenvolvido
deve possuir. Atua como um contrato entre o cliente e o desenvolvedor e
a base para todas as etapas subsequentes do desenvolvimento e
normalmente escrito em linguagem natural.
ENGENHARIA DE SOFTWARE
65
CONSEQUENCIAS
ENGENHARIA DE SOFTWARE
66
RASTREABILIDADE.
estabelecida?
origem
do
requisito
claramente
REVISES DE SOFTWARE
o processo ou atividade para leitura de um artefato de seu software
visando assegurar que ele cumpre sua especificao e atende s
necessidades de seus usurios e ocorre em diferentes momentos do
software.
Tem como objetivo validar e verificar os artefatos de software.
Pode ser aplicada a qualquer artefato produzido ao longo do processo
de desenvolvimento de software.
As revises podem ser:
PARES (PEER-REVIEWS): aumenta a probabilidade de defeitos a
serem encontrados. Utilizam:
o ANNIMIDADE: relacionamentos pessoais no afetam a
reviso.
o INDEPENDNCIA DOS REVISORES EM RELAO AO ARTEFATO
A SER REVISADO: permite uma avaliao objetiva sem
conflitos de interesse.
TIPOS DE REVISO DE SOFTWARE
INSPEO DE SOFTWARE
ENGENHARIA DE SOFTWARE
67
ENGENHARIA DE SOFTWARE
68
PLANEJAMENTO
Responsvel: moderador
Tarefas:
- Definir contexto da inspeo: descrio da inspeo, como a
preparao individual dever ocorrer, documento a ser inspecionado,
autor do documento, entre outros.
- Selecionar inspetores: recomenda-se utilizar entre 3 e 5 inspetores em
uma inspeo.
- Distribuir material.
PREPARAO INDIVIDUAL
- Responsvel: Inspetor
- Tarefas: estudar os artefatos e fazer anotaes sobre os artefatos.
REUNIO DE INSPEO
- Envolvidos: moderador, inspetores e autor
- Tarefas:
- Leitura do documento com a equipe discutindo possveis defeitos
(durao recomendada 2 horas);
- Produzir uma lista de defeitos;
- Em casos de discordncia a deciso sobre registrar um defeito ou no
(falso positivo) do moderador.
RETRABALHO
- Responsvel: Autor
- Tarefa: corrigir os defeitos encontrados.
CONTINUAO
- Responsvel: Moderador
- Tarefa:
ENGENHARIA DE SOFTWARE
69
ENGENHARIA DE SOFTWARE
70
WIEGERS, 2003)
ENGENHARIA DE SOFTWARE
71
ENGENHARIA DE SOFTWARE
72
POLTICAS
DE
RASTREABILIDADE:
quantidade
de
informaes (histrico) sobre o relacionamento entre requisitos
que mantida. Como rastrear as mudanas de requisitos e seus
possveis impactos.
RASTREABILIDADE
RASTREABILIDADE
dependentes;
DE
REQUISITOS:
links
entre
requisitos
SUPORTE FERRAMENTA:
ser
ENGENHARIA DE SOFTWARE
73
ENGENHARIA DE SOFTWARE
74
EXERCCIOS
1) Assinale a opo correta quanto a requisitos de software.( CESPE - 2010 TRE-MT - Tcnico Judicirio - Programao de Sistemas)
a)Requisitos funcionais descrevem as propriedades emergentes do
sistema, como segurana e tempo de resposta.
b)Requisitos no funcionais so descritos de forma qualitativa e no
quantitativa
c) Requisitos so provenientes de pessoas relevantes para o sistema, e
no de outros sistemas que interagem com o sistema que est sendo
especificado.
d)A matriz de rastreabilidade no oferece suporte para requisitos
funcionais.
e)Reviso de requisitos, prototipao e gerao de casos de teste so
exemplos de tcnicas de validao de requisitos.
2) Segundo Ian Sommerville, existe uma srie de tcnicas de validao de
requisitos que podemser utilizadas em conjunto ou individualmente.
So elas (FUNCAB - 2010 - SEJUS-RO - Analista de Sistemas):
a) gerao de casos de teste, revises de requisitos, gerenciamento de
mudanas e prototipao.
b) revises de requisitos, prototipao, gerao de casos de teste e
anlise automatizada da consistncia.
c) prototipao, anlise automatizada da consistncia, revises de
requisitos e gerenciamento de mudanas.
d) gerenciamento de mudanas, anlise automatizada da consistncia,
revises de requisitos e gerao de casos de teste.
e) anlise automatizada da consistncia, prototipao, gerenciamento de
mudanas e gerao de casos de teste.
3) No que diz respeito aos sistemas de software, teste um conjunto de
atividades que podem ser planejadas antecipadamente e conduzidas
sistematicamente. Um tipo I de teste se refere ao conjunto de atividades
que garante que o software implementa corretamente uma funo
especfica, associado construo do produto de forma correta ou no,
enquanto um tipo II se refere a um conjunto de atividades diferente que
garante que o software construdo corresponde aos requisitos do cliente,
associado construo do produto certo. Esses testes do tipo I e II so
denominados, respectivamente (FGV - 2010 - FIOCRUZ - Tecnologista em
Sade - TI - Sistemas de Informao):
a) Depurao e homologao.
b) Homologao e aceitao.
c) Aceitao e verificao.
d) Verificao e validao.
e) Validao e depurao.
4) Verificao e validao so atividades da anlise de software,
necessrias para se identificar o que o software precisa executar, seguida
ENGENHARIA DE SOFTWARE
75
de uma avaliao do usurio quanto s atividades definidas. (CESPE - 2011 TJ-ES - Tcnico de Informtica - Especficos)
___ CERTO ___ ERRADO
5) Os produtos de trabalho resultantes da engenharia de requisitos so
avaliados quanto qualidade durante a etapa de validao de requisitos.
Analise
os
itens
a
seguir
referentes
a
essa
etapa:
I. Um dos principais mecanismos de validao de requisitos a avaliao
tcnica formal.
II. O modelo de anlise pode garantir que os requisitos foram
consistentemente declarados.
III. frequentemente til examinar cada requisito em face de um
conjunto de questes do tipo checklist.
IV. A equipe de reviso que avalia os requisitos inclui apenas pessoas com
conhecimento tcnico na rea de TI, como engenheiros de softwares,
desenvolvedores etc.
Est correto o que consta em:
a) I, II, III e IV
b) II e IV
c) I, II e IV
d) II, III e IV
e) I, II e III
6) Assim como o software, os requisitos tambm devem ser avaliados
quanto qualidade. A validao, atividade da engenharia de requisitos,
responsvel por garantir que os requisitos tenham sido declarados de
forma clara e precisa. Alm disso, a validao busca detectar
inconsistncias, erros e omisses, objetivando alinhar os requisitos s
normas estabelecidas para o projeto, produto e processo. (CESPE - 2011 TJ-ES - Analista Judicirio - Anlise de Sistemas - Especficos)
___ CERTO ___ ERRADO
ENGENHARIA DE SOFTWARE
76
MATRIZ DE RASTREABILIDADE
Matrizes de rastreabilidade so os principais artefatos produzidos na
fase de gerncia de requisitos. Elas relacionam os requisitos identificados
a um ou mais aspectos do sistema ou do seu ambiente, de modo que elas
possam ser procuradas rapidamente para entender como uma modificao
em um requisito vai afetar diferentes aspectos do sistema.
RASTREABILIDADE
Tcnica usada para prover relacionamento entre requisitos, projeto e
implementao final do sistema. uma caracterstica de sistemas nos
quais os requisitos so claramente ligados s suas fontes e aos artefatos
criados durante o ciclo de vida de desenvolvimento de sistema.
a habilidade de descobrir a histria de toda caracterstica do
sistema, dado que os impactos de mudanas nos requisitos podem ser
identificados. (Hamilton, 1991)
OBJETIVOS
GERENCIAR O PROJETO:
o Acompanhar a evoluo
desenvolvimento;
dos
requisitos
ao
longo
do
ENGENHARIA DE SOFTWARE
77
o Registrar
status
de
cada
requisito
em
relao
ao
desenvolvimento, em relao a modificaes aceitas e
justificativas associadas;
o Estabelecer uma viso comum entre o cliente e a equipe de
projeto em relao aos requisitos que sero atendidos pelo
projeto de software;
ACOMPANHAR AS MUDANAS:
o Atualmente tem-se a convico que mudanas em requisitos ao
longo do processo de desenvolvimento de software fazem parte
do processo;
o Motivos: necessidades no identificadas inicialmente, alteraes
no contexto, correo de erros ou mesmo novas perspectivas por
parte dos stakeholders;
o Alteraes em requisitos podem implicar em mudanas em
artefatos de projeto, cdigo, casos de testes, etc.
GARANTIA DE QUALIDADE:
o Aspectos relacionados a qualidade: modelo CMM, CMMI, ISO
9001.
A rastreabilidade auxilia:
ANLISE DE COMPLETUDE NA ALOCAO DE REQUISITOS A
COMPONENTES DO SOFTWARE: A avaliao dos links de
rastreabilidade de requisitos a artefatos de design e implementao
identifica requisitos ainda no alocados ou implementados;
ENGENHARIA DE SOFTWARE
78
ENGENHARIA DE SOFTWARE
79
Data
Assinatura
Nome
Data
Assinatura
<nome do projeto>
Matriz de Rastreabilidade de Requisitos
Data: dia/ms/ano
Elaborado por:
<nome(s) do(s) elaborador(es)>
ID Requisito
Descrio Prioridade Responsvel / Verso Caso de Teste
Data
Data
Proprietrio
Alterao Concluso
Id do
Descrio Prioridade
requisito (Feature)
do
elencada
identificado no
requisito.
para o
Documento
requisito.
(Anlise) de
Requisitos.
Figura 35 Modelo de Matriz
Nome do
Nmero Identificao Data de
Data de
responsvel da verso do caso de alterao concluso
pela
do
teste elaborado
do
do
execuo e requisito.
para o
requisito. requisito.
controle do
requisito.
requisito.
de Rastreabilidade (Fonte: extrado da Web)
EXERCCIOS
ENGENHARIA DE SOFTWARE
80
ORIENTAO A OBJETOS
HISTRIA
ENGENHARIA DE SOFTWARE
81
http://zeromeia.net84.net/smalltalk/programando.html
CONCEITOS FUNDAMENTAIS
ENGENHARIA DE SOFTWARE
82
ENGENHARIA DE SOFTWARE
83
ATRIBUTO
ENGENHARIA DE SOFTWARE
84
ENGENHARIA DE SOFTWARE
85
ENGENHARIA DE SOFTWARE
CLASSES
Antes da herana
Cliente
Funcionario
86
ATRIBUTOS
cpf
nome
dataNascimento
endereco
dataPrimeiraCompra
cpf
nome
dataNascimento
endereco
dataAdmissao
funo
Aps a herana
Pesoa
cpf
nome
dataNascimento
endereco
Cliente
dataPrimeiraCompra
Funcionrio
dataAdmissao
funcao
Quando uma subclasse possui mais do que uma superclasse dito
que temos uma herana mltipla.
A herana no precisa se limitar aos objetos de negcio. Pelo
contrrio, um dos maiores ganhos que ns temos com a orientao a
objetos a possibilidade de se estender todo esse conceito de utilizao
para todos os componentes do nosso sistema.
Exemplo: podemos criar uma classe para um relatrio, com o
logotipo da empresa, dados de identificao do cabealho e do rodap, e a
partir dessa classe, herdar todos os outros relatrios do sistema,
particularizando em cada um, as caractersticas especficas. Imagine o
esforo necessrio para se trocar o logo e incluir o nome do usurio
logado em todos os 1000 relatrios de um sistema: calculo uns dois
minutos.
POLIMORFISMO
ENGENHARIA DE SOFTWARE
87
funcionrio, o que nos leva a ter a mesma operao, porm com mtodos
diferentes.
ENGENHARIA DE SOFTWARE
88
EXERCCIOS
1)
a)
b)
c)
d)
e)
b)
c)
ENGENHARIA DE SOFTWARE
d)
e)
89
3)
4)
5)
6)
ENGENHARIA DE SOFTWARE
90
b) I, II e IV, apenas.
c) II, III e IV, apenas.
d) I e II, apenas
e) II e IV, apenas.
7) A Anlise e Projeto Orientado a Objetos, um recurso tem como meta
principal reduzir o nmero de variveis globais usadas dentro de
um programa, consistindo na separao dos aspectos externos de
um objeto, permitindo que a sua implementao possa ser
modificada sem que afete as aplicaes que o utilizam. Este
recurso denominado:
a) Encapsulamento
b) Independncia
c) Polimorfismo
d) Modularidade
e) Herana
8) Orientao a Objetos um paradigma de anlise, projeto e
programao de sistemas de software. A respeito desse
paradigma, assinale a afirmativa incorreta. (FGV - 2009 - MEC Analista de Sistemas - Especialista)
a) Um objeto pode ser considerado um conjunto de dados.
b) Os objetos possuem identidade, estado e comportamento.
c) Um evento pode existir se no houver um objeto a ele
associado.
d) Um objeto pode existir mesmo que no exista nenhum evento
associado a ele.
e) A orientao a objetos implementa o conceito de abstrao,
classe, objeto, encapsulamento, herana e polimorfismo.
9) Em desenvolvimento de sistemas, focalizar nos aspectos essenciais
inerentes a uma entidade e ignorar propriedades significa
concentrar-se no que um objeto e faz antes de se decidir como
ele ser implementado. Na orientao a objetos, este um
conceito tpico (FCC - 2011 - TRE-RN - Tcnico Judicirio - Programao de
Sistemas)
a) Herana
b) Reusabilidade
c) Abstrao
d) Encapsulamento
e) Compartilhamento
ENGENHARIA DE SOFTWARE
91
2 BIMESTRE UML
Adaptado da Revista Engenharia de Software Magazine
HISTRIA
ENGENHARIA DE SOFTWARE
92
CONCEITO
A UML uma linguagem usada para especificar, visualizar e
documentar os artefatos de um sistema baseado em objeto, sob
desenvolvimento. Ela representa a unificao das notaes de Booch,
Rumbaugh e Jacobson, bem como as melhores ideias de uma
quantidade de outros tericos de metodologia. Unificando as notaes
usadas por esses mtodos baseados em objeto, a Unified Modelling
Language oferece a base para um padro de fato no domnio de anlise
e projeto baseado em objeto, apoiada em uma ampla base de
experincia (Rational Software Corporation).
ENGENHARIA DE SOFTWARE
93
UTILIZAO
A UML pode ser usada para modelar visualmente:
A interao de sua aplicao com o mundo externo;
O comportamento de sua aplicao;
A estrutura de seu sistema;
Os componentes de seu sistema;
A arquitetura de sua empresa;
Ajuda a visualizar o sistema;
Especifica a estrutura e o comportamento;
Proporciona um guia para a construo do sistema;
Documenta as decises tomadas.
ENGENHARIA DE SOFTWARE
94
NOTAO
especifica para
linguagem de
programao.
VANTAGENS
do
ENGENHARIA DE SOFTWARE
95
COMPONENTES DA UML
MODELOS DE ELEMENTOS
So os conceitos utilizados nos diagramas. Pode ser uma
representao grfica presente em diversos diagramas ou definido para
que faa parte de um diagrama. So eles: CLASSES, OBJETOS, ESTADOS,
PACOTES, COMPONENTES e RELACIONAMENTOS9.
CLASSES
OBJETOS
ENGENHARIA DE SOFTWARE
96
ESTADOS
COMPONENTES
ENGENHARIA DE SOFTWARE
97
RELACIONAMENTOS
ENGENHARIA DE SOFTWARE
98
ENGENHARIA DE SOFTWARE
99
ENGENHARIA DE SOFTWARE
100
ENGENHARIA DE SOFTWARE
101
DIAGRAMAS
Um diagrama uma representao grfica parcial ou total de um
modelo. Apresentao grfica de uma coleo de elementos de modelo,
geralmente processados como um grfico de arcos (relacionamentos) e
vrtices (outros elementos de modelo) conectados.
A UML 2.0 (verso atual) define 13 tipos de diagramas divididos
em duas categorias de modelagem: ESTTICA (ESTRUTURAL) ou
DINMICO (COMPORTAMENTO).
DIAGRAMAS ESTRUTURAIS (ESTTICOS)
ENGENHARIA DE SOFTWARE
102
ENGENHARIA DE SOFTWARE
103
1)
2)
a) Componentes
b) Implantao
c) Estado
d) Classes
e) Sequncia
3)
__ Certo __ Errado
4)
ENGENHARIA DE SOFTWARE
104
a) Afirmativas I e II so verdadeiras.
b) Afirmativas I e III so verdadeiras.
c) Afirmativas II e III so verdadeiras.
d) Todas as afirmativas so verdadeiras.
5) A respeito da linguagem UML correto afirmar que (Concurso
Serpro-2001):
a) no se trata de uma linguagem de documentao.
b) voltada para a representao conceitual e fsica de um sistema.
c) no abrange a documentao para a realizao de testes.
d) no deve ser empregada para a documentao de artefatos que
faam uso de sistemas completos de software.
e) uma linguagem utilizada para a realizao de testes de
programas.
6) Entre outros, a UML inclui os diagramas de (Concurso Serpro-2001):
a) classes, objetos, fluxo de dados e de atividades.
b) classes, implantao, grficos de estado e de sequncias.
c) objetos, classes, contexto, implantao.
d) classes, objetos, testes, implantao.
e) objetos, casos de uso, contexto, implantao.
7) Na UML, as classes A e B legam suas estruturas e comportamentos
classe C. Considerando apenas o fato apresentado nessa
circunstncia, correto afirmar que a se aplica tipicamente o
conceito de (FCC - 2009 - TRT - 7 Regio (CE) - Analista Judicirio - Tecnologia
da Informao)
a) delegao.
b) derivao.
c) herana mltipla.
d) mtodo polimrfico.
e) multiplicidade.
8) A UML define em sua verso 2.0, treze tipos de diagramas, divididos
em duas categorias: diagramas estruturais e diagramas dinmicos.
Assinale a alternativa que no indique um diagrama estrutural da
UML. (FGV - 2009 - MEC - Analista de Sistemas - Especialista)
a) Diagrama de Viso Geral.
b) Diagrama de Implantao.
c) Diagrama de Pacotes.
d) Diagrama de Classes.
e) Diagrama de Objetos.
ENGENHARIA DE SOFTWARE
105
DIA PORTABLE
ENGENHARIA DE SOFTWARE
106
cisco, entre muitos outros. Desta forma, muito pouco provvel que
voc no venha a encontrar o desenho que precisa para seu diagrama.
Para utiliz-lo simples, basta abrir um novo projeto e comear a
desenhar seus diagramas. Para inserir novos objetos, primeiro escolha
uma categoria na caixa de opes no lado esquerdo da tela. Feito isto,
escolha as formas que deseja inserir em seu projeto e para adicion-las
basta clicar sobre a figura com o mouse e arrast-la at o quadro (ou
clicar sobre a figura e sobre o quadro)
medida que uma figura vai sendo posicionada na tela, voc pode
observar seu enquadramento correto por meio do fundo quadriculado e
das rguas horizontais e verticais dispostas para tal funo. Se aps
inserir a figura houver algum problema, para apag-la basta selecionar
e utilizar o delete do teclado.
Na barra de ferramentas situada na borda superior do programa
esto disponveis diversos tipos de opes para ajudar em seu
desenho, como opes de criao de camadas, exibio de grade,
posicionamento, mtodos de entrada, seleo, gravao de seu
diagrama, entre outras.
ENGENHARIA DE SOFTWARE
107
ENGENHARIA DE SOFTWARE
Divide-se em:
ATIVIDADE DE UML
COLABORAO DE UML
108
ENGENHARIA DE SOFTWARE
COMPONENTE UML
IMPLANTAO DE UML
SEQUNCIA DE UML
109
ENGENHARIA DE SOFTWARE
110
PROPRIEDADES DA FORMA
Para inserir uma forma necessrio selecion-la e arrast-la para a
rea de trabalho. Com a forma na rea de trabalho, d um clique duplo e
surge a tela de propriedades de acordo com a forma escolhida.
ENGENHARIA DE SOFTWARE
111
OBSERVAES
Serial: PHGVY-62VQH-6YR3J-46D86-TG2MT
ENGENHARIA DE SOFTWARE
112
CASOS DE USO
Descreve um conjunto particular de funcionalidades do sistema,
modelando o dilogo que uma entidade externa, chamada ator, realiza
com o sistema.
Especifica o comportamento de um sistema ou parte dele.
tambm uma descrio do conjunto de passos que o sistema executar
para desempenhar suas funes.
baseado em um cenrio descritivo de como a entidade externa
interage com o sistema. Identifica eventos que podem ocorrer e
descreve a resposta do sistema para estes eventos.
Quando combinados, os casos de uso constituem todas as formas
de uso do sistema e fornecem uma viso do sistema focada na
funcionalidade.
Possibilita um formato de apresentao compreensvel que pode
ser utilizado para aprimorar a comunicao, especialmente entre os
projetistas da aplicao e os clientes. So muito usados nas fases
posteriores do ciclo de vida, ajudando na identificao dos objetos,
desenvolvimento de planos de teste e documentao.
ENGENHARIA DE SOFTWARE
113
ATOR
So entidades do meio ambiente (externa ao sistema)
que interagem com o sistema para obter alguma
funcionalidade. Podem ser: humanos, outros sistemas,
organizaes, dispositivos externos, etc., que interagem com
o sistema. Alguns atores do incio a eventos enquanto outros
interagem com o sistema em decorrncia do resultado de outros
eventos.
COMO IDENTIFICAR OS ATORES
CASO DE USO
Utilizado para representar as funcionalidades do
sistema. Representar o que o sistema faz (no como).
uso.
ENGENHARIA DE SOFTWARE
114
Ator: CLIENTE
Casos de Uso: sacar dinheiro, transferir dinheiro e consultar
saldo.
CENRIO
Um cenrio a descrio de uma das maneiras pelas quais um caso
de um pode ser realizado.
Um cenrio tambm chamado de instncia de um caso de uso.
Normalmente h diversos cenrios para um mesmo um caso de uso.
RELACIONAMENTO DE EXTENSO
Um caso de uso pode ser estendido por outro (funcionalidade).
Pode ser usada para:
Simplificar fluxos de eventos complexos;
Representar comportamentos opcionais;
Lidar com excees.
A extenso ocorre em pontos especficos (pontos de extenso).
ENGENHARIA DE SOFTWARE
115
RELACIONAMENTO DE INCLUSO
Um caso de uso pode ser incluir outro no sentido de sempre utilizar
suas funcionalidades. Pode ser usada para:
Representar comportamentos reutilizveis;
Simplificar fluxos de eventos complexos.
O <<include>> um vnculo obrigatrio, ou seja, SEMPRE usar as
suas funcionalidades (inclui todo o comportamento do caso de uso que
est sendo includo).
RELACIONAMENTO DE ESPECIALIZAO
Um caso de uso pode ser especializar outro (adio/refinamento do
fluxo de eventos original). Especializao permite modelar comportamento
de estruturas de aplicao em comum.
Este tipo de relacionamento ocorre entre atores e entre casos de uso.
RELACIONAMENTO ENTRE CASOS DE USO
GENERALIZAO:
classes;
mesma
semntica
da
generalizao
entre
ENGENHARIA DE SOFTWARE
116
ENGENHARIA DE SOFTWARE
117
Exemplo de EXTEND:
ENGENHARIA DE SOFTWARE
118
ENGENHARIA DE SOFTWARE
a)
b)
c)
d)
e)
2)
119
do
do
do
do
do
ENGENHARIA DE SOFTWARE
120
ENGENHARIA DE SOFTWARE
121
ENGENHARIA DE SOFTWARE
122
ENGENHARIA DE SOFTWARE
123
ENGENHARIA DE SOFTWARE
124
que devem ter data e valor, alm do tipo de movimento, que pode ser
dbito ou crdito.
Clientes ainda podem solicitar cartes de contas bancrias, que
devem ter nmero, validade e senha para cada cliente, alm de tales
de cheques para contas correntes, que devem armazenar o nmero
inicial e final das folhas do talo. O sistema ainda deve permitir aos
clientes consultar saldos e extratos.
DIAGRAMA DE CLASSES
Representao dos dados manipulados e armazenados pelos
programas de acordo com os conceitos de Orientao a Objetos. Notao
fortemente baseada no Diagrama Entidade-Relacionamento de Peter
Chen. Deve-se observar que o Diagrama de Classes privilegia a descrio
segundo o paradigma OO. Resumindo: Trata de dados e funes.
CLASSE
uma descrio de um conjunto de objetos que compartilham os
mesmos atributos, operaes, relacionamentos e semntica.
Representa a abstrao de um conjunto de OBJETOS do Mundo Real
que possuem tipos de caractersticas e de comportamento em comum.
Exemplo: PESSOA.
ENGENHARIA DE SOFTWARE
125
CONVENES
ATRIBUTOS
Um atributo uma propriedade nomeada
de uma classe que descreve um intervalo de
valores que as instncias podem apresentar.
Uma classe pode ter qualquer nmero de
atributos ou mesmo nenhum atributo.
Representa alguma propriedade do item
que est sendo modelado, compartilhado por
todos os objetos desta classe. Um objeto de
uma classe poder ter valores especficos para
cada um dos seus atributos. Exemplo: Todo
estudando possui nome, data de nascimento, e
sexo.
OPERAES
Uma operao a assinatura de uma implementao de um servio
que pode ser solicitado por algum objeto da classe para modificar seu
estado.
VISIBILIDADE
uma propriedade cujo valor (pblico, protegido ou privado) denota
como o elemento poder ser visto externamente:
PBLICO (+): qualquer objeto pode acessar os atributos ou
operaes da classe que se relacione com a classe que o possui;
PROTEGIDO (#): atributos e operaes de uma classe so acessveis
apenas por suas subclasses, ou seja, pode ser acessado apenas pelos
descendentes da classe;
PRIVADO(-): atributos e operaes de uma classe so acessveis
apenas pela prpria classe.
RELACIONAMENTOS
Especifica como as classes se relacionam. Podem ser de trs tipos:
ENGENHARIA DE SOFTWARE
126
ASSOCIAO
AGREGAO
ENGENHARIA DE SOFTWARE
127
COMPOSIO
CLASSE DE ASSOCIAO
ENGENHARIA DE SOFTWARE
128
HERANA
HERANA MLTIPLA
Na herana nica, uma classe tem um conjunto de pais (uma cadeia
de superclasse). A herana mltipla envolve do que uma cadeia de
superclasses. Problemas:
Choques de nomes de atributos ou mtodos;
Dificulta a manuteno do cdigo fonte.
ENGENHARIA DE SOFTWARE
129
MULTIPLICIDADE
Embora a multiplicidade seja especificada para classes, ela define a
quantidade de objetos que participam de um relacionamento. Existem dois
indicadores de multiplicidade para cada associao ou agregao (uma em
cada final de linha).
DIAGRAMA DE CLASSE
utilizado para:
modelar a viso esttica do projeto de um sistema;
modelar o relacionamento entre os diversos objetos que faro
parte do sistema;
capturar o vocabulrio do problema;
ancorar os comportamentos em suas classes;
ENGENHARIA DE SOFTWARE
130
IDENTIFICANDO AS CLASSES
ENGENHARIA DE SOFTWARE
131
IDENTIFICANDO OS ATRIBUTOS
IDENTIFICANDO O COMPORTAMENTO
IDENTIFICANDO GENERALIZAES
IDENTIFICANDO ASSOCIAO
Vamos
fazer juntos
????
ENGENHARIA DE SOFTWARE
132
ENGENHARIA DE SOFTWARE
133
ENGENHARIA DE SOFTWARE
134
ENGENHARIA DE SOFTWARE
135
parciais deve ser maior ou igual a 70. Para reprovao direta esta mdia
deve ser menor que 30. Mdias entre 30 (inclusive) e 70 (exclusive)
colocam o aluno em prova final. Se mdia da prova final com a mdia
anterior for menor que 50, o aluno est reprovado, caso contrrio,
aprovado.
RF09. O sistema deve controlar a situao de um aluno, podendo estar
matriculado, trancado, formado, ou ter abandonado o curso.
5) Faa o diagrama de classes do estudo de caso abaixo:
Uma locadora de veculos deseja um sistema para facilitar o
atendimento a seus clientes. O processo de aluguel de carros atual
confuso e est gerando insatisfao entre os clientes. A locadora
formada basicamente pelos seus clientes e carros para aluguel. Os carros
esto divididos em diversos tipos: popular, luxo e utilitrio. As
informaes importantes sobre os carros a serem armazenadas so:
cdigo (placa do carro), tipo, modelo, ano, cor, chassis, quilometragem e
valor do aluguel (diria). Os funcionrios sero responsveis pe3lo
cadastro dos clientes e dos carros adquiridos pela locadora, por efetuar o
aluguel de um carro para o cliente e dar baixa no aluguel. Existem clientes
especiais e clientes comuns. Os especiais possuem uma taxa de desconto
e um valor de quilometragem extra para seus aluguis. Qualquer cliente
identificado por RG, nome, CPF, telefone, endereo, contato.
6) Faa o diagrama de controle de respostas das questes de uma prova:
A Instituio de Ensino UniLinense deseja controlar todas as
respostas referentes s questes, de uma determinada prova, aplicadas
aos alunos da instituio. Sabe-se que uma prova tem que ter
obrigatoriamente uma questo e pode ter vrias, as questes por sua vez
fazem parte da prova e s podem estar vinculada a uma determinada
prova.
Cada prova tem somente um professor responsvel e um mesmo
professor pode se responsabilizar por vrias provas. Os alunos a serem
controlados se subdividem em alunos regulares e alunos dependentes.
Ambos alunos respondem vrias questes e uma questo aplicada a
vrios alunos. Para cada questo aplicada a um aluno deseja-se
armazenar uma resposta.
7) Faa o diagrama de controle de venda de veculos:
O objetivo principal desse sistema controlar as vendas de veculos,
direto da fbrica, realizadas pelos Concessionrios aos clientes. Sabe-se
que um Concessionrio pode vender vrios Veculos diretamente da
fbrica e que os veculos podem ser vendidos em vrios concessionrios
(por exemplo, um Gol pode ser vendido por vrios concessionrios). Toda
Venda destinada a um e somente um Cliente e todo cliente pode
comprar vrios veculos.
ENGENHARIA DE SOFTWARE
136
DIAGRAMA DE OBJETOS
Representa a instncia (uma ocorrncia) do diagrama de classes.
Para cada classe temos um objeto (instncia) em um determinado tempo.
Podemos enxergar dados reais facilitando a compreenso e a
modelagem de estrutura complexas de dados. Auxilia ainda na
identificao de problemas na execuo de uma aplicao.
A representao grfica semelhante classe, um retngulo com
duas partes. Na primeira exibido o nome do objeto sublinhado (pode ser
omitido desde que mantenha os dois pontos e o nome da classe e na
segunda os seus atributos um em cada linha com seus respectivos
valores:
Funcionrio1
: Funcionrio
Diagrama de Classes
Funcionrio
nome : string
cargo : string
salrio : real
Projeto
trabalha
1..*
0..1
gerencia
FuncionrioContratado
FuncionrioTerceirizado
carteiraProfissional: string
dataAdmisso:date
inicioContrato:date
terminoContrato:date
prestadoraServicos:string
taxaAdministracao:real
descrio:string
inicio: date
fim : date
custo : real
ENGENHARIA DE SOFTWARE
137
Diagrama de Objetos
P1:Projeto
descrio= Desenvolvimento do Sistema DKA
inicio = 01/12/2006
fim = 02/02/2007
custo = 6000,00
gerente
F1:FuncionarioContratado
F1:FuncionarioContratado
F1:FuncionarioTerceirizado
nome = Silvio Abreu
cargo = Analista de Sistemas
salrio = 2500,00
inicioContrato = 02/12/2006
fimContrato = 26/02/2007
prestadoraServio = SISTEM
taxaAdministrativa = 6
EXERCCIOS
01. Desenhe um diagrama de objetos para o diagrama de classes abaixo:
ENGENHARIA DE SOFTWARE
138
(Concurso
Serpro-2001-
ENGENHARIA DE SOFTWARE
139
DIAGRAMA DE SEQUENCIAS
Vamos imaginar a seguinte situao:
Preciso da lista de vendedores com o total
de vendas.
Relatrio de Comisses
Resposta:
100 Afonso 15.000,00
215 Andra 30.000,00
A quem pertence a matrcula 100?
RESPOSTA:
100 - Afonso
:ContraCheque
novo()
ENGENHARIA DE SOFTWARE
140
:Benefcio
:Funcionrio
excluirBenefcio()
:Aluno
obterNome(matrcula)
Ativao
Mensagem
de retorno
Mensagem
disc1:Disciplina
Coordenador
obterGrade()
PreReq]
condio: s se
for verdadeira
Grade
auto-chamada
ENGENHARIA DE SOFTWARE
141
sd DiagramaSeq1
objeto1
objeto2
mensagem
Venda
matrcula : string
nome : string
dataAdmissao : date
salarioBruto : real
/salarioLiquido : real
percentualComissao : real
0..*
numero : integer
data : date
valor : real
grava()
obterListaVendedoresAtivos()
calcularSalarioLiquido(dataRef) : real
ENGENHARIA DE SOFTWARE
142
Diagrama de Sequncias:
:Venda
:TelaCadastro
Assistente de
Gerncia
obterListaVendedoresAtivos()
numero_venda
busca(nmero_venda)
data, valor
seleo do vendedor
grava()
Vamos fazer
juntos???
:Vendedor
ENGENHARIA DE SOFTWARE
143
ENGENHARIA DE SOFTWARE
144
ENGENHARIA DE SOFTWARE
145
ENGENHARIA DE SOFTWARE
146
ENGENHARIA DE SOFTWARE
147
EXERCCIOS
ENGENHARIA DE SOFTWARE
148
ENGENHARIA DE SOFTWARE
149
a) Cadastrar cliente;
b) Efetuar aluguel.
ENGENHARIA DE SOFTWARE
150
Figura 64 Requisitos
ENGENHARIA DE SOFTWARE
151
ELICITAO DE REQUISITOS
Por ser onde identificamos os requisitos, ou seja a ideia inicial do
sistema, necessrio a compreenso do problema.
PROBLEMAS
Escopo;
Entendimento;
Volatilidade.
DESAFIOS
ENGENHARIA DE SOFTWARE
152
ENGENHARIA DE SOFTWARE
153
CASOS DE USO
focando
nos
problemas
ENGENHARIA DE SOFTWARE
PROBLEMA:
DETALHAMENTO
TCNICO
ESPECIFICAO FUNCIONAL DO SISTEMA.
154
DESNECESSRIO
DURANTE
SOLUO
GERNCIA DE REQUISITOS
PROBLEMA: DIFICULDADES DE ESTABELECER UMA
ATUALIZAO E REUTILIZAO DE CASOS DE USO
ESTRATGIA
PARA
SOLUO
ENGENHARIA DE SOFTWARE
155
PROBLEMA:
DIFICULDADE
DE
IMPLANTAO
RASTREABILIDADE DOS REQUISITOS.
MANUTENO
DA
SOLUO
PROBLEMA:
DIFICULDADES
DE
RASTREABILIDADE DOS REQUISITOS
ESTABELECIMENTO
RETROATIVO
DE
SOLUO
BOAS FRIAS!!!!
Obrigada por tudo e me desculpe
por alguma coisa.