Padro de Anlise de Sistemas

Verso 2.5

Padro de
Anlise de Sistemas
Verso 2.5
Padro de Anlise de Sistemas
Verso 2.5

Histrico de Atualizaes
Verso Data Alteraes
1.0 15/03/2007 Definio de boas prticas para a Anlise de Sistemas
1.1 30/04/2007 Alterao no diagrama de implementao de classes para
componentes.
Incluso da forma de trabalho com documentos replicados na rede.
Nomenclatura dos diagramas dentro da especificao (para conter o
nome da funcionalidade e no mais apenas fluxo ou
especificao).
1.2 22/05/2007 Adicionado o apndice no documento contendo diversas orientaes
rpidas para o desenvolvimento da atividade de anlise de sistemas.
2.0 18/09/2007 Padro de Orientao a Objetos.
2.1 06/12/2007 Adicionado padro de solicitao ADO.
2.2 03/01/2008 Incluso de um novo controle nas solicitaes ADO e incluso dos
mecanismos para Anlise de Impacto.
2.3 08/02/2008 Alterado padro de solicitao ADO.
2.4 11/02/2008 Inserido Rastreabilidade
2.5 22/02/2008 Inserido Relacionamento Entre Casos de Uso.

20/3/2008 Pgina 2 de 64
Padro de Anlise de Sistemas
Verso 2.5

ndice
INTRODUO..................................................................................................................................5

1. ENTERPRISE ARCHITECT...................................................................................................6

1.1 VISO GERAL ................................................................................................................................... 6

1.2 LICENAS ......................................................................................................................................... 6
1.3 PADRES .......................................................................................................................................... 6
1.4 CONFIGURAO ............................................................................................................................... 6

2. DIAGRAMAS, ELEMENTOS E LIGAES .......................................................................8

2.1 DIAGRAMAS ..................................................................................................................................... 8

2.2 ELEMENTOS E LIGAES................................................................................................................ 10
2.2.1 Caso de Uso............................................................................................................................... 10
2.2.2 Requisitos................................................................................................................................... 10
2.2.3 Alteraes .................................................................................................................................. 11
2.2.4 Classes ....................................................................................................................................... 12
2.2.5 Tabelas....................................................................................................................................... 12
2.2.6 Componentes.............................................................................................................................. 12
2.2.7 Atividades .................................................................................................................................. 13

3. ESTRUTURAS DOS PROJETOS .........................................................................................16

3.1 PADRES DE ESTRUTURAS DE PROJETOS ....................................................................................... 16

3.1.1 Manuteno ............................................................................................................................... 17
3.1.2 Banco de Dados......................................................................................................................... 20
3.1.3 Funcionalidades ........................................................................................................................ 20
3.1.4 Requisitos................................................................................................................................... 24
3.1.5 Implementao........................................................................................................................... 25
3.1.6 Casos de Uso ............................................................................................................................. 26
3.1.7 Modelo Lgico ........................................................................................................................... 27
3.1.8 Componentes.............................................................................................................................. 28
3.1.9 Distribuio ............................................................................................................................... 29
3.1.10 Relacionamento Entre Casos de Uso .................................................................................... 29

4. PROCEDIMENTOS................................................................................................................31

4.1 LEVANTAMENTO DE REQUISITOS ................................................................................................... 32

4.1.1 Identificar requisitos funcionais ................................................................................................ 32
4.1.2 Identificar requisitos no funcionais ......................................................................................... 33

20/3/2008 Pgina 3 de 64
Padro de Anlise de Sistemas
Verso 2.5

4.1.3 Identificar alteraes no modelo ............................................................................................... 33

4.2 ESPECIFICAO DO ITEM ............................................................................................................... 35
4.2.1 Atualizar diagramas de caso de uso, atividades e implementao............................................ 35
4.2.2 Solicitar alteraes ADO e atualizar diagrama de entidades ................................................ 36
4.2.3 Atualizar diagrama de atividades.............................................................................................. 40
4.3 DOCUMENTAO INICIAL .............................................................................................................. 41
4.3.1 Pr-documentao da funcionalidade a ser alterada................................................................ 41
4.4 TEMPLATES DISPONVEIS ............................................................................................................... 44
4.4.1 Solicitao ADO ..................................................................................................................... 45
4.4.2 Prottipo de Tela ....................................................................................................................... 45
4.4.3 Prottipo de Relatrio ............................................................................................................... 46
4.4.4 Caso de Uso............................................................................................................................... 46
4.5 MECANISMOS DE RASTREABILIDADE............................................................................................. 46
4.5.1 Uso do Elemento........................................................................................................................ 46
4.5.2 Hierarquia de Uso do Elemento ................................................................................................ 47
4.5.3 Matriz de Rastreabilidade ......................................................................................................... 50

5. APNDICE...............................................................................................................................51

5.1 AGREGAO ................................................................................................................................... 51

5.2 CONTROLE DE VERSO (CVS) ....................................................................................................... 52
5.3 TRY..CATCH..END .......................................................................................................................... 54
5.4 ADICIONAR AUTORES .................................................................................................................... 55
5.5 DIAGRAMA DE FONTE DE INCLUDE ( *.CH ) .................................................................................. 57
5.6 INCLUIR OPO DE MENU ............................................................................................................... 59
5.7 FONTES LOCALIZADOS NA PASTA RAIZ DOS SISTEMAS ................................................................. 61
5.8 DOCUMENTAO DE JOB .............................................................................................................. 61

20/3/2008 Pgina 4 de 64
Padro de Anlise de Sistemas
Verso 2.5

Introduo

Esse documento tem por objetivo estabelecer as melhores prticas para a elaborao de
anlises de sistemas na rea de Desenvolvimento de Software do SICREDI, atravs da
ferramenta Enterprise Architect (EA).

