Upload
emanuelchaves
View
2.013
Download
1
Embed Size (px)
Citation preview
1
Curso de Gestão da TI
Análise de Projetos de Sistemas
Prof. Flávio Barbosa
23/09/2009
2
Módulo 4.1
Aula 8
Estudo de Caso
3
AGENDA• Análise Estruturada x Análise OO• Construção dos diagramas do SI da
biblioteca
4
Para solucionar o problema do reduzido
reaproveitamento dos códigos
(reusabilidade), definiu-se melhor a ideia de
Análise Orientada a Objeto (AOO).
O setor de informática da maioria das
organizações têm desenvolvido os seus
softwares utilizando a programação
orientada a objeto.
ANÁLISE ESTRUTURADA x ANÁLISE OO
5
A programação orientada a objeto (POO) é
diferente da programação estruturada.
Na POO, funções e dados estão juntos,
formando o objeto. Essa abordagem cria uma
nova forma de analisar, projetar e
desenvolver programas; uma forma mais
abstrata e genérica, que permite maior
reaproveitamento dos códigos e facilita a
sua manutenção.
ANÁLISE ESTRUTURADA x ANÁLISE OO
6
Cuidado! Existem gatos no mundo OO.A maioria dos bancos de dados (BD) são
relacionais, ou seja, não OO.Se no seu produto houver um atributo com a
imagem, quando o objeto for criado ele poderá
trazer a imagem mesmo não a utilizando. Esse
simples exemplo, aumentaria o tráfego da rede
e processamento do BD desnecessariamente.
PODERÁ porque é
possível utilizar de
implementações que
busquem a informação
somente quando for
utilizada.
ANÁLISE ESTRUTURADA x ANÁLISE OO
7
Observe que a análise (modelagem)
orientada a objeto não é somente uma
nova forma de programar, mas uma nova
forma de pensar um problema, de forma
abstrata, utilizando conceitos do mundo
real e não conceitos computacionais.
ANÁLISE ESTRUTURADA x ANÁLISE OO
8
O usuário final verá todos
os ícones e janelas da tela
como objetos e associará a
manipulação desses objetos
visuais à manipulação dos
objetos reais que eles
representam.
ANÁLISE ESTRUTURADA x ANÁLISE OO
8
9
Por exemplo, um ícone impressora representará a impressora de seu sistema computacional (real) e permitirá a execução deimpressão, a seleção do tamanho da página, entre outras operações com esse objeto.
ANÁLISE ESTRUTURADA x ANÁLISE OO
10
A UML define somente como deve ser o Diagrama
de Casos de Uso (desenho), e não a narrativa.
Esse fato provocou e, provoca, a disseminação
de vários templates (modelos) de como escrever
as narrativas dos casos de uso.
CONSIDERAÇÃO SOBRE CASOS DE USO
TEXTODESENHO
10
11
Não há um consenso geral sobre como
descrever a narrativa, existem técnicas,
mas não é possível afirmar que essa ou
aquela está correta, isso dependerá:Projeto;Processos; Ferramentas
disponíveis.
CONSIDERAÇÃO SOBRE CASOS DE USO
12
Sistema de biblioteca.
Ferramenta para modelagem dos
casos de uso será o StarUML.
Os requisitos estão no livro didático.
ESTUDO DE CASO
13
Site da ferramenta StarUML encontra-se no
endereço: http://staruml.sourceforge.net/en/
ESTUDO DE CASO
14
O StarUML permite a criação de projeto por
Abordagem, ou seja, ele cria uma “estrutura”
baseada em cada uma das abordagens que
ele oferece.
Criando um novo projeto no StarUML
Será utilizado
um projeto
vazio.
15
Definido o título do projeto
e algumas propriedades
referentes a autoria do
modelo.
Criando um novo projeto no StarUML
16
Adicionando o modelo
funcional ao projeto.
Criando um novo projeto no StarUML
17
Adicionando diagrama de caso de uso
“Visão Geral” ao projeto.
Criando um novo projeto no StarUML
18
DIAGRAMA DE CASO DE USO: Visão Geral
Bibliotecário
Leitores
Categoriade Leitores
ObrasLiterárias
Categoriade Obras
Funcionários
Empréstimoda Obra
Leitor
Devoluçãoda Obra
Essa é a visão geral dos requisitos.
Incrementando os requisitos…
19
Adicionando a
Consulta a todos os
cadastros.
Incrementando os requisitos…
Bibliotecário
GerenciarLeitores
CategorizarLeitores
GerenciarObras
Literárias
CategorizarObras
GerenciarFuncionários
EmprestarObra
Leitor
Devolver aObra
ConsultarCadastros
<<include>>
<<include>>
<<include>>
<<include>>
<<include>>
DIAGRAMA DE CASO DE USO: Visão Geral
20
Adicionando a
Manutenção a todos
os cadastros.
Bibliotecário
GerenciarLeitores
CategorizarLeitores
GerenciarObras
Literárias
CategorizarObras
GerenciarFuncionários
EmprestarObra
Leitor
Devolver aObra
ConsultarCadastros
<<include>>
<<include>>
<<include>>
<<include>>
<<include>>
Incluir, Alterar eExcluir Cadastros
(Manutenção)
<<extend>>
DIAGRAMA DE CASO DE USO: Visão Geral
21
ATIVIDADE EM DUPLAS – SOLICITO INTERAÇÃO
Quais os requisitos ou
tipo de requisitos, que
não estão contemplados
pelo diagrama de Caso de
Uso “Visão Geral”
observando o item “B1” do
livro didático p.170? Por
que não estão
contemplado?
Bibliotecário
GerenciarLeitores
CategorizarLeitores
GerenciarObras
Literárias
CategorizarObras
GerenciarFuncionários
EmprestarObra
Leitor
Devolver aObra
ConsultarCadastros
<<include>>
<<include>>
<<include>>
<<include>>
<<include>>
Incluir, Alterar eExcluir Cadastros
(Manutenção)
<<extend>>
22
DIAGRAMA DE CASO DE USO: Visão Geral
Adicionando
um
Descritivo
Narrativo
(documen-
tação) aos
casos de
uso.
23
Explicitando a
dependência
entre casos de
uso (seta
pontilhada).
O caso de uso origem, de onde a seta saiu,
depende do caso de uso que está recebendo a
seta ou está sendo apontado.
DIAGRAMA DE CASO DE USO: Visão Geral
24
Neste exemplo se lê
a dependência:
“Gerenciar Leitores”
depende de
“Categorizar
Leitores”.Isso porque é necessário ter a categoria
de leitores previamente cadastrada para
ser usada no registro do leitor.
DIAGRAMA DE CASO DE USO: Visão Geral
25
DIAGRAMA DE CASO DE USO: Visão Geral
Por que não foi
criado um
<<include>> ao
invés de indicar a
dependência?
Porque “Categorizar Leitores” existe sozinho, ou
seja, independente do Caso de Uso “Gerenciar
Leitores” existir, ele é um cadastro próprio.
26
DIAGRAMA DE CASO DE USO: Visão Geral
É o mesmo caso
de “Gerenciar
Obras
Literárias” que
depende de
“Categorizar
Obras”.
27
Ao documentar o caso de uso “Gerenciar
Funcionários” observá-se que o bibliotecário terá
acesso a essa funcionalidade. Uma pergunta deve
ser respondida junto
ao usuário:
“O Bibliotecário
poderá gerir os
funcionários?”
DIAGRAMA DE CASO DE USO: Visão Geral
ESSE EXEMPLO EXPLICA
PORQUE O DIAGRAMA DE
CASO DE USO TAMBÉM É
UMA TÉCNICA DE
ELICITAÇÃO
(LEVANTAMENTO) DE
REQUISITOS.
ESSE EXEMPLO EXPLICA
PORQUE O DIAGRAMA DE
CASO DE USO TAMBÉM É
UMA TÉCNICA DE
ELICITAÇÃO
(LEVANTAMENTO) DE
REQUISITOS.
28
DIAGRAMA DE CASO DE USO: Visão Geral
Neste exemplo foi
descoberto algo
que o cliente não
sabia ou não
havia pensado.
O Stakeholder consultado
definiu que o Depto. De RH
gerenciará os funcionários.
O Stakeholder consultado
definiu que o Depto. De RH
gerenciará os funcionários.
29
ATIVIDADE
Porém, o
Stakeholder poderia
ter dito que existe um
bibliotecário gerente
responsável pelos
cadastro dos
funcionários.
Neste caso, como ficaria esse modelo?
30
Adicionando o modelo
estrutural ao projeto.
Criando o modelo estrutural
31
Adicionando diagrama de classe
“Classes Gerais” ao projeto.
Criando um novo diagrama no modelo estrutural
32
É importante começar a modelagem das
classes pelos casos de uso que são
dependências
de outros.
Criando as Classes do SI
Vamos observar
quem recebe a
seta de
dependência:
33
No modelo de Classes Gerais criado
modelamos as classes dependentes:
Criando as Classes do SI
34
Nome da classe em itálico indica que ela
é abastrata, ou seja, não será
instanciada.
Criando as Classes do SI
35
Métodos ou atributos sublinhados
indicam que o escopo é de classe ao
invés de instância (objeto).
Criando as Classes do SI
36
A classe descendente (filha) herda
atributos e métodos da classe ancestral
(pai).
Criando as Classes do SI
37
Modelando as demais classes:
Vamos aos
detalhes…
Criando as Classes do SI
38
Modelando as demais classes:
Agrupar
Semelhanças
(abstração)
Observem o
atributo
“telefone”
Criando as Classes do SI
39
Modelando as demais classes:
Multiplicidade
Criando as Classes do SI
40
Modelando a movimentação:
Vamos aos
detalhes…
Criando as Classes do SI
41
Modelando a movimentação:
Composição
Criando as Classes do SI
42
Modelando a movimentação:
Relatórios
representados
pelo tipo “List”
Criando as Classes do SI
43
Atendendo os requisitos B2 – Impressões.O sistema deve permitir a impressão de uma listagem das obras emprestadas no momento, agrupadas por categoria de obra, contendo o nome do leitor, título da obra, data de retirada e data prevista para devolução.
Criando as Classes do SI
44
Atendendo os requisitos B2 – Impressões.O sistema deve permitir a impressão de um relatório contendo as obras em atraso no período (por exemplo, semanal ou quinzenal), contendo, para cada dia do período, o nome do leitor, o telefone, o e-mail, a data de empréstimo e a data prevista para devolução.
Criando as Classes do SI
45
Atendendo os requisitos B2 – Impressões.O sistema deve permitir ao leitor imprimir um histórico de seus empréstimo de obras. Para tal o leitor deve ter sido previamente cadastrado e deve portar um código de identificação e uma senha.Esse histórico deve conter uma linha para cada obra emprestada pelo leitor, contendo o título da obra, a data de retirada e devolução e o valor da multa em cada ocasião.
Criando as Classes do SI
46
Atendendo os requisitos B2 – Impressões.O sistema deve permitir a consulta on-line da situação de uma obra literária. Uma obra está ocupada se existe um leitor que a emprestou no momento. Essa consulta deve mostrar uma linha para cada obra, constando, em cada uma dessas linhas, o título da obra, o número de cópias existentes, o número de obras ocupadas e o número de obras disponíveis.
Criando as Classes do SI
47
Atendendo os requisitos B2 – Impressões.
Modelo de Caso de Uso para Listagens
48
O StarUML pode gerar a documentação
usando a opção de menu Tools ->
StarUML Generator…
Clique em
Next
Gerando a documentação do SI.
49
O StarUML pode gerar a documentação
usando a opção de menu Tools -> StarUML
Generator…
Clique em
Next
Gerando a documentação do SI.
50
O StarUML pode gerar a documentação
usando a opção de menu Tools -> StarUML
Generator…
Clique em
Generate.
Gerando a documentação do SI.
51
O StarUML pode gerar a documentação
usando a opção de menu Tools ->
StarUML Generator…
Clique em
Finish.
Gerando a documentação do SI.
52
O StarUML pode gerar a documentação
usando a opção de menu Tools ->
StarUML Generator…
Clique em
Finish.
PRONTO!
Gerando a documentação do SI.
53
O documento gerado pelo StarUML tem as
seguintes caracteristicas:
1.Índice Analítico e Remissivo;
2.Contem a Narrativa dos casos bem
como os diagramas dos seus gráficos;
Gerando a documentação do SI.
54
Diagrama de Implantação
Documentando Requisitos Não-Funcionais
55
1. Sistemas
2. Sistemas de Informação
3. Ciclo de Vida
4. Engenharia de Requisitos
5. Análise Estruturada e Orientada a
Objetos
REVISÃO
56
Visite o site e avalie a aula.
Utilize seu código e senha de aluno.
http://www.inepad.org.br/interativacoc/