Aula 7 – Análise de Projetos de Sistemas

1

Curso de Gestão da TI

Análise de Projetos de Sistemas

Prof. Flávio Barbosa

16/09/2009

2

Módulo 4.1

Aula 7

Análise Orientada a Objetos II

3

AGENDA• Processo Unificado• Estudo de Caso 1: Jogo da Velha• Estudo de Caso 2: Biblioteca

4

Um processo é um conjunto de passos que

define “quem” está “fazendo” “o que”,

“quando” e “como” para alcançar

determinado objetivo.

O QUE É UM PROCESSO?

Jacobson, I.; Booch, G.; Rumbaugh, J. The Unified Software Development Process, 1999. 4

5

Linguagem para Modelagem Unificada

Independente de processo

Indica apenas como criar e ler modelos

Não diz como, quando ou quais modelos

deverão ser criados

UML – Unified Modeling Language

Isso fica por conta do processo de desenvolvimento do software.

6

Vantagens: Padronização da linguagem de

comunicação entre os envolvidos

(desenvolvedores, analistas e usuários); Redução da ambiguidade; Reaproveitamento dos diagramas (um

mesmo diagrama pode ser utilizado em

diversas fases de desenvolvimento do

software);


7

Exemplo: Engenharia reversa com Netbeans.

Este vídeo ilustra a Geração do modelo a partir

do código, ou seja, realiza engenharia reversa.

www.netbeans.org

Vantagens: Mapeamento direto das classes para

linguagens de programação orientadas a

objetos e “vice-versa”.

ww

w.n

etbe

ans.

org


8

Portanto....

UML é apenas parte de um método para

desenvolvimento de SI, e o fato de ser

independente de processo lhe permite ser

utilizado em vários processos de

engenharia de software.


9

Do dicionário Michaelis, metodologia

significa:

1. Estudo científico dos métodos.

2. Arte de guiar o espírito na investigação

da verdade.

3. Filos Parte da Lógica que se ocupa dos

métodos do raciocínio, em oposição à

Lógica Formal.

METODOLOGIA

10

É uma metodologia que utiliza toda a

definição da UML;

É um framework genérico de um

processo de desenvolvimento;

Baseado em componentes;

Orientado pelos casos de uso, centrado na

arquitetura, iterativo e incremental

(diferencial).

Processo Unificado (PU)

JACOBSON, I. et al. The unified software development process. Reading : Addison-Wesley, 1999

11

Dirigido por casos de uso: Um software tem por finalidade servir seus usuários. Portanto, para construir um sistema de sucesso devemos saber quem são seus usuários potenciais e o que eles querem e precisam.

11


12

Dirigido por casos de uso:

O termo usuário representa alguém ou

alguma coisa (como um outro sistema)

que interage com o sistema que está sendo

desenvolvido.


13


A interação do usuário com o

sistema é realizada através de

uma interface.

Quando o usuário é um ser

humano a interface geralmente

é representada por um

dispositivo e/ou software.13


14


Quando o usuário é um outro

sistema a interface pode ser, no

meio lógico (software), por

exportação/importação de

arquivos, banco de dados

(SGDB), webservices, etc..


15

Dirigido por casos de

uso:

No meio físico, as

interfaces podem ser

por antenas, cabos,

ondas de frequência

(RFID), etc..


16

Dirigido por casos de uso: Outra expectativa dos casos de uso é atender, exatamente, às necessidades de cada usuário que interage com o SI, evitando funcionalidades desnecessárias.


17


Alistair Cockburn diz que um caso de uso é

uma coleção de possíveis sequências de

interações entre o SI em estudo e os

usuários deste, relacionado a um

determinado objetivo.


18


Um caso de uso é um

pedaço de funcionalidade do

SI que retorna ao usuário um

resultado de valor.

JACOBSON, I. et al. The unified software development process. Reading : Addison-Wesley, 1999.JACOBSON, I. Objectory is the unified process. Component Strategies, v.1, n. 10, Apr., 1998 p. 67-72.ERIKSSON, H. E.; PENKER, M. UML Toolkit. New York : John Wiley, 1998.


19


Casos de uso capturam requisitos

funcionais e todos juntos resultam no

modelo de casos de uso, o qual descreve a

funcionalidade completa do SI.