20/3/2008 Pgina 5 de 64
Padro de Anlise de Sistemas
Verso 2.5

1. Enterprise Architect

1.1 Viso geral

O Enterprise Arquitect uma ferramenta CASE (Computer Aided Software

Engineering) para desenhar e construir sistemas baseando-se na UML 2.0.

1.2 Licenas

O EA possui duas licenas que sero utilizadas:

- Corporate: utilizada pelos Analistas de Sistemas para criao dos diagramas.
- Lite (viewer): utilizada pelos Programadores e Analistas de Testes para consulta
dos diagramas.

1.3 Padres

Sero utilizados dois padres distintos de projetos no EA:

- padro para linguagens de programao estruturada (PE);
- padro para linguagens orientadas a objetos (OO).

1.4 Configurao

Para armazenar a documentao, podemos utilizar duas formas:

- Banco de dados: o projeto armazenado no Oracle (esta opo ser utilizada em
novos projetos). Para conexo no banco, ser utilizado o Oracle Provider for OLE
DB, na opo Connect to server..., disponvel na tela principal. Nesta opo
devem ser configurados o nome do banco e o schema para conectar, conforme
exemplos abaixo:

20/3/2008 Pgina 6 de 64
Padro de Anlise de Sistemas
Verso 2.5

Telas de conexo no banco de dados Oracle

- Master e Rplicas: o projeto fica na rede em um arquivo Design Master e cada

Analista cria um arquivo rplica para sincronizar. Para a criao do arquivo Master,
j existe um template padro, que deve ser solicitado Qualidade de Software
(esta opo no ser mais utilizada).

20/3/2008 Pgina 7 de 64
Padro de Anlise de Sistemas
Verso 2.5

2. Diagramas, Elementos e Ligaes

2.1 Diagramas

O EA trabalha com os diagramas padres da UML e outros estendidos que sero

utilizados. Os diagramas podem ser includos nas views e packages atravs da opo
Add Diagram..., disponvel no boto direito do mouse, conforme abaixo:

Nos diagramas estruturais da UML, estaremos utilizando os seguintes:

- Package: para agrupar diagramas ou outras packages;
- Class: para diagramas de classes de sistemas orientado a objetos;
- Component: para componentes de software e cdigos-fonte;
- Deployment: para diagramar as arquiteturas das aplicaes.

20/3/2008 Pgina 8 de 64
Padro de Anlise de Sistemas
Verso 2.5

Nos diagramas comportamentais da UML, estaremos utilizando os seguintes:

- Use Case: para diagramar casos de uso, atores e seus relacionamentos;
- Activity: para diagramar o fluxo de atividades dos casos de uso.

Nos diagramas estendidos da ferramenta, estaremos utilizando os seguintes:

20/3/2008 Pgina 9 de 64
 Padro de Anlise de Sistemas
Verso 2.5

- Requirements: para diagramar os requisitos de cada caso de uso

(funcionais, no-funcionais, prottipos, tabelas e componentes de software
envolvidos, etc.);
- Maintenance: para diagramar as alteraes (change requests) efetuadas
no modelo ou sistema;

2.2 Elementos e Ligaes

Nesta seo estaremos especificando os tipos de elementos utilizados nos diagramas,

suas respectivas ligaes e as cores padres de cada tipo.

2.2.1 Caso de Uso

Elemento Objetivo Utilizado nos Ligaes Observaes

Diagramas
Especificar o caso de Casos de Uso e Casos de uso podem
uso a da Requisitos. estar ligados entre si
funcionalidade. atravs de include ou
extend.

2.2.2 Requisitos

Os requisitos utilizaro os elementos Requirement, sendo divididos nos tipos abaixo:

20/3/2008 Pgina 10 de 64
 Padro de Anlise de Sistemas
Verso 2.5

Elemento Objetivo Utilizado nos Ligaes Observaes

Diagramas
Especifica os requisitos Requisitos e Atividades. Devem ser ligados com
de negcio necessrios realisation no
funcionalidade. diagrama de requisitos,
Geralmente so tendo como origem o
apontados na Anlise caso de uso e destino o
de Negcio. requisito, e com
dependency no
diagrama de atividades,
tendo como origem a
atividade e destino o
requisito.
Especifica o layout do Requisitos e Atividades. Devem ser ligados com Deve possuir um
relatrio da realisation no documento vinculado
funcionalidade. diagrama de requisitos, utilizando o template
tendo como origem o Prottipo de Relatrio,
caso de uso e destino o atravs da opo
requisito, e com Linked Document.
dependency no
diagrama de atividades,
tendo como origem a
atividade e destino o
requisito.
Especifica o layout de Requisitos e Atividades. Devem ser ligados com Deve possuir um
tela da funcionalidade. realisation no documento vinculado
diagrama de requisitos, utilizando o template
tendo como origem o Prottipo de Tela,
caso de uso e destino o atravs da opo
requisito, e com Linked Document.
dependency no
diagrama de atividades,
tendo como origem a
atividade e destino o
requisito.
Especifica o layout do Requisitos e Atividades. Devem ser ligados com Deve possuir um
arquivo que o sistema realisation no documento vinculado
est gerando ou diagrama de requisitos, utilizando o template
importando. tendo como origem o Prottipo de Arquivo,
caso de uso e destino o atravs da opo
requisito, e com Linked Document.
dependency no
diagrama de atividades,
tendo como origem a
atividade e destino o
requisito.
Especifica sugestes de Manuteno Devem ser ligados com Sua utilizao
Testes para auxiliar o dependency ao opcional.
Analista de Testes na change no diagrama de
identificao de manuteno.
impactos para validar a
implementao.

2.2.3 Alteraes

