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.


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.


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.


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.


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.


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.


16

Adicionando o modelo

funcional ao projeto.


17

Adicionando diagrama de caso de uso

“Visão Geral” ao projeto.


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


20

Adicionando a

Manutenção a todos

os cadastros.

Bibliotecário

GerenciarLeitores

CategorizarLeitores

GerenciarObras

Literárias

CategorizarObras


EmprestarObra

Leitor

Devolver aObra

ConsultarCadastros

<<include>>

<<include>>

<<include>>

<<include>>

<<include>>

Incluir, Alterar eExcluir Cadastros

(Manutenção)

<<extend>>


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


EmprestarObra

Leitor

Devolver aObra

ConsultarCadastros

<<include>>

<<include>>

<<include>>

<<include>>

<<include>>

Incluir, Alterar eExcluir Cadastros

(Manutenção)

<<extend>>

22


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.


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.


25


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


É 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?”


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


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:


34

Nome da classe em itálico indica que ela

é abastrata, ou seja, não será

instanciada.


35

Métodos ou atributos sublinhados

indicam que o escopo é de classe ao

invés de instância (objeto).


36

A classe descendente (filha) herda

atributos e métodos da classe ancestral

(pai).


37

Modelando as demais classes:

Vamos aos

detalhes…


38


Agrupar

Semelhanças

(abstração)

Observem o

atributo

“telefone”


39


Multiplicidade


40

Modelando a movimentação:

Vamos aos

detalhes…


41


Composição


42


Relatórios

representados

pelo tipo “List”


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.


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.


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.


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.


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


usando a opção de menu Tools -> StarUML

Generator…

Clique em

Next


50


usando a opção de menu Tools -> StarUML

Generator…

Clique em

Generate.


51




Clique em

Finish.


52




Clique em

Finish.

PRONTO!


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;


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/

Documents

Aula 8 – Análise de Projetos de Sistemas