Aula 8 – Análise de Projetos de Sistemas

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/