As alteraes utilizaro os elementos Change, conforme abaixo:

Elemento Objetivo Utilizado nos Ligaes Observaes

Diagramas
Especificar as Manuteno Devem ser ligadas Podem estar ligadas no
alteraes realizadas sempre com trace em caso de uso ou nos
no sistema (change todos os diagramas. requisitos no diagrama
requests). de requisitos.

20/3/2008 Pgina 11 de 64
 Padro de Anlise de Sistemas
Verso 2.5

2.2.4 Classes

As classes no padro OO utilizaro podero ser importadas de sistemas j existentes

via engenharia reversa, e seguiro o padro da ferramenta usando o elemento Class,
conforme abaixo:
Elemento Objetivo Utilizado nos Ligaes Observaes
Diagramas
Especificar as classes Classes Devem ser ligadas
dos sistemas orientados entre si com os padres
a objetos. UML no diagrama de
Classes e com
dependency nos
diagramas de requisitos
e atividades.

2.2.5 Tabelas

As tabelas e outros objetos do banco de dados utilizaro o elemento do tipo Class

com stereotype Table na view Banco de Dados, conforme abaixo:
Elemento Objetivo Utilizado nos Ligaes Observaes
Diagramas
Especificar as tabelas e Classes Devem ser ligadas
outros objetos do banco entre si e nos outros
de dados. diagramas com
dependency.

2.2.6 Componentes

Os componentes de software sero documentados utilizando os tipos de elementos

abaixo:
Elemento Objetivo Utilizado nos Ligaes Observaes
Diagramas
Especificar pginas Componentes Devem ser ligadas Tipo do elemento
WEB e outros cdigos- entre si e nos outros Class com stereotype
fontes da camada View diagramas com os web page.
da aplicao. padres UML.

Especificar funes Componentes Devem ser ligadas nos Deve ser utilizada a
pblicas diagramas com tecla F4 para alterar a
(Clipper,PL/SQL e dependency. cor da borda do
outras linguagens componente para
padro PE). vermelho.
Especificar arquivos de Componentes ou Deve ser ligadas
configurao. Classe atravs de trace ao
change de alterao

20/3/2008 Pgina 12 de 64
 Padro de Anlise de Sistemas
Verso 2.5

2.2.7 Atividades

Nos diagramas de atividades sero utilizados os elementos abaixo:

Elemento Objetivo Utilizado nos Ligaes Observaes

Diagramas
ActivityInitial: Atividades Control Flow
Especifica o incio do
fluxo.
ActivityFinal: Especifica Atividades Control Flow
o fim do fluxo.

FlowFinal: Especifica o Atividades Control Flow

encerramento do fluxo
antes de chegar no
final. Tambm
utilizado para encerrar
iteraes de loops.
Activity: Especifica a Atividades Control Flow
execuo de uma
atividade no fluxo.

Activity: Especifica a Atividades Control Flow Para criar a atividade

execuo de uma composta utilizada a
atividade composta no opo Advanced-
fluxo, ou seja, >Composite Element,
redireciona para outro disponvel clicando-se
diagrama de com o boto direito no
atividades. elemento.
Structured Activity: Atividades Control Flow Para loops deve ser
Especifica atividades selecionado a opo
compostas e Loop Node na criao
estruturadas, como do elemento.
laos de repetio.
Action: Especifica Atividades Control Flow Usada para cada
aes no fluxo, como passo do controle de
por exemplo, controle transao: BEGIN
de transaes. TRANSACTION,
ROLLBACK e
COMMIT.
Decision: Especifica Atividades Control Flow
desvios condicionais
no fluxo (If e Case).

Merge: Especifica o Atividades Control Flow Deve ser utilizado

agrupamento de vrias antes de um elemento
entradas do fluxo. que pode receber mais
de uma entrada.
Object: Especifica o Atividades Control Flow Na ligao com Control
fluxo de dados entre as Flow, a cor do conector
atividades, como por deve ser cinza ao invs
exemplo, variveis e de preto.
arrays. A cor deve ser:
Red: 210 Green: 230
Blue: 211

Seguem abaixo alguns exemplos de diagramas com seus elementos e ligaes:

20/3/2008 Pgina 13 de 64
Padro de Anlise de Sistemas
Verso 2.5

Diagrama de requisitos, seus elementos e tipos de ligaes.

Diagrama de atividades e seus elementos.

20/3/2008 Pgina 14 de 64
Padro de Anlise de Sistemas
Verso 2.5

20/3/2008 Pgina 15 de 64
Padro de Anlise de Sistemas
Verso 2.5

3. Estruturas dos Projetos

3.1 Padres de Estruturas de Projetos

O projeto conter todos os sistemas de uma determinada famlia, e as views para

separar os diagramas seguiro os padres definidos por tipo de linguagem, conforme
abaixo:
- a estrutura padro para linguagens de programao estruturada (PE) utilizar as
seguintes views: Banco de Dados, Funcionalidades, Implementao, Manuteno e
Relacionamento Entre Casos de Uso.

- a estrutura padro para linguagens orientadas a objetos (OO) utilizar as seguintes

views: Banco de Dados, Requisitos, Casos de Uso, Modelo Lgico, Componentes,
Distribuio e Manuteno.

20/3/2008 Pgina 16 de 64
Padro de Anlise de Sistemas
Verso 2.5

O contedo de cada view ser detalhado a seguir.

3.1.1 Manuteno

A view Manuteno possui a finalidade de documentar as alteraes (change

requests) realizadas no modelo e por conseqncia, no sistema. Abaixo a estrutura no
Project Browser:

Estrutura da view Manuteno

20/3/2008 Pgina 17 de 64
Padro de Anlise de Sistemas
Verso 2.5