JACOBSON, I. et al. The unified software development process. Reading : Addison-Wesley, 1999.JACOBSON, I. Objectory is the unified process. Component Strategies, v.1, n. 10, Apr., 1998 p. 67-72.ERIKSSON, H. E.; PENKER, M. UML Toolkit. New York : John Wiley, 1998.


20


Este modelo substitui a

especificação funcional

tradicional (DFD, por exemplo),

cujo papel é responder à

seguinte questão:

“O que o sistema faz?”20


21


A estratégia de casos de uso pode ser

caracterizada pela adição de 3 palavras no

final dessa pergunta: “o que o sistema faz...”

“...para cada usuário? ”

Vid

al M

artin

s w

ww

.bat

ebyt

e.pr

.gov

.br

Analisar (ver) os requisitos de diferentes ângulos,

onde cada ângulo corresponde a um usuário.


22


A estratégia de casos de uso pode ser

caracterizada pela adição de 3 palavras no

final dessa pergunta: “o que o sistema faz...”

“...para cada usuário? ”

Vid

al M

artin

s w

ww

.bat

ebyt

e.pr

.gov

.br

A importância destas 3 palavras é que nos fazem

pensar nos valores dos usuários, não apenas em

funções que poderiam ser interessantes.


23


Direcionam o processo de desenvolvimento:

1.Desenvolvedores criam uma série de

modelos de projeto e implementação que

os realizam efetivamente.

Vid

al M

artin

s w

ww

.bat

ebyt

e.pr

.gov

.br


24


Direcionam o processo de desenvolvimento:

2.Equipes de testes realizam seu trabalho

para garantir que os componentes do

modelo de implementação cumpram

corretamente os objetivos estabelecidos

nos casos de uso.

Vid

al M

artin

s w

ww

.bat

ebyt

e.pr

.gov

.br


25


Não só iniciam o processo de

desenvolvimento, como também o

mantêm coeso.

Vid

al M

artin

s w

ww

.bat

ebyt

e.pr

.gov

.br


26

Dirigido por casos de uso significa que o

processo de desenvolvimento executa

uma sequência de tarefas derivadas dos

casos de uso.

Eles são especificados, projetados e

servem de base para a construção dos

casos de teste.

Vid

al M

artin

s w

ww

.bat

ebyt

e.pr

.gov

.br


27


Os casos de uso direcionam a arquitetura

do SI, que por sua vez, influencia a

seleção dos casos de uso.

Portanto, ambos (arquitetura e casos de

uso) amadurecem no decorrer do ciclo de

vida do SI.

Vid

al M

artin

s w

ww

.bat

ebyt

e.pr

.gov

.br


28

Centrado em arquitetura:

Se refere a integração dos componentes

do SI, a definição da arquitetura definirá

como o SI será criado e evoluído.


29


O conceito de arquitetura de software

incorpora os aspectos estáticos e

dinâmicos mais importantes do SI.

Vid

al M

artin

s w

ww

.bat

ebyt

e.pr

.gov

.br


30


Os principais fatores que influenciam a

arquitetura são:

Plataforma sobre a qual o SI irá funcionar

(SO, SGDB, protocolos de rede, etc.);

Blocos de construção reusáveis disponíveis

(por exemplo, um framework para construção

de interface gráfica com o usuário);

Vid

al M

artin

s w

ww

.bat

ebyt

e.pr

.gov

.br


31


Os principais fatores que influência a

arquitetura são:

Distribuição;

Sistemas legados e requisitos não

funcionais (performance, confiabilidade,

etc.).

Vid

al M

artin

s w

ww

.bat

ebyt

e.pr

.gov

.br


32


Ela representa uma visão do projeto

de software (SI) como um todo, na qual

as características mais importantes

são colocadas em destaque, deixando

os detalhes de lado.

Vid

al M

artin

s w

ww

.bat

ebyt

e.pr

.gov

.br


33

Observem essas figuras:

ENTENDENDO CASO DE USO & ARQUITETURA

A arquitetura

deste sistema

permitirá a

instalação da

tomada

(requisito)?

33

34

Observem essas figuras:

Energia eólica é

limpa, portanto

ecologicamente

correta.

Mas, a arquitetura da região produz vento suficiente (requisito) para instalação das

turbinas de vento? 34


35

Observem essas figuras:A arquitetura da laje

suportará (requisito) o

peso das pessoas

quando elas estiverem