Nesta view existiro packages para as verses, itens e Artefatos do PDS,

facilitando a localizao das implementaes dentro do modelo.
Para documentar estas alteraes, o diagrama utilizado ser do tipo Manuteno
(Maintenance) e para as alteraes sero utilizados os elementos do tipo Change.
Segue abaixo exemplo do diagrama de manuteno e como fazer o rastreamento
dos elementos.

Diagramas de Manuteno com Alteraes e Sugestes de Teste

Pressionando-se CTRL+U sobre a alterao podemos rastrear os pontos de

utilizao da alterao, conforme abaixo:

Tela de utilizao dos elementos nos diferentes diagramas

20/3/2008 Pgina 18 de 64
Padro de Anlise de Sistemas
Verso 2.5

Na package Artefatos do PDS ser indicado os documentos que sero

gerados durante o processo de desenvolvimento de software.

AN (Anlise de Negcio): independente de serem chamados de PI

(projeto de implementao) ou serem anexados no SGDWeb com outro
nome, ao entrar para o controle de verses devero necessariamente
receber o prefixo AN_*.
CAR (Checklist de Avaliao de Requisitos)
FER (Formulrio de Entendimento de Requisitos)
RAI (Relatrio de Anlise de Impacto)

O objeto CAR deve estar linkado a verso do pacote atravs de dependency.

Para o exemplo abaixo devero ser utilizados os diagramas do tipo package
diagram.

Os objetos AN, FER E RAI devem estar linkados atravs de dependency ao change
de manuteno do item.

20/3/2008 Pgina 19 de 64
Padro de Anlise de Sistemas
Verso 2.5

3.1.2 Banco de Dados

A view Banco de Dados conter as tabelas e os objetos do banco utilizados pelo

sistema.
Para documentar estes objetos, o diagrama utilizado ser do tipo Classes (Logical)
e os elementos sero do tipo Class com stereotype Table. J existe um objeto
customizado com estas caractersticas que dever ser utilizado.
Nas tabelas no sero documentados os atributos, somente seus relacionamentos
de forma simplificada, pois o modelo ER completo poder ser solicitado ADO.
Segue abaixo a estrutura no Project Browser:

Diagrama da View Banco de Dados

3.1.3 Funcionalidades

A view Funcionalidades ser utilizada somente no padro PE e conter a

especificao (requisitos) e fluxo (atividades) de cada funcionalidade do sistema.

20/3/2008 Pgina 20 de 64
Padro de Anlise de Sistemas
Verso 2.5

As funcionalidades estaro agrupadas em packages pelo seu tipo especfico:

Biblioteca, Cadastros, Consultas, Movimentao, Parmetros, Processamento e
Relatrios.
Cada funcionalidade conter sempre duas packages: Especificao e Fluxo.

View Funcionalidades

Na Especificao, o diagrama utilizado ser do tipo Requisitos (Requirements) e os

elementos utilizados sero os seguintes: Class,Use Case e Requirements. Alm de seus
prprios elementos, o diagrama de requisitos possui elementos de outras views ligados no
Caso de Uso.
O diagrama de requisitos tem como objetivo especificar os requisitos funcionais e
no funcionais necessrios funcionalidade, quais os componentes de software que
implementam a mesma, quais tabelas sero impactadas e as alteraes executadas na
funcionalidade.

20/3/2008 Pgina 21 de 64
Padro de Anlise de Sistemas
Verso 2.5

Diagrama de Requisitos e seus elementos

Podem existir casos em que a funcionalidade que est sendo diagramada esteja
duplicada no Legado e em PL/SQL. Somente nestes casos podero existir dois
componentes de software ligados a um Caso de Uso, conforme exemplo abaixo:

Funes equivalentes no Legado e em PL/SQL

20/3/2008 Pgina 22 de 64
Padro de Anlise de Sistemas
Verso 2.5

No Fluxo, o diagrama utilizado ser do tipo Atividade (Activity) e os elementos

utilizados sero os descritos na tabela vista anteriormente. Alm de seus prprios
elementos, o diagrama de atividades ainda poder conter atividades com requisitos
ligados, indicando a execuo dos mesmos.

Diagrama de atividades, com alguns requisitos

vinculados certas atividades

O diagrama de atividades deve ser detalhado o suficiente para que o programador

consiga implementar a rotina sem maiores dvidas.

20/3/2008 Pgina 23 de 64
Padro de Anlise de Sistemas
Verso 2.5

3.1.4 Requisitos

A view Requisitos ser utilizada somente no padro OO ser semelhante view

Funcionalidades, pois conter a especificao (requisitos) de cada funcionalidade do
sistema ou ainda requisitos padres a todas as funcionalidades (Ex: campos padres,
etc.). As funcionalidades tambm estaro agrupadas em packages pelo seu tipo
especfico: Biblioteca, Cadastros, Consultas, Movimentao, Parmetros, etc.

View Requisitos

O diagrama utilizado ser do tipo Requisitos (Requirements) e os elementos

utilizados sero os Requirements. Alm de seus prprios elementos, o diagrama de
requisitos possuir elementos de outras views, tais como Class, Use Case e Components.
O diagrama de requisitos tem como objetivo especificar os requisitos funcionais e
no funcionais necessrios funcionalidade, quais os componentes de software (ou
classe) que implementam a mesma, quais tabelas sero impactadas e as alteraes
executadas na funcionalidade.

Diagrama de requisitos de sistemas orientados a objetos

20/3/2008 Pgina 24 de 64
Padro de Anlise de Sistemas
Verso 2.5

3.1.5 Implementao

A view Implementao ser utilizada somente no padro PE e conter os fontes do

do sistema. Cada cdigo-fonte ter uma package com seu nome e extenso, separadas
por packages da estrutura fsica do projeto.
Na Implementao, o diagrama utilizado ser do tipo Componentes (Components) e
os elementos utilizados sero do tipo Component.
Devero ser documentadas somente as funes e procedures pblicas do sistema,
pois as estticas ficaram sobre responsabilidade do codificador.

View Implementao com suas packages e componentes

Os componentes devero ter sua cor da borda alterada para vermelho, atravs da
tecla F4 com o componente selecionado.
Os componentes sero utilizados para identificar qual funo pblica implementa
um determinado caso de uso, conforme exemplo a seguir:

Componente indica qual funo implementa o caso de uso

20/3/2008 Pgina 25 de 64
Padro de Anlise de Sistemas
Verso 2.5

3.1.6 Casos de Uso

A view Casos de Uso ser utilizada somente no padro OO e conter os Casos de

Uso do sistema no padro UML, somente com relacionamentos entre outros casos de uso
e atores, separados em packages de acordo com sua funcionalidade.

View Casos de Uso

Na view Casos de Uso ter a package Relacionamento Entre Casos de Uso, que
armazenar o relacionamento entre Casos de Uso.

Nos Casos de Uso, o diagrama utilizado ser do tipo Casos de Uso (Use Case) e
os elementos utilizados sero do tipo Use Case e Actors.

20/3/2008 Pgina 26 de 64
Padro de Anlise de Sistemas
Verso 2.5

Diagrama de Caso de Uso, seus elementos e relacionamentos

3.1.7 Modelo Lgico

A view Modelo Lgico ser utilizada somente no padro OO e conter o Modelo

Lgico do sistema no padro UML, somente com suas classes e os relacionamentos entre
elas, separados em packages de acordo com a estrutura do projeto.
Nos projetos j existentes pode ser utilizada a opo de engenharia reversa para
importar as classes, na opo do Code Engineering -> Import Source Directory do menu
do boto direito.

View Modelo Lgico

20/3/2008 Pgina 27 de 64
Padro de Anlise de Sistemas
Verso 2.5

No Modelo Lgico, o diagrama e os elementos utilizados sero do tipo Classes

(Class).

Diagrama de Classes

3.1.8 Componentes

A view Componentes ser utilizada somente no padro OO ser semelhante view

Implementao do padro PE, contendo o restante dos componentes de software do
sistema orientado a objetos (pginas, arquivos XML, fontes PL/SQL, etc.) e a relao
destes componentes com as classes e as camadas da aplicao (view, model, controller,
etc.), separados em packages de acordo com a estrutura do projeto.

View Componentes
Nos projetos j existentes, tambm pode ser utilizada a opo de engenharia
reversa para importar os componentes.

20/3/2008 Pgina 28 de 64
Padro de Anlise de Sistemas
Verso 2.5

Diagrama de componentes com as camadas da aplicao

3.1.9 Distribuio

A view Distribuio ser utilizada somente no padro OO e conter a viso da

arquitetura da aplicao (topologia, servidores, etc.).
Esta view no ser obrigatria por enquanto, mas de grande valia para elucidar a
arquitetura de produo para novos profissionais.

3.1.10 Relacionamento Entre Casos de Uso

A view Relacionamento Entre Casos de Uso ser utilizada somente no padro PE,
no padro OO o Relacionamento Entre Casos de Uso estar na view Casos de Usos.
Est view conter os Relacionamentos entre os Casos de Uso mais importantes do
Sistema.
O tipo de relacionamento utilizado nos diagrama de Relacionamentos Entre Casos
de Uso dependency.

20/3/2008 Pgina 29 de 64
Padro de Anlise de Sistemas
Verso 2.5

Diagrama Relacionamento Entre Casos de Uso

20/3/2008 Pgina 30 de 64
Padro de Anlise de Sistemas
Verso 2.5

4. Procedimentos

O processo de Anlise de Sistemas est composto por duas principais etapas:

Levantamento de Requisitos da Anlise de Negcio e Especificao do Item para
desenvolvimento. Alm destas, tambm pode existir a necessidade de mais uma etapa de
Documentao Inicial, caso no exista documentao de Anlise de Negcios.

act Inicial

Funcionalidade Documentao inicial

documentada
[Nao]

[Sim]

Lev antamento de
Requisitos

Especificao do item

20/3/2008 Pgina 31 de 64
Padro de Anlise de Sistemas
Verso 2.5

4.1 Levantamento de Requisitos

act Lev antamento de Requisitos

Identificar
requisitos
funcionais
Identificar
alteraes no
modelo
Identificar
requisitos nao
funcionais

4.1.1 Identificar requisitos funcionais

Sem dvida esta a atividade mais importante da Anlise de Sistemas. Identificar

os requisitos funcionais pode no ser to simples quanto parece, pois podem estar
escondidos no texto da Anlise de Negcio ou, muitas vezes, implcitos.
Um requisito pode ser definido como "uma condio ou uma capacidade com a qual o
sistema deve estar de acordo". Os requisitos funcionais especificam aes que um sistema
deve ser capaz de executar, sem levar em considerao restries fsicas. Especificam,
portanto, o comportamento de entrada e sada de um sistema.
So documentados na pasta Manuteno como requisito ou alterao (se o requisito j
existir deve ser registrada uma alterao). Quando uma alterao realizada deve ser
vinculada com o link Trace ao requisito ou ao caso de uso. Abaixo um exemplo de um
requisito de manuteno visando incluir um campo na tela do cadastro de finalidades.

1: ALT-001 uma mudana do requisito REQ-0037

20/3/2008 Pgina 32 de 64
Padro de Anlise de Sistemas
Verso 2.5

4.1.2 Identificar requisitos no funcionais

Requisitos no funcionais estabelecem restries gerais do sistema em termos de