no segundo andar?

35


36

Agrupem-se e respondam!

ATIVIDADE!

A arquitetura do SI deve permitir a captura

de imagens de uma webcam

(requisito funcional), porém o driver funciona

apenas em Windows (requisito não funcional).

Observando o texto

ao lado e as figuras

anteriores responda:

Qual a relação dos

casos de uso

(requisitos) com a

arquitetura do SI?

37

Se o driver funciona apenas no windows então, necessariamente, a arquitetura do SI deverá funcionar sobre plataforma Windows.Isso elicita outros requisitos:1.Qual a configuração dos computadores?2.Existem licenças suficientes?3.E a parte do SI que não precisará de webcam, terá de funcionar sobre plataforma Windows também? Pode ser Web?

RESPOSTA!

38

Os casos de uso correspondem as

funcionalidades do SI (requisitos), enquanto

a arquitetura corresponde a forma como

serão montadas ou mostradas essas

funcionalidades, ou seja, os requisitos

(casos de uso) definirão quais formas

(arquiteturas) o SI poderá assumir.

RESPOSTA!

39

Os requisitos (casos de uso) definirão quais

formas (arquiteturas) o SI poderá assumir.

R1 + R2 =

R3 + R4 =

RELAÇÃO:RX + RY = ?

RESPOSTA!

40


Para encontrar essa forma, os arquitetos

devem trabalhar a partir de uma

compreensão geral das funções

(requisitos) chave do SI, isto é, dos casos

de uso chave.

PROCESSO UNIFICADO (PU)

Vid

al M

artin

s w

ww

.bat

ebyt

e.pr

.gov

.br

41

Iterativo e incremental:

Um projeto usando o PU sempre vai ser

iterativo.

Uma iteração é um miniprojeto que resulta

em versão do SI.

Como a cada iteração teremos uma versão

melhor que a anterior, isso o caracteriza

como incremental.


42

Iterativo e incremental:


43

Cada ciclo é concluído com uma versão

do produto pronta para distribuição;

Uma versão é um conjunto

relativamente completo e consistente de

artefatos (executável do software e

manuais);

As versões podem ser distribuídas para

usuários internos ou externos.

CICLO DE VIDA DO PROCESSO UNIFICADO

Vid

al M

artin

s w

ww

.bat

ebyt

e.pr

.gov

.br

44

Cada ciclo consiste em 4 (quatro) fases:

1.Início

2.Elaboração

3.Construção

4.Transição

Cada fase é também subdividida em

iterações, como discutido anteriormente.

Vid

al M

artin

s w

ww

.bat

ebyt

e.pr

.gov

.br


45

Cada ciclo consiste de 4 (quatro) fases:

1.Concepção (Início)

2.Elaboração

3.Construção

4.Transição

Cada fase é também subdividida em

iterações, como discutido anteriormente.

Vid

al M

artin

s w

ww

.bat

ebyt

e.pr

.gov

.br


4646


47

ATIVIDADE

Você, como gestor de TI, concentraria

esforços em qual ou quais fases (início,

elaboração, construção e transição) e por

quê?

Agrupem-se e respondam!

47

48

RESPOSTA

Na fase de início e elaboração porque é

onde estão os maiores esforços na

modelagem do negócio e elicitação de

requisitos (casos de uso)

que direcionam todo o

restante do SI.

48

49

ESTUDO DE CASO: SI DE BIBLIOTECA

A - Visão geral do sistema:O sistema para a Biblioteca consiste no gerenciamento dos empréstimos de obras literárias, bem como da devolução dessas obras.

O sistema deve emitir diversos tipos de relatórios e consultas, possibilitando um melhor gerenciamento dos empréstimos.

50

B - Requisitos funcionais

B1 - Lançamentos diversos

1.O sistema deve permitir a inclusão, alteração e consulta de leitores da biblioteca, com os seguintes atributos:

nome, endereço, cidade, estado, telefone, e-mail, documento de identificação, categoria de leitor e data de nascimento.


51

2. O sistema deve permitir a inclusão, alteração e remoção das diversas categorias de leitores, com os seguintes atributos: código da categoria, descrição da categoria e número máximo de dias que essa categoria de leitor pode emprestar uma obra.

Exemplos de categorias de leitores são: aluno de graduação, aluno de pós-graduação, professor, funcionário e usuário externo.


52