usabilidade, performance, confiabilidade, documentao, entre vrios outros. Estes podem
estar diretamente ligados ao caso de uso (mediante Realisation) ou a qualquer outro
elemento. Abaixo um exemplo de requisitos no funcionais:

As linhas vermelhas apontam os requisitos no funcionais. Isto , os que no

evitam que a rotina funcione, mas garantem sua qualidade.

4.1.3 Identificar alteraes no modelo

Uma vez que os requisitos funcionais e no funcionais foram identificados devem

ser vinculados ao modelo existente. Para isto utiliza-se o link Trace. Veja exemplo
abaixo:

20/3/2008 Pgina 33 de 64
Padro de Anlise de Sistemas
Verso 2.5

Podemos visualizar que, para o item 2296, foi identificado uma alterao na rotina
de atualizao de base. O requisito de alterao (em verde) est ligado ao requisito
funcional Atualizao de Base. A leitura deste diagrama que a Atualizao de base da
funcionalidade sofreu uma alterao no item 2296.

No grfico acima, observa-se que o item 2298 implementou uma atualizao de

base (requisito funcional) e uma alterao na tela do cadastro.

20/3/2008 Pgina 34 de 64
Padro de Anlise de Sistemas
Verso 2.5

4.2 Especificao do Item

4.2.1 Atualizar diagramas de caso de uso, atividades e implementao

Neste ponto j esto todos os requisitos levantados e colocados dentro da pasta de

manuteno (no respectivo item e verso) e ligados nos casos de uso impactados. Neste
momento devemos detalhar cada implementao utilizando os templates fornecidos na
ferramenta e comentrios que sejam necessrios para garantir que o programador capte o
solicitado.
Um exemplo de detalhamento por comentrios pode ser observado abaixo:

req Especificao

REQ-0026: tecla
[ESC]

20/3/2008 Pgina 35 de 64
Padro de Anlise de Sistemas
Verso 2.5

A tela acima pode ser acessada com um duplo-click no requisito (ou em qualquer
outro elemento).
Quando o requisito for de tela, relatrio, alterao de tabela ou algum outro que
necessite de uma especificao mais complexa, utilizam-se os templates e documentos
vinculados.

4.2.2 Solicitar alteraes ADO e atualizar diagrama de entidades

Sempre que existir alterao ou criao de tabelas, deve-se utilizar um requisito de alterao
com um documento vinculado atravs da opo do boto direito Linked Document...,
utilizando o template de Solcitao ADO. Veja abaixo um exemplo:

20/3/2008 Pgina 36 de 64
Padro de Anlise de Sistemas
Verso 2.5

req item 2298

ALT-0002: Nova
tabela

A alterao tambm deve ser ligada tabela, para rastreamento dos objetos impactados.
class ER

grupo_empreendimento_ccrpfina
ALT-0002: Nova
trace tabela

(from item 2298)

Alm disto, deve ser adicionada uma tag na change, atravs do boto direito, seleciondo-se a
opo Add e em seguida Tagged Value..., conforme imagem abaixo:

20/3/2008 Pgina 37 de 64
Padro de Anlise de Sistemas
Verso 2.5

Na combo box do campo Tag:, deve ser selecionado o valor ADO, que j estar previamente
cadastrado, conforme imagem abaixo:

No campo Value: deve ser informado o valor TRUE, em letras maisculas, conforme imagem
abaixo:

20/3/2008 Pgina 38 de 64
Padro de Anlise de Sistemas
Verso 2.5

Segue abaixo o template para solicitaes ADO:

Para enviar esta solicitao ADO, deve ser criada uma atividade avulsa no SGD
com dos dados abaixo:
Padro que deve estar no campo Descrio da atividade
Nome do repositrio/equipe: <exemplo: eap_sicredi, eap_sis>
Nome da pasta: <ex.:canais de Apoio>
Sistema: <sigla do sistema>
Verso do sistema: <onde est sendo realizada a alterao>
N item: <n do item no SGD que est saindo a alterao>
N subitem: <n do subitem da alterao caso exista>
Nome do change: <change/requisito de alterao que contm o documento
linkado>

20/3/2008 Pgina 39 de 64
Padro de Anlise de Sistemas
Verso 2.5

4.2.3 Atualizar diagrama de atividades

O diagrama de atividades o mais importante para o desenvolvedor. Este valida e

especifica o caso de uso e seus requisitos. O detalhamento do diagrama depende da
necessidade de especificar certa funcionalidade. Exemplo:

Observa-se que esto alocados os principais requisitos levantados na especificao

e as tabelas impactadas no item. Isto opcional, mas altamente recomendado.

20/3/2008 Pgina 40 de 64
Padro de Anlise de Sistemas
Verso 2.5

4.3 Documentao Inicial

act Documentao inicial

Lev antamento Lev antamento Esboo do

de requisitos de tabelas prottipo de tela
bsicos env olv idas e relatrio

Montar
Atualizar Diagrama de diagrama de
diagrama de ativ idades caso de uso
implementao bsico com seus
requisitos

4.3.1 Pr-documentao da funcionalidade a ser alterada

As primeiras especificaes no tero documentao na ferramenta. Portanto,

torna-se necessrio realizar um pr-levantamento da funcionalidade impactada. Os
diagramas que devem ser criados e mantidos so os mesmos mencionados neste
documento, mas de uma forma simplificada evitando um impacto inicial alto. Ao passar do
tempo estas anlises sero complementadas elevando o nvel de detalhamento.
O primeiro passo identificar o fonte e inseri-lo no diagrama de implementao.
Depois, monta-se o caso de uso e realiza-se um levantamento bsico de requisitos (aes
da rotina e outros pontos que sejam relevantes para a alterao proposta pelo item).
Realiza-se um mapeamento das principais tabelas envolvidas e criam-se (se ainda no
existirem) no diagrama de Entidades. Com tudo isto pronto monta-se o diagrama de
atividades bsico visando suportar as alteraes propostas. Abaixo, um exemplo do
cadastro de finalidades do sistema de crdito, onde o item 2298 solicitou um novo campo
na tela.

20/3/2008 Pgina 41 de 64
Padro de Anlise de Sistemas
Verso 2.5

req item 2298

ALT-0001: Incluir REQ-0039: Os

campo para grupos devem ser
grupo de selecionados
empreendimento mediante um
browse

ALT-0002: Nova
tabela

REQ-0049:
Atualizao de
Base

2: levantamento das alteraes necessrias para o item 2298 (no diagrama de manuteno)

3: Diagrama de caso de uso e requisitos da rotina.

20/3/2008 Pgina 42 de 64
Padro de Anlise de Sistemas
Verso 2.5

20/3/2008 Pgina 43 de 64
Padro de Anlise de Sistemas
Verso 2.5

4: Diagrama de atividades inicial da rotina. Observa-se que est simplificado mas esboa perfeitamente seu comportamento.

5: Prottipo bsico da tela da rotina

4.4 Templates disponveis

O EA permite a incluso de templates para facilitar a especificao das

funcionalidades. Para vincular um template utilizar a opo Linked Document (ou
CTRL+ALT+D) de cada objeto do diagrama.

20/3/2008 Pgina 44 de 64
Padro de Anlise de Sistemas
Verso 2.5

Seleo de templates disponveis

4.4.1 Solicitao ADO

Este template visa documentar as alteraes de estrutura de tabelas e a criao/

manuteno de ndices. Sempre deve ser vinculado a um requisito de mudana de
estrutura ou criao de tabelas/objetos no banco de dados.

4.4.2 Prottipo de Tela

Prottipos de tela visam especificar, de forma completa, as telas e campos da

funcionalidade. O template deve estar vinculado a um requisito de tela.

Requisito de tela em azul no diagrama de requisitos.

20/3/2008 Pgina 45 de 64
Padro de Anlise de Sistemas
Verso 2.5

Seleo do Tipo de Requisito

4.4.3 Prottipo de Relatrio

A especificao funciona da mesma forma que o prottipo de tela, ou seja, um

requisito do tipo relatrio e um template vinculado para esta finalidade.

4.4.4 Caso de Uso

O caso de uso pode ser estendido vinculando-se a um template de caso de uso,

especificando cenrios e condies.

4.5 Mecanismos de Rastreabilidade

H trs mecanismos de rastreabilidade que so recomendados para fins de anlise

de impacto ou mesmo entendimento e localizao da utilizao de elementos (casos de
uso, requisitos, tabelas, etc.).

4.5.1 Uso do Elemento

possvel rastrear a utilizao de um elemento em todos os diagramas que utilizam

este elemento. Para isto, basta clicar sobre o elemento e utilizar uma das opes abaixo:
Menu Element > Find in diagrams...

20/3/2008 Pgina 46 de 64
Padro de Anlise de Sistemas
Verso 2.5

CTRL + U

Seleo do Diagrama que est usando o elemento

4.5.2 Hierarquia de Uso do Elemento

Sintetizando, permite rastrear a utilizao de um elemento segundo as vises:

necessrio para (needed by), depende de (depends on) e aponta para (links to).
Menu View > Hierarchy
CTRL + SHIFT + 4
A seguir seguem exemplos do uso deste recurso.

20/3/2008 Pgina 47 de 64
Padro de Anlise de Sistemas
Verso 2.5

Hierarquia do objeto com profundidade nvel 5

Hierarquia do objeto com profundidade nvel 2

20/3/2008 Pgina 48 de 64
Padro de Anlise de Sistemas
Verso 2.5

possvel fazer a configurao do nvel de profundidade que se deseja adentrar

quanto aos elementos relacionados. Quanto maior a profundidade, mais demorado tende a
ser a montagem do resultado da pesquisa de hierarquia, contudo, mais ricos sero os
resultados em termos de favorecer uma correta anlise de impacto. A configurao padro
do EA faz a hierarquia at o 5 nvel a partir do elemento pesquisado. Para realizar esta
configurao deve-se acessar o menu Tools > Options > aba General > campo Max
Hierarchy View Depth.

20/3/2008 Pgina 49 de 64
Padro de Anlise de Sistemas
Verso 2.5

4.5.3 Matriz de Rastreabilidade

Possibilita visualizar os relacionamentos entre todos os elementos, a partir de um

pacote de origem e um pacote destino, sendo de um tipo (caso de uso, requisito, etc)
versus outro, contendo ligaes do tipo dependncia, realizao, etc.. Para o caso,
recomenda-se que seja feito o uso deste recurso aplicado para o pacote (origem (source) e
destino (target)) Caso de Uso > Funcionalidades (do sistema em questo), tipo (type) Use
Case versus Use Case, e tipo de ligao (Link Type) dependncia (dependency). Isto far
com que a matriz de rastreabilidade seja montada com a finalidade de exibir as
dependncias entre os casos de uso existentes a partir do pacote de origem e destino.
Para fazer uso da matriz e informar estes parmetros deve-se acessar o menu View >
Relationship Matrix. Importante: aps configurar e gerar a matriz use o boto Options >
Profiles > Save as New Profile para salvar a configurao da matriz do sistema em
questo (no exemplo, foi salvo como Matriz Site UFV).

Matriz de rastreabilidade de dependncias entre casos de uso

20/3/2008 Pgina 50 de 64
Padro de Anlise de Sistemas
Verso 2.5

5. Apndice