3. O sistema deve permitir a inclusão, alteração e remoção das diversas categorias de obras literárias, com os seguintes atributos: código da categoria, descrição da categoria, número máximo de dias que esse tipo de obra pode ficar emprestado e taxa diária de multa por atraso na devolução.

Exemplos de categorias de obras literária são: livro,periódico, revista, nota didática, jornal, relatório

técnico, tese de doutorado e dissertação de mestrado.


53

4. O sistema deve permitir a inclusão, alteração e remoção das obras literárias da biblioteca. Cada obra possui os seguintes atributos: código, ISBN, título da obra, código da categoria de obra literária, autores, palavras-chave, data da publicação, número de edição, editora e número de página.

Cada obra pode possuir uma ou mais cópias na biblioteca. Assim, o sistema deve atribuir um identificador único a cada uma das cópias.


54

5. O sistema deve permitir a inclusão,

alteração e remoção de funcionários da

biblioteca, com os seguintes atributos:

nome, endereço, cidade, estado, telefone

e data de nascimento.


55

6. O sistema deve permitir o empréstimo de uma obra

literária por um leitor. Cada empréstimo possui os

seguintes atributos: data de empréstimo da obra, data

prevista para devolução, identificação do leitor

(previamente cadastrado), funcionário responsável

pelo empréstimo e identificação da cópia da obra

emprestada. O sistema deve calcular a data prevista

para devolução com base na categoria da obra,

limitando o tempo de acordo com a categoria de leitor.


56

7. O sistema deve permitir a devolução da obra por um leitor, com os seguintes atributos: identificação da cópia da obra emprestada, data de devolução da obra. O sistema deve automaticamente calcular uma multa se a data de devolução for superior à data prevista para devolução da obra. O valor da multa é calculado multiplicando-se o número de dias de atraso pela taxa diária de atraso, de acordo com a categoria de obra literária.


57

B2 - Impressão de diversos tipos de relatórios

e consultas

8.O sistema deve permitir a impressão de

uma listagem das obras emprestadas no

momento, agrupadas por categoria de obra,

contendo:

Nome do leitor, título da obra, data de retirada

e data prevista para devolução.


58

9. 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:

Nome do leitor, o telefone, o e-mail, a data

de empréstimo e a data prevista para

devolução.


59

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


60

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


61

C - Requisitos não-funcionais

C1. Confiabilidade

12.O sistema deve ter capacidade para

recuperar os dados perdidos da última

operação que realizou em caso de falha.


62

13.O sistema deve fornecer facilidades para a realização de backups dos arquivos do sistema.

14.O sistema deve possuir senhas de acesso e identificação para diferentes tipos de usuários:administrador do sistema, funcionários da biblioteca e leitores que têm acesso ao sistema na biblioteca (em quiosques especiais).


63

C2. Eficiência

15.O sistema deve responder a consultas

on-line em menos de 5 segundos.

16.O sistema deve iniciar a impressão de

relatórios solicitados dentro de no máximo

20 segundos após sua requisição.


64

C3. Portabilidade

17.O sistema deve ser executado em

computadores Pentium 200mHz ou

superior, com sistema operacional

Windows 98 ou acima.

18.O sistema deve ser capaz de

armazenar os dados em base de dados

Oracle ou Sybase.


65

Martins V. O processo unificado de desenvolvimento de

software. Acessado em 13/09/2009:

www.batebyte.pr.gov.br

JACOBSON, I. et al. The unified software development process. Reading : Addison-Wesley, 1999.

JACOBSON, I. Objectory is the unified process. Component Strategies, v.1, n. 10, Apr., 1998 p. 67-72.

ERIKSSON, H. E.; PENKER, M. UML Toolkit. New York : John Wiley, 1998.

REFERÊNCIAS

66

Tema 8 – ESTUDO DE CASO Análise Estruturada x Análise OO. Construção dos diagramas do SI

da biblioteca.

O que veremos na

próxima aula:

Não se esqueçam de: Ler o material didático. Participar das atividades do

portal.

67

Curso de Gestão da TI

Obrigado!

Nos vemos em nossa plataforma.

Prof. Flavio Barbosa

68

Visite o site e avalie a aula.

Utilize seu código e senha de aluno.

http://www.inepad.org.br/interativacoc/

Documents

Aula 7 – Análise de Projetos de Sistemas