5.1 Agregao

Um conceito que pode ser utilizado na diagramao Agregao. Veja exemplo

abaixo:

act teste

Tela do Tela do Tela do

produto 01 produto 02 produto 03

Tela
principal

Funcionalidade

Observamos que a tela principal do sistema est composta por trs outras telas.
Cada uma das trs telas deve conter um prottipo de tela vinculado.

Este recurso pode ser aplicado praticamente em qualquer elemento. Abaixo outro
exemplo com requisitos da funcionalidade:

req teste

Permitir consulta Funcionalidade

de associados
com [F4]

Seleciona com Permitir consulta

[Enter] e cancela de ttulos com
com [ESC] [F4]

20/3/2008 Pgina 51 de 64
Padro de Anlise de Sistemas
Verso 2.5

Selecionar com a tecla [Enter] e canelar com a tecla [ESC] deve ser atendido pelos
dois requisitos.

5.2 Controle de Verso (CVS)

O Controle de Verso do modelo ser realizado via CVS e no mesmo repositrio

dos sistemas.
Ao final de cada pacote, o projeto deve ser exportado para XML e armazenados no
CVS, na pasta analise_sistemas de cada sistema.

Estrutura do CVS para especificaes EA

20/3/2008 Pgina 52 de 64
Padro de Anlise de Sistemas
Verso 2.5

Para fazer a exportao os seguintes passos devem ser seguidos:

Clicar com o boto direito no modelo do sistema, selecionem a opo Export Model to
XMI...

Na caixa de dilogo, informar o caminho e nome do arquivo XML a ser criado e na opo
XMI Type selecionem UML 2.1 (XMI 2.1). Aps clicar no boto Export.

Os arquivos gerados devem ser commitados na pasta analise_de_sistemas de cada

sistema.

20/3/2008 Pgina 53 de 64
Padro de Anlise de Sistemas
Verso 2.5

5.3 Try..Catch..End

Para documentar o Try..Catch..End deve ser utilizado o exemplo abaixo:

20/3/2008 Pgina 54 de 64
Padro de Anlise de Sistemas
Verso 2.5

5.4 Adicionar Autores

Para adicionar autores devem ser seguidos os passos abaixo:

Selecionar a opo do menu Settings -> People -> Project Authors

Para adicionar o autor nos diagramas, basta clicar no boto New Diagram Notes,
e para mudar, clicar com o boto direito no diagrama e depois acessar Properties...,
selecionando o autor na combo box.

20/3/2008 Pgina 55 de 64
Padro de Anlise de Sistemas
Verso 2.5

Para adicionar nos diagramas, basta clicar no boto New Diagram Notes, e para
mudar, clicar com o boto direito no diagrama e depois acessar Properties...,
selecionando o autor na combo box.

20/3/2008 Pgina 56 de 64
Padro de Anlise de Sistemas
Verso 2.5

5.5 Diagrama de fonte de Include ( *.CH )

Na Implementao deve ser criado uma package com a descrio Header e adicionar uma
Class com a descrio do arquivo header, mudando o sterotype para header

20/3/2008 Pgina 57 de 64
Padro de Anlise de Sistemas
Verso 2.5

Adicionar a package no diagrama de composio de estrutura da Implementao

Adicionar a alterao no diagrama de composio de estrutura da package Header,

ligando a alterao atravs de trace

20/3/2008 Pgina 58 de 64
Padro de Anlise de Sistemas
Verso 2.5

Por ltimo ligar a classe do arquivo header na package do fonte que utiliza este arquivo, no
diagrama de composio de estrutura da lib do fonte

5.6 Incluir opo de menu

No diagrama de requisitos da funcionalidade que ser disponibilizada no menu deve ser

adicionado somente um requisito funcional, no sendo necessrio adicionar a alterao e o
componente neste diagrama.

20/3/2008 Pgina 59 de 64
Padro de Anlise de Sistemas
Verso 2.5

A alterao deve ser adicionada na funcionalidade da montagem de menus de cada

sistema

20/3/2008 Pgina 60 de 64
Padro de Anlise de Sistemas
Verso 2.5

5.7 Fontes localizados na pasta Raiz dos Sistemas

Para fontes que esto na pasta raiz dos sistemas, como os includes ou .prg de macro-
sistemas ( Ex: CCRC, SIAT, etc ) que tiverem alteraes, dever ser criada uma package
chamada RAIZ no EA na implementao para documentar

5.8 Documentao de JOB

Criar uma package Jobs sob a package Banco de Dados

20/3/2008 Pgina 61 de 64
Padro de Anlise de Sistemas
Verso 2.5

Criar um objeto para o job sob a package recm criado, com uma identificao de sua
funcionalidade (no o nmero do job, uma vez que ele um nmero seqencial que no
depende do analista de sistemas). Criar tambm um diagrama de objetos, para que possa ser
colocado o job.

Colocar o job dentro do diagrama de objetos

20/3/2008 Pgina 62 de 64
Padro de Anlise de Sistemas
Verso 2.5

Criar uma package Jobs dentro da rea de funcionalidades do aplicativo, criando as

packages Especificao e Fluxo para que sejam criados os diagramas de requisitos e atividades
correspondentes (para o caso de PE). Para OO eu no cheguei a fazer um exemplo.

Criar o diagrama de requisitos dentro da pasta Especificao. O job deve ser adicionado
como link dentro desse diagrama.

20/3/2008 Pgina 63 de 64
Padro de Anlise de Sistemas
Verso 2.5

Criar o diagrama de atividades, criando uma atividade do tipo Composite para

representar a atividade do job propriamente dita. Apontar nesse diagrama o job como link e
adicionar uma nota com as regras de execuo do mesmo.

20/3/2008 Pgina 64 de